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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The CoreOS CI shared lib sets `HOME` to the workspace:
a81bfab789
and there's no easy way for it to detect when `HOME` is correctly set:
8574f04d96853d5fdef3
For now, just work around this until we have a cleaner solution. (Though
it makes sense overall to uses `$HOME` anyway instead of hardcoding
`/root`).
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
Now that cosa and FCOS have moved to f32, a bunch of tests are breaking.
Let's make them more resistant to releasever changes.
While we're here though, bump the container image we use on the target
host to f32, and update the systemd example output.
One OpenShift user saw this from rpm-ostree:
```
client(id:cli dbus:1.583 unit:machine-config-daemon-host.service uid:0) added; new total=1
Initiated txn UpdateDeployment for client(id:cli dbus:1.583 unit:machine-config-daemon-host.service uid:0): /org/projectatomic/rpmostree1/rhcos
Txn UpdateDeployment on /org/projectatomic/rpmostree1/rhcos failed: File header size 4294967295 exceeds size 0
```
which isn't very helpful. Let's add some error
prefixing here just to clarify this is pulling from
the repo.
xref https://github.com/ostreedev/ostree/pull/2118
I have no idea why I came up with the previous code instead
of just expanding `%_isa`. The old code blew up for me
trying to use rojig w/silverblue because of the `abi` in:
```
$ rpm -q --provides gawk | grep \(
gawk(abi) = 3.0
gawk(x86-64) = 5.0.1-5.fc31
$
```
We can definitely assume that we have the same value of `_isa`
at rojig build time as for the target.
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.
The `rust-toolset` package does not exist in Fedora, so we cannot
use it for BuildRequires. Change the conditional to exclude ELN
from the %rhel conditional.
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
Start adding some pain if `--unified-core` isn't provided
to help flush out anyone relying on it. (And I think today
pungi is not passing it, so e.g. Fedora IoT/Silverblue are impacted)
Prep for merging https://github.com/coreos/rpm-ostree/pull/1793
Co-authored-by: Jonathan Lebon <jonathan@jlebon.com>
This was apparently removed in: 2263bb35f6
It's done nothing for the last 5 years, I think it's safe to remove.
I was just looking at this code when thinking about extensions.
The lists of pros and cons for each approach in the background section
of the manual use markdown formatting that is rendered as nested
lists. Separate the lists of benefits and drawbacks so that readers of
https://rpm-ostree.readthedocs.io/en/latest/manual/background/ and the
rendered markdown on github can understand which items are pros and
which are cons.
Signed-off-by: Doug Hellmann <dhellmann@redhat.com>
Both libostree and the upgrader do timestamp checks, and the error
message is exactly the same. So it's hard to tell which path exactly
failed.
Add some error-prefixing to make debugging easier.
Going to update rpm-ostree for RHEL 8.3, we did a huge bump
in libdnf which now defaults to enabling zchunk in its build
system. We added the infrastructure before to detect things,
so propagate that to libdnf.
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.
