Hi! 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. Thanks, Guillem
