Funny dialog

dad: (while joining us, who're watching the Vienna New Year's concert on TV) Nice flowers?
mom: No. It's a peasant's fair.
dad: That can be nice too, no? A nice peasant's fair?

...

Hmm. This might require a bit of explanation.

My mother has been teaching floral design for almost 20 years. She's also managed the flower decorations in the local church for ages. This obviously isn't because she knows nothing about flowers or floral decoration; she obviously does and is, in fact, quite passionate about it.

A result of this is that she can be quite upset when you went to church on christmas eve after she's done quite some work arranging the flowers, and you didn't even notice them (because they are, after all, things meant to be decorations in the background—and you gave your attention to the mass itself). Or that when there's something going on on TV or in real life involving a concert, the church, or something else, she'll first look at the flowers, and only then at whatever else is going on.

As I do, dad also knows this. So his question was really after her expert opinion on whether the flowers were nice. In that light, the final remark is rather... silly.

Replacing a mainboard

About a week or two ago, my sister called me that her computer didn't boot anymore. After looking at it for a short while and asking her how it had stopped working, there was only one conclusion that I could come to: the processor fan had broken down, which meant that she'd had a processor meltdown (she had a Pentium I-class system; back then, builtin thermometers weren't as common as they are now). She needed a replacement. Now I do have a bunch of spare hardware, but I didn't have anything that could compare to her 200-something Mhz system, and she was already complaining that the thing was rather slow; so I helped her find a 233Mhz Pentium mainboard (with processor) on eBay.

That arrived on monday at her place, and she brought it to me to install it.

That's done now, but not before I had to tell the thing it was the worst mainboard design that I have ever seen. No, really. And I've seen quite some mainboards already, since I used to work for a place where they sold hardware, a while back.

The power connector, IDE connectors, serial ports, parallel port, and floppy drive connector are all positioned in the top left corner of the mainboard, above the PCI slots and right below where the power block is supposed to be. As a result, it's nearly impossible to reach them. When you do reach them, they're all placed so fucking close to eachother that it's nearly impossible to fit them all and to do so correctly. The one exception to that rule is the parallel port, which is fairly close to the rest, but still in the same area. It gets in fairly easily—unfortunately, it also gets out fairly easily if you touch them cables, which you have to do to put the topmost PCI card in its slot. Grmbl. Can't they put those cables in the center right, where they belong?!?

After fighting with them cables, it was time for the RAM. That mainboard contains two DIMM slots and four 72-pin SIMM thingies. I have one RAM module for the DIMM slots, but unfortunately it didn't work with that module; I'm not sure whether it's the RAM that's broken, or whether the mainboard simply doesn't want to accept it. Fortunately, I have some 72pin RAM modules left.

Unfortunately, I found that the 72pin slots were placed so close to the top of the mainboard that I had to get it out again in its entirety to be able to fit the topmost module. Grmbl. One centimeter of space is too much to ask?

After that, it turned out that the machine still didn't boot. At first I thought this was one of those braindead BIOSes that doesn't boot unless you hook up a keyboard, but in the end that didn't seem to be the case. After one by one disconnecting everything, it turned out that the system would boot when I didn't connect the CD writer, but it would not boot at all when I did connect it. And when I say "not boot", I really mean it that way; it didn't even start the POST.

Replacing the IDE data cable didn't help. I even tried using the one of the hard disk (which worked, because I had already done a boot from disk), or to connect the writer to as slave to the primary connector, but no luck; it simply wouldn't boot with that writer connected.

Well, I'm tired of it now. Maybe I'll go to the shop with that writer again (it was a christmas present, so should still be under warranty) and ask them to have a look at it, but otherwise sis won't have a writer.

Whoops

I had a bunch of old packages in my ~/debian/nbd/ directory, that didn't serve much purpose anymore, so I wanted to clean them out.

wouter@grep.be:~/debian/nbd$ rm -Rf *

After that finished, I realized that this directory also contained my CVS checkouts of the NBD upstream CVS. And one of those checkouts contained quite a lot of uncommitted code. Whoops.

So, what do you do then? Stop writing to disk immediately. Pull the plug. Except this is a laptop, so, push the power button until you don't see anything anymore; and next, try to read the lost file from a different installation.

That "different installation" was an easy one. I've always had a second, minor, 'play' partition on my laptop, that I use to try out all sorts of operating systems. I've used it to run Debian stable, Ubuntu, MacOS X. It currently contains Gentoo; I intend to try out FreeBSD for PowerPC some time.

But the fact that it already had Gentoo meant I could use that one to run debugfs on the (not mounted) file system, and try to find my files back. Except that I'd never done that before, and I didn't know where to start. And since my gentoo installation isn't set up entirely right, I couldn't get networking to work okay, thus, no help through IRC.

My first guess was to check the ext3 journal. There's a command to dump any random inode to disk in hex format (dump <inode number>, with the square brackets), so that should help. I thought.

Hah

I spent two hours looking at kernel code, trying to find out what the on-disk format of the ext3 journal is (which, as it turns out, isn't part of the ext3 driver; it is a totally different driver, called jbd), only to find out that it wouldn't help me; a journal obviously only contains information on the new data it's going to write, not on the old data it's overwriting. And seen how removing a file means you overwrite a directory inode block with newer information that does not contain the reference to the removed file anymore, that wasn't helpful.

At least I learned what the ext3 journal's on-disk format is. Might be useful in the future.

My next move was looking at debugfs again. Found that it has some command called dump_unused, which will dump the raw data of any blocks that are not allocated, provided that raw data isn't just zeroes. That's a lot of blocks; bzip2'ed, I had already 1.5G before I killed it.

Fortunately, an easy 'bzgrep' told me that the file was, indeed, in there somewhere.

I did a commit now. Just to be sure

FreeBSD? Nope.

On my laptop's hard disk, I have this small secondary partition that I use to fool around with. It's had installations of all sorts of things, including Debian woody (back when that was still stable), MacOS X (which came with the thing), ubuntu, and (currently) Gentoo. The motto being that you can't love your own system (in my case, Debian Unstable) unless you know what other systems look like.

Since I'd gotten tired of Gentoo by now, I wanted to try something else. As $SUBJECT probably tells you, that something else was FreeBSD for PowerPC this time.

Only after booting I found out that my keyboard doesn't work. As it apparently is documented.

Well, that's it, then. No FreeBSD for me. Let's see what NetBSD looks like.

Weight loss

I thought my loss of 20kg over a period of two years was kinda impressive. I was wrong.

Whoa.

Norbert, congrats. I only hope you did it in a way more healthy way than I did (which basically boils down to "eating way less than I should, and having bad eating habits when I do").

Prospective talks for the Debian Devroom @ FOSDEM2006

By request:

Here's a list of people who've confirmed they're going to give a talk in the Debian Devroom at the next FOSDEM. This list isn't final yet (there are some more people who've asked for a time slot but did not confirm yet; and I didn't assign slots yet, either) but it might be interesting for those who are coming to have a preview of the subjects that will be available.

Well then.

Lars Wirzenius: Nobody expects the Finnish Inquisition: Confessions of a package torturer

Piuparts tests that .deb packages can be installed, upgraded, and removed without problems. Lars uses it to torture all the packages he can get his hands on. This talk will explain how to use it on your packages before uploading them, and thus improving their quality and not having them suffer in Lars's hands.

Martin Zobel-Helas: Debian-Volatile - behind the scenes

This talk will give an overview of how packages are handled for Debian-volatile; what changes are allowed, how security is handled.

Martin F. Krafft: Improving workflow in Debian through process integration

This talk will be about the same subject as Martin's doctorate thesis. The abstract for that is:
This research paper/project details the technical challenges the Debian project faces as it continues its tremendous growth in size and popularity. It describes a research endeavour designed to increase the use of version control within the project for improved coordination of globally distributed teams of volunteers working on the software packages that make up the system. The research primarily focuses on the integration and consolidation of the involved processes. With tools already available for some parts of these processes as well as the coordination of teams, the goal is not to reinvent the wheel, but rather to reuse and improve these tools, to better integrate them, and to make them more accessible by providing abstraction wrappers with interfaces intuitive to Debian developers. It is further the intent for these tools to be optional and fully compatible to existing practices, thus not forcing developers to adapt. The research starts with process analysis and studies of the work habits on the side of the developers, and targets the final output of tools, which implement improved workflow in Debian package management through meaningful integration of existing (and proven) methods

Enrico Zini: Debtags, and what you can do with it today

This talk will introduce the Debtags project, what it has accomplished so far and the wonderful advanced tools that are now available, using debtags, to make sense of the huge package archive.

Bill Allombert: Inside the Debian menu system

The debian menu system transparently keeps the menus in sync with the list of installed applications; so transparently, in fact, that a lot of developers do not know how the system really works. This talk will detail the various components of the system, what the technical challenges are and how they are solved.

Frans J. Pop: Debian Installer internals

An introduction to the inner workings of Debian Installer. Starting with what happens when the installer boots, the talk will go on to discuss how the dynamic menu structure allows the installer to be adapted for different architectures and installation methods. Other subjects will include the special nature of udebs, the contents of a D-I initrd, how cdebconf knits everything together and allows the use of different frontends, preseeding and the use of hooks. If time allows, a short introduction into the build system and CD building may be provided. Some knowledge of Debian package management (like priorities and dependencies) is assumed in this talk.

Aurelien Jarno: The Debian GNU/kFreeBSD port

Debian GNU/kFreeBSD is a port of Debian using the FreeBSD kernel and a GNU libc library. It is currently the most advanced non-Linux port in terms of packages ported.
This talk gives an overview of GNU/kFreeBSD, and a quick comparison between the FreeBSD and the Linux kernel, to give users the necessary information to let them find how the FreeBSD kernel could fill their needs. It then describes the status of the port and the choices made concerning the architecture of the port (libc, threading library, etc.). It will continue by giving the various ways to try out this port and to give help, giving pointers to useful documentation and some useful hints.
Best portability practices are also covered, for both the Debian packaging and the upstream code. It will be based on real examples of non-portable code, and will show the best way to change it into portable code.

Summing the times that people gave me, I'll have anywhere between 5h25 and 6h00 of talks already, and two more people who've shown real interest in doing something in the Debian devroom (but who haven't sent me the information I ask for to be able to confirm their talk; please do so!). I'll probably get 9 hours in all (10 if I squeeze a little bit; but then I might have some issues with the key signing party, which I'm also co-organizing), so there is still some time left for interested parties. However, if you're interested in giving a talk, you shouldn't wait too long anymore!

Almost...

... there.

There's a particularly nasty project at work that has been stressing me over the last few days/weeks/months which has now almost, but not quite, reached a successful conclusion.

It required some financial creativity to get it there, though. But that's a piece of the past now—I managed to reduce it to a technical problem; now I only need to fix those, and I'm done.

I wish tomorrow was over already. But, well. I'm very close.

In other news, something exciting is happening for the m68k port. But more on that later.

Blondes.

How to keep a blonde busy.

That's a really good one.

Wanted: the m68k ABI spec

I've been looking for this everywhere. Unfortunately, it does not appear as this is available in any other form than a book from Prentice-Hall. To make matters worse, the book is no longer in print.

Its ISBN number was/is 0-13-877663-6. If anyone has a copy that they can miss, I'd appreciate it.

On flames.

What's worse?

Making an honest mistake, making fun of someone making an honest mistake, or making a silly fuss about someone making fun of someone making an honest mistake?

The answer to that one is left as an exercise to the reader.

CF/68 binutils

Work on patching binutils is progressing nicely. I don't have the board itself yet, but I'm preparing modified binutils already; for now, I've added a -mcf68 flag that would only allow those instructions that are common to both processor families. It's not finished yet, though—though most integer instructions have been done, I still need to start on the floating point instruction set, and even for the integer instruction set some of the insn patterns are rather... complex to understand. But by comparing both programmer manuals to the insn patterns, it's doable. Somewhat.

While in the middle of all this, it's very sucky to forget your laptop's adapter at work, however. Especially if you've been working on batteries most of the time already, and they're almost empty, and your only copy is on the laptop's hard disk.

I've been able to copy everything important from to my desktop just in time; about a minute after it was finished, the laptop's screen went black. I'll have to work on this box for the rest of today, I guess.

There's an alioth project called debian-coldfire if you care to have a look—though it's rather empty for the time being. More news when it's there.

Oh, and I'm still looking for a copy of that book, which would be very helpful when we start doing the compiler bits, or in finding out the cause of #345574.

Vitiligo

The koppen program on the één station in Belgium just broadcasted a reportage on vitiligo, a skin disease which involves a loss of pigmentation on some parts of the body (whereas other parts are unaffected). The result is that those parts of the skin do not tan. The reportage featured three people suffering from the disease; a young girl, one woman who was a bit older, and one rather well-known Belgian actress.

The interesting bit about this reportage, for me, was the name of this disease. I've been a vitiligo patient myself ever since about the age of eight—during summer, my hands often look similar to the hands of the young woman on the picture of the wikipedia page—but no matter how often people would tell me, I always forgot its official name, instead calling it "pigment spots" or something. This blog post is as much an outing that I have this skin disease as it is a way of remembering the name. Heck, while writing this post I got distracted for a while, and when coming back to it, my first subconscious reaction was that it should read "Vertigo". Which is something entirely different, and also not unknown to me. But that's for a different time.

Not that having Vitiligo matters much to me. By itself, it doesn't either hurt or itch; and during winter, when the rest of my skin isn't tanned, it's hardly visible. If at all. All I need to do is to take care that I don't get too much sun during summer, because a tanned skin is a protection against the sun; without it, you'll get sunburn more easily—and those white patches don't tan. And yes, believe me, when those patches get all red because of sunburn, they itch. Like hell. But then, since I'm a computer guy who likes nothing better than to stay inside with a computer all day, that's not really a problem...

Identity crisis

Debian GNU/Linux 3.0 barok tty5

barok login:
Debian GNU/Linux 3.1 barok tty5

barok login:
Debian GNU/Linux testing/unstable barok tty5

barok login:

That's what I'm actually seeing on barok's monitor right now, after it's been running for a while. Yup.

XFree86 still amazingly active.

Quite a while ago, the XFree86 people managed to finally piss off everyone with their license change to the XFree86 1.1 license, so that everyone upped and went back to X.org. After that, they released XFree86 4.5.0, but nobody's been looking. So, I wondered whether they'd still be active, and what would be going on. The X source is quite a lot, it'd be hard to manage that with just a couple of people. Would be interesting to see what they've been up to, I thought.

So I went and had a look at their CVSweb server, to see what the recent commits were. If there were any.

Well, there have been. The latest commit I saw was the one by David Dawes, all over the tree, done 11 days ago. It goes like this:

===================================================================
RCS file: /xf86/anoncvs/cvs/xc/lib/X11/ConnDis.c,v
retrieving revision 3.32
retrieving revision 3.33
diff -u -r3.32 -r3.33
--- xc/lib/X11/ConnDis.c	2004/06/24 02:21:15	3.32
+++ xc/lib/X11/ConnDis.c	2006/01/09 14:58:24	3.33
@@ -1,4 +1,3 @@
-/* $Xorg: ConnDis.c,v 1.8 2001/02/09 02:03:31 xorgcvs Exp $ */
 /*
  
 Copyright 1989, 1998  The Open Group
@@ -24,7 +23,7 @@
 in this Software without prior written authorization from The Open Group.
 
 */
-/* $XFree86: xc/lib/X11/ConnDis.c,v 3.31tsi Exp $ */
+/* $XFree86: xc/lib/X11/ConnDis.c,v 3.32 2004/06/24 02:21:15 tsi Exp $ */
 
 /* 
  * This file contains operating system dependencies.

Yes, very crucial commit. Wait, it gets better: the commit message says 'Remove most foreign cvs keywords.' "Most"? You mean you've been slaving at all those files, carefully removing the Xorg headers, and you've left some behind? Are you kidding?

But I'm not being very fair to them, obviously. There've been more commits over the last year, and most of those did not relate to comments in the code. They relate to the Imakefiles. They've been doing nothing but fixing the build system. Wonderful, isn't it? Those pesky Imakefiles...

So that's it? Comment changes and build fixes? Nothing else?

Well, no. I'm lying. There's also been this:

 161. Implement a major #include rework throughout the tree.  Also enforce it
      for all non-external builds (i.e. in-tree & SDK)  (Marc La France).
 160. Rework the building of hw/xfree86/parser to be more in line with the
      building of other server subdirectories (such as common/)
      (Marc La France).
 159. ANSIfy /xc/lib/font/builtins/, and fix warnings, whitespace & formatting
      (Marc La France).

A major #include rework? Wonderful. Must be some great new feature, right?

Almost:

@@ -62,8 +61,8 @@
 
 #include "attributes.h"
 
-#include "Xlib.h"
-#include "Xresource.h"
+#include <X11/Xlib.h>
+#include <X11/Xresource.h>
 #include "Xrm.c"
 
 static XrmDatabase CopyDb(XrmDatabase inDb);

Yes, very useful.

I didn't go through the entire tree (have better things to do) but, really; if this is the average quality of the commits they've been doing, one wonders why they don't just give up. Oh well...

Retaliating to spam.

How do you fight spam?

Not through regulation. Spammers will find loopholes and exploit them. You can plug the loophole, but then they'll find another one. And some spammers will just not care, try to avoid the cops. Sure, eventually they'll get caught, but for every spammer caught there's ten more waiting.

Not through technology; that's an arms race. Improve your filters, and the spammers will just modify their mails to slip through again.

I don't think it is possible to fight spammers. But you can take revenge...

Let's look at a typical nigerian scam:

From: foo@bar.baz
To: wouter@grep.be
Subject: PLEASE HELP
Date: some_date_in_the_future

Hi,

My name is <the name of a relative of someone rich who died>.

I have <some problem involving an amount of money that I cannot get
at>.

Could you please <do something which will cost you a lot of money>?

Thanks.

PS: please, reply on my private email address <scammer@scam.com>.

The important phrase is the last one: if you could please be so kind as to reply to their "private" email address. Obviously that email address is a throwaway one; but one would expect that they must read it and hope someone replies to it before the amount of spam on that address gets too high to reasonably be able to read it.

Which is the catch. I wonder how those spammers would react if I would start adding their "private" email addresses to some database and, rather than throwing away mails which are so obviously spam, start forwarding them to random addresses from that pool...

Yaboot acting up

I'm noticing some strange behaviour in yaboot lately: when I switch on my laptop, there are times when it simply doesn't boot; instead, it gives me an error message about memory and something being too small (I'll write down the exact message next time if someone needs it to debug) and then drops me into OpenFirmware.

I can switch it off and on again at that point as much as I want to, but it will continue to fail. At one point it didn't even drop me into OpenFirmware anymore; instead, it looped over the first-stage booter all the time.

The only way I have found to make it boot again is to put in a bootable CD-ROM that uses yaboot to start, such as a Ubuntu live-CD. It doesn't even have to actually boot; just making sure I start yaboot from that CD once is enough.

I find this very strange, especially as the second time it happened, I didn't change anything that could remotely be related (the first time I did remove a kernel image). So before I start debugging my hardware: anyone else seeing this?

Ten ways to make a buildd admin's life miserable.

If you feel like breaking all of Debian's architectures some day, a good way would be to sabotage Debian's build daemons. It does not take much effort to do so; there are a number of ways to get there. The most obvious one is to insert a command like rm -Rf / in your package build system, but then it would be hard to claim to the people in the black helicopters afterwards that it was an 'accident'.

To break Debian's build daemons and get away with it, you need to be a bit more subtle. Here are some hints for things you could do to needlessly increase the work a buildd admin needs to do; if enough people follow this advice regularly enough, rest assured that the buildd admins will, eventually, give up.

1. Make your build loop, but still produce output all the time. Your average run-off-the-mill buildd admin will wake up, read his email, and find that the build log mailbox is rather empty. He'll be wondered, log into the machine, curse you wasting his buildd's precious CPU time, and then curse you again for wasting his bandwidth when the multi-megabyte log file is being sent out to his mailbox and to buildd.debian.org (or, as in this case, experimental.ftbfs.de).
2. Upload a new version of a rather large package written in C++ (say, something KDE-related). Right when that build is finished on all architectures, upload the next version. Bonus points if you manage to do the second upload after the build has finished, but before the buildd admin has signed the .changes file. Extra bonus points if you manage to do all of that during a backlog.
3. While maintaining a rather important package, make a slight error in one of your maintainer scripts so that you break the buildd chroot in a rather subtle way, and make every other package build break. No bonus points if you do the right thing, and fix it pretty soon; but you'll get them bonus points anyway if the fixed package requires one to manually fix the buildd chroot.
4. Break your postinst script so that it does not ever exit. Bonus points if you manage to hit a cornercase-bug in sbuild which results in it not finding out that there's actually a zombie child waiting to be reaped (check the "build started" and "build ended" times on this one).
5. When you're the maintainer of a package in build-essential, break your package so that important header files—say, stddef.h—are gone.
6. Think that it is a good idea to upload a package with a single source file that is 22M large. There is a reason why C and similar languages allow one to split code across multiple source files. Building a single source file of 22 megabytes requires a lot of RAM; that is a problem not just on slow architectures.
7. Upload a package that hides the compiler command line while compiling. Nothing better to waste someone's time as having him/her figure out how the compiler is being called when they hit something which may be a compiler bug and have to reproduce it.
8. Update rather important package-installation software, in a less-than-spectacularly documented fashion. Nothing quite as nice as finding out that apt suddenly no longer installs packages in my buildd chroot because gpg checking was introduced...
9. Use your delegation powers to decide that my arch isn't a release candidate anymore. Okay, so that was our fault. Whatever.

And, last but not least:

10. Take all of the above too seriously. No, really. It's only a joke.

FOSDEM keysigning

wouter@western:~$ gpg --no-default-keyring --keyring .gnupg/importring.gpg --list-keys | grep '^pub' | wc -l
39

Which is not to say that 39 people will be attending; only that there are 39 keys, since some people have sent in more than one key. If you want to participate, all you have to do is to go read the instructions and send in your key.

Whee.

According to the graphs, we are now officially no longer the worst architecture! Whee.

Not that I feel happy for the hppa folks, but we've been in this position for way too long already, now. It's about time we got through this. Therefore: Whee!

Of course, the fact that we're not the last in the list now does not mean that our problems are over. There's #345574 to care about (and, hence, #340563; and there are a bit more issues like that one that will need a bit of love to be resolved. But we're going in the good direction again, which is great.

In somewhat related news, some of our ColdFire eval boards have arrived at their destinations already. Unfortunately, mine has not arrived yet; but I presume it will rather soonishly. I should probably finish patching binutils to handle those FPU instructions as well, so that I can start testing and comparing...

nbd-tester-client

Prompted by #350357, I did something I've planned to do a long time already, but had so, so far, failed to do: I wrote an nbd-tester-client. All it does currently is a sequential read of the entire block device, but it's written in such a manner that it should be easy to add additional tests—say, random reads, or write-read-verify cycles.

Not that I actually needed such an application to identify and fix the bug (which boils down to a forgotten return 0 somewhere halfway the code; upload on the way), but it's a good thing none the less. It even pointed out one problem with nbd-server: that it will do write() calls without select, thus allowing for a deadlock if both the client and the server have a full write queue. I'll fix that for NBD 2.9 (might be too intrusive for 2.8, and I'm not sure whether the kernel actually writes without waiting for its write queue to be emptied).

The code is in CVS HEAD, if you want it.