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.
Followup to https://github.com/ostreedev/ostree/pull/2463
One thing I noticed here is we lost usage of `build-check.sh`
which also invokes `clang`, which doesn't speak `-fanalyzer`
and would be broken by this if we try to enable `build-check.sh`
again. But that can come later.
In general, we're probably going to need to change most of our
`g_return_if_fail` to `g_assert`. The analyzer flags that
the function can return `NULL`, but the caller isn't prepared for
this.
In practice, let's abort.
In general, we're probably going to need to change most of our
`g_return_if_fail` to `g_assert`. The analyzer flags that
the function can return `NULL`, but the caller isn't prepared for
this.
In practice, let's abort.
In general, we're probably going to need to change most of our
`g_return_if_fail` to `g_assert`. The analyzer flags that
the function can return `NULL`, but the caller isn't prepared for
this.
In practice, let's abort.
In general, we're probably going to need to change most of our
`g_return_if_fail` to `g_assert`. The analyzer flags that
the function can return `NULL`, but the caller isn't prepared for
this.
In practice, let's abort.
https://bugzilla.redhat.com/show_bug.cgi?id=1945274 is an issue where a privileged
kubernetes daemonset is writing a socket into `/etc`. This makes ostree upgrades barf.
Now, they should clearly move it to `/run`. However, one option is for us to
just ignore it instead of erroring out. Some brief investigation shows that
e.g. `git add somesocket` is a silent no-op, which is an argument in favor of ignoring it.
Closes: https://github.com/ostreedev/ostree/issues/2446
This is nicer than having the caller parse the commit
object, or indirect via the `OstreeRepoFile*` object of the root.
Will be used in ostree-rs-ext around tar parsing.
This is part of `OstreeCommitModifier`, but I'm not using
that in some of the ostree-ext Rust code.
It just makes more sense as a direct policy API, where it should
have been in the first place. There's already support for
setting a policy object on a commit modifier, so that's all the
old API needs to do now.
There's a general Unix philosophy that "silence is golden".
However, when one is explicitly invoking an error check it's nice
to see explicit success.
We already print various statistics, so ending with a happy
note has no extra cost.
The logic for `--selinux-policy` ended up in the `--tree=dir`
path, but there's no reason for that. Fix the imported
labeling with `--tree=tar`. Prep for use with containers.
We had this bug because the previous logic was trying to avoid
duplicating the code for generic `--selinux-policy` and
the case of `--selinux-policy-from-base --tree=dir`.
It's a bit more code, but it's cleaner if we dis-entangle them.
Having to touch a global test counter when adding tests is
a recipe for conflicts between PRs.
The TAP protocol allows *ending* with the expected number of
tests, so the best way to do this is to have an explicit
API like our `tap_ok` which bumps a counter, then end with `tap_end`.
I ported one test as a demo.
This will be helpful for the "ostree native container" work in
https://github.com/ostreedev/ostree-rs-ext/
Basically in order to reuse GPG/signapi verification, we need
to support adding a remote, even though it can't be used via
`ostree pull`. (At least, not until we merge ostree-rs-ext into ostree, but
even then I think the principle stands)
Colin Walters