Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Santiago Vila]

On Wed, May 18, 2016 at 06:58:49PM +0200, Markus Koschany wrote:

> [...]
> 
> To put it simply: There are countless circumstances under which programs
> can FTBFS. There is a standard way to determine when a FTBFS is release
> critical and when it is not. If it builds fine on our buildd network it
> should be a strong indication against raising the severity to RC.

Well, I don't see that such standard is being applied as a general rule.

Just take a look at the countless FTBFS bugs filed by reproducible
builds people. They are almost always serious, but many of them fail
to meet the condition that the FTBFS has to happen in the official
buildds.

Example 1: A package which fails to build under a given locale.
Official autobuilders have LANG=C, but failing to build from source
when LANG=fr_FR is also considered serious.

Example 2: A package fails to build in a strange timezone. Official
autobuilders have TZ=UTC, but failing to build from source when TZ is
different is also considered serious.

[ I'm Cc:ing Chris Lamb here in case he wants to share with us
  his criteria for deciding severities for FTBFS ]

So, your standard is clearly different from the usual standard I see
applied everywhere, which is why I wonder where your standard comes
from, as it does not follow the current practice I see.

The build-depends/build-conficts were created to ensure that packages
always built the same, not just in the official buildds, but really in
any system which meets the build-depends.

We want everybody to be able to build packages and have the same result,
not just in the official buildds.

In this case, nowhere in policy or in developers-reference it's stated
that the chroot must be "clean" for the build to succeeed.

The only condition for the build to succeed is that build-depends
and build-conflicts are met.

> Contrary to your belief not every FTBFS is RC. For instance not every
> Java or Python package can be built on every release architecture. I
> certainly would like to see this fixed but I don't consider it to be
> release critical at the moment because nobody intends to do the required
> porting work.

It is only RC if it built successfully in the past in those archs.

Can you think of a better example? This one is not controversial at all.

> The issue here at hand is that you don't use a _clean_ chroot like the
> ones produced by either pbuilder, cowbuilder or sbuild. In my chroot
> only automake1.11 gets installed.

So I must ask: Where did you get the idea that chroots have to be clean?

They have not, otherwise we would not have invented build-conflicts.

> And no, I wouldn't tell someone to install a missing build-dependency
> because then the build would fail in a clean chroot environment too
> which would be a serious issue.

Glad to know.

But then, why did you suggest that I remove automake from my chroot?
You did it with "...". It was irony? It was sarcasm?

Were you seriously suggesting that the problem was in my chroot?

Thanks.