lintian currently warns if packages don’t use debian/watch version=5.

trixie was released one month ago only and only supports version=4.
This is ridiculous, pardon my french.

Please omit that warning until after the forky release. And I do mean
omit, not move to experimental.

Getting angry on maintainers does not help or solve problems for anyone
to be honest. It only makes situations bad and tense.
I have had nice and civil discussions with you on (many) occasions
in the past and I'd appreciate if we can continue it further down the line as well.

(I'm not a lintian maintainer myself but I regularly help with reviews and patches
on lintian)

But why should it be omitted? I think moving it to info should be good
enough to do here -- we would like to encourage maintainers to move to
a newer watch version eventually.

Thanks
Nilesh

It’s likely fatal if they upgrade prematurely, though.

(And, perhaps I was a bit angry, but recent lintian churn has
been immense every time it got updated… this is getting on the
nerves of all package maintainers…)

I'm glad there's a lot of activity again around lintian, even if that
means that we need to temporarily deal with more churn (and possibly
some tags that need to be adjusted) while the backlog gets reduced.

Lucas

On Mon, 15 Sep 2025 03:25:20 +0200 (CEST) Thorsten Glaser <tg@debian.org> wrote:

I'm not sure I understand what you mean by this?

AFAIU, the lintian version that's released to unstable isn't targeted
for packages in stable.

I (very candidly) don't understand why Trixie not supporting d/watch v5
is causing issues? Please be more verbose so we can address this issue :)

I don't understand this part. Can you be verbose about how this
appears fatal to you?

Lintian version released to unstable is not meant for trixie and are
hence not hit by d/watch version 5 info tag.
As such, I am inclined to tag this bug as wontfix but I am leaving
that to lintian maintainers.

I'd like to hear reasons of what led you to say this, and what specific
pain points you have had since past few (with past one year) lintian releases.

I am actually willing to invest my (unpaid, volunteer) time and efforts
to help make it better for you and other developers with patches etc.

Yes, but the watch file especially is expected to be consumable
by developers and other tooling on trixie. Heck, probably even
bookworm at least. There’s a service for this even, what does the
backend behind qa.debian.org/cgi-bin/watch use?

It’s been a buildup. Lots of tag renamings (some tags got renamed
twice even), the whole move to the new format with the square
brackets (which made the lintian from the previous stable even
segfaulting), and then a whole flood of rather opinionated new
tags that even partially are wrong (e.g. the one that complains
about debian/* not having the current year listed in copyright
even when there was nothing passing threshold of originality in
the current year).

I’m sorry I don’t have a small number of actionable points for this.

Thanks anyway,
//mirabilos

I don't see how adding d/watch v5 tag in lintian release for
unstable affects any of that.

The d/watch in trixie is v4. The lintian version in trixie has
checks for d/watch v4. It considers d/watch v4 as the latest
watch version.

Packages with d/watch v5 will not enter stable. At best, they can
be in stable-bpo. And none of it has any functional impact here.

All those changes were added back in 2021 and 2022. I actually did
the effort to fact check this in `git log`. This means that there
was nothing "getting-on-nerves" that has happened in the past year
or two.

Anyway, I think there's no further action for me to take here. I
will stop engaging in this bug report further as the discussion here
is mostly done IMO.

Yes, but they are going to be DEVELOPED by people running stable¹,
and their upstream info is going to be CHECKED by a service running
on a system running stable, possibly even old*stable. Gah!

① This is perfectly fine since we build in chroots anyway and can
  do the testing also in those chroots or special test VMs.

…

I’ve literally got no response suitable to that.

Anyway, some people may get cross if uscan(1) will start throwing
errors soon but…

bye,
//mirabilos

tag 1115177 wontfix
thanks

I agree with Nilesh's reasoning and see no actual problem with the
inclusion of d/watch v5 checks in Lintian.

Maintainers can (and should) build packages intended for unstable on
chroots/VMs/etc running unstable and thus shouldn't be affected by this.

In any case, even if Lintian doesn't suggest it, people have already and
will continue to migrate to d/watch v5. Solutions should be taken (maybe
a backported version of uscan?) to support these changes when required
on machines running stable or older releases.

I thus feel this is less a problem with Lintian itself and more with
uscan/other programs parsing d/watch files.