jmtd → Jonathan Dowland's Weblog

Wow, my first "Debian day" in 2013, but it's a bit of a misnomer because I didn't do any Debian work tonight.

I spent some time poking at geary, Yorba's new email client which looks promising. I haven't managed to get it working much, though. Someone packaged an old version in Debian but it wouldn't work with either my home or my work IMAP/SMTP servers for various reasons. I did get a git checkout to build in March or April but that stopped working on Debian when they dropped "Precise" support (It seems they were backporting various GIR/Webkit bits and pieces into their own code and didn't want to carry that around any more). They've currently got a fundraiser going, they're aiming for $100k and (at the time of writing) need half of that with only 10 hours to go.

Recently I've also been trying to fix a rockbox bug on Sansa Fuze v1 which really cripples writing onto the Fuze. The original firmware does not support microsd capacities >32G which rules it out for me. Sadly the v1 version of the Fuze is uncommon enough that I don't think this bug is getting much attention. My investigations have been limited to fairly dumb bisect-like approaches, combined with lots of writing onto a microsd card (which will probably be killed dead by all this). My initial attempts at a bisect have failed as it turns out the problem is the inverse of a regression: it bizarrely seems as if the bug was fixed in a version-branch, rather than stopped working in one, so it has never been squashed in the main branch at all. Furthermore, the commit that seems to fix the problem is a totally benign version bump, and almost certainly hasn't fixed the bug. So with sufficient further testing I'll probably just prove that this bug has never been fixed. It might be time to switch tack and look into diagnosing the bug rather than trying to side-step it. Or perhaps just spend £15 on a Sansa Clip Zip and forget all about the Fuze v1. Either way I hope someone releases a 128G microsd card this year!

Every now and then I wonder whether it would make sense to package rockbox in Debian in some way. Probably not.

Tags: debian

Recently, I've been using awk in shell scripts more and more often.

When I saw Thomas' Blog I reeled a bit from of the make/shell quoted within. (Sorry Thomas! It's still a thought provoking blog post):

DEBVERS         ?= $(shell dpkg-parsechangelog | sed -n -e 's/^Version: //p')
VERSION         ?= $(shell echo '$(DEBVERS)' | sed -e 's/^[\[:digit:]]*://' -e 's/[-].*//')
DEBFLAVOR       ?= $(shell dpkg-parsechangelog | grep -E ^Distribution: | cut -d" " -f2)
DEBPKGNAME      ?= $(shell dpkg-parsechangelog | grep -E ^Source: | cut -d" " -f2)
DEBIAN_BRANCH   ?= $(shell cat debian/gbp.conf | grep debian-branch | cut -d'=' -f2 | awk '{print $1}')
GIT_TAG         ?= $(shell echo '$(VERSION)' | sed -e 's/~/_/')

I couldn't help but re-write it to be more efficient (and in the case of DEBIAN_BRANCH, more correct):

DEBVERS        := $(shell dpkg-parsechangelog | awk '/^Version:/ {print $$2}')
VERSION        := $(shell echo '$(DEBVERS)' | sed -e 's/^[0-9]*://' -e 's/-.*//')
DEBFLAVOR      := $(shell dpkg-parsechangelog | awk '/^Distribution:/ {print $$2}')
DEBPKGNAME     := $(shell dpkg-parsechangelog | awk '/^Source:/ {print $$2}')
DEBIAN_BRANCH  := $(shell awk 'BEGIN{FS="[= ]+"} /debian-branch/ {print $$2}' debian/gbp.conf)
GIT_TAG        := $(subst ~,_,$(VERSION))

Tags: debian software

With GNOME 3, if you want to override a setting with a new site default, assuming your app has been updated to use the new gsettings API and doesn't still use the old gconf one, the best guide on what to do is still Ross Burton's blog post from two years ago, although you can find most of what you need to know buried deep in the GSettings C API specification, which is not the first place I would have looked (lesson learned!)

Note: In this context I'm in the role of systems administrator, rather than distributor/vendor or software author. Whereas you are generally advised to use gsettings itself and not poke at the backend (dconf for Linux), the documentation seems to point sysadmins towards dconf hackery rather than gsettings. However gsettings worked for me, and I got nowhere with dconf direct.

Some caveats worth knowing about:

• Throughout the GNOME documentation and tools, "schema", "key" and "path" are used nearly interchangeably to mean roughly the same thing. (I think a path describes a key within a schema, to be precise.)
• schemas/keys/paths "must start with and end with a forward slash character", except when they mustn't, such as in override files, where you must use a dot, and you don't prefix or suffix the schema/key/path with dots. In fact the command line gsettings tool only accepts dotted schemas, not slash-separated ones.
• Sometimes, people choose XML, and save themselves the trouble of writing a custom parser, but at the expense of ease for humans having to read or write files. gsettings uses XML for schema files, but a separate ini-style format for override files. Everybody wins?
• glib-compile-schemas requires a path argument, so all your schema and override files must be in the same place. Sites have to lump stuff into /usr/share/glib-2.0/schemas alongside distribution files, rather than separated out to (say) /usr/local/share/glib-2.0/schemas.
• It's quite possible to get an override file past glib-compile-schemas which non-the-less is broken. The result is gsettings clients, including the gsettings binary itself, complaining and then segfaulting. Do not rely on glib-compile-schemas to ensure compliant override files.
• glib-compile-schemas would appear to read override files in native byte order, so make sure you name your override so that it sorts after any distribution-provided overrides. E.g., 20_my_gnome-shell.gschema.override to sort after 10_gnome-shell.gschema.override.

Today I had to create 40 guest accounts on our 70-seat Linux cluster, including randomly generate passwords, set up persistent storage on our NFS server, etc.; quickly. As a nice-to-have I also wanted to add some application icons to the GNOME 3 "Favourite Apps" menu for the guests. Would you like to guess which of those jobs was the easier of the two?

Tags: linux

Last year, I failed to write and mention that I'd joined the Council of the Free/Libre Open-Source Software UK group FLOSS UK, formerly known as the UK UNIX User's Group (UKUUG). As a council-member, I helped to organise the recent Large Installation Systems Administration conference that took place in my native Newcastle, UK.

Five years ago I gave a talk at the (then) UKUUG Linux conference in Manchester, 2008, about documentation for sysadmins, using ikiwiki. I recently noticed that I hadn't put the abstract or slides up here, so now I have.

Tags: linux software

The classic procmail recipe for (reasonably) safe automatic mailing list filtering is

:0
* ^List-Id:[^<]+<\/[a-z0-9-.]+
$MAILDIR/MATCH/

This relies on mailing lists being configured such that the first part of the ID, up to the first dot, is a good identifier for the list. this is not always the case (*.lists.fedoraproject.org, I'm looking at you). Removing the dot from the expression above means you end up with unambiguous, albeit long, folder names (devel.lists.fedoraproject.org).

If you access this mail over IMAP, you have another problem: the dots create a nested folder heirarchy that probably doesn't make any sense (devel → lists → fedoraproject → org). It's possible to change the configuration of IMAP clients and servers to use a different delimiter, but this is not an oft travelled road, and I don't feel like finding the pot holes. Better to substitute the dot for something else. I'd recommend an ASCII character, Unicode seems to throw up a whole bunch of client problems.

Here's a variation that solves the problem:

:0
* ^List-Id:[^<]+<\/[a-z0-9-.]+
{
  :0
  subst=| echo "$MATCH" | tr . :

  :0
  $MAILDIR/$subst/
}

At the cost of elegance, you can add rules to give friendlier names to lists from folks who have well-defined list-ids (integration left as an exercise to the reader):

:0
* ^List-Id:.*debian.*lists\.debian\.org
subst=| echo "$MATCH" | sed 's/\([A-Za-z0-9-]\+\)\..*/\1/'

Finally, there are some "lists" you probably don't want to file in their own individual folders. Inject these into the top-most rule:

* ! ^List-Id.*groups\.facebook\.com

Finally thanks to Brett for showing me some exim filter snippets that would let me implement the above in a (slightly) nicer looking way. Sadly I think I'm stuck with procmail for some other features I use, but it's been a while since I looked.

Tags: email