toolbox/toolbox.spec

442 lines
14 KiB
RPMSpec
Raw Normal View History

%global __brp_check_rpaths %{nil}
Name: toolbox
Version: 0.0.99.5
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
%global goipath github.com/containers/%{name}
%if 0%{?fedora}
%gometa -f
%endif
%if 0%{?rhel}
%if 0%{?rhel} <= 9
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
%gometa
%else
%gometa -f
%endif
%endif
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
Release: 8%{?dist}
Summary: Tool for interactive command line environments on Linux
2024-02-07 13:45:03 +00:00
License: Apache-2.0
URL: https://containertoolbx.org/
Source0: https://github.com/containers/%{name}/releases/download/%{version}/%{name}-%{version}-vendored.tar.xz
# RHEL specific
Source1: %{name}.conf
# Upstream
Patch0: toolbox-test-system-new.patch
Patch1: toolbox-test-system-Unbreak-Podman-s-downstream-Fedora-CI.patch
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
# Fedora specific
Patch100: toolbox-Make-the-build-flags-match-Fedora-s-gobuild.patch
Patch101: toolbox-Make-the-build-flags-match-Fedora-s-gobuild-for-PPC64.patch
# RHEL specific
Patch200: toolbox-Make-the-build-flags-match-RHEL-s-gobuild.patch
Patch201: toolbox-Make-the-build-flags-match-RHEL-s-gobuild-for-PPC64.patch
Patch202: toolbox-Add-migration-paths-for-coreos-toolbox-users.patch
BuildRequires: gcc
BuildRequires: go-md2man
BuildRequires: golang >= 1.22
BuildRequires: meson >= 0.58.0
BuildRequires: pkgconfig(bash-completion)
BuildRequires: shadow-utils-subid-devel
BuildRequires: systemd
BuildRequires: systemd-rpm-macros
2022-12-21 05:22:14 +00:00
%if ! 0%{?rhel}
BuildRequires: golang(github.com/HarryMichal/go-version) >= 1.0.1
BuildRequires: golang(github.com/acobaugh/osrelease) >= 0.1.0
BuildRequires: golang(github.com/briandowns/spinner) >= 1.17.0
BuildRequires: golang(github.com/docker/go-units) >= 0.5.0
BuildRequires: golang(github.com/fsnotify/fsnotify) >= 1.5.1
BuildRequires: golang(github.com/godbus/dbus) >= 5.0.6
BuildRequires: golang(github.com/sirupsen/logrus) >= 1.8.1
BuildRequires: golang(github.com/spf13/cobra) >= 1.3.0
BuildRequires: golang(github.com/spf13/viper) >= 1.10.1
BuildRequires: golang(golang.org/x/sys/unix) >= 0.1.0
BuildRequires: golang(golang.org/x/text) >= 0.3.8
BuildRequires: golang(gopkg.in/yaml.v3) >= 3.0.0
BuildRequires: pkgconfig(fish)
# for tests
# BuildRequires: codespell
# BuildRequires: golang(github.com/stretchr/testify) >= 1.7.0
# BuildRequires: ShellCheck
2022-12-21 05:22:14 +00:00
%endif
Recommends: skopeo
Requires: containers-common
Requires: podman >= 1.6.4
%if ! 0%{?rhel}
Requires: flatpak-session-helper
%endif
%description
Toolbx is a tool for Linux, which allows the use of interactive command line
environments for development and troubleshooting the host operating system,
without having to install software on the host. It is built on top of Podman
and other standard container technologies from OCI.
Toolbx environments have seamless access to the user's home directory, the
Wayland and X11 sockets, networking (including Avahi), removable devices (like
USB sticks), systemd journal, SSH agent, D-Bus, ulimits, /dev and the udev
database, etc..
%package tests
Summary: Tests for %{name}
Requires: %{name}%{?_isa} = %{version}-%{release}
Requires: coreutils
Requires: grep
# for htpasswd
Requires: httpd-tools
Requires: openssl
Requires: skopeo
%if ! 0%{?rhel}
Requires: bats >= 1.7.0
%endif
%description tests
The %{name}-tests package contains system tests for %{name}.
%prep
%setup -q
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
%patch -P0 -p1
%patch -P1 -p1
%if 0%{?fedora}
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
%ifnarch ppc64
%patch -P100 -p1
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
%else
%patch -P101 -p1
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
%endif
%endif
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
%if 0%{?rhel}
%ifnarch ppc64
%patch -P200 -p1
%else
%patch -P201 -p1
%endif
Drop github.com/coreos/toolbox compatibility from RHEL 10 onwards 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/9506173f88dc26bf https://github.com/containers/toolbox/issues/188 [3] https://github.com/sosreport/sos/pull/3370
2023-10-02 12:02:29 +00:00
%if 0%{?rhel} <= 9
%patch -P202 -p1
%endif
Drop github.com/coreos/toolbox compatibility from RHEL 10 onwards 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/9506173f88dc26bf https://github.com/containers/toolbox/issues/188 [3] https://github.com/sosreport/sos/pull/3370
2023-10-02 12:02:29 +00:00
%endif
%gomkdir -s %{_builddir}/%{extractdir}/src %{?rhel:-k}
%build
export %{gomodulesmode}
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
export GOPATH=%{gobuilddir}:%{gopath}
export CGO_CFLAGS="%{optflags} -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64"
%meson \
%if 0%{?rhel}
-Dfish_completions_dir=%{_datadir}/fish/vendor_completions.d \
Drop github.com/coreos/toolbox compatibility from RHEL 10 onwards 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/9506173f88dc26bf https://github.com/containers/toolbox/issues/188 [3] https://github.com/sosreport/sos/pull/3370
2023-10-02 12:02:29 +00:00
%if 0%{?rhel} <= 9
-Dmigration_path_for_coreos_toolbox=true \
Drop github.com/coreos/toolbox compatibility from RHEL 10 onwards 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/9506173f88dc26bf https://github.com/containers/toolbox/issues/188 [3] https://github.com/sosreport/sos/pull/3370
2023-10-02 12:02:29 +00:00
%endif
%endif
-Dprofile_dir=%{_sysconfdir}/profile.d \
-Dtmpfiles_dir=%{_tmpfilesdir} \
-Dzsh_completions_dir=%{_datadir}/zsh/site-functions
%meson_build
# %%check
# %%meson_test
%install
%meson_install
%if 0%{?rhel}
%if 0%{?rhel} <= 9
install -m0644 %{SOURCE1} %{buildroot}%{_sysconfdir}/containers/%{name}.conf
%endif
%endif
%files
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
%doc CODE-OF-CONDUCT.md NEWS README.md SECURITY.md
2022-12-21 05:22:14 +00:00
%license COPYING %{?rhel:src/vendor/modules.txt}
%{_bindir}/%{name}
2019-04-30 10:52:59 +00:00
%{_datadir}/bash-completion
%{_datadir}/fish
%{_datadir}/zsh
2019-03-14 13:25:59 +00:00
%{_mandir}/man1/%{name}.1*
%{_mandir}/man1/%{name}-*.1*
%{_mandir}/man5/%{name}.conf.5*
2021-07-28 16:54:13 +00:00
%config(noreplace) %{_sysconfdir}/containers/%{name}.conf
%{_sysconfdir}/profile.d/%{name}.sh
2019-03-14 13:25:59 +00:00
%{_tmpfilesdir}/%{name}.conf
%files tests
%{_datadir}/%{name}
%changelog
* Tue Feb 27 2024 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.5-8
- Unbreak Podman's downstream Fedora CI (part 2)
- Backport some new upstream tests
Resolves: RHEL-30245
* Tue Feb 13 2024 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.5-7
- Unbreak Podman's downstream Fedora CI
- Update the BuildRequires on golang to reflect reality
Resolves: RHEL-30245
2024-02-11 23:40:44 +00:00
* Sun Feb 11 2024 Maxwell G <maxwell@gtmx.me> - 0.0.99.5-6
- Rebuild for golang 1.22.0
2024-02-07 13:45:03 +00:00
* Wed Feb 07 2024 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.5-5
- Migrate to SPDX license
* Sat Jan 27 2024 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.99.5-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Thu Jan 11 2024 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.5-3
- Drop 'Recommends: subscription-manager'
* Tue Dec 19 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.5-2
- Drop the experience and support subpackages
* Tue Dec 19 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.5-1
- Update to 0.0.99.5
* Tue Dec 19 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.4-10
- Require openssl(1) for the system tests in the tests subpackage
* Wed Dec 06 2023 Adam Williamson <awilliam@redhat.com> - 0.0.99.4-9
- tests subpackage: require httpd-tools for htpasswd
* Tue Dec 05 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.4-8
- Fix the conditionals for 'if RHEL <= 9'
* Thu Nov 30 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.4-7
- Track the active container on Fedora Linux Asahi Remix
* Thu Nov 09 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.4-6
- Drop the custom /etc/containers/toolbox.conf from RHEL 10 onwards
Drop github.com/coreos/toolbox compatibility from RHEL 10 onwards 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/9506173f88dc26bf https://github.com/containers/toolbox/issues/188 [3] https://github.com/sosreport/sos/pull/3370
2023-10-02 12:02:29 +00:00
* Mon Oct 02 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.4-5
- Drop github.com/coreos/toolbox compatibility from RHEL 10 onwards
* Mon Oct 02 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.4-4
- Be aware of security hardened mount points
- Simplify removing the user's password
* Sat Jul 22 2023 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.99.4-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Wed Mar 8 2023 Nieves Montero <nmontero@redhat.com> - 0.0.99.4-2
- Sprinkle a debug log
* Wed Feb 22 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.4-1
- Update to 0.0.99.4
* Wed Feb 22 2023 Martin Jackson <mhjacks@swbell.net> - 0.0.99.3-12
- Fix the ExclusiveArch
* Tue Feb 21 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.3-11
- Add ExclusiveArch to match Podman
* Thu Feb 02 2023 Yaakov Selkowitz <yselkowi@redhat.com> - 0.0.99.3-10
- Sync packaging changes from CentOS Stream
* Sat Jan 21 2023 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.99.3-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
2022-12-21 05:22:14 +00:00
* Thu Dec 22 2022 Yaakov Selkowitz <yselkowi@redhat.com> - 0.0.99.3-8
- Use vendored dependencies for RHEL/ELN builds
* Sat Jul 23 2022 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.99.3-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Tue Jul 19 2022 Maxwell G <gotmax@e.email> - 0.0.99.3-6
- Rebuild for CVE-2022-{1705,32148,30631,30633,28131,30635,30632,30630,1962} in
golang
* Sat Jun 18 2022 Robert-André Mauchin <zebob.m@gmail.com> - 0.0.99.3-5
- Rebuilt for CVE-2022-1996, CVE-2022-24675, CVE-2022-28327, CVE-2022-27191,
CVE-2022-29526, CVE-2022-30629
* Sat Jan 22 2022 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.99.3-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Sun Jan 09 2022 Ondřej Míchal <harrymichal@fedoraproject.org> - 0.0.99.3-3
- Add upstream patch fixing doubled error messages
* Fri Dec 10 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.3-2
- BuildRequire only systemd-rpm-macros as recommended by the Fedora packaging
guidelines
2021-12-10 03:46:24 +00:00
* Fri Dec 10 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.3-1
- Update to 0.0.99.3
* Mon Oct 25 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.2^3.git075b9a8d2779-9
- Restore backwards compatibility with existing containers
* Fri Oct 22 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.2^3.git075b9a8d2779-8
- Ensure that binaries are run against their build-time ABI
2021-09-13 15:02:32 +00:00
* Mon Sep 13 2021 Oliver Gutiérrez <ogutierrez@fedoraproject.org> - 0.0.99.2^3.git075b9a8d2779-7
- Rebuilt for gating tests
2021-09-09 08:37:58 +00:00
* Thu Sep 09 2021 Oliver Gutiérrez <ogutierrez@fedoraproject.org> - 0.0.99.2^3.git075b9a8d2779-6
- Rebuilt for gating tests
* Mon Aug 23 2021 Oliver Gutiérrez <ogutierrez@fedoraproject.org> - 0.0.99.2^3.git075b9a8d2779-5
- Version bump to build and check fedora gating after fixing ansible playbooks
* Fri Aug 20 2021 Oliver Gutiérrez <ogutierrez@fedoraproject.org> - 0.0.99.2^3.git075b9a8d2779-4
- Version bump to build and check fedora gating
2021-08-18 11:44:07 +00:00
* Wed Aug 18 2021 Oliver Gutiérrez <ogutierrez@fedoraproject.org> - 0.0.99.2^3.git075b9a8d2779-3
- Added Fedora gating
* Wed Aug 18 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.2^3.git075b9a8d2779-2
- Require containers-common for ownership of %%{_sysconfdir}/containers
* Mon Aug 09 2021 Oliver Gutiérrez <ogutierrez@fedoraproject.org> - 0.0.99.2^3.git075b9a8d2779-1
- Updated to 0.0.99.2^3.git075b9a8d2779 snapshot
* Thu Jul 29 2021 Oliver Gutiérrez <ogutierrez@fedoraproject.org> - 0.0.99.2^2.git40fbd377ed0b-1
- Updated to 0.0.99.2^2.git40fbd377ed0b snapshot
* Wed Jul 28 2021 Oliver Gutiérrez <ogutierrez@fedoraproject.org> - 0.0.99.2^1.git9820550c82bb-1
- Updated to 0.00.99.2^1.git9820550c82bb snapshot
* Wed Jul 28 2021 Ondřej Míchal <harrymichal@seznam.cz> - 0.0.99.2-3
- Update dependencies of -tests subpackage
* Fri Jul 23 2021 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.99.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
* Sat Jun 26 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.2-1
- Update to 0.0.99.2
2021-02-23 19:19:10 +00:00
* Tue Feb 23 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.1-1
- Update to 0.0.99.1
* Wed Jan 27 2021 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.99-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
2021-01-12 13:16:48 +00:00
* Tue Jan 12 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99-1
- Update to 0.0.99
* Mon Jan 11 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.98.1-2
- Harden the binary by using the same CGO_CFLAGS as on RHEL 8
2021-01-07 19:36:04 +00:00
* Thu Jan 07 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.98.1-1
- Update to 0.0.98.1
2021-01-05 17:29:31 +00:00
* Tue Jan 05 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.98-1
- Update to 0.0.98
* Wed Nov 25 2020 Ondřej Míchal <harrymichal@seznam.cz> - 0.0.97-2
- Move krb5-libs from -support to -experience, and update the list of packages
in -experience
2020-11-03 19:29:55 +00:00
* Tue Nov 03 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.97-1
- Update to 0.0.97
2020-10-01 18:25:44 +00:00
* Thu Oct 01 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.96-1
- Update to 0.0.96
2020-08-30 20:56:44 +00:00
* Sun Aug 30 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.95-1
- Update to 0.0.95
* Mon Aug 24 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.94-1
- Update to 0.0.94
* Wed Jul 29 2020 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.93-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Sat Jul 25 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.93-1
- Update to 0.0.93
2020-07-03 14:08:39 +00:00
* Fri Jul 03 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.92-1
- Update to 0.0.92
* Fri Jul 03 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.91-2
- Fix the 'toolbox --version' output
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
* Tue Jun 30 2020 Harry Míchal <harrymichal@seznam.cz> - 0.0.91-1
- Update to 0.0.91
2020-06-27 13:50:55 +00:00
* Sat Jun 27 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.18-5
- Remove ExclusiveArch to match Podman
* Wed Jun 10 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.18-4
- Sync the "experience" packages with the current Dockerfile
- Make "experience" Require "support"
* Fri Apr 03 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.18-3
- Drop compatibility Obsoletes and Provides for fedora-toolbox
* Fri Jan 31 2020 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.18-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
2020-01-14 15:35:45 +00:00
* Tue Jan 14 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.18-1
- Update to 0.0.18
2019-11-20 17:13:56 +00:00
* Wed Nov 20 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.17-1
- Update to 0.0.17
2019-10-29 15:16:55 +00:00
* Tue Oct 29 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.16-1
- Update to 0.0.16
2019-09-30 16:34:52 +00:00
* Mon Sep 30 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.15-1
- Update to 0.0.15
* Wed Sep 18 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.14-1
- Update to 0.0.14
2019-09-05 13:14:13 +00:00
* Thu Sep 05 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.13-1
- Update to 0.0.13
* Sat Jul 27 2019 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.12-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
2019-07-22 12:34:53 +00:00
* Mon Jul 22 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.12-1
- Update to 0.0.12
2019-06-25 17:23:33 +00:00
* Tue Jun 25 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.11-2
- Require flatpak-session-helper
2019-06-21 14:57:36 +00:00
* Fri Jun 21 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.11-1
- Update to 0.0.11
2019-05-21 20:48:54 +00:00
* Tue May 21 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.10-1
- Update to 0.0.10
2019-04-30 10:52:59 +00:00
* Tue Apr 30 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.9-1
- Update to 0.0.9
2019-04-16 20:00:57 +00:00
* Tue Apr 16 2019 Adam Williamson <awilliam@redhat.com> - 0.0.8-2
- Rebuild with Meson fix for #1699099
2019-04-12 15:31:21 +00:00
* Fri Apr 12 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.8-1
- Update to 0.0.8
2019-03-14 13:25:59 +00:00
* Thu Mar 14 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.7-1
- Update to 0.0.7
* Fri Feb 22 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.6-1
- Initial build after rename from fedora-toolbox