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...
We recently discovered `list_objects()` is inefficient with memory.
The more efficient `list_objects_set()` API isn't yet public, but
this fsck code actually just skips over non-commit objects, and
we already have an API to list just those.
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.
When we did the merger, it turns out cargo by default is basically
going to include all of stuff in the git repository root directory
which is "libostree". We just want the stuff in `rust-bindings/`.
I initially tried adding `include = "rust-bindings/"` but
according to
https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields
specifying `include` means that `exclude` is
ignored, which is kind of annoying. Further, doing so *also*
turns off the cargo automatic rules for handling e.g. `gitignore`.
So for now I went with the approach of adding everything from the C
library stuff into `exclude/`.
I messed this up; the last release should inherit from the previous
release (N-1) and not the previous to that (N-2).
I think (hope) this isn't an ABI break...
Just noticed this when I was going to add a new symbol.
In https://github.com/ostreedev/ostree/pull/2633 I realized
that our CI only builds git of libostree or git of rust-bindings,
not git of both. And we definitely want to test the latter too,
so e.g. the Rust tests *also* become tests for changes to the C code.
In a prior change we discovered that for bad historical reasons
libostree was returning a mapping "object type+checksum" => "metadata"
but the "metadata" was redundant and pointless.
Optimize the prune API to use a (currently internal) object listing
API which returns a set, not a map. This allows `GHashTable` to
avoid allocating a separate array for the values, neatly cutting
memory usage in half (from ~13MB to ~6MB) on my test case of a
dry-run prune of a FCOS build.
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.
I was looking at https://github.com/ostreedev/ostree/pull/2632
and confused at the usage of
`GVariant *value = g_variant_new ("(b@as)", TRUE, g_variant_new_strv (NULL, 0));`
which looked strange - why the empty strv?
It turns out that this is a historical legacy of the time when
ostree had pack files. And nothing actually cares about the values
of these variants; we should have an API that returns a proper set,
and not a hash.
But...since all of these things have exactly the same value, instead
of allocating lots of redundant copies on the heap, just have
them all hold a refcount on a shared value.
This cuts the heap usage from 20MB to 13MB on a test FCOS repository
build.
It inherently depends on the individual build, and can't
really be an official stable API for introspection users.
I've noticed the value of this flip flop when doing local builds.
I'm fairly certain no one is trying to use it from a higher level
language.
It'd probably make sense to even drop from the official C API,
but I'm trying to be conservative with that.
I was looking at our `.gir` and noticed we had the cmdprivate bits
because the pattern for excluding headers is `-private.h`, which
didn't match `cmdprivate.h`.
There's a pile of new warnings in GCC 12 from F36, I dug into
them but most of them seem inscrutable - I am not seeing the bugs.
For now to unblock further work, stop using this flag.
I'm aiming to do some more work on the Rust side around `fsck`
like functionality, and this is a useful primitive. There isn't
a great Rust crate for xattrs, and I think it's better to share this
code.
It's really tempting to remove `make syntax-check`, it has very
very rarely found any real problems.
But anyways, just exclude all the binding code because it trips
up random problems we simply don't care about like mentions of
`O_NDELAY` in the `GLib-2.0.gir`.
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
https://github.com/coreos/coreos-assembler/blob/2088d24884771093101d95f915c921505128ef76/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)
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.
This way it's more convenient for downstream crates like ostree-rs-ext
to convert loaded variants.
TODO: Can we add a feature for the `gvariant` crate and expose via
that too?
An intimidating spam of compiler errors at the start, but the
biggest was handling the new convention of `ostree_sys::` => `ffi::`.
This will require a semver bump of course.
Colin Walters