PostgreSQL's libpq5 package got its symbols file somewhere around version 8.4, so the symbols in there were all marked with version "8.4~" or greater. As I'm working on pgapt.debian.net aiming at providing packages for all upstream-supported PG versions (currently 8.3 and up), this made packages incompatible with 8.3's libpq5.

There didn't seem to be a ready program to feed a series of .deb files which would then run dpkg-gensymbols and build a symbols file, so I wrote this shell script:

#!/bin/sh

set -eu

[ -d tmp ] || mkdir tmp

i=1

for pkg in "$@" ; do
    echo "$pkg"
    test -e "$pkg"
    name=$(dpkg-deb -I "$pkg" | perl -lne 'print $1 if /^ Package: (.+)/')
    version=$(dpkg-deb -I "$pkg" | perl -lne 'print $1 if /^ Version: (.+)/')
    out=$(printf "tmp/%03d_%s" $i "$version")
    dpkg-deb -x "$pkg" "$out"
    dpkg-gensymbols -P"$out" -p"$name" -v"$version" \
        ${oldsymbols:+-I"$oldsymbols"} -O"$out.symbols" | \
        tee "$out.symbols.diff"
    test -s "$out.symbols.diff" || rm "$out.symbols.diff"
    oldsymbols="$out.symbols"
    rm -rf "$out"
    i=$(expr $i + 1)
done

To use it, do the following:

• debsnap -a i386 libpq5
• ls binary-libpq5/*.deb > files
• edit "files" to have proper ordering (~rc versions before releases, remove bpo versions, etc.)
• ./walk-symbols $(cat files)

The highest-numbered *.symbols file in tmp/ will then have symbol information for all packages. I then did some manual post-processing like s/~rc1-1/~/ to get nice (and backportable) version numbers.

Another nice trick (pointed out by jcristau) is to replace the lowest version number of that package (8.2~ here, where libpq changed SONAME) by 0 which will make dpkg-shlibdeps omit the >= version part. (Most packages depending on libpq5 will profit from that.)

I'm still pondering whether this script is non-trivial enough add to devscripts. (The people I asked so far only made comments about the mkdir call...)

My first DNSSEC setups were using OpenDNSSEC, but at some point I prefered to migrate to DNSSEC-Tools.

Here's a hack (howto) to migrate the KSK keys to .krf format. The ZSK keys will be generated by the first zonesigner run.

#!/bin/sh

ZONE="$1"
KEY="$2"
ALGO="$3"

cd keys
sudo softhsm --export $ZONE.zsk --slot 0 --pin 1234 --id $KEY
softhsm-keyconv --tobind --in $ZONE.zsk --name $ZONE. --algorithm $ALGO

BINDKEY=$(ls K$ZONE*key)
sed -i -e 's/256/257/' $BINDKEY
BASEKEY=$(basename $BINDKEY .key)

cd ..

cat > $ZONE.krf <<EOF
zone    "$ZONE"
    serial      "2011112202"
    kskcur      "$ZONE-signset-00001"
    signedzone  "$ZONE.signed"
    kskcount    "1"
    archivedir  "/var/lib/dnssec-tools/archive"
    kskdirectory    "/cb/ns.df7cb.de/keys"
    zskdirectory    "/cb/ns.df7cb.de/keys"
    endtime     "+2592000"
    lastset     "$ZONE-signset-00004"
    zonefile    "$ZONE"
    keyrec_type "zone"
    keyrec_signsecs "1321964086"
    keyrec_signdate "Tue Nov 22 12:14:46 2011"

set "$ZONE-signset-00001"
    keys        "$BASEKEY"
    set_type    "kskcur"
    zonename    "$ZONE"
    keyrec_setsecs  "1321961247"
    keyrec_setdate  "Tue Nov 22 11:27:27 2011"

key "$BASEKEY"
    zonename    "$ZONE"
    keyrec_type "kskcur"
    algorithm   "$ALGO"
    random      "/dev/urandom"
    keypath     "/cb/ns.df7cb.de/keys/$BINDKEY"
    ksklength   "2048"
    ksklife     "15552000"
    revperiod   "3888000"
    keyrec_gensecs  "1321961248"
    keyrec_gendate  "Tue Nov 22 11:27:28 2011"

EOF

zonesigner -keydirectory keys -usensec3 -genzsk -verbose $ZONE

rollinit $ZONE >> all.rollrec

echo "/cb/ns.df7cb.de/$ZONE.signed $ZONE cb@df7cb.de" >> checkzones.txt

(The filenames at the end are those used by http://www.incertum.net/archives/11-DNSSEC-mit-Debiansqueeze-dnssec-tools,-bind9.html)

Vim's habit of completing the full filename of the first match on :e has always annoyed me. Rhonda pointed me to wildmode - thanks!

set wildmode=longest,list:longest,list:full

Transitioning Python modules to dh_python2 is straightforward. I removed LOADS of magic from python-radix. I especially like the complexity reduction in debian/rules, but debian/control also got some fields removed.

Because of some problem with Denic's DNSSEC testbed and bind resolvers, dlv.isc.org has removed all DLV records for *.de domains. WTF.

29. April 2011

I doubt CUPS and I will ever become friends. Every time I try to print something at home, my notebook has new issues. This time the HP color laser had jobs stuck at "pending".

Fix this time: re-run hp-setup to add a new printer definition. In the gimp print dialog a new tab for "color" will appear. Thanks zobel for the suggestion.

At work, I'm dealing with lots of different database setups, luckily mostly PostgreSQL running on Debian. At the same time, a fair amount of the tools in the PostgreSQL ecosystem (not the PostgreSQL server packages itself) are not in the best shape in the Debian archive.

I'm trying to change that by adopting some of the packages. So far, I have fixed a few RC bugs where packages where suddenly trying to build against PostgreSQL 9.0 while expecting 8.4. To my surprise, there are no packages yet in the archive that support multiple PostgreSQL versions in parallel. There is even a package ready to help doing this - postgresql-server-dev-all, but apparently nobody has used it yet. It turned out that after working around a few trivial problems and adding just a few lines of sh code, it was pretty straightforward to port skytools and postgresql-pllua to 9.0 while keeping 8.4 support. The latter has no version-specific code left in debian/ except for a list of supported versions in debian/pgversions, so a future port to 9.1 will be trivial. (Fun fact: the old postgresql-pllua version 0.8.1 was actually a typoed 0.3.1 version.)

Most PostgreSQL tools use a common subversion repository on Alioth, but there is no common mailing list address that is put into the Uploaders fields, so it is hard to get an overview over the state of all packages. I've compiled a list of all packages in svn, git, bzr (the server packages), and a few others in DDPO to fix that for now.

Other packages I've updated so far are pgtune, pgbouncer, and pgpool2.

Using a virtual IP managed by heartbeat is a nice way to work around the slow fallback behavior with multiple nameservers in /etc/hosts. But unlike ntpd, bind9 doesn't automatically listen on new IPs on the system.

Here's a cute hack to fix that:

# cat /etc/ha.d/haresources
server01 bind9release IPaddr::10.0.0.3 bind9takeover

# cat /etc/ha.d/resource.d/bind9release
#!/bin/sh
# when giving up resources, reload bind9
case $1 in
        stop) /etc/init.d/bind9 reload ;;
esac
exit 0

# cat /etc/ha.d/resource.d/bind9takeover
#!/bin/sh
# on takeover, reload bind9
case $1 in
        start) /etc/init.d/bind9 reload ;;
esac
exit 0

I have just released version 0.11 of Tenace, my bridge hand viewer/editor for Linux/Unix (and Windows, if you have Gtk installed and get it compiled).

The new "Open in web" feature will send the current hand to bridgebase online's handviewer to share with other on the web. The parallelized parscore computation (if you have multiple CPUs) has been improved, thanks to Bo's work on making DDS multi-threaded.

Updated Debian package are on the way to the mirrors, the source code is on the Tenace homepage,

When my wife bought her HP 2605dn color laser, she had also ordered a set of replacement cartridges because the originals would supposedly not last very long. It turned out that they would last over two years, though.

Now, the black cartridge was empty. The replacements are original HP components, but recycled/refilled second hand from a different source. I put in the black one, and the trouble started with the new drum having a big scratch that would appear in every print. After two years, returning the cartridge was not an option. As the old drum was still good, the idea was to put the new toner into the old cartridge. A bit of googling (and visual inspection) quickly revealed that you are not supposed to do this, the device doesn't have any facilities to access anything.

Some post did indicate though that the cartridge actually consists of two parts that are only held together by two pivot pins and two small springs. If you pull the two parts apart a bit, you can feel the axis the parts are moving around. So, I would try to use the old drum part with the new toner container part.

Removing the springs is easy (also removing the flap covering the drum, along with a tiny third spring). The two pivot pins are pretty inaccessible, but I managed to pull out both using a pointy tong. One pin is made of metal, if you need more space you can drill a small hole right next to it. The other pin is made of plastic with a small hole in it, in one case I succeeded by screwing in a little screw and pulling at it.

Reassembling the parts is not so hard. I put the "new" cartridge into the printer, waited for the initialization to finish, only to find out the printer would still think the cartridge was empty and should be replaced. Duh.

I then discovered a small chip attached to one corner of the drum unit, probably carrying product ID and some serial number. Luckily, it was easy to be removed and exchanged with the other drum unit. Still, the printer thought the cartridge was empty. Some (windows) driver re-installations later it was clear that there is no "ignore fill level and print anyway" option. (Cups didn't print either.)

The HP Support Forum has a long Ink cartridge empty but it's not thread with lots of complaints but few answers. (Their problem is mostly with new HP cartridges becoming "empty" after a few days.) Someone suggests trying to cold reset the printer. For the 2605dn, that's holding the left and right buttons while powering on. I removed the cartridges for doing so. When I had put them back in, the printer asked me to confirm that non-HP material was installed, and subsequently didn't display any fill level for the black cartridge anymore, just "|?|" in the display.

Printing works now. Yay.

(Lesson learned: I still hate dealing with printers.)

Jan 5 2011, 3070g, 54cm

Julia, Mom and Dad are all well and very happy.