Archive for November, 2005

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.

I knew that hard disks had a limited time-life park/unpark-wise, but I didn't know that was that bad. I always thought that because of ext3's commit every 5 seconds, disk would never spin out and park the head. I was wrong. It seems that whether or not the disk is accessed, every put here the time it is for your disk minutes, it does park and unpark the head. Well, at least on laptop disks, because it seems this is not the case for desktops.

My 3 year-old vaio, which is now this web server, has a Load_Cycle_Count of 580465 for 9775 Power_On_Hours, which is about 1 load cycle per minute.
My 1 year-old vaio, has a Load_Cycle_Count of 83718 for 4043 Power_On_Hours, which is about 1 load cycle every 3 minutes.

While I managed to actually stop the load cycles to occur on the older vaio, with hdparm -B254, nothing actually stopped it on the newer one. I tried to change some other parameters with hdparm -S but nothing did work. I still have to take a look at the BIOS, though.

Now, the question is : why the fuck are the heads parked/unparked every little while even when accesses occur ? Is it a conspiracy so that laptop disks won't last forever ?

Well, at least, I've never experienced a hard disk failure in 12 years of using computers with hard disks. For how long ?...

[Note: the Dell laptop provided by my company, running Windows XP (which also has a somewhat journalled filesystem and commits the journal every few seconds) has around 24000 load cycles for about 800 hours of use, which is 1 load cycle every 2 minutes, so this is not a Linux issue.]

How surprised am I.

Well, seems I belong to the Shire.

To which race of Middle Earth do you belong?

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

I'm not sure I have to be proud of the fact that my name has a meaning in klingon.


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.