SVN already has cvs2svn. I needed something to do this the other way around. You probably think I’m crazy. I’m not (at least not because of this). I already have the biggest part of my dotfiles in CVS and have a working setup through joeyh’s sshanoncvs which works fine. I want to play around with subversion, so I have converted my CVS repository to SVN. Howerver, my home directory is checked out on a lot of boxes which don’t have any SVN client installed. So, I rather add a post-commit hook which updates my dotfiles each time I commit to the SVN repository. Quite neat.

Once I get some sort of decent access controls set up for this, I’ll just post a link to the script, but if you want a copy in the meantime, just drop me a mail.

Got home from a party Sunday morning (at 0800, after a party), checked my mail and there were my plane tickets. Opensourceworldconference, here I come!

I think I have done one of the most hairy installations of Debian ever today. The situation: a host with a MegaRAID card, remotely, behind a firewall, to get Debian installed. No serial console.

First, you ssh through the firewall. Then you ssh to a machine on the internal network and run rdesktop to another internal server. From that rdesktop session, you run Internet Explorer and connect to the internal management card on the machine to be installed and get a text console through a Java applet.

Ok, so now you have a connection to the machine to be installed. It has its Debian CD in the CD-ROM player. Reboot the system, boot it, using video=vga16:off, since the text console doesn’t handle the frame buffer at all. Once it’s up, we chose Norwegian keyboard. Of course the installer doesn’t find the megaraid card. Out to a shell, and because of the choosing of a Norwegian keyboard, / is nowhere to be seen. After searching a bit around and mounting /dev/hda at /dev/a we did recover the slash. So, after discovering that being able to unpack the 5.7MB big drivers.tgz somewhere, we decide to reboot with a different ramdisk_size. 64MB is good.

So, reboot, repeat the procedure, though this time with American keyboard instead, since it actually works (and is a norwegian keyboard; something is clearly wrong somewhere, but sometimes two wrongs make a right). mkfs.ext2 /dev/ram1, mount it at /tmp2, unpack /cdrom/dists/stable/main/disks/current/bf2.4/drivers.tgz to /tmp2, unpack modules.tgz in there again, insmod the megaraid module (which is in /tmp2/lib/modules/2.4.18-bf2.4/drivers/kernel/scsi/megaraid.o), do the install.

So far, so good, I thought. Of course I was wrong. The kernel installed didn’t have initrd with the megaraid driver on, nor were it compiled in, so back to square one: boot with huge ramdisk, unpack drivers.tgz from the cd, unpack modules.tgz, insmod megaraid, mount /dev/sda5 /target. Then, chroot into /target, fix up sources.list, install a kernel, make sure the lilo config is correct, then umount everything and reboot again. Woo, it works.

I overslept class today, so I decided to stay home and do some useful work instead. So, I managed to upload a new version of Mailman and Apache2, this one seems a bit better than the last one, at least svn still seems to work. Woo.

I was supposed to do an Apache 2 upload today, but due to work taking a bit too much time, I ended up not having the time to do it. Been hacking apache all afternoon, though not the Debian part of it, just configuring and fixing it up; it sure is a complex beast.

Had a drift meeting on IRC where we discussed the crack of epsilon last week. Good to have everybody catch up. After dinner, I upgraded Advertpro and run the evil localhost proxy hack on the forum, which should speed it up somewhat. Also fixed up various other small stuff. Tired now. Sleep.

Writing multiarch proposals seems to be this week’s most popular sport. I’ve written my own proposal. This one should address most issues people have, without pissing off anybody too much. We need a was to say “this package depends on this package with this architecture”, but apart from that, my proposal seems fairly solid. (At least nobody’s been able to really pick it apart yet.) It doesn’t attack my sense of aestetics either, unlike some of the other proposals.

The ad system running on zeta.hardware.no was changed today from Advertpro running under mod_perl to a Tomcat based Java system. Seems to work fine so far, though I seriously dislike Tomcat’s XML based config files.

elmo prodded me on IRC that my mail host was refusing spam with a “550 Message classified as spam”. While this is correct, it causes double-bounces to go to postmaster@debian.org, which is unintentional. At Samfundet we have a setup which doesn’t bounce spam sent to lists, it just accepts it and nullroutes it. I don’t think that’s the right way, but it’s better than annoying postmaster@debian with bounces.

I’m using exim4, and this is how I solved it. I replaced my normal spam-bounce rule:

with:

In addition, a special router is needed; mine is called 50_err_devnull:

Finally, the devnull transport:

This is a bit hard-coded and could probably be fixed a bit better, but it seems to work fine for me, at least.

amd64 and multiarch seem to be the hot topic of the day. I’ve been trying to chase down something which I thought was a linker bug. Of course, it wasn’t a linker bug, it was a silly assumption somewhere in gcc. Or, at least I like to believe it is, since else it’s a bug somewhere in my lib64c6 package. Anyhow, lib64c6-dev and lib64c6 are almost ready; there are always some bugs which creep in at the last moment. Upgrading gcc seemed to fix my problem compiling binaries.

Most of my evening has been spent discussing how to do 64 bit packages should be implemented. The consensus seems to lean towards having lib64foo and libfoo packages for amd64 and i386 respectively. How to fix the -dev package problem is yet to be decided.