Lost in Changelogs

I hope you can help me better understand the flow of changelogs.

Today we have again a small update for manjaro and it is a single package:

powerdevil-5.15.2-2

hopefull I ran pacman -Qc powerdevil to get the changelog. But as so often it did not show any.

So first question: Is there a general way to get to the changelog? Or is this an individual hunt for each package? I would even be willing to consider a code diff a changelog in this case.

Second question: If this is not possible. Which I fear is the case.
How is the process. Where does the change log get lost. I assume that there always is one initially set by the developers. I don’t want to play the blame game. I want to know if maybe I can put some effort into developing a tool to automate getting this. I think this would be a worthwhile improvement.

I am still relatively new to Linux so my understanding of the workings behind the curtain is still very limited.

it was a stability fix, powerdevil was crashing. it got fast-tracked so the changelog may not have been dealt with. either way, you need it :wink:

https://bugs.kde.org/show_bug.cgi?id=403776#c20

1 Like

No doubt. I installed right away. This is also not about being “selective” as I don’t think it is wise to leave the default path more than absolutely necessary under Linux.

It is about being curious what cool features I got, or which quirks might finally be gone.

Thank you for the link. It shows that there is a change log, as I assumed. So normally I would expect
pacman -Qc powerdevil to return at least
“Fix crash (FS#61926)”

running pacman -Qc returns a changelog for only 1 in a hundred packages. So obviously this feature is not really delt with at all. Can’t this be automated somehow, to get the changelogs, when providing the updates?

Add me.

I love reading changelogs and I wish I could have a list of them to read before any major update. I know 98% of users don’t care about them (I even hear some users actually update without looking at the package list :flushed:).

Maybe someone will come up with something that generates a easy readable changelog for all packages (1 or 100) marked for update.

Changelogs are not collated, but you can view the changes yourself.

Powerdevil is maintained by Arch, so go to the package page.

https://www.archlinux.org/packages/extra/x86_64/powerdevil/

Click on View Changes and you get the commit list for a package.
https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/powerdevil

Listed here is the patch commit to fix the crashing issue.

https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/powerdevil&id=5bb1a6881928539dd89317f7f98f75bb66af554b

You can also go to the upstream URL which should have all changes for version upgrades, depends on the developer.

All the source code is also available for the extra keen.

3 Likes

Ok, how do I know who maintains a package?

Its in the package details.

$ pacman -Qi powerdevil
Name            : powerdevil
Version         : 5.15.2-2
...
Packager        : Antonio Rojas <arojas@archlinux.org>
Build Date      : Thu 07 Mar 2019 03:05:42 AEDT
...
Validated By    : Signature
$ pacman -Qi systemd
Name            : systemd
Version         : 241.556-1
...
Packager        : Philip Mueller <philm@manjaro.org>
Build Date      : Thu 07 Mar 2019 05:37:36 AEDT
...
Validated By    : Signature

Manjaro maintained package commit history would be available in gitlab.

2 Likes

Tell me if I am wrong, but while starting to write a script I noticed, this is are not the changelog’s/diff of powerdevil code, but only the package manager’s changes, when integrating it.

For example the changelog of terminator

2018-04-10	upgpkg: terminator 1.91-6	grazzolini
2017-03-27	upgpkg: terminator 1.91-5	grazzolini
2017-03-23	upgpkg: terminator 1.91-4	grazzolini
2017-03-01	upgpkg: terminator 1.91-3	grazzolini
2017-02-28	upgpkg: terminator 1.91-2	grazzolini
2017-02-28	upgpkg: terminator 1.91-1	grazzolini
2017-02-11	upgpkg: terminator 1.90-2	bgyorgy
2017-01-03	upgpkg: terminator 1.90-1	grazzolini
2016-12-09	upgpkg: terminator 1.0-2	grazzolini
2016-12-09	upgpkg: terminator 1.0-1

Not exactly helpful either.

The changelog I was looking for in case of terminator would be rather this:

The pacman -Qc is only used for changes to the package. Like new upstream version or rebuild. It is not the changelog of the software in that package.

It also needs to be create by hand, so only some maintainer do that.

A quote form Allan McRae, since it is a little bit older you need to replace svn with git.

And very few official packages will have one as the vast majority of the developers find it a waste of time… especially given we are somewhat verbose in the svn commit message.
https://bbs.archlinux.org/viewtopic.php?pid=861895#p861895

2 Likes

For the actual code changes you would have to go upstream and view each commit associated with a new version bump, assuming the developer uses public accessible version control.

Arch builds the packages, it doesn’t develop them, rarely patches them, but sometimes the changes / PKDBUILD details can fast track what you are looking for upstream.

I found out about the change by reading @sueridgepipe’s post in the Plasma discussion thread. I didn’t know it was even broken because I’d not noticed it fail on either of my systems, both of which have batteries to monitor. One a notebook and the other has a UPS hooked up to the USB port.

You do realise Manjaro is not a commercially backed distribution with paid employees developing and supporting it?

The Manjaro folk can be counted on fingers and do any work in their freetime as most are still in full-time employment or have other real life commitments. It started out as a hobby and quite frankly is still technically albeit done to an exceptionally high standard.

If you or anyone else with the coding skills can help out and develop an automated way to achieve such collation it would be fantastic and much appreciated I am sure. I’m too rusty these days to even go there myself, I haven’t had the time to keep up with language developments either. Rust (the language) is something that interests me though. My last really active days were in the late 90s to early 00s when I didn’t have a Wife and kids to look out for. These days I am dealing mainly with hardware and network infrastructure on a day-to-day basis. I sub-contract a lot of coding and software support work as their aren’t enough hours in the day and I prefer the building and testing work.

Ofc, and I would never expect a manual solution. Else I would have requested a changelog like this:

Yes, I am a developer and also wrote countless automation scripts in bash nowadays. And would offer my assistance if this is feasible/wanted. But as I said, I have no idea of the process a maintainer has to go through yet.

I guess most, if not all packages are maintained in one of the major VCS like CVS, svn or git.
So it should be feasible to automate a generic changelog from the commit messages. While certainly not perfect, better than nothing. Ofc if the package is not in version control it will still have no change log. Or if the commit messages are empty/cryptic, it will not help much. But GIT changed the playing field somewhat. With its twitter like one line summary encouragement per commit as well as its staging mechanism that makes it easy to commit in small dosages of descriptive changes. Commit histories have become far more reflective of a real change log.

Also if this would be implemented, one could also somewhat better judge the quality of a project/package by seing if such a commit log is available/clean or not.

No risk, no fun :smiley: :wink:

3 Likes

To be honest, I was including myself in that group of people :joy:

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.