OK, it took me all weekend and then some, but I think I've got a
somewhat functional rpm now. I uploaded what I've got so far to:
(Though it's not a Debian package, hopefully Debian won't mind me using
their web space for this...)
In theory, everything (including CardDAV and CalDAV) should work except
for SSO (and hence OAuth2), but I haven't yet tested much beyond
"syncevolution --export", will do that later.
Some notes on what is done:
* The D-Bus service is enabled in this build.
* On Sailfish, accessing PIM data requires being in the unix group
"privileged" (gid 998). I've thus made syncevo-dbus-helper sgid
privileged. (Not sure if it's cleaner to do that, or doing it to
syncevo-dbus-server. Also, perhaps there's a more elegant way than
making the executable sgid, but it works for now.)
* The Bluetooth support is disabled in this build. (After all, maybe
there's already a bluetooth SyncML on the phone? Haven't checked.)
* I have made no attempt to follow the Harbour rules, mostly because
they're ridiculous and violate the FHS for no good reason at all.
* Had to do some pkg-config magic in configure-sub.in (Qt5 seems to rely
on pkg-config a lot more than Qt4 did).
* I filter the contacts by SyncTarget "local", so that it won't try to
sync all your social media buddies. By default, Sailfish's backend
filters by SyncTarget "aggregate", so I have to use this filter even
from readItem (which already knows the luid it wants), since otherwise
the default filter will filter out the requested luid.
* The QtContacts API from Qt5 QtPIM turns out to be somewhat different
from the QtContacts API from Qt4 QtMobility. Some of the changes are:
- QtContacts luids are now strings, not integers (and the APIs for these
ids have been renamed from "LocalId" to just "Id"). The strings
the manager id, so they're surprisingly long strings...
- QtContacts no longer support adding arbitrary detail (the set of
supported detail types now appears fixed), all detail are indexed by
enums instead of strings. Hence, I've had to disable the
* mKCal for Qt5 required some more messing with pkg-config, but
otherwise, the code seemed to compile and work without modifications.
(Thus, haven't really checked whether I should have done any.)
* Haven't yet investigated what happens with notes - if they're stored
in mKCal anymore, perhaps support for them should be disabled?