[SyncEvolution] Release preparations for 1.5.2

[Graham Cobb]

On 26/10/16 15:21, Patrick Ohly wrote:
> I am using the policy-key workaround, but haven't actually verified
> whether it is needed. 

I haven't done exhaustive testing, but I think it is needed if the
policy-key in gsettings would otherwise be reset (i.e. null). In other
words, if you are completely deleting the gsettings and recreating them
you need something non-null in the policy-key.  If you are not
recreating them then they will already have a non-null (and possibly
even correct) value.

Yes, that raises the question of why the code doesn't check the value of
policy-key when it is loaded and change a null value to something else
(say 0)!

>With the work-around, I am running into a problem
> (see
> https://nightly.syncevolution.org/2016-10-26-05-27_exchange_sanity_release-eas-jessie-amd64_prebuilt-jessie-amd64_trusty-amd64/prebuilt-jessie-amd64/21-exchange/ and https://nightly.syncevolution.org/2016-10-26-05-27_exchange_sanity_release-eas-jessie-amd64_prebuilt-jessie-amd64_trusty-amd64/prebuilt-jessie-amd64/21-exchange/Client_Source_eas_contact_testImport.log.html): basically any attempt to create some item on the Exchange server fails with an error code 12 = GDBus.Error:org.meego.activesyncd.SyncError.FolderHierarchyChanged: Sync error: Mailbox folders are not synchronized, need FolderSync first
> 
> Here's a snippet from the activesyncd.log:
> 
> ...
> (process:111:0xf61d090): libeas-DEBUG:> POST /Microsoft-Server-ActiveSync?Cmd=Sync&User=nightly at ouvku.hostedoffice.ag&DeviceId=aaaaaaa99cb14effac6a8f447AAAAAAA&DeviceType=MeeGo HTTP/1.1
> (process:111:0xf61d090): libeas-DEBUG:> Soup-Debug-Timestamp: 1477486033
> (process:111:0xf61d090): libeas-DEBUG:> Soup-Debug: SoupSessionAsync 1 (0xf623b90), SoupMessage 10 (0x147a7170), SoupSocket 11 (0x147d23a0)
> ...
> (process:111:0xf61d090): libeas-DEBUG:Received 12 bytes for request 0x14793f00
> (process:111:0xf61d090): libeas-DEBUG:< HTTP/1.1 200 OK
> (process:111:0xf61d090): libeas-DEBUG:< Soup-Debug-Timestamp: 1477486034
> (process:111:0xf61d090): libeas-DEBUG:< Soup-Debug: SoupMessage 10 (0x147a7170)
> (process:111:0xf61d090): libeas-DEBUG:< Cache-Control: private
> (process:111:0xf61d090): libeas-DEBUG:< Content-Type: application/vnd.ms-sync.wbxml
> ...
> (process:111:0xf61d090): libeas-DEBUG:eas_connection - wbxml2xml++
> (process:111:0xf61d090): libeas-DEBUG:
> === dump start: xml_len [168] ===
> <?xml version="1.0"?>
> <!DOCTYPE ActiveSync PUBLIC "-//MICROSOFT//DTD ActiveSync//EN" "http://www.microsoft.com/">
> <Sync xmlns="AirSync:">
>   <Status>12</Status>
> </Sync>
> === dump end ===
> 
> That is with your "workround folder sync when server loses state" patch
> applied.
> 
> Any idea how to proceed with this? Is the policy-key workaround perhaps
> not working as intended?

No, it is nothing to do with policy-key.  That gives different symptoms:
either OK status but 0-length response or some 4nn status (419? I can't
remember).

It looks like the problem is that a FolderSync is needed. You need to
use --print-databases.  See the "Problems" in the Wiki page.

All my patch in bug 61869 does is enable --print-databases to be used as
a manual workround for this problem. It doesn't attempt to solve it
automatically.

If I remember correctly, one reason I didn't try to fix it automatically
is that I couldn't reproduce the problem! If you can reproduce the
problem reliably then maybe we can try to really fix it.

By the way, this raises a couple of interesting questions for your build
testing. The EAS support (in the backend and in activesyncd) keeps state
(in ~/.cache/activesync, in gsettings, and in the wallet). You might
want to think about whether your automated testing wants to make sure it
destroys all that state before running.

_______________________________________________
SyncEvolution mailing list
SyncEvolution at syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution