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