Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cant open auto-cpufreq in a fresh installed kubuntu #574

Open
hh9515 opened this issue Oct 4, 2023 · 11 comments
Open

cant open auto-cpufreq in a fresh installed kubuntu #574

hh9515 opened this issue Oct 4, 2023 · 11 comments
Labels
no repro The issue was not reproducible

Comments

@hh9515
Copy link

hh9515 commented Oct 4, 2023

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

Have you tried?

Error output:

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

image


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
Copy link
Collaborator

Hi, please update to the latest version and try again

@atimeofday
Copy link

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

@shadeyg56
Copy link
Collaborator

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

@shadeyg56 shadeyg56 added the no repro The issue was not reproducible label Oct 11, 2023
@atimeofday
Copy link

@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
Copy link
Collaborator

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?

@hh9515
Copy link
Author

hh9515 commented Oct 12, 2023

@shadeyg56
image

@atimeofday
Copy link

@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
Copy link
Collaborator

@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
Copy link

Thunder-Ultra commented Oct 24, 2023

@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
Copy link
Owner

AdnanHodzic commented Nov 21, 2023

@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
Copy link
Contributor

rootCircle commented Nov 21, 2023

@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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no repro The issue was not reproducible
Projects
None yet
Development

No branches or pull requests

6 participants