First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 57002
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Gentoo Linux Gnome Desktop Team <gnome@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Jeremy Huddleston <eradicator@gentoo.org>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
gstreamer-0.8.3-dont-expand-GST_CACHE_DIR.patch gstreamer-0.8.3-dont-expand-GST_CACHE_DIR.patch text/plain Simone Gotti (RETIRED) 2004-07-15 15:57 0000 1.58 KB Details
gstreamer-0.8.3-r2.ebuild gstreamer-0.8.3-r2.ebuild text/plain Simone Gotti (RETIRED) 2004-07-15 15:58 0000 2.34 KB Details
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 57002 depends on: Show dependency tree
Show dependency graph
Bug 57002 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)







View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2004-07-14 03:12 0000
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).

------- Comment #1 From Jeremy Huddleston 2004-07-14 03:43:25 0000 -------
yep... the addpredict takes care of it.

I think this is only noticable if you don't already have that dir...

------- Comment #2 From foser (RETIRED) 2004-07-14 05:43:32 0000 -------
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 ?

------- Comment #3 From Simone Gotti (RETIRED) 2004-07-15 15:57:01 0000 -------
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.

------- Comment #4 From Simone Gotti (RETIRED) 2004-07-15 15:57:41 0000 -------
Created an attachment (id=35511) [edit]
gstreamer-0.8.3-dont-expand-GST_CACHE_DIR.patch

------- Comment #5 From Simone Gotti (RETIRED) 2004-07-15 15:58:36 0000 -------
Created an attachment (id=35512) [edit]
gstreamer-0.8.3-r2.ebuild

------- Comment #6 From Alexander Skwar 2004-07-17 15:00:32 0000 -------
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.

------- Comment #7 From Jeremy Huddleston 2004-07-18 22:07:35 0000 -------
*** Bug 56094 has been marked as a duplicate of this bug. ***

------- Comment #8 From foser (RETIRED) 2004-07-19 08:31:25 0000 -------
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 ?

------- Comment #9 From Simone Gotti (RETIRED) 2004-07-19 09:16:19 0000 -------
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.

------- Comment #10 From foser (RETIRED) 2004-07-19 09:46:57 0000 -------
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.

------- Comment #11 From Simone Gotti (RETIRED) 2004-07-26 11:08:30 0000 -------
Sorry but with the addpredict I'm having the same sandbox violation. 

------- Comment #12 From foser (RETIRED) 2004-08-03 13:18:49 0000 -------
*** Bug 57610 has been marked as a duplicate of this bug. ***

------- Comment #13 From foser (RETIRED) 2004-08-03 13:33:06 0000 -------
not fixed

------- Comment #14 From foser (RETIRED) 2004-08-03 13:49:43 0000 -------
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.

------- Comment #15 From Fredrik Persson 2004-08-03 15:51:03 0000 -------
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.

------- Comment #16 From foser (RETIRED) 2004-08-11 04:11:03 0000 -------
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

First Last Prev Next    No search results available      Search page      Enter new bug