Comment 10 for bug 640689

OK, now on to the actual error. The error message "Stored username None and specified username kkissling mismatch." comes from an old implementation of Quickly's bzr_set_login:

    # if no bzr launchpad-login set, set it now !
    if launchpad_name:
        from bzrlib.plugins.launchpad import account
        stored_username = account.get_lp_login()
        if stored_username is not None:
            # No account set yet
            launchpad_name = launchpad_name.lower()
            account.check_lp_login(launchpad_name)
            account.set_lp_login(launchpad_name)
        elif stored_username != launchpad_name:
            return (1,
                _("Stored username %s and specified username %s mismatch." % (
                    stored_username, launchpad_name)))

This code was just reverted (rev 540, on September 28, "Merge bzr internal API use reverts"), and the current implementation invokes bzr shell commands.

I've never seen this code before, but it looks wrong, in a way that would explain why it was reverted and why this problem is happening. It seems like that if statement ought to be "if stored_username is None", not "if stored_username is not None". With the code as it is, if you've never set your bzr Launchpad login name, you'll get an error that None doesn't match the login name you want to set.

But, that code is only run in an except clause, when something goes wrong creating the Launchpad object. Why is it going wrong every time? This could be a problem with launchpadlib, a problem with the Launchpad server itself, or a problem with the Quickly code that reads the credentials file. (This is why I suggested that switching to login_with() might solve the problem.) Whatever it is, getting a new credential doesn't solve the problem, and so the next time the user starts up Quickly, the exception happens again and they have to get *another* credential. And because of the 'if stored_username is not None' problem, Quickly exits before the user can do anything.

To find out exactly what the problem is, hack the code to re-raise the underlying error:

except (IOError, HTTPError), e:
    raise e
    if interactive:
        ...