Hello 2.9.0!
No, not the Linux release of that version (that's still far away, if it will ever be developed, and I don't think I'll be wanting to run that if/when it does).
Instead, I'm talking about the NBD userland tools of that version, which I just released. Today we're only a few weeks after the release of 2.8.7—sorry for all you packagers out there who now have to throw away your work. But it's well worth it; nbd-server now finally functions like a real UNIX daemon: you specify exports in a configuration file, you can export more than just one export from the same server, and it has some interesting new features today. If you ever looked at nbd-server and decided that the way it's implemented is too hackish for your taste, then 2.9.0 may be a good time to revisit that opinion.
Of course, I should note that 2.9.0 is a .0 release, so does still need some testing in the wild, so might not yet be ready for your production server. But other than that, it should be pretty much okay and usable.
Give it a try!
In related news, Ronnie Sahlberg, one of the wireshark developers, has made my day by writing an NBD dissector, which I've been wanting to have for quite a while now. Happy happy, joy joy.
Errrrrrr...
[Wed Nov 01 22:33:32 2006] [error] [client 127.0.0.1] (21)Is a directory: Could not open property database. [500, #1]
So, we fix that.
wouter@country:~$ sudo rmdir /var/lock/davlock wouter@country:~$ touch /var/lock/davlock wouter@country:~$ sudo chown www-data:www-data /var/lock/davlock
That should fix it, right? Wrong.
[Wed Nov 01 22:34:15 2006] [error] [client 127.0.0.1] (20)Not a directory: Could not open property database. [500, #1]
Right.
The fun bit about this is, I was having issues with a mod_dav installation where the authentication was being done by mod_auth_kerb. Which at first wasn't possible because of #395931, but luckily there was a workaround. But then, that approach was not without its share of issues, either:
[Wed Nov 01 21:15:03 2006] [error] [client 192.168.0.101] configuration error: couldn't check access. No groups file?: /
Oh well, stuff it then. I'll use a different way to get this done.
One year of Planet Grep.
Well—almost, anyway. Planet Grep was launched on the 28th of November, 2005, at which date it managed to collect an astonishing 117 hits, for a total of 9,23M. At least that's what my awstats pages say (they're on samba.grep.be, but don't bother trying to read them—you need a Kerberos account in the GREP.BE realm to do so). I guess I should wait 'till the end of the month before posting a post such as this one, but I got interested due to the poking of one particular individual who would fit the target personae of Planet Grep had he had a blog.
It might be nice to try and figure out whether it's been a popular year. And I would say that this is the case: the next month, it surpassed the bandwidth usage of my regular site at grep.be, and by the end of January, it had almost double that amount (789M for Planet Grep vs 372MB for grep.be).
Pretty quick start, that.
These days, bandwidth usage has risen to a good 2G of bandwidth each month (on average), where it has stagnated (the peak was in june at 2,33G). That's about 55M per day, on average. Not bad for a simple business ADSL line.
Contrary to what I'd expected, the site is most popular on wednesdays (59M, or 646 pages on average), rather than in weekends. In fact, weekends sees the lowest number of hits (even if it still reaches a good 50M). But that's easily explained if we look at the hours during which Planet Grep is most often consulted: most of you seem to take a quick peek at this page just after lunch break (between 14:00 and 15:00). Shouldn't you be working, no?
Ah well. It might also be interesting to note that most of you use an RSS reader. 132039 hits were to /rss20.xml, 31297 were to /rss10.xml, and only 18594 hits were to the main page.
Which is probably the reason why 73.4 % of you use an unknown browser, and 56.1 % an unknown operating system. But at least Firefox and Linux occupy a good second place on both lists, which is what I care most about.
Let's see what happens a year from now, shall we?
FOSDEM Call For Talks for the Debian Devroom
I just (well, over an hour ago by now) sent out the Call for Talks for the Debian Devroom at the upcoming FOSDEM. If you're interested in giving a talk there, now would be a good time to let me know.
From 2 to 5
One thing about being an m68k porter is that you get to play with hardware a lot. And I mean a lot. Ska, jazz, newwave, and barok had all died during the last few weeks to months; so I was back to two working m68k machines that I could somewhat work with (quickstep, a 25Mhz 040 that I own, and arrakis, a 50Mhz (or so) 060 owned by Ingo Juergensmann). Which was not enough. To make matters worse, arrakis had actually died last week, but that was fixed quickly enough (thanks, Ingo).
Which had left me with non-working jazz, barok, ska, and newwave.
It isn't the first time that newwave dies on me, and it isn't the first time that a simple power-on again fixes it, after a few weeks of downtime. I can only conclude that this isn't a box which likes being powered on all the time, and that I'll have to leave it powered off for a few weeks every now and then. That's not a big issue, since the machine isn't very high on RAM anyway, so not very useful (apart from testing EMILE on, and other similar things).
Barok had died a few weeks ago with a kernel oops that it couldn't even print out entirely. If that sounds like hardware failure, that's because it is hardware failure. Luckily, it's nothing too bad; removing the expansion cards one by one and replacing them afterwards revealed that it's the cache RAM which is the culprit. That's good news and bad news at the same time; good, because a Macintosh IIci can work without this cache RAM (it was sold without those things after all; the cache expansion was an option); bad, because it already is the slowest machine I have, and losing the cache doesn't make it speed up. But at least that one works again—if any of you have some IIci cache lying around that you don't need anymore, feel free to send it my way.
Jazz had only paniced, like it does every time. It's a Quadra 950, and those have never been very well supported by Debian. I just needed to reboot it, which I forgot about every time I got near it. It's working again now, compiling away at the next EMILE version, which will fix a few bugs and should make it into etch. Or, well, at least it would be, if not for the b0rken debian/rules file, which I will now have to fix, I guess. Not that this isn't anything I can't handle.
Leaves Ska, which needs a new hard disk. That's not a big problem, I just need to get around to flinching me one out of the old unused RAID array at the office, low-levelling it, and placing it in ska. Which I have been planning to do for only, eh, three months or so. Whoops.
Release status
I love this time in the release.
Debian GNU/Linux 4.0 country tty1 country login:
Usually, that says testing/unstable rather than 4.0; and yes, country runs unstable. But since you can only get packages into testing by going through unstable, that means at some point (preferably as late as possible), unstable has to claim it's 4.0
After that, we're up to freeze, and then a few months later we've got our new stable. Isn't that cute.
Hardware support
A while back, my brother's computer had issues. It would dump core of
random programs, and would produce a BSOD under Windows at random times,
too. Running memtest86 showed that something was wrong with the memory,
so we replaced it. Unfortunately, that didn't help; so the conclusion I
made was that there was something wrong with something between the
processor and the RAM
—the cache (L1 or L2), some data or
address line degrading, or perhaps even the memory controller. In any
way, that didn't matter; what mattered is fixing the issue.
So we replaced the mainboard and the processor with something newer. He's now got a pretty modern mainboard, with all the interesting bits and pieces found in such a thing, and a Dual Core Pentium4 at 3.4Ghz. Occasionally, I must say that the socket 775 is pretty... weird. But I digress.
Upon installing everything, I found that trying to run the system with broken memory had managed to corrupt whatever was on the hard disk; his ReiserFS superblock thought the filesystem was some incredible amount larger than it really was, and Windows would turn up a BSOD before even booting. The first was pretty easy to fix; I hit 'e' in the grub menu, added init=/bin/bash to the end of the kernel command line, and instructed some tool from the reiserfs toolkit to fix the filesystem. After that finished, and after a subsequent exec /sbin/init finished, Debian was up and running again. That took all of a few minutes. Having booted it, I proceeded to install the security updates that had accumulated for Sarge since the time his system had started to break down (which is a few months). Then I realized that I had to reconfigure the system to understand the new mainboard.
Only that had already happened. Hotplug, discover, and perhaps some friends, had all done their work and there was nothing to be done anymore. Isn't that nice.
The same couldn't be said for Windows. Booting from the install medium and choosing "recovery" in the install menu didn't fix things. Even reinstalling the system without formatting the hard drive didn't get us any further. The only thing we could do was to wipe the drive clean and reinstall.
Windows better hardware support? My ass.
Me too, daddy, me too!
According to Aurelien Jarno, it's possible to run Debian/ARM and both Debian/MIPS platforms inside an emulator that itself is packaged and runs on Debian.
Since fairly recently (about a month or two, I guess), the same is true for Debian/m68k. Granted, the emulator you need to install isn't called "qemu", but with ARAnyM (short for 'Atari Running on Any Machine') it is now possible to run Debian/m68k. And it's fairly easy to do, too:
- Download the installer images for Debian/m68k
- Install the aranym package
- Run aranym once. This will create a directory .aranym with a default config file.
- create a file to be used as a disk image: dd if=/dev/zero of=./disk.img bs=1k seek=2M count=1.
- Edit the configuration file. The important bits are the section [IDE0] and [LILO]. It's pretty self-explanatory.
- Run aranym-mmu -N -l.
There, you have a free m68k development machine!
Note, however, that there might be issues with the network interface;
the NIC in the emulated machine is unlike any real, actual Atari
hardware. There is a driver for Linux, but I'm not 100% sure whether
it's been integrated in the Debian kernels yet. I'm sure Christian will kick me awake
on this, though 
Rock's kernel
I've decided it's been enough.
Rock has been running 2.6.12 for ages. Not because I didn't want to upgrade, but since 2.6.12 was the last Debian-packaged kernel that would actually boot on rock. You see, this machine is a rather old SMP system, and there seems to be something wrong with its interrupt system. It would boot if I used a uniprocessor kernel instead, but then it's pretty silly to have a box with two processors, and only use one of them...
At first I ignored it, assuming it would get fixed some time soon. Unfortunately, that didn't happen. And since we're at 2.6.18 right now, and the kernel team has done away with uniprocessor or SMP-only kernels, that means I can't even upgrade to the latest kernel anymore, even if I'd want to.
I've been using git-bisect for the last few days in an attempt to find the issue, so that I can report it... only today I realized that I did remember 2.6.13 not to work, but that perhaps it failed for reasons not related to my current problem. Downloading that package from snapshot.debian.net and verifying showed that this is, indeed, the case. Grmbl.
So I had to start all over again... Not fun.
After starting that, I suddenly found out that make-kpkg didn't want to be friends anymore:
LC_ALL=C make-kpkg --initrd --config oldconfig --rootcmd fakeroot kernel-image exec debian/rules DEBIAN_REVISION=2.6.13-10.00.Custom INITRD=YES ROOT_CMD=fakeroot kernel-image debian/ruleset/targets/source.mk:34: *** target pattern contains no `%'. Stop. wouter@rock:/usr/src/linux-2.6$
Hate. Grmbl.
#include <stdarg.h>
The stdarg API, which allows you to use a variable number of arguments to a function in C, is pretty fun. However, it's also pretty limited in what it allows, to a degree that it invites people to try and find workarounds to things you can't do with the API as it is documented.
Unfortunately, this almost always breaks when the software is compiled on hardware that happens to be not your own, as there is a reason why stdarg is implemented the way it is: portability.
A (not so) recent discussion on #debian-devel on OFTC showed to me how this confuses many people. Don't worry—it confused me too, the first time I had to think about it.
The problem is that in order for stdarg to be able to do what it does, it needs to read function arguments from whereever they are stored. Where that actually is depends on the operating system and the hardware you're using; it could be on the stack, but e.g., the SPARC architecture actually has a mechanism to pass parameters using processor registers (although those are most likely not used when stdarg is in use, since the number of parameters that can be passed that way is obviously pretty limited). If parameters are on the stack, then you may be able to just access the memory as you would access any random variable; but it could also be the case that you need to take some specific steps to access the stack, or perhaps your architecture or operating system has some protection for stack-based security attacks, which would make it impossible to directly access memory on the stack that is actually part of another subroutine.
So if you try to do anything that isn't defined in the stdarg api (like trying to figure out the number of arguments by peeking inside the va_list data type, or passing a va_list to another function without using the C99 va_copy macro) will break. Yes. Very sorry.
Curses
Yes, the console library. I'm learning it right now.
It's pretty neat, but it's got some ugly bits.
getmaxyx() is one of those ugly bits.
That is all.
Grep.be (and related)
Yes, my domain has been off the net for quite a few days now. This was related to the Internet connection that's in front of most of that domain being down. I'm quite very extremely unhappy about that. It's not as if that connection is a cheap one, and I would've expected a slightly better service for the price I'm paying. As it turned out, it wasn't my ISP's fault, but then still.
Of course, it's all working again now, and I'm a bit happier. I will start thinking about making sure this connection is no longer an SPOF, however. That should help...
Planet Grep mirrorred
Yes, Kris: everything is a fscking^W, eh, Funky DNS problem. Or, well, at least, every problem can be solved by use of some smart DNS tricks.
Planet Grep is now mirrorred on Christophe Vandeplas' server, and both servers are now published in DNS for planet.grep.be; so, next time our link goes down (hopefully never), at least Planet Grep will not cease to exist. Isn't that wonderful?