Hello,

Having librsvg2-bin in the build-dependencies prevent the package to
build on some architecture (librsvg only builds on architecutres where
rust is ported to)

Could you please drop librsvg2-bin from the build-dependencies?

The BD was added in the following commit:

commit 90e4beaa8cb065d5964681b8b1dc72c84eeb5f9e
Author: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date:   Tue May 10 21:31:12 2016 -0400

    build gnupg-module-overview.png and ship it

    Upstream uses imagemagick for conversion of svg to png, and
    imagemagick itself appears to delegate to  rsvg-convert

But what I see is that the .png file is not rebuilt during the build of
the package and I don't know if imagemagick is still using rsvg-convert
anyway, so, is it really necessary to have that BD?

Without it, gnupg builds fine on kfreebsd

Kind regards,
Laurent Bigonville

On Tue, 07 Sep 2021 12:13:31 +0200 Laurent Bigonville <bigon@debian.org>  wrote:

 > Hello,
 >
 > Having librsvg2-bin in the build-dependencies prevent the package to
 > build on some architecture (librsvg only builds on architecutres where
 > rust is ported to)
 >
 > Could you please drop librsvg2-bin from the build-dependencies?
 >
 > The BD was added in the following commit:
 >
 > commit 90e4beaa8cb065d5964681b8b1dc72c84eeb5f9e
 > Author: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
 > Date: Tue May 10 21:31:12 2016 -0400
 >
 > build gnupg-module-overview.png and ship it
 >
 > Upstream uses imagemagick for conversion of svg to png, and
 > imagemagick itself appears to delegate to rsvg-convert
 >
 > But what I see is that the .png file is not rebuilt during the build of
 > the package and I don't know if imagemagick is still using rsvg-convert
 > anyway, so, is it really necessary to have that BD?
 >
 > Without it, gnupg builds fine on kfreebsd
 >

Hello,

Did you had anytime to look at it?

Kind regards,

Laurent Bigonville

Laurent Bigonville wrote...
(...)

Comparing the built packages before and after removing that build
dependency shows no differences, so it should be safe to drop it.

    Christoph

We believe that the bug you reported is fixed in the latest version of
gnupg2, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 993857@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christoph Biedl <debian.axhn@manchmal.in-ulm.de> (supplier of updated gnupg2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 18 Dec 2021 14:04:20 +0100
Source: gnupg2
Architecture: source
Version: 2.2.27-3
Distribution: unstable
Urgency: medium
Maintainer: Debian GnuPG Maintainers <pkg-gnupg-maint@lists.alioth.debian.org>
Changed-By: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>
Closes: 982546 993578 993857
Changes:
 gnupg2 (2.2.27-3) unstable; urgency=medium
 .
   * Avoid network interaction in generator. Closes: #993578
   * Remove build dependency on librsvg2-bin. Closes: #993857
   * Backport "Scd: Fix CCID driver for SCM SPR332/SPR532".
     Closes: #982546
   * Update watch file: Sticking to the 2.2 series for the time being
Checksums-Sha1:
 5a3dff314eb53507dfae1b309386b50e2fecb3ec 3630 gnupg2_2.2.27-3.dsc
 612f9e8e7f2fd3895ea60c58555d3748209300f7 63396 gnupg2_2.2.27-3.debian.tar.xz
 468f54819d9bf97e3567e50846ded157e2b8c8c3 18163 gnupg2_2.2.27-3_powerpc.buildinfo
Checksums-Sha256:
 c3fcf3c8f0aad05bb86f7bdcd67bdc9dd67cb35b0605778de3ee5b07ba621934 3630 gnupg2_2.2.27-3.dsc
 ef72e1094b7c47c9394d1d46bfda1ca46fbea53165f3e40fe169372f8fa3f62b 63396 gnupg2_2.2.27-3.debian.tar.xz
 6b7b6df55424c98439fa1965dfbfc98be225b8c13c9331b8eb3aa168e64fb60c 18163 gnupg2_2.2.27-3_powerpc.buildinfo
Files:
 71fba127d1241a8e6a455390e1612819 3630 utils optional gnupg2_2.2.27-3.dsc
 385950bb6b92782f8fc6f52c42b617ae 63396 utils optional gnupg2_2.2.27-3.debian.tar.xz
 59522b4bf244add746fe0329178e25dc 18163 utils optional gnupg2_2.2.27-3_powerpc.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEWXMI+726A12MfJXdxCxY61kUkv0FAmG+CgsACgkQxCxY61kU
kv1e4A/+OVaievLVKVaGRh41GGsMG46t2SisYVVdj/cs6nyMn7YRwuy2O2o8Yv1U
RSFxTq6FHFVlXrCdBf56k0+lmQ6lSXRh692dRS+Ic0Qk3o5y1MfakojHLcx/2p9I
t1w3NT8Eu62w3zgxn7+lKZcCJCxuOhSB3PMiTQZFOtkwoUiRqHhu8lnKKuQ1pXDW
YaCmNg9l+TZkPj/Rc/wmUGbn7K64+GF1zUagEjRyaKIeiZNkbf1tYYuMihkSNiLS
6Ac/1R3kl+6cyh+6jvSqbA2uxdVfqGqNopG4vkD/OLWVcf9/zzBEKs37xII/0DWP
F/54drXk86Suxe5XHN/YfWLSJhFOoFVdhy5AR5EaWYCBtoRx+d0TTwV6mLIwlZs0
GVxo3PjGKrXPwmy+/TY7vaXESfSDqLpSw9dE0wjLdcrxpL480jm1x4PVppnxoJJf
60cLYvolVG8gskYlwGNa1Fw8fyQirx87THWjajsu1wh8FL8hzeBe/uNKNfIuH8wl
wneMxJuW5AyyFvgRKRscac5Ave1aB7KwOEcxYi3IMNgxRgzHhdCL3pgCxWEyNe+p
hHtn1iJbWo56qu/nu81joObN5H9WXJjQraEoUhpFgBS+Fs8FLUTM2Or1y7ERMFmi
GYiinqMglIgFjHywl0zwXdlfQIYmklg33TcVDBF+yaLmPacbiSM=
=Toi9
-----END PGP SIGNATURE-----

Control: reopen 993857
Control: retitle 993857 gnupg2: gnupg-module-overview.png is not built from source

Thanks for looking into this, Laurent and Christoph.

Looking at it a bit further, I'm not convinced that dropping the
build-dep is the right way to go, either for policy reasons or for
correctness.  Looks to me like upstream is shipping a pre-built binary
image, as well as the source for the image.  We should be rebuilding it,
just like we rebuild everything else.

debian expects to build every generated file from source (the preferred
form of modification) and to not re-distribute any pre-built binaries
from upstream.  Consider if upstream were to ship a pre-built executable
as an example that is clearer -- we wouldn't want to redistribute that.

Upstream's git repo also doesn't contain any copies of the PNG, it's
just included in the shipped tarball.  We have a way of tracking how the
PNG is created during upstream's tarball generation process.

Additionally, the .png in question as shipped upstream is misrendered
-- the text labels for many nodes, and for all of the legend are
not placed correctly.  The version built if I use "convert" or "gm
convert" puts the text in the right spot.  Here are is the version
shipped in upstream's 2.2.27 tarball:

Thanks for your feedback.

My understanding of the policy has always been that the source tarball
shipped in debian must indeed contain all the files in their "preferred
form of modification" but the fact that the resulting artifact has to be
rebuilt during the build of the package was merely a recommendation.
Here we have both the .svg and the .png file shipped in the tarball, so
that looks DFSG compatible to me.

My main concern here was to be certain that gnupg can build all
architectures even the one without rust support and your proposal allows
this, so it's good for me and if you think it's better to rebuild the
image during the build I've no objections.

The fact that there is a rendering problem with the .png shipped in the
upstream tarball should be reported in any case I think.

Kind regards,

Laurent Bigonville

Daniel Kahn Gillmor wrote...

Quite frankly, I don't think even it's necessary to stress the policy
here, shipping a "more correct" PNG should be motivation enough. And it
seems you have a plan how to achieve both the above goal and Laurent's
interest to have GnuPG built on kfreebsd, so just go ahead.

    Christoph

This is almost certainly not the case for executable code -- if someone
upstream shipped an x86_64 binary, as a debian user i would be pretty
upset if the upstream binary was just passed through directly.

But whether executable code or not, the requirement isn't just that the
source code is available, but that the toolchain is also all free
software, right?  (there may be some exceptions for bootstrapping
tooling, but afaict we're working on trying to fix even that with
diverse dual compiling, rebootstrap, and reproducible builds projects).

The only way that i can see to be confident that the toolchain is
present is to actually do the build, right?  and if we do the build and
it's different than the generated object shipped by upstream, which one
should we prefer?

makes sense (and i share your goal)!

Agreed, though i'd just as soon ask upstream to stop shipping the png in
their tarball :)