Mattias Eriksson

No, the cosmic-notifications errors seems to be a red herring. I added some basic retry logic to cosmic-notifications, but that didn't change anything. Now, in my logs I do not...

But I'm not using any client certificate.

I realize I had forgotten about this issue. Thanks for the feedback, I will have another go and investigate the certificate chains.

Not able to reproduce exactly, but it looks like it was the native roots that got me. Closing

I guess it need to listen to a ext_idle_notification_v1::Event::Resumed event, and update the time.

I created a small fix here, to add ssh-agent at the bottom of the stack, like we used to do back in the 90:s https://github.com/pop-os/cosmic-session/pull/48 That way you only have...

It sounds like a good idea, and if we are happy to keep ssh separate from the keyring, then it will probably simply the implementation. But one thing to think...

Since the solution is easy by just providing the --password-store="gnome-libsecret" on the command line with the preferred storage, I don't understand why you just don't create a wrapper script that...

Also, note that the Appimage will overwrite the tutanota-desktop.desktop file at every upgrade, and hence break any fix by the user... so this is kind of an annoying issue.

No, that is the "perfect" solution that I refer to, and I know you do that, but that doesn't seem to work. So I suggest a shell script `tutanota.sh` that...