#1040138 changelog-file-missing-explicit-entry needs exception for bookworm

#1040138#5
Date:
2023-07-01 13:01:11 UTC
From:
To:
Hi,

this is the bookworm edition of #1001651 which got fixed by adding an
exception, judging from the changelog entry of lintian 2.115.0.

This issue happens again when preparing a successive upload to bookworm.
I have aide 0.18.3-1, 0.18.3-1+deb12u1 and 0.18.3-1+deb12u2, the deb12u2
gets this lintian tag.

See https://salsa.debian.org/debian/aide/-/blob/bookworm/debian/changelog

Greetings
Marc

#1040138#10
Date:
2023-10-09 00:06:58 UTC
From:
To:
Marc Haber <mh+debian-packages@zugschlus.de> (2023-07-01):

That exception only hides the root of the bug, which includes (at least)
a messed up version sorting.

Adding another exception for bookworm will only lead to more
whack-a-mole down the line (see #1051140).

Cheers,

#1040138#15
Date:
2023-10-09 07:53:44 UTC
From:
To:
What is the recommended way to get rid of this? Re-sorting
changelog entries? Adding an override?

I don't see the connection here.

Greetings
Marc

#1040138#20
Date:
2023-10-28 12:43:42 UTC
From:
To:
Marc Haber <mh+debian-packages@zugschlus.de> (2023-10-09):

On the lintian developer side: Fixing whatever produces the weird and of
course incorrect ordering that's then expected and complained about.

Adding an exception hides the bug. Then it's going to appear again when
the next suite is around the corner, until an exception is added again,
etc. That doesn't seem like a good idea to me.


Cheers,

#1040138#25
Date:
2024-02-29 08:04:24 UTC
From:
To:
* Cyril Brulebois <kibi@debian.org> [2023-10-28 14:43]:

I have the impression that the discussion went astray. The original
reported issue is that the sequence of versions:

     0.18.3-1 ⇒ 0.18.3-1+deb12u1 ⇒ 0.18.3-1+deb12u2

is perfectly valid but, yet, Lintian says that the third one is not
allowed to follow the second one.

According to the Debian Developer's Reference, section 5.14.3:

“Version numbers are usually selected by appending +debXuY, where X is
the major release number of Debian and Y is a counter starting at 1.
e.g. 1:2.4.3-4+deb12u1.”

Mu understanding is that the last number (Y) is expected to increase in
successive releases.

Could the code in Lintian be changed such that the warning
changelog-file-missing-explicit-entry will only be triggered when
Z+debXu1 does not follow Z? For now, it seems to be triggered whenever
Z+debXu\d+ follows Z.

Best,

Rafael Laboissière

#1040138#30
Date:
2026-01-10 10:10:20 UTC
From:
To:
Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.

#1040138#35
Date:
2026-08-04 20:12:12 UTC
From:
To:
Hello all,

I think fixing this in 'bookworm' suite is no longer possible, and so the original
bug report would be technically 'closed'.

However, I read the other bug reports linked above - and it appears to me that
this needs to be bumped per release which is not optimal at all. Hence I have
opened an MR to use `distro-info` to get current stable information so the
'exception' would remain independent of lintian code going forward.

I am using the same bug report to track this and going ahead with retitling. I hope
this should be fine.

Thanks,
Nilesh

#1040138#40
Date:
2026-08-06 13:31:09 UTC
From:
To:
Hello,

Bug #1040138 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/4e9bd2fdde3205d873c8df479a2217526c9b5455
This ends the cycle of having to hard-code stable distribution name on every backport
as we directly use the name of stable distribution that we get from `distro-info`
and consequently `distro-info-data`

See the commit message in
https://salsa.debian.org/lintian/lintian/-/commit/2dc42ac0dc2073d6537203cbb4fb82d82460d7ef
for more information.

Only drawback with this implementation is that we are now depending on the system time for
getting the stable distro name via the `->stable()` call, as we do not pass any date here to
avoid hard-coding it once again.
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1040138