Bug#848859: FTBFS randomly (failing tests)

[Santiago Vila]

> >> 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.

Ok, I now understand the question, but now I don't understand the
purpose of the question :-)

First of all, I don't see that the buildds are unreliable, or at least
I don't see that they fail randomly 5% of the time.

But in either case, if they were so unreliable, nothing prevents
building the same set of packages in another autobuilder farm not
being the official one.

This is precisely what is done in reproducible builds, what Lucas Nussbaum does,
and what I do as well (in a much smaller scale).

Because we mainly care about the quality of the packages themselves,
which is what we ship to our users, not about the quality of the
official autobuilders, which we don't ship to our users.

In other words, it may be interesting to consider the whole chain
that you mention, but I'm only interested in the packages themselves.

> > 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.

The single-core / multi-core issue was just an example of possible
reason why package might build fine in buildd.debian.org and not in my
autobuilders (or the opposite).

But it was just an example. The real problem is when it fails to build
in every autobuilder but buildd.debian.org and people still say
"it builds fine on buildd.debian.org so it's not RC" but *without*
giving the reason why it fails in every other autobuilder.

So this is like having a "build-depends: buildd.debian.org".
Maintainer does not investigate enough and basically says that all
the other autobuilders are wrong "for not being buildd.debian.org".

This is what IMO makes the package non-free, the need to build the package
in some of the official autobuilders for *unknown* reasons.

Thanks.