On Mon, 30 Sep 2024 at 13:06:31 +0200, Santiago Vila wrote:
> - When I build with 1 CPU, I have never found the build problem so far.
> - When I build with 2 CPUs, I got a failure rate of 66%
> (16 failures over 24 tries so far).
When I tried this, it was consistently failing if and only if I use
the .dsc from the archive, and consistently succeeding with a rebuilt
.dsc. All of these builds have been in a VM with 3 VCPUs, on a host
system with 4 cores (SMT disabled, so 1 thread per core).
I don't know *why* rebuilding the .dsc avoids this failure mode, but it
appears that it does. This means that I can't usefully try workarounds
or add extra debugging instrumentation, because any time I do that, the
.dsc is rebuilt, the problem vanishes, and the debugging instrumentation
doesn't trigger.
In particular I tried modifying the failing target to add the obvious
debug info for why upstream's check was failing:
```diff
deutex-check:
+ $(DEUTEX) -h || echo exit status $$?
+ $(DEUTEX) -h | grep -w PNG || echo exit status $$?
@$(DEUTEX) -h | grep -qw PNG || { \
```
but that didn't exhibit the failure (deutex -h showed the expected output
and exited with status 0, deutex -h | grep -w PNG showed non-empty output
and exited with status 0, and upstream's check succeeded).
Are you able to send a modified .dsc (rebuilt with no changes, or with
only changelog changes) to your rebuild infrastructure? If yes, please
try with a rebuilt .dsc (with 2 or more CPUs, since that seems to be
your worst-case scenario for this particular package).
> I would try how it behaves when using --no-parallel.
It did build successfully with `dh $@ --no-parallel`, but that doesn't
necessarily mean anything, because adding that flag required rebuilding
the .dsc, and my experience has been that rebuilding the .dsc is itself
enough to work around this for some as yet unknown reason.
smcv
