cant open auto-cpufreq in a fresh installed kubuntu

[eret9616]

Fill out information requested in this template, without doing so issue will be ignored & closed!

Have you tried?

• Searching through existing/closed issues to see if your bug has already been already submitted?
• If installation failed with auto-cpufreq-installer,have you tried installing auto-cpufreq using Snap package?
• Have you tried configuring auto-cpufreq?
• Have you tried suggestions in troubleshooting section?

Error output:

Add/paste error output in case of failed installation or other failing component

---

System information:

Add/paste output of:

➜  auto-cpufreq git:(master) ✗ auto-cpufreq --debug
Traceback (most recent call last):
  File "/opt/auto-cpufreq/venv/bin/auto-cpufreq", line 4, in <module>
    __import__('pkg_resources').run_script('auto-cpufreq==1.9.9+9f132bdc.post6.dirty', 'auto-cpufreq')
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/auto-cpufreq/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 3248, in <module>
    @_call_aside
     ^^^^^^^^^^^
  File "/opt/auto-cpufreq/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 3223, in _call_aside
    f(*args, **kwargs)
  File "/opt/auto-cpufreq/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 3261, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/auto-cpufreq/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 617, in _build_master
    ws.require(__requires__)
  File "/opt/auto-cpufreq/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 956, in require
    needed = self.resolve(parse_requirements(requirements))
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/auto-cpufreq/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 815, in resolve
    dist = self._resolve_dist(
           ^^^^^^^^^^^^^^^^^^^
  File "/opt/auto-cpufreq/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 856, in _resolve_dist
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'PyGObject' distribution was not found and is required by auto-cpufreq

Also please be descriptive about the issue you're reporting, i.e: what you tried & what's the expected behaviour.

---

[shadeyg56]

Hi, please update to the latest version and try again

[atimeofday]

Exact same issue with latest version on Fedora Silverblue. Advice / questions for further diagnosis?

[shadeyg56]

I wasn't able to reproduce this in Ubuntu

Exact same issue with latest version on Fedora Silverblue. Advice / questions for further diagnosis?

I tried testing in a docker container and it wasn't able to work. I know we have had issues with Silverblue in the past. I know very little about Silverblue but it seems it doesn't use yum which auto-cpufreq tries to use to install the necessary dependencies. I was unsuccessful getting the packages to install in the docker container with rpm-ostree

I might try Silverblue in a VM and see if that works better. @atimeofday If you want to take a look, here is the function in the installer that handles package installs

[atimeofday]

@shadeyg56 Silverblue is "immutable" / container-native Fedora. Everything that can be run in a container - is. Flatpak, distrobox, then local filesystem, then layering apps/dependencies into the base image with rpm-ostree as a last resort.

Auto-cpufreq was patched to install in a local fallback location instead of the top-level, write-protected /usr, which appears to still be the case. However, that does not account for the new dependencies. Would it be possible to install auto-cpufreq and its dependencies in a distrobox (docker) container, and manage the host hardware from there?

I see that function has some instructions for new-distro-support PRs - I can open one up separate from this if necessary. I missed that and the dependencies list during installation because it detected Fedora. I think that function is enough of a lead that I can ask some experts on that sort of containerization from the Universal Blue project, which is technically how I'm using Silverblue.

Thanks for that link!

[shadeyg56]

Would it be possible to install auto-cpufreq and its dependencies in a distrobox (docker) container, and manage the host hardware from there?

Yes, using distrobox would probably be your best alternative. As far as I know, this should work but am not 100% sure since auto-cpufreq requires a system service and I'm not sure how distrobox handles that.

I see that function has some instructions for new-distro-support PRs - I can open one up separate from this if necessary. I missed that and the dependencies list during installation because it detected Fedora

Yes, its pretty trivial to add new distros. The main issue I see is when looking at /etc/os-release it only shows the distro as Fedora rawhide. Is there anyway for the script to distinguish a standard Fedora install from a Silverblue install?

[eret9616]

@shadeyg56

[atimeofday]

@hh9515 I believe I saw a series of additional manual setup steps for the snap package. Have you tried using the installer script instead?

[shadeyg56]

@hh9515 yeah agreeing with that the other guy said, if you look at this part of the README that recommends installing from the repo with the installer script. We aren't really actively working on or testing the Snap package much anymore.

[Thunder-Ultra]

@hh9515

The Last line in the output clearly declares the missing python Package PyGObject as follows :
pkg_resources.DistributionNotFound: The 'PyGObject' distribution was not found and is required by auto-cpufreq

Which can be installed in either of the two ways. Linux Safe way is using the system package manager. But the alternaive uses the python package manger (pip) which is known to cause issues with the system package manager.

So, you can install it in the linux 🐧 safe way using the following command

sudo apt install python3-gi python3-gi-cairo gir1.2-gtk-4.0

Or, if u want the alternative 🛑 way, the following command will help (Try only if the above command doesn't work)

sudo apt install libgirepository1.0-dev gcc libcairo2-dev pkg-config python3-dev gir1.2-gtk-4.0
pip install pycairo
pip install PyGObject

Links : https://pygobject.readthedocs.io/en/latest/getting_started.html#ubuntu-logo-ubuntu-debian-logo-debian

[AdnanHodzic]

@rootCircle since you added initial support for pyproject.toml as part of #576 do you have any opinions on this, same thing with #601?

@Thunder-Ultra my preferred solution and direction we're going in with this project is to have .deb or i.e .rpm packages as part each releases and ideally have auto-cpufreq as part of Debian repositories for which there's already an auto-cpufreq Debian RFP. | Other reference: #157

Then you'd intrinsically down this path:

So, you can install it in the linux 🐧 safe way using the following command

sudo apt install python3-gi python3-gi-cairo gir1.2-gtk-4.0

Because all of these packages would be listed as part of dependencies when auto-cpufreq is build and would be installed when auto-cpufreq is installed. Then after installation you'd immediately have auto-cpufreq CLI ready to go or auto-cpufreq icon/desktop entry if you wanted to install it using GUI.

[rootCircle]

@rootCircle since you added initial support for pyproject.toml as part of #576 do you have any opinions on this, same thing with #601?

I don't have much conceptual idea about immutable OS(Fedora Silverblue in general), but specifying external dependencies is still not supported yet with pyproject.toml! See RFC. If implemented soon, it can offload lots of installation script work to minimum. Till then installation script or this can help!
Even then, I am not sure if that can fix #601 in general.

Packaging might help a lot in current case for general users! ➕

This might be helpful by the way Installing packages to /opt or /usr/local (Silverblue)