Hi Santiago,
On 11/29/25 13:46, Santiago Vila wrote:
Sorry for the reopening, but I believe this is not fixed yet.
no worries, thanks for re-testing it.
This package used to FTBFS in my setup, on machines with 2 CPUs,
approximately 10% the time.
this seems to be a really weird issue, I could never reproduce this on
neither my notebook nor my desktop where I did all my ck uploads ever since.
The autobuilder hang happens in a way
that it has to be killed by hand. Not even sbuild's built-in
timeout mechanism works.
which is important to fix (just to emphasis that). however, I'm a bit
lost on the "real-world" impact.
let's focus on amd64 for now since that's where you noticed the problem.
On the buildds, the package always built fine in the first attempt. Is
this problem a more 'make packages better by testing different things'
case (I remember the "doesn't build with cpu=1 MBF" some years ago), or
is it actually breaking something?
I'm not trying to argue the problem away, just trying to understand the
impact. If it's a "doesn't build reliably under non-default conditions",
maybe we could just skip the testsuite if nproc < 4 or so..
The previous version used to build
flawlessly on machines with 1 CPU, but now this is what happens
when I try the same:
wow, if I summarize correctly:
* 0.7.2-6 on cpu=1 sets automatically tests=1, works better than -7
* 0.7.2-7 on cpu=1 sets statically test=1, works worse than -6
Since the test=1 handling is in d/rules rather than upstream, I can't
see any logic behind this behaviour.
the package always fails on machines with 1 CPU. I would say that version -6
was better.
I've uploaded -8 yesterday which is identical to -6.
Regards,
Daniel
