sandbox fuckery ahoy I know bugs for multiple versions is frowned upon but this looks like the exact same bug. Reproducible: Always Steps to Reproduce: 1. emerge -avuDNt @system @installed 2. gets to python 2 or 3 3. sandbox error Actual Results: Calculating dependencies ... done! [ebuild U ] dev-lang/python-2.7.3-r1 [2.7.2-r3] USE="gdbm ipv6 ncurses readline sqlite ssl threads (wide-unicode) xml -berkdb -build -doc -examples -tk -wininst" 0 kB x86_64-pc-linux-gnu-gcc -pthread -c -fno-strict-aliasing -march=native -O2 -pipe -mcx16 -msahf -fprefetch-loop-arrays -ftree-vectorize -fno-reorder-blocks -fno-reorder-functions -fwrapv -DNDEBUG -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Python/compile.o Python/compile.c x86_64-pc-linux-gnu-gcc -pthread -c -fno-strict-aliasing -march=native -O2 -pipe -mcx16 -msahf -fprefetch-loop-arrays -ftree-vectorize -fno-reorder-blocks -fno-reorder-functions -fwrapv -DNDEBUG -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Python/graminit.o Python/graminit.c x86_64-pc-linux-gnu-gcc -pthread -c -fno-strict-aliasing -march=native -O2 -pipe -mcx16 -msahf -fprefetch-loop-arrays -ftree-vectorize -fno-reorder-blocks -fno-reorder-functions -fwrapv -DNDEBUG -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Python/symtable.o Python/symtable.c x86_64-pc-linux-gnu-gcc -pthread -c -fno-strict-aliasing -march=native -O2 -pipe -mcx16 -msahf -fprefetch-loop-arrays -ftree-vectorize -fno-reorder-blocks -fno-reorder-functions -fwrapv -DNDEBUG -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE \ -DSVNVERSION="\"`LC_ALL=C svnversion .`\"" \ -DHGVERSION="\"`LC_ALL=C hg id -i .`\"" \ -DHGTAG="\"`LC_ALL=C hg id -t .`\"" \ -DHGBRANCH="\"`LC_ALL=C hg id -b .`\"" \ -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c ACCESS DENIED open_wr: /.svn/wc.db <-------------------------- abort: repository . not found! abort: repository . not found! abort: repository . not found! rm -f libpython2.7.a >>> Source compiled. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-26547.log" VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /.svn/wc.db A: /.svn/wc.db R: /.svn/wc.db C: svnversion . -------------------------------------------------------------------------------- x86_64-pc-linux-gnu-gcc -pthread -DNDEBUG -Wl,-O1 -Wl,--enable-new-dtags -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--sort-common -L. Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl -lutil -o Parser/pgen Parser/pgen ./Grammar/Grammar ./Include/graminit.h ./Python/graminit.c touch Parser/pgen.stamp x86_64-pc-linux-gnu-gcc -pthread -c -DNDEBUG -march=native -O2 -pipe -mcx16 -msahf -fprefetch-loop-arrays -ftree-vectorize -fno-reorder-blocks -fno-reorder-functions -fwrapv -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Python/ast.o Python/ast.c x86_64-pc-linux-gnu-gcc -pthread -c -DNDEBUG -march=native -O2 -pipe -mcx16 -msahf -fprefetch-loop-arrays -ftree-vectorize -fno-reorder-blocks -fno-reorder-functions -fwrapv -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Python/compile.o Python/compile.c x86_64-pc-linux-gnu-gcc -pthread -c -DNDEBUG -march=native -O2 -pipe -mcx16 -msahf -fprefetch-loop-arrays -ftree-vectorize -fno-reorder-blocks -fno-reorder-functions -fwrapv -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Python/graminit.o Python/graminit.c x86_64-pc-linux-gnu-gcc -pthread -c -DNDEBUG -march=native -O2 -pipe -mcx16 -msahf -fprefetch-loop-arrays -ftree-vectorize -fno-reorder-blocks -fno-reorder-functions -fwrapv -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Python/symtable.o Python/symtable.c x86_64-pc-linux-gnu-gcc -pthread -c -DNDEBUG -march=native -O2 -pipe -mcx16 -msahf -fprefetch-loop-arrays -ftree-vectorize -fno-reorder-blocks -fno-reorder-functions -fwrapv -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE \ -DSVNVERSION="\"`LC_ALL=C svnversion .`\"" \ -DHGVERSION="\"`LC_ALL=C `\"" \ -DHGTAG="\"`LC_ALL=C `\"" \ -DHGBRANCH="\"`LC_ALL=C `\"" \ -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c ACCESS DENIED open_wr: /.svn/wc.db rm -f libpython3.2.a Expected Results: Upgrade works I would love to know why they would think this would work, I can't find anything anywhere that would be a svn repo (or a mercurial repo). Well unless this it supposed to be for svn/hg builds of python. ~ # cd /var/tmp/portage/dev-lang/python-2.7.3-r1/work/Python-2.7.3/ Python-2.7.3 # svnversion . Unversioned directory
This is pretty easy to reproduce: floppym@naomi ~ % pwd /home/floppym floppym@naomi ~ % sudo mkdir /.svn floppym@naomi ~ % sudo touch /.svn/wc.db floppym@naomi ~ % sandbox svnversion . ACCESS DENIED open_wr: /.svn/wc.db ACCESS DENIED unlink: /.svn/wc.db-wal The real question is whether we actually want to work around somebody having a subversion repo in the root directory (/). Seems pretty weird to me. :)
I suppose we could addpredict /.svn.
I don't think we should, since as your example shows any ebuild calling svnversion without being in a svn repository will fail, I doubt python is the only one, and I doubt they'll all be spotted and fixed. I don't think it's worth getting the high-profile/popular ebuilds to work around this if it'll still be something the user needs to fix on their system to get portage to work reliably. If I could think of a non-python-specific fix/workaround that made any sense I'd be for that, but a default addpredict for this is pretty terribly ugly :(
Closing as WONTFIX then.
Weedy: You may be able to work around this on your own by adding a hook like this to /etc/portage/bashrc: pre_src_compile() { addpredict /.svn }
(In reply to comment #1) > The real question is whether we actually want to work around somebody having > a subversion repo in the root directory (/). Seems pretty weird to me. :) I have my root in VC (/etc, kernel config, some crap in /var, and parts of my /home dir). I have been considering switching to git for a while but I think python checks for git, hg, and svn. Guess I can switch to bzr... (In reply to comment #5) > Weedy: You may be able to work around this on your own by adding a hook like > this to /etc/portage/bashrc: > > pre_src_compile() { > addpredict /.svn > } Ok then.
