Package: dh-golang Version: 1.39 Severity: serious My first submissions for the dmarc-cat package (#920385) were refused by the FTP masters because the built-using field did not respect §7.8 of the Debian policy. Extract from #debian-ftp:
16:55:59 <jrtc27> Built-Using is only meant to be used when the result is GPL/MPL/similar and you've statically linked (/bundled) another source package 16:56:33 <anarcat> okay, so to comply with licensing issues? 16:56:47 <anarcat> it also seems useful to track rdeps for golang as well, no? 16:57:03 <waldi> no, built-using is _not_ for tracking dependencies 16:57:10 <waldi> it is for license compliance 16:57:26 <waldi> and bsd licensed software does not require that So in the case of dmarc-cat, dependencides like golang-github-stretchr-testify-dev should actually not be listed in the Built-Using field. dh-cargo solves this by manually inspecting the copyright files in the dependencies: https://sources.debian.org/src/dh-cargo/17/dh-cargo-built-using/ Some similar solution should be implemented in dh-golang. In the meantime, a workaround is to inspect the automatically generated Built-Using line and hardcode a proper version after a manual copyright audit. In the case of dmarc-cat, that inspection seem to indicate no Built-Using line should be included whatsoever, as all dependencies are BSD/MIT/Expat/Apache which doesn't require including source... -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-golang depends on: ii debhelper 12 ii dpkg 1.19.2 ii libdpkg-perl 1.19.2 ii perl 5.28.1-3 dh-golang recommends no packages. dh-golang suggests no packages. -- debconf-show failed
