MATE 1.8 ARM keywording needs this, see the blocked bug; thank you in advance.
Is pciutils really a hard dependency? 99% of arm boards don't have PCI, so that seems kind of silly to install on there... And it's pulled from the kernel sources? Isn't it a bit silly to pull a 75MB file down, just to build a 50K binary and a 19K library? Ah upstreams, how I miss having sane ones... That being said - it will build, however, I'd like to patch this to make it not link against libpci on !x86 machines. It does work, but I suppose I'll need to open a bug for cpupower itself... xu cpupower # LD_LIBRARY_PATH=. ./cpupower Usage: cpupower [-c|--cpu cpulist ] <command> [<args>] Supported commands are: frequency-info frequency-set idle-info idle-set set info monitor help Not all commands can make use of the -c cpulist option. Use 'cpupower help <command>' for getting help for above commands. xu cpupower # ldd cpupower libcpupower.so.0 => not found librt.so.1 => /lib/librt.so.1 (0xb6f52000) libc.so.6 => /lib/libc.so.6 (0xb6e22000) libpthread.so.0 => /lib/libpthread.so.0 (0xb6e02000) /lib/ld-linux-armhf.so.3 (0xb6f61000) I'll leave it up to maekke to decide if he wants to keyword this with the pci-utils dependency in there. That also being said, it doesn't seem like cpupower actually does anything on ARM - but that could be because this is from a 3.14 kernel, and the machine is using an older kernel... xu cpupower # LD_LIBRARY_PATH=. ./cpupower info System's multi core scheduler setting: not supported System's thread sibling scheduler setting: not supported System does not support Intel's performance bias setting xu cpupower # LD_LIBRARY_PATH=. ./cpupower frequency-info couldn't analyze CPU 0 as it doesn't seem to be present xu cpupower # LD_LIBRARY_PATH=. ./cpupower idle-info Could not determine cpuidle driver I mean, we can keyword it, but whatever it's being used for, it isn't going to work properly.
(In reply to Steev Klimaszewski from comment #1) > Is pciutils really a hard dependency? 99% of arm boards don't have PCI, so > that seems kind of silly to install on there... > > And it's pulled from the kernel sources? Isn't it a bit silly to pull a > 75MB file down, just to build a 50K binary and a 19K library? Ah upstreams, > how I miss having sane ones... That's why I'm only bumping to major releases, like 3.13 -> 3.14 -> 3.15, as that source tarball will be pulled in by linux-headers, gentoo-sources, and so forth anyway > That being said - it will build, however, I'd like to patch this to make it > not link against libpci on !x86 machines. It does work, but I suppose I'll > need to open a bug for cpupower itself... #if defined(__i386__) || defined(__x86_64__) in /usr/src/linux-3.13.4/tools/power/cpupower/utils/helpers/pci.c so maybe you can indeed drop the -lpci (or, rather the pkg-config stuff the ebuild uses to replace -lpci) from linker line for ARM i accept patches ;)
but this should be keyworded anyway asap, and the -lpci thing move to it's own bug, because it's stupid to hold *a desktop* like MATE (re: bug 508072) hostage for an ebuild enhancement
(In reply to Samuli Suominen from comment #3) > but this should be keyworded anyway asap, and the -lpci thing move to it's > own bug, because it's stupid to hold *a desktop* like MATE (re: bug 508072) > hostage for an ebuild enhancement Who said anything about holding a desktop hostage? I'm very familiar with MATE - it's what I use, on ARM and x86 - I'm saying that cpupower *doesn't WORK* - compiles fine, yes, but it doesn't DO anything, and I'm pretty sure it's supposed to be used similarly to cpufreq-utils was, since I think this is what replaces it. But the question is, is this now tightly coupled to the kernel as well?
Added ~arm keywording. It would have been nice to have some of my comments here addressed, but since all we care about is putting in the keyword, there you go.
