>>> Emerging (1 of 1) gnome-extra/hamster-applet-2.32.1 * hamster-applet-2.32.1.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * Package: gnome-extra/hamster-applet-2.32.1 * Repository: gentoo * Maintainer: gnome@gentoo.org * USE: amd64 elibc_glibc kernel_linux libnotify multilib userland_GNU * FEATURES: preserve-libs sandbox splitdebug >>> Unpacking source... >>> Unpacking hamster-applet-2.32.1.tar.bz2 to /var/tmp/portage/gnome-extra/hamster-applet-2.32.1/work >>> Source unpacked in /var/tmp/portage/gnome-extra/hamster-applet-2.32.1/work >>> Preparing source in /var/tmp/portage/gnome-extra/hamster-applet-2.32.1/work/hamster-applet-2.32.1 ... * Fixing OMF Makefiles ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/gnome-extra/hamster-applet-2.32.1/work/hamster-applet-2.32.1 ... * Configuration of gnome-extra/hamster-applet-2.32.1 with CPython 2.7... CCFLAGS="-O2 -g -pipe" LINKFLAGS="-Wl,-O1,--as-needed" "" --prefix=/usr --libdir=/usr/lib64 configure /var/tmp/portage/gnome-extra/hamster-applet-2.32.1/temp/environment: line 5998: : command not found * ERROR: gnome-extra/hamster-applet-2.32.1 failed: * configure failed * * Call stack: * ebuild.sh, line 56: Called src_configure * environment, line 5401: Called python_execute_function '-s' 'waf-utils_src_configure' * environment, line 3939: Called waf-utils_src_configure * environment, line 5998: Called die * The specific snippet of code: * CCFLAGS="${CFLAGS}" LINKFLAGS="${LDFLAGS}" "${WAF_BINARY}" --prefix=/usr --libdir=/usr/$(get_libdir) $@ configure || die "configure failed" * * If you need support, post the output of 'emerge --info =gnome-extra/hamster-applet-2.32.1', * the complete build log and the output of 'emerge -pqv =gnome-extra/hamster-applet-2.32.1'. * The complete build log is located at '/var/tmp/portage/gnome-extra/hamster-applet-2.32.1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/gnome-extra/hamster-applet-2.32.1/temp/environment'. * S: '/var/tmp/portage/gnome-extra/hamster-applet-2.32.1/work/hamster-applet-2.32.1'
Created attachment 260039 [details] environment
IIRC, there was a forum post about it - eclass was broken, but it's fixed now.
Well, arguably, you could say hamster-applet should use the call in pkg_setup. If you see it this way, reopen.
problem is that waf-utils eclass should not define this variable in pkg_setup, it should be an eclass-scope variable like we usually do for this kind of stuff.
CCing scarabeus for the previous comment
eclass API changes are bad bad bad.
(In reply to comment #4) > problem is that waf-utils eclass should not define this variable in pkg_setup, > it should be an eclass-scope variable like we usually do for this kind of > stuff. > Then you have problem that you have to define such variable PRIOR inherit, and given it spins of the S you need to define S prior inherit too. It is safer to expect ebuilds to use all provided package scopes.
To bit expand my point: normaly we do and would not work: EAPI=4 MY_P=eeeee inherit waf-utils ... S=${WORKDIR}/${MY_P} ... required if global scope: EAPI=4 MY_P=eeeee S=${WORKDIR}/${MY_P} inherit waf-utils ... I bet most people would never spot this issue, thus i set it in function scope.
Did I already say I hate waf ? Why is it that not all packages would use waf script and rename it to something silly ? Didn't (waf) upstream set a policy for this ? Or do upstream devs think it's funny to mess around with the build system's name.
I wonder if we could package waf as-is and make all waf packages use that script we will have on system. But i bet they are version dependant and thats the reason why it is shipped with each package huh?
waf upstream explicitly say in their doc that we should not do that. They could say their build system is broken by design, would be the same imho. But to the real question, is there a package using waf but named something else ? Could we not just symlink WAF_BINARY to waf in src_prepare ?
(In reply to comment #11) > But to the real question, is there a package using waf but named something else > ? See talloc ebuild :D
god help us... Anyway, could you (did you ?) send a mail to gentoo-dev saying waf-utils eclass should use pkg_setup always ?
(In reply to comment #13) > god help us... > > Anyway, could you (did you ?) send a mail to gentoo-dev saying waf-utils eclass > should use pkg_setup always ? > Nope I did not, i probably should done it src_configure and drop pkg_setup as whole, cause it would make more sense, and always work. What do you think?
fine by me. If possible the new feature should be documented (can't remember if it is right now).
Eclass updated in main tree based on consensus with Gilles. Closing as fixed.
