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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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)
This splits the builder completion step into separate actions for
creating/loading a sysroot.
It also introduces a roundtrip test over a freshly-created empty
sysroot.
This adds a `SysrootBuilder` in order to allow consumers to load
a configured `Sysroot` in an ergonomic way. It tries to prevent
logic bugs coming from handling half-initialized entities.
The `resolve_rev` C method should really have been
`resolve_rev_optional` from the start - it is more obviously wrong
in Rust because the input parameter `allows_noent` controls
whether the returned `Option` can ever be `None`.
I debated adding this to the C bindings, and may still do so,
but eh it's faster to write + ship in Rust, and the future of ostree is
Rust anyways.
This gives auto-cancelling semantics on `Drop`, plus a nicer
`.commit()` method on the transaction.
Matches the currently private `_OstreeRepoAutoTransaction` in the C
library.
```
Colin Walters (8):
Add 2021.3 feature
Re-export glib, gio
Deny unused results, warn on missing docs (except auto/)
Add new GLib 0.14 variant types for metadata types
Fix build with --features=v2021_3, use in CI by default
Add more documentation for --features=v2021_3
Use glib-sys via re-exported `glib::ffi` (and similar for gio)
Release 0.12.2
Luca BRUNO (5):
cargo: fix version in features chain
lib: fix 'dox' feature
cargo: point to docs.rs and clean up
ostree: release 0.12.1
cargo: bump ostree-sys to 0.8.1
```
In general only `-sys` crates should depend on other `-sys`
crates. IOW for us, `ostree-sys` depends on `glib-sys`.
By using the re-export, we avoid needing to keep a version lock
between `glib` and `glib-sys` in our main crate. And similar
is true of our higher level reverse dependencies (e.g. `ostree-rs-ext`).
Also weaken our dependency to `0.14` as that's clearer.
It's a huge trap for us not to build with the latest ostree feature
on, I didn't have my IDE configured for it, and CI didn't have
it on.
The previous bump to glib 0.14 broke the Sign code.
