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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We lost this during the transition from PAPR to CoreOS CI. We don't have
a lot of new tests there since new unit tests tend to be in Rust, though
we should still run what we do have.
Repurpose the `rust` branch to more generically run all unit tests
and not just the Rust ones. It still also checks that compilation
against the MSRV works fine.
The next/previous functions were renamed, and the journal is no longer
seeked to the head on open, so we have to do it manually. We did that
already in most places, except one.
For more information, see:
https://github.com/jmesmon/rust-systemd/pull/121
The design of https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb
is problematic for us for multiple reasons. The first big reason
is that rpm-ostree is designed for "cross" builds and e.g. today
we use a Fedora-derived container to build RHEL CoreOS images.
However the default database lives inside the `rpm` package which
means that if we e.g. upgrade the coreos-assembler container to F33
it will suddenly try to use sqlite for RHCOS which is obviously broken.
Related to this, rebases from f32 to f33 w/layered packages
are broken: https://bugzilla.redhat.com/show_bug.cgi?id=1876194#c3
With this we can configure things to continue to use bdb for f33
for ostree-based systems, so that by enforcing an upgrade order
f32 → f33 [bdb] → f34 [sqlite] ... the intermediate f33 w/bdb
still understands sqlite and hence rebases will work.
The main goal here is simply to start the ball rolling
in having rpm-ostree use the ostree-rs crate, so we can
use it for other code in the future. We also bump the
glib crate to a new major, but no code changes were
required for that.
I spent a bit of time looking through our C code for
an example to oxidize, but almost all of our C code using
libostree also has calls back into other nontrivial rpm-ostree
C code. To make a lot more oxidation progress I think we need
to invent an internal `librpmostree-sys` crate so we can have
Rust -> C calls.
I found this bit of treefile code computing the checksum that
we can oxidize - and as soon as we have more libdnf bindings
we can move all of the checksumming into Rust too.
Otherwise we could fail to check out the policy on a host
where the SELinux module is loaded but inactive, which would
deny calling `setxattr(security.selinux)`.
And in general we don't want to do chown/xattr at all here.
In the scenario where ostree is in the fcos overrides but *not*
bodhi, *and* a new test requires it, our CI will fail.
We aren't hard requiring the latest ostree right now.
Not clear it ever worked, it's definitely broken now and no
one can be using it. If we want this functionality we can revisit
adding it later (preferably in Rust with tests).
Motivated by trying to oxidize a bit of this code and then
discovering it didn't work.
For the Fedora CoreOS extensions work, when layering packages, we need
to be able to tell libsolv to pick the packages which will go with the
base packages. IOW, it needs to know that the base packages shouldn't be
uninstalled.
While investigating
https://github.com/coreos/fedora-coreos-tracker/issues/525, I realized
that libsolv does have a flag which allows us to express this:
`SOLVER_LOCK`.
This then allows libsolv to choose the right package for us (if found).
And in the case where it can't find a matching package, libsolv itself
will print exactly what the conflict is, which is more informative than
the "forbidden replacements" error we currently print out.
Update submodule: libdnf
This is the case in RHCOS, and it's confusing to see:
`Enabled rpm-md repositories:`
since one might think the text on the following lines are
the repositories.
We want to test upgrades that actually change files as a general
rule; in some cases we want to test "large" upgrades to validate
performance.
This code generates a "synthetic" upgrade that adds an ELF note
to a percentage of ELF files (randomly selected). By doing
it this way we are only actually testing one version of the code.
Migrated from https://github.com/coreos/coreos-assembler/pull/1635/
using the Rust code from https://github.com/ostreedev/ostree/pull/2127
