staging.inyokaproject.org

Archiv/KDE Passwortspeicher

Status: Ungelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |
Dieses Thema ist die Diskussion des Artikels Archiv/KDE_Passwortspeicher.

noisefloor Team-Icon

(Themenstarter)

Anmeldungsdatum:
6. Juni 2006

Beiträge: 29567

Hallo,

Ändern wir dann auch den Wiki-Artikelnamen?

Done. KDE Brieftasche ist jetzt ein Redirect auf KDE Passwortspeicher.

Aber: im Artikel kommt noch 41x (!) der Begriff "KDE Brieftasche" vor. Bitte durch gehend auf "KDE Passwortspeicher" ändern. Da hatte ich gerade so gar keine Lust zu... Die Einleitung ist angepasst.

Gruß, noisefloor

Cruiz Team-Icon

Avatar von Cruiz

Anmeldungsdatum:
6. März 2014

Beiträge: 5557

Hallo,

Danke! Die Wortersetzung ist erledigt.

Gruß,
Cruiz

droeben

Anmeldungsdatum:
7. September 2013

Beiträge: 55

Hallo,

momentan experimentiere ich mit Plasma5, um mich auf den Umstieg von 14.04 vorzubereiten. Dabei ist mir aufgefallen, dass man digitale Brieftaschen aus KDE4 Zeiten anscheinend nicht in Plasma5 öffnen kann (hab es unter Kubuntu 16.04 und Opensuse getestet und hatte beide Male keinen Erfolg). Wenn ich diesen Blogeintrag vom KWallet-Betreuer richtig verstehe, sind kwallet4 und kwallet5 inkompatibel und könne folglich nicht einfach übertragen werden?

Den im Blogeintrag erwähnten Migrationsassistenten habe ich leider auch nicht finden können. Statt dessen wird anscheinend empfohlen die Passwörter aus kwallet4 zu exportieren (ich denke wohl als XML wie es kwallet anbietet) und dann wieder nach kwallet5 zu importieren?

Lange Rede kurzer Sinn: Wenn das jemand so bestätigen kann, dann würde ich den Artikel um einen Abschnitt bzgl. kwallet4 und kwallet5 (wenn die Diktion so richtig ist, bei KDE weiß man ja nie) ergänzen.

droeben

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Hallo!

Der Artikel wurde nun für groovy angepasst, sollte™ auch in focal so stimmen, ich kann es aber nicht selbst testen und habe daher nur ersteres eingetragen.

frustschieber Team-Icon

Ehemalige
Avatar von frustschieber

Anmeldungsdatum:
4. Januar 2007

Beiträge: 4259

Ohne Groovy jetzt ungetestet.

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

frustschieber schrieb:

Ohne Groovy jetzt ungetestet.

Wie lange bleibt der noch, bis er archiviert wird? Ich habe gerade kein aktuelles, sauberes Kubuntu und ich mutmaße mal, das meine Selbstbau-Frickelversionen nicht zählen 😀

noisefloor Team-Icon

(Themenstarter)

Anmeldungsdatum:
6. Juni 2006

Beiträge: 29567

Hallo,

ungetestete Artikel bleiben so ca. 5-6 Monate im Wiki, bevor sie ins Archiv gehen.

Gruß, noisefloor

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

noisefloor schrieb:

ungetestete Artikel bleiben so ca. 5-6 Monate im Wiki, bevor sie ins Archiv gehen.

So ungefähr hatte ich das auch im Kopf. Sollte aber passen. Wenn meine Planung nicht wieder durch irgendwelche Hochwasser oder Explosionen durcheinandergebracht werden, hab ich in nem guten Monat Zeit mir ein natives Kubuntu zu installieren und um diese Artikel zu kümmern.

noisefloor Team-Icon

(Themenstarter)

Anmeldungsdatum:
6. Juni 2006

Beiträge: 29567

Uuuuuund...? Stand der Dinge? Oder gab es doch eine Explosion?

Gruß, noisefloor

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Tatsächlich „nur“ zwei Brände mit dem üblichen „Fenster geschlossen halten“, also nichts unübliches.

Was Kubuntu angeht: Selbst das Grundsystem funktioniert nicht. Ich bezweifle auch, dass sich das noch mal ändert. Mittlerweile kommen ja nicht mal mehr grundlegende Stabilisierungen ins Plasma. Insofern tue ich mir etwas schwer mit dem Testen. Alles auf Qt-Basis „flackert“ ständig und die Oberfläche neigt ohne Anpassungen schon zu Abstürzen. Ich habe mich mal auf 22.04 vertröstet, habe aber wenig Hoffnung, wenn ich ehrlich bin.

Mit 20.04 testen lohnt auch nicht, das ist schon EOL, 21.10 kurz davor.

noisefloor Team-Icon

(Themenstarter)

Anmeldungsdatum:
6. Juni 2006

Beiträge: 29567

Ok, Danke für die Rückmeldung. Falls es mal besser werden sollte: die Archivierung ist ja reversible.

Gruß, noisefloor

noisefloor Team-Icon

(Themenstarter)

Anmeldungsdatum:
6. Juni 2006

Beiträge: 29567

Und archiviert.

Interessanter Weise war der Artikel nirgendwo verlinkt.

Gruß, noisefloor

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Ja, wie schon mal an anderer Stelle erwähnt (glaube ich) würde ich was Qt/KDE angeht möglichst wartungsarme Artikel bevorzugen oder tatsächlich alles archivieren was < 21.10 ist. Ich weiß nur gerade auch nicht, ob das auf debianoiden überhaupt eine nutzbare Zukunft hat, da gibt es ja „schon immer“ Probleme. Ubuntu macht es sich da einfach und klatscht einfach alles nach universe, Debian versucht dann selbst zu maintainen, was seit dem Wechsel auf Qt5 auch eher unschön lief. Das gehört allerdings weniger zu speziell diesem Artikel, denn zu allen. Kubuntu ist dann ja auch durch die GTK-Standard-Anwendungen zudem ein Exot.

Wäre wohl eher eine Fragestellung fürs Wiki-Team? Ich kann gerade nur sagen, das Kubuntu nicht auf meinem modernen Laptop als lauffähig bezeichnet werden kann.

noisefloor Team-Icon

(Themenstarter)

Anmeldungsdatum:
6. Juni 2006

Beiträge: 29567

Hallo,

die nächste Archivierungswelle wird IMHO mit dem EOL von 18.04 kommen. Bzw. genau genommen ist Kubuntu 18.04 ja EOL. Nur machen wir im Wiki da ja keinen Unterschied.

Kubuntu ist dann ja auch durch die GTK-Standard-Anwendungen zudem ein Exot.

Wieso? Die Schnittmenge der Standardanwendungen ist doch auch unter den GTK-basierten *buntus eher gering. Plus mit Lubuntu + LXQt gibt es ein Derivat, was auch auf Qt setzt. Was da eher im Weg steht sind mögliche KDE-Abhängigkeiten. Wenn ich bei mir unter Ubuntu Dolphin installieren wollte, bräuchte es etliche 181 Paket und ~171 MB auf der SSD.

Gruß, noisefloor

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

noisefloor schrieb:

die nächste Archivierungswelle wird IMHO mit dem EOL von 18.04 kommen. Bzw. genau genommen ist Kubuntu 18.04 ja EOL.

20.04 auch, da das mitgelieferte Qt EOL ist und nicht gepflegt wird (0 Backports, 6 Updates seit Release).

Kubuntu ist dann ja auch durch die GTK-Standard-Anwendungen zudem ein Exot.

Wieso? Die Schnittmenge der Standardanwendungen ist doch auch unter den GTK-basierten *buntus eher gering.

Na, da kommt Firefox, Thunderbird anstatt der nativen Anwendungen zum Einsatz, zudem noch ein paar Dinge „unter der Haube“ wie der icon-cache aus der GTK-Welt. Das ist alles logisch, da Ubuntu ausschließlich (Basis-)Pakete von GTK unterstützt, aber kein „echtes“ Plasma. Die Integration von GTK in Qt-Umgebungen ist mittlerweile richtig gut geworden, aber es sind nach wie vor zwei unterschiedliche Ansätze. Ich stoße bspw. oftmals bei freedesktop-Standards auf Probleme, da sich GTK nicht dran hält (war auch schon immer so und ist kein Negativpunkt, es ist nur eine Stelle an der es öfter knirscht). Dazu kommt, das auch Plasma sehr eingeschränkt kompiliert wird, da eben die aktuellen Qt-Pakete alle nicht vorhanden sind.

Plus mit Lubuntu + LXQt gibt es ein Derivat, was auch auf Qt setzt.

Das macht das Ausliefern von EOL-Paketen nicht besser 😉 Betrifft ja auch VLC, VirtualBox, usw.

Was da eher im Weg steht sind mögliche KDE-Abhängigkeiten. Wenn ich bei mir unter Ubuntu Dolphin installieren wollte, bräuchte es etliche 181 Paket und ~171 MB auf der SSD.

Dolphin ist auch ein Parade-Beispiel. Das braucht ja auch alles grundlegende aus Qt/KF und Plasma, inkl. Netzwerkkram. Falkon hat bspw. 0 Abhängigkeiten zu KF5, lediglich optional. Krusader, als nicht-Desktopumgebungs-Dateiemanager braucht lediglich kparts als Abhängigkeit. KMail/Kontact hingegen verlangt natürlich wieder den kompletten Unterbau.

Ändert nichts an der grundlegenden Problematik von Qt-Paketen unter Ubuntu. Außer Ubuntu selbst und Xubuntu nutzen auch alle Derivate Qt. Scheint aber keinen so richtig zu stören — und verständlicherweise hat auch keiner von denen Lust Qt selbst zu pflegen und für die anderen die Pakete neu gegenzukompilieren. Es gibt zwar die Möglichkeit verschiedene Qt-Versionen parallel zu betreiben, aber das scheint auch niemand zu nutzen, zumindest bei meinen letzten Versuchen nicht.