Bubulle's weblog

• Distance: 7,25km
• Temps: 36mn52sec
• Vitesse: 11,80km/h, 8'16"/mile, 5'05"/km,

Marc, from my experience, there is no 'secret' in the console-tools/kbd migration work. Just low involvment of all parties.

I have watched the work on console handling stuff in Debian for a few years now, and my conclusion is just that nearly nobody cares about it now.

I do maintain console-data that provides console fonts and keymaps. I took it over slowly from Alastair McKinstry (the console-tools maintainer mentioned in Marc's blog entry) because that involved maintaining localization of keymap names....that are used and visible in the installer.

Ideas to switch the installer to console-setup and related tools are floating around. Just not achieved...because of lack of motivated manpower. Progress was made because of Anton Zinoviev and Colin Watson's work, but the project is currently hosed on a quite critical choice:

• either ask about keymap layout during install, but that requires internationalization of the model/layout names...that are in an XML file. Nobody worked on this and this is therefore a blocker.
• or use the Ubuntu way to set the keymap (by asking users to type keys and guess the right keymap from that). Colin already said to the D-I team that this is basically a big hack...but, well, it works.

About console-tools being installed by default: this is the consequence of it being Important while kbd is Extra. I think it should be up to kbd maintainers to push the change up. But this brings us back to the initial remark: indeed, now nobody cares about console handling, particularly when it comes at handling non-English environments. Those who still use the console in Linux environments apparently all do it with US keyboards and an English locale. For sure, kbd is more maintained than console-tools so, at least, we should switch to it.

Funnily, our installer (even the graphical version) *still* relies on console keymaps during the installation process and, therefore, we rely on mostly unmaintained stuff here (people who think that I maintain console-data are plain wrong: I just keep it surviving...:-))

After last 2.6.25 kernel again dropped support for /proc/acpi, I decided to move forward and try removing things which depend on it on my laptop.

That actually involved switching from klaptopdaemon to kpowersave.

This is really a must do. I don't know if this happened in KDE tasks but if it is not, we should think about it.

Not only is kpowersave properly using /sys/class/power_supply instead of /proc/acpi/battery, but it seems much more powerful and providing reliable information.

PS: that /sys interface seems nice but finding where the hell information is stored is really a nightmare: "/sys/class/power_supply" is damn anti-natural to me... And, well, this is probably the 4th or 5th change for system information in Linux. Sometimes, I regret the stability of Windows when it comes at this (/me runs away).