Package: duplicity Version: 0.7.16-1 Followup-For: Bug #890645 I see the same problem, having just upgraded testing.
This is a clear regression: there was no requirement for external libraries to use duplicity with B2 in previous versions of duplicity. Note that this will mean that anyone using duplicity in stretch for B2 will lose access to their data when upgrading to buster. Are the changes from 0.7.11-1 to 0.7.16-1 sufficiently important that this regression has to be implemented? If so, please make sure the README, and the buster release notes, warn about the loss of access to duplicity B2 data. Is there any information or testing on whether the out-of-repository workround described in the error message works? Please include the latest information on that in the README as well. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.utf8), LANGUAGE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.utf8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages duplicity depends on: ii gnupg 2.2.4-3 ii libc6 2.26-6 ii librsync1 0.9.7-10+b1 ii python 2.7.14-4 ii python-fasteners 0.12.0-3 ii python-lockfile 1:0.12.2-2 Versions of packages duplicity recommends: ii python-oauthlib 2.0.6-1 ii python-paramiko 2.0.0-1 ii python-pexpect 4.2.1-1 ii python-urllib3 1.22-1 ii rsync 3.1.2-2.1 Versions of packages duplicity suggests: ii lftp 4.8.1-1 pn ncftp <none> ii python-boto 2.44.0-1 pn python-cloudfiles <none> pn python-gdata <none> pn python-swiftclient <none> pn tahoe-lafs <none> -- no debconf information