i've dug into this a bit more deeply and found an explanation for the
logging gotchas under certain locales:

as per the python wiki 
(http://web.archive.org/web/20120425192131/http://wiki.python.org/moin/UnicodeEncodeError)
 when you run somestring.decode(whicheverencoding) python2 does weird
encode-and-then-decode things if your somestring is already unicode.

log.py uses s.decode('utf8',ignore)  - which fails to ignore errors on
some locales (apparently in the down-EN-coding step before the
decode...).

check out the attached test script, which contains an iso8859 string to
log. if you run it (at least under python 2.6) with LC_CTYPE=anything
utf8 or plain C/POSIX then it works fine. if your CTYPE is iso88591,
then the first decode of x works but the second decode fails, and we get
the ascii can't encode complaint.

i've just changed  the debian version (0.6.20-2) to do the decode in
log.py conditionally:

_logger.log(DupToLoggerLevel(verb_level), s if (isinstance(s,unicode))
else s.decode("utf8", "ignore"))

regards,
az

** Attachment added: "test script for the decode-ascii-issue"
   
https://bugs.launchpad.net/ubuntu/+source/duplicity/+bug/989496/+attachment/3483743/+files/dreck.py

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/989496

Title:
  UnicodeDecodeError during backup due to non-utf8 translation

To manage notifications about this bug go to:
https://bugs.launchpad.net/duplicity/+bug/989496/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to