Dear Maintainer,

From my perspective, this is technically not a new bug report; it is
another part of the wishlist item reported as bug #841837, which was not
addressed by the change which led that bug report to be closed.

The change made under that bug report resulted in identical binNMU
entries being folded together, and listed with one entry per identical
changelog, at the end of the list. This is a major improvement, and
addresses the large majority of cases where such identical entries made
change lists hard to read.

However, as mentioned in that wishlist bug report, binNMUs are not the
only context in which substantially-identical changelogs occur:

I am once again seeing this, albeit at a smaller scale, with a mass
update to KDE-related packages. Specifically (although I cannot
guarantee that this is the full set of affected packages, without
spending more time on analyzing each changelog entry than I want to
invest), kcrash, kdbusaddons, and kemoticons have changelog entries for
version 5.70.0-1 which differ only in the package name and the exact
timestamp.

(Some other packages involved in the same mass update seem to include a
changelog section for that version which is identical to the one from
the packages named, but also have an additional changelog section for
the same version to describe other changes which are specific to each
package. Otherwise, there would probably be closer to a dozen packages
which I could easily list. Splitting out such identical sections from
otherwise-differing changelog entries would clearly do more harm than
good.)

Part of the request made under that bug report was for all such
identical changelog entries to be folded together, much (if not
necessarily exactly) as is now done with binNMUs; whether the identical
changelog entries result from binNMUs or from something else is not
relevant to that purpose.

Please either extend the current binNMU folding to catch other types of
identical changelog entries and treat them similarly, or add an
additional feature (possibly requiring enablement via an option) to
cause such additional identical entries to be folded together in a
similar way.

(I can easily see that this may be a less commonly desired behavior, and
that indeed some people may prefer to have it not happen, given that it
would break up the orderly listing of package versions in cases where
other versions' changelog entries to the same packages are not similarly
identical. As such, making this an optional behavior which has to be
enabled would probably be more appropriate than making it the default.)

Another notable special case is the current wave of formally sourceful
NMUs by the Reproducible Builds team to pick up .buildinfo metadata
for architecture-independent packages [1]; these NMUs all carry the
changelog text

  * Non maintainer upload by the Reproducible Builds team.
  * No source change upload to rebuild on buildd with .buildinfo files.

Could you please take a look?

Thanks!

[1] http://layer-acht.org/thinking/blog/20201231-no-source-change-source-uploads/

packages, and this time I've taken the trouble to make a count.

If that count is accurate, there appear to be as many as *43* different
changelog entries (as presented by apt-listchanges) which are identical
except for the displayed package name and exact timestamp. In all cases,
the version number given is either 5.97.0-1 or an epoch-prefixed version
of the same.

This is a considerably larger degree of changelog-list clutter than with
the three packages referenced in the message which opened this bug
report as having identical changelog entries shown at once, and
represents a correspondingly larger potential benefit from the ability
to have them folded together into a single condensed entry.

I have a fix pending which merges changelog entries which are _entirely_
identical, which I implemented as part of addressing bug #383803, but I
gather that fix won't work here. If I'm understanding correctly, the
issue discussed here is the content of the changelog entry being
identical but the package name in the changelog entry (just to be clear:
we're talking about the package name written in the entry in the
changelog file, not the package that the entry is found in, right?) or
its date being different.

Can you perhaps provide me of an example of two specific deb files
somewhere I can download online which demonstrate this phenomenon so I
can reproduce the issue? I suspect with a reproducible test case in hand
it will be relatively straightforward to add a fix for this issue to the
fix I already have pending for the other one.

I apologize for the delayed response; for no reason I have yet managed
to identify, I seem to have not received mail about any of the comments
on this bug report.

I believe I saw some combine-able changelog entries in a set of updates
I installed just this past week, but I did not bother to confirm that
they were sufficiently identical to have been combined, nor to remember
what the packages involved were; I had no reason to expect those details
to be any more important than they have been in the past several years.

However, I did mention a few specific package names and associated
version numbers in the original message with which I filed this bug
report:

I believe it should be possible to obtain the .deb files for these from
snapshot.debian.org, assuming that is currently functional.

If my recollection is correct, those are the package names as they were
shown in the apt-listchanges output; I do not know offhand whether that
represents names of source packages, binary packages, neither of the
above, or some combination.

Is that information sufficient to be able to provide a reproducer for
testing potential fixes?

Hi,

You didn't get my previous response because I didn't send it to
*-submitter. I didn't realize at the time I sent it that messages aren't
sent to bug authors by default. Now I know. ;-)

I took a look at some of the packages you mentioned, and the executive
summary is that the KDE packages are... weird. They have nearly
identical changelog entries, but they come from different source
packages, use different package names in each changelog entry, and use
slightly different dates in their trailers. All these together make it
very challenging for apt-listchanges to dedup them in any way that isn't
a gross hack and/or risks accidentally deduping other changelog entries
that shouldn't have been.

I reached out to the KDE/Qt maintainers to ask for their advice about
this and to see if anything can be done to make these changelog entries
more consistent so they can be more safely deduped.

Because of the circumstances outlined above, this is still an issue in
the upcoming version of apt-listchanges currently in experimental, and I
don't know when/if I'm going to be able to address it. I agree with you
that different behavior would be better, but it is just not clear what
the right way to achieve it is.

   jik