rpms/toolbox
7
0
Fork 0
Code Issues Pull Requests Releases Activity
8fd7877f42
toolbox/toolbox.spec

482 lines
15 KiB
RPMSpec
Raw Normal View History

Ensure that binaries are run against their build-time ABI https://bugzilla.redhat.com/show_bug.cgi?id=1995439
2021-10-22 00:17:56 +00:00
%global __brp_check_rpaths %{nil}
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
Name: toolbox
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
Version: 0.0.99.4
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}
Fix the ExclusiveArch 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 7ce081c75c58898a96d5cae129fbc120f255e1d6 https://src.fedoraproject.org/rpms/toolbox/pull-request/12
2023-02-22 14:48:32 +00:00
Fix the conditionals for 'if RHEL <= 9' '%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 1d18729e66267b6a267b362af06d0a130cdb967f and d437e836048bc5eecc1fc1b111cfe74d70c5c67e
2023-12-05 14:14:49 +00:00
%if 0%{?fedora}
%gometa -f
%endif
%if 0%{?rhel}
Clarify that %golang_arches_future are meant for RHEL 10 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.
2023-11-09 16:07:29 +00:00
%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
Fix the ExclusiveArch 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 7ce081c75c58898a96d5cae129fbc120f255e1d6 https://src.fedoraproject.org/rpms/toolbox/pull-request/12
2023-02-22 14:48:32 +00:00
%else
%gometa -f
%endif
Fix the conditionals for 'if RHEL <= 9' '%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 1d18729e66267b6a267b362af06d0a130cdb967f and d437e836048bc5eecc1fc1b111cfe74d70c5c67e
2023-12-05 14:14:49 +00:00
%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
Fix the conditionals for 'if RHEL <= 9' '%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 1d18729e66267b6a267b362af06d0a130cdb967f and d437e836048bc5eecc1fc1b111cfe74d70c5c67e
2023-12-05 14:14:49 +00:00
Release: 8%{?dist}
Tweak the Summary No need to issue a build just for this.
2021-04-28 23:02:13 +00:00
Summary: Tool for containerized command line environments on Linux
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
License: ASL 2.0
Update URL to point to the website No need to issue a build just for this.
2021-12-10 04:11:42 +00:00
URL: https://containertoolbx.org/
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
Source0: https://github.com/containers/%{name}/releases/download/%{version}/%{name}-%{version}-vendored.tar.xz
Unify the build with RHEL 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 https://github.com/containers/toolbox/commit/f555029304415a06 https://github.com/containers/toolbox/issues/1246
2023-10-02 11:32:02 +00:00
# RHEL specific
Unify the build with RHEL There's no need to do a build just for this.
2023-04-03 20:23:50 +00:00
Source1: %{name}.conf
Ensure that binaries are run against their build-time ABI https://bugzilla.redhat.com/show_bug.cgi?id=1995439
2021-10-22 00:17:56 +00:00
Don't use podman(1) when generating the completions 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
2023-02-27 16:49:45 +00:00
# Upstream
Unify the build with RHEL 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 https://github.com/containers/toolbox/commit/f555029304415a06 https://github.com/containers/toolbox/issues/1246
2023-10-02 11:32:02 +00:00
Patch0: toolbox-Build-fixes.patch
Add two upstream patches that are already in CentOS Stream 9
2023-10-02 11:46:15 +00:00
Patch1: toolbox-cmd-initContainer-Be-aware-of-security-hardened-moun.patch
Patch2: toolbox-Simplify-removing-the-user-s-password.patch
Track the active container on Fedora Linux Asahi Remix
2023-11-30 21:16:08 +00:00
Patch3: toolbox-cmd-Track-the-active-container-on-Fedora-Linux-Asahi.patch
Don't use podman(1) when generating the completions 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
2023-02-27 16:49:45 +00:00
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
Remove a patch specific to Fedora that doesn't seem necessary anymore There's no need to do a build just for this.
2023-02-23 16:15:40 +00:00
Patch100: toolbox-Make-the-build-flags-match-Fedora-s-gobuild.patch
Patch101: toolbox-Make-the-build-flags-match-Fedora-s-gobuild-for-PPC64.patch
Add missing files for RHEL builds Source and Patch listings should not be conditionalized, as that causes SRPM contents to be inconsistent. https://src.fedoraproject.org/rpms/toolbox/pull-request/14
2023-06-22 20:54:55 +00:00
# RHEL specific
Pull in the rest of the RHEL specific patches to further unify the build There's no need to do a build just for this.
2023-06-26 13:26:07 +00:00
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
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
Add missing 'BuildRequires: gcc' A C compiler is necessary to build Toolbx [1]. GCC is being pulled in by the other BuildRequires, but it's good to explicitly list it since GCC isn't part of the default buildroot since Fedora 29 [2] and will prevent the compiler from unexpectedly changing to Clang. There's no need to do a build just for this. [1] Upstream commit c8aaed52c547e24e https://github.com/containers/toolbox/commit/c8aaed52c547e24e https://github.com/containers/toolbox/pull/923 [2] https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
2023-02-21 15:48:16 +00:00
BuildRequires: gcc
Revert back to referring to go-md2man as go-md2man 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 701836afcad6f0b08d8430e0914103d0871e4cdc. 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
2022-05-17 16:18:33 +00:00
BuildRequires: go-md2man
Bump the golang requirement to ensure recent CVE fixes '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
2023-02-22 19:29:43 +00:00
BuildRequires: golang >= 1.19.4
Shuffle the BuildRequires around There's no need to do a build just for this.
2023-04-03 22:27:52 +00:00
BuildRequires: meson >= 0.58.0
BuildRequires: pkgconfig(bash-completion)
BuildRequires: shadow-utils-subid-devel
BuildRequires: systemd
BuildRequires: systemd-rpm-macros
Use vendored dependencies for RHEL
2022-12-21 05:22:14 +00:00
%if ! 0%{?rhel}
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
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
Update to 0.0.93 The test suite has been temporarily disabled because ShellCheck 0.7.1 triggers SC2086 for some unquoted variables. It should be re-enabled as soon as it's fixed upstream.
2020-07-09 15:01:25 +00:00
BuildRequires: golang(github.com/docker/go-units) >= 0.4.0
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
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
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
BuildRequires: golang(golang.org/x/sys/unix)
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
BuildRequires: golang(golang.org/x/term)
Don't 'BuildRequires: pkgconfig(fish)' on RHEL ... because RHEL doesn't have fish. There's no need to do a build just for this.
2023-04-03 22:34:08 +00:00
BuildRequires: pkgconfig(fish)
Sync packaging changes from CentOS Stream
2023-02-02 17:55:51 +00:00
# for tests
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
# BuildRequires: codespell
Mark and comment out the unused BuildRequires for %check Fallout from 484d3d62090cfad0f91274d96956c32219bf099b and 12df1ef16a673d90a85d3b8fc631adcd1ae27ba5 There's no need to do a build just for this.
2023-02-21 16:01:39 +00:00
# BuildRequires: golang(github.com/stretchr/testify) >= 1.7.0
# BuildRequires: ShellCheck
Use vendored dependencies for RHEL
2022-12-21 05:22:14 +00:00
%endif
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
Require containers-common for ownership of %%{_sysconfdir}/containers
2021-08-17 16:15:50 +00:00
Requires: containers-common
Update to 0.0.14 Fix a typo in the minimum Podman version requirement. Podman 1.4.0 is meant to be fine.
2019-09-18 17:07:10 +00:00
Requires: podman >= 1.4.0
Don't 'Requires: flatpak-session-helper' on RHEL ... because RHEL has always shipped toolbox >= 0.0.97 and hence doesn't require flatpak-session-helper. There's no need to do a build just for this.
2023-04-03 19:32:11 +00:00
%if ! 0%{?rhel}
Requires: flatpak-session-helper
%endif
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%description
Update to 0.0.99
2021-01-12 13:16:48 +00:00
Toolbox is a tool for Linux operating systems, which allows the use of
containerized command line environments. It is built on top of Podman and
other standard container technologies from OCI.
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
Sync packaging changes from CentOS Stream
2023-02-02 17:55:51 +00:00
%if ! 0%{?rhel}
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
# The list of requires packages for -support and -experience should be in sync with:
Update URL to point at the latest extra-packages file for Fedora 33 There's no need to issue a build just for this.
2020-06-30 12:13:27 +00:00
# https://github.com/containers/toolbox/blob/master/images/fedora/f33/extra-packages
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
%package support
Summary: Required packages for the container image to support %{name}
# These are really required to make the image work with toolbox
Requires: passwd
Requires: shadow-utils
Update to 0.0.99.3
2021-12-10 03:46:24 +00:00
Requires: util-linux
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
Requires: vte-profile
%description support
The %{name}-support package contains all the required packages that are needed
Tweak the description No need to issue a build just for this.
2020-11-25 21:49:41 +00:00
to be installed in the OCI image to make it work with %{name}.
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
The %{name}-support package should be typically installed from the Dockerfile
if the image isn't based on the fedora-toolbox image.
%package experience
Summary: Set of packages to enhance the %{name} experience
Update the "experience" sub-package - Sync it with the current Dockerfile - Make it Require the "support" sub-package
2020-06-10 14:10:24 +00:00
Requires: %{name}-support = %{version}-%{release}
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
Requires: bash-completion
Add bc and iproute to the toolbox-experience sub-package No need to issue a build just for this.
2021-07-08 18:59:14 +00:00
Requires: bc
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
Requires: bzip2
Requires: diffutils
Requires: dnf-plugins-core
Requires: findutils
Update the "experience" sub-package - Sync it with the current Dockerfile - Make it Require the "support" sub-package
2020-06-10 14:10:24 +00:00
Requires: flatpak-spawn
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
Requires: fpaste
Requires: git
Requires: gnupg
Requires: gnupg2-smime
Update the "experience" sub-package - Sync it with the current Dockerfile - Make it Require the "support" sub-package
2020-06-10 14:10:24 +00:00
Requires: gvfs-client
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
Requires: hostname
Add bc and iproute to the toolbox-experience sub-package No need to issue a build just for this.
2021-07-08 18:59:14 +00:00
Requires: iproute
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
Requires: iputils
Requires: jwhois
Requires: keyutils
Move krb5-libs to -experience, and update the list of packages The krb5-libs package is necessary to ensure the presence of the /etc/krb5.conf.d directory with the correct permissions. However, it's not strictly necessary and toolbox(1) can work without it. https://src.fedoraproject.org/rpms/toolbox/pull-request/4
2020-11-25 21:06:47 +00:00
Requires: krb5-libs
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
Requires: less
Requires: lsof
Requires: man-db
Requires: man-pages
Requires: mtr
Update to 0.0.99.2 Disable the %check section because 'go test ...' isn't working as it is in the build environment.
2021-06-26 18:03:14 +00:00
Requires: nano-default-editor
Move krb5-libs to -experience, and update the list of packages The krb5-libs package is necessary to ensure the presence of the /etc/krb5.conf.d directory with the correct permissions. However, it's not strictly necessary and toolbox(1) can work without it. https://src.fedoraproject.org/rpms/toolbox/pull-request/4
2020-11-25 21:06:47 +00:00
Requires: nss-mdns
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
Requires: openssh-clients
Requires: pigz
Requires: procps-ng
Requires: rsync
Requires: sudo
Requires: tcpdump
Requires: time
Requires: traceroute
Requires: tree
Requires: unzip
Requires: wget
Requires: which
Requires: words
Move krb5-libs to -experience, and update the list of packages The krb5-libs package is necessary to ensure the presence of the /etc/krb5.conf.d directory with the correct permissions. However, it's not strictly necessary and toolbox(1) can work without it. https://src.fedoraproject.org/rpms/toolbox/pull-request/4
2020-11-25 21:06:47 +00:00
Requires: xorg-x11-xauth
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
Requires: xz
Requires: zip
%description experience
The %{name}-experience package contains all the packages that should be
installed in the container to provide the same default experience as working
on the host.
The %{name}-experience package should be typically installed from the
Dockerfile if the image isn't based on the fedora-toolbox image.
Sync packaging changes from CentOS Stream
2023-02-02 17:55:51 +00:00
%endif
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
Update to 0.0.94 Based on code written by Ondřej Míchal.
2020-08-24 17:39:43 +00:00
%package tests
Summary: Tests for %{name}
Requires: %{name}%{?_isa} = %{version}-%{release}
Update dependencies of -tests subpackage
2021-03-21 23:06:32 +00:00
Requires: coreutils
Requires: gawk
Requires: grep
Requires: skopeo
Don't 'Requires: bats' on RHEL ... because RHEL doesn't have bats. There's no need to do a build just for this.
2023-04-03 19:26:42 +00:00
%if ! 0%{?rhel}
Requires: bats
%endif
Update to 0.0.94 Based on code written by Ondřej Míchal.
2020-08-24 17:39:43 +00:00
%description tests
The %{name}-tests package contains system tests for %{name}.
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%prep
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
%setup -q
Don't use podman(1) when generating the completions 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
2023-02-27 16:49:45 +00:00
%patch0 -p1
Add two upstream patches that are already in CentOS Stream 9
2023-10-02 11:46:15 +00:00
%patch1 -p1
%patch2 -p1
Track the active container on Fedora Linux Asahi Remix
2023-11-30 21:16:08 +00:00
%patch3 -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
Pull in the rest of the RHEL specific patches to further unify the build There's no need to do a build just for this.
2023-06-26 13:26:07 +00:00
%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
Remove a patch specific to Fedora that doesn't seem necessary anymore There's no need to do a build just for this.
2023-02-23 16:15:40 +00:00
%patch100 -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
Remove a patch specific to Fedora that doesn't seem necessary anymore There's no need to do a build just for this.
2023-02-23 16:15:40 +00:00
%patch101 -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
Pull in the rest of the RHEL specific patches to further unify the build There's no need to do a build just for this.
2023-06-26 13:26:07 +00:00
%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
Unify the build with RHEL There's no need to do a build just for this.
2023-04-03 20:23:50 +00:00
%if 0%{?rhel}
Pull in the rest of the RHEL specific patches to further unify the build There's no need to do a build just for this.
2023-06-26 13:26:07 +00:00
%ifnarch ppc64
Add missing files for RHEL builds Source and Patch listings should not be conditionalized, as that causes SRPM contents to be inconsistent. https://src.fedoraproject.org/rpms/toolbox/pull-request/14
2023-06-22 20:54:55 +00:00
%patch200 -p1
Pull in the rest of the RHEL specific patches to further unify the build There's no need to do a build just for this.
2023-06-26 13:26:07 +00:00
%else
%patch201 -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
Pull in the rest of the RHEL specific patches to further unify the build There's no need to do a build just for this.
2023-06-26 13:26:07 +00:00
%patch202 -p1
Unify the build with RHEL There's no need to do a build just for this.
2023-04-03 20:23:50 +00:00
%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
Unify the build with RHEL There's no need to do a build just for this.
2023-04-03 20:23:50 +00:00
Simplify and unify the build with RHEL There's no need to do a build just for this.
2023-02-23 14:22:14 +00:00
%gomkdir -s %{_builddir}/%{extractdir}/src %{?rhel:-k}
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%build
Use %gomodulesmode introduced in go-rpm-macros-3.0.10 There's no need to do a build just for this.
2023-02-21 16:15:21 +00:00
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}
Harden the binary by using the same CGO_CFLAGS as on RHEL 8
2021-01-11 11:57:06 +00:00
export CGO_CFLAGS="%{optflags} -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64"
Simplify and unify the build with RHEL There's no need to do a build just for this.
2023-02-23 14:22:14 +00:00
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
%meson \
Unify the build with RHEL There's no need to do a build just for this.
2023-04-03 20:23:50 +00:00
%if 0%{?rhel}
Don't 'BuildRequires: pkgconfig(fish)' on RHEL ... because RHEL doesn't have fish. There's no need to do a build just for this.
2023-04-03 22:34:08 +00:00
-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
Unify the build with RHEL There's no need to do a build just for this.
2023-04-03 20:23:50 +00:00
-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
Unify the build with RHEL There's no need to do a build just for this.
2023-04-03 20:23:50 +00:00
%endif
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
-Dprofile_dir=%{_sysconfdir}/profile.d \
-Dtmpfiles_dir=%{_tmpfilesdir} \
-Dzsh_completions_dir=%{_datadir}/zsh/site-functions
Unify the build with RHEL There's no need to do a build just for this.
2023-04-03 20:23:50 +00:00
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%meson_build
Update to 0.0.99.2 Disable the %check section because 'go test ...' isn't working as it is in the build environment.
2021-06-26 18:03:14 +00:00
# %%check
# %%meson_test
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%install
%meson_install
Fix the conditionals for 'if RHEL <= 9' '%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 1d18729e66267b6a267b362af06d0a130cdb967f and d437e836048bc5eecc1fc1b111cfe74d70c5c67e
2023-12-05 14:14:49 +00:00
%if 0%{?rhel}
Drop the custom /etc/containers/toolbox.conf from RHEL 10 onwards 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/0a29b374e649437 https://github.com/containers/toolbox/issues/1065
2023-11-09 16:17:07 +00:00
%if 0%{?rhel} <= 9
Unify the build with RHEL There's no need to do a build just for this.
2023-04-03 20:23:50 +00:00
install -m0644 %{SOURCE1} %{buildroot}%{_sysconfdir}/containers/%{name}.conf
%endif
Fix the conditionals for 'if RHEL <= 9' '%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 1d18729e66267b6a267b362af06d0a130cdb967f and d437e836048bc5eecc1fc1b111cfe74d70c5c67e
2023-12-05 14:14:49 +00:00
%endif
Unify the build with RHEL There's no need to do a build just for this.
2023-04-03 20:23:50 +00:00
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%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
Use vendored dependencies for RHEL
2022-12-21 05:22:14 +00:00
%license COPYING %{?rhel:src/vendor/modules.txt}
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%{_bindir}/%{name}
Update to 0.0.9
2019-04-30 10:52:59 +00:00
%{_datadir}/bash-completion
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
%{_datadir}/fish
%{_datadir}/zsh
Update to 0.0.7
2019-03-14 13:25:59 +00:00
%{_mandir}/man1/%{name}.1*
%{_mandir}/man1/%{name}-*.1*
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
%{_mandir}/man5/%{name}.conf.5*
Added missing configuration file
2021-07-28 16:54:13 +00:00
%config(noreplace) %{_sysconfdir}/containers/%{name}.conf
Use %{name} instead of hard-coding 'toolbox' There's no need to issue a build just for this.
2020-05-14 16:25:18 +00:00
%{_sysconfdir}/profile.d/%{name}.sh
Update to 0.0.7
2019-03-14 13:25:59 +00:00
%{_tmpfilesdir}/%{name}.conf
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
Sync packaging changes from CentOS Stream
2023-02-02 17:55:51 +00:00
%if ! 0%{?rhel}
Add the toolbox-support and toolbox-experience subpackages These are intended to be installed into the image if the image doesn't use the fedora-toolbox container as the base image - all the packages are already preinstalled there. The support subpackage should be installed to images that intent to work flawlessly with toolbox. The experience subpackage should be installed as well, to provide the same experience while working in the container as one would get on the host. https://src.fedoraproject.org/rpms/toolbox/pull-request/1
2019-03-26 15:03:03 +00:00
%files support
%files experience
Sync packaging changes from CentOS Stream
2023-02-02 17:55:51 +00:00
%endif
Update to 0.0.94 Based on code written by Ondřej Míchal.
2020-08-24 17:39:43 +00:00
%files tests
%{_datadir}/%{name}
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%changelog
Fix the conditionals for 'if RHEL <= 9' '%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 1d18729e66267b6a267b362af06d0a130cdb967f and d437e836048bc5eecc1fc1b111cfe74d70c5c67e
2023-12-05 14:14:49 +00:00
* Tue Dec 05 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.4-8
- Fix the conditionals for 'if RHEL <= 9'
Track the active container on Fedora Linux Asahi Remix
2023-11-30 21:16:08 +00:00
* Thu Nov 30 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.4-7
- Track the active container on Fedora Linux Asahi Remix
Drop the custom /etc/containers/toolbox.conf from RHEL 10 onwards 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/0a29b374e649437 https://github.com/containers/toolbox/issues/1065
2023-11-09 16:17:07 +00:00
* 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
Add two upstream patches that are already in CentOS Stream 9
2023-10-02 11:46:15 +00:00
* 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
Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2023-07-22 16:34:45 +00:00
* 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
Sprinkle a debug log Signed-off-by: Nieves Montero <nmontero@redhat.com>
2023-03-08 10:24:16 +00:00
* Wed Mar 8 2023 Nieves Montero <nmontero@redhat.com> - 0.0.99.4-2
- Sprinkle a debug log
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
* Wed Feb 22 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.4-1
- Update to 0.0.99.4
Fix the ExclusiveArch 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 7ce081c75c58898a96d5cae129fbc120f255e1d6 https://src.fedoraproject.org/rpms/toolbox/pull-request/12
2023-02-22 14:48:32 +00:00
* Wed Feb 22 2023 Martin Jackson <mhjacks@swbell.net> - 0.0.99.3-12
- Fix the ExclusiveArch
Add ExclusiveArch to match Podman 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
2023-02-21 16:32:58 +00:00
* Tue Feb 21 2023 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.3-11
- Add ExclusiveArch to match Podman
Sync packaging changes from CentOS Stream
2023-02-02 17:55:51 +00:00
* Thu Feb 02 2023 Yaakov Selkowitz <yselkowi@redhat.com> - 0.0.99.3-10
- Sync packaging changes from CentOS Stream
Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2023-01-21 05:16:24 +00:00
* 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
Use vendored dependencies for RHEL
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
Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2022-07-23 10:41:32 +00:00
* 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
Rebuild for CVE-2022-{1705,32148,30631,30633,28131,30635,30632,30630,1962} in golang
2022-07-19 18:59:13 +00:00
* 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
Rebuilt for CVE-2022-1996, CVE-2022-24675, CVE-2022-28327, CVE-2022-27191, CVE-2022-29526, CVE-2022-30629
2022-06-18 10:23:53 +00:00
* 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
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2022-01-22 02:54:24 +00:00
* 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
Add upstream patch fixing doubled error messages
2022-01-09 18:36:32 +00:00
* Sun Jan 09 2022 Ondřej Míchal <harrymichal@fedoraproject.org> - 0.0.99.3-3
- Add upstream patch fixing doubled error messages
BuildRequire only systemd-rpm-macros ... as recommended by the Fedora packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/Tmpfiles.d/ https://pagure.io/packaging-committee/issue/824
2021-12-10 10:15:00 +00:00
* 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
Update to 0.0.99.3
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
Restore backwards compatibility with existing containers https://bugzilla.redhat.com/show_bug.cgi?id=1995439
2021-10-25 11:33:41 +00:00
* Mon Oct 25 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.2^3.git075b9a8d2779-9
- Restore backwards compatibility with existing containers
Ensure that binaries are run against their build-time ABI https://bugzilla.redhat.com/show_bug.cgi?id=1995439
2021-10-22 00:17:56 +00:00
* 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
Rebuilt for gating
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
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
Bumped version for rerun gating after updating the ansible playbooks
2021-08-23 18:26:50 +00:00
* 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
Version bump to build and check fedora gating
2021-08-20 10:30:18 +00:00
* 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
Updated specfile for gating execution
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
Require containers-common for ownership of %%{_sysconfdir}/containers
2021-08-17 16:15:50 +00:00
* Wed Aug 18 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.2^3.git075b9a8d2779-2
- Require containers-common for ownership of %%{_sysconfdir}/containers
Updated to 0.0.99.2^3.git075b9a8d2779 snapshot
2021-08-09 18:09:23 +00:00
* 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
Updated to 0.0.99.2^2.git40fbd377ed0b snapshot
2021-07-29 13:27:25 +00:00
* 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
Updated sources to 0.00.99.2^1.git9820550c82bb snapshot
2021-07-28 15:55:24 +00:00
* 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
Added changelog entry for the update dependencies of -tests subpackage
2021-07-28 15:25:06 +00:00
* Wed Jul 28 2021 Ondřej Míchal <harrymichal@seznam.cz> - 0.0.99.2-3
- Update dependencies of -tests subpackage
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2021-07-23 19:27:42 +00:00
* 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
Update to 0.0.99.2 Disable the %check section because 'go test ...' isn't working as it is in the build environment.
2021-06-26 18:03:14 +00:00
* Sat Jun 26 2021 Debarshi Ray <rishi@fedoraproject.org> - 0.0.99.2-1
- Update to 0.0.99.2
Update to 0.0.99.1
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
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2021-01-27 22:07:14 +00:00
* Wed Jan 27 2021 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.99-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
Update to 0.0.99
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
Harden the binary by using the same CGO_CFLAGS as on RHEL 8
2021-01-11 11:57:06 +00:00
* 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
Update to 0.0.98.1
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
Update to 0.0.98
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
Move krb5-libs to -experience, and update the list of packages The krb5-libs package is necessary to ensure the presence of the /etc/krb5.conf.d directory with the correct permissions. However, it's not strictly necessary and toolbox(1) can work without it. https://src.fedoraproject.org/rpms/toolbox/pull-request/4
2020-11-25 21:06:47 +00:00
* 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
Update to 0.0.97
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
Update to 0.0.96
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
Update to 0.0.95
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
Update to 0.0.94 Based on code written by Ondřej Míchal.
2020-08-24 17:39:43 +00:00
* Mon Aug 24 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.94-1
- Update to 0.0.94
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2020-07-29 12:41:16 +00:00
* Wed Jul 29 2020 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.93-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
Update to 0.0.93 The test suite has been temporarily disabled because ShellCheck 0.7.1 triggers SC2086 for some unquoted variables. It should be re-enabled as soon as it's fixed upstream.
2020-07-09 15:01:25 +00:00
* Sat Jul 25 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.93-1
- Update to 0.0.93
Update to 0.0.92
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
Fix the 'toolbox --version' output Even though the actual release is 0.0.91, 'toolbox --version' was showing 0.0.90.
2020-07-03 13:36:51 +00:00
* 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
Remove ExclusiveArch to match Podman
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
Update the "experience" sub-package - Sync it with the current Dockerfile - Make it Require the "support" sub-package
2020-06-10 14:10:24 +00:00
* 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"
Drop compatibility Obsoletes and Provides for fedora-toolbox
2020-04-03 17:00:14 +00:00
* Fri Apr 03 2020 Debarshi Ray <rishi@fedoraproject.org> - 0.0.18-3
- Drop compatibility Obsoletes and Provides for fedora-toolbox
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2020-01-31 01:49:13 +00:00
* Fri Jan 31 2020 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.18-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
Update to 0.0.18
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
Update to 0.0.17
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
Update to 0.0.16
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
Update to 0.0.15
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
Update to 0.0.14 Fix a typo in the minimum Podman version requirement. Podman 1.4.0 is meant to be fine.
2019-09-18 17:07:10 +00:00
* Wed Sep 18 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.14-1
- Update to 0.0.14
Update to 0.0.13
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
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2019-07-27 01:41:12 +00:00
* Sat Jul 27 2019 Fedora Release Engineering <releng@fedoraproject.org> - 0.0.12-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
Update to 0.0.12
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
Require flatpak-session-helper
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
Update to 0.0.11
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
Update to 0.0.10
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
Update to 0.0.9
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
Rebuild with Meson fix for #1699099
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
Update to 0.0.8
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
Update to 0.0.7
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
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
* Fri Feb 22 2019 Debarshi Ray <rishi@fedoraproject.org> - 0.0.6-1
- Initial build after rename from fedora-toolbox
Reference in New Issue Copy Permalink