bzr.dev missing signatures
John A Meinel
john at arbash-meinel.com
Mon May 8 20:19:20 BST 2006
John A Meinel wrote:
> Erik Bågfors wrote:
>> On 5/8/06, John A Meinel <john at arbash-meinel.com> wrote:
>>> Erik Bågfors wrote:
>>> > After reading this, I thought I should sign my commits. It felt
>>> > to run
>>> > sign-my-commits. It dies with the following
>>> > : [bagfors at zyrgelkwyt]$ ; bzr sign-my-commits
>>> > erik at bagfors.nu-20051220112436-0c74ef0e272fe074
>>> > bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode
>>> > byte 0xc3 in position 10: ordinal not in range(128)
>>> > at /home/bagfors/src/bzr/bzr.dev/bzrlib/testament.py line 139
>>> > in as_text_lines
>>> > /Erik
>>> What version of bzr are you using? Because I know there was a patch
>>> around that fixed testament to properly encode things as utf-8, and I'm
>>> hoping we don't have a regression.
>> bzr.dev latest (which is 0.8 :) )
>>> I'll look through my encoding branch, and see if testament fails with
>>> Unicode committers.
> Can you send me a more complete backtrace?
> The line in question is doing:
> return [line.encode('utf-8') for line in r]
> So it is supposed to be encoding things properly. It would seem that
> somewhere internally we are actually pre-encoding into utf-8, and then
> we are encoding again into utf-8 (which tries to decode as ascii first,
> and fails).
Just to confirm my suspicion, at the very least the call:
_revprops_to_lines() does encode into utf-8, So if there was a unicode
entry in revision properties, that would cause a double utf-8 encode.
I'm not sure whether to fix things in my encoding branch (which now has
a chance of landing, but isn't guaranteed for a while), or whether to do
it on an independent branch (which has a much higher chance of actually
More information about the bazaar