duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

Larry Gilbert wrote:
> In the trenches with users?  In my case, I *am* the user. :-)

OK, welcome aboard.

> (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?)

Putting it in Blueprints would be a good idea for now, with a note on
the mailing list to let us know its there.

> There's the I18N/L10N angle.  You probably noticed already that it's
> an area I'm very interested in. :-)  Any work to be done in this area,
> I'm happy to tackle it.

Very good, we can use all the help we can get.

> Being able to divide a backup set across more than one target at a
> time would be cool.  I wrote more about this:
> https://blueprints.launchpad.net/duplicity/+spec/redundancy

That's kind of the approach Tahoe takes and we have a backend for it.

As to multiple targets, hmmm, we can discuss it.  My normal approach,
and the approach I recommend is to use duplicity to backup locally, then
rsync that backup to a remote store.  That avoids a lot of the hassle of
network errors causing duplicity to fail.  Checkpoint/Restart will help
in that now, but I still think local then remote is the way to go.

> What do others think about a duplicity config file?  There are certain
> options I use all the time.  I suppose they could be handled with
> aliases, but the current CLI doesn't seem compatible with use of a
> single, simple alias.  Also, are there Windows users in the house?
> I'm not sure Windows has anything akin to "alias" in its shell.

I would love to see a config file for all of the options, and I think
with the named backups we have now, we could do that.  It would mean a
consistent set of options between runs.

Not sure we need multi-level config file parsing, but ConfigParser will
handle that as well.

> Migrating the GnuPG code to GPGME might lessen the headache of keeping
> up with GnuPG (if it is a headache?).  See:
> 
> http://www.gnupg.org/gpgme.html
> https://launchpad.net/pygpgme

Looked at it earlier, but its either C or Ruby, no Python bindings.  Its
not really an issue on keeping up with gnupg, they don't release often.

> I wanted to suggest migrating to setuptools to take advantage of some
> of its cool features.  However, I just learned that the project has
> reached a watershed: development has stagnated, users have alleged
> neglect on the part of the maintainer, and someone has forked it to a
> new project ("distribute") to get caught up on bugs it's accumulated.
> So maybe it's a good time to wait on that.

That reminds me of one thing we do need to add to the list of things to
do, rework the install to match what the package managers (deb, rpm) do.
 If someone installs from the tarball then from the repository, chances
are really good that there will be a /usr/bin/duplicity and a
/usr/local/bin/duplicity, both at different versions.  That can cause
some really confusing problems since installs have gone to the Windows
method of splattering things all over the system.

...Ken