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 <az@debian.org>  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 <az@debian.org>  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 <az@debian.org>  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 <az@debian.org>  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 <az@debian.org>  Fri, 31 Jul 2009 10:50:30 +1000