Without this patch the kvm ebuild will only work on systems where the kernel source directory is the same as the linux build directory. This is because of a naive test for the source directory (takes /* off of the tail and adds on /source). I tested this patch with a combined directory and it works for both. --- /usr/portage/app-emulation/kvm/kvm-81.ebuild 2008-12-16 15:30:13.000000000 +0000 +++ kvm-81-r1.ebuild 2008-12-30 03:56:18.000000000 +0000 @@ -117,7 +117,7 @@ use esd && audio_opts="esd $audio_opts" use pulseaudio && audio_opts="pa $audio_opts" use sdl && audio_opts="sdl $audio_opts" - use modules && conf_opts="$conf_opts --kerneldir=$KV_DIR" + use modules && conf_opts="$conf_opts --kerneldir=/lib/modules/$KV_FULL/build" conf_opts="$conf_opts --disable-gcc-check" conf_opts="$conf_opts --prefix=/usr" #conf_opts="$conf_opts --audio-drv-list=\"$audio_opts\"" Reproducible: Always Steps to Reproduce: 1. Compile kernel in a seperate directory to /usr/src/linux-* (e.g. with make O=/kernel/build/directory) 2. Try to compile kvm ebuild against this kernel Actual Results: Ebuild fails because kvm's configure script looks for the kernel source in /usr/src/source Expected Results: Ebuild works as for combined kernel source/build directory.
There must be something wrong with your setup. KV_DIR is supposed to handle the /lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build, according to your eclass. Does /usr/src/linux exist, but you just don't use it? If so, nuke it.
I confirmed this on a friend's machine (after building a kernel there out of directory). Also if I remove /usr/src/linux this happens: * Determining the location of the kernel source code * Unable to find kernel sources at /usr/src/linux * This package requires Linux sources. * Please make sure that /usr/src/linux points at your running kernel, * (or the kernel you wish to build against). * Alternatively, set the KERNEL_DIR environment variable to the kernel sources location * * ERROR: app-emulation/kvm-81 failed. * Call stack: * ebuild.sh, line 49: Called pkg_setup * kvm-82-r1.ebuild, line 44: Called linux-info_pkg_setup * linux-info.eclass, line 696: Called die * The specific snippet of code: * get_version || die "Unable to calculate Linux Kernel version" * The die message: * Unable to calculate Linux Kernel version * * If you need support, post the topmost build error, and the call stack if relevant.
This is probably a bug in the linux-mod eclass, then. I'm not particularly interested in working around that eclass. kernel-misc: Is this supposed to work? If so, what am I doing wrong? If not, should it be fixed in the eclass?
No the bug isn't in the linux-mod eclass, I've already checked that. The bug is due to an incorrect assumption in the configure script of kvm as I mentioned. You can check the configure script yourself in the area that detects the source directory for the fault, as I mentioned it is a simple substitution of /build$ to /source. I really think this patch should be applied to work around the kvm configure script problem, or a patch for the configure script should go in your patch list. I'm sure a lot if not most gentoo users compile their kernel in a separate directory to the source directory.
Looking at /lib/modules/$KV_FULL/build is not the right solution because that requires the kernel to be installed, and our linux-mod system does not require that. The usual thing to do is to pass both $KV_DIR and $KV_OUT_DIR to the package's build system. If kvm does not have a hook for separate source and build directories, then you can maybe add one by looking at how other packages do it. sys-fs/fuse is one example, which has: ECONF_PARAMS="--with-kernel=${KV_DIR} --with-kernel-build=${KV_OUT_DIR}"
(In reply to comment #5) > Looking at /lib/modules/$KV_FULL/build is not the right solution because that > requires the kernel to be installed, and our linux-mod system does not require > that. > > The usual thing to do is to pass both $KV_DIR and $KV_OUT_DIR to the package's > build system. If kvm does not have a hook for separate source and build > directories, then you can maybe add one by looking at how other packages do it. > sys-fs/fuse is one example, which has: > ECONF_PARAMS="--with-kernel=${KV_DIR} --with-kernel-build=${KV_OUT_DIR}" > 1. KVM requires the kernel to be installed anyway. 2. I don't care about what linux-mod wants, when kvm needs the kernel to be installed anyway.. the fix is for the kvm build script not the eclass. 3. If you don't want to pass KV_DIR then a patch is required for the configure script if you want to be anal about things, and since there's so many comments for such a stupid small thing you obviously do ;) This patch would benefit a lot of people and not negatively impact anyone. The configure fix would be slightly cleaner. What was I removed from the CC list?
linux_mod doesn't need the kernel to be installed *at the time the package is emerged*. Obviously it needs to be installed before it's used. Not the same thing at all. That, I suspect, benifits a lot more people (me included) than separate object directories for a kernel. I have yet to even get a separate object directory to work at all for 2.6.28 (which changed include path layout for x86, it seems). I'm certainly not going to change the kvm build to make it less flexible when it doesn't work at all current kernels. So here's a question: Can you do a separate object directory for 2.6.28? If so, can you build kvm against it in any way? If so, how? I didn't remove anyone from CC, so I don't know how you got removed.
(In reply to comment #7) > linux_mod doesn't need the kernel to be installed *at the time the package is > emerged*. Obviously it needs to be installed before it's used. Not the same > thing at all. That, I suspect, benifits a lot more people (me included) than > separate object directories for a kernel. I have yet to even get a separate > object directory to work at all for 2.6.28 (which changed include path layout > for x86, it seems). I'm certainly not going to change the kvm build to make it > less flexible when it doesn't work at all current kernels. What? This makes the build MORE FLEXIBLE. Please read what I have said.. understand it.. then make a comment. I have a much greater understanding of the kernel build process and the kvm build process than you, and the frustration of trying to get any fix in is too much when people constantly reply to me without understanding the situation. Please just read my patch and the configure script! If you still can't tell what is happening you don't have the capabilities or skills to be able to maintain this ebuild. > > So here's a question: Can you do a separate object directory for 2.6.28? If > so, can you build kvm against it in any way? If so, how? I made my own overlay, which is identical to yours but has my patch applied. This builds against kernels regardless of their object directory. > I didn't remove anyone from CC, so I don't know how you got removed. Yeah weird that!
(In reply to comment #8) > (In reply to comment #7) > > linux_mod doesn't need the kernel to be installed *at the time the package is > > emerged*. Obviously it needs to be installed before it's used. Not the same > > thing at all. That, I suspect, benifits a lot more people (me included) than > > separate object directories for a kernel. I have yet to even get a separate > > object directory to work at all for 2.6.28 (which changed include path layout > > for x86, it seems). I'm certainly not going to change the kvm build to make it > > less flexible when it doesn't work at all current kernels. > > What? This makes the build MORE FLEXIBLE. > > Please read what I have said.. understand it.. then make a comment. > > I have a much greater understanding of the kernel build process and the kvm > build process than you, and the frustration of trying to get any fix in is too > much when people constantly reply to me without understanding the situation. > > Please just read my patch and the configure script! If you still can't tell > what is happening you don't have the capabilities or skills to be able to > maintain this ebuild. > > > > > So here's a question: Can you do a separate object directory for 2.6.28? If > > so, can you build kvm against it in any way? If so, how? > > I made my own overlay, which is identical to yours but has my patch applied. > This builds against kernels regardless of their object directory. > > > I didn't remove anyone from CC, so I don't know how you got removed. > > Yeah weird that! > As a further note, I've tested this build on both: linux-2.6.27.6 linux-2.6.28 Actually I updated the ebuild for the next kvm version also when I did this test. I can supply the new ebuild if you want.
(In reply to comment #8) > What? This makes the build MORE FLEXIBLE. > > Please read what I have said.. understand it.. then make a comment. In addition, perhaps you could re-read Dang's comment too. At least by my judgement of his last comment, he acknowledges that separated source objects is something worth supporting, however he is having trouble getting a kernel built in this way. Perhaps you could give him a helping hand by explaining how you build your kernels in this way. Us maintainers do not commit things without performing our own testing, and at the moment, Daniel is unable to do that. You do not need to explain in detail. Also, you refer to a "configure script" patch but I cannot see any patches which modify configure on this bug. Can you please attach it here? Thanks.
also, you were never on the CC list (click View Bug Activity). However, as reporter of the bug you get all bugmail sent to you (unless you have deviated from the default bugzilla user preferences). See the Preferences pages. You are probably now getting 2 copies of these emails (1 as reporter, 1 as CC member)
I can't maintain kvm anymore.
app-emulation/kvm is replaced in favor of app-emulation/qemu-kvm and we never build the modules anymore. So there's nothing to do here.
