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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It turns out there's a naming clash between `to_string()` here in
Rust *and* introspection is incorrectly associating the method
with `ostree::Deployment` because of the naming prefix.
Where I stalled out before is this file has `pkg-add foo`, but
now that we have the `foo` package pre-built we can move all
this stuff into `misc.sh`.
I dropped the YAML parsing of `--version` because we don't
have python. This is related to
https://github.com/coreos/coreos-assembler/issues/1645
This stubs out sufficient infrastructure for us to register
as a client and call the Moo API.
A glaring problem here is the lack of extensive `glib::Variant`
bindings; that's covered in the next gtk-rs release.
My real goal was to try porting the `rpmostree-builtin-apply-live.cxx`
code entirely to Rust, but there's more to do to expose the
transaction helper APIs we have.
Came out of discussion in https://github.com/coreos/rpm-ostree/pull/2581
around some racy code for checking for the live commit object.
The reliability of apply-live depends on the
underlying commits not being garbage collected. Our diff logic
is in terms of ostree commits, not the physical filesystem (this
allows us to make various optimizations too).
Ultimately I think we should drive some of the live-apply
logic into libostree itself; we can more easily have an atomic
state file instead of the two split refs.
(Or perhaps what we should add to ostree is like a refs.d model
where a single atomic file can refer to multiple commits)
For now though let's rework the code here to write refs. We
retain the file in `/run` as just a "stamp file" that signals
that a deployment has had `apply-live` run.
Prep for "Rust-as-main", where I want to build libdnf statically.
And this really completes the "library thinout" story because
now we avoid dragging our *private* `libdnf.so` into the caller's
address space, which can cause potential conflicts if they're
also linking the system one. (Which could easily occur with
something like gnome-software)
All we were using libdnf for (indirectly via libsolv) is comparing
version strings but librpm can already do that for us.
This effectively reverts commit: c8113bde32
We never ended up using it; instead the `rdcore` bits from
`coreos-installer` have the rootfs reprovisioning logic.
The latest crypto-policies package changed recently to dynamically set
the policy at install time so that if FIPS is enabled, the selected
backend is `FIPS`:
9b9c9f7378
This doesn't really make sense for us though since the compose server
configuration should be decoupled from the installroot. (More generally,
this also affects e.g. `yum install --installroot`).
Override the script for now so that we always select the `DEFAULT`
policy. We'll discuss with upstream to see what the right solution is
there.
This also works around the fact that rpm-ostree doesn't yet implement
Lua (#749).
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1847454
Resolves: https://github.com/coreos/fedora-coreos-tracker/issues/540
Switch to the "installed" model introduced by:
https://github.com/coreos/coreos-assembler/pull/1441
It's hard to support running tests *both* from the srcdir
and installed; in this case because we have a symlink that needs
to be followed, which kola knows how to do from the srcdir
but not when installed. Let's establish a new convention of
`tests/kolainst`. In our case we follow the symlink manually
for now.
That bit will be cleaned up when we eventually switch entirely
to kola tests.
