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
