rpms/toolbox
7
0
Fork 0
Code Issues Pull Requests Releases Activity
52cbc50450
toolbox/toolbox.spec

227 lines
6.3 KiB
RPMSpec
Raw Normal View History

Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
Name: toolbox
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
Version: 0.0.91
%global goipath github.com/containers/%{name}
%gometa
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
Release: 2%{?dist}
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
Summary: Unprivileged development environment
License: ASL 2.0
Use %{name} instead of hard-coding 'toolbox' There's no need to issue a build just for this.
2020-06-30 12:11:35 +00:00
URL: https://github.com/containers/%{name}
Update to 0.0.16
2019-10-29 15:16:55 +00:00
Source0: https://github.com/containers/%{name}/releases/download/%{version}/%{name}-%{version}.tar.xz
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +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
Patch0: toolbox-Make-it-build-on-aarch64.patch
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
Patch1: toolbox-Embed-the-version-from-Meson-into-the-binary.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-Don-t-use-Go-s-semantic-import-versioning.patch
Patch101: toolbox-Make-the-build-flags-match-Fedora-s-gobuild.patch
Patch102: toolbox-Make-the-build-flags-match-Fedora-s-gobuild-for-PPC64.patch
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
Update to 0.0.8
2019-04-12 15:31:21 +00:00
BuildRequires: ShellCheck
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 >= 1.13
Update the name of the go-md2man package It used to have 'go-md2man' as a virtual Provides, but that's no longer the case, and the source package was also renamed afterwards.
2019-06-25 18:07:14 +00:00
BuildRequires: golang-github-cpuguy83-md2man
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(github.com/HarryMichal/go-version)
BuildRequires: golang(github.com/acobaugh/osrelease)
BuildRequires: golang(github.com/briandowns/spinner) >= 1.10.0
BuildRequires: golang(github.com/godbus/dbus) >= 5.0.3
BuildRequires: golang(github.com/sirupsen/logrus) >= 1.4.2
BuildRequires: golang(github.com/spf13/cobra) >= 0.0.5
BuildRequires: golang(golang.org/x/sys/unix)
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
BuildRequires: meson
Update to 0.0.9
2019-04-30 10:52:59 +00:00
BuildRequires: pkgconfig(bash-completion)
Update to 0.0.7
2019-03-14 13:25:59 +00:00
BuildRequires: systemd
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
Require flatpak-session-helper
2019-06-25 17:23:33 +00:00
Requires: flatpak-session-helper
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
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%description
Toolbox is offers a familiar RPM based environment for developing and
debugging software that runs fully unprivileged using Podman.
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
Requires: krb5-libs
Requires: vte-profile
%description support
The %{name}-support package contains all the required packages that are needed
to be installed in the container image to make it work with the %{name}.
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
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
Requires: iputils
Requires: jwhois
Requires: keyutils
Requires: less
Requires: lsof
Requires: man-db
Requires: man-pages
Requires: mlocate
Requires: mtr
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
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.
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%prep
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
%setup -q
%patch0 -p1
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
%patch1 -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
%patch100 -p1
%ifnarch ppc64
%patch101 -p1
%else
%patch102 -p1
%endif
%gomkdir
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%build
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 GO111MODULE=off
export GOPATH=%{gobuilddir}:%{gopath}
ln -s src/cmd cmd
ln -s src/pkg pkg
Update to 0.0.9
2019-04-30 10:52:59 +00:00
%meson --buildtype=plain -Dprofile_dir=%{_sysconfdir}/profile.d
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%meson_build
%check
Update to 0.0.8
2019-04-12 15:31:21 +00:00
%meson_test
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%install
%meson_install
%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
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%license COPYING
%{_bindir}/%{name}
Update to 0.0.9
2019-04-30 10:52:59 +00:00
%{_datadir}/bash-completion
Update to 0.0.7
2019-03-14 13:25:59 +00:00
%{_mandir}/man1/%{name}.1*
%{_mandir}/man1/%{name}-*.1*
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
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
Initial build after rename from fedora-toolbox
2019-03-01 17:59:51 +00:00
%changelog
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