On Fri, 17 Aug 2018 10:05:31 +0000 Damyan Ivanov <d...@debian.org> wrote: > Package: bmake > Version: 20160220-2+b1 > Severity: normal > Tags: patch > > Hi, > > While rebuilding some packages that were using bmake, I stumbled on a couple > failures, which were only triggered when `-j X` was passed to sbuild. Even > `-j > 1` caused failure. > > The failure looks like: > > dh_auto_test -O--buildsystem=bmake > bmake test VERBOSE=1 > bmake[1]: bmake[1]: don't know how to make test. Stop > > bmake[1]: stopped in /<<PKGBUILDDIR>> > dh_auto_test: bmake test VERBOSE=1 returned exit code 2 > > This seems to be caused by an oddity in bmake, which changes its output when > `-j` is used: > > An example is the udfclient package: > > Compare: > > $ bmake -s -n test 2>/dev/null > > bmake: stopped in /home/dam/w/tmp/udfclient-0.8.8 > $ > > with > > $ bmake -s -n -j 1 test 2>/dev/null > `test' was not built (made 3, flags 2049, type 2000000)! > $ > > The check in bmake.pm¹ uses the first line of STDOUT as an indicator whether > the given target exists and is fooled by the diagnostic output when -j is > used. > > ¹ https://sources.debian.org/src/bmake/20160220-2/debian/bmake.pm/#L32 > > Adding a call to clean_jobserver_flags() doesn't help, because that routine > only acts when a job server is used² (--jobserver-... present in $MAKEFLAGS) > > ² > https://sources.debian.org/src/debhelper/11.3.5/lib/Debian/Debhelper/Dh_Lib.pm/#L2166 > > My tests show that temporarily removing MAKEFLAGS from the environment in > bmake.pm/exists_make_target() works around the problem. > > A proper fix may be to direct the diagnostic output of bmake to STDERR, or to > add an empty line before it to make it similar to the non-`-j` case, but I > guess that's an upstream decision to make. > > > BTW, that bug report could have been accompanied by a merge request if the > packaging of bmake was available on salsa.debian.org :)
Thanks for your report. bmake is in fact at salsa: https://salsa.debian.org/salsa/bmake -- Cheers, Andrej
