Summary: | www-client/epiphany-2.24.3-r10 sandbox violation | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Simone <simleo> |
Component: | New packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dabbott, dan.fego, gentoo-bugzilla, jobbara.artalmatlan, mozilla, njdoyle+bugs, rose, Sander.Sweers |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
This patched ebuild makes epiphany-2.26.2 work with xulrunner-1.9.1 epiphany-2.26.2-sandbox.diff |
Description
Simone
2009-03-24 10:17:14 UTC
Created attachment 186088 [details]
build.log
which firefox do you have installed ? (bin/non-bin/xulrunner/...) (In reply to comment #2) > which firefox do you have installed ? (bin/non-bin/xulrunner/...) > www-client/mozilla-firefox-bin-3.0.7 USE="restrict-javascript" LINGUAS=<all disabled> I switched to non-bin firefox (3.0.8) but that didn't fix the problem. I had multiple xulrunner installations (1.8, 1.9, bin). After unmerging all of them as well as Firefox, epiphany finally merged. I don't know if this counts as a fix. (In reply to comment #2) > which firefox do you have installed ? (bin/non-bin/xulrunner/...) > I have also the same bug. xulrunner-1.9.1_beta4-r1, xulrunner-bin-1.8.1.19, mozilla-firefox-3.5_beta4-r1 & mozilla-firefox-bin-3.0.10 This also happens with epiphany-2.26.2 as well. Adding mozilla@gentoo.org as I believe bug #265700 is a duplicate. Created attachment 192454 [details]
This patched ebuild makes epiphany-2.26.2 work with xulrunner-1.9.1
This should only be used if you have xulrunner-1.9.1 merged prior to emerging epiphany.
*** Bug 271250 has been marked as a duplicate of this bug. *** This bug needs to be fixed rather than worked around by adding add_predicts Here's a shot in the dark, but does it error out with FEATURES=usersandbox ? (In reply to comment #11) > Here's a shot in the dark, but does it error out with FEATURES=usersandbox ? It does for me. *** Bug 275258 has been marked as a duplicate of this bug. *** This cause of this problem is identical to bug 247040. Remove xpti.dat and compreg.dat from firefox/xulrunner components directory, and the problem will go away. Newer xulrunner won't install it on it's own unless it's already there. Created attachment 196033 [details]
epiphany-2.26.2-sandbox.diff
We can either patch it out here, or I can patch it out of the gecko.m4. Gnome herd let me know which way you all want to go, either way this will be a fix for all versions of epiphany. If you decide to use this we can use a simple sed to remove it.
As I said this can be easily done via sed : --- /usr/portage/www-client/epiphany/epiphany-2.26.2.ebuild 2009-05-18 16:40:47.000000000 -0500 +++ ../gentoo/www-client/epiphany/epiphany-2.26.2.ebuild 2009-06-29 00:10:25.815645342 -0500 @@ -68,6 +68,10 @@ # Fix libcanberra automagic support, bug #266232 epatch "${FILESDIR}/${PN}-2.26.1-automagic-libcanberra.patch" + # Fix sandbox violations + sed -i -e "s/GECKO_XPCOM_PROGRAM_CHECK//g" "${S}"/configure.ac + + # Make it libtool-1 compatible rm -v m4/lt* m4/libtool.m4 || die "removing libtool macros failed" @@ -76,14 +80,6 @@ } src_configure() { - addpredict /usr/$(get_libdir)/xulrunner-1.9/components/xpti.dat - addpredict /usr/$(get_libdir)/xulrunner-1.9/components/xpti.dat.tmp - addpredict /usr/$(get_libdir)/xulrunner-1.9/components/compreg.dat.tmp - - # Why are these write-opened per bug #228589 and bug #253043 - addpredict /usr/$(get_libdir)/mozilla/components/xpti.dat - addpredict /usr/$(get_libdir)/mozilla/components/xpti.dat.tmp - addpredict /usr/$(get_libdir)/mozilla/components/compreg.dat.tmp gnome2_src_configure } This will allow for all them addpredicts to be removed once and for all. Is it something that epiphany upstream maybe shouldn't call? Sed'ing it out always and having to eautoreconf or patch configure too will get bothersome real quick, at least once we are able to get rid of other patches that make us eautoreconf right now. gecko.m4 modification doesn't help for that, as upstream tarballs will have their gecko.m4 stuff in aclocal.m4, and to get ours used we need to eautoreconf too. (In reply to comment #17) > Is it something that epiphany upstream maybe shouldn't call? > > Sed'ing it out always and having to eautoreconf or patch configure too will get > bothersome real quick, at least once we are able to get rid of other patches > that make us eautoreconf right now. > gecko.m4 modification doesn't help for that, as upstream tarballs will have > their gecko.m4 stuff in aclocal.m4, and to get ours used we need to eautoreconf > too. > This is really irrelevant. Upstream has already said the next major release will depend on webkit only, xulrunner is going on away. (In reply to comment #16) > As I said this can be easily done via sed : > > --- /usr/portage/www-client/epiphany/epiphany-2.26.2.ebuild 2009-05-18 > 16:40:47.000000000 -0500 > +++ ../gentoo/www-client/epiphany/epiphany-2.26.2.ebuild 2009-06-29 > 00:10:25.815645342 -0500 > @@ -68,6 +68,10 @@ > # Fix libcanberra automagic support, bug #266232 > epatch "${FILESDIR}/${PN}-2.26.1-automagic-libcanberra.patch" > > + # Fix sandbox violations > + sed -i -e "s/GECKO_XPCOM_PROGRAM_CHECK//g" "${S}"/configure.ac > + > + > # Make it libtool-1 compatible > rm -v m4/lt* m4/libtool.m4 || die "removing libtool macros failed" > > @@ -76,14 +80,6 @@ > } > > src_configure() { > - addpredict /usr/$(get_libdir)/xulrunner-1.9/components/xpti.dat > - addpredict /usr/$(get_libdir)/xulrunner-1.9/components/xpti.dat.tmp > - addpredict /usr/$(get_libdir)/xulrunner-1.9/components/compreg.dat.tmp > - > - # Why are these write-opened per bug #228589 and bug #253043 > - addpredict /usr/$(get_libdir)/mozilla/components/xpti.dat > - addpredict /usr/$(get_libdir)/mozilla/components/xpti.dat.tmp > - addpredict /usr/$(get_libdir)/mozilla/components/compreg.dat.tmp > > gnome2_src_configure > } > > This will allow for all them addpredicts to be removed once and for all. > It works for me. Thank you! This has been fixed for 2.26.*, I don't think it makes much sense to touch 2.24.3-r10 (stable). |