Kwallet: Support KF5

[Thaodan]

As the title says please support KF5 Kwallet

[mitya57]

Unfortunately PyKDE5 doesn't yet have KWallet bindings, thus we can't port it yet.

[jaraco]

I'm closing this as wontfix for now. At such a time that a solution is possible, feel free to revive the conversation.

[phlinx]

Hi. Due to this issue with backintime in archlinux (bit-team/backintime#545) I can confirm that the patch proposed by Germar in the according Archlinux bug (https://bugs.archlinux.org/task/48380) works (I adapted it to be applied to the sourcecode directly):

--- a/keyring/backends/kwallet.py   2016-02-04 16:56:03.000000000 +0100
+++ b/keyring/backends/kwallet.py   2016-03-02 10:31:09.234734254 +0100
@@ -24,9 +24,9 @@
         except dbus.DBusException as exc:
             raise RuntimeError(exc.get_dbus_message())
         try:
-            bus.get_object('org.kde.kwalletd', '/modules/kwalletd')
+            bus.get_object('org.kde.kwalletd5', '/modules/kwalletd5')
         except dbus.DBusException:
-            raise RuntimeError('cannot connect to org.kde.kwalletd')
+            raise RuntimeError('cannot connect to org.kde.kwalletd5')
         return 5.1

     def __init__(self, *arg, **kw):
@@ -41,7 +41,7 @@
         self.folder = 'Python'
         self.appid = 'Python program'
         try:
-            remote_obj = bus.get_object('org.kde.kwalletd', '/modules/kwalletd')
+            remote_obj = bus.get_object('org.kde.kwalletd5', '/modules/kwalletd5')
             self.iface = dbus.Interface(remote_obj, 'org.kde.KWallet')
             self.handle = self.iface.open(
                         self.iface.networkWallet(), wId, self.appid)

[jaraco]

@hefeweiz3n, The patch seems pretty straightforward, mainly replacing kwalletd with kwalletd5. I'm not familiar with kwallet, but that change strikes me as likely to cause problems on existing systems that may only have kwalletd. What would you expect to happen for those users?

[phlinx]

My Guess is (can't test since Arch dropped kwallet4 a while ago) that it would stop working. So the cleaner approach might be to write a second backend for kwallet5 with those changes. Seems straightforward according to the docs, so I'll try that. Is there a way to specify an order in which the backends are tried? e.g. kwallet5 should be tried first, then kwallet(4).

[Thaodan]

But why this behaviour? At least when kde sc 4 support ends it should be fine to support only kframeworks. An other would be to use the path for the version that kde tells us via the environment or dbus.

Am 2. März 2016 17:28:04 MEZ, schrieb hefeweiz3n notifications@github.com:

My Guess is (can't test since Arch dropped kwallet4 a while ago) that
it would stop working. So the cleaner approach might be to write a
second backend for kwallet5 with those changes. Seems straightforward
according to the docs, so I'll try that. Is there a way to specify an
order in which the backends are tried? e.g. kwallet5 should be tried
first, then kwallet(4).

---

Reply to this email directly or view it on GitHub:
#168 (comment)

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[mitya57]

I don't think old kwalletd is worth supporting, especially when we already have one backend for it (in keyrings.alt). In Debian testing (and Kubuntu) old kwallet has been removed and only kwallet5 is available. So 👍 for the patch from @hefeweiz3n's comment.

[jaraco]

Okay. Sounds good to me.