Jonathan Kamens <j...@kamens.us> writes: > TLDR this will be fixed in 4.1 and it's a significant enough fix that I > should probably release 4.1 to experimental
Great, thank you! Let me know when that's ready to go. > So, this was one of the edge cases mentioned in the design documentation > for the revamped changelog filtering logic: when the persistent database > is not being used in a particular invocation of the program or there is > no data for a particular package in the database (this is what you ran > into), and the changelog data for a package is being fetched over the > network because it is not present in the package, we can't use > historical changelog data to determine which entries to display and > which to filter out. I probably should know this, but I guess I don't: why did you have to fetch changelog data for those packages from the network? Both of them ship truncated changelogs, but the changelogs are truncated well, well before any entries that would be of any interest to apt-listchanges on my system. I probably don't understand the design model here, but I would have expected changelogs to only be fetched over the network if apt-listchanges exhausted the changelog shipped with the package and still couldn't find the beginning of the entries it wanted to display. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
