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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
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
