Beiträge von oMPete

Stimme zu! <
Das Problem vor dem PC/Smartphone ist technisch kaum lösbar.
Selbst, wenn man alles verbietet, außer purem Text, werden jene,
die rumnerven wollen dann eben Blödsinn schreiben.
Bleibt noch Blocken oder rausschmeißen.
Und am Ende vermutlich von einer großen Gruppe ein kleines Häuflein.

Hm.

Punkt 1)

Zitat von Svenn

...peinlichen Emoji-Reaktionen...Wenn ich whatsapp wollte...

klingt zumindest eher aufgeregt und liefert keine weiteren Informationen zur Sache.

Punkt 2)

Zitat von Jaroslav

Völlig an der Realität vorbei... & > bringen keinen Mehrwert <

Das geht völlig an Deiner (und vermutlich Svenn's) Realität vorbei und bringt Dir keinen Mehrwert.
Es gibt aber nunmal unterschiedliche Einsatzszenarien.
Du hast Dir immerhin die Mühe gemacht, das näher zu erläutern.
Somit ist - zumindest für mich - der Punkt "Stören" nachvollziehbar geworden.

Allerdings betrifft das in großen Gruppen / Gemeinschaften natürlich Alle Beteiligten.
Wenn es also Alle stören, oder Ihnen keinen Mehrwert bringen würde,
ist anzunehmen, dass die es schon im eigenen Interesse unterlassen würden.
Weil die Emoji-Reaktionen dort aber eben doch benutzt werden,
sonst würden sie Dich ja nicht nerven, ist das offensichtlich nicht der Fall.
Auch für den Einsatz in großen Gruppen / Gemeinschaften sprichst Du also anscheinend
zunächst einmal für Dich selbst, sicher für Einige. Definitiv nicht für Alle.
Sonst gäb es kein Problem.

Es sieht so aus, als wäre Euch damit geholfen, die Emoji-Reaktionen für Euch
empfängerseitig komplett auszublenden.
So wäre die Störung für Euch beseitigt und die anderen Teilnehmer
könnten selbige trotzdem zu ihrem persönlichen Mehrwert weiter nutzen.

Das würde ich an Deiner Stelle als konkreten Feature-Request formulieren.
Die Emoji-Reaktionen sind ja gerade neu, möglicherweise ist es kein großes Problem,
an der Stelle etwas zu verändern.

Kommt vermutlich auf den Ton an, in welchem man fragt und darauf,
wie gut man erklärt, was man genau möchte und warum.

Zitat von Svenn

Wie können diese peinlichen Emoji-Reaktionen deaktiviert werden?Stören und bringen keinen Mehrwert

Sag doch einfach all Deinen Kontakten, dass sie das lassen sollen.
Wenn keiner mit Emoji reagiert, bekommst Du die auch nicht
und musst Dich nicht ärgern.
Falls die dann einfach frech Deine Wünsche ignorieren sollten,
kannst Du sie immer noch blockieren, wie ecosviszero  vorgeschlagen hatte.

Was den "Mehrwert" angeht, find ich die Dinger selber ganz praktisch, ist also eine subjektive Einschätzung.

Hardcore!

Jetzt hab ich für einen kleinen Moment gehofft, eine wirklich aktuelle Übersicht gefunden zu haben (s.o.)

Aber Smoke taucht da nicht einmal in der Liste derer auf, die es nicht in die Übersicht geschafft haben.

Leben heißt Lernen.

WOW!

DeltaChat hatte ich bisher überhaupt nicht auf dem Schirm und finde es ausgesprochen interessant,
da hätte ich genausogut landen können. Werde es ziemlich sicher mal ausprobieren.
Bei dem Versuch, mir einen besseren Überblick zu verschaffen, bin ich gerade auf eine
gute Vergleichstabelle mit Instant Messengern gestolpert. Wikipedia ist leider hoffnungslos veraltet.

Comparison of Instant Messengers

Bei mir "Session."

Session | Send Messages, Not Metadata. | Private Messenger

Session is a private messenger that aims to remove any chance of metadata collection by routing all messages through an onion routing network.

getsession.org

Ich war eigentlich von Anfang an threema durch & durch.

Aber wegen Schwierigkeiten, es ausschließlich auf Desktop-PC zu nutzen,
verbunden mit der Tatsache, dass openMittsu noch kein PFS unterstützt
und ich deshalb momentan überhaupt keine Nachrichten mehr empfangen kann (senden geht),
hab ich mir zwischendurch einen einstweilige Alternative suchen müssen.

Ich geb es hier nicht gerne zu, aber seit den wenigen Tagen, die ich "Session" nutze,
hab ich dort schon genau doppelt so viele Kontakte, wie in 4 Jahren threema zuvor.
Allesamt bei WhatsApp abgeworben bzw. die immerhin dazu gebracht, das parallel zu installieren.
Argumente waren dabei: kostenlos, anonym, sicher(genug), FOSS, multiplattformfähig & Multi-Device-fähig,
Fork von Signal, auch in der Schweiz angesiedelt & einfach zu installieren.

Was hat bei 90% der Leute als Argument gezogen?
Kostenlos.
Banane. Traurig, aber die Realität. Und wenn es darum geht, in Kontakt zu bleiben
und nebenbei noch Menschen aus den Klauen der Datensammelkraken zu retten,
ist mir (fast) jedes Mittel recht.

Ich selber werde auf jeden Fall auch bei threema bleiben.
Hab ich ja bezahlt.
Und hoffe auf 2.x.

DAS find ich mal richtig Klasse!

Ich hab schon die ganze Zeit überlegt, hier irgendwo ein richtig gut fundiertes Plädoyer reinzustellen, warum threema das unbedingt machen sollte. Kann ich mir dann sparen. Umso besser, ich schwatze eh schon zuviel.

Das war des Pudels Kern!

Jetzt funktioniert ALLES! AppImage & auch das neue Build.

Weltklasse! Above & beyond.

Vielen Dank, Lenny & ganz besonders vielen Dank, Jana für die ganze Mühe, die Du Dir gemacht hast!

Zitat von Lenny

die neue Authentication-Variante kann ich dir senden, falls du sie implementieren möchtest

Falls es da in Zukunft was zu testen geben sollte, stehe ich sehr gerne bereit.

Dank Dir , Lenny!

Das finde ich Beides ausgesprochen hilfreich.

Zu meiner eigenen Einschätzung kann ich dann hier noch ergänzen, dass Custom ROMs nicht in einer Reihe mit VMs & Emulatoren stehen. Diese sind tatsächlich inoffizielle Bastellösungen. VMs (bei Emulatoren muss ich vorsichtiger sein, nehme aber an, dass das analog zu sehen ist) sind selber offizielle Produkte. threema supported zunächst mal (vertragsrechtlich) grundsätzlich Android. Die Frage ist an der Stelle dann, ob Android vom jeweilgen VM-Hersteller supported wird und wie weit. Also z.B. Oracle. Android in einer VirtualBox ist möglich. Wenn Oracle das offiziell unterstützt, dann ist es ein "echtes" Android. Ob das so ist, kann ich nicht sagen, nehme es aber an, gibt Anhaltspunkte.

Ähnlich vermute ich es z.B. mit Google & Android Studio.

Umgekehrt hatten wir das noch gar nicht, da hat Lenny uns gerade drauf gestossen:

Es ging immer um die Annahme: Smartphone ist ok, (Smartwatch, Automobil, wie wir gelernt haben auch) andere Hardware mit Android?

ABER: Wie sieht das mit einem Smartphone aus, auf dem ein Custom ROM von Android installiert ist?

Da bin ich sehr sicher, dass das von threema offiziell NICHT unterstützt wird. Wer Custom ROMs nutzt, muss selber wissen, was er (sie, etc.) tut. Es ist dann jedenfalls KEIN Android mehr, sondern bestenfalls etwas Android-Basiertes. Und da geht ganz klar aus den AGB hervor, dass es nicht unterstützt wird.

Besonders Interessant daran ist, dass dieser Fall sicher um ein Vielfaches häufiger ist, als die bisher besprochenen Varianten.

Cool.

Zu Beta 2.X noch: Das leuchtet absolut ein. Ist doch super, dass es überhaupt schon so gut funktioniert, schließlich BETA.

Ergänzung:

Das Thema hier war aus meiner Sicht ursprünglich eine Frage technischer Machbarkeit.

schlingo hat Durch die Aussagen zu "offiziellem" Support einen juristischen Aspekt hinzugefügt.

Ob etwas supported ist, oder nicht, ist von der Vertragsgestaltung abhängig. Die ist zunächst einmal frei. threema kann da alles Mögliche reinschreiben, oder eben nicht. Vertraglich gesehen hat der Support auch mit der Lizenzierung zu tun.

Ich z.B. habe im threema Shop eine Lizenz für Android erworben.

Lizenzen kann man bei threema unter anderem auch verschenken. Du kannst also eine Lizenz kaufen, OHNE IRGENDEINE Installation zu haben. Vertraglich gesehen berechtigt Dich der Erwerb einer Lizenz (in diesem Fall für Android) zu genau den Rechten, die vertraglich Allen gewährt werden, die diese spezifische Lizenz erwerben. Das wird auch nicht erst dann gültig, wenn Du etwas installierst. Du hast also zunächst einmal genau dieselbe Menge an Recht auf Support, die von threema jedem vertraglich gewährt wird, der eine solche Lizenz erwirbt. Das, was dort gewährt wird, hat treema sich vorher überlegt und entschieden.

Also: Der Erwerb einer Lizenz für Android (bei den Anderen Systemen respektive) gewährt die vertraglich garantierte Menge an Support für Android.

JETZT kommt die Frage nach Einschränkungen. Du gehst davon aus, dass es welche gibt. Ansonsten wäre ja Android Android und müsste gleichermassen Supported werden, unabhängig davon, wieviel Support das ist. Er muss nur gleich sein.

Deine Annahme und Aussage ist, dass Emulatoren & virtuelle Maschinen, obwohl auch Android, NICHT supported werden. Um diese Aussage zu unterstützen, verweist Du auf einen Teil der Bedienungsanleitung. Die KANN durchaus Teil der Vertragsgestaltung sein, ist sie aber in diesem Fall nicht. Damit ist das in diesem Zusammenhang irrelevant. Ich hatte Dich um Klarstellung gebeten, aber weitere Belege für Deine Aussage hast Du nicht genannt, nur die Ursprüngliche wiederholt. Davon wird sie leider nicht aussagekräftiger.

Die Frage ist, ob threema vertraglich erstens überhaupt auf Hardware eingeht und falls ja zweitens irgendwelche explizit aus dem Vertrag ausschließt, oder drittens jegliche nicht explizit eingeschlossene Hardware ausschließt. 2&3 könnten dann in Übereinstimmung mit Deiner Aussage sein. Also kann eine Frage sein: werden Emulatoren und VMs vertraglich von threema explizit irgendwo ausgeschlossen, oder werden bestimmte Hardwares eingeschlossen und alle anderen ausgeschlossen, worin genannte nicht enthalten sind?

Die AGB welche im Shop bei dem Erwerb einer Lizenz angezeigt wedren, geben das, wie ich oben schon erwähnt hatte, nicht her.

Also habe ich mich auf die Suche begeben, ob ich dazu was Genaueres finden kann. Aus threema selber unter Android kann man in den Einstellungen unter "About Threema" > "Terms Of Service" Eine spezifischere Version der Geschäftsbedingungen aufrufen, welche unter Punkt 5.1 den einzigen vertraglichen Zusammenhang zu Hardware herstellt, den ich finden konnte. Nämlich: https://threema.ch/de/faq/platforms

Nun wird es interessant. Threema macht hier für iOS Gebrauch von einem expliziten Ausschluss: Apple Car Play.

Unter Android wird alles mögliche unterstützt, (Handy, Tablet, Wearables z.B. Smartwatches und Android Auto) aber NICHTS EXPLIZIT ausgeschlossen. Wäre nun gar nichts explizit ausgeschlossen, könnte man davon ausgehen, dass ALLES Andere ausgeschlossen ist. Das ist aber nicht der Fall. (!) Daher stellt sich nun die Frage, was denn eigentlich mit VMs, Emulatoren usw. ist und warum die da nicht stehen. Da kommen wir in die Auslegung der Intention des Vertrags. Also was will threema? Es liegt die Annahme nahe, dass threema an VMs und Emulatoren an der Stelle einfach nicht gedacht hat, weil das im Use-Case-Szenario eine eher seltene Variante ist. Allerdings habe ich mich etwas gründlicher im Netz umgesehen und dabei die Idee VM und auch Emulator häufiger gefunden. Besonders Android Studio als offizielle Version von Google wird häufiger genannt und liegt gerade für die Entwicklung auch nahe. Nun wird unter Android ALLES eingeschlossen, was irgendwie geläufig ist. Threema auf einer Smartwatch und im Auto unter Android werden offiziell (!) unterstützt. Dagegen wird unter Android NICHTS explizit ausgeschlossen. Das legt nahe, das der Vertrag im Sinne threemas so interpretiert werden kann, dass funktionsfähige Android Instanzen durchaus alle unterstützt werden sollen. Warum auch nicht. Sicher kann man von Android Studio nicht behaupten, dass es weniger "richtiges" Android ist, als Android auf einer Smartwatch. Damit noch ein Kommentar zu VMs, weil das nicht jeder weiß: ich habe es zwar weiter oben als Spiel & Bastellösung bezeichnet, damit aber meine eigene VM gemeint. Virtualisierungstechniken sind weit verbreitet und gerade die ganz Großen setzen vielfach auf VMs. Ganze Cloudserverfarmen laufen in virtuellen Maschinen. Mit allen Konsequenzen. Selbst, wenn man also davon ausgeht, dass threema nur "richtige" Android Instanzen unterstützt und dann eine virtuelle Maschine z.b. von Oracle oder VMWare mit einem Smartphone oder einer Smartwatch vergleicht, darf behauptet werden, dass die VMs die deutlich professionelleren Umgebungen sind. Bei Emulatoren kenne ich mich nicht so aus, aber wenn Android Studio die offizielle Test- und Entwicklungsumgebung für Android ist, dann ist das sicher nicht weniger Android, als auf irgendeinem Smartphone oder einer Uhr oder im Auto.

Aus diesen Gründen darf ziemlich sicher angenommen werden, dass es vertraglich gesehen von threema gewollt ist, dies auch zu unterstützen. Außerdem sollte es auch im Interesse threemas sein. Je mehr Plattformen unterstützt werden (können) desto besser fürs Geschäft.

Das hatte ich in meinen Posts weiter oben auch schon versucht klar zu machen, aber hiermit ist es hoffentlich deutlicher geworden.

Davon ausgehend, dass das alles zutrifft - was es mit hoher Wahrscheinlichkeit tut - ist Deine Aussage dazu, was "offiziell" supported wird falsch.

Ansonsten wäre eine offizielle, rechtsverbindliche Aussage von threema selber zu dem Thema hilfreich. Mit dem Verweis auf eine Bedienungsanleitung ist die Frage jedenfalls nicht zu beantworten.

Nach aktuellem Stand der Dinge gehe ich also davon aus, dass ich mit meiner Android-VM eine vollwertige Instanz von threema betreibe, die auch offiziell supported wird und dass selbiges auch für andere Menschen gilt, die threema in einer vergleichbaren Installation benutzen. Nicht, dass ich den Support unbedingt nötig hätte, aber das ist hier nicht das Thema. Es geht ums Prinzip.

Sollte sich offiziell von Seiten threemas herausstellen, dass ich mit meiner Interpretation der Vertragsgrundlage doch falsch liege, wäre auch gleich noch interessant, ob nicht explizit genannte Installationsformen von threema toleriert werden. Da das bei openMittsu so ist, ist eigentlich davon auszugehen. Fallls nicht, würde ich selbstverständlich threema nicht mehr in der VM betreiben und bis auf Weiteres ohne threema leben müssen, in der Hoffnung, dass Desktop 2.x mir eine Option bietet, das zu nutzen, so wie ich möchte.

Ich halte das für unwahrscheinlich, aber wer weiß.

Ich habe das sehr gut verstanden.

Nur, was Du hier als "offizielle Aussage" bezeichnest ist eine technische Erläuterung.

Die ist nicht bindend. Bindend sind die Allegemeinen Geschäftsbedingungen. Wenn die von Dir referenzierten Punkte Teil der AGB wären, wären die dort mit eingebunden. Sind sie aber nicht. Es handelt sich ausschließlich um eine Erklärung, wie man im Normalfall etwas technisch bewerkstelligen kann. Das machet KEINERLEI bindende Aussage, was und wie von threema "offiziell" unterstützt wird.

In den AGB wird AUSSCHLIESSLICH von der Nutzung auf "einem Gerät" gesprochen. Ohne weitere Hardware zu nennen. Hier kann man noch ergänzen, dass tatsächlich durch die Möglichkeit, die threema geschaffen hat, das Gerät zu wechseln (Backup einspielen usw.) von threema eindeutig gemeint ist: auf EINEM GERÄT ZU EINEM ZEITPUNKT.

Allgemeine Geschäftsbedingungen Threema Shop – Threema Shop

Eine VM oder ein Emulator ist auch ein Gerät. Und natürlich geht es hierbei immer um die Hauptinstanz, da diese Lizenziert wird, also iOS / Android. DESKTOP/WEB ist hier irrelevant.

Nebenbei bemerkt zum Thema Lizenzen erklärt threema noch interessanterweise, dass man z.B. von iOS nicht nach Android wechseln kann und umgekehrt (mit EINER Lizenz, mit einer ID geht das ja problemlos), weil das An APPLE bzw. GOOGLE liegt, weil die das in der Lizenzverwaltung in ihren Stores nicht ermöglichen, eine Lizenz mitzunehmen. threema selber lässt das also grundsätzlich zu. Das erklärt auch die Nutzungsmöglichkeit mit openMittsu.

Es sieht hier also eher so aus, als hättest DU was nicht verstanden.

Darüber hinaus kann ich mir nur schwer vorstellen, dass wenn jemand sich threema in einer VM oder einem Emulator installiert und dann tatsächlich ein Problem bekommt und an den Support wendet, ihm dort nicht geholfen wird.

Ich lege hier nochmal nach und zwar aus ehrlichem Interesse.

Zitat von ecosviszero

De facto wird meines Wissens nach (derzeit) offiziell überhaupt nur Threema (Android-Version) auf einem "echten" Android-Gerät unterstützt

WO steht das?? Nur weil irgendwas nicht explizit erwähnt wird, heißt es noch lange nicht dass es auch nicht so ist.

Im offiziellen Shop und beim Erwerb der Lizenz, insbesondere im threema-Shop selber wird ausschließlich auf das Betriebssystem referenziert. NICHT auf die Hardware. Du kaufst threema für iOS oder Android (Ausnahme Huawei?) der einzige indirekte Hinweis ist ein Screenshot beim Erwerb der Kategorie "Mobile" von einem Smartphonebildschirm. Das ist als bindende Aussage definitiv erheblich zu dünn.

Ansonsten geht es immer nur um das Betriebssystem. Wenn ich also im threema-Shop eine Android Lizenz erwerbe und mir dann threema ausschließlich in einer VM installiere, wo Android läuft ist es ja immer noch Android, das ist der Sinn von virtuellen Maschinen. Funktioniert auch einwandfrei. Also warum sollte das "offiziell" nicht unterstützt werden?

Damit korrigiere ich meine Überlegung aus dem Post davor und stelle mich auf den Standpunkt, dass es sehr wohl "offiziell" möglich ist, threema in einer VM oder einem Emulator zu nutzen.

Falls das tatsächlich von threema selber offiziell nicht erlaubt ist (was soll eigentlich unterstützt hier in dem Kontext genau heißen? supported?) dann muss es ja irgendwo dokumentiert sein. Mit dem Kauf der Lizenz kommt ein Vertrag zwischen dem Käufer und threema zustande, da sollte es explizit drinstehen, falls nicht, wird es auch supported, muss es dann auch, denn der Lizenzerwerb im Shop jedenfalls bezeht eundeutig die Hardware NICHT mit ein.

Also: WO STEHT DAS?

Nebenbei bemerkt, ist es bei den allermeisten Herstellern irgendwelcher Software in der Regel das Ziel, möglichst VIELE Umgebungen zu unterstützen, NICHT möglichst wenige. das kommende Multi-Device System von threema deutet auch in diese Richtung. Ebenso der ganze Aufwand mit DESKTOP/WEB.

Warum sollte threema sich überhaupt für Hardware interessieren? Es läuft unter iOS / Android. Wenn da irgendwas nicht funktioniert, was nicht an threema liegt, sind Apple / Google dafür zuständig. In einer VM VMWare / Oracle usw. Bei Emulatoren... Jedenfalls NICHT threema. die supporten threema. Unter Android / iOS, egal wo es dann drauf läuft.

Noch ein letztes Beispiel: Ich seh auch NIRGENDWO explizit was zu Samsung Galaxy ... Google Pixel usw.

Bedeutet das, dass die auch nicht "offiziell" unterstützt werden?! Das wäre bitter.

Zitat von schlingo

hier noch einmal der Hinweis, dass das von Threema nicht unterstützt wird (siehe oben)

Meinst Du nicht, dass das eine ziemlich pauschale Aussage ist?

Hier wurde gefragt, ob das möglich ist. Nicht ob man es "darf" oder es supported wird. Ich dachte außerdem, da selber schon drauf hingewiesen zu haben. Habe allerdings ziemlich viel geschrieben, war auch schon spät am Abend.

Grundsätzlich stimme ich mit Dir absolut überein, dass es wichtig ist darauf hinzuweisen, gerade wenn jemand neu zu threema kommt. Ganz klar.

Aber: zumindest die von mir beschriebene Methode 1. iOS wird nach meinem Verständnis sehr wohl offiziell von threema unterstützt, zumindest insoweit 2.x BETA offiziell unterstützt wird. Dazu ist ja eine völlig normale und "legale" Instanz unter iOS nötig. Warum die nicht auf einem Tablet installiert sein dürfte, leuchtet mir nicht ein. Dass eine BETA eine BETA ist, erklärt sich wohl von selbst.

openMittsu wird nicht supportet, aber von threema offiziell toleriert, das verlasse ich mich auf die Aussage von ThE_-_BliZZarD.

Und dass die Optionen VM / Emulator experimentelle Bastellösungen für Technikaffine sind, dachte ich deutlich gemacht zu haben.

Meine langen Ausführungen hatten den Hintergrund, dass ich threema gut finde und es schön finde, da auch Andere für zu begeistern. Denen dabei zu helfen, threema für Ihre Zwecke nutzen zu können, auch wenn es etwas schwierig ist.

Man kann natürlich auch sagen: Was Du da vorhast, geht mit threema nicht. Ist jedenfalls nicht erlaubt und will threema auch nicht.

Such Dir doch 'n anderen Messenger.

Ob das im Sinne von threema ist, kann ich nicht beurteilen.

Zitat von ThE_-_BliZZarD

Das Problem ist, dass irgendwo eine Version installiert ist, die inkompatibel ist, aber zuerst geladen wird.

Das hatte ich auch so verstanden und hiermit gemeint:

Zitat von oMPete

dass irgendein Paket ("buggy") VORHER eine Abhängigkeit mit QT5 (anscheinend verschiedene) installiert,

"Buggy" der Diskussion auf Arch-Linux folgend und ich hab bei QT selber mal reingeschaut. Irgendein Programm nutzt 5.12.8, obwohl mein System LM 21.3 (auf Ubuntu 22.04) auf Version 5.15.3 unterwegs ist. Das ist ein Fehler in dem entsprechenden Paket / Programm und darf man (anscheinend) als Bug bezeichnen. (NICHT in openMittsu)!

apt-cache policy qtbase5-dev:

apt-cache policy qtbase5-dev
qtbase5-dev:
 Installiert:           5.15.3+dfsg-2ubuntu0.2
 Installationskandidat: 5.15.3+dfsg-2ubuntu0.2
 Versionstabelle:
*** 5.15.3+dfsg-2ubuntu0.2 500
       500 http://ftp.hosteurope.de/mirror/archive.ubuntu.com jammy-updates/universe amd64 Packages
       100 /var/lib/dpkg/status
    5.15.3+dfsg-2 500
       500 http://ftp.hosteurope.de/mirror/archive.ubuntu.com jammy/universe amd64 Packages

sudo find / -name 'libqsqlcipher.so':

sudo find / -name 'libqsqlcipher.so'
find: ‘/tmp/.mount_sessioXih30t’: Keine Berechtigung
find: ‘/run/user/1000/doc’: Keine Berechtigung
find: ‘/run/user/1000/gvfs’: Keine Berechtigung
/usr/lib/x86_64-linux-gnu/qt5/plugins/sqldrivers/libqsqlcipher.so
/home/oMPete/myBuildDir/qt5-sqlcipher/build/sqldrivers/libqsqlcipher.so

häh? wieso "Keine Berechtigung"? ich bin hier root. sudo ist ok. muss ich das in einer root-konsole ausführen? -das gefundene "myBuildDir" hab ich Gestern nach Deiner Anleitung erst angelegt. dubios.

apt-cache policy openmittsu (ff.):

apt-cache policy openmittsu
openmittsu:
 Installiert:           0.10.0plus10~focal
 Installationskandidat: 0.10.0plus10~focal
 Versionstabelle:
*** 0.10.0plus10~focal 100
       100 /var/lib/dpkg/status

apt-cache policy libqt5sql5-sqlcipher
libqt5sql5-sqlcipher:
 Installiert:           0.1.3~focal
 Installationskandidat: 0.1.3~focal
 Versionstabelle:
*** 0.1.3~focal 100
       100 /var/lib/dpkg/status
ARGH! ich hätte geschworen, dass es nicht installiert ist, weil ich immer nur das AppImage benutzt habe. Das muss von einem Test übrig geblieben sein, als ich den PC ursprünglich aufgesetzt hatte. 
BEIDES erfolgreich deinstalliert.
:~$ apt-cache policy libqt5sql5-sqlcipher
N: Paket libqt5sql5-sqlcipher kann nicht gefunden werden.
:~$ apt-cache policy openmittsu
N: Paket openmittsu kann nicht gefunden werden.

./qsqlcipher-test:

./qsqlcipher-test
Available QSqlDatabase driver: QSQLITE
Available QSqlDatabase driver: QSQLCIPHER
Running Task 1...
Running Task 2...
Running Task 3...
Running Task 4...
Running Task 5...
Running Task 5.1...
Hint: The next test might trigger a segfault when SQLCipher is linked against an incompatible version of OpenSSL or comes with the broken compatibility patch for OpenSSL 1.1.x.
Running Task 5.2...
Running Task 5.3...
Running Task 6...
Running Task 7...
Success! All tests completed.

Hä Hä Hä. War also DOCH in openMittsu. Das ist auch das Einzige, was ich nicht aus offiziellen Quellen installiert habe. Dazu hab ich ja extra Dein Repository zu den Quellen hinzugefügt. Das ist natürlich damit MEIN Fehler und KEIN BUG in openMittsu. Bin ich ja selber schuld.

Ich wär aber ums Verrecken nicht selber drauf gekommen. Vileen Dank für die Konsolenbefehle, genau danach hatte ich Gestern Abend - bis heute morgen um 5 - erfolglos gesucht.

Hurra! Damit hat das build geklappt. Es läuft auch, aber JETZT bekomme ich damit ganz genau denselben Fehler, den auch das AppImage produziert. Aber erstmal Vielen Dank für Deine Geduld & Mühe.

./openMittsu

Logging location: /home/oMPete/.local/share/openMittsu.log
[2025-03-02 13:55:46.040] [main] [warning] Could not connect to server. The error was: Remote Host (g-c0.0.threema.ch:5222) closed connection.
[2025-03-02 13:55:46.041] [main] [critical] Got no reply from server for AuthAck, we have 0 of 32 bytes available.
[2025-03-02 13:55:46.085] [main] [warning] Could not connect to server. The error was: Server did not reply after sending client authentication (invalid identity?).
[2025-03-02 13:55:46.099] [main] [warning] Could not connect to server. The error was: Remote Host (g-c0.0.threema.ch:5222) closed connection.
[2025-03-02 13:55:46.100] [main] [critical] Got no reply from server for AuthAck, we have 0 of 32 bytes available.
[2025-03-02 13:55:46.106] [main] [warning] Could not connect to server. The error was: Server did not reply after sending client authentication (invalid identity?).
[2025-03-02 13:55:46.158] [main] [warning] Could not connect to server. The error was: Remote Host (g-c0.0.threema.ch:5222) closed connection.
[2025-03-02 13:55:46.159] [main] [critical] Got no reply from server for AuthAck, we have 0 of 32 bytes available.
[2025-03-02 13:55:46.166] [main] [warning] Could not connect to server. The error was: Server did not reply after sending client authentication (invalid identity?).
[2025-03-02 13:55:46.217] [main] [critical] Got no reply from server for AuthAck, we have 0 of 32 bytes available.
[2025-03-02 13:55:46.217] [main] [warning] Could not connect to server. The error was: Remote Host (g-c0.0.threema.ch:5222) closed connection.
[2025-03-02 13:55:46.223] [main] [warning] Could not connect to server. The error was: Server did not reply after sending client authentication (invalid identity?).
QSqlDatabasePrivate::removeDatabase: connection 'openMittsuDatabaseConnection1740920141353' is still in use, all queries will cease to work.
QObject::killTimer: Timers cannot be stopped from another thread
QObject::~QObject: Timers cannot be stopped from another thread

Ich hab eine threema-Shop Lizenz für Android. Damit hat das immer funktioniert. Aktuell läuft threema bei mir in einer Android-VM. Dort habe ich ein frisches ID-Backup erstellt, dann die VM beendet. openMittsu gestartet, neue Datenbank vom ID-Backup erstellt. Beim Verbinden kommen dann die Fehler. Früher hat das mit dem ID-Backup immer funktioniert. Ich will damit fragen, ob der Server jetzt meine ID aus irgendeinem Grund nicht mehr akzeptiert, oder das doch an was Anderem liegt. ()

Hm.

Ich hab nochmal gründlich im Netz gesucht. Den Fehler kenne ich ja schon lange. Das Problem ist häufig und distributionsübergreifend. Gibt es schon seit Jahren und ich habe auch ziemlich aktuelle Meldungen dazu gefunden. In verschiedenen Zusammenhängen.

hier bei Arch und den verlinkten Seiten sieht es so aus, als ob das daran liegt, dass irgendein Paket ("buggy") VORHER eine Abhängigkeit mit QT5 (anscheinend verschiedene) installiert, wodurch dann die beiden unterschiedlichen Versionen aufeinanderknallen.

Dazu passt auch, dass es bei Dir unter einem frischen LM 21.3 (auf Ubuntu 22.04) funktioniert.

Es sei denn, es läge schon an Installationsoptionen von Linux MInt selber. Mein System ist LVM/LUKS vollverschlüsselt.

Es ist nicht sehr alt, vielleicht ein Jahr. Aber ich hatte denselben Fehler mit openMittsu auch auf allen anderen PCs vorher. Darum AppImage, das ging dann bisher immer. Jetzt irgendwie nciht mehr, wie's scheint.

Ich habe ziemlich viele Pakete installiert, würde das System aber als "sauber" bezeichnen, also nur aus den offiziellen Paketquellen, allerdings hab ich auch ne ganze Menge Flatpaks. Es muss im Zweifel ein Paket sein, was ich IMMER nachinstalliere, aber auch das sind nicht wenige.

Wie bekomme ich jetzt raus, wer da der Schuldige ist? Ich hab noch einen Backtrace mit strace & ltrace ausprobiert, werd aber nicht schlau draus.

Hätte den Backtrace angehangen, ist aber erheblich zu lang. 10.000 Zeichen Limit pro Post.

Jedenfalls wird das Problem wirklich unheimlich oft erwähnt. Scheint nicht so einfach zu sein mit QT.

Punkt 1&2 hab ich gemacht, hat auch geklappt, keine Fehler. Danach mit dem letzten AppImage getestet, dass Du hier verlinkt hattest.

Selbes Fehlerbild.

Dann hab ich den Code der Reihe nach ausgeführt (und mittlerweile auch langsam verstanden, was ich da so mache )

Ich kann ein wenig Code lesen und hier und da was scripten, bin aber eben doch eher ein GUI-Äffchen.

Jedenfalls ist es bis Punkt 9 fehlerfrei und sauber durchgelaufen und dann beim qsqlcipher-test unter Punkt 10 bekomme ich das hier:

./qsqlcipher-test
Available QSqlDatabase driver: QSQLCIPHER
Available QSqlDatabase driver: QSQLITE
Running Task 1...
Running Task 2...
Running Task 3...
Running Task 4...
Cannot mix incompatible Qt library (5.12.8) with this library (5.15.3)
Abgebrochen (Speicherabzug geschrieben)

Den kennen wir doch schon. An der Stelle hab ich dann abgebrochen, in der Annahme, dass der folgende build so keinen Sinn ergibt.

Zitat von LebenOhneHandy

ich würde gerne Threema nutzen, habe aber kein Handy/Smartphone. Bei meiner Recherche ist mir leider nicht klar geworden, ob das inzwischen möglich ist

Ja das geht, ich mache es schon seit 4 Jahren. Je nachdem, für welchen Weg Du Dich entscheidest, kann es aber ein ziemliches "Abenteuer" werden.

Was jetzt im Augenblick geht:

Möglichkeit 1: iOS - wurde hier schon erwähnt, aber ich erlaube mir mal, das genauer zu erklären, weil die ganze Nummer mit der Voraussetzung KEIN SMARTPHONE ziemlich komplex ist.

Methode 2: Das oben schon verlinkte openMittsu zu benutzen, was aber je nach Plattform im Augenblick ein paar Probleme hat.

Damit zu Methode 3. VMs

Und zum Schluss noch Methode 4. Emulatoren

5. Falls Du mit all dem nicht glückich wirst - die hardcore-Bastelei ist nicht Jedermanns Sache, kannst Du entweder warten. Je nachdem wie es mit der Version threema-DESKTOP 2.x weitergeht, könnte das in der Zukunft was werden. Standalone-Option auf PC wäre super und würde ich mir wünschen. Auch die nächste Variante, die dann immerhin mit Android verbunden werden kann, statt nur im iOS, wird es wohl schon besser machen. Oder wenn Du das alles gleich haben möchtest, dann guck Dir DAS mal an:

ich hoffe, das macht es um einiges klarer, was es momentan heißt, threema komplett ohne smartphone zu benutzen.

und damit hab ich fertig.

Zitat von holydiver

Wenn man bei der EU richtig ticken würde, würde man nun schleunigst sämtliche Anti-Verschlüsselungsvorhaben einstellen

Zusammen mit dem hier vorherigen Post, lernen wir daraus, dass die bei der EU ganz offensichtlich NICHT mehr richtig ticken.

Ist zwar keine ganz neue Erkenntnis, aber "quod erat demonstrandum" - was zu beweisen war.

Vollidioten.

Danke, Jana! Mitten in der Nacht...

Klappt leider immer noch nicht, exakt identisches Fehlerverhalten, daher lasse ich die Screenshots diesmal weg. Getestet mit dem neuen AppImage aus dem Link oben mit frischer Datenbank erstellt vom aktuellen ID-Backup. Sorry.

System:
Kernel: 5.15.0-133-generic x86_64 bits: 64 compiler: gcc v: 11.4.0 Desktop: Cinnamon 6.0.4
tk: GTK 3.24.33 wm: muffin vt: 7 dm: LightDM 1.30.0 Distro: Linux Mint 21.3 Virginia
base: Ubuntu 22.04 jammy

Zitat von ThE_-_BliZZarD

Qt braucht OpenSSL 1.1.1, ich vermute mal, dein System hat nur OpenSSL 3.0 oder 3.1

stimmt:
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

Ich vermute, dass die Schar der Benutzer von openMittsu leider ein eher kleines Häuflein ist und darunter noch weniger, die das unter einer Distribution nutzen, wo das AppImage nötig ist, weil sie es selber nicht kompilieren können (zu blöd, ich) bzw. wegen:

Zitat von oMPete

Cannot mix incompatible Qt library (5.12.8) with this library (5.15.3)

Wenn Du Dir am Ende die ganze Arbeit mit dem AppImage nur wegen mir machen solltest, würde ich Dir das gerne ersparen. Ich habe nach einigen Tagen ziemlich extremer Bastelei und Recherche für mich eine alternative Lösung gefunden, die gut funktioniert.

Zitat von ThE_-_BliZZarD

das AppImage... naja, sprechen wir nicht drüber.

Falls Du aber entschlossen sein solltest, das AppImage jetzt auch jeden Fall zum Fliegen zu bringen, mache ich definitiv mit und stehe für jegliche Art weiterer Tests bereit.

Hallo Jana,

der Test war leider nicht erfolgreich. Ich habe als erstes meine Installation ausprobiert, so wie sie war, nur mit dem neuen AppImage. Die Meldungen im Screenshot kamen allesamt gleichzeitig, nach der Eingabe des DB-Passworts. (Screenshots zur besseren Lesbarkeit in Spoilern):

Ich habe dann zunächste vermutet, dass es damit zusammenhängen könnte, dass ich threema zwischenzeitlich unter Android benutzt habe. Also meine Android-VM gestartet, threema und dann ein frisches ID-Backup gemacht. Threema beendet, VM beendet, damit es nicht zu doppelten Verbindungen zum Server kommt. openMittsu geöffnet und neue, leere DB vom ID-Backup erstellt. AppImage gestartet.

"OK" -> "Connect"

Das ganze nochmal von der Konsole gestartet, Konsolenausgaben komplett:

Und hier noch das Protokoll, ich hab die älteren Einträge mal dringelassen, die noch zu dem vorigen AppImage gehören, also vor 28.02.25:

Sieht ziemlich ähnlich aus. Sorry.