Bug#895540: nx-libs: FTBFS with parallel > 1 due to errors cleaning
On 25 Apr 2018, at 17:16, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
>
> Control: reopen -1
>
> Hi James, hi Adrian, hi Niels,
> (also Cc:ed: Mihai Moldovan, upstream nx-libs)
>
> On Do 12 Apr 2018 13:02:45 CEST, James Clarke wrote:
>
>> Source: nx-libs
>> Version: 3.5.99.16-1
>> Severity: serious
>>
>> Hi,
>> Currently, nx-libs FTBFS (likely only probabilistically) when built with
>> parallel > 1; this occurred on the ia64 buildd lenz[1], but I have
>> reproduced it locally in an amd64 cowbuilder chroot.
>>
>> Please either fix the Makefile dependency issues, or disable parallel
>> cleaning.
>>
>> Regards,
>> James
>>
>> [1] https://buildd.debian.org/status/fetch.php?pkg=nx-libs&arch=ia64&ver=2%3A3.5.99.16-1%2Bb1&stamp=1523508333&raw=0
>
> I spent two days with this after my possible fix (running make clean with -j1 did not fix the problem).
>
> One reason for the persistance of the bug is: the build does not fail in clean anymore, but in the build target instead. For the same reason.
>
> The "cause" of the underlying problem is the fix for debhelper bug #894573 (building with -Oline make option). Or at least, if I drop -Oline from the make build calls, the package builds ok.
>
> Unfortunately, there is not much history on the reasoning behind adding -Oline to DH's make build call. Can any of you provide some background information?
>
> And: I am aware of the real underlying cause might possibly being a dependency flaw in nx-libs's highly complicated Makefile target stack. However, I spent two days now cleaning that up but to no avail.
>
> I'd be happy to get some clue from any of you. I also Cc: one of our other upstream devs to follow our discussion here. If any of you dislikes being Cc:ed directly in this thread, please let me know.
All -Oline does is ensure that the output from the parallel commands doesn't
get mixed up:
-O[type], --output-sync[=type]
When running multiple jobs in parallel with -j, ensure the output
of each job is collected together rather than interspersed with
output from other jobs. If type is not specified or is target the
output from the entire recipe for each target is grouped together.
If type is line the output from each command line within a recipe
is grouped together. If type is recurse output from an entire
recursive make is grouped together. If type is none output
synchronization is disabled.
It should therefore be merely a cosmetic change so reading the build logs is
easier. However, this will of course slightly affect timings, and potentially
briefly block make processes from running whilst their output buffer is full,
so if you do have missing dependencies, the change in timing could be enough to
reveal the bug; the fact that it used to work is merely a coincidence, and
there's no guarantee it would have continued to do so on different systems.
Regards,
James
Reply to: