Bug#1054298: apt-listchanges: 4.4 still/again showing old changelogs
On 2023-10-21 Jonathan Kamens wrote: > On 10/21/23 12:24, Andreas Metzler wrote: > > However I still do not get it. > > * Is there a useful scenario where someone would set save_seen=none in > >the apt stanza? > *shrug* I don't know. That design decision was made long before my time. I > don't see any good reason to change it given that if anybody /is/ taking > advantage of it for whatever reason, then doing so would cause them trouble. Hello, I have played around a little bit, upgrading a single package, with and without save_seen=none: I could not see a difference in behavior for apt-listchanges 3.x. It showed new changelog entries compared to the installed version even if the same upgrade was previously aborted. With apt-listchanges there is a difference in behavior, with save_seen=none it showed new changelog entries compared to the installed version even on abort (like 3.x), with save_seen=/var/lib/apt/listchanges.db it did not re-show changes if the previous try was aborted. I could *not* reproduce this bug, i.e. apt-listchanges showing older changelog entries than the one installed. Assuming 3.x behavior is correct (see below) I still have no idea what user-visible changes save_seen is supposed to trigger. Is this a performance optimization or an implementation detail? Afaiu apt-listchanges > > * Would I be reshown changelog entries when I had already seen them > >before but aborted the upgrade if save_seen=/var/lib/apt/listchanges > >was set? > In version 3.x of apt-listchanges, if you aborted the update and then ran it > again you would be shown the changes again. In the current 4.x version of > apt-listchanges, you will /not/ be shown the changes again if you abort and > rerun an update. > Your question has prompted me to think further about this and now I'm not > convinced the change in behavior in 4.x is correct. What do you think? Do > you think the program should only "commit" the changes to the database and > not display them again if the user goes through with the update? Yes I think the old behavior is correct. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1054298: apt-listchanges: 4.4 still/again showing old changelogs
On 10/21/23 12:24, Andreas Metzler wrote: However I still do not get it. * Is there a useful scenario where someone would set save_seen=none in the apt stanza? *shrug* I don't know. That design decision was made long before my time. I don't see any good reason to change it given that if anybody /is/ taking advantage of it for whatever reason, then doing so would cause them trouble. * Would I be reshown changelog entries when I had already seen them before but aborted the upgrade if save_seen=/var/lib/apt/listchanges was set? In version 3.x of apt-listchanges, if you aborted the update and then ran it again you would be shown the changes again. In the current 4.x version of apt-listchanges, you will /not/ be shown the changes again if you abort and rerun an update. Your question has prompted me to think further about this and now I'm not convinced the change in behavior in 4.x is correct. What do you think? Do you think the program should only "commit" the changes to the database and not display them again if the user goes through with the update? jik
Bug#1054298: apt-listchanges: 4.4 still/again showing old changelogs
On 2023-10-21 Jonathan Kamens wrote: > I just noticed this: > On 10/21/23 01:39, Andreas Metzler wrote: [...] > > *save_seen=none* > How did you end up with "save_seen=none" here? That's not the default, or at > least it shouldn't be if everything is working as it should. The default > setting is "save_seen=/var/lib/apt/listchanges". Hmm. [...] > If you made that config change, and you don't want to see duplicate > changelog entries, then you need to set it back to > "save_seen=/var/lib/apt/listchanges". If you didn't make that change, then > we need to figure out how it got made, and that's the bug that needs to be > fixed. Let me know. [...] I think I know why. During testing 4.x at one point in time I did a purge and reinstall and had to reanswer debconf questions and stumbled upon this: +--- | A record of already displayed changes can be kept in order to avoid | displaying them again. This is useful, for example, when retrying a | upgrade. | | Should apt-listchanges skip changes that have already been seen? +--- Which was rather mysterious to me. ;-) The only thing I could map to interaction with apt-listchanges was "This is useful, for example, when retrying a upgrade." - When doing an upgrade I am shown the changelog and can abort. If I abort and retry later I would want to be shown the new changelogs entries again since I want to know changes to be implemented, i.e. the difference between installed version and new version, no matter whether the entries were already shown in an aborted upgrade. So I understood this question was for this special subcase and answered accordingly. I did not expext for apt-listchanges having a mode when invoked by apt to always ancient changelogs. I gather my understanding was incorrect. ;-) However I still do not get it. * Is there a useful scenario where someone would set save_seen=none in the apt stanza? * Would I be reshown changelog entries when I had already seen them before but aborted the upgrade if save_seen=/var/lib/apt/listchanges was set? cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1054298: apt-listchanges: 4.4 still/again showing old changelogs
I just noticed this: On 10/21/23 01:39, Andreas Metzler wrote: -- Package-specific info: ==> /etc/apt/listchanges.conf <== [apt] frontend=pager which=both no_network=false email_address=root email_format=text confirm=true headers=false reverse=false *save_seen=none* How did you end up with "save_seen=none" here? That's not the default, or at least it shouldn't be if everything is working as it should. The default setting is "save_seen=/var/lib/apt/listchanges". If you tell apt-listchanges not to use the seen database then it's certainly doing to display lots of duplicate changelog entries! That is expected behavior. If you made that config change, and you don't want to see duplicate changelog entries, then you need to set it back to "save_seen=/var/lib/apt/listchanges". If you didn't make that change, then we need to figure out how it got made, and that's the bug that needs to be fixed. Let me know. Thanks, Jonathan Kamens
Bug#1054298: apt-listchanges: 4.4 still/again showing old changelogs
Thanks for reporting. Can you email me the snapshot file in /var/lib/apt/listchanges-snapshots with the timestamp corresponding to when this occurred, or it it's too big to email upload it somewhere and share the link? Just to me, please, not to BTS. Thank you! On October 21, 2023 1:39:15 AM EDT, Andreas Metzler wrote: >Package: apt-listchanges >Version: 4.4 >Severity: normal > >Hello, > >I had tested 4.0 and 4.1 and had seen old changelogs. Upgrading to 4.2 >did not fix this (although it should have) so I purged apt-listchanges, >manually removed /var/lib/apt/listchanges* and reinstalled >apt-listchanges. Things seemed to work for some time. > >Then today I upgraded to 4.4, and afterwards did a dist-upgrade and was >shown e.g: > >linux (4.19.37-6) unstable; urgency=high >[...] > -- Salvatore Bonaccorso Fri, 19 Jul 2019 00:23:17 +0200 > >cu Andreas > >-- Package-specific info: >==> /etc/apt/listchanges.conf <== >[apt] >frontend=pager >which=both >no_network=false >email_address=root >email_format=text >confirm=true >headers=false >reverse=false >save_seen=none >capture_snapshots=auto >snapshot_dir=/var/lib/apt/listchanges-snapshots > > >-- System Information: >Debian Release: trixie/sid > APT prefers testing > APT policy: (500, 'testing'), (1, 'experimental') >Architecture: amd64 (x86_64) > >Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) >Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE not >set >Shell: /bin/sh linked to /usr/bin/dash >Init: systemd (via /run/systemd/system) >LSM: AppArmor: enabled > >Versions of packages apt-listchanges depends on: >ii apt2.7.6 >ii debconf [debconf-2.0] 1.5.82 >ii python33.11.4-5+b1 >ii python3-apt2.6.0 >ii python3-debconf1.5.82 >ii sensible-utils 0.0.20 >ii ucf3.0043+nmu1 > >apt-listchanges recommends no packages. > >Versions of packages apt-listchanges suggests: >ii exim4-daemon-light [mail-transport-agent] 4.97~RC2-2 >ii firefox [www-browser] 118.0.2-1 >ii lynx [www-browser] 2.9.0dev.12-1 >ii mlterm [x-terminal-emulator] 3.9.3-1 >ii python3-gi 3.46.0-1 >ii w3m [www-browser] 0.5.3+git20230121-2 >ii xterm [x-terminal-emulator]385-1 > >-- debconf-show failed >~ >~ >~ >~ > -- Sent from my phone. Please excuse brevity and autocorrect errors.
Bug#1054298: apt-listchanges: 4.4 still/again showing old changelogs
Package: apt-listchanges Version: 4.4 Severity: normal Hello, I had tested 4.0 and 4.1 and had seen old changelogs. Upgrading to 4.2 did not fix this (although it should have) so I purged apt-listchanges, manually removed /var/lib/apt/listchanges* and reinstalled apt-listchanges. Things seemed to work for some time. Then today I upgraded to 4.4, and afterwards did a dist-upgrade and was shown e.g: linux (4.19.37-6) unstable; urgency=high [...] -- Salvatore Bonaccorso Fri, 19 Jul 2019 00:23:17 +0200 cu Andreas -- Package-specific info: ==> /etc/apt/listchanges.conf <== [apt] frontend=pager which=both no_network=false email_address=root email_format=text confirm=true headers=false reverse=false save_seen=none capture_snapshots=auto snapshot_dir=/var/lib/apt/listchanges-snapshots -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-listchanges depends on: ii apt2.7.6 ii debconf [debconf-2.0] 1.5.82 ii python33.11.4-5+b1 ii python3-apt2.6.0 ii python3-debconf1.5.82 ii sensible-utils 0.0.20 ii ucf3.0043+nmu1 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii exim4-daemon-light [mail-transport-agent] 4.97~RC2-2 ii firefox [www-browser] 118.0.2-1 ii lynx [www-browser] 2.9.0dev.12-1 ii mlterm [x-terminal-emulator] 3.9.3-1 ii python3-gi 3.46.0-1 ii w3m [www-browser] 0.5.3+git20230121-2 ii xterm [x-terminal-emulator]385-1 -- debconf-show failed ~ ~ ~ ~
