bzr commit error because of no identity (should look at /etc/mailname)

[LaMont Jones]

% sudo apt-get dist-upgrade <-- installing bzr 2.2.0-1
...
% bzr commit
bzr: ERROR: Unable to determine your name.
Please, set your name with the 'whoami' command.
E.g. bzr whoami "Your Name <email address hidden>"

This should, at worst, be a warning. Or there should be a trivial way to cause it to be. If the user wants to be anonymous-ish, he should be allowed to be.

[Jelmer Vernooij (jelmer)]

Some users ended up doing commits with a committer email / hostname set that was invalid or private. See bug 549310.

Other than running "bzr whoami", it should be possible to prevent this error by setting the EMAIL or BZR_EMAIL environment variables. bzr doesn't really care about whether those values are set to a valid email address, just that they are set.

[Jelmer Vernooij (jelmer)]

Warning the user when they do a commit while the username was guessed seems like a good idea, in the same spirit as the --strict warning/errors for "bzr push".

[James Troup (elmo)]

Our use case is /etc in bzr. We don't care at all about having valid
email addresses in the bzr history for these branches. This change is
really problematic for us. We're either going to have to patch it out
or fix hundreds of machines (either by running bzr whoami or setting
BZR_EMAIL with some dummy value).

I understand the rationale somewhat for the more traditional use cases
of bzr (distributed revision control for source code), but we surely
can't be the only users who don't care about the validity of email
addresses and find this an unwelcome change.

[Jelmer Vernooij (jelmer)]

On Thu, 2010-08-12 at 16:07 +0000, James Troup wrote:
> Our use case is /etc in bzr. We don't care at all about having valid
> email addresses in the bzr history for these branches. This change is
> really problematic for us. We're either going to have to patch it out
> or fix hundreds of machines (either by running bzr whoami or setting
> BZR_EMAIL with some dummy value).
I agree we should keep supporting that use case. Would having bzr only
warn about no username being set be a problem for you?

Cheers,

Jelmer

[Parth Malwankar (parthm)]

Maybe a option (bzr ci --guess-user|--guess-whoami) can be provided. I would prefer a new option to a warning as it would allow special cases to be handled explicitly and in the normal case the user won't need to commit <fail> uncommit - whoami - commit. Instead commit <fail> whoami - commit sequence would remain.

[Jelmer Vernooij (jelmer)]

On Thu, 2010-08-12 at 16:59 +0000, Parth Malwankar wrote:
> Maybe a option (bzr ci --guess-user|--guess-whoami) can be provided. I
> would prefer a new option to a warning as it would allow special cases
> to be handled explicitly and in the normal case the user won't need to
> commit <fail> uncommit - whoami - commit. Instead commit <fail> whoami
> - commit sequence would remain.
That means users with a large number of installations (such as elmo)
would still have to run "bzr whoami" in one way or another on all their
machines.

[John A Meinel (jameinel)]

I think downgrading it to a warning would be ok. I've noticed other systems do the same thing.

That said, if you are upgrading 400 machines to a newer version of bzr, can't that same mechanism be used to call 'bzr whoami' one time on each of those machines? (It doesn't have to happen on every commit, just one global setup.) Certainly you're running 'bzr commit' on all of those machines as well (or you wouldn't have had the problem in the first place)....

I can agree that change is disruptive, but having appropriate defaults for the common case is also useful.

[James Troup (elmo)]

Jelmer Vernooij <email address hidden> writes:

> On Thu, 2010-08-12 at 16:07 +0000, James Troup wrote:
>> Our use case is /etc in bzr. We don't care at all about having valid
>> email addresses in the bzr history for these branches. This change is
>> really problematic for us. We're either going to have to patch it out
>> or fix hundreds of machines (either by running bzr whoami or setting
>> BZR_EMAIL with some dummy value).
> I agree we should keep supporting that use case. Would having bzr only
> warn about no username being set be a problem for you?

If it warns once, that's fine. If it warns on every invocation of bzr,
that's no better at all.

--
James

[James Troup (elmo)]

John A Meinel <email address hidden> writes:

> I think downgrading it to a warning would be ok. I've noticed other
> systems do the same thing.
>
> That said, if you are upgrading 400 machines to a newer version of bzr,
> can't that same mechanism be used to call 'bzr whoami' one time on each
> of those machines?

Sure except that we run bzr as many different users. And yes, we could
in theory, force a 'bzr whoami' run for all of those users across 400
machines.

Or, you know, we could just give up and switch to some other VCS system
which doesn't annoy us so much because I really don't want to do that
:-P

(A per branch/checkout/whatever way to disable this error would be
 sufficient to downgrade this from a blocker on us upgrading to a simple
 annoyance.)

--
James

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Troup wrote:
> John A Meinel <email address hidden> writes:
>
>> I think downgrading it to a warning would be ok. I've noticed other
>> systems do the same thing.
>>
>> That said, if you are upgrading 400 machines to a newer version of bzr,
>> can't that same mechanism be used to call 'bzr whoami' one time on each
>> of those machines?
>
> Sure except that we run bzr as many different users. And yes, we could
> in theory, force a 'bzr whoami' run for all of those users across 400
> machines.
>
> Or, you know, we could just give up and switch to some other VCS system
> which doesn't annoy us so much because I really don't want to do that
> :-P
>
> (A per branch/checkout/whatever way to disable this error would be
> sufficient to downgrade this from a blocker on us upgrading to a simple
> annoyance.)
>

bzr whoami --branch

Is a per-branch way to disable this error...

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxl2SEACgkQJdeBCYSNAAO4bwCgka4/VoXMPtYvGpDgDE6R3+uP
8G8AoNPYZrzvwxYfwge6NvoiU2Ffcnyd
=gjFm
-----END PGP SIGNATURE-----

[James Troup (elmo)]

John A Meinel <email address hidden> writes:

>> (A per branch/checkout/whatever way to disable this error would be
>> sufficient to downgrade this from a blocker on us upgrading to a simple
>> annoyance.)
>
> bzr whoami --branch
>
> Is a per-branch way to disable this error...

I meant a way that works across all users; something that is stored in
the .bzr and stops this non-issue-for-us from being reported as a fatal
error for any user on the machine who uses the branch.

--
James

[Alexander Belchenko (bialix)]

James Troup пишет:
> John A Meinel <email address hidden> writes:
>
>>> (A per branch/checkout/whatever way to disable this error would be
>>> sufficient to downgrade this from a blocker on us upgrading to a simple
>>> annoyance.)
>> bzr whoami --branch
>>
>> Is a per-branch way to disable this error...
>
> I meant a way that works across all users; something that is stored in
> the .bzr and stops this non-issue-for-us from being reported as a fatal
> error for any user on the machine who uses the branch.

`bzr whoami --branch` sets the identity for *all* users.

[Parth Malwankar (parthm)]

Would a switch like --guess-committer or --committer=ARG for 'bzr ci' satisfy this use case?

[Martin Pool (mbp)]

The main problem with inferring the email address seems to be is that checked both the email domain and the hostname. Perhaps it would be reasonable to assume that if the machine's mail domain is set, it is correct. So we might get auto commits from <email address hidden> but not from joe@home. Then sysadmins just need to make sure /etc/mailname is set, which it probably is already.

[Nick Moffitt (nick-moffitt)]

Bug #647475 overlaps heavily with this bug. It concerns the fact that this problem breaks etckeeper rather terribly, especially in the update-manager where it's not made as clear what's actually going wrong. It's likely worth marking a duplicate of this one.

[Martin Pool (mbp)]

I asked before if trusting the mailname would be a good solution for
this. What do you think, Nick?
--
Martin

[Nick Moffitt (nick-moffitt)]

Martin: For this and for Bug #647475 I think even filling it full of <email address hidden> would be fine, as etckeeper/manual-etc-in-bzr trees do not typically get published anywhere for obvious reasons. We're not actually concerned with the value of this field, as we have ignored it for a long time and used changelog-style commit messages to contain the commiter info along with other pieces of information we care about. That is partly why this came as such a shock to us.

Trusting the mailname, perhaps with an ignorable warning (maybe recommending an uncommit if they want to go back and fix the committer address?), seems to have no drawbacks for this use case.

[Max Bowsher (maxb)]

I think considering the machine's mailname is perhaps not necessary.

As I see it, there are two significant divisions of use-cases here:

1) The ones that bug 549310 was filed about, where users are committing revisions to be shared with the world, and the email address really really ought to be a valid configured email address.

2) The ones who are managing an /etc-in-bzr, where <local-unix-user@machine-hostname> is probably the exact most useful thing that we could record anyway.

Could we not just add a branch.conf boolean setting (and corresponding switches to 'bzr init', 'bzr reconfigure') which reverts to the previous behaviour?

[Martin Pool (mbp)]

On 26 November 2010 07:57, Max Bowsher <email address hidden> wrote:
> Could we not just add a branch.conf boolean setting (and corresponding
> switches to 'bzr init', 'bzr reconfigure') which reverts to the previous
> behaviour?

So, it would default to warning or failing, to help people who don't
realize they ought to set it?

We could, but that would still fail one of the Canonical IS wishes
that this not require per-machine setup.
--
Martin

[Charlie Schluting ☃ (cschluti)]

After discussing with lamont, we think trusting mailname is fine (by default).. provided that it won't require us to set an option to enable that behaivor.

Can this be in v2.3?

Thanks!
 -Charlie

[John A Meinel (jameinel)]

Martin, your branch for this has landed, should we be considering it Fix Released instead of In Progress? Or did you have more you needed to do. Maybe that should be split out as another bug?

[Martin Pitt (pitti)]

Accepted bzr into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Clint Byrum (clint-fewbar)]

Hello LaMont, or anyone else affected,

Accepted bzr into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Jelmer Vernooij (jelmer)]

Verified by running the bzr testsuite from the package in a clean natty install.

[Launchpad Janitor (janitor)]

This bug was fixed in the package bzr - 2.3.4-0ubuntu1

---------------
bzr (2.3.4-0ubuntu1) natty-proposed; urgency=low

  * New upstream release.
   + Fix bzr version number in deprecation warnings. LP: #794960
   + Prevent write attemps on remote branch during "bzr up". LP: #786980
   + Fix conflict handling when two trees involved in a merge have different
     root ids. LP: #805809

bzr (2.3.3-0ubuntu1) natty-proposed; urgency=low

  * New upstream release.
   + Fixes deprecation warning on newer versions of Python. LP: #760435
   + Stops 'bzr push' from copying entire repository if a .bzr directory is
     present without a branch. LP: #465517
   + Fixes undefined local variable error when waiting for lock. LP: #733136
   + Fixes lock contention issues pushing to a bound branch. LP: #733350
   + Transfers less data creating a new stacked branch. LP: #737234
   + Several fixes to the test suite, making it more robust. LP: #654733,
      LP: #751824
   + 'bzr merge --pull --preview' actually shows a preview rather than
     actually merging. LP: #760152
   + bzr smart server now supports UTF-8 user names. LP: #659763
   + user identity can now be set based on username and /etc/mailname, not
     requiring it to be set manually. LP: #616878
   + stacking is now fully transitive. LP: #715000
   + makes in-terminal crash report of plugins much shorter. LP: #716389
 -- Jelmer Vernooij <email address hidden> Thu, 14 Jul 2011 21:12:58 +0200

[LaMont Jones (lamont)]

% bzr init; bzr add
...
% bzr commit -m 'Initial import.'
bzr: ERROR: Unable to determine your name.

I believe this means we have regressed.

[LaMont Jones (lamont)]

2.4.0-0ubuntu2~11.IS.8.04 from jelmer, if that helps get the conversation going

[Jelmer Vernooij (jelmer)]

It is still possible to get this error, although in most cases it should be able to automatically determine your user id. Do you have a valid /etc/mailname, and does the current user have an entry in the passwd database?

[LaMont Jones (lamont)]

This was inside debian-installer, no mailer installed on the box. So it does seem to be a different use-case than one would get from the original bug report.

[Martin Pool (mbp)]

The case of lacking an /etc/mailname is https://bugs.launchpad.net/bzr/+bug/884502

Note that you don't need to have an actual mailer, just a mailname that contains one line giving the mail domain of the box.