gkrellm2-cpufreq depends on libcpupower-dev produced by Debian kernel

[Christian Ehrhardt ]

I don't know how important that is as gkrellm2-cpufreq itself is scheduled for removal.
But I wanted to make sure that it is known that the Debian kernel produces "libcpupower-dev" which isn't available in Ubuntu and thereby blocking various things in proposed.

root@d10-sid:~# apt-cache show libcpupower-dev
Package: libcpupower-dev
Source: linux
Version: 5.7.10-1
Installed-Size: 169
Maintainer: Debian Kernel Team <email address hidden>
Architecture: amd64
Replaces: libcpufreq-dev
Provides: libcpufreq-dev
Depends: libcpupower1 (= 5.7.10-1)
Conflicts: libcpufreq-dev
Description-en: CPU frequency and voltage scaling tools for Linux (development files)
 libcpupower is a library for inspecting and controlling cpufreq and
 cpuidle tunables.
 .
 This package is needed to compile programs against libcpupower.

gkrellm2-cpufreq will most likely be removed from goovy as it makes no sense without that build-dep.
Never the less the kernel Team could evaluate if providing "libcpupower-dev" makes sense for Ubuntu.

[Christian Ehrhardt  (paelzer)]

Present on Debian, but not Ubuntu:

$ rma libcpupower-dev
libcpupower-dev | 4.9.228-1 | oldstable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libcpupower-dev | 4.19.118-2+deb10u1~bpo9+1 | stretch-backports | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libcpupower-dev | 4.19.132-1 | stable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libcpupower-dev | 5.7.10-1~bpo10+1 | buster-backports | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libcpupower-dev | 5.7.10-1 | testing | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
libcpupower-dev | 5.7.10-1 | unstable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x

[Christian Ehrhardt  (paelzer)]

The new update to "cpufreqd" now also build-depends on libcpupower-dev.
This is more common to be used, so the prio slightly increases IMHO.

OTOH cpufreqd already has delta, and we might as well try to build differently.
The package seems community/foundations maintained, but not in main.
Adding a bug task for it.

The Debian package has no git VCS entry to check when/why they changed build deps.

$ rma cpufreqd
cpufreqd | 2.4.2-2 | oldoldstable | source, amd64, armel, armhf, i386
cpufreqd | 2.4.2-2 | oldstable | source
cpufreqd | 2.4.2-2 | stable | source
cpufreqd | 2.4.2-2+b1 | oldstable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
cpufreqd | 2.4.2-2+b2 | stable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, s390x
cpufreqd | 2.4.2-2.3 | testing | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, s390x
cpufreqd | 2.4.2-2.3 | unstable | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, s390x
cpufreqd | 2.4.2-2.3 | unstable-debug | source
cpufreqd | 2.4.2-2.3+b1 | testing | ppc64el
cpufreqd | 2.4.2-2.3+b1 | unstable | ppc64el

 cpufreqd | 2.4.2-1 | precise/universe | source, amd64, armel, armhf, i386, powerpc
 cpufreqd | 2.4.2-2ubuntu1 | trusty/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el
 cpufreqd | 2.4.2-2ubuntu1 | xenial/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
 cpufreqd | 2.4.2-2ubuntu2 | bionic/universe | source, amd64, arm64, armhf, i386, ppc64el, s390x
 cpufreqd | 2.4.2-2ubuntu3 | eoan/universe | source, amd64, arm64, armhf, i386, ppc64el, s390x
 cpufreqd | 2.4.2-2ubuntu3 | focal/universe | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
 cpufreqd | 2.4.2-2ubuntu3 | groovy/universe | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
 cpufreqd | 2.4.2-2.2ubuntu1 | groovy-proposed/universe | source, amd64, arm64, armhf, riscv64, s390x

[Brian Murray (brian-murray)]

See also bug 1215411 for some discussion regarding providing libcpupower.

[Bryce Harrington (bryce)]

It appears to fail only for ppc64el. The proper solution sounds to be complicated; would it be suitable as a temporary workaround to drop that arch from the cpufreqd package (and leave this bug open until the underlying issue is resolved)?