1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
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
|
