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.
> 
> So, unless anybody has a better idea, I'll add --no-parallel to dh 
> invocation
> at the top of debian/rules (the package never failed to build for me
> on machines with a single CPU).
> 
> Before doing so, I still would like some input from debhelper and 
> doxygen maintainers (and of course other members of Debian Science).
> 
> (Cc to the last uploader and the usual uploader in the control file).
> 
> Thanks.
> 

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

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

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.

Best regards,
Niels


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20241028/673eb9af/attachment.sig>