Firefox snap durch deb ersetzen

Bekanntlich forciert Canonical deren Format snap, auch Firefox gibt es in Ubuntu 22.04 ausschließlich nur noch als snap-Image. Wie man das durch Firefox deb ersetzen kann, ist auf diversen Seiten beschrieben, aber auf keine würde ich verlinken (das geht schon mit “Ji m”s ewigem Kardinalfehler “sudo gedit” los).

  1. Erstelle eine Prioritätsdatei:
    • 1
      
      sudo nano /etc/apt/preferences.d/mozillateamppa.pref

      Füge über c&p ein:

      Package: firefox*
      Pin: release o=LP-PPA-mozillateam
      Pin-Priority: 501
    • Alternativ könnte man umgekehrt die Installation von Fx aus den Ubuntu-Repositories herunterstufen (das ist ein transitional .deb-Package, das in jedem Fall versionshöher ist, sich also drübersetzen und die snap-Version installieren würde)
      1
      
      sudo nano /etc/apt/preferences.d/firefox.pref

      Füge über c&p ein:

      Package: firefox*
      Pin: release o=ubuntu
      Pin-Priority: -1
  2. Füge das PPA Mozilla Team hinzu:
    1
    
    sudo apt-add-repository ppa:mozillateam/ppa
  3. Seit geraumer Zeit läßt apt-add-repository nach Hinzufügen automatisch “apt update” laufen – deswegen ist die Prioritätsdatei in dieser Liste an erste Stelle gesetzt worden (man muß ja nicht unnötige Schritte und Traffic erzeugen).

  4. Deinstalliere Fx snap (sollte man diese Anleitung damit abarbeiten, wäre ein temporäres Copypasten der Schritte in einen Editor von Vorteil, freilich ist’s nicht mehr viel):
    1
    
    sudo snap remove firefox
  5. Installiere
    • Firefox
      1
      
      sudo apt install firefox

    • oder Firefox-ESR
      1
      
      sudo apt install firefox-esr

      Für Firefox-ESR brauchte es die Prioritätsdatei nicht, da keine solche Version in den Ubuntu-Repos angeboten wird, sie stört aber auch nicht.

Konfigurationsverzeichnisse liegen an unterschiedlichen Orten:

  • snap: “~/snap/firefox/”
  • deb: “~/.mozilla/”

Im übrigen kann ich nur jedem nahelegen, sich andere Linux-Distributionen anzusehen. Besser wird’s mit Canonical und Ubuntu nicht.

Firefox 98: Profile nicht abwaertskompatibel

Warnung: Firefox ändert mal wieder etwas an den Profilen, sprich mit Fx 98.0 candidate build 2 (die Final ist für 2022-03-08 avisiert) einmal gestartet, kann das Profil nicht wieder mit der derzeitigen Final 97.0.1 geladen werden.

Ein realistisches Szenario, da Fx 98.0cb2 Sites reproduzierbar crashen läßt, die aus einem Link in Thunderbird geladen werden.

Wer also diese Dev-Version testen will, vorher “~/.mozilla/” sichern!

Streams in vlc abspielen

Streams einer bekannten Videoplattform sind dafür vorgesehen, im Browser zu laufen. Um darüber hinausgehendes zu verhindern, werden ständig neue technische Rafinessen ersonnen (man denke nur an Fragmentierung des Videos, separate Audiospuren etc.).

vlc hat man bis vor geraumer Zeit durch Aufruf des Stream-URLs noch nutzen können. Derzeit stockt die Wiedergabe jedoch aller paar Sekunden – unbrauchbar. In Foren wird nach Lösungen gefragt. Tips, man solle doch smplayer nehmen (ohnehin nur ein Frontend für mplayer oder mpv), verkennen, daß dieser selbst derartige Streams gar nicht abrufen kann, sondern sich eines bekannten Zusatz-Tools bedient.

Ich betone, es soll ausschließlich um die Wiedergabe des temporär nur dafür im Cache gehaltenen Streams gehen. Also das, was ein Browser auch nur macht, aber ein Player technisch besser könnte, wenn ihm kein Bein gestellt wird (die Systembelastung ist merklich geringer, insbesondere unter Linux, dort haben Browser i.d.R. keine wirkliche Hardware-Beschleunigung).

vlc nutzt für Quellen entsprechende Playlists, eine Art Profile. Arch-based sind sie unter “/lib64/vlc/lua/playlist/” abgelegt, in debian-basierten Systemen unter “/usr/lib/x86_64-linux-gnu/vlc/lua/playlist/”. Default sind es .luac-Files. Es werden jedoch nicht nur Kompilate, also Binaries, erkannt, sondern auch .lua-Files.

Man benötigt keine neue vlc-Version (auch ein 4.0er nightly-snap soll nicht helfen), man kann das entsprechende .luac-File durch ein .lua-File (logscherweise raw) ersetzen.

In EndeavourOS ist das Problem damit behoben, ebenso in einer LFocal-VM (dort hat es bisher gar nicht abgespielt werden können), in einer Debian-testing-VM stockt es noch. Es sind unterschiedliche vlc-Versionen. Generell funktioniert es also – derzeit – wer es wirklich braucht (für mich ist es lediglich eine interessante technische Problemstellung gewesen), müßte in letzterem weitersuchen, bspw. Konfigurationen (VM, vlc,…) vergleichen.

LXQt: Shortcuts ohne Funktion

Wenn Tastenkombinationen keine Reaktion mehr zeigen, merkt man erstmal, wie sehr man selbst darauf baut. LXQt-Shortcuts funktionieren nicht mehr (wenn nicht mal über ctrl+alt+t ein Terminal gestartet werden kann, was ich hier ständig mache, ist das schon hart, hrr).

Sobald der Desktop aufgebaut ist, erscheint folgende Message:

lxqt-panel
Removable media/devices manager: Global shortcut 'X86Eject' cannot be registered

Ich untersuche das Problem seit Freitag (da ist es erstmals aufgetreten, testing ist in EndeavourOS, also arch-based, prinzipiell aktiviert). Es ist irrelevant, welcher Window Manager genutzt wird (openbox, xfwm4). Zwischenzeitlich habe ich schon angenommen gehabt, ich hätte die Ursache gefunden bzw. zumindest einen Workaround.

lxqt-globalkeysd kann nicht gestartet werden. Dies kann man sehen unter:

LXQt Configuration Center → Session Settings → Basic Settings → Global Keyboard Shortcuts

An der Stelle kann man den Dienst starten, freilich überlebt dieser keinen Reboot oder Relogin.

Unter

LXQt Configuration Center → Autostart → Application Autostart → LXQt Autostart

habe ich “lxqt-globalkeysd” mit “Wait for system tray” als Workaround hinzugefügt. Hilft allerdings nicht zuverlässig. Im Moment funktioniert’s, was nicht daran liegen muß.

Zum Thema kann man fast nichts finden. Vor 5 Jahren ist das Fehlerbild schon mal aufgetreten (nicht bei mir, ich habe damals LXDE genutzt). Damals soll geholfen haben:

PCmanFM → Preferences → Volume → disable “Mount removable media automatically whe they are inserted” und disable “Show available options for removable media when they inserted”

Ist hier aber auch nicht einwandfrei reproduzierbar.

Thunderbird: Feeds ohne Zertifikat

Thunderbird in aktueller Version (derzeit 89.0b4) zieht keine RSS-Feeds von unsicheren URLs, also http ohne s, mehr. Möglicherweise kann man dies für eine Übergangszeit ähnlich wie in Fx über einen Eintrag in user.js rücksetzen, aber darum soll es hier nicht gehen (drin ist drin, gilt global und wird vergessen).

In erster Linie dürfte das Feeds betreffen, die man seit Jubeljahren bezieht. D.h., hier prüft man, ob Feeds nicht längst über https ziehbar sind. Das “s” im URL dazuschreiben, funktioniert nicht. Man entfernt den Feed (die Nachrichten bleiben erhalten) und fügt den Feed mit nun https hinzu.

Feeds ohne secure sollte es nun so langsam nicht mehr geben. Stimmt bei https aber das Zertifikat nicht, zieht Tb auch nichts.

feed subscriptions

Das Beispiel rglinuxtech.com ist nur über http erreichbar, aber Feeds gibt’s so eben nicht mehr. Über https funktioniert es nicht, da das eingebundene Zertifikat nicht darauf, sondern auf dessen Hoster pipeten.co.uk ausgestellt worden ist.

Über “Add Exception” gelangt man auf folgenden Requester:

Read more “Thunderbird: Feeds ohne Zertifikat”

VBox: stuttering in yt

VMs in VBox eignen sich für wirklich vieles, aber nicht gerade für yt. In Firefox (und wohl auch Chromium) starten Videos nicht wirklich, es wird scheinbar ewig gebuffert. Man muß mehrfach stoppen und starten, bis es weiter geht…ein wenig.

(Nicht nur) in diesen Browsern gibt es unter Linux keine Hardware-Unterstützung durch die GPU, geplant ist bislang auch nichts (nicht mal im closed source Chrome). D.h., das Rendering hat die CPU in Software zu übernehmen. In nativen Linux-Installationen macht sich das nicht bis kaum bemerkbar, so man nicht gerade eine Schippe Sand als CPU hat. In VBox-VMs allerdings eben schon, zumal die GPU-Treiber VBoxSVGA und VMSVGA dahingehend auch nicht die stärksten sind.

In altägyptischen Flash-Zeiten hat es mal den Workaround gegeben, per Rechtsklick (oder auch kleiner Konfigurationsdatei) im Video HW-Unterstützung zu deaktivieren, also das, was eh nicht da ist. Flash, ohnehin nie für Videos gedacht, ist aber tot (und nein, solchen Dreck installieren wir auch nicht, User ohne Plan aus einem bestimmtem Forum), mithin auch diese Einstellmöglichkeit.

Das problematische OpenGL in Hardware ausknipsen hilft bei diesem Fehlerbild auch nicht. Auch nicht, den Original-Firefox zu verwenden statt des Kompilats der jeweiligen Linux-Distribution (in debian gibt es gerade mal ein Problem, was so umgehbar ist). Alles bereits ausprobiert.

In Fx’ “about:config” gibt es mehrere Probanden, die zu testen wären. Ohne die Ursache zu kennen, ist das aber eher ein trial & error. Defaults eines frischen Profils bringen auch nichts.

Nun hat das Ganze früher mal ohne zu stottern funktioniert. Da es für mich aber keine Priorität hat (ja, das gibt es, User ohne Plan aus einem bestimmtem Forum), bin ich dem bislang nicht nachgegangen.

Um zum Punkt zu kommen, yt streamt in VP8/VP9. Eine Hardware-Unterstützung gibt es dafür bisher kaum, wohl aber für H.264. Als Linux- und OSS-Verfechter würde man natürlich lieber ein freies Format verwenden, an der Stelle muß man abwägen.

Allein Codecs installiert zu haben, genügt nicht. Dem Browser muß gesagt werden, daß er H.264 verwenden, d.h. von yt anfordern soll. Gibt’s sicherlich auch eine Möglichkeit unter “about:config”, denn etwas anderes wird das Fx-Add-on h264ify auch nicht verändern. Als Quickfix mag es genügen – und es funktioniert einwandfrei.

Btw., wenn man ein Add-on zum Ändern des User Agents installiert hat, kann man auch eine brauchbare Kombination aus OS und Browser ermitteln, dann wird H.264/mp4 gestreamt und man braucht nichts extra.

Firefox: Add-ons deaktiviert

Es ist mal wieder ein Weltuntergang. Jedenfalls, schenkt man manchen Usern Glauben, die da behaupten, ohne Add-ons sei Firefox nicht zu gebrauchen, also denen, die Fx mit ach so wichtigen Add-ons zukleistern. Seit heute Nacht werden in Fx automatisch Add-ons deaktiviert, weil bei mozilla.org Verantwortliche den Ablauf des entsprechenden Zertifikats verpennt haben.

Interessanterweise werden nicht sämtliche disabled, bspw. NoScriptdas ist ein unverzichtbares Add-on – läuft weiter. Wer also nicht sonstige installiert und aktiviert hat, merkt davon nichts. Installieren, auch manuell, wird freilich mit dem falschen Hinweis abgelehnt, das .xpi sei corrupt (auch NoScript).

Der Vorgang zeigt aber nicht nur die Verschlafenheit bzgl. Zertifikaten, sondern vor allem die Unfähigkeit und den Unwillen von Usern zur Recherche. Seit ~3:00 (!) gibt es einen Bugreport auf bugzilla.mozilla.org und seitdem bis jetzt, Nachmittag, 41 (!) Duplicates, also weitere (nunmehr geschlossene) Bugreports desselben Problems.

Bei mozilla.org hat man sich ob der Zahl fortwährender Postings leicht genervt gezeigt (discourse.mozilla.org ist offensichtlich seit Stunden permanent überlastet), aber zumindest gg. Mittag eine Interimlösung mit einem Zwischenzertifikat bereitgestellt.

Zum Zeitpunkt des Schreibens dieses Postings ist Fx 66.0.4 Candidate Build 1 angeboten, dann aber wieder entfernt worden, freilich ohnehin bloß für Redmond OS. Mittlerweile ist Directory Listing für download-installer.cdn.mozilla.net/pub/firefox/candidates/ disabled.

Solange hotfix-update-xpi-intermediate@mozilla.com-1.0.2-signed.xpi ziehbar ist (manuell in Fx zu installieren, allerdings nicht in den ESR-Versionen), ist das jedoch völlig ausreichend. Auch nur ein .xpi-File, das funktioniert aber. Und danach auch wieder installierte Add-ons sowie das Installieren von Add-ons.

Update 2019-05-05, 19:30: Mozilla hat Fx 66.0.4 mit einem Fix bereitgestellt (bei Erststart wird automatisch der eventuell zuvor im User-Profil unter extensions abgelegte intermediate-Fix gelöscht). Gefixte 60er ESR- und 67.0b-Versionen fehlen allerdings noch.

Update 2019-05-05, 21:00: Mittlerweile liegt auch 60.6.2esr vor.

Ubuntu: vaapi unter chromium entfernen

Man sollte wissen, was man installiert hat, erst recht als Linux-User.

Jener weiß es offensichtlich nicht. Er spricht von “google-chrome” in Version 71.0.3578.98 (schon der Zusatz 64 bit wäre überflüssig, da es Google Chrome für Linux seit langem nur noch für x86_64, also nicht x86_32, gibt).

Google Chrome ist längst weiter, schon die Abfrage unter siduction ergibt für chromium, die OSS-Variante, 72.0.3626.53-1. Dagegen ist genannte 71er derzeit genau die für chromium unter Ubuntu Xenial bis Disco.

Wir halten also fest, er hat chromium und nicht google-chrome installiert. Und jetzt müßte man sich auch mal richtig informieren, vor allem, wenn man Support geben will. pro-linux.de berichtet, daß ein längst bereitstehender, jedoch wegen möglicher Probleme bislang nicht freigeschalteter, Patch in chromium übernommen worden ist – in Fedora und Ubuntu. In letzterem ist es ein unsägliches Snap-Paket. In den chromium-Settings Hardware-Unterstützung deaktiviert zu haben, genügt dabei offenbar nicht.

Den proprietären Treiber nvidia (technisch besser als der freie nouveau, Kunststück bei Infos unter Verschluß, aber ständig inkompatibel zu bestimmten Kernel- und VBox-Versionen) nicht installieren, stattdessen nouveau nutzen wollen, kann ich verstehen (ich fahre auch nur noch nouveau nach ehedem langjährigem Support meinerseits für nvidia auf diesem Portal). Am besten, man kickt dieses unsägliche Snap und damit eben auch dieses Paket.

1
2
sudo apt purge snapd
sudo apt autoremove

Zudem kann man chromium mit Variablen starten.

2019-01-24, Nachtrag: Besagter Threadstarter, seit 11 Jahren dabei, sieht noch nicht mal, was er falsch macht, daß er unsauber arbeitet. Er schafft es auch nicht selbst aus diesem Chaos heraus. Aber Lamento gegen nvidia. Installationen und Reparaturen selbst verkorkster nvidia-Installationen habe ich hunderte Male erklärt (Suchmaschine → Hilfe zur Selbsthilfe). Das ist der Hauptgrund, weshalb ich mich dort nach langjährigem Support ausgeklinkt habe.

Falkon, Chromium: Freezes, Glitches

Wenn Falkon oder Chromium extrem zäh starten und aus Grafikfehlern gar nicht mehr herauskommen, liegt dies mit großer Wahrscheinlichkeit am default aufgerufenen OpenGL in Hardware, das GPU und/oder Driver in diesem Fall nicht sauber unterstützen, ältere Radeon und Intel oder auch Nvidia mit nouveau. In Chromium kann man das zwar in den Settings disablen, aber da muß man ja erst mal hinkommen.

Man kann zwei Umgebungsvariablen setzen, handlicherweise schreibt man sich ein kurzes Script:

1
2
3
4
5
6
7
8
#!/bin/bash
# force OGL in software
 
export QT_XCB_FORCE_SOFTWARE_OPENGL=1
export LIBGL_ALWAYS_SOFTWARE="true"
falkon &
 
exit 0

Als falkon.sh speichern, mit

1
chmod +x falkon.sh

ausführbar machen und mit

1
./falkon.sh

starten. Für Chromium erstellt man entsprechend.

Video-Loops in Firefox

Beim Abspielen in Websites eingebetteter Videos in Firefox (insbesondere v50.1.0) kann es zu einer Schleife kommen, es werden nur flackernd die ersten 1…2 Sekunden gezeigt, während der Ton weiterläuft. In anderen Browsern wie Chromium gibt es dagegen kein solches Problem, ergo kann es nicht an gstreamer etc. liegen. Da ein Video scheinbar grundlos in Fx auch mal korrekt abgespielt werden kann, erschwert es die Findung der Ursache(n).

Diese liegt in einer Option für off-main-thread compositing. Über about:config setzt man layers.acceleration.force-enabled auf false oder, wie ich es bei meinen Fx-Settings generell halte, schreibt in user.js einen Eintrag (so hat man jederzeit eigene Änderungen im Blick und kann dieses File auch einfach in andere Installationen mitnehmen):

// off-main-thread compositing
user_pref("layers.acceleration.force-enabled", false);

In user.js enthaltenes wird beim nächsten Fx-Start in prefs.js übernommen (dort sollte man nicht herumeditieren).

Siehe auch Renderfehler in Firefox v40.x!