Free as in speech

The most common (and, in fact, visible) complaint concerning the New Maintainer process is the time it takes for the DAM to approve the applicant and, after that, create her account. No need to rehash over that.

Another very common problem seems to lie at the AM level, with a number of AMs being mostly inactive, as far as the NM process is concerned, for long periods of time. I know a number of NMs who are waiting for their AM to, basically, come back to life.

It’s not OK for an NM to have to wait for months for her AM at whatever step of the procedure without any reply whatsoever to her mails/IRC pings. It’s even less OK to have NMs wait for months for their final AM report to be posted on -newmaint.

The problem is not with the time taken by the whole procedure (though that can be improved too), the problem is with unresponsive AMs. If you can’t keep up, give up. Don’t let your NMs wait for you indefinitely.

It’s even worse when the AM wants to be the exclusive sponsor for her NM. That means the NM cannot properly take care of her packages in Debian. That’s not acceptable. That practice should be discouraged.

And, oh, this works both ways: if you’re in the NM queue and have time constraints impacting your application, please tell so to your AM and ask to be put on hold until you can find enough time to resume your application. You’ll help everybody by doing so.

I’ve just updated the dgap packages with a new (beta) release from Digi. This release accommodates newer kernels and introduces a udev script, though the previous releases worked just fine with udev too.

The packages are now built for Etch. On Sarge systems, you should keep version 1.3.6-1.

The following apt source line can be used (sources available too):

deb http://debian.technologeek.org/ etch non-free

You’ll find the old packages at http://debian.technologeek.org/pool/non-free/d/dgap/old/ for Sarge systems or should anything go wrong with the latest packages. They can be installed by apt if you request the exact version.

Bug reports and feedback should be directed at my inbox, as usual.

Today’s kernel: 2.6.23 + 2.6.23-hrt1 patchset + mactel patches. That gives an amd64 tickless kernel that just works and I’m not observing the weird behaviour I observed with 2.6.22-hrt6 that forced me back to a 2.6.21 kernel.

I still need to remove the HID_QUIRK_POWERBOOK_ISO_KEYBOARD quirk for my GEYSER IV ISO keyboard, otherwise the @ and < are swapped. The good news, on the audio side, is that I don’t need to manually fix the pin config for the HDA codec anymore, which is a great step forward :-)

There’s a patched radeontool available that introduces a radeontool power low command to switch the chip into low power mode. And it works. Saves about 45 minutes of battery power, bringing the laptop’s autonomy to something like 2:15 hours. Still far, far away from the 4 hours I had on the PowerBook but it’s a step forward. This also means the laptop is now quiet; I don’t hear the fans anymore. I’ve had this laptop for 11 months now, and it’s something I was really, really looking forward to.

Update on the EFI firmware update 1.4: this update really fixes the keyboard issue in legacy bootloaders, I’ve had a working keyboard in LILO at each and every (re)boot since I installed it.

Apple released a firmware update for the MacBook Pro about two weeks ago, entitled “MacBook Pro EFI Firmware Update v1.4″.

The update contains, among other things, a microcode update for the Core2 Duo CPUs.

It also looks like this update fixes the longstanding issue of the non-working keyboard in the legacy bootloaders. As it used to work from time to time, I’m not entirely sure the issue is fixed yet, I may just have been lucky so far.

I’ve been told that this update breaks the framebuffer, so if your kernel has framebuffer support for the console you may want to hold off…

After adding the ability to load 64bit kernels on machines equipped with a 32bit PROM, I’ve now added initrd support to arcload.

I’ve tested that code on IP22, if you give it a go on another platform please let me know how it goes! Don’t bother with IP27, initrd is unsupported in the kernel on that one (some work required). Patches welcome if any are required.

To add an initrd to your arcload config, use the initrd keyword in the same manner you use the image keyword. And to be on the safe side, add a test entry, so that you can still boot the machine if for some reason the initrd can’t be loaded :)

I’ve produced a patch for arcboot too, so that will appear in arcboot at some point in the near future too.

For the past weeks, I’ve been working on getting an SGI Origin200 system to run Debian.

Getting a working kernel for the machine took some time and lead to the discovery of 2 nasty bugs, which will be fixed in 2.6.23 thanks to Ralf Baechle (who found and fixed both bugs). There’s still some work left but the machine is in a usable state, except for a dead eth1 interface.

Now I’m having some fun with the bootloader, namely ARCLoad in this case. ARCLoad supports all the Linux-supported SGI MIPS machines, but couldn’t load 64bit kernels on machines equipped with a 32bit PROM; all Debian kernels for SGI MIPS machines have been 64bit for some time now, so that means ARCLoad was unusable with these machines (note that the Origin200 comes with a 64bit PROM, so this wasn’t a showstopper for this project).

Thankfully another bootloader, arcboot, is used for these machines and supports 64bit kernels. Stealing a snippet of code from arcboot I’ve now uploaded arcload 0.5-5 which fully covers our needs. The joy of free software.

I’ve also been working on getting the latest rEFIt version to build with GNU EFI, which means updating GNU EFI to efi110. Took some time, but everything built in the end. I haven’t tested the resulting rEFIt binary yet, waiting some feedback from GNU EFI uptream before doing so.

Kernel of the day: 2.6.22 + hrt6 patchset + mactel-linux SVN patches dated today

On the ALSA side, the config for the Sigmatel codec has been fixed (mactel-linux patch, backport from 2.6.23), so I don’t have to patch that myself anymore. Hope it’ll last, this time.

I still need to remove the POWERBOOK_ISO_KEYBOARD quirk for the Geyser IV ISO keyboard, though.

The appleir driver is gone now, so the remote control is no longer associated with an event device, and LIRC should be used instead. This means the remote control won’t work in pommed anymore, so either I’m adding a LIRC interface to pommed or I’m dropping the remote control support.

I’ve just uploaded to unstable a new revision of SANE which fixes the longstanding SCSI interface problem in 32/64bit mixed environments. If you own a SCSI scanner, please read on and give it a go.

For the past several years, it wasn’t possible to scan using a SCSI scanner if you were running a 64bit kernel and a 32bit userland. The sg_hdr struct, which is the base of the Linux SG3 interface, contains pointers (you see that coming, right?) so its size obviously differs in 32bit and 64bit mode; and a 32bit pointer is kind of useless as-is for a 64bit kernel. The SG3 asynchronous interface (read/write calls on /dev/sgX) does not handle the 32/64bit conversion and returns an error while sanity checking the sg_hdr struct passed to it.

Hopefully, the SG_IO ioctl interface, also part of SG3 and now generalized to every SCSI device (not limited to /dev/sgX), uses the same sg_hdr struct with the added bonus that the ioctl 32bit compat layer built into the kernel converts the 32bit sg_hdr it gets from userland to a 64bit sg_hdr it passes on to the 64bit ioctl handler, and back again.

Only difference, the SG_IO ioctl interface is synchronous, whereas the read/write interface is asynchronous and thus allows command queueing. So SANE (sanei_scsi) now has lost its command queueing feature but it looks like (after testing) it wasn’t making any difference anymore.

This problem affects users on the following architectures, when running a 64bit kernel with a 32bit userland: i386/amd64, MIPS, MIPSel, SPARC, PowerPC, ia64. That makes for an important part of our supported architectures.

If you own a SCSI scanner, here’s a test you can do: scan using the current version of SANE in unstable (1.0.19~cvs20070505-2), then with the new, patched version (1.0.19~cvs20070505-3) and report back if:

• the scanner backtracks more than it does with the previous version
• you see weird errors OR you see no error and you should be seeing some
• performance sucks
• the resulting image is broken in one way or another

If all goes well, this patch will make it into SANE upstream RSN.

I’ve just built a 2.6.21 kernel for my machine, only to realize that the machine doesn’t behave like some other similar (if not identical) MacBook Pro do.

Facts:

• the keyboard does not need the HID_QUIRK_POWERBOOK_ISO_KEYBOARD quirk, otherwise the @ and < keys are inverted.
• on the ALSA side, the macbook_pro_v2_pin_configs config does not work; the headphones work but not the speakers. I’m using the macmini_pin_configs config from the 2.6.20 mactel-linux patches which does work fine (and is identical to the macbook_pin_configs config in the 2.6.21 kernel).

So, now I’m really confused. A colleague here has got the exact same machine, except he bought it in mid-february and I bought mine back in november (the day after they were announced by Apple, so my machine is one of the “very first” Core2 Duo MacBook Pro). Either there has been a new hardware revision, or there’s something weird happening. I’m running an x86-64 kernel and my colleague is running an i386 kernel, but I really can’t believe it makes any difference at all.

I guess I’ll have to find out what’s going on …

I am currently going through the SANE bugs reported on bugs.d.o. There are quite a few of them, and verifying them already takes a long, long time; fixing them is another story entirely, given I own none of the affected scanners or platforms.

I’ll be going through the bugs this week-end, re-reading the logs, tagging/retitling as needed so hopefully the list will be easier to read.

If you have - or are affected by - an open bug against SANE, please try to reproduce the bug on an up-to-date unstable system. I’ll be uploading a CVS snapshot to unstable today for that purpose.

SANE is a complex piece of software that is best maintained in a team, if only because there’s so much hardware involved that the more maintainers you have, the more different hardware you can have too. If you have a scanner, have some knowledge about USB, shared libraries, GTK among other things and want to help, mail me and tell me what you can/want to do. Some knowledge about SCSI can help too, though SCSI scanners aren’t exactly mainstream anymore.

I currently own only 3 scanners, one old SCSI scanner and a pair of nearly identical USB scanners; so that really makes 2 scanners.

If you have some scanners lying around that you don’t use anymore, I (and the SANE developers too) could probably use them. I’m primarily interested in any scanner that is involved in one of the bugs currently open against SANE. I’m also looking for a scanner supported by the epson backend (the Epson scanners I have are supported by the snapscan backend).

Now, back to these damn bugs.