It’s been a while since I last acquired new gadgets but I think I’ve made up for lost time with my last weeks purchases.

You may remember that I’ve had my eye on the Openmoko phones since early 2007, but in between shifting across the world and starting a new job I never got around to purchasing one of the first versions. The second version, the “Freerunner”, was released in June this year and I placed an order with Pulster, a local distributor, shortly after. The phones have been in hot demand, so I only received my phone last week, a wait of of almost 2 months, and it turned up missing one of the cables that was meant to come with it. Still some distribution kinks to be worked out.

Distribution kinks are the least of Openmoko’s worries at the moment though. As advertised, the phone is definitely not ready for primetime distribution yet. I’ve tried three different software images on it: the original “stable” 2007.2 image, the current “devel” 2008.8 image and the latest completely rebuilt SHR release which is the most promising yet. With the SHR image I’ve been able to send and receive calls and text messages, although the interface is somewhat arcane. I’m most interested in the GPS which looks to be working reasonably well at this stage.

After almost a week with the phone I’m glad I purchased it, and I’m having fun hacking on it, but there is a huge way to go before I’ll be able to use it as my primary phone. So that’s gadget #1.

The second gadget is a new Digital SLR camera. I’ve been thinking about getting back into photography for a while (I last took photos seriously in high school) and when I saw how affordable digital SLRs had become I couldn’t resist. There isn’t much between Canon and Nikon when comparing mid-range SLRs these days, so after about a week of deliberation I decided on the Canon 450D, primarily because most of my workmates also have Canon SLRs!

I only got the camera on Friday, and spent half the weekend playing with the GPS on the phone (I want to set them up so I can geo tag all my photos), so I haven’t had quite as much time to play with it yet. I expect to spend plenty of quality time with it on our holiday in Malta next week. First impressions are favourable, although I’m fast discovering camera viewfinders were not really designed for people who wear glasses. I may have to consider wearing contacts again.

Once we get back from Malta I’d like to find a local (or online) photography club with some good weekly assignments to fire my creativity and motivate me to get the most out of my new toy.

On hardy after the latest round of updates:


matt@krypton:~$ dpkg -s flashplugin-nonfree | grep Version
Version: 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2


Granted this package is in hardy-backports not hardy proper, but still, what on earth?!?!


- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
e0acebd2-71f1-4df8-ae4d-50355ad7aa81
[ 6 ] Choice 1: Wouter Verhelst
[ 6 ] Choice 2: Aigars Mahinovs
[ 3 ] Choice 3: Gustavo Franco
[ 3 ] Choice 4: Sam Hocevar
[ 2 ] Choice 5: Steve McIntyre
[ 4 ] Choice 6: Raphaël Hertzog
[ 1 ] Choice 7: Anthony Towns
[ 6 ] Choice 8: Simon Richter
[ 5 ] Choice 9: None Of The Above
- - -=-=-=-=-=- Don’t Delete Anything Between These Lines =-=-=-=-=-=-=-=-


*yawn* It’s made me tired writing all of that out. Maybe sometime soon I should explain in more detail exactly what parts of Debian’s governance model I think need changing or maybe I need to wait until I’ve achieved a few more technical things and gained enough respect before anyone will listen to my opinions…

About a month ago Dell announced with great fan-fare that they were the first computer company that offered their customers the chance to be carbon neutral, by planting trees to offset the carbon dioxide generated in producing a years worth of electricity for the computer. Nice idea.

They’re lucky that they specifically didn’t mention packaging, and saving the forests. I was down in Hamilton today for work, and a box from Dell arrived with two sticks of RAM for a new Dell server. We’re talking standard 1GB ECC sticks of ram. The packaging for these two unremarkable sticks of memory amounted to no less than seven boxes of increasing size (think japanese dolls), 8 peices of packaging foam, and one long strip of “air bubbles”. Two of the boxes contained absolutely nothing except for packaging foam, and were just used to pad out the medium size boxes, so that the boxes containing the actual ram didn’t bounce around. The two sticks could easily have fit in just one of the smaller boxes! The waste is unbelievable, see the picture below with your own eyes.

click for fullsize image

With the number of trees that died to support this packaging effort, I sure hope that the $6 I pay to make my desktop carbon neutral plants a lot more trees than is strictly necessary!

I had a bit of a surprise today when I sat down to read this weeks DWN and found my own name and a link to and old post about some Lightweight Debian Archive Scripts that I had written in October last year staring back at me from the second sentence!

As chance would have it, just last week I updated these scripts to use reprepro, as suggested in many of the comments that I received after writing the last post. I hadn’t got around to making the new scripts public yet, so I guess the link from DWN is a sign of sorts!

My main motivation for updating the scripts to use reprepro was to give myself the ability to have a testing, and stable archive as recently we’ve been dealing with .debs manually for testing as we didn’t want to put them into the archive for fear of prematurely updating the production hosts with untested code. I’d heard that reprepro had some nice support for moving packages between local repositories which sounded exactly like what I wanted.

Reprepro was indeed fairly easy to setup and install. I backported reprepro 0.9.1 and installed it alongside my existing sbuild setup as documented in the original post.

The changes to the scripts were fairly minimal, although again, they assume some things for my environment, and its likely that they’ll need some modification before being useful to you:

• process_packages assumes you have pairs of distributions named like ‘foo’ and ‘foo-testing’. Every package picked up from incoming/foo is automatically added into foo-testing after it is successfully built
• add-packages is mostly redundant, used only to add packages manually if the automatic insertion fails because reprepro has got itself confused

You can grab the updated scripts and my reprepro configuration from:

• process_packages - Runs from cron to build new packages and add them to the -testing archive
• add-packages - Manually adds packages
• distributions - Reprepro distributions file
• options - Reprepro options file
• pulls - Reprepro pulls file

The new setup is great and I’m very happy with reprepro and the new archive. The only thing I haven’t had time to look into properly yet is how to pull specific packages from testing into stable, but not everything. Ideally I would be able to run a command like

reprepro <stable-dist> pull <pkgname>

If I could get that working then it would be awesome.

Over the past few weeks I’ve been working on extending the dbconfig-common packages to support the SQLite database format. My primary motivation for this is so that I can start using dbconfig-common to manage the database(s) for the PHPwiki packages which currently only support SQLite out of the box.

The main changes that were required were to separate out the debconf questions that are only relevant for remote and authenticated database types. These changes were committed yesterday. I plan to make the remaining changes required to bring the SQLite support up to scratch over the next few days, so hopefully dbconfig-common 1.8.18 with SQLite support will be uploaded before too long.

NM Application
In other news, Alexander Wirt finished off my NM Report, so now I’m waiting for the front desk to review it and send me on to the DAM. It’s great to be making progress and a big thank you to Alexander for taking me through the process, testing my knowledge and sponsoring my packages.

Back in January I talked about setting up some scripts to automatically load ssh/gpg keys into the appropriate agents when you plugged in a UBS key. I had quite a number of people ask me for my scripts, but they just weren’t quite ready.

I’m still not entirely happy with the solution that I’ve come up with, but I figure its working well enough to get some feedback now.

It’s based very heavily on the usb-storage script originally written by Sean Finney, so I think that means I owe him Pizza now. However while its based on the usb-storage script it has changed in a few major ways:

• Use udev rather than hotplug
• Support GPG as well as SSH keys
• Script no longer responsible for mounting partition

The mounting of the partition is the key change and I’m still tossing up whether the way I’m doing it is best or whether I should return to having it handled by the script. The primary reason for changing it was to allow the partition to be mounted in a stable location (as opposed to a random directory under /var/tmp) so that I could symlink from appropriate places in my home directory to the partition on the key.

The symlinking is needed to keep GPG happy as the gpg-agent seems to store only the passphrase and requires access to the private key whenever you need to sign/encrypt something. The way ssh-agent works is much nicer in this respect, in that once you’ve loaded a key into the agent it doesn’t need to refer to it on disk again.

Currently I’m using autofs to mount the partition as needed and this seems to be working well. It’s probably possible to go back to mounting the partition at a stable location from within the script without too much hassle.

You can grab the script from http://www.mattb.net.nz/debian/misc/manage-keys

The remaining details for my configuration are below:

First, setup udev to rename the key partitions to a static name and then fire the script at the appropriate times
/etc/udev/rules.d/usbkey.rules

ACTION=="add", KERNEL=="sd?2", SYSFS{serial}="A0494386139B005B", NAME="%k", SYMLINK="usbkeys", RUN+="/usr/local/bin/manage-keys"
ACTION=="remove", KERNEL=="sd?2", RUN+="/usr/local/bin/manage-keys"


Then setup autofs to mount the partition on demand
/etc/auto.master

/media/usb /etc/auto.usbkey --timeout=10

/etc/auto.usbkey

keys -fstype=ext3,ro,noatime,nosuid,nodev :/dev/usbkeys


I keep only id_dsa and secring.gpg on the key and symlink from the appropriate places in my homedir to /media/usb/keys/

matt@argon:~$ ls -l .ssh/
total 76
-rw------- 1 matt matt 612 2006-04-12 22:45 authorized_keys
-rw-r--r-- 1 matt matt 2694 2006-04-12 22:46 config
lrwxrwxrwx 1 matt matt 22 2006-04-13 01:08 id_dsa -> /media/usb/keys/id_dsa
-rw-r--r-- 1 matt matt 612 2006-04-12 22:46 id_dsa.pub
-rw-r--r-- 1 matt matt 58851 2006-04-12 23:10 known_hosts
matt@argon:~$ ls -l .gnupg/
total 2336
-rw-r--r-- 1 matt matt 126 2006-04-12 22:56 gpg.conf
drwx------ 2 matt matt 4096 2006-04-12 23:07 private-keys-v1.d
-rw------- 1 matt matt 1175737 2006-04-12 23:29 pubring.gpg
-rw------- 1 matt matt 600 2006-04-13 01:51 random_seed
lrwxrwxrwx 1 matt matt 27 2006-04-13 01:08 secring.gpg -> /media/usb/keys/secring.gpg
-rw------- 1 matt matt 10560 2006-04-12 23:27 trustdb.gpg


And that’s basically it. The script takes care of the rest.

The main problem I’m having with the script at the moment is that it doesn’t autolock the screen when you remove the key because gnome-screensaver-command is lacking the necessary environment variables to find the DBUS socket it needs to talk to its backend. Need to read up on DBUS/gnome-screensaver and sort out how to fix that tommorrow.

Update: Updated example udev config so it doesn’t run a script out of /home

Miredo is an implementation of the Teredo - IPv6 over IPv4 tunnelling protocol which I have been playing with lately. I have filed an ITP bug to get Miredo into Debian, however this has been delayed while I try and get a handle on some of the patent issues surrounding the Teredo protocol. While Miredo itself is licensed under the GPLv2 the state of the Toredo protocol is less clear.

Teredo was created by Christian Huitema, an architect with Microsoft. It is currently a Proposed Internet Standard waiting for the IETF editor to review it and assign an RFC number for it, IANA will then assign a permanent prefix for use by Teredo clients, servers and relays.

According to the IETF IPR disclosure page, Microsoft has filed a statement of claim against the technologies described in the Proposed Standard. Microsoft states that they will provide a Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers in their statement. Specifically the license that they offer the Teredo protocol under is called the Microsoft Royalty Free Protocol License Agreement. This is a catch-all license that Microsoft uses for all client-server protocols used by Windows. The license itself doesn’t make any claims about Microsoft’s IP rights, it simply gives you a license to use any rights Microsoft may have in the specific protocol you are using. For example at the end of the license agreement you select which protocols you wish to have covered under the agreement. Alongside Teredo you can also choose protocols such as IPv4, DNS, 6to4 and lots of other common protocols.

The actual patent application for Teredo is incredibly difficult to find, the IETF IPR disclosoure doesn’t link to it, none of the proposed standards link to it and googling for “Teredo Patent Application” isn’t particularly successful either. In the end it turns out that the title is quirkily named “Allowing IPv4 clients to communicate over an IPv6 network when behind a network address translator with reduced server workload” and was published as Patent Application 20040190549 on the 30th September 2004.

• USPTO Patent Application 20040190549
• PDF Download of full original application (with diagrams) from the EU patent office - Click the ‘orginal document’ tab, cancel the download window that pops up (unless you only want the 1st page), then select ’save full document’ from the title bar above the tabs and go through the captcha form.

Incidentally if anyone knows of a nicer way to link to a US Patent Application than the ugly URL above, I would love to know.

Half the reason that the Patent Application was hard to find is that it doesn’t actually mention Microsoft anywhere at all, unlike the ~5000 odd other Patent Applications currently filed by Microsoft. From what I can tell it appears that Christian Huitema has filed the application through is own personal attorneys independently of Microsoft.

So where does this leave us in terms of getting Miredo into Debian? The short answer is I’m not entirely sure.

I can’t seem to find a definitive statement regarding Debian’s position on patents anywhere, the best I’ve been able to come up with is a debian-legal post from Andrew Suffield from Jan 2005 which offhandedly describes the informal Debian patent policy as:

“ignore patents until somebody starts to wave them around, then drop the offending thing like a hot rock”

So maybe I’ve already shot Miredo in the foot, by investigating its Patent Status…

My take on the situation seems to be that Debian is perfectly happy (and perhaps has no other option but) to ignore patents applicable to software in Debian until it becomes apparent that a particular patent is being enforced or has the potential to be enforced.

So the question now becomes whether the Microsoft Royalty Free Patent License is acceptable enough to Debian to allow Miredo to be included in main or non-free, or whether it simply can’t be redistributed at all. The main problem I see with the license is that it does not permit you to sublicense other parties to make use of the Toredo technology used by Miredo. If this were a copyright license then that would most certainly fail to pass the Debian Free Software Guidelines, does Debian treat patents in the same manner?

I think it’s time for me to post to debian-legal to seek some “official” guidance on the situation, but hopefully this post has ordered my thoughts enough that I can now write a coherent mail seeking help. If you have any comments or pointers to Debian statements on this sort of situation that I have missed they would be most welcome.

Update - 21 Jun 2006: This post just featured in DWN even though its hardly fresh news! I’ve since updated the scripts to use reprepro, so I would highly recommend you read the updated post. The remainder of this page exists only for historical interest!

Hello Planet Debian :),

Steve Kemp wants a solution to magically build uploaded packages. I maintain several small Debian archives and recently needed a solution like this too. The solution needs to provide semi-automated package builds and installation. The full Debian Archive Kit (DAK) was far too heavy for my needs.

I ended up creating a couple of wrapper scripts around sbuild and debarchiver to achieve this. The basic flow of packages through my archives goes like this:

1. Packages uploaded to an incoming directory (/home/sbuild/incoming/<dist_name>)
2. process_packages script scans incoming directory for each dist every minute and spawns builds (via sbuild) as necessary
3. Once packages are built site admin is emailed build logs
4. Admin checks packages and runs add-packages to add the packages to the archive
5. add-packages invokes debarchiver to do the heavy lifting and then generates the release files.

There is no support for GPG signed packages at this stage, hence the manual check before packages are added to the archive. The scripts were a quick hack a few months ago, and I’ve just hacked them again to pull all the site specific stuff out into easily modifiable variables at the top of the scripts, so hopefully I haven’t introduced any syntax errors! You will need correctly configured sbuild and debarchiver setups prior to running these scripts.

If you want to use them, feel free, I’d love to know if they are useful to anyone but me. If there is some interest I’d be happy to tidy them up, package them properly and maintain them.

Get them from:
http://www.mattb.net.nz/debian/misc/process_packages
http://www.mattb.net.nz/debian/misc/add-packages

I run process_packages from cron with an entry like

*/1 * * * * sbuild /home/sbuild/bin/process_packages &>/dev/null


My /home/sbuild layout looks like

drwxr-xr-x 2 root sbuild 4.0K Jul 31 11:16 bin
drwxr-xr-x 2 sbuild sbuild 12K Oct 26 16:32 build
drwxr-xr-x 6 root root 4.0K Sep 14 12:38 chroots
drwxr-xr-x 4 sbuild sbuild 4.0K Jul 13 09:59 incoming
drwxr-xr-x 2 sbuild sbuild 24K Oct 26 16:31 logs

bin contains the scripts, build contains symlinks to the chroots, and is used as the directory to invoke sbuild from. The resulting .debs are also placed in build. chroots contains the actual distribution chroots, incoming holds a directory for each distribution to process and is scanned by process_packages. logs contains a dump of all the sbuild logs. Debarchiver should be configured to pick up packages out of the build directory.

Let me know if I need to provide more details.

I came one step closer to becoming a Debian Developer today when Alexander Wirt was assigned as my Application Manager. Now I will spend several months working through the NM process with him.

You can keep track of my progress at the follwing URL: https://nm.debian.org/nmstatus.php?email=debian%40mattb.net.nz