Bug#848859: FTBFS randomly (failing tests)

[Ole Streicher]

On 05.01.2017 11:36, Santiago Vila wrote:
> On Thu, Jan 05, 2017 at 11:06:50AM +0100, Ole Streicher wrote:
>> Hi all,
>>
>> On 04.01.2017 20:57, Santiago Vila wrote:
>>> I still want to build all packages and have 0 or 1 failures,
>>> so in this case the probability should be 1/50/2, i.e. 1%.
>>>
>>> I think this is still feasible.
>>
>> My experience is that the buildds that are currently in use provide more
>> build problems than the packages themself. BTW, why don't you count this
>> as RC?
> 
> Can you clarify the question? I don't understand what you refer exactly.

It does not make sense to have 100% reliability on the package itself to
build but only 95% on the buildds. If we want to have reliability, then
every chain member counts -- and the weakest one in the moment for me
does not seem to be the packages themselves, but the buildd setups we
currently have. So, if you consider unreliable package builds as an RC
problem, you should also consider the unreliable buildd setup as an RC
problem.

>>> But as far as there are people in this project who consider that a
>>> package which FTBFS on single-CPU machines more than 50% of the time
>>> is ok "because it does not usually fail in buildd.debian.org",
>>> we are doomed.
>>
>> We have 10 archs, and with a 50% chance of failure you will not get any
>> version built. Even when the buildds try it two or three times.
> 
> It's actually more subtle than that.
> 
> The package may be ready to be built on multi-core machines, but not on
> single-core machines. So, the probability that I measure (greater than 50%),
> might not be the same as the probability on official autobuilders.

Ususally it is the other way around: packages build fine
single-threaded, but don't do so on many threads (or CPUs). At the end
it it also depends on how many CPUs you actually get for the build -- if
there are some packages built in parallel, the result may be as for a
single CPU.

> Then there is the other subtle thing: The package may be Arch:all, in
> which case a 50% of probability (this time independent on the number
> of CPUs) may go unnoticed very easily, either because the maintainer
> uploaded the .deb him/herself, or, if the maintainer uploaded
> in source-only form, we can just be lucky for that time.

I would favour much to ignore any prebuilt binaries and to re-build
everything anyway.

> We provide software which is free to be modified. If people is going
> to modify it and then it fails because the package only builds ok in
> buildd.debian.org, then we are removing one of the essential freedoms,
> the freedom to modify it, and the package becomes de-facto non-free,
> even if we still distribute it in main.

First, the multi-CPU buildd setup is free (as in speech), isn't it? So,
depending on this does not make anything non-free. I don't see why the
dependency on a specific build environment would change the DFSG
freeness at all (as long as the build environment itself is DFSG free).

Then, we are speaking about random failures. If you use a single-core
and see a build failure, you can just pragmatically repeat it.

Sorry, I don't see why this would restrict DFSG freedom here.

Best regards

Ole