Fedora 31: keine i686 Kernels mehr?

Die Schlacht um i686 geht in die nächste Runde, kaum das Ubuntu zurück gerudert hat bzw. sich da noch windet, schlagen die ersten bei Fedora in die gleiche Kerbe: Keine i686 Kernels mehr.

Keine i686er Kernels mehr für Fedora 31+

Ben Cotton hat dazu geschrieben:

On Fri, 21 Jun 2019 at 14:15, Ben Cotton <bcotton@redhat.com> wrote:

https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

== Summary ==
Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.

Anders als bei Ubuntu sollen alle Supportpakete weiterhin gebaut werden, so daß Wine keine Probleme machen würde, man könnte halt nur keine 32Bit Systeme mehr mit einem neuen Kernel booten und dann in Folge irgendwann gar nicht mehr, weil der Kernel zu dem ganzen Boot/Init des Systems ja in nicht unerheblichen Teilen beiträgt.

Früher oder später war der Schritt ja zu erwarten. Das wenigsten die 32Bit RPMs weiterhin gebaut werden, damit 32 Bit Anwendungen auch unter 64 Bit  funktionieren, ist ein Lichtblick, außer für Besitzer von 32 Bit Systemen.
Ein Wine ohne 32 Bit wäre für viele User ein absolutes No-Go, weil zig alte Windowsgames auf 32 Bit laufen!

Fedora hat Krita 4.1.8 bekommen und wir ein Problem

Freude, Fedora hat ein Krita Update bekommen \o/ … öhm…auf die sechs Monate alte Version 4.1.8, statt der aktuellen Version 4.2.2. Und damit einen Bug, den Linux Mint schon im Januar hatte, man kann jetzt nämlich das Fenster nicht mehr maximieren. WTF !

„Erfreut Euch an den Bugs, was anderes habt Ihr nicht!“ (Bill Gates)

Ich spare mir mal das lange Palaver über die Ursachen alte Versionen zu compilieren, wenn dann auch noch Bugs drin sind. *Kopfschüttel*  Der Fix ist jedenfalls denkbar einfach. Auf der rechten Seite sind Docker untergebracht. Auf den ersten Blick bemerkt man, daß die Seite komisch aussieht, weil jede Menge neue, völlig unnütze Docker da drin sind. Aus einem mir unverständlichen Grund, triggert das Krita dazu, das Maximize Button im Fensterrahmen abzulehnen und sonst auch alle Request an den Windowmanager das Fenster doch mal zu vergrößern zu verneinen.

Wenn man jetzt ein paar von den Dockern entfernt, braucht man vermutlich eh nicht, dann kommt zuerst die Maximize Funktion wieder und nach dem ersten Refresh des Fensterrahmens ist auch das Button wieder da.

Wer das Zitat von Bill Gates nicht kennt, kann ja mal auf den Text klicken 😉

Systemd: Aus den Wirren des Paketmanagements

„Aus den Wirren der Paketabhängigkeiten im Dschungel von Systemd“ man könnte einen Roman damit betiteln 🙂  Gestern abend, es war mal wieder Serverupdatezeit, flutschte eine Anzeige eines Fedora-Paketes, daß keinen Sinn machte, über den Bildschirm: qrencode-libs

QR Codes auf einem Server?

Ja, wenn man eine Webseite hat, die z.b. QR Codes ausgibt, weil eine HandyApp einen Bestätigungscode haben will, warum nicht. Dummerweise hatte dieser Server genau einen Job und der hatte nichts mit QR Codes zu tun. „Naja,ok, das wird jemand mal irgendwann für was ausprobiert haben… kann weg!“ denkste Dir so.. und dann kommt das Erwachen: „Wieso will dnf jetzt systemd löschen?“

$ sudo dnf erase qrencode-libs
[sudo] Passwort für  ….. :
Fehler:
Problem: The operation would result in removing the following protected packages: systemd

Das kommt so …

Der Systemd hat eine harte Abhängigkeit auf die lib von dem qrencoder :

$ rpm -q -R systemd | grep qrenc
libqrencode.so.3()(64bit)

ganz genau genommen ist es journalctl:

$ ldd /usr/bin/journalctl |grep qrenc
libqrencode.so.3 => /lib64/libqrencode.so.3 (0x00007fef36540000)

„Kann mir bitte einer erklären, wieso journalctl QR CODES bauen können müßte ?????“

Kann ja wohl nur ein Fehler sein 😉   Der Maintainer bei Redhat war da jetzt anderer Meinung:

What do you mean "wrongfully"? It's "rightfullly" linking against qrencode-libs because that functionality is used by journalctl.
While somewhat unfortunate, it's correct.

Steht aber allein da, denn auch bei Manjaro Linux ist das schon mal jemandem vor mir aufgefallen und siehe:

https://forum.manjaro.org/t/systemd-238-51-1-has-picked-up-a-dependency-on-qrencode/43070

Could this be due to a dirty chroot?

$ ldd `which journalctl`
	linux-vdso.so.1 (0x00007fff47fc9000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f55fd82e000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f55fd477000)
	libsystemd-shared-238.so => /usr/lib/systemd/libsystemd-shared-238.so (0x00007f55fd027000)
	libqrencode.so.4 => not found

I’m pretty certain journalctl doesn’t need qrencode?

Das sehe ich auch so, trotzdem habe ich mal etwas geforscht und die Ursache gefunden:

journalctl .c

#if HAVE_QRENCODE
/* If this is not an UTF-8 system don’t print any QR codes */
if (is_locale_utf8()) {
fputs(„\nTo transfer the verification key to your phone please scan the QR code below:\n\n“, stderr);
print_qr_code(stderr, seed, seed_size, n, arg_interval, hn, machine);
}
#endif

Jetzt wirds spannend:

Wozu wird das benutzt?

Um, wenn es ein UTF8-System ist UND der Code mit dem QR Support kompiliert wurde, einen Verifikations Schlüssel als QR CODE fürs Handy auszugeben, um mit dem Versiegelungs-Schlüssel abgesicherte Journaleinträge zu prüfen.

Das Verfahren heißt bei Systemd Forward Secure Sealing (FSS).  Keine Ahnung wer das Feature von Journald nutzt. Es klingt jedenfalls nach einer brauchbaren Idee, falls ein Hacker die Einträge manipuliert. Ich bezweifle aber stark, daß der Key dabei per QR Code an ein Handy übermittelt werden muß, statt per SCP an einen anderen Server.

Für diese eine Zeile Code da oben, die kaum jemand jemals einsetzen wird (Bitte Zahlen liefern, wer welche hat), immer noch diese Lib mit sich rumschleppen… was solls, GB sind billig  😉