Description of problem: with latest update evolution stopped to remember passwords Version-Release number of selected component (if applicable): $ rpm -qa | grep evolution evolution-bogofilter-3.8.5-2.fc19.x86_64 evolution-data-server-3.8.5-4.fc19.x86_64 evolution-help-3.8.5-2.fc19.noarch evolution-3.8.5-2.fc19.x86_64 evolution-ews-3.8.5-1.fc19.x86_64 How reproducible: happened on two machines Steps to Reproduce: 1. Run evolution 2. Evolution will ask about a password although one is already stored, but enter your password 3. Close evolution 4. Open evolution Actual results: Evolution will ask about the password. Also, looking at stored passwords with seahorse - newly created app-specific passowrd for google account was not stored in keyring. Expected results: Evolution to use password stored in keyring! Additional info: $ ps -aux | grep gnome-keyring marek 1735 0.0 0.0 619324 3700 ? Sl 09:26 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login Note, I am using application specific passwords -- it's a hassle to update the password as I need to log in to the google account and create a new one. Also, the modal window asking for password should lock just an application! not the whole desktop! Email password is not Desktop's password, just an application password, so no reason to block user's access to the desktop.
Thanks for a bug report. The evolution-source-registry is responsible for password management, it uses libsecret API, thus if anything breaks there, then the password read/write fails. Usually restart of the evolution-source-registry helps, especially after update it's better to restart all background evolution* processes. It can be tricky under gnome-shell, which restarts calendar factory, which makes sure the evolution-source-registry is running. Try to run evolution-source-registry from console like this: $ GCR_DEBUG=all /usr/libexec/evolution-source-registry and it'll print debug information from gnome-keyring too (the process is quite chatty on its own too). If you use gnome-shell, then I would kill all evolution-* processes except calendar factory, then run the source registry as above and then kill the old calendar factory, when the gnome-shell will start new instance of the calendar factory for you.
It looks like, it's fixed. Not sure what was the reason, somehow it got fixed with the latest update. Closing as "current release".