Uh-oh, thanks for reporting it....

(In reply to Dan Jacobson from comment #0)
> And also
> ** (ephy-profile-migrator:7802): WARNING **: Failed to clear the password
> schema: Timeout was reached

This seems like gnome-keyring misbehaving; I don't think it's our fault.

> ** (epiphany:7800): WARNING **: Failed to upload batch. Status code: 400,
> response: 8

This one's probably caused by the failed migration:

(In reply to Dan Jacobson from comment #0)
> After
> upgrade epiphany-browser:amd64 3.26.2-1 3.26.4-1
> one sees three of
> (ephy-profile-migrator:7802): GLib-GIO-CRITICAL **: g_settings_set_value:
> key 'sync-history-time' in 'org.gnome.Epiphany.sync' expects type 'x', but a
> GVariant of type 'd' was given

What went wrong here is that the 3.26.4 migration is incompatible with the 3.26.3 migration, migrate_sync_settings_path(). migrate_sync_settings_path() assumes that the setting it's migrating from (a double) has the same type as the new setting, which used to be double as well, but it's now an int. So we need to get the double out of the GVariant, convert it to an int, and create a new GVariant using the old settings. Gabriel, do you want to work on this and test it out?

Fortunately, as long as we get this fixed in 3.26.5, this will probably only affect Debian users, because Debian decided to skip 3.26.3. (It's also good for us that Debian skipped this release, because otherwise this problem would have taken a lot longer to find.)

(In reply to Dan Jacobson from comment #0)
> ** (epiphany:7800): WARNING **: Failed to upload batch. Status code: 400,
> response: 8

Status 400 is Bad Request, and response code 8 is invalid or badly-formed data. Seems that the previous errors propagated in such a way that some malformed data was uploaded to the sync storage server.

(In reply to Michael Catanzaro from comment #1)
]> What went wrong here is that the 3.26.4 migration is incompatible with the
> 3.26.3 migration, migrate_sync_settings_path(). migrate_sync_settings_path()
> assumes that the setting it's migrating from (a double) has the same type as
> the new setting, which used to be double as well, but it's now an int. So we
> need to get the double out of the GVariant, convert it to an int, and create
> a new GVariant using the old settings. Gabriel, do you want to work on this
> and test it out?

I'm not sure how to fix this if migrate_sync_settings_path() had already run and failed. Changing migrate_sync_settings_path() to convert from double to gint64 wouldn't be too late now?

> Fortunately, as long as we get this fixed in 3.26.5, this will probably only
> affect Debian users, because Debian decided to skip 3.26.3. (It's also good
> for us that Debian skipped this release, because otherwise this problem
> would have taken a lot longer to find.)

Why did Debian skip 3.26.3?

(In reply to Gabriel Ivașcu from comment #2)
> I'm not sure how to fix this if migrate_sync_settings_path() had already run
> and failed. Changing migrate_sync_settings_path() to convert from double to
> gint64 wouldn't be too late now?

The case where the migration has already run and failed is probably unfixable. But you can fix migrate_sync_settings_path() for users who have not run that migration yet.

> Why did Debian skip 3.26.3?

Debian regularly skips releases; there's probably no particular reason for it.

Created attachment 365641 [details] [review]
profile-migrator: Fix migrate_sync_settings_path()

Account for the recent migration of sync timestamps from double to
gint64.

Review of attachment 365641 [details] [review]:

::: src/profile-migrator/ephy-profile-migrator.c
@@ +916,3 @@
+      type = g_variant_get_type (value);
+
+      /* All double values in the sync schema have been converted to gint64 recently. */

/* All double values in the old sync schema have been converted to gint64 in the new schema. */

Attachment 365641 [details] pushed as 7c3c01d - profile-migrator: Fix migrate_sync_settings_path()