Zypper history: summarise rpm changes
I have a python script that can summarise RPM change-logs for anything install by zypper in the past N days. The idea being to work around the limitation that the Tumbleweed release announcements only lists the DVD changes, but the release almost always contains more than that. I recently gave it a spring-clean for python3, and have now shared it as a gist in case it may be of use to others: https://gist.github.com/digitaltrails/094cd5a5d08670560c8bb199041321a6 Usage is as follows: Usage: zypphist.py [options] Report change log entries for recent zypper installs. Options: -h, --help show this help message and exit -i ZYP_INSTALL_DAYS, --installed-since=ZYP_INSTALL_DAYS Include anything zypper installed up to the specified days ago(default 1). -c RPM_CHANGE_ENTRIES, --change-entries=RPM_CHANGE_ENTRIES For matched zypper installs, report a given number of dated RPM change-log entries (default 1). Example: sudo python3 zypphist.py --installed-since=3 Sample output for one package: ================================================== +Package: 2024-09-14 09:02:57 nvidia-utils-G06 ------------------------------ * Tue Aug 13 2024 Stefan Dirsch <sndirsch@suse.com> - Update to 550.107.02 * Fixed a race condition involving modeset ownership which could lead to flip event timeout errors when enabling the 'fbdev' kernel module parameter in nvidia-drm. * Fixed a regression that caused nvidia-powerd to exit when nvidia-dbus.conf was not present in the /etc/dbus-1/system.d/ directory. * Fixed a bug that could cause memory corruption while handling ACPI events on some notebooks. * Fixed a bug that could cause external displays to become frozen until the next modeset when using PRIME Display Offloading with the NVIDIA dGPU acting as the display offload sink. The one limitation is that the script cannot work out how many rpm change log entries might apply to a release and defaults to one. Michael
On 9/14/24 5:25 PM, Michael Hamilton wrote:
I have a python script that can summarise RPM change-logs for anything install by zypper in the past N days.
The idea being to work around the limitation that the Tumbleweed release announcements only lists the DVD changes, but the release almost always contains more than that.
I recently gave it a spring-clean for python3, and have now shared it as a gist in case it may be of use to others:
https://gist.github.com/digitaltrails/094cd5a5d08670560c8bb199041321a6
Usage is as follows:
Whoa! Works quite nicely, but the number of lines of output was unexpectedly large. I captured it to check what 4 days worth of Tumbleweed changelogs amounted to: $ wc -l < tmp/zypyscroll.txt 5490 No wonder it looked like things were streaming by fast. Not a bad thing at all, just means you need to either pipe to a file or pager (or just use the scrollbar) to step through the output. I'd always just used "rpm -q -a --queryformat ...", so it's nice to have the "..." already fixed for changelogs. Thanks! -- David C. Rankin, J.D.,P.E.
On Sunday 15 September 2024, David C. Rankin wrote:
On 9/14/24 5:25 PM, Michael Hamilton wrote:
I have a python script that can summarise RPM change-logs for anything install by zypper in the past N days.
The idea being to work around the limitation that the Tumbleweed release announcements only lists the DVD changes, but the release almost always contains more than that.
I recently gave it a spring-clean for python3, and have now shared it as a gist in case it may be of use to others:
https://gist.github.com/digitaltrails/094cd5a5d08670560c8bb199041321a6
Usage is as follows:
Whoa!
Works quite nicely, but the number of lines of output was unexpectedly large. I captured it to check what 4 days worth of Tumbleweed changelogs amounted to:
$ wc -l < tmp/zypyscroll.txt 5490
No wonder it looked like things were streaming by fast. Not a bad thing at all, just means you need to either pipe to a file or pager (or just use the scrollbar) to step through the output.
I'd always just used "rpm -q -a --queryformat ...", so it's nice to have the "..." already fixed for changelogs.
Thanks!
Thanks for the feedback - it inspired me to update the gist. I've added a -g (--group) option that groups packages that have the same change-log text. That greatly reduces the output, but at the cost of using RAM to hold the accumulated text until the script finishes (so there is quite a delay before any output). The default is not to group. Sample output: ================================================== +Package: 2024-09-14 09:02:49 nvidia-compute-G06 +Package: 2024-09-14 09:02:50 nvidia-compute-utils-G06 +Package: 2024-09-14 09:02:52 nvidia-gl-G06 +Package: 2024-09-14 09:02:53 nvidia-gl-G06-32bit +Package: 2024-09-14 09:02:54 nvidia-video-G06 +Package: 2024-09-14 09:02:55 nvidia-video-G06-32bit +Package: 2024-09-14 09:02:56 nvidia-compute-G06-32bit +Package: 2024-09-14 09:02:57 nvidia-utils-G06 +Package: 2024-09-14 09:02:57 nvidia-drivers-G06 ------------------------------ * Tue Aug 13 2024 Stefan Dirsch <sndirsch@suse.com> - Update to 550.107.02 * Fixed a race condition involving modeset ownership which could lead to flip event timeout errors when enabling the 'fbdev' kernel module parameter in nvidia-drm. * Fixed a regression that caused nvidia-powerd to exit when nvidia-dbus.conf was not present in the /etc/dbus-1/system.d/ directory. * Fixed a bug that could cause memory corruption while handling ACPI events on some notebooks. * Fixed a bug that could cause external displays to become frozen until the next modeset when using PRIME Display Offloading with the NVIDIA dGPU acting as the display offload sink.
On 15.09.2024 03:10, Michael Hamilton wrote:
Thanks for the feedback - it inspired me to update the gist. I've added a -g (--group) option that groups packages that have the same change-log text.
Just check the source rpm. Same changelog means they are built from the same SRPM. rpm --qf '%{sourcerpm}'
On Sunday 15 September 2024, Andrei Borzenkov wrote:
On 15.09.2024 03:10, Michael Hamilton wrote:
Thanks for the feedback - it inspired me to update the gist. I've added a -g (--group) option that groups packages that have the same change-log text.
Just check the source rpm. Same changelog means they are built from the same SRPM.
rpm --qf '%{sourcerpm}'
Thanks, good suggestion. I experimentally modified it to do: rpm -q --qf '%{sourcerpm}\n' --changelog Grouping by sourcerpm didn't speed up the script. So a smaller key wasn't a win. I still have to accumulate the text, so no win on RAM. I could refrain from retrieving the changelog until the final pass, but that doubles the execs of rpm. I could potentially use the non-standard DiskDict module, to keep the dictionary on disk - probably slower though. Grouping by sourcerpm could be argued to be more accurate because unrelated rpms will not be grouped together just because they have the same change-log text. If different sourcerpms do share the same change-log text, then the output for those rpms will be duplicated. So some output compression may be lost. It does add a smidgen of complexity, but it feels tidier. I'll leave it to simmer and see what other suggestions/opinions come in. If it begins to be used widely I suspect I should do something to reduce the number of execs of rpm, that may be a big win on speed (an xargs kind of approach). Out of curiosity I tried python3.13t with and without the JIT, didn't seem to make a notifiable difference. Michael
On Sunday 15 September 2024, Andrei Borzenkov wrote:
On 15.09.2024 09:09, Michael Hamilton wrote:
If it begins to be used widely I suspect I should do something to reduce the number of execs of rpm,
RPM had python bindings for as long as I remember.
Thanks, I should have guessed. I could not resist changing the script to use it (the gist has been updated). It's only three times faster though.
On 9/15/24 3:34 AM, Michael Hamilton wrote:
RPM had python bindings for as long as I remember. Thanks, I should have guessed.
I could not resist changing the script to use it (the gist has been updated). It's only three times faster though.
300% is nothing to snivel at, next a rewrite in C :) -- David C. Rankin, J.D.,P.E.
On Sunday 15 September 2024, Andrei Borzenkov wrote:
On 15.09.2024 03:10, Michael Hamilton wrote:
Thanks for the feedback - it inspired me to update the gist. I've added a -g (--group) option that groups packages that have the same change-log text.
Just check the source rpm. Same changelog means they are built from the same SRPM.
rpm --qf '%{sourcerpm}'
I added options to group either way: -g, --group group packages with duplicate change-log entries -s, --group-by-source group packages from same source rpm Grouping by changelog text results in a smaller report, but it depends on what's in the release. About 30% smaller for recent history (I've yet to add back source and repo name reporting when grouping by changelog.) Michael
participants (3)
-
Andrei Borzenkov -
David C. Rankin -
Michael Hamilton