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 `. `'` la...@debian.org / chris-lamb.co.uk `-