FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/auto-cpufreq/scripts/auto-cpufreq-install.sh'

[adnanhodzic]

FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/auto-cpufreq/scripts/auto-cpufreq-install.sh'

[yochananmarqos]

@bu4ak

sudo auto-cpufreq --install

Don't do that, it's already installed. Enable the service and go.

[Red-Eyed]

I understand that there is no need to run --install. But calling --install and getting that error doesn't seem right for the end user.

[yochananmarqos]

@Red-Eyed Well, don't tell them to, then. 😉

On Arch & derivatives, Pacman should track all installed files to the system to avoid conflicts when installing or updating packages. It's customary that a package installed via the repos or AUR should install all required files for this reason.

I can do a PR for the README for Arch & Manjaro here in a bit.

EDIT: PR is done.

[yochananmarqos]

why isn't the service triggered automatically after install. Can't this be the case for both AUR and Manjaro package?

The service is not enabled by default with the AUR package because of Arch's KISS principle and Simplicity.

[Arch] does not add automation features such as enabling a service simply because the package was installed.

However, Manjaro's "Enjoy the Simplicity" involves making things easier:

Manjaro is an accessible, friendly, open-source operating system. Providing all the benefits of cutting-edge software combined with a focus on getting started quickly, automated tools to require less manual intervention, and help readily available when needed. Manjaro is suitable for both newcomers and experienced computer users.

[Red-Eyed]

yes it doesn't work at all on manjaro, just checked that out

[AdnanHodzic]

Not even if if it's installed as a snap?

[Red-Eyed]

Not even if if it's installed as a snap?

so, I guess the problem is with AUR installation, not the snap.

[yochananmarqos]

@Red-Eyed

I guess the problem is with AUR installation

No, the problem is people are trying to install it when it's already installed. The AUR package installs all the required files including the service.

[Red-Eyed]

I installed it via pacman on my manjaro that didn't see auto-cpufreq and got the same error FileNotFoundError

[yochananmarqos]

@Red-Eyed The new Manjaro community package (currently in the testing repo) is the same except it also automatically enables the service.

Again, it's ready to go after installation. There's no need to run the install command at all.

[Red-Eyed]

@bu4ak is that fixed?

[bu4ak]

@Red-Eyed ,
yochananmarqos are absolutely right. There is no need to run sudo auto-cpufreq --install because it is already installed (via AUR in my case).

To enable daemon service:

 systemctl enable auto-cpufreq
 systemctl start auto-cpufreq

[crian]

In the AUR package all files are installed and ready to go. The end-user just needs to enable the systemd service.
There is no need to run the install command.

[AdnanHodzic]

Hi @crian, as I mentioned in #91

I didn't know that was the case with AUR package. In my opinion and to keep things consistent as they are with snap and
auto-cpufreq-installer. It would be the best if after AUR package installation, auto-cpufreq would be available as a binary,
and then you have an option to run it live or install or whatever you want to do with it.

Just so I'm on the same page. Is there a reason why this is done differently as part of AUR package? Because if there's a reason for this kind of implementation I think we should properly mention it under "AUR Linux" section as otherwise Arch/Manjaro users will run into problems.

[yochananmarqos]

@AdnanHodzic

after AUR installation, auto-cpufreq --install will be automatically run

No, the PKGBUILD installs auto-cpufreq.service to /usr/lib/systemd/system/.

and just the systemctl needs to be enabled?

For the AUR package, yes. The user will see a message after installation letting them know they need to enable the service.

However, with the Manjaro package, the service is automatically enabled.

Both packages install cpufreqctl.sh to /usr/share/auto-cpufreq/.

It would be the best if after AUR package installation, auto-cpufreq would be available as a binary

It is via the setup.py:

❯ pacman -Ql auto-cpufreq-git
auto-cpufreq-git /usr/
auto-cpufreq-git /usr/bin/
auto-cpufreq-git /usr/bin/auto-cpufreq
auto-cpufreq-git /usr/lib/
auto-cpufreq-git /usr/lib/python3.8/
auto-cpufreq-git /usr/lib/python3.8/site-packages/
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/PKG-INFO
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/SOURCES.txt
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/dependency_links.txt
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/requires.txt
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/top_level.txt
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/zip-safe
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/__init__.py
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/__pycache__/
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/__pycache__/__init__.cpython-38.opt-1.pyc
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/__pycache__/__init__.cpython-38.pyc
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/__pycache__/core.cpython-38.opt-1.pyc
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/__pycache__/core.cpython-38.pyc
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/core.py
auto-cpufreq-git /usr/lib/systemd/
auto-cpufreq-git /usr/lib/systemd/system/
auto-cpufreq-git /usr/lib/systemd/system/auto-cpufreq.service
auto-cpufreq-git /usr/share/
auto-cpufreq-git /usr/share/auto-cpufreq/
auto-cpufreq-git /usr/share/auto-cpufreq/scripts/
auto-cpufreq-git /usr/share/auto-cpufreq/scripts/cpufreqctl.sh

Perhaps add a check for pacman when running the --install option and detect if the service is already installed to /etc/systemd/system/ or not.

[crian]

Hi @crian, as I mentioned in #91

I didn't know that was the case with AUR package. In my opinion and to keep things consistent as they are with snap and
auto-cpufreq-installer. It would be the best if after AUR package installation, auto-cpufreq would be available as a binary,
and then you have an option to run it live or install or whatever you want to do with it.

Just so I'm on the same page. Is there a reason why this is done differently as part of AUR package? Because if there's a reason for this kind of implementation I think we should properly mention it under "AUR Linux" section as otherwise Arch/Manjaro users will run into problems.

The AUR package compiles and installs all files. That's a typical behavior of a PKGBUILD.

It's a good idea to mention this in the readme. So that arch users don't run into this issue.

[AdnanHodzic]

@yochananmarqos thank you for an elaborate clarification.

after AUR installation, auto-cpufreq --install will be automatically run

No, the PKGBUILD installs auto-cpufreq.service to /usr/lib/systemd/system/.

and just the systemctl needs to be enabled?

For the AUR package, yes. The user will see a message after installation letting them know they need to enable the service.
However, with the Manjaro package, the service is automatically enabled.

I was just about to say, why isn't the service triggered automatically after install. Can't this be the case for both AUR and Manjaro package?

Both packages install cpufreqctl.sh to /usr/share/auto-cpufreq/.

It would be the best if after AUR package installation, auto-cpufreq would be available as a binary

👍

It is via the setup.py:

❯ pacman -Ql auto-cpufreq-git
auto-cpufreq-git /usr/
auto-cpufreq-git /usr/bin/
auto-cpufreq-git /usr/bin/auto-cpufreq
auto-cpufreq-git /usr/lib/
auto-cpufreq-git /usr/lib/python3.8/
auto-cpufreq-git /usr/lib/python3.8/site-packages/
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/PKG-INFO
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/SOURCES.txt
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/dependency_links.txt
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/requires.txt
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/top_level.txt
auto-cpufreq-git /usr/lib/python3.8/site-packages/auto_cpufreq-1.0-py3.8.egg-info/zip-safe
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/__init__.py
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/__pycache__/
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/__pycache__/__init__.cpython-38.opt-1.pyc
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/__pycache__/__init__.cpython-38.pyc
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/__pycache__/core.cpython-38.opt-1.pyc
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/__pycache__/core.cpython-38.pyc
auto-cpufreq-git /usr/lib/python3.8/site-packages/source/core.py
auto-cpufreq-git /usr/lib/systemd/
auto-cpufreq-git /usr/lib/systemd/system/
auto-cpufreq-git /usr/lib/systemd/system/auto-cpufreq.service
auto-cpufreq-git /usr/share/
auto-cpufreq-git /usr/share/auto-cpufreq/
auto-cpufreq-git /usr/share/auto-cpufreq/scripts/
auto-cpufreq-git /usr/share/auto-cpufreq/scripts/cpufreqctl.sh

Perhaps add a check for pacman when running the --install option and detect if the service is already installed to /etc/systemd/system/ or not.

Sounds like a good idea to me.

Hi @crian, as I mentioned in #91

I didn't know that was the case with AUR package. In my opinion and to keep things consistent as they are with snap and
auto-cpufreq-installer. It would be the best if after AUR package installation, auto-cpufreq would be available as a binary,
and then you have an option to run it live or install or whatever you want to do with it.

Just so I'm on the same page. Is there a reason why this is done differently as part of AUR package? Because if there's a reason for this kind of implementation I think we should properly mention it under "AUR Linux" section as otherwise Arch/Manjaro users will run into problems.

The AUR package compiles and installs all files. That's a typical behavior of a PKGBUILD.

It's a good idea to mention this in the readme. So that arch users don't run into this issue.

@crian

👍 I'm fine with whatever approach you guys take. You're the maintainers of these packages.

@crian @yochananmarqos

If things can't be automated, and end user needs to do something after install. I would really appreciate if one of you could edit the exiting Arch Linux section and add necessary instructions. Either extend it to "Arch/Manjaro Linux" or create single section for "Arch Linux" and another one for "Manjaro Linux" is fine with me.

Of course, I'm more then willing to assist you with this during review process.

[AdnanHodzic]

@yochananmarqos

why isn't the service triggered automatically after install. Can't this be the case for both AUR and Manjaro package?

The service is not enabled by default with the AUR package because of Arch's KISS principle and Simplicity.

[Arch] does not add automation features such as enabling a service simply because the package was installed.

However, Manjaro's "Enjoy the Simplicity" involves making these easier:

Manjaro is an accessible, friendly, open-source operating system. Providing all the benefits of cutting-edge software combined with a focus on getting started quickly, automated tools to require less manual intervention, and help readily available when needed. Manjaro is suitable for both newcomers and experienced computer users.

I'm completely fine with that, every distro has its own ways of doing this and philosophies which should be respected.

In this case could you please create another MR for re-organizing the README. But this time, extending Arch Linux section and pointing existing elements that are part of the README. I really had a feeling in #90 it was solely focusing on how to get it installed/running on Arch, and in process making these instructions fuzzy for other distros.

[AdnanHodzic]

README updated, I hope this clarifies any confusion. Please submit a new PR if you think otherwise.