Tim, your issue in comment 26 is confusing to me. It looks like it's
caused by my patch in comment 6?
Specifically, it looks like subprocess.Popen returns a unicode string as
stdout for you. I can't reproduce locally, in either python2.7 or
python3.7:
>>> import subprocess
>>> subprocess.Popen([u'ls'],
>>> stdout=subprocess.PIPE).communicate()[0].decode('utf8')
The documentation for Popen says:
"If encoding or errors are specified, or text is true, the file objects stdin,
stdout and stderr are opened in text mode with the specified encoding and
errors, as described above in Frequently Used Arguments. The universal_newlines
argument is equivalent to text and is provided for backwards compatibility. By
default, file objects are opened in binary mode."
None of the arguments that would cause Popen to return a unicode string
seem to be passed to it by duplicity...?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1855736
Title:
Duplicity fails to start
To manage notifications about this bug go to:
https://bugs.launchpad.net/duplicity/+bug/1855736/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
