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

[Santiago Vila]

On Wed, May 18, 2016 at 08:12:52PM +0200, Markus Koschany wrote:
> Am 18.05.2016 um 19:35 schrieb Santiago Vila:
> > 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.
> 
> Every RC bug filed by the reproducible build folks is always
> reproducible in a clean chroot. I have seen many of those reports. I
> have fixed many of them.

A clean chroot, but a "not clean environment", so to speak.

My point is that adding extra packages is just another way to make the
environment "not clean".

Our build system should be ready for any sort of "not cleanliness",
not only the ones that result from defining environment variables.

> > 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.
> 
> No. These two examples are reproducible build issues but are not RC.

Ok, let's provide bug numbers.

FTBFS under some locales:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795731
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808454

Both are "Severity: serious" because they are FTBFS.

FTBFS under some timezones:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795690

Also "Severity: serious" because it's FTBFS.

> [...]
> > We want everybody to be able to build packages and have the same result,
> > not just in the official buildds.
> 
> No. We are talking about sensible defaults. For the majority of people
> this bug is a non-issue.

I build a lot of packages. debhelper is used by a lot of packages.
Since I don't want to waste disk I/O, I have debhelper in my chroot
installed by default. This makes automake to be installed by default.

I would say this is a more than sensible default for anybody who build
a lot of packages.

> [...]
> > They have not, otherwise we would not have invented build-conflicts.
> 
> Build-Conflicts is not a Policy requirement. We talked about that before.

Yes, and I said that your interpretation of policy in this paragraph
is extremely narrow.

Of course it is not a policy requirement. If your package does not
need any build-depends or build-conflicts, why would you add one?

Let me quote it again, with emphasis on two other words:

  Source packages that *require* certain binary packages to be installed
  or *absent* at the time of building the package can declare
  relationships to those binary packages.

I think we can agree that the package being discussed *requires*
automake to be absent.

How does a *requirement* (that automake is absent) suddenly becomes optional?

Please don't say that policy says "can". This just means that you can
use those fields if your package needs them.

Once that it's known that the package needs them (either build-depends
or build-conflicts), they are *required*, not optional.

Thanks.