Skip to content

Google Summer of Code

Gestern abend hat Google die teilnehmenden Projekte am Summer of Code bekannt gegeben. Auf der Liste stehen viele bekannte Organisationen und auf deren Seiten finden sich auch recht interessante Projekte. Unter anderem ist das Tor-Projekt diesmal wieder dabei. Es gibt einiges an Vidalia zu verbessern und auch einige nette Applikationen um Tor herum sind auf der Seite erwähnt. Falls du also Lust hast, etwas Zeit mit Programmieren zu verbringen, schau die GSoC-Seite mal an. Es findet sich dort wahrscheinlich für jeden etwas.

Distrowars

Ich hatte auf meinem Laptop seit einiger Zeit ein Ubuntu installiert und kürzlich war ich der Meinung, dass er mal eine andere Distribution benötigt. Zum einen war kürzlich grml in der Version 1.1 erschienen und wollte getestet werden, andererseits hatte ich früher Gentoo und damit war ich damals auch zufrieden.

grml bringt das Programm grml2hd mit. Damit lässt sich die Live-CD auf die Festplatte bringen. Die Installation selbst ist recht einfach. Es wird nach der Partition und dem Dateisystem gefragt, Nutzer angelegt etc. In kürzester Zeit war das System installiert und ich konnte es nutzen. Doch es dauerte nicht lange und ich bemerkte, dass der Rechner beim Runterladen großer Dateien langsam wurde. Ein Blick auf die DMA-Einstellungen bestätigte den Verdacht, dass kein DMA eingeschalten ist. Es liess sich nicht aktivieren und dmesg zeigte:

ata_piix 0000:00:1f.2: version 2.12
ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ]
PCI: Unable to reserve I/O region #1:8@1f0 for device 0000:00:1f.2
ata_piix 0000:00:1f.2: failed to request/iomap BARs for port 0 (errno=-16)
PCI: Unable to reserve I/O region #3:8@170 for device 0000:00:1f.2
ata_piix 0000:00:1f.2: failed to request/iomap BARs for port 1 (errno=-16)
ata_piix 0000:00:1f.2: no available native port

Spätere Tests ergaben, dass das ein “grml-Problem” ist. Ich konnte den Effekt bei keiner anderen Live-CD (Debian, Gentoo, Knoppix, Ubuntu) feststellen. Eine Idee war noch, einen anderen Kernel zu installieren. Gesagt, getan. Doch nach einem Reboot begrüsste mich die Meldung GRUB. Also wieder die Live-CD eingeworfen und mittels grub-install den Rechner wieder bootfähig gemacht. Mika gab mir noch einen Tip, einen Blick auf /etc/kernel-img.conf zu werfen. Doch selbst mit einer angepassten Konfiguration ging das schief.

Daneben gab es noch kleinere Probleme und ich entschied mich, mit Gentoo weiter zu machen. Gentoo bringt seit einiger einen grafischen Installer mit. So hoffte ich, den mal praktisch testen zu können. Aber der X-Server tat mir nicht den Gefallen zu starten. So versuchte ich den konsolenbasierten zu nutzen. Dieser stürzte jedoch undeterministisch ab. Ich schaffte es damit nur einmal in die Nähe einer Installation zu kommen. Ich hätte es zwar noch auf dem klassischen Weg probieren können. Dazu fehlte mir jedoch die Lust.

Bei Distrowatch schaute ich mich noch nach weiteren interessanten Distributionen um. Jedoch konnte ich nichts ansprechendes finden und unternahm deswegen einen letzten Versuch mit Debian. Zu meiner Überraschung war das eine komplett problemlose Angelegenheit. Die Installation lief problemlos durch. Danach habe ich ein paar Anpassungen gemacht, Software eingespielt und Konfigurationen ergänzt. Also läuft auf dem Rechner zunächst mal Debian. Zumindest bis es mir zu langweilig wird. ;-)

Ach ja, wer sich fragt, welchen exotischen Rechner ich denn habe: IBM Thinkpad R52

Bitten by Subervsion

Kürzlich erhielt ich den Auftrag, einige Subversion-Repositorys auf einen neuen Server umzuziehen. Dazu sollte noch ein Trac (Bug-/Issuetracker) auf den Rechner sowie WebDAV angepasst werden. Alles in allem keine große Sache. Es sollte innerhalb eines Arbeitstages gegessen sein. Sollte ...

Nach einigen Vorbereitungsarbeiten warf ich im ersten Repository ein beherztes svnadmin dump $REPO > $REPODUMP an und wartete. Kurz vor Ende brach der Prozess ab und meldete svnadmin: Found malformed header in revision file. Eine Websuche ergab, dass die Datenbank wahrscheinlich korrupt ist. Die Fehlerquelle liegt wahrscheinlich im Zusammenspiel von mod_dav und Subversion. Gleiches kann auch mit svnserve auftreten. Soweit ich las, ist der Fehler nicht genau reproduzierbar. Daher existieren auch keine Fixe. Eine zweite mögliche Fehlerquelle liegt in der Hardware. Auf dem Server gab es wohl in dem Zeitraum Probleme mit dem RAID. Eventuell kommt das Problem auch daher. Die Mailingliste von Subversion ergab hier nur einen Hinweis auf das Pythonskript fsfsverify von John Szakmeister. Im Verzeichnis $REPO/db/revs liegen die bisherigen Revisionen und man übergibt dem Skript einfach die fehlerhafte Datei. (Wobei das nur für das Format FSFS gilt.) Aber das einzige, was das Skript dabei ausspuckte, war:

File “/foo/bar/fsfsverify/fsfsverify.py”, line 661, in __init__
  (field, value) = line.split(’:’, 1)

Was tun?, sprach Zeus. Ich entschied mich, einen genaueren Blick in die Struktur von FSFS zu werfen und auch den Autor des Programms um Rat zu fragen. FSFS hat den Vorteil, dass es pro Datei immer nur einen binären Diff mit Metainformationen speichert. Somit könnte man praktisch die Informationen wieder zurückgewinnen, denn das Format des Diffs ist ebenfalls offengelegt. Jedoch ist bei dem Repository ein durchschnittlicher Diff 1,5MB (sic!) groß. Da will man nichts händisch zusammenbasteln. John antwortete mir glücklicherweise und bot seine Hilfe an. Nach einigem Mailaustausch schafften wir es, die Datenbank zu reparieren. Der dabei entstandene Diff entspricht zwar nicht dem Originaldiff. Aber er kommt nahe dran.

So kann ich jetzt mit einer Woche Verzögerung das Projekt beenden. Trotz der Verzögerung sind alle glücklich. :-)

cronjob