Description of problem: Using the %constrain_build macro now produces a Lua error in Rawhide/F39. Version-Release number of selected component (if applicable): 254-1.fc39 How reproducible: Steps to Reproduce: 1. fedpkg co python-pandas 2. cd python-pandas 3. fedpkg mockbuild Actual results: Start: build phase for python-pandas-1.5.3-4.fc39.src.rpm Start: build setup for python-pandas-1.5.3-4.fc39.src.rpm error: lua script failed: attempt to compare nil with number 1< (%lua) 0< (%constrain_build) Expected results: A successful build begins. Additional info: Other packages that demonstrate the problem are: - libinstpatch - python-graph-tool The python-graph-tool package uses a memory constraint instead of a CPU one (“%constrain_build -m 15360”), but the failure is the same.
There's also perhaps a competing native functionality in RPM 4.19 now. https://github.com/rpm-software-management/rpm/issues/804
For now, I am thinking of replacing %constrain_build -c 1 with %global _smp_build_ncpus 1 in python-pandas and libinstpatch. (What these two packages really need is serial builds.) I will leave python-graph-tool as a reproducer for now. It looks like the only other user of this macro is firefox.
FEDORA-2023-a5593695bb has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a5593695bb
FEDORA-2023-a5593695bb has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
Ugh; I mentioned the bug in a libinstpatch update, but I did not think I used one of the magic words to close it. Reopening.
(In reply to Miro Hrončok from comment #1) > There's also perhaps a competing native functionality in RPM 4.19 now. > https://github.com/rpm-software-management/rpm/issues/804 Yes, %constrain_build is supposed to be redundant in rpm >= 4.19. But breakage is unexpected, I'll have a look. (In reply to Ben Beasley from comment #2) > For now, I am thinking of replacing > > %constrain_build -c 1 > > with > > %global _smp_build_ncpus 1 > > in python-pandas and libinstpatch. (What these two packages really need is > serial builds.) Yes, for the serial build case %constrain_build is killing a fly with a shotgun. But _smp_build_ncpus is a non-trivial macro and overriding it can break other things in turn, please use this instead (backwards compatible for the last 10+ years): %global _smp_ncpus_max 1
Right, the problem is %_smp_build_ncpus changing into a parametric macro in 4.19 in combination with %constrain_build using the newish Lua macros table, which treats parametric macros specially: Rpm 4.18: > $ rpm --eval "%{_smp_build_ncpus}" > 8 > $ rpm --eval "%{lua:print(macros._smp_build_ncpus)}" > 8 Rpm 4.19: > <mock-chroot> sh-5.2# rpm --eval "%{_smp_build_ncpus}" > 8 > <mock-chroot> sh-5.2# rpm --eval "%{lua:print(macros._smp_build_ncpus)}" > function: 0x559916d63610 It's possible this all needs another layer of indirection to fix, ie to avoid changing %_smp_build_ncpus to a parametric macro.
Should be fixed in rpm-4.18.90-9.fc39, if not then do make noises.
(In reply to Panu Matilainen from comment #6) > […] please use this instead (backwards compatible > for the last 10+ years): > > %global _smp_ncpus_max 1 Thank you; I will. (In reply to Panu Matilainen from comment #8) > Should be fixed in rpm-4.18.90-9.fc39, if not then do make noises. Works for me; thanks for the quick fix.
FEDORA-EPEL-2024-4019d184db (libinstpatch-1.1.6-29.el10_0) has been submitted as an update to Fedora EPEL 10.0. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-4019d184db
FEDORA-EPEL-2024-4019d184db (libinstpatch-1.1.6-29.el10_0) has been pushed to the Fedora EPEL 10.0 stable repository. If problem still persists, please make note of it in this bug report.