After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 529668 - access violation on Gentoo
access violation on Gentoo
Status: RESOLVED FIXED
Product: GEGL
Classification: Other
Component: general
0.0.16
Other All
: Normal normal
: ---
Assigned To: Default Gegl Component Owner
Default Gegl Component Owner
Depends on:
Blocks:
 
 
Reported: 2008-04-24 07:37 UTC by Helmut Jarausch
Modified: 2009-06-23 00:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Helmut Jarausch 2008-04-24 07:37:47 UTC
Please describe the problem:
When a package is installed on a Gentoo system, it all happens in a 
'sandbox'. Access to a directories/files outside of this sandbox
results in an 'access violation' error.


During build, executing
tools/.libs/lt-introspect
it tries to 
mkdir /root/.gegl-0.0
which fails.

Can this be avoided?

(I couldn't try gegl-0.0.20 since this isn't on ftp.gimp.org

Many thanks for your help.


Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 quazgar 2008-06-14 21:07:13 UTC
The downstream bug report, including a workaround (setting the GEGL_SWAP variable):
https://bugs.gentoo.org/show_bug.cgi?id=183425
Comment 2 Kevin Cozens 2009-01-01 01:24:23 UTC
Could someone using Gentoo test the latest 0.0.22 release of GEGL and report back as to whether the sandbox violation still exists?
Comment 3 quazgar 2009-01-04 17:28:48 UTC
Seems to work fine without the prior workaround for me, this bug probably can be closed as fixed.

You might also want to have a look at the following configure patch:
gegl-20-configure-ac.patch from http://bugs.gentoo.org/show_bug.cgi?id=240776
It adds some new dependency configure flags (instead of automagically using detected libraries).
Comment 4 Tobias Mueller 2009-06-23 00:33:52 UTC
Closing as per comment #3.