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

[Lucas Nussbaum]

severity 834744 serious
thanks

On 07/09/16 at 14:17 +0100, Santiago Vila wrote:
> I suggest to raise the severity now

Yes.

Lucas

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 834744 serious
Bug #834744 [src:xmlgraphics-commons] xmlgraphics-commons: FTBFS (missing 
build-depends on gnupg)
Severity set to 'serious' from 'normal'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
834744: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834744
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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.

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Markus Koschany]

On 07.09.2016 13:06, Santiago Vila wrote:
> On Wed, 7 Sep 2016, Emmanuel Bourg wrote:
> 
>> I haven't been able to reproduce this issue either with a clean pbuilder
>> environment. For some reason gnupg was installed by default in the
>> environment, but maybe this changed recently?
> 
> I don't know if this changed recently with pbuilder, but recent
> versions of sbuild do not require gnupg to be present in the chroot.

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.

> 
> This is from the NEWS file:
> 
>  * Major changes in 0.70.0:
> 
>   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.


> If you or Markus insist on building xmlgraphics-commons with gnupg in
> the chroot, then it's not that you can't reproduce the bug, it's that
> you are not even *trying* to reproduce the bug.
> 
> By definition, to reproduce the bug you need a chroot not having
> gnupg installed. Successful builds with gnupg in the chroot do not
> give any information at all regarding the reproducibility or
> unreproducibility of this bug.
> 
> I think this was evident enough from my use of "missing build-depends"
> in the subject and the patch that I attached, so I'm really surprised
> (and disappointed) that I have to tell again what this bug is about.
> 
> I'm even more disappointed by the fact that this is a missing
> build-depends and it's downgraded to normal when we have considered
> missing build-depends as RC for *ages*.

This bug only surfaced three weeks ago. We could always rely on gnupg
being installed by default. Even the last official sbuild was
successful. [1] This kind of bug should be solved and clarified from
top-down starting with questioning if the apt change in 1.3~exp1 was
necessary and ensuring that our most important build tools behave
identically.

This cannot be achieved by filing RC bugs against numerous affected
packages. In my opinion this is inefficient and just increases the
workload of contributors. Debian Policy is not a document to force
maintainers into implementing something, it rather reflects common best
practices in this distribution. If gnupg was demonstrably always present
in a clean chroot environment, then we should also consider confirming
that and thinking about reverting this change in our tool chain which
would save many manhours and be much more effective.

We have an obvious contradiction at the moment when something has
changed which has always been true (gnupg being installed by default)
and where the most commonly used build tools cowbuild/pbuilder and
sbuild behave differently. This should be investigated with priority now
and in the light of these circumstances lowering the severity is
reasonable and completely up-to the maintainers. By the way marking the
bug as unreproducible just means that feedback from someone else is
appreciated.


> 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.

Regards,

Markus

[1]
https://buildd.debian.org/status/fetch.php?pkg=xmlgraphics-commons=all=2.1-1=1454340725



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Santiago Vila]

On Wed, 7 Sep 2016, Emmanuel Bourg wrote:

> I haven't been able to reproduce this issue either with a clean pbuilder
> environment. For some reason gnupg was installed by default in the
> environment, but maybe this changed recently?

I don't know if this changed recently with pbuilder, but recent
versions of sbuild do not require gnupg to be present in the chroot.

This is from the NEWS file:

 * Major changes in 0.70.0:

  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".

If you or Markus insist on building xmlgraphics-commons with gnupg in
the chroot, then it's not that you can't reproduce the bug, it's that
you are not even *trying* to reproduce the bug.

By definition, to reproduce the bug you need a chroot not having
gnupg installed. Successful builds with gnupg in the chroot do not
give any information at all regarding the reproducibility or
unreproducibility of this bug.

I think this was evident enough from my use of "missing build-depends"
in the subject and the patch that I attached, so I'm really surprised
(and disappointed) that I have to tell again what this bug is about.

I'm even more disappointed by the fact that this is a missing
build-depends and it's downgraded to normal when we have considered
missing build-depends as RC for *ages*.

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.

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Santiago Vila]

On Wed, Sep 07, 2016 at 04:47:15AM +0200, Markus Koschany wrote:

> I disagree with your bug severity. The build does not fail in a clean
> cowbuilder environment. I'm attaching my build log as proof.

The build log is just a proof that the build succeeded, but *not* a proof
that the environment was clean.

If you are unable to do it with pbuilder, please post a build log made
with sbuild using a chroot not containing gnupg.

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Santiago Vila]

On Wed, Sep 07, 2016 at 04:47:15AM +0200, Markus Koschany wrote:

> You should rather work towards defining a common build environment
> standard in Debian [...]

You must be joking. There is already a "common build environment standard",
and it's called the set of build essential packages, of which gnupg is not
(not the old gnupg, not the new gnupg, not the old gnupg2, and not the
new gnupg1).

Everything which is required to build and it's not in build essential
must go in build-depends.

What part of this standard (the build essential set of packages, the
one that really counts, not the list of packages in the package
builder of the day) is the one that you don't understand?

It's in Policy 4.2, here is a quote:

 If build-time dependencies are specified, it *must* be possible to
 build the package and produce working binaries on a system with
 *only* essential and build-essential packages installed and also
 those required to satisfy the build-time relationships (including
 any implied relationships).


This is what you are still not doing with your pbuilder example.

You say "unreproducible", I say unwillingess to reproduce.

This is a must directive in policy, and everybody agrees that missing
build-depends are RC. Do you still disagree that this is severity
serious?

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Emmanuel Bourg]

I haven't been able to reproduce this issue either with a clean pbuilder
environment. For some reason gnupg was installed by default in the
environment, but maybe this changed recently?

Emmanuel Bourg

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Markus Koschany]

Correct build log attached now.


xmlgraphics-commons_2.1-1_amd64.build.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Debian Bug Tracking System]

Processing control commands:

> severity -1 normal
Bug #834744 [src:xmlgraphics-commons] xmlgraphics-commons: FTBFS (missing 
build-depends on gnupg)
Severity set to 'normal' from 'serious'

-- 
834744: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834744
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Santiago Vila]

severity 834744 serious
tags 834744 - unreproducible
thanks

Sorry, but missing build-dependencies are RC, and they have always been.


On Mon, 22 Aug 2016, Markus Koschany wrote:

> This package builds fine in a clean cowbuilder chroot environment

No, it does not. If the chroot environment includes gnupg, then
it's *not* a clean chroot.

To reproduce, please build in a chroot *not* having gnupg installed.

If you can't do that with cowbuilder, try sbuild.

I attach a full build log.

Please attach also your build log made with sbuild in a chroot *not*
having gnupg installed, so that we can compare.

If you can't reproduce a bug you should ask the submitter for a way
to reproduce it, not silently downgrade the bug and mark it as
unreproducible without telling the submitter.

Moreover, the bug report clearly said "missing build-depends" (it is
in the subject and it's difficult to miss) and it even included a
patch. Are you really unable to reproduce it, or you just "don't want"
to reproduce it?

Thanks.

xmlgraphics-commons_2.1-1_amd64-20160818T113412Z.gz
Description: application/gzip
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Markus Koschany]

Control: tags -1 unreproducible
Control: severity -1 normal

On Thu, 18 Aug 2016 14:22:57 + Santiago Vila  wrote:
> Package: src:xmlgraphics-commons
> Version: 2.1-1
> Severity: serious
> Tags: patch
> 
> Dear maintainer:
> 
> I tried to build this package with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
[...]

This package builds fine in a clean cowbuilder chroot environment and on
Debian's official buildd network. The issue is unreproducible hence I'm
going to downgrade the severity to normal until someone else can confirm
that this is a release critical issue. So far I cannot confirm this.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Santiago Vila]

Package: src:xmlgraphics-commons
Version: 2.1-1
Severity: serious
Tags: patch

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
BUILD FAILED
/<>/build.xml:620: The following error occurred while executing 
this line:
/<>/build.xml:591: Execute failed: java.io.IOException: Cannot run 
program "gpg" (in directory "/<>"): error=2, No such file or 
directory


The gnupg package is not essential. Therefore, whenever a package
requires it for building there should be a build-dependency on it.

Trivial (but untested) patch below.

Thanks.

--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Build-Depends: debhelper (>= 9), javahelper
 Build-Depends-Indep: ant-optional,
  default-jdk,
  default-jdk-doc,
+ gnupg,
  junit4,
  libcommons-io-java (>= 1.3.1),
  libcommons-logging-java,

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.