On 07.09.2016 16:40, gregor herrmann wrote:
> On Wed, 07 Sep 2016 16:05:24 +0200, Johannes Schauer wrote:
>
>>> The package xmlgraphics-commons started recently failing to build from
>>> source in a clean sbuild environment although it was built successfully
>>> on the buildd network a few months ago. This behavior cannot be observed
>>> in a clean cowbuilder environment though. [1]
>
>>> 3. or if cowbuilder should not install gnupg by default
>> I think it should not because I think that source packages should be compiled
>> in an environment that is as minimal as possible for the reasons given above.
>> But of course this is up to the cowbuilder maintainers.
>
> FWIW, I don't have a /usr/bin/gpg in my {amd64,i386} {stretch,sid}
> cowbuilder chroots. But they are present in older ones.
>
> I suspect I don't have them anymore because I clean my chroots (with
> debfoster), and others might still have gnupg installed because it
> was originally installed but never removed.
>
> (I haven't tried, but I guess creating a new cowbuilder chroot won't
> have gnupg either.) Hi, I have just created a new cowbuilder base chroot with sudo DIST=sid ARCH=amd64 cowbuilder --create and this command still installs gnupg. I don't know what I'm currently missing but this is the issue that I would like to get resolved with this bug report. In my opinion cowbuilder and sbuild should always install only the minimum build requirements by default which are demanded by Policy and the tools should behave identically. That means no matter which tool I use the same package should build or fail in both chroots. Quoting Johannes Schauer > indeed, there already is a definition of the "common build environment > standard" and that definition is given by the relationships between packages > in > the archive and the implicit dependencies on Essential:yes and > build-essential, > just as given in the section of Debian policy that you described. > > I would be interested to hear what Markus means by defining a "common build > environment standard" because then I'd like to present reasons why our current > standard (Essential:yes plus build-essential plus Build-Depends minus > Build-Conflicts) is an excellent way to define the set. I was talking about the build environment tools like cowbuilder, pbuilder and sbuild which are actually used in practice for building packages in a commonly called "clean" environment. By using the word "clean" I refer to the same properties that you have described as installing Essential: yes and build-essential packages. Everything else is just the defined build-dependencies in debian/control. I completely agree with that. My point is that I have come across a lot of bug reports in the past that either claim the build failed in a clean cowbuilder or sbuild environment or both. Now we all agree that a package that fails to build on the official buildd network is RC buggy. But what about packages that neither fail there nor locally in a clean cowbuilder environment but under some obscure circumstances in a local sbuild environment? Is this automatically release critical because the package FTBFS or do we accept that not every FTBFS is automatically RC and that there might be corner cases, so rare that they should not be deemed "serious", "grave" or "critical" but just to be normal issues? #834682 [1] is an example of such a dilemma. For me this package builds fine in cowbuilder and sbuild but it fails for Santiago. Since I can't reproduce the issue I have downgraded the severity and marked the bug as "unreproducible". Now I don't want to allege that this bug is some kind of imagination but I'm responsible as the maintainer to determine the severity of a bug report. Just ignoring the bug report and waiting for the autoremoval can't really be a solution. I personally find it rude and disrespectful if Santiago immediately raises the severity again and claims that each and every one of his local FTBFS bugs is always RC. Thus I have used the phrase "common build environment standard" because we need _tools_ that implement the Policy, are reliable and deliver a reproducible and verifiable output. I would rather like to see that we require only one tool for building packages before we upload them "source-only" into the archive which would certainly bring synergy effects. Then we all would have less to worry about FTBFS bug reports in the future. And regarding #834744 [2] I have never disputed that this is a bug in xmlgraphics-commons despite the fact that the package builds fine in a clean cowbuilder environment. My point is that we should be more careful when we assign severities to bug reports because there might be other solutions like the ones I have mentioned in my initial bug report. Now we know that this behavioral change was intended and there is actually some kind of bug in cowbuilder that "tricked" us into believing gnupg was part of a default clean environment. Adding gnupg to Build-Depends was never the issue in the first place. Regards, Markus [1] https://bugs.debian.org/834682 [2] https://bugs.debian.org/834744
signature.asc
Description: OpenPGP digital signature
