Bug#834744: xmlgraphics-commons: FTBFS (missing build-depends on gnupg)

[Santiago Vila]

On Wed, Sep 07, 2016 at 02:05:45PM +0200, Markus Koschany wrote:
> I have just filed
> 
> http://bugs.debian.org/836940
> 
> against cowbuilder and sbuild and asked both maintainers for a
> clarification. Apparently apt moved the dependency on gnupg from Depends
> to Recommends in version 1.3~exp1 and together with the recent gnupg2
> transition, this caused a behavioral change in sbuild.

IMHO, the bug is a waste of time, and I can easily imagine what sbuild
maintainer will probably tell you: If it's not required to have gnupg
inside the chroot, then there is no point in requiring it to be inside
the chroot.

> >   11) Drop requirement for gpg inside the chroot as external archive keys are
> >       now processed without gpg and signing of the internal repository is
> >       entirely optional with helpful warning and error messages in case
> >       signing failed.
> > 
> > 
> > Please note that this bug is not just "xmlgraphics-commons FTBFS".
> > 
> > This bug is "xmlgraphics-commons FTBFS if gnupg is not in chroot".
> 
> Actually this is not a specific issue in xmlgraphics-commons but affects
> all packages that relied on gnupg being installed by default.

There are not so many of them. These are the ones I remember:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834600
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834744
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835098

including this one. So "All packages" = 3 so far. This is after building
all 15000 source packages in stretch that generate "Arch: all" binary packages.

> This bug only surfaced three weeks ago. We could always rely on gnupg
> being installed by default.

No, actually you could not rely on gnupg being installed by default,
because gnupg was not essential and it was never was.

This bug was "hidden", so to speak, but it has always been a bug,
it's just now that we discovered it.

The "theory" has not changed: If you need a package during build, you
have to put it in build-depends. This is clearly written in policy.

If gnupg is installed by default and there is not a build-depends,
nobody will notice, but it's still a bug.

> This cannot be achieved by filing RC bugs against numerous affected
> packages.

Yes, it can, because they are RC bugs, they have always been, and
there are not so many packages affected.

I can count them with the fingers in my two hands, and I don't even
need to announce it as a mass bug filing.

> In my opinion this is inefficient and just increases the
> workload of contributors.

You are now worried by workload of contributors? How ironic.
My workload is increased every time I have to explain obvious
and well established things to people who ignore Debian Policy
regarding the set of build essential packages.

If you are really worried about workload of contributors, I suggest
you follow Debian Policy and raise this to serious, where it belongs.

> Debian Policy is not a document to force
> maintainers into implementing something, it rather reflects common best
> practices in this distribution.

I don't want to force anything. You don't have to fix this bug. Do
nothing and let the autoremoval procedure happen if you wish, but this
bug is serious because, as you say, that has been common best practice
for ages every time we have discovered a missing build-depends.

> By the way marking the bug as unreproducible just means that
> feedback from someone else is appreciated.

We already have "help" for that. When we know exactly and precisely
how to reproduce something (in this case, building without gnupg in
the chroot), we don't use unreproducible.

> > Before I take this to the Technical Committee, do you want to propose
> > a summary of the disagreement? This is not required but it's
> > recommended here in point 2:
> > 
> > https://www.debian.org/devel/tech-ctte
> > 
> > Thanks.
> 
> I suggest to wait until both cowbuilder and sbuild maintainers responded
> to #836940.

I suggest to raise the severity now, as I have already wasted too much
time explaining obvious things in this report, and don't like the idea
of wasting even more time.

Thanks.