Tag Archives: Software

irssi-Hilight mit Jabber

Seit einigen Jahren läuft in meiner Screen-Session neben ICQ und anderen Tools auch ein irssi, um mich mit der Welt des IRC zu verbinden. In den meisten Channels bin ich einfach nur anwesend, gelegentlich spricht mich dann aber doch jemand an. Dank hilight im irssi wird man darüber ja eigentlich informiert. Nur leider schaue ich viel zu selten in das irssi-Fenster, um das dann letztendlich auch zu sehen. (Ja, screen informiert ueber Pings in anderen Fenstern, aber da guck ich doch erst Recht nicht hin …)

Da irssi eine schicke Perl-API hat, liegt es doch nahe, ein Perl-Script zu schreiben, mit dessen Hilfe ich mich anderweitig informieren lassen kann. Sehr nahe liegt da der Instant Messenger, der sowieso immer läuft, wenn ich am Rechner sitze – konkret Jabber.

Mit dem Perl-Modul Net::Jabber ist das alles kein Problem (abgesehen von den lückenhaften Dokumentationen, insbesondere in der irssi API) und so gibt es nun das Script irssi2jabber.pl, das als irssi-Script geladen werden kann und mir nun bei jedem Hilight oder jeder privaten Nachricht, die auftreten, während ich /away bin, eine Nachricht an meinen Jabber-Account schicken.

Das Script ist etwas kommentiert, die notwendigen Einstellungen stehen ganz am Anfang und müssen in die irssi-Config. Unter der GPLv3 darf es jeder weiterverwenden, natürlich nehme ich auch Patches an, die, wenn sie nützlich sind, eingepflegt werden.

Kalendertool gesucht

Ich vermisse es mal wieder: Mein Wunschkalendertool.

Folgende Eigenschaften soll es haben:

  • Frontend im Stil vom Google-Kalender. Erreichbar über jeden Browser.
  • Verfügbare Software, die ich auf meinem eigenen Server installieren kann und die mir alleinige Kontrolle über meine Daten gibt.
  • Das Backend kann Kalenderdaten in IMAP-Foldern verwalten. Das ist meine derzeitige Speicherform, die den Vorteil hat, dass ich kein zusätzliches LDAP- oder DAV-System installieren muss, sondern einfach mein E-Mail-Postfach verwenden kann.
  • Kostenlos und OpenSource.
  • Optional: Eine schicke API, mit der ich ggf. auch andere Tools wie z.B. einen Reminder anbinden kann. Das muss aber nicht sein, weil die Daten ja auch schon im IMAP-Folder gut lesbar vorliegen.

Sachdienliche Hinweise bitte in die Kommentare oder per Nachricht an mich.

Penguineering

Penguineering ist ein Kunstwort, das aus penguin und engineering zusammengesetzt ist. Die Idee stammt von einer Freundin, die mir dieses Wort freundlicherweise überlassen hat, sodass ich mir gleich mal die Domain penguineering.com reservieren konnte.

Seit gestern Abend ist unter http://tools.penguineering.com eine Sammlung von Tools zu finden, die in einzelner oder gemeinsamer Arbeit der Blog-Autoren entstanden sind und allgemein verfügbar sein sollen.

Die Seite sieht noch etwas mager aus, aber das wird sich im Lauf der Zeit ändern.

Windows Vista: Auf der Höhe der Zeit?

Bei unserem Zeitabgleich zwecks Mensabesuch fiel mir vorhin auf, dass die Systemuhr meines Vista-Systems (das ist unfreiwillig nutze) mal wieder einige Minuten nachgeht. Normalerweise merke ich so etwas nicht, die lokalen Dienste stören sich nicht daran, bei Terminen ist der Griff nach dem Handy gewohnter und direkt zeitkritische Dinge tu ich auf dem Rechner nicht.

Trotzdem stellte sich dann die Frage: Was tun, um diese Situation in Zukunft ohne Mehraufwand zu verhindern? Seit XP kann sich auch Windows mit öffentlich verfügbaren Zeitservern synchronisieren. Das scheitert im Netz der Uni Magdeburg aber daran, dass das Rechenzentrum sehr restriktiv bei der Freigabe von Ports ist und NTP schlichtweg nicht funktioniert. Vista bestätigt das mit der lapidaren Meldung, dass irgendwo ein Fehler aufgetreten sei. Eine Möglichkeit, auf unprivilegierte Ports auszuweichen, gibt es nicht.

Zum Glück gibt es an der FIN einen eigenen Zeitserver (herkules.cs.uni-magdeburg.de), der sich für solche Zwecke einspannen lässt; mit diesem läuft es dann jetzt. Sonst hätte ich auf das Feature wohl verzichten müssen. Eine spontane Google-Suche nach Tools zur Zeitsynchronisierung unter Vista hat mich jedenfalls nur auf Seiten geleitet, die die Lösung mit bordeigenen Mitteln beschreiben.

Homepage mit trac 0.10.x

Wir arbeiten ab und zu an IMPULS. Anfang des Jahres sind wir mit dem Subversion-Repo hier nach antiblau gezogen und benutzen jetzt Trac anstelle des Bugtracking-Systems von Sourceforge. Trac bietet neben Repository Browser, Bug Tracker und Milestone-Verwaltung auch ein Wiki. Andere Projekte wie z.B. Licq oder lcd4linux haben ihre ganze Homepage mit Trac realisiert. Da sich ein Wiki ganz gut eignet um unabhängig von HTML-Editor, PHP-Kenntnissen etc. so eine Seite aktuell zu halten, beschloss ich die Homepage für Impuls auch mit dem sowieso schon genutzten Trac zu verwirklichen.

Die größte Hürde für eine sinnvolle Nutzung von Trac als Homepage stellt die Navigation dar. Im Wiki selbst sind mehr oder weniger nur Sprünge von Seite zu Seite möglich, eine einheitliche Navigation, beispielsweise über eine Sidebar ist so zunächst nicht vorgesehen. Dass das irgendwie möglich ist, sieht man bei Licq, also hab ich mir angeschaut, wie man das mit den Paketen von Debian Etch sinnvoll umsetzen kann, dort wird Trac in Version 0.10.x verwendet also noch vor der Umstellung der Template-Engine mit der 0.11.x.

Das Prinzip ist eigentlich ganz einfach: Trac an geeigneter Stelle in irgendeinem HTML-Template einen neuen div-Container unterschieben mit beliebiger Id und anhand dieser Id dann ein passendes CSS Stylesheet bauen. In diesem Fall haben wir in /usr/share/trac/templates/header.cs eine Zeile eingefügt:

Das hat den Vorteil, dass jede neue Trac-Installation von der Änderung erstmal nichts mitbekommt. Die Datei site_navi.cs muss im jeweiligen Trac-Projekt-Ordner angelegt werden, um in den Genuss der Navi-Sidebar zu kommen. Konkret geschieht dies im Unterordner templates des Trac-Projektordners, da wo z.B. auch die Dateien site_header.cs und site_footer.cs liegen. Die Datei site_navi.cs enthält dann den Inhalt der Sidebar, im Fall der IMPULS-Homepage sieht das so aus:

Fehlt noch das passende Stylesheet, dazu sind noch folgende Änderungen nötig. Zunächst eine Anpassung der Datei site_css.cs, die im gleichen Projektordner liegt:

Wie man sieht wird hier eine Stylesheetdatei eingebunden. In dieser wird dann das angepasste Stylesheet definiert. Die Datei style.css liegt ebenfalls im Trac-Projektordner und zwar im Unterordner htdocs. Im Falle der Impuls-Homepage hat sie folgenden Inhalt:

Damit sich die Sidebar harmonisch einfügt sind auch einige kleine Hacks an den bereits vorhandenen Elementen der Seite nötig, speziell die clear:right, damit der eigentliche Inhalt sauber neben und nicht unter die Sidebar gesetzt wird.

Was man in der Sidebar dann letztendlich verlinkt, bleibt jedem selbst überlassen. Im Falle von Impuls wollte ich eigentlich eine sehr flache Hierarchie haben, ist mir nicht ganz gelungen. Ansonsten genügt es für weitere Änderungen die beiden Dateien style.css und site_navi.cs zu bearbeiten. Mit einem möglichen Update auf Trac 0.11.x wird das ganze dann aber sehr wahrscheinlich nicht mehr funktionieren, weil dort keine Clearsilver-Templates mehr benutzt werden. Wenn es soweit ist, müssen wir mal schauen, wie wir das dann umsetzen.

Flock – Social Browsing

Eigentlich war ich auf der Suche nach einer Firefox-Integration für Bibsonomy. Aber wie das so ist, bin ich dabei über einige andere Dinge gestolpert. Zum Beispiel Flock.

Flock ist ein sogenannter Social Web Browser, das heisst, neben den üblichen Browser-Features (Flock ist ein Firefox-Abkömmling) gibt es eine Vielzahl von Integrationen für Web 2.0-Dienste, z.B. del.icio.us, Flickr, WordPress (tatsächlich schreibe ich gerade mit der WordPress-Integration von Flock).

Das Interface ist gewöhnungsbedürftig, weil es eine Menge neuer Optionen gibt. Wer aber sowieso viele Web 2.0-Dienste nutzt, wird sich damit wohlfühlen.

Branches und Merges mit Subversion 1.5

Nachdem letzte Woche der RC 5 von Subversion 1.5 veröffentlicht wurde, beschreibt Ben Collins-Sussman heute in seinem Blog ganz kurz das Feature von Subversion 1.5, auf das viele warten. Subversion 1.5 behält selbst ein Auge auf Branches und Merges und macht das Arbeiten mit Branches damit um einiges leichter. Er demonstriert dies an einem beispielhaften Arbeitsablauf:

1. Make a branch for your experimental work:

$ svn cp trunkURL branchURL
$ svn switch branchURL

2. Work on the branch for a while:

# ...edit files
$ svn commit
# ...edit files
$ svn commit

3. Sync your branch with the trunk, so it doesn’t fall behind:

$ svn merge trunkURL
--- Merging r3452 through r3580 into '.':
U button.c
U integer.c

$ svn commit

4. Repeat the prior two steps until you’re done coding.
5. Merge your branch back into the trunk:

$ svn switch trunkURL
$ svn merge --reintegrate branchURL
--- Merging differences between repository URLs into '.':
U button.c
U integer.c

$ svn commit
6. Go have a beer, and live in fear of feature branches no more.

Wenn man bedenkt, wie aufwändig manuelles Merging bei Subversion vorher war, könnte das jetzt kaum einfacher sein. Man musste in den Commit-Messages die Revisionsnummern mitloggen und aufpassen auch ja die richtigen Sachen von einem Branch in den anderen zu tun. Jetzt brauch man sich um die Revisionsnummern nicht mehr kümmern, das wird alles wegfallen, super coole Sache!

Einsam in der Zwischenablage

Zu den ungelösten Rätseln der Windows-Gemeinschaft (unfreiwillige Mitgliedschaft üblich) gehört auch die Antwort auf die Frage, wieso die Zwischenablage (aka Clipboard) auch bei Windows Vista weiterhin nur die Aufnahme eines einzigen Elements erlaubt, während andere Desktopsysteme schon seit Generationen eine einfache Clipboard-Verwaltung über die Traybar erlauben.

Bislang habe ich mich damit abgefunden, heute wurde es mir zu nervig, ständig Daten aus der Zwischenablage zu verlieren. Deshalb habe ich mich einmal auf die Suche nach entsprechenden Tools gemacht. Folgende Einschränkungen waren gegeben:

  • Lauffähig unter Windows Vista (was auf dem Rechner im Labor installiert ist)
  • OpenSource, wenigstens FreeWare – ich mag für dieses “Feature” nicht auch noch bezahlen
  • möglichst schlank
  • einfach bedienbar, ohne in die gewohnte Arbeitsweise einzugreifen

Schon der erste Punkt hat die Auswahl sehr stark begrenzt, was aber letztendlich auch den Entscheidungsprozess vereinfacht hat. Interessant bis erschreckend fand ich, dass solche Tools nur selten kostenlos verfügbar sind. Letztendlich hab ich mich mit einer Lite-Version zufrieden, die als Freeware erhältlich ist. Selbst mit grundlegenden Funktionen kann man hier noch Geld verdienen.

Drei Kandidaten blieben letztendlich übrig:

  1. ClipMagic
  2. MultiClipBoard
  3. Visual Clipboard LE

ClipMagic erschien mir auf den ersten Blick zu überladen. Ich möchte meine Zwischenablage nicht klassifizieren und auch nicht langzeitarchivieren.

MultiClipBoard entspricht zwar dem gewünschten Funktionsumfang, sieht aber selbst für meinen Geschmack einfach hässlich aus. Das Tool kam auf die Ersatzbank.

Blieb noch Visual Clipboard LE, das zwar nur in abgespeckter Version kostenlos ist, dafür aber ansprechend aussieht und meine funktionalen Anforderungen erfüllt. Es lassen sich eine voreinstellbare Zahl von Texten und Bildern speichern und rudimentäre Einstellungen, insbesondere zur Art der Aktivierung vornehmen. Die Mausaktivierung habe ich ausgestellt – ich werde sie wohl eh nicht nutzen – per Tastatur wird die Auswahl eines Clipboard-Inhaltes per Druck auf Strg+Alt angezeigt. Leider lässt sich diese Einstellung nicht ändern.

Ich werde beobachten, die gut ich mit diesem Tool auskomme. Natürlich nehme ich gern Hinweise für weitere Tools, die den oben genannten Kriterien entsprechen, entgegen.

Noch ein Tipp: Wenn man (jedenfalls unter Vista) beim Öffnen eines Kontextmenüs im Explorer die Shift-Taste gedrückt hält, erscheinen weitere Optionen. Zum Beispiel “Als Pfad kopieren”, um den Pfad einer Datei in die Zwischenablage zu verbringen.

Kernel-Upgrade: Gar nicht so einfach

Nachdem ich die NE2k-Netzwerkkarte aus meinem Server durch eine 3com-Karte ersetzt hatte, dachte ich mir heute, dass ich eigentlich das längst fällige Kernel-Upgrade mal durchführen könnte. Bislang wurde das durch eben jene Netzwerkkarte verhindert, die nur mit einer Kernel-Version <= 2.6.18 lief.

Ganz so einfach, wie ich anfangs dachte, sollte sich das Upgrade dann aber doch nicht gestalten. Meist erzeuge ich die neue Config, indem ich das alte .config-File in das neue Kernelverzeichnis kopiere und dann manuell die Konfiguration anpasse. Die Parameter passen in der Regel so, dass ich am neuen Kernel kaum etwas verändern muss.

Heute nicht: Offenbar hat sich in den Bereichen SATA-Treiber und Netzwerkfilter so viel geändert, dass einige meiner Optionen, nämlich der SATA-Controller-Treiber selbst und die Targets für das NAT, nicht übernommen wurden. Und weil das letzte Kernel-Basteln mit diesem Rechner schon seeehr lange her ist, wusste ich eigentlich nur noch, dass der Treiber meines Controllers komplett anders heisst, als Chipsatz und Karte. Zum Glück hat die alte Kernel-Konfiguration noch aufschlussreiche Hinweise geliefert. SATA-Krams ist jetzt jedenfalls in einem eigenen Bereich und recht komplett vom SCSI getrennt.

Eine spontane Idee, die ich dabei hatte: Man könnte auf einer Webseite (zum Beispiel unter der Domain kernelconfig.org) einen Service einrichten, der Konfigurationen für einen bestimmten Kernel entgegennimmt und auf möglichst gleich funktionierende Konfigurationen für einen neueren Kernel umsetzt. Im gleichen Zuge könnten noch Tipps gegeben werden, wie sich die Konfiguration verbessern lässt und als Plus könnte passend zu einer Systemanalyse (dmesg, lspci, isapnp, lsusb, ….) eine passende Kernel-Konfiguration ausgegeben werden. Falls jemand viel Zeit und Lust hat …

Auf jeden Fall habe ich nun einen aktuellen Kernel (2.6.25) auf meinem Server und kann wieder Uptime sammeln. :)

LIRC für eisfair – eine Episode voller Rückschläge

Wie man auf Pack-Eis sehen kann, betreue ich das Paket »LIRC« für Eisfair. Wie bei climm und GnuPG bin ich 2005 aus persönlicher Notwendigkeit heraus in diese Rolle gerutscht. Mein Heimserver war damals für das Abspielen meiner Musik verantwortlich und eine Infrarotfernbedienung ist da Gold wert. Wie so oft im OpenSource-Bereich brachte ich das Paket auf einen Stand, der meinen Anforderungen genügte und beließ es bei einer längeren Liste mit Ideen und ToDos, die im Prinzip seit 2005 auf ihre Umsetzung warten – andere Dinge waren halt wichtiger.

Nun wurde kürzlich ein neues Kernel-Paket für eisfair-1 veröffentlicht: ein gepatchter 2.4.35. Wir haben im Testteam lange getestet bis er im März der Öffentlichkeit zum Fraß vorgeworfen wurde. Ein neuer Kernel bedeutet aber auch, dass LIRC neu übersetzt werden muss, da es seine Treiber selbst mitbringt und Kernelmodule nunmal zur Kernelversion passen müssen. Es gab auch schon die eine oder andere Anfrage in der Newsgroup und ich beschäftige mich seit ein paar Tagen mit einer neuen Version des Pakets.

Zunächst steht das Kompilieren an. Ich konnte LIRC 0.8.2 für die eisfair-Kernel 2.4.26-1 und 2.4.35-wt1 jeweils in den Versionen mit und ohne Unterstützung für SMP übersetzen – für 2.4.26 mit der alten Build-Umgebung mit gcc 2.95.3 und für den 2.4.35 mit der zukünftigen Build-Umgebung mit gcc 3.4.6, die zur Zeit vom Testteam getestet wird. Das Übersetzen von LIRC artet schnell in Arbeit aus, weil es mit einem Lauf aus ./configure, make und make install nicht getan ist. Das muss für jede Kernel-Version und jeden gewünschten Treiber einzeln gemacht werden, es sei denn, man kompiliert gleich alle Treiber. Tut man dies nicht, ist noch mindestens ein Lauf mit der Option --with-driver=userspace nötig, damit LIRC auch in der Lage ist mit verschiedenen Treibern gestartet zu werden und nicht nur mit dem, für den es kompiliert wurden, wie z.B. serial.

Also wie gesagt, ich konnte LIRC für die Treiber serial und atiusb kompilieren – das sind die beiden, wo ich selbst Hardware zum Testen habe. Dank VMware waren auch die verschiedenen Kernel kein Problem, ich hab einfach für jeden eine neue virtuelle Maschine angelegt. Die anfängliche Euphorie, dass auch ein LIRC 0.7.1 mit den aus 0.8.2 gebauten Kernelmodulen für 2.4.35 läuft, wich dann der ersten Enttäuschung. Ich hatte zunächst die Version, die mit allen Treibern laufen soll, mit --with-driver=none kompiliert. Das funktionierte logischerweise nicht. Der erste herbe Rückschlag: LIRC 0.8.1, 0.8.2 und 0.8.3pre1 lassen sich mit der neuen eisfair-Buildumgebung und der korrekten Option --with-driver=userspace nicht übersetzen, wie man auf der Mailingliste von LIRC nachlesen kann.

Man kann dort ebenfalls nachlesen, dass ich versucht habe, die neueste Version aus dem CVS zu übersetzen, wo dieser Fehler bereits behoben ist. Leider macht mir da die Buildumgebung einen Strich durch die Rechnung. Das Skript ./configure liegt nicht im CVS, sondern wird mit den autotools (autoconf, automake usw.) erst noch selbst erzeugt. In der Theorie funktioniert das gut, in der Praxis tritt bei mir leider der gleiche Fehler auf, den ich vor einiger Zeit schon hatte, als ich climm aus dem SVN bauen wollte. Es wird ein unbrauchbares Skript erzeugt, dass nur eine wenig hilfreiche Meldung ausgibt. Wenn sich jemand gut mit autoconf auskennt und eine Idee hat, wo da das Problem liegt, möge sie sich dringend bei mir melden! Fazit jedenfalls: LIRC aus CVS ist für mich nicht möglich.

Heute erreichte mich dann über die Mailingsliste von LIRC die überraschende Nachricht, dass gerade die 0.8.3pre2 rausgegeben wurde. Der o.g. Fehler tritt nicht mehr auf, dafür ein neuer. LIRC lässt sich nicht mehr mit dem Treiber serial übersetzen, weil in der entsprechenden Quellcode-Datei eine Header-Datei aus den Kernelquellen nicht gefunden wird. Zumindest wird sie bei den 2.4er Kerneln nicht gefunden. Ein flüchtiger Blick in den Quellbaum eines 2.6er Kernels offenbarte, dass es dort zwei Dateien io.h gibt, eine in /usr/src/linux/include/linux und eine in /usr/src/linux/include/asm – beim 2.4er Kernel gibt es bloß letztere.

Auch dies habe ich auf der Mailingliste von LIRC gemeldet und warte erstmal ab. Es gibt nämlich mehrere Möglichkeiten jetzt:

  • ich warte ab, bis die nächste LIRC-Version veröffentlicht wird, mit der ich alles korrekt übersetzen kann
  • ich baue das allgemeine LIRC und die Treiber für atiusb aus der 0.8.3pre2 und die Treiber für serial aus der 0.8.2
  • ich kann durch wundersame Eingebung oder Hilfe von außen den Fehler in der Buildumgebung finden, so es denn tatsächlich einer in dieser ist, und die aktuelle Version aus dem CVS übersetzen
  • ich gehe in den Versionen soweit zurück, bis ich auf eine stoße, die ich komplett übersetzen kann, das wäre dann wahrscheinlich die 0.8.0
  • ich behebe den Fehler in 0.8.3pre2 selbst und übersetze dann meine modifizierte Version

Ehrlich gesagt, gefällt mir die erste Version bisher am besten, allerdings könnte das unter Umständen noch eine Weile dauern, je nachdem wie schnell die Entwickler von LIRC die nächste Version rausbringen. Module aus verschiedenen Versionen wollte ich eigentlich vermeiden, um mir nicht eine zusätzliche Fehlerquelle aufzureißen. Auch eine alte Version finde ich nicht so cool. Ob wir den potentiellen Fehler in der Buildumgebung schnell finden, ist auch ungewiss, bleibt also im Grunde noch die letzte Möglichkeit: ich stöber durch den C-Code und beheb den Fehler selbst – dazu hab ich keine Lust…

Falls sich also jemand fragt, warum die neue Version des LIRC-Pakets für eisfair so lange braucht, ich weise sämtliche Schuld von mir und schiebe es auf höhere Gewalt!