Archive for the 'debian' Category

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.

Isaac, there is actually a cleaner way to do the same as your hook. Just add the following to your .pbuilderrc file :

export CCACHE_DIR="/var/cache/pbuilder/ccache"
export PATH="/usr/lib/ccache:${PATH}"

EXTRAPACKAGES=ccache
BINDMOUNTS="${CCACHE_DIR}"

That will need bug #341453 to be fixed first, though, but if you set both BUILDUSERID and BUILDUSERNAME it will work out of the box (with the default configuration, PATH is not preserved because of the bug).

Note that you can also set HOOKDIR instead of using the --hookdir command line argument, thus not needing your wrapper.

... 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...

I've been dealing with some open source projects in the past, submitting patches and stuff, but dealing with mozilla.org is really a hassle. You never really know what to do at what moment. They even admit that it's not easy... And I'm not even talking about how bugzilla is a pain in the ass.

But this is the first time I've been asked to actually find a submitter myself.

I already sent patches that actually did land in the CVS without me requesting anything. So what's the difference ? That it's a feature request instead of a bug ?

What about my other patches ?

Recently, I've been going through mozilla-firefox's list of bugs and took a look to some of them. I got interested in #336411, since I'm regularly hit by this one myself (remember ? I said I got strange crashes with 1.5beta1).

It appears that this strange crasher is in fact due to extensions using binary components. ColorZilla was the one killing my firefox. Why does it crash on debian's firefox and not on upstream's ? Simple : upstream's is built with gcc 3.4, debian's with gcc 4.0. Both C++ ABIs are incompatible. Now the question is : what can we do for that ?

A quick fix could be to check before loading the component, if it's linked to the incompatible libstdc++.so.5, but it's almost as nasty as the bug itself... I've not really investigated possible solutions yet, but if you have some better ideas, you're welcome.

Another bug I got interested in is #211010 and its dupe, #256384. This one was really nasty. One of the kind I hate : bad programming practices. The interesting thing with this bug, though, was that it's been revealed because of 3 other issues in 2 separate programs.

The first issue is that autoconf decides to use echo 'something\c' over echo -n something when both '\c' and -n are understood by echo.

The second issue is that when giving some options with spaces to configure (like in --enable-optimize="-pipe -w -O2"), the associated variable gets backslashed spaces (i.e. "-pipe\ -w\ -O2") (thus, being an autoconf feature)

The third issue is that the mozilla configure.in script tries to get rid of these backslashed spaces with echo $enableval | sed -e 's|\\\ | |g', triggering the nasty dash bug. A simple workaround, as stated in #256384 is to quote $enableval

Now, for the dash bug itself.

What happens with dash is that whenever you echo a '\c' escape sequence, all subsequent echo commands stop printing after the first argument containing a backslash. For example echo test1 'test2\ttest3' test4 outputs test1 test2<tab>test3.

In the case of our echo $enableval, since its value was -pipe\ -w\ -O2, it printed -pipe\ without any space after the backslash, so that it was not removed by the sed call. This value was then substitued in config/autoconf.mk.in to create config/autoconf.mk, where the ending backslash was interpreted as its shell meaning (continue on next line), thus breaking the variable, and build command lines.

And for the bad programming practice ?

The dash bug is due to a global variable that never got re-initialized, leaving the "terminate echo" (kinda) flag turned on (which is only checked when there is a backslash in the argument, since it is used to stop printing after, guess what... '\c').

No wonder why one of the first things you learn in programming classes is : never use global variables. (or at least, be very very very careful about what you do with them)

... and in experimental. RC2 is due soon and final a few days after... I'll definitely need to update my firefox extensions packaging kinda howto, so as to all my extensions packages, so that they actually work with latests releases of firefox.

... why on earth is it so hard to release source and binary at the same time ? It happens all the time with mozilla.org software, and it just pisses me off.

Update: Hell, source is still not available, but, well, I just got it from CVS and uploaded to experimental. Enjoy.

... and in debian experimental. I get strange segfaults on quit, though... I'll have to investigate those... I didn't get them with a CVS checkout from 3 days ago, with the very same build scripts... strange.

I also updated the branding package, for which I missed stuff to make it work with Firefox 1.5beta...

Enjoy.

In the past few days, there has been some move on the Firefox front in Debian. Eric uploaded the long-waited non-b0rked security update for sarge, and I finally sync'ed the experimental package with all the last changes from unstable.

I made some work on the mozilla-firefox-branding package so that it actually works for both Firefox 1.0 (and supposedly earlier versions) and Deer Park. Though there are regressions (see NEWS.Debian file), it is now much much cleaner and won't mess up with other extensions as it used to do (it used to behave strange with ctxextensions, leading to a *huge* (and unuseable) context menu). You can give it a try.

Firefox 1.5 beta 1 has been announced for the 8th, and I already started to pull out the latest trunk to prepare its release. Stay tuned.