Archive for the 'Debian' Category

Trying to upgrade a craptastic server that’s proving problematic under 2.6.18 to the Etch 1/2 kernel, not only is the machine extremely sloooooow to boot, but it turns out that it’s partly due to bnx2 now requesting a firmware file, whereas the firmware is built-in in the 2.6.18 Etch kernel.

Of course, the machine has no working network access due to this, and, to make things even worse, the firmware file is nowhere to be found. No firmware-nonfree in etch-proposed-updates and it’s not in the firmware-nonfree package in unstable.

You’d better hide your kittens, for Etch 1/2 makes me want to kill a large number of kittens.

New developer accounts have been created moments ago, “finally”.

Congratulations to all new DDs, with a special note for Aurélien GÉRÔME (ag) and Cyril BRULEBOIS (KiBi).

All of this made possible by Sam, our best DPL to date.

Also, don’t listen to the fucktards going around telling “OMG DEBIAN IS DYING!!11!1!”. They’re just that, fucktards.

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.

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.