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.
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.
> 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.
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?
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
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.
So it should be possible to pass these variables through then?
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
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.
You might want to document this as a "known issue" kind of thing for package-notes though.
Will do.
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.
FEDORA-2022-546a5b5510 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-546a5b5510
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.
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.