Pinephone: Daily Driver – Tag 1

Hallo Linuxphone Fans,

heute ein Bericht zu Neuerungen am Pinephone und die Antwort auf die Frage „Wie wars damit im Meeting zu sitzen“ 🙂

Pinephone: Daily Driver – Tag 1

Zunächst, es gibt jetzt Gnome 40 BETA für Pinephone, aber leider stützt seitdem die gnome-session häufiger ab. Ich kann das Update nicht empfehlen. Leider hängt da eine Menge an anderen Programmen dran, weshalb dies (Nicht)Update dann sehr viele andere Updates verhindert. Wenn es Euch hilft: Es stürzt zwar ab und zu ab, aber das ist nicht sooo dramatisch oft.

Die Gnome Session 40 Beta hat auch einen Vorteil, denn die 2 Min. Timeouts beim Runterfahren oder Rebooten sind weg, Jetzt hängts nur noch am Ende beim Reboot oder Shutdown Target 😀

Mit dem nächsten Systemd Update wird jetzt systemd-oomd auf dem Pinephone nicht mehr ausgeführt, weil „tada“ .. mangelnde Unterstützung 🙂 Brauchen tun wir den zur Zeit eh nicht, weil 3 GB RAM schon ganz ordentlich sind, bei den bisschen Apps die da zum Einsatz kommen.

Megapixels kommt

Megapixels ist in einer neuen Version erschienen und stützt/friert jetzt beim Foto speichern nicht mehr ab/ein. Außerdem hat Martijn Braam ein Farbkorrekturprofil hinzugefügt, so daß wieder Farbe in die Bilder reinkommt. Leider funktioniert das in der Vorschau nicht live. Da man es nicht eh nicht beeinflussen kann, spielt das auch keine Rolle. Außerdem ist der Kamerawechsel jetzt stabil möglich. Das gilt auch für die ISO und Shutter(Belichtung) Einstellungen, die zwar immer noch umständlich und zu klein, aber dafür wenigsten ohne Absturz nutzbar sind.

Megapixels hat jetzt einen eingebauten QR Scanner, der sogar funktioniert, wenn man ein Pinephone mit funktionierendem Autofocus hat, was, laut Martijn Braam, nicht jedes Pinephone hat. Die Ursache ist unbekannt, wie so vieles was diesen verbauten Chip betrifft 😉  der QR Code Scanner zeigt bislang den Inhalt nur in Megapixels ab. Ich habe mal vorsichtig angefragt, was denn eigentlich passieren sollte 😉

Als Appetitthäppchen habe ich da mal was für Euch:

22:30 Uhr – Darktable WB Korrektur – Krita mit Iain’s Denoise entrauscht

Wir hatten heute Nebel – Krita Farbsättigung – Entrauscht mit Iain’s big Denoise

22:15 Uhr Entrauscht mit Krita Iain’s big Denoise ( G’mic )

Verglichen mit einem Chip von 2010 ist das „gar nicht mal so übel“ meinte Martijn 😀

Umwerfende Bilder werden wir aber vermutlich mit dem Pinephone nie sehen werden 😉

Pinephone als Daily Driver – Tag 1

Kommen wir zur spannenden Frage, wie wars denn so tagsüber mit dem Pinephone als Begleiter?

Tja, Warm 🙂 also man merkt es in der Tasche, wenn es was getan hatte. Positiv überrascht war ich, daß Gesprächspartner nicht gemerkt haben, daß sich das Telefon gewechselt habe. Das Mikro ist auch passend laut und super im Freisprechen im Auto. Das war allerdings schon alles positive des Tages.

Phosh ist wegen Gnome-Session bei der Vorführung abgesemmelt. Naja, gnome-session riss es mit, als es den Abgang machte. Dafür war es dann sehr schnell wieder da. Für 4 h Einsatz sind 50% Akkuladung drauf gegangen, da der Leerlauf bei 1.3 – 1.5 W liegt. Das ist für ein Telefon absolutes Nogo. Da werden noch viele Devs jahre mit verbringen, bis der Linux Kernel weiß, was Energiesparend ist.

Ein Anruf schaffte es nicht zur Annahme durch den Lockscreen, vermutlich weil ein Mediaplayer Musik spielte. oh, ich habe mich übrigens geirrt, es gibt doch noch etwas positives: Die Medienkontrolle im Lockscreen funktioniert, was sehr praktisch beim Autofahren ist, da man es damit blind bedienen kann: blindes Verklicken tut niemandem weh.

Für Nachts durfte dann Android wieder dran. Mal sehen wie der nächste Testtag wird.

 

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  😉