John A Meinel пишет:
> > marno wrote:
>> >> Public bug reported:
> > 
>> >> Using german umlaut in description when checking in produces:
> > 
> > ...
> > 
>> >> Traceback (most recent call last):
> > ...
> > 
>> >>   File "bzrlib\option.pyo", line 291, in _optparse_callback
>> >> UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 1: ordinal not in range(128)
> > 
>> >> bzr 2.0.1 on python 2.5.4 (Windows-Vista-6.0.6002-SP2)
>> >> arguments: ['C:\\Program Files (x86)\\Bazaar\\bzr.exe', 'qsubprocess', '"commit" "-m" "Textlogfile f\xfcr Buchungen speicherte im Webroot von xxxr.de" "apps/frontend/modules/buchen/actions/actions.class.php" "--fixes=Textlogfile" "--fixes=f\xfcr" "--fixes=Buchungen" "--fixes=speicherte" "--fixes=im" "--fixes=Webroot" "--fixes=von" "--fixes=xxx.de"']
>> >> encoding: 'cp1252', fsenc: 'mbcs', lang: None
> > 
> >   affects qbzr
> > 
> > Seems to be an issue with how qbzr is passing arguments to the bzr
> > subprocess, and then how bzr itself tries to parse those. I'm adding
> > qbzr, just in case there is something that it could be doing differently.

Well, I can reproduce it with plain command line like this

C:\Temp\2>bzr ci -m1 --fixes тест --unchanged

bzr: ERROR: exceptions.UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-3:
ordinal not in range(128)

Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 842, in exception_to_return_code
  File "bzrlib\commands.pyo", line 1037, in run_bzr
  File "bzrlib\commands.pyo", line 624, in run_argv_aliases
  File "bzrlib\commands.pyo", line 743, in parse_args
  File "optparse.pyo", line 1387, in parse_args
  File "optparse.pyo", line 1427, in _process_args
  File "optparse.pyo", line 1502, in _process_long_opt
  File "optparse.pyo", line 774, in process
  File "optparse.pyo", line 794, in take_action
  File "bzrlib\option.pyo", line 291, in _optparse_callback
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-3: ordinal not in range(128)

bzr 2.0.1 on python 2.5.4 (Windows-XP-5.1.2600-SP3)
arguments: ['C:\\Program Files\\Bazaar\\bzr.EXE', 'ci', '-m1', '--fixes', '\xf2\xe5\xf1\xf2',
'--unchanged']
encoding: 'cp1251', fsenc: 'mbcs', lang: 'ru'
plugins:
  bzrtools             C:\Program Files\Bazaar\plugins\bzrtools [2.0.1]
  explorer             C:\work\Bazaar\plugins\explorer [0.8.2]
  fastimport           C:\work\Bazaar\plugins\fastimport [0.8.0dev]
  format1              C:\work\Bazaar\plugins\format1 [unknown]
  launchpad            C:\Program Files\Bazaar\plugins\launchpad [2.0.1]
  qbzr                 C:\work\Bazaar\plugins\qbzr [0.16.0dev]
  rebase               C:\work\Bazaar\plugins\rebase [0.5.4]
  repoalias            C:\work\Bazaar\plugins\repoalias [unknown]
  scmproj              C:\work\Bazaar\plugins\scmproj [0.4.6dev]
  stats                C:\work\Bazaar\plugins\stats [unknown]
  svn                  C:\work\Bazaar\plugins\svn [1.0.2dev]
  x_bit                C:\work\Bazaar\plugins\x_bit [1.0.0]

*** Bazaar has encountered an internal error.  This probably indicates a
    bug in Bazaar.  You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    including this traceback and a description of the problem.

So, actual "bug" in bzrlib itself.

> > My initial guess is that it is an issue with how 'qsubprocess' is being
> > invoked. Because the '"commit..."' is being supplied as a single string
> > argument to the command.

No, qsubprocess invoked correctly.

> > Also, '"--fixes=f\xfcr"' is not usually how '--fixes' is used. Usually
> > you give it something like "--fixes lp:12345" or "--fixes gnome:2345".

Yes, perhaps we can add validation call in qcommit for values supplied as --fixes. I'm sure there
was one long time ago before we started using qsubprocess.