Evolution-data-server (or e-d-s for short) seems to be a fairly nice piece of software. It’s being more and more integrated with the gnome desktop and other non-gnome applications such as gaim are using it. I prefer to be able to use my tools from the command line and I want to hook e-d-s into gnus so I can actually look up email addresses and maintain that inside of gnus.

I started writing some command line tools tonight and discovered that the API documentation isn’t really up to speed. It lacks a lot of documentation. The header files are readable enough that I manage to navigate with just those and a fair amount of trial and error. So far, the command line tool just spits out all the people from all the address books with no way to search or do anything useful with the information, but it’s a good start. I just hope integration with bbdb and gnus will go smooth.

I was in tridge’s talk on ldb this morning. ldb is a lightweight database with an LDIF/LDAP frontend which can use tdb, “trivial database” as its backend. E-d-s uses Sleepycat DB as the backend, and I have some performance problems there, in addition to the fact that I never liked libdb. I therefore started writing a tdb backend for e-d-s. It’s a lot of cut-and-paste from the file backend, but that just means I save a lot of time.

I finally got around to changing my system to a UTF-8 system the other day. It was surprisingly easy, but with a few caveats to not annoy people on Latin-1 IRC channels and such.

Pterm supports UTF8 just fine, but is evidently not smart enough to actually pick a unicode font, so I had to tell it explicitly to use one.

Irssi in stable, testing, unstable, warty and hoary are all too old to have proper recode support, so I packaged irssi 0.8.10rc5 and uploaded that to breezy. This has nice recode support so you can say “please use latin1 while talking to this person”. I’ll have to fix that on vawad too when I get home.

Apart from that, it meant adjusting a set of dotfiles to not set LANG if it is already set, changing the default in the gdm login screen and fix up the ssh config on vawad to actually allow passthrough of LANG and LC_* environment variables.

I need to adjust my emacs setup too, but that’s not too urgent and it is fairly simple to do.

Yesterday was all about breaking and not getting stuff to work properly. First, I broke pkg-config with the 0.17 release. The pkg.m4 included there broke because I’m a twit and misunderstood what James Henstridge said and then failed to test the changes properly. 0.17.1 was released this morning to fix this issue as well as the backwards test for whether inter-library dependencies are supported or not.

Later in the day, I fumbled around with getting LaTeX to frame a part of my thesis with a shaded background. After a lot off googling around, I found framed.sty which does what I want without any fuss. Yay. Now I’ll just have to actually write the content.

Right now, I’m fixing up stuff again. Jeff Bailey is fixing some bugs in mkinitrd for us at work, which is kinda cool to watch through a shared screen session. IRC + shared screen is fun.

Basically, the problem with Planet having feeds “break” it is that Planet uses an ultra-liberal feed parser which ignores errors (and thereby breaks the XML spec). Of course, this means Planet’s output might not be valid either.

I’ve had this discussion with Keybuk a few times, he seems to think having planet work this way is a feature and not a bug.

The first pkgconfig release in about 1.5 years is now out. A bunch of bugfixes, some feature enhancements. Please test it and give me feedback.

Inspired by Md’s efforts to provide numbers showing how many packages have been downloaded off ftp.it.debian.org, I decided to try to get the same numbers for another mirror. The admin of ftp.se volunteered his logs, and I ran a small, ugly shell snippet[1] on the logs to extract the number of downloaded packages:

The numbers include some amd64 downloads, but this is such a small number that it won’t have skewed the numbers significantly so they are included for completeness.

[1]: bzcat */httpd_2005-02-*.bz2| perl -ne '/_([[:alnum:]]+)\.deb/ and do {$arches{$1}++}; END {foreach $key (keys %arches) { print $arches{$key}, " $key\n"}}' | sort -rn

Julien, please don’t reinvent the wheel. Just use a version control system. Whether you prefer Arch, SVN, CVS or any other is nothing I’m going to tell you to, but you’ll save yourself a lot of work by just using a version control system.

After about a week of gcc compiles, I have multiarch working now. Mostly, at least:

(hoary-clean)root@shonap:/tmp# cat hello.c
#include <stdio.h>

int main(int argc, char **argv) {
  fprintf(stderr, "hello multiarched world\n");
}
(hoary-clean)root@shonap:/tmp#

A trivial hello.c. Then, we have a multiarched libc6 and libc6-dev:

(hoary-clean)root@shonap:/tmp# ls /usr/include/stdio.h
ls: /usr/include/stdio.h: No such file or directory
(hoary-clean)root@shonap:/tmp# ls /usr/include/i386-linux/stdio.h
/usr/include/i386-linux/stdio.h
(hoary-clean)root@shonap:/tmp#

Matching libraries:

(hoary-clean)root@shonap:/tmp# ls /usr/lib/libc.so /lib/libc.so.6
ls: /usr/lib/libc.so: No such file or directory
ls: /lib/libc.so.6: No such file or directory
(hoary-clean)root@shonap:/tmp# ls -1 /usr/lib/i386-linux/libc.so /lib/i386-linux/libc.so.6
/lib/i386-linux/libc.so.6
/usr/lib/i386-linux/libc.so
(hoary-clean)root@shonap:/tmp#

Then, compile, check, run:

(hoary-clean)root@shonap:/tmp# gcc-3.4 hello.c -o hello
(hoary-clean)root@shonap:/tmp# file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
(hoary-clean)root@shonap:/tmp# ldd hello
                libc.so.6 => /lib/i386-linux/libc.so.6 (0xb7eb1000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)
(hoary-clean)root@shonap:/tmp#
(hoary-clean)root@shonap:/tmp# ./hello
hello multiarched world
(hoary-clean)root@shonap:/tmp#

Yay!

Of course, there are minor problems left, like gcc thinking that it installs the 64 bit libraries into /usr/lib/i486-linux/x86_64-linux, that it currently can’t compile for 64 bit due to the symlink from libgcc_s_64.so being missing and other minor stuff like that. It seems glibc also needs a minor adjustment (just a missing symlink from i486-linux to i386-linux in /usr/include).

As a final test, I scp-ed the 64 bit binary I built (after having created the libgcc_s_64 symlink by hand) to an AMD64, and it works beautifully there.

I’ve gotten multiarch working again today:

root@shonap:/# ls -l /lib/libc-* /lib/ld-linux.so.2
ls: /lib/libc-*: No such file or directory
lrwxrwxrwx  1 root root 22 Jan 25 18:56 /lib/ld-linux.so.2 -> i386-linux/ld-2.3.2.so
root@shonap:/# ls /lib/i386-linux/
ld-2.3.2.so               libm.so.6               libnss_nisplus-2.3.2.so
ld-linux.so.2             libmemusage.so          libnss_nisplus.so.2
libBrokenLocale-2.3.2.so  libnsl-2.3.2.so         libpcprofile.so
libBrokenLocale.so.1      libnsl.so.1             libpthread-0.10.so
libSegFault.so            libnss_compat-2.3.2.so  libpthread.so.0
libanl-2.3.2.so           libnss_compat.so.2      libresolv-2.3.2.so
libanl.so.1               libnss_dns-2.3.2.so     libresolv.so.2
libc-2.3.2.so             libnss_dns.so.2         librt-2.3.2.so
libc.so.6                 libnss_files-2.3.2.so   librt.so.1
libcrypt-2.3.2.so         libnss_files.so.2       libthread_db-1.0.so
libcrypt.so.1             libnss_hesiod-2.3.2.so  libthread_db.so.1
libdl-2.3.2.so            libnss_hesiod.so.2      libutil-2.3.2.so
libdl.so.2                libnss_nis-2.3.2.so     libutil.so.1
libm-2.3.2.so             libnss_nis.so.2

At least, it works for glibc on i386. I now need to fix up gcc to look in the right places and whip up a few sample packages. The nicest thing about all this is the small size: it’s barely a patch to upstream’s sources and apart from the splitting of packages which is needed, it’s a tiny change to the Debian packaging.

Since SSL doesn’t support more than one virtual host per IP/port pair and I want to run a few vhosts on my server, I am using port-based SSL-vhosting. This worked well for a while and I was using 443, 444, 445, 446 and so on.

Then, MS comes about and decides they need to use a new port number since they’ve tweaked CIFS a little. What number do they choose? 445! And what happens the first time some random hole in their implementation is found? The university stops incoming connections to port 445. Not rejects or anything nice like that, no. They just drop the packets on the floor.

I just love it when people make random changes like that without telling. And I am so happy about MS grabbing random port numbers.