Locks acquired via the smart protocol have poor lock info.

A possible alternative solution for bzr+ssh://bazaar.launchpad.net/ specifically would be to teach that server to use the username (or user id) from the SSH authentication rather than "supermirror@vostok" when generating a lock info file. This might be a good idea anyway, for dealing gracefully with older clients that don't have this fix.

Is this a duplicate of bug #125420 (or vice versa)?

jml and thumper to look at during the Oct sprint

I guess they are related. For bug 125420, we can improve matters in the short term by setting $BZR_EMAIL which probably clears up the confusion problem mentioned there.

That said, it would be good to get this problem properly fixed so that the client can send lock info, which is what this bug is about.

We are able to set the launchpad codehosting service to show "<email address hidden>" instead of "supermirror@vostok". While it isn't ideal, it is better.

I think writing "${lpuser}@bazaar.launchpad.net" in the lock would be confusing.

Normally, the bzr committer id includes a REAL user-provided email address that can be used to contact a human. We should not generate fake email addresses like this.

We should use the "${user.displayname} <${user.prefferred_email}>" if the email is public to authed users on the website, or use "${user.displayname] (${user.name})" or, if it exists, use some @launchpad.net email alias that redirects to the preferred of the user.

Keeping the bug open and pushing out until a complete solution is available.

I understand (after talking with thumper) that this is related: a push to launchpad got interrupted (dropped connection) and the message after that was

$ bzr push
Using saved push location: bzr+ssh://<email address hidden>/~chipaca/xyzzy/blah
Unable to obtain lock lp-46717904:///~chipaca/xyzzy/blah/.bzr/branch/lock
held by <email address hidden> on host crowberry [process #10729]
locked 9 hours, 30 minutes ago
Will continue to try until 11:36:49, unless you press Ctrl-C
If you're sure that it's not being modified, use bzr break-lock lp-46717904:///~chipaca/xyzzy/blah/.bzr/branch/lock
bzr: ERROR: Could not acquire lock "(remote lock)"

doing bzr break lock lp-46717904:///... didn't work; I had to remove both the -<number> and the ///.

This isn't really in progress anymore.

Bug 128824 has the same root cause: we don't translate paths back to virtual paths when we raise errors.

Separately from the path translation, the other remaining issue in this bug is that neither Launchpad nor Bazaar attempt to store the client's host information in the lock info.