So I wanted to see how is the lzma support in libarchive, since there is now a stable release having my lzma patch, but pacman-g2's make check fails with the new version, sigh.. It looks like some file descriptor leak, it does not like when we try to install 1000 packages with pacman at once.

So we had this bugreport, just building miro against python 2.6 did not work out very well. Then I pushed a python-2.5 package, before I would realise all the miro deps would have to built against py25 as well, if I want to achieve this approach. OK, that's a no-go. Then I found the right few-liner solution in the #python@freenode logs. :)

I sent it to upstream, we'll see how will they handle it.

Oh, and I got a new patch to darcs-fast-export. A second contributor, yay! :)

I got a reply to patches I sent one and a half year ago. ;)

My patches to anames.pl and sockter-interface.pl are now applied in f0rked's irssiscripts repo.

Heh, it took my whole day. So the solution was that I needed to disable two CONFIG setting Crazy enabled (+ I enabled KVM again, not sure if that is related or not).

And of course bisecting was totally damn unnecessary, since the bug is triggered by a given config line, not by a bad commit.

Life is good.

So I reported this "timer runs too fast" bug to LKML and they asked me to bisect it. I know bisect already, but I only bisected userspace software which is easy. Basically you write a script that reproduces the issue, then git bisect will find the first bad commit automatically.

With the kernel, this is much slower, because you must manually test each step.

Of course I wanted to speed things up, so I wrote a small testcase and run it right after init=/bin/sh. This is bad. I haven't noticed until almost the end of the bisect that the bug occurs only after udev is loaded. Now that I'm sure the corrected test script really reports GOOD for 2.6.27 and BAD for 2.6.28, I can do the real bisect...

As a side note, doing this with 1 machine would be really annoying. Luckily I can do whatever I want on my iBook, the build is done one of our fast Frugalware servers (dream) and I just download and test the bzImage on my notebook. I guess network booting would make it a bit faster (because currently I boot the test kernel, boot back the working one, download the next test one, goto 1), but I won't set up a whole tftp server on my iBook just for this. ;)

So hopefully tomorrow we'll know what is the real first bad commit.

I finished the update to 2.6.28 (I mean fixing external modules) in a WIP repo, will merge it tonight, if everything goes fine.

OTOH it turns out that the net in qemu-ppc is disabled because the driver is disabled in the ppc config. So I'll have to enable those drivers when I sync.

Oh and a trick. mplayer -vo null -vc null will stop playing audio if video finishes earlier. mplayer -novideo won't. So that'll be the solution for my "sample music gets truncated in an flv-wav-mp3 conversion" problem. ;)

Finally the W3C css validator guys are nice, see this thread, basically it works fine now! :)

After upgrading kernel to 2.6.28 my clock measures about 70 mins in an hour, sigh. We are debugging the issue with crazy, but probably it's not a user error, so we'll need to mail the lkml.

I just tried qemu svn, and it's amazing.

qemu-system-ppc -prom-env 'boot-device=cd:,\boot\yaboot\yaboot' -prom-env 'boot-args=conf=cd:,\boot\yaboot\yaboot.conf' -cdrom frugalware-1.0pre2-ppc-net.iso -hda ~/documents/qemu/hda.img

can boot the 1.0pre2 ppc netinstall iso! :)

The current problem is that the network card the machine emulates is not supported by the installer, but that'll be tomorrow's problem.

I recently ported our Qemu package to PPC, and just tested that it really works. We have a Linux binary (compiled for i386) for some 'plan making' exercise (inside the AI course at the uni), and of course I wanted to run it on my iBook. And yes, just wrapping the command with qemu-i386 made it work! :)

The other problem I noticed is that building external modules on PPC does not work. It seem to be a known bug. PLD has a patch that changes the error message - to a permission problem. Given that on x86 building a kernel module is possible as a user - the goal would be the same on PPC as well. Not yet resolved...

Quoting a mail I just sent to Miller:

,,It seems I hit a bug in sudo-1.7.0 (at least I can't reproduce it with 1.6.9p17):

$ sudo chown vmiklos /etc/sudoers $ sudo false sudo: /etc/sudoers is owned by uid 1003, should be 0 Segmentation fault

According to gdb, it seem to be a nullpointer-dereference bug, and given that it is reproducible only in case the permission and/or owner is wrong, I don't think it has a security impact. But who knows. ;)''

We'll see how does he handle the problem.