I recently notice that after doing an upgrade and rebooting Artix Linux the shortcuts to launch applications/programs for some reason it's taking like 15-20 seconds to launch terminal or any other program, but it doesn't seem to be affecting shortcuts for: closing windows, volume up/down, resizing windows, etc.
What could the problem be? I'm running Artix Linux with Cinnamon DE and runit.
Same here; most annoying bug ever.
Did a fresh install. Resolved the issue. Then I installed base-devel. Brought the issue back again.
I too use Cinnamon. This is not a Cinnamon issue.
Same to me. I have Mate, icons appear on my desktop after 15-20s on start, some apps like Liferea, Schildichat etc take huge time to open or connect...
It's not happening at all in Mate for me. I suggest checking your logs for associated errors during this bug and try and identify the package which was upgraded that caused this if you wished to narrow down the cause and possibly arrive at a faster resolution of the issue, I don't see any similar topics on the Arch forums.
I think it's xdg-desktop-portal, xdg-desktop-portal-gtk related...
https://linux.debian.bugs.dist.narkive.com/HHOR5FI9/bug-994865-delayed-start-due-to-pipewire-not-running
https://old.reddit.com/r/swaywm/comments/ptwd6p/thunar_and_xdgdesktopportal_block_each_other/
Uninstalled xdg-desktop-portal, xdg-desktop-portal-gtk and now icons appear with no lag on desktop but Liferea takes minutes to start and Schildichat connects but slowly.
Yep, it's related to gnome-keyring
Traceback (most recent call last):
File "/usr/lib/liferea/plugins/gnome-keyring.py", line 54, in do_query
coll = self.get_collection()
File "/usr/lib/liferea/plugins/gnome-keyring.py", line 43, in get_collection
service = Secret.Service.get_sync(Secret.ServiceFlags.LOAD_COLLECTIONS, None)
gi.repository.GLib.Error: g-io-error-quark: Eroare la apelul StartServiceByName pentru org.freedesktop.secrets: Limita de timp a fost atinsă (24)
Yep, uninstalled gnome-keyring and Liferea starts instantly...
I have been tinkering with gnome-keyring-daemon for some time. After reading your post I removed gnome-keyring entirely as well and voila.
Curious what you fine folks are using as an alternative to gnome-keyring for the time being?
Waiting for this issue to be remedied, using secret-tool directly, or have an alternative?
All the best,
some anon
gnome-keyring is the GNOME alternative to pass: https://www.passwordstore.org/
I'm using pass together with passmenu: https://git.zx2c4.com/password-store/tree/contrib/dmenu
For certificate and key management I'm using GnuPG:
https://www.gnupg.org/
https://wiki.archlinux.org/title/GnuPG
I wasn't aware that I can have pass store my SSH key password and USB passwords for their sessions. I'll have to investigate further. To think I've been using pass all these years not knowing this and continuing to use gnome-keyring to leverage libsecret is bewildering. There's just too much software to know all the ins-and-outs, let alone keep up with it all.
pass can store any text, much like Bitwarden. You can even migrate data from Bitwarden to pass. Whether you should store passphrases to decrypt your SSH keys is another matter (you shouldn't).
Na, pass cannot do what I was asking about. All good.
I'm talking about session passwords. SSH in particular. LUKS can be forgotten straight away.
Running an local-to-remote rsync backup script would trigger multiple requests to enter the SSH password.
SSH password should be stored until logout for efficiency. Perhaps if I bash/zsh pull the password from pass, and have GPG store the session for X minutes. Actually that would be easy to do and worthwhile. Still not efficient when connecting to countless remote servers and needing to constantly unlock the SSH key with its passphrase however.
Trying to teach me about pass... Shameful. Still love you though .
; ]
@topic: See if this solves your problem: https://forum.artixlinux.org/index.php/topic,3091.msg20215.html#msg20215
Update your system, you should have no issues.
You asked this:
This implies you not knowing what the "alternatives" (from a GNOME-centric point of view) are, and are asking what to use instead of gnome-keyring. I gave an answer: pass
and GnuPG. I don't use GNOME. I have zero GNOME components on my system, and yet I not only use SSH on a daily basis, but also SFTP, using gpg-agent and pinentry-tty on a bare X.Org system, through a getty login, using dwm + st. And that is rock solid - it never stopped working, unlike gnome-keyring.
This only shows the impracticality of bloated software like GNOME.
If you care about security that much, you should know that storing anything in memory for a prolonged period of time is a security risk. But that is a compromise one decides upon - to have
comfort of not having to enter passphrases constantly, or to have a
greater degree of security. That said, gpg-agent does that. You either don't know that, or are trolling.
What I use is simply not use gnome-keyring, but then I don't do much with ssh except recently moved some things between computers with sftp. This may not be a helpful alternative if you are using it of course, but there is a reason for my avoidance of gnome-keyring wherever possible. Historically there was a longstanding annoying bug where Chromium would give errors because it would try to use gnome-keyring-daemon except it was not properly initialized if you didn't have the full Gnome desktop installed, so you had to rename /usr/bin/gnome-keyring-daemon, and it was often installed as a dependency for something else that used the libs that also were part of the package which meant it couldn't be uninstalled. So possibly it would work better if the full Gnome desktop was installed, I notice that Cinnamon and Mate are mentioned here, but this is only speculation as I don't have the problem in the first place.