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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Remove installonlypkg use and check if other kernel types are provided
Remove unneeded g_printerr statement
Update src/libpriv/rpmostree-core.c
Based on feedback
Co-authored-by: Jonathan Lebon <jonathan@jlebon.com>
Same motivation as
7392259332
I think we should encourage removing the writable bits from
executables. This has happened to me:
https://thomask.sdf.org/blog/2019/11/09/take-care-editing-bash-scripts.html
And not having the writable bit may help prevent hardlink
corruption with OSTree in some cases.
We can't do this by default, but add a convenient treefile option
for it.
This starts out by just doing this for RPMs, but I'll add
a secondary pass which does it during postprocessing soon too.
When g-ir-scanner runs, it uses a stub binary to help introspect the
target rpm-ostree library. That binary needs to link to the library, and
of course, transitively, to our bundled libdnf. Since we run the scanner
uninstalled, we use `LD_LIBRARY_PATH` to point the stub at the libdnf
from the build directory.
When we compile rpm-ostree, we use `-rpath` to point it at our libdnf,
which emits a `DT_RPATH` attribute. However, during dynamic linking at
runtime, it turns out that `LD_LIBRARY_PATH` has *lower* precedence than
`DT_RPATH`. This means that if there is already a libdnf at
`/usr/lib64/rpm-ostree`, it takes precedence.
This subtlety is mostly fine to ignore usually, because the stub doesn't
actually run any rpm-ostree business logic, so it doesn't really matter
that it runs against the "technically wrong" `libdnf.so.2`.
Where it becomes obvious something is off however is if we've just
built a new libdnf, and we have new code which references symbols from
the new libdnf that aren't in the stale libdnf at `$libdir/rpm-ostree`.
And this is exactly what was happening in CI (though it's of course
possible to reproduce this locally as well): we were using a new symbol,
`hy_goal_favor`, and building inside the cosa buildroot image, which
already has rpm-ostree installed, and so `ld.so` chose the bundled
libdnf of the installed rpm-ostree when loading the `g-ir-scanner` stub.
Thus why it failed with:
```
./tmp-introspectzh0n2cga/.libs/lt-RpmOstree-1.0: symbol lookup error: .libs/librpmostree-1.so.1: undefined symbol: hy_goal_favor
```
And of course, the root cause here has nothing to do with the stub in
itself. It's actually trivially easy to see the behaviour difference wrt
`LD_LIBRARY_PATH` on installed binaries. Using a shared object
from `python3-libdnf` which links to libdnf without using rpath, we can
see that `LD_LIBRARY_PATH` has an effect:
```
$ ldd /usr/lib64/python3.7/site-packages/libdnf/_transaction.so | grep libdnf
libdnf.so.2 => /lib64/libdnf.so.2 (0x00007fdde789e000)
$ LD_LIBRARY_PATH=./libdnf-build/libdnf ldd /usr/lib64/python3.7/site-packages/libdnf/_transaction.so | grep libdnf
libdnf.so.2 => ./libdnf-build/libdnf/libdnf.so.2 (0x00007fa615048000)
```
Whereas with rpm-ostree:
```
$ ldd /usr/bin/rpm-ostree | grep libdnf
libdnf.so.2 => /usr/lib64/rpm-ostree/libdnf.so.2 (0x00007f7da5271000)
$ LD_LIBRARY_PATH=./libdnf-build/libdnf ldd /usr/bin/rpm-ostree | grep libdnf
libdnf.so.2 => /usr/lib64/rpm-ostree/libdnf.so.2 (0x00007fc905dbd000)
```
And going further down the rabbit hole, `DT_RPATH` is in fact considered
deprecated for this reason; it makes it harder to run with uninstalled
libraries or whatever reason one has to want to override a library (one
can still use `LD_PRELOAD`, though the semantics are different, and it's
less commonly used than `LD_LIBRARY_PATH`). Instead, we should use
`DT_RUNPATH`, which does have lower precedence than `LD_LIBRARY_PATH`,
matching the usual behaviour.
To make the linker emit `DT_RUNPATH` attributes, we have to use the
`--enable-new-dtags` flag. This also then fixes the g-ir-scanner issue
described above.
The main goal here is to get `assert_jq()` usable in
kola tests.
This was forked from ostree long ago but we aren't
using most of it. I want to try to move this into kola where
we're just using `tests/common` but this code references
`tests/gpghome` which we weren't using.
Only a few things here reference `SRCDIR` - change those
to fail for now if it's not set, since we're not running
those tests in kola yet. I will eventually try to
clean that up later.
Jenkins does its own `git merge` when testing PRs. Doing a naive
`git diff ${merge_commit}^..${merge_commit}` won't work right because
it might perform a diff across multiple commits.
What we want to do here is to just skip trivial merge commits or
otherwise error out on them if they're non-trivial (since it likely
means that one did conflict resolution manually instead of rebasing,
which we should encourage).
The `origin/master..$HEAD` range will correctly still contain all the
parents of any merge commit which is not yet in `origin/master`.
We are have been pretty inconsistent about this; I think while it's
true the project is called "OSTree", "RPM-OSTree" is just annoying
to type and looks weird. `rpm-ostree` requires much less
"shift key gymnastics".
Also, the "proper name" style like RPM/OSTree is best when
something can be viewed more "abstractly" - there are multiple
RPM implementations (historically) and OSTree also is a *concept*
in addition to an implementation.
rpm-ostree though is much more of a "concrete" thing so it
makes more sense to use it as a "project name".
Right now, rebuilding ostree into the continuous tag is manual, so we've
only been doing it when necessary to fast-track something e.g. for
rpm-ostree or cosa (see [1] for the long-term goal).
Which means when finding an ostree to use to override in our CI-built
FCOS, we should just let dnf find whatever the latest version is, even
if it's just from the regular Fedora repos.
[1] https://github.com/packit-service/packit/issues/264
Even though C happily accepts 0 for NULL, this is ambiguous with our
coding style. E.g. here we're actually returning a pointer, not a
gboolean. So let's be less misleading.
For Fedora CoreOS production streams, we want to *only* source from
lockfile repos. But right now, rpm-ostree doesn't allow not specifying
`repos`. Relax this restriction and just check that at least one of the
two was provided.
Pre-FCOS we made an effort for automatic updates but nowadays
with Fedora CoreOS we generally expect people to be using zincati.
Until we fix the "agent registration" problem:
https://github.com/coreos/rpm-ostree/issues/1747
Let's not confuse people by printing `AutomaticUpdates: disabled`.
Only print if it's set to a value in non-verbose mode.
In Fedora CoreOS, we have a "coreos-pool" repo from which all packages
in lockfiles are tagged for reproducible builds. This repo is shared
across all streams, including those on f31 and f32.
Thus, it makes no sense for composes to ever pick packages unconstrained
from the pool without being guided by a lockfile. Otherwise, one can
easily end up with e.g. f32 packages in an f31 compose.
Add a new `lockfile-repos` for this which is only used for fetching
lockfile packages and nothing else. For example, this will allow
`cosa fetch --update-lockfile` to Just Work as expected by only fetching
new packages from regular yum repos.
Today, lockfiles only restrict the NEVRA of specifc package names from
which libsolv can pick. But nothing stops libsolv from picking entirely
different packages which still satisfy the manifest requests.
This was mostly a theoretical issue in Fedora CoreOS, but became reality
with the addition of Fedora 32 packages in the pool. libsolv would
happily try to pick e.g. `libcurl-minimal` from f32 instead of sticking
with the f31 `libcurl` from the lockfiles:
https://github.com/coreos/fedora-coreos-streams/issues/75#issuecomment-610734584
(But more generally, see
https://github.com/coreos/fedora-coreos-tracker/issues/454).
Let's add a `--ex-lockfile-strict` mode, which in CI and production
pipeline build contexts will require that (1) *only* locked packages are
considered by libsolv, and (2) *all* locked packages were marked for
install.
One important thing to note here is that we don't short-circuit libsolv
and manually `hy_goal_install` lockfile packages. We want to make sure
the treefile is still canonical. Strict mode simply ensures that the
result agrees with the lockfile.
That said, even in developer contexts, we don't want the
`libcurl-minimal` issue that happened to be triggered. But we still want
to allow flexibility in adding and removing packages to make hacking
easier. I have some follow-up patches which will enable this.
We need to be friendlier to people who are transitioning from
"traditional" yum managed systems. This patchset starts to lay
out the groundwork for supporting "intercepting" binaries that
are in the tree.
For backwards compatibility, this feature is disabled by default,
to enable it, one can add `cliwrap: true` to the manifest.
To start with for example, we wrap `/usr/bin/rpm` and cause it
to drop privileges. This way it can't corrupt anything; we're
not just relying on the read-only bind mount. For example nothing
will accidentally get written to `/var/lib/rpm`.
Now a tricky thing with this one is we *do* want it to write if
we're in an unlocked state.
There are various other examples of binaries we want to intercept,
among them:
- `grubby` -> `rpm-ostree kargs`
- `dracut` -> `rpm-ostree initramfs`
- `yum` -> well...we'll talk about that later
The garbage collection issue should be fixed now, and it's just nicer on
developers' cache to stay on the same commit. And again, it's a nice
sanity-check to know that we're always able to compose an older tree.
That said, we probably should still bump this from time to time.
While we're here, add some comments for making it easier to match `popd`
calls with the original `pushd`.
Start the ball rolling on converting some of our tests into
the coreos-assembler/kola framework:
d940420b78/mantle/kola/README-kola-ext.md
The nondestructive ones are easy.
We haven't been consistent about doing this; I personally
think rustfmt is a big aggressive with the line wrapping
but eh, consistency is more important.
And heh so I tried to `git push --set-upstream cgwalters` and
that failed because there was an already extant `rustfmt`
branch from a while ago...looking at that code it got lost
in the CI refactoring - we're not running `build-check.sh`
at the moment.
Move the rustfmt bits into `codestyle.sh` which is closer
to where it should be anyways.
This is just a cleaner arrangement to make the separation more explicit.
It also matches what most other wrapper crates do.
One advantage of this is that we can tell cbindgen directly that we
don't want it to ever export symbols from `libdnf-sys`.
Related discussions in:
https://github.com/coreos/rpm-ostree/pull/2047
When we ran rustfmt, it converted our bare `extern` blocks to
`extern "C"` which has a different meaning apparently.
This caused cbindgen to try to interpret the structs, and it barfed
on the newtype void wrappers.
Looking at libgit2-rs, it seems to use these "uninstantiable types"
instead.
Prep for using `rustfmt`.
