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.
Ultimately a repo is just a file descriptor wrapper with some
cached data, etc. We can send it between threads, much like how
`gio::File` is `Send`.
Motivated by trying to write to a repo from a separate thread
in https://github.com/cgwalters/ostree-container
Quite a while ago we added staged deployments, which solved
a bunch of issues around the `/etc` merge. However...a persistent
problem since then is that any failures in that process that
happened in the *previous* boot are not very visible.
We ship custom code in `rpm-ostree status` to query the previous
journal. But that has a few problems - one is that on systems
that have been up a while, that failure message may even get
rotated out. And second, some systems may not even have a persistent
journal at all.
A general thing we do in e.g. Fedora CoreOS testing is to check
for systemd unit failures. We do that both in our automated tests,
and we even ship code that displays them on ssh logins. And beyond
that obviously a lot of other projects do the same; it's easy via
`systemctl --failed`.
So to make failures more visible, change our `ostree-finalize-staged.service`
to have an internal wrapper around the process that "catches" any
errors, and copies the error message into a file in `/boot/ostree`.
Then, a new `ostree-boot-complete.service` looks for this file on
startup and re-emits the error message, and fails.
It also deletes the file. The rationale is to avoid *continually*
warning. For example we need to handle the case when an upgrade
process creates a new staged deployment. Now, we could change the
ostree core code to delete the warning file when that happens instead,
but this is trying to be a conservative change.
This should make failures here much more visible as is.
The `archive_entry_symlink()` API can definitely return `NULL`,
reading through the libarchive sources.
I hit this in the wild when using old ostree-ext to try to unpack
a chunked archive.
I didn't try to characterize this more, and sorry no unit test right
now.
I was reading this thread
https://internals.rust-lang.org/t/from-life-before-main-to-common-life-in-main/16006/30
and that reminded me about this code, which it turns out actually
doesn't compile with my default local cargo config:
```
$ cat ~/.cargo/config
[target.x86_64-unknown-linux-gnu]
rustflags = ["-Ctarget-cpu=native", "-C", "link-arg=-fuse-ld=lld"]
[profile.release]
incremental = true
$ cargo b
...
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-m64" "/var/srv/walters/src/github/ostreedev/ostree/target/debug/deps/ostree_test-4ca8e730f9dc6ffc.10325uqlhkyr5uol.rcgu.o" "/var/srv/walte"
= note: ld.lld: error: undefined symbol: __start_linkme_NONDESTRUCTIVE_TESTS
>>> referenced by 22nn09lfsklfqvyy
>>> /var/srv/walters/src/github/ostreedev/ostree/target/debug/deps/ostree_test-4ca8e730f9dc6ffc.22nn09lfsklfqvyy.rcgu.o:(ostree_tes)
```
For now let's just go back to having a static list of functions.
We don't have *too* many of those.
I'm working on enhancing the ostree-rs-ext test suite and I hit
a bug where walking a mtree and creating a parent would fail to
load lazy intermediate directories, e.g.:
/ -> usr -> bin
If we walked we'd load `/` but keep `usr` lazy, and then invalidation
would crash because it wasn't loaded.
If we're going to mutate a subdir, we need to have all the parents
loaded.
I know this is missing tests, but...it's a bit tedious to do with
the existing C tests. Eventually soon we'll execute on merging
all 3 repos, and better share test suites.
This is failing for me as of recently but only when I build
without optimization. I don't think we've ever written any
code that returned a large structure by value.
Let's just drop this one.
We do implicitly have this data because we log timings via structured
metadata in a later journal entry, but it's quite common to lose
the structured metadata because a lot of tooling just grabs the default
syslog-compatible text from `journalctl`.
Let's be louder when we hit this case as a general rule too; I think
most people shipping ostree systems want to see if it's happening.
https://bugzilla.redhat.com/show_bug.cgi?id=2003532
Basically there's a systemd bug where it's losing the `_netdev`
aspect of Ceph filesystem mounts. This means the network is taken
down before Ceph is unmounted. In turn, our invocation of `sync()`
blocks on Ceph, which won't succeed.
And this in turn manifests as a failure to transition to the new
deployment.
I initially did this patch to just rip out the global `sync()`. I
am pretty sure we don't need it anymore. We've been doing individual
`syncfs()` on `/sysroot` and `/boot` for a while now, and those
are the only filesystems we should be touching. But *proving* that
is a whole other thing of course.
To be conservative, let's instead just add a timeout of 5s on
our invocation of `sync()`. It doesn't return any information on
success/error anyways.
To allow testing without the `sync()` invocation, we also support
a new `OSTREE_SYSROOT_OPT_SKIP_SYNC=1` environment variable. For
staged deployments, this needs to be injected via e.g. systemd unit
overrides into `ostree-finalize-staged.service`.
Implementing this is a bit hairy - we need to spawn a thread. I
debated blocking in arecursive mainloop, but I think `g_cond_wait_until()`
is also fine here.
In fixing https://github.com/coreos/rpm-ostree/pull/3323
I felt that it was a bit ugly we're installing `/usr/bin/ostree-container`.
It's kind of an implementation detail. We want users to use
`ostree container`.
Let's support values outside of $PATH too.
For example, this also ensures that TAB completion for `ost` expands
to `ostree ` with a space.
Fixes `Argument with 'nonnull' attribute passed null` by making
the code not exist at all anymore.
In upstream libsoup this code is gone too; it uses `GUri` from glib
which we probably could now too, but one thing at a time.
This is trying to address:
https://pagure.io/fedora-iot/issue/48
Basically we changed rpm-ostree to start doing a shared lock during
commit by default, but this broke because pungi is starting a process
doing a commit for each architecture, and then trying to regenerate
the summary after each one.
This patch is deleting a big comment with a rationale for why
summary regeneration should be exclusive. Point by point:
> This makes sure the commits and deltas don't get
> deleted while generating the summary.
But prune operations require an exclusive lock, which means that
data still can't be deleted when the summary grabs a shared lock.
> It also means we can be sure refs
> won't be created/updated/deleted during the operation, without having to
> add exclusive locks to those operations which would prevent concurrent
> commits from working.
First: The status quo *has* prevented concurrent commits from working!
There is no real locking solution to this problem. What we really
need to do here is regenerate the summary after each commit *or*
when the caller decides to do it and e.g. include deltas at the same
time.
It's OK if multiple threads race to regenerate the summary;
last-one-wins behavior here is totally fine.
Colin Walters
