Indeed. This is critical, as it renders GAIM quite useless if you have a lot of accounts on several networks or with several identities (in my case, it pops up seven password request windows all over the desktop...)

I compiled the latest gaim (1.5.0b2) downloaded yesterday and the problem is not there anymore

To the original reporter: Is it really beta7.

Gaim has a patches to store its passwords in gnome-keyring. Do you have installed it? Does installing of it help?

Yes, that's really Beta7 (in my case an update from 10.0) No, I haven't installed gnome-keyring. In fact, I don't run the Gnome desktop. So, if Gaim is supposed to use gnome-keyring, either let it complain about missing gnome-keyring with an info box, or (better) let it fall back to its upstream behaviour.

Gaim requires gnome-keyring already:

jpr@zugzwang:~/Desktop> rpm -q --requires gaim | grep key
libgnome-keyring.so.0

So it should be installed.

HPJ, what if its not running?

In GNOME, gnome-keyring gets started by gnome-session. I could write a patch to libgnome-keyring to start it up if it isn't running, I guess.

I don't think that would be the right way (starting applications if you need it or not). I second Jörgs suggestion to have a fallback to old behavior if Gnome desktop is not running.

OK, I think the problem is that in converting from the old .gaimrc password code to the new gnome-keyring-manager code, the "Remember password" setting got turned off for all of the accounts. Holger, if you open the GAIM Accounts window, select an account, and click "Modify", is the checkbox checked? If not, just check it, and then it should remember the password in the future.

I tried that several times. At last with Beta 8. Gaim will not keep the password, no matter if I check the box or not. When restarting Gaim the "remeber password" box is never checked.

Now this is getting interesting.

If we want users to be able to run applications like GAIM or nm-applet or whatever $APPLICATION using gnome-keyring-daemon in order to store secrets we run into this bug.

As long as g-k-d is not launched with the X session, GNOME_KEYRING_SOCKET will not be set and, hence, the applications will fail to identify a running instance of g-k-d.

An insane workaround is launching g-k-d and setting the environment variable upon start of each application using g-k-d if GNOME_KEYRING_SOCKET is not set. (This is actually what I have done for KNetworkManager to use the g-k-d, see bug #156366)

The correct solution would be launching g-k-d with the X session -- the same what we do for GNOME.  But how can we know whether a user actually makes use of it? e.g. does he/she use any of the depending applications at all?

JFYI, Holger was able to use GAIM + password storage after running

  $ export `gnome-keyring-daemon`
  $ gaim

Comment #10 refers to running applications depending on g-k-d in all X sessions (KDE, *box, ...) but GNOME.

(hpj: JP said I should take this because you have too many bugs assigned to you.)

fixed in autobuild; now if gnome-keyring-manager isn't running, it will just
fall back to the old gaim password storage code

oops, fixed

*** Bug 150099 has been marked as a duplicate of this bug. ***

The problem is: you should not just test if gnome-keyring-manager is installed but if it's running.

Holger: that's what we do. If gnome-keyring-manager is running, we use it. If not, we use gaim's old system. Are you seeing some problem?

Oh, if you switch back and forth between GNOME and KDE, you'll run into problems, because the gnome-keyring code removes the passwords from gaim's config files (so they're not stored unencrypted there). So every time you log into GNOME, you'd need to re-enter your password next time you log into KDE. Is that what you're seeing? Or something else?

Sorry, my mistake. Finally I found all buttons I had to check to keep the password.
I'm neither using Gnome nor KDE, just Openbox.