During the emake, notice this: cd . ; \ for i in gstreamer.args gstreamer.hierarchy gstreamer.interfaces gstreamer.prerequisites gstreamer-scan.o gstreamer.signals ; do \ test -f $i || touch $i ; \ done \ fi mkdir .libs gcc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -Wall -DGST_DISABLE_DEPRECATED -I../../libs -I../.. -I../.. -c gstreamer-scan.c -fPIC -DPIC -o .libs/gstreamer-scan.o gcc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -Wall -DGST_DISABLE_DEPRECATED -I../../libs -I../.. -I../.. -c gstreamer-scan.c -o gstreamer-scan.o >/dev/null 2>&1 gcc -o .libs/gstreamer-scan .libs/gstreamer-scan.o ../../gst/.libs/libgstreamer-0.8.so /usr/lib/libxml2.so -lz -lm /usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so -lpthread /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libglib-2.0.so /usr/lib/libpopt.so creating gstreamer-scan ACCESS DENIED mkdir: /var/lib/cache/gstreamer-0.8 ACCESS DENIED mkdir: /var/lib/cache/gstreamer-0.8 if test "x../.." != "x../.."; \ then \ export BUILT_OPTIONS="--source-dir=../../gst"; \ fi; \ gtkdoc-scan \ \ --module=gstreamer \ --source-dir=../../gst \ $BUILT_OPTIONS \ --ignore-headers="gettext.h gst-i18n-lib.h gst-i18n-app.h gst_private.h gstatomic_impl.h gstdata_private.h gstarch.h cothreads.h cothreads_compat.h gthread-cothreads.h types.h grammar.tab.h gstmarshal.h gstaggregator.h gstbufferstore.h gstfakesink.h gstfakesrc.h gstfdsink.h gstfdsrc.h gstfilesink.h gstfilesrc.h gstidentity.h gstmd5sink.h gstmultifilesrc.h gstpipefilter.h gstshaper.h gststatistics.h gsttee.h gsttypefindelement.h gstspider.h gstspideridentity.h gstsearchfuncs.h gstxmlregistry.h" touch scan-build.stamp *** Rebuilding template files *** if test x"." != x. ; then \ cp ./gstreamer-sections.txt . ; \ touch gstreamer-decl.txt ; \ fi gtkdoc-mktmpl --module=gstreamer | tee tmpl-build.log adding an 'addpredict /var/lib/cache/gstreamer-0.8' should fix it (testing now to be sure).
yep... the addpredict takes care of it. I think this is only noticable if you don't already have that dir...
ive seen this before, but i'm not sure what triggers it. I don't like add* solutions, because they're kind of ugly hacks. I guess this isn't a clean install is it ?
Hi, I had the same problem and mine was a clean installation on a new system. I've found the REAL problem and resolved it in this way: If you look in EVERY Makefile you'll see this line: GST_CACHE_DIR = /var/lib/cache/gstreamer-0.8 where var/lib would be ${localstatedir} but the configure script expanded it. So I removed the expansion with this proposed patch. I don't know if this is the right thing to do. But I haven't found anything better. I'll also attach the new ebuild.
Created attachment 35511 [details] gstreamer-0.8.3-dont-expand-GST_CACHE_DIR.patch
Created attachment 35512 [details] gstreamer-0.8.3-r2.ebuild
Happens for me as well. This seems to be a dupe of bug #56094 - however, I'd rather make #56094 a dupe of this bug here, as we've got a patch attached here.
*** Bug 56094 has been marked as a duplicate of this bug. ***
added the 'addpredict' solution. The problem is that to create the docs on a new gst-0.8 install, it uses a tool gstreamer-scan that uses some functionality that creates(/uses?) a gst plugins cache. This cache normally isn't created until after the installation, so thats why we sandbox. The cache gets created anyway in the ebuild, so it shouldn't be harmful to do the addpredict. Still it is not a solution i like, it would probably better to check (a) if the cache generation is reall needed & (b) if it is needed if we can't do in the builddir somewhere. Both solutions require some more research I don't have the time to deal with right now. @ simon : I haven't tested your patch, but I can't really see why that would change anything. Are you sure it didn't just work because you had a working gst-0.8 installation available when you added your patch ?
I'm sure that it works, my was a first install on a new system and I think I've explained the problem quite well. I'll reexplain it: Like you know gstreamer buld system uses /var/lib/cache/gstreamer-0.8 to store some cache data. This directory is defined (in all Makefiles) by GST_CACHE_DIR that should be GST_CACHE_DIR="\$localstatedir"/var/lib/cache/gstreamer-0.8. Like you know, to avoid the filesystem overwrite the ebuild.sh script during the install phase change all the dirs from / to /var/tmp/portage (for example localstatedir is changed from /usr to /val/tmp/portage/usr). this doesn't happen in the configuration phase because it have to give the right dirs to the configure script. The problem is that the configure script force the expansion of GST_CACHE_DIR so it will become GST_CACHE_DIR=/var/lib/cache/gstreamer-0.8 and this cause the sandbox violation when the program that creates the docs write in it. My patch will remove this forced expansion in the configure script, avoing this sandbox violation, setting the GST_CACHE_DIR to the right path. I think it's a better solution that will solve the REAL problem, but if you prefer the addpreditc hack go with it.
I know what it tries todo, but i'm not convinced it works like you think it does and also you are redefining a var that gets used in source files.
Sorry but with the addpredict I'm having the same sandbox violation.
*** Bug 57610 has been marked as a duplicate of this bug. ***
not fixed
the problem i think is that i was a bit too tight with the addpredict. I have made it a bit looser on the dirs it covers. Please rsync & try again.
For me, it works now. *However*, since gstreamer was a depenency while emerging kde, kdemultimedia was emerged right after gstreamer and that procedure printed this message: ************************************************** * * You do not seem to have GStreamer and the * KDE GStreamer bindings installed. Without these * aRts output will be used exclusively. * * You can get these bindings from kdenonbeta/gst * or from the JuK homepage. * * JuK supports GStreamer output but will also * work with aRts. * ************************************************** Perhaps this can be disregarded, I don't know. But for some reason, it looks like it doesn't recognize that gstreamer is there.
the problem here got fixed afaik (no reply = good news ?) @ comment 15 : file a bug with the kde team, i don't know much about juk
