Those of you that have a very good memory might remember me writing patches for the Evolution e-mail client to make it support newsgroups. And I didn’t do it just for fun, either: as part of the Gnome Desktop Integration Bounty Hunt, I would earn $750 with it.

Now, my patch was accepted on 12 January, and now I finally received the cheque… though I was pretty convinced myself the money would come in the end, the non-arrival of my bounties was becoming quite the source of fun for others.

The good people of GNOME didn’t quite seem to be in a hurry, either. A small reconstruction:

On 8 February, after another bounty winner writes a message to the evolution-hackers mailing list asking about the money, the GNOME people claimed:

Oh! If it’s in the Round One, then we’ll send it sooner. I’ll make sure Ben gets your address; he’ll contact you if anything else needs to be arranged.

We’ve been kind of slow about this– LinuxWorld Expo had us running around busy for awhile. Sorry it’s taken so long!

While that was quite encouraging, it took them another month before they got to the point where they were needing my address: on 19 March, I received a congratulatory message that also asked for my postal address:

Congratulations for winning the Desktop Integration Bounty Hunt prize #127519: Finish NNTP support in Evolution in the amount of $750.

After another month, I got a bit nervous and I wanted to know what was going on. On 6 April, I got the following response:

Novell is processing its Sponsorship funds for the Bounty competition. I expect the GNOME Foundation will be sending you a check by the end of the month.

After three more weeks, things were speeding up a little. I got this on 29 April:

GNOME Foundation has received the funds from Novell for the Desktop Integration Bounty Hunt and will be sending you a check next week.

And now, finally, on 25 May, I actually got the check. I have forwarded it to my bank, so I’m kind of hoping the money will be on my account soon. It’s not that I had been needing it desparately, the GNOME organisation just seems to be a bit badly organized if this kind of thing takes so long…

After my earlier painful attempts at getting the Mandrake LIRC packages to work, I tried the all-new Mandrake 10 this week. And I’m sorry to report the LIRC packages still don’t seem to work well. The /etc/sysconfig/lircd file was documented a bit better than in Mandrake 9, which was encouraging, but the damned thing just didn’t work.

My advice: just remove the Mandrake LIRC packages completely, reboot, and fetch the good stuff.

Why it didn’t work I’m not sure, but there’s something very wrong, that’s clear. The thing is the people ad Mandrake found it nessecary to change the default locations of communication files LIRC uses, which not only makes Mandrake’s LIRC incompatible with software that assumes the normal LIRC locations, but which also seems to have been done a bit half-heartedly.

In fact, the whole Mandrake LIRC package seems to have been a quick and dirty cut-and-paste operation. For example, the init script for LIRC uses the setserial tool, but the package doesn’t have a dependency to it, so you need to look at the script to see why it doesn’t work.

Also, the following messages appeared in my syslog:

lircd 0.6.6[2647]: could not get hardware features
lircd 0.6.6[2647]: this device driver does not support the new LIRC interface
lircd 0.6.6[2647]: make sure you use a current version of the driver

Strange: I had only installed Mandrake-made LIRC packages then. Also, I got

lircd: lircd shutdown failed
kernel: devfs_remove: lirc/lirc0 not found, cannot remove

This should have been lirc/0, the name of the LIRC device. Today’s lesson: not supplying packages is better than supplying packages that don’t work at all.

As the more enthusiastic visitor of my website may recall, I talked about this earlier: the Pooier 666 performance that was supposedly going to be held on 21 May.

Well, as you can see, the date has passed, and unfortunately, there doesn’t seem to have been a Pooier 666 performance at all Obviously, last friday, we did some research, but the Pooier 666 website still carried the “maybe perhaps hopefully we’ll play in roden in May” announcement, and the website of the place where it was supposed to be didn’t mention it at all. So after e-mailing one of the band’s members, calling the place, and admittedly even calling one of the Pooiers, with no results, we were finally forced to give up…

Just to remind you, this is what the Pooiers are all about:

Pooier 666 isn’t just a band, it’s a name that stands. In a short period, this punk combo has fallen from the level of one of the most drinking group of scum in Groningen to a band that goes on stages a few times a year to make itself immortal to the present plebs.

Well, now that there don’t seem to be any Pooier 666 performances coming, I guess I should just enjoy myself surfing websites about the Pooiers. Such as this interview with the bass player. About how they write songs:

(…) Someone has a riff, someone else has a riff as well, merge them, yell “fuck” and “die” and a hit is born. Stealing numbers is a thing we do quite often too, by the way.

About the performance in Vera:

That was fun. Especially the fog engine we brought. I heared the fog even made it to the hallway. Nobody noticed we played like shit. Everybody noticed we played the song “Work” 6 times. Well, that’s how you create thits. We had a great time.

Finally, much to my embarassment: check the first Google hit for “Pooier 666″….

Allright, I admit it. It was a bit too late, and I was a bit too positive when I wrote about the Stemwijzer source code protection earlier. Apart from the unescape trick, the source code that appeared was severely obfuscated as well, and I didn’t really feel like going through it thoroughly. Anyone who points me to a nice de-obfuscator to help gets a point.

Still maintaining my position that this source code obfuscation is pretty childish — especially here, where they refuse to tell how exactly they generate your voting advice, whereas it would seem a bit strange to just rely on some secret script to make a choice for you. Might take another look when I feel more like it.

I had been busy setting up my home cinema system for some time now, and now that’s it’s all more or less working, I decided to make a separate home cinema section for my website where I describe what I’m doing. It’s up now, and I will fill it with some tutorials over the next few days. No pictures yet though — seems my camera got lost somewhere. Stay tuned.

Here’s a small write-up of my experiences of getting Freevo to boot from the Lilo startup menu. The idea is that you’d be able to select Freevo in the list of operating systems (Linux, Windows, FreeBSD, …) on system boot, and when you select Freevo, Linux boots directly into Freevo in full-screen mode, enabeling you to play DVD’s, video and music and such. I did a similar thing for SuSe Linux some time ago, and doing this isn’t really that much rocket science — it just takes a lot of rebooting and testing and stuff.

Step 1. User configuration
The idea is to create a separate user, freevo, which will run the applications. First make sure you can run Freevo (with LIRC if you want that) fine just from your normal Linux login. For this, you’ll need to have a .lircrc file, and a .freevo configuration directory for the user.

Now, the important step here is to create an .xinitrc file in the home directory for the user. This file contains the commands that will be run when X-Windows starts. My contents are just:

/opt/freevo/freevo

We don’t need no window manager or anything else: just Freevo. I have it set to start fullscreen by default, so this works out fine. In the home directory, I also did a

ln -s .xinitrc .xsession

This ensures that both from the login manager and from just running startx the same thing happens: Freevo is started, and when it’s done, X-Windows closes down.

Step 2. System configuration
Now for the more tricky and system-dependent part: getting this to work at startup. We add an entry to the boot manager (Lilo or Grub) which passes init=/freevo/init as a kernel option, which will cause Freevo to be run rather than the usual runlevel routine. The normal Linux and Freevo entries from my lilo.conf look like this:

image=/boot/vmlinuz
	label="Linux"
	root=/dev/hda10
	initrd=/boot/initrd.img
	append="devfs=mount hdc=ide-scsi hdd=ide-scsi \
                acpi=ht resume=/dev/hda5 splash=silent"
	vga=788
	read-only
image=/boot/vmlinuz
	label="Freevo"
	root=/dev/hda10
	initrd=/boot/initrd-2.4.22-10mdk.img
	append="devfs=mount hdc=ide-scsi hdd=ide-scsi \
                acpi=ht resume=/dev/hda5 init=/freevo/init"
	read-only

Note I trimmed the “append” line a bit, the backslash should not be there and the line should just run through. Now we need an init executable. I created an executable (source) that just runs the /freevo/init.sh script, that does the actual work. You can download the script here, just chmod 755 it and place it into the /freevo directory, tailor it to your system, and you should be set to go.

This in combination with LIRC is just so great!

Now that LIRC finally works well enough on my box, and has worked over the last few weeks, I had almost forgotten what a pain it was to set up. Today, my brother celebrated his birthday with some friends, so he wanted to watch some movies on a beamer, and I agreed to set it up for him, and I figured out it would be nice to use my remote for that. While the beamer and stuff was easily set up within an hour or so, LIRC on Mandrake took considerably more time. I got exactly the same errors I had earlier (”Device not found” error messages” and stuff), insmod‘ing lirc_serial and editing /etc/sysconfig/lircd didn’t exactly work out either. Eventually I ended up downloading the real thing and installing from source, which went relatively problem-free (well, at first my kernel wouldn’t build and then it wouldn’t install, but that’s related to the fact that my Mandrake system was an upgrade from an earlier version — word of advice: never do that), so eventually it all worked just in time. Sure sounds like a screw-up by Mandrake to me. Better not distribute packages at all than bad packages that give the user false hope.

Yesterday evening, I accidentally dropped my receiver (well, twice actually :S), and, you guessed it, it broke! Hell of scare considering the work I put in it. Luckily, I succeeded in fixing it pretty quickly: just one contact didn’t work too well. Still it seems to be an awfully fragile business.

Now that I’ve gotten LIRC to work, I’m having some fun setting up applications to use it. A small write-up of my experiences so far:

Freevo
Freevo is a home cinema system which enables you to play video’s and music and watch TV on your PC. Installation of the program wasn’t difficult, just followed the documentation and ran

lynx http://freevo.sf.net/install.sh -dump | bash

After editing ~/.freevo/freevo.conf, I just ran ~/freevo/freevo and the program itself worked. Now for the LIRC support. I added the following line to ~/.lirc/local_conf.py:

LIRCRC = '/home/meilof/.lircrc'

I also added some buttons to my ~/.lircrc from the examples shipped with Freevo in the contrib/lirc/ directory. I also installed the required pylirc module (Mandrake package: python-lirc).

Thing is though, it doesn’t work! The program complains about being unable to open some file, supposedly the LIRC communication pipe. Thing is that Mandrake installs this as /tmp/.lircd, whereas applications expect this to be /dev/lirc. This file, on the other hand, is the directory containing the LIRC serial connection device file in Mandrake, and for some obscure reason I cannot remove the file, even if the LIRC module is not loaded. Maybe I should compile LIRC myself and see if that helps.

XMMS
Mandrake has a xmms-lirc module, but I can’t seem to find any documentation about that. Would be cool though.

Xine
Xine has a _huge_ amount of options controllable by LIRC, documented here. Would be nice if this would work. But since I installed Xine from packages originally designed for SuSe, I’m probably having the same problem as with Freevo.

Mouse controlling
Another cool thing is to be able to control the mouse pointer with LIRC. Quite easy to set up (documented here), but that document for some reason doesn’t describe how to do mouse buttons, so here’s how I do it:

BUTTON1_CLICK * MENU
BUTTON3_CLICK * TIMER

There are also BUTTON1_TOGGLE, BUTTON1_DOWN and BUTTON1_UP. Moving the mouse works well enough, especially with some accelleration (ACCELERATOR 1 30 10), but double-clicking a song in XMMS didn’t work at all. Besides, my circuit doesn’t work too reliably from distances of more than a few meters, which makes this a bit useless.

Found back my digital camera today, so I took a few pictures that should explain why I shouldn’t even start thinking about building my own electronics.

As is plain to see (well, plain… I know the image quality is pretty horrible, but then again the lighting was very bad, and my digital camera doesn’t work too well inside a house in general), my soldering skills are quite disappointing. Also notice the hole in the mouse that was supposed to hold the IR receiver. Though it isn’t /quite/ as nice as its inspiration source, I was actually quite satisfied with this. But than, that didn’t require any soldering.

Even though, in the next vacation, I’ll probably try my hand at this again, hopefully with some better results…