Up to now, whenever I've needed a backport or debian recompile, I've done it locally. But finally last night, instead of studying for this morning's exam, I decided to do it properly.

The tool for producing a debian archive tree is reprepro. There are a few howtos out there for it, but none of them quite covered everything I needed. So this is mine. But we'll get to that later, first we need to have some packages to put up.

For building packages, I decided to do it properly and use pbuilder. Just install it:

Make the following changes to /etc/pbuilderrc:

The first, to point to your local mirror, and the second to credit you in the packages.

Then, as root:

Now, we can build a package, lets build the hello package:

dget and debchange are neat little utilities from devscripts. You can configure them to know your name, e-mail address, etc. If you work with debian packages a lot, you'll get to know them well. Future versions of debchange support --bpo for backports, but we use -n which means new package. You should edit the version number in the top line to be a backport version, i.e.:

Now, let's build it. We are only doing a backport, but if you were making any changes, you'd do them before the next stage, and list them in the changelog you just edited:

Assuming no errors, the built package will be sitting in /var/cache/pbuilder/result/.

Now, for the repository:

This file defines your repository. The codename will be the distribution you list in your sources.list. The version should match it. The architectures are the architectures you are going to carry - "all" refers to non-architecture-specific packages, and source to source packages. I added amd64 to mine. SignWith is the ID of the GPG key you are going to use with this repo. I created a new DSA key for the job. NotAutomatic is a good setting for a backports repo, it means that packages won't be installed from here unless explicitly requested (via package=version or -d etch-backports).

Let's start by importing our source package:

(There is currently a known bug in reprepro's command-line handling. -S and -P are swapped.)

Now, let's import our binary package:

Reprepro can be automated with it's processincoming command, but that's beyond the scope of this howto.

Test your new repository, add it to your /etc/apt/sources.list

Enjoy. My backports repository can be found here.

My blog hasn’t had much to say recently, but now that I’m feeling pressured by University assignments, I think it’s time to get back into one-post-per-day mode :-)

I remember once trying Google Reader, just after it launched, and very quickly deciding that I couldn’t stand it, and I’d stick to Liferea.

Recently, however, Liferea has been giving me trouble. It’s been incredibly unstable, and I’d often forgot to run a transparent proxy on my laptop when in restrictive environments, so it’d miss lots of posts and generally be un-happy. The instability I fixed by exporting an OPML list, wiping the configuration, and re-loading, but that was a ball-ache to do. While I was bitching about this, Vhata pushed me to try Google Reader again.

I was pleasantly surprised. It works well, and I didn’t find it oppressive. That doesn’t mean it’s perfect, I’d like to see the following things improved:

• Duplicate post detection (i.e. planetified & origional posts, liferea does this)
• Performance
• Favicons (or something similar, to make it more clear where a post comes from)
• On that note, maybe configurable colour borders for important feeds?
• Automatic refreshing (i.e. “r”)
• More viewable area
• A key press for opening a post in a backgrounded new tab “v” changes your focus to the new tab, which is against the principles of tabbed browsing.

Some cool things it does that lifera doesn’t:

• Clicking on a folder shows you the all the posts from the feeds in that folder
• “river of posts” view, which lets me get through my reading a lot faster
• preloading images for posts that I haven’t got to yet (this contributes a fair whack to the reading speed, given the slow interwebs in ZA)
• Shared items
• Access from multiple machines (OX, X-forwarding worked, but this is neater)
• Doesn’t crash (sorry lifrea…)

I’m converted. Google Reader really is good.

/me gets on with reading feeds…

I came across irssi-libnotify integration in a picture in blog post I read this morning.

I thought about this, and decided that this was something I had to have. I often don’t pay attention to my IRC while I’m busy with something else, and miss out on a conversation that I’m being hailed in. (By something else, I’m meaning non-important, non-masked-interrupts-something-else.)

It isn’t an easy problem to solve, though. Irssi is running on a remote machine inside screen. I’ll be accessing it from one of many machines, possibly NATed, and possibly unable to receive incoming TCP connections.

I googled around a bit, and came across 3 main classes of solution to this problem:

1. Run libnotify directly on the irssi-box, and use ssh’s X-forwarding to display it on my client. This is sub-optimal, because your X server isn’t always available. Example: irssi-libnotify (which requires the module to be reloaded every time you re-attach screen)
2. Output all hilighted messages to a log file (using fnotfiy), and tail that log file with a second ssh session into a local script that calls libnotify. Sub-optimal, because it requires manually running a second ssh session, and restarting it in the event of network issues. Example
3. Send notify events down the Print Channel of the terminal. This will pass through screen, and pop out at your terminal-emulator. xterm and rxvt are both capable of then sending them to an arbitrary command (which could call libnotify). This is quite a clever hack, except that gnome-terminal doesn’t support it. Example

As you can see, they all have major short-comings, and I wasn’t about to implement any of them.

Finally, I realized that Jabber would be a good way to hail me. My laptop / desktop / n800 / foo all run jabber clients. Perfect. I googled, and found a few pre-canned solutions. I settled for jabber-hilight-notify. It runs a jabber client in a perl irssi script. This then sends me a message whenever a hilighted line crops up. (Assuming I’m not in “Do Not Distrub” mode)

I initially had some problems with getting jabber-hilight-notify working. It turns out that setting a custom resource string is a bad idea. My final config was:

My Pidgin provides the libnotify integration, although jabber-hilight-notify’s designed to work with Tavu (a desktop-notification frontend for KDE). I think a better approach would be to use Telepathy. If such a general telepathy-based solution could be found, then it would be easy to have multiple remote daemons send notifications to you via jabber transport.

Now to see if I’m still happy with it after a week of it interrupting me.

I had an interesting discussion with “bonnyrsa” in #ubuntu-za today. He’d re-arranged his partitions with gparted, and copied and pasted his / partition, so that he could move it to the end of the disk.

However this meant that he now had two partitions with the same UUID. While you can imagine that this is the correct result of a copy & paste operation, it now means that your universally unique ID is totally non-unique. Not in your PC, and no even on it’s home drive.

Ubuntu mounts by UUID, so now how do we know which partition is being mounted?

• “mount” said /dev/sda2
• /proc/mounts said /dev/disk/by-uuid/c087bad7-5021-4f65-bb97-e0d3ea9d01a6 which was a symlink to /dev/sda2.

However neither were correct.

Mounting /dev/sda4 (ro) produced “/dev/sda4 already mounted or /mnt busy”.

Aha, so we must be running from /dev/sda4.

/dev/sda2 mounted fine, but then wouldn’t unmount: “it seems /dev/sda2 is mounted multiple times”.

Aaaargh!

I got him to reboot, change /dev/sda2s UUID, and reboot again (sucks). Then everything was better.

This shouldn’t have happened. Non-unique UUIDs is a really crap situation to be in. It brings out bugs in all sorts of unexpected places. I think parted should (by default) change the UUID of a copied partition (although if you are copying an entire disk, it shouldn’t).

I’ve filed a bug on Launchpad, let’s see if anyone bites.

PS: All UUIDs in this post have been changed to protect the identity of innocent Ubuntu systems (who aren’t expecting a sudden attack of non-uniqueness).

The CS Department at UCT has some Wireless APs on Channel 13. This is quite cool (for geeky reasons), but my MacBook (purchased in the US) did not agree. As far as it is concerned, the only 802.11g channels in existence are 1-11.

The reason for this is that my Atheros (madwifi) network card is a software-defined radio. Atheros interprets the FCC regulations to mean that it cannot provide an Open Source driver for this card, allowing it broadcast on any random channel. Thus the madwifi driver contains a binary HAL, produced by Atheros, which is responsible for regulating frequencies and power levels. (This HAL has been reverse-engineered by the OpenBSD people, but not for my card, unfortunately).

The card has two values stored in it’s EEPROM, a “countrycode”, and a “regdomain”. The countrycode is overrideable in software (you modprobe ath_pci countrycode=710), but only if the countrycode you specify is valid for the card’s regdomain. Some cards have a 0x00 or 0xFF regdomain (wildcard values), but mine had 0x64. This meant that whenever I tried to specify a country code, I’d get an error, and the madwifi module would refuse to load:

There has been some success with changing the regdomain in the EEPROM, using the hard-to-find ar5k utility (or possible the ath_info utility?). However, again this didn’t work with my model. But I found an e-mail from somebody who’d been playing with similar stuff. I mailed Salvatore, and he replied almost instantly, pointing me to a public Windows utility for changing regdomains. It depends on a special driver, available in the demo of “CommView for Wireless”.

I installed Windows in my swap partition (it’s not an operating system I normally have around). (Naturally, I forgot to have an Ubuntu CD handy, to rebuild my grub, but that was easily remedied.). After a few blue screens of death (install all necessary drivers first), I got my regdomain changed to 0x37, which is the regdomain for South Africa & Europe.

Now, I’m writing this from a couch in the CS department, using a channel 13 AP. Success.