Bug 2121587 - scons: RPM_ARCH not defined
Summary: scons: RPM_ARCH not defined
Alias: None
Product: Fedora
Classification: Fedora
Component: wesnoth
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 2120063
TreeView+ depends on / blocked
Reported: 2022-08-25 21:26 UTC by Gwyn Ciesla
Modified: 2022-09-12 17:42 UTC (History)
10 users (show)

Fixed In Version: wesnoth-1.17.7-1.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2022-09-12 17:42:38 UTC
Type: Bug

Attachments (Terms of Use)

Description Gwyn Ciesla 2022-08-25 21:26:17 UTC
Wesnoth fails to build on f37 and f38 but only within an RPM build. If I use the exact same scons commands it builds on f38, but the rpm build fails:

g++ -o wesnoth -pthread -fPIE -pie -Wl,-z,relro,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -Wl,--build-id=sha1 -Wl,--whole-archive build/release/libwesnoth-widgets.a -Wl,--no-whole-archive build/release/wesnoth.o build/release/libwesnoth-client.a build/release/liblua.a build/release/libwesnoth-core.a build/release/libwesnoth-game.a build/release/libwesnoth-sdl.a build/release/libwesnoth-client.a -lboost_regex -lboost_filesystem -lboost_locale -lboost_thread -lboost_coroutine -lboost_context -lboost_system -lboost_random -lboost_program_options -lboost_iostreams -lpthread -licudata -licui18n -licuuc -lcrypto -lssl -lSDL2 -lSDL2_mixer -lSDL2_image -lvorbisfile -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lcairo -lfontconfig -lfreetype -lX11 -ldbus-1 -lhistory
g++: fatal error: environment variable 'RPM_ARCH' not defined

The rpm builds fine on f36 and under.

I'm not sure if this an RPM issue or a macro/config issue.

Comment 1 Panu Matilainen 2022-08-29 08:21:32 UTC
Rpm is setting RPM_ARCH in the environment just like it always did (see for yourself: add 'echo RPM_ARCH: ${RPM_ARCH}' to beginning of %build), this is something more peculiar.

gcc has no interest in that variable, I guess this would be package-notes asking for that info. Why it's not finding it is another question: is scons setting up some kind of sanitized build environment, or something? I have no idea, most packages are obviously building just fine with all this.

Reassigning to package-notes whose maintainers may have encountered this before.

Comment 2 Zbigniew Jędrzejewski-Szmek 2022-08-29 10:44:13 UTC
> I guess this would be package-notes asking for that info

Yeah, that's almost certainly it. We use $RPM_ARCH in the gcc specs file.
But first we check that %_arch is set, to rule out noarch builds. So this is
very strange.

Comment 3 Luca Boccassi 2022-08-29 10:48:59 UTC
This is not a noarch build no? At least log above is showing some compilation. If I understand correctly the specs parsing, RPM_ARCH will be the first env var checked. Are any of the RPM_ env vars defined at all? Can that be checked?

Comment 4 Panu Matilainen 2022-08-29 11:11:27 UTC
It's not a noarch package no, but there are no conditionals for setting RPM_ARCH, it's *always* there including noarch.

It's there at the start of %build in this case too (ie the spec isn't doing anything totally weird), but somehow in the link of final executable (AFAICS) it has gone missing: https://kojipkgs.fedoraproject.org//work/tasks/9575/91249575/build.log

Comment 5 Panu Matilainen 2022-08-29 11:15:19 UTC
From https://scons.org/doc/2.1.0/HTML/scons-user/x1750.html

> When SCons builds a target file, it does not execute the commands with the same external environment that you used to execute SCons. Instead, it uses the dictionary stored in the $ENV construction variable as the external environment for executing commands. 

So as I suspected, it's a "sanitized build environment", enforced by scons. Not specific to wesnoth but any scons based project will encounter this.

Comment 6 Luca Boccassi 2022-08-29 11:17:01 UTC
So it should be possible to pass these variables through then?

Comment 7 Panu Matilainen 2022-08-29 11:22:21 UTC
I guess so. And I guess optimally this would be set from the scons package centrally, but I've no idea whether that's possible. I'm just a bystander in this, really :D

Comment 8 Zbigniew Jędrzejewski-Szmek 2022-08-29 11:31:40 UTC
I don't think we can handle this within package-notes. Looking at the SConstruct file in wesnoth,
even things like $PATH and $TERM are explicitly set. It seems $RPM_PACKAGE_NAME,
$RPM_PACKAGE_VERSION, $RPM_PACKAGE_RELEASE, $RPM_ARCH would need to be handled like this.
This needs to be done in the package itself.

I'll reassign this to weston, it'll need to be handled there, sorry.

Comment 9 Panu Matilainen 2022-08-29 11:41:37 UTC
You might want to document this as a "known issue" kind of thing for package-notes though.

Comment 10 Zbigniew Jędrzejewski-Szmek 2022-08-29 11:48:32 UTC
Will do.

Comment 11 Gwyn Ciesla 2022-08-29 22:15:52 UTC
Thanks, I was able to patch. Oddly the SConstruct an option to bring in the entire environment and it doesn't bring in the RPM bits.

Comment 12 Fedora Update System 2022-08-29 22:24:37 UTC
FEDORA-2022-546a5b5510 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-546a5b5510

Comment 13 Fedora Update System 2022-08-30 06:59:31 UTC
FEDORA-2022-546a5b5510 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-546a5b5510`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-546a5b5510

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Fedora Update System 2022-09-12 17:42:38 UTC
FEDORA-2022-546a5b5510 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.