This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.
Die meisten, die mich persönlich kennen oder durch das Archiv dieses Blogs stöbern, wissen, das Gentoo meine absolute Lieblingsdistribution ist. Der Grund ist für mich vor allem das Paketsystem "Portage" bzw. das Konzept der Use-Flags, welche eine Anpassung des System auf einem Level erlaubt, zu dem man bei den üblichen Binärdistributionen wie Ubuntu, SuSE, RedHat und co nur mit sehr großem Aufwand gelangen kann - der User "BliZZarD" hat das Anfang des Jahres im Heise-Forum ziemlich gut auf den Punkt gebracht.
Doch seit sich vor einigen Jahren der Gründer Daniel Robbins aus dem Projekt zurückgezogen hat, lässt das System spürbar nach. Zunächst hielt ich das Editorial im aktuellen LinuxUser (11/2008) für übertrieben - doch beim letzten Update stieß ich auf das in Bug #244511 beschriebene Problem.
Offenbar bereits seit drei Tagen sind Pakete als "Stable" markiert, die zur Installation die noch als unstable geltene Portage-Version 2.1.5 benötigen. Im Ergebnis sieht man beim Versuch, ein Update durchzuführen, im Moment folgende Ausgabe:
Calculating world dependencies... done!
[ebuild U ] sys-libs/com_err-1.40.9 USE="nls" 0 kB
[ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 USE="nls" 0 kB
[ebuild U ] sys-fs/e2fsprogs-1.41.2 USE="nls" 0 kB
[ebuild U ] sys-libs/ss-1.40.9 USE="nls" 0 kB
[blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B ] sys-libs/e2fsprogs-libs (is blocking sys-libs/ss-1.40.9,sys-libs/com_err-1.40.9)
Die übliche Lösung bei solchen "blockings" ist es, das betroffene Paket vor dem Update zu entfernen. In diesem Fall wäre das aber hochgradig fatal, denn das zum Download der Pakete verwendete Programm "wget" hängt von der Systembibliothek "com_err" ab, wie Robert Wolf bereits vor zwei Tagen feststellte. Dieser auch von den Entwicklern empfohlene und normalerweise korrekte Weg würde einem das System also beschädigen und unter Umständen nur mit recht hohem Aufwand wiederherstellbar machen (sprich: die benötigten Pakete an einem anderen Rechner herunterladen und anschließend kopieren).
Die Lösung ist eigentlich einfach und von Daniel Carosone in Beitrag #40 beschrieben: Die Pakete wieder als unstable markieren, bis portage-2.1.5 stabil geworden ist und die Blockings selber Auflösen kann. Doch bis jetzt ist nichts passiert. Für das Projekt ist das wirklich peinlich, mit einer stabilen Version, die sich seit drei Tagen nicht sauber aktualisieren lässt, macht sich das Projekt wirklich keine Freude.
Wer davon betroffen ist, kann entweder (1) Portage in der Version 2.1.5 als stabil markieren und anschließend auf diese Version wechseln:
Obwohl ich mit beiden Verfahren erfolgreich war, ist (2) meine klare Empfehlung. Zumindest solange, wie es keine saubere Lösung für das Problem gibt und man auf die neuere Version der Programme nicht angewiesen ist.
This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.
Update: Due to an increasing number of english speaking visitors I have translated the main conclusion of this entry. Have a look at the comments.
Na, das ging ja gut los. Der Versuch, mit dem KNetworkManager eine statische IP-Adresse über's normale Kabel einzurichten, scheiterte. Die Daten wurden akzeptiert, aber nicht aktiviert. Der gleiche Versuch mit der Gnome-Variante des Tools ( nm-applet) verlief erfolgreich, integrierte sich aber natürlich alles andere als gut in die KDE-Umgebung (ansonsten hätte ich damit auch leben können).
Auf der Kommandozeile war als Ausgabe nur diese läppische Zeile zu finden:
Activate Connection /org/freedesktop/NetworkManagerSettings/Connection/2 on Device /org/freedesktop/Hal/devices/net_00_00_f1_7b_97_e0
Das Syslog ( /var/log/syslog) war da etwas informativer:
Nov 3 14:02:40 sam NetworkManager: connection _get _settings _cb(): connection _get _settings _cb: Invalid connection: 'NMSettingIP4Config' / 'addresses' invalid: 1
Nov 3 14:02:40 sam NetworkManager: connection _get _settings _cb(): connection _get _settings _cb: Invalid connection: 'NMSettingIP4Config' / 'addresses' invalid: 1
Nov 3 14:02:57 sam NetworkManager: connection _updated _cb: assertion `old _connection != NULL' failed
Bei der Suche nach dieser Ausgabe stieß ich auf einen Bugreport, der mir zeigte, dass ich nicht der einzige mit dem Fehler war. Um es kurz zu machen: Nachdem es auch dort keine Lösung gab, habe ich mir die Quelltexte der Pakete network-manager und network-manager-kde heruntergeladen, mit einigen Debugging-Ausgaben angereichert und bin schließlich dahinter gekommen, dass der Systemdienst NetworkManager die Netmask im CIDR-Format erwartet ("/24"), KNetworkManager diese aber im Dezimalformat ("255.255.255.0") übergibt.
Zu einem Patch hatte ich dann keine Zeit mehr, aber es gibt einen einfachen Workaround: Im Feld für die Netzmaske diese in CIDR-Schreibweise in den ersten Block eintragen, und die restlichen mit Nullen auffüllen: "24.0.0.0". Dann bekommt NetworkManager genau das übergeben, was er erwartet.
Aber das so ein fundamentaler Fehler im Release noch nicht behoben worden ist, erstaunt mich dann ja doch.
This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.
Wir haben gerade eine wunderschöne Rechnung über eine Summe von exakt 100 EUR netto erstellt. Darauf kommen genau 19 EUR MwSt, möchte man meinen. Nur Lexware ist - mal wieder - anderer Meinung:
Mag sein, dass das rechtlich so OK ist - aber erklär das mal dem Kunden... :-(
This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.
Und wie es sich für so eine Bild-Schlagzeile gehört mit einem großen orangenen Warndreieck daneben.
Kurze Hintergrund-Information: Die nächste Ubuntu-Version kommt mit dem neuen Linux-Dateisystem "ext4". Nun wurde festgestellt, dass bei einem Absturz kurz nach dem Start die Konfigurationsdateien von KDE und Gnome zerstört (= geleert) sein können, was einen erneuten Start etwas schwierig macht. Nach einer kurzen Analyse hat der Entwickler des Dateisystems, Ted Ts'o, einen Workaround geschrieben, aber auch deutlich gemacht, dass eigentlich die Anwendung fehlerhaft programmiert ist.
Erst nach sechs Stunden hat sich mal jemand die Mühe gemacht, den Original-Kommentar von Ted Ts'o zu lesen. Kurz zusammengefasst: Viele Programmierer verlassen sich darauf, dass nach einem close() die Dateien auf der Festplatte liegen - was aber per Definition nicht wahr ist, erst ein flush() stellt dies sicher. Und damit ist es definitiv ein Fehler in der Anwendung, der halt erst dann auffällt, wenn das Dateisystem - wie auch ext4 - die Daten aus Performanz-Gründen lange im Speicher behält.
Aber das wirklich hässliche am Heise-Forum ist: All diese unqualifizierten Beiträge sind grün bewertet worden.
open("w")Achtung Betriebssystem, ich möchte in diese Datei schreiben, lass bloß niemand anderen da jetzt dran!close()So, ich bin fertig, nun dürfen andere auch wieder.flush()Hey Betriebssystem, ich hoffe, DU bist auch fertig mit der Datei.
This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.
Es könnte so einfach sein,
ist es leider nicht!
Um in OpenOffice.org 3 ein mit Einfügen > Bild > Aus Datei... in ein Textdokument eingebettetes Bild zu drehen, muss man ernsthaft das Bild in die Zwischenablage kopieren, in OpenOffice Draw einfügen, dort drehen ( Rechtsklick > Position und Größe), kopieren und wieder im Writer einfügen. Lustigerweise kann man es anschließend auch im Textdokument drehen.
Dazu fällt mit außer "Frickelware" eigentlich nichts ein. In OpenOffice 2.0 ging es übrigens direkt aus dem Writer.
This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.
Naja, eigentlich nicht KDE, sondern der Network-Manager von KDE 4.2, plasma-widget-network-manager. Seit ewigen Zeiten ist dort der Bug mit der Nummer 334052 offen. Dieser Bug beschreibt einen Fehler der Auftritt, wenn man versucht, den "WPA Enterprise"-Modus (WPA-EAP) für WLANs zu verwenden. Ja, genau das Protokoll, welches von eduroam eingesetzt wird.
Obwohl der Bug nun schon seit 3 Monaten bekannt ist, gibt es immer noch keinen funktionierenden Fix, ja eigentlich nichtmal eine ernsthafte Reaktion der Entwickler! Sieht so aus, als müsste ich da mal wieder ran (nachdem ich schon den Vorgänger KNetworkManager aufgrund eines anderen Bugs und ebenfalls ausbleibender Reaktion fixen musste). Sowas ist echt ärgerlich. Zumal ich überlege, das Ding rauszuschmeißen und statt dessen einfach das Gnome-Applet zu verwenden.
Update 2009-05-14
Sieht so aus, als sei der Bug nun endlich behoben; im Report steht seit gestern ein Patch bereit, der zu funktionieren scheint. Für mich etwas zu spät.
This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.
Update 20.05.2009: Mit dem heute erschienenen Update auf kernel-desktop-2.6.29.3-1mnb-1-1mnb2 hat sich das Problem zumindest für mich erledigt. Der hier beschriebene Workaround sorgt nun im Gegenteil dafür, dass der X-Server nicht mehr startet. Deshalb vor dem Update die Zeile unbedingt auskommentieren!
Die Performance-Probleme gingen doch nicht auf Mandrivas Kappe. Statt dessen ist Intel schuld: Die Kombination aus Treiber-Version 2.7.0 und Kernel 2.6.29 macht laut diesem Foren-Beitrag zicken!
Die dort empfohlene Abhilfe hat auch bei mir funktioniert. In die /etc/X11/xorg.conf in der Section Device den folgenden Eintrag hinzufügen:
Außerdem wurde dort noch empfohlen, in die /etc/modules die folgende Zeile einzutragen;
i915 modeset=1
Bei mir war das aber nicht nötig, das System rennt auch ohne diesen Eintrag wieder wie gewohnt. Hoffen wir, dass ich an diese Einträge denke, wenn irgendwann der Kernel 2.6.30 stabil wird und sie nicht mehr nötig sein sollten ;-)
