[buildd-tools-devel] Bug#836940: Bug#836940: cowbuilder, sbuild: should behave identically in regard to default gnupg installation

[Markus Koschany]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20160907/c94a775d/attachment.sig>