Since a week or so Collectd-mod-cpufreq isn't available on RT3200 snapshot. Is there a reason for this or permanent?
Usually this is because of a build error with a package, but I just did a full package build and it worked fine.
My suspicion is that there was a change in what target was used on the buildbots to make the packages for the aarch64_cortex-a53/ and aarch64_cortex-a72/ architectures. The cpufreq module will only build on Mediatek targets, but they are located in with the target-independent architecture packages. So if a non-Mediatek Arm 64 target was used for the buildbot when it built those packatges, colledf-mod-cpufreq wouldn't get built. That's all I can figure.
This was built based on Master that was pulled yesterday, feel free to use: https://va1der.ca/~public/openwrt/bin/aarch64/collectd-mod-cpufreq_5.12.0-43_aarch64_cortex-a53.ipk
Someone with access to the buildbots will have to weigh in on why the package disappeared from snapshots though.
It looks like the linux-bcm27xx_bcm2710 sdk is used for a53 on master. It is armvirt/64 on openwrt-22.03
Master:
22.03:
What SDK gets used for the shared package set in phase2 is undefined and pretty much random (whatever gets to it first), the packages' build recipes need to define their requirements correctly (e.g. via non-shared).
Since there are packages that depend this being a particular target, is there any way to massage this?
Or, since there is no actual hard restriction on building collectd-mod-cpufreq for other targets (it just can't be used on targets without CPU scaling), perhaps the answer is to remove the restriction in its Makefile on building only with a Mediatek target.
The alternatives would be to either make it non-shared or make it behave properly on a system without scaling and then to drop the dependency.
I'm not sure I understand this dichotomy.
Prior to a few days ago, it seems that most of the time a Mediatek build was supplying the packages for the aarch64 architectures. This meant that the collect-mod-cpufreq package was in the public repository and availalble to any target on those architectures. Even targets that couldn't use it. This has been the case for some time, since I use that package and was never unable to download and install it when I wanted to. This didn't break OpenWrt. I don't see why we can't just remove the dependency, which will cause the package to reappear for all.
Since the package has been in the public repository in the past, the ONLY people in the past that the dependency caused the package not to be built for are for people who conducted a full package build at home. I don't think that this package suddenly appearing in full home builds for other-than-Mediatek aarch64 targets is going to break anything either.
In short, it's pretty safe to just remove the dependency.
And to emphasize, it’s more than Mediatek.
Apparently it's clear why this package isn't presented/build anymore.
Is someone correcting this or should it be reported elsewhere?
Or is this package permanently dropped? (would be a shame).
2 Likes
The reason is probably that aarch64_cortex-a53 is currently using bcm27xx/bcm2710 SDK for the package compilation, so neither TARGET_armsr or TARGET_mediatek gets matched.
(see step 7 download SDK in https://buildbot.staging.openwrt.org/master/packages/#/builders/14/builds/72 )
rsync -4 -va 'downloads.openwrt.org::downloads/snapshots/targets/bcm27xx/bcm2710/openwrt-sdk-*.tar.xz' sdk.archive
in dir /builder/aarch64_cortex-a53/build (timeout 1200 secs)
watching logfiles {}
argv: [b'rsync', b'-4', b'-va', b'downloads.openwrt.org::downloads/snapshots/targets/bcm27xx/bcm2710/openwrt-sdk-*.tar.xz', b'sdk.archive']
using PTY: False
receiving incremental file list
openwrt-sdk-bcm27xx-bcm2710_gcc-12.3.0_musl.Linux-x86_64.tar.xz
The easiest cure is probably to remove the target dependency and just let the module get built for all targets, even if they do not actually support any frequency scaling.
I will do that.
EDIT:
I authored the fix to both main/master and 23.05.
1 Like