Arches, please stabilize =net-libs/xulrunner-1.8.0.4. Some apps are going to have xulrunner support, so we have to stabilize this :) Thanks! x86 stable
Stable on ppc
Please, do not stabilize xulrunner as it is now, at least bump it to 1.8.0.10: -- Mike Hommey <glandium@debian.org> Tue, 22 Aug 2006 23:15:16 +0200 xulrunner (1.8.0.5-1) unstable; urgency=high * The "upstream doesn't, so I do" release: Checked out the XULRUNNER_1_8_0_5_RELEASE tagged code from upstream CVS. * Fixes the following security vulnerabilities: CVE-2006-3113, CVE-2006-3677, CVE-2006-3801, CVE-2006-3802, CVE-2006-3803, CVE-2006-3805, CVE-2006-3806, CVE-2006-3807, CVE-2006-3808, CVE-2006-3809, CVE-2006-3810, CVE-2006-3811, CVE-2006-3812. -- Mike Hommey <glandium@debian.org> Fri, 6 Oct 2006 19:13:56 +0200 xulrunner (1.8.0.7-1) unstable; urgency=low * New upstream release (taken from the MOZILLA_1_8_0_7_RELEASE tag in upstream CVS) * Fixes the following security vulnerabilities: CVE-2006-4340, CVE-2006-4253, CVE-2006-4565, CVE-2006-4566, CVE-2006-4568, CVE-2006-4569, CVE-2006-4571. xulrunner (1.8.0.9-1) unstable; urgency=low * New upstream release (taken from upstream CVS) * Fixes mfsa-2006-{68-73} also known as CVE-2006-6497, CVE-2006-6498, CVE-2006-6499, CVE-2006-6500, CVE-2006-6501, CVE-2006-6502, CVE-2006-6503, CVE-2006-6504. -- Mike Hommey <glandium@debian.org> Thu, 8 Mar 2007 19:08:10 +0100 xulrunner (1.8.0.10-1) unstable; urgency=low [ Mike Hommey ] * New upstream release (taken from upstream CVS) * Fixes mfsa-2007-{01-07}, also known as CVE-2006-6077, CVE-2007-0008, CVE-2007-0009, CVE-2007-0045, CVE-2007-0775, CVE-2007-0776, CVE-2007-0777, CVE-2007-0778, CVE-2007-0779, CVE-2007-0780, CVE-2007-0800, CVE-2007-0981, CVE-2007-0995.
amd64 done.
If xulrunner-1.8.0.4 is to become stable then maybe bug #155349 should be reopened? It is currently resolved WONTFIX due to the reason "it will never become stable anyway..." In any case, Im with Gerkan, why on earth stabilize on a quite outdated version that has loads of security holes that has since long been patched.
Okay arches, added a non-vulnerable version of xulrunner. I just added the ebuild to the tree, but since it fixes security issues, please stabilize it. Thanks. x86 stable
Maybe updating xulrunner would fix this NOTGNOME bug: http://bugzilla.gnome.org/show_bug.cgi?id=356632 An Epiphany version of the same bug can be found here: http://bugzilla.gnome.org/show_bug.cgi?id=429564
(In reply to comment #6) Obviously :) 1.8.0.11 is already in the tree. Just waiting for arches to stabilize it.
(In reply to comment #7) > Obviously :) Does xulrunner 1.8.0.11 fix bug 173408, too?
(In reply to comment #8) > (In reply to comment #7) > > Obviously :) > > Does xulrunner 1.8.0.11 fix bug 173408, too? > It should, as it's fixed since 1.8.0.8.
sigh, unccing arches until i can test it more.
probably it is better to jump to 1.8.1.3, as firefox-1.5* is going to be removed from the tree? ebuild http://g-overlays.googlecode.com/svn/trunk/mozilla/net-libs/xulrunner/xulrunner-1.8.1.3.ebuild patches http://g-overlays.googlecode.com/files/xulrunner-1.8.1.3-patches-0.1.tar.bz2
(In reply to comment #11) > probably it is better to jump to 1.8.1.3, as firefox-1.5* is going to be > removed from the tree? > ebuild > http://g-overlays.googlecode.com/svn/trunk/mozilla/net-libs/xulrunner/xulrunner-1.8.1.3.ebuild > patches > http://g-overlays.googlecode.com/files/xulrunner-1.8.1.3-patches-0.1.tar.bz2 > Indeed, in fact we shouldn't have 1.8.0.x in the tree. Wonder why i didn't noticed before. I'll see what i can do. Thanks for the info. Marking the bug as LATER.
Is this in a security perspective an accepted solution as the currently stable (and latest unmasked) version in portage has open vulnerables and is depended on by ~arch packages (swt, liferea-1.2.x)? I know masking 1.8.0.4 or unmasking 1.8.0.11 leaves us with a sort-of broken tree, but should not vulnerable packages be masked if there is no newer working package?
Bumped to 1.8.1.3, thanks Gergan.
Hello again arches. @amd64,ppc: Please test and stabilize this. 1.8.0.4 is vulnerable, and 1.8.0.11 has been removed since it was broken, also 1.8.0.x(that is, firefox-1.5.0.x) is unsupported, only 1.8.1.x(ff 2.0.0.x) is supported. @hppa,ppc64,sparc: Please test and re-keyword. Thank you and sorry for the bugspam. It should work perfectly right now.
When will it be avaible at a mirror? Not even listad @ http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-libs/xulrunner/
Ignore last comment and sorry for the spam, did just appere.
Please let me ask, what is that KEYWORDS="-*" supposed to achieve?
amd64 done. Since the upgrade requrires a revdep-rebuild, could an elog be added?
Raúl could you disable the pyxcom extensions for now, although on x86 I didn't have such problems as the reporter in http://bugs.gentoo.org/show_bug.cgi?id=174944. It broke epiphany's with python extension turned on as in this debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416068. As far as I know nothing uses it for now, so probably it is safer to disable it for now. I'll test now if and how they break compilation on amd64, but the other problem is much more serious to be resolved easily
(In reply to comment #20) Nod, done, thanks again :) I didn't had any issue on x86 or ia64.
(In reply to comment #14) > Bumped to 1.8.1.3, thanks Gergan. > Working fine for me. I know devs already knew it, but sometimes it feels good to receive good news :)
Created attachment 116575 [details, diff] 610_xpcom_sample.patch this patch should resolve bug http://bugs.gentoo.org/show_bug.cgi?id=155349 (xulrunner does not build with the debug use flag). As to the python extension - I was also unable to reproduce the problem from the bug 174944 on amd64 (I think that the problem is because of him using python-2.5). On the other hand I was unable to reproduce this time the debian epiphany problem on my new amd64 install, but there are still other problems. The extension is not usable directly, as it is missing rpath - so import xpcom.components will fail with unresolved libxul library (probably the same problem, which was reported for java). One possible way to solve these problems is adding back xulrunner to the ldpath (via env.d entry), there should be no problems with library collisions with the other (seamonkey, firefox if they are not added to the ldpath) as they does link to unversioned libraries and RPATH ($ORIGIN) has priority to the standard ldpath (we could not use rpath in this cases as it will probably link to the older xulrunner installs - as we could only use absolute path, and I don't know if java has rpath corresponding flag).
As I already asked somewhere, would it be possible to add sql USE flag to have sql extension compiled in xulrunner ? It would be great.
xulrunner-1.8.1.3 fails to build on ppc with java USE flag. Adding "mozconfig_annotate '' --disable-javaxpcom" to the ebuild or -java to USE flags (almost the same) allows xulrunner-1.8.1.3 to build. xulrunner-1.8.0.4 has no such problem.
Are you running gcj? Could you post some information and the actual error?
(In reply to comment #26) > Are you running gcj? Could you post some information and the actual error? > I am running gcj and until today I thought I had tried to build with ibm-jdk, but the error tells me that's not so. I apparently have no idea of how to change a jvm for a build environment. I though I just used java-config -S jvm-name and then env-update && source /etc/profile. That does not appear to have worked as the error tells me that I am still using gcj. 'java-config -L' lists ibm-jdk as my jvm for both root and normal user, but the build environment still uses gcj. When I can actually use the ibm jvm for the ebuild that might clarify the issue here. I will do an ebuild ... clean and see if that gives a different answer afterwards.
what's up with this, ppc?
(In reply to comment #28) > what's up with this, ppc? > As of xulrunner-1.8.1.4, builds with gcj and java.
ppc done, closing.
