libcpupower.so is not installed from linux-tools

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1215411

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

This bug was nominated against a series that is no longer supported, ie saucy. The bug task representing the saucy nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

This is still a problem in Trusty, Xenial and Yakkety.

Same libcpupower.so symlink is missing in the following packages:
- linux-tools-3.13.0-96 in trusty-updates
- linux-tools-4.4.0-38 in xenial-updates
- linux-tools-4.8.0-17 in yakkety

Apparently, this issue isn't "In Progress" at all currently, so setting the status to "Confirmed".

Can we please have a libcpupower-dev package compatible to Debian (https://packages.debian.org/sid/libcpupower-dev)?

Added a patch against lp:~ubuntu-kernel/ubuntu/+source/linux/+git/zesty that adds a libcpupower-dev package, compatible with what Debian has.

Dear kernel team, please review it.

Dmitry - your patch doesn't work so well when you have multiple kernel packages installed. You should look at how the linux-tools packages are abstracted.

Hi Tim!

I understand that the user can have multiple kernels installed. However, I am not sure if supporting multiple versions of a development package makes sense. After all, there can be only one header file matching i.e. #include <cpufreq> and only one library file matching -lcpupower.

If you really want me to use the versioned package names, then I will have to use the alternatives mechanism for handling which of the installed packages provides /usr/include/cpufreq.h and /usr/lib/libcpupower.so. This will increase the complexity and make the package naming incompatible with Debian. Do you want me to go this way?

Dear Tim or somebody from the kernel team — can you please reconsider my patch, or reply to my proposal in comment #8?

This one isn't "In Progress" at all it seems.

I had some discussion about this on kernel-team mailing list in September, and provided a patch which addresses Juerg Haefliger’s review:

https://lists.ubuntu.com/archives/kernel-team/2017-September/086839.html

However there has been no action since then :(

Attaching the new version of the patch here as well. Also subscribing Juerg in case he can help us here.

Nice, it even installs cpupower.h (which isn't present in Debian's libcpupower-dev).

I see you also sent a patch for cpupower.h upstream [1]. That would finally fix [2].
Doesn't look like upstream is interested though...

[1] https://patchwork.kernel.org/patch/10009599/
[2] https://bugzilla.kernel.org/show_bug.cgi?id=153161

So I've built and installed kernel 4.13.0 with this patch in 18.04.

Building mate-applets with -lcpupower fails near the end with an unusual error message:

...................

   dh_shlibdeps
dpkg-shlibdeps: error: no dependency information found for /usr/lib/libcpupower.so.4.13.0-32 (used by debian/mate-applets/usr/lib/mate-applets/mate-cpufreq-applet)
Hint: check if the library actually comes from a package.
dh_shlibdeps: dpkg-shlibdeps -Tdebian/mate-applets.substvars debian/mate-applets/usr/lib/mate-applets/command-applet debian/mate-applets/usr/lib/mate-applets/mate-drivemount-applet debian/mate-applets/usr/lib/mate-applets/mate-charpick-applet debian/mate-applets/usr/lib/mate-applets/accessx-status-applet debian/mate-applets/usr/lib/mate-applets/trashapplet debian/mate-applets/usr/lib/mate-applets/timer-applet debian/mate-applets/usr/lib/mate-applets/mate-geyes-applet debian/mate-applets/usr/lib/mate-applets/mate-multiload-applet debian/mate-applets/usr/lib/mate-applets/mate-netspeed-applet debian/mate-applets/usr/lib/mate-applets/mateweather-applet debian/mate-applets/usr/lib/mate-applets/battstat-applet debian/mate-applets/usr/lib/mate-applets/mate-cpufreq-applet debian/mate-applets/usr/lib/mate-applets/stickynotes-applet debian/mate-applets/usr/bin/mate-cpufreq-selector returned exit code 255
dh_shlibdeps: Aborting due to earlier error
debian/rules:10: recipe for target 'binary' failed
make: *** [binary] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2

-------------------

I've checked the contents of libcpupower1 and libcpupower-dev. Something's not right... Usually there's one real library and two symlinks to it, but here it's not so:

$ ls -l /usr/lib/libcpupower.so*
-rw-r--r-- 1 root root 79416 фев 4 21:36 /usr/lib/libcpupower.so
lrwxrwxrwx 1 root root 24 фев 4 21:36 /usr/lib/libcpupower.so.1 -> libcpupower.so.4.13.0-32
-rw-r--r-- 1 root root 22760 фев 4 21:36 /usr/lib/libcpupower.so.4.13.0-32

For reference, in Debian Stretch I have this:

$ ls -l /usr/lib/libcpupower.so*
lrwxrwxrwx 1 root root 20 янв 4 14:12 /usr/lib/libcpupower.so -> libcpupower.so.0.0.1
-rw-r--r-- 1 root root 22824 янв 4 14:12 /usr/lib/libcpupower.so.0.0.1
lrwxrwxrwx 1 root root 20 янв 4 14:12 /usr/lib/libcpupower.so.1 -> libcpupower.so.0.0.1

I don't know, is it a problem in the patch, or something's with my kernel build?

Ah, I see the problem. There's no .shlibs file for linux-tools-4.13.0-32 in /var/lib/dpkg/info directory. I'll try to add the missing dh_makeshlibs for it...

Ok... mate-applets package builds and installs now, but looks like the real problem is that the cpufreq applet is being linked to the versioned library (instead of libcpupower.so or libcpupower.so.1).

$ ldd /usr/lib/mate-applets/mate-cpufreq-applet | grep cpupower
 libcpupower.so.4.13.0-32 => /usr/lib/libcpupower.so.4.13.0-32 (0x00007f04df4a6000)

In Debian it looks better:

$ ldd /usr/lib/mate-applets/mate-cpufreq-applet | grep cpupower
 libcpupower.so.1 => /usr/lib/libcpupower.so.1 (0x00007f5e94357000)

Vlad, thanks for testing! I don’t have much time to work further on the patch (especially when there is no guarantee for it being applied). Maybe you can try to create an updated patch where dh_makeshlibs will be properly called during build?

Here are the changes that I added after your patch.

The problem is that the cpufreq applet is still linked to libcpupower.so.4.13.0-32 during the build. We need to make it link to libcpupower.so.1, like in Debian.

Looks like it happens because DT_SONAME isn't correct.

Ubuntu:

$ objdump -p /usr/lib/libcpupower.so.4.13.0-32 | grep SONAME
  SONAME libcpupower.so.4.13.0-32

Debian:

$ objdump -p /usr/lib/libcpupower.so.0.0.1 | grep SONAME
  SONAME libcpupower.so.1

So... the modified SONAME is apparently needed for the specific version of cpupower tool to depend strictly on the corresponding version of libcpupower.so.* from the same linux-tools-* package:

$ objdump -p /usr/lib/libcpupower.so.4.15.0-10 | grep SONAME
  SONAME libcpupower.so.4.15.0-10

$ ldd /usr/lib/linux-tools-4.15.0-10/cpupower | grep libcpupower
 libcpupower.so.4.15.0-10 => /usr/lib/libcpupower.so.4.15.0-10 (0x00007fb94ec4b000)

$ dpkg -S /usr/lib/linux-tools-4.15.0-10/cpupower
linux-tools-4.15.0-10: /usr/lib/linux-tools-4.15.0-10/cpupower

$ dpkg -S /usr/lib/libcpupower.so.4.15.0-10
linux-tools-4.15.0-10: /usr/lib/libcpupower.so.4.15.0-10

With such setup, it won't be possible to make mate-cpufreq-applet link against a symlink (like libcpupower.so.1) instead of the versioned library (like libcpupower.so.4.15.0-10).

I really don't know how to solve this without breaking that setup. Anyone has any ideas?

Hello, i don't know if i am in the correct place but i have the following issue:
If i use a monitor with a higher refresh rate then 60 then i will get nasty screen tearing and flickering.

I have a monitor with 75 hz ,a amd rx 480 gpu with open source video drivers.

The work-around the issue that i found is to force the gpu power state to high with the command echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

In my opinion this should be a High importance because it will offer a pour experience when for every user that it's using open source drivers and a high refresh monitor

Any updates on the state of this issue?

@apolitech please do not hijack this bug for a completely unrelated problem. If you believe yours is legit kernel issue then raise a new ticket at https://bugs.launchpad.net/ubuntu/+source/linux/+filebug.

I've built a test kernel that provides a new package linux-tools-dev-<version>. This is probably not what you ultimately want but would that help in any way?

To install it:

$ sudo add-apt-repository ppa:juergh/kernel
$ sudo apt install linux-tools-dev-5.0.0-29

$ dpkg -L linux-tools-dev-5.0.0-29
/.
/usr
/usr/lib
/usr/lib/linux-tools-dev-5.0.0-29
/usr/lib/linux-tools-dev-5.0.0-29/include
/usr/lib/linux-tools-dev-5.0.0-29/include/cpufreq.h
/usr/lib/linux-tools-dev-5.0.0-29/include/cpuidle.h
/usr/lib/linux-tools-dev-5.0.0-29/lib
/usr/share
/usr/share/doc
/usr/share/doc/linux-tools-dev-5.0.0-29
/usr/share/doc/linux-tools-dev-5.0.0-29/changelog.Debian.gz
/usr/share/doc/linux-tools-dev-5.0.0-29/copyright
/usr/lib/linux-tools-dev-5.0.0-29/lib/libcpupower.so

Hi Juerg!

This is a step towards what we want, but ideally it would be nice to have an unversioned package (like linux-tools-dev) that would ship some symlinks in /usr/include and /usr/lib, so that we don’t need to pass -I and -L to gcc.

I understand, I just don't see how we can achieve this. You can have multiple linux-tools packages installed and you'll get different versions of libcpupower. We don't guarantee ABI stability so your running app needs to be linked to the version of the running kernel or it might no longer work.

I just checked Debian and there you can have 2 different versions of libcpupower installed as well and depending on which is installed, the generic link points to a different (kernel) version of libcpupower. How is this expected to work if the ABI is different between the two versions?

$ dpkg -l libcpupower-dev
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===============-===============-============-=====================================================================
ii libcpupower-dev 5.2.9-2~bpo10+1 amd64 CPU frequency and voltage scaling tools for Linux (development files)

$ ls -l /usr/lib/x86_64-linux-gnu/libcpupower.so*
lrwxrwxrwx 1 root root 20 Aug 25 17:28 /usr/lib/x86_64-linux-gnu/libcpupower.so -> libcpupower.so.2.0.1
-rw-r--r-- 1 root root 26840 Aug 28 04:20 /usr/lib/x86_64-linux-gnu/libcpupower.so.0.0.1
lrwxrwxrwx 1 root root 20 Aug 28 04:20 /usr/lib/x86_64-linux-gnu/libcpupower.so.1 -> libcpupower.so.0.0.1
lrwxrwxrwx 1 root root 20 Aug 25 17:28 /usr/lib/x86_64-linux-gnu/libcpupower.so.2 -> libcpupower.so.2.0.1
-rw-r--r-- 1 root root 26840 Aug 25 17:28 /usr/lib/x86_64-linux-gnu/libcpupower.so.2.0.1

Debian has package names that follow upstream SONAME, e.g. libcpupower0, libcpupower2.

The -dev package is used only for building, the resulting binary packages get dependency on library package. When there is ABI break, upstream changes SONAME, so the library package changes too and all reverse dependencies need rebuild.

Can you do the same in Ubuntu?

We roll the kernel (and libcpupower) every 3 weeks and don't guarantee ABI stability so that's not feasible.

Does libcpupower's own ABI actually change with each new Ubuntu kernel?

I think it changes quite rarely:

- Once it changed in Linux 4.7, in commit [1] (April 2016),
- Then it changed in Linux 5.1, in commit [2] (February 2019).

The Debian maintainer has a patch [3] that updates the SONAME version when ABI changes.

There has been an attempt [4] to send that patch upstream, but apparently upstream is not interested in that.

However, if ABI breaks once in three years, maybe it’s not that difficult to maintain a patch?

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ac5a181d065d74fb
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae2917093fb60bdc
[3]: https://salsa.debian.org/kernel-team/linux/blob/master/debian/patches/bugfix/all/cpupower-bump-soname-version.patch
[4]: https://patchwork.kernel.org/patch/9168711/

Probably not but we have no tooling in place to check. And we also support different kernel versions on every release. For example, the main Bionic kernel is based on 4.15 and the (current) Bionic hwe kernel is based on 5.0 but that's a moving target. And we could introduce other kernels for Bionic in the future. Any update of any of those kernels could break the libcpupower ABI and simply incrementing a SONAME number will not be sufficient IMO.

Hmm, I didn't know upstream didn't bump the SONAME with the latest breaking change...

Hi again Juerg and all,

I want to mention that upstream Linux developers actually *do* care about ABI stability.

For example, one of the commits broke ABI but it was quickly reverted and then fixed in a way that does not change the ABI:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=41ddb7e1f79693d9

Please reconsider providing a public -dev package again. For applications that want to know information about CPUs, the only alternative is using libcpufreq. However that library is abandoned both upstream and in Debian, and recently I have seen it returning junk data.

The affected applications are:

$ reverse-depends -b libcpufreq-dev -r focal
Reverse-Build-Depends
* cpufreqd
* gkrellm2-cpufreq
* gnome-applets
* mate-applets
* xfce4-cpufreq-plugin

During my +1 maintenance I looked at both gkrellm2-cpufreq and cpufreqd (ppc64el arch only) both of which are depwait in groovy because Ubuntu does not have a libcpupower-dev package. If Ubuntu isn't going to provide the libcpupower-dev package we should blacklist packages which depend on it so people doing +1 maintenance don't keep spending time on it.

The Eoan Ermine has reached end of life, so this bug will not be fixed for that release

Yeah as Brian I came by this a while ago (and now again). Bug 1891336 is about the same.
This one here is older and closer to a conclusion.
So I'll make the other one a dup, but added bug-tasks and an update-excuse tag to show up in excuses.

Hi Christian! In comments #11 and #17 there are some patches for this bug. They probably need rebasing though.

Yeah Dmitry, thanks for reminding everyone about it.

But TBH I have not had the feeling that the feeling that the kernel team (which needs to do it) had started working/thinking on this case.

@Kernel Team - ping is this on your radar at all or did it fall through the cracks?