Bah, 4 year old fixed chrome bug still an issue for TB developers

I idle in many Mozilla's IRC channels, and happened to see some chrome registration lines pass by on #extdev. The developer was having an issue with their chrome files not being found, with an error similar to:

no chrome package registered for chrome://extensionname/content/somefile.xul

The immediate thing I noticed was their chrome registration lines were describing extensionName rather than extensionname. Having been in the process of rewriting my extension to do things Mozilla Build way, I had been reading Chrome Registration a day or so earlier, and saw that it listed FireFox 2 as not handling mixed case package names as part of registration. Bug 132183 (thankfully listed on MDC article) seems to describe the issue, first reported in 2002 and resolved in 2005. A suggestion to use lower case for the package name fixed the bug for the #extdev developer, and a few hours later I've tried figuring out if this really was the cause.

I needed to find what code the latest release of ThunderBird was using. The version is 2.0.0.23 at this time, found here http://www.mozillamessaging.com/en-US/thunderbird/ . According to MDC, ThunderBird 2 uses the Gecko 1.8.1 branch. The bug report says the it was fixed on trunk in December 2005, somewhere around the 13th or 14th. After spending some time trying to work out what version was trunk at that time (I don't figure it out), I try to find the commit related to the bug. There isn't a link to the commit from the bug report. I look at the patches submitted on the bug report to find out the file most likely to change by the fix is nsChromeRegistry.cpp. Using humph's advice from the IRC channel #Education I use bonsai to find commits affecting this file between 2005-12-13 and 2005-12-15 (just in case the timezones are different between cvs commits and bugzilla).
Once the differences are found, and I still have no idea what gecko version this is, I compare the changes made to the source tar.bz2 - why not just check with the source repository for ThunderBird 2 releases? Well, that would assume it's documented somewhere, and in a place that could be found. Under the release notes for TB 2.0.0.23, the FAQ says the release code is in CVS, and to follow the build intructions. The 'TB simple build' on this page is for the coming-soon TB 3, and TB 2 just isn't mentioned. Since the release notes mention it's CVS, maybe the only cvs titled link works: 'Getting Mozilla Source Code Using CVS'. I can see a mention of how to get the TB 2 development branch, but no mention of how to get TB 2 releases. I follow over to CVS Tags and find that TB 2 was indeed using 1.8 branch, and it was made in September 2005 so a trunk commit in December 2005 won't help ThunderBird 2.
The checking of the source.tar.bz2 of the 2.0.0.23 confirms, this bug fix never came to ThunderBird 2. So what to do? The bug was fixed 4 years ago on a later code base; it's not a show stopper but extension developers involved or introduced to ThunderBird 2 have a fair possibility of running into it. So, I've done the only thing I can think of, and documented it on MDC that chrome registrations with mixed case won't work for ThunderBird 2 or SeaMonkey 1.1, in addition to the existing comment about FireFox 2, and used the warning template so people won't miss it. Unfortunately, the templates strip any formatting or links, which makes a link to the bug impossible, but at least there's a place to point for the next ThunderBird extension developer butting their heads against this.

Forced fsck on Ubuntu 8.10 boot

During the boot I got one of those "filesystem has been mounted X times, time for a checkup" messages. I didn't particularly want that, I had other things to do, so pressed Esc to skip. It kinda hanged, and I may have pressed Esc again. Messages spewed across the screen, and Iwas forced to a shell prompt with an instruction to run fsck. Didn't want to do that, so rebooted. Dumped to shell prompt again with an instruction to run fsck. On running fsck, I get many screens of not-very-nice looking messages, and then this:

Buffer I/O error on device sda1, logical block 16777358

Error reading block 16777358 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error? yes

Force rewrite?

Scary. Similar messages have been seen by others, and they've succeeded to get their system back by answering 'yes' to the above questions. Personally, this looks like the point where you will likely lose everything, so if there's anything you value, seek professional help. Answering 'yes' worked for me, but I have no idea what damage has been done. Time for a new hard drive.

Building Firefox Round 2

Things are better the second time around? Rewind 8 months, I was struggling with a debug build of Firefox, nothing was working right. Well, the hint may have been in what I was compiling. I eventually got a build working, but looking back at that, I was building the wrong thing, I was building from cvs when it seems I should have been using Mercurial. Ugh. Makes some amount of sense, but looking at MDC I can see why I thought I was doing the right thing:

"Those doing active development can check out the latest source using CVS"

Which seems to contradict other information on the page. I'm always hesitant with editing this stuff; there are smarter people than me working on this, maybe it's right. I'm pretty darn sure it's wrong.

So, I've bought a new hard drive, installed the latest OS I favour, and starting fresh. I'm building from Mercurial looking at jbostons' wiki content on the build process for Ubuntu. and checking against MDC's build options info. It's been lovely. Here's some feedback I certainly didn't get last time:

checking for stdint.h... yes
checking for inttypes.h... yes
checking for sys/int_types.h... no
checking for GL/glx.h... no
configure: error: Can't find header GL/glx.h for WebGL (install mesa-common-dev (Ubuntu), mesa-libGL-devel (Fedora), or Mesa (SuSE))
*** Fix above errors and then restart with "make -f client.mk build"
make[1]: *** [configure] Error 1
make[1]: Leaving directory `/home/matt/Projects/mozilla/src'
make: *** [/home/matt/Projects/mozilla/src/ff-debug/Makefile] Error 2

What? It couldn't find a header and told me what to install? We are certainly living in the future.

sudo apt-get install mesa-common-dev

Running the debug build has also been a joy. I don't remember getting this much feedback at the console last time, I'm not entirely sure it's all good news:

++DOCSHELL 0xb11bbac0 == 5
WARNING: NS_ENSURE_TRUE(browserChrome) failed: file /home/matt/Projects/mozilla/src/docshell/base/nsDocShell.cpp, line 9888
WARNING: Something wrong when creating the docshell for a frameloader!: file /home/matt/Projects/mozilla/src/content/base/src/nsFrameLoader.cpp, line 1017
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /home/matt/Projects/mozilla/src/content/base/src/nsFrameLoader.cpp, line 1041
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /home/matt/Projects/mozilla/src/content/base/src/nsFrameLoader.cpp, line 197
pldhash: for the table at address 0xb11bbee8, the given entrySize of 48 probably favors chaining over double hashing.
++DOCSHELL 0xb11bbe80 == 6

But it's better the second time around.

Burying The Dead

Sigh. The time has come. I'll try to develop a more detailed post mortem, might create some content for a small bit of a thesis.
Partly in an effort to find a memory leak, way back in March I went about splitting the Bittorrent XPCOM work into separate reusable components. With hope, things like BirdTorrent could make use of these components, as the code is reliant on Mozilla's platform rather than any direct system calls.
Things attempted:

• Splitting the work into parts eg. Server, PeerFactories, Torrents, Bencoding library, BitTorrent Wire library, BitTorrent Utility library
• One step build
• Testing of individual components

These didn't go well. Things didn't go well at all. The fact that the last release of something usable was February, and it's now November, isn't a particularly thrilling fact. Pretty much each task I've gone along with in that time has stalled at some point, so now my project has more loose ends than functioning ones. There's been times when I've thought it might get better, but I don't really have the support needed for this development (or not willing to ask for it, because it needs too much). It's damn irritating, but at this point I think fixing what's broken would take more time than just starting again.
My aim is to let the current work die. Start afresh, and as it goes I hope to pick through the bones for what may be used, without inheriting the bits that caused this collapse.