bloovis.com

I currently use fetchmail to download my Gmail email via POP3 to my laptop, where I read it with a text-mode email client called sup. But for a couple of months back in 2009, I was in the middle of a cross-country move and temporarily switched to using the Gmail web UI. Then when I switched back to using fetchmail, it wasn’t able to read those two months’ worth of email, which remained missing until today.

To get back the missing messages, I first used the Gmail web UI to label those messages. I knew that I was missing email that had arrived between July 9, 2009 and Aug 29, 2009. So I did a search in Gmail for after:2009/7/9 before:8/29/2009. Then I clicked on the “select all” checkbox, and when Gmail asked me if I wanted to select all 1700 messages in the search results, I said yes. Then I tagged those messages with the “missing” label.

Back on the laptop, I installed mutt, another text-mode email client that I used for many years, and which has excellent IMAP support. I created a ~/.muttrc file that looked like this:

mbox_type=Maildir
set from = "myusername@gmail.com"
set realname = "My Name"
set imap_user = "myusername@gmail.com"
set imap_pass = "mypassword"
set folder = "imaps://imap.gmail.com:993"
set spoolfile = "+INBOX"
set postponed ="+[Gmail]/Drafts"
set trash = "imaps://imap.gmail.com/[Gmail]/Trash"


I created a maildir to store the missing messages:

maildirmake ~/Maildir/missing


Finally, I started mutt. It showed my Gmail inbox, so I told it to switch to the “missing” pseudo-folder by typing c=missing. I tagged all the messages in that folder using T., then saved them all to the newly created Maildir folder using ;s~/Maildir/missing. It took several minutes to download many megabytes of email. After that was done, I now had a fully-populated mail directory containing all the missing messages.

Each time I install Linux Mint on a new machine, or upgrade an installation, I have to perform a set of tweaks to get the system to look and behave the way I want. After doing these tweaks yet again over the weekend, I decided to write them down for posterity.

• Before IBM introduced the PS/2 in the mid-80s, the Control key on terminals and PCs was always where God intended it: next to the A key. The PS/2 keyboard moved the Control key to a very inconvenient location on the bottom left corner of the keyboard. All other PC makers copied this incredible blunder. Finger tendons have suffered ever since, especially those of Emacs users. To fix this: Menu / Control Center / Assistive Technologies / Keyboard Accessibility / Layouts / Options / Ctrl key position / Swap Ctrl and CapsLock.
• Make bash the default shell: sudo dpkg-reconfigure dash, answer No.
• The compiz window manager provides useless eye candy and doesn’t honor some window manipulations, like roll-up. To disable it: Menu / Control Center / Appearance / Visual Effects / None. This must be done before changing window behavior.
• I like seeing all windows in the task bar when I switch workspaces. To enable this, open Window List Preferences, and enable Show windows from all workspaces and Restore to native workspace.
• Enable Emacs editing keys in Firefox: gconftool-2 --set /desktop/gnome/interface/gtk_key_theme Emacs --type string
• Install useful Firefox addons: Adblock Plus, Keyconfig, Flashblock, LastPass, ViewSourceWith.
• I dislike having to enter my password when the screensaver comes on after an idle period. To disable this behavior: Menu / Control Center / Screensaver / uncheck Lock screen when screensaver is active.
• Add the volume control to panel: right-click on panel, select Add to Panel, choose Indicator Applet.
• Install the SSH server to allow remote shell access: sudo apt-get install openssh-server
• To enable two-finger scrolling on the touchpad: go to Menu / Preferences / Mouse / Touchpad, where the option can be found.
• Suspend when the lid is closed: Menu / Preferences / Power management / When laptop lid is closed: Suspend.
• My editor has bindings for F1 and F11, but gnome-terminal uses these as shortcuts for Help and Full Screen, respectively. This page has the solution. To disable F1 in gnome-terminal: Edit / Keyboard Shortcuts. Select action Contents, click on F1, hit Backspace to change the binding to Disabled. Do the same for F11.
• Install a bunch of useful packages: keepassx, openssh-server, gnome-ppp, dvdbackup, flac, vorbis-tools, ruby, rubygems1.8, ruby-dev, libtcltk-ruby, cdparanoia, tkdiff, sun-java6-bin, sun-java6-jdk, sun-java6-plugin, sun-java6-jre.

It looks like the upgrade to the latest Ubuntu is going to keep me busy solving problems for a while.

Today’s second problem has to do with the fingerprint reader in the ThinkPad X41. There’s a good source of information here, but there wasn’t a definitive set of instructions for Ubuntu 10.04 that actually worked. Most of the uproar about the fingerprint reader in Ubuntu 10.04 has to do with a bug where the Enter key has to be pressed after swiping your finger. I couldn’t even get to that point; the trouble was getting logins to prompt for a finger swipe.

As per the instructions at ThinkWiki, I installed and configured the required packages from the standard repository (no PPAs):

sudo apt-get install thinkfinger-tools libpam-thinkfinger
sudo /usr/lib/pam-thinkfinger/pam-thinkfinger-enable

Then I was able to use tf-tool --acquire and tf-tool --verify to show that the fingerprint device worked. But I was not able to use tf-tool --add-user USERNAME to create a fingerprint file for use by the authentication system; this build of tf-tool did not support that option. So I had to set things up manually, by acquiring the fingerprint file and placing it in the proper directory, with the proper name, and with the proper permissions:

sudo su    # login as root
cd /etc/pam_thinkfinger
tf-tool --acquire USERNAME.bir
chown USERNAME:root USERNAME.bir
chmod 400 USERNAME.bir

In all of these commands, substitute your ordinary user name for USERNAME. After this is done, authentication prompts, either in a terminal (e.g., with sudo) or in X (e.g., the login screen), should ask for either a password or a finger swipe. Due the known aforementioned bug, it may also be necessary to hit Enter after the swipe.

I have an old Logitech QuickCam for Notebooks that uses the pwc (Philips Web Cam) driver on Linux. This camera has always worked flawlessly on Linux Mint 6 (Ubuntu 8.10). But on Linux Mint 9, the camera only worked the first time it was plugged in; on subsequent plug-ins, no programs could read images from the camera. The fswebcam utility reported a timeout trying to read the frame buffer; other programs like Cheese or Skype simply displayed blank images.

The solution is to unplug the camera (if it is not already unplugged), then forcibly remove the pwc driver:

sudo modprobe -r pwc

Then the next time the camera is plugged in, the pwc driver will be loaded automatically and will work properly. This has to be done every time you unplug the camera. I’m not sure why this is necessary with recent Ubuntu releases.

I just spent many hours getting a 4GB USB key into a state where it can be used to boot Linux Mint 9 (based on Ubuntu 10.04). Here are some notes on the problems I had to solve.

In the past, I’ve used unetbootin to create bootable USB keys. When I did this with the Linux Mint 9 ISO image, the resulting USB key booted up just fine, but the installer application hung when trying to run the partition editor. I narrowed this down to an assertion failure in libparted. Apparently it doesn’t like the geometry on some USB keys. This is a known bug.

Fortunately, the ThinkPad R61 has a CD drive, so I created a CD from the ISO image and booted that. Then after installing Mint 9 on the hard disk and booting that, I was able to create a bootable USB key that didn’t crap out in the installer. I did this by using Mint 9’s built-in Startup Disk Creator, which is in the main Menu under Administration. I told it to erase the entire USB key, which apparently reconfigured its partition table into a form that libparted liked. I verified this by rebooting the R61 with the USB key and running gparted.

The next set of problems came when I tried booting an older ThinkPad R50p with the USB key. As in all recent ThinkPads, you can choose the boot device by pressing the blue ThinkVantage or Access IBM button at startup, then pressing F12. But on the R50p, the USB key wasn’t shown as a boot device. I ran Setup (IBM’s term for BIOS configuration), and in the Startup screen I tried to enable the USB HDD device. This didn’t work; the machine just beeped at me. After a long bout of head-scratching, I finally figured out that Setup doesn’t allow more than eight boot devices to be enabled. I disabled a couple of useless boot devices (e.g., HDD1 and USB Floppy), and then I could enable the USB key.

Finally the USB key would start to boot on the R50p. But after the Linux Mint logo came up, the machine hung with the hard disk light on solid. I rebooted from the USB key and selected the recovery mode boot option in Grub (I forget the exact name for it). Then I was able to see the last error message at the hang. It was an I/O error accessing the fd0 device, which is the floppy. More headscratching and Google searching revealed that I needed to disable the floppy device in Setup.

Now I was able to get past the hang on booting from the USB key, but then X refused to run, displaying a dialog box saying that it was going to run in low graphics mode. This turned out to be a problem with the kernel mode setting (KMS) feature of recent Ubuntu releases. Apparently this is a very bleeding-edge method of determining graphics card type, and it doesn’t appear to work on older machines. The fix was to provide the nomodeset kernel parameter when booting. I did this by hitting Enter when the Grub menu came up, then hitting Enter again to edit the kernel command line. I add the nomodeset parameter and pressed Enter a couple of more times to boot. This time the system was able to boot to a good desktop, though the Mint logo didn’t appear during the early boot stages.

I upgraded one of my ThinkPads from Linux Mint 7 to Linux Mint 9 today, and discovered that I was no longer able to use my HP P1006 printer. The HP printer tool (hp-toolbox) detected the printer correctly, downloaded the appropriate plugin, but then couldn’t install the plugin. Running the tool from the command line didn’t give any extra information. This is a known bug in Ubuntu 10.04.

The solution is to download and build the HP printer package (known as hplip) from source. The complete instructions are here. I had to install the following extra packages before the configure and make steps would succeed: libjpeg-dev, libsnmp-dev, libcups2-dev, libusb-dev, python-dev, libsane-dev, and libcupsimage2-dev.

I use pilot-xfer (part of the pilot-link package) to back up the data on my Palm Centro, and occasionally to install files on the Centro. It’s always worked fine on Linux Mint 6. The only thing I needed to do before running pilot-xfer was load the visor kernel module using this command:

sudo modprobe visor

But when I switched to a different laptop running Linux Mint 7, pilot-xfer never seemed to be able to connect with the Centro for the second and subsequent attempts after a reboot. Some poking around revealed that the problem is apparently due to the visor module setting up an incorrect symbolic link for the device /dev/pilot. Normally, after you connect the Centro to the computer with a USB cable and press the hotsync button, /dev/pilot should become a symlink that points to ttyUSB1. But I was seeing it point to ttyUSB0, which is the wrong device file for the Centro.

I couldn’t find an elegant way to fix the problem, so I was forced to come up with a brute force method: before connecting the Centro with the USB cable, remove the visor module and the device symlink:

sudo rmmod visor
sudo rm /dev/pilot

Then after connecting the Centro, load the visor module again:

sudo modprobe visor

Note 1: Immediately after you load the visor module, /dev/pilot will point to ttyUSB0. That’s OK. After you press the hotsync button, the visor module should change the symlink to point to ttyUSB1. If it doesn’t, you’ll have to use the brute force “unplug and unload” method I described above.

Note 2: You should always press the hotsync button on the Centro before running pilot-xfer.

Note 3: You can eliminate the need to use the -p option with pilot-xfer by setting the environment variable PILOTPORT to /dev/pilot. Putting this line in your ~/.bashrc (if your shell is bash) will do the trick:

export PILOTPORT=/dev/pilot

In the previous post, I wrote about how I solved a problem with fetchmail connecting to the postfix mail server. I also have postfix configured to transfer mail to procmail, which does some filtering for me using some rules I’ve written in ~/.procmailrc. But postfix+procmail is really overkill for a laptop or any other machine that is not going to be used as a mail server. Both of these programs can be replaced by maildrop, which delivers mail to your local mailbox or maildir, and which has a much more readable filtering language than procmail.

To get started with maildrop on Linux Mint or Ubuntu, install the maildrop and courier-authdaemon packages. It’s not strictly necessary, but for safety you can also disable postfix by doing this:

sudo service postfix stop
sudo chkconfig postfix off

Now you need to configure fetchmail to use maildrop. Simply add the following line to your ~.fetchmailrc:

mda "/usr/bin/maildrop"

The quotes aren’t necessary; I had them there because I had been experimenting with passing options to maildrop. The fetchmail man page recommends the options “-d %T”, but these aren’t required in this simple, single-user setup.

The next step is to write some mail filtering rules for maildrop. These go into the file ~/.mailfilter. The mailfilter man page describes the filtering language, but doesn’t give many examples. Here’s my ~/.mailfilter (with a bogus address replacing a real one):

DEFAULT="$HOME/Maildir/inbox"
LINUS="$HOME/Maildir/linus"
WOTD="$HOME/Maildir/wotd"

logfile "$HOME/maildrop.log"

if (/^From:.*torvalds@linux\.com/)
{
  to $LINUS
}

if (/^From:.*word@m-w\.com/)
{
  to $WOTD
}

to $DEFAULT

In this example, I’m filtering mail to three different maildir directories; all messages that aren’t caught by the two filters get delivered to the default maildir. If these directories didn’t already exist, they would need to be created with the maildirmake program. maildrop also allows delivering mail to mbox files, but I consider mbox evil and don’t use it any more.

Now whenever you run fetchmail, it should hand off the mail to maildrop for delivery. Check the log file, ~/maildrop.log, to make sure your filtering works as expected.

Today I installed fetchmail on Linux Mint 7, which also brought in postfix as the mail transfer agent. I’d used this combination on Linux Mint 6 with no problems, but on Mint 7 (which is based on Ubuntu Jaunty), fetchmail printed this error message:

fetchmail: connection to localhost:smtp [::1/25] failed: Connection refused.


The error was caused by fetchmail attempting to make an IPV6 connection to postfix on the local machine. Postfix refused the connection, so fetchmail then attempted an IPV4 connection, which was successful. The mail was delivered, but the error message was annoying.

As usual, I tried several solutions I found with Google, including an attempt to disable IPV6 on a system-wide basis. The thing that finally worked was to comment out the following line in /etc/hosts:

#::1 localhost ip6-localhost ip6-loopback


Several years ago, the Ubuntu developers made a horrible decision to make dash the default shell instead of bash. This breaks numerous shell scripts, and I recently discovered it also broke one of my own Ruby scripts that depended on bash’s signal handling. The problem here was that when a TERM signal is sent to dash, it doesn’t kill off its child processes.

The problem isn’t fixed by making bash the login shell for a particular user, because some programs (such as Ruby) invoke /bin/sh, which is a symlink to /bin/dash. The fix for this problem is to make bash the default shell on a system-wide basis. The following command does that:

sudo dpkg-reconfigure dash

When you are asked whether to install dash as /bin/sh, answer No. This will update the symlink, among other things.