[Debichem-devel] Status update for xulrunner 1.9 - maintainers, we need you

Fri May 2 07:30:16 UTC 2008

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. pkg-mozilla-maintainers at lists.alioth.debian.org