Closed inglor closed 3 years ago
I have not jump to 5.12 yet. Developpements are too draft for a merge. I will push a 5.12 untested hotfix on master ASAP
I don't catch.
I made a cherry-pick
from the development commit which is fixing 5.12
But that fix was already in CoreFreq 1.84 !
https://github.com/cyring/CoreFreq/blob/61cabad55486b4b54c19080f76ed3e234df71afc/corefreqk.c#L52
Is your fork outdated ?
This is on Archlinux where the 5.12
is already in testing
and some packages are already updated to 5.12
(like linux-ck
)
The source is fetched from: https://github.com/cyring/CoreFreq/archive/tag/1.84.tar.gz
See my logs
$ sudo dkms install --no-depmod -m corefreq -v 1.84 -k 5.12.0-1-ck
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area...
make -j32 KERNELRELEASE=5.12.0-1-ck -C /usr/src/corefreq-1.84 KERNELDIR=/usr/lib/modules/5.12.0-1-ck/build...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.12.0-1-ck (x86_64)
Consult /var/lib/dkms/corefreq/1.84/build/make.log for more information.
$ cat /var/lib/dkms/corefreq/1.84/build/make.log
DKMS make.log for corefreq-1.84 for kernel 5.12.0-1-ck (x86_64)
Fri 30 Apr 14:51:29 BST 2021
make: Entering directory '/usr/src/corefreq-1.84'
cc -Wall corefreqd.c corefreqm.c \
-D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=5250000000 -D UBENCH=0 \
-o corefreqd -lpthread -lm -lrt
cc -Wall \
corefreq-cli.c corefreq-ui.c corefreq-cli-rsc.c \
corefreq-cli-json.c corefreq-cli-extra.c \
-D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=5250000000 -D UBENCH=0 \
-o corefreq-cli -lm -lrt
make -j1 -C /usr/lib/modules/5.12.0-1-ck/build M=/var/lib/dkms/corefreq/1.84/build modules
make[1]: Entering directory '/usr/src/corefreq-1.84'
make[1]: warning: -j1 forced in submake: resetting jobserver mode.
CC [M] /var/lib/dkms/corefreq/1.84/build/corefreqk.o
/var/lib/dkms/corefreq/1.84/build/corefreqk.c:52:26: error: expected declaration specifiers or ‘...’ before string constant
52 | MODULE_SUPPORTED_DEVICE ("Intel,AMD,HYGON");
| ^~~~~~~~~~~~~~~~~
make[2]: *** [scripts/Makefile.build:271: /var/lib/dkms/corefreq/1.84/build/corefreqk.o] Error 1
make[1]: *** [Makefile:1855: /var/lib/dkms/corefreq/1.84/build] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.12.0-1-ck/build'
make: *** [Makefile:70: all] Error 2
make: Leaving directory '/usr/src/corefreq-1.84'
The problem is master
has moved on from 1.84
tag significanty which includes the compatibility with kernel 5.12
. See comparison:
https://github.com/cyring/CoreFreq/compare/1.84...master
I don't make use of tags
beside to inform about major.minor
but don't track revision
My previous PKGBUILD
did not fetch from archive but directly from current GitHub master, including latest revisions.
It's much better to have a stable tag than master
which keeps evolving.
It's much better to have a stable tag than
master
which keeps evolving.
I'm mainly reserving revision
for hotfixes on master and API changes, but indeed don't do tags whenever a revision
happens.
That's why I used PKGBUILD
that way:
# Maintainer: CyrIng <labs[at]cyring[dot]fr>
_gitname=CoreFreq
pkgname=corefreq-git
realname=corefreq
pkgver=<M>.<m>
pkgrel=<r>
pkgdesc="CoreFreq, Processor monitoring software with BIOS like functionalities"
arch=('x86_64')
url='https://github.com/cyring/CoreFreq'
license=('GPL2')
depends=('dkms')
makedepends=('git')
source=(git+${url}.git)
md5sums=('SKIP')
install=${realname}.install
package() {
cd ${srcdir}/${_gitname}
BINDIR=${pkgdir}/bin
SRCTREE=${pkgdir}/usr/src
DRVTREE=${SRCTREE}/corefreqk-${pkgver}
# dkms setup
install -Dm 0644 Makefile ${DRVTREE}/Makefile
install -Dm 0644 dkms.conf ${DRVTREE}/dkms.conf
install -Dm 0755 scripter.sh ${DRVTREE}/scripter.sh
install -m 0644 *.c *.h ${DRVTREE}/
# systemd setup
install -Dm 0644 corefreqd.service \
${pkgdir}/usr/lib/systemd/system/corefreqd.service
}
where:
pkgver
for CoreFreq Major.minor
pkgrel
for CoreFreq revision
Indeed, this was not the ArchLinux way to do it but it was a mean to follow the project progress and I could notify the AUR of any new upstream revision.
I see. To summarize there's no tagged release which is compatible with 5.12. I'm not a fan of switching the corefreq
stable package to tracking master
, instead I will look at back-porting the patch~es~.
edit:
Just need the f6a350b
For future reference, downstream maintainers expect tags and will always follow such practices. It was also clear on my PR for adding the links for Archlinux packages.
For future reference, downstream maintainers expect tags and will always follow such practices. It was also clear on my PR for adding the links for Archlinux packages.
Thanks for your packages.
Recreating the 1.84
tag. Hope it makes things better.
Hi @cyring
Version 1.84 doesn't build with latest released kernel version
5.12
. Thedevelop
branch works OK - time to release or patch the1.84
release?