Created attachment 342838 [details] build.log When trying to build app-emulation/libvirt-1.0.3-r2, I get: * Found kernel source directory: * /usr/src/linux * Could not find a Makefile in the kernel source directory. * Please ensure that /usr/src/linux points to a complete set of Linux sources * Unable to calculate Linux Kernel version for build, attempting to use running version /var/cache/portage/gentoo/eclass/linux-info.eclass: line 384: value = (3 << 16) + (5 << 8) + : syntax error: operand expected (error token is "+ ")
The issue is in the kernel_is() function. libvirt's usage hasn't changed here in a really long time and our usage is exactly as documented by the eclass.
Issue persists and also affects dev-libs/glib-2.32.4-r1: linux-info.eclass: line 384: value = (2 << 16) + (4 << 8) + : syntax error: operand expected (error token is "+ ") >>> Emerging (2 of 2) dev-libs/glib-2.32.4-r1 * glib-2.32.4.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * glib-2.32.4-AS_IF-patches.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * pkg-config-0.26.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux-2.6.32-hardened-r116 * Could not find a Makefile in the kernel source directory. * Please ensure that /usr/src/linux points to a complete set of Linux sources * Unable to calculate Linux Kernel version for build, attempting to use running version * Unable to calculate Linux Kernel version for build, attempting to use running version /var/cache/portage/gentoo/eclass/linux-info.eclass: line 384: value = (2 << 16) + (4 << 8) + : syntax error: operand expected (error token is "+ ") * The ebuild phase 'setup' has exited unexpectedly. This type of behavior [...]
Can someone please fix this? >>> Emerging (2 of 7) sys-fs/aufs-util-3.8_p20130422 * aufs-util-3.8_p20130422.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux-3.6.11-aufs * Could not find a Makefile in the kernel source directory. * Please ensure that /usr/src/linux points to a complete set of Linux sources * Unable to calculate Linux Kernel version for build, attempting to use running version * Unable to calculate Linux Kernel version for build, attempting to use running version /var/cache/portage/gentoo/eclass/linux-info.eclass: line 384: value = (2 << 16) + (4 << 8) + : syntax error: operand expected (error token is "+ ") * The ebuild phase 'setup' has exited unexpectedly. This type of behavior [...]
The latest error message came from this machine: # uname -r 3.8.8 # ll /usr/src/ total 8 lrwxrwxrwx 1 root root 17 Dec 24 02:32 linux -> linux-3.6.11-aufs drwxr-xr-x 23 root root 4096 Apr 12 11:42 linux-3.8.6-aufs drwxr-xr-x 23 root root 4096 Apr 23 15:39 linux-3.8.8-aufs-r1 >> The linux symlink is dead
Comment #0 comes from a machine where /usr/src/linux -> /dev/null (because the concept of an always outdated symlink is annoying). The machine in comment #2 looks like this: # uname -r 3.2.40-hardened # ll /usr/src/ total 8 lrwxrwxrwx 1 root root 26 Jul 20 2012 linux -> linux-2.6.32-hardened-r116 drwxr-xr-x 24 root root 4096 Apr 28 12:43 linux-3.2.43-hardened-r1 drwxr-xr-x 24 root root 4096 May 13 23:20 linux-3.2.44-hardened-r2 >> The linux symlink is dead, again # readlink -f /lib/modules/$(uname -r)/source/Makefile # readlink -f /lib/modules/$(uname -r)/build/Makefile /root/build-3.2.40-hardened/Makefile # readlink -f /lib/modules/$(uname -r)/build/source/Makefile So I assume that linux-info.eclass:get_version() has severe troubles when the linux symlink is not available and sources for the running version do no longer exist either, but the build directory does exist.
Is anyone looking at this at all? sys-apps/dbus-1.6.12 joins the club: Determining the location of the kernel source code Found kernel source directory: /dev/null Could not find a Makefile in the kernel source directory. Please ensure that /usr/src/linux points to a complete set of Linux sources Unable to calculate Linux Kernel version for build, attempting to use running version Unable to calculate Linux Kernel version for build, attempting to use running version /var/cache/portage/gentoo/eclass/linux-info.eclass: line 384: value = (2 << 16) + (4 << 8) + : syntax error: operand expected (error token is "+ ")
(In reply to Dennis Schridde from comment #5) > Comment #0 comes from a machine where /usr/src/linux -> /dev/null (because > the concept of an always outdated symlink is annoying). > > The machine in comment #2 looks like this: > # uname -r > 3.2.40-hardened > # ll /usr/src/ > total 8 > lrwxrwxrwx 1 root root 26 Jul 20 2012 linux -> linux-2.6.32-hardened-r116 > drwxr-xr-x 24 root root 4096 Apr 28 12:43 linux-3.2.43-hardened-r1 > drwxr-xr-x 24 root root 4096 May 13 23:20 linux-3.2.44-hardened-r2 > >> The linux symlink is dead, again > You have no compiled sources for the kernel that the system is running?
(In reply to Mike Pagano from comment #7) > You have no compiled sources for the kernel that the system is running? I do, but they are not accessible via /usr/src/linux (which is a symlink to /dev/null, to prevent the outdated-symlink issue).
(In reply to Dennis Schridde from comment #8) > (In reply to Mike Pagano from comment #7) > > You have no compiled sources for the kernel that the system is running? > > I do, but they are not accessible via /usr/src/linux (which is a symlink to > /dev/null, to prevent the outdated-symlink issue). Seems like something someone willing to write patches for the issue might do. Why not put something like `ln -nfs /lib/modules/$(uname -r)/build /usr/src/linux` in boot scripts... /etc/local.d... if only preventing outdated symlink is your goal?
(In reply to Samuli Suominen from comment #9) > (In reply to Dennis Schridde from comment #8) > > (In reply to Mike Pagano from comment #7) > > > You have no compiled sources for the kernel that the system is running? > > > > I do, but they are not accessible via /usr/src/linux (which is a symlink to > > /dev/null, to prevent the outdated-symlink issue). > > Seems like something someone willing to write patches for the issue might do. > > Why not put something like `ln -nfs /lib/modules/$(uname -r)/build > /usr/src/linux` in boot scripts... /etc/local.d... if only preventing > outdated symlink is your goal? Should /usr/src/linux point to the source or the build directory? And how do I do that with systemd? In any case: It seems linux-info.eclass has some logic to use the running kernel version (and the appropriate build dir) in case /usr/src/linux, but it does not appear to work properly. I tried to dig into it once, but during the short time I had, I couldn't figure out how the program flow is supposed to be and where the empty string came from.
Affects net-libs/libnftnl-1.0.0-r2 as well.
The isue persists.
A workaround is setting KERNEL_DIR.
*** Bug 632032 has been marked as a duplicate of this bug. ***
If anyone works on this, please feel free to post patches to gentoo-dev for review.
(In reply to Mike Pagano from comment #15) > If anyone works on this, please feel free to post patches to gentoo-dev for > review. this patch mitigate the problem in my case diff -u /var/portage/repos/gentoo/eclass/linux-info.eclass linux-info.eclass --- /var/portage/repos/gentoo/eclass/linux-info.eclass 2017-02-28 20:50:50.000000000 +0100 +++ linux-info.eclass 2017-10-09 21:07:45.788876390 +0200 @@ -508,9 +508,18 @@ # the Makefile is simple enough to use the noexec extract function. # This has been true for every release thus far, and it's faster # than using make to evaluate the Makefile every time. + KV_MAJOR=$(getfilevar_noexec VERSION "${KERNEL_MAKEFILE}") KV_MINOR=$(getfilevar_noexec PATCHLEVEL "${KERNEL_MAKEFILE}") KV_PATCH=$(getfilevar_noexec SUBLEVEL "${KERNEL_MAKEFILE}") + + # this could happen, seen after a "make O=builddir modules_prepare" + if [ -n "${KV_MAJOR}" -a -n "${KV_MINOR}" -a -z "${KV_PATCH}" ] + then + qeerror "Could not detect complete kernel version, assuming ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}" + KV_PATCH=0 + fi + KV_EXTRA=$(getfilevar_noexec EXTRAVERSION "${KERNEL_MAKEFILE}") if [ -z "${KV_MAJOR}" -o -z "${KV_MINOR}" -o -z "${KV_PATCH}" ] The makefile that's responsible of the problem is: $ cat /usr/src/build/Makefile# Automatically generated by /usr/src/linux-4.13.1/scripts/mkmakefile: don't edit VERSION = 4 PATCHLEVEL = 13 lastword = $(word $(words $(1)),$(1)) makedir := $(dir $(call lastword,$(MAKEFILE_LIST))) ifeq ("$(origin V)", "command line") VERBOSE := $(V) endif ifneq ($(VERBOSE),1) Q := @ endif MAKEARGS := -C /usr/src/linux-4.13.1 MAKEARGS += O=$(if $(patsubst /%,,$(makedir)),$(CURDIR)/)$(patsubst %/,%,$(makedir)) MAKEFLAGS += --no-print-directory .PHONY: __sub-make $(MAKECMDGOALS) __sub-make: $(Q)$(MAKE) $(MAKEARGS) $(MAKECMDGOALS) $(filter-out __sub-make, $(MAKECMDGOALS)): __sub-make @:
(In reply to Francesco Riosa from comment #16) Indeed $KBUILD_OUTPUT/Makefile does not contain a SUBLEVEL variable. Further, it might happen that the source of the running kernel (and thus $KV_DIR/Makefile) has disappeared. In that case, $KBUILD_OUTPUT/Makefile seems like a viable alternative. I prepared a patch: https://github.com/gentoo/gentoo/pull/6564
Could a developer please have a look at this? I believe the change is of reasonable quality and solves the problem, and there were no objections so far.
Thanks for your work. If you are still interested in seeing this, please post it to gentoo-dev for discussion and then re-reopen this bug.
