I wondered why my mouse cursor changed suddenly and thought I was just getting hacked. But it seems to be a bug in portage: During "emerge sync", the import utility from ImageMagick is called: root 13313 0.8 3.0 13276 11652 pts/14 S 18:45 0:08 python2.2 /usr/bin/emerge sync root 14872 0.0 0.2 2008 912 pts/14 S 18:47 0:00 sh -c { /usr/sbin/ebuild.sh depend; } 2>&1 root 14873 0.0 0.3 2240 1212 pts/14 S 18:47 0:00 /bin/bash /usr/sbin/ebuild.sh depend root 14877 0.0 0.6 7744 2616 pts/14 S 18:47 0:00 import eutils flag-o-matic If I abort import, it pops up again, so it probably happens for many (or even all) ebuilds. Reproducible: Always Steps to Reproduce: 1. emerge sync 2. 3. Actual Results: My mouse cursor (in X11) changed to a double cross. "emerge sync" hung (progress indicator after ">>> Updating Portage cache... " did not change anymore). Expected Results: Update the cache and quit. :) Portage 2.0.47-r10 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4) ================================================================= System uname: 2.4.19-cube-8 i686 AMD Athlon(tm) processor GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo http://distro.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb:/usr/vice/etc:/usr/share/config:/usr/kde/3.1/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/afs/modload /etc/afs/C /etc/afs/afsws /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 libg++ gtkhtml gdbm berkdb libwww gtk cdr -3dfx 3dnow -aalib acl afs -alsa apm -arts avi -bonobo crypt -cups dga -directfb doc -dvd encode -esd -evo -fbcon -ggi gif -gnome -gnome-libs -gphoto2 -gpm guile -icc -icc-pgo imap imlib ipv6 -java jpeg kde kerberos lcms ldap -matrox maildir mbox mikmod mmx monitor -motif mozilla mpeg -mule mysql nas ncurses nls -odbc oggvorbis opengl oss pam -pcmcia -pda pdflib -perl png -pnp postgres python qt qtmt quicktime readline -ruby samba sasl sdl slang -slp -snmp socks5 spell ssl -static -svga -tcltk -tcpd tetex tiff truetype -voodoo3 X xml xml2 -xmms xv -zeo zlib" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -O3 -pipe" CXXFLAGS="-O2 -mcpu=i686 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://hybrid.sascha.silbe.org/gentoo-portage" FEATURES="sandbox ccache"
I just saw this today as well, and I didnt know wtf was going on cuz I didn't update anything since the last time I did a emerge rsync. The cursor changed for me 3 or 4 times before the rsync finished.
I temporarily replaced /usr/bin/import with a little Perl script to capture the arguments passed to import: $ cat import.output Hi. This is perl 5.008. @ARGV: [eutils flag-o-matic] I also noticed a sparse file called flag-o-matic in ~ after aborting the first 'emerge sync'. Could it be that a Python import statement is being evaluated by the shell?
heh, nick you might want to have a look at this...
The culprit seems to be /usr/portage/eclass/php.eclass Replace line 8: import eutils flag-o-matic With: inherit eutils flag-o-matic and it'll be fixed. It's a really small change... Should I submit a patch for it or will this do?
If "import eutils flag-o-matic" is being evaluated by the shell, how can changing "import" to "inherit" really fix the problem? This is only hiding the problem by evaluating a non-existent command that results in a "command not found" error instead of running a program named "import". Am I wrong?
Ah, but 'inherit' is not a non-existent command. See the eclasses in /usr/portage/eclass/. It looks like some custom shell function supposed to, well, import the requested eclasses. So 'inherit eutils flag-o-matic' would in fact load eutils.eclass and flag-o-matic.eclass, which are in the same directory as php.eclass. If I understood things right anyway.
You're assuming the wrong context. The statement in question is not being evaluated by Python as intended, but by the shell, which is why "import eutils flag-o-matic" results in /usr/bin/import being invoked with arguments 'eutils' and 'flag-o-matic'. In the shell context, substituting "inherit" for "import" simply changes the command evaluated by the shell from one that exists (/usr/bin/import) to one that (probably) does not exist on the PATH.
This was fixed. It was a typo in the PHP eclass where someone used import instead of inherit. The person in question fixed it in CVS.
I apologize. It was my typo. I was testing the eclass on a server box without X, and the error didn't show up at all for me. I do have one question based on this. Why did the eclass get sourced when 'emerge sync' was run?
> You're assuming the wrong context. The statement in question > is not being evaluated by Python as intended, but by the shell The shell -is- the intended evaluation context. 'Inherit' is a custom shell function, as already explained. If you wish to learn the basics of shell programming, you'll find a tutorial there: http://steve-parker.org/sh/sh.shtml If you want to learn how Python (and its import statement) works, the official tutorial is a good starting point: http://www.python.org/doc/current/tut/tut.html Hope this helps! > Why did the eclass get sourced when 'emerge sync' was run? I don't know. qpkg -f doesn't list the eclass as belonging to any package. I used to believe that 'emerge sync' only fiddled with stuff in /usr/portage -- apparently not. Are the eclasses stored in the server-side rsync repository, then?
Thanks, I understand the basics of shell programming well enough, I just became confused about the target interpreter when I saw 'import'. Too much work, caffeine, nicotine, bad food; not enough sleep, etc. I hope no one took offense, none was intended.
The eclasses are in /usr/portage/eclass. I don't know why Portage sources them after a sync, though.
