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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This is a potential path to fix
https://github.com/coreos/rpm-ostree/issues/2391
Basically our shared library and executable duplicate too much
code (particularly Rust). Since most of the shlib APIs aren't
performance sensitive, let's have them fork off the binary
via a hidden CLI entrypoint and parse the output.
We got annobin (hardening) warnings in a downstream RPM analysis,
I think this will help ensure that the Rust code is built with
things like `-znow` etc.
We need this for https://cxx.rs
While we're here:
- Add some more comments/links
- Since the Rust bits are now at the toplevel, we can explicitly
invoke `cargo`
- And since we can do that, use the `+` syntax to specify the
toolchain explicitly
We have logging when a "client" connects to us over the main bus,
but none when a "process" connects to the transaction-private
DBus socket.
It's going to help us debug problems to log the latter. In
the future we can try to correlate them, but for now simple
logging in a similar way should help.
See 82679ce834
I've seen at least one user report a bunch of failing
services on CoreOS that might be due to `/boot` not mounting.
Let's make it explicitly clear this is required.
The error would then be systemd saying a dependency failed, rather
than ostree confusingly saying it can't invoke `readlinkat()`.
Silence is a bit too eerie for this. But what we really
need to do is switch to using cxx-rs so we can pass down the
`Transaction` object into Rust so that we can emit messages
from that side (including things like package diffs).
(Keeping the old name for muscle memory compatibility for now)
I think `apply-live` is a clearer name; it's more imperative
and it may not be obvious (particularly to non-native English speakers)
to parse "livefs" as "live fs".
First, we now need the `vendor/` directory at the toplevel because
that's where `Cargo.toml` is.
Now this triggers another bug introduced in the build system
with how we're handling the `rpmostree-rust.h` header.
We ended up vendoring a pre-generated one in the tarball
mainly because RHEL doesn't include cbindgen.
Now probably in the future I'd like to fix that.
But let's clean this up - the tarball generation process copies
the file into `rpmostree-rust-prebuilt.h`, and build machinery
detects that and entirely skips looking for or trying to build
our internal cbindgen.
Prep for reworking `core.rs` to use cxx-rs
(Notable in this is the dropping of `goto out` by writing
a small struct with a destructor to handle the cleanup `unlinkat()` for us)
Fixes: e9011530e5
Fedora Silverblue doesn't specify any `initramfs-args` in the
treefile. The above commit then caused us to omit `--no-hostonly`
which completely fails today because we sandbox dracut off
from seeing the real hardware and the host filesystems, so
it omits a lot of modules.
It wasn't noticed because Fedora CoreOS does always specify
arguments in the treefile.
Closes: https://github.com/coreos/rpm-ostree/issues/2343
Yet more print format issues uncovered by users running on armv7.
Also add a space between the specifier and the "ms" because it makes one
doubtful whether printf interprets this correctly.
I think this will resolve
https://bugzilla.redhat.com/show_bug.cgi?id=1906184.
I think we should have done this as soon as it was clear that
Rust was sticking and not just an optional thing.
Reasons to make this change now:
- More clear that Rust is going to be the majority of code in the future
- `cargo build` and `cargo test` in a fresh git clone Just Work
- Paves the way for using `cargo` to build C/C++ instead of Automake
On traditional rpm systems this can hang because the outer
process may have an rpmdb lock, and the inner one wants
to acquire a lock. Here we're sandboxing the `%post` script
and it's targeting a separate temporary filesystem compared to
the booted one (so there's no double locking). Plus we don't
create the rpmdb in the target until all scripts have run.
Inspired by https://twitter.com/_msw_/status/1335981558717587473
I've been meaning to hook up `ex history` to a pager a-la-journalctl,
though it's not high-priority, and it'd be nice to do it in Rust instead
(I think this command would be a good candidate for more oxidation if we
move the CLI entrypoint to Rust.)
For now at least, let's not spam the full history by default. Instead,
limit it to 3, and add `--limit` and `--all` options to tweak that if
wanted (I thought about making `--limit -1` just mean all entries,
though I think I'd still want an explicit `--all` anyway.)
