giseldo/neodataset huggingface dataset:
duplicity remove-all-but-n-full Fails with TypeError: an integer is required (lp:#1809851)

[Original report](https://bugs.launchpad.net/bugs/1809851) created by **Eric Koski (ekoski1)**
```
duplicity 0.7.17
Python 2.7.15rc1
Ubuntu 18.04LTS
ext4 filesystem

command-line output:

$ duplicity remove-all-but-n-full 1 --force file:///media/eric/Lnx_bk0
Synchronizing remote metadata to local cache...
GnuPG passphrase for decryption:
Copying duplicity-full-signatures.20171002T012817Z.sigtar.gpg to local
cache.
Copying duplicity-full-signatures.20180102T070445Z.sigtar.gpg to local
cache.
Copying duplicity-full-signatures.20180405T080021Z.sigtar.gpg to local
cache.
Cleanup of temporary directory /tmp/duplicity-j3izoa-tempdir failed - this
is probably a bug.
Traceback (innermost last):
  File "/usr/bin/duplicity", line 1555, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1541, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1393, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1414, in do_backup
    sync_archive()
  File "/usr/bin/duplicity", line 1204, in sync_archive
    copy_to_local(fn)
  File "/usr/bin/duplicity", line 1154, in copy_to_local
    tdp.move(globals.archive_dir.append(loc_name))
  File "/usr/lib/python2.7/dist-packages/duplicity/path.py", line 643, in
move
    self.copy(new_path)
  File "/usr/lib/python2.7/dist-packages/duplicity/path.py", line 463, in
copy
    self.copy_attribs(other)
  File "/usr/lib/python2.7/dist-packages/duplicity/path.py", line 470, in
copy_attribs
    util.maybe_ignore_errors(lambda: os.chmod(other.name, self.mode))
  File "/usr/lib/python2.7/dist-packages/duplicity/util.py", line 92, in
maybe_ignore_errors
    return fn()
  File "/usr/lib/python2.7/dist-packages/duplicity/path.py", line 470, in
<lambda>
    util.maybe_ignore_errors(lambda: os.chmod(other.name, self.mode))
 TypeError: an integer is required
```

Story points: 6.0
duplicity won't restore backup due to unknown error (lp:#1806466)

[Original report](https://bugs.launchpad.net/bugs/1806466) created by **mariana xavier (marianaxrp)**
```
Hello,

Last week I did a fresh install on my Ubuntu but now I can't restore the
backup I had made. I get the following error message:


Traceback (innermost last):
  File "/usr/bin/duplicity", line 1560, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1546, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1398, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1477, in do_backup
    restore(col_stats)
  File "/usr/bin/duplicity", line 733, in restore
    restore_get_patched_rop_iter(col_stats)):
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 558,
in Write_ROPaths
    for ropath in rop_iter:
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 521,
in integrate_patch_iters
    for patch_seq in collated:
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 389,
in yield_tuples
    setrorps(overflow, elems)
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 378,
in setrorps
    elems[i] = iter_list[i].next()
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 121,
in difftar2path_iter
    tarinfo_list = [tar_iter.next()]
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 339,
in next
    self.set_tarfile()
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 333,
in set_tarfile
    self.current_fp = self.fileobj_iter.next()
  File "/usr/bin/duplicity", line 769, in get_fileobj_iter
    backup_set.volume_name_dict[vol_num],
 KeyError: 1



 lsb_release -d
Description:    Ubuntu 18.04.1 LTS

 dpkg-query -W deja-dup duplicity
deja-dup        37.1-2fakesync1
duplicity       0.7.18.2+bzr1367-0ubuntu1~ubuntu18.04.1
```

Story points: 6.0
Backup fails with “zlib inflate problem: invalid stored block lengths” (lp:#1800139)

[Original report](https://bugs.launchpad.net/bugs/1800139) created by **rbuick (robert-buick)**
```
It fails backup with:
Backup Failed

GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
gpg: Fatal: zlib inflate problem: invalid stored block lengths
===== End GnuPG log =====

-----

Attempting to restore returns

Restore Failed

GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
gpg: Fatal: zlib inflate problem: invalid stored block lengths
===== End GnuPG log =====

------

lsb_release -d
Description:    Ubuntu 18.04.1 LTS
deja-dup        37.1-2fakesync1
duplicity       0.7.17-0ubuntu1

------

deja-dup.gsettings:

org.gnome.DejaDup last-restore ''
org.gnome.DejaDup periodic true
org.gnome.DejaDup periodic-period 1
org.gnome.DejaDup full-backup-period 90
org.gnome.DejaDup backend 'remote'
org.gnome.DejaDup last-run '2018-10-22T23:01:17.255583Z'
org.gnome.DejaDup nag-check '2018-10-08T14:09:09.699233Z'
org.gnome.DejaDup prompt-check 'disabled'
org.gnome.DejaDup root-prompt true
org.gnome.DejaDup include-list ['$HOME']
org.gnome.DejaDup exclude-list ['$TRASH', '$DOWNLOAD']
org.gnome.DejaDup last-backup '2018-10-22T23:01:17.255583Z'
org.gnome.DejaDup allow-metered false
org.gnome.DejaDup delete-after 0
org.gnome.DejaDup.Rackspace username ''
org.gnome.DejaDup.Rackspace container 'my-linux-pc'
org.gnome.DejaDup.S3 id ''
org.gnome.DejaDup.S3 bucket ''
org.gnome.DejaDup.S3 folder 'my-linux-pc'
org.gnome.DejaDup.OpenStack authurl ''
org.gnome.DejaDup.OpenStack tenant ''
org.gnome.DejaDup.OpenStack username ''
org.gnome.DejaDup.OpenStack container 'my-linux-pc'
org.gnome.DejaDup.GCS id ''
org.gnome.DejaDup.GCS bucket ''
org.gnome.DejaDup.GCS folder 'my-linux-pc'
org.gnome.DejaDup.Local folder 'my-linux-pc'
org.gnome.DejaDup.Remote uri 'smb://backup_nas/backup/'
org.gnome.DejaDup.Remote folder 'MacBook_linux'
org.gnome.DejaDup.Drive uuid ''
org.gnome.DejaDup.Drive icon ''
org.gnome.DejaDup.Drive folder 'my-linux-pc'
org.gnome.DejaDup.Drive name ''
org.gnome.DejaDup.GOA id ''
org.gnome.DejaDup.GOA folder 'my-linux-pc'
org.gnome.DejaDup.GOA type ''
org.gnome.DejaDup.File short-name ''
org.gnome.DejaDup.File type 'normal'
org.gnome.DejaDup.File migrated true
org.gnome.DejaDup.File name ''
org.gnome.DejaDup.File path 'smb:///home/me_as_a_user/deja-dup'
org.gnome.DejaDup.File uuid ''
org.gnome.DejaDup.File icon ''
org.gnome.DejaDup.File relpath@ ay []

--------

DEJA_DUP_DEBUG=1 deja-dup --backup | tail -n 1000 > /tmp/deja-dup.log

empty


---------

DEJA_DUP_DEBUG=1 deja-dup --restore | tail -n 1000 > /tmp/deja-dup.log

empty
```

Story points: 14.0
Add option to specify the DropBox upload chunk size (lp:#1795621)

[Original report](https://bugs.launchpad.net/bugs/1795621) created by **Pedro Gimeno (pgimeno)**
```
The current dpbxbackend.py code includes the following snippet:

# This is chunk size for upload using Dpbx chumked API v2. It doesn't
# make sense to make it much large since Dpbx SDK uses connection pool
# internally. So multiple chunks will sent using same keep-alive socket
# Plus in case of network problems we most likely will be able to retry
# only failed chunk
DPBX_UPLOAD_CHUNK_SIZE = 16 * 1024 * 1024

However, DropBox has a limit of 25,000 API calls per month per team. With
that chunk size, this means a maximum of about 390 GiB (419 GB) per month.

That turned out to be insufficient for us, and we spent all of our API call
quota for this month very quickly for this reason (it's October 2,
therefore the quota won't be reset for a whole month).

See https://www.dropbox.com/developers/reference/data-transport-limit for
more information about the limits and the best practices related to
division of files into chunks during uploads in Dropbox.

The upload chunk size should be changeable without editing the sources (a
command-line option would be ideal), and a notice should be added in the
man page stating this problem.

The suggested command line option is: --dropbox-upload-chunk-size

The suggested text for the man page is:

For the option:

        --dropbox-upload-chunk-size
              Defines the size in MB of each upload chunk for DropBox. Each
              chunk implies one API call, and the number of API calls may
be
              limited. Defaults to 16 MB. See also A NOTE ON DROPBOX
ACCESS.

For A NOTE ON DROPBOX ACCESS, add:

       4.     Note that there may be a limit to the number of API calls
that
              a Dropbox application may use per month. As of this writing,
              most account types have a limit of 25,000 API calls per
month.
              Files are uploaded in chunks, and each chunk upload effects
an
              API call, therefore you may need to adjust the option
              --dropbox-upload-chunk-size appropriately according to the
size
              of your backup.

I can try to come up with a patch, but not being familiar with the code or
the language, I can't guarantee it will be of sufficient quality.
```

Story points: 6.0
InvalidGrantError at every use of authenticated onedrive oauth (lp:#1792785)

[Original report](https://bugs.launchpad.net/bugs/1792785) created by **Jakob Böttger (jswiss)**
```
duplicity 0.7.18.1
Python 2.7.13
Debian 9.3
oauthlib (2.1.0)
requests-oauthlib (1.0.0)
request (1.0.2)

If you authenticate onedrive via oauth the .json is saved and the running
instance of duplicity is working. At the next use duplicity is always
failing with:

 Traceback (innermost last):
  File "/usr/local/bin/duplicity", line 1560, in <module>
    with_tempdir(main)
  File "/usr/local/bin/duplicity", line 1546, in with_tempdir
    fn()
  File "/usr/local/bin/duplicity", line 1385, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/local/lib/python2.7/dist-packages/duplicity/commandline.py",
line 1135, in ProcessCommandLine
    backup, local_pathname = set_backend(args[0], args[1])
  File "/usr/local/lib/python2.7/dist-packages/duplicity/commandline.py",
line 1010, in set_backend
    globals.backend = backend.get_backend(bend)
  File "/usr/local/lib/python2.7/dist-packages/duplicity/backend.py", line
223, in get_backend
    obj = get_backend_object(url_string)
  File "/usr/local/lib/python2.7/dist-packages/duplicity/backend.py", line
209, in get_backend_object
    return factory(pu)
  File "/usr/local/lib/python2.7/dist-
packages/duplicity/backends/onedrivebackend.py", line 90, in __init__
    self.initialize_oauth2_session()
  File "/usr/local/lib/python2.7/dist-
packages/duplicity/backends/onedrivebackend.py", line 127, in
initialize_oauth2_session
    self.http_client.refresh_token(self.OAUTH_TOKEN_URI)
  File "/usr/local/lib/python2.7/dist-
packages/requests_oauthlib/oauth2_session.py", line 309, in refresh_token
    self.token = self._client.parse_request_body_response(r.text,
scope=self.scope)
  File "/usr/local/lib/python2.7/dist-
packages/oauthlib/oauth2/rfc6749/clients/base.py", line 411, in
parse_request_body_response
    self.token = parse_token_response(body, scope=scope)
  File "/usr/local/lib/python2.7/dist-
packages/oauthlib/oauth2/rfc6749/parameters.py", line 379, in
parse_token_response
    validate_token_parameters(params)
  File "/usr/local/lib/python2.7/dist-
packages/oauthlib/oauth2/rfc6749/parameters.py", line 386, in
validate_token_parameters
    raise_from_error(params.get('error'), params)
  File "/usr/local/lib/python2.7/dist-
packages/oauthlib/oauth2/rfc6749/errors.py", line 415, in raise_from_error
    raise cls(**kwargs)
 InvalidGrantError: (invalid_grant) The user could not be authenticated or
the grant is expired. The user must first sign in and if needed grant the
client application access to the requested scope.
```
Original tags: oauth onedrive

Story points: 6.0
onedrive authentication fails (lp:#1777256)

[Original report](https://bugs.launchpad.net/bugs/1777256) created by **Louis Kirsch (louiskirsch)**
```
Trying to run a command with onedrive for the first time, e.g.
`duplicity list-current-files onedrive://backups`
triggers authentication correctly:
```
Could not load OAuth2 token. Trying to create a new one.
In order to authorize duplicity to access your OneDrive, please open XXX in
a browser and copy the URL of the blank page the dialog leads to.
```

and then after submitting the URL of the blank page crashes with
```
Traceback (innermost last):
  File "/usr/local/bin/duplicity", line 1555, in <module>
    with_tempdir(main)
  File "/usr/local/bin/duplicity", line 1541, in with_tempdir
    fn()
  File "/usr/local/bin/duplicity", line 1380, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/local/Cellar/duplicity/0.7.17/libexec/lib/python2.7/site-
packages/duplicity/commandline.py", line 1127, in ProcessCommandLine
    globals.backend = backend.get_backend(args[0])
  File "/usr/local/Cellar/duplicity/0.7.17/libexec/lib/python2.7/site-
packages/duplicity/backend.py", line 223, in get_backend
    obj = get_backend_object(url_string)
  File "/usr/local/Cellar/duplicity/0.7.17/libexec/lib/python2.7/site-
packages/duplicity/backend.py", line 209, in get_backend_object
    return factory(pu)
  File "/usr/local/Cellar/duplicity/0.7.17/libexec/lib/python2.7/site-
packages/duplicity/backends/onedrivebackend.py", line 90, in __init__
    self.initialize_oauth2_session()
  File "/usr/local/Cellar/duplicity/0.7.17/libexec/lib/python2.7/site-
packages/duplicity/backends/onedrivebackend.py", line 157, in
initialize_oauth2_session
    authorization_response=redirected_to)
  File "/usr/local/Cellar/duplicity/0.7.17/libexec/lib/python2.7/site-
packages/requests_oauthlib/oauth2_session.py", line 244, in fetch_token
    self._client.parse_request_body_response(r.text, scope=self.scope)
  File "/usr/local/Cellar/duplicity/0.7.17/libexec/lib/python2.7/site-
packages/oauthlib/oauth2/rfc6749/clients/base.py", line 409, in
parse_request_body_response
    self.token = parse_token_response(body, scope=scope)
  File "/usr/local/Cellar/duplicity/0.7.17/libexec/lib/python2.7/site-
packages/oauthlib/oauth2/rfc6749/parameters.py", line 376, in
parse_token_response
    validate_token_parameters(params)
  File "/usr/local/Cellar/duplicity/0.7.17/libexec/lib/python2.7/site-
packages/oauthlib/oauth2/rfc6749/parameters.py", line 406, in
validate_token_parameters
    raise w
 Warning: Scope has changed from "wl.skydrive_update wl.offline_access
wl.skydrive" to "onedrive.readwrite wl.skydrive_update wl.offline_access
wl.signin wl.skydrive".
```

Duplicity version: 0.7.17
Python version 2.7
OS Distro and version OSX
Type of target filesystem: OneDrive
```

Story points: 6.0
Backup chain corrupted due to scp failure (lp:#1776733)

[Original report](https://bugs.launchpad.net/bugs/1776733) created by **Bouke (bouke-haarsma)**
```
Today I've been trying to salvage some lost data using our duplicity
backups. However during the restoration I've run into the following error a
few times:

    Invalid data - SHA1 hash mismatch for file:
    duplicity-inc.20180601T033002Z.to.20180601T073003Z.vol16.difftar.gpg

Digging through the backup volumes, that specific increment caught my
attention:

    200M Jun  1 09:38 duplicity-
inc.20180601T033002Z.to.20180601T073003Z.vol15.difftar.gpg
     21M Jun  1 09:38 duplicity-
inc.20180601T033002Z.to.20180601T073003Z.vol16.difftar.gpg
    201M Jun  1 10:27 duplicity-
inc.20180601T033002Z.to.20180601T073003Z.vol19.difftar.gpg

Notably:

 - volume 16 is incomplete
 - volume 17 and 18 are missing

In the logs when creating that backup, the following relevant messages have
been outputted:

    Giving up after 5 attempts. BackendException: Error running 'scp
-oServerAliveInterval=15 -oServerAliveCountMax=2 /tmp/duplicity-
VA2x4D-tempdir/mktemp-fqSlsK-18 offsite-
backup.cb.local:/backup/dbs02r2.cb.local/duplicity-
inc.20180601T033002Z.to.20180601T073003Z.vol16.difftar.gpg'
    Giving up after 5 attempts. BackendException: Error running 'scp
-oServerAliveInterval=15 -oServerAliveCountMax=2 /tmp/duplicity-
VA2x4D-tempdir/mktemp-RbVN9m-19 offsite-
backup.cb.local:/backup/dbs02r2.cb.local/duplicity-
inc.20180601T033002Z.to.20180601T073003Z.vol17.difftar.gpg'
    Giving up after 5 attempts. BackendException: Error running 'scp
-oServerAliveInterval=15 -oServerAliveCountMax=2 /tmp/duplicity-
VA2x4D-tempdir/mktemp-SEdTr8-20 offsite-
backup.cb.local:/backup/dbs02r2.cb.local/duplicity-
inc.20180601T033002Z.to.20180601T073003Z.vol18.difftar.gpg'

For reference, the command used to produce this backup is:

    /usr/bin/duplicity --full-if-older-than 1M --encrypt-key XXXXXXXX
--max-blocksize 1048576 --gpg-options -z 1 --asynchronous-upload -v 8
--include /my/data --exclude ** /my pexpect+scp://offsite-backup//backup

Duplicity version: 0.7.15
Python version: 2.7.5
OS: CentOS 7.3 EL7 (centos-release-7-3.1611.el7.centos.x86_64)
Filesystem: XFS

Looking through the backup logs, I see quite a few of those "giving up"
messages. Probably those increments are corrupted as well. I'm starting to
lose my confidence in the backups produced by duplicity. I expect that when
an increment hasn't fully completed, duplicity would not continue to use
that increment for the backup chain.

Am I doing something horribly wrong, or is this expected behaviour from
duplicity?
```

Story points: 6.0
Not working with OneDrive/SharePoint for businesses (lp:#1757515)

[Original report](https://bugs.launchpad.net/bugs/1757515) created by **Fedaykin (fedaykin7c2)**
```
Duplicity (all versions) do not supports OneDrive for businesses.

My Univeristy  uses the SAML-based authentication, which Duplicity lacks.

This authentication requires a set of cookies to be passed. The basic idea
is that the browser should open the authentication site, which will ask for
credentials, such as username, password. Once the user is authenticated a
ticket will be generated and set as a cookie and a redirect is issued to
the original site, which now grants access based on the cookie.
```

Story points: 6.0
multi backend multiple oPort for sftp fails (lp:#1756718)

[Original report](https://bugs.launchpad.net/bugs/1756718) created by **madimadi (ubuntu-madi)**
```
When multibackend used for multiple sftp connection, sftp port value taken
multiple times into the sftp command for every SFTP instance configured in
JSON file.

Actual Example:
INFO 1
. Running 'sftp -oIdentityFile=/id_rsa -oTCPKeepAlive=yes -oPort=17032
-oServerAliveInterval=15 -oServerAliveCountMax=2 -oPort=11224
XXX@DOMAIM.COM
.....
INFO 1
. Running 'sftp -oIdentityFile=/id_rsa -oTCPKeepAlive=yes -oPort=17032
-oServerAliveInterval=15 -oServerAliveCountMax=2 -oPort=11224
YYY@OTHERDOMAIM.COM


So sftp will use only the first oPort value. As a result there's no way to
use individual tcp ports for each SFTP connection in multi backend.

The same for identity file. No support for providing multiple ssh identity.

duplicity 0.7.13.1
```

Story points: 6.0
Support named AWS profiles (lp:#1751881)

[Original report](https://bugs.launchpad.net/bugs/1751881) created by **John W. Lamb (jolamb)**
```
The AWS CLI config file format allows specifying multiple sets of account
credentials in the same file by placing them in unique INI sections:
<https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-
profiles.html>

The Boto library supports use of these named profiles via the
boto3.session.Session(..., profile_name="") named parameter:
<http://boto3.readthedocs.io/en/latest/reference/core/session.html>

There doesn't seem to be a means of providing the profile name for
s3/s3+http backup/restore in duplicity, but there should be. I would prefer
this capability versus various environment variable based options.
```

Story points: 6.0
Patch: add --compression-level option (lp:#1745582)

[Original report](https://bugs.launchpad.net/bugs/1745582) created by **B. Reitsma (breitsma)**
```
duplicity-0.7.16

I've created a small patch to make the compression level configurable.

$ diffstat -p1 compression_level.diff
 duplicity/commandline.py |    3 +++
 duplicity/globals.py     |    2 ++
 duplicity/gpg.py         |    2 +-
 3 files changed, 6 insertions(+), 1 deletion(-)
```

Story points: 6.0
It should batch-unfreeze glacier S3 objects to speed up restorations (lp:#1740833)

[Original report](https://bugs.launchpad.net/bugs/1740833) created by **Yajo (yajo)**
```
Scenario: Duplicity is configured with S3 backend, S3 is configured to move
objects to Glacier storage after 1 week, full backups are stored every
Sunday, partial backups happen once each night, today is Friday, the user
wants to restore a backup from last week's Wednesday.

User executes `duplicity [options] restore s3://bucket/folder /local/folder
--time 9D`.

What happens: The backup takes about 2-4 days to restore.

What should happen: The backup should take about 5-12h to restore.

Why it happens: Duplicity unfreezes (move from Glacier to Standard S3
storage mode) archives automatically (cool) one by one (not cool).
Unfreezing one archive can take usually 5-12h. Assuming you need to
unfreeze files from 4 days to get the full chain, that gives you a 20-48h
minimum wait, unless files are split into i.e. 200MB chunks, which can
produce more objects to unfreeze, summing extra 5-12h each.

Why it should not happen: If you go into S3 Management Console, you can
manually select as many Glacier files as you want and unfreeze them all at
once, having to wait those 5-12h, yes, but just once for all of them.
Duplicity should do that automatically through Boto too.

Thanks!
```

Story points: 12.0
KeyError: 56 (lp:#1731631)

[Original report](https://bugs.launchpad.net/bugs/1731631) created by **Kenneth Loafman (kenneth-loafman)**
```
Last run of Deja-dup has ended up with the following error:

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 1473, in do_backup
    restore(col_stats)
  File "/usr/bin/duplicity", line 729, in restore
    restore_get_patched_rop_iter(col_stats)):
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 558,
in Write_ROPaths
    for ropath in rop_iter:
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 521,
in integrate_patch_iters
    for patch_seq in collated:
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 389,
in yield_tuples
    setrorps(overflow, elems)
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 378,
in setrorps
    elems[i] = iter_list[i].next()
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 107,
in filter_path_iter
    for path in path_iter:
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 121,
in difftar2path_iter
    tarinfo_list = [tar_iter.next()]
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 339,
in next
    self.set_tarfile()
  File "/usr/lib/python2.7/dist-packages/duplicity/patchdir.py", line 333,
in set_tarfile
    self.current_fp = self.fileobj_iter.next()
  File "/usr/bin/duplicity", line 765, in get_fileobj_iter
    backup_set.volume_name_dict[vol_num],
 KeyError: 56

This is with 0.7.14+bzr1336-0ubuntu3~ubuntu17.10.1.
```
Original tags: artful

Story points: 6.0