duplicity (3.0.3.2-1) unstable; urgency=medium

  this build does not include any python libraries beyond the absolute
  minimum needed for typical backends. (the newest python build infrastructure
  seems to insist in packaging everything and the kitchen sink. i do not
  agree with that. a plain duplicity installation should not pull
  in 170+ fairly obese packages.)

  please consult requirements.txt for the required dependencies, should you
  want to use duplicity with optional backends (ie. backends other
  than file, imap, rsync, scp, sftp, we3bdav).

 -- Alexander Zangerl <az@debian.org>  Sun, 29 Dec 2024 21:42:18 +1000

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 <az@debian.org>  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 <az@debian.org>  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 <az@debian.org>  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 <az@debian.org>  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 <az@debian.org>  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 <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