Zenpower has been unmaintained for at least 5 years now, and there is also a newer fork of it called Zenstats that has support for AM5. I have fixed the package with this commit: https://github.com/gentoo/guru/commit/1d7c85e619f112ad2eddbef4bd033c15073fc47a However, I am still filing a bug because I want to make sure it is OK to package the newer fork, Zenstats. Reproducible: Always
Thanks for the bug report, I have drop 0.2.0 because when the repo was still alive that version was even older (I could have created a version with the latest commit instead) It normal I didn’t notice the repo was dead since I didn’t need to rebuild the package, and I only have a Zen3 device, but since a Zenstats exist I think I will change the package to pull sources form there instead (at least also supports Zen5)
OK sounds good, thanks for the quick response.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=751e858f5a2540ff2e8ff75343e04f5566bce0d7 commit 751e858f5a2540ff2e8ff75343e04f5566bce0d7 Author: Gonçalo Negrier Duarte <gonegrier.duarte@gmail.com> AuthorDate: 2024-12-29 11:50:31 +0000 Commit: Gonçalo Negrier Duarte <gonegrier.duarte@gmail.com> CommitDate: 2024-12-29 11:50:31 +0000 zenpower3: add 0.2.0-r1 9999, drop 0.2.0 * update ebuild to use zenstats (mantain fork of zenpower3) * update Makefile patch to work with clang Closes: https://bugs.gentoo.org/947057 Closes: https://bugs.gentoo.org/947153 Signed-off-by: Gonçalo Negrier Duarte <gonegrier.duarte@gmail.com> sys-kernel/zenpower3/Manifest | 2 +- ....2.0-use-symlink-to-detect-kernel-version.patch | 9 ----- ...wer3-use-symlink-to-detect-kernel-version.patch | 37 ++++++++++++++++++ sys-kernel/zenpower3/metadata.xml | 2 +- sys-kernel/zenpower3/zenpower3-0.2.0-r1.ebuild | 45 ++++++++++++++++++++++ sys-kernel/zenpower3/zenpower3-0.2.0.ebuild | 32 --------------- sys-kernel/zenpower3/zenpower3-9999.ebuild | 45 ++++++++++++++++++++++ 7 files changed, 129 insertions(+), 43 deletions(-)
So, this "maintained" fork has a single commit in three years over the repo it's forked from (koweda/zenpower3, also a fork, but one with actual contributions) and the owner's own GH profile states that they've deserted the site for ideological reasons - not a good look! But I'm not here to throw mud - here's some actual code review. 90% of that commit by weight is a cosmetic find-and-replace rebranding (called "refactoring" by the author) which breaks any userspace not expecting sysfs hwmon paths to get randomly rugpulled, and the remainder adds 2 PCI IDs for Zen4/5 and some dubiously copy-pasted code (do Zen4 and Zen5 really have the same model ID 0x61? why do they both include a workaround meant for Zen1? what happens when this code runs on a non-0x61 AM5 part?) On the Gentoo side this should have had an accompanying pkgmove and/or pkg_postinst message to explain to users the how and especially the **why** of their impending system breakage. The useful parts of the "refactoring" patch, if they turn out to be correct at all, could've been extracted to a patch in ${FILESDIR} and upstream changed to the less disruptive one. That ship has sailed; I'm just leaving this comment here to give closure to anyone else trying to figure out why modprobe is suddenly throwing errors and their system monitoring has stopped working.
I don't think any ship has sailed given it's been in GURU for less than a week. But it's also better to file a new bug than comment on closed ones usually.
(In reply to Sam James from comment #5) Sorry. I was a bit harsh, nothing personal meant at anyone here. Having to interact with certain GUI system monitors leaves me a bit exasperated (not naming names, but their bugzilla has 178 open bugs for the program and most of those are people complaining about the UI :), and there's the prospect of doing that all over again if this gets reverted. It'd be nice if there was a way to get permanent identifiers through udev for hwmon stuff but I don't think it's possible.
(In reply to Enne Eziarc from comment #6) > (In reply to Sam James from comment #5) > > Sorry. I was a bit harsh, nothing personal meant at anyone here. Having to > interact with certain GUI system monitors leaves me a bit exasperated (not > naming names, but their bugzilla has 178 open bugs for the program and most > of those are people complaining about the UI :), and there's the prospect of > doing that all over again if this gets reverted. > > It'd be nice if there was a way to get permanent identifiers through udev > for hwmon stuff but I don't think it's possible. Yeah its not a great look to act like that. I filed the bug to have the package fixed, not for someone to rant in my bugzilla post. Jeez.
