[pkg-gnupg-maint] gnupg2_2.2.38-1_amd64.changes REJECTED

[Daniel Kahn Gillmor]

[including full text here because i've added lintian-maint here]

On Mon 2022-09-05 13:30:06 -0400, Daniel Kahn Gillmor wrote:
> On Sun 2022-09-04 13:56:20 +0200, Ansgar wrote:
>> On Thu, 2022-09-01 at 20:42 -0400, Daniel Kahn Gillmor wrote:
>>> I'm a little bit confused by this REJECT message:
>>> 
>>> On Thu 2022-09-01 23:05:39 +0000, Debian FTP Masters wrote:
>>> > gnupg2 source: lintian output: 'license-problem-non-free-RFC doc/OpenPGP', automatically rejected package.
>>> > gnupg2 source: If you have a good reason, you may override this lintian tag.
>>> 
>>> Nothing has changed in the gnupg2 source package upstream for
>>> doc/OpenPGP between 2.2.35 (in testing) and 2.2.38 (just uploaded), and
>>> doc/OpenPGP itself doesn't even contain an RFC, it just refers to the
>>> RFCs related to OpenPGP (RFC 4880 and RFC 2440).
>>> 
>>> Furthermore, when i run lintian 2.115.3 locally on the package before
>>> uploading, i don't see these error messages.
>>
>> ftp-master has lintian 2.104.0 from bullseye. For the previous gnupg2
>> upload (gnupg2_2.2.35-3.dsc) it says:
>>
>>     E: gnupg2 source: license-problem-non-free-RFC doc/OpenPGP
>>     W: gnupg2 source: mismatched-override license-problem-non-free-RFC [doc/OpenPGP]
>>
>> I think the last gnupg2 upload was before the upgrade of ftp-master to
>> bullseye where it was still running an older version of lintian.
>
> I don't see anything in this conversation that suggests that we think
> there is an actual RFC in doc/OpenPGP, or any other kind of license
> problem with the source.
>
> Do you want me to just add a lintian override to the gnupg2 source
> package that will be ignored (actually, complained about as unnecessary)
> by the version of lintian in unstable?

So i think the issue here is that in gnupg2 debian packaging
eb8a6be72ef19d21337131023f1883fccbb138c6 i updated
debian/source/lintian-overrides to use the new lintian syntax (the one
where variable data from the tag is wrapped in square brackets), but
ftp-master is rejecting based on the earlier form.

Upstream just released 2.2.39, so i'll go ahead and try uploading that
one with both variants of the lintian lines (with and without square
brackets) in debian/source/lintian-overrides.  This guarantees at least
one mismatched-override warning no matter which version of lintian is
being run, but it should produce no errors at least.

However, this raises a general question of how package maintainers
should track lintian when doing their development work targeting
unstable.  Should we run the version from bullseye locally, so that we
only get the advantages of new lintian scans every upgrade cycle?
Should we run both versions of lintian somehow?  should we do like i've
done with 2.2.39 and describe both versions of tags that were recently
rewritten?

Or would it make more sense for ftp-master to use lintian from
bullseye-backports instead when ingesting packages into unstable?

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20220906/e164da3c/attachment-0001.sig>