duplicity (0.8.22-1) unstable; urgency=medium upstream's requirements.txt is now included in /usr/share/doc/duplicity, and should help with figuring out any dependencies for optional duplicity modules. -- Alexander Zangerl Sun, 01 May 2022 17:23:30 +1000 duplicity (0.8.04-1) unstable; urgency=high duplicity is now built with and for python 3. if you are using one of the backends that require unpackaged external python modules, then you'll have to (re)get those with pip3 (e.g. cloudfiles, backblaze b2). -- Alexander Zangerl Mon, 23 Sep 2019 00:31:51 +1000 duplicity (0.7.17-1) unstable; urgency=medium backblaze backend changes since version 0.7.15 duplicity requires external, unpackaged modules to access backblaze storage: to use backblaze storage you will have to apt-get install python-pip and use pip to install the python 'b2' modules. -- Alexander Zangerl Sun, 18 Mar 2018 17:44:24 +1000 duplicity (0.7.03-1) unstable; urgency=low include/exclude behaviour include and exclude filelist now support globbing, but the behaviour has changed somewhat: please refer to /usr/share/doc/duplicity/changelog.gz (and the duplicity manpage) for further details. -- Alexander Zangerl Sun, 07 Jun 2015 13:13:05 +1000 duplicity (0.7.02-1) unstable; urgency=low scp:// access and restricted shells Version 0.7 is pickier about commands failing on a target host, and aborts in that case. This will affect you if you are using a restrictive shell like rssh together with scp:// access, as duplicity will try to check and mkdir the backup dir using an interactive ssh connection - which rssh disallows. (scp does not have any facility for directory listings or creation.) Solution: use the sftp:// access mechanism. -- Alexander Zangerl Wed, 25 Mar 2015 21:14:10 +1000 duplicity (0.6.20-3) unstable; urgency=low Duplicity and locales This version of duplicity completely ignores your locale settings and uses POSIX instead, because under some locales (e.g. fr_FR.utf8) the logger causes duplicity to crash (see bug #682837). -- Alexander Zangerl Tue, 05 Mar 2013 12:43:16 +1000 duplicity (0.6.18-4) unstable; urgency=low Reworked Ubuntu One backend This version includes a reworked standalone backend for Ubuntu One, which no longer requires Gnome, an X11 session or software that's not packaged for Debian. The backend requires the python-oauth and -httplib2 packages and duplicity therefore now recommends them. Check the man page for details about Ubuntu One authentication. -- Alexander Zangerl Thu, 18 Oct 2012 13:07:36 +1000 duplicity (0.6.17-1) unstable; urgency=low New sftp/scp backend This version of duplicity comes with a new sftp/scp backend, which does no longer use sftp/scp client programs and pexpect but instead relies on paramiko, a python ssh+sftp implementation. The options --scp-command and --sftp-command are thus obsolete, ignored and a deprecation warning is shown if they are used. At this time the sftp/scp module supports only one ssh option (given in --ssh-options): -oIdentityfile=some_key_file All other ssh options are silently ignored. The dependencies have been updated: duplicity now recommends rsync and paramiko (covering the most common use cases) and suggests the required modules for all other supported storage backends. -- Alexander Zangerl Sun, 01 Jan 2012 16:04:13 +1000 duplicity (0.6.08b-1) unstable; urgency=low With 0.6.06 duplicity stopped removing old data properly, EXCEPT when one ran a cleanup option with --extra-clean enabled. Note that normal remove* ops are not sufficient for a proper clean. (the cause is changeset 616, lp:~mterry/duplicity/list-old-chains) This has lead to numerous problems wrt. the archive dir cache growing without bounds as well as some cache desynchronization issues. It's also extremely counter-intuitive: despite requesting removals not enough data is removed. Until upstream resolves this problem properly, the Debian version of duplicity now automatically and unconditionally runs a cleanup operation after a successful remove-older-than or remove-all-but-n-full operation. The definition of "successful" in this context: --force was enabled, and the remove op found something to remove. This forced cleanup is run with --extra-clean active. -- Alexander Zangerl Mon, 15 Mar 2010 20:52:56 +1000 duplicity (0.6.04-1) unstable; urgency=low The --archive-dir handling has changed substantially in 0.6, in ways that affect existing backups. Duplicity now requires an archive dir, and if you don't give it one explicitly it will use ~/.cache/duplicy/. To distinguish between multiple backups, a per-backup subdirectory of the archive dir is used. This suffix is a hash of the target url or can be set with --name. The suffix is ALWAYS ADDED, the archive dir itself is no longer used. Consequences: * If you have existing backups with an archive dir (where you had to specify unique archive dirs), you must add an appropriate --name to have duplicity use the right archive directory. Using your existing, specific --archive-dir and --name '' works. * If you do not do that or if you have no existing archive dir, then duplicity will create a new archive dir and synchronize/recreate the archive dir content from the remote repository. If you use encryption then the first duplicity run (attempting this resynchronization) will fail unless you give it the encryption passphrase (or access to and passphrase of the relevant gnupg key) - local archive dir contents are not encrypted but remote repositories are. For existing backups I'd highly recommend that you run a collection-status first, with the appropriate --archive-dir and --name. It may pay off to ls the archive dir afterwards, confirming that no unintended --name subdirs have been created. After that step any required resynchronizations should be complete and duplicity should again work fine for unattended backups with or without encryption. -- Alexander Zangerl Fri, 31 Jul 2009 10:50:30 +1000