Category: linux

Paketquelle partner nicht in Jammy

axt

Kurzinfo für Ubuntu 22.04: Es gibt einen Vorschlag Steve Langaseks, die ohnehin seit Groovy leere Paketquelle partner (in Focal ist AFlash zu dessen mehr oder eher weniger Lebzeiten als letztes noch enthalten gewesen) zu schließen. Gegenmeinungen scheint es bislang keine zu geben…oder mit anderen Worten, interessiert keinen mehr. Im Einzelnen oder überhaupt.

Die Begründung ist allerdings schräg. Der Snap Store sei mittlerweile so ausgereift, daß dieser partner ersetzen könne. Was nichts über das aufblasende bis hin das Prinzip Linux-Paketverwaltung zerstörerische snap selbst aussagt…

Arch Linux 2022.01.01, Image in VBox nicht UEFI-faehig

axt

Um in einer VBox-VM statt im CSM-Mode (Compatibility Support Module, das UEFI verhält sich, als sei es ein BIOS) im UEFI-Mode zu booten, ist lediglich im “VM VirtualBox Manager” unter System → Motherboard → Extended Features “Enable EFI (special OSes only)” zu aktivieren. Alternativ in einem Terminal:

1

vboxmanage modifyvm "VM name" --firmware efi

Selbstverständlich muß das zu bootende Image so oder hybrid erstellt worden sein (ein installiertes System sowieso). Das einfache Bootmenu von Arch Linux erscheint dann wie folgt:

Nicht so beim aktuellen Image archlinux-2022.01.01-x86_64.iso. Die Arch-Einträge fehlen, schlicht da das Image in VBox-VMs im UEFI-Mode nicht boot-fähig ist. Nativ soll es OK sein.

Man kommt nur in die EFI Shell oder das rudimentäre UEFI-Menu. Änderungstests in letzterem oder im VM-Manager sind erfolglos. Andere UEFI-fähige Distributions-Images, bspw. ein mit isorespin.sh angepaßtes Lubuntu oder das aktuelle EndeavourOS booten anstandslos, ebenso Arch-Images davor.

Ursächlich soll systemd 250.1-1 sein, es gibt einen Bugreport dazu bei archlinux.org. So es so ist, müßte dann, da Upstream, jedoch einer bei systemd erstellt werden.

Erhärtet wird es, da ein User ein Image mit systemd 249.x erstellt hat, das entsprechend boot-fähig ist. Jener bietet es zwar zum Download an, ein OS-Image von irgendjemandem verändert, so nett es gemeint ist, würde ich jedoch nicht verwenden.

Ebensogut könnte es ein Zusammenspiel mehrerer Faktoren, d.h. mit VBox sein, würde also (auch) dorthin gehören. Freilich nutze ich prinzipiell die jeweils aktuelle Version, sprich Testbuilds, derzeit 6.1.31 (das letzte ist knapp 4 Wochen alt, jetzt könnte so langsam mal wieder was kommen, manchmal gibt’s 3 Versionen pro Woche). In besagten Threads wird 6.1.30 final verwendet.

Wer jetzt Arch Linux in einer VBox-VM mit UEFI installieren will (mit CSM gibt es kein Problem), kann 2021.12.01 heranziehen – hat dann natürlich erheblich zu aktualisieren, was bei arch durch permanente Updates aber ohnehin der Fall ist – oder mit 2022.01.01 in der EFI Shell folgendes aufrufen:

1

FS1:\EFI\BOOT\BOOTx64.EFI

Das installierte System scheint keine UEFI-Boot-Probleme mit aktuellem systemd in VBox-VMs zu haben.

Update 1: Zwischenzeitlich ist upstream ein Bugreport für systemd erstellt worden.

Update 2: Der Commit boot: Fix readdir_harder() on VirtualBox für systemd ist 2022-01-10 Spätabend hinzugefügt worden, Arch Linux liefert systemd 250.2-2 damit in testing bereits aus. Das Februar-Image sollte dann dahingehend problemlos boot-fähig sein.

Update 2022-01-18: Die heutige (eigentlich vom 13.) Final VBox 6.1.32 löst zwar das Problem, Arch Linux 2022.01.01 zeigt im UEFI-Mode das vollständige Menu und kann folgerichtig booten. Jedoch bringt VBox 6.1.33-149396 das Problem zurück.

Update 2022-02-01: archlinux-2022.02.01-x86_64.iso funktioniert dahingehend korrekt.
FYI: Das wenige Stunden zuvor von testing nach extra gewanderte archinstall 2.3.1 ist enthalten.

pdf, finale Ungleichheit

axt

Das Portable Document Format ist entwickelt worden, um ein finales Dokument zu erhalten, das in jedem OS in jedem pdf-Viewer gleich aussieht, ebenfalls gedruckt. Es ist wie gesagt ein Endprodukt, es soll nicht editierbar sein (was User offensichtlich nie verstehen werden). Daß Drittanbieter Bastelprogramme anbieten, ändert daran nichts.

In 3 Jahrzehnten ist freilich immer weiter angeflanscht worden, so daß es nicht nur den einen Standard, die eine Version gibt. Bspw. für Archivierung sollte PDF/A (in Unterversionen), ISO 19005, gewählt werden, absichtlich unteres Level.

Hybrid-PDF kann man bei der Erstellung (LibreOffice) wählen, um in einem .pdf-File sowohl PDF als auch ODF zu speichern. Das .pdf-File wird damit durch Trickserei editierbar, man braucht nicht separat .odt bzw. .ods zu speichern. Natürlich ist dabei die Filesize größer. Wenn das File weitergegeben werden und nicht editierbar sein soll, darf man das selbstverständlich nicht hybrid speichern (eher exportieren).

Sind Forms eingebettet, kann ein solches pdf-File als ausfüllbares Formular verwendet werden. Dazu genügt ein pdf-Viewer.

Read more “pdf, finale Ungleichheit”

Streams in vlc abspielen

axt

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

axt

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.

⚠ Ventoy: Verdacht auf Malware #3

axt

Nachdem die letzten Versionen auf Virustotal wieder steigende Funde verzeichnet haben, 1.0.59 steht bei 4/60, schießt ventoy 1.0.60 mit bislang 13/60 (!) Scannern durch die Decke.

Ich werde mich nicht erneut an den Programmierer wenden, nur um dummes Zeug lesen zu müssen. Das Programm an sich ist in seiner Art Spitze, es wird stetig ausgebaut, aber verbietet sich durch sowas, genauer, der Programmierer selbst deklariert es mit seinen Ausflüchten, die ein massives technisches Unverständnis erkennen lassen, als potentiell gefährlich und eben nicht einsetzbar.

Nun schlagen derzeit die Scanner bei Windows-Versionen wieder massiv an, bei Linux-Versionen noch nicht. Es ist freilich die Frage, wie die Scanner auf Virustotal überhaupt Linux-Software testen – Funde hat es durchaus schon gegeben – wie dies zu bewerten ist. Wenn jedoch ein Programmierer derart sorglos und luschig arbeitet, muß man es insgesamt annehmen. Und Code für jeweilige OS wird er auch nicht komplett und getrennt neu schreiben, sondern möglichst in einem OS multiOS kompilieren und im LAN kopieren.

Es sei ausdrücklich vor dem Einsatz von ventoy gewarnt.

Ventoy: grafisches Frontend

axt

Bisher ist ventoy unter Linux nur in einer Shell nutzbar. Das ist auch ausreichend und hat damit durchaus einen nerdigen Charme. ;-) Mit Version 1.0.52 wird nun auch ein grafisches Frontend, das der Windows-Version sowohl in Funktionen als auch Aussehen gleicht (Screenshot auf LXQt/Openbox/Mikachu in einer VM), mitgeliefert.

Btw., auch, wenn ich nicht mehr Ventoy: Verdacht auf Malware #2 aktualisiere, ich lasse selbstverständlich weiterhin jede Linux- und Windows-Version scannen. Sollte sich wieder etwas diesbzgl. ereignen (nur dieser malaysische MaxSecure, quasi nebenan, 1/62, meckert für die Windows-Version nach wie vor), wird dies kundgetan.

Timetable: EndeavourOS

axt

Das aktuelle EndeavourOS-Release als Anlaß nehmend, liste ich ähnlich wie schon für siduction dessen Timetable. Da ich die Images aufgeführter Distributionsversionen bislang nicht gelöscht habe (normalerweise hebe ich veraltetes nicht auf, habe den Artikel aber schon länger geplant), habe ich diesmal Image Sizes, Kernel und XServer konkret aufführen können (ich hab’ jedes Image in einer VM mindestens soweit gebootet – und das ist stellenweise recht interessant ;-)).

Read more “Timetable: EndeavourOS”

Thunderbird: Feeds ohne Zertifikat

axt

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”

arch/LXQt: Gruppierte Fenster im Panel nicht waehlbar

axt

Laufen mehrere Instanzen eines Programmes, werden deren Fenster in einem Panel gruppiert. Das bedeutet, in bspw. LXQt-Panel erscheint nur 1 Tab für eine Programmgruppe, geht man darauf, klappt das Panel vertikal bzw. horizontal (je nach Anordnung des Panels) auf, man kann das gewünschte Fenster anklicken.

Man spart damit also massiv Platz. Hat man z.B. Thunderbird geöffnet, will eine eMail schreiben, sind das schon mal 2 Fenster, im Tb-Tab gruppiert. Benötigt man für die eMail Informationen aus dem ebenfalls geöffneten Filemanager oder Browser, wechselt man dorthin und wieder zurück.

Seit Mitte der Woche sind gruppierte Fenster aber nicht mehr klickbar. Der jeweilige Tab öffnet sich zwar (es fällt schon auf, daß man dazu überhaupt klicken muß, denn eigentlich ist es ein Mouseover), man sieht die einzelnen Einträge, beim Klick darauf schließt sich aber sofort die Auswahl.

Mit ctrl+tab kann man zwar die Fenster weiterhin wechseln, sind jedoch viele geöffnet, braucht das länger.

Eine Falschkonfiguration in z.B. panel.conf ist es nicht, ich nehm’s vorweg, nicht das Panel selbst ist die Ursache.

Ich habe diverse Bugtracker als RSS-Feeds aboniert. In dem von arch findet sich tatsächlich FS#70386 – LXQt panel doesn’t allow to select any grouped window von gestern Nachmittag. Offensichtlich sind kürzliche Änderungen in bestimmten qt5-Paketen in arch ursächlich.

Als Workaround kann man die jeweils letzte Version ohne den Namenszusatz “kde” installieren. Hat man diese noch in “/var/cache/pacman/pkg/” liegen, kopiert man diese einfacherweise in ein leeres Verzeichnis, um von dort mit “pacman -U *” zu installieren. Wer sein System sauber hält, hat die freilich nicht mehr und zieht sie sich von archive.archlinux.org:

1
2
3
4
5
6
7

mkdir -p ~/Downloads/arch/oldver/qt5/
cd ~/Downloads/arch/oldver/qt5/
wget https://archive.archlinux.org/packages/q/qt5-base/qt5-base-5.15.2-5-x86_64.pkg.tar.zst
wget https://archive.archlinux.org/packages/q/qt5-declarative/qt5-declarative-5.15.2-1-x86_64.pkg.tar.zst
wget https://archive.archlinux.org/packages/q/qt5-svg/qt5-svg-5.15.2-2-x86_64.pkg.tar.zst
wget https://archive.archlinux.org/packages/q/qt5-wayland/qt5-wayland-5.15.2-1-x86_64.pkg.tar.zst
yay -U *

Es erfolgt eine Warnung, daß gedowngradet werden soll.

Um im nächsten Update-Prozeß diese 4 Pakete nicht gleich wieder zu ersetzen, muß man sie natürlich pinnen. In “/etc/pacman.conf” erweitert man die entsprechende Zeile auf “IgnorePkg = qt5-base qt5-declarative qt5-svg qt5-wayland”.

Vergessen kann man das Ganze nicht, denn z.B. “yay -Syyu” zeigt “ignoring package upgrade” an. Sind dann gefixte Pakete verfügbar, kommentiert man die IgnorePkg-Zeile aus oder entfernt die Paketnamen.

·

Update: Revert the revert, the affected applications have been fixed ;-)

Wenn qt5-base-5.15.2+kde+r171-3 in Abhängigkeit der Aktualität des jeweiligen Mirrors angeboten wird, kann und sollte das Pinning wieder aufgehoben werden.