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!
