Last weekend was mostly spent fighting with Gnome/DBus/HAL/MumbleKit.
The story starts with me upgrading my laptop to Karmic. (Well, no, actually it starts a bit before that, but we’ll pretend.) After deciding that the new version of GDM blows goats (see Google passim: it seems that it got HFPed) I downgraded to the gdm-2.20 package, which actually has documentation and can be configured. It was about this time that I discovered a bug.
Reboot laptop. Watch as upstart(8) provokes a number of exciting-looking warnings, starts gdm(8) and then… a black screen with a cursor in the top left corner. At this point, you can try pressing C-M-F1 to switch to the initial vconsole, but nothing seems to happen; but switching back to the broken X session with C-M-F7 shows me vcon 1. C-M-F1 blanks the screen again. Net effect: you can type at a vcon or see what it’s saying, but not both.
It took me a while to work out what was going on. Turns out that the buggered gdm package that I removed had left its little dropping in /etc/init, following standard dpkg(8) practise of leaving configuration files lying around. Only this time, both the /etc/init/gdm.conf file from shiny but funted gdm and the /etc/init.d/gdm file (and all its little /etc/rcn.d friends) from the good gdm-2.20 timewarp were trying to start the same daemon, setting up an X display on the same vcon. Result: very confused video hardware and a less than fully working system.
So far, so dull. Now I try to get the rest of my system back the way I liked it before. Only gnome-power-manager (the thingummy that puts a battery-level indicator in the system tray) no longer has the Hibernate and Suspend options in its menu. (Just like my desktop at work, actually: I thought I’d just broken that, though.) There’s a handy FAQ for gnome-power-manager which gives a number of commands to diagnose the problem. They don’t help. Of course, the answer is that some idiot decided to hide them unless you tinker with gconf.
Which leaves the continuing annoyance of the CPU-frequency applet. The applet only controls one CPU at a time, and (at least for me) a second applet crashes immediately if I try to add it. I’ve given up on this: I wrote a script which talks to the org.gnome.CPUFreqSelector backend service over DBus and beats it over the head until my will is done. Of course, just finding that there isn’t any documentation on the org.gnome.CPUFreqSelector protocol and having to guess from poking the server using introspection isn’t enough: you also have to do stupid things to PolicyKit because users should be allowed to turn the computer off but not mess with its processor speed by default. Or something.
What fun.
Leave a comment