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&arch=all&ver=2.1-1&stamp=1454340725
signature.asc
Description: OpenPGP digital signature