lp:~mterry/duplicity/argv-encode

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp:duplicity/0.6 at revision 956

duplicity-team: Pending requested 2014-01-06

Diff: 12 lines (+1/-1)

1 file modified

bin/duplicity (+1/-1)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

951. By Michael Terry on 2014-01-06

Encode sys.argv using system filename encoding before printing

950. By ede on 2014-01-03

recommit: implement fix as suggested by original autor
http://lists.nongnu.org/archive/html/duplicity-talk/2013-11/msg00017.html

949. By Kenneth Loafman on 2014-01-02

Reformat to be more consistent. Remove tabs.

948. By Kenneth Loafman on 2014-01-02

* Reverted changes to gdocsbackend.py

947. By Kenneth Loafman on 2014-01-02

Fix conflicts.

946. By Kenneth Loafman on 2014-01-02

* Restored missing line from patch of gdocsbackend.py

945. By Kenneth Loafman on 2013-12-30

* Merged in lp:~mterry/duplicity/encoding
  - This branch hopefully fixes two filename encoding issues:
  - Users in bug 989496 were noticing a UnicodeEncodeError exception which
    happens (as far as I can tell) because some backends (like webdav) are
    returning unicode filenames from list(). When these filenames are combined
    with the utf8 translations of log messages, either (A) the default ascii
    encoding can't handle promoting the utf8 bytes or -- if there aren't any
    utf8 bytes in the translation -- (B) the resulting unicode string raises
    an error later when log.py tries to upgrade the string again to unicode
    for printing.
  - This fix is largely implemented by adding a wrapper for backend list()
    implementations. This wrapper ensures that duplicity internals always see
    a byte string. (I'd like to eventually use this same wrapping strategy to
    implement generic retry support without backends having to add any logic,
    but that's just a thought for the future.)
  - That is, the fix for issue #1 is completely inside backend.py and the
    changes to backends/*.py.
  - The rest of the invasive changes deal with filenames that may not be valid
    utf8. This is much rarer, but possible. For proper handling of this, we
    need to print using unicode, and convert filenames from the system filename
    encoding to unicode, gracefully handling conversion errors. Some of the
    filenames we print are remote names. Who knows what encoding they are in;
    it could be different than the system filename encoding. 99% of the time,
    everything will be utf8 and we're fine. If we do get conversion errors,
    the only effect should be some question mark characters in duplicity
    logging output.
  - I tried to convert as much of the actual codebase to use unicode for
    printing. But I stopped short of adding an assert in log.py to enforce
    unicode, because I didn't want to go through all the backend code and
    manually adjust those bits without being able to test each one.

944. By Kenneth Loafman on 2013-12-29

Nuke tabs.

943. By Kenneth Loafman on 2013-12-28

* Merged in lp:~ed.so/duplicity/debian.dav.mkdir
  - upstream debian patch "webdav create folder recursively"
    http://patch-tracker.debian.org/package/duplicity/0.6.22-2

942. By Kenneth Loafman on 2013-12-28

* Merged in lp:~ed.so/duplicity/debian.paramiko.log
  - upstream debian patch "paramiko logging"
    http://patch-tracker.debian.org/package/duplicity/0.6.22-2