What is OpenID? http://openid.net/

Wir sind jetzt ein OpenID-Provider - Wer eine will soll mir einfach eine Nachricht schreiben.

Was ist OpenID? http://openid.net/

Mir war bekannt das Akonadi zwingend eine MySQL-Abhängigkeit hat und seinen eigenen MySQL-Server startet, als mir dann Gestern bewusst wurde, dass Akonadi damit meine normalen MySQL-init.d-Scripte hijackt und sich deshalb meine normalen Datenbankanwendungen nicht mehr richtig verbinden konnten wurde mir das ganze dann zu blöd.

Und anstatt mich auf mein Abitur vorzubereiten habe ich dann was nützliches getan und ein bisschen recherchiert. Mir war schon seit längerem bekannt das Akonadi einen MySQL-Server benutzt und daher prinzipiell auch einen bereits laufenden MySQL-Server benutzen kann. (Was ich in diesem Zusammenhang übrigens erwähnen will, fände ich die Idee eines KDE-weiten-MySQl-Server ganz interessant - da wohl immer mehr Anwendungen mit SQlite an ihre Grenzen stoßen und MySQL-Datenbanken unterstützen oder gar benötigen, bsp.: Akonadi, Amarok, Digikam, … )

Also kurzhand meinen eigenen MySQL-Server mit der entsprechenden Datenbank bestückt und Akonadi so eingerichtet das es diese benutzt (Tipp: Eigenen Akonadi Benutzer anlegen). Dies hat auch ganz gut funktioniert so, allerdings hat der TEST  14 noch probleme bereitet (”Kein Ressourcen-Vermittler gefunden”, XDG_DATA_DIRS).

Dieses Problem das eigentlich garkeines ist, weil es wenn man Akonadi nach dem Fehler nochmal startet doch irgendwie geht ist trotzdem extrem nervig weil es wie gesagt bei jedem Start diesen lästigen Fehler produzierte.

Ich konnte das Problem jedoch für mich so lösen, indem ich in der ~/.bashrc ein

export XDG_DATA_DIRS="/usr/share:$XDG_DATA_DIRS"

eingefügt habe. Das Passende Verzeichnis hat mir der Akonadi Selbsttest verraten: Dort heißt es das Verzeichnis /usr/share/akonadi/agents wurde durchsucht sowie bla bla bla …

Durch suchen habe ich herausgefunden das /akonadi/agents weggelassen werden muss. Auch sei hier nochmal darauf hingewiesen das es sich um den openSUSE 11.1 spezifischen Pfad handelt, andere distributionen können u.U. auch andere Verzeichnisse wie z.B. /opt/kde/usr/share verwenden! (Steht dann aber auch im Selbsttest so drinne)

Zum ausschalten:

K-Icon/Chamäleon(openSUSE) → Systemeinstellungen (das von KDE, nicht mit irgendwelchen distributionseigenen Tools verwechseln) → Benachrichtigungen → Systemnachrichten → Quelle für das Ereignis: "KDE-Systemnachrichten"
und dort "Abmelden" und "Anmelden" aussuchen und jeweils das Häkchen vor "Klang abspielen" rausnehmen - wer's später wiederhaben will kann einfach das Häkchen wieder rein machen, aber es funktioniert - probiert's aus!

The only clue I got was from /var/log/messages:
EXT3-fs: sda2: couldn’t mount because of unsupported optional features (240).

It seems that udev >= 150 doesn’t like the deprecated sysfs stuff very much (apparently it took over it functions).
To keep it short: I had to uncheck the kernel modules SYSFS_DEPRECATED_V2 (also you should uninstall SYSFS_DEPRECATED), rebuild and install the kernel and everything worked again

Gentoo als Source-Distribution ist natürlich bestens dafür geeignet und stellt sich als erstaunlich kooperativ heraus, folgende Schritte sind nötig:

1. emerge -av portage-utils crossdev (erstes dürfte wahrscheinlich schon installiert sein)
2. crossdev –target $MACHINE-$VENDOR-$KERNEL-$OS (durch die entsprechenden Werte ersetzten, Tabelle forestlen oder im Gentoo Handbuch nachgucken, für meinen Fall: crossdev –target i686-pc-linux-gnu)
3. Anschließend müsste es einen compiler i686-pc-linux-gnu geben, einfach mal probieren ob der Befehl gefunden wird …

Zum compilieren des Kernels sind jetzt noch folgende Schritte notwendig:

1. export ARCH=”x86″ (kleiner Tipp: Hier ist die Kernel-Architektur gefragt, die sich je nach Version etwas verändern kann, deshalb einfach mal in $Kernelsource/arch  nachgucken, was die Version gerade so anbietet)
2. export CROSS_COMPILE=”$YOUR_CROSS_COMPILER_HERE” (also in meinem Fall export CROSS_COMPILE=”i686-pc-linux-gnu”)

(Wer will kann das ganze auch in ein eigens angelegtes script packen und z.b. unter /usr/bin speichern, Vorschlag dazu am Ende)

Und jetzt kann wie gewohnt make menuconfig bzw. einfach nur make aufgerufen werden. Bei mir ist allerdings noch folgender Fehler aufgetreten:

arch/x86/boot/boot.h: Assembler messages:
arch/x86/boot/boot.h:112: Error: bad register name `%dil’
make[1]: *** [arch/x86/boot/video.o] Fehler 1
make: *** [bzImage] Fehler 2

Dies liegt jedoch offenbar nicht am Cross-compiler selbst sondern an der Tatsache, das der Kernel älter als der aktuell laufende Kernel ist, ich wurde auf folgenden git-comitt aufmerksam gemacht, der das Problem behebt.

Zum Schluss noch der Hinweis auf das wiedermal recht ausführliche Gentoo-Handbuch, das unter dem Thema Embedded Devices auch zum Thema CC etwas hergibt.

Beispiel für make-script:

#!/bin/sh
exec make ARCH=”x86″ CROSS_COMPILE=”i686-pc-linux-gnu-” INSTALL_MOD_PATH=”${SYSROOT}” “$@”

Together with my new DSLRs (a Nikon D40, I know an oldie but goldie), I started to use flickr to publish some of my pictures. I don’t really trust google (especially with their new face registration … ) and since Gilles always uses it, I started to use it too.

And so far it worked quite well, I used a digikam export plugin to publish them, so not much handwork involved.

My fotostream can be found under the following adress, would be nice if you could leave some comments: http://www.flickr.com/photos/mirrakor/

• Here’s whats changed so far:
• Added an additional “get ” command, which stores the received NMEA records in the current directory. And automaticly names the file after the according date. In default mode* it groups the records in one file per day.
• The date function has been “fixed”, well actually it created a valid timestamp in some way (I think something tactical), but it wasn’t really useable, so it’s now yyyy-mm-dd (HH:MM:SS), pretty, ain’t it?
• For all switches (see below) you can now set default values at the beginning of the script. Also the default device is set to /dev/ttyUSB0 (set this according to your configuration), it saves you to type that -d every time

There’ve been some switches added:

• -s –separate-tracks Creates a new file for every track. Naming scheme is: yyyy-mm-dd_counter.nmea

• -z:int –zeros=int which sets the number of leading zeros (i.e. if you, for some reason have more than 100 tracks of one single day you might want to set -z:3 so you’ll get 0001 and even 0333 is sorted correctly

• -c:int –counter-offset=int Imaging this: You just downloaded all tracks from your device (including 7 tracks you created today) and delete your device. What happens? A fellow mapper comes by and what the heck, you go out and tagg a round, but now the script would create a file yyyy-mm-dd_0.nmea, which already exists, since we’ve downloaded it earlier, counter offset to the rescue! With -c:8 you’ll get a file named yyyy-mm-dd_8.mnea and will go on with yyyy-mm-dd_9.nmea … (the next date will start with a counter of 0 again )

Usage examples:

./rgm -s -z 3 get 17-  (will get all tracks starting from 17 and store them in individual files with the naming scheme date_000x.nmea )

Note: You must place the switches before the actual command (get, track, etc. )!

Things still left to do:

• A function to erease the device
• Geoid correction
• GPX output
• Check if file already exists
• Make it possible to pass a directory as option

UPDATE:

HAHA! You wouldn’t believe it, just the day I finished with the script the original author released an update (to be percicse 2 hours later), jumping from rev. 14 to rev 19 (aaaah, whyyy?! And we thought he isn’t working on it anymore …), well quick changelog: Added GPX output (trackx) and the possibility to erease the memory

UPDATE²:

The modifications of rev14 are now adapted to the script of rev19.

UPDATE (March 15, 200):

It’s now also possible to directly download/write files in GPX format with the ‘getx’ command, the other switches also apply to this one (separate/single files, leading zeros, offset counter … ). You’ll notice that a single gpx file, that consists of several tracks, will have several tracks inside, which can be edited manually (i.e. with viking)

You can get the modified version here: http://www.michael-skiba.de/rgm.txt (You might want to rename it to rgm.py or something like that)

The original version can be found here: http://code.google.com/p/rgm3800py/

But all in all it was hardly a match for the solid Amarok 1.4 (ah.. see some parallels? kde 3.5 < -> kde 4.0), there has been an some small update already, and we’re now at 2.0.1.1 (the latest included a security fix, so update it!).

One thing that bugged me was the broken multi-file-editing-dialog and the missing iPodmedia-player-support.

As an Ex-Gentoo there’s only one thing to do: Reach out for the bleeding edge and get a copy of the latest development branch. (Sidenote Amarok will soon switch from svn to git and be a test-case for the rest of the KDE project)

What can I say?
As always the future looks so bright:
- “Media-Player-Applet” works and is able to transfer tracks to my sisters iPod nano of the latest generation (4th?)
- Editing several files at once works (so far..)
- Bookmark feature (with some additions this will be very nice for audio book listeners)
- As I see it, the “Widget”-View has changed, there are not 4 displays anymore but instead only a single one with a clickable list of used widgets

Ist natürlich inakzeptabel und ein Ekel.. in den nächsten Tagen werde ich einen Weg suchen, dieses Krebsgeschwür zu entfernen… (Kommentare willkommen!)

Just a little sidenote: I installed a new gallery plugin, to get some in the pictures of the blog…