Bug#961563: crash: Build failure due to parallel execution
On 2020-05-26 17:10 +0300, Adrian Bunk wrote: > Control: severity -1 normal > Control: tags -1 - ftbfs > > On Tue, May 26, 2020 at 11:58:19AM +0900, Benjamin Poirier wrote: > > Source: crash > > Severity: serious > > Tags: upstream patch ftbfs > > Justification: fails to build from source (but built successfully in the > > past) > > > > Dear Maintainer, > > > > The crash package sometimes fails to build when dpkg-buildpackage is > > invoked with -j > 1: > > > > # dpkg-buildpackage -us -uc -j4 > >... > > You are not the first person to fall into this trap. > >-j, --jobs[=jobs|auto] > Number of jobs allowed to be run simultaneously, number > of jobs matching the number of online processors if auto > is specified (since dpkg 1.17.10), or unlimited number > if jobs is not specified, equivalent to the make(1) > option of the same name (since dpkg 1.14.7, long option > since dpkg 1.18.8). Will add itself to the MAKEFLAGS > environment variable, which should cause all subsequent > make invocations to inherit the option, thus forcing the > parallel setting on the packaging (and possibly the > upstream build system if that uses make) regardless of > their support for parallel builds, which might cause > build failures. > > -J is the correct dpkg-buildpackage option. Thanks for the tip. Indeed, specifying -J avoids the problem. > > > This is because crash's configure rewrites Makefile via a temporary file > > (Makefile.new) and it is now getting invoked multiple times in parallel. > > This is a problem upstream. > > Correct. > > > It can be avoided with the following change: > > --- a/debian/rules > > +++ b/debian/rules > > @@ -12,8 +12,7 @@ include /usr/share/dpkg/buildflags.mk > > dh $@ > > > > override_dh_auto_build: > > - dh_auto_build > > - $(MAKE) extensions lzo snappy > > + dh_auto_build -- all extensions lzo snappy > >... > > This would fix only the "dpkg-buildpackage -j1" case, Since the crash package has debian/compat level 9, dh always invokes make with -j1. So that patch avoided problems from dpkg-buildpackage invocations with -j > 1. > "dh $@ --parallel" would still fail due to > make -j4 all extensions lzo snappy > Yeah... but I wasn't suggesting adding "--parallel". Actually, the intention of the patch I suggested was not to enable parallel building; it was to prevent it (since it's not supported upstream). > > The correct workaround to enable parallel building is: > > %: > dh $@ --parallel > > override_dh_auto_build: > $(MAKE) > $(MAKE) extensions > $(MAKE) lzo > $(MAKE) snappy True, but it doesn't bring any benefit I think because of crash's Makefile: debian/rules build dh build --parallel dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) dh_update_autotools_config -O--parallel dh_auto_configure -O--parallel dh_auto_configure: warning: Compatibility levels before 10 are deprecated (level 9 in use) debian/rules override_dh_auto_build make[1]: Entering directory '/root/crash-7.2.8' /usr/bin/make make[2]: Entering directory '/root/crash-7.2.8' TARGET: X86_64 CRASH: 7.2.8 GDB: 7.6 make[3]: Entering directory '/root/crash-7.2.8' make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. Anyways, if pressed, I would agree that the initially reported failure is due to a user error with regards to -j vs. -J. Please feel free to close this bug.
Bug#961563: crash: Build failure due to parallel execution
Control: severity -1 normal Control: tags -1 - ftbfs On Tue, May 26, 2020 at 11:58:19AM +0900, Benjamin Poirier wrote: > Source: crash > Severity: serious > Tags: upstream patch ftbfs > Justification: fails to build from source (but built successfully in the past) > > Dear Maintainer, > > The crash package sometimes fails to build when dpkg-buildpackage is > invoked with -j > 1: > > # dpkg-buildpackage -us -uc -j4 >... You are not the first person to fall into this trap. -j, --jobs[=jobs|auto] Number of jobs allowed to be run simultaneously, number of jobs matching the number of online processors if auto is specified (since dpkg 1.17.10), or unlimited number if jobs is not specified, equivalent to the make(1) option of the same name (since dpkg 1.14.7, long option since dpkg 1.18.8). Will add itself to the MAKEFLAGS environment variable, which should cause all subsequent make invocations to inherit the option, thus forcing the parallel setting on the packaging (and possibly the upstream build system if that uses make) regardless of their support for parallel builds, which might cause build failures. -J is the correct dpkg-buildpackage option. > This is because crash's configure rewrites Makefile via a temporary file > (Makefile.new) and it is now getting invoked multiple times in parallel. > This is a problem upstream. Correct. > It can be avoided with the following change: > --- a/debian/rules > +++ b/debian/rules > @@ -12,8 +12,7 @@ include /usr/share/dpkg/buildflags.mk > dh $@ > > override_dh_auto_build: > - dh_auto_build > - $(MAKE) extensions lzo snappy > + dh_auto_build -- all extensions lzo snappy >... This would fix only the "dpkg-buildpackage -j1" case, "dh $@ --parallel" would still fail due to make -j4 all extensions lzo snappy The correct workaround to enable parallel building is: %: dh $@ --parallel override_dh_auto_build: $(MAKE) $(MAKE) extensions $(MAKE) lzo $(MAKE) snappy cu Adrian
Bug#961563: crash: Build failure due to parallel execution
Source: crash Severity: serious Tags: upstream patch ftbfs Justification: fails to build from source (but built successfully in the past) Dear Maintainer, The crash package sometimes fails to build when dpkg-buildpackage is invoked with -j > 1: # dpkg-buildpackage -us -uc -j4 [...] /usr/bin/make extensions lzo snappy make[2]: Entering directory '/tmp/x/crash-7.2.8' mv: cannot stat 'Makefile.new': No such file or directory Makefile: cannot create new Makefile please copy Makefile.new to Makefile make[2]: *** [Makefile:324: lzo] Error 1 make[2]: *** Waiting for unfinished jobs mv: cannot stat 'Makefile.new': No such file or directory Makefile: cannot create new Makefile please copy Makefile.new to Makefile make[2]: *** [Makefile:328: snappy] Error 1 make[3]: Entering directory '/tmp/x/crash-7.2.8' make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. gcc -Wall -g -shared -rdynamic -o echo.so echo.c -fPIC -DX86_64 -DGDB_7_6 eppic.so: failed to pull eppic code from git repo gcc -Wall -g -shared -rdynamic -o trace.so trace.c -fPIC -DX86_64 -DGDB_7_6 gcc -Wall -g -shared -rdynamic -o dminfo.so dminfo.c -fPIC -DX86_64 -DGDB_7_6 gcc -Wall -g -I. -shared -rdynamic -o snap.so snap.c -fPIC -DX86_64 -DGDB_7_6 make[3]: Leaving directory '/tmp/x/crash-7.2.8' make[2]: Leaving directory '/tmp/x/crash-7.2.8' make[1]: *** [debian/rules:16: override_dh_auto_build] Error 2 make[1]: Leaving directory '/tmp/x/crash-7.2.8' make: *** [debian/rules:12: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 This is because crash's configure rewrites Makefile via a temporary file (Makefile.new) and it is now getting invoked multiple times in parallel. This is a problem upstream. It can be avoided with the following change: --- a/debian/rules +++ b/debian/rules @@ -12,8 +12,7 @@ include /usr/share/dpkg/buildflags.mk dh $@ override_dh_auto_build: - dh_auto_build - $(MAKE) extensions lzo snappy + dh_auto_build -- all extensions lzo snappy override_dh_auto_clean: cp $(CURDIR)/Makefile $(CURDIR)/debian/Makefile.ori -- Because the package uses debian/compat level 9, dh forces -j1.
