Dakons blog

Irgendwann diese Woche zappte ich früh morgens (so um 1:30 Uhr) noch durch die Gegend und landete bei Bowling for Columbine. In einer Szene sagte eine Mutter sinngemäß: Warum rufen sie die Polizei? Weil die Waffen haben. Warum also einen Mittelsmann benutzen?. Wenn ich eine Waffe (legal) im Haus habe und sie verantwortungsvoll und richtig benutze, wo ist das Problem?

Irgendwie klingt das wie Windows: es ist doch mein Computer, ich weiß schon was ich da tue. Warum soll ich also nicht als Administrator arbeiten? Wie man in Winnenden gesehen hat gibt es immer eine Möglichkeit des Missbrauchs. Das ist der Grund warum neuere Windows-Versionen den Benutzer damit nerven ständig Administrator-Rechte anzufordern (ein dämliches Konzept, man klickt ja doch immer "zulassen"). Der Unix-Ansatz ("die Polizei rufen") ist dagegen: der Privatmann kriegt (fast) keine Waffe (aka Systemrechte) in die Hand. Wenn er was braucht muss er explizit anfordern welche zu bekommen.

Es gibt für mich keinen Grund warum überhaupt irgendjemand eine Schusswaffe haben sollte. Bei Polizisten sehe ich unstrittig ein das es ohne nicht geht, zumindest solange da draußen noch bei anderen Leuten Schusswaffen existieren. Aber ansonsten? Jäger, Förster? Gut, von mir aus. Aber die Waffe gehört dort definitv nicht in einen Privathaushalt. Wenn sie in den Wald fahren wollen sollen sie halt vorher auf dem Forstamt oder sonstwo mit Waffentresor vorbeifahren. Am Besten mit 4-Augen-Prinzip: jemand anders muss sehen das sie die Waffe entnehmen und die Rückgabe auch entsprechend quittieren. Patronen müssen abgezählt werden, die leeren Hülsen vorgezeigt werden. Sportschützen? Wenn sie Trockenübungen machen wollen sollen sie halt ins Vereinshaus fahren. Die Tennis-Spieler fahren auch jeden Tag zur Sporthalle um ihr Training zu machen. Und Munition brauchen die schon mal gar nicht zuhause, sie dürfen ja eh nur im Schießstand oder auf Turnieren schießen. Dann können sie auch da Munition bekommen.

This night Albert committed a patch I have written so all teams with the same number of translated messages now get the same rank on the web page. Currently we have 5 teams scoring gold for the stable translations. Portugese now is one of them while Greek has dropped to rank 24. I hope we get the top ten teams to all score gold until the release of 4.5.3, which means 64 messages worst case (Chinese Traditional). Come on guys, go for it!

Ein altes Spielzeug von mir ist das EFS, mit dem Feuerwehren ihre Einsatzprotokolle erstellen können. Um die Mailingliste des selben nicht mit unnötigem Zeug zu fluten habe ich mich jetzt entschlossen ein extra EFS-Blog einzurichten. Falls es irgendjemanden interessiert.

It has been a longstanding wish to get Smartcard support in KGpg. I mainly ignored this for two reasons: I believe that this should not be handled by KGpg, but by GnuPG itself, and I don't have that equipment around to test anything. Now two days ago a user came up with this again and the good news is: it works now (at least he told me so). Basically everything is handled by GnuPG, I just need to put the right things into it. The real smartcard fix was really trivial and also two related bugs that were found on the way were also fixed. Big thanks to Stanislav Sidorenko here for being extremely responsible when testing this patches and giving excellent feedback.

Aus Gründen, die hier nichts zur Sache tun, war ich heute versucht glibc 2.9 mit einem gcc 4.3.4 sowie aktuellen binutils neu zu bauen. Leider funktionierte das nicht so ganz wie erhofft:

checking for /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/as... /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/as
checking version of /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/as... 2.20.1.20100303, bad
checking for /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/ld... /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/ld
checking version of /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/ld... 2.20.1.20100303, bad
...
*** These critical programs are missing or too old: as ld
*** Check the INSTALL file for required versions.

Irgendwie überkamen mich da leichte Zweifel das eine Version, die Monate jünger ist als die glibc, zu alt sein soll. Oder hat da jemand beim Prüfen der Versionsnummer nicht mit 4-teiligen Angaben gerechnet? Was auch immer ich erwartet habe, es kam noch schlimmer:

echo $ECHO_N "checking version of $AS... $ECHO_C" >&6; }
  ac_prog_version=`$AS --version 2>&1 | sed -n 's/^.*GNU assembler.* \([0-9]*\.[0-9.]*\).*$//p'`
  case $ac_prog_version in
    '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
    2.1[3-9]*)
        ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
    *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;

Das Ende der Welt ist nahe! Nein, es ist mir egal das die WM bald rum ist, aber es könnte schlimmer kommen. Zunächst einmal frage ich mich was die am Mittwoch eigentlich übertragen haben. Das Spiel, das ich eigentlich sehen wollte, war es jedenfalls nicht. Aber was noch viel schlimmer ist: was kann am Sonntag passieren? Pest oder Cholera? Man stelle sich vor Spanien gewinnt, eine Mannschaft die das ganze Turnier über eher mau gespielt hat. Denen gönne ich das ungefähr so viel wie den komischen Typen mit den blauen Trikots vom letzten Mal. Aber egal. Oder was noch viel schlimmer wäre: Holland könnte gewinnen. Ich habe kein Problem damit das sie Weltmeister wären, das sie nicht spielen könnten, oder das dann noch mehr Wohnwagen durch die Gegend eiern. Alles kein Problem. Aber das Holland nicht Fußballweltmeister wird ist eine ähnliche Naturkonstante wie π oder e. Ich fürchte wenn sie gewinnen kollabiert das Universum und wird durch etwas noch schlimmeres ersetzt.

Gestern titelte die Tagesschau mit Westerwelle: 2011 wird erste Provinz an Afghanen übergeben. Eigentlich kann er das jetzt schon haben. Denn er hat nicht gesagt das er es an die afghanische Regierung übergibt. Und selbst wenn er das tut: die Warlords gewinnen sowieso. Die regieren auch jetzt selbst unter den Augen der NATO. Insofern kann er auch bei einem sofortigen Abzug die Provinzen an die Afghanen übergeben. Nur halt an andere.

I often face the same problem once I upgraded KDE to the lastest version from openSuSE build service: the KHTML part isn't working properly, I always get the error message /usr/lib/libphonon.so.4: symbol pa_ext_device_manager_reorder_devices_for_role, version PULSE_0 not defined in file libpulse.so.0 with link time reference. This is not only my problem and it doesn't seem related to openSuSE either as a google search on pa_ext_device_manager_reorder_devices_for_role shows.

My workaround was always to revert my libphonon to the version shipped in openSuSE 11.2 as this did not show the problem. But now I can't do this anymore since KDE 4.5 requires a newer phonon for development. Since I have some bugs to fix I decided to look into this.

For reference I take a copy of libphonon.so.4.3.0 which worked for me until now. A short look showed that this symbol is not mentioned anywhere within this library. Now let's look into the current one:

$ nm -D /usr/lib/libphonon.so.4.4.0 | grep pa_ext
U pa_ext_device_manager_read
U pa_ext_device_manager_reorder_devices_for_role
U pa_ext_device_manager_set_subscribe_cb
U pa_ext_device_manager_subscribe

What does this show? In the dynamic symbols of that library there are unresolved references to pa_ext_something. Ok, let's do some shell magic: scan all libraries libphonon.so.4.4.0 links against and look if they have something that would resolve this:

$ for i in $(ldd /usr/lib/libphonon.so.4.4.0 | sed 's/.*=> //;s/ (0x[a-f0-9]*)$//'); do nm -D $i | grep pa_ext && echo $i; done
00011710 T pa_ext_stream_restore_delete
000112b0 T pa_ext_stream_restore_read
00010f60 T pa_ext_stream_restore_set_subscribe_cb
00011070 T pa_ext_stream_restore_subscribe
000114e0 T pa_ext_stream_restore_test
00011a00 T pa_ext_stream_restore_write
/usr/lib/libpulse.so.0

Ok, this shows that other pa_ext_* symbols are coming from libpulse.so.0, but not the ones we need. Since this is the only libpulse package I find in any repositories I have I'm locked here.

So what happens? If I read an older message by Harald Fernengel correctly the package was build using a pulseaudio version with device manager extensions. But that version is not shipped in the same repository (which is a bug IMHO). At runtime I don't have this symbols around as the only versions I have seem to miss that extension. Seems to be a problem not only openSuSE faces.

Hörer des ältesten Kulturmagazins der Welt werden Onkel Hotte kennen und lieben. Deutschlands derzeitige Lieblingssängerin kommt auch aus Hannover, aber sie assoziiert wohl jemand anderen als das Original. Und der Inhaber des Kompromatkoffer denkt sich jetzt wohl auch: "abgesägt, gut getan".

I had the CAFF mode twice in the feature plan and it's finally also in the code I thought I would write a bit what's that all about. But instead of writing this all here as it was my first intention I instead have written most of the stuff to a chapter keysigning in KGpg documentation. After a week of waiting the online docs are now also up to date so it's time to take a look.

And for those who want to know why it's called "CAFF" mode: there is a perl script caff in the package signing-party that does basically the same. But that script has some drawbacks, e.g. it wants to send all your mail with your local sendmail. While this might be handy with a one-person workstation this sucks when it comes to laptops (where you often don't have a proper local MDA set up) or even non-Un*x hosts (think of KDE on Windows). Since that script always annoyed me in one or the other way I couldn't let it go because it is just too useful. So now KGpg can do the same work hopefully for me and use my usual mail setup. Whoa! ;)

So everyone who wants to know how this key signing stuff is intended to work please have a look at the docs I've written and tell me if this is understandable. Improvements always welcome.