AttributeError: 'GPGError' object has no attribute 'decode'

Bug #1733057 reported by Bruce Merry on 2017-11-18
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Duplicity
Medium
Unassigned

Bug Description

As of 0.7.15, I'm getting this traceback:

Traceback (innermost last):
  File "/usr/bin/duplicity", line 1559, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1545, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1394, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1526, in do_backup
    check_last_manifest(col_stats) # not needed for full backup
  File "/usr/bin/duplicity", line 1228, in check_last_manifest
    last_backup_set.check_manifests()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 208, in check_manifests
    remote_manifest = self.get_remote_manifest()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 245, in get_remote_manifest
    (util.ufn(self.remote_manifest_name), util.ufn(message)))
  File "/usr/lib/python2.7/dist-packages/duplicity/util.py", line 63, in ufn
    return filename.decode(sys.getfilesystemencoding(), 'replace')
 AttributeError: 'GPGError' object has no attribute 'decode'

I believe this is a regression caused by commit 1336, where a GPGError object is being passed to util.ufn.

Jonathan Elchison (jelchison) wrote :

I'm also experiencing this error.

My daily backup last succeeded yesterday with this environment:

Using installed duplicity version 0.7.14, python 2.7.12, gpg 1.4.20 (Home: ~/.gnupg), awk 'GNU Awk 4.1.3, API: 1.1 (GNU MPFR 3.1.4, GNU MP 6.1.0)', grep 'grep (GNU grep) 2.25', bash '4.3.48(1)-release (x86_64-pc-linux-gnu)'.

My daily backup failed today with this environment:

Using installed duplicity version 0.7.15, python 2.7.12, gpg 1.4.20 (Home: ~/.gnupg), awk 'GNU Awk 4.1.3, API: 1.1 (GNU MPFR 3.1.4, GNU MP 6.1.0)', grep 'grep (GNU grep) 2.25', bash '4.3.48(1)-release (x86_64-pc-linux-gnu)'.

I concur that this seems to be a regression introduced by something in 0.7.15.

Here is my traceback, which appears to match the original report:

Traceback (innermost last):
  File "/usr/bin/duplicity", line 1559, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1545, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1394, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1526, in do_backup
    check_last_manifest(col_stats) # not needed for full backup
  File "/usr/bin/duplicity", line 1228, in check_last_manifest
    last_backup_set.check_manifests()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 208, in check_manifests
    remote_manifest = self.get_remote_manifest()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 245, in get_remote_manifest
    (util.ufn(self.remote_manifest_name), util.ufn(message)))
  File "/usr/lib/python2.7/dist-packages/duplicity/util.py", line 63, in ufn
    return filename.decode(sys.getfilesystemencoding(), 'replace')
 AttributeError: 'GPGError' object has no attribute 'decode'

Thanks, everyone!

Changed in duplicity:
importance: Undecided → Medium
milestone: none → 0.7.16
status: New → Fix Committed
Ronald (pd1acf) wrote :

this bug is now affecting the CentOS EPEL repos:

duplicity-0.7.15-1.el7.x86_64

no longer affects: centos
clayton craft (craftyguy) wrote :

I know that this is of 'medium' importance, and that there are several other items in the 0.7.16 milestone with a higher 'importance' value, but this bug literally breaks performing incremental backsups for all of my systems. Is there any chance of getting, say, a 0.7.15.1 (or whatever you want to call it) release with only this fix in it?

Jonathan Elchison (jelchison) wrote :

This may not be an option for some, but a successful workaround for me was to force a full backup.

Changed in duplicity:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers