Red Hat Bugzilla – Bug 1014623
poor handling of utf-8 strings in bkr client
Last modified: 2018-02-05 19:41:31 EST
Created attachment 806402 [details] encode myxml to utf-8 upon creation Description of problem: $ bkr job-results --prettyxml J:507498 Traceback (most recent call last): File "/usr/bin/bkr", line 9, in <module> load_entry_point('bkr.client==0.14.1', 'console_scripts', 'bkr')() File "/usr/lib/python2.7/site-packages/bkr/client/main.py", line 50, in main return cmd.run(*cmd_args, **cmd_opts.__dict__) File "/usr/lib/python2.7/site-packages/bkr/client/commands/cmd_job_results.py", line 83, in run print parseString(myxml).toprettyxml() File "/usr/lib64/python2.7/xml/dom/minidom.py", line 1931, in parseString return expatbuilder.parseString(string) File "/usr/lib64/python2.7/xml/dom/expatbuilder.py", line 940, in parseString return builder.parseString(string) File "/usr/lib64/python2.7/xml/dom/expatbuilder.py", line 223, in parseString parser.Parse(string, True) UnicodeEncodeError: 'ascii' codec can't encode characters in position 150082-150084: ordinal not in range(128) $ Version-Release number of selected component (if applicable): beaker-client-0.14.1-1.fc18.noarch How reproducible: always Steps to Reproduce: 1. see description Actual results: 'ascii' codec failure Expected results: XML containing the job's results is generated Additional info: attaching proposed patch
The underlying problem here is that we're sending an XML document through XML-RPC as a unicode string rather than as a binary sequence. However, we can't change that without breaking the server API, so this is a good suggested fix. We can get away with hardcoding UTF-8 (rather than checking for an encoding declaration in the XML) because we control the server side as well and always use UTF-8 as the encoding declaration in our XML data.
Thanks for the patch, Martin! bkr job-clone suffers the same problem, this patch fixes them both: http://gerrit.beaker-project.org/2359
beaker 0.15.1 has been released.
This change has been nominated to be back ported to the 0.14 branch, to be released as part of the next maintenance release 0.14.2.
Adjusting target milestone to make the changes backported to 0.14.2 easier to identify. 0.15.0 has enough significant regressions that it shouldn't be used, so the change means that 0.15.1 can be effectively reidentified as the union of that tag and the 0.14.2 target milestone.
Closing as addressed in Beaker 0.14.2.