Decrappify GNOME3 Powermanagement

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" :-)

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

readonly ELEVENMIN_MODE=no

at 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.

A trivial systemd unit script: vboxservice.service

In a VirtualBox guest, VBoxService (which is for example responsible for setting the time after a host suspend/resume) is not started on boot. I thought about writing a simple init script to doit (editing the vboxadd init script seemed like a bad idea, since it might get overwritten on updates).
Then I decided to try the "native systemd" way.
Executive summary: it is much easier than with old style SysV init:

# cat /etc/systemd/system/vboxservice.service
[Unit]
Description=VirtualBox guest services

[Service]
ExecStart=/usr/bin/VBoxService -f

[Install]
WantedBy=default.target

Activate with systemctl enable vboxservice.service.

12.1 update - no problems and systemd rocks

Two days ago I updated my home server to 12.1, basically by doing

# cd /etc/zypp/repos.d
# sed -i 's/11.4/12.1/' *
# zypper ref
# zypper -v dup --no-recommends

The only small glitch I had was systemd apparently taking a nap during boot, which made the machine take very long to boot (about 2 minutes).
After filing bug 730776, I found out (with the helpful hint from Frederic), that I still had an invalid swap partition in my fstab. After fixing that, the bootup now really is blazingly fast:
server:~ # systemd-analyze
Startup finished in 4116ms (kernel) + 33827ms (userspace) = 37944ms

new avr-gcc packages

Thanks to Volker Kuhlmann, there are now 3 brand new avr-gcc packages in the CrossToolchain:avr repository: avr-gcc-436, avr-gcc-462 and avr-gcc-47-20111105.
The "original" cross-avr-gcc package is still at 4.3.3, as that's the most tested revision and also it has additional patches that are dropped from the new versions. Those patches add, amongst others, XMEGA support which is not present in the avr-gcc packages. That's something to improve in the future.

The packages contain a run-avr-gcc-XXX wrapper script (substitute XXX with the 436, 462,...) to make testing the respective compiler very easy.

Have fun testing!

Cool. Censored Mailinglists.

Funny. As soon as someone brings up an unwanted topic, the openSUSE Factory Mailinglist Dictator^WModerator shows up and the rest of the discussion never reaches the list. Without a notice of course.

So that's what I had to say on the topic, and the Factory list will now probably do without me. This post is just that people have a chance to know why their bugreports will be handled the way they are.

Date: Thu, 10 Nov 2011 07:50:03 +0100
From: Stefan Seyfried
To: opensuse-factory@opensuse.org
Subject: Re: Decision making (Was Re: [opensuse-factory] Kmail 4.7 is not
 shippable in 12.1)
In-Reply-To: <201111091248.27668.markus.s@kdemail.net>

On 09.11.2011 12:48, Markus Slopianka wrote:

> On Mittwoch 09 November 2011 11:45:27 Stefan Seyfried wrote:
> 
>> We should simply revert the mistake of making KDE the default desktop.
> 
> https://features.opensuse.org/306967
> https://features.opensuse.org/307495
> 
> Live with it, vocal minority!

Well, some time ago it was said that openSUSE is a meritrocracy. Those
who do the work get to decide.

It is very easy for people to first vote "make $BROKEN_DESKTOP default"
and later complain that it does not work.

Obviously, all the people wanting to have a certain desktop as a default
need to make it work. If it doesn't, it does not deserve to be the default.

There is even FATE for that: https://features.opensuse.org/312959
Right now, people vote for not having a working desktop.

That's fine with me. Makes bugfixing much easier: either "RESOLVED -
WORKSFORME", or "Component: KDE4-Workspace", "[x] reassign to default
component owner".
I doubt it improves the user experience, but hey, the users voted for
it, so who am I to complain.

My first remotely useful Arduino sketch

I want to use the arduino to interface a small graphic LCD to my satellite set-top-boxes.
The problem with most of the boxes you can buy today is, that they only have a one-line, 12-16 character text-only VFD display and no longer the nice credit-card sized graphic LCDs the old dbox2 or dreamboxes had.
Most new boxes have an USB port,though, so interfacing the LCD via USB is pretty easy.
The code (both arduino and a small test program for the box) is here on gitorious. The protocol is primitive but pretty efficient on RAM and it does recover from errors surprisingly well. The update rate of maybe 10 FPS is enough for this kind of usage.
Now I need to implement some "display driving daemon" which can be interfaced easily with the set-top-box software.

Android Update brings PAN/NAP to Motorola defy

After my summer vacation, I finally did the official update on my defy, which brought the thing to Android 2.2.2.
Since Motorola had obviously done quite some customizing to the original 2.1, not too many obvious differences were there: "Mobile Hotspot" was present before. The design theme (which is something I could not care less about...) was already like 2.2 before and the horrible "MotoBlur" interface is still there, so I thougt "well, it's mostly some bugfixing under the hood".

Today, I wanted to finally look into the bluetooth dialup problems I had with the device: NetworkManager was somehow not happy with the responses to some AT commands it got before, resulting in non-working Bluetooth "tethering". Back then, I did not care too much and chose to just use WiFi instead, but today I decided to look into it.

What can I say? The software update upgraded the Bluetooth tethering from dialup (rfcomm/serial/ppp) to PAN/NAP. Which I like much better as it is more "natural" anyway.

Yet another bug I don't need to tackle anymore :-)

Update: The same is possible using the "Wireless Tether for Root Users" app from the android market. Just make sure that you start tethering before pairing the device using bluetooth applet, I'm not sure if there is a way to add the PAN interface to an aready paired device, at least I did not find one, so just checking the "Do you want to use the device for internet access" box during pairing is easiest.

Of course I don't expect this to work with KDE, but it works very well with nm-applet and bluetooth-applet from GNOME.

New toy: Arduino (packages fixed)

So I finally got an arduino or more precisely, a nice starter kit from fritzing.org.

Unboxing pictures are here.

I followed the instructions on installing the software from OBS, but checked the repositories first and found that there were some problems with FACTORY builds in Klaus' repo.
Additionally, the packages are, even if made to build, not working with the arduino uno thats in the starterkit.

The reasons are

• arduino uno has a different USB controller and appears as ACM device, not usbserial


• apparently, the avrdude included in CrossToolchain:avr is newer than what the arduino software expects and thus does need another protocol specification


• the arduino package sports its own avrdude.conf which does not work with the uno

Of course I fixed all those problems (and submitrequested the fixes back to the "upstream" projects) in the temporary project home:seife:arduino :-)
So now all you should need to do to get the first program uploaded to the uno is:

• add the home:seife:arduino repository


• add the CrossToolchain:avr repository


• zypper install arduino


• add your user to the dialout group (we could create some special udev rule case that discovers the arduino and makes the device accessible for group "users", but that would not help for the other arduinos that come with FT232 usb-serial interfaces)


• relogin to activate your dialout group membership


• start "arduino" from a terminal (the package is missing a desktop file, I will try to fix that later)

You can also install the fritzing package, but probably better use the package from the Education project than that from Contrib since Education seems to contain a much more recent package.
But for now, everything I did was done using arduino.

Now looking at what is needed to get this to work, I'm wondering if the arduino related packages should just be put into CrossToolchain:avr, or if we should create some project for this Arduino stuff, containing the arduino and fritzing packages and everything needed to support them.
An argument against the "stand alone Arduino project" would be that it duplicates significant build efforts (the cross-avr packages are probably pretty expensive to build).
The pro agument is, that interested users need to add only one repository. If even fritzing is there, they need not add the "Education" repo. This would be good, because adding such big repos which also contain lots of updated "standard" packages (there's SDL etc. in Education) is certainly not recommended for novice users because of the unpredictable side effects. Note that the CrossToolchain:avr repo is pretty small and does not contain anything that updates system tools or similar, so adding this one should be "mostly harmless".

I'll need to think about this and maybe talk with other involved parties at the openSUSE conference in two weeks...

(e)glibc cross compiling issue...

While building a brand new powerpc cross-compiler with crosstool-ng (which is great), I came about a simple issue which was unexpectedly hard to fix:

../misc/syslog.c: In function '__vsyslog_chk':
../misc/syslog.c:123: sorry, unimplemented: inlining 
failed in call to 'syslog': function body not available
../misc/syslog.c:155: sorry, unimplemented: called from here

Using different combinations of build helper tools, eglibc, gcc, whatever did not really help. Even the search engine results were full of the same questions but with very little answers, and most of the answers were clearly in the league of cargo cult programming, nothing you'd want to rely on for a toolchain to be used by others.
But finally I came across this mail from Mike Frysinger which finally showed that it can be as easy as

CT_LIBC_GLIBC_EXTRA_CFLAGS="-U_FORTIFY_SOURCE"

:-)
Of course the question remains why compiling glibc has to be always a major PITA, but that's something I'd rather not discuss in public...

The s2ram Whitelist is finally dead - Yeah!

http://article.gmane.org/gmane.linux.power-management.general/23624

Should have happened much sooner. Rest in peace.

openSUSE 32bit to 64bit live conversion

Kids, don't try this at home.
Anyway, here is what worked for me:

• add arch = x86_64 to /etc/zypp/zypp.conf


• zypper ref -f


• rpm -qa kernel*


• zypper in -f kernel-default kernel-default-base (the kernel packages found by the step above)


• mkinitrd


• reboot


• zypper in -f glibc


• zypper in -f rpm Attention: don't install, just resolve everything and get the list of -32bit packages that would get installed


• zypper in -f file-32bit libbz2-1-32bit... Install all the -32bit packages that were selected in the previous step


• zypper in -f rpm


• zypper dup --no-recommends --download-in-advance


• mkinitrd


• reboot

Whenever zypper asks you for conflict resolution (which will be every single case), select the option that involves "change architecture", never select "break ..." or "do not install ...". There should be no "uninstall..." proposal in the summary before confirming, only architecture changes and newly installed -32bit packgages.

There were some failing postinstalls for glib and other libraries, which could probably have been avoided by more carefully updating in intermediate steps, or by installing some -32bit library packages before the "dup" step, but the resulting system seems to work just fine.

Making GNOME more Usable

And while I am at it, some hints on getting GNOME a small little bit more usable. The problem is mostly the default window manager, and the gripes I'm having with it are basically the same that Linus Torvalds had some years ago. I want my window buttons to be configurable. To be more precise, I want the "maximize" button to behave like in almost every other window manager: 3 different mouse buttons, 3 different button actions: "maximize", "maximize horizontally", "maximize vertically".
Linus' problems have been addressed, and I'm explaining a lame workaround for my wishes to get something slightly similar to what I want. My workaround does only work because of the fixes for Linus' problems.

After looking into the code I understood that the window buttons are only used with left-click, right and middle click are handled by the "window titlebar action" instead.

So I redefined the window titlebar mouse actions to do maximize horizontally / vertically on right click and double click. (I am pretty accustomed to having middle button on title bar put the window into the background, but I might change that).

So here's what you have to do.

• open regedit.exe gconf-editor


• browse to /apps/metacity/general


• change action_double_click_titlebar to toggle_maximize_vertically


• change action_right_click_titlebar to toggle_maximize_horizontally

While you are at it, you might also enable resize_with_right_button, which restores even some more sanity.

For all those asking why I'm not using a different window manager with GNOME: been there, tried that, but the integration of them all was pretty horrible (keyboard shortcuts no longer easily configurable, ...) and I want somehting that just works and does not always get in my way. If I wanted that, I could have kept KDE.

Making Windows Usable

If you ever have to use Windows, and are accustomed to "focus follows mouse" as I am, you might find this description useful.

I'm citing the important part here, to let me find it more easily:

Believe it or not, Windows does support focus-follows-mouse, though there is no GUI configuration exposing it. Instead you must edit a registry key and then log out and back in for the change to become effective. You can use regedit to edit the key.
[...]
you need to change a binary-valued registry key:
HKEY_CURRENT_USER\Control Panel\Desktop\UserPreferencesMask
This is a little-endian bitmask. For focus-follows-mouse, add the flag 0x1.
For example, my XP SP2 laptop originally had a value of 9E 3E 05 80, which is 0x80053E9E. To activate focus-follows-mouse I changed to 0x80053E9F, or 9F 3E 05 80 in regedit.

Helped me a lot on a Vista machine yesterday. Don't forget to log out and back in again after the change.

OpenStack "bexar" packages for openSUSE and SLES11SP1 are ready

Shortly after the OpenStack "bexar" (spoken "bear") release was ready, my packages finished building and are available at the isv:B1-Systems:OpenStack Build Service repo.

Grab them, while they are still hot!

The ride might still be a bit bumpy as the whole OpenStack development is very Ubuntu centric, and thus some of the dependencies, especially to old versions of python stuff are tricky to find. However, first results look promising.

I'll update here soon with some short hints on how to configure and use the whole lot.

Thanks go to my colleagues Christian Berendt and Andre Nähring at B1 Systems GmbH who have been tireless in testing packages and reporting packaging bugs and other problems. Thanks also to Gregory Haskins with whom I started the packaging effort early in december.

DeLorean?

Check out this bugreport. Sometimes I'm wondering if Takashi has a time machine, allowing him to jump back in time in order to fix reported bugs in such an amazingly short time... ;-)

Load average

No comment:

  2:05pm  up 79 days  6:40,  5 users,  load average: 2948.98, 2948.04, 2945.49

(Later we found out that the load was actually "fake", the kernel had somehow died and everything accessing /proc/$pid/* was hanging in state D)

Don't Ask

(No, it was not me who made this necessary. Yes, we did reinstall the machine anyway.)

#!/bin/bash
while read p; do
  rpm -V $p > /dev/null && continue
  echo "fixing $p's file ownership..."
  while read x x u g x x x x n x; do
    chown -h $u:$g $n
  done < <(rpm -qlv $p)
done < <(rpm -qa)

Increasing the X resolution for KVM guests

Today I wondered again, why my KVM guests get only 800x600 display resolution, even though the framebuffer console is configured for 1024x768. While most of the time this does not matter for testing, it does once you want to evalutate desktop environments or such in a VM.
I checked the xorg log file and found, that the Cirrus card emulation apparently has no DDC channel implemented, thus cannot detect the monitor and then X.org falls back to a plain SVGA monitor. From the logfile:

Using default hsync range of 31.50-37.90 kHz
Using default vrefresh range of 50.00-70.00 Hz

Simply setting those ranges to something reasonable (I got my values from "hwinfo --monitor") helps quite a lot. Put this into /etc/X11/xorg.conf.d/50-monitor.conf:

  HorizSync   31 - 61
  VertRefresh 50 - 90

and you get a much more usable 1024x768 resolution.

"Could not find any loop device." WTF?

susi:~ # mount /space/FACTORY.iso /mnt/ -oloop
mount: Could not find any loop device. Maybe this kernel does not know
       about the loop device? (If so, recompile or `modprobe loop'.)

WTF? That never happened to me before, so I assumed (obviously) that something was broken in current FACTORY and filed a bug.

Finally we found out, that the loop module was always unconditionally loaded on every machine by boot.localfs, which is no longer run since I switched to systemd.

As Kay pointed out in the bug, it is very easy to fix:

susi:~ # echo loop > /etc/modules-load.d/loop.conf

At least until someone fixes the Kernel's loop device behaviour ;)