Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #83143 > unrolled thread

Bug#894906: linux-cpupower: provide a systemd service and a default config file

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#894906: linux-cpupower: provide a systemd service and a default config file jim_p <pitsiorisj@outlook.com> - 2024-07-22 17:00 +0200
    Bug#894906: linux-cpupower: provide a systemd service and a default config file Francesco Poli <invernomuto@paranoici.org> - 2024-07-27 18:00 +0200
      Bug#894906: linux-cpupower: provide a systemd service and a default config file Francesco Poli <invernomuto@paranoici.org> - 2024-09-15 17:30 +0200
        Bug#894906: linux-cpupower: provide a systemd service and a default config file Salvatore Bonaccorso <carnil@debian.org> - 2024-09-21 17:20 +0200
        Bug#894906: linux-cpupower: provide a systemd service and a default config file Bastian Blank <waldi@debian.org> - 2024-09-22 12:00 +0200
          Bug#894906: linux-cpupower: provide a systemd service and a default config file Francesco Poli <invernomuto@paranoici.org> - 2024-09-22 16:40 +0200
            Bug#894906: linux-cpupower: provide a systemd service and a default config file Francesco Poli <invernomuto@paranoici.org> - 2024-12-28 18:00 +0100
              Bug#894906: linux-cpupower: provide a systemd service and a default config file Francesco Poli <invernomuto@paranoici.org> - 2025-03-10 19:40 +0100
                Bug#894906: linux-cpupower: provide a systemd service and a default config file Salvatore Bonaccorso <carnil@debian.org> - 2025-03-17 21:30 +0100
                  Bug#894906: linux-cpupower: provide a systemd service and a default config file Francesco Poli <invernomuto@paranoici.org> - 2025-03-18 18:40 +0100
                    Bug#894906: linux-cpupower: provide a systemd service and a default config file Salvatore Bonaccorso <carnil@debian.org> - 2025-03-21 13:30 +0100
                      Bug#894906: linux-cpupower: provide a systemd service and a default config file Francesco Poli <invernomuto@paranoici.org> - 2025-08-31 11:20 +0200
                        Bug#894906: linux-cpupower: provide a systemd service and a default config file Francesco Poli <invernomuto@paranoici.org> - 2025-09-29 23:10 +0200
                          Bug#894906: linux-cpupower: provide a systemd service and a default config file Salvatore Bonaccorso <carnil@debian.org> - 2025-10-13 17:30 +0200
                            Bug#894906: linux-cpupower: provide a systemd service and a default config file Francesco Poli <invernomuto@paranoici.org> - 2025-10-13 23:20 +0200
                              Bug#894906: linux-cpupower: provide a systemd service and a default config file Francesco Poli <invernomuto@paranoici.org> - 2025-10-15 20:30 +0200

#83143 — Bug#894906: linux-cpupower: provide a systemd service and a default config file

Package: linux-cpupower
Version: 6.9.9-1
Followup-For: Bug #894906
X-Debbugs-Cc: pitsiorisj@outlook.com

Sunday report... on Monday afternoon because I forgot about it. Like with the
previous change, adding "After=remote-fs.target" did not change much. It still
fails like half the times, like it does with the other parameter or with
neither of the two.

If it helps, here is the output of journalctl for one time that it failed on
boot and I restarted it to make it work

$ sudo journalctl -b -u cpupower.service
Jul 22 17:40:12 pc systemd[1]: Starting cpupower.service - Apply cpupower
configuration...
Jul 22 17:40:12 pc cpupower[339]: + ESTATUS=0
Jul 22 17:40:12 pc cpupower[339]: + test  !=
Jul 22 17:40:12 pc cpupower[339]: + PARS= -g powersave
Jul 22 17:40:12 pc cpupower[339]: + PARS= -g powersave
Jul 22 17:40:12 pc cpupower[339]: + test  -g powersave !=
Jul 22 17:40:12 pc cpupower[339]: + cpupower frequency-set -g powersave
Jul 22 17:40:12 pc cpupower[339]: + ESTATUS=1
Jul 22 17:40:12 pc cpupower[339]: + PARS=
Jul 22 17:40:12 pc cpupower[339]: + test  !=
Jul 22 17:40:12 pc cpupower[339]: + exit 1
Jul 22 17:40:12 pc systemd[1]: cpupower.service: Main process exited,
code=exited, status=1/FAILURE
Jul 22 17:40:12 pc systemd[1]: cpupower.service: Failed with result 'exit-
code'.
Jul 22 17:40:12 pc systemd[1]: Failed to start cpupower.service - Apply
cpupower configuration.
Jul 22 17:42:32 pc systemd[1]: Starting cpupower.service - Apply cpupower
configuration...
Jul 22 17:42:32 pc cpupower[755]: + ESTATUS=0
Jul 22 17:42:32 pc cpupower[755]: + test  !=
Jul 22 17:42:32 pc cpupower[755]: + PARS= -g powersave
Jul 22 17:42:32 pc cpupower[755]: + PARS= -g powersave
Jul 22 17:42:32 pc cpupower[755]: + test  -g powersave !=
Jul 22 17:42:32 pc cpupower[755]: + cpupower frequency-set -g powersave
Jul 22 17:42:33 pc cpupower[755]: + PARS=
Jul 22 17:42:33 pc cpupower[755]: + test  !=
Jul 22 17:42:33 pc cpupower[755]: + exit 0
Jul 22 17:42:33 pc systemd[1]: Finished cpupower.service - Apply cpupower
configuration.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.9.9-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-cpupower depends on:
ii  libc6         2.38-14
ii  libcap2       1:2.66-5
ii  libcpupower1  6.9.9-1
ii  libpci3       1:3.13.0-1

linux-cpupower recommends no packages.

linux-cpupower suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#83248

[Multipart message — attachments visible in raw view] — view raw

On Mon, 22 Jul 2024 17:49:13 +0300 jim_p <pitsiorisj@outlook.com> wrote:

[...]
> Sunday report... on Monday afternoon because I forgot about it. Like with the
> previous change, adding "After=remote-fs.target" did not change much. It still
> fails like half the times, like it does with the other parameter or with
> neither of the two.
[...]

Then I really cannot understand what's going on in your system... I am
sorry...   :-(

Is there anyone else who has tested the three files I sent?
Does anyone else have issues with them?

I reiterate the request to people from the Debian Kernel Team: could
someone please step in, test the three files, and share his/her insight
about why they seem to work for me, but not for jim_p?


P.S.: Please Cc me, in case you want me to see the replies earlier;
I am not subscribed to the bug, I just see comments on the web bug log,
when I am not in Cc...

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#84001

[Multipart message — attachments visible in raw view] — view raw

On Sat, 27 Jul 2024 17:54:34 +0200 Francesco Poli wrote:

[...]
> I reiterate the request to people from the Debian Kernel Team: could
> someone please step in, test the three files, and share his/her insight
[...]
> ?

Dear Debian Kernel Team,
this bug needs love, could some of you please spend a little time to
address it?

I provided [three files] that work for me™, I would be happy to see them
integrated into the linux-cpupower binary package (they are released
under the terms of the GNU GPL license v2 or later), so that other
users may benefit from them, without having to manually copy them.

[three files]: <https://bugs.debian.org/894906#17>

Could you please test them, possibly share your thoughts and/or propose
enhancements, and then include them into the Debian package?

Or otherwise, if you think there's something wrong with them, could you
please explain what is wrong? Maybe there's a way to fix them...

I really hope this bug can soon be solved once and for all.
Thanks for your understanding!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#84057

Hi,

On Sun, Sep 15, 2024 at 05:23:10PM +0200, Francesco Poli wrote:
> On Sat, 27 Jul 2024 17:54:34 +0200 Francesco Poli wrote:
> 
> [...]
> > I reiterate the request to people from the Debian Kernel Team: could
> > someone please step in, test the three files, and share his/her insight
> [...]
> > ?
> 
> Dear Debian Kernel Team,
> this bug needs love, could some of you please spend a little time to
> address it?
> 
> I provided [three files] that work for me™, I would be happy to see them
> integrated into the linux-cpupower binary package (they are released
> under the terms of the GNU GPL license v2 or later), so that other
> users may benefit from them, without having to manually copy them.
> 
> [three files]: <https://bugs.debian.org/894906#17>
> 
> Could you please test them, possibly share your thoughts and/or propose
> enhancements, and then include them into the Debian package?
> 
> Or otherwise, if you think there's something wrong with them, could you
> please explain what is wrong? Maybe there's a way to fix them...
> 
> I really hope this bug can soon be solved once and for all.
> Thanks for your understanding!

We had a short discussion on this bug in one of the recent kernel-team
meetings. We think the proposed approach is probably not too generic
enough to be included. But I'm not the right person to respond here,
Bastian will following up later with an answer in more detail.

https://meetbot.debian.net/debian-kernel/2024/debian-kernel.2024-07-31-19.00.txt
https://meetbot.debian.net/debian-kernel/2024/debian-kernel.2024-07-31-19.00.log.html

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#84065

On Sun, Sep 15, 2024 at 05:23:10PM +0200, Francesco Poli wrote:
> Or otherwise, if you think there's something wrong with them, could you
> please explain what is wrong? Maybe there's a way to fix them...

The linux-cpupower package includes low level tools to interrogate and
set certain low level CPU features.  So the reasons for installing this
package are two-fold, you either want to see various things, or you want
to globally change them.  But because of the two different usages, just
installing the package can not change global settings without futher
user interaction.

Yes, we could provide them disabled.  But overall we are currently at a
point, where even desktop environments have rudimentary settings for
this.  And also basic cpu frequency is not longer a useful way to save
energy, but things like p states as used, which just shut of whole parts
of the chip.

About the files itself: please loose the shell wrapper.  You can use
EnvironmentFile and multiple ExecStart with variable expansion (however
no conditionals).

Bastian

-- 
In the strict scientific sense we all feed on death -- even vegetarians.
		-- Spock, "Wolf in the Fold", stardate 3615.4

[toc] | [prev] | [next] | [standalone]

#84068

[Multipart message — attachments visible in raw view] — view raw

On Sun, 22 Sep 2024 11:55:18 +0200 Bastian Blank wrote:

> On Sun, Sep 15, 2024 at 05:23:10PM +0200, Francesco Poli wrote:
> > Or otherwise, if you think there's something wrong with them, could you
> > please explain what is wrong? Maybe there's a way to fix them...
> 
> The linux-cpupower package includes low level tools to interrogate and
> set certain low level CPU features.

Dear Bastian,
thanks for taking the time to reply.

However, I only agree with part of your reasoning, see below.

> So the reasons for installing this
> package are two-fold, you either want to see various things, or you want
> to globally change them.

Exactly, I am encouraging you to make the change-operation more
convenient for system administrators, who want to set something at boot
(without having to manually invoke 'cpupower' after each boot or having
to reinvent ad-hoc strategies).

> But because of the two different usages, just
> installing the package can not change global settings without futher
> user interaction.
> 
> Yes, we could provide them disabled.

That's exactly what I am advocating: please ship the three files in the
'linux-cpupower' package, but install the systemd service disabled by
default.
Any sysadmin who wants to use the systemd service will have to edit the
'/etc/default/cpupower' file anyway, hence no big deal if he/she also
has to issue the following command:

  # systemctl enable --now cpupower.service

> But overall we are currently at a
> point, where even desktop environments have rudimentary settings for
> this.

Come on, not all Debian users run (sophisticated) desktop
environments. My own desktop is built on Fluxbox, which is not even a
desktop environment (just a standalone window manager): I am not aware
of any cpupower-related settings in Fluxbox (are there any?).

Anyway, Debian GNU/Linux machines may be up and running, without any
logged-in user and/or without any desktop environment executing.

Moreover, not all Debian GNU/Linux machines have desktop environments.
What about (machines that only run) servers?
Or HPC clusters?
Network gateways?
Embedded systems?

A convenient mechanism to set cpupower-related things at boot would be
useful for at least these cases... 

> And also basic cpu frequency is not longer a useful way to save
> energy, but things like p states as used, which just shut of whole parts
> of the chip.

How are these things (like p states) managed?
Could you please tell me more about them?

> 
> About the files itself: please loose the shell wrapper.  You can use
> EnvironmentFile and multiple ExecStart with variable expansion (however
> no conditionals).

I had considered using multiple ExecStart directives.
"No conditionals" is exactly the reason why I concluded that I had to
go for the external script.
Hence, I think that we cannot do without the external script...


I reiterate the request to integrate the [three files] into the
'linux-cpupower' package, with the systemd service disabled by default.

[three files]: <https://bugs.debian.org/894906#17>

I acknowledge that they are probably sub-optimal and could be further
generalized and/or enhanced.
But, until someone comes up with a better solution, they are better
than nothing...
The current situation is that every user has to set up ad-hoc solutions
(perhaps involving the deprecated 'rc.local' file or otherwise), unless
he/she can leverage some desktop tool...

And, of course, any of you from the Debian Kernel Team can further
improve the files at any time.
But, please, first ship the three files in the package, without waiting
for the perfect solution. This bug report has been open since April
2018... As Voltaire once said, the better is the enemy of the good.


Thanks for reading so far.
Still hoping to see this bug fixed for good.

Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#84968

[Multipart message — attachments visible in raw view] — view raw

On Sun, 22 Sep 2024 16:37:37 +0200 Francesco Poli wrote:

[...]
> I reiterate the request to integrate the three files into the
> 'linux-cpupower' package, with the systemd service disabled by default.
[...]

I have further improved the 'cpupower.sh' after analyzing it with
shellcheck (Debian package 'shellcheck').

I am re-attaching the three files to this message, for clarity's sake.

> I acknowledge that they are probably sub-optimal and could be further
> generalized and/or enhanced.
> But, until someone comes up with a better solution, they are better
> than nothing...
> The current situation is that every user has to set up ad-hoc solutions
> (perhaps involving the deprecated 'rc.local' file or otherwise), unless
> he/she can leverage some desktop tool...
> 
> And, of course, any of you from the Debian Kernel Team can further
> improve the files at any time.
> But, please, first ship the three files in the package, without waiting
> for the perfect solution. This bug report has been open since April
> 2018... As Voltaire once said, the better is the enemy of the good.

Please, pretty please, ship the three files with the 'linux-cpupower'
package, setting the systemd service disabled by default.

Let's fix this bug once and for all!





N.B.:
For any user who wants to manually install the three attached files
*before* they are shipped by 'linux-cpupower', the commands are:

  # install -m 644 cpupower.default /etc/default/cpupower
  # install -m 755 cpupower.sh /usr/libexec/cpupower
  # install -m 644 cpupower.service /usr/lib/systemd/system/
  # systemctl daemon-reload

After this manual installation (or once the 'linux-cpupower' package
ships them and installs the systemd service disabled by default), the
administrator (root user) can edit /etc/default/cpupower as appropriate
and then issue the command:

  # systemctl enable --now cpupower.service



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#86413

[Multipart message — attachments visible in raw view] — view raw

On Sat, 28 Dec 2024 17:52:44 +0100 Francesco Poli wrote:

[...]
> Please, pretty please, ship the three files with the 'linux-cpupower'
> package, setting the systemd service disabled by default.
> 
> Let's fix this bug once and for all!
[...]

Is there any chance to see the three files included in the
'linux-cpupower' package?

Please my previous [message], for more details.

[message]: <https://bugs.debian.org/894906#94>


Thanks for your time and patience.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#86485

Hi Francesco,

On Mon, Mar 10, 2025 at 07:25:37PM +0100, Francesco Poli wrote:
> On Sat, 28 Dec 2024 17:52:44 +0100 Francesco Poli wrote:
> 
> [...]
> > Please, pretty please, ship the three files with the 'linux-cpupower'
> > package, setting the systemd service disabled by default.
> > 
> > Let's fix this bug once and for all!
> [...]
> 
> Is there any chance to see the three files included in the
> 'linux-cpupower' package?
> 
> Please my previous [message], for more details.
> 
> [message]: <https://bugs.debian.org/894906#94>
> 
> 
> Thanks for your time and patience.

Let me try to quickly summarize the status here (don't shoot the
messenger):

From a src:linux maintenance point of view I think we would still
continue to decline shipping some scripts in packages produced, but
there might be a chance we ship them if they are maintained upstream
as examples (FWIW, this is very similar argument as it holds for which
patches we accept to cherry-pick, only what is reviewed and accepted
upstream and is applied in at least a upper version)

My proposal to you would be: Do upstream the scripts as part of the
tools/power/cpupower source. If they get accepted we might include them
as part of upstream as well in the produced packages.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#86499

[Multipart message — attachments visible in raw view] — view raw

On Mon, 17 Mar 2025 21:21:53 +0100 Salvatore Bonaccorso wrote:

[...]
> On Mon, Mar 10, 2025 at 07:25:37PM +0100, Francesco Poli wrote:
[...]
> > Is there any chance to see the three files included in the
> > 'linux-cpupower' package?
[...]
> Let me try to quickly summarize the status here (don't shoot the
> messenger):
> 
> From a src:linux maintenance point of view I think we would still
> continue to decline shipping some scripts in packages produced, but
> there might be a chance we ship them if they are maintained upstream
> as examples (FWIW, this is very similar argument as it holds for which
> patches we accept to cherry-pick, only what is reviewed and accepted
> upstream and is applied in at least a upper version)
> 
> My proposal to you would be: Do upstream the scripts as part of the
> tools/power/cpupower source. If they get accepted we might include them
> as part of upstream as well in the produced packages.

Hello Salvatore,
thanks for your followup.

I can try, hoping that the answer won't be "this is a job for distros,
not for upstream!"...

Where do I start from?
By sending a message to the [linux-pm] mailing list?

[linux-pm]: <https://lore.kernel.org/linux-pm/>

Please let me know, thanks for your time.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#86523

Hi Francesco,

On Tue, Mar 18, 2025 at 06:27:52PM +0100, Francesco Poli wrote:
> On Mon, 17 Mar 2025 21:21:53 +0100 Salvatore Bonaccorso wrote:
> 
> [...]
> > On Mon, Mar 10, 2025 at 07:25:37PM +0100, Francesco Poli wrote:
> [...]
> > > Is there any chance to see the three files included in the
> > > 'linux-cpupower' package?
> [...]
> > Let me try to quickly summarize the status here (don't shoot the
> > messenger):
> > 
> > From a src:linux maintenance point of view I think we would still
> > continue to decline shipping some scripts in packages produced, but
> > there might be a chance we ship them if they are maintained upstream
> > as examples (FWIW, this is very similar argument as it holds for which
> > patches we accept to cherry-pick, only what is reviewed and accepted
> > upstream and is applied in at least a upper version)
> > 
> > My proposal to you would be: Do upstream the scripts as part of the
> > tools/power/cpupower source. If they get accepted we might include them
> > as part of upstream as well in the produced packages.
> 
> Hello Salvatore,
> thanks for your followup.
> 
> I can try, hoping that the answer won't be "this is a job for distros,
> not for upstream!"...
>
> Where do I start from?
> By sending a message to the [linux-pm] mailing list?
> 
> [linux-pm]: <https://lore.kernel.org/linux-pm/>
> 
> Please let me know, thanks for your time.

That is where I would start as well. Or more specific looking what
"get_maintainer.pl" gives me:

$ ./scripts/get_maintainer.pl ./tools/power/cpupower/
Thomas Renninger <trenn@suse.com> (maintainer:CPU POWER MONITORING SUBSYSTEM)
Shuah Khan <shuah@kernel.org> (maintainer:CPU POWER MONITORING SUBSYSTEM)
"John B. Wyatt IV" <jwyatt@redhat.com> (maintainer:CPU POWER MONITORING SUBSYSTEM)
John Kacur <jkacur@redhat.com> (maintainer:CPU POWER MONITORING SUBSYSTEM)
linux-pm@vger.kernel.org (open list:CPU POWER MONITORING SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)

That means apart from using the linux-pm  mailinglist, add as well as
recipients the respecive maintainers responsible.

Hope that helps you to start, feel free to as well CC the Debian bug
so that (or at least point out when you have started the discussion
upstream so that we can mark the bug forwarded).

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#89049

[Multipart message — attachments visible in raw view] — view raw

On Fri, 21 Mar 2025 13:17:52 +0100 Salvatore Bonaccorso wrote:

[...]
> Hope that helps you to start, feel free to as well CC the Debian bug
> so that (or at least point out when you have started the discussion
> upstream so that we can mark the bug forwarded).

Hello Salvatore,
it was not a short journey, but the (refined) patch has been accepted
upstream.

Now I would like to see it shipped in the Debian package, please...

It is already present in the Debian source package:

https://sources.debian.org/src/linux/6.16.3-1/tools/power/cpupower/cpupower.sh
https://sources.debian.org/src/linux/6.16.3-1/tools/power/cpupower/cpupower.service.in
https://sources.debian.org/src/linux/6.16.3-1/tools/power/cpupower/cpupower-service.conf

But the Debian binary package does not ship the files:

  $ dpkg -l | grep cpupower | cut -c 1-77
  ii  libcpupower1                    6.16.3-1                            amd64
  ii  linux-cpupower                  6.16.3-1                            amd64
  $ dpkg -S libexec/cpupower
  dpkg-query: no path found matching pattern *libexec/cpupower*
  $ dpkg -S cpupower.service
  dpkg-query: no path found matching pattern *cpupower.service*
  $ dpkg -S cpupower-service.conf
  dpkg-query: no path found matching pattern *cpupower-service.conf*


Please note that:

 * cpupower.sh should be installed to /usr/libexec/cpupower

 * cpupower.service.in should be transformed (with some sed editing)
   into /usr/lib/systemd/system/cpupower.service  (this systemd service
   unit is disabled by default)

 * cpupower-service.conf should be installed
   to /etc/cpupower-service.conf

All this is taken care of by the Makefile, see lines 310÷315 (and other
related lines):

https://sources.debian.org/src/linux/6.16.3-1/tools/power/cpupower/Makefile#L310


Please modify Debian binary package 'linux-cpupower', so that it
correctly ships the three above-mentioned files in the correct
destinations, with the systemd service unit disabled by default.


Looking forward to seeing this bug fixed once and for all.
Thanks for your time!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#89457

[Multipart message — attachments visible in raw view] — view raw

On Sun, 31 Aug 2025 11:03:51 +0200 Francesco Poli wrote:

[...]
> Hello Salvatore,
> it was not a short journey, but the (refined) patch has been accepted
> upstream.
> 
> Now I would like to see it shipped in the Debian package, please...
> 
> It is already present in the Debian source package:
> 
> https://sources.debian.org/src/linux/6.16.3-1/tools/power/cpupower/cpupower.sh
> https://sources.debian.org/src/linux/6.16.3-1/tools/power/cpupower/cpupower.service.in
> https://sources.debian.org/src/linux/6.16.3-1/tools/power/cpupower/cpupower-service.conf
> 
> But the Debian binary package does not ship the files:
> 
>   $ dpkg -l | grep cpupower | cut -c 1-77
>   ii  libcpupower1                    6.16.3-1                            amd64
>   ii  linux-cpupower                  6.16.3-1                            amd64
>   $ dpkg -S libexec/cpupower
>   dpkg-query: no path found matching pattern *libexec/cpupower*
>   $ dpkg -S cpupower.service
>   dpkg-query: no path found matching pattern *cpupower.service*
>   $ dpkg -S cpupower-service.conf
>   dpkg-query: no path found matching pattern *cpupower-service.conf*
> 
> 
> Please note that:
> 
>  * cpupower.sh should be installed to /usr/libexec/cpupower
> 
>  * cpupower.service.in should be transformed (with some sed editing)
>    into /usr/lib/systemd/system/cpupower.service  (this systemd service
>    unit is disabled by default)
> 
>  * cpupower-service.conf should be installed
>    to /etc/cpupower-service.conf
> 
> All this is taken care of by the Makefile, see lines 310÷315 (and other
> related lines):
> 
> https://sources.debian.org/src/linux/6.16.3-1/tools/power/cpupower/Makefile#L310
> 
> 
> Please modify Debian binary package 'linux-cpupower', so that it
> correctly ships the three above-mentioned files in the correct
> destinations, with the systemd service unit disabled by default.
> 
> 
> Looking forward to seeing this bug fixed once and for all.
> Thanks for your time!

Is there any update on this?

Please fix this bug once and for all, thanks for your time and
dedication!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#89581

Hi,

On Tue, Sep 30, 2025 at 05:47:44AM +0200, Salvatore Bonaccorso wrote:
> Francesco,
> 
> On Mon, Sep 29, 2025 at 10:53:49PM +0200, Francesco Poli wrote:
> > On Sun, 31 Aug 2025 11:03:51 +0200 Francesco Poli wrote:
> > 
> > [...]
> > > Hello Salvatore,
> > > it was not a short journey, but the (refined) patch has been accepted
> > > upstream.
> > > 
> > > Now I would like to see it shipped in the Debian package, please...
> > > 
> > > It is already present in the Debian source package:
> > > 
> > > https://sources.debian.org/src/linux/6.16.3-1/tools/power/cpupower/cpupower.sh
> > > https://sources.debian.org/src/linux/6.16.3-1/tools/power/cpupower/cpupower.service.in
> > > https://sources.debian.org/src/linux/6.16.3-1/tools/power/cpupower/cpupower-service.conf
> > > 
> > > But the Debian binary package does not ship the files:
> > > 
> > >   $ dpkg -l | grep cpupower | cut -c 1-77
> > >   ii  libcpupower1                    6.16.3-1                            amd64
> > >   ii  linux-cpupower                  6.16.3-1                            amd64
> > >   $ dpkg -S libexec/cpupower
> > >   dpkg-query: no path found matching pattern *libexec/cpupower*
> > >   $ dpkg -S cpupower.service
> > >   dpkg-query: no path found matching pattern *cpupower.service*
> > >   $ dpkg -S cpupower-service.conf
> > >   dpkg-query: no path found matching pattern *cpupower-service.conf*
> > > 
> > > 
> > > Please note that:
> > > 
> > >  * cpupower.sh should be installed to /usr/libexec/cpupower
> > > 
> > >  * cpupower.service.in should be transformed (with some sed editing)
> > >    into /usr/lib/systemd/system/cpupower.service  (this systemd service
> > >    unit is disabled by default)
> > > 
> > >  * cpupower-service.conf should be installed
> > >    to /etc/cpupower-service.conf
> > > 
> > > All this is taken care of by the Makefile, see lines 310÷315 (and other
> > > related lines):
> > > 
> > > https://sources.debian.org/src/linux/6.16.3-1/tools/power/cpupower/Makefile#L310
> > > 
> > > 
> > > Please modify Debian binary package 'linux-cpupower', so that it
> > > correctly ships the three above-mentioned files in the correct
> > > destinations, with the systemd service unit disabled by default.
> > > 
> > > 
> > > Looking forward to seeing this bug fixed once and for all.
> > > Thanks for your time!
> > 
> > Is there any update on this?
> > 
> > Please fix this bug once and for all, thanks for your time and
> > dedication!
> 
> Please, there is really no need to ping us regularly at this. It is on
> the open bug list with patch, we have not yet come to it.

I opened a MR to include the files in the packaging for
linux-cpupower:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1674

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#89596

[Multipart message — attachments visible in raw view] — view raw

On Mon, 13 Oct 2025 17:24:04 +0200 Salvatore Bonaccorso wrote:

[...]
> I opened a MR to include the files in the packaging for
> linux-cpupower:
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/1674

Thanks!

I noticed a typo in the 'linux-cpupower.README.Debian' file: there's a
repeated "the the", which should be just "the".


I would also like to suggest a clearer explanation text.
I would rephrase the whole file as:

"""
linux-cpupower for Debian
-------------------------

The linux-cpupower package ships a cpupower systemd service unit to run
the cpupower utility at boot with settings read from a configuration file
('/etc/cpupower-service.conf').

This systemd service is not enabled or started by default.
If you want to enable it, edit '/etc/cpupower-service.conf'
(uncommenting at least one of the options, depending on your preferences)
and then issue the following command (with root privileges):

  systemctl enable --now cpupower.service

 -- Salvatore Bonaccorso <carnil@debian.org>  XXX, XX XXX XXXX XX:XX:XX +XXXX
"""


Please compare with
<https://sources.debian.org/src/linux/6.16.11-1/tools/power/cpupower/README#L184>


Thanks a lot for your time and dedication!   :-)

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [next] | [standalone]

#89644

[Multipart message — attachments visible in raw view] — view raw

On Tue, 14 Oct 2025 20:27:26 +0200 Salvatore Bonaccorso wrote:

[...]
> On Mon, Oct 13, 2025 at 11:01:57PM +0200, Francesco Poli wrote:
[...]
> > I would also like to suggest a clearer explanation text.
[...]
>
> Thanks, I just have pushed an improved description for it which will
> be in the next experimental upload.

Thanks to you, bye!   :-)

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web