Bug#1082135: sumo: FTBFS randomly due to dh_installdocs misbehavior (?)

[Niels Thykier]

Control: reassign -1 sumo

Santiago Vila:

owner 1082135 !
severity 1082135 serious
thanks

Hello. After I recently switched to 4th generation EPYC processors
from AMD for archive rebuilds, this package now fails to build
always in bookworm, using machines with 2 CPUs:

[...]

>

I honestly do not consider this suitable for release.


at the top of debian/rules (the package never failed to build for me
on machines with a single CPU).



(Cc to the last uploader and the usual uploader in the control file).

Thanks.

So, unless anybody has a better idea, I'll add --no-parallel to dh invocation Before doing so, I still would like some input from debhelper and doxygen maintainers (and of course other members of Debian Science).

In my view, the underlying problem is that the sumo build ends up running:

 `... && doxygen ... &> file.log`





Best regards,
Niels

Under `bash`, this causes a redirect of stderr + stdout. Under `dash` (`/bin/sh` on Debian systems), this only redirects stdout *AND* backgrounds the process. As a basic premise of all `debhelper` tools is that no other process is running in parallel that can affect the outcome (such as changing files in directories being operated on by said dh-tool). With `doxygen` potentially running in the background while `dh_installdocs` is running, I am writing this off as a bug in `sumo` until someone can reliably reproduce this happens for `sumo` without `doxygen` (or any sumo build tool) running in parallel that *could* affect what `dh_installdocs` should be operating on.

OpenPGP_signature.asc
Description: OpenPGP digital signature