Procmail Maildir messages disappearing

Google-friendly title, no?

Executive summary:

In your ~/.procmailrc

MAILDIR=$HOME/Maildir – is BAD, whereas

MAILDIR=$HOME/Maildir/ – is good.

The slash at the end appears to tell procmail that this is a Maildir directory, rather than something else, elusive.

For a week my messages were appearing in $HOME/Maildir, but they were just in there with names like msg.zFS, instead of going into $HOME/Maildir/new and having a name like 1282544959.Q22432E173.192.0.54.2:1,T.

This meant they effectively disappeared, and I had a quiet, relaxing week.

Followed by a panicked and expletive-filled hour or so.

When I put the slash back, new messages started appearing in my Inbox again.

I was also able just to move the msg.zFS files into “new”, and they appeared fine, which was nice.

lastfmsubmitd on Ubuntu Dapper

So I had been thinking about putting last.fm support into GSSMP, and then I got an email to the mailing list suggesting it, and then I couldn’t sleep tonight, and, as ever, something that sounded easy has turned into a saga.

I decided to use lastfmsubmitd to handle communicating with last.fm, since it seems silly to re-implement this in every app, and, after worrying that the web site didn’t mention any binary packages, I was glad to discover that it has indeed been packaged for Ubuntu Edgy, Feisty and Gutsy.

Of course, since I use an distro version that is *gasp* almost ONE YEAR OLD (Ubuntu Dapper) there were no packages for my version.

So I downloaded the Edgy version and tried to install it, but it complained that my version of python-support was too old.

After quite a bit of faffing I extracted the .deb file using ar (1), and then untarred the file inside there called control.tar.gz and edited the file inside there called control so that it said python-support (>= 0.1) instead of 0.2. Simple, eh?

[Of course, all of this assumes that the packager had no good reason for asking for version 0.2. So far, it looks like that assumption was correct.]

After some careful re-tarring and re-arring (if that’s a word) I had a new .deb, which you can download if you’re interested, from here: lastfmsubmitd_0.32.1-1-friggedbyandy_all.deb which appears to install cleanly (so long as I create a config file /etc/lastfmsubmitd.conf BEFORE I install…).

That config file, by the way, just looks like this:

[account]
password = mypassword
user = myusername

and is owned by the lastfm user, in the root group, and is not readable by “all”. Note that you can’t make it owned by the lastfm user until after you’ve installed the deb, because that user won’t exist until then.

Are you following so far?

Of course, for some unknown reason that deb only contains the daemon lastfmsubmitd, and not the helper program lastfmsubmit, which allows you to actually submit tracks on the command line, despite the fact that the deb installs the man page for that command.

So, I downloaded the relevant original source package, and just extracted the file lastfmsubmit and put it in my PATH.

After executing a simple command like this:

sudo chmod a+w /var/spool/lastfm

(obviously) it seems to actually work when I run from the command line like so:


lastfmsubmit --artist "Propellerheads" --album "Decksandrumsandrockandroll" --title "A Number of Microphones" --length "45"

Now on to doing what I actually wanted to do…

Update: note also the bug in these packages that prevents cron.daily from running: Ubuntu 136717

Obviously, there was a bug

So I’ve released GSSMP 1.1, which is guaranteed to contain one fewer bugs, and is relatively unlikely to contain any new ones. Also, thanks to João Pinto, it should build without warnings on AMD64 too!

If anyone wants to make an AMD64 package, I’d be really happy to put that up on the download page. It should be a simple matter of unzipping the source, cd-ing into the gssmp directory, and running make pkg-all.

Go on, it’ll be fun…