user/stream configuration is deleted when keyring unlocking is unsuccessful

Thanks, I'm aware of this issue. The next version will be much more forgiving with respect to keyring issues.

After update to Debian testing, not even the passphrase dialog is shown, it directly jumps to "add a new account" dialog. Any pointers how to debug this?

$ apt-cache policy polly python-keyring python-gnomekeyring gnome-keyring
polly:
  Installed: 0.93.10-0~416~saucy1
  Candidate: 0.93.10-0~416~saucy1
  Version table:
 *** 0.93.10-0~416~saucy1 0
        500 http://ppa.launchpad.net/conscioususer/polly-daily/ubuntu/ saucy/main amd64 Packages
        100 /var/lib/dpkg/status
python-keyring:
  Installed: 0.9.3-1
  Candidate: 0.9.3-1
  Version table:
     1.6-1 0
          1 http://ftp2.de.debian.org/debian/ sid/main amd64 Packages
 *** 0.9.3-1 0
        500 http://debian.tu-bs.de/debian/ testing/main amd64 Packages
        100 /var/lib/dpkg/status
python-gnomekeyring:
  Installed: 2.32.0+dfsg-3
  Candidate: 2.32.0+dfsg-3
  Version table:
 *** 2.32.0+dfsg-3 0
        500 http://debian.tu-bs.de/debian/ testing/main amd64 Packages
          1 http://ftp2.de.debian.org/debian/ sid/main amd64 Packages
        100 /var/lib/dpkg/status
gnome-keyring:
  Installed: 3.8.2-2
  Candidate: 3.8.2-2
  Version table:
 *** 3.8.2-2 0
        500 http://debian.tu-bs.de/debian/ testing/main amd64 Packages
          1 http://ftp2.de.debian.org/debian/ sid/main amd64 Packages
        100 /var/lib/dpkg/status

The issue is likely to be on python-keyring, so probably there isn't much that can be done from Polly.

For the record: python-keyring does not use python-gnomekeyring at all, instead I was missing the gir1.2-gnomekeyring-1.0 package. Additionally, gnome-keyring-daemon needs to be started at login, otherwise python-keyring falls back to its default backend and asks for the password on stdin.

Okay, this did not work every time. Apparently, python-keyring is buggy when it some to determining the default keyring (see https://bitbucket.org/kang/python-keyring-lib/issue/96/default-backend-sort-order-is-not), which resulted in Polly loading secrets sometimes from Gnome keyring, sometimes from the file backend... -.-

A a workaround, I created the file .local/share/python_keyring/keyringrc.cfg with this content:

[backend]
default-keyring = keyring.backend.Gnome.Keyring

I have patched /usr/bin/polly so that it prints the currently used keyring backend, and it really uses Gnome keyring now. However, Polly won't start anymore after this change, and dies with a backtrace:

current keyring is:
<keyring.backends.Gnome.Keyring object at 0x7fe9fdc9da10>
Traceback (most recent call last):
  File "/usr/bin/polly", line 330, in <module>
    account_manager = gui.twitter.account.Manager(NAME, config_path, config_path_lock, setting_factory, proxy_controller, font_scheme, identifier_factory, status_bar)
  File "/usr/lib/python2.7/dist-packages/polly/gui/twitter/account.py", line 489, in __init__
    subtoken_secret = keyring.get_password(self.name, subtoken)
  File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 36, in get_password
    return _keyring_backend.get_password(service_name, username)
  File "/usr/lib/python2.7/dist-packages/keyring/backends/Gnome.py", line 53, in get_password
    items = self._find_passwords(service, username)
  File "/usr/lib/python2.7/dist-packages/keyring/backends/Gnome.py", line 30, in _find_passwords
    from gi.repository import GnomeKeyring
  File "/usr/lib/python2.7/dist-packages/gi/__init__.py", line 27, in <module>
    from ._gi import _API, Repository
ImportError: cannot import name _API

I guess this is related to the fact that Polly is not yet ported to GObject Introspection and uses modules that are incompatible with GI, but the underlying python-keyring implementation uses introspection. I currently cannot downgrade to a previous version of python-keyring (the only version in Debian testing is 1.6), so I guess, I have to find a different Twitter client :-(

But why is the Debian package version relevant? Can't you simply download and locally extract a python-keyring tarball, of whatever version you want, and start Polly with PYTHONPATH pointing to it?

Same/Similar problem startd to bite me (debian testing/sid) just recently. I have to randomly(?) readd my accounts after suspend/resume/restart. To me it seems like polly (or the lib it's using) has recently changed into using kwalletmanager for storing secret data, and fails somewhere in beetween.

I am not sure if this is anything to do with the keyring, I was trying to set up a proxy server configuration and shutting it down after seeing the curl errors deleted the accounts promptly - which is rather unhelpful. :)

It is repeatable for me.

Polly 0.93.11 (pre-alpha 3.11)
Copyright (C) 2011 Marcelo Hashimoto
cache path: /home/hakan/.cache/polly
config path: /home/hakan/.config/polly
data home: /home/hakan/.local/share/polly
initializing... done
DEBUG: account1 disconnected because of curl error 28
DEBUG: account1 will reconnect in 0.25 seconds
DEBUG: account2 disconnected because of curl error 28
DEBUG: account2 will reconnect in 0.25 seconds
DEBUG: account3 disconnected because of curl error 28
DEBUG: account3 will reconnect in 0.25 seconds
DEBUG: account2 connected successfully
DEBUG: account3 connected successfully
DEBUG: account1 connected successfully
DEBUG: account1 disconnected successfully
DEBUG: account2 disconnected successfully
DEBUG: account3 disconnected successfully
finalizing... DEBUG: ACCOUNT DELETED
DEBUG: ACCOUNT DELETED
DEBUG: ACCOUNT DELETED
done
clearing... done
Thank you for using Polly!
To contribute please visit https://launchpad.net/polly.

I've just upgraded to Ubuntu 13.10 from 13.04, it seems Polly updated to Polly 0.93.11 (pre-alpha 3.11) from the previous version and lost the account settings, similarly to the other reports.

I don't use a proxy, or a password-protected keyring.

The "In Progress" status indicates that the issue is already acknowledged and being worked on. Please do not post comments just to say you are also having the issue.

Is this the same as bug 1154870, which describes an almost identical issue but hasn't been closed as a duplicate?

No, it's not. The comments went off-topic, but the original report describes a different issue.