Kernel versions 2.6.9-rc and later do have the ability to set a version appendix in the configuration, so that you don't have to edit the makefile any more. This breaks *all* kernel related ebuilds, because ${KV} contains the wrong version. See the kernel Makefile: VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 9 EXTRAVERSION = -rc4 LOCALVERSION = $(subst $(space),, \ $(shell cat /dev/null $(localversion-files)) \ $(subst ",,$(CONFIG_LOCALVERSION))) KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(LOCALVERSION) So ${KV} should either to the same thing, the makefile does or should use $(uname -r) for kernel version. And no, it's not an option to replace ${KV} with $(uname -r) in all related ebuild files. ;-)
uname -r won't be an acceptable solution as it goes against policy. investigating.
*** Bug 68728 has been marked as a duplicate of this bug. ***
John, any progress on this? Would like to see it fixed..
$KV is defined in portage.py so I'm reassigning to them. Here's the story: 2.6.9 introduced a new kernel config option allowing the user to define their own custom string to append to the kernel version string. For example, development-sources-2.6.9 normally has a version string of "2.6.9", but if I set the new CONFIG_LOCALVERSION option to "-dsd" then my version string would be "2.6.9-dsd". (there are other ways to set localversion, read on..) When I do "make modules_install" from the kernel source tree, modules get installed in "/lib/modules/2.6.9-dsd". I reboot into my new kernel, modprobe correctly finds the modules at that location and loads them without problem. I then come to install an external module available in portage (e.g. nvidia-kernel). I emerge this, portage detects my kernel version string as "2.6.9" so installs the module under "/lib/modules/2.6.9". I then come to "modprobe nvidia", and modprobe can't find the module. Here's what needs to be done: The function "ExtractKernelVersion" in portage.py needs to be extended to parse the localversion. This is quite tricky, perhaps there is a better solution? When defining the localversion, the kernel makefile will first search for files at /usr/src/linux/localversion* and read them in alphabetical order, appending each one to the localversion string. It will then read the value of CONFIG_LOCALVERSION found in /usr/src/linux/.config and append that. If any spaces are present in any localversion, they will be removed. For example: /usr/src/linux/localversion-a reads "-gen too" /usr/src/linux/localversion-b reads "-test" /usr/src/linux/.config contains the following line: CONFIG_LOCALVERSION="-dsd" The localversion here would be "-gentoo-test-dsd". Assuming the kernel source was standard 2.6.9, when I then boot into my kernel, the version string would be "2.6.9-gentoo-test-dsd" and modules would be placed at "/lib/modules/2.6.9-gentoo-test-dsd". Remember that on an unconfigured kernel, a .config file will not exist. And obviously, there might not be any localversion* files existing. So perhaps extending "ExtractKernelVersion" for all this isn't the best idea. How would you guys propose that we handle this?
Most things that require the kernel version require the kernel to be configured and compiled, no? I can't think of anyting that doesn't and, if there is, it wouldn't be a kernel module right? I'm pretty sure extending ExtractKernelVersion to follow the logic you've described will suffice. After all, if the kernel isn't configured and compiled, there won't be a localversion (beyond the files defined if any).
Please confirm this by the way...
Sounds good. As long as portage doesn't bail out if no .config exists or something like that - it should do its best to construct the localversion out of what is present.
Many ebuilds already rely on building against a configured kernel - all external kernel modules do this.
Created attachment 43002 [details, diff] fix-portage-kernel-localversion.patch Jason, you rock! Just tested it out, and found a couple of problems. the localversion files weren't being read, and portage produces a traceback when no .config exists. I've fixed it with this patch.. but bear in mind that its the first python code i've ever touched :)
Added the patch to CVS and will add the lot to portage_2_0 now.
*** Bug 70906 has been marked as a duplicate of this bug. ***
I reported the duplicate bug 70906.. sorry I missed this one. I also wrote a patch for it attached there, if anyone cares to check it out. But it looks like you guys pretty much have it solved..
*** Bug 71626 has been marked as a duplicate of this bug. ***
thanks to all those involved. I think since then it has been agreed that portage is the wrong place to be setting KV, and linux-info is already in the tree to cater for this.
