Alright. This is freaking weird, but I finally managed to duplicate langthang's problem's he was experiencing... steps: 1) emerge -C python-fchksum 2) FEATURES="gpg sandbox" emerge python-fchksum . --receives this-- >>> emerge (1 of 1) dev-python/python-fchksum-1.7.1 to / >>> md5 src_uri ;-) python-fchksum-1.7.1.tar.gz >>> Unpacking source... >>> Unpacking python-fchksum-1.7.1.tar.gz to /var/tmp/portage/python-fchksum-1.7.1/work >>> Source unpacked. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-dev-python_-_python-fchksum-1.7.1-21348.log" open_wr: /var/lib/portage/prelink-checksum.tmp.portage_lockfile open_wr: /var/lib/portage/prelink-checksum.tmp.portage_lockfile -------------------------------------------------------------------------------- Note the portage_md5.perform_checksum (specifically when using md5 module) filename; I have no clue how the hell that is pissing off the sandbox, althoug enabling SANDBOX_DEBUG (set it in /etc/make.conf to 1 fex), shows the sandbox intercepting a heck of a lot more then I'd expect. Either way, something is very, very screwy, and I can't nail figure out how it's doing that.
Alright. that stupid /etc/init.d/function.sh portageq hack has to go (I've complained before, now I have ammo)- the portageq call runs w/ the sandbox armed (no, disabling the sandbox around that import isn't a viable solution), and the sandbox is catching an inline locking statement when portage is inherited- This is the output from inserting a traceback.print_stack() call in lockfile Python 2.3.3 (#1, Feb 3 2004, 13:16:11) [GCC 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r2, propolice)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import portage File "<stdin>", line 1, in ? File "/usr/lib/portage/pym/portage.py", line 6887, in ? portdb=portdbapi(settings["PORTDIR"]) File "/usr/lib/portage/pym/portage.py", line 5029, in __init__ self.manifestVerifier = portage_gpg.FileChecker(self.mysettings["PORTAGE_GPG_DIR"], "gentoo.gpg", minimumTrust=self.manifestVerifyLevel) File "/usr/lib/portage/pym/portage_gpg.py", line 66, in __init__ self.keyringStats = fileStats(keyringPath) File "/usr/lib/portage/pym/portage_gpg.py", line 28, in fileStats mya.append(portage_md5.perform_checksum(filepath)) File "/usr/lib/portage/pym/portage_md5.py", line 49, in perform_checksum mylock = portage_locks.lockfile(prelink_tmpfile, wantnewlockfile=1) File "/usr/lib/portage/pym/portage_locks.py", line 62, in lockfile traceback.print_stack()
what about this as a fix: [ -z "${RC_NOCOLOR}" ] && RC_NOCOLOR="$(source /etc/make.conf 2> /dev/null ; echo $RC_NOCOLOR)"
Yay... this just got expanded so it's *much* worse. Current cvs automatically attempts locking in /var/lib/portage/ *alway* when FEATURES="gpg" is on, so any portageq call when the sandbox is active (gtk-engines2 fex) will piss the sandbox off.
I'm pretty sure I fixed this by re-handling locks.
Bug has been fixed and released in stable portages on or before 2.0.51-r2
