Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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

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.

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

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.