Re: Duplicity-talk Digest, Vol 247, Issue 1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Duplicity-talk Digest, Vol 247, Issue 1

duplicity-talk mailing list
Hello all.  Long time lurker.  Just noticing the subject of modifying the
output reports that currently exist and attempts to change them.

I guess I have extensively used the current reports for checking on backup
status and determining pass or fail of individual backups.

If it would be possible to keep both the old and whatever becomes a new
parse able format, that would be wonderful.  If not, I will follow and
change to the new format when it goes live.

Thanks,
Kelly Black
(Back to lurking)

On Tue, 22 Jan 2019, [hidden email] wrote:

> Send Duplicity-talk mailing list submissions to
> [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
> or, via email, send a message with subject or body 'help' to
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Duplicity-talk digest..."
>
>
> Today's Topics:
>
>   1. Re: [ftplicity:feature-requests] #45 Feature: Parseable
>      output, especially dates (Marc Diethelm)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 21 Jan 2019 21:11:31 +0100
> From: Marc Diethelm <[hidden email]>
> To: [hidden email]
> Subject: Re: [Duplicity-talk] [ftplicity:feature-requests] #45
> Feature: Parseable output, especially dates
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello Ede / Duplicity-talk
>
> As you can see I just joined the mailing list. Thanks for inviting me.
> Hope I'm doing this right.
>
> So thanks for posting my thoughts from the duply thread. To reiterate a
> bit. I was surprised by the way the supposedly machine-readable output
> (using --log-fd or --log-file) looks. I find it not easy to parse at all.
>
> In the snippet posted by ede you find a possible sketch of what I
> believe would make parsing much more feasible.
> And being able to parse the output is in fact crucial to me.
>
> I have only marginal experience with Python unfortunately. My experience
> is in Node.js. But I'd like to help with this in any way I can.
>
> Regards, Marc
>
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Duplicity-talk mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>
>
> ------------------------------
>
> End of Duplicity-talk Digest, Vol 247, Issue 1
> **********************************************
>

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Duplicity-talk Digest, Vol 247, Issue 1

duplicity-talk mailing list
Hello all,

I have been thinking for a while that we need something more easily machine parseable -- even if just to aggregate information from multiple duplicity runs. My plan for it was to add a new --json flag or similar that spits out JSON or whatever can be easily consumed by other applications through familiar libraries but can also be extended.

From memory this will not be straightforward, as the current code spits things out in various places, rather than collating summary information and formatting it in one place.

Kind regards,

Aaron



_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Duplicity-talk Digest, Vol 247, Issue 1

duplicity-talk mailing list
On Mi, 2019-01-23 at 10:36 +0000, Aaron via Duplicity-talk wrote:
> Hello all,
>
> I have been thinking for a while that we need something more easily machine parseable -- even if just to aggregate information from multiple duplicity runs. My plan for it was to add a new --json flag or similar that spits out JSON or whatever can be easily consumed by other applications through familiar libraries but can also be extended.
>
> From memory this will not be straightforward, as the current code spits things out in various places, rather than collating summary information and formatting it in one place.

I am dreaming of a local installation of readthedocs and a converter which converts
duply output into something like the readthedocs build process logs

So - something more parseable like json would definitively be very welcome.


--
Wolfgang


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk