No google authorization when doing a clean restore

Bug #1883254 reported by Kevin Zollman on 2020-06-12
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Déjà Dup
Undecided
Unassigned
deja-dup (Ubuntu)
High
Unassigned
Focal
High
Unassigned

Bug Description

[ Impact ]
Users with a backup on Google Drive may be confused when trying to restore from that backup on a fresh install.

With 40.6, they have to attempt a backup first to properly connect their Google account. But there's no suggestion that that is the right path.

Instead, a restore simply hangs with no feedback.

[ Test Case ]
On a fresh install, open Deja Dup, click the restore button, and notice that the progress bar never finishes.

[ Regression Possibility ]
The patch is pretty small, but technically does affect both restore and backup paths.

[ Original Report ]
I started a clean restore on a Virtual Machine without setting up a backup job first. The restore is from Google drive. When I click through it gets to the "Checking for backups" screen and just sits there. Eventually, I just canceled it. I think it's doing this because it doesn't yet have credentials to access the google drive, but also doesn't notice this fact or ask for them.

The bug can easily be solved by first starting a backup with google drive. Now it does notice that it needs credentials and starts that process. If I do that first, cancel the backup and then go back to the restore, things go better. The restore gets further along (although there's another bug we're discussing here that might be related to the VM).

The expected behavior for me at least is that even if you haven't set up a backup yet, if you try to do a restore from a Google drive Deja Dup should start the process of getting credentials to access the drive.

OS: Ubuntu 20.04
Deja-Dup: 40.6-1ubuntu2
Duplicity: 0.8.11.1612-1

Michael Terry (mterry) wrote :

Oooh excellent find. Let me try to reproduce and fix.

Michael Terry (mterry) wrote :
Changed in deja-dup:
status: New → Fix Committed
Michael Terry (mterry) wrote :

This bug is bad enough to deserve a patch release to our stable 40.x track too. I'll handle that later, but noting it here so I don't forget.

Michael Terry (mterry) wrote :

I had some extra time, so I released 40.7 with this fix.

https://gitlab.gnome.org/World/deja-dup/-/releases/40.7

Changed in deja-dup:
status: Fix Committed → Fix Released
Michael Terry (mterry) wrote :

I'm proposing this bug for an SRU to focal via an update to deja-dup 40.7.

description: updated
Changed in deja-dup (Ubuntu):
status: New → Fix Committed
importance: Undecided → High
Changed in deja-dup (Ubuntu Focal):
importance: Undecided → High
status: New → In Progress
Sebastien Bacher (seb128) wrote :

Thanks, new version uploaded to focal and groovy

Changed in deja-dup (Ubuntu Focal):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package deja-dup - 40.7-1ubuntu1

---------------
deja-dup (40.7-1ubuntu1) groovy; urgency=medium

  * New upstream version (lp: #1883254)
  * Resynchronize on Debian, remaining change
  * debian/control.in:
    - Suggests python3-pydrive, ideally that would be a recommends but
      the package needs to be promoted first
  * debian/patches/disable-google-drive.patch:
    - remove the patch disabling google drive, python3-pydrive is available
      now in focal
  * debian/rules:
    - set -Dpydrive_pkgs=python3-pydrive this way deja-dup knows how to
      install the pydrive backend on demand via packagekit

 -- Sebastien Bacher <email address hidden> Fri, 27 Mar 2020 12:31:06 +0100

Changed in deja-dup (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers