Re: Help requested: Packages which FTBFS randomly
On 02/20/2017 11:05 AM, Jonathan Dowland wrote:
> On Mon, Feb 20, 2017 at 01:57:52AM +0100, Adam Borowski wrote:
>> * single-CPU machines have gone the way of the dodo. Even the crummiest
>> machine I could find while dumpster-diving looking for a non-sse3 one
>> already has HT and builds your examples successfully. Same for ARM SoCs
>> -- my RPi1 is kaputt, and anything newer has multiple cores. This, I'd
>> say it's a waste of time to care about _building_ on single CPU.
>
> /me looks lovingly at the PowerPC G4 Mac Mini propping up his display. I
> wonder if I should consider registering as a porter...
>
> How uncommon are single CPU virtual machines? Or containers with resource
> constraints to one CPU or something similar? I think that is at least as
> relevant as the availability of (new) uniprocessor hardware.
>
> None of the FTBFS problems I've seen in this thread have been because the
> tests *required* multiple cores, by the way; more so that they were racy
> or buggy in some other fashion. If uniprocessor buildds are finding these
> bugs then that's a virtue, IMHO.
Also, who's to say that tests failing on uniprocessor machines are buggy?
Maybe the tests are fine and they're exposing a bug in the actual
software or library that might fail in the same way if the circumstances
are just right?
If a failure happens on uniprocessor machines, who's not to say they don't
also happen on multicore machines that are under heavy load? For the same
code to fail on uniprocessor machines but succeed on multicore I would
expect there to be some kind of race condition that is triggered if
program execution is serialized to a single processor. But that could also
happen on multicore if that's under heavy load. Who's not to say that a
bug like this could not also be triggered on a new hardware, because a
new CPU generation behaves slightly differently?
I do believe that packages that FTBFS consistently on unprocessor
machines should be considered RC-buggy. We can argue about whether the
corresponding bugs should be marked as stretch-ignore, but I don't
believe that this something we want to have in the long term.
Regards,
Christian
Reply to: