giseldo/neodataset huggingface dataset:
duplicity falsely reports succeeded backup, empty manifest file (lp:#676042)

[Original report](https://bugs.launchpad.net/bugs/676042) created by **9johnny (s.j.)**
```
duplicity version duplicity 0.6.09
Python 2.5.2
Distributor ID: Debian
Description:    Debian GNU/Linux 5.0.6 (lenny)
Release:        5.0.6
Codename:       lenny

==backup log snip==
ionice -c 3 nice -n 9 duplicity incremental --full-if-older-than 2W
--asynchronous-upload --no-encryption --asynchronous-upload --no-encryption
--exclude '/tmp/**' --exclude '/proc/**' --exclude '/dev/**' --exclude
'/sys/**' --exclude '/root/.cache/**' --exclude '/var/cache/duplicity/**'
--exclude '/var/marsnet/duplicity/**' --exclude '/var/alternc/mnt/**'
--exclude '/var/lib/mysql/**' --exclude '/var/alternc/db/**' --exclude
'/var/log/mysql/**' / ssh://backup@mybckhost//opt/marsnet/backups/
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Thu Oct 28 01:13:25 2010
Last full backup is too old, forcing full backup
--------------[ Backup Statistics ]--------------
StartTime 1289607215.28 (Sat Nov 13 01:13:35 2010)
EndTime 1289636885.88 (Sat Nov 13 09:28:05 2010)
ElapsedTime 29670.59 (8 hours 14 minutes 30.59 seconds)
SourceFiles 1730868
SourceFileSize 106161258939 (98.9 GB)
NewFiles 1730868
NewFileSize 106161244989 (98.9 GB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 1730868
RawDeltaSize 105419449446 (98.2 GB)
TotalDestinationSizeChange 65491887291 (61.0 GB)
Errors 0
-------------------------------------------------

++ hostname --fqdn
+ ionice -c 3 nice -n 9 duplicity remove-all-but-n-full 1 --force --no-
encryption ssh://backup@mybckhost//opt/marsnet/backups/
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Sat Nov 13 01:13:30 2010
Deleting backup set at time:
Thu Oct 28 01:13:25 2010
Deleting this file from backend:
duplicity-full-signatures.20101027T231325Z.sigtar.gz
==end snip==

This is the log from the backup that failed. Ihave conditional execution so
backups aren't removed if duplicity fails. In this case there was no error,
but I found an empty manifest file in the destination directory. Sorry, i
don't use extra verbose output in my backup scripts.
All the restore scripts fail silently: they see the archive as empty, this
could be the reason why duplicity reported success on exit?
(very annoying, i just had to restore a file, i'm trying to recover at
least a part of it using simple gunzip and tar..)
```

Story points: 20.0
Fix documentation: Why not tar? (lp:#675520)

[Original report](https://bugs.launchpad.net/bugs/675520) created by **nodata (ubuntu-nodata)**
```
The page "Why not tar?" on the duplicity website discusses problems with
tar:
 http://duplicity.nongnu.org/new_format.html

A recent HN discussion addressed most of these points, maybe this could
lead to improvements in duplicity?

I quote:
"The first two issues -- a lack of index and the fact that you can't seek
within a deflated tarball -- are true but are easily handled by smarter
compression. Tarsnap, for example, splits off archive headers and stores
them separately in order to speed up archive scanning.

The third issue -- lack of support for modern filesystem features -- is
just plain wrong. Sure, the tar in 7th edition UNIX didn't support these,
but modern tars support modern filesystem features.

The fourth issue -- general cruft -- is correct but irrelevant on modern
tars since the problems caused by the cruft are eliminated via pax
extension headers."
-- http://news.ycombinator.com/item?id=1665875
```

Story points: 16.0
duplicity prefers fully-qualified-domain-name (fqdn) over hostname (lp:#667885)

[Original report](https://bugs.launchpad.net/bugs/667885) created by **nodata (ubuntu-nodata)**
```
Duplicity determines the machine's hostname in order to warn the user about
unexpectedly backing up to the same location from two machines.

However, it does this using socket.getfqdn().  It seems many users expect
the value of socket.gethostname() instead.

Now, I don't fully understand exactly the difference between the two calls,
so I'm not necessarily advocating for this change.  But gethostname() seems
to be what most home users at least expect.  Is the situation different for
server users?

If we made this change, we'd have to be careful to gracfully accept
previous uses of getfqdn() that we wrote to manifests.  I'd be willing to
whip up a patch, Ken, if you think this is a sensible change.

Examples:
=========
(This original report)
Duplicity gives: localhost6.localdomain6

$ cat /etc/hostname
mybox

$ cat /etc/hosts
192.168.1.5     mybox   # Added by NetworkManager
127.0.0.1       localhost.localdomain   localhost
::1     mybox   localhost6.localdomain6 localhost6
=========
(Bug 1086068)
Duplicity gives: localhost

$ cat /etc/hostname
computername

$ cat /etc/hosts
127.0.0.1       localhost computername
=========
```

Story points: 48.0
Date format is inconsistent in the output of `duplicity collection-status` (lp:#652696)

[Original report](https://bugs.launchpad.net/bugs/652696) created by **zpcspm (zpcspm)**
```
I have a wrapper that parses the output of `duplicity collection-status` to
make decisions about running a full or an incremental backup.

Today it failed.

I was assuming that the day of the month is always two digits, so I was
counting for:

Fri Oct 01 00:00:05 2010

but I've got

Fri Oct  1 00:00:05 2010

I'm using duplicity 0.6.10

It would be nice to make the date format consistent, unless there's a
strong reason against it.
```
Original tags: wishlist

Story points: 16.0
Minor typo in manpage (" its' ") (lp:#644820)

[Original report](https://bugs.launchpad.net/bugs/644820) created by **Aaron Whitehouse (aaron-whitehouse)**
```
The man page reads:
"namely ssh through its’ utility routines scp and sftp"
it should read:
"namely ssh through its utility routines scp and sftp"
```

Story points: 6.0
sftp backend: falsely reports ok if target fs was r/o (lp:#638629)

[Original report](https://bugs.launchpad.net/bugs/638629) created by **az (az-debian)**
```
this is a copy of debian bug #596857, which lives here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596857

synopsis: when the target fs is mounted read-only and you're using sftp,
then duplicity claims success for
backups even though it couldn't save a single bit.

this somehow happens only if the fs is mounted r/o - "normal" insufficient
permissions result in
a misleading error message ("Invalid SSH password") and lots of retries.

if you use --use-scp, you get lots of retries and 'scp failed' errors.

the original submitter reported this for 0.6.08 and i've confirmed it for
0.6.09.
```

Story points: 8.0
Duplicity is failing with an assertion error when looking for a non-existent manifest file (lp:#633101)

[Original report](https://bugs.launchpad.net/bugs/633101) created by **Kenneth Loafman (kenneth-loafman)**
```
Binary package hint: duplicity

Dupliciity refuses to back my files and throws up an assertion error where
it appears to be trying to use a non-existent manifest.part file.  That
file doesn't exist and I cannot find where it is referenced.  Here is the
traceback:

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1251, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1244, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1149, in main
    globals.archive_dir).set_values()
  File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line
676, in set_values
    self.get_backup_chains(partials + backend_filename_list)
  File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line
799, in get_backup_chains
    map(add_to_sets, filename_list)
  File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line
789, in add_to_sets
    if set.add_filename(filename):
  File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line
89, in add_filename
    self.set_manifest(filename)
  File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line
118, in set_manifest
    remote_filename)
AssertionError: ('duplicity-full.20100817T193647Z.manifest.part',
'duplicity-full.20100817T193647Z.manifest')

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: duplicity 0.6.09-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.35-20.29-generic 2.6.35.4
Uname: Linux 2.6.35-20-generic i686
Architecture: i386
Date: Wed Sep  8 12:18:29 2010
InstallationMedia: Ubuntu-Netbook 10.10 "Maverick Meerkat" - Alpha i386
(20100803.1)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_GB.utf8
 SHELL=/bin/bash
SourcePackage: duplicity
```
Original tags: apport-bug i386 maverick ubuntu-une

Story points: 32.0
[Feature Request] support xz for compressing volumes (lp:#629357)

[Original report](https://bugs.launchpad.net/bugs/629357) created by **Rob Fortune (usedonlytosignup)**
```
xz offers a superior compression ratio at the cost of higher CPU load
during creation of backup, but still decompresses (when you need it most)
at a rapid pace. I don't know if it should be the default but adding it as
an option could save yottabytes of bandwidth :)
```
Original tags: patch

Story points: 86.0
sftp backend establishes a new connection for every action (lp:#619016)

[Original report](https://bugs.launchpad.net/bugs/619016) created by **Max Kanat-Alexander (mkanat)**
```
duplicity 0.6.08b
python 2.4.3
CentOS 5.5

When using the SFTP backend (really the scp:// backend, but I suppose
they're the same now), duplicity creates a new connection for every single
file that it wants to download or upload. For the manifest and signature
files in particular, this can add 30 minutes to a backup process. Since
SFTP is a persistent protocol and initial session negotiation is slow, it
would probably be faster to just make the connection once and then issue
commands over it, instead of re-making the connection for every upload or
download.
```

Story points: 12.0
Fine grained control of full vs incremental backups (lp:#614631)

[Original report](https://bugs.launchpad.net/bugs/614631) created by **zpcspm (zpcspm)**
```
Currently (I'm using 0.6.09), if 'full' or 'incremental' actions are not
specified explicitly, duplicity creates an incremental backup if it detects
a chain, or a full backup otherwise.

This behavior is somehow limited and I think I have an enhancement
suggestion.

Assume there would be an option named --chain-length. If called without
explicit 'full' or 'incremental' actions, but with `--chain-length 10`,
duplicity would still do a full backup if it would detect a recent chain
consisting of 1 full backup and 9 incremental backups.

I think this would add some useful flexibility (unless I'm missing
something and it could be done without having to parse the output of
collection-status action first, for enforcing an explicit 'full' action for
certain chain lengths).
```

Story points: 6.0
CTRL-C before first volume - temporary files not cleaned up (lp:#613243)

[Original report](https://bugs.launchpad.net/bugs/613243) created by **Liraz (liraz-siri)**
```
If I CTRL-C before the first volume is completed, temporary files
created in the cache are not cleaned up. Clues may be found in the
exception raised on CTRL-C:

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1251, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1244, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1226, in main
    incremental_backup(sig_chain)
  File "/usr/bin/duplicity", line 487, in incremental_backup
    globals.backend)
  File "/usr/bin/duplicity", line 294, in write_multivol
    globals.gpg_profile, globals.volsize)
  File "/usr/lib/python2.5/site-packages/duplicity/gpg.py", line 279, in
GPGWriteFile
    data = block_iter.next(min(block_size, bytes_to_go)).data
  File "/usr/lib/python2.5/site-packages/duplicity/diffdir.py", line
505, in next
    result = self.process(self.input_iter.next(), size)
  File "/usr/lib/python2.5/site-packages/duplicity/diffdir.py", line
187, in get_delta_iter
    for new_path, sig_path in collated:
  File "/usr/lib/python2.5/site-packages/duplicity/diffdir.py", line
265, in collate2iters
    relem1 = riter1.next()
  File "/usr/lib/python2.5/site-packages/duplicity/selection.py", line
174, in Iterate
    subpath, val = diryield_stack[-1].next()
  File "/usr/lib/python2.5/site-packages/duplicity/selection.py", line
141, in diryield
    for filename in robust.listpath(path):
  File "/usr/lib/python2.5/site-packages/duplicity/robust.py", line 61,
in listpath
    dir_listing = check_common_error(error_handler, path.listdir)
  File "/usr/lib/python2.5/site-packages/duplicity/robust.py", line 37,
in check_common_error
    return function(*args)
  File "/usr/lib/python2.5/site-packages/duplicity/path.py", line 514,
in listdir
    return os.listdir(self.name)
KeyboardInterrupt
Exception exceptions.TypeError: "'NoneType' object is not callable" in
<bound method TemporaryDirectory.__del__ of
<duplicity.tempdir.TemporaryDirectory instance at 0x8922dac>> ignored
Exception exceptions.TypeError: "'NoneType' object is not callable" in
<bound method TemporaryDirectory.__del__ of
<duplicity.tempdir.TemporaryDirectory instance at 0x8922eac>> ignored
```

Story points: 10.0
duplicity fails on ERROR 30 TypeError (lp:#610603)

[Original report](https://bugs.launchpad.net/bugs/610603) created by **Serge Stroobandt (serge-stroobandt)**
```
Hi there,

Since recently, I am experiencing a problem with duplicity.
On an up-to-date bubba excito machine, duplicity fails to make a backup
on an ext3 mount and dumps the following error.

The only thing that I might have done wrong is that I have manually removed
previously failed backup archives because the disk was full.

Apparently, I am not the only one with this error.
See also deja-dup forum: https://bugs.launchpad.net/deja-dup/+bug/545486
What should I do to get my automated backups running again ???

NOTICE 1
. Reading globbing filelist /home/admin/.backup/weekly/excludeglob.list

NOTICE 1
. Reading globbing filelist /home/admin/.backup/weekly/includeglob.list

INFO 1
. Using temporary directory /tmp/duplicity-sc4Wlo-tempdir

ERROR 30 TypeError
. Traceback (most recent call last):
.   File "/usr/bin/duplicity", line 589, in ?
.     with_tempdir(main)
.   File "/usr/bin/duplicity", line 582, in with_tempdir
.     fn()
.   File "/usr/bin/duplicity", line 510, in main
.     globals.archive_dir).set_values()
.   File "/usr/lib/python2.4/site-packages/duplicity/collections.py", line
557,
in set_values
.     self.warn(sig_chain_warning)
.   File "/usr/lib/python2.4/site-packages/duplicity/collections.py", line
626,
in warn
.     + "\n" + "\n".join(self.other_sig_names),
. TypeError: bad operand type for unary +
.
```

Story points: 6.0
RFE: Method to list all files within a backup set (lp:#607670)

[Original report](https://bugs.launchpad.net/bugs/607670) created by **David Anderson (q-launchpad-net-dw-perspective-org-uk)**
```
I use duplicity for on-line backup.

Each time a full backup is done I also remove a previous full backup away
to off-line storage.

To do this, I use "ls -c" to list the files in order of date, and then
manually remove the old ones.

It would be very helpful if duplicity had the facility to list the complete
set of backup files in a particular set, i.e. in between full backups.

e.g.

duplicity list-duplicity-files -t 7D target_url

This would list all the signature files, archive, manifests, etc., that are
in the full backup set active 7 days ago and all increments up until the
next full backup set after that.
```

Story points: 12.0
rsync backend password file  (lp:#600391)

[Original report](https://bugs.launchpad.net/bugs/600391) created by **Orair (gustavo-orair)**
```
Actually I need to use duplicity to backup remotely. This backup will also
save my server's /etc directory.

As stated in https://help.ubuntu.com/community/rsync "The rsync daemon is
an alternative to SSH for remote backups. Although more difficult to
configure, it does provide some benefits. For example, using SSH to make a
remote backup of an entire system requires that the SSH daemon allow root
login, which is considered a security risk. Using the rsync daemon allows
for root login via SSH to be disabled."
So, I presumed I need to use duplicity through rsync backend and also use
gpg encryption to encrypt my backup files.

For security reasons I cannot pass any of my passwords by arguments in
command line to duplicity.
In the gpg-key case I need to create a gpg key and use --gpg-options '--
passphrase-file=${GPG_KEY}'.

But I need to make a similar procedure to rsync. So, I have password saved
in a file. The rsync utility provides the option --password-file to inform
the password saved in a file.
So, the following command will synchronize using rsync (/etc/password
contains the password):
rsync -avz --password-file /etc/rsyncd.password /backup/
user@backup_server::backup_module/etc

Then I need to pass the --password-file option to rsync backend in a
command such as the following:
duplicity  --gpg-options '--passphrase-file=${GPG_KEY}' --rsync-options '--
password-file /etc/rsyncd.password' /etc
rsync://user@backup_server::backup_module/etc

What is the correct way to do this?
Is there any other way to achieve my needs?

Best,
Orair.
```

Story points: 10.0
Some translations not installed (lp:#595974)

[Original report](https://bugs.launchpad.net/bugs/595974) created by **Gabor Karsay (gabor-karsay)**
```
Some translations are not installed, although they are translatable in
launchpad or there are po-files for them. This is probably because they are
missing in the po/LINGUAS file.

For example 0.7 series has
13 translatable languages in launchpad
9 po files in directory po/
7 languages in po/LINGUAS

The situation is similar in 0.6 series.
```

Story points: 4.0
error text when repository corrupt is misleading (lp:#591391)

[Original report](https://bugs.launchpad.net/bugs/591391) created by **matt.wartell (matt-wartell+lp)**
```
During a run of duplicity where the previous run had failed due to a key
error, I repeatedly hit the line:

   assert dup_time.curtime != dup_time.prevtime, "time not moving forward
at appropriate pace - system clock issues?"

when the fault was that "duplicity cleanup" needed to be run. I apologize
for not having saved logs. This bug could either be considered a
documentation bug or a call for more robust consistency checking of the
repository.

$ duplicity --version
duplicity 0.6.08b
$ python --version
Python 2.6.5
$ uname -a
Linux tallguy.local 2.6.32-22-core2 #33 SMP Tue May 25 08:51:25 EDT 2010
i686 GNU/Linux
# Ubuntu lucid with very minor kernel option changes

This is not related to (and happened prior to
https://bugs.launchpad.net/duplicity/+bug/591364)
```

Story points: 6.0
"DiffDirException: Bad tarinfo name" on diff. backup (lp:#575010)

[Original report](https://bugs.launchpad.net/bugs/575010) created by **Moritz Maisel (mail-maisel)**
```
After running for weeks without problems, differntial backup now fails
reproducible with the following traceback (also included the last 5 lines
of log-data):

---->8----*snip*----
tarfile: Bad Checksum
Removing still remembered temporary file /tmp/duplicity-ZDESlF-
tempdir/mkstemp-UP21kB-1
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1239, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1232, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1214, in main
    incremental_backup(sig_chain)
  File "/usr/bin/duplicity", line 478, in incremental_backup
    bytes_written = dummy_backup(tarblock_iter)
  File "/usr/bin/duplicity", line 160, in dummy_backup
    while tarblock_iter.next():
  File "/usr/lib/python2.6/dist-packages/duplicity/diffdir.py", line 505,
in next
    result = self.process(self.input_iter.next(), size)
  File "/usr/lib/python2.6/dist-packages/duplicity/diffdir.py", line 187,
in get_delta_iter
    for new_path, sig_path in collated:
  File "/usr/lib/python2.6/dist-packages/duplicity/diffdir.py", line 275,
in collate2iters
    relem2 = riter2.next()
  File "/usr/lib/python2.6/dist-packages/duplicity/diffdir.py", line 344,
in combine_path_iters
    refresh_triple_list(triple_list)
  File "/usr/lib/python2.6/dist-packages/duplicity/diffdir.py", line 330,
in refresh_triple_list
    new_triple = get_triple(old_triple[1])
  File "/usr/lib/python2.6/dist-packages/duplicity/diffdir.py", line 316,
in get_triple
    path = path_iter_list[iter_index].next()
  File "/usr/lib/python2.6/dist-packages/duplicity/diffdir.py", line 236,
in sigtar2path_iter
    raise DiffDirException("Bad tarinfo name %s" % (tarinfo.name,))
DiffDirException: Bad tarinfo name
.purple/logs/jabber/bar@domain.com/.system/20000000000000000000000000000000000000000000000000000
---->8----*snip*----

(Note: I replaced mail and im IDs due to privacy concerns. If you need
"real" data I can provide that via PM.)

To me it looks like duplicity is expecting some file named
".purple/logs/jabber/bar@domain.com/.system/20000000000000000000000000000000000000000000000000000"
which does not exist.

System-info:
duplicity 0.6.08
Ubuntu karmic
Python 2.6.4
Target filesystem is FTP
```

Story points: 6.0
Dropbox Backend App Key got lost in 0.7.0 (lp:#1388600)

[Original report](https://bugs.launchpad.net/bugs/1388600) created by **mm (mtl-0)**
```
Hi!

After upgrading to 0.7.0 my dropbox backend seems to be broken. When I try
to backup to dropbox duplicity states the following error:
Attempt 1 failed. ErrorResponse: [403] u"Invalid app key (consumer key).
Check your app's configuration to make sure everything is correct."
Attempt 2 failed. ErrorResponse: [403] u"Invalid app key (consumer key).
Check your app's configuration to make sure everything is correct."
Attempt 3 failed. ErrorResponse: [403] u"Invalid app key (consumer key).
Check your app's configuration to make sure everything is correct."
Attempt 4 failed. ErrorResponse: [403] u"Invalid app key (consumer key).
Check your app's configuration to make sure everything is correct."

I fixed it by inserting the old dropbox key in dpbxbackend.py and compiling
it.
```

Story points: 18.0
Unable to update to latest duplicity through apt-get (lp:#1387942)

[Original report](https://bugs.launchpad.net/bugs/1387942) created by **Gaurav Ashtikar (gau1991)**
```
Duplicity Version: 0.7.0-0ubuntu0ppa1012~ubuntu12.04.1
Python version: Python 2.7.3 (default, Feb 27 2014, 19:58:35)
OS: Ubuntu 12.04.5 LTS

Hi,
I was updating packages, thorugh apt-get upgrade, duplicity given me
following error:

Setting up duplicity (0.7.0-0ubuntu0ppa1012~ubuntu12.04.1) ...
SyntaxError: ('invalid syntax', ('/usr/lib/python2.7/dist-
packages/duplicity/backends/gdocsbackend.py', 51, 197, "        self.client
= gdata.docs.client.DocsClient(source='duplicity Usage: dpkg  Options:
parser options:                                      output formats,
defaults to 'dpkg'                                 for compatibility with
dpkg
than version
<number> is lower than 0)     ')\n"))

dpkg: error processing duplicity (--configure):
 subprocess installed post-installation script returned error exit status
101
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Errors were encountered while processing:
 duplicity
E: Sub-process /usr/bin/dpkg returned an error code (1)
```

Story points: 14.0