Pinephone: alle RPMs im PVA Repo

Posted on by
Wer Carola auf seinem Fedora PC installiert hat, hat vielleicht schon davon gehört, daß es ein REPO bei Linux-Am-Dienstag.de gibt: http://repo.linux-am-dienstag.de/pva.repo
modemmanager-agps-1-1.aarch64.rpm
pathdiscover-1-1.aarch64.rpm
phosh-antispam-1-2.aarch64.rpm
Man kann sich da auch die PVA RPMs ziehen, die neueste Version mit dem IMAPSync läuft 1a auf dem Pine, auch wenn x86_64 dran steht 😉

Pinephone: NHEKO angetested

Posted on by

Mir war langweilig, da habe ich Nheko, ein Matrix Client installiert via RPM aus dem Fedora Repo, kurz für Euch angetestet und gleich noch ein paar Tipps parat.

Pinephone: NHEKO angetested

Es war Zeit Nheko mal wieder anzutesten, weil ich einen Matrixclienten brauche, der nicht rückwärts schreibt, keinen immensen Platz verbraucht und die CPU nicht zu 100% auslastet beim Telefonieren(so wie Firefox 🙁 ).

Nheko hat in der Zeit seit meinem letzten Test viel verbessert. Da wäre die Telefonie, die E2EE (Ende-Zu-Ende-Verschlüsselung) und das Handling von Spaces zu nennen. Klappt alles, wenn clevererweise in den EInstellungen als ersten den Touchscreenmode aktiviert.

Allerdings gibt es auch ein „kleines“ Problem 🙂 Das UI Scaling findet leider nicht bzw. falsch statt. Statt den Screen kleiner zurechnen, wenn in der Desktopumgebung ( DE ) Phosh 200% UI-Scaling aktiviert ist, damit man an alles ran kommt, wird das z.Z. noch nicht beachtet. (Hat vermutlich keiner getested 🙂 ).

Damit man sich anmelden kann, muß man erstmal in den Phosh-Einstellungen für den Bildschirm das Scaling auf 150% oder 100% setzen. 150% ist ein guter Kompromiss, weil man so die Hürde Loginscreen überwinden kann, ohne sich eine Lupe holen zu müssen 😉

Danach geht es mit 150% UI-Scaling ganz gut zu bedienen. Es war etwas merkwürdig, daß man swipen muß um einen „Bereich“ wie z.b. einen „Space“ oder „alle Räume“ zu erreichen, statt da einfach auf den Namen zu klicken, aber man kommt drauf… irgendwann 😉

E2EE funktioniert

Als ersten wird man daran erinnert, daß man ja jetzt die neue Client-Session verifizieren muß, war mit Hilfe der Emoticons gut klappt. Allerdings sah es optisch noch nicht ganz rund aus, was aber kein Problem darstellt. Auch wurden noch einige & HTML-Codes im Fenster/Requester Titel nicht umgewandelt, aber auch das ist ein rein optischer Fehler.

Was ich sagen kann ist, die E2EE funktioniert. Die Entwickler weisen daraufhin, daß die Implementierung im Securitycontext ungeprüft ist, also unsicher implementiert sein könnte. Da wirds es wohl Zeit für ein kleines Croudfunding für den Code-Auditor.

Es klingelt \o/

Full-Featured Matrix Clienten können ja auch Audio- und Videoanrufe managen. Das habe ich natürlich sofort ausprobiert und das Ergebnis war im erwarteten Maß funktional. Reine Audioanrufe funktionieren, wobei Ihr wissen solltet, daß der erste Anruf immer etwas länger braucht, als die nachfolgenden. Das scheint nicht am Clienten zu liegen, sondern am Tunnel- oder Synapseserver selbst. Auf Android mit Element oder Schildichat dauert es beim ersten mal auch länger.

Bei Videoanrufen habe ich nicht mit einem Erfolg gerechnet, was auch prompt nicht geklappt hat. Das liegt aber nicht an Nheko, sondern an der Art und Weise wie man auf dem Pinephone auf die Kamera zugreift und das funktioniert nicht. Im Firefox übrigens zur Zeit auch nicht mehr. Ob das am Kernel liegt, oder gstreamer oder sonst eine Systemkomponente kann ich nicht sagen. Müßte man mal debuggen.

Angerufen werden funktioniert auch, dummerweise kann man den Call auf den Lockscreen nicht annehmen, auch wenn man einen Hinweis sieht. Ich empfehle den Post von Guido Günther auf dem Gnome-Blog zu lesen, die bauen da gerade ein Pluginsystem für den Lockscreen, so daß man da alles mögliche tun kann. Wozu man dann noch den Lockscreen braucht, verstehe ich allerdings nicht so ganz 🙂 In letzter Konsequenz wäre der überflüssig, wenn alle Apps da Ihren Kram machen können.

1% CPU Last

Ich habe gerade mal nachgesehen, im Leerlauf kommt Nheko auf einem Core auf 1% Last. Das ist echt klasse!

Ich habe da auch mal alle GPU Tricks aktiviert im nheko.desktopfile:

Exec=env LIBVA_DRIVER_NAME=v4l2_request LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video0 LIBVA_V4L2_REQUEST_MEDIA_PATH=/dev/media0 nheko %u

Sofern Nheko Hardware Rendering kann, reduziert das oben den Stromverbrauch noch mehr. Ich habe auch das Gefühl, es startet jetzt schneller.

Fazit: sehr brauchbar, wenn der UI-Scale-Faktor korrekt beachtet würde 🙂

Pinephone: How to Fix Geary’s Libsoup Problem

Posted on by

Nachdem ich Euch gestern den Statusbericht geschrieben hatte, wollte ich mal mit Geary Emails lesen. Was für eine fatale Entscheidung 🙁

Pinephone: How to Fix Geary’s Libsoup Problem

Was braucht man zum Lesen von Emails? Ein Emailprogramm! Also nehmen wir doch das seit zwei Jahren installierte, konfigurierte und funktionierende Geary … startet nicht … öhm ?!?!

Dem Journal seine Geheimnisse zu entreißen war auch nicht so einfach, weil Geary nicht als geary Unit logged, sondern als „geary-autostart.desktop[4159]“ wobei die Zahl die PID des Prozesses ist die, na wer räts, flexibel ist. Hallo?!?! Er hat denn diesen Blödsinn jetzt wieder verzapft!

Kommen wir zum Problem

geary-autostart.desktop[4159]: ![err] 18:09:01.0248 libsoup:libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.

Wahnsinnsmeldung, aber tatsächlich zutreffend. Es gibt zwei Versionen von der LibSoup: 2.4 und 3.0.

Libsoup is an HTTP library implementation in C. It was originally part of a SOAP (Simple Object Access Protocol) implementation called Soup, but the SOAP and non-SOAP parts have now been split into separate packages.

1/3 aller Apps setzen noch auf 2.4, die anderen 2/3 setzen auf die Version 3.0 der Lib. Offensichtlich ist es nicht erlaubt, beide Versionen gleichzeitig in einem Programm zu benutzen, was ja auch Sinn macht, weil so ein App-Entwickler leicht mal den Überblick über seine Ressourcen verliert und dann passieren ganz komische Dinge.

Es gibt es nur ein kleines Problem:

# ldd /usr/bin/geary | grep soup
libsoup-2.4.so.1 => /lib64/libsoup-2.4.so.1 (0x0000007f80910000)

… kleine Pause, damit sich die Info bei Euch setzen kann…

Ok, also Geary nutzt nur die 2.4, kann aber nicht sein, weil die Meldung sagt ja, daß beide Versionen gesichtet wurden. Da müssen wir wohl mal mit strace nachsehen, was da abgeht:

pine@fedorapine ~]$ strace -f geary 2>&1 | grep soup
openat(AT_FDCWD, „/lib64/libsoup-2.4.so.1„, O_RDONLY|O_CLOEXEC) = 3
[pid 5045] openat(AT_FDCWD, „/usr/lib64/evolution-data-server/libsoup-3.0.so.0“, O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
[pid 5045] openat(AT_FDCWD, „/lib64/libsoup-3.0.so.0„, O_RDONLY|O_CLOEXEC) = 21
[pid 5045] write(2, „![err] 18:13:40.0262 libsoup:lib“…, 121![err] 18:13:40.0262 libsoup:libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.) = 121

Wie der erfahrene Leser sofort sieht, sind hier zwei Prozesse beteiligt, der Hauptprozess ist Zeile 1, also Geary selbst:

openat(AT_FDCWD, „/lib64/libsoup-2.4.so.1„, O_RDONLY|O_CLOEXEC) = 3

ein Subprozess mit PID 5045 sind die anderen:

[pid 5045] openat(AT_FDCWD, „/usr/lib64/evolution-data-server/libsoup-3.0.so.0“, O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
[pid 5045] openat(AT_FDCWD, „/lib64/libsoup-3.0.so.0„, O_RDONLY|O_CLOEXEC) = 21
[pid 5045] write(2, „![err] 18:13:40.0262 libsoup:lib“…, 121![err] 18:13:40.0262 libsoup:libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.) = 121

Jetzt ist eigentlich schon klar, daß Geary tatsächlich nur die 2.4 lädt, aber irgendeine Lib/App/Plugin das Nachgeladen wird, will die 3.0 laden.

Da stellt sich jetzt die Frage, wie man das rausbekommt, weil Geary schon 148 Libs lädt und was das an Plugins lädt, steht nur im Source drin und ist vermutlich auch hochgradig davon abhängig, was das jeweilige Plugin vorhat.

Langer Rede kurzer Sinn

Um das rauszubekommen, mußte eine radikale Entscheidung her:

chmod 000 /lib64/libsoup-3.0.so.0.0.5

Eigentlich als Notmaßnahme gedacht um zu sehen, ob Geary starten würde, wenn man die Lib aus dem System entfernt, brachte das dann alles nötige ans Licht. Geary startet nämlich „normal“, aber eine als Adressbuch genutzte Komponente namens „folks“ , die wollte nicht mehr.

libfolks is a library that aggregates people from multiple sources (e.g. Telepathy connection managers and eventually evolution data server, Facebook, etc.) to create meta-contacts.

Das machte sich dann im Journal so bemerkbar:

Aug 17 18:55:01 fedorapine geary[5678]: *[wrn] 18:55:01.0337 folks:backend-store.vala:768: Failed to load module from path ‚/usr/lib64/folks/26/backends/eds/eds.so‘: libsoup-3.0.so.0: Kann die Shared-Object-Datei nicht öffnen: Keine Berechtigung
Aug 17 18:55:01 fedorapine geary[5678]: *[wrn] 18:55:01.0369 folks:backend-store.vala:768: Failed to load module from path ‚/usr/lib64/folks/26/backends/bluez/bluez.so‘: libsoup-3.0.so.0: Kann die Shared-Object-Datei nicht öffnen: Keine Berechtigung
Aug 17 18:55:01 fedorapine geary[5678]: *[wrn] 18:55:01.0377 folks:backend-store.vala:768: Failed to load module from path ‚/usr/lib64/folks/26/backends/ofono/ofono.so‘: libsoup-3.0.so.0: Kann die Shared-Object-Datei nicht öffnen: Keine Berechtigung
Aug 17 18:55:01 fedorapine geary[5678]: *[wrn] 18:55:01.0418 folks:Failed to find primary PersonaStore with type ID ‚eds‘ and ID ’system-address-book‘.
Aug 17 18:55:01 fedorapine geary[5678]: Individuals will not be linked properly and creating new links between Personas will not work.
Aug 17 18:55:01 fedorapine geary[5678]: The configured primary PersonaStore’s backend may not be installed. If you are unsure, check with your distribution.

Jetzt haben wir die Ursache für das Problem gefunden, aber wie fixen wir das jetzt erstmal temporär, bis Geary auf LibSoup-3 umgestellt ist?

How to Fix … auf die ganz harte Tour

Wir brauchen…

einen Gearywrapper
die Hilfe von Sudo
und ein gutes Gedächtnis,

weil das dürft Ihr nach jedem Geary oder LibSoup3 Update nochmal anpassen 🙁

SUDO

Wir tragen in die /etc/sudoers entweder direkt oder über das sudoers.d Verzeichnis folgendes ein:

# cat /etc/sudoers | grep geary
@include /etc/sudoers.d/gearywrapper.conf

# cat /etc/sudoers.d/gearywrapper.conf
pine ALL = (root) NOPASSWD: /usr/bin/chmod

ACHTUNG: damit darf der Pineuser alle Files chmodden die er will, oder die ein Angreifer will, aber nie ändern können sollte. Anders gehts aber erstmal nicht.

Der Geary-Wrapper

In die Datei /usr/local/sbin/gearywrapper muß das rein:

#!/bin/bash

sudo /usr/bin/chmod 000 /lib64/libsoup-3.0.so.0.0.5
geary –gapplication-service
sudo /usr/bin/chmod 755 /lib64/libsoup-3.0.so.0.0.5

dann chmod 755 /usr/local/sbin/gearywrapper ausführen.

Das Geary-Desktopfile

Das File /usr/share/applications/geary-autostart.desktop muß so geändert werden:

#TryExec=geary
#Exec=geary –gapplication-service
Exec=/usr/local/sbin/gearywrapper

Das File /usr/share/applications/org.gnome.Geary.desktop kann so geändert werden, aber nicht alle Einträge sind wichtig, die ersten 2 reichen:

TryExec=/usr/local/sbin/gearywrapper
Exec=/usr/local/sbin/gearywrapper %U
Exec=/usr/local/sbin/gearywrapper mailto:
Exec=/usr/local/sbin/gearywrapper –new-window

Ab jetzt startet Geary aus dem AppGrid wieder \o/ nur das Adressbuch funktioniert nicht mehr ganz so umfangreich wie es sollte, aber zumindest kann man wieder Emails lesen und schreiben.

Update: 13:46 Uhr – fixed Geary 40.0-9 released

Fedora Maintainer Kalev Lember hat für die älteren Versionen von Geary, und natürlich die Rawhideversion, einen Upstreampatch in den Fedora Build integriert und mit dem Paket ab Version 40.0-9, ist der Fehler behoben und Geary startet auch mit dem aktuellen folks und Evolution Unterbau. Auf den obigen Workaround hingewiesen, entfleuchte Kalev der folgende Kommentar: „Hah, fun hack 🙂“ . Es war zwar echt nervig das Problem zu isolieren, aber der Workaround war wirklich spaßig 😀