# Great, so cpufrequtils is gone?

## The_Great_Sephiroth

I have just discovered that cpufrequtils is masked, and it JUST happened because I have installed Gentoo multiple times recently and now I am told to use cpupower. This worries me since cpufrequtils WORKS. With that said, is cpupower a drop-in replacement? I do NOT want something that requires me to edit a million configuration files or scripts to make my existing, working software work with this new utility. For example, will KDE still see all of my governors and such which were exposed n the past by cpufrequtils? If not, why are things being broken in favor of cpupower, which I have read clings to systemd, which I am trying to escape in the Gentoo world?

----------

## Jaglover

Why you think it is masked? It is not masked here. OTOH, I never felt the need for it, in-kernel frequency control works just fine.

----------

## depontius

Do you do anything special with your cpu frequency?  I used to use cpufrequtils, but now I just pick ondemand as the default governor in my kernel config, and have been perfectly happy.

----------

## Ant P.

 *The_Great_Sephiroth wrote:*   

> I have just discovered that cpufrequtils is masked

 

By whom? It's not masked in the main portage tree. No mention of it anywhere in /profiles/ and the last changelog entry, from 2013, was to mark it stable.

----------

## Olis

 *Ant P. wrote:*   

>  *The_Great_Sephiroth wrote:*   I have just discovered that cpufrequtils is masked 
> 
> By whom? It's not masked in the main portage tree. No mention of it anywhere in /profiles/ and the last changelog entry, from 2013, was to mark it stable.

 

Here it is masked since today. "emerge --sync" gave me this today:

```
!!! The following installed packages are masked:

- sys-power/cpufrequtils-008-r4::gentoo (masked by: package.mask)

/usr/portage/profiles/package.mask:

# Pacho Ramos <pacho@gentoo.org> (01 Dec 2014)

# Upstream dead for a long time, use sys-power/cpupower

# instead. Removal in a month.
```

I replaced cpufrequtils with cpupower today, no problems so far.

----------

## Yamakuzure

I am using cpupower for ages with KDE, no problems so far.

----------

## The_Great_Sephiroth

Thanks, if it gives you two no problems I am going to go ahead and emerge it! I have been reading on it and it is supposedly going to do more than cpufrequtils, but right now it does nothing more than cpufrequtils, so it seems strange that it is masked, but it isn't my call to make.

I do "emerge-webrsync" and "emerge --sync" during every install, which is probably why it isn't masked for the rest of you. Update and it will be masked with a message about being removed next month.

----------

## Ant P.

 *Olis wrote:*   

> Here it is masked since today. "emerge --sync" gave me this today:

 

Oh, that's annoying.

I've held off switching to cpupower because it wants to download/extract the entire kernel tarball for one tiny binary. I only use the e17 cpufreq thing these days anyway, so I may as well have both those uninstalled.

----------

## chaoscommander

I don't get it. Something that works and has no known security issues.. can just be considered "done", can't it? Why would it need to receive updates as long as it remains working? Why would it need to be removed from the repository?

----------

## depontius

 *chaoscommander wrote:*   

> I don't get it. Something that works and has no known security issues.. can just be considered "done", can't it? Why would it need to receive updates as long as it remains working? Why would it need to be removed from the repository?

 

Put it in a local overlay.  I'm getting more and more stuff there myself, as it's necessary to avoid systemd.

----------

## Ottre

 *chaoscommander wrote:*   

> I don't get it. Something that works and has no known security issues.. can just be considered "done", can't it? Why would it need to receive updates as long as it remains working? Why would it need to be removed from the repository?

 

Occasionally, the Gentoo TreeCleaner project makes mistakes. They are understaffed and don't have time to fully investigate if the alternatives are a drop-in replacement, or investigate whether upstream is "dead" or just inactive. Case in point, they tried to remove net-nntp/inn (developed by Internet Systems Consortium) at one point.

If you care about cpufrequtils send an email to the gentoo-dev mailing list. There's probably a thread about packages due to be removed in December, in which case reply to the thread instead of starting a new one.

----------

## khayyam

 *chaoscommander wrote:*   

> I don't get it. Something that works and has no known security issues.. can just be considered "done", can't it? Why would it need to receive updates as long as it remains working? Why would it need to be removed from the repository?

 

chaoscommander ... issues with cpufrequtils do in fact exist, I've seen system loads that are symptomatic of some process going awry that when investigated turn out to be the cpufrequtil daemon. The problem is that the in kernel cpufreq code went through some refactoring about 3.10.x (or thereabouts) and this isn't reflected in cpufrequtils. Also, cpupower (which is maintained at kernel.org) was released about that time to create a tool that worked with the changes to cpufreq. It doesn't, unlike cpufrequtils, run as a daemon, but that really isn't necessary as the ondemand and conservative governers are able to step without needing a daemon process, all that's needed is a method to set the governer/parameters, anything else is really the domain of acpid or other tools. Basically, cpufrequtils was made obsolete, though technically it can do things that cpupower simply doesn't ... like settings to dim the display, or what-have-you, but again these don't really belong in the cpufreq domain.

best ... khay

----------

## ch64

So you wrote: (look what i've print in bold)

- sys-power/cpufrequtils-008-r4::gentoo (masked by: package.mask)

----------

## mv

Besides the technical reasons given by khayyam:

Gentoo is always seriously understuffed. Unfortunately, it is "normal" that in the moment when a developer loses interest in a package (e.g. because he uses another one - the technical reasons given by khayyam are likely to be the cause for this) that package is removed from the tree unless another developer steps up who is interested in the package. Since there are not so many developers in gentoo, the latter happens only rarely or for absolutely essential packages.

What you can do as a user in such a situation:

 Become a developer.

 A mild form of 1: Care about the package in a local overlay (you can also make it public if you want to serve the Gentoo community); if upstream still exists, you can just start with the latest ebuild which was in portage (if you missed it, you can always fetch it from CVS [or git in some future]). Of course, it is then your responsibility to adapt the ebuild to changes required by portage and/or other packages. Unfortunately, 2. is not an option if upstream no longer exists, i.e., if the tarball can no longer be downloaded from upstream.

I was voting once to keep such tarballs on mirrors anyway, but the request was rejected.

----------

## depontius

 *mv wrote:*   

> 
> 
> I was voting once to keep such tarballs on mirrors anyway, but the request was rejected.

 

How does one vote?  It seems that there are other processes around here, besides bugzilla and the forums.  I've looked occasionally on mailing list archives.  I've also seen IRC references, though I don't generally participate in IRC.  But I'm not sure about the processes behind those two.  Is there a guide of some sort?

----------

## chaoscommander

 *khayyam wrote:*   

>  *chaoscommander wrote:*   I don't get it. Something that works and has no known security issues.. can just be considered "done", can't it? Why would it need to receive updates as long as it remains working? Why would it need to be removed from the repository? 
> 
> chaoscommander ... issues with cpufrequtils do in fact exist, I've seen system loads that are symptomatic of some process going awry that when investigated turn out to be the cpufrequtil daemon. The problem is that the in kernel cpufreq code went through some refactoring about 3.10.x (or thereabouts) and this isn't reflected in cpufrequtils. Also, cpupower (which is maintained at kernel.org) was released about that time to create a tool that worked with the changes to cpufreq. It doesn't, unlike cpufrequtils, run as a daemon, but that really isn't necessary as the ondemand and conservative governers are able to step without needing a daemon process, all that's needed is a method to set the governer/parameters, anything else is really the domain of acpid or other tools. Basically, cpufrequtils was made obsolete, though technically it can do things that cpupower simply doesn't ... like settings to dim the display, or what-have-you, but again these don't really belong in the cpufreq domain.
> 
> best ... khay

 

Thank you for the details. Maybe it would help to include such reasons in the masking message so people were less confused.

And to mv.. how much I would like to be a developer for Gentoo! But I am nearly completely clueless about coding and have no time to learn from scratch until I'm good enough to help.

----------

## NeddySeagoon

 *mv wrote:*   

> 2. A mild form of 1: Care about the package in a local overlay (you can also make it public if you want to serve the Gentoo community); if upstream still exists, you can just start with the latest ebuild which was in portage (if you missed it, you can always fetch it from CVS [or git in some future]). Of course, it is then your responsibility to adapt the ebuild to changes required by portage and/or other packages.

 

That translates into become a proxy maintainer for the package.  You get to do everything a developer does except commit things to the tree.

The dev who you work with will do that for you.  Your name goes in the changelog, so you get the credit and the package stays in the main tree.

----------

## Ant P.

 *khayyam wrote:*   

> Also, cpupower (which is maintained at kernel.org) was released about that time to create a tool that worked with the changes to cpufreq. It doesn't, unlike cpufrequtils, run as a daemon

 

cpufreq-set isn't a daemon any more than hdparm is.

----------

## khayyam

 *Ant P. wrote:*   

>  *khayyam wrote:*   Also, cpupower (which is maintained at kernel.org) was released about that time to create a tool that worked with the changes to cpufreq. It doesn't, unlike cpufrequtils, run as a daemon 
> 
> cpufreq-set isn't a daemon any more than hdparm is.

 

Ant ... actually I may be confusing cpufreqd with cpufrequtils.

best ... khay

----------

## yngwin

 *chaoscommander wrote:*   

> I don't get it. Something that works and has no known security issues.. can just be considered "done", can't it? Why would it need to receive updates as long as it remains working? Why would it need to be removed from the repository?

 

If a package just works, it won't be removed. But in this case it would need updates to keep up with relevant changes in newer kernel versions. In general we only remove packages that have known bugs, but are no longer maintained.

----------

## mv

 *depontius wrote:*   

> How does one vote?

 

My terminology might have been misleading: I was involved in a discussion on the developer mailing list when the topic was about dropping a packet due to dead upstream which I considered a serious problem, since keeping the ebuild is not enough, once the tarball left the mirrors.

But there was no interest in the discussion: It seems, Gentoo does not have the resources to keep "historilcal" tarballs of dead projects (or at least there is no interest in doing so).

----------

