![[Foto: FreeBSD beschwert sich über das verschwinden von /dev/ad1. Der Festplatte
auf dem es installiert ist.]](freebsd-ad1-timeouts-504x414.jpg "ad1 antwortet nicht. Wo war noch mal / drauf?")
Der Rechner ist ein undankbarer Schrotthaufen, trotz Radiatorverlegung und Kühlwasserwechsel
nervt er mit Abstürzen, die ich auf minderwertige Festplattenkabel zurückführe.
www.fabiankeil.de/blog-surrogat/2005/10/30/e17-update-mit-hindernissen.html
Vor etwas über einem Monat bin ich von E16 auf E17 umgestiegen. Genauer gesagt: auf 0.16.999.013. Mittlerweile ist Version 0.16.999.018 aktuell, die meisten Zwischen-Versionen waren auch in den FreeBSD-Ports vorhanden.
Ich versuchte mehrfach, E17 zu aktualisieren, bin aber immer gescheitert.
Mit jeder Version erhielt ich andere Fehler vom Compiler. Nicht sicher, ob die Quellen von freedesktop.org, oder FreeBSD-eigene Patches das Problem hervorriefen und da meine C-Kenntnisse nahe Null liegen, wartete ich erstmal ab.
Auf den Mailinglisten gab es keine passenden Problemberichte, von daher war ich auch nicht restlos überzeugt, dass das Problem nicht teilweise mit meinen Systemen zusammenhing. Auch wenn das Problem sowohl unter FreeBSD 5.4, als auch unter einem relativ frischen FreeBSD 6.0 auftrat.
Heute erhielt ich folgenden Fehler:
root@r51 /usr/ports/x11-wm/enlightenment-devel #make ===> WARNING: Vulnerability database out of date, checking anyway ===> Extracting for enlightenment-0.16.999.018 => Checksum OK for enlightenment-0.16.999.018.tar.gz. ===> Patching for enlightenment-0.16.999.018 ===> Applying FreeBSD patches for enlightenment-0.16.999.018 ===> enlightenment-0.16.999.018 depends on executable: gmake - found ===> enlightenment-0.16.999.018 depends on file: /usr/local/bin/libtool15 - found ===> enlightenment-0.16.999.018 depends on shared library: Imlib2.3 - found ===> enlightenment-0.16.999.018 depends on shared library: evas.1 - found ===> enlightenment-0.16.999.018 depends on shared library: edje.5 - found ===> enlightenment-0.16.999.018 depends on shared library: ecore.1 - found ===> enlightenment-0.16.999.018 depends on shared library: embryo.9 - found ===> enlightenment-0.16.999.018 depends on shared library: eet.9 - found ===> enlightenment-0.16.999.018 depends on shared library: iconv.3 - found ===> enlightenment-0.16.999.018 depends on shared library: intl - found ===> enlightenment-0.16.999.018 depends on shared library: X11.6 - found ===> Configuring for enlightenment-0.16.999.018[...]===> Building for enlightenment-0.16.999.018 gmake all-recursive gmake[1]: Entering directory `/usr/ports/x11-wm/enlightenment-devel/work/enlightenment-0.16.999.018' Making all in src gmake[2]: Entering directory `/usr/ports/x11-wm/enlightenment-devel/work/enlightenment-0.16.999.018/src' Making all in bin gmake[3]: Entering directory `/usr/ports/x11-wm/enlightenment-devel/work/enlightenment-0.16.999.018/src/bin' cc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/X11R6/include -I../.. -I../../src/bin -I../../src/lib -DUSE_ E_CONFIG_H -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/X11R6/i nclude -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=FAST_PC -I /usr/local/include -I/usr/X11R6/include -O -pipe -march=pentium4m -c e_main.c In file included from e_includes.h:14, from e.h:87, from e_main.c:4: e_border.h:199: error: syntax error before "Ecore_X_Icon" gmake[3]: *** [e_main.o] Error 1 gmake[3]: Leaving directory `/usr/ports/x11-wm/enlightenment-devel/work/enlightenment-0.16.999.018/src/bin' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/x11-wm/enlightenment-devel/work/enlightenment-0.16.999.018/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/x11-wm/enlightenment-devel/work/enlightenment-0.16.999.018' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Stop in /usr/ports/x11-wm/enlightenment-devel.
Mein Leidensdruck war stark genug angewachsen, um mich zu motivieren, das Problem ein bisschen genauer
anzuschauen. Dafür brauchte ich eine halbe Ewigkeit, obwohl der Fehler eigentlich
offensichtlich ist: evas, ecore, edje, eet und embryo werden nicht
aktualisiert, make hält ihren Versionsstand für ausreichend.
Installiert waren noch ecore-0.9.9.013, edje-0.5.0.013, eet-0.9.10.013, embryo-0.9.1.013, und evas-0.9.9.013. Für Enlightenment 0.16.999.018 nicht neu genug. Nachdem ich die Abhängigkeiten per Hand aufgelöst hatte, ließ sich E17 anstandslos kompilieren und installieren.
Da mein Laptop bereits aktualisiert war, meldete ich mich auf dem Desktop-Rechner an, auf dem noch 0.16.999.013 lief. Dort versuchte ich, das Problem im Makefile zu beheben, um dem Port-Maintainer gleich einen Patch schicken zu können.
Der Rechner ist ein undankbarer Schrotthaufen, trotz Radiatorverlegung und Kühlwasserwechsel
nervt er mit Abstürzen, die ich auf minderwertige Festplattenkabel zurückführe.
Innerhalb von fünf Minuten meldete sich zweimal in Folge die Festplatte ab. Wenn die Root-Partition verschwindet wird auch FreeBSD 6.0 unglücklich und lässt sich nur durch Neustart reanimieren.
Zwei unfreiwillige Neustarts sind fast drei zu viel. Sie bewogen mich dazu, den Rechner unterm Schreibtisch hervor zu reißen, das Gehäuse mit einem Messer zu öffnen (keine Zeit den verlegten Schraubenzieher zu suchen) und alle Kabel auf festen Sitz zu überprüfen.
Alle Stecker saßen soweit ich fühlen konnte stabil, danach machte er erstmal keine Mucken mehr, um die Investition in neue Kabel werde ich jedoch auf Dauer nicht rumkommen.
Meine Versuche das Makefile anzupassen, waren leider erfolglos. Vor allem deshalb, weil ich dessen Syntax falsch verstand und zu faul war, im Handbuch nach Erleuchtung zu suchen. Im Makefile heißt es:
LIB_DEPENDS= Imlib2.3:${PORTSDIR}/graphics/imlib2 \
evas.1:${PORTSDIR}/graphics/evas \
edje.5:${PORTSDIR}/graphics/edje \
ecore.1:${PORTSDIR}/x11/ecore \
embryo.9:${PORTSDIR}/lang/embryo \
eet.9:${PORTSDIR}/devel/eet
Ich dachte, die Nummern würden sich auf die Ausgabe von pkg_info beziehen. Dass ecore-0.9.9.013 gar keine 1 enthält, übersah ich.
Nach ein wenig planlosem Rumeditieren hatte ich Make so weit gebracht, die vorhandenen Versionen als unpassend anzusehen und die aktuellen Versionen zu besorgen.
Danach beschwerte sich Make jedoch darüber, noch immer die falschen Bibliotheken
vorzufinden. Das dann noch noch benutzte Handbuch
erklärt auch warum. Die Nummern beziehen sich auf die Ausgabe von ldconfig -r.
Diese bleibt jedoch gleich:
fk@r51 ~ $ldconfig -r|grep ecore
124:-lecore.1 => /usr/X11R6/lib/libecore.so.1
125:-lecore_job.1 => /usr/X11R6/lib/libecore_job.so.1
147:-lecore_txt.1 => /usr/X11R6/lib/libecore_txt.so.1
148:-lecore_con.1 => /usr/X11R6/lib/libecore_con.so.1
149:-lecore_x.1 => /usr/X11R6/lib/libecore_x.so.1
150:-lecore_ipc.1 => /usr/X11R6/lib/libecore_ipc.so.1
164:-lecore_evas.1 => /usr/X11R6/lib/libecore_evas.so.1
165:-lecore_config.1 => /usr/X11R6/lib/libecore_config.so.1
166:-lecore_file.1 => /usr/X11R6/lib/libecore_file.so.1
167:-lecore_dbus.1 => /usr/X11R6/lib/libecore_dbus.so.1
Ich hatte make nur dazu gebracht, die ldconf-Ausgabe nicht mehr
anzuerkennen, nicht aber dazu, sich für die pkg_info-Ausgabe zu interessieren,
auf die meine Änderungen passen würden.
So wie es aussieht, müssen die Versionen von ecore, edje, eet, embryo und evas hochgezählt werden, da sie nicht mehr kompatibel zu ihren Vorgängern sind. Da E17 noch in der Entwicklung ist, eigentlich kein Wunder.
Das überlasse ich lieber Leuten, die wissen was sie tun. Die Verantwortung habe ich per Mail abgeschoben.
Das Update hat sich übrigens gelohnt, mehr dazu später.