I haven't seen this particular behavior before. Similar server (i.e.,
non-desktop) scenarios were brought up in bug 686690 and addressed in
launchpadlib 1.9.0 and later.
The keyring library has difficulties with keyring/wallet backends that
appear to be available but when used do not work. That seems to be the
class of defect being experienced here.
A version of Martin's suggestion is the best I can come up with at the
moment: Change keyringlib such that it will not consider the GNOME and
KDE backends to be available unless DISPLAY is set.
A temporary workaround would be to specify file-based token storage by
creating a ~/keyringrc.cfg file with these contents:
A tangential note: for non-interactive use (e.g., cron jobs) you should
use the credentials_file="/path/to/file" argument. In this case you'll
still get the same error unless you force a non-GUI keyring backend.
Once the credential file exists (and is valid), no further keyring
access will be attempted.
I haven't seen this particular behavior before. Similar server (i.e.,
non-desktop) scenarios were brought up in bug 686690 and addressed in
launchpadlib 1.9.0 and later.
The keyring library has difficulties with keyring/wallet backends that
appear to be available but when used do not work. That seems to be the
class of defect being experienced here.
A version of Martin's suggestion is the best I can come up with at the
moment: Change keyringlib such that it will not consider the GNOME and
KDE backends to be available unless DISPLAY is set.
A temporary workaround would be to specify file-based token storage by
creating a ~/keyringrc.cfg file with these contents:
[backend] keyring= keyring. backend. UncryptedFileKe yring
default-
A tangential note: for non-interactive use (e.g., cron jobs) you should file="/ path/to/ file" argument. In this case you'll
use the credentials_
still get the same error unless you force a non-GUI keyring backend.
Once the credential file exists (and is valid), no further keyring
access will be attempted.