Control: reassign -1 lintian [ Leaving context intact for other lintian maintainers. ]
Hi! On Tue, 2026-01-27 at 02:03:40 +0100, Guillem Jover wrote: > On Mon, 2026-01-26 at 22:57:34 +0530, Nilesh Patra wrote: > > Package: dpkg > > Severity: serious > > X-Debbugs-Cc: [email protected] > > <mailto:[email protected]>.org > > Control: affects -1 + src:lintian > > Version: 1.23.5 > > > Lintian’s test suite has started to fail with huge number of errors. > > > > | dpkg-source: error: 'Marc 'HE' Brockschmidt <he@unknown>, Jeroen van > > Wolffelaar<[email protected]>, > > | Frank <[email protected]>, Yama@gotchi, Josip, I am afraid of spam and > > think this helps <no_spam_please AT debian.org>’ is > > | not a valid email |address list > > > > This looks like the consequence of latest dpkg upload. > > > > | dpkg (1.23.5) unstable; urgency=medium > > | . > > | [ Guillem Jover ] > > | * dpkg-source: Do not error out on empty fields. Closes: #1125985 > > | * Perl modules: > > | - Dpkg::Email::Address: Do not construct invalid objects. > > Ah, I validated the archive with the new Dpkg::Email::Address and > Dpkg::Email::AddressList modules and reported or bumped the severity > of the handful of impacted packages, but forgot to check lintian. > > (This behavior change would have been introduced in dpkg 1.23.4.) > > > A large amount of test suite uses legacy tests and there’s even a > > "malformed-contact” tag that lintian emits. Fixing all of this > > is well, annoying since this is a large number. > > > > OTOH I don’t understand the reasoning behind completely failing to build > > a package due to one wrong email address. > > The lintian tag of error severity combined with a dpkg warning of malformed > > email address looks like a pretty good check to me already. > > The rationale is that this is how the field is specified both in the > dpkg documentation and in the Debian Policy (the latter as a must in > §3.3, §5.6.2). > > And letting invalid entries means that the maintainers might not end > up receiving mails, or that other tools need to cope with the > unexpected/bogus values. > > I think, that in many cases dpkg being lenient is a disservice to the > entire ecosystem, and unhelpful for maintainers that might for example > not run lintian, and while lintian has been extremely helpful in trying > to avoid badness, when that role can be taken over by dpkg at the source > of the badness, that's always going to be better. > > Also warnings from dpkg are easy to miss when they get emitted in the > middle of the build output. > > In this case for example, I made the Maintainer and Uploaders validators > fatal, but the duplicate Maintainer address in the Uploaders field just > a warning, because that's not as bad IMO. (And the latter might still > make sense as the current lintian tag, because in contrast to dpkg's > warning, this one is tracked in dashboards, UDD, etc) > > > Do you think dpkg can emit a warning here instead? > > It could, but I'd rather not. This has happened many times in the past > as well, when dpkg has been made more strict, and then lintian stopped > being able to validate bogus data on its own, and then those checks or > tags got removed as unnecessary. It also seems to be part of the deal > with how lintian operates, where it needs to adapt to changes in > tooling. :) > > So, I'd like to reassign this to lintian. And while I have my hands > full, if this is a capacity problem, I'd rather spend the time fixing > lintian than reverting this in dpkg, TBH. After discussing this on IRC, I'm doing this now. Thanks, Guillem
