It got clear yesterday why many Python-projects are going to be a catastrophe on the long run: We cannot rely on them as we never know if the same dependency-tree is also working for the next released stable version. In regards to auto-cpufreq: This is not working and the dependency-tree changed drastically more to even no longer really focussed to be offline possible compiled as stable tarball. Upstream git was now included and demanded for further compilation. Also pip and we have a clear reasoning why we reject package-management within packages. We have one package-manager, we do not need another one or even worse like in that case pip sideloading data from pypi at build-time.
That's the reasoning why we remove also Python-packages when upstream-maintainers are doing such ways. It is their right to do, no doubt. But from security-point this is and stays a catastrophe. Who knows exactly the full list of dependencies in the sideload? And how to verify them being trustworthy in that concrete version downloaded? The xz-issue showed exactly the point. And why do many maintainers ignore this in the Python-sphere? We end up at a point where every new release is going to be a hard and long way of inclusion. This cannot be the goal because long-term and stable focused systems suffer under such circumstances.
Thread closed!
]]>Link scrambled
Please do not offer pre-compiled binaries and instead the sources for compilation. Thanks!
You should however then change to version 2.0.
That is the newest version of auto-cpufreq that can be used. Each one after, doesn't work without big changes.
IE, I don't know how to make 2.1 or newer work. 
Here is a link the way you want it to be though.
EDIT: Needs fixing.
To quote:
If you miss something, try it yourself building, make proposals and share your insights.
There is also a thread regarding packages: https://forums.hyperbola.info/viewtopic.php?id=773
If you like to provide a port / package for cpupower working on Hyperbola GNU/Linux-libre, feel free to provide one and feel always invited to do so. You can create also here in this category a new thread for your own made package and port as cpupower is meant as running service and therefore needs for sure definitions for openrc and runit.
But to say it clear: I have for the moment no time to provide any new package as I'm busy with 0.4.5 for Hyperbola GNU/Linux-libre. We are following there our roadmap: https://wiki.hyperbola.info/doku.php?id … y_way_v045
]]>D-Bus
upower
polkit
HyperbolaBSD itself is also not supporting bloated implementations alike those named.
]]>Good evening. Please tell me what Hyperbola tool is used to manage energy consumption, for a notebook.
If there is, please write the name of the package.
Thank you.
This will work for now, while its GNU/Linux-Libre but after HyperbolaBSD is out, it likely won't work anymore unless fixes are made.
upload.disroot.org/r/k4C29osW#WTJcIiXOlcwPD78SeezoIJiz0BOmnt+ssumcNCVMIgw=
If you prefer though, I could just give you a PKGBUILD I have. Although, I would need to change the key signatures.
]]>