Pinephone: Firefox Addons wieder gangbar machen

Moin, Moin,

wer auf dem Pinephone alle Fedora Updates eingespielt hat, wird jetzt aktuell keine Addons mehr haben, weil die systemweiten Crypto-Policies dies unterbinden.

Pinephone: Firefox Addons wieder gangbar machen

Wie Ihr diesem früheren Beitrag hier entnehmen könnt:

NSS 3.59 bricht mit SHA-1: Firefox Addons betroffen

Hat die Einstufung von SHA-1 als unsicherer Hash-Algorithmus zur Folge, das die Zertifikate zum Signieren von Firefox Addons nicht mehr akzeptiert werden, aber viele Addons von Mozilla noch nicht mit sha256 signiert wurden. Das nss 3.59.0-3 Paket, das diese Beschränkung temporär wieder aufhebt, hat es leider nicht auf Rawhide geschafft, weswegen Firefoxaddons jetzt nicht mehr funktionieren.

Allerdings kann man da selbst Abhilfe schaffen. Einmal Root werden und folgendes eingeben:

update-crypto-policies –set DEFAULT:FEDORA32
reboot

Nun läuft das Pinephone auf einem etwas entspannteren Modus. Das darf natürlich nicht ewig so bleiben. Wir warten lediglich bis es ein Firefoxupdate gibt, daß die NO-SHA1 Policy für Firefox ignoriert, bis die ganzen Addons neu signiert wurden. In dem Augenblick können wir die DEFAULT Policy wiederherstellen ( update-crypto-policies –set DEFAULT ).

Doch noch einen weiterer Pinephone Beitrag vor Silvester geschafft 🙂

 

Pinephone: Judgement Day!

In den letzten Tagen haben wir das Pinephone zusammen aufgebaut, es gewartet, mit Ihm gespielt, ja so angefreundet. Heute aber kommt der Terminator, denn es ist …

Pinephone: Judgement Day!

Wir haben jetzt den 4. Advent… ok, Ihr aber nicht mehr.. und noch kann man mit dem Pinephone nicht das tun, was der Name insistiert: Telefonieren. Ok, zumindest unter Fedora kann man es nicht, weswegen ja auch noch die Manjaro Community Edition auf der internen Speicherkarte ist.

Was geht denn so alles nicht mit dem Pinephone und wo hakt es gewaltig?

Gestern machte ich mich bewaffnet mit meinem neuen „Telefon“ auf den Weg um das GPS in freier Wildbahn zu testen. Leider kam ich nur bis zur anderen Straßenseite, dann war die Grenze des Wlan überschritten und die Gnome-Maps Anwendung streikte knallhart. Merke: Ohne I-NET keine Positionsupdates – von Offlinekarten & Cachen keine Spur.

Ok, ein Smartphone sollte ja i.d.R. Mobilfunk dabei haben, aber was machen die Leute, die damit von einer Nordseeinsel zur anderen Insel navigieren wollen? Antwort: In die Röhre schauen!

Viel Spaß hätten Sie mit der zickigen kleinen App auch nicht, denn die Schrift für die Straßen wird winzig angezeigt, keine Chance da im Auto während der Fahrt etwas zu lesen. Immerhin Routenplanen geht, aber auf die Idee, den GPS Standort als Ausgangsort für eine Route zu benutzen oder auch nur anzubieten: Fehlanzeige. Es würde sowieso nicht nutzen, bedienen lässt sich die App während der Fahrt eh nicht, die Buttons sind viel zu klein dafür, wenn sie denn überhaupt auf einen Druck reagieren. Wäre die App von Google, dann wären die heute ein Subunternehmen von Microsoft oder Apple.

Fehlender DPI Ausgleich

Das Hauptproblem hier ist der fehlende DPI Skaler in den Bildschirmeinstellungen. Der würde Appanwendungen größenmäßig verdoppeln, was der Sache entgegen käme, aber aus irgendeinem Grund (vermutlich Display zu klein .. muhahahar .. urgs 🙁 ) nicht vorhanden ist.

Foto: Surface Pro 4 Fedora 32 Gnome

Wenn ich mein 3k Tablet nehme, kann ich dort 100%, 200% und 300% auswählen. Das müßte im Pine eigentlich nur mal aktiviert werden. Kann eigentlich nicht so schwer sein. Phosh setzt an genau dieser Stelle an, da es dort quasi permanent aktiviert ist. Man kann es dort zum Ausgleich dafür aber nicht abschalten 😉 Mir ist gerade danach, der Aufforderung der Musik in meinen Kopfhörern zu folgen und das A-Team zu Hilfe zu rufen.

Das Gnome-Team

Ich habe ja erwähnt, daß ich 16 offene Bugs bei Gnome habe, einige beziehen sich darunter auch auf Maps. Da meinte doch ein Witzbold, daß man da den Drei-Finger-Swipe benutzen könnte um aus der Fullscreen Anwendung auf den Aktivitätenscreen umzuschalten. Der Mann hatte offenkundig noch kein Telefon mit Gnome in der Hand 😀 Das geht natürlich technisch schon, weil die Swipes theoretisch erkannt werden, aber so rein physikalisch gibt es da das Problem 3 Finger auf den Bildschirm zu bekommen und die dann auch noch auf einanderzu zu bewegen. Die ersten zehn Versuche haben nicht funktioniert. Auf dem Tablet ist das platzmäßig natürlich kein Problem. Jetzt kommt aber verschärfend noch hinzu, daß Maps ja auch auf Fingergesten reagiert 😉 Es ist genauso schlimm, wie Ihr es Euch gerade ausmalt.

Tagesform

Im Gnome-Team gibt es echt Leute die mitdenken und welche, naja, reden wir nicht drüber. Die Anzahl der vernüftigen Teammitglieder überwiegt zum Glück. Am 21.12. kam Bewegung in einige Bugs bei Gnome. Z.b. stellte sich herraus, daß die seit einem Jahr um das Problem der falsch positionierten Notificationsfensteres wissen, da auch jede Menge Patche an „mutter“ gemacht haben, es aber nicht zum Erfolg geführt hat. Was ist eigentlich so schwer daran einen Rechenfehler zu beheben, weil witzigerweise die Klicks auf dem Bildschirm an den korrekten Stellen erkannt und nur die grafischen Inhalte außerhalb vom Screen gemalt werden:

Das die ganzen Gnome App-Windows so Ihr Eigenleben führen, wissen wir ja. Starten die Fenster aus irgendeinem völlig unerfindlichen Grund mit Fenstern, die BREITER sind als der Bildschirm breit ist, reagieren die nicht auf Maximieren. Minimieren geht, aber Maximieren wird ignoriert. Das zu erwartende Verhalten wäre übrigens, kleiner zu werden und sich maximal dem Fenster anzupassen. Dann gibt noch die Appfenster, die darauf reagieren, aber einen Rand lassen! Was an „Maximieren“ ist eigentlich so schwer zu verstehen???

Von der Tagesform abhängig scheint auch der Inhalt zu sein. Das Gnome-Control-Center aka „Einstellungen“ hat einen an sich coolen weg mit Platzproblemen umzugehen. Es zeigt einfach nur die Auswahliste der Sektionen an und dann hinter den Namen einen kleinen Pfeil „>“, drückt man drauf, wird der Inhalt des Fensters eine „Etage“ nach Links geschoben, so daß man die Kontrollen benutzen kann. Theoretisch. Praktisch kommt es vor, daß das Fenster mal so, oder zweigeteilt erscheint. Dann sind links die Sektionsnamen und rechts die Kontrollen.

„..zu erwartendes Verhalten..“

Apropos „zu erwartendes Verhalten“, da meinte doch einer dazu, daß die Hotcorner links oben ( Activities ) zu recht nicht gehen würde, weil eine App im Fullscreen wäre. Blöd nur, daß gar nicht die Hotcorner Funktion gemeint war, sondern das Activities Button links oben in der Ecke selbst, das man sich mit dem Links->Rechts Swipe aus einer Fullscreenapp reinswipen kann, dann aber nicht funktioniert und jetzt kommts, mit der Begründung, „das wäre ja absichtlich so“. Ihr vermutet richtig, es war der gleiche Witzbold. Ich habe nahegelegt, doch die Erwartungshaltung zu ändern, weil die Fullscreenapp in dem Moment, wo man das Activities-Button zu sehen bekommt, eh nicht mehr zu sehen ist, sondern der Dock, den man reingeswipt hat. Leider keine Reaktion bekannt.

Statt sich mit Bugs auseinander zu setzen, wird gern mal an der Form moniert. Ich gebe da alle relevanten Infos an, wenn da mal bei „onboard“ die Anführungszeichen fehlen, wird gleich auf stur gestellt. ( Genau, Der Herr 😉 ) Ich muß allerdings auch gestehen, nach den ersten Bugs, hatte ich echt keinen Bock mehr deren Bugtrackerwahl ( Gitlab ) auszubaden, wo man sich erst das Projekt ( wenn man es denn kennt, was ich nicht zwangsläufig weiß ) auswählt und dann erst einen Bugreport anklicken kann. Wenn man Bugtracker kennt, sind da als erstes alle bekannten Komponenten in einer Auswahlbox und dann legt man mit Auswahl des OS, Architektur usw. los. Eine Singlepageanwendung quasi, nicht so bei Gitlab.

Wenn man es schon mehr zu seinem eigenen Projekt weiß als die Bugreporter, dann sollte man das einfach dem Projekt zuweisen und loslegen. Meine Meinung.

Die Ursache für die ganzen Bugs war übrigens die Maximierenfunktion meines Scripts, mit der alle neugestarteten Anwendungen handygerecht groß gemacht werden, weil sonst in der Regel unbrauchbar. Komisch ist nur, daß es bei Nicht-Gnome-Fenstern keine Probleme damit gab 😉

Zurück zum Pinephonetest in freier Wildbahn

Was passiert mit zu sensitiven Touchgeräten? Weiß man nicht, weil die Batterie auf mysteriöse Weise schnell erschöpft ist. Woher ich das weiß? Ich habe meins rechtzeitig aus der Hosentasche gezogen.

Wie Ihr ja wisst, habe ich dem Power-Button beigebogen, das Handy in den Stand-By zu schicken. Das dumme an Powerbutton mit rausstehendem Knopf ist, das sie beim Gehen von alleine gedrückt werden. Das Ende vom Lied ist, die starten dann, landen im Lockscreen und … bleiben da 🙁

Denn das Display ist so sensitiv, was zwar gut bei der gewollten Eingabe, aber sehr schlecht in der Hosentasche ist. Nach 20 Sekunden habe ich aufgegeben auf DELETE zudrücken  und einfach Login geklickt, damit das Eingabefeld für das Passwort wieder frei wird. Das ist natürlich nicht das einzige Problem das daraus resultiert. Weil alle paar Sekunden eine Eingabe erkannt wird, geht der Lockscreen nicht wieder aus. Der Bildschirm bleibt an und der zieht so 0.5 W zu den 1.5 W, die im Lockscreen ohnehin verbraucht werden.

So kann das Pinephone leider nicht ernsthaft bleiben, weil es unbrauchbar ist. Auch der Einsatz des extra für mobile Endgeräte entwickelten Phosh Desktops, hilft nur bedingt weiter. Auch da sind Schaltflächen zu klein, Fenster zu breit und frech wie oskar kann man sich mit Phosh 0.6 nicht mal mehr abmelden um einen anderen Desktop zu starten, Phosh 0.7 crasht gleich beim Start und 0.7.1 war noch nicht verfügbar.

„Housten, haben wir irgendwas das wie gewollt funktioniert?“

Ich habe vorhin entspannt „Battle of Wesnoth“ gespielt, bis der Akku „plötzlich“ leer war. Die meiste Zeit habe ich auf „Zug beenden“ gehämmert, aber naja 😀

Wenn man mal von dem Kram oben absieht, dem viel zu hohen Stromverbrauch und dem Umstand, daß ich immer noch nicht mit Fedora telefonieren kann, können wir auf das Jahr 2021 hoffen. Es kann eigentlich nur besser werden.

Also dann: Wir sehen uns in 2021 😀 Guten Rutsch Euch allen!