Debian PostgreSQL Packaging Project

We have launched the Debian PostgreSQL Packaging Project at http://pkg-postgresql.alioth.debian.org/. We are a group of people interested in maintaining Debian packages related to PostgreSQL.

Obviously, Debian already contains a large number of packages related to PostgreSQL. The idea behind this project is to get the involved maintainers together, concentrate resources, exchange ideas, and allow more people to get involved in small ways. See our web site about participating.

When non ASCII names will finally work? (part 2)

no comment

CDBS usage statistics

Here is a fun little statistic for CDBS lovers and haters: Percent of packages (source, binary) using CDBS over time:

Sources-sid-main-2005-04        9.76    10.02
Sources-sid-main-2005-05        10.20   10.62
Sources-sid-main-2005-06        10.36   10.76
Sources-sid-main-2005-07        10.76   11.16
Sources-sid-main-2005-08        11.05   11.36
Sources-sid-main-2005-09        11.48   12.32
Sources-sid-main-2005-10        12.08   13.12
Sources-sid-main-2005-11        12.66   13.68
Sources-sid-main-2005-12        13.13   14.13
Sources-sid-main-2006-01        13.29   14.37
Sources-sid-main-2006-02        13.59   15.00
Sources-sid-main-2006-03        13.97   15.34
Sources-sid-main-2006-04        14.38   15.73
Sources-sid-main-2006-05        14.53   16.17
Sources-sid-main-2006-06        14.71   16.30
Sources-sid-main-2006-07        15.17   16.54
Sources-sid-main-2006-08        15.84   17.04
Sources-sid-main-2006-09        16.23   17.07
Sources-sid-main-2006-10        16.60   17.24
Sources-sid-main-2006-11        16.97   17.56
Sources-sid-main-2006-12        17.46   17.90
Sources-sid-main-2007-01        17.66   17.97
Sources-sid-main-2007-02        17.87   18.12
Sources-sid-main-2007-03        18.06   18.38
Sources-sid-main-2007-04        18.27   18.68
Sources-sid-main-2007-05        18.86   19.39
Sources-sid-main-2007-06        19.64   20.66
Sources-sid-main-2007-07        19.79   20.93
Sources-sid-main-2007-08        20.13   21.15
Sources-sid-main-2007-09        20.32   21.33
Sources-sid-main-2007-10        20.81   21.95
Sources-sid-main-2007-11        21.16   22.02
Sources-sid-main-2007-12        21.48   22.17
Sources-sid-main-2008-01        22.12   22.67

World domination in about 2020. :)

A Sporty PgCon?

Those who stuck around one or two days after PgCon last year in Ottawa might have noticed that there were a lot of runners in town. As it happens the Ottawa Race Weekend will take place again this year the Saturday and Sunday after the conference. They offer everything from a short walk up to a marathon. I am considering signing up for one of the races this year. If any fellow conference goers want to join up in a type of PostgreSQL team effort, feel free to contact me.

Problems with newer kernels

It has become apparent to me that the Linux kernels in Debian testing and unstable (2.6.2x) have all kinds of problems compared to the one in stable (2.6.18), especially when it comes to working with virtualization. I have been trouble booting newer kernels as guest systems in VirtualBox (bug #434723) and QEMU (and bug #449085). There is some chatter in the Gentoo forums to the same effect. I have also had trouble compiling the host system kernel modules of VMPlayer and VirtualBox with newer kernels. If your job requires regular juggling of virtual machines and operating systems, this creates big problems. Plus my UMTS card stopped working (bug #433750), also confirmed by Gentoo chatter. :) I have also tried to build pure upstream kernels myself, but they have the same problems. So my advice to those running Debian post-stable is to stick to kernel 2.6.18 from stable if you are seeing funny issues.

Configuration files with Git

A while ago I put the configuration files in my home directory (.bashrc, .psqlrc, etc.) into a Subversion repository so I could keep track of what I changed and distribute the changes to different machines. This worked well, but the choice of Subversion created a number of shortcomings: It was difficult to work with unconnected hosts (no local commits), it is difficult to make changes that apply only to some machines (branches, changesets?), and you need a separate directory for the repository.

Now I have converted this to Git, which appears to address these problems. The repository information is entirely contained in the .git directory in the top level of the working tree. I haven't transferred the tree to a different host yet, so that will be next week's project.

Now I'll go ahead and commit the .gitconfig file into the GIT repository. :)

Version control unmaddened

PostgreSQL is the only project I'm involved in that uses CVS. Most other places now use Subversion, Bazaar, or something else. That's fine, but it's really annoying to continously type in the wrong tool when you switch back and forth.

So today I fixed this problem. I wrote this little shell script I call vcs:

#!/bin/sh



if [ -d CVS ]; then

       cvs "$@"

       exit $?

fi



if [ -d .svn ]; then

       svn "$@"

       exit $?

fi



dir=$(pwd)



while [ -n "$dir" ] && [ "$dir" != / ]; do

       if [ -d "$dir/.bzr" ]; then

               bzr "$@"

               exit $?

       fi



       dir=$(dirname "$dir")

done



exit 77

This can be extended in obvious ways.

Put this in your path, and then you can use vcs for everything.

But somehow, cvs is really easy to type, or maybe your fingers are wired to svn or something else. So add to this a couple of shell functions like this:

bzr() { vcs "$@" || { [ $? -eq 77 ] && command bzr "$@"; }; }

cvs() { vcs "$@" || { [ $? -eq 77 ] && command cvs "$@"; }; }

svn() { vcs "$@" || { [ $? -eq 77 ] && command svn "$@"; }; }

Now you can type cvs update or whatever your brain or fingers prefer and it will do the right thing.