Reasons for loving FLOSS, #<fairly large number>

As I've mentioned before, I've been poking at a gmail backup application based off libgmail. It's been making slow progress, partly because I've been distracted by other things (such as Project Euler), but it hasn't completely stalled.

Recently, while fiddling with it, though, I hit a snag - libgmail would throw an exception when trying to access certain threads. After much head scratching, and testing, I eventually twigged that the problematic threads all included messages sent via google chat. A little focussed debugging showed that gmail creates pseudo mail messages for these when accessed via the API libgmail uses that don't quite match the messages libgmail expects. A little crude patch later, and the problem was fixed for me.

Thus armed, I submitted a bug to the Debian bug tracker, at around 19:00 local time. At 21:00, I received a acknowledgement from the maintainer, who had forwarded upstream, and at 21:10, I received a note that a patch had been applied upstream. Just over 2 hours from bug report to upstream fix strikes me as pretty good going.

New Toy

I have a rather old laptop. Considering that I acquired it at the end of 2001, it's served me exceedingly well, and proved rather robust. All good things must come to and end, and, although I've kept the laptop alive despite a gradually failing hard-drive for some time, the screen, which never quite recovered from water damage due to being caught in some rather heavy rain on the bike, eventually gave up the ghost.

Thus I have a new, shiny, fast toy. I acquired a Fujitsu-Siemens Li1718 laptop (dual-core 1.78Ghz Pentium, 160GB harddisk, ATI graphics, etc) (pictures here). Overall, a very nice shiny toy.

My home desktop machine is still marginally more powerful, but, considering I only spent 7000 rand on the laptop, and I spent slightly more than that on the desktop machine 18 months ago, it's quite a testament to how technology prices have continued to fall.

Installing Debian was quite painless - The latest etch installer had minimal trouble, and upgrading to lenny was completely painless, thanks to doing it at campus, with a nice fast local mirror available (I've not been tracking testing for a while, so I thought this was a good time to start doing so again). The only thing not working out of the box is the wireless network card, but there are patches for madwifi floating around, so hopefully that will fix itself in due course, and I'm not such a heavy wireless user that it really matters. The graphics card is currently not accelerating OpenGL stuff, but the current work on the DRI drivers should solve that fairly soon. There was a time when I would have booted into the windows partition just to check things, but these days my confidence in Linux's hardware support is such that I no longer bother, so I honestly don't know what was pre-installed on the machine.

And, with Eskom's current failure to provide the country with reliable power, it is nice to once again have a machine with a battery life that can be measured in more than seconds (Of course, this means I lose an excuse not to do work, but the toy's worth it.)

Upgrading debian

I don't think I've mentioned recently just how much I adore debian's easy upgrades.

Considering that I upgraded our file server yesterday, with the only major hiccup being due to carelessness on my part (a stupid error on the kernel command line), and everything seems to be working fine now, with almost no additional tweaking required, I think it's time a corrected that lack.

I am truly a fan of the work and effort that goes into knocking the rough edges off the entire process.

The upgrade that didn't quite go according to plan

Today (well, yesterday now), I replaced the machine that had been hosting dip.sun.ac.za with a much faster and shinier bit of hardware. To keep the upgrade simple, I had planned to move the old hard disks across and go from there. Since it's very new and shiny hardware, I spent some time ensuring dip had a new enough kernel and all that, so everything should have been fairly smooth.

I wish.

One of the hard drives failed when moved across. No problem, says I, I have a spare, and it's a raid array, so plug in the spare, let the array rebuild and all will be OK. The spare was the right size for the array, only the failed drive had hosted raid space + some extra reserved for swap and a couple of dirs, like /tmp that didn't need to be on the raid array. Aha, says I, I have another extra drive handy, so plug that in, make swap space and the file-systems, and everything is hunky dory. That done, I sat a twiddled my thumbs for a couple of hours while the RAID array rebuild (I did go and have supper while doing this). Once the array had rebuild, and after I'd fixed udev's naming oif the network devices, I rebooted - and the system did not come up. With very little info as to why. Eventually, I booted up using a rescue disk, to discover the problem was because the drive I'd shoved in to provide the swap space had some old lvm metadata left on it, that was stopping the lvm partitions being found correctly. Once this got sufficiently nuked, the machine was happy. I was less so, since by this stage the upgrade had eaten up a lot more time than I wanted.

Still, new shiny machine is running, and seems to be running very fast, so all looks to be well at the moment. I also took the opportunity to upgrade dip to etch, since I was breaking stuff anyway. Other than a brief hiccup with Openldap, it went often without a hitch.

What I did with my extra long weekend

Other than the usual weekend games session (which was quite fun, although I did horribly in the Big Cheese, and got left in awful position in US Patent No 1), and watching the world cup final, I mainly upgraded tron to debian etch.

Why did this take so long?

Well, the downloading everything over dialup part played a role. Convincing the lirc modules to compile was also a bit of a pain (a combination of out of date docs, and not wanting to dial up during the day on Monday meaning I solved the problem in a rather convoluted way). Migrating the settings from freevo-1.5 to freevo-1.7 was fairly painless, but what took the most time was my very clever idea to replace the awkward custom scripts fro running freevo with gdm & autologin. This worked fine, but I spent several iterations getting the session configured so that freevo would start by default. All is now solved, and tron is up and running better than ever. My local tweaks, based off patches in the freevo bug tracking system, are now unnessecary. Of course, I completed everything just in time to notice that freevo-1.7.1 had been released, so I'll have to update to that soon as well, but that should be a fairly minor issue, especially as I've setup freevo in a dedicated directory under /opt

One advantage of the newer combination of kernel and lirc modules, is that all my remote buttons are now recognised correctly, which has simplified my .lircrc configuration for freevo, so I feel the effort has not been wasted.