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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Rust has a nice crate for doing perfect hashing. Move that
code into Rust and drop the dependency on `gperf`. This also
helps move away from Autotools.
The way gresources work using a constructor function started
failing when I was refactoring the build system, and I couldn't
figure it out. It's just easier to use Rust for this which
has nice toolchain-integrated functionality for this.
This is much better than bindgen because it's fully safe. It's
much more ergonomic too:
- Invoke Rust methods-on-structs just like C++ methods-on-structs
- Rust `Result<>` is translated automatically to exceptions
See https://cxx.rs/context.html for more.
There won't be any support for writing to the bdb backend in f34, so
e.g. pkglayering won't work (and obviously even composes wouldn't work
once the buildroot moves to f34).
Instead of requiring the whole world to add an `rpmdb` key in their
manifests, let's just add a compile flag for it, and tweak the spec file
to use this flag on f34.
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
I was looking at the output of `ostree admin config-diff`
on a base FCOS boot. It'd be really nice to trim that down
as much as possible, so we can cleanly capture the difference
between user config and system config.
Let's use static enablement rather than presets.
This is part of investigating using https://cxx.rs/
In order to make this really work, we need to convert some of our C
code to C++ so we can include cxx.rs-generated code.
This starts by converting just two files as a starting point.
I did the minimal porting; I didn't try to actually rewrite them
to resemble modern C++, just "C in C++ mode".
The `Journal::open` API has been deprecated in favour of the new
`OpenOptions` builder pattern.
We could dedupe this a bit more, though the mock journal in the history
code makes it trickier and there's little value in mocking the builder
pattern too.
Now always based on an overlayfs:
f2773c1b55
This fixes a whole swath of problems with the previous design,
including the danger in replacing `/usr/lib/ostree-boot` which
broke booting for some people.
Further, we don't need to push a rollback deployment; the livefs
changes are always transient. So now we store livefs state
in `/run` instead of in the origin file.
Since we're doing a rewrite, it's now in Rust for much more safety.
We also always work in terms of incremental diffs between commits;
the previous huge hammer of swapping `/usr` was way too dangerous.
This effectively reverts commit: c8113bde32
We never ended up using it; instead the `rdcore` bits from
`coreos-installer` have the rootfs reprovisioning logic.
See https://github.com/coreos/rpm-ostree/pull/2206#issuecomment-721372634
The commit 7f579a55d3fb7ec1cb9f74f8ec6bc36675df2ccc broke hashing
of overlay commits; this is a super evil bug because it causes us
to silently do the wrong thing.
The cause here is the GLib bindings don't (AFAICS) support getting
a `&mut` for a GLib boxed value.
Move all of the treefile checksum code into one place - this is
far saner. The reason I didn't do this before is that it
will cause a spurious rebuild when one updates rpm-ostree, but...eh.
Particularly in places like the lockfile code where we were iterating
on a list of packages, validating UTF-8 and `memcpy()`ing strings
from C is...well, unnecessary.
I don't think there's any actual real performance concerns right
now but let's use this as a best practice because the patterns
we establish *will* be copy+pasted or at least used as inspiration
for other places where performance might matter.
I happened to scroll past this code while doing something
else and noticed what we were doing here was silly - no need
to re-validate UTF-8 etc when serde can hand us a `String` directly.
Clippy reports this as an error; I think in practice Linux
doesn't return short writes for regular files, but it's still
a good idea to do the right thing here.
Let's just use the GLib translation bits rather than rolling our own;
this applies primarily to `ffi_new_string()`.
However, I think in most cases performance here doesn't
matter enough to have an even more special case that avoids duplicating
the string. Let's remove the `ffi_view_str()` optimization too
in favor of consistently using GLib translation.
In the future perhaps we should argue for adding a `from_glib_str_unchecked()`
to the upstream GLib bindings.
This avoids us leaking all of the Rust symbols as public
into our shared library.
Came up in team chat since one person tried to copy just `/usr/bin/rpm-ostree`
from the dev container into a target and got a linker crash; but
really we want to avoid all the duplicated symbols entirely.
(And we should investigate cross-language LTO because that's the
only way to get full savings)
This starts bridging parts of the daemon syscore logic to Rust
plumbing, moving the livefs detection logic over there as a first
consumer. That was the simplest logic available for wiring, and
mostly meant as a sanity check.
It's tempting to flip the default, but let's encourage
people to adapt to the `modules` version now.
Plus infrastructure to add deprecation warnings here
will come in handy in the future.
