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

[Chris Lamb]

Hi, please do not CC me in further replies. Many thanks.  -lamby

On Wed, 18 May 2016, at 07:50 PM, Santiago Vila wrote:
> 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.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby at debian.org / chris-lamb.co.uk
       `-