The runtime dependency on shadow-utils-subid should have already been
part of commit 95d6ea8689 to ensure that Toolbx >= 0.0.99.4 would
be able to dlopen(3) the library. It only worked in practice because
the podman RPM also required it.
There's no need to do a build just for this.
With Toolbx 0.0.99.6, 'rpminspect --tests=elf', run by the Fedora CI,
fails with:
/usr/bin/toolbox lost full GNU_RELRO security protection
This is because from version 0.0.99.6 onwards, toolbox(1) is only built
with the '-z relro' linker flag, but not '-z now' [1].
Fallout from 2c1d60d335
[1] Upstream commit 83f28c52e47c2d44
83f28c52e4https://github.com/containers/toolbox/pull/1548
Start using the golang-ipath(...) virtual Provides for BuildRequires
because they use the top-level import paths and are closer to what is
listed in the upstream go.mod. The golang(...) virtual Provides mention
each individual Go package within a Go module, and bigger modules can
have several packages in them. It is noisy and tedious to keep up with
the list of packages that are currently in use, by looking at all the Go
source files, and then to list them as BuildRequires.
Update the compiler and linker flags for Fedora by incorporating some of
the changes to the distribution's defaults up to Fedora 39, which is the
oldest supported Fedora. Switch to using the GO_BUILDTAGS and
GO_LDFLAGS environment variables, because their unprefixed counterparts
have been deprecated [1], and start annotating the toolbox(1) binary
with an ELF note that identifies the RPM for which it was built [2].
However, the change to use the RPM's %{name}, %{version}, %{release} and
the SOURCE_DATE_EPOCH environment variable [3], instead of /dev/urandom,
to generate the build ID annotation for the toolbox(1) binary [4] was
left out. It will need more work to propagate the RPM's %{name},
%{version} and %{release} to Meson.
Stop carrying the downstream patch for the compiler and linker flags for
PPC64. The architecture was already discontinued from Fedora 29 [5],
even before the patch was added [6]. It was added purely for the sake
of completeness, and in the last four years since it was introduced, it
hasn't been tested or used. At this point it's becoming too much of a
maintenance burden, and removing it silences the %ifarch-applied-patch
warning from rpmlint.
Fill in some of the missing Requires for the toolbox-tests sub-package.
[1] go-rpm-macros commit bc7e5cc55c4709e8
https://pagure.io/go-rpm-macros/c/bc7e5cc55c4709e8
[2] Fedora redhat-rpm-config commit 57edf0cad7b089ed
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/57edf0cad7b089edhttps://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
[3] https://reproducible-builds.org/docs/source-date-epoch/
[4] go-rpm-macros commit 1980932bf3a21890
https://pagure.io/go-rpm-macros/c/1980932bf3a21890https://fedoraproject.org/wiki/Changes/ReproduciblePackageBuilds
[5] https://fedoraproject.org/wiki/Changes/DiscontinuePPC64
[6] Commit ba60453d21https://src.fedoraproject.org/rpms/toolbox/pull-request/22
Toolbx's system tests download several images when setting up the test
suite, and cache them for later use by the tests [1]. This saves time
and avoids hitting rate limits imposed by OCI registries by not
downloading the same images repeatedly for several tests, but at the
cost of increased use of storage space to cache the images.
The images are cached under BATS_TMPDIR. It defaults to the TMPDIR
environment variable, and if that's not set then to /tmp [2]. Normally,
TMPDIR isn't set, and the images end up getting cached under /tmp. Now,
/tmp is typically on tmpfs backed by RAM or swap, which means that it
should be used for smaller size-bounded files only, and /var/tmp should
be used for everything else [3].
The images are big enough that a collection of them can't be described
as smaller and size-bounded, and it led to:
1..306
# test suite: Set up
# test suite: Tear down
not ok 1 setup_suite
# (from function `setup_suite' in test file ./setup_suite.bash, line
55)
# `_pull_and_cache_distro_image fedora "$((system_version-1))" ||
false' failed
# Failed to cache image registry.fedoraproject.org/fedora-toolbox:40
to /tmp/bats-run-IPz4Cn/image-cache/fedora-toolbox-40
# time="2024-02-19T11:41:43Z" level=fatal msg="copying system image
from manifest list: writing blob: write
/tmp/bats-run-IPz4Cn/image-cache/fedora-toolbox-40/dir-put-blob607392514:
no space left on device"
# bats warning: Executed 1 instead of expected 306 tests
So, change the default location of the BATS_TMPDIR environment variable
to /var/tmp by setting TMPDIR.
[1] Toolbx commit 50683c9d9a78adc9
50683c9d9ahttps://github.com/containers/toolbox/pull/375
[2] https://bats-core.readthedocs.io/en/stable/writing-tests.html
[3] https://systemd.io/TEMPORARY_DIRECTORIES/https://src.fedoraproject.org/rpms/toolbox/pull-request/20
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The test.environment variable was removed from the variables defined in
tests.yml in commit 1b207227f3, but it's still used, which causes
Ansible to break:
The task includes an option with an undefined variable. The error was:
'dict object' has no attribute 'environment'. 'dict object' has no
attribute 'environment'
https://src.fedoraproject.org/rpms/toolbox/pull-request/19
The stack-prot test [1] currently fails with:
Hardened: /usr/bin/toolbox: FAIL: stack-prot test because stack
protection not enabled (lto:_cgo_6f668e16310a_Cfunc_mygetgrnam_r)
According to the documentation [1], the test is supposed to pass if the
C compiler is GCC and it was used with the -fstack-protector-strong
option. That's definitely the case, since Fedora uses GCC by default,
and its default build flags (including %optflags) include
-fstack-protector-strong.
There's also no function called mygetgrnam() in neither Toolbx nor its
chain of dependencies.
Therefore, temporarily disable the stack-prot test to prevent the Fedora
CI from failing.
[1] https://sourceware.org/annobin/annobin.html/Test-stack-prot.html
In recent times, 'rpminspect --tests=annocheck', run by the Fedora CI,
has been failing because of the intentional DT_RPATH or DT_RUNPATH value
of /run/host%{_libdir} that's present in %{_bindir}/toolbox [1]. It's
not clear if they started failing again only recently due to changes in
rpminspect(1), or if the previous attempt at silencing it was broken and
never actually worked [2].
[1] Upstream commit 6063eb27b9893994
6063eb27b9https://github.com/containers/toolbox/issues/821
[2] Commit 12fabacd03https://github.com/rpminspect/rpminspect/issues/1296
... because subscription-manager requires python3-dnf, which contains
%{_bindir}/dnf-3 and %{_bindir}/dnf4 [1]. This is a problem on Fedora
Silverblue, because they shouldn't be present on OSTree based variants
of Fedora.
This reverts parts of commit 6682165143.
[1] https://github.com/fedora-silverblue/issue-tracker/issues/521
Start using Toolbx as the name of the project, instead of Toolbox; and
recommend subscription-manager, as requested by the Fedora Workstation
Working Group [1], to make it easier to have gratis, self-supported Red Hat
Enterprise Linux containers on Fedora.
[1] https://pagure.io/fedora-workstation/issue/391
'%if 0%{?rhel} <= 9' is the wrong way to express 'if RHEL <= 9'. On
Fedora, %rhel won't be defined. So, %{?rhel} will expand to nothing,
and leave only a 0 on the left hand side, making the condition TRUE on
Fedora.
Note, that conditions like '%if 0%{?rhel}', and other relational
operators like ==, > and >= work as expected. The problem is only with
< and <=.
Fallout from 1d18729e66 and
d437e83604
Complete support for RHEL Toolbx images based on the Red Hat Universal
Base Images (or UBI) was only recently added to Toolbx [1], in version
0.0.99.4. Before that, Toolbx would only pick the image for RHEL 8,
and even before that, it would pick the base 'ubi8' image, which isn't
designed for interactive command line use.
Due to this, RHEL >= 8.5 shipped a custom configuration file
in /etc/containers/toolbox.conf to specify the image.
However, that's not necessary anymore. RHEL 10 is going to be a fresh
new operating system, and it will be better if we don't ship any custom
configuration that's not needed, because it will ensure consistency with
non-RHEL operating systems, including Fedora.
[1] Upstream commit 0a29b374e649437
0a29b374e6https://github.com/containers/toolbox/issues/1065
Since the RHEL conditional was only targeting RHEL 9, it wasn't clear
whether it needed updating for RHEL 10. So, it's better to say that
%golang_arches are for RHEL 9 and older, and %golang_arches_future are
for Fedora and RHEL 10 onwards.
This doesn't change any behaviour of the built artifacts, because the
build is only shared with RHEL 9 onwards. Hence, a conditional checking
for RHEL 9 is the same as one checking for RHEL 9 and older.
There's no need to do a build just for this.
Some limited compatibility with github.com/coreos/toolbox was added to
RHEL 8.5 when the implementation of the toolbox RPM was changed from
github.com/coreos/toolbox to github.com/containers/toolbox. This was
carried forward to RHEL 9 to give everybody some extra time to adjust.
This compatibility involved setting the HOST environment variable inside
the Toolbx containers for 'sos report' to work, and replicating the
command line interface from github.com/coreos/toolbox.
The problem with setting the HOST environment variable in Toolbx
containers is that it's a very generic name without any namespacing.
Not every user is going to use 'sos report', and it can easily conflict
with a variable of the same name being used for a different purpose.
This is similar to the NAME and VERSION environment variables that used
to be set inside Toolbx containers due to outdated or wrong information
in Fedora's container guidelines [1]. They were a constant source of
complaints and were recently fixed [2]. The same logic applies to HOST.
Instead of expecting the Toolbx container to have the HOST environment
variable, sos(1) should be taught how to work inside a Toolbx container
without requiring any extra configuration [3].
The problem with replicating the command line interface from
github.com/coreos/toolbox is that it's difficult to document it, because
it's so different from the native interface that users on non-RHEL
operating systems, including Fedora, have come to expect. So, it's an
undocumented easter egg that receives very limited, if any, testing.
RHEL 8.5 was released on the 9th of November in 2021, which was almost
two years ago. RHEL 10 is going to be a fresh new operating system.
It's time to ship a version of sos(1) in RHEL that works without any
extra configuration inside Toolbx containers, and to inform RHEL users
to adapt to the native command line interface.
[1] https://docs.fedoraproject.org/en-US/containers/guidelines/creation/
[2] Upstream commit 9506173f88dc26bf
9506173f88https://github.com/containers/toolbox/issues/188
[3] https://github.com/sosreport/sos/pull/3370
This pulls in an extra patch [1] that's necessary to fix the build on
only CentOS Stream 9, not Fedora. While not needed, it also doesn't
hurt Fedora and has the added benefit of keeping the build unified with
RHEL.
There's no need to do a build just for this.
[1] Upstream commit f555029304415a06
f555029304https://github.com/containers/toolbox/issues/1246
This is actually needed for Fedoras 36 and 37, but, at least currently,
not necessary for Fedoras 38 and 39.
There's no need to do a build just for this.
https://github.com/containers/podman/issues/17657
