Mozilla in Lenny

[Mike Hommey]

Hi,

Here is another status update, for xulrunner only. It's not moving as fast
as it should, but I lack time for that.

On Wed, Jul 23, 2008 at 07:57:46AM +0200, Mike Hommey wrote:
> Current versions of iceweasel and xulrunner in unstable are better than
> the ones in testing right now, but are still not release quality. There
> are still at least 2 really problematic bugs with it, and a bunch of
> other issues I'd like to tackle before release:
> - #482415 and #486334, which I'm not sure if they are the same issue or
>   not, and I can't even reproduce.

Still nothing on that front.

> - #490360 for which I wonder if I'm not going to "simply" disable the
>   jemalloc library by default, but leaving possibility to enable it
>   (note: Ubuntu doesn't have it enabled though shipping it, because
>   the xulrunner-stub doesn't load it, normally ; I patched it to do so)

I disabled jemalloc and users will be allowed to enable it setting the
MOZILLA_JEMALLOC environment variable. This will be in xulrunner
1.9.0.3-1 due soon.

> - j2re1.4 is making a whole bunch of problems. Having it installed and
>   having the /usr/lib/mozilla/plugins/libjavaplugin-oji.so file pointing
>   to it makes xulrunner-1.9 infinitely loop at initialization when the
>   plugin is not registered. When you solve the infinite loop problem
>   (which this plugin is the only one to trigger), you hit #402165, and
>   once you work around that one, you end up with a crash in
>   JavaPluginFactory5::Initialize () from
>   /usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so.
>   So, considering this file is in j2re1.4, I found no better way to
>   solve the issue fully than to conflict with j2re1.4. The problem is
>   that people who don't care about the plugin, but only care about the
>   java runtime version 1.4 just can't install it, and we already got a
>   bug report from a user needing just that. Any suggestions welcome,
>   here.

Nothing new here, unfortunately.

> - Seeing how many problems we have with plugins, and how it's a burden
>   for users reporting bugs to go all the way moving them around
>   (especially now that we have 2 system directories for plugins, which
>   is intended as a transition for lenny+1), I want to implement
>   https://bugzilla.mozilla.org/show_bug.cgi?id=342333, i.e. having
>   iceweasel -safe-mode disable all plugins. It's possible in Tools >
>   Add-ons > Plugins, already, but when your browser crashes before you
>   can even reach that, that's of no help.

I added a way to disable all plugins by setting the
MOZILLA_DISABLE_PLUGINS environment variable instead, so that it is also
possible to easily disable plugins in embedding applications such as
epiphany, and not only iceweasel.

> - Anti-phishing protection should be disabled by default, because of its
>   privacy concerns.

This must be done on iceweasel end.

> - #491822

This still needs investigation, and is iceweasel stuff, anyways.

> - Remove mozilla-xremote-client call in run-mozilla.sh, as this is done
>   by the applications themselves, now, and it's posing some problems at
>   build time at least on PPC

Will be fixed in xulrunner 1.9.0.3-1. It appears the xulrunner startup
script suffers from a lack of love upstream, and has not seen many of
the changes that happened to the script for firefox, which used to be
exactly the same, but diverged because of this.

> - #491693

Will be fixed in xulrunner 1.9.0.3-1

> - Allow mozilla xul extensions to live in /usr/share/mozilla/extensions/
>   instead of /usr/share/mozilla/extensions/{application_uuid}, which
>   breaks the purpose of having a shared location.

This won't actually happen. For one, location will have to be
/usr/share/mozilla/extensions/common, as agreed with upstream, and it
can't be done as easily as I would have liked it to be done, so it will
have to wait more important issues to be solved first. This can wait
after Lenny, anyways.

> (I may have forgotten some others, if you can think of some, please
> followup. I'll also do that myself if I remember something important)
> 
> For iceape, I would have liked to reintroduce the calendar package, but
> I haven't had time yet, and it's too late in the release process to add
> this back. This unfortunately means regression for stable users, but
> it's too risky to add this bunch of untested code now.

FWIW, about other packages:

> For other mozilla related packages I maintain (or not yet), there are a
> couple things I need to do before release:
> - Fix venkman so that it works with any 3.0.x version of iceweasel.

This was done, and the fixed venkman is in testing already.

> - Package the new upstream of tabextensions. This might end up as a new
>   package because while the new one is the only way to get it work with
>   iceweasel 3.0, I'm not sure it works with iceape and even if it does,
>   it'd a huge regression in functionality.

tabextensions new upstream is so much of a different beast that I'll
just leave the current one for iceape only.

> - Package dom-inspector, which is not provided by iceweasel itself
>   anymore.

This was done, and it reached testing a while ago. There is a new
upstream changing a bunch of stuff, supposedly fixes for
firefox/iceweasel 3.0. I will probably upload this new upstream to
unstable, and see what we will do with it.

I'm going to upload 1.9.0.3-1 soon, so I invite the release team to
already take a look at the upstream changes to anticipate the upload.

Changes between 1.9.0.1 and 1.9.0.2
http://git.debian.org/?p=pkg-mozilla/iceweasel.git;a=commit;h=665bfa3a9adefe649266a524aa046c513f937ab3
Changes between 1.9.0.2 and 1.9.0.3
http://git.debian.org/?p=pkg-mozilla/iceweasel.git;a=commit;h=f2bb1a05028205e3c0c1ca9f769b291aa79b1a71

(This is the iceweasel repository, but as it happens, xulrunner and
iceweasel tarballs are now perfectly identical)

Cheers,

Mike