Lutris 0.5.14: Kein Spiel startet mehr

Da denkt man sich: „Hey ,es ist Sonntagmorgen, laß und ein paar Rote abschießen“ und da startet EVE einfach mal nicht mehr. Schuld ist ein Fehler von Lutris, der sich jetzt rächt.

Lutris 0.5.14: Kein Spiel startet mehr

Heute hat es Lutris 0.5.14 ins Stable geschafft und wurde prompt aktualisiert. Was für ein mieser Start ins Gamerleben an diesem Sonntag 😀 Keins der Spiele hat mehr funktioniert und das nur, weil eine alte Versionen meinte: „och nehmen wir doch den ~/ Shortcut, statt den absoluten Pfad, wie bei allen anderen Pfadangaben“ 🙂

Kurz um, der Fehler ist leicht zu fixen:

cd ./.lutris/games/

dort findet Ihr für jedes Spiel eine Datei mit Endung .yml :

$ cat eve-online-1650280372.yml
game:
arch: win64
exe: /home/<XXXXXXXX>/Games/eve-online/drive_c/EVE/Launcher/evelauncher.exe
prefix: ~/Games/eve-online
system: {}
wine:
version: lutris-fshack-7.2-x86_64

Das <XXXXXXXX> steht für den Benutzernamen von Euch, bei Prefix steht nun nur „~/“ statt „/home/<XXXXXXXX>/“ . Das ändert Ihr mit einem Texteditor Eurer Wahl und schon starten die Spiele wieder.

$ cat eve-online-1650280372.yml
game:
arch: win64
exe: /home/<XXXXXXXX>/Games/eve-online/drive_c/EVE/Launcher/evelauncher.exe
prefix: /home/<XXXXXXXX>/Games/eve-online
system: {}
wine:
version: lutris-fshack-7.2-x86_64

Ihr müßt nur aufpassen, daß ihr Euren Homepfad irgendwann nicht mal ändert, weil sonst all die Config nicht mehr stimmen 😉

 

Verspätungen bei Fedora Releases – Ein Kommentar

Na alle gut Durch die Zeitumstellung gekommen? 🙂  In den letzten Tagen hatten wir Nachrichten von Verzögerungen bei Fedora 39, die mal einer kleinen Erläuterung bedürfen.

Verspätungen bei Fedora Releases – Ein Kommentar

Ich mache das jetzt ja schon mehr als ein Jahrzehnte mit und deswegen schockt mich so eine Verzögerung überhaupt nicht. Das ist meiner Meinung nach nicht mal eine Erwähnung im Blog wert. Beim letzten Linux am Dienstag hatten wir das Thema auch und es ist lächerlich daraus irgendwas abzuleiten.

Letztes Jahr z.b. verzögerte sich Fedora 37 auch vom Oktober in den November und es war kein Weltuntergang. Wieso das in einigen Portalen so klingt, weiß ich nicht.

Wie läuft das normalerweise ab?

Das Steuerungskomitee legt einen Zeitplan der u.a. vorsieht, wann die Betaphase anfängt und wann das normalerweise 6 monatige Intervallrelease live gehen soll. Bis zum Betafreeze können alle Updates und Neuerungen eingebracht werden, danach nur noch Bugfixe und wenn alle Bugs behoben sind, dann darf das neue Release in den Stablebereich und alle Newsportale laufen heiß mit Meldungen wie „Fedora 39 finally ready“ oder „Fedora 39 bringt Gnome 50.3.4.7.haste.nicht.gesehen“.

Dazu gibt diverse Meetings im IRC bei der die Projektleitung über den Fortschritt informiert wird. Bestimme Fehler sind tolerabel, z.b. wenn eine Lokalisierung noch nicht 100% ist, aber die nur jeder hundertste sehen würde usw. andere Fehler sind es nicht, weil grundlegende Funktionen nicht laufen. Jetzt testen das nicht nur die Maintainer, sondern auch normale Fans die helfen wollen. Dabei kann es passieren, daß Bugs erst entdeckt werden, wenn die Betaphase schon angefangen hat, die Zeit bis zum Releasedate aber schon knapp wird. So ist es auch diesmal passiert…gleich zweimal.

Alles halb so wild

Das ist aber kein Beinbruch, weil die Releasedaten sind exakt daran gebunden, daß keine Fehler auftreten, sind also schon immer fexibel. Es gibt im Projekt auch keinen Druck, weil die Maintainer das kaum beeinflussen können. Es kommt schwer drauf an, was nicht geht. Ist Software komplett kaputt, z.b. Gnome , kann man nur warten, bis der Fix da ist. Geht was bei der „Infrastruktur“ nicht, und da zählt das Installationsmedium dazu, dann können die zuständigen Spezialisten direkt was machen. Aber auch hier gibts keinen Druck, woher auch?

Sollte es zwei Monate dauern bis Fedora 39 raus kommt, dann ist das halt so. Ich kann mich daran entsinnen, daß schon mal ein ganzer Monat drangehängt werden mußte

Für wen haben die Zeitpunkte überhaupt einen Wert?

Es gibt nur zwei Dinge die von den Zeitpunkten bestimmt werden:

Beim Betafreeze steht fest, welche Software ins Image kommt und in welcher min. Version. d.b. danach kann keine neue Software und keine grundlegende Änderung z.b. am Distrilayout im Filesystem mehr gemacht werden.

Beim Final Go für die neue Release fängt die Upgrade Uhr an zu ticken, weil das „alte Release“, in diesem Fall Fedora 37, nur noch 4 Wochen mit Updates versorgt wird. D.b. hier sind die Admins betroffen, die dann in Firmen für die Upgrades sorgen müssen. Es wir aber natürlich niemand daran gehindert schon eher von 37 auf 38 zu Updaten 😉

Für Euch als Anwender ist das Releasedate völlig irrelevant. Aus diesem Grund verstehe ich die Aufregung auf den Newsportalen auch nicht, es kommt, wenn es kommt und damit hat es sich. Vermutlich muß man aber irgendwas „neues“ „berichten“ wenn man ein Newsportal ist.  Also Leute entspannt Euch, es gibt erst was zu sehen, wenn es was zu sehen gibt 😉

Plymouth Bootanimation umstellen

Wenn Euch Eure Bootanimation zu langweilig geworden ist, kann Euch geholfen werden.

Plymouth Bootanimation umstellen

Die Bootanimationen von z.B. Fedora werden von Plymouth dargestellt. Es handelt sich dabei um sogenannte „Themes“. Welcher bei Euch gerade eingestellt ist, könnt Ihr so rausbekommen:

$ plymouth-set-default-theme
spinner

Welche Themes auf Eurem System bereits verfügbar sind, könnt Ihr mit –list erfahren:

$ plymouth-set-default-theme –list
bgrt
details
fade-in
solar
spinner
text
tribar

Um zu erfahren, welche Themes noch verfügbar sind, müssen wir DNF fragen:

$ dnf search plymouth-theme
Letzte Prüfung auf abgelaufene Metadaten: vor 0:11:37 am Mi 25 Okt 2023 09:18:42 CEST.
======== Name Treffer: plymouth-theme =====================
plymouth-theme-breeze.x86_64 : Breeze theme for Plymouth
plymouth-theme-charge.x86_64 : Plymouth „Charge“ plugin
plymouth-theme-fade-in.x86_64 : Plymouth „Fade-In“ theme
plymouth-theme-hot-dog.noarch : Plymouth Happy Hot Dog Theme
plymouth-theme-script.x86_64 : Plymouth „Script“ plugin
plymouth-theme-solar.x86_64 : Plymouth „Solar“ theme
plymouth-theme-spinfinity.x86_64 : Plymouth „Spinfinity“ theme
plymouth-theme-spinner.x86_64 : Plymouth „Spinner“ theme

Wenn wir nun einen anderen Theme nutzen möchten, machen wir das so:

$ plymouth-set-default-theme tribar

Das alleine reicht aber noch nicht aus, denn so würde der Theme erst beim nächsten Kernelupdate geändert werden, denn der Befehl macht nichts anderes als diese Datei hier zu füllen:

$ cat /etc/plymouth/plymouthd.conf
# Administrator customizations go in this file
[Daemon]
Theme=tribar

Da die Animation im Initramfs Teil des Bootvorganges abläuft, muß das initramfs des Kernels(oder aller Kernel wenn Ihr drauf besteht) aktualisiert werden:

$ dracut -f

Dann können wir rebooten und uns die neue Animation ansehen.

Ich rate allerdings dazu, das alles in einer VM auszuprobieren, weil man dann nicht dauernd den physikalischen PC rebooten muß. In der VM geht das nämlich schneller 😉

Dieser Beitrag wurde im Rahmen von Linux am Dienstag erstellt.