Nach einem Betriebssystem-Update von Debian 11 auf Debian 12 wollte Torchlight 2, das vor dem Update problemlos lief, nicht mehr starten: nach dem Klick auf das Icon erschien nur noch kurz der Spash-Screen … und das war’s - vom eigentlich erwarteten Startschirm fehlte jede Spur.

Als erste Möglichkeit zur Fehlersuche bietet sich meist ein Start des Programms über die Kommandozeile an, in der Hoffnung, dadurch vielleicht in paar Statusmeldungen zu sehen. Dies funktioniert auch beim Start von Torchlight 2, welches eine ganze Menge an Meldungen ausgab, bevor es letztendlich mit einem “Speicherzugriffsfehler” abbrach.

Leider führte die Kombination von “Torchlight 2” und “Speicherzugriffsfehler” bei der Suche nach Lösungsmöglichkeiten nicht zu hilfreichen Ergebnissen. Auch Tips, die in Richtung von Bibliothekskonflikten gingen halfen nicht, das Programm wieder zum Starten zu bewegen.

Zum Ziel führte letztendlich ein Blick in die Datei “ogre.log”, die auf den ersten Blick identisch mit den Ausgaben beim Programmstart aussieht, allerdings noch ein paar zusätzliche Ausgaben enthält:

So war der entscheidende Hinweis zwischen den Zeilen “Loading library RenderSystem_GL” und “Path for saving is” versteckt, im konkreten Fall ein

der sich durch Installation des Pakets libglu1-mesa letzendlich leicht beheben ließ.

Während in der Vergangenheit mehr oder minder regelmäßig Aktualisierungen für den Synology Disk Station Manager gefunden wurden, war die autmatische Suche neuerdings verdächtig lange der Meinung, daß alles Bestens wäre.

Ein Klick auf die Versionshinweise zeigte allerdings, daß sehr wohl Aktualisierungen verfügbar waren. Aktuell ist “7.2.1-69057 Update 5” vom 08.04.2024, während die noch installierte “7.2-64570 Update 3” auf den 03.08.2023 datiert.

Während die Updates 1 bis 5 zur 7.2.1 tatsächlich wohl auch nur nach Bedarf angeboten und eingespielt werden

Your Synology NAS may not notify you of this DSM update because of the following reasons.

Your DSM is working fine without having to update. The system evaluates service statuses and system settings to determine whether it needs to update to this version. [Quelle]

enthält die “7.2.1-69057” u.a. Korrekturen für einige Sicherheitslücken (u.a. Sudo, OpenSSL und Zlib) und eine Installation scheint somit sinnvoll. In den Notes steht auch die Erklärung, warum der DSM die Aktualisierung nicht anzeigt

For the models below, you can only download the upgrade patch from Synology Download Center because you won’t receive notifications for this update on your DSM.

Plus Series: …, DS218+, … [Quelle]

allerdings ohne weitere Begründung, warum diese Vorgehensweise gewählt wurde.

Eine weitere Unstimmigkeit gibt es dann noch im Download-Zentrum:

Während angezeigt wird, daß nach dem Herunterladen und Installieren von “7.2.1-69057 (with Update 1)” noch das Herunterladen von Installieren von “7.2.1-69057 Update 5” notwendig ist, meldet sich die DSM-Aktualisierung bereits nach dem Einspielen des ersten Pakets mit “DSM 7.2.1-69057 Update 5”.

In den letzten Tagen sorgte eine Änderung am “KeepassXC"-Paket in Debian für hitzige Diskussionen.

Der grundlegende Gedanke, ein Paket mit minimalem und ein Paket mit vollständigem Funktionsumfang anzubieten ist hierbei nicht ungewöhnlich: eine solche Aufspaltung gibt es bis hin zu den Desktop-Umgebungen, wo z.B. bei der Installation zwischen einem “gnome” und einem “gnome-core"-Paket gewählt werden kann, welches nur den minimal notwendigen Umfang zu Betrieb der Desktopumgebung enthält.

Was allerdings nicht nur mir unangenehm aufstößt ist die Vorgehensweise des Paketbetreuers, der statt der Erstellung eines zusätzlichen “keepassxc-core”-Pakets das ursprüngliche “keepassxc”-Paket um bestehende Funktionalität erleichtert und somit bestehende Installationen mit der nächsten Aktualisierung beschneidet.

Dies ist offensichtlich ohne vorherigen Dialog mit den KeepassXC-Entwicklern geschehen und führt dazu, daß nun vermehrt Anwender bei KeepassXC (nicht vorhandene) Fehler melden, denn

This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there’s little that can be done about that. [Quelle]

Dieser Satz und vor allem eine Aussage wie

Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks. [Quelle]

lässt aber nicht unbedingt (nur) auf sachliche Hintergründe schließen, sondern zeigt deutlich, wo das eigentliche Problem liegt - und erinnert mich von der Grundeinstellung an den Münchner OB Dieter Reiter.

Im Laufe der Jahre hat sich die Anzahl der von mir betreuten Joomla!-Installationen deutlich reduziert. Von mehreren Websites ist noch eine Intranet-Seite übriggeblieben, welche bis vor Kurzem noch mit Joomla! 3 lief.

Hauptgrund hierfür war die aus meiner Sicht nur spärlich vorhandene Dokumentation für Entwickler, welche Anpassungen an Erweiterungen bei Versionsänderungen zu machen sind. Während zum Beispiel der Wechsel zu Hugo auf Grund der guten Dokumentation in Kombination mit einem ebenso guten Forum nur wenig Frustmomente bot, war schon die Erfahrung beim Umstieg von Joomla! 1.5 auf 2.5 derart nervig, daß im Laufe der Zeit alle Websites von Joomla! zu WordPress migriert wurden, statt den Versuch zu starten, die bestehende Funktionalität unter der neuen Joomla!-Version lauffähig zu bekommen.

Nachdem inzwischen aber Joomla! 5 veröffentlicht ist, sollte auch die Intranet-Site zumindest auf Joomla! 4 migriert und somit auch die selbstentwickelten Erweiterungen angepasst werden, was sich wieder als frustrierendes Erlebnis entpuppte. Wenn es schon Zusammenstellungen wie “Potential backward compatibility issues in Joomla 4” gibt, wäre es hilfreich, wenn dort nicht als erstes ein “Content is Incomplete” ins Auge springen würde und viele der hier aufgelisteten Dinge auch dort zu finden wären.

In diesem Beitrag habe ich die verschiedenen Quellen gesammelt, mit denen ich die Erweiterungen mit Joomla! 4 lauffähig gemacht habe - am Ende des jeweiligen Abschnitts ist als Quelle die Seite angegeben, auf welcher ich als erstes auf meiner Suche nach Lösungen fündig wurde. Vieles davon ist sog. Legacy-Funktionalität, d.h. ich habe nicht nach aktueller Philosophie neu entwickelt, sondern versucht, mit minimalem Aufwand die jeweilige Erweiterung zu reparieren und wieder funktionsfähig zu bekommen.

Vollständigen Beitrag lesen

In einem Verzeichnis auf der lokalen Festplatte schlummerten noch ein paar Uralt-Mails, welche alle als einzelne Textdateien gespeichert waren. Leider bietet Thunderbird keine Möglichkeit, über die Oberfläche einen Importvorgang anzustoßen, aber es geht auch recht einfach durch die Hintertür.

In der Oberfläche wird in den “Lokalen Ordnern” mittels Rechsklick ein neuer Ordner “GanzalteMails” angelegt. Dies bewirkt, daß im Profilverzeichnis ("~/.thunderbird/PROFILNAME/Mail/Local Folders/") zwei Dateien “GanzalteMails” und “GanzalteMails.msf” erzeugt werden. In diesem Ordner wird auf Dateisystemebene nun händisch ein neuer Unterordner “GanzalteMails.sbd” erzeugt, in welchen die Textdateien kopiert werden.

Damit Thunderbird die Texte auch tatsächlich als Mailbox-Files erkennt, ist es wichtig, daß jede Datei - wie in RFC 4155 “The application/mbox Media Type” beschrieben - mit einem korrekten Vorspann beginnt:

mbox database files can be recognized by having a leading character sequence of “From”, followed by a single Space character (0x20), followed by additional printable character data

Was genau nach dem Leerzeichen kommen muß, kann sich zwischen verschiedenen Anwendungen unterscheiden, weshalb die meisten Mailclients fast alles akzeptieren, was auch nur halbwegs standardkonform aussieht. Thunderbird genügt z.B. ein

als Kennzeichnung. Wer dies einfach und komfortabel an den Anfang aller “*.txt”-Dateien einfügen möchte, kann sed als Werkzeug verwenden: