#4883 duplicity 0.7.11 update

[Scott Hannahs]

Here is the latest update to duplicity. It passes the -m build test with a few exceptions.

1. The testing phase creates and removes files of various ownership and cannot be ru "as nobody"
2. The testing phase needs more than the default 256 maxfiles in OS X.
3. The paramiko vesion 2 backend is not supported.

These items are noted in the packaging description.
Attached should be info file, patch file and dpkg output (in the next message)

[Scott Hannahs]

And here is the dpkg output as promised...

[Hanspeter Niederstrasser]

Was the downgrade from gnupg2 to gnupg-unified intentional?
Optional but preferable: can you change the *Depends: fields to use the multiline format in ABC order:

Depends: <<
    pkg1,
    pkg2
<<

instead? It makes tracking dependencies significantly easier.

[Scott Hannahs]

Hanspeter,

Here is an update with the perferred format. I did intend to use gpg-unified. I believe that the code does not use gpg2. Also since it is only compatible with parmiko version 2 I removed that backend.

[Hanspeter Niederstrasser]

What happens if someone has a non-Fink python2.7 first in the path? Will this affect all the #!/usr/bin/env python2.7 in the scripts? I think it would be better to change those to #!/sw/bin/python2.7 instead (I can do the change locally before committing).

[Scott Hannahs]

Ok, go ahead. Should that be a %p expansion since not all fink is in /sw? I was reluctant to hard code a path.

It should work with other installations of python27 so if someone boosted the priority of their version over the fink version then that is their issue. I am fairly sure it works with the stock python on OS X. I kept using 2.7 since that is on many legacy systems and it should be backwards compatible.

-Scott

On Feb 2, 2017, at 10:32 PM, Hanspeter Niederstrasser nieder@users.sf.net wrote:

What happens if someone has a non-Fink python2.7 first in the path? Will this affect all the #!/usr/bin/env python2.7 in the scripts? I think it would be better to change those to #!/sw/bin/python2.7 instead (I can do the change locally before committing).

[Hanspeter Niederstrasser]

You can use a @TOKEN@ in the patch file that is then replaced on the fly in PatchScript time with this construct:

sed 's|@PREFIX@|%p|g' < %{PatchFile} | patch -p1

Thanks for the package update.