Thanks for the information. First of all, as reported by the log file you sent and the listing of your backup directory, there is an uncompressed backup volume in your volume directory, and an uncompressed file of files signatures, created or last modified on Dec 22:

  duplicity-full.20161129T015237Z.vol1.difftar
  duplicity-full-signatures.20161129T015237Z.sigtar

along with their older compressed versions, created on Nov 28:

  duplicity-full.20161129T015237Z.vol1.difftar.gz
  duplicity-full-signatures.20161129T015237Z.sigtar.gz

As far as I know there shouldn't be any such uncompressed files in the backup location. Did you uncompress them yourself perhaps? In any case, they're confusing duplicity (the command-line backup tool Déjà-Dup is a graphical front-end to), if I understand the log file and error message correctly:

  DUPLICITY: INFO 1
  DUPLICITY: . Args: /usr/bin/duplicity collection-status [...]

  [...]

  DUPLICITY: DEBUG 1
  DUPLICITY: . 12 files exist on backend

  DUPLICITY: DEBUG 1
  DUPLICITY: . Extracting backup chains from list of files:
   [u'duplicity-full.20161129T015237Z.vol1.difftar',
    u'duplicity-full.20161129T015237Z.manifest',
    u'duplicity-full.20161129T015237Z.vol1.difftar.gz',
    u'duplicity-full-signatures.20161129T015237Z.sigtar.gz',
    u'duplicity-full-signatures.20161129T015237Z.sigtar',
    [...]

  DUPLICITY: DEBUG 1
  DUPLICITY: . File duplicity-full.20161129T015237Z.vol1.difftar is not part of a
    known set; creating new set

  DUPLICITY: DEBUG 1
  DUPLICITY: . File duplicity-full.20161129T015237Z.manifest is part of known set

  DUPLICITY: ERROR 30 AssertionError
  [...]
  DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/collections.py",
    line 105, in add_filename(self.volume_name_dict, filename)
  DUPLICITY: . AssertionError:
    ({1: 'duplicity-full.20161129T015237Z.vol1.difftar'},
    'duplicity-full.20161129T015237Z.vol1.difftar.gz')

From my understanding of the duplicity source code in the incriminated file, this is what happens when happens Déjà-Dup launches the collection-status action to have duplicity find out which backup chains are in the backup repository: Déjà-Dup passes the list of files in this directory to duplicity, which takes the uncompressed duplicity-full.20161129T015237Z.vol1.difftar for the start of a backup set, then tries to add the compressed duplicity-full.20161129T015237Z.vol1.difftar.gz to this set, and fails because the volume number of this file has already been added to the set. Otherwise there would be two backup volumes with the same volume number in the backup set, and duplicity can't guess which one to take into account.

To fix this bug from happening in the future, we could perhaps restrict the file list that is passed from Déjà-Dup to duplicity collection-status? Perhaps to *.{diff,sig}tar.{gz,gpg} and *.manifest files only, or something like that?

Or perhaps it could be fixed in duplicity, by having duplicity prefer a particular filename when there are two volumes with the same number in the same backup set? But then which one and on what grounds?

Vej, your take on that?

In the meantime, David, I believe it's safe for you to delete those extraneous uncompressed files (or move them outside of your backup repository). The assertion error should no longer be triggered, but you should bump into other errors, because your backup repository clearly doesn't have a complete, well-formed backup chain. More on that later.