Archive for the 'mozilla' Category

After quite some work on packaging it, Firefox 2.0b1 is finally being uploaded to experimental.

It is linked to the system libmyspell instead of the bundled one, and can use system dictionaries like Thunderbird already does. I'm also working on using the system libsqlite3, but it first requires some build changes in the debian sqlite3 package and some more work to see if it's really feasible... you see, they like to take external libraries and modify them so much as adding symbols, changing some internals... and these changes only exist in the mozilla codebase... (the 2 main examples of that being expat and sqlite3)

It also includes a working DOM Inspector which upstream didn't include in their release because they are in the process of moving the component in the core.

I also had to fix some more the build system so that some things would be installed by make install (they tend to forget it), others would just be installed (mistakenly removed rules...) or make clean would do its work: cleaning (they tend to forget to flag files for removal when they create it in a Makefile). All that makes me wonder what their review/super-review thing is worth.

Anyways, please give it a try, especially if you reported a bug on earlier versions, it would be helpful if you closed bugs that are fixed by this release (don't forget the 'Version:' in the closing message so that the BTS version tracking would do its work).

Update: Upstream Firefox 2.0b1 has a working DOM Inspector. It only appears it just doesn't build correctly the way we build Firefox... might be some missing changes to the Makefiles. Again. *sigh*

Update 2: It was trickier: missing something to make the inspector symbols public instead of having a hidden visibility...

Update 3: It was actually my fault. /me goes hiding under a rock. And I managed to remove a comment to this post when removing spam... *sigh*. I think I need to take a break.

Then, help spread Firefox and get creditted in Firefox 2. Now, what I think is really amazing is how much effort they spend to credit those helping to spread Firefox, but not those helping to fix it.
Don't get me wrong, I don't care about being creditted myself for the several patches I sent and more, but I'm pretty sure a lot of people who sent patches like me are not creditted either.
It's already a PITA to get patches applied (some patches are still waiting to be reviewed or applied)...

Update: At least, they credit in the CVS logs.

Imagine an application that writes in its application directory, and if it fails to write there, write in a user profile directory.

Imagine a wide-spread operating system where the default settings allow any user to write almost anywhere on the file system.

Enjoy the result (Comment #7 gives a good overview of the problem).

Xulrunner finally reached unstable on sunday, and it already needed some adjustments. I forgot a conflict, misnamed the libsmjs-dev package, the hppa assembler code got somehow duplicated, so xulrunner failed to build on hppa, and some preference files needed to be moved around the packages.

It also fails to build on alpha, but that's not my fault.

I also changed the way we identify a Debian built xulrunner in the user agent. I replaced the "Gecko/yyyymmdd" string with "Gecko/Debian/x.y.z.t-r". That has several advantages over the previous "Gecko/yyyymmdd Debian/x.y.z.t-r" string:

• It shortens the already long user agent string so that additions such as product name are not painful,
• removes pointless information (the date in the original string indicates the date of the build, not that of the API),
• keeps the "Gecko" string (which some site might want, seing how Apple and Konqueror did put a "like Gecko" string),
• and finally avoid confusion with other Debian release informations that may be present in the product specific part (I think Galeon puts one, for instance).

That needed 2 updates, because I realized in between that while you can set the general.useragent.product and general.usergagent.productSub variables, they are not actually taken into account until you change them a first time... The HTTP protocol initialization in xulrunner forces the respective values Gecko and yyyymmdd... I just completely removed that part of the code in xulrunner.

I took advantage of this needed fix to work even more on the package, enabling the typeaheadfind module, needed by galeon and epiphany, removing some old perl code that does nothing except producing useless errors during the build, and, last but not the least, enabling the "flat style" chrome, meaning that instead of being stuck in .jar files, everything is just here in a standard tree.

It appears upstream provides a way to build such trees (option --enable-chrome-format=flat to configure), but it's useless because it doesn't install the trees when running make install. In addition to that, the configure script still requires zip, even if it doesn't use it, except for some obscure .jar files in libnss, that are not installed either. So after disabling the build of these useless files and removing the zip strict requirement if we build flat chrome, and fixing the script responsible for installation of the chrome files, everything got much better.

These changes have been applied to firefox as well, so stay tuned, it's for next upload.

Having highjacked spidermonkey, I did some bug triage there as well. It appeared they could all be closed by the fact libmozjs0d is there. I still need to make some triage in my patches to xulrunner and send upstream those that I still have not sent, if they are of any interest there.

Apart from this xulrunner stuff, I also did some bug clean-up on libxml2 and libxslt, which I've been somehow neglecting for some time.

Martin said:

Firefox and OpenOffice.org seem to be two flagship products of the F/OSS world. At the same time, they are probably the two best examples of programmes orthogonal to the Unix philosophy. Does that mean that the Unix philosophy is the wrong way? Holy Shit!

No, Martin, that doesn't mean anything about the Unix philosophy. It only means Windows developers don't have a clue about Unix.

You know, nothing can be perfect from the first time, so I had to fix a few issues in a new upload. Well, for you, it makes no difference, since 1.8.0.1-1 never reached the archive, but these changes were needed so that epiphany and friends could properly build against xulrunner.

I also started filing wishlist bugs with patches to build some packages against xulrunner as soon as it gets into the archive. Galeon is undergoing. Next one might be kazehakase. Stay tuned.

Update: Patches for galeon, kazehakase, and devhelp sent.

Checking Signature on .changes
(...)
Good signature on /home/mh/pbuilder/sid/result/xulrunner_1.8.0.1-1_i386.changes.
Checking Signature on .dsc
(...)
Good signature on /home/mh/pbuilder/sid/result/xulrunner_1.8.0.1-1.dsc.
Uploading via ftp xulrunner_1.8.0.1-1.dsc: done.
Uploading via ftp xulrunner_1.8.0.1.orig.tar.gz: done.
Uploading via ftp xulrunner_1.8.0.1-1.diff.gz: done.
Uploading via ftp libnspr4-dev_1.8.0.1-1_all.deb: done.
Uploading via ftp libmozjs-dev_1.8.0.1-1_all.deb: done.
Uploading via ftp libsmjs1_1.8.0.1-1_all.deb: done.
Uploading via ftp libsmjs1-dev_1.8.0.1-1_all.deb: done.
Uploading via ftp libxul-dev_1.8.0.1-1_all.deb: done.
Uploading via ftp libnss3-dev_1.8.0.1-1_all.deb: done.
Uploading via ftp xulrunner_1.8.0.1-1_i386.deb: done.
Uploading via ftp xulrunner-gnome-support_1.8.0.1-1_i386.deb: done.
Uploading via ftp libnspr4-0d_1.8.0.1-1_i386.deb: done.
Uploading via ftp libmozjs0d_1.8.0.1-1_i386.deb: done.
Uploading via ftp spidermonkey-bin_1.8.0.1-1_i386.deb: done.
Uploading via ftp libxul0d_1.8.0.1-1_i386.deb: done.
Uploading via ftp libnss3-0d_1.8.0.1-1_i386.deb: done.
Uploading via ftp xulrunner_1.8.0.1-1_i386.changes: done.
Successfully uploaded packages.

I wonder how long it will take to the ftp-masters to accept it. It seems the NEW queue is not as fast as it used to be. It's been a week I've been waiting for libxml2 and libxslt to get through, and they still haven't made it. If enough people is interested in the package before it comes out of NEW, I'll probably upload it in my repository.

I have a patch for epiphany-browser that I'll send soon to the BTS. I'll come up with a patch for yelp as well. Then, bye bye mozilla-browser.

I'm also going to build an unofficial firefox on top of xulrunner, and maybe upload it to experimental, so that we can have some feedback about that. I'll see with Eric about that.

Firefox 1.5 has been released by Eric in unstable, with a package name change, thus I provide a new branding package.

As for compatibility with plugins and extensions (#341682 and #342788), the patch is ready and should go in with the next upload. Stay tuned.

... and for now, it's 1.5rc2 that got in experimental.

I made some changes to the firefox wrapper script so that it should be quicker to launch firefox in most cases. We don't try to find the JVM version, since the ones we wanted to set LD_ASSUME_KERNEL for have been ABI incompatible for a while, and we don't remove the XUL.mfasl and other problematic files since it is now correctly (I hope) by firefox itself. And if bugs arise again, we'll try to fix in upstream code, not in wrapper script...

I also fixed the dash bug and another one in xpidl.

For what it's worth, I did some testing with JVMs and firefox. I got success with

• Sun JRE 1.5update5,
• Sun 1.4.2_10,
• IBM 1.4.2SR3 (but not with java-package, see bug #338277),
• Blackdown 1.4.2-02 and 1.4.1-01.

On the other hand,

• IBM 1.3.1SR8 segfaults,
• Blackdown 1.3.1+02a and 1.3.0-FCS are built against libxpcom.so with older C++ ABI, so ld can't find __vt_17nsGetServiceByCID,
• Sun 1.3.1_10 can't load libstdc++-libc6.1-1.so.2.


mh@namakemono:/tmp$ wget "http://download.mozilla.org/?product=firefox-1.5b2&os=linux&lang=en-US"
(...)
mh@namakemono:/tmp$ tar -zxf firefox-1.5b2.tar.gz
mh@namakemono:/tmp$ cd firefox/
mh@namakemono:/tmp/firefox$ ./firefox
./run-mozilla.sh: line 131: 7540 Segmentation fault "$prog" ${1+"$@"}
mh@namakemono:/tmp/firefox$ ldd firefox-bin | grep c++
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7610000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb67b3000)


Why on earth is upstream's firefox linked against BOTH libstdc++5 AND libstdc++6 ?!?

Update: Okay, now, with a little more thinking:

mh@namakemono:/tmp/firefox$ LD_LIBRARY_PATH=. ldd firefox-bin | grep c++
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb75a0000)


And after a bit more investigation, it appears that the gtk module for scim is responsible for loading libstdc++.so.6...