GNOME3 has actually become quite usable, but I was really annoiyed by the inability to disable actions on "critical low battery" (Additionally, there is no way to define what "critical low battery" is and with a big battery I assume this might well mean that you cannot use the machine anymore even though there is half an hour of juice left). Add to that bnc#738782 which leaves my screen unlocked after suspend and I decided it was time to use someting sane -- like xfce4-power-manager -- instead.
However, it's not that easy, as everything power related is hard-coded into the gnome-settings-daemon -- and even in different places.
So here is a package with a patch that simply disables the handling of all the power-related keys in the media-keys (!) plugin and additionally prevents the build of the power plugin completely.
Now just start xfce4-power-manager (and maybe use the Evil Status Icon Forever shell extension to make it show up in a visible place).
The patch is here, it is clearly not upstreamable but I'd rather have an ugly hack than an unusable "good solution" :-)
Thursday, December 29, 2011
Friday, December 23, 2011
If you don't want to fight package maintainers...
...then work around the bug.
One example is bug 699400: hwclock is never set correctly when NTP is used (unless it was almost correct before...).
I reported the bug, I argued with the maintainer, it did lead to nothing, the bug was "RESOLVED INVALID" (interesting notion: either it is resolved or it is invalid, then there is nothing to resolve...)
What's my workaround? I exploit the fact that old SysV init uses bash scripts. The init script which sets the clock does source /etc/sysconfig/clock. Internally, it uses a variable ELEVENMIN_MODE.
So what did I do? Simply add
The script will throw some errors on boot and shutdown due to its inability to change a readonly shell variable, but I can live much better with a harmless warning than with a totally wrong system time at each reboot :-)
Update: Werner has pointed out in the bug that this is totally wrong and will make a mess of your time settings, so use this at your own risk. OTOH I have more than 2000 productive systems here running with this. We had lots of problems before and have no problems anymore after doing it like described here. So at least for me the wrong solution works good.
One example is bug 699400: hwclock is never set correctly when NTP is used (unless it was almost correct before...).
I reported the bug, I argued with the maintainer, it did lead to nothing, the bug was "RESOLVED INVALID" (interesting notion: either it is resolved or it is invalid, then there is nothing to resolve...)
What's my workaround? I exploit the fact that old SysV init uses bash scripts. The init script which sets the clock does source /etc/sysconfig/clock. Internally, it uses a variable ELEVENMIN_MODE.
So what did I do? Simply add
readonly ELEVENMIN_MODE=noat the end of /etc/sysconfig/clock.
The script will throw some errors on boot and shutdown due to its inability to change a readonly shell variable, but I can live much better with a harmless warning than with a totally wrong system time at each reboot :-)
Update: Werner has pointed out in the bug that this is totally wrong and will make a mess of your time settings, so use this at your own risk. OTOH I have more than 2000 productive systems here running with this. We had lots of problems before and have no problems anymore after doing it like described here. So at least for me the wrong solution works good.
Subscribe to:
Posts (Atom)