... 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
There's no golang on %ix86 from RHEL 9 onwards [1], and hence no podman
either [2].
Recently, with Podman 4.4.1, there are also no new podman builds for
%ix86 for Fedora 36 onwards [3]. Arguably, the podman change should
have been limited to Fedora Rawhide, but it's probably not a big problem
because there's no %ix86 install media for Fedora CoreOS, Silverblue or
Workstation.
Note that while %golang_arches on RHEL 9 doesn't include %arm, it's
included in both %golang_arches and %golang_arches_future on Fedora.
[1] go-rpm-macros commit b1500ff47ee8cdd1
https://src.fedoraproject.org/rpms/go-rpm-macros/c/b1500ff47ee8cdd1
[2] podman commit 555a5a504dd538d5
https://src.fedoraproject.org/rpms/podman/c/555a5a504dd538d5
[3] podman commit 313c3e86a81c69eb
https://src.fedoraproject.org/rpms/podman/c/313c3e86a81c69eb
There's no need to pass the --buildtype=plain option to the %meson RPM
macro, because it's one of the default options used by the macro.
There's no need to do a build just for this.
Fallout from 33bd39b0f9
Not having golang.org/x/crypto/ssh/terminal explicitly listed as a
BuildRequires isn't breaking the build at the moment. However, since
it's a direct dependency, and Toolbx is written in Go, it's good to
explicitly list it due to the statically linked nature of Go binaries.
It will make it easier to gauge the fallout from a security bug.
There's no need to do a build just for this.
Earlier Viper was being pulled in by Cobra, and hence wasn't explicitly
listed as a BuildRequires. However, Cobra 1.4.0 removed the Viper
dependency [1], so it needs to be explicitly listed.
There's no need to do a build just for this.
[1] Cobra commit 5b2b9e9f61d36ccb
https://github.com/spf13/cobra/issues/1597
The 'go-md2man' virtual Provides was briefly lost after the
golang-github-cpuguy83-go-md2man package was renamed to
golang-github-cpuguy83-md2man. The virtual Provides has since been
restored [1], and go-md2man is being used as a standalone binary tool,
not as a Go package that's imported into Toolbx's source code. Hence,
it makes sense to refer to the tool as go-md2man, and not by it's
import path.
This reverts commit 701836afca.
There's no need to do a build just for this.
[1] golang-github-cpuguy83-md2man commit c085b15e5acd8d07
https://src.fedoraproject.org/rpms/golang-github-cpuguy83-md2man/c/c085b15e5acd8d07
