Last time we tried this, it crashed epiphany as soon as any pygtk-using extension was loaded.

Hmm, maybe epiphany's problem...

Pyjamas-desktop works nicely here - of course, I'm using svn trunk from upcoming 0.6 release. 0.5 in AUR is a bit old and it does not contain pyjamas-desktop.


Sincerely,
Gour

https://launchpad.net/ubuntu/gutsy/+source/xulrunner/+changelog

xulrunner (1.8.0.11-1) unstable; urgency=low

* New upstream release (taken from upstream CVS)
* Fixes mfsa-2007-11.
* debian/python-xpcom.postinst, debian/python-xpcom.prerm: Added missing
component registration/unregistration.
* debian/patches/25_gnome_helpers_with_params.dpatch: Make MIME registry
use system mime.types when it doesn't get extensions from the Gnome
registry. Closes: #414008.
* debian/rules: Add the debugging symbols from python-xpcom to the
libxul0d-dbg package.
* debian/control:
+ Make python-xpcom conflict with epiphany-browser until epiphany
fixes its problems with python thread state. Closes: #416031.
+ Add the fact that python-xpcom debugging symbols are in the
libxul0d-dbg package.


this indicates that epiphany is the problem, not python-xpcom.

also - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416068

what other linux distributions are doing therefore is to place
"conflict" between python-xpcom and epiphany.

what they are _not_ doing is cutting off other projects at the
knees just because someone unrelated can't fix their program.

also, you could just do this:

http://live.gnome.org/Epiphany/WebKit

which will avoid the problem, because epiphany will use webkit,
not xulrunner. problem goes away.

.... actually, after reading that page, it turns out that
webkit is now the default build for epiphany.

which would explain why they haven't fixed the problem, because
resources and time are focussed on webkit not xulrunner.

l.

I am willing to try enabling it again, as the report has been closed upstream as obsolete. This was in xulrunner 1.8, where we've had 1.9 and 1.9.1 now, and the affected epiphany was 2.16 or 2.18 then.
If pyxpcom crashes epiphany, it goes out, simple as that. I can't make xulrunner conflict with epiphany, because xulrunner is the only possible backend for epiphany at this moment. As for webkit: that's scheduled for 2.28, there's no webkit code in 2.26. From what I've seen of webkit, it still has a long way to go. Switching over to it now is not an option.

hiya jan,

well, what i would suggest trying to do is create a separate package - python-xpcom - which you _can_ do using the mozilla xulrunner build process - --enable-application=xpcom i _think_ might do it (instead of what you're using to build xulrunner which is --enable-application=xulrunner).

or, just... what the heck, build xulrunner a second time and only extract the xpcom.so and other files.

or - i don't know how flexible arch build process is: can you do two or more binary packages from the same source distro/package? that's the .deb way, and you can create -dev packages which contain headers and .la and .pc files only that way, from the same build process.

if you can do that, that would definitely be the way to go. but, failing that, a separate package would work.

also i don't know if you can do conflict-marking, but that would be a smaart move to indicate it (if indeed it's still broken).

btw yes - steer clear of webkit for the time being. the maintenance of the webkit project is beginning to show signs of strain, as they stick rigidly to procedures that have worked well in the past. as momentum behind webkit grows, the procedures are beginning to both constrict the project's progress and also stress out the developers and anyone trying to work with their procedures.

so - stay clear for now.

I would appreciate it if this feature were added.