Description of problem: My rpmbuild fails with + /usr/lib/rpm/check-rpaths + /usr/lib/rpm/redhat/brp-mangle-shebangs + /usr/lib/rpm/brp-remove-la-files + env /usr/lib/rpm/redhat/brp-python-bytecompile '' 1 0 -l8 Bytecompiling .py files below /tmp/tito/rpmbuild-titodu7594qh/BUILDROOT/tito-0.6.22-1.git.8.759c031.fc38.x86_64/usr/lib/python3.11 using python3.11 usage: compileall.py [-h] [-l] [-r RECURSION] [-f] [-q] [-b] [-d DESTDIR] [-s STRIPDIR] [-p PREPENDDIR] [-x REGEXP] [-i FILE] [-j WORKERS] [--invalidation-mode {checked-hash,timestamp,unchecked-hash}] [-o OPT_LEVELS] [-e DIR] [--hardlink-dupes] [FILE|DIR ...] compileall.py: error: argument -l: ignored explicit argument '8' This is because my .rpmmacros contains %_smp_mflags %( \ [ -z "$RPM_BUILD_NCPUS" ] \\\ && RPM_BUILD_NCPUS="`/usr/bin/getconf _NPROCESSORS_ONLN`"; \\\ if [ "$RPM_BUILD_NCPUS" -gt 16 ]; then \\\ echo "-l16"; \\\ elif [ "$RPM_BUILD_NCPUS" -gt 3 ]; then \\\ echo "-l$RPM_BUILD_NCPUS"; \\\ else \\\ echo "-l3"; \\\ fi ) that effectively sets %_smp_mflags to -l8 on my system. I use that because that is valid option to makefile and it is much better than -j option. This worked for ages even with various macros. But recently brp-python-bytecompile broke that. Version-Release number of selected component (if applicable): python-srpm-macros-3.11-9.fc38.noarch
I'm not sure it's reasonable to expect that any arbitrary flag can be placed into %_smp_mflags. To allow that would place an extremely high burden on anything which wishes to consume that macro. It would be nice for it to get a bit of documentation somewhere, though.
When we added %_smp_mflags here, Petr asked the question: https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/154#comment-124613 > I couldn't find docs for %_smp_mflags. How much of a guarantee is there that it contains no other flags than -j? My answer was: > %_smp_mflags is documented in https://rpm-packaging-guide.github.io/ and used in many other RPM macros in Fedora and upstream everywhere. There is no official guarantee that it will never contain anything else, but if it does, I assume multiple things would burn. I am willing to take that risk. -------------- I see this has now come to that. Since compileall.py does not support -l, I will replace %{_smp_mflags} with -j%{_smp_build_ncpus}. However, %{_smp_mflags} is also used in various pythonX.Y.spec files as well. I don't think you build Python often, so I will keep it there. I agree with Tibbs that the "allowed" flags of %{_smp_mflags} must be documented somewhere.
Mirek, would you be able to review and test the fix? The CI should provide you a scratch build shortly. https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/159 https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/160
I do also see an argument for renaming %_smp_mflags to %_smp_make_flags or something like that (with an appropriate number of underscores). This would reinforce what is mildly implied by the "m" in "mflags" that these are flags for make and not really anything else. Then have other things cook up their own set of flags that can be overridden individually if that's needed. It would also free us to actually transition from using '-j' to '-l' as a make argument if that actually makes more sense. I should probably raise this with RPM upstream. The build constraint stuff and anything else that would mess with this is I believe using %_smp_build_ncpus under the hood to actually set the CPU count, so that should always be the safe way to get at this.
I should also add that overriding %_smp_mflags as is done in the original comment will mess with anything that modifies %_smp_build_ncpus internally (like the %constrain_build macro) which is the recommended way to limit build parallelism according to RPM upstream. I know that's rare, but you should not expect that the method you employ can be considered to be generally acceptable.
The fix works for me. Thank you.
FEDORA-2023-8296eb197d has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-8296eb197d
FEDORA-2023-de50d15670 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-de50d15670
FEDORA-2023-8296eb197d has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-de50d15670 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-de50d15670 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-de50d15670 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.