Comment 2 for bug 633101

Similar problem here (Debian stable with 0.6.08b-1+b1), with the following trace :

Info: File duplicity-inc.20101225T001425Z.to.20101226T001506Z.manifest.part is not part of a known set; creating new set
Info: File duplicity-full-signatures.20101222T161821Z.sigtar.gpg is not part of a known set; creating new set
Info: Ignoring file (rejected by backup set) 'duplicity-full-signatures.20101222T161821Z.sigtar.gpg'
Info: File duplicity-full.20101222T161821Z.manifest.gpg is not part of a known set; creating new set
Info: File duplicity-full.20101222T161821Z.vol1.difftar.gpg is part of known set
Info: File duplicity-full.20101222T161821Z.vol2.difftar.gpg is part of known set
Info: File duplicity-full.20101222T161821Z.vol3.difftar.gpg is part of known set
Info: File duplicity-inc.20101222T161821Z.to.20101223T002132Z.manifest.gpg is not part of a known set; creating new set
Info: File duplicity-inc.20101222T161821Z.to.20101223T002132Z.vol1.difftar.gpg is part of known set
Info: File duplicity-inc.20101223T002132Z.to.20101224T001431Z.manifest.gpg is not part of a known set; creating new set
Info: File duplicity-inc.20101223T002132Z.to.20101224T001431Z.vol1.difftar.gpg is part of known set
Info: File duplicity-inc.20101224T001431Z.to.20101225T001425Z.manifest.gpg is not part of a known set; creating new set
Info: File duplicity-inc.20101224T001431Z.to.20101225T001425Z.vol1.difftar.gpg is part of known set
Info: Removing still remembered temporary file /tmp/duplicity-g1LQZX-tempdir/mkstemp-zwaTeY-1
Info: Traceback (most recent call last):
Info: File "/usr/bin/duplicity", line 1251, in <module>
Info: with_tempdir(main)
Info: File "/usr/bin/duplicity", line 1244, in with_tempdir
Info: fn()
Info: File "/usr/bin/duplicity", line 1149, in main
Info: globals.archive_dir).set_values()
Info: File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line 676, in set_values
Info: self.get_backup_chains(partials + backend_filename_list)
Info: File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line 799, in get_backup_chains
Info: map(add_to_sets, filename_list)
Info: File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line 789, in add_to_sets
Info: if set.add_filename(filename):
Info: File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line 89, in add_filename
Info: self.set_manifest(filename)
Info: File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line 118, in set_manifest
Info: remote_filename)
Info: AssertionError: ('duplicity-inc.20101225T001425Z.to.20101226T001506Z.manifest.part', 'duplicity-inc.20101225T001425Z.to.20101226T001506Z.manifest.gpg')
Fatal: Duplicity failed.

I noticed that the file in the local cache was more or less normal (size > 0), whereas the distant one was of size 0.

I guess that situation has happened as the file was transferred once on the distant server, which was over quota, so the file was created with size 0... then the resulting failures on next run.

The situation may be a bit different from the other reporter's, but duplicity should try and handle such events better or at least explain such failures in more details.

Hope this helps.