There seems to be a borkage in the stable tree that makes kernel builds get installed where vanilla-sources get EXTRAVERSION set to "2.4.22", which then proceeds to break with genkernel. unpleasant at the best. there also seems to be a broken [ ] statement early in unpacking. Reproducible: Always Steps to Reproduce: 1. 2. 3.
confirmed. the problem is in kernel.eclass: cvs-id 1.35 adds the kernel-version again to EXTRAVERSION in the top-level Makefile. cvs-id 1.31 worked. I'd guess that all kernel ebuilds with something "extra" added in the ebuild-name (ac-sources?) to determine the version of a patch will get a wrong EXTRAVERSION and a wrong modules-dir. the modules may even get overwritten by a new version of a patch ...
this should be fixed in cvs now
sorry, still does not work here with kernel.eclass cvs-id 1.41. I'm using the following home-grown kernel-ebuild: --- snipp --- ETYPE="sources" inherit kernel OKV=2.4.20 KV=2.4.20 EXTRAVERSION="-tom" S=${WORKDIR}/linux-${KV} src_unpack() { unpack linux-${OKV}.tar.bz2 cd ${WORKDIR} mv linux-${OKV} linux-${KV}${EXTRAVERSION} || die "mv to -extraversion failed" cd ${WORKDIR} cd linux-${KV}${EXTRAVERSION} patch -p1 < ${FILESDIR}/tom.patch || die "patch failed" kernel_universal_unpack } --- snapp --- this results in an EXTRAVERSION of "-2.4.20" instead of "-tom"
cvs-id 1.42 works as expected -- so we can leave this resolved. Thanks lostlogic.
