libcpupower.so is not installed from linux-tools

Bug #1215411 reported by Artem Popov
56
This bug affects 7 people
Affects Status Importance Assigned to Milestone
cpufreqd (Ubuntu)
Confirmed
Undecided
Unassigned
gkrellm2-cpufreq (Ubuntu)
Confirmed
Undecided
Unassigned
linux (Ubuntu)
In Progress
Medium
Unassigned
opa-ff (Ubuntu)
New
Undecided
Unassigned

Bug Description

The patch for bug 1158668 installs cpupower_$(abi_version) command-line tool as well as libcpupower.so.$(abi_version).

This isn't particularly suitable for projects that previously used libcpufreq and intend to migrate to libcpupower, because the libcpupower.so symlink is no longer installed. The command-line tools can also have symlinks (e.g. cpupower -> cpupower_$(abi_version)).

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

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.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: saucy
Tim Gardner (timg-tpi)
Changed in linux (Ubuntu Saucy):
assignee: nobody → Tim Gardner (timg-tpi)
status: Incomplete → In Progress
Tim Gardner (timg-tpi)
Changed in linux (Ubuntu Saucy):
assignee: Tim Gardner (timg-tpi) → Kamal Mostafa (kamalmostafa)
Changed in linux (Ubuntu Saucy):
importance: Undecided → Medium
Revision history for this message
Joseph Salisbury (jsalisbury) wrote : Closing unsupported series nomination.

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.

Changed in linux (Ubuntu Saucy):
status: In Progress → Won't Fix
Revision history for this message
Vlad Orlov (monsta) wrote : Re: libcpupower.so is not installed from linux-tools (saucy)

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

tags: added: trusty xenial yakkety
Revision history for this message
Vlad Orlov (monsta) wrote :

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

Changed in linux (Ubuntu):
status: In Progress → Confirmed
Revision history for this message
Dmitry Shachnev (mitya57) wrote :

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

no longer affects: linux (Ubuntu Saucy)
Changed in linux (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Dmitry Shachnev (mitya57) wrote :

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.

Changed in linux (Ubuntu):
assignee: Kamal Mostafa (kamalmostafa) → Ubuntu Kernel Team (ubuntu-kernel-team)
tags: added: patch
Tim Gardner (timg-tpi)
Changed in linux (Ubuntu Zesty):
assignee: Ubuntu Kernel Team (ubuntu-kernel-team) → Tim Gardner (timg-tpi)
status: Triaged → In Progress
Revision history for this message
Tim Gardner (timg-tpi) wrote :

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.

Changed in linux (Ubuntu Zesty):
assignee: Tim Gardner (timg-tpi) → nobody
Revision history for this message
Dmitry Shachnev (mitya57) wrote :

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?

Revision history for this message
Dmitry Shachnev (mitya57) wrote :

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

Vlad Orlov (monsta)
tags: added: zesty
removed: saucy
summary: - libcpupower.so is not installed from linux-tools (saucy)
+ libcpupower.so is not installed from linux-tools
Vlad Orlov (monsta)
tags: added: artful
Revision history for this message
Vlad Orlov (monsta) wrote :

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

Vlad Orlov (monsta)
tags: added: bionic
Revision history for this message
Dmitry Shachnev (mitya57) wrote :

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.

Revision history for this message
Vlad Orlov (monsta) wrote :

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

Revision history for this message
Vlad Orlov (monsta) wrote :

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?

Revision history for this message
Vlad Orlov (monsta) wrote :

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...

Revision history for this message
Vlad Orlov (monsta) wrote :

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)

Revision history for this message
Dmitry Shachnev (mitya57) wrote :

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?

Revision history for this message
Vlad Orlov (monsta) wrote :

Here are the changes that I added after your patch.

Revision history for this message
Vlad Orlov (monsta) wrote :

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.

Revision history for this message
Vlad Orlov (monsta) wrote :

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

Revision history for this message
Vlad Orlov (monsta) wrote :

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?

Vlad Orlov (monsta)
tags: added: cosmic
removed: artful yakkety zesty
Vlad Orlov (monsta)
tags: added: disco
Changed in linux (Ubuntu Zesty):
status: In Progress → Invalid
Vlad Orlov (monsta)
tags: added: eoan
Brad Figg (brad-figg)
tags: added: cscc
Revision history for this message
APolihron (apolitech) wrote :

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

Revision history for this message
APolihron (apolitech) wrote :

Any updates on the state of this issue?

Revision history for this message
Juerg Haefliger (juergh) wrote :

@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.

Revision history for this message
Juerg Haefliger (juergh) wrote :

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

Revision history for this message
Dmitry Shachnev (mitya57) wrote :

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.

Revision history for this message
Juerg Haefliger (juergh) wrote :

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

Revision history for this message
Dmitry Shachnev (mitya57) wrote :

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?

Revision history for this message
Juerg Haefliger (juergh) wrote :

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

Revision history for this message
Vlad Orlov (monsta) wrote :

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

Revision history for this message
Dmitry Shachnev (mitya57) wrote :

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/

Revision history for this message
Juerg Haefliger (juergh) wrote :

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.

Revision history for this message
Vlad Orlov (monsta) wrote :

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

Revision history for this message
Dmitry Shachnev (mitya57) wrote :

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

tags: added: rls-gg-incoming
Revision history for this message
Brian Murray (brian-murray) wrote :

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.

Revision history for this message
Brian Murray (brian-murray) wrote :

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

Changed in linux (Ubuntu Eoan):
status: In Progress → Won't Fix
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

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.

no longer affects: cpufreqd (Ubuntu Zesty)
no longer affects: cpufreqd (Ubuntu Eoan)
no longer affects: gkrellm2-cpufreq (Ubuntu Zesty)
no longer affects: gkrellm2-cpufreq (Ubuntu Eoan)
Changed in cpufreqd (Ubuntu):
status: New → Confirmed
Changed in gkrellm2-cpufreq (Ubuntu):
status: New → Confirmed
tags: added: update-excuses
tags: added: update-excuse
removed: update-excuses
Revision history for this message
Dmitry Shachnev (mitya57) wrote :

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

no longer affects: linux (Ubuntu Zesty)
no longer affects: linux (Ubuntu Eoan)
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

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?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.