2009/6/22 Peter Schuller :
> ~/.duplicity//cache - cache files, removable at any time
> ~/.duplicity//config - backup profile configs, etc
> ~/.duplicity//checkpoints - checkpoint info
That really should be:
$XDG_CACHE_HOME/duplicity/ (aka ~/.cache/duplicity/),
$XDG_CONFIG_HOME/duplicity/ (aka
2009/6/23 Kenneth Loafman :
> OK, I think the message is clear, but the problem is that adhering to
> standards after the fact is going to mean some extra coding to move
> files around during the first run of the new package. Maybe later.
Sounds like the smart-archive-dir already uses never-befor
2009/6/23 Kenneth Loafman :
> Easy enough to implement if its going to be useful. So far I'm not
> seeing much support for it. The next question is, since it's a
> freedesktop spec, does it also apply to servers? I would hate to see
> two solutions for one problem.
Yeah, it applies to servers.
2009/6/25 Kenneth Loafman :
> I'll make a 'stable' branch ending at 0.5.18 and leave 'trunk' as is.
There might be a slight advantage to making a '0.5' and '0.6' LP
series (for stability of URLs over time). I know that loses the
obvious hint that one is stable and one unstable, but that point cou
2009/6/25 Kenneth Loafman :
> No problem. I am having a bit of a problem with LP at the moment.
> Their inflexibility about deletions may mean that we can't use stable as
> the name of a branch. It appears that since I created and deleted two
> of them previously while learning the system, all of
** Changed in: deja-dup
Status: New => Invalid
--
Unable to backup
https://bugs.launchpad.net/bugs/388034
You received this bug notification because you are a member of
duplicity-team, which is subscribed to duplicity.
Status in Déjà Dup: Invalid
Status in duplicity - Bandwidth Efficient
2009/6/30 Kenneth Loafman :
> Or, should we check and refuse to run until synchronized?
This might be a good option if sync'ing is ever dangerous or the wrong
thing to do. So the user can check out the situation and see why
duplicity thinks things are out of sync. But I suspect it is safe?
-mt
2009/6/30 Kenneth Loafman :
> Should it be its own command, or is this something we just need to do
> automatically at the start of the run?
Speaking with my Deja Dup hat on (as always :)), if it wasn't run
automatically by duplicity, I would probably just run it myself on
every run. Just to make
Hello! I just updated the duplicity-team PPA for 0.6.01. (it may not
be visible this second on the PPA page, but they're all pushed)
Has this PPA been publicized? It probably should be (since it can be
kept up-to-date more readily than the existing public PPA for
duplicity -- the deja-dup PPA).
But the PPA on the website is the deja-dup one. I'm suggesting that
instead of linking to that, we link to the duplicity-team one. And
maybe announce the switch on the mailing list.
-mt
2009/7/1 Kenneth Loafman :
> It's mentioned on the website... is that what you meant?
>
>
2009/7/2 Kenneth Loafman :
> Thanks for doing the work on this! I'd like to work with you later to
> understand how to set this up so we can add the process to our dist/
> directory and do it all at once. I imagine we'll need a dist/debian
> directory and at least one script.
Yeah, that would ma
Can we turn off bugmail to this list? It's a little spammy.
Is the team subscribed explicitly to the mail? Or is it because the
team is 'bug supervisor' for the project?
If we need a bug supervisor team, maybe create a new team/mailing list?
-mt
___
So, just FYI about the translation support I enabled. Right now,
users that tell LP they speak a non-English language will have the
option to help translate Duplicity [1].
LP will update its idea of which strings are available and what is
translated every time we update the pot or po files in bzr
2009/7/10 Kenneth Loafman :
> Thoughts? Opinions?
I don't have much experience with packaging Python. I'm used to C and its ilk.
Maybe move duplicity-bin and rdiffdir into a bin subdirectory (and
rename duplicity-bin obvi)?
That's all I've got. :)
-mt
___
2009/8/4 Kenneth Loafman :
> What do you think should be the next major development thrust in
> duplicity? I've got some generic ones, but you're in the trenches with
> more users than I see, so let's hear from you and get something going.
Quick reply, maybe a more full one in time.
First, thank
2009/8/4 Larry Gilbert :
> (By the way, what do you think of Launchpad's "Blueprints" feature?
> Would that be a good venue for promoting ideas, or do you prefer we
> stick to the mailing list?)
Not to discourage use of it if ya'll find it useful, but I'll point
out that Blueprints is one of LP's
2009/8/5 Kenneth Loafman :
> So far, so good on the feedback. Don't be afraid to complain if I'm
> doing something wrong. I guarantee it won't be the first time.
Since you asked for complaints... :) I wanted to share my experience
with the new date format that went out a while ago. I don't kn
2009/8/6 Kenneth Loafman :
> I made the release on LP based on the following changes, no announcement
> yet, will wait for you guys to check it out. No surprises, but I'll
> start doing things this way so you have a first look. Will put this out
> in a week, or sooner if you want.
Will test, but
2009/8/6 Michael Terry :
> Will test, but unfortunately, I may not be able to get back to you in
> the next few days. I'm leaving tomorrow morning and may be busy.
I tested rev 589, and it seems fine to me. :)
+1 for release
-mt
___
M
2009/8/24 Rob Oakes :
> How does does the process work? Are newly detected files somehow added to
> the underlying "full" backup? Do the incremental snapshots exist in
> independence, each containing only the data about how files have changed
> relative to the full backup? Or do the incremental
2009/8/25 Kenneth Loafman :
> OK, I forgot about 0.5.19, spent most of last week wondering to myself
> what it was that I was supposed to get done and did not. This time I'm
> putting it on the calendar. A 3-day migraine makes one forgetful. ;-)
:-/ Suck.
> I've tested against the current tes
2009/9/7 Kenneth Loafman :
> Where to go?
I'm pretty happy with the state of duplicity these days. par2 would be nice.
Deja Dup's pet bugs would be 388725 and 432092. Deja Dup has issues
with its 'restore everything to /tmp and then move them out of there'
strategy if space is tight or dependin
Hello! I was talking to Rob Oaks from Time Drive a while back about
possibly merging efforts. That sort of broke down because I said I
was too invested in my 'call-duplicity-then-interpret-logs' method and
he was too invested in his 'use-duplicity's-Python-module' method.
But that got me thinking
Listing Old Files (defined to be files in a previous full backup) is
interesting to me. I'd like to get it to work, if possible.
I've looked at the code a bit, and I believe the following is true
(please correct if not):
1. There is one signature chain for each full backup chain
2. Filenames are
Ken: Please look at lp:~mterry/duplicity/list-old-chains -- it's a
first pass at keeping old chains and letting you list their contents.
The only missing bit from my perspective is an error if you try to
list from a backup chain that doesn't have a signature. I'll add that
and file a merge request
Ken, I'm not feeling much enthusiasm here for this from you. :) So
as I understand it, these are the suggested options:
Solution A: Always keep sig files. Con: Takes up space. (Do we have
any data for that for big backups?)
Solution B: Keep sig files if an option is passed (--keep-sigs?).
Con
2009/10/22 Kenneth Loafman :
> I like the idea of your Solution D. That would actually encourage
> people to run cleanup on a normal basis and that's a "good thing".
OK. I like it too. I'll work on a patch. If I can get it in 0.6.06,
I'd be extra pleased. What's my time window for that?
Woul
2009/10/22 Kenneth Loafman :
> I planned on putting out .06 at the "end of the week". I don't think a
> couple of days would matter much. What do you think you'll need?
I could have a patch for you by end of day (EST) Friday.
-mt
___
Mailing list: ht
2009/10/22 Kenneth Loafman :
> Fantastic! Go for it.
OK, merge requests filed. Works for me. Thanks, Ken!
-mt
___
Mailing list: https://launchpad.net/~duplicity-team
Post to : duplicity-team@lists.launchpad.net
Unsubscribe : https://launchpad.ne
2009/10/22 Kenneth Loafman :
> I planned on putting out .06 at the "end of the week". I don't think a
> couple of days would matter much. What do you think you'll need?
Not to be pesky or anything, but things didn't seem to go as planned?
Hope you're not busy fighting swine flu or anything, Ken!
2009/10/29 Kenneth Loafman :
> Life and hard drives got in the way. An old system of mine bit the dust
> and recovery was not as easy as I thought. I had a cascade of problems:
Heh, well at least I can assume you had good backups. :)
> 6) rebuild the system from scratch, Karmic of course.
W00
Is there a planned date for 0.6.07?
-mt
___
Mailing list: https://launchpad.net/~duplicity-team
Post to : duplicity-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~duplicity-team
More help : https://help.launchpad.net/ListHelp
Just an FYI, I tested the 0.6-series branch against my deja-dup test
suite today, thinking I'd try to catch some bugs before release.
Passed fine. :)
-mt
___
Mailing list: https://launchpad.net/~duplicity-team
Post to : duplicity-team@lists.launchpa
This is a known bug with 0.6.07. I will shortly update the PPA to use
the recently-released 0.6.08 which fixes the issue.
-mt
On 9 March 2010 09:52, Andrea Gelmini wrote:
> Goodmorning,
> I'm using your wonderful Duplicity since years.
> With latest update from you PPA (0.6.07-0ubuntu0karm
Packages are building now.
-mt
On 9 March 2010 10:41, Andrea Gelmini wrote:
> 2010/3/9 Michael Terry :
>> This is a known bug with 0.6.07. I will shortly update the PPA to use
>> the recently-released 0.6.08 which fixes the issue.
>> -mt
>
> Thanks a lot for
Question #103950 on Duplicity changed:
https://answers.edge.launchpad.net/duplicity/+question/103950
Michael Terry posted a new comment:
No! You're sure you have 0.6.08a and it's installed correctly?
There is a workaround: pass --gpg-options " " (a blank space).
But
Hello, Ken! I was curious about the plans around 0.7 and the timing
of its eventual release. Thinking about it loaded me with questions.
So here I go.
I know it has enhanced parity/checksum checking or some such? Are
there features we are waiting to bake or just waiting for the existing
feature
Michael Terry has proposed merging lp:~mterry/duplicity/backend-log-codes into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
Related bugs:
#578663 Use log codes for common backend errors
https://bugs.launchpad.net/bugs/578663
I've added some new error codes (and
I'm only proposing this for 0.7, but if you request, I can easily backport to
0.6. I'm not sure how much longer you plan to keep doing 0.6 releases.
--
https://code.launchpad.net/~mterry/duplicity/backend-log-codes/+merge/25373
Your team duplicity-team is requested to review the proposed merge o
On 15 May 2010 11:06, Kenneth Loafman wrote:
> As to snapshot tarballs, that would be nice. Is that something we could
> set up on LP for nightly or weekly builds. Could it be triggered only
> if there was a change?
Yes... There is a way of building daily builds from bzr called
bzr-builder [1]
OK, try lp:~mterry/duplicity/backend-log-codes2
I figured no reason to file new merge request? Same code, but not an upgraded
branch. Not sure how this branch got upgraded. I must have accidentally done
it...
"bzr help formats" says "The newest format, 2a, is highly recommended. If your
pro
Hello, Ken et al!
The Ubuntu One service is gaining support for remote-only files
(rather than synchronized files), and I'm getting user interest in
supporting that in Deja Dup. So the first step would be a backend for
Duplicity.
Ideally targeted for the 0.6.x line, as a new backend is unlikely
Michael Terry has proposed merging lp:~mterry/duplicity/backend-log-codes3 into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
--
https://code.launchpad.net/~mterry/duplicity/backend-log-codes3/+merge/42759
Your team duplicity-team is requested to review the proposed merge
Question #139342 on Duplicity changed:
https://answers.launchpad.net/duplicity/+question/139342
Status: Open => Answered
Michael Terry proposed the following answer:
The default for GPG appears to be CAST-128 (aka CAST5):
https://secure.wikimedia.org/wikipedia/en/wiki/CAST-128
--
Michael Terry has proposed merging lp:~mterry/duplicity/u1 into lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/u1/+merge/62128
Adds Ubuntu One backend.
--
https://code.launchpad.net/~mterry/duplicity/u1
Note that this requires trunk of the ubuntuone-couch module. So a little
difficult to test right now.
--
https://code.launchpad.net/~mterry/duplicity/u1/+merge/62128
Your team duplicity-team is requested to review the proposed merge of
lp:~mterry/duplicity/u1 into lp:duplicity.
___
Michael Terry has proposed merging lp:~mterry/duplicity/levelName into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/levelName/+merge/62226
I found this while messing with the Ubuntu One backend, because
Hello! I filed a couple branch merge requests last week, but realized
I never actually sent an email discussing them! Here we go.
So remember last November, when I said, "I'm working on U1 support,
when is the next release so I can squeeze it in?" Well... The U1
server just recently finally en
Awesome. Yes, the man page is updated in the branch.
-mt
On 31 May 2011 10:53, Kenneth Loafman wrote:
> Michael,
>
> I'll try to get it in the next release. Have you updated the man page
> and/or the README?
>
> ...Thanks,
> ...Ken
>
> On Tue, May 31, 2011
Michael Terry has proposed merging lp:~mterry/duplicity/gio-name into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/gio-name/+merge/63565
I've recently discovered that sometimes (at least on WebDAV)
Michael Terry has proposed merging lp:~mterry/duplicity/retry-decorator into
lp:duplicity with lp:~mterry/duplicity/gio-name as a prerequisite.
Requested reviews:
duplicity-team (duplicity-team)
Related bugs:
Bug #545486 in Duplicity: "Backup fails with 'Error: No data available
Hello! I was looking at
https://bugs.launchpad.net/deja-dup/+bug/487720 again, which I'll
summarize. If something goes wrong when backing up, a partial file
can get left on the backup target. This partial file confuses
duplicity and the sha1 sum for the partial file doesn't match what
duplicity
if ya like. I'm
also curious if you think there would be any side effects of redoing
the last block, with either version of the patch.
The simple patch is attached as well as a testing script to reproduce
the bug reliably.
-mt
On 7 June 2011 10:09, Michael Terry wrote:
> Hello! I w
Michael Terry has proposed merging lp:~mterry/duplicity/u1-status into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/u1-status/+merge/64404
Further testing with the u1 backend has revealed that the server
Ken, any comment on feasibility of this patch, perhaps in time for
this weekend's release?
-mt
On 7 June 2011 12:31, Michael Terry wrote:
> I have a potential fix... It's a bit hackish, but seems to work.
> Basically, when we resume, we just always redo the last block. There
&
On 14 June 2011 15:17, edso <504...@bugs.launchpad.net> wrote:
> ** Visibility changed to: Public
Arg! I didn't notice this bug was private before. But since this
public mailing list was getting the emails, seems that even private
bugs aren't very private.
I would suggest that this mailing list
Michael Terry has proposed merging lp:~mterry/duplicity/797758 into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
Related bugs:
Bug #797758 in Duplicity: "Duplicity ignores some FatalErrors"
https://bugs.launchpad.net/duplicity/+bug/797758
For more details,
Hello! I know Ken has been wanting an automated way to maintain the
PPA. With the relatively recent Launchpad feature of 'recipes', I
think we have it. I use them for Deja Dup for daily testing builds,
and they work great.
Basically, the way this will work on a new duplicity release is:
* bzr
Michael Terry has proposed merging lp:~mterry/duplicity/u1-ignore-404 into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/u1-ignore-404/+merge/65405
Ignore 404 errors when we try to delete a file on Ubuntu
Michael Terry has proposed merging lp:~mterry/duplicity/guard-tarinfo into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/guard-tarinfo/+merge/65688
A deja-dup user described a duplicity traceback that
Michael Terry has proposed merging lp:~mterry/duplicity/enotconn into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
Related bugs:
Bug #794576 in Duplicity: "Transport endpoint is not connected"
https://bugs.launchpad.net/duplicity/+bug/794576
For more de
Michael Terry has proposed merging
lp:~mterry/duplicity/look-at-partials-during-sync into lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
Related bugs:
Bug #703142 in Duplicity: "AssertionError: assert len(chain_list) == 2"
https://bugs.launchpad.net/duplicity/+
Michael Terry has proposed merging lp:~mterry/duplicity/more-accurate-sync into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/more-accurate-sync/+merge/68884
The current sync'ing code breaks down a b
Michael Terry has proposed merging lp:~mterry/duplicity/report-encrypted-chains
into lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/report-encrypted-chains/+merge/68885
For Deja Dup, I'm trying to su
Ahem, of course I meant "all of which need work..."
--
https://code.launchpad.net/~mterry/duplicity/report-encrypted-chains/+merge/68885
Your team duplicity-team is requested to review the proposed merge of
lp:~mterry/duplicity/report-encrypted-chains into lp:duplicity.
_
Michael Terry has proposed merging lp:~mterry/duplicity/815635 into
lp:duplicity with lp:~mterry/duplicity/more-accurate-sync as a prerequisite.
Requested reviews:
duplicity-team (duplicity-team)
Related bugs:
Bug #815635 in Duplicity: "Bad passphrase can leave bogus sigtar in ar
Michael Terry has proposed merging lp:~mterry/duplicity/retry-u1 into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/retry-u1/+merge/69780
I realized I never enabled retry code for the Ubuntu One backend
Michael Terry has proposed merging lp:~mterry/duplicity/818178 into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
Related bugs:
Bug #818178 in Duplicity: "Shouldn't try to delete files it knows don't exist"
https://bugs.launchpad.net/duplicity/+
Michael Terry has proposed merging lp:~mterry/duplicity/u1-fixes into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/u1-fixes/+merge/70359
This branch fixes some issues with the Ubuntu One backend.
- Adds
Michael Terry has proposed merging lp:~mterry/duplicity/another-non-2.4-ism
into lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/another-non-2.4-ism/+merge/72316
--
https://code.launchpad.net/~mterry
Oh. I accidentally pushed this to trunk. Whoops. Well, it's pretty innocent
and obvious change.
--
https://code.launchpad.net/~mterry/duplicity/another-non-2.4-ism/+merge/72316
Your team duplicity-team is requested to review the proposed merge of
lp:~mterry/duplicity/another-non-2.4-ism into
The proposal to merge lp:~mterry/duplicity/another-non-2.4-ism into
lp:duplicity has been updated.
Status: Needs review => Approved
For more details, see:
https://code.launchpad.net/~mterry/duplicity/another-non-2.4-ism/+merge/72316
--
https://code.launchpad.net/~mterry/duplicity/another-no
The proposal to merge lp:~mterry/duplicity/another-non-2.4-ism into
lp:duplicity has been updated.
Status: Approved => Merged
For more details, see:
https://code.launchpad.net/~mterry/duplicity/another-non-2.4-ism/+merge/72316
--
https://code.launchpad.net/~mterry/duplicity/another-non-2.4-
Michael Terry has proposed merging lp:~mterry/duplicity/early-catch-498933 into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/early-catch-498933/+merge/72607
This is a stop-gap measure for bug 498933
That is a good and sensible idea, but the current backend.list architecture
isn't well suited for that, performance wise.
(A) We can't ask for information about just one file, we have to list all files
each time
(B) We can't ask for size information. We'd have to download the file again.
Both
Due to conversations in the mailing list, I've retooled this branch to, instead
of using the system tarfile.py, just updating our internal copy to python2.7's
version (with changes for 2.4-compatibility).
Once we drop 2.4 support, it will be a simple change to drop our internal
version and use
For this specific purpose of verifying after each upload, we don't really need
list_extended(), but something like get_size(filename).
That way, it's easier to check after each volume.
--
https://code.launchpad.net/~mterry/duplicity/early-catch-498933/+merge/72607
Your team duplicity-team is req
The patch there looks invalid, because it looks like it just assigns more bits
in the tarfile for the gid/uid, which I don't think is part of the standard.
Though maybe I'm misinterpreting the patch.
However, I do think this branch would solve that bug, as newer tarfiles seem to
have explicit
> true but backends usually list all files anyway. dont they? .. ede
They do if you ask them to, and that's the only listing capability the current
Duplicity backend.py API has.
But if we're talking about adding to that API, I suspect most backends have a
"query info about a particular file" ca
ede, making resume optional is a good idea (maybe a --no-resume option). But
that's a separate bug/branch.
As for get_info() vs get_size(), I'm nervous about getting *all* infor we can.
That might be a lot, and some info is more or less expensive on different
backends.
See, for example, all
Heh, obviously that GFileInfo link should have been
http://developer.gnome.org/gio/stable/GFileInfo.html
--
https://code.launchpad.net/~mterry/duplicity/early-catch-498933/+merge/72607
Your team duplicity-team is requested to review the proposed merge of
lp:~mterry/duplicity/early-catch-498933 i
> this is a mapped list, right?
I'm not familiar with that term, but were you asking what I meant by
dictionary? I meant a python dictionary, like:
a = {'key': 'value'}
a['key'] == 'value'
> get_info("path/to/file", ("size","last_mod") )
With this API, you'll still have to handle the backend
> because it is the more elegant approach. you were worrying about too much
> info by default. ok, so
> we know which info we need, so let's request it. if we can't get it, we'll
> get a no key=>value pair
> for it, so we can deal with it.
My point was just, no matter what, some backends won't p
I feel like the importance of the details of the API design, while not a
trivial matter, has still been dwarfed by the amount of virtual ink we've
spilled. :)
I'm honestly fine with either way. I'd be willing to do the work for either
way. Maybe Ken can chime in with further suggestions or h
> would you be interested in implementing it in sftp or rather ftp? i could do
> one of those.
When we start a branch, we can push it under ~duplicity-team so we both have
access to it and can help flesh out the backends.
--
https://code.launchpad.net/~mterry/duplicity/early-catch-498933/+merge
I have a branch here:
https://code.launchpad.net/~duplicity-team/duplicity/check-volumes/+merge/72826
It's a work in progress, but has code for gio and local backends.
Since Ken wasn't big on specifying which bits you want, I didn't put
that in.
But I did put in support for backends specifying in
On 25 August 2011 14:38, Kenneth Loafman wrote:
> I thought I was pretty clear, all we need is file size in order to match
> what we expect to find.
Agreed. And that's all my branch does. Though it does use a
dictionary so we could add more in the future (which I thought you
wanted).
-mt
_
Michael Terry has proposed merging lp:~mterry/duplicity/cloudfiles-10k into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
Related bugs:
Bug #832149 in Duplicity: "Uploads to Rackspace fail silently"
https://bugs.launchpad.net/duplicity/+bug/832149
For more de
Having added and tested query support to the Ubuntu One, Rackspace, Amazon S3,
GIO, and local backends, I'm marking this branch 'ready for review'.
Edso said he'd look into sftp/ftp later as well.
--
https://code.launchpad.net/~duplicity-team/duplicity/check-volumes/+merge/72826
Your team duplic
Michael Terry has proposed merging lp:~duplicity-team/duplicity/check-volumes
into lp:duplicity.
Requested reviews:
Michael Terry (mterry)
For more details, see:
https://code.launchpad.net/~duplicity-team/duplicity/check-volumes/+merge/72826
This is the first pass of checking each volume&#
> did you see my comment on
> https://code.launchpad.net/~duplicity-team/duplicity/check-volumes/+merge/72826
> ?
Yes. The code gracefully handles backends that don't support querying
metadata. It only declares a volume corrupt if the backend successfully
determined size (or lack of a file alt
I'll mark this branch 'rejected' as it has been superseded by the merged
check-volumes branch.
--
https://code.launchpad.net/~mterry/duplicity/early-catch-498933/+merge/72607
Your team duplicity-team is requested to review the proposed merge of
lp:~mterry/duplicity/early-catch-498933 into lp:dup
The proposal to merge lp:~mterry/duplicity/early-catch-498933 into lp:duplicity
has been updated.
Status: Needs review => Rejected
For more details, see:
https://code.launchpad.net/~mterry/duplicity/early-catch-498933/+merge/72607
--
https://code.launchpad.net/~mterry/duplicity/early-catch-
Michael Terry has proposed merging lp:~mterry/duplicity/partial-encryption into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
Related bugs:
Bug #838264 in Duplicity: "Duplicity thinks partial encrypted backups are not
encrypted"
https://bugs.launchpad.net/dupl
Michael Terry has proposed merging
lp:~mterry/duplicity/fix-local-backend-validation into lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
For more details, see:
https://code.launchpad.net/~mterry/duplicity/fix-local-backend-validation/+merge/74222
Looks like I forgot to
Michael Terry has proposed merging lp:~mterry/duplicity/rbNoneNone into
lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
Related bugs:
Bug #835892 in Duplicity: "duplicity crash: "AssertionError: rb None None""
https://bugs.launchpad.net/duplicity/+
Michael Terry has proposed merging
lp:~mterry/duplicity/check-passphrase-on-restart into lp:duplicity.
Requested reviews:
duplicity-team (duplicity-team)
Related bugs:
Bug #878964 in Duplicity: "Resuming a backup with a different password should
throw an error"
https://bugs.lau
Hello! I'm at UDS this week and Canonical has been talking about new
acceptance criteria for package updates landing in main and testing
requirements for projects they write. This is going to affect the
Ubuntu packaging work I do on duplicity (as well as the work I do on
deja-dup).
Basically the
Can we re-examine whether duplicity-team should be the Answer Contact
in Launchpad?
I don't mean to sound user-hostile, but I feel like the Question
emails make this list low signal/high noise (for those that might not
be as interested in user support).
I feel like the topics are often better sui
On 2 November 2011 13:51, wrote:
> On 02.11.2011 18:18, Kenneth Loafman wrote:
>> How could we get the Answer Contact to be the mailing list? If so, then
>> that would be better.
I'll create a ~duplicity-talk team owned by ~duplicity-team, set its
contact address to duplicity-t...@nongnu.org,
1 - 100 of 272 matches
Mail list logo
