Hi everyone[1], Here is a status update for xulrunner 1.9, and what remains to be done to be ready for what we would like to be in Lenny.
In the past few weeks, I've uploaded several beta releases of xulrunner to experimental, with the latest one, 1.9~b5-4 (in NEW) being more-or-less in its final shape (shape being different than codebase). I also have a working package for iceweasel built on top of xulrunner, which is waiting for xulrunner 1.9~b5-4 to come out of NEW to be uploaded (it requires changes to the xulrunner-stub that were done in this release). I already went through most libmozjs-dev build-depending packages[2] and sent messages to their maintainers to test packages available on my people.d.o space [3]. These packages are current unstable versions rebuilt against experimental libmozjs-dev, except for libjavascript-perl where some changes were required[4]. gxine remains to be done, and should hopefully only require changes in an .m4 file, and will be handled as libjavascript-perl. This means unstable version of all these packages should be simply binNMUable when it comes for xulrunner 1.9 to go into unstable. That was for the easy part. Now for the painful part. I'm sorry this comes quite late but time constraints on my part, xulrunner packaging stabilization requirements, and iceape required changes were such that this mail couldn't happen much earlier. There have been major changes to the way xulrunner is packaged, the main one being that we now must rely on upstream ways to do things, which can be painful for reverse dependencies package maintainers, I'm sorry for this. Also, version 1.9's xpcom being incompatible with version 1.8's, I had to add some more development stuff to iceape, so that at least the totem plugin can work in both iceape from unstable and iceweasel from experimental. This also actually will make the transition less painful, as about half libxul-dev build dependent packages should build with iceape-dev instead, now. Anyways, the main change for package maintainers with xulrunner 1.9 being uploaded to unstable (not before a few weeks, though) is that libxul-dev disappears. "Why?" will you ask. The reason is that the main part of the APIs being different, packages build depending on libxul-dev will already have to be modified. This generally doesn't apply to plugins, but these are the easier to change. Roughly, we have 3 types of things that use libxul-dev currently: - plugins - xpcom components (this includes plugins using xpcom; I think there is only totem) - embedding applications (such as browsers). Here is how things should be changed to fit the target: General rule: do *not* use rpaths. For plugins: - Build depend on iceape-dev (>= 1.1.9-5) - Compile/Linkage flags should be taken from iceape-plugin.pc. It currently adds a dependency on nspr, which -Wl,--as-needed should drop most of the time. Most plugins don't use the LDFLAGS from there anyways, only CFLAGS. Still, please avoid linking against nspr when not needed. This is not related to the transition, but to avoid loading nspr under konqueror and webkit (when the latter will have plugins support, soon) - The plugin package must depend on iceweasel | iceape | add other browsers supporting plugins here. - The plugin package must *not* depend on xulrunner-1.9. - Do *not* use rpaths. For xpcom components, and plugins using xpcom (at least totem) - Build depend on iceape-dev (>= 1.1.9-5) - Compile/Linkage flags should be taken from iceape-xpcom.pc, and if a plugin, iceape-plugin.pc. - Add -lxpcomglue_s to the flags from iceape-xpcom.pc. This guarantees things to work in both 1.8 and 1.9 based products. (building against xulrunner 1.9 would only make them work on 1.9 based products). Note that the totem plugin currently built against libxul-dev does *not* work with iceweasel 1.9 for this reason (xpcomglue_s is not shipped in libxul-dev) Vanilla upstreams should already be doing the right thing (totem does). - Dependency rules are as above. - Do *not* use rpaths. - Exception to these rules are components for use in embedding applications, where we don't care about backwards compatibility. Then build depend on xulrunner-dev, and take the flags from libxul.pc or libxul-unstable.pc (see below for the difference). This will add the proper -lxpcomglue_s already, so you don't have to care about it. I think only epiphany-extensions is concerned, and has already been dealt with. For applications embedding a gecko (i.e. gtkmozembed), such as kazehakase, yelp, etc.: - Build depend on xulrunner-dev (>= 1.9~b5-4) - Compile/Linkage flags should be taken from either mozilla-gtkmozembed-embedding.pc, libxul-embedding-unstable.pc or libxul-embedding.pc. Note mozilla-gtkmozembed-embedding.pc and libxul-embedding-unstable.pc are equivalent. The difference between libxul-embedding-unstable.pc and libxul-embedding.pc is that the -unstable variant allows to use mozilla APIs that are not frozen. Prefer to use libxul-embedding.pc wherever possible. - The application will be linked against the (static) xpcom standalone glue. This glue is responsible for dlload()ing the appropriate libxul. Yes, this is silly, but diverging from upstream here would be even more painful. - Do *not* use rpaths. - The binary package must depend on xulrunner-1.9 (>= 1.9~b5-4). Just in case I haven't stressed it enough: do *not* use rpaths, they will break things in subtle ways, especially for plugins and components. Also, the proper solution to problems such as the current one with experimental epiphany-extensions is *not* to add an rpath, but to make sure components are not loaded before the standalone glue (the one loading libxul) is initialized. These were building rules, but your sources may require source changes. For plugins and components, it should only be a matter of changing a few pkg-config checks. See proposed patches for some packages on my people.d.o space [5]. For other applications, you should first check the Ubuntu diffs, they may already contain what you need (but don't apply blindly ubuntu changes, I already spotted a package adding an rpath, and you don't want to do that). If Ubuntu doesn't include changes to support xulrunner 1.9, you'll have to patch yourself. For that, take a look at other packages, or their Ubuntu diffs, to see if you couldn't get hints from there. Also, you can refer to upstream documentation about code porting[6]. At least all gnome desktop applications should have patches in the Ubuntu diffs. If you want your upstreams to apply the patches required to build against xulrunner 1.9, you should be careful that source changes don't break builds against xulrunner 1.8, though, but that's not something that is required for Lenny, so if you don't have time, just skip that part. If you need assistance, contact the pkg-mozilla team, preferrably on the list [7], so that we can help you. You will be able to upload plugins and components packages as soon as iceape-dev gets out of NEW. For embedding applications, you can already try things with xulrunner-dev 1.9~b5-3, but it will only work on x86_64 for a stupid reason. As a workaround, you can try replacing x86_64 by your architecture in /etc/gre.d/1.9.system.conf. This is fixed in version 1.9~b5-4, which is why you need to build depend on that version. (and wait for it to go out of NEW). The goal would be to have everything ready in unstable by the end of may, so that we can realistically stabilitze everything before the release. Before that, it would be great if you could upload packages building against xulrunner-dev in experimental, say, by mid-may. Please also notify us if you think you won't be able to make it before then. Thanks for your attention. Mike 1. libxul-dev build-depending packages' maintainers BCCed. Please bounce to maintainers of any concerned package that does *not* appear in the following list (and tell me what package is missing, too ;) ): blam, chmsee, classpath, devhelp, eclipse, epiphany-browser, epiphany-extensions, evolution-rss, galeon, gcj-4.1, gcj-4.2, gcj-4.3, gluezilla, gnome-chemistry-utils, gnome-python-extras, gtk-vnc, gtk2hs, kazehakase, liferea, miro, mozilla-bonobo, mozilla-traybiff, mplayerplug-in, openoffice.org, openvrml, pcmanx-gtk2, rhythmbox, ruby-gnome2, seahorse, swt-gtk, totem, vlc, yelp 2. The packages in question are: bfilter, freej, edbrowse, gxine, libjavascript-perl, mediatomb. elinks is excluded because only experimental contains a version requiring libmozjs-dev, and this version is not planned for Lenny, as seen with elinks maintainers. 3. http://people.debian.org/~glandium/mozjs-1.9/ 4. See bug #478064. A header in libmozjs-dev needs changes too, which has been done in version 1.9~b5-4. 5. http://people.debian.org/~glandium/plugins/ 6. http://developer.mozilla.org/en/docs/Migrating_from_Internal_Linkage_to_Frozen_Linkage 7. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]