Tag Archives: Update

Fedora: Alarm – Firefox 117 händisch einspielen, weil nicht im Repo :(

Posted on by

Ein Fehler im Workflow der Fedora Buildfarm führt zu dem Problem, daß wir Firefox 117 jetzt händisch einspielen müssen, denn in 117 sind eine Menge kritischer Lücken gestopft worden.

Fedora: Alarm – Firefox 117 händisch einspielen, weil nicht im Repo 🙁

Wie man dem Securityreport von Mozilla für Firefox 117 entnehmen kann, gibt es 6 schwere Lücken in Firefox, die man ausnutzen kann um z.B. aus der Sandbox auszubrechen, oder Programmcode auszuführen.

Normalerweise bereitet Martin die Firefox Updates gewissenhaft vor und das seit Jahren, wofür man ihm nicht oft genug Danken kann! Diesmal ist allerdings etwas schief gegangen.

Am Montag gegen 14 Uhr wurden die BuildJobs für F37-F40 ( jaja, Leute 40!!! ) gestartet und hätten so 2-5h gebraucht. Am Mittwoch „liefen“ die Prozesse immer noch, da habe ich mal Alarm geschlagen, denn seit Dienstag waren die Bugs bekannt, da werden die Exploits bald fertig sein.

Wie Kevin Fenzi dann nach mehrmaligem Nachhaken meinerseits, feststellte, hingen die VMs fest (muß das neue Java Update drauf sein 🙁 ). Die Jobs mußten auf echte Baremetall Maschinen umgezogen werden, wo sie dann Mittwochabend gegen 21 Uhr auch fertig waren. Ich habe dann Firefox sofort getestet und für Ok gefunden, konnte aber keinen Bodhi Vorgang finden, wo man dem Build das Karma gegeben konnte, um es ins Stable zu puschen.

Stellt sich raus: Keine Jobs im Bodhi drin, was auch bedeutet, keine RPMs im Updates-Testing Repo 🙁

Und das bringt uns direkt zu den Anweisungen, wie Ihr jetzt gleich Euren Fedora PC aktualisieren könnt/solltet:

Fedora 37:

sudo dnf update https://kojipkgs.fedoraproject.org//packages/firefox/117.0/1.fc37/x86_64/firefox-117.0-1.fc37.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/firefox/117.0/1.fc37/x86_64/firefox-langpacks-117.0-1.fc37.x86_64.rpm

Fedora 38:

sudo dnf update https://kojipkgs.fedoraproject.org//packages/firefox/117.0/1.fc38/x86_64/firefox-langpacks-117.0-1.fc38.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/firefox/117.0/1.fc38/x86_64/firefox-117.0-1.fc38.x86_64.rpm

Podman Update verhindert Start alter Container

Posted on by

Ein Update von Podman verhindert das Starten von alten Containern. Das betrifft auch Toolbox.

Podman Update verhindert Start alter Container

Die Fedora Toolbox benutzt Podman um Container zu erstellen und zu starten. Das geht aber mit Podman 4.6.x nicht mehr für jeden Container, da dazu nicht mehr die nötigen Limits erlaubt werden, die noch mit 4.5.x dem Container zugewiesen wurden. Eine Datenmigration ist das einzige Mittel, alte Container wieder zu starten.

Die meist angesprochene Endlösung war das Löschen und Neuerstellen der betroffenen Container, was aber mit einem Datenverlust einhergehen würden, so man den Daten in dem Container drin hat. Einige Benutzer merkten an, daß Toolbox gar nicht für dauerhafte Container ausgelegt wäre, und man sich nicht wundern müßte, wenn Daten verloren gingen, da gegen den „Sinn“ von Toolbox gehandelt wurde.

Das ist natürlich per se kein Argument, weil Toolbox ja nur das Kontrollwerkzeug ist. Was man mit dem Container dann anstellt, ist ja jedem selbst überlassen 😉

Aber ist das Überhaupt ein Problem? Wir fragen Prof. Dr. Besser-Weiß von der Uni Kassel-Schwarzensee.

Das Interview

„Herr Professor Besser-Weiß, ist das Update von Podman überhaupt ein Problem?“
„Nein.“
„Herr Professor, wir danken für das Gespräch.“

Die Migration

Im Podman Issue[0] gibt es dafür folgende Migrationslösung:

$ podman export $CONTAINER_NAME -o output.tar
$ podman import output.tar $NEW_IMAGE_NAME
$ podman container rm $CONTAINER_NAME
$ toolbox create --image localhost/$NEW_IMAGE_NAME -i $CONTAINER_NAME

Danach kann der Container wieder gestartet werden.

Wer tatsächlich keine Daten in dem Container hat, was bei meinen Experimenten mit Cheese auf dem Surface Tablet z.B. der Fall war, weil Cheese seine  Daten im Home speichert, hat ohnehin kaum Hemmung den Container zu löschen und einfach neu anzulegen.

Da Fedora das Podman Update bereits ins Stable getan hat, solltet Ihr Euch bei Zeiten, also jetzt, darum kümmern, bevor Ihr das Programm im Container nochmal braucht.

[0] Quelle: https://github.com/containers/podman/issues/19634

PVA: Updates auf 1.22 bereinigen Problem mit Plugins

Wer Carola über das Repo installiert hat, wird heute ein Update auf die v1.22 bekommen, welches Probleme mit den Plugins bereinigt, die dazu führen, daß die Verarbeitung von Befehlen stockt. Außerdem gibt es noch ein Update von „say“ das die neue Stimme von GTTS im Zaum hält.

Falls das PVA System bei Euch gerade im geistigen Zustand einer Tomate ist, also nicht mehr reagiert, dann Desktopsession beenden und wieder einloggen. Das sollte das im laufenden Betrieb beheben. Update vorher nicht vergessen. Ganz harte können auch im Terminal „killall -9 pva java“ eintippen, aber das könnte bei Euch auch ungewollte Nebenwirkungen haben.

Ab v1.19 ist auch der Piper TTS Support enthalten, den ich im letzten Artikel schon vorgestellt habe:

Piper TTS braucht Eure technische Expertise

Die Sprachfehler wurden soweit das mit einfachsten Mitteln möglich war, kompensiert, aber nicht behoben.