While PyXPCOM is mentioned here and there as a side issue on several bugs, I can't find any bug report focused on fixing and stablizing PyXPCOM support. If there is no active maintainer for it, let me know and I'll find one for you. Reproducible: Always
https://bugs.gentoo.org/show_bug.cgi?id=170101#c20 Something to say, Gergan?
Well I see the following problems, which we should solve beforehand: 1. if we enable it on firefox and xulrunner, where we will install them? - most probably they will collide in site-packages/xpcom and would be useless in any other location. So most probably the extension should be installed only from xulrunner or only from firefox (I vote for xulrunner as hopefully, we will be able to build firefox-3 on top of it) 2. without hackery the extension is useless in the moment - that's because of the way we build the mozillas' with rpath, also the extension's sharedobject will not be able to find its dependencies from firefox or xulrunner. One way is probably to set the rpath for it equal to $MOZILLA_FIVE_HOME - not the best solution, but most probably will work. 3. bug #174944 was probably because of the reporter using python-2.5, so it is probably still valid. 4. the debian bug - I was unable to reproduce it on amd64 and in the moment I don't have x86 to test it, but it could be simply because of some very strange coincidences - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416068. I will probably be able to make patch for issue 2 today or tomorrow, I could eventually test issue 3 (although I still don't have python-2.5). Well if we are able to resolve 2&3 and decide to have it only on xulrunner for example and no one experience the strange debian bug anymore - I think it will be safe to enable it. Of course, it will be great if someone could test it correctly (aside from simple import of the python-modules and such I don't know how to test if it works) or make patch for issue 3 for example, if he/she is able to reproduce it
Created attachment 120823 [details, diff] 620_python_extension_rpath.patch fix the linking issue I'm able to import xpcom.components and to run some of the pyxpcom tests (2 out of 8 fail) from a user's directory I think that I have seen somewhere, that it is possible to build pyxpcom as a separate package, if this could be done, that's also a viable alternative to in-tree building
forgot to say this patch is against xulrunner-1.8.1.3, I hope it will apply clean against 1.8.1.4
*** Bug 209842 has been marked as a duplicate of this bug. ***
Created attachment 147397 [details, diff] patch for ebuild to build pyxpcom. Patch that already was posted in bug 209842
Created attachment 148462 [details, diff] patch against net-lib/xulrunner-1.8.1.13 This bug is still "new"?!?
Gergan, is the patch still needed? I guess it is?
And Michael, i suppose it works for you? With the patch Gergan posted or without?
*** Bug 249555 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > *** Bug 249555 has been marked as a duplicate of this bug. *** > Basically bug 249555 asked for a USE flag "pyxpcom" to control compile time support of PyXPCOM when installing xulrunner. While I support fixing PyXPCOM in general, I'd rather have a consistent option to enable or disable the building myself. Is there some compelling reason against a local USE flag that no one is sharing? No offense, but this is a source code distribution, and USE flags are meant to enable or disable compile time features according to the individual's needs.
So, 1.9.1 has python support. Closing as fixed...
