Yeah, I think so. Most of our warnings we deal with immediately.
On 7 February 2014 04:53, wrote:
> do i understand correctly? we currently have no such functionality, we
> would have to introduce it?
>
> e.g.
> - catch the error & set a globals.runtime_error var
> - on exit react on that var
do i understand correctly? we currently have no such functionality, we would
have to introduce it?
e.g.
- catch the error & set a globals.runtime_error var
- on exit react on that var
something like that? ..ede
On 06.02.2014 23:44, Michael Terry wrote:
> Wherever we currently log a warning du
Wherever we currently log a warning due to log.WarningCode.cannot_process,
we should note that we did it somewhere global (globals.py maybe) and at
the end of the run, if we flipped the "some file didn't process" bit, we
should log a message to the user to look up and see what's wrong.
On 5 Febru
Mike,
if you could give me some pointers i might be able to spare some time soonish.
..ede
On 05.02.2014 04:03, Michael Terry wrote:
> I can implement a warning at the end of any run that includes a skipped
> restored file, sure. But I'm not sure about timeframe.
>
>
> On 2 February 2014 09
I can implement a warning at the end of any run that includes a skipped
restored file, sure. But I'm not sure about timeframe.
On 2 February 2014 09:23, wrote:
> Mike,
>
> sounds like a fair compromise. as you are familiar with the issue, would
> you mind implementing it like this?
>
> ..ede
>
Mike,
sounds like a fair compromise. as you are familiar with the issue, would you
mind implementing it like this?
..ede
On 31.01.2014 14:15, Kenneth Loafman wrote:
> I agree. We try to exit with an error code, but I know we don't keep track
> of errors for later reporting. Perhaps just a me
I agree. We try to exit with an error code, but I know we don't keep track
of errors for later reporting. Perhaps just a message that says to examine
the log would suffice for now?
On Fri, Jan 31, 2014 at 7:12 AM, wrote:
> Ken,
>
> could you give your take on the below?
> i still feel duplici
Ken,
could you give your take on the below?
i still feel duplicity should exit with an error code after the restore and
mention the files it had problems with in the end. a warning i the middle might
be easily overlooked by the user.
..ede
On 23.01.2014 20:57, edgar.sol...@web.de wrote:
> act
actually we issue a warning only..
to put it in other words. finishing without a special hint could give a user
the impression that all files were restored fine (on the command line) which
they weren't. we should circumvent that.
..ede
On 23.01.2014 20:51, Michael Terry wrote:
> Interesting t
Interesting thought. We do issue a log message... And Deja Dup does
collect those and warn user at end. I hadn't thought of duplicity doing
that collating itself.
I don't know how I feel about an error exit code. I'm not sold, but I
don't feel strongly. Most error returns are currently for "c
On 23.01.2014 19:34, Michael Terry wrote:
> There is a separate but related patch in 0.6.23 that makes the bug less
> severe by letting the user restore the rest of the files that aren't affected
> (rather than aborting restore entirely):
> https://code.launchpad.net/~mterry/duplicity/catch-seq-c
/me hugs Kenneth
On 23 January 2014 13:24, Kenneth Loafman wrote:
> I'll work on getting the release out this afternoon, possibly tomorrow
> morning.
>
>
>
> On Thu, Jan 23, 2014 at 12:08 PM, Michael Terry wrote:
>
>> Just went through and found a few more dups. That should be all of
>> them.
I'll work on getting the release out this afternoon, possibly tomorrow
morning.
On Thu, Jan 23, 2014 at 12:08 PM, Michael Terry wrote:
> Just went through and found a few more dups. That should be all of them.
> I also tried to explain a bit more about the three symptoms and what a user
> can
Just went through and found a few more dups. That should be all of them.
I also tried to explain a bit more about the three symptoms and what a user
can do about it in the master bug.
On 23 January 2014 12:33, Michael Terry wrote:
> (Note that in explaining this to affected users, the fix does
Yes. It is the root cause to both those issues (I've marked as dups).
Anything that looks like:
assert len( patch_seq ) == 1, len( patch_seq )
or
assert first.difftype != "diff", patch_seq
or
librsync error 103 while in patch cycle
is fixed by this bug.
On 23 January 2014 12:21, wrote:
> i
(Note that in explaining this to affected users, the fix doesn't actually
get their data back. That's gone for good. But it helps avoid the bug for
the future.)
There is a separate but related patch in 0.6.23 that makes the bug less
severe by letting the user restore the rest of the files that a
is this possibly related to these new issues people showed up with on the list
as well?
1. https://answers.launchpad.net/duplicity/+question/242530
2. https://bugs.launchpad.net/duplicity/+bug/1271927
thx.. ede
On 23.01.2014 18:09, Michael Terry wrote:
> https://bugs.launchpad.net/duplicity/+bu
https://bugs.launchpad.net/duplicity/+bug/1252484
On 23 January 2014 11:51, wrote:
> On 23.01.2014 17:46, Michael Terry wrote:
> > Is there an ETA for 0.6.23? I'd like to see that data loss fix in the
> wild.
> >
> > (Ubuntu has it patched in as an update, so no pressure from my side
> really,
On 23.01.2014 17:46, Michael Terry wrote:
> Is there an ETA for 0.6.23? I'd like to see that data loss fix in the wild.
>
> (Ubuntu has it patched in as an update, so no pressure from my side really,
> but I still see the occasional question or bug filed about it. The sooner we
> get the fix o
Is there an ETA for 0.6.23? I'd like to see that data loss fix in the wild.
(Ubuntu has it patched in as an update, so no pressure from my side really,
but I still see the occasional question or bug filed about it. The sooner
we get the fix out the better.)
-mt
_
20 matches
Mail list logo
