Hi Jonathan,

two other cases of ancient NEWS items being show, this time with
apt-listchanges 4.2 and when upgrading falkon from 23.08.1-1 to
23.08.2-1 and multiple src:libdrm packages from 2.4.115-1 to 2.4.116-1:

$ dpkg -l 'libdrm*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Tr
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                  Version      Architecture Description
+++-=====================-============-============-===================
ii  libdrm-amdgpu1:amd64  2.4.115-1    amd64        Userspace interface
ii  libdrm-amdgpu1:i386   2.4.115-1    i386         Userspace interface
ii  libdrm-common         2.4.115-1    all          Userspace interface
ii  libdrm-dev:amd64      2.4.115-1    amd64        Userspace interface
ii  libdrm-intel1:amd64   2.4.115-1    amd64        Userspace interface
ii  libdrm-intel1:i386    2.4.115-1    i386         Userspace interface
ii  libdrm-nouveau2:amd64 2.4.115-1    amd64        Userspace interface
ii  libdrm-nouveau2:i386  2.4.115-1    i386         Userspace interface
ii  libdrm-radeon1:amd64  2.4.115-1    amd64        Userspace interface
ii  libdrm-radeon1:i386   2.4.115-1    i386         Userspace interface
ii  libdrm2:amd64         2.4.115-1    amd64        Userspace interface
ii  libdrm2:i386          2.4.115-1    i386         Userspace interface
ii  libdrm2-dbgsym:amd64  2.4.115-1    amd64        debug symbols for l

I got shown three NEWS entries, one from a few days ago (correct), one
from 2018 (falkon) and one from 2007, seemingly for libdrm2, but I
suspect that at least the multiarch setup (libdrm2:amd64 vs
libdrm2:i386, see above) might have played a role:
--- News for falkon ---

falkon (3.0.0-3) unstable; urgency=medium
  ===========================================

  Falkon is a replacement for the former package Qupzilla. If you, or some
  other user of this computer were using Qupzilla formerly, it is possible
  to restore bookmarks which were gathered with Qupzilla, so they become
  available for Falkon users.

  Here is a method for user John Doe, in shell language:

  # USER_HOME=/home/johnDoe;
  # cp ${USER_HOME}/.config/qupzilla/profiles/default/bookmarks.json \
  ${USER_HOME}/.config/falkon/profiles/defaults/

  Please notice that doing so will erase any previous file
  ${USER_HOME}/.config/falkon/profiles/defaults/bookmarks.json

--- News for libdrm2 ---

libdrm (2.3.0-4) experimental; urgency=low

  * We are now shipping libdrm with the default permissions set to 666,
    rather than the upstream default of 660. If you have untrusted users,
    you should configure the X server to explicitly use a mode of 660 in
    the xorg.conf.

Is it possible for you to find the file in
/var/lib/apt/listchanges-snapshots corresponding to the time of the apt
run when this issue occurred and either email it to me separately (don't
append to the ticket) if it's small enough or if it's not then upload it
somewhere and share the link with me? That will greatly help me to
troubleshoot this.

Thanks,

jik

The falkon NEWS entry display was correct. There was no NEWS file in
23.08.1-1 and it was added (with that old entry in it) in 23.08.2-1, so
apt-listchanges correctly concluded that it was a new NEWS entry and
displayed it.

While this may be an edge case, I believe apt-listchanges is correct in
this case to err on the side of showing the user more rather than less.

Still looking into the libdrm one, will let you know when I know more.

   jik

On Tue, 17 Oct 2023 08:36:24 +0200 Axel Beckert <abe@debian.org> wrote:

 > Package: apt-listchanges
 > Version: 4.2
 > Severity: normal
 >
 > Hi Jonathan,
 >
 > two other cases of ancient NEWS items being show, this time with
 > apt-listchanges 4.2 and when upgrading falkon from 23.08.1-1 to
 > 23.08.2-1 and multiple src:libdrm packages from 2.4.115-1 to 2.4.116-1:
 >
 > $ dpkg -l 'libdrm*'
 > Desired=Unknown/Install/Remove/Purge/Hold
 > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Tr
 > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
 > ||/ Name Version Architecture Description
 > +++-=====================-============-============-===================
 > ii libdrm-amdgpu1:amd64 2.4.115-1 amd64 Userspace interface
 > ii libdrm-amdgpu1:i386 2.4.115-1 i386 Userspace interface
 > ii libdrm-common 2.4.115-1 all Userspace interface
 > ii libdrm-dev:amd64 2.4.115-1 amd64 Userspace interface
 > ii libdrm-intel1:amd64 2.4.115-1 amd64 Userspace interface
 > ii libdrm-intel1:i386 2.4.115-1 i386 Userspace interface
 > ii libdrm-nouveau2:amd64 2.4.115-1 amd64 Userspace interface
 > ii libdrm-nouveau2:i386 2.4.115-1 i386 Userspace interface
 > ii libdrm-radeon1:amd64 2.4.115-1 amd64 Userspace interface
 > ii libdrm-radeon1:i386 2.4.115-1 i386 Userspace interface
 > ii libdrm2:amd64 2.4.115-1 amd64 Userspace interface
 > ii libdrm2:i386 2.4.115-1 i386 Userspace interface
 > ii libdrm2-dbgsym:amd64 2.4.115-1 amd64 debug symbols for l
 >
 > I got shown three NEWS entries, one from a few days ago (correct), one
 > from 2018 (falkon) and one from 2007, seemingly for libdrm2, but I
 > suspect that at least the multiarch setup (libdrm2:amd64 vs
 > libdrm2:i386, see above) might have played a role:
 >
 > --- News for falkon ---
 >
 > falkon (3.0.0-3) unstable; urgency=medium
 > ===========================================
 >
 > Falkon is a replacement for the former package Qupzilla. If you, or some
 > other user of this computer were using Qupzilla formerly, it is possible
 > to restore bookmarks which were gathered with Qupzilla, so they become
 > available for Falkon users.
 >
 > Here is a method for user John Doe, in shell language:
 >
 > # USER_HOME=/home/johnDoe;
 > # cp ${USER_HOME}/.config/qupzilla/profiles/default/bookmarks.json \
 > ${USER_HOME}/.config/falkon/profiles/defaults/
 >
 > Please notice that doing so will erase any previous file
 > ${USER_HOME}/.config/falkon/profiles/defaults/bookmarks.json
 >
 > -- Georges Khaznadar <georgesk@debian.org> Tue, 03 Apr 2018 18:26:55
+0200
 >
 > [Inbetween was NEWS for xca 2.5.0-1 which was current as I upgraded from
 > 2.4.0-2+b1]
 >
 > --- News for libdrm2 ---

Jonathan Kamens <jik@kamens.us> writes:

I'm not saying that you're wrong in that analysis, but I think that's a
change that may be surprising to package maintainers.  It's not unusual
for people to add retrospective NEWS entries intended for people who will
later be upgrading to a new stable release, but which are irrelevant for
people running unstable who have already upgraded.

I'm not sure what the balance is between those cases and cases where the
NEWS entry is indeed useful and should be displayed (and I've not looked
at this one in particular), but I know I've used the behavior of
apt-listchanges hiding even newly-introduced NEWS entries for older
versions not involved in the current upgrade before, intentionally.

Jonathan Kamens <jik@kamens.us> writes:

I'm not saying that you're wrong in that analysis, but I think that's a
change that may be surprising to package maintainers.  It's not unusual
for people to add retrospective NEWS entries intended for people who will
later be upgrading to a new stable release, but which are irrelevant for
people running unstable who have already upgraded.

I'm not sure what the balance is between those cases and cases where the
NEWS entry is indeed useful and should be displayed (and I've not looked
at this one in particular), but I know I've used the behavior of
apt-listchanges hiding even newly-introduced NEWS entries for older
versions not involved in the current upgrade before, intentionally.

While your observation may be correct, there doesn't seem to be anything
actionable here, so I'm not sure what you're getting at.

Fundamentally, the decision to change apt-listchanges's algorithm to use
file contents rather than version numbers to decide what entries to
display means that entries, including the one we're discussing, will now
be displayed to the user that weren't displayed before. This isn't a
bug, it's a feature; before entries that should have been displayed
weren't, and the whole point of the algorithm change is to err on the
side of displaying more rather than less.

I am not sure this is going to be enough of an issue to treat it as
anything other than an occasional blip which is just going to happen
with the new algorithm and that's fine.

But if you think it's more than that, then what do you suggest we do
about it? Do we need to, e.g., conduct some sort of "maintainer
awareness campaign" to let maintainers know that this change is coming?
Do you think we need to deal with this now, or can we wait and see how
much of an issue it is before taking further action?

   jik

Jonathan Kamens <jik@kamens.us> writes:

Basically, what I'm arguing is that I hadn't really understood the
implications of that when you were discussing it previously for cases
where people have retroactively added old entries.  I'm sorry, I really
should have picked up on this during the previous design discussion, and I
didn't.

Previously, my *experience* of apt-listchanges (which I know was not
exactly what it was doing) was that it was based on version.  Entries
equal to or older than the version I already had installed were not
displayed; entries newer than that version were.

The semantics of showing every entry that had not been seen before are
substantially different in some edge cases.  For example, if I fix a typo
in the changelog of the previous version of the package (something I have
done many times) or add a new bug closer that I missed, I think, from the
new documentation, that entry is shown to the user again because its
checksum changed, even though it's the entry for the version they already
have installed and none of those changes are of interest to the user, and
I wasn't expecting or wanting them to be shown the entry again.

If I'm reading what_to_display.html correctly, the change only affects
cases where the entries being retroactively added or changed are
contiguous with the new entries.  As soon as it sees an intervening
already-seen entry, it stops.  That definitely reduces the scope of the
change a lot, but I think that, with normal maintenance practice of fixing
typos or the like in older changelog entries, there will be a small but
steady trickle of cases where the new algorithm "redisplays" entries that
from the perspective of the user they've already seen, because the change
is something tiny they don't care about, or they see NEWS entries that
don't apply to them since they're only meant for stable upgraders.

(I am not sure about that last case; it's possible there are more cases
where the NEWS entry should be shown than when it shouldn't.)

I'm not sure either, and certainly the old algorithm had its own share of
bugs that were probably worse.

I think that the semantics I personally would expect would be met with an
additional filter of discarding entries whose version equals or is less
than the version of the package already installed and whose package
matches the package of the changelog entry already seen in the installed
package, but I do see the problem with this in that you don't know if the
entry is for the package that is currently installed because you're not
tracking the association between source and binary package names.

Well, before we get to the question of making maintainers aware of it, do
you see a way for maintainers to get the semantics that they want?  It's
one thing to tell people "the old way you were doing this won't work, do
this other thing instead," but a harder lift to tell people "you can't do
that any more."

I was unable to reproduce the libdrm issue or determine how it could
have happened from attempting to reproduce it and examining the code. To
be clear: I'm not disputing that it happened, just saying I can't figure
out how so I can't figure out how to fix it. :-/

In the process of attempting to reproduce it I discovered and fixed
three different bugs. Two of those bugs only impact debugging snapshots,
and indeed, they prevented the snapshot you sent me from being complete,
which is part of why I was unable to reproduce the issue. It's remotely
possible that the third bug might explain the behavior you saw, but I
can't figure out how.

All I can think to do at this point is to put out a new experimental
version of apt-listchanges with these three fixes in it and then we'll
see if the issue you encountered happens again. Because I can't
reproduce the issue or figure out how it could have happened, I can't
think of a better solution than that at this point.

   jik

just wanted to add an agreement to this --- as a user it would be really
confusing to see old entries, -- the programme is "apt listchanges" not
"apt listchangelogs". as a user i want to see what has changed.

dont want to discourage all the great work, but are you sure the benefits
exceed the complexity for users?

If I'm reading what_to_display.html correctly, the change only affects


im sure you have thought about this, but when i read the design notes i was
left wondering ---

what happens if changelog entries are identical because things are enabled,
reverted and then changed:

version 1: enable feature
version 2: disable feature temporarily
version 3: other independent changes
version 4: enable feature
version 5: something else

v4 and v1 entries have the same content, does this mean we might never see
the intervening v3 in some circumstances ( i install v1 then go to v5 - the
v4 changelog matches v1  so will we lose v3?)

what if two packages have the same changelog and i upgrade then separately
- does the fancy algorithm mean i see nothing on the second upgrade?

i would think the checksum of the most recently seen changelog is the one
most likely to change when people fix typos, add lines crediting people for
bug fixing, remove/add whitespace, add forgotten changes - isnt relying on
it always going to be a bit fragile?

is there a reason you cant just record the binary package version that is
installed, and only show the changelogs from that version up to the new
version?

(or have a header that says "these are old entries but their content
changed"?)

If you search back through old apt-listchanges bugs, you will see
numerous bug reports in which people complain about not being shown
changelog and NEWS entries that they should have been shown. The old
algorithm apt-listchanges was using wasn't just broken; it is
/impossible/ to make that algorithm always show things it should, given
the lack of constraints on package maintainers in formatting changelog
and NEWS entries. A choice was therefore made that it is preferable to
show users information twice than not to show them the information at
all, hence the new algorithm.

We can't rely on the package names in entries to match either the binary
or source name of the package they're included in. We can't rely on the
version numbers of binary packages produced from the same source
packages to be identical. We can't rely on the version numbers in
entries to match the version numbering sequence in either the source or
the binary package. We can't even rely on the version numbers being
consistent /within a single changelog or NEWS file/. If we imposed
requirements in this area and enforced them with lintian, /then/
apt-listchanges could take advantage of those rules (/but only for
package that come from Debian repositories!/) and leverage version
numbering. Without enforced requirements, it simply doesn't, and can't,
work reliably.

Asked to choose between, "I'm annoyed because I saw this information
twice and had to do some thinking to realize it wasn't important to me
the second time," and, "I'm annoyed because I didn't see this
information at all and it was important for me," the former seems
preferable to me, and frankly it doesn't seem like a particularly close
call. If the user doesn't see the information at all, /they have no way
of knowing there's something important they missed./ They are relying on
the tool to present important information to them, and the tool failed.
"I have to check every package I upgrade by hand to see if there are
NEWS entries that apt-listchanges failed to show me," seems like a lot
more work than, "Sometimes I have to think a bit to realize that a
changelog entry I've been shown is a repeat."

There is one tweak to the new algorithm we could potentially make that
might slightly reduce repeats without too much (albeit not zero) risk of
omitting entries that the user should see: when installing a new version
of an already-installed package, we could enable cautious
version-number-based stop-parsing logic when parsing the
changelog.Debian.gz in the package, just like we recently enabled when
parsing the changelog fetched via apt. We can only do this for changelog
files, not for NEWS files, because we can rely on changelog files having
a new entry for every release, which is required for the version-stop
logic to work safely.

I personally don't think this change would make enough of a difference
in terms of filtering out repeats to justify the risk of filtering out
something the user should actually see. Specifically, some of the
examples that you and Russ cited of changes to old entries that trigger
a redisplay to the user with the current algorithm, are changes that I
think /should/ trigger a redisplay, i.e., I think the user /should/ see
that entry again when it has been edited. Not the typos, no, but it's
obviously not practical to ask apt-listchanges to start interpreting the
content of entries to figure out which changes are "substantive" and
which are not. Which is exactly why it errs on the side of displaying.

If it turns out I'm wrong, i.e., if it turns out there are too many
repeat changelog entries (again, /not/ NEWS entries; this logic is not
safe to use on NEWS files) being displayed, we can always turn it on
later. But I think the only way we have to collect the data to find out
whether that's the case is to let the new algorithm loose as-is into the
wild.

More comments below.
on them so their checksums won't match and they will be treated as
different entries, as they should be, for the purpose of deciding when
to stop parsing the changelog.

Furthermore, "content" includes the trailer, so if the entry for v5 has
a different date in its trailer, as it should, then it will be shown to
the user again, even though the text of the changelog entry was already
displayed in v3. I will update what_to_display.md to make this clearer.

Note this paragraph in what_to_display.md (emphasis added): "Given this
stored data, the filtering algorithm is simple: Ignore any entry whose
content checksum is in the database, and stop reading a file when we hit
a /complete entry/ that's already in the database."

In other words, the rule used to determine whether the user sees a
particular changelog entry only pays attention to the content and
trailer, whereas the rule used to determine when to stop parsing a
changelog file pays attention to the whole entry, including its header.
Yes, if by "the same changelog" you mean exactly the same including the
header and trailer, i.e., including the version number and the date.
Which is arguably correct behavior, and which is how the old version of
apt-listchanges also behaves.

Because this is the old logic, and it regularly fails to show people
things they should have seen, which is why we replaced it.

   jik

Jonathan Kamens <jik@kamens.us> writes:

I'm surprised that remembering the pair of package name and version number
from the changelog header for every entry that has previously been shown
is not sufficient.  At first glance, any case where that doesn't work
feels like a bug in the changelog that should be fixed in the package
changelog.

Debian guarantees that the combination of source package name and version
number are unique across the archive over a fairly long span of time (this
is enforced by DAK), so any place where that's not sufficient to
disambiguate a specific upload of a source package looks like a bug in the
package (using a package name that doesn't match the source package name
in its changelog, for instance).  It's not up to apt-listchanges to work
around every bug in package changelogs.  Maybe some of the old
apt-listchanges bugs were simply bugs in the package that were
misassigned?

I agree with all of this.  What I do think you can rely on, which would be
a bug in the package if not followed, are the following rules:

* Any auxillary changelog files that aren't named changelog.Debian.gz or
  changelog.Debian.<arch>.gz are not intended to be shown to the user via
  apt-listchanges.  They're only historical or supplementary documentation
  and may follow some other arbitrary rules, duplicate other packages,
  etc.  The only value of <arch> that may contain relevant entries is one
  that matches the architecture of the package being installed.

* Any newly-added changelog entry's source package and version number will
  correspond to either an upload of that source package with that version
  number or a change that was never uploaded to the archive at all, and
  source package and version number pairs are enforced to be unique.
  Therefore, any instance where you see the same source package and
  version number with wildly different contents of the entry constitutes a
  bug in the changelog that should be fixed in the changelog, and it is
  safe for apt-listchanges to deduplicate entries based on the source
  package and version number pair.

  Note that it's possible that one package may copy the entries from
  another package into its own changelog.  These source package and
  version number pairs may therefore not be unique across source packages
  (and obviously won't be across binary packages).  But the promise here
  is that two packages won't use the same source package and version
  number pair to convey different information; if there is overlap, it
  will be because entries were copied from one package to another without
  significant semantic changes.

* Once a changelog or NEWS entry for a source package and version number
  pair has been shown to a user, any subsequent changes to that entry will
  be invisible to that user.  Therefore, if further information needs to
  be shown to that user, this needs to be done with a new changelog or
  NEWS entry, or by changing the version number of the changelog or NEWS
  entry.  Not doing that is a bug in the package, not in apt-listchanges.
  This is the previous behavior of apt-listchanges that maintainers are
  used to and have mostly been assuming.

* Once you find an entry in a given changelog or NEWS file that's already
  been shown to the user, you can stop looking beyond that for new entries
  that haven't been shown to the user.  (You're already relying on this;
  I'm just stating it for completeness.)

I don't think we've written these rules down in detail in Policy but I'd
be happy to work on doing that so that you have an official document to
point to when telling people that the bug is in the changelog.

So let's explore this option.  It's unfortunately fairly difficult to
impose the rules I listed above with Lintian because they're mostly about
cross-package consistency and Lintian can only look at one package at a
time, but we can certainly write them down in Policy.

Right, I agree, but I think there's a third choice here, which is that the
package maintainer should have control over what information is and isn't
shown to the user so that they can designate which changes are important
and which aren't.  What I'm trying to avoid is treating the problem purely
as a negotiation between apt-listchanges and the user and assuming the
package contents are a given that cannot be changed.

apt-listchanges is a communication conduit between the package maintainer
and the user, and ideally should be following the instructions of the
package maintainer about what to display to the user, since the package
maintainer is going to be the expert here on what the user should know
(even if they sometimes get it wrong).  apt-listchanges has to trust the
package maintainer's opinion on what to show the user anyway, since the
package maintainer is the one writing the files and can always not put
something in the files at all.

I think a lot of these problems come from the fact that these instructions
were implicit rather than explicit, so package maintainers are guessing at
what apt-listchanges will do (or not even thinking about it), and then
apt-listchanges is guessing at what package maintainers intended, and the
resulting feedback loop has some possibility of wandering off into weird
design space.  If we make the interface more explicit, then hopefully it
will be simpler and more predictable for everyone.

I think I am convinced that apt-listchanges should always show the user
any unseen changelog or (most importantly) NEWS entries up until the
last-shown entry, even if they are for old package versions.  I can see
the use case for a package maintainer adding an old entry that isn't
relevant for unstable users, as previously mentioned, but the more I think
about this, the more convinced I am that the risk of not showing an entry
that is relevant is too high and package maintainers will just need to say
explicitly in the NEWS entry that this doesn't apply to people who have
already upgraded to version X if they mean that.

I should also say explicitly that I think the version of apt-listchanges
currently in experimental is a substantial improvement over the version
currently in unstable, and I'd be happy to see it move to unstable before
we resolve all of this.  I'm just expecting the handling of changed
entries to be surprising, and for people to want to sort that out in a way
that preserves the ability to fix older entries without redisplaying them.

I did an analysis of the 4731 packages installed on one of my Debian
boxes: does the package name on the first line of changelog.Debian.gz
match either the binary or source package name, and does the version
number on that line match the corresponding binary or source version
number of the package?

I found only one package breaking the rules, keybase, which isn't even a
Debian package, so Not Our Problem.

Given this, I am comfortable enabling the same version-based filtering
for changelog.debian[.arch][.gz] files that we are already doing for
`apt changelog` output, and I will make this change for the next release
of apt-listchanges. This will solve the "fixing typos and adding
retroactive notations to the changelog entry for the most recent
previous release will cause the user to see it again" problem we've been
discussing.

I think the build system can, and perhaps already does, enforce the
requirement that the package name at the top of the changelog match
either the binary or source package name and the version number matches
the corresponding binary or source version number. This is not a
cross-package check, it's strictly limited to the package being built.

For the most (I still have some concerns, outlined below), I like the
rules you've outlined and I think it would be useful to codify them
somehow in policy, though I certainly don't think I'm the right person
to do that, given my short tenure with Debian.

I remain reluctant to do version-number-based filtering for NEWS.Debian
entries. Because NEWS files do not contain entries for nearly every
release, the analysis I did of changelog files is much harder to perform
for NEWS files, so I cannot use the data to convince myself that it is
safe to do this. As a fail-safe, the current version-based logic only
stops parsing a changelog file if it finds entries for both the version
number being installed and the previously installed version number in
the file. I can't use that fail-safe with NEWS files because they don't
have entries for every release. The risk of version-based filtering
failing to show the user something they should have seen is therefore
higher for NEWS than for changelog, and I believe it is preferable to
not do version-based filtering and occasionally show the user something
they've already seen some form of before. This will occur much less
frequently for NEWS files than it would for changelog files since NEWS
files are updated so much less often.

   jik

Jonathan Kamens <jik@kamens.us> writes:

Incidentally, I'm pretty sure it's always the source package.  I think
even with binNMUs, the entry always uses the name of the source package.
(This is for Debian packages; I don't know what strange stuff third-party
packages might do.)

The top entry of the changelog defines the source package version number,
so there's no need to enforce that; it's the only place the source version
number is specified.  (I suppose one could hack the .dsc file or something
and maybe you could sneak something really bizarre through that way, but I
don't think that's something you need to worry about.)

I'm fairly sure Lintian will also complain if the changelog and source
package name don't match, although I haven't checked.

I'm much less worried about this problem with NEWS files, so I'm happy to
try that for a while and see if it causes many problems.

OK, I've implemented version-based changelog parsing for local
changelogs, in
https://salsa.debian.org/debian/apt-listchanges/-/commit/83796647f31f3e8952d99a43c07c7b1b83632954
. As a bonus, there's a performance improvement included that I stumbled
across while making the change. And I added a unit test to confirm that
it works as expected.

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.

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.

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.

I saw this on upgrade today from torsocks 2.5.0-1 to 2.5.0-4

  torsocks (2.0.0-1) unstable; urgency=low

    This is a completely new version of torsocks. Please update to the new
    configuration file format.

    The `usewithtor` wrapper has been removed from this package, please call
    `torsocks` directly instead.

$ grep "^\w\|--" apt-listchanges-20260225.txt
apt-listchanges: Noticias
-------------------------
tor (0.2.0.26-rc-1) experimental; urgency=critical
 -- Peter Palfrader <weasel@debian.org>  Tue, 13 May 2008 12:49:05 +0200
pulseaudio (11.1-2) unstable; urgency=medium
 -- Felipe Sateler <fsateler@debian.org>  Fri, 17 Nov 2017 20:13:57 -0300
libx11 (2:1.1-1) experimental; urgency=low
 -- Josh Triplett <josh@freedesktop.org>  Fri, 24 Nov 2006 17:36:55 -0800
socat (1.7.1.3-1.3) unstable; urgency=low
 -- Jakub Wilk <jwilk@debian.org>  Sun, 22 Apr 2012 10:49:00 +0200

Thank you!!

Today on a testing machine I got old news for libx11 2:1.1-1 (it was
updated from 2:1.8.12-1+b1 to 2:1.8.13-1) and pulseaudio 11.1-2 (it was
updated from 17.0+dfsg1-2+b2 to 17.0+dfsg1-2.1). I've also checked
/var/lib/apt/listchanges on this machine and it seems empty (113 bytes).
There is no /var/lib/apt/listchanges-snapshots.
/var/lib/apt/listchanges-old is not empty, but I'm not sure how useful it
is *after* those news entries were shown. OTOH it doesn't contain 'libx11'
or 'pulseaudio' keys.