Version: 2.104.0

Running `lintian --fail-on warnings` on a package which overrides all
warnings in debian/lintian-overrides unexpectedly returns exit code 2.
Expected behavior is for this command to return exit code 0 unless
`lintian --fail-on overrides` is also specified.

Reading `man lintian` implies that `lintian --fail-on warnings` and
`lintian --fail-on overrides` should have distinct behaviors. However,
`lintian --fail-on warnings` seems to behave as if `lintian --fail-on
warnings,overrides` were specified instead.

If `lintian --fail-on warnings` should always fail on warnings, even
when debian/lintian-overrides overrides these warnings, the
documentation should probably be clarified. However, this behavior
leaves no way to check that a package having one or more overrides has
no additional issues.

I run lintian as part of my build process. I'd like to fail the build if
lintian finds issues with either the source package or the binary
package. Currently, if I use --fail-on, and the package has any
overrides, lintian always returns exit code 2. And if I don't use
--fail-on, lintian always returns exit code 0. I seem to be unable to 
have lintian return a non-zero exit code only when a package has an
issue that has not yet been fixed or overridden. Using
--ftp-master-rejects might return such an exit code, however, such an 
exit code is not documented and would prevent using a --profile.

Same discussion applies for `--fail-on errors` etc.

Thanks,
Daniel Kauffman
Business Experience Designer
Rock Solid Solutions LLC

Hi,

today I ran into the same issue on Bookworm.

What was strange though: some packages hit this bug, others did not.

Turns out it is related to "automatic" overrides being present or not.
A python package of mine had automatic overrides for
"package-contains-documentation-outside-usr-share-doc
[usr/lib/python3/dist-packages/PackageName-Version.egg-info*]"

The --show-overrides option (hitting #1019690 here) said:
"N: masked by screen python/egg/metadata"

After adding explicit overrides in the package the --fail-on function
worked correctly again and I got exit code 0 instead of 2.


Hope this helps!

Best wishes

Control: tags -1 + patch

So the issue is that these "automatic" overrides aren't actually
overrides internally, but "masks".  Lintian's default EWI output treats
masked and overridden tags similarly, in terms of display priority, but
does not treat them the same when it comes to the fail-on parameter.

The following patch changes lintian to treat masks like overrides when
counting reported tags.  With this patch applied, tags that are masked
internally no longer count as reported, so they don't trigger "fail-on"
for different severities.  Note that it specifically does *not* trigger
'--fail-on override'.  That would be easy to implement, but I don't
think it's the right thing to do, as a masked tag is not really under a
package maintainer's control and doesn't indicate anything that they've
specifically enabled in their package.

This is a slight change in behavior, but I think it's a reasonable one.
The existence of this bug highlights how confusing the current behavior
can be.

From dca99e1438ef25518bbb440ceb2e7c540f5a14b1 Mon Sep 17 00:00:00 2001
From: Noah Meyerhans <noahm@debian.org>
Date: Tue, 13 Oct 2026 14:35:48 -0400
Subject: [PATCH] don't count masked tags as reported

Closes: #1031878
---
 lib/Lintian/Pool.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Lintian/Pool.pm b/lib/Lintian/Pool.pm
index db153f989..f7c0157b7 100644
--- a/lib/Lintian/Pool.pm
+++ b/lib/Lintian/Pool.pm
@@ -191,7 +191,7 @@ sub process{
                 next
                   unless $PROFILE->display_level_for_tag($hint->tag_name);

-                if (!defined $hint->override) {
+                if (!defined $hint->override && !@{$hint->masks}) {

                     ++$reported_count{$tag->visibility}
                       if !$tag->experimental;

As such, I dislike the idea of screen altogether - it is simply easier to not
trigger certain tags when they should not be triggered rather than masking it
like this.

Dropping that should not be too difficult, but assessing the impact of it would
need some analysis. I guess for now we could take your patch.

Please make an MR -- it is much easier to review with passing CI.

Yeah, this wasn't something I'd seen before and I was a bit surprised by
it.

I don't know the history of these screens/masks, but I suspect the idea
was to simplify the creation of exceptions without requiring them to be
built into the checks directly.  It makes sense, but is obviously a
little unexpected.

https://salsa.debian.org/lintian/lintian/-/merge_requests/820

noah

Hello,

Bug #1031878 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lintian/lintian/-/commit/aa360ae841cdd321583656b73c3c6f68b2e35c47

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1031878