56995 2004-07-14 01:31 0000 sandbox violation in planner-0.12 2004-07-14 05:38:33 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified x86 All RESOLVED FIXED P2 major --- 1 andrew@operationaldynamics.com gnome@gentoo.org python@gentoo.org andrew@operationaldynamics.com 2004-07-14 01:31:20 0000 Only occurs with (new, ~arch) planner-0.12 ebuild. Does not occur when merging planner-0.11. No differences between two ebuilds, :. conclude problem upstream. Problem in make phase (not make install), probably due to call to /usr/bin/pygtk-codegen-2.0, whatever that is. make[2]: Entering directory `/export/tmp/portage/planner-0.12/work/planner-0.12/python' if /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/include/python2.3 -I/usr/include/pygtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -DORBIT2=1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/libgsf-1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/orbit-2.0 -Wno-missing-declarations -Wno-missing-prototypes -march=pentium3 -O2 -pipe -fomit-frame-pointer -MT planner_la-plannermodule.lo -MD -MP -MF ".deps/planner_la-plannermodule.Tpo" \ -c -o planner_la-plannermodule.lo `test -f 'plannermodule.c' || echo './'`plannermodule.c; \ then mv -f ".deps/planner_la-plannermodule.Tpo" ".deps/planner_la-plannermodule.Plo"; \ else rm -f ".deps/planner_la-plannermodule.Tpo"; exit 1; \ fi mkdir .libs gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/include/python2.3 -I/usr/include/pygtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -DORBIT2=1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/libgsf-1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/orbit-2.0 -Wno-missing-declarations -Wno-missing-prototypes -march=pentium3 -O2 -pipe -fomit-frame-pointer -MT planner_la-plannermodule.lo -MD -MP -MF .deps/planner_la-plannermodule.Tpo -c plannermodule.c -fPIC -DPIC -o .libs/planner_la-plannermodule.o (cd .\ && /usr/bin/pygtk-codegen-2.0 \ --override planner.override \ --load-types planner-arg-types.py \ --prefix planner planner.defs) > gen-planner.c \ && cp gen-planner.c planner.c \ && rm -f gen-planner.c ACCESS DENIED unlink: /usr/share/pygtk/2.0/codegen/defsparser.pyc ACCESS DENIED open_wr: /usr/share/pygtk/2.0/codegen/defsparser.pyc ACCESS DENIED unlink: /usr/share/pygtk/2.0/codegen/scmexpr.pyc ACCESS DENIED open_wr: /usr/share/pygtk/2.0/codegen/scmexpr.pyc ACCESS DENIED unlink: /usr/share/pygtk/2.0/codegen/definitions.pyc ACCESS DENIED open_wr: /usr/share/pygtk/2.0/codegen/definitions.pyc ACCESS DENIED unlink: /usr/share/pygtk/2.0/codegen/argtypes.pyc ACCESS DENIED open_wr: /usr/share/pygtk/2.0/codegen/argtypes.pyc ACCESS DENIED unlink: /usr/share/pygtk/2.0/codegen/override.pyc ACCESS DENIED open_wr: /usr/share/pygtk/2.0/codegen/override.pyc gets a bit further then ebuild aborts with access violations. This is the Makefile block in question, and although obviously $* is getting "planner" as a substitution, I couldn't pin down why (@#%^&! autotools, grrr) .defs.c: (cd $(srcdir)\ && $(PYGTK_CODEGEN) \ --override $*.override \ --load-types planner-arg-types.py \ --prefix $* $*.defs) > gen-$*.c \ && cp gen-$*.c $*.c \ && rm -f gen-$*.c Maybe --prefix $* needs to be set to something else? Hard to say. This one doesn't quite earn a Critical or Blocker IMHO - after all, supposedly these changes would be made to the file system at the install step. Still, it shouldn't be doing what it's doing. AfC spider@gentoo.org 2004-07-14 02:33:16 0000 hmmm , what version of pygtk do you have installed? I didn't catch the new python bindings with a USE flag (doing that now) but they were built and didn't generate a sandbox violation here, so I'm curious as to what could be the difference. andrew@operationaldynamics.com 2004-07-14 05:21:52 0000 My pygtk was at 2.0.0 I just upgraded to current stable, 2.0.0-r1, and then tried planner again. Result was a successful merge. Might want to make the dependency: pytk >= 2.0.0-r1. Actually, while you're at it, you might remove pygtk-2.0.0.ebuild :) AfC foser@gentoo.org 2004-07-14 05:38:33 0000 the difference is that 2.0.0-r1 of pygtk (and up) pre-generates the pyc/pyo files and then they don't get created on the fly when some other package uses the codegen stuff causing the sandbox violations. So i fixed the pygtk dep to be at least 2.0.0-r1 Anyway.. the python team should probably remove the older versions (1.99 & 2.0.0) at least & also i noticed there's a new release of pygtk-0.6 you might also want to have a look at that.