I was using firefox 3.5_beta4 with USE=-xulrunner, and xulrunner 1.9.0 installed separately, because some things (one of them being gnash) aren't yet updated to build against xulrunner 1.9.1. That's not possible any more: either I lose the ability to build plugins (unless they were recently fixed) or I lose the ability to try out firefox 3.5. Please either allow xulrunner 1.9.0 and 1.9.1 to be installed side by side while making sure plugins use 1.9.0, or bring back USE=xulrunner support.
Plugins not building with 1.9.1 really should not be happening since mozilla tries to keep the plugin API constant between releases (mostly so that proprietary plugins keep working) I'll take a look at gnash, in the meanwhile you should take a look at swfdec-mozilla, and give me a list of what else stops working. I have the following plugins working with 1.9.1: www-plugins/moonlight-1.0.1 media-video/totem-2.26.1[nsplugin] media-sound/rhythmbox-0.12.1[nsplugin] www-plugins/adobe-flash-10.0.22.87 www-plugins/swfdec-mozilla-0.8.2
(In reply to comment #1) > Plugins not building with 1.9.1 really should not be happening since mozilla > tries to keep the plugin API constant between releases (mostly so that > proprietary plugins keep working) Are you sure they don't keep the plugin ABI constant? That's all that's required to keep existing installed plugins (whether proprietary or not) working. If they do keep the plugin API constant, that suggests other things are relying on xulrunner internals. Already had swfdec-mozilla installed next to gnash :) I enable one and disable the other when one doesn't work on a particular site. I will check what exactly is depending on xulrunner on my system, try to build all of those with 1.9.1, and give you a list of anything that fails. It will take a little while though, especially since xulrunner itself will take a long time to update.
(In reply to comment #2) > Are you sure they don't keep the plugin ABI constant? That's all that's > required to keep existing installed plugins (whether proprietary or not) > working. If they do keep the plugin API constant, that suggests other things > are relying on xulrunner internals. > Hey, isn't keeping ABI constant a superset of keeping API constant? :) > I will check what exactly is depending on xulrunner on my system, try to build > all of those with 1.9.1, and give you a list of anything that fails. It will > take a little while though, especially since xulrunner itself will take a long > time to update. > Excellent, if you find a lot of breakage, convert this bug into a tracker bug and open other bugs blocking this.
> Excellent, if you find a lot of breakage, convert this bug into a tracker bug > and open other bugs blocking this. > there is my bug about epiphany :-) : http://bugs.gentoo.org/show_bug.cgi?id=265700
Strange. Here, gnash compiles perfectly fine. (In reply to comment #4) > there is my bug about epiphany :-) : > > http://bugs.gentoo.org/show_bug.cgi?id=265700 > INVALID -- epiphany 2.26 works with xulrunner 1.9.1 :p
(In reply to comment #5) > Strange. Here, gnash compiles perfectly fine. > > (In reply to comment #4) > > there is my bug about epiphany :-) : > > > > http://bugs.gentoo.org/show_bug.cgi?id=265700 > > > > INVALID -- epiphany 2.26 works with xulrunner 1.9.1 :p > Yes Nirbheek, but epiphany-2.26 isn't yet in portage tree :-)
(In reply to comment #3) > Hey, isn't keeping ABI constant a superset of keeping API constant? :) No, it really isn't. It's possible to change the API without changing the ABI, and it's possible to change the ABI without changing the API. You were partially joking, I know, but I'm not sure which part was the joke, so responding anyway. (In reply to comment #5) > Strange. Here, gnash compiles perfectly fine. That's great. Hopefully it was a problem that has since been fixed and gnash will compile and install equally fine for me.
(In reply to comment #6) > > INVALID -- epiphany 2.26 works with xulrunner 1.9.1 :p > > > Yes Nirbheek, but epiphany-2.26 isn't yet in portage tree :-) > Neither is xulrunner 1.9.1, anyway, 2.26 is slowly entering portage, so that bug is not an issue right now, except to change the deps of epiphany-2.24
The first result: dev-java/icedtea6 (java overlay) fails with IcedTeaPlugin.cc:3768: error: no matching function for call to 'nsIProcess::Run(int, const char**&, int&, int)' /usr/include/xulrunner-1.9.1/unstable/nsIProcess.h:66: note: candidates are: virtual nsresult nsIProcess::Run(PRBool, const char**, PRUint32)
dev-java/swt and gnome-extra/yelp built fine, then came media-video/vlc: support/npunix.c:55:19: error: npupp.h: No such file or directory
www-client/mozilla-firefox failed, but you already fixed that. www-client/kazehakase installs, but fails with "libxul.so: cannot open shared object file: No such file or directory" at runtime (which is nothing new), and fails by not doing anything useful when including /usr/$(get_libdir)/xulrunner-1.9.1 in LD_LIBRARY_PATH (which is new) www-plugins/mplayerplug-in fails because its pkg_setup built_with_use check is broken. I cannot test anything else because glibc fucking broke my entire system (/var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/temp/environment: line 1275: eblit-glibc-src_install: command not found) and portage happily continued to get rid of everything of my existing glibc install.
(In reply to comment #10) > dev-java/swt and gnome-extra/yelp built fine, then came media-video/vlc: > > support/npunix.c:55:19: error: npupp.h: No such file or directory > That file's been replaced by npfunctions.h see if just symlinking to npupp.h works -- if it does, then the patch will be trivial for 1.9.1. Else we'll have to go patch-hunting :p
My system's almost back to normal, and sane enough to retry mplayerplug-in with the buggy pkg_setup check bypassed. It fails with [...] checking pkg-config is at least version 0.9.0... yes checking for MOZPLUG... no configure: WARNING: mozilla-plugin not found checking for MOZPLUG... no configure: WARNING: firefox-plugin not found checking for MOZPLUG... no configure: WARNING: seamonkey-plugin not found checking for MOZPLUG... no configure: WARNING: xulrunner-plugin not found checking for MOZPLUG... yes checking for xpidl... no configure: error: xpidl compiler not found [...] which seems to be because it's looking in $MOZILLA_HOME, rather than $MOZILLA_HOME/bin.
(In reply to comment #12) > (In reply to comment #10) > > dev-java/swt and gnome-extra/yelp built fine, then came media-video/vlc: > > > > support/npunix.c:55:19: error: npupp.h: No such file or directory > > That file's been replaced by npfunctions.h see if just symlinking to npupp.h > works Actually, I see the code already does #ifdef HAVE_NPFUNCTIONS_H #include <npfunctions.h> #else #include <npupp.h> #endif but HAVE_NPFUNCTIONS_H isn't getting defined. In comment #1, you wrote that plugins should still build without a problem, but clearly, regardless of whether it's mozilla's fault or the plugins', they don't. So again, please bring back firefox[!xulrunner].
(In reply to comment #14) > Actually, I see the code already does > > #ifdef HAVE_NPFUNCTIONS_H > #include <npfunctions.h> > #else > #include <npupp.h> > #endif > > but HAVE_NPFUNCTIONS_H isn't getting defined. > Well then, I suppose a bug report is in order. > In comment #1, you wrote that plugins should still build without a problem, but > clearly, regardless of whether it's mozilla's fault or the plugins', they > don't. So again, please bring back firefox[!xulrunner]. > Not going to happen. * This is the overlay, things are expected to break * Is there any reason to keep xulrunner optional in firefox besides this? No. * This reason is not sufficient; these problems need to be fixed regardless of whether firefox uses the system xulrunner. Changing summary to reflect the true goal of this bug...
(In reply to comment #13) > My system's almost back to normal, and sane enough to retry mplayerplug-in with > the buggy pkg_setup check bypassed. It fails with > > [...] > checking pkg-config is at least version 0.9.0... yes > checking for MOZPLUG... no > configure: WARNING: mozilla-plugin not found > checking for MOZPLUG... no > configure: WARNING: firefox-plugin not found > checking for MOZPLUG... no > configure: WARNING: seamonkey-plugin not found > checking for MOZPLUG... no > configure: WARNING: xulrunner-plugin not found > checking for MOZPLUG... yes > checking for xpidl... no > configure: error: xpidl compiler not found > [...] > > which seems to be because it's looking in $MOZILLA_HOME, rather than > $MOZILLA_HOME/bin. > mplayerplug-in is really depreciated and should me p.masked for removal. Everyone should start moving to gecko-mediaplayer.
(In reply to comment #10) > dev-java/swt and gnome-extra/yelp built fine, then came media-video/vlc: > > support/npunix.c:55:19: error: npupp.h: No such file or directory > This is fixed in vlc-1.0.0_rc4 which is in the tree, I would imagine it would come out of p.mask long before xulrunner makes its final release of 1.9.1.
(In reply to comment #15) > * This is the overlay, things are expected to break For the record, it's no longer the overlay.
Created attachment 196223 [details] List of packages depending on xulrunner (In reply to comment #18) > For the record, it's no longer the overlay. > And it's masked. I've attached a list of packages that depend on xulrunner, and their status. The "Unknown" status packages need to have their status updated. PS: kazehakaze should work now, I've added an env.d entry for LDPATH for xulrunner
(In reply to comment #18) > (In reply to comment #15) > > * This is the overlay, things are expected to break > > For the record, it's no longer the overlay. > It is still ~arch that is p.masked, still expected to be problems with packages that link against it.
Created attachment 196311 [details] updated list Original is obsolete, The new list includes all those working and ebuilds that have broken check on useflags, and ebuilds that need to be patched for new xulrunner. List is far from complete but closer then it was :)
FYI dev-util/monodevelop-2.0 dev-dotnet/gluezilla-2.4.2 dev-dotnet/gecko-sharp-0.13 dev-util/devhelp-0.23-r1 All of those build and install without errors here. I tried to run Monodevelop and Devhelp : everything is fine.
Created attachment 196316 [details] New list (In reply to comment #22) > FYI [snip] > dev-util/devhelp-0.23-r1 devhelp-0.23 uses webkit-gtk, not xulrunner, 0.21 was the last version using xulrunner. The rest of the packages have been added (alongwith more) to the list PS: gnu-classpath has been removed from the list because it pulls in xulrunner:1.8 not 1.9
=gnome-extra/evolution-data-server-2.26.2 and some other packages seem to have problems with the doc use flag enabled and nspr-4.8 installed. See http://bugs.gentoo.org/show_bug.cgi?id=275249 and http://bugs.gentoo.org/show_bug.cgi?id=275260 for example.
Created attachment 197445 [details] Newest list Here's the final list. Some things have been removed because they pulled in 1.8. Once the stuff in this list is fixed, we can unmask firefox and nspr-4.8
I fixed devhelp (gnome herd) and mplayerplug-in (mozilla herd). Bugs should be opened for the others and made to block this one
Is it my understanding that openoffice will fail to reemerge if I unmask whats needed to emerge firefox 3.5? Will revdep-rebuild force a rebuild of openoffice?
(In reply to comment #27) > Is it my understanding that openoffice will fail to reemerge if I unmask whats > needed to emerge firefox 3.5? Will revdep-rebuild force a rebuild of > openoffice? > Just rebuild it w/o the nsplugin USE-flag, it's unlikely that you would want to use it.
Created attachment 197480 [details] Newerest list Here's another list. Turns out swt isn't quite fixed
(In reply to comment #27) > Is it my understanding that openoffice will fail to reemerge if I unmask whats > needed to emerge firefox 3.5? Will revdep-rebuild force a rebuild of > openoffice? > Yes it will force a rebuild.
(In reply to comment #29) > Created an attachment (id=197480) [edit] > Newerest list > > Here's another list. Turns out swt isn't quite fixed > Nirbheek is no point in keeping a package masked over four packages, there are known work arounds until maintainers catch up with development. I still say xulrunner-1.9.1, nspr-4.8. and firefox-3.5 all need to be unmasked so bugs can be found reported and fixed before the 3.5.1 release of firefox and xulrunner-1.9.2 are released.
Changing focus to generic release bug tracker...
Just a question: Someone know why these patches have been dropped: patch -p0 < /root/x/patch/000_flex-configure-LANG.patch patch -p1 < /root/x/patch/055_firefox-2.0_gfbsd-pthreads.patch patch -p1 < /root/x/patch/063_firefox-rpath-3.patch patch -p0 < /root/x/patch/068_firefox-nss-gentoo-fix.patch patch -p0 < /root/x/patch/100-system-hunspell-corrections.patch patch -p0 < /root/x/patch/800-bsd_include.patch They still apply cleanly. Maybe check if the bugs they fixed are not reintroduced by dropping them. At least the rpath thing was needed in e.g. _rc3 to keep prelink happy. (otherwise it would complaining that stuff in /usr/lib(64)/xulrunner-1.9.1 could not be prelinked because it couldn't find the dependencies or so.
the OOO 3.1.0 is broken after I got FF3.5 with corresponding xulrunner. can't emerge it as well, can't revdep rebuild it as well. Here is what it says : In file included from ../inc/plugin/unx/plugcon.hxx:105, from ../inc/plugin/unx/sysplug.hxx:35, from ../inc/plugin/impl.hxx:85, from /var/tmp/portage/app-office/openoffice-3.1.0/work/ooo/build/ooo310-m11/extensions/source/plugin/base/service.cxx:38: /usr/include/xulrunner-1.9.1/stable/npapi.h:155: error: redefinition of 'struct _NPP' /var/tmp/portage/app-office/openoffice-3.1.0/work/ooo/build/ooo310-m11/solver/310/unxlngx6.pro/inc/npsdk/npapi.h:210: error: previous definition of 'struct _NPP'
the OOO 3.1.0 is broken after I got FF3.5 with corresponding xulrunner. can't emerge it as well, can't revdep rebuild it as well. Here is what it says : In file included from ../inc/plugin/unx/plugcon.hxx:105, from ../inc/plugin/unx/sysplug.hxx:35, from ../inc/plugin/impl.hxx:85, from /var/tmp/portage/app-office/openoffice-3.1.0/work/ooo/build/ooo310-m11/extensions/source/plugin/base/service.cxx:38: /usr/include/xulrunner-1.9.1/stable/npapi.h:155: error: redefinition of 'struct _NPP' /var/tmp/portage/app-office/openoffice-3.1.0/work/ooo/build/ooo310-m11/solver/310/unxlngx6.pro/inc/npsdk/npapi.h:210: error: previous definition of 'struct _NPP' is there anyone doing something on this ?
(In reply to comment #35) > the OOO 3.1.0 is broken after I got FF3.5 with corresponding xulrunner. > > can't emerge it as well, can't revdep rebuild it as well. Here is what it says > : > > In file included from ../inc/plugin/unx/plugcon.hxx:105, > from ../inc/plugin/unx/sysplug.hxx:35, > from ../inc/plugin/impl.hxx:85, > from > /var/tmp/portage/app-office/openoffice-3.1.0/work/ooo/build/ooo310-m11/extensions/source/plugin/base/service.cxx:38: > /usr/include/xulrunner-1.9.1/stable/npapi.h:155: error: redefinition of 'struct > _NPP' > /var/tmp/portage/app-office/openoffice-3.1.0/work/ooo/build/ooo310-m11/solver/310/unxlngx6.pro/inc/npsdk/npapi.h:210: > error: previous definition of 'struct _NPP' > > > is there anyone doing something on this ? > Please watch the double post. There is an openoffice bug for this already, if you just can not wait just -nsplugin openoffice and it will compile cleanly.
(In reply to comment #35) > the OOO 3.1.0 is broken after I got FF3.5 with corresponding xulrunner. > bug 256773 Please see the bugs this one depends on, and if you have an issue which is NOT in those, open a NEW bug blocking this one. Do not comment here.
*** Bug 275973 has been marked as a duplicate of this bug. ***
3.5.1 has been unmasked in CVS, will hit users in a few hours. Thanks everyone.
