cisco-vpnclient-3des bombs because I use a xen kernel with a release tak (2.6.12.6-xen_20051215b). The ebuild looks for /lib/modules/${KV}/build, but KV=2.6.12.6 while my kernel install modules in /lib/modules/2.6.12.6-xen_20051215b/build. Adding the following to the ebuild in my portdir_overlay fixes the problem. if [ ! -d /lib/modules/${KV}/build -a -d /lib/modules/`uname -r`/build ]; then KV=`uname -r` fi I'm not sure if this is an inappropriate use of KV by cisco-vpnclient-3des or if KV should equal `uname -r`. Please file as appropriate.
Ehh, KV should always be the version of the kernel linked to by /usr/src/linux and not `uname -r`, at all. In your case, it is valid because that is your booted kernel. Basically, you should be able to compile a new kernel, then the vpn client, without having to reboot to you new kernel first. Anyway, since your solution is only run if the KV dir cannot be found, it'll work for now. I'm guessing that thre's something appending the Xen string improperly, as it isn't showing up in the Makefile for KV to pick up.
(In reply to comment #1) > I'm guessing that thre's something appending the Xen string improperly, as it > isn't showing up in the Makefile for KV to pick up. My kernel came from the xen-sources package, so possibly this bug should be assigned there. I appended the _DATE at the end, but -xen came from the package.
I just updated all of the ebuilds in CVS for another bug (bug #119057). Can you see if this resolves the issue for you, also. I think it might work around the issue.
I never got a response, so I'm going to assume that this fixed it. If it didn't feel free to REOPEN the bug and we'll look at it some more.