There is a logical bug in sys-power/cpufreqd-2.2.1. I have a patch ready and submitted it upstream, see URL. I don't know how fast upstream will be to react; maybe Gentoo wants to provide a patched revision. Maybe you even want this fixed before stabilizing as requested by 178169, I'm not sure.
Created attachment 126797 [details, diff] patch correcting the logic The same patch as upstream, as the Gentoo bug tracker has nicer patch display.
Still an issue, still not fixed upstream, so I still vote for Gentoo including this fix at least on the distro level.
Fix still not included in upstream 2.3.3 (see bug 233481 for bump request).
so this hasn't made it into 2.3.4 either? why? i'd prefer if bugs like these where handled by upstream...
(In reply to comment #4) > so this hasn't made it into 2.3.4 either? No, judging from the fact that my patch in my local overlay still applies cleanly, and the fact that the source file in question hasn't seen a change in over a year. > why? Whish I knew. I guess upstream doesn't regularly look at the patches tracker, and either they forgot about a mail they got when I first submitted the thing, or there was no such mail. I guess I could try poking them on some mailing list, see if I can get a reaction there. Or do you know of a reliable way to contact the cpufreqd devs? > i'd prefer if bugs like these where handled by upstream... So do I. But I'd rather have it handled by Gentoo than not handled at all.
yes - please try to contact upstream again. the new maintainer may just not have looked into it yet... thanks
(In reply to comment #6) > yes - please try to contact upstream again. Done that: http://sourceforge.net/mailarchive/forum.php?thread_name=4ADD8D70.9000903%40gmx.net&forum_name=cpufreqd-devel Looking at the archive, the 6th most recent thread is by me as well, dating over a year back now. That might have caused trouble due to my use of GPG/MIME, though, so maybe they couldn't read it. The archives certainly have trouble. > the new maintainer may just not have looked into it yet... They have a new maintainer? There you know more than me. Looking at the git commits, it seems that Mattia Dongili has done all commits, and he's been the main committer for as long as the CVS can remember, as far as I can see. Thanks to my investigations on this issue I have found out that they have moved from CVS to git, so the source browser at the SF project page is outdated. My statement about cpufreqd_cpu.c being unchanged for over a year remains valid.
(In reply to comment #7) > (In reply to comment #6) > > yes - please try to contact upstream again. > > Done that: > http://sourceforge.net/mailarchive/forum.php?thread_name=4ADD8D70.9000903%40gmx.net&forum_name=cpufreqd-devel > Looking at the archive, the 6th most recent thread is by me as well, dating > over a year back now. That might have caused trouble due to my use of GPG/MIME, > though, so maybe they couldn't read it. The archives certainly have trouble. > yes - and mattia responded already. good news.. while we are at it, perhaps you want to push the lm_sensors patch from bug #233481? > > the new maintainer may just not have looked into it yet... > > They have a new maintainer? There you know more than me. Looking at the git > commits, it seems that Mattia Dongili has done all commits, and he's been the > main committer for as long as the CVS can remember, as far as I can see. > ah - ok. i got the impression, due to the new homepage and the copyright notice there.... thanks
cpufreqd-2.3.4-r1 has this patch. thanks for the work.
