On this year’s Chemitzer Linux-Tage (CLT, engl. “Chemnitz Linux Days’) I attended a few talks of which especially formorer’s ikiwiki talk was very interesting. I attended his talk since I found out that ikiwiki is command line wiki compiler in contrary to the thousands of solely web based wikis out there. As a big fan of statically generated content this idea sounded very interesting to me. But just having a short look at ikiwiki’s web page didn’t help to get started and it seemed as if I had not the right idea of how ikiwiki works to get started. So formorer’s talk seemed to be a good possibility to get an idea of how ikiwiki works without much effort. During the talk I noticed that ikiwiki can many things I do with the Website Meta Language (WML), but can do some more things WML can’t do out of the box:

1. It’s not only a framework to generate web pages, it’s more like a content management system (CMS).
2. Versioning is intergal part of ikiwiki without reinventing the wheel: It works out of the box with — beyond others — Subversion, Git and Mercurical (Hg).

And when formorer showed that even Tobi Oetiker uses ikiwiki, I noticed that ikiwiki probably could be a WML killer, since I knew Tobi as a WML fan. And ikiwiki looks very appealing for the WML fan inside me, too… OTOH: Intergrating WML as a backend to ikiwiki could be an interesting idea, though. Hearing what kind of input files ikiwiki can process, I also got the idea of using hnb (Hierachical Notebook) files as input for ikiwiki. hnb files are already XML and so a conversion to XHTML shouldn’t be that hard. But when searching the web for “ikiwiki hnb” I found the blog postings of a few people switching away from hnb, e.g. to vimoutliner. Since I’m an Emacs addict and don’t like vim very much (if I use a vi, I use nvi or elvis), I searched for “emacs hnb” and indeed found someone who switched from hnb to org-mode – of which I never heard before. Unfortunately org-mode doesn’t seem to be in Debian (Update 00:23: Yeah, yeah, I now know it’s included in emacs22, but emacs22 hasn’t made it into kfreebsd-i386 yet, so I didn’t notice. See the comments. :-) but I’ll play around with it a little bit. Unfortunately a first test wasn’t that promising. But we’ll see.

Now playing: Men at Work — Down Under

Finally. With notification implemented I’m able to release the latest and greatest of AcmeCal. At the moment AcmeCal can do notification by either mail or XMPP (aka. Jabber). Still some polishing to do, like having the XMPP plugin test for presence before notifying. Having notification implemeted makes it even more clear that I need to improve the argument handling code. At the moment I’m using this in my crontab: acmecal-notify –type XMPP –from “$(date +”%F %R”)” –to “$(date -d “now + 30 min” +”%F %R”)” This version also brings AcmeCal right at the 1 KLoC-mark and it is now my primary calendar. Download AcmeCal version 0.3 - hey, it works this time

I was a bit surprised when a letter from UEA arrived with a new logo on it. It looks like someone turned up the brightness until the thin parts of the letters started to vanish. IE+1? What's that then? There's confirmation on UEA's wikipedia page which includes the above logo. Ironically, the letter I got looks like it doesn't conform to the linked guidelines. I think this change weakens UEA's links with its alumni a bit, don't you? The old logo was everywhere while I was there. I'm going to miss the square logo with rounded reflex blue letters. Maybe I should stock up on UEA mugs, although a gold-on-blue UEA mug looks a bit wrong.

While most of you people and readers are doing quick and great works in Python, Ruby, or any modern language, there's still people like me fighting with The Low Level. I like that, but the X architecture is just the proof of concept of an architecture which wrongly evolved because it was not designed to. Xlib and all concepts it is based upon where probably fun and sufficient in the 80's, but nowaday, it can really be a joke. I really hope that somedays Xorg will break things and start a new fresh X design (at least from Xlib point of view). It's not that I think Xorg people are doing bad stuff, but there are mostly bailling out from a long code and design history IMHO. So, last weeks I was trying to fix the sloppy focus in awesome. I've found a real interesting Web page from Alex Hioreanu about various issues that we encountered too. I've been trying ahwm hack, but it's not really reliable. And then I've been trying a lot of things, and this morning I figured out something which works pretty well. It just fails in some corner case with GTK+ apps that are not reporting XMotionEvent when the pointer move, and I don't know why and how get them. Let's see.

I just released version 0.26 of Wammu. This release fixes various problems found by users. Full list of changes:

• Various attempts to make Windows version back to usable state, but it is not ready yet as there are quite random crashes in python-gammu on Windows. Anybody with knowledge of python modules on Windows who is willing to help is welcome.
• Dropped GNOME Bluetooth (btctl) support, it crashes too often.
• Fix icons size to be all 16x16.
• Fixed crash when D-Bus can not launch notification service.

There is still no working binary for Windows. I don't have time and environment for maintaining them. Volunteers are welcome!

I first heard about Jon Oxer's home automation setup when he visited Google last year to give a tech talk (heh, that's right, I introduced him). After reading this latest article on his house, I've come to realise that he's implementing pretty much every cool thing I wanted to do when I get around to building the "dream house" (except I'm not too keen to go microchipping myself). The main difference is Jon's actually electronically inclined, whereas I have all the ideas, but lack the ability to go hack them together myself. So many things I'd like to learn, so little time to learn them...

I like autotools, I use them widely and I'm happy that I understand autotools sufficiently that I can be confident in using them and helping others with theirs. All my own upstream C projects rely on autotools and I have a personal rule that I always preserve make distcheck compatibility during CVS/SVN changes and without fail prior to ALL releases.
Lenny will be the second Debian release with which I've been involved and as I prepare to round on the RC bugs once again, I'm noticing a pattern in autotools bugs from other upstream teams.

1. If more upstream projects enforced rigorous testing with make distcheck, a lot of bone-headed numbskull errors would be prevented in the upstream codebase. Fixing make distcheck isn't that hard because it is a test of the build system files, not necessarily the source code. Once an upstream build is fixed, subsequent make distcheck failures are both rare and serious. Other failures in the test suite should be easier to spot too. The important point is that make check only tests the current build on the upstream system. make distcheck goes a long way to ensuring that the package will build in the same way on lots of systems, including cross builds.


2. autotools expects such fixes to be made upstream and fixing things after the release can be a serious PITA, so fix it before release.


3. The single greatest weakness of make distcheck and autotools in general is bit rot. It is so important for upstream to refresh the autogenerated files on an intermittent basis. With a big development team, this can be easy - especially if new people are regularly joining and building the source for the first time from CVS/SVN. Once that rotation stops, the difficulties of trying to fix the upstream code get more and more noticeable. Maybe one day autotools will fix this and become more resistant to bit rot but, for now, it is a significant problem.


4. As a consequence of file rotation, it is seldom a good idea to keep any autotools generated files in any form of RCS, even distributed ones. This is where I fall foul of many who want to package directly from SVN CVS foo. The mantra of lots of RCS helpers is "everything must be in the RCS" which is just plain wrong IMNSHO. The only things that must be in any RCS are the bits that upstream needs to write. So Makefile.am is, Makefile.in is not. configure.ac is, configure is not. Same for libtool, ltmain.sh, config.* and a host of other autotools generated files. If autogen.sh can generate or symlink them, don't have them in RCS. If, as upstream, you have not had to edit the file or copy it into place using a patch supplied by someone else, it should not be in the RCS. This discipline ensures that when someone starts from a fresh checkout, the build system is refreshed (and is why many autotools upstreams add a "make rcsclean" rule that goes one stage beyond make distclean by going back to raw RCS). If you maintain a helper that is meant to build packages like this, ensure that the helper has support for getting from raw RCS to make distcheck and ensure that the helper uses the tarball created by make dist not one of it's own.

Yes, bit rot is the curse of all software but when combined with the lack of usage of make distcheck prior to upstream falling quiet, I sometimes wonder about the merits of trying to fix bugs in the build system of packages with a most recent upstream release that precedes Etch. I get a real chill thinking about upstream packages with a most recent release that precedes Sarge.
So, if you're working on an upstream project using autotools, just do everyone a favour:

 svn cvs  ci -m "make sure things work"

make uninstall

make distclean

./autogen.sh

./configure --prefix=... 

make

make check

make install

make distcheck

Repeat the last stage until it completes without errors, commit the changes and retest from the beginning.
I'm not proposing something I do not do myself - as above, I do these tests on my own (released) upstreams on a regular basis. I just wish more upstreams would do so too. If every upstream did this prior to that final release, it would be so much easier to do all kinds of cool things with your code, long after you lose interest in it yourself.

What's the best way to join a community, any community? Little by little.
I have been working with Ruby on Rails for well over a year already, even given a talk (at Encuentro Nacional Linux y Software Libre ENLi) inviting other people to use this very nice and well thought out environment. But, so far, I've been only a end-user, not really giving anything back besides minor bug reports.
Well, it's not as much as to say that I'm now a contributor - this is just a first statement of intent. I have worked a bit on several bits of code I keep repeating and hand-copying over my different Rails projects. Of course, that's completely not DRY - And completely not nice. So I decided to stop advancing on several projects, and learn my way on stting those bits of code as Rails plugins.
So far, it's been quite simple - and a good excercise on proper separation. I started, of course, with the easiest bit of code I could think of as useful in a general sense, and packaged it up as acts_as_catalog (of course, proper SVN tree and very basic, introductory README. And, of course, as I keep progressing with this work, I'll keep adding some plugins to my currently quite empty RubyForge page.
Anyway... Little by little, time will come where we have to think more seriously on how to properly bring together the Ruby on Rails style to work more tightly with Debian. Currently, the two have such different points of view on how to manage and ship components that I am not sure we will be able to truly bridge them together... But it is definitively worth trying. Hmh, looks like a task for Debconf! ;-)

I had a call last week from one of our customers that a self-managed server had been attacked and email wasn't running smoothly on it any more. The exploited web app (old version of mambo IIRC) had been repaired and there didn't appear to be a shell-gaining exploit, so what was wrong? Looking at the mail queue gave a clue. I couldn't see anything at first. Nothing. No output. Eventually, qmail-qstat returned and reported over 50,000 emails in the queue, which is pretty high for that webserver. Poking around the mailserver found lots of examples of a few types of spam. I stopped outgoing mail so I could clean up. I don't use qmail much. It hasn't been free software for long and the default upstream packaging (which was being used on that server) isn't very friendly IMO. So, I had no idea how to remove messages from a qmail queue, like exim -Mrm or postsuper -d. I looked at the qmail man pages and the qmail binaries. Nothing. I looked at the qmail FAQ. Nothing. I asked a LUG IRC channel. Something, but no answer. With some web searches, I found mailRemove.py - why is this not in qmail and not even a FAQ? No clear contact details on the FAQ, either.

I’ve decided to blog about films whenever there are in my backlog five films I’d like to mention or talk about. I’ll also mention that when I moved to ikiwiki, I set up a films.rss feed, and some other stuff. Now:

• A History of Violence: short and incredible. Has flaws but I still give it 4.5/5. I’ll check more of Cronenberg (I loved, ages ago, M. Butterfly and Dead Ringers).
• Bent: gays, nazis, camp. Intense but not overly rough. Mick Jagger plays a drag singer named Greta.
• Elsa y Fred: terrific love story between two elderly people. Magnificent China Zorrilla. Ignore if you can’t stand romance or Argentinian.
• Martian Child: entertaining, has children and dogs, never ever ever ever ever give up.
• No Country for Old Men: oooh. All my friends hated it and told me: “you are going to love it”. And Bardem really steals the show. More below.

---

You may want to skip this part if you haven’t seen No Country for Old Men, though I won’t be spoiling much. My friends watched it some weeks ago, and I did yesterday (I refused to go with them to a dubbed session). One of them told me that she had disliked it very much because of the uneasiness she got from it, about how human life can result so worthless for people, and so on. Chatting a bit more, we came to the conclusion that I watch these films differently. Basically, I can unplug the empathy off from a film whenever (simplifying a bit) violence or cruelty reaches a certain level, and just consider it an entertainment completely unrelated to reality. Sort of, anyway. And I don’t think I could enjoy (some) films as much if I didn’t. For me, No Country for Old Men had no message in it, and had a single story line: following close the path of a creature portrayed by Bardem, that (maybe not) strangely enough managed to keep me hooked to the screen, not minding the low pace, and finding the end (minus the dreaming bits) very appropriate.

So, sometime over the past few weeks I clocked up ten years as a Debian developer:

From: Anthony Towns <aj@humbug.org.au>
Subject: Wannabe maintainer.
Date: Sun, 8 Feb 1998 18:35:28 +1000 (EST)
To: new-maintainer@debian.org
Hello world,
I'd like to become a debian maintainer.
I'd like an account on master, and for it to be subscribed to the
debian-private list.
My preferred login on master would have been aj, but as that's taken
ajt or atowns would be great.
I've run a debian system at home for half a year, and a system at work
for about two months. I've run Linux for two and a half years at home,
two years at work. I've been active in my local linux users' group for
just over a year. I've written a few programs, and am part way through
packaging the distributed.net personal proxy for Debian (pending
approval for non-free distribution from distributed.net).
I've read the Debian Social Contract.
My PGP public key is attached, and also available as
<http://azure.humbug.org.au/~aj/aj_key.asc>.
If there's anything more you need to know, please email me.
Thanks in advance.
Cheers,
aj
-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
On Netscape GPLing their browser:  How can you trust a browser that
ANYONE can hack? For the secure choice, choose Microsoft.''
        -- <oryx@pobox.com> in a comment on slashdot.org

Apparently that also means I’ve clocked up ten and a half years as a Debian user; I think my previous two years of Linux (mid-95 to mid-97) were split between Slackware and Red Hat, though I couldn’t say for sure at this point. There’s already been a few other grand ten-year reviews, such as Joey Hess’s twenty-part serial, or LWN’s week-by-week review, or ONLamp’s interview with Bruce Perens, Eric Raymond and Michael Tiemann on ten years of “open source”. I don’t think I’m going to try matching that sort of depth though, so here are some of my highlights (after the break).

---

• Starting small: my first package was distributed-net-pproxy, which would claim a bunch of work units which could then be distributed over the local LAN. Useful if you’re in Australia in the mid-90s and being charged by the minute for Internet access. distributed.net didn’t allow general distribution, so I asked for (and received) explicit permission to include it in Debian. (distributed.net had a ten year anniversary last year too)
• Diving straight in: I got sucked in to the mailing lists pretty quickly, and within a couple of months was up to my neck trying to redesign the way we did releases; oddly enough that didn’t turn out quite so easy, but at least it ended up with some concrete proposals within a couple of months, pretty much synchronously with the hamm (2.0) release going out (and, I guess, about a year after I’d started using Debian…). At around the same time was, I think, my first recorded comment about trade offs regarding freeness…
• cruft: My first bit of Debian specific code was cruft (that its name, not it’s value…), which worked okay as a prototype, but got snagged up in debian-policy trying to get packages to make a note of files they’ll put on the system without telling dpkg (eg, /etc/passwd, /var/cache/apt/archives/*.deb, etc). That pretty much sapped my interest in it, and cruft stagnated until Marcin Owsiany picked it up in 2005.
• Played for a sucker, part one: a few months later I was messing around doing QA stuff and fixing bugs and as part of that did an NMU of netbase (which at the time directly contained all sorts of important tools like ping and inetd directly). That went something like:

  From: Anthony Towns
  Date: Sat, Nov 21, 1998
  There are a few bugs accumulating against the netbase package which
  you're maintaining. I was wondering if you'd mind if I made an NMU
  to fix some of them for the upcoming slink release?
  

  From: Peter Tobias
  Date: Sat, Nov 21, 1998
  No, please go ahead ... I'm quite busy right now and I would really
  appreciate any help. Please let me know if you need additional information
  about the package.
  

  From: Anthony Towns
  Date: Sun, Dec 6, 1998
  There's an NMU sitting in Incoming now. It fixes a few bugs, viz:
  [...]
  

  From: Peter Tobias
  Date: Fri, Dec 25, 1998
  due to my current job I don't have much time to work on my debian
  packages. In order to have more time for my other debian packages
  I would like to give away the netbase package. Are you interested
  in maintaining this package?
  

  From: Anthony Towns
  Date: Fri, Dec 25, 1998
  Ummm. Sure. I guess. (or, iow, *Eeeeeeeeeeeeek*!!!)
  
  

• ifupdown: As part of maintaining netbase I tried to figure out a way of fixing bugs like 31745 and 39118. Basically, Debian used to do networking by generating a script on install that you could modify by hand, and that was it – so when the commands needed changed between 2.0 and 2.2 (no more “route add -net”), you couldn’t make that upgrade “just work”. Red Hat handled it with “ifup” and “ifdown” commands that would look at a whole bunch of shell-format variables in /etc, which worked but wasn’t elegant, so I came up with something I thought was actually pleasant. It’s fundamental attitude is to be a parser – the networking commands are specifed as compile-time configuration, the description of your network is your runtime configuration, and ifupdown just puts those all together without trying to actually understand what’s going on. To some degree, that works really well – it keeps all the knowledge separate so when you’re writing an /etc/network/interfaces, you’re not worried about how DHCP works; in others it breaks down – in particular if bringing up an interface fails part way through, is it up, or down, or something else entirely?
• bugs.debian.org: I’m not entirely sure why, but in August ‘99 I decided to start running a script to stop old bugs from being permanently deleted:

  From: Anthony Towns
  Subject: BTS and old bugs
  Date: Tue, 24 Aug 1999 22:33:16 +1000
  To: debian-private@lists.debian.org
  ObPrivate: Erm. I'm not sure. It is only even vaguely relevant to
  developers.
  Since bugs #9705 and #36727 don't seem like being fixed any time soon
  and Darren hasn't managed to convert the BTS to using debbugs.deb yet,
  I've made a little script to stop us from continuing to lose bug
  reports, and am running it in my crontab on master.
  ~ajt/debian-bugs/archive/ contains hardlinked copies of the bugs in
  ~iwj/debian-bugs/spool/db (except split into sub-directories). When
  the bugs get expired from the BTS, the hardlink in ~ajt remains, so
  the file doesn't get lost forever.
  In the week or so I've been running it, some 500 odd bugs expired [0].
  

  Next month I sent Darren Benham a first version of bugreport.cgi, and at some point around then must’ve sent off a pkreport.cgi too; by the month after (October) I’d evidently been added to the debbugs group, because I was merging my archived bugs into the official debbugs directories.
• testing: So a year and a bit later and there had been some more discussions about making major changes to our release process, and since I’d done some more algorithms subjects at university by this point, dove in a bit more seriously. For me, the main challenge seemed to be keeping dependencies consistent, and it turns out validating dependencies and conflicts is an NP-complete problem, and solving that reasonably efficiently seemed like a good first step. By October ‘99 I’d come up with a first pass solution, which I think was still in Perl at the time. A couple more rounds of playing with consistency checking stuff ensued, resulting in some regularly updated lists being generated by December, and by March 2000 or so that had graduated to a simulation of testing as we know and love it today.
• Played for a sucker, part two: so after a few months of maintaining a testing suite while potato (Debian 2.2) was getting finalised for release I figured it’d be useful to get broader release experience, so asked Richard Braakman if I could help out with the last bits of the potato release. At which point he said “sure”, gave me James Troup’s email address for accepting/rejecting packages etc, then buzzed off to a mobile phone related junket in the US, and laid low until the release was actually out… A cunning plan, for sure. Happily, that didn’t take too long – I think I started around June, and potato was finished baking for release at LinuxWorld Expo in August, though it did involve about 2000 lines of archive changes and stuff mailed to James over the period, along with half a dozen mails to -devel-announce.
• Junket: In the middle of that was my first ever debconf – or technically the Debian portion of the 2000 LSM/RMLL in Bordeaux, aka Debconf 0. It was awesome – met heaps of cool people, got to practice my high school French, and enjoy some lovely red wine while gossipping about free software. Also heard RMS sing the free software song live. But the wine was great!
• katie/dak: The biggest problem with the “simulation of testing” mentioned above was it was held together with paperclips and sticky-tape; or less metaphorically, shell one-liners and hardlinks. Since packages would originally get uploaded to unstable, and then move into testing, and then get deleted from unstable, you’d end up at least doubling the bandwidth required to mirror Debian, because each package would get sent to mirrors once for unstable and once for testing. Which is fine for a simulation, but for deployment, well, we needed package pools, which in turned required a rewrite of dinstall. James did all the initial work, apart from some of the schema design and the scarier SQL, and by November had it deployed for the non-US archive, and got it onto ftp-master in December. At which point the time was ripe for hooking up testing into the archive proper, which is about the point that the testing scripts got named “britney” so as to fit in with all silly names in the da-katie suite. I’m pretty sure the rationale was that I did the final coordination of the potato release (archive changes, cd images, announcement, etc), I spent from about 3am to 10am listening to a handful of Britney Spears songs on repeat. The phrase “scarred for life” might come to mind. Since that point, there’s been lots of evolutionary changes to both dak and testing (including a rewrite of the perl parts of testing into python), but it’s all built fairly naturally from that point.
• debootstrap: I’m pretty sure my motivation for writing debootstrap was a mix of just wanting to avoid having to worry about out of date base tarballs for the purposes of keeping testing in-sync, and wondering if it was actually possible to write a script to bootstrap a Debian system from the sort of minimally functioanl environment the installer has to put up with. In the end, it turned out pretty cool – it was used by the final boot-floppies, it’s part of d-i, it makes tools like pbuilder possible, I think it helps embedded folks heaps, it’s spawned some imitators, and generally been a pretty cool exercise in hackery.
• Freedom and purity: About six months earlier, there was a big flamewar and an attempted vote on whether to remove non-free from the archive. I’d written a rebuttal and counter-proposal, but it all ended up collapsing in a heap, due to disputes about the constitution. For some reason I feel like this mail was more interesting than all the previous ones combined… That ended up needing a whole bunch of changes to the constitution: one to make it clear under what circumstances the social contract can be changed, and another on what happens when one option on a vote requires a supermajority while another doesn’t, and working that out ended up taking from October 2000 until October 2003. It was actually kind-of interesting; trying to analyse a good voting system that works in the real world has all sorts of interesting maths to it, and there’s a whole bunch of election methods guys that have studied it in a bunch of depth. And since its elections, you can have fun with all sorts of scenarious of corruption – like what if the secretary’s trying to change the results. In practice, the difference between good and bad election methods seems to turn out to be negligible, but why wouldn’t you have the best one you possibly can? A couple of months after those changes were done, dropping non-free got reproposed, and I did another counter-proposal; this time they were actually voted on, with the counter-proposal winning, by a little under a two-to-one margin. Which means we get to get rid of non-free by making it completely superfluous, rather than just near enough.

Hrm, this is going on longer than I’d hoped. Oh well, to be continued!

I've been re-reading RFC 2822 again over the weekend, for obvious reasons, and I'm amused I've not noticed this section in the past:

3.6.5. Informational fields

The informational fields are all optional. The "Keywords:" field contains a comma-separated list of one or more words or quoted-strings. The "Subject:" and "Comments:" fields are unstructured fields as defined in section 2.2.1, and therefore may contain text or folding white space.

subject  = "Subject:" unstructured CRLF
comments = "Comments:" unstructured CRLF
keywords = "Keywords:" phrase *("," phrase) CRLF

Now we all know that emails have subjects, but how many people have ever used the Keywords: header, or the Comments: one? It'd be nice if we could use these fields in mails - I can immediately think of "keywords" as tags, and I'm sure I'm not alone. I've looked at multiple "tags for mutt" systems, but all of them fall down for the same reason. I can add tags to a mail, and limit a folder to those mails that contain a given tag. But I cannot do that for multiple folders and that makes them useless :( Has anybody worked on a multi-folder tag system for Mutt? If so pointers welcome. If not I'd be tempted to create one. I guess implementation would be very simple. There are three caeses:

• Adding a tag
• Deleting a tag
• Finding all messages with agiven tag.

The first two are easy. The second could be done by writing a cronjob to scan messages for Keyword: headers, and writing a simple index. That could then be used to populate an "~/Maildir/.tag-results" folder, via hardlinks, of all matching messages. Better yet you could pre-populate ~/Maildir/.tag-$foo containing each message with a given tag. Then theres no searching required! (Although your cronjob would need to run often enough when the tag were added to a message it would appear there within a reasonable timeframe. Update: I've written the indexer now. It works pretty quickly after the initial run, and is quite neat! tagging messages with mutt.

From the start of the DebianEeePC project, we have used a combination of the irc channel and our wiki site to our great advantage. The DebianEeePC/HowTo/Install document has been actively maintained as we go, serving not only as a good reference for new users, but also for existing users and developers to see where improvements are being made and what is left to work out. Recently, we’ve started using the wiki for task management as well. Patterned after DebianInstaller/Bugs, we now have DebianEeePC/Bugs where we link to reports on the BTS for packages we maintain and our own usertags on packages we don’t maintain. As well, we are keeping a DebianEeePC/Todo to manage our tasks. I see from a search through the wiki that lots of other Debian subprojects keep Todo lists, but most of them have little more structure than point-form lists. A few, though, have structured these pages a bit more carefully. For instance, some of these use tables listing who each task is assigned to, when it was assigned, and when it is completed. Our point-form list is a bit more free-form regarding task assignments. Participants can register their interest in a given task and what they are doing as a subpoint of the task. As for state changes over time, we rely on the revision history on “info” page for people to be able to see state changes for particular Todo items. When something is done, it just gets dropped from the list. I haven’t exhaustively reviewed everyone’s Todo page, but from my brief survey I haven’t seen a couple of things I’ve added to try to help people choose what to do next. The first is to tag items with six difficulty/importance pairs, rating each actionable item from Easy/Urgent to Hard/Wishlist. The second is to state dependencies between items using anchors. It would be nice to see any of you are doing something similar and hear about whether it has worked out well for you. I’m happy with how the irc/wiki combination has helped with project management. In the past with a different project I’ve made an abortive attempt to use the task management system at Alioth, but it just seemed too cumbersome and nobody ended up using it. With the wiki, it appears barriers to participation in task management are sufficiently lowered that everyone is willing to help keep it up. And with irc, we can keep on top of defining and assigning (or more usually volunteering to do) various tasks, and making sure the wiki is kept completely up to date. It takes a bit of discipline to do, but after the habits are established, it gets easier, and the rewards are well worth it.

So today is the third anniversary of my first upload of the ISC DHCP v3 package to Debian. It all started back in the days of the linux.conf.au 2005 organising committee. Bob Edwards, who ran the ANU Department of Computer Science computer labs (which ran on Debian at the time), was constantly complaining about bugs like #286011, once he'd found out I was a Debian developer. So I figured I'd try and do something about it, so I think I emailed the maintainers, who had been fairly inactive (the last upload before mine was in July the year before), and asked if they'd like me to NMU the package. I think Matt Zimmerman emailed me back and told me to knock myself out, and add myself as an uploader while I was at it, and well, the rest is history... I've had fun fixing bugs, trying to clean things up, deal with a pretty archaic upstream build system and get the package up to current Debian standards compliance. One of the highlights was being able to finally get rid of Debian Installer's dependence on the v2 DHCP client package, so we could finally jettison the v2 packages for Lenny (which reminds me, I still have to figure out how to handle the transition from Etch with respect to that). I've been working hard to try and get as many of the patches in Debian's DHCP packages incorporated upstream. Unfortunately, they have a totally unpredictable release cycle, and they have feature releases and bug fix releases. The feature releases are very few and far between, and they won't introduce new features into a bugfix release. Speaking of patches, my personal philosophy is that distribution packages shouldn't differ radically in behaviour or functionality from their upstream source, so I've resisted incorporating some of the more deviant patches from Ubuntu, instead forwarding them directly upstream. There's still a bit of work to be done with the package. The ISC released version 3.1.0 a while ago, and that's the version I'm trying to standardise on for Lenny. It's got new support for a domain-search option, which means people can stop abusing the domain-name option to set a domain search list in their clients. The domain-search option is also honoured by Mac OS X (Leopard), and I dare say Windows Vista probably supports it as well, but I haven't checked. Unfortunately the client-side support for the domain-search option is a bit flaky in 3.1.0, so I'm hoping the ISC will release 3.1.1 real soon now, as I believe most of the flakiness issues are addressed in it. Of course, for Lenny to do the right thing consistently with this new option, #460609 and #465158 need to be resolved also. The last thing I'm trying to sort out for Lenny is the reasonably in-demand LDAP patch. It's been floating around out-of-tree for longer than I've been maintaining the package. Jos L. Redrejo Rodr guez has been kind enough to clean up the patch for me, so that rather than bastardising the standard DHCP package to build a dhcp3-server package that has LDAP support, it basically builds DHCP twice, once with the patch and once without, and the dhcp3-server-ldap package just diverts /usr/sbin/dhcpd3 out of the way and plonks in the LDAP-enabled binary in its place. I hope to upload a new revision of the package that builds this new binary package within the next week (hopefully this weekend). After that's done, and hopefully 3.1.1 has been released, and Lenny is out of the way, I'm going to focus on transitioning away from a versioned set of DHCP packages. The whole "3" in everything was to allow the v2 and v3 packages to coexist. I've sought advice from the release team about this, and they said not to bother, but it feels really gross to have the version 4 package (4.0.0 has been released by the ISC for a while now as well) be still called dhcp3, and to install into /etc/dhcp3 and other such versioned directories. The final thing I want to look into is collaborative maintenance. I've been wanting to do this for a while, but I wanted to get the package into a revision control system (shock horror, it's not currently) and I've been baulking at how to do it the "right" way. I'm pretty sold on using Git for the revision control system, I just haven't figured out the right approach yet. Martin Krafft's articles about it have been interesting, but feel a bit overly advanced, and don't quite suit my situation. I've been hesitant to start using Git, then discover I've done it all wrong, and have to start again. I need to just bite the bullet. My upstream also doesn't use Git, and doesn't make their revision control system publicly available, so I just get the tarballs when they're released. Speaking of upstream, I made the discovery last year that they're just down the road from me in Redwood City, so I've been trying to improve relations by getting the main folks who work on DHCP at ISC to pop up to Google for lunch every now and then, which so far has happened twice, and been good a opportunity to have a chat. In fact, they're keen for Debian to join the DHCP Forum (Debian is already a member of the BIND Forum) and I think they've started talking to the Debian folks responsible for our BIND Forum membership about extending that to cover the DHCP Forum as well. So that's about it. I think after three years of being the sole uploader, I'll formally put myself in as the maintainer and Eloy as an uploader until I get around to implementing collaborative maintenance.

There are communal elections in my region this weekend.I'm a supporter and member of the Greens. Please support us by voting for us.Don't vote for CSU. Ever. Just think of what they've been doing towards spying on citizens, data retention and such. They fight against your freedom by blaming the "terrorists".We could use up to 20% greens, and there is no way we're going to reach that anytime soon. So it's save to vote for the Greens. Even with your vote, they'll probably just reach 10%, and that definitely is a good thing for democracy. Nobody is talking about the Greens becoming the strongest party, you know... but we could use more Greens than we currently have in the parliaments. If we have 4-5 reasonably strong parties and changing coalitions, that helps fighting corruption.

There are communal elections in my region this weekend.I'm a supporter and member of the Greens. Please support us by voting for us.Don't vote for CSU. Ever. Just think of what they've been doing towards spying on citizens, data retention and such. They fight against your freedom by blaming the "terrorists".[Yes, I am aware that these topics are national, not communal topics. But in communal topics it's the same thing. CSU wants to waste billions of money on a train which is 10 minutes faster at the airport, and which nobody is going to use because it's quite a bit more expensive. The money could be used for much better purposes, but I guess they owe some construction companies ... It is a fact that they have introduced study fees, despite the need for more high-qualified people; they should be putting more money into our universities instead of driving people away from higher education.]We could use up to 20% greens, and there is no way we're going to reach that anytime soon. So it's save to vote for the Greens. Even with your vote, they'll probably just reach 10%, and that definitely is a good thing for democracy. Nobody is talking about the Greens becoming the strongest party, you know... but we could use more Greens than we currently have in the parliaments. If we have 4-5 reasonably strong parties and changing coalitions, that helps fighting corruption.

About a week and a half ago, I had to call in to work. The conversation went about like this:

Me: I'm going to be a little late today. I'm stuck in the mud, but I'm still on the road.

Other end: (Laughter).. *ahem* I'm sorry, but that sounded really funny.

From our house, we can take either the south road or the north road to lead to the highway. The north road always has at least some rock or sand on it. The south road is just dirt. And at the corner where it meets our road, it's dirt in a flood area with lots of trees around it. Meaning that is is often impassible.

But the south road saves me 1.3 miles each way on my drive in to work. So I like to take it when I can.

Lately we've had moisture, but since it's winter, the mud and water on the south road freezes overnight sometimes. Generally I figure that if the mud all over on our own yard is frozen, it's safe to take the south road.

Last week, our yard was frozen. The mud was solid and there were patches of ice. So I started heading towards the south road. I got to the corner, and there was ice and solid-looking frozen mud. So I went ahead. And promptly fell through the ice and landed in the water -- and mud -- beneath it.

Not good. I figured I'd try to get out of it. I actually was able to move the car, and got to within 5 feet of the solid ground, but there was just no going past there. So I called a neighbor with a tractor, and called in to work while he made his way over. He wasn't sure if he wanted to pull our car out from the front, so, due to his location, he had almost a 3-mile tractor drive.

Meanwhile, I worked to get the car as far back as I could. He pulled me out with no problems. I offered to pay, but he wouldn't accept anything. I stopped at home for a quick change of clothes and shoes (I had hopped out in the mud to try to find any sort of debris or something that could provide better traction), then went in to work -- only an hour late.

I got several comments from co-workers. And some "helpful advice" regarding which road I ought to be taking for the next few days. All in good fun, of course.

Terah and I always knew it was just a matter of time before something like this happened.

So, finally, it has. What a relief!

Terah made some buried cherry cookies for me to take over to our neighbors that weekend as a thank-you. He's been pulling people out of that corner for decades, and from the sound of it, I'm just about the most boring one yet.

Every year on Good Friday, our church choir joins with the other church choir in the area for an evening choir program.

This year we are performing The Seven Last Words of Christ by Theodore Dubois. It's a challenging and beautiful piece. We'll have our combined choir, plus pipe organ and various other instruments.

Easter starts with a sunrise service, then breakfast at church. During the service, we'll sing a number of additional songs. I think the list includes The heavens are telling by Haydn, Ave Verum (KV 618) by Mozart, Love Is Come Again arr. by Parker & Shaw, Praise the Lord by Handel, Alleluia (from Veni Sancte Spiritus, K 47) by Mozart, and Thanks Be to Thee by Handel.

It's a lot of fun to be in the choir, and also quite a joyful time. I'm looking forward to Easter.