PR#3: Drop 32bit arches in RHEL 9 - rpms/go-rpm-macros

rpms / go-rpm-macros

#3 Drop 32bit arches in RHEL 9

Closed 2 years ago by sgallagh. Opened 3 years ago by psabata.

rpms/ psabata/go-rpm-macros rhel9 into rawhide

Petr Šabata • 3 years ago

7099a99

go-rpm-macros.spec

file modified

+7 -1

		`@@ -8,6 +8,9 @@`

		`# Master definition that will be written to macro files`
		`%global golang_arches %{ix86} x86_64 %{arm} aarch64 ppc64le s390x`
		`+ %if 0%{?rhel} >= 9`
		`+ %global golang_arches x86_64 aarch64 ppc64le s390x`
		`+ %endif`
		`%global gccgo_arches %{mips}`
		`# Go sources can contain arch-specific files and our macros will package the`
		`# correct files for each architecture. Therefore, move gopath to _libdir and`
		`@@ -17,7 +20,7 @@`
		`ExclusiveArch: %{golang_arches} %{gccgo_arches}`

		`Name: go-rpm-macros`
		`- Release: 1%{?dist}`
		`+ Release: 2%{?dist}`
		`Summary: Build-stage rpm automation for Go packages`

		`License: GPLv3+`
		`@@ -162,6 +165,9 @@`
		`%{_spectemplatedir}/*.spec`

		`%changelog`
		`+ * Mon Nov 30 2020 Petr Šabata <contyk@redhat.com> - 3.0.9-2`
		`+ - Drop 32bit arches in EL 9`
		`+`
		`* Thu Aug 13 2020 Neal Gompa <ngompa13@gmail.com> - 3.0.9-1`
		`- Update to 3.0.9`

psabata commented 3 years ago

Signed-off-by: Petr Šabata contyk@redhat.com

psabata commented 3 years ago

EL9 does not build golang on neither armv7hl nor i686. This sets the environment for the rest of the ecosystem.

Note it doesn't require a Rawhide build, just ELN, which I'll do manually once accepted.

zuul commented 3 years ago

Build failed.

rpm-scratch-build : SUCCESS in 5m 31s
rpm-linter : FAILURE in 2m 56s
rpm-rpminspect : SUCCESS in 5m 04s (non-voting)
check-for-tests : SUCCESS in 5s
rpm-install-test : SUCCESS in 2m 35s
rpm-test : SKIPPED

psabata commented 3 years ago

That's bogus and unrelated to this PR.

ngompa commented 3 years ago

:thumbsup:

psabata commented 3 years ago

I've been playing with this and, to my horror, virtually not a single golang package follows the guildelines regarding this macro. Guess I'll have to file hundreds of bugs...

Besides my use case noted above, if Fedora adds a new architecture, unsupported by golang, they would all break.