On Tue, 28 Sep 2021 11:46:13 +0100 "Chris Lamb" <lamby@debian.org> wrote: > Hi Ola, > > > My guess has been that we should not generally fix lintian warnings > > unless they are really important. > > (Agree with this, of course.) > > > So I assume quite a few of them could be removed. But maybe I'm > > wrong here. > > That could work, although it would have the drawback of potentially > hiding the "really important" tags. I suspect we should only consider > removing/hiding tags if they were somehow introduced by the LTS update > process itself. Or, putting it another way: in the usual case, there > should probably be no difference between the Lintian output between > before and after applying a fix for relevant CVE(s)? That was where I was heading too. Lintian doesn't have a comparative mode but I think that's essentially what is needed. Extracting the lintian warnings from the build log or running lintian explicitly against the pre-CVE version and running it again after the build with the final CVE changes. Lintian warnings in tracker.d.o aren't necessarily helpful for this as those were output by lintian in unstable. It should be the appropriate version of lintian for the prospective upload. Maybe a lintian-diff script? - enough fuzzing to handle changes in order in the output, changes in some things like line numbers within the tag messages. We've got debdiff, something like that for lintian would be useful. Nice and simple, return zero on success, print out a diff and exit non-zero on failure. If the script could parse an sbuild pre and post build log file, so much the better. -- Neil Williams ============= https://linux.codehelp.co.uk/
Attachment:
pgpWxWBn1HSXQ.pgp
Description: OpenPGP digital signature