Athlon64

I recently applied a whole bundle of updates including alsa-lib on my Fedora Core 4 x86_64 desktop. Since then I started getting the error message

ALSA lib control.c:817:(snd_ctl_open_noupdate) Invalid CTL default
Open error: No such file or directory

whenever I tried to open alsamixer, and similar errors and crashes running other apps that expected to be able to use the Alsa sound system (which worked quite well before the update).

My wife had a printing emergency earlier today, so we now own a Lexmark z603 inkjet printer. Lexmark being one of the first manufacturers to bring out winprinters meant that I would probably have never agreed to buy one, but since I was asleep at the time the decision wasn't really up to me :-)

Update: Better than building from source, AT-rpms has a perl-Tk rpm in their yum repository - this is a far cleaner method of installing Tk. Add the following to your /etc/yum.conf:

[at-stable]
name=ATrpms for Fedora Core $releasever stable
#baseurl=http://apt.physik.fu-berlin.de/fedora/$releasever/en/$basearch/at-stable/
baseurl=http://apt.atrpms.net/fedora/$releasever/en/$basearch/at-stable

Wow. I just whacked in the Fedora Core 2 x86_64 DVD, went through the upgrade steps, rebooted, and everything just worked. Could not believe it.

Despite all the hoopla around regarding 4k stacks and the nvidia binary drivers, this is not an issue on amd64. I've heard that the 64-bit kernel in FC2 still uses 9k stacks, but I've not found out for sure if that's exactly why, or if it's something else. So far alsa seems to be working (I got it running on a 2.6 kernel with FC1, so perhaps I avoided some pain here since I was already configured for it), now we'll see if I can get jackd to build without core dumping when it tries to set the sample rate.

This little fix had me stumped for several hours. From a windows box, printing to a samba server using CUPS gives no joy. Windows has it's own drivers, so it will send raw printer instructions to CUPS, expecting these to be passed directly to the printer. CUPS usually expects to be able to do the data conversion itself using it's drivers, using a set of mime-types to recognise incoming jobs, and translating them to the proper printer language on the way, be it postscript, bubblespeak or whatever your particular paper-chomping animal speaks. CUPS seems to ship (on RedHat / Fedora at least) without support for application/octet-stream support. Is it just me, or is octet really hard to type?

Configure/LD fails to find or link to libqt-mt

This is not likely to be useful for anyone on it's own, but nonetheless it's something I had to do on my system to make Rosegarden-4 (a midi sequencer) build on my amd64 system.
Using the planet-ccrma src rpm, configure failed while detecting Qt. Investigation of config.log shows that ld (the linker) is failing to find libqt-mt. On FC1, that's in /usr/lib64/qt-[ver]/lib/, but the config script/ld looked only in /usr/lib64/qt-[ver]/lib64/, which kinda makes sense, but alas there be no library in those waters. Solution: