[SyncEvolution] Release preparations for 1.5.2

Patrick Ohly patrick.ohly at intel.com
Wed Oct 26 14:21:33 UTC 2016


On Sun, 2016-10-23 at 19:11 +0100, Graham Cobb wrote:
> On 23/10/16 15:51, Graham Cobb wrote:
> > I don't think that is a regression in this version (I guess the previous
> > version has the same problem), although until I can work out exactly
> > what is happening I can't be sure.  I will look into it a little further
> > but I may not be able to fix it before I go on holiday.  It might even
> > require proper protocol version handling (which we have avoided so far
> > -- see an earlier thread about EAS versions some time ago).
> 
> The problem turned out to be PolicyKey related (I hate "provisioning").
> This exchange server seems to handle the need for provisioning
> differently and doesn't send the 449 status unless you send a bad PolicyKey.
> 
> The workround is to make sure that the policy-key is configured in the
> account gsettings. Any non-null value will do, including 0. This
> triggers provisioning, which will end up eventually with a valid PolicyKey.
> 
> I have updated the wiki page to include setting that.

Thanks for the wiki update, that has already helped one person - myself!
I've signed up for a hosted Exchange 2016 service and (re-)enabled that
in the nightly testing, replacing gconftool-2 commands with gsettings
commands as per your instructions in the wiki.

I am using the policy-key workaround, but haven't actually verified
whether it is needed. 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?


> There are a few things that it might be nice to do one day (i.e. will
> never happen :-) )...

I have a similar list ;-}

> 1) The whole gsettings stuff should be hidden from the users, with some
> way to pass the necessary parameters from syncevolution.
>
> 2) I suspect that provisioning is now being triggered every time
> activesyncd is restarted as loading the account details from gsettings
> means activesyncd thinks the policy key has changed when it hasn't
> really.  We rely on this to get it set correctly the first time, but we
> ought to find a way to work out that it hasn't actually changed.
> 
> 3) The creation of Office365 means that for users using that service,
> all the required parameters (except password) can be defaulted sensibly
> if we know the email address. Maybe we should allow the case of
> specifying an account which has not been set up in gsettings to use the
> account name as an email address and then use the Office365 defaults.

The envisioned solution was some kind of external account setup, with
SyncEvolution completely hidden. All of these points would fit into such
a setup helper.

As it stands now, SyncEvolution is just some infrastructure component of
a larger system, with a command line for power users. The only problem
is that this larger system has never been implemented for most desktop
systems.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.






More information about the SyncEvolution mailing list