This bug is being reported because this ebuild is currently trying to build against the kernel tree by accessing it through /lib/modules/`uname -r` instead than through /usr/src/linux like it should. This is bad in many situations, like: - livecd installs: the running kernel is the one from the livecd and is most likely not the same the user is installing to; - livecd chroot fixes: as above; - generic chroot: running kernel comes from outside, as above; - kernel updates: users most likely would want their system to have all the modules ready _before_ restarting. Please fix your ebuild to use /usr/src/linux. Thanks, Diego
Created attachment 174647 [details] Build log
All this logic seems to be handled by the linux-mod and linux-info eclasses. The ebuild doesn't actually do anything besides calling eclass functions. Thanks
Created attachment 221167 [details, diff] workaround This is a patch against the ebuild to show what is wrong. Unless you have the param KDIR set the ${S}/module/Makefile then does by default the faulty behaviour that this bugreport is about. This patch is wrong in so many ways, only a proof of concept. But I do not think KDIR is one of the "standard" variables, and thus it falls on the ebuild to set it.
>=sysprof-1.1 does not install a kernel module, so sysprof is no longer connected with this bug. Diego, is this bug report is still relevant with the current state of the linux-info.eclass?
(In reply to comment #4) > Diego, is this bug report is still relevant with the current state of the > linux-info.eclass? typo, meant linux-mod.eclass
*** Bug 241960 has been marked as a duplicate of this bug. ***
*** Bug 250300 has been marked as a duplicate of this bug. ***
any news for this bug ?
I don't see any call to uname in linux-mod.eclass . If I'm missing anything here, please re-open.