Nearly a month has elapsed since Debian released Lenny. The interesting thing for me about this release was that I failed to get to the point where running etch was causing me pain. This became even more evident when Katherine commented on my Lenny T-Shirt - I'd forgotten to mention our release to her! Previously there have been a bunch of features coming that I really wanted, sometimes to the point of using backports. It's probably something to do with the way I run Debian; I use stable for remote machines and while in the past this would have meant quite a few work boxes these days it's just a box at my parents' and my colo. Where I felt the pain during this release cycle was on the boxes where I run unstable (my home desktop) or testing (my work box and my laptops). Development on new shininess slows down significantly while we're preparing for release (not unsurprisingly). And there are things coming up I quite like the look of, largely aimed at the desktop arena. I've been running Network Manager 0.7 from experimental on my EEE, for example - I need the HSO 3G support to avoid unnecessary faff on a daily basis. I've got ATI cards in my work and home desktops, so I'm watching the Mesa developments with interest - roll on OpenGL 2.0 support hopefully. The Intel KMS support that doesn't seem to be quite there yet but RSN, no, really, will be nice for my laptops. Experimental VDRs are looking interesting and perhaps worth upgrading my PVR to.

For a long time I haven't really understood the point of view that Debian shouldn't release. Or rather, I haven't understood why people would think that was a serious option. The first Debian box I installed went into a colo facility shortly afterwards. This is the first release I've not been running Debian on a commercial colo box and while I treat my personal colo in a similar fashion it's not quite the same in terms of priorities. However I still think regular releases are hugely important to the project. Some pain for those of us more interested in new shiny is a small price to pay for producing a flexible, reliable distribution, be they server administrators (though I see a worrying number of people decide to install testing on their production servers and then rarely/never update it), derivers or appliance vendors.

Mind you, now we've released I'm going to have to do all those things I've been putting off. I should probably start with moving my Perl bits into pkg-perl. And maybe I should switch over some sources.list files to point at squeeze instead of lenny...

Yesterday was my birthday, and it was full of cookies, pies, magical pixie dust and things made entirely of sugar and spice! The remainder of the day was spent re-installing Debian Lenny upon my EEE PC - Somehow I managed to completely screw the system. Because the EEE PC is one of those ultra-portable machines I mostly used it when I was travelling, or outdoors. That mean I was generally receiving poor connectivity and the system packages weren't up to date. While I was in bed I figured I'd dist-upgrade it to the recently released Lenny. Unfortunately I started the dist-upgrade inside X.org, once I realised this I figured I'd cancel the operation via Ctrl-c. Bad news everbody: I think I was unlucky enough to interrupt an upgrade of libc, or something equally critical. Every single application gave segfaults afterward. I had two open root terminals and I could navigate around via cd .., and "echo *", but all other commands such as sudo, dpkg, strace just gave segfaults. (Even static commands gave errors - so it might have been the dynamic loader that was borked, I admit I didn't look too closely.) I figured reinstalling would be a good solution since the machine has a 4Gb root partition and /home was stored on a separate 16Gb volume. Unfortunately I managed to misjudge the installer's partitioning step and nuke the partition table on the external volume so I ended up losing the whole system. Happily reinstallation was a breeze as my home network is setup to allow installation via PXE network booting (at some point I should document NFS-root PXE-booting). It took me longer to fiddle with the BIOS on the EEE PC to allow network booting than it did to complete a minimal install. Which I guess is good. I still need to restore my backup of /home/, but that can wait a few days. Right now I'm loathe to touch the machine at all - although I did distract myself by getting KVM to PXE boot:

# create 4gb disk image
dd if=/dev/zero of=/tmp/img.img bs=1024 count=4096k
# launch KVM
sudo kvm -no-acpi
  -boot n -tftp /var/lib/tftpboot/ -bootp /pxelinux.0
  -hda /tmp/img.img
  -net nic,macaddr=00:0E:35:be:de:ad  -net user

It seems that KVM wants to have access to the local TFTP root directory so I just pointed it at that. Since my desktop machine is also my TFTP + DHCP host that works out nicely. (A quick scan of the manual suggests that QEMU/KVM has funky built-in TFTP code, so it doesn't actually forward TFTP requests over the network.) DHCP requests were certainly passed around as expected though and were answered via my local dnsmasq installation. I did see errors at every DHCP request in syslog, but they seemed harmleess enough:

gold dnsmasq[29241]: no address range available for DHCP request via qemu0

*shrugs* ObFilm: Never Been Kissed.

position:fixed in Android Webkit Good news for mobile web developers! In the latest development build of Android ("cupcake"), WebKit supports iPhone touch events and CSS3 animations/transforms. This means that Richard Herrera's iPhone fixed positioning hack will soon work Android too. The WebKit CSS Animation demos also work, but lack of hardware acceleration in Android makes them painfully slow compared to the iPhone.

Samba.grep.be, my main server (which occasionally also hosts a domU for p2) was upgraded to lenny this monday evening. I wish I could say there were no issues, but unfortunately that's not true. At first, everything seemed to run smoothly; of course I did have to recompile a few locally written programs to run against some SONAME changes (programs that are too trivial to package, really, and too ugly too), but other than that, everything was fine. It went wrong sometime during the night. Apparently something didn't like the new kernel or the new xen, because everything started to lock up. Since I only noticed this when I was at a customer the next day, I couldn't fix it until I got home again in the evening (meaning, downtime for a full day); and unfortunately, the exact failure mode meant that not much was written to the log -- certainly not enough to figure out what went wrong:

Mar 10 04:04:41 samba kernel: [ 7033.011523] INFO: task cron:21006 blocked for more than 120 seconds.
Mar 10 06:43:46 samba kernel: [ 7033.011614] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 10 17:35:04 samba kernel: [ 7033.011701] cron          D 7fffffffffffffff     0 21006   4147

After that, nothing before the reboot, which happened at around 21:00. Take good note of the timings on those messages, and the apparent discrepancies between the syslog timestamp and the kernel timestamp. 7033 seconds after boot was around 3:30 AM... When I arrived at the physical server, this kind of message was rolling over the console several times a second, with just the name and PID of the blocking process changed. And with several more lines following the message, of course. As a result, the system was not responsive at all. I didn't file a bug since, frankly, there's so little information that I wouldn't even know what to file a bug against (the kernel? Xen? Some rogue process that runs as root and changes settings which cause a driver to block? I wouldn't know). Instead, all I could do was to reboot the server and hope for the best. Not that I like that kind of situation. Fortunately, the problem didn't reproduce itself today; here's for hoping that it never will.

Certain amount of hyperbole, but still a great perspective on software-as-a-service vs service-as-a-service in Iceland. Microsoft Skull-fucks Iceland s Economy, Contracts Syphilis Entertaining too :)

It took us a couple of weeks to organise, but we had a small Lenny release party in Cambridge last weekend. We had the usual crowd of Cambridge folks, plus Noodles and codehelp. Jason Clifford from UKFSN even threw some cash our way to help cover the costs - Thanks Jason! :-) We started at the Regal pub in town, then headed back to my place and drank until late. Quite a number of the revellers also bought some of our shiny new Lenny release T-shirts! If you'd like one, look at the details here and mail me! Update: Fixed the URL to the T-shirt photo. Doh!

If you are managing a Free Software project, you may eventually be confronted with a security vulnerability. Normally bugs in the Open Source world are discussed in a transparent way on public forums. In the case of security bugs however, there are benefits to temporarily withholding these details from the public.

Some people describe this approach as responsible disclosure. It boils down to this:

if the vulnerability is not publicly known, warn the vendors first and give them some time to fix it before making the details public.

If the vulnerability is already public knowledge, then you can focus on fixing it as soon as possible and maybe let reporters know about a better way to report their findings.
Sample Security PolicyHere's the procedure we now follow in the Mahara project for security bugs we found ourselves or which have been privately disclosed to us through security@mahara.org:

1. Figure out the extent of the problem: which versions of Mahara are affected by this problem?
2. Fix the problem on all supported branches of the project in a private source control repository.
3. Share the vulnerability information with vendor-sec and request a CVE identifier.
   
4. Prepare release tarballs and packages.
5. Draft a security advisory for the Security forum.
6. Wait until the embargo date to push the release out.
   

Emails to vendor-sec should include:

• a description of the problem
• any proof of concept code demonstrating the vulnerability
  
• the list of affected versions
• any patches you have prepared
• a proposed embargo date

Benefits of properly handling security bugs
First and foremost, it protects end-users by giving them a chance to download and install fixed versions of your software before widespread exploitation of the security flaws.

Secondly, it may increase your project credibility. While you are admitting that your software has flaws, you are also demonstrating that your project is committed to dealing with the most serious ones promptly and in a responsible manner.

Finally, sharing security flaws and having your fixes reviewed by a select group of experts may reveal extra vulnerabilities you missed while preparing your patches. This gives you an opportunity to improve your fixes before they are released and to avoid having to issue yet another security advisory a few days later.

Big thanks to Steffen Joeris for his help in shaping the Mahara policy!

OK, so after a lot of dithering I finally decided that I wanted to stand again for re-election in the DPL election this year. That's despite the fact that it's not good for my health and I don't have enough time to start with... Why am I doing it?

• I believe I've done a good job in the last year, and lots of other people seem to agree. However, I did not find the time for all the work I hoped to do and I think it's worth carrying on.
• I've been pestered to stand again by a lot of my friends in the project.
• I wasn't going to let Zack stand unopposed! *grin*

To make the job easier this year if elected, I'm standing with Luk Claes as an assistant. He and I are good friends, and we share ideas and values on a lot of points. My experience from the last year as DPL tells me that the job is a big one, and sharing the load with a willing victim^Wvolunteer should help with that.

I have recently configured my mail server to use IMAP. I started doing this when I was attending Linux.conf.au so that I could read urgent mail using my EeePC while at the conference and then be able to deal with the more complex stuff using my laptop later on. The next logical step is to have mail delivered to different folders in the IMAP account. While there are ways of doing this via the Subject and other header fields, my needs are not that great. All I need to do is to support user+extension@example.com going to a folder named extension in the user s mail store. While changing my mail server I decided to install Postfixadmin at the same time. My first attempt to use Maildrop was to put the following in the /etc/postfix/main.cf file:
mailbox_command = /usr/bin/maildrop -d mail -f $SENDER $DOMAIN $USER $EXTENSION That seems to only work when you have local accounts, so I ended up setting fallback_transport = maildrop and then putting the following in /etc/postfix/master.cf: maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/bin/maildrop -d vmail $ nexthop $ user $ extension Where vmail is a Unix account I created for storing mail. Then I added the following to /etc/postfix/main.cf. Some of these are probably redundant (such as the virtual_mailbox_base). The recipient limit is set to 1 because there are no command-line parameters for maildrop to support two recipients for the same message.
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_gid_maps = static:2000
virtual_uid_maps = static:2000
virtual_mailbox_base = /mail
vmaildir_destination_recipient_limit = 1
virtual_transport = maildrop
maildrop_destination_recipient_limit = 1
The files /etc/postfix/mysql* all have fields user=, password=, hosts=, and dbname=. The queries in each of the files are as follows:
mysql_virtual_alias_maps.cf:query = SELECT goto FROM alias WHERE address='%s' AND active = 1
mysql_virtual_domains_maps.cf:query = SELECT domain FROM domain WHERE domain='%s'
mysql_virtual_mailbox_maps.cf:query = SELECT maildir FROM mailbox WHERE username='%s' AND active = 1 The /etc/courier/maildroprc file has the following contents: # log the maildrop actions
logfile "/var/log/maildrop.log" # parameters 1, 2, and 3 are the domain, user, and extension
DOMAIN=tolower("$1")
USER=tolower("$2")
EXTENSION=tolower("$3")
DEFAULT="/mail/$DOMAIN/$USER" # try making a backup (cc) copy of the mail but do not abort if it fails
exception
cc "$DEFAULT/.backup/"
# try delivering to the extension folder but do not abort if it fails
exception
if(length("$EXTENSION") != 0 && "$EXTENSION" ne "backup")

to "$DEFAULT/.$EXTENSION/"

# deliver to the main inbox if there is no folder matching the extension or if no extension is specified
to "$DEFAULT/"
Installing Postfixadmin [1] was another challenge entirely. One of the complications of this is that there is no Debian package for Lenny (it seems that there will be one in Squeeze - Lenny+1). I found David Goodwin s tutorial on installing Postfixadmin and lots of other things on Debian/Etch [2] to be a very useful resource. I look forward to seeing a Lenny version of that document. Please let me know if you can think of any way to improve this.

• [1] http://postfixadmin.sourceforge.net/


• [2] http://codepoets.co.uk/postfixadmin-postgresql-courier-squirrelmail-debian-etch-howto-tutorial

Today got asked by a colleague, who wanted to throw away the early history of his repo. git allows you easily to rewrite the history start with:

echo $FIRST_SHA >> .git/info/graft
git filter-branch -f

Then with interactive git rebase you can rewrite this important initial commit. Of course you have to define $FIRST_SHA and your repo shouldn't be dirty.

Once your new Free Software project has had some traction and is gaining users, you will probably want to supplement its initial homepage with a few extra services. However, the most important aspects of managing a Free Software community have more to do with relating to human beings.
Social Interactions in Small ProjectsIn the early days of your project, support requests usually only come in through personal emails to the lead developer. In order to build your community, make sure new users feel welcome:

• Be friendly and informal in your responses. Feel free to use the person's first name at the beginning of your emails.


• Be responsive to feedback and request for help. Most Free Software developers are quite busy so this is about letting user know that you'll get back to them or thanking them for their suggestions/feedback. Very few people take the time to contact authors to let them know about the problems they run into. It's important to be supportive of the ones who do.
  


• Be calm when responding to negative feedback. It helps to take a full day to cool off before sending a reply. Thank users for writing to you, but remind them that you are not getting paid to work on this project and that you are doing this for fun in your spare time. Some users seem to forget this.

But of course, remember that the main job of a developer/maintainer is to make the software better. Keep this in mind when replying to support requests and allocate your (limited) time accordingly.
More Tools for Growing ProjectsAs your project grows and handling user-reported issues start becoming more of a burden, consider two things: documentation and distributed support.

The obvious place to start documentation-wise is to start collecting responses that you send to users who get in touch with you. This is the original meaning of a FAQ: answers to actual questions sent in by actual users. Fill your FAQ with irrelevant questions and users won't bother reading it and will email you instead.

In addition to providing good documentation, you should also think about creating a mailing list or a forum where users can post their questions (Google Groups provides a nice blend of the two technologies). There are two main advantages to this service:

• the support load is distributed across other users of the software
• questions and answers are archived by search engines

As your project grows even bigger, you will probably also want to look into getting a bug tracker and a wiki.

Have a look at this excellent online book for more ideas.

This release had more annoying globalish changes than any release that I remember recently. There were lots of little changes across all files, lots of internal reorganization, and lots of tweaks and little changes to match behavior changes elsewhere in the infrastructure. It's all movement towards a more maintainable code base, but it's not as much fun as fixing lots of bugs. This release should fix the occasional problems that people saw with checking source packages (sorry about that, my fault) and somewhat faster performance due to a bunch of work by Raphael Geissert. It also incorporates changes from debhelper 7.2.3, including removing the requirement that one call install-docs and update-menus in maintainer scripts. That work is now handled by triggers (except for menu-methods files). This was supposed to be the Policy 3.8.1 release, but I ran out of time today. I'm still hoping to get to that very soon (before 2.2.7 propagates into testing), but there were enough important fixes in this that I didn't want to delay it further. I'm running into a bit of a problem with Lintian at the moment. It's a lot of fun, and we're making a ton of progress, but it's taking me roughly a day a week to really keep up with the incoming bugs and patch submissions and do a proper job of merging them (which is more than just applying them). This really isn't sustainable. I have a bunch of other things that I want to do, both inside Debian and outside, and I'm going to have to reduce the amount of time that I'm spending on Lintian soon. I hate to do that, since it's great to stay this up-to-date and see this high pace of change, but things may start backing up a bit in the near future. As usual, thank you very much to Adam D. Barratt and Raphael Geissert for all of their work, without which this release wouldn't have been possible.

It's crazy to think that this is just past the one-year anniversary of my surgery. A year out and I can lift about 12kg (25lbs for the Americans and Iranians), I'm not on routine or regular pain killers of any sort. I still have to take it easy and need to make sure I get to the gym more often - when I don't I start to get pain and have trouble keeping up with Leif. I have discovered that I can't sleep on airplanes anymore, even in Air Canada business class. So, no more red-eyes for me. It's hard to shed a tear over that one. =) I suppose I have a lot of little limitations like that, but a year in I don't notice them so much anymore.

I shudder a bit to think that at this time last year, I was just home from the hospital. A long walk for me was a trip to the mailbox: I was only up for it every couple of days, and it took me about 30 minutes, including stops for sitting.

Thanks for your love and support, everyone.

Django Lint is a static analysis tool that checks (or lints) web applications that are built around the Django web development framework. It aims to encourage the development of high-quality reusable Django applications. It currently reports on:

• Nullable CharField or TextField model fields
• Missing recommended configuration variables in settings.py
• Mismatch of null=True and blank=False for model fields
• Use of BooleanField with default=True or use of NullBooleanField
• Where myapp.models is actually a directory-based package instead of a single models.py
• Excessive number of models in a single application
• Models within an application having a common prefix
• Use of unique_for_date, unique_for_month or unique_for_year modifiers
• Naive tree structure implementations using ForeignKey('self')
• Missing __unicode__ methods or use of __str__
• Incorrect ordering of standard model methods relative to Django style guidelines
• Misordered middleware in settings.py
• Models with too many fields (or zero) fields
• Extremely large CharField fields
• Use of the PositiveSmallIntegerField or SmallIntegerField fields
• Use of auto_now or auto_now_add modifiers on date fields
• Instances of URLField without an explicit verify_exists value
• (and more)

Admittedly, some of the checks are based on the implementation details of MySQL, PostgreSQL and SQLite backends, but this fits with the goal of promoting re-usable applications anyway. GPLv3 source, tarballs, etc. Patches welcome.

/me for DPL Given that it is now widespread news, I guess it's time to blog about it: I'm running for DPL in this year elections, i.e.: zack for DPL!. Am I out of my mind?
Possibly It started as a joke at last DebConf, with my (naked or dressed ...) room mates spreading that rumor. Then the idea grows into me ... and now here I am. (IOW: I'm pretending I'm not entirely guilty of inflicting another platform to be read.) Apparently we are just two candidates: me and the "ticket" Steve-Luk. For the moment I've to spare a page where I will collect material about the election, and a couple of feelings:

• Sending the nomination mail is embarrassing: we are used to do only technical stuff in Debian, declaring our will of taking care for a while of our non-technical issues ain't easy.
• Preparing a platform is an intriguing experience. Whining about our problems is a thing. Trying to distill them in an organized list, and think about long term solutions is a totally different one. I suggest to try writing your own "platform" even if you are not candidate, and even when there are no DPL elections around (as Joey and HE did a while ago, IIRC, in the form of blog posts). It can be a rewarding exercise.

Version 1.0 of my platform has been submitted to the secretary, and is now available from my homepage. If you have questions, for me or the other candidates, just post them on -vote: campaigning has just started, I'm confident it will be fun! Update the platform is now available from the vote page

As you might have guessed (or not), I ve been playing with the idea of improving my Debian rebuild setup by building on tmpfs: disk I/O take a signifiant amount of time, that could easily be reduced by building (mostly) in memory. Most packages build fine on tmpfs: only 8 packages fail only on tmpfs. Apparently, most of the failures are caused by old versions of autoconf: this version used /tmp to store temporary files ; for example, when generating Makefile, it would create it on /tmp, then move it to the current directory. The problem arises when /tmp is an ext3 filesystem, while the current directory is on tmpfs: when moving the file back to the current directory, the mtime of the file is truncated. This can lead make to think that a given target needs to be rebuilt. A nice example of that is the smuxi package, that just loops when building. Demo:

# cat Makefile
f2: f1
        echo "Need to rebuild f2!"

First case: f1 and f2 are stored in the current directory. Make agrees that
f2 was created after f1:

# rm f1 f2 ; touch f1 ; touch f2 ; make
make:  f2' is up to date.

Second case: f2 is created on /tmp, then moved to the current directory. Make thinks that f2 was created before f1 (and is right, according to stat).

# rm f1 f2 ; touch f1 ; touch /tmp/f2 ; mv /tmp/f2 f2 ; make
echo "Need to rebuild f2!"
Need to rebuild f2!
# stat f1 f2
  File:  f1'
[..]
Modify: 2009-03-08 18:21:08.900237000 +0100
  File:  f2 
[..]
Modify: 2009-03-08 18:21:08.000000000 +0100

The listeners of yesterday s episode of Venty s Hackerfunk radio show on Radio LoRa already know and heard it: We made identi.ca talk. And we did it with help of other microbloggers. (The podcast version of this Hackerfunk episode will be online in a few days, too. Will link it here and either Venty or me will post it on identi.ca, too, as soon as it s published.) A few weeks ago we thought about how we could show microblogging on the radio. With identi.ca s Jabber (XMPP) interface we have real time access, and so the idea was born to pipe all incoming dents into a speech synthesis system. Then we tried to figure out which tools would be appropriate. Quite fast, people on identi.ca as well as on the LUGS IRC (e.g. bones0) pointed us to festival and espeak. We found no support for German in festival, so we went for espeak although festival would have had the advantage of the existence of a festival plugin for the popular multiprotocol messenger Pidgin. Next step was more difficult than expected: How to make a tail -f of XMPP incoming messages? Something like rsstail, just for XMPP. Although using the IM to IRC gateway Bitlbee (as I use it myself) and using tail -f (or better inotail -f ) on the IRC client s log file (ii comes to my mind for such purposes) would have been an option, nobody had the idea at that time. And since @deepspawn conjured xmpptail in less than two hours we happily took it. xmpptail (tar.gz) is written in Python and uses Twisted Words (Debian package python-twisted-words) as XMPP libraries. I had to patch xmpptail slightly for unbuffered I/O, Unicode support and for removing things we don t want to hear on the radio as follows, but it worked more or less out of the box.

--- xmmptail.py 2009-02-25 20:47:48.000000000 +0100
+++ xmpptail.py 2009-03-07 18:48:57.000000000 +0100
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python -u
 # -*- coding: utf-8 -*-
 # author: Carlos A. Perilla 
 # This file is part of Jance bot.
@@ -65,7 +65,8 @@
          body = unicode(e.__str__())
          break
 
-    print("%s: %s" % (from_id,body))
+#    print("%s: %s" % (from_id,body))
+    print("%s" % (body.encode('utf-8')))
 
 
 def authfailedEvent(xmlstream):
@@ -80,9 +81,9 @@
   dprint('Got something: %s -> %s' % (el.name, str(el.attributes)))
 
 if __name__ == '__main__':
-    print "Starting"
+    #print "Starting"
     execfile('tailconf')
-    print USER_HANDLE
+    #print USER_HANDLE
     me = USER_HANDLE + "/xmpptail"
     myJid = jid.JID(me)
     server = USER_HANDLE[USER_HANDLE.find('@')+1:]

So after configuring xmpptail to use the hackerfunk Jabber account, we successfully ran the following script during the radio show:

./xmpptail.py   while read LINE; do
        if [ "$LINE" = "empty" ]; then
                continue;
        fi;
        echo $LINE
        echo $LINE   tee -a xmpp-espeak.log   espeak --stdin -v de;
done

At the end of the show, @rebugger found this howto which describes very detailed how to get festival working together with the non-free ( non-free as in DFSG) MBROLA project which offers also the appropriate files for German. But because of how much work this would be to get it running, I currently prefer to stay with espeak for German speech synthesis . Next step would be to use mnoGosearch s mguesser to detect the language of a dent and run espeak (or whatever text-to-speech system is appropriate for the guessed language) with the appropiate options for that language, because otherwise many dents sound really funny. ;-) Update, 15:02: Venty gave the whole system the name Identibla .

So, fanatical readers of my blog (are there any?) may remember a long time back that I got bored and wrote a little script that amused me. While testing something out yesterday, I needed to find a domain that I wasn t using in production so I could test on it. I stumbled across Cheese Nibbles which had a lovely We ll be back with something cool soon message on it. So, I did my tests, and they worked. Everything s good. I d actually forgotten what was on Cheese Nibbles in the first place, so I started rooting round in the code. I found the old site, and I decided to resurrect it. I posted in a couple of IRC channels, to see if other people found the site amusing, and got the following back in response

<Daviey> neat
<Daviey> Mez: rss feed needed
<Mez> Daviey: *chuckles*
<Mez> but then it d be twitter
<Daviey> sure, but a shared account
<Daviey> Or.. make it twitter when changed

So, well, thanks to Dave Walker s suggestion, I did a quick google, and within 6 minutes, had it working. You can find the twitter feed at http://twitter.com/cheesenibbles Also, over the last couple of weeks I ve been working with Zeth from my local LUG (and the tech, who shall remain anonymous, like The Stig ) on a podcast, which we are, for now calling The Podcast (imaginative I know). I was interviewed in the first podcast (which Zeth did alone, and I (apparently) provided the comedy element for) and presented with Zeth for the second one. Also, as the second one was recorded during the Ubuntu Global Bug Jam, of which I was running one of the venues, I actually allowed myself to be interviewed for it aswell. The podcast is very rough around the edges at the moment, and well, we haven t got a website, or an RSS feed yet, but you can find the show notes here, and download the podcast episode in either MP3 Format, or OGG Format All comments/thoughts/suggestions welcome!

I ve been working as of late with psycopg2, the Python bindings for PostgreSQL. Documentation is a bit, erm, lacking. You can get the basic stuff working by reading Python s DBAPI-2.0 specification, since psycopg2 follows it, but (as I ve only recently realized) discovering the extra features that exist needs you to poke the source. The other day I was wanting to pass to the execute method of a cursor a sequence to fill the value list in a SQL IN statement. The DBAPI spec does not mention this usage at all, and a cursory question in #python told me it wasn t supported (required?) by the spec. It is, in any case, supported in psycopg2. You just need to

  import psycopg2.extensions

and it just works: you can pass tuples, and they ll be converted to a value list. If you want to be able to pass lists as well:

  from psycopg2.extensions import SQL_IN, register_adapter
  register_adapter(list, SQL_IN)

There is also a row factory in psycopg2.extras that offers a dictionary interface, instead of tuple-based. Finally, I have no idea why, but when I started with psycopg2, I came to get the idea that only named parameter substitution was supported (INSERT ... VALUES (%(var1)s, %(var2)s)), but simple %s substitution is also supported: just pass (of course) a tuple as the second parameter to execute, instead of a dictionary.