If built with USE=acpi, sys-power/cpufreqd requires sys-power/acpid for ACPI functionality. The dependencies do not reflect this. (This may also be true with regard to sys-power/apmd and USE=apm, but I don't know because I don't have a Gentoo system that requires apm.) Reproducible: Always Steps to Reproduce: 1. USE=acpi emerge sys-power/cpufreqd 2. Set up cpufreqd with acpi rules without first emerging acpid Actual Results: No rules using any ACPI functions will work unless acpid is installed and running, which will cause cpufreqd to fail to start. Expected Results: With USE=acpi, sys-power/cpufreqd should depend upon sys-power/acpid.
er, sorry, replace sys-power/apmd with sys-apps/apmd in the above.
@ppc team, what do you think? acpid keyworded -ppc, so, probably if we add it to DEPEND, ppc keyword should be dropped from sys-power/cpufreqd?
No, cpufreqd works fine on PowerPC, we don't use ACPI profiles, so there's no need for acpid.
(In reply to comment #3) > No, cpufreqd works fine on PowerPC, we don't use ACPI profiles, so there's > no need for acpid. So, drop keywords from acpid too, huh?
There are no keywords on ppc for acpid? I'm not sure what you're asking for. The use flag "acpi" is already masked on ppc, so this doesn't effect us.
(In reply to comment #5) > The use flag "acpi" is already masked on ppc, so this doesn't effect us. Ok, thanks for clarification. It seems that we can just add optional dependency on acpid to cpufreqd with 'acpi' USE-flag
I am unable to reproduce this issue using sys-power/cpufreqd-2.4.2-r2. Maybe this problem has been fixed in the latest revision? I compiled cpufreqd with the acpi USE flag and without acpid running, and cpufreqd starts and stops without any problems. Using 'cpufreqd --no-daemon -V 7', I debugged the program to make sure it was properly running acpi command, and it seemed to. The only issue I can potentially see is setting 'acpid_socket=/var/run/acpid.socket' since this config setting requires acpid explicitly.
Are people aware cpufreqd is completely dead package and shouldn't be used? I believe Gentoo is the only distribution still carrying the package in repository. The Linux kernel source tree has the current tool, which is cpupower. That's cpupower or linux-misc-apps in Portage.
(In reply to Samuli Suominen from comment #8) > Are people aware cpufreqd is completely dead package and shouldn't be used? > I believe Gentoo is the only distribution still carrying the package in > repository. > The Linux kernel source tree has the current tool, which is cpupower. That's > cpupower or linux-misc-apps in Portage. CCing treecleaners (a lot of months passed since we talked about this ;))
(In reply to Samuli Suominen from comment #8) > Are people aware cpufreqd is completely dead package and shouldn't be used? > I believe Gentoo is the only distribution still carrying the package in > repository. > The Linux kernel source tree has the current tool, which is cpupower. That's > cpupower or linux-misc-apps in Portage. Does cpupower include a daemon allowing setting frequency in response to temperature? For anyone interested - I put cpufreqd in my overlay until I figure out whether I want to maintain it in-tree. Arch appears to have cpufreqd in their repository as well.
(In reply to Richard Freeman from comment #10) > (In reply to Samuli Suominen from comment #8) > > Are people aware cpufreqd is completely dead package and shouldn't be used? > > I believe Gentoo is the only distribution still carrying the package in > > repository. > > The Linux kernel source tree has the current tool, which is cpupower. That's > > cpupower or linux-misc-apps in Portage. > > Does cpupower include a daemon allowing setting frequency in response to > temperature? cpupower doesn't have a daemon, as daemon is not required, kernel will do that based on selected governor $ cpupower frequency-info --governors You can then enable one of these governors on all CPUs using: $ cpupower frequency-set --governor [governor] And cpupower frequency-set allows more finetuned settings like '--max' And there is a /etc/init.d/cpupower script that allows setting these on boot, kernel will do the rest Seriously, cpupower and the kernel can replace whatever cpufreqd does, it might be a learning curve, but google is full of examples :)
(In reply to Samuli Suominen from comment #11) > Seriously, cpupower and the kernel can replace whatever cpufreqd does, it > might be a learning curve, but google is full of examples :) Not true AFAIK. For instance, it is not possible to link the change in governors to the battery charge, except by playing with ACPI maybe.
One more problem: by uninstalling cpufreqd and moving to cpupower, cpufrequtils also gets uninstalled (since it's blocked by cpupower) and this way gkrellm-cpufreq gets broken (uses libcpufreq.so provided by cpufrequtils package), and that library does not come with either cpupower or linux-misc-apps.
dropped
