Upgrading to Ubuntu 8.04

There have been many blog posts on the Ubuntu Planet about the ease of upgrading to the brand new 8.04 version. Unfortunately, my experience with my Dell Inspiron 1420N was not flawless. Of course, the three big problems were caused by software that was not fully supported; one problematic package was an esoteric bit of software from the community-supported “universe,” the second was caused by a Dell-provided driver for a softmodem I never use, and the third was caused by a proprietary program that hasn’t kept up with the changes to the Linux kernel. There was also a minor problem with the Wifi light that is easily fixed by installing an additional package. Most people, who stick to Ubuntu-supported software (the “main” component), or well-known stuff from universe, will probably have an easier time. I did, however, get everything working with a little bit of elbow grease, the details of which follow for anyone who finds themselves in the same boat.

The first and most serious problem: pam-encfs, as shipped in Hardy, does not work, and will mess up your PAM configuration. This will prevent you from logging in, and in fact, will lock you out of your system in the middle of the upgrade if your screen locks after a period of inactivity (as happened to me). To gain control of things, I had to boot into recovery mode, run “dpkg –-configure -a”, and then “apt-get dist-upgrade” to make sure everything was installed correctly. Even then, I still could not log in. From recovery mode, looking in /var/log/auth.log revealed the following messages:

Apr 22 21:10:18 pigwidgeon gdm[5577]: PAM unable to dlopen(/lib/security/pam_encfs.so)
Apr 22 21:10:18 pigwidgeon gdm[5577]: PAM [error: /lib/security/pam_encfs.so:
    undefined symbol: __stack_chk_fail_local]
Apr 22 21:10:18 pigwidgeon gdm[5577]: PAM adding faulty module:
    /lib/security/pam_encfs.so

After disabling pam-encfs in my PAM configuration, I could log in normally, but my encrypted directories weren’t mounted automatically. Googling around turned up bug 20573 in Launchpad, so I’m not the only one who ran into this. Luckily, there’s a patch, and I’ve built a usable package that will work until the official fix gets into Ubuntu, which can be obtained from my Personal Package Archive on Launchpad.

If you encrypt your entire home directory, something like the following might work (I haven’t tried it myself, so YMMV):

1. Do the upgrade, make sure your screen doesn’t lock, and don’t do anything that would require authentication.
2. Reboot when it’s done, but make sure you reboot into “recovery mode,” and drop into a root shell.
3. Add the my Personal Package Archive on Launchpad to your Apt sources.
4. Do the usual “apt-get update && apt-get upgrade” thing, make sure libpam-encfs gets upgraded.
5. Exit the root shell, continue bootup as normal.

It appears that libpam-encfs is not a very widely used package, so hopefully the number of people who will be bitten by this is small.

The second problem: No Sound. This always seems to be a problem with the 1420N (I initially had no sound on the Feisty to Gusty upgrade), and it has the same cause: the softmodem driver. But I didn’t figure that out until an entry on the Dell Linux Wiki about it appeared soon after the official release. After following those instructions to remove the driver, the problem was solved. I’m sure that in a few weeks the Dell folks will have a new, working driver for the softmodem, but since I never use it, I’m not too worried about it.

Third problem: VMware doesn’t work. There are two issues here; the first is that VMware Server 1.0.x is incompatible with the 2.6.24 kernel series, and the second is a conflict with a system library that VMware overrides. The kernel issue was solved by uninstalling the vmware-server and vmware-kernel-modules packages, installing the tar.gz version of VMware Server 1.0.5, and then running the latest vmware-any-any package (download here). The library conflict, which prevented even the server console from running, manifested itself with the following error messages on startup:

libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2)
/usr/local/lib/vmware/bin/vmware:
   /usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0'
   not found (required by /usr/lib/libstdc++.so.6)
/usr/local/lib/vmware/bin/vmware:
   /usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4'
   not found (required by /usr/lib/libcairo.so.2)

This was caused by an incompatible version of the library libgcc_s.so.1 that’s shipped with VMware. Removing the file /usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1 forced VMware to use the Ubuntu-supplied version of the library, and allowed VMware to start normally.

The fourth problem, which is very minor, was that the WiFi light on the front panel no longer works. This is a consequence of moving to the next-generation driver for the Intel wifi chip. To solve it, simply install the “linux-backports-modules-2.6.24-16-generic” package.

Once those problems were out of the way, I was able to enjoy the new release, which is full of the incremental improvements I’ve come to expect from Ubuntu every six months – including an integrated version of the new Firefox 3, which is worth it for the JavaScript performance improvement alone.

The School as a Neighborhood Anchor

While flipping through the Mozilla blogosphere this evening, I came across an interesting post from David Ascher, the new leader of Mozilla’s messaging effort, which was only tangentially about messaging. He had attended an event where people were discussing how to sesmically retrofit aging Vancouver city schools, and pondered the differences between building a consensus on school construction policy and building a consensus on the “future of email.” One point he made that struck me was this:

… it was hard to find people who didn’t appreciate the elegance of an old idea: that our schools shouldn’t be thought of (and budgeted for) as single purpose “teaching boxes”, but instead as multi-purpose community hubs, leveraging precious real estate to provide a variety of civic services (libraries, gyms, meeting spaces, cafeterias, playing fields), with an appropriate funding model.

He goes on to list a few positive effects of viewing schools in this manner, all of which had me nodding my head in agreement. Building schools with the intent of using them as “neighborhood anchors” won’t solve all the ills of urban schools (I remember a particularly heartbreaking example of a glittering new high school in Washington, DC that was left to rot), but it’s a good idea, especially in communities where there is little investment, public or otherwise.

Fixing MoinMoin for Firefox 3

I’ve been trying out the Firefox 3 betas lately, and have been impressed. But I’ve noticed a big problem with the WYSIWYG editor in the MoinMoin wiki (which runs a small wiki I have on my home network). When I try to click the “link” button on the toolbar, the ensuing popup window is completely blank, instead of showing a nice dialog box as it should. This also happens with any other popup dialog box in the editor. Since Firefox 3 will likely be the standard browser around the house when the next Ubuntu upgrade comes in April, this poses a problem.

So I decided to find out what was going on, and if there was anything I could do about it. The first round of Googling was not encouraging. MoinMoin uses FCKeditor to provide its WYSIWYG editing capability, but it uses very out-of-date version. The FCKeditor folks did a bunch of fixes for Firefox 3, but MoinMoin hasn’t updated their copy to pick up the changes.  There’s a bug report for the issue on the MoinMoin site, but there appeared to be no activity on fixing it. Attempting to simply replace MoinMoin’s copy of FCKeditor with the new version failed miserably; there was a JavaScript alert dialog on practically every keystroke, and with little knowledge of the underlying code, there was no way I could figure out the problem.

After doing some more digging into what the exact Firefox 3 incompatibility was, I found that Firefox has an issue with a window opened with the JavaScript flag “modal=yes”. Further, the discussion in the FCKeditor bug tracker pointed me to a patch that fixed the problem. Unfortunately, there has been quite a bit of refactoring in the codebase, and I couldn’t simply apply the patch to the copy MoinMoin has (the file mentioned doesn’t even exist in the MoinMoin version); I had to backport it. After looking around the directory tree in /usr/share/moin/htdocs/applets/FCKeditor, I was able to find a similar spot in the code, and make the change. Here are the steps:

1. Fire up your favorite editor and open $MOIN_HOME/wiki/applets/FCKeditor/editor/js/fckeditorcode_gecko_2.js. If you’ve installed MoinMoin from an Ubuntu package, $MOIN_HOME/wiki is /usr/share/moin/htdocs.
2. Search on the string modal=yes. It should be on a line that looks something like this:

   var J="location=no, menubar=no, toolbar=no, dependent=yes,
   dialog=yes, minimizable=no, modal=yes, alwaysRaised=yes"+",
   resizable="+(G?'yes':'no')+", width="+D+", height="+E+", top="+H+", left="+I;

3. Remove the “modal=yes,” (include the comma).
4. Clear your browser cache.

After that, I was able to edit my MoinMoin wiki with all the Firefox 3 goodness.

Update 3/21: The MoinMoin developers have checked in the fix, so this won’t be a problem in the next version (1.6.2) of MoinMoin!

Update 4/7: With the fix, the link editor now inserts invalid links.  We’re not done yet.

Power Searching for Thunderbird

The volume of my work email has gotten so huge that I no longer manually tag messages or add them to folders; it’s just too time-consuming, and dragging things to a simple “archive” folder when I’m done is about the only thing from having thousands of message in my Inbox. I’ve been relying on the built-in search capability of Thunderbird (for one account) and Outlook (for the other) to find things. While mostly serviceable, it could be much better, especially since I haven’t mastered the art of finding The Perfect Search Term. Via Lifehacker, I found a new extension for Thunderbird called “Seek” that adds some very interesting capabilities. I watched the screencast, and it looks promising. The Mozilla Messaging people might want to look at this sort of thing to help differentiate Thunderbird from the pack (not just Outlook, but also various webmail services). I look forward to trying this extension out soon.

Emacs and the Modern Desktop

I’ve been using GNU Emacs, an over-featured text editor for Unix-like systems, off and on since 1989. It has a somewhat primitive interface (at least for those who, like me, are accustomed to a mouse and menu-driven interface), and several quirks that are indicative of its pre-Mac and pre-Windows origin (for example, to find a string in a file, you use CTRL+S for “search” instead of CTRL+F for “find”, and the cursor is mysteriously called “point” in all the documentation). But it can’t be beat for the breadth of file editing tasks it handles well; from DNS Zone Files to Apache configuration files to shell scripts to Windows INI files to XML to source code for just about any programming language you care to name (even Ada!), it can syntax-highlight them all, and in many cases provide additional commands that make editing easier.

Its versatility and power – not to mention its essential “Free as in Speech” nature – has allowed it to survive over the years and function well as both a terminal application and a GUI application on many different platforms. But as the graphical capabilities of Linux workstations have evolved, especially in the last five years or so, Emacs hasn’t kept up. It has always been the odd window out on my desktop, with jagged fonts worthy of a early-to-mid-90’s Sun workstation and a Motif-ish scrollbar to match.

Fortunately, a few changes have been made on the “bleeding edge” that allows Emacs to use the same text rendering techniques that most other Linux desktop applications have been using for years, and a fellow named Alexandre Vassalotti has made Ubuntu packages of Emacs with this new feature, making installation a snap.

One problem I had with this tutorial is that he relies on setting the default font for text using X Resources. Since the new “pretty Emacs” is an alpha version, there’s always the possibility of something not working correctly, and so I keep both the new version and a “stable” version installed. Unfortunately, the older version uses a different naming convention for fonts, and since the X Resource Database setting affects both versions, his configuration suggestion doesn’t work for me.

I set the default font programmatically through the initialization file (“.emacs”), which is written in a programming language called Emacs Lisp. I accomplish this by setting an element in a List data structure called “default-frame-alist”, and I needed to find a way to set that element based on what version of Emacs was running. In Java, this would look something like:

AlistElement fontspec;
if(Emacs.getVersion().indexOf(“23”) > 0)
{
     // Use new-style font name
     fontspec = new AlistElement(“font”, “Liberation Mono-10”);
}
else
{
     fontspec = new AlistElement(“font”, “7x13”);
}

defaultFontAlist.add(fontspec);

After shaking off some cobwebs (if you use Emacs enough to want to customize it, you can’t help but pick up a little bit of Lisp along the way), I figured out the the “if/else” part, but how to manipulate the alist (which is called an “Association List,” similar to a Java Map) was a bit tougher. But I stumbled upon someone who had a similar problem of adding things to an alist, and he suggested using the lisp push function. So my final Lisp code looked like this:

(if (not (eq (string-match "23" (emacs-version)) nil))
     (push '(font . "Liberation Mono-8") default-frame-alist)
     (push '(font . "7x13") default-frame-alist))