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
https://github.com/containers/toolbox/commit/50683c9d9a78adc9https://github.com/containers/toolbox/pull/375
[2] https://bats-core.readthedocs.io/en/stable/writing-tests.html
[3] https://systemd.io/TEMPORARY_DIRECTORIES/
Resolves: RHEL-61579
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'
Resolves: RHEL-61579
The stack-prot test [1] currently fails in Fedora and RHEL 10. On
Fedora, it says:
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 both Fedora and RHEL 10 use
GCC by default, and their 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
and RHEL CIs from failing.
[1] https://sourceware.org/annobin/annobin.html/Test-stack-prot.html
Resolves: RHEL-33522
... 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
The only known user of the toolbox-experience and toolbox-support
packages was: https://github.com/AICoE/tf-in-container
... which was declared dead in February 2022.
Hence, there's no need to keep offering these subpackages. Especially,
since the cost of keeping them updated to match the content of the
fedora-toolbox images is quite high. If someone really needs these
subpackages, then they can be reinstated.
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
https://github.com/containers/toolbox/commit/0a29b374e649437https://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
https://github.com/containers/toolbox/commit/9506173f88dc26bfhttps://github.com/containers/toolbox/issues/188
[3] https://github.com/sosreport/sos/pull/3370
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
'BuildRequires: golang >= 1.19.4' will ensure that recent CVEs like
CVE-2022-41717 remain fixed.
There's no need to do a build just for this, because the toolbox package
has either already been built with a sufficiently recent golang or will
soon be.
https://bugzilla.redhat.com/show_bug.cgi?id=2161274
The %gometa RPM macro also generates a ExclusiveArch on %golang_arches
or %golang_arches_future depending on whether the -f flag is present or
not. This was overriding the separately specified ExclusiveArch.
Fallout from 7ce081c75chttps://src.fedoraproject.org/rpms/toolbox/pull-request/12
