IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Specifically, I verified that *before* the previous patch to the
ed25519 C code, the last bit of code would fail with a SIGSEGV when
trying to read the empty signature.
The pattern this API uses in C is to allow the input parameters
pointer targets to be `NULL`, and it doesn't return values in that
case.
A further complexity here is that the API will still return `NULL`
for symbolic links.
But Rust can't express this pattern as is, so we were always
returning values but in `Option<T>` wrappers that the caller needed
to unwrap for the metadata.
(We really want an even more efficient API here that avoids the glib
objects entirely, e.g. no reason not to pass directly back a type
that lets Rust directly read from the fd for bare repos, but
that can come later)
Because the source is in a subdirectory, we lose out on cargo target
autodiscovery.
I noticed this when I edited one of the tests in a way that
should have failed, but didn't...
No real changes.
```
$ cargo fix --edition
note: Switching to Edition 2021 will enable the use of the version 2 feature resolver in Cargo.
This may cause some dependencies to be built with fewer features enabled than previously.
More information about the resolver changes may be found at https://doc.rust-lang.org/nightly/edition-guide/rust-2021/default-cargo-resolver.html
When building the following dependencies, the given features will no longer be used:
libc v0.2.126 removed features: extra_traits
The following differences only apply when building with dev-dependencies:
getrandom v0.2.6 removed features: std
```
which looks OK to me.
There were some changes to the sys API for introspection fixes.
And add a feature for the current release, which is something
I'll add to the checklist for releases.
Fix up the paths for the crates now that the Rust bindings are in
`rust/`.
We can't today include the test suite because it depends on `ostree-rs-ext`
which would make everything circular.
(Building that now requires a separate `cd tests/inst && cargo build`)
I want to write APIs that *require* the caller to have set up
an ostree transaction. It's natural to require passing a guard
to do so. But then we want an accessor for the repo.
The underlying `ostree_repo_load_file()` API has the caller pass
`NULL` for output arguments it doesn't want. This isn't sanely
bindable in Rust - what the generator does is always request
all values, but maps them all to `Option<T>`.
The main cases are where a user wants either metadata, or both
metadata and content. This API gives just metadata; it's a
bit more efficient as we don't need to open the file, and doesn't
require the caller to `unwrap()`.
Today we hardcode `/bin/bash` in
2088d24884/src/cmd-build (L405)
But that breaks the concept of a bidirectional bridge between
container image and ostree commit because this little bit of
knowledge is encoded at the buildsystem side.
This metadata key is intended to be written into an ostree commit,
and then we will use it automatically in `container encapsulate`.
The "source of truth" for this key will hence be able live in the same
place that's generating the ostree commit.
The more "proper" place for this is probably alongside the other
constants in the libostree core C code. But that's tedious and
slow to release. And Rust is the future. And we've been slowly
adding more "core ostree" functionality here.
Followup to the previous PR. I realized now with `io_lifetimes`
we can offer a safe `dfd_borrow()` that *borrows* the file descriptor
for the repository. (In contrast to the current `.dfd()` that returns
the raw version)
Building on that, add another API that re-acquires a `Dir` instance.
(In the future in theory we could optimize this more by knowing
whether or not the repo was constructed via cap-std, and perhaps
in theory synthesize a `&Dir` reference, but I don't think we
need that now)
I'm trying to make more use of `cap-std` in our stack, and
this will be a key enabling API.
Actually a notable side benefit of this is that we don't need
to teach the ostree C code itself to use `openat2`, we inherit
cap-std's setup.
All of the internal ostree code using the prior `openat()` should
continue to work.
I only did basic sanity checking of this; there may be bugs
in other APIs.
The fact that the uid/gid/mode are big endian bit me when I was
trying to parse this "by hand" in ostree-rs-ext.
Let's add a footgun-free API for this.
(And yeah, we should probably do the same for the other variant types)
