here's a teeny little patch that fixes some problems with the nvidia-kernel ebuild when /usr/src/linux does *not* point to /usr/src/<some_kernel_version>, such as a kernel directory in somebody's home directory. Only people with this setup should notice a difference. Index: nvidia-kernel-1.0.2880.ebuild =================================================================== RCS file: /home/cvsroot/gentoo-x86/media-video/nvidia-kernel/nvidia-kernel-1.0.2880.ebuild,v retrieving revision 1.2 diff -u -r1.2 nvidia-kernel-1.0.2880.ebuild --- nvidia-kernel-1.0.2880.ebuild 2002/04/25 06:56:22 1.2 +++ nvidia-kernel-1.0.2880.ebuild 2002/04/28 19:53:24 @@ -22,6 +22,7 @@ nv_get_kernel_version () { # Determine the version of the kernel sources local NV_KV="`readlink /usr/src/linux`" + NV_KV="`basename $NV_KV`" if [ $? -ne 0 ] then die "/usr/src/linux does not exist"
I'll take this bug.
I actually got rid of the nv_get_kernel_version function altogether (in the version 1.3 of the ebuild), because portage sets $KV variable automatically. Could you test whether portage makes the same kind of mistake? If it does, please open a new bug about this. Thanks.
Nope. Doesn't work. >>> Completed installing into /var/tmp/portage/nvidia-kernel-1.0.2880/image/ etc/ etc/modules.d/ etc/modules.d/nvidia lib/ lib/modules/ lib/modules/home/ lib/modules/home/jnelson/ lib/modules/home/jnelson/kernel/ lib/modules/home/jnelson/kernel/2.4.17-r5/ lib/modules/home/jnelson/kernel/2.4.17-r5/kernel/ ...
Additionally, why wasn't the ebuild -r value increased?
So this becomes a bug in portage now, for it (portage) doesn't set the KV environment variable properly. Please open a new bug report for this, as it is no longer specific to nvidia ebuild. To answer your second question, I chose not to increment the ebuild's revision becase this is an entirely internal fix, i.e. it contains no user-visible changes. There will be no difference on your system after you install this new version of the ebuild, compared to the previous version. Thanks.
I disagree. It's not portage's *job* to tell me what kernel I'm compiling a module for. What was wrong with the patch I sent you? It worked for all the test cases I threw at it, although it *could* use more error checking, like "no /usr/src/linux exists" and so on.
Jon, it *is* portage's job to tell you that. That task is quite generic and is called for by several more ebuilds (e.g. see alsa-driver and em8300-modules). That was why drobbins added the functionality to Portage in the first place (see bug 599). The function nv_get_kernel_version was written (by me) because KV environment variable was not available at the time. Now KV variable is the ``official'' way of detecting the current kernel version in an ebuild, so the function has to go. Otherwise, there is nothing wrong with the patch that you sent. But understand, that the bug that you discovered also affects at least two more ebuilds. That is why I'm saying, again, that it should be reported as a separate portage bug. This way you can fix it in *one* place, and thus all the packages that compile kernel modules will be fixed. Thanks.
I checked the source (Luke), and yep - ebuild.sh does set KV. So I wrote some new code to handle that (for portage). This bug is closed, and thanks for setting me right!
So, is this bug fixed in the latest portage? If so, in which version? Looks like bug 2374 may be about the same issue. Thanks.
