Re: [Duplicity-team] [Merge] lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity/0.7-series

2017-08-07 Thread Kenneth Loafman 
I used the diff and patched just giobackend.py.  Did not mean to mark rejected 
earlier.

-- 
https://code.launchpad.net/~mterry/duplicity/giobackend-display-name-0.7/+merge/328633
Your team duplicity-team is requested to review the proposed merge of 
lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity/0.7-series.

___
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

[Duplicity-team] [Merge] lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity/0.7-series

2017-08-07 Thread Kenneth Loafman 
The proposal to merge lp:~mterry/duplicity/giobackend-display-name-0.7 into 
lp:duplicity/0.7-series has been updated.

Status: Rejected => Merged

For more details, see:
https://code.launchpad.net/~mterry/duplicity/giobackend-display-name-0.7/+merge/328633
-- 
Your team duplicity-team is requested to review the proposed merge of 
lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity/0.7-series.

___
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

[Duplicity-team] [Merge] lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity/0.7-series

2017-08-06 Thread Kenneth Loafman 
The proposal to merge lp:~mterry/duplicity/giobackend-display-name-0.7 into 
lp:duplicity/0.7-series has been updated.

Status: Needs review => Rejected

For more details, see:
https://code.launchpad.net/~mterry/duplicity/giobackend-display-name-0.7/+merge/328633
-- 
Your team duplicity-team is requested to review the proposed merge of 
lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity/0.7-series.

___
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

[Duplicity-team] [Merge] lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity

2017-08-05 Thread Michael Terry 
Michael Terry has proposed merging 
lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity.

Requested reviews:
  duplicity-team (duplicity-team)

For more details, see:
https://code.launchpad.net/~mterry/duplicity/giobackend-display-name-0.7/+merge/328632

I was doing some testing on the google-drive: GIO backend (this is not the 
gdoc: duplicity backend, but rather using GNOME's abstraction layer to talk to 
Google through the giobackend code) and noticed some problems.

(A) Getting a list of files was broken because this backend chooses to use 
internal IDs for all its filename. Only the display_name() call gets the real 
user-set filename. Which, OK. We can use that instead. This will work for 
google-drive: as well as all other backends, since that is the 
user-set/user-visible name that we want to work with anyway.

(B) Getting files wasn't working because we had been passing NOFOLLOW_SYMLINKS. 
Apparently the google-drive: backend treats all internal files as symlinks to 
other internal files? Doesn't matter, we can avoid having to care about what a 
backup does in that regard by simply not passing that flag. It was a level of 
precaution that we don't really need. Normally, duplicity will always be 
dealing with real files. If it's trying to get a symlink, it's because the user 
manually created one. In which case, maybe we should follow it, since the user 
wants us to.

Together, these fixes let google-drive: work (and maybe other similarly bizarre 
GIO backends). I also tested on a couple other backends (SSH and local) and 
they worked fine still.
-- 
Your team duplicity-team is requested to review the proposed merge of 
lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity.
=== modified file 'CHANGELOG'
--- CHANGELOG	2017-07-20 12:06:01 +
+++ CHANGELOG	2017-08-05 22:24:26 +
@@ -1,4 +1,28 @@
+<<< TREE
 New in v0.8.00 (2016/07/??)
+===
+New in v0.7.14 (2017/07/??)
+---
+* Merged in lp:~dawgfoto/duplicity/skip_sync_collection_status
+  - collection-status should not sync metadata
+  - up-to-date local metadata is not needed as collection-status is
+generated from remote file list
+  - syncing metadata might require to download several GBs
+* Fixed slowness in 'collection-status' by basing the status on the
+  remote system only.  The local cache is treated as empty.
+* Fixed encrypted remote manifest handling to merely put out a non-fatal
+  error message and continue if the private key is not available.
+
+
+New in v0.7.13.1 (2017/06/18)
+-
+* Fixed problem in dist/makedist when building on Mac where AppleDouble
+  files were being created in the tarball.  See:
+  https://superuser.com/questions/61185/why-do-i-get-files-like-foo-in-my-tarball-on-os-x
+
+
+New in v0.7.13 (2017/06/12)
+>>> MERGE-SOURCE
 ---
 * Merged in lp:~aaron-whitehouse/duplicity/remove-python26
   - Remove Python 2.6 support references and tests.

=== modified file 'Changelog.GNU'
--- Changelog.GNU	2017-07-20 12:06:01 +
+++ Changelog.GNU	2017-08-05 22:24:26 +
@@ -1,3 +1,4 @@
+<<< TREE
 2017-07-20  Kenneth Loafman  
 
 * Fixed encrypted remote manifest handling to merely put out a non-fatal
@@ -31,6 +32,27 @@
   - Also see https://code.launchpad.net/~dawgfoto/duplicity/replicate/+merge/322836.
 
 2017-06-19  Kenneth Loafman  
+===
+2017-07-20  Kenneth Loafman  
+
+* Fixed encrypted remote manifest handling to merely put out a non-fatal
+  error message and continue if the private key is not available.
+
+2017-07-18  Kenneth Loafman  
+
+* Fixed slowness in 'collection-status' by basing the status on the
+  remote system only.  The local cache is treated as empty.
+
+2017-07-11  Kenneth Loafman  
+
+* Merged in lp:~dawgfoto/duplicity/skip_sync_collection_status
+  - collection-status should not sync metadata
+  - up-to-date local metadata is not needed as collection-status is
+generated from remote file list
+  - syncing metadata might require to download several GBs
+
+2017-06-18  Kenneth Loafman  
+>>> MERGE-SOURCE
 
 * Fixed problem in dist/makedist when building on Mac where AppleDouble
   files were being created in the tarball.  See:

=== modified file 'bin/duplicity'
--- bin/duplicity	2017-07-19 17:52:30 +
+++ bin/duplicity	2017-08-05 22:24:26 +
@@ -61,6 +61,7 @@
 from duplicity import tempdir
 from duplicity import util
 
+
 if '--pydevd' in sys.argv or os.getenv('PYDEVD', None):
 # The following is for starting remote debugging in Eclipse with Pydev.
 # Adjust the path to your location and version of Eclipse and Pydev.
@@ -1520,8 +1521,13 @@
 
 # get current collection status
 col_stats = collections.CollectionsStatus(globals.backend,
+<<< TREE

[Duplicity-team] [Merge] lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity

2017-08-05 Thread Michael Terry 
The proposal to merge lp:~mterry/duplicity/giobackend-display-name-0.7 into 
lp:duplicity has been updated.

Status: Needs review => Superseded

For more details, see:
https://code.launchpad.net/~mterry/duplicity/giobackend-display-name-0.7/+merge/328632
-- 
Your team duplicity-team is requested to review the proposed merge of 
lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity.

___
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

[Duplicity-team] [Merge] lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity/0.7-series

2017-08-05 Thread Michael Terry 
Michael Terry has proposed merging 
lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity/0.7-series.

Requested reviews:
  duplicity-team (duplicity-team)

For more details, see:
https://code.launchpad.net/~mterry/duplicity/giobackend-display-name-0.7/+merge/328633

I was doing some testing on the google-drive: GIO backend (this is not the 
gdoc: duplicity backend, but rather using GNOME's abstraction layer to talk to 
Google through the giobackend code) and noticed some problems.

(A) Getting a list of files was broken because this backend chooses to use 
internal IDs for all its filename. Only the display_name() call gets the real 
user-set filename. Which, OK. We can use that instead. This will work for 
google-drive: as well as all other backends, since that is the 
user-set/user-visible name that we want to work with anyway.

(B) Getting files wasn't working because we had been passing NOFOLLOW_SYMLINKS. 
Apparently the google-drive: backend treats all internal files as symlinks to 
other internal files? Doesn't matter, we can avoid having to care about what a 
backup does in that regard by simply not passing that flag. It was a level of 
precaution that we don't really need. Normally, duplicity will always be 
dealing with real files. If it's trying to get a symlink, it's because the user 
manually created one. In which case, maybe we should follow it, since the user 
wants us to.

Together, these fixes let google-drive: work (and maybe other similarly bizarre 
GIO backends). I also tested on a couple other backends (SSH and local) and 
they worked fine still.
-- 
Your team duplicity-team is requested to review the proposed merge of 
lp:~mterry/duplicity/giobackend-display-name-0.7 into lp:duplicity/0.7-series.
=== modified file 'duplicity/backends/giobackend.py'
--- duplicity/backends/giobackend.py	2016-01-29 11:43:58 +
+++ duplicity/backends/giobackend.py	2017-08-05 22:24:42 +
@@ -116,8 +116,11 @@
 
 def __copy_file(self, source, target):
 from gi.repository import Gio  # @UnresolvedImport
+# Don't pass NOFOLLOW_SYMLINKS here. Some backends (e.g. google-drive:)
+# use symlinks internally for all files. In the normal course of
+# events, we never deal with symlinks anyway, just tarballs.
 source.copy(target,
-Gio.FileCopyFlags.OVERWRITE | Gio.FileCopyFlags.NOFOLLOW_SYMLINKS,
+Gio.FileCopyFlags.OVERWRITE,
 None, self.__copy_progress, None)
 
 def _error_code(self, operation, e):
@@ -150,12 +153,18 @@
 def _list(self):
 from gi.repository import Gio  # @UnresolvedImport
 files = []
-enum = self.remote_file.enumerate_children(Gio.FILE_ATTRIBUTE_STANDARD_NAME,
-   Gio.FileQueryInfoFlags.NOFOLLOW_SYMLINKS,
+# We grab display name, rather than file name because some backends
+# (e.g. google-drive:) use filesystem-specific IDs as file names and
+# only expose the "normal" name as display names. We need the display
+# name, because we try to parse them. If the backend does this sort of
+# trickery, it will accept both versions of the filename, so we
+# shouldn't get into any trouble doing this.
+enum = self.remote_file.enumerate_children(Gio.FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME,
+   Gio.FileQueryInfoFlags.NONE,
None)
 info = enum.next_file(None)
 while info:
-files.append(info.get_name())
+files.append(info.get_display_name())
 info = enum.next_file(None)
 return files
 

___
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