When i start esync, it works perfectly with one little failure in it, mentioned above Reproducible: Always Steps to Reproduce: 1. # esync Actual Results: * Importing old portage tree * Doing '/usr/bin/emerge sync' now * Doing 'eupdatedb' now * indexing: 3852 ebuilds to go !!! ERROR: dev-util/devhelp-0.8.1 failed. !!! Function , Line 1291, Exitcode 1 !!! error sourcing ebuild aux_get(): (0) Error in dev-util/devhelp-0.8.1 ebuild. (1) Check for syntax error or corruption in the ebuild. (--debug) 0 ebuilds to go * esearch-index generated in 5 minute(s) and 56 second(s) * indexed 6953 ebuilds * size of esearch-index: 1094 kB * Importing new portage tree * Preparing databases * Searching for changes Portage 2.0.50-r7 (2004.0, gcc-3.4.0, glibc-2.3.3_pre20040420-r0, 2.6.7-rc1-love1) ================================================================= System uname: 2.6.7-rc1-love1 i686 AMD Athlon(tm) processor Gentoo Base System version 1.4.15 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-tbird -Os -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-tbird -Os -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache fixpackages prelink sandbox" GENTOO_MIRRORS="ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://gentoo.inode.at/source/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.tu-clausthal.de/pub/linux/gentoo/" MAKEOPTS="-j3" PKGDIR="/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X acpi alsa apache2 avi cdr chroot crypt cups dedicated dga dvd encode fbcon flac gif gnutls gpm gtk gtk2 icq imagemagick imlib ipv6 java jpeg libg++ maildir mmx mmxext motif mozilla moznocompose moznoirc mozp3p mozsvg mpeg mpeg4 mysql ncurses nls nptl oggvorbis opengl pdflib perl png python qt qtmt quicktime samba sdl snmp speex ssl svg svga tcltk tiff truetype unicode usb videos x86 xml xmms xvid"
seems like it might be a problem with $(use_with zlib)
Mips is seeing this on just about every mips machine during rsync (at least as has been reported to me and witnessed on my RaQ2). CC'ing dev-portage incase they've got an idea on this. Eroor doesn't seem to be turning up on my sparc64 or x86 machines, so it's gotta be something specific to mips machines for some reason.
`Kumba advised, and I confirmed, that the problem occurs when the zlib USE flag is not set.
Well Joshua im on x86 and it occurs, so it cant be mips specific.
and I'm on ppc64 and it's happening and anoying!
Architecture is irrelevant. The common trigger is USE="-zlib".
It's imploding, because $? == 1 on the way out (simple, but crappy fix is adding [ 1 == 1 ] to the end of the ebuild). use_with zlib when USE="-zlib" results in use_with returning 1. This isn't an arch specific bug, this is either a bug in ebuild.sh's use_enable/use_with, or a bug in devhelp. Basically, it's dependant on the reason for use_with/use_enable returning 1 when the flag is disabled.
how about we just reorder DOCS to be the last variable
Fixed in CVS.
A better fix that avoids scenarios like this is to change the source statement in ebuild.sh. Currently, it's source ${EBUILD} || die "error sourcing ebuild" As this bug demonstrated, even if the ebuild's syntax *is perfect, and hasn't called die to bail early* portage is willing to incorrectly state that it failed sourcing the ebuild. I view this as wrong; the die "error sourcing ebuild" should only be executed when either A) the ebuild explicitly bails in the global scope, B) the source function reports a bash syntax error (unbalanced quotes, etc). Assuming that the last return value during sourcing of the ebuild is an indication of if the ebuild was sourced right or not is wrong- die is used for explicitly bailing if an ebuild needs such functionality. So... use this instead. -source ${EBUILD} || die "error sourcing ebuild" +eval "`cat ${EBUILD}; echo '[ 0 == 0 ]'`" || die "error sourcing ebuild" This behaves exactly the same as the previous sourcing, it just makes it such that stray non-zero return values don't cause portage to falsely think the ebuild's syntax is broke, completely avoiding bugs such as this. Thoughts?
Meanwhile, I checked w/ foser if it was an issue- for this ebuild, until the portage fix is exposed to users (eg .51 is stable on all arches), devhelp will have [ 0 == 0 ] tagged onto the end of it with a comment pointing back here. This explicitly fixes the stray return-value breakage, and should be removed once .51 has been stabled.
AFAIK, this is fixed on the mips-end of things. Portage can close whenever.
Bug has been fixed and released in stable portages on or before 2.0.51-r2
