[SyncEvolution] Re: new SyncEvolution binaries, dropping features?
On 24/07/2020 20:38, Patrick Ohly wrote: > [Most of the text below was written in December 2019, but than > unintentionally sent to an internal mailing list - no surprise that I > never got any response!] > > Hello! > > Over the Christmas holidays I worked on building a new SyncEvolution release. > My > current goal is to build for Ubuntu Bionic (most > recent LTS) and support those binaries on all more recent Debian and > Ubuntu releases. > > If possible, I'd like to drop unused features if they require extra > effort. This mostly depends if someone still needs them. Let me list > some features that I'd like to remove. If you still need them, please > respond here: > > * At the top of that list is ActiveSync support. activesyncd no longer > builds on Debian Stretch because it depends on libgnome-keyring, which > was removed. It probably can be ported to libsecret, but that's > extra work. I no longer need ActiveSync myself (my employer banned it a while ago and, more recently, I have retired anyway). I feel it is a shame to let it die and could probably be persuaded to do some work on it if someone actually wanted it and could provide me with access to systems to develop and test. But if no one wants to use it, there is no point. > * x86 (i.e. 32 bit) binaries - it doubles the testing effort. > > * RPMs - they never had proper dependencies and I am not sure whether > they ever worked at all. > > * Akonadi support and KDE in general. > > I first encountered problem with Akonadi in Debian Stretch and reported > it here with a stand-alone reproducer: > https://bugs.kde.org/show_bug.cgi?id=369203 > > But as pointed out in that issue, the API that SyncEvolution uses is no > longer supported and thus SyncEvolution would have to be ported to the > current API, whatever that is - I haven't investigated that. I gave up on the KDE PIM tools (and associated data) some time ago so I am no longer using this. > > * Port to Python 3 and stop supporting Python 2. > > Regarding the source code, I'd like merge all pending patches. This > obviously includes all the changes that are required to build on more > recent Linux distros, but also the C++ modernization that I started a > while back. > > The result will be more than just a simple bug fix release, but also not > something that has any new user-visible features. I'm not entirely happy > with that, but I also don't want to be stuck completely in pure > maintenance mode. > > I got testing on the newer Linux distros working with the updated code > base already beginning of this year, but then got stuck because of a > regression and lack of time to dig into that. Since then, the apt repo > keys expired and I haven't renewed them because the binaries probably > wouldn't work anyway. > > I suppose users would like to see binaries again, primarily because > SyncEvolution fell out of Debian/Ubuntu? Now that I am retired, I am not sure what my usage will be. My (new) master for contacts and calendar is in Owncloud/Nextcloud (mainly using Thunderbird as UI), however I haven't decided how I will keep various other devices synced (particularly Sailfish, if I continue to use that). I would find it convenient to have Debian binaries although I don't know if I will need them long term. I am disappointed, having worked on PIM sync for many years, that the world seems to be willing to settle for very limited and mostly locked up services from Microsoft, Apple or Android. ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Syncevolution in Windows 10 Subsystem for Linux running Debian
Just to note that I have managed to complete a simple proof-of-concept syncevolution run under Windows 10 WSL with Debian. All I did was a simple sync between a remote webdav server and local files, but it works. Apart from a small packaging problem (reported separately), the only real issues are the fact that it is headless and X Windows is not available. Two workrounds are needed for that: 1) Start dbus using: dbus-run-session -- bash 2) Start the gnome-keyring-daemon using: eval `echo password | gnome-keyring-daemon --unlock` Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Invalid signature for SyncEvolution 1.5.3 repo
On 28/02/2019 21:15, Patrick Ohly wrote: > Long story short, it should work again. Remember that as users you still > need to renew the signing key with: > sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 43D03AD9 Thanks Patrick, that works now. Now I have a different problem: using the 1.5.3 packages I can't get syncevolution to recognise the webdav backends (caldav or carddav). After some debugging, it seems there is a missing dependency on libneon27-gnutls. Installing that allows the webdav backends to be recognised (syncdav.so requires libneon-gnutls.so.27). Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] Invalid signature for SyncEvolution 1.5.3 repo
Hi, I wanted to try out syncevolution with the Windows 10 Debian environment. I tried following the instructions at https://syncevolution.org/blogs/pohly/2018/syncevolution-153, including using apt-key to import the signing key. That stage went fine, but I got the following error from apt-get update: Err:5 https://download.01.org/syncevolution/apt stable InRelease The following signatures were invalid: EXPKEYSIG 9B911472715D06C6 SyncEvolution Reading package lists... Done W: GPG error: https://download.01.org/syncevolution/apt stable InRelease: The following signatures were invalid: EXPKEYSIG 9B911472715D06C6 SyncEvolution E: The repository 'https://download.01.org/syncevolution/apt stable InRelease' is not signed. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] "Comparison was impossible" "
On 28/04/17 10:05, Patrick Ohly wrote: > On Fri, 2017-04-28 at 10:31 +0200, Vincent wrote: >> Could you tell me more about synccompare? > > In the syncevolution.org packages, it is under /usr/bin/synccompare. > It's a perl script that takes two database dumps and compares them, > similar to a diff between text files. I find it to be of variable usefulness. It is great when it works, but in my experience it scales horribly. I have to have it completely disabled on all my low-power systems (phones, etc) -- I have never had it run to completion on my Jolla phone, even leaving it overnight, so I just turn off comparison on those devices. Even on higher power systems it sometimes gets very confused and mixes up parts of different entries and ends up reporting all 2000 entries as different! I have it mostly turned off except when testing to see if changes are propagating as expected (or what changes are being lost as I do some one-way syncs). I think I always see "comparison was impossible" with refreshes. I assumed that is because the databases are deleted or something (although thinking about it further I am not sure that is a reasonable expectation). Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] [INFO] SoupTransport Failure
On 14/01/17 09:01, deloptes wrote: > I think your config is not good, but I have not idea how a carddav/caldav > setup should look like. sorry. I think you have to wait for someone more > experienced to assist, or go through the syncevolution guide again. Here is an example of my script for syncing between local files and Owncloud (using carddav/caldav). Although this is not using Evolution, it may help. By the way, I don't claim this is the only way, or that it is optimal or that every parameter is required -- my scripts have evolved over time! But the script below does work. Note: in that second command, that password= is empty (it is not that I removed a password). I don't remember if the empty password is needed or not. And, as deloptes says, if you are having problems and want to get more logs, replace the loglevel=1 with loglevel=4 below, and run the sync with SYNCEVOLUTION_DEBUG=1 (I also specify --daemon=no but that may be bacause I sometimes need to use gdb on the plugin). Look for logs in ~/.cache/syncevolution/ syncevolution --remove @Test_Files syncevolution --configure password= syncUrl=local://@Test_OC peerIsClient=1 loglevel=1 Test_OC@Test_Files syncevolution --configure sync=two-way uri=contacts loglevel=1 Test_OC@Test_Files contacts syncevolution --configure sync=two-way uri=business loglevel=1 Test_OC@Test_Files business syncevolution --configure sync=two-way uri=personal loglevel=1 Test_OC@Test_Files personal syncevolution --configure sync=two-way uri=calendar loglevel=1 Test_OC@Test_Files calendar syncevolution --configure --template none backend=file database=file:///home/cobb/SyncEvoData/contacts/ databaseformat=text/vcard @Test_Files contacts syncevolution --configure --template none backend=file database=file:///home/cobb/SyncEvoData/business/ databaseformat=text/vcard @Test_Files business syncevolution --configure --template none backend=file database=file:///home/cobb/SyncEvoData/personal/ databaseformat=text/vcard @Test_Files personal syncevolution --configure --template none backend=file database=file:///home/cobb/SyncEvoData/calendar/ databaseformat=text/calendar @Test_Files calendar syncevolution --remove @Test_OC syncevolution --configure --template none username= printChanges=1 dumpData=1 loglevel=1 target-config@Test_OC syncevolution --configure password= syncUrl=workround.gnome.keyring loglevel=1 target-config@Test_OC syncevolution --configure sync=two-way uri=contacts loglevel=1 target-config@Test_OC contacts syncevolution --configure sync=two-way uri=business loglevel=1 target-config@Test_OC business syncevolution --configure sync=two-way uri=personal loglevel=1 target-config@Test_OC personal syncevolution --configure sync=two-way uri=calendar loglevel=1 target-config@Test_OC calendar syncevolution --configure --template none backend=carddav database=https://x.y.net/owncloud/remote.php/carddav/addressbooks//contacts/ @Test_OC contacts syncevolution --configure --template none backend=carddav database=https://x.y.net/owncloud/remote.php/carddav/addressbooks//business/ @Test_OC business syncevolution --configure --template none backend=carddav database=https://x.y.net/owncloud/remote.php/carddav/addressbooks//personal/ @Test_OC personal syncevolution --configure --template none backend=caldav database=https://x.y.net/owncloud/remote.php/caldav/calendars//defaultcalendar/ @Test_OC calendar syncevolution Test_OC@Test_Files ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On 18/11/16 15:06, Patrick Ohly wrote: > SyncEvolution can be used in such a mode - one just needs a central hub > which supports the full semantic and attributes of everything that one > wants to sync, and the description of what each peer supports has to be > accurate. Unfortunately, in practice both conditions aren't completely > met. I don't think either condition is anywhere near being met. What backend would you suggest can be used which "supports the full semantic and attributes of everything that one wants to sync"? I am not aware of one, but I have only tried a few. The second condition is the most serious. In my experience of my many devices over the years, the question of support is the hardest. The combinations of design limitations, bugs and strange interactions (attribute X can't be set if attribute Y is set) is really hard to define. Even in the case where I knew the code intimately (the GPE implementation for Maemo) the description language could not express the restrictions I knew about (let alone the unknown bugs!). > The file backend is a bit limited in that it does not fully support > iCalendar 2.0 semantic. It can store individual VEVENTs, but it doesn't > know about relationships between items sharing the same UID. I'm not > sure anymore what the implication was in practice - might only be > relevant when dealing with peers which themselves do not support the > semantic. If I remember correctly, this restriction is an issue for recurrence exception handling. But I haven't looked into it recently. > I suspect the reason for the spurious changes was more related to poor > conversion between Outlook data formats and the master storage. As soon > as a peer is expected to store data correctly and then doesn't, that > undesired modification may get propagated back. There is certainly a serious issue with Outlook as some of the object semantics are just different from the implied semantics in the vformats and cannot be reliably converted. But I also see problems with Owncloud & KDE. It particularly affects non-standard attributes, which keep coming and going and never stabilise even when no changes are happening on any device. > That happens also in 1:1 syncs and is unrelated to multi-way syncing. In my experience it is a much smaller problem in 1:1 cases: typically things are either supported or not and the worst I see is that syncs may keep trying to set data which is being ignored -- but no database changes actually occur on either side if nothing has changed. In the multi-way case, that turns into the data changing with attributes toggling on and off or changing values as syncs with different devices occur, even when no data has actually changed. I haven't looked into it for some time but I seem to remember that it is partly due to the syncs not being part of a single sync but appearing to be subsequent events, making changes that then have to be propagated to other devices. I am not blaming SyncEvolution -- I am just not convinced that multi-way sync can ever be replaced by a series of two-way syncs. Maybe when I retire I will have time to do more work on this. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On 18/11/16 13:03, Patrick Ohly wrote: > With multi-way you mean a sync topology that has cycles? Yes, that's > indeed not possible with SyncEvolution. I also don't see a way to do it > as long as one is stuck with existing data formats. Actually, I meant even without cycles. It seems to me from my own experiments that it is impossible (in the real world) to keep N > 2 devices in sync just using pairwise syncs (assuming changes on any device, but disallowing conflicting changes). The main problem is different sets of supported attributes. That was the problem OpenSync tried to solve (with its centralised database and lists of supported attributes) but SyncEvolution ignores (a very reasonable but large simplification). I have tried to simulate this by using a files backend as a common point to synchronise everything with, but I still see a lot of spurious changes and corruptions being propagated around. That means that, for the time being, I am forced to treat Outlook as my master and only do one-way syncs from there to my other devices. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On 16/11/16 20:10, deloptes wrote: > Hi Graham, > they confirmed it is not working on SailFish - who knows when they will > implement it and how it will be implemented ... given the comments > above ... > Perhaps we have to work closer with the Jolla team on it. Or ... get proper > SyncEvolution backend for SailFish. I am sure I used to have a version of SyncEvo on my Jolla, due to the kindness of someone on the list who built it. I seem to remember it worked sort of -- was it for calendar or contacts? Anyway it stopped working (did Jolla change the underlying data store or something? I can't remember). I haven't bothered recently and have never even looked for it to try to install on my Jolla C. > For the time being I read the only supported way is via Cal/CardDav ... and > people reported to be using own service ... which s*cks ... I do sync with my personal owncloud instance so I have calendar and contacts in Cal/CardDav form. I have not got around to trying the Sailfish Cal/CardDav support to see if it works with owncloud but plan to when I have time. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On 16/11/16 08:43, Tino Mettler wrote: > On Wed, Nov 16, 2016 at 08:16:29 +0100, Patrick Ohly wrote: > > [...] > >> while Buteo was a "cleanly designed" framework which avoided doing >> any of the hard work and delegated that to "plugins". In other >> words, it didn't actually solve the problems. > > OpenSync reloaded? :-) Oooh, a bit of a low blow :-) I certainly learnt a lot from spending quite a lot of effort trying to make OpenSync work! The main one (and the main reason I am here) is that sync is **really** hard to do in the general case. Syncevolution does a great job on two-way sync but it would be really good to solve the multi-way problem one day :-) But that would require some significant work by a team who are willing to look at and learn from all the previous attempts. I sometimes wish Philippe Kahn had not lost interest in sync. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On 26/10/16 17:10, Patrick Ohly wrote: > I'll try that, thanks for the hint... yes, it helped. Good. > I'm now running into some new conversion issues for calendar data (time > zone related). To be checked. I can't say I am surprised. The time zone stuff is fairly fragile -- I seem to remember putting in some hacks to try to make the best of a bad job. Make sure that the timezone of the syncevolution system is the same as the timezone of the Outlook calendar that creates the events (I seem to remember there are some cases where I had to make that assumption, which is most likely true for most people). I have not seen any problems with Exchange syncs, although I am getting problems when I sync Exchange<->Files<->Owncloud. I think they are to do with handling exceptions in repeated events (the failing items are to do with repeating weekly meetings which I have been moving around in Outlook). But I am not sure if the real problem is creating bad files from the Exchange events or syncing the files with Owncloud. I have run out of time to look into it further before I go on holiday, unfortunately. But I really don't know if this is a regression -- my regular syncs had stopped working for some time (due to changes in our Exchange setup) and I (stupidly) didn't get them working again until after I had installed the 1.5.2 code. My suspicion is that it isn't a regression as there have been no changes in those areas (and the repeating event support is even more flakey than timezone support :-( ). Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
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=nigh...@ouvku.hostedoffice.ag=aaa99cb14effac6a8f447AAA=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] === > > "http://www.microsoft.com/;> > > 12 > > === 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@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
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. There are a few things that it might be nice to do one day (i.e. will never happen :-) )... 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On 23/10/16 10:51, Graham Cobb wrote: > I will try to find some time this week to copy libwbxml2.so.1 to my > jessie system and do some functional testing of the release. Hmm. Things are no longer working for me. HOWEVER, since I last tried, my employer has moved me to Office365!!! I strongly suspect that the problem I am now seeing is really to do with that. The user visible problem is that everything works (including listing folders) but whenever data is accessed Exchange returns success but no data (as if all the folders are empty). 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). Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On 21/10/16 19:46, Patrick Ohly wrote: > These are all problems which should have been caught by the automated > testing. I really need to sign up for some hosted Exchange service :-/ On that note, I am on holiday from Friday for 2 weeks. I am unlikely to be able to do any testing while I am away. I will try to find some time this week to copy libwbxml2.so.1 to my jessie system and do some functional testing of the release. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On 16/10/16 20:33, Patrick Ohly wrote: > I've update the "experimental" and "unstable" repo and published > versions 1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf (SyncEvolution) and > 0.92+20161014+SE+8918ba1 (activesyncd). > I have installed on my production (Debian Jessie) system. This installed (as expected) activesyncd-jessie 0.92+20161014+SE+8918ba1-1. However, this activesyncd seems to expect libwbxml2.so.1, which is not available in jessie (or stretch). I note that on my development system (running stretch) I have previously built that version of libwbxml2 and installed it into /usr/local. I have not yet tried copying it to my production system because I wanted to check with you first. It seems that your activesyncd packages cannot be used on Debian systems? To further complicate matters, it looks like the the previous activesynd-stretch package actually included that library file. Did you change that deliberately? > If you pull from "experimental", then please replace with "unstable": > the idea is that only I update from "experimental" and that "unstable" > will get the same update after some sanity checking. I didn't follow > that when announcing the version above, so if you now follow > "experimental", then please replace by "unstable". It seems that the versions you mention above are only present in "experimental", not "unstable". Is that what you intended? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On 07/10/16 12:19, Patrick Ohly wrote: > Sorry, forgot about that question: I granted your account additional > roles, so you should be able to edit > https://syncevolution.org/wiki/ms-exchange-and-kde-synchronization (and > other pages) now. Thanks. I have added the gsettings instructions now. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On 03/10/16 19:00, Graham Cobb wrote: > If you can build packages with the fixes to the two bugs I found I will > test them out (might not be until the end of the week, though). I think the two bugs (98014 and 98026) are all that are needed to avoid ActiveSync regrssion in 1.5.2. But I would be keen to test a fixed package, when you have it, on my production Debian Stable system (I have been testing on my Debian Testing system). > By the way, how should I go about updating my HOWTO on the Wiki (to add > the gsettings commands) now that the Wiki is no longer writable? Any thought on how I go about this? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On 03/10/16 13:39, Graham Cobb wrote: > I notice that there are a number of other warnings in the activesyncd > build. I am not sure I will get a chance to review them until next weekend. Actually there aren't that many. I reviewed them quickly and they all seem to be about deprecated Glib features. They should be addressed at some point but I don't think they are critical now. > Meanwhile, over the next few days, I will try to at least make sure that > I can run a few syncs with no other problems. I would like to convince > myself that the synckey problems I was seeing over the weekend were > testing artefacts rather than real problems. I have done a couple of runs and things are working. I think I got confused between refresh and one-way syncs when I was trying stuff at the weekend (empty responses are to be expected with one-way syncs if nothing has changed). If you can build packages with the fixes to the two bugs I found I will test them out (might not be until the end of the week, though). By the way, how should I go about updating my HOWTO on the Wiki (to add the gsettings commands) now that the Wiki is no longer writable? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On 02/10/16 23:04, Graham Cobb wrote: > On 02/10/16 14:39, Patrick Ohly wrote: >> On Sun, 2016-10-02 at 14:21 +0100, Graham Cobb wrote: >>> activesyncd now works without crashing. But it is being sent empty data >>> by the server. So some more work to do. >> >> Please share your progress. I consider this a 1.5.2 release blocker. > > Still working on it. > > I am seeing a few different issues but having some difficulty working > out how to reproduce them. > > The one I can most easily reproduce at the moment is a crash in > activesyncd when receiving some specific calendar data. The crash is in > icalproperty_set_value, called from > eas_cal_info_translator_parse_response handling unmapped data fields > (i.e. trying to create a X-MEEGO-ACTIVESYNCD- custom property). I have found this. See bug 98026. Sorry, I am travelling this week and am not set up to create a git commit for it but the fix is straightforward. I notice that there are a number of other warnings in the activesyncd build. I am not sure I will get a chance to review them until next weekend. Meanwhile, over the next few days, I will try to at least make sure that I can run a few syncs with no other problems. I would like to convince myself that the synckey problems I was seeing over the weekend were testing artefacts rather than real problems. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On 02/10/16 14:39, Patrick Ohly wrote: > On Sun, 2016-10-02 at 14:21 +0100, Graham Cobb wrote: >> activesyncd now works without crashing. But it is being sent empty data >> by the server. So some more work to do. > > Please share your progress. I consider this a 1.5.2 release blocker. Still working on it. I am seeing a few different issues but having some difficulty working out how to reproduce them. The one I can most easily reproduce at the moment is a crash in activesyncd when receiving some specific calendar data. The crash is in icalproperty_set_value, called from eas_cal_info_translator_parse_response handling unmapped data fields (i.e. trying to create a X-MEEGO-ACTIVESYNCD- custom property). I have not yet had time to build debug versions of all the code to step through this. I will have another go tomorrow if I get a chance. I have also seen a problem with sync keys: I have managed to get into a mode where EAS is rejecting the sync key but we are not managing to start again with a slow sync. I need to reproduce this again. The "empty data" problem I saw earlier may or may not be real. Again I need to try to reproduce it again. I am beginning to suspect that these latter 2 problems may be affected by the fact that my first tests were using "one-way-from-remote" syncs (as I wanted to keep the first tests simple). I am beginning to wonder if that mode prevents recovering from cases where activesyncd and Exchange end up out of sync with sync keys. But this is just speculation until I look into them further. I am concentrating on the icalproperty crash for now. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On 01/10/16 18:00, Graham Cobb wrote: > I have just tried to run a quick check that sync with Exchange > Activesync is working. It isn't (activesyncd is exiting due to a > "Trace/breakpoint trap"). OK, I have tracked that problem down. It is a packaging problem with the new GSettings schema files. See bug #98014. The account details now have to be setup using gsettings instead of gconf. I will need to update my instructions in the Wiki. activesyncd now works without crashing. But it is being sent empty data by the server. So some more work to do. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On 29/09/16 13:45, Patrick Ohly wrote: > Before I tag and release this as 1.5.2, it would be great to get some > feedback that this release doesn't cause regressions. In particular, > syncing with phones over Bluetooth needs some testing because there has > been one change that I couldn't fully test myself (only seems to make a > difference with some phones). I have just tried to run a quick check that sync with Exchange Activesync is working. It isn't (activesyncd is exiting due to a "Trace/breakpoint trap"). I will now need to work out what is going wrong. That will take me a bit longer as I will have to set up a proper test environment. Just thought I would send this note as a heads-up. Meanwhile I would like to know what the dbus-launch changes mean for running on headless systems (no X11). I previously used a version of dbus-session.sh from you. I still seem to need it. Is that the expected behaviour? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] survey: providing SyncEvolution binaries
On 22/08/16 14:22, Patrick Ohly wrote: > So let me ask: which distro do you need syncevolution.org binaries for? > Why? I meant to reply to this before. May not be needed now as you seem to have decided to build for Jessie and Stretch anyway... I find it useful to have precompiled binaries for Debian stable (my production system) and Debian testing (my development system). Of course, Tino provides packages but I have sometimes found it useful to be able to use your latest build before they have appeared in the distribution. I build my own versions when I am doing development. But I still find it convenient to have a "standard" version installed so I can compare behaviour :-) And just knowing that it is building for you is very helpful when it isn't building for me! So, I could certainly live without your builds -- Tino's packages would normally meet my needs and I could always build if I needed to. But I do use your versions and appreciate having them available. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] TDEPIM sync questions
On 06/02/16 09:56, deloptes wrote: > It does now exit, but staying there after > > Synchronization successfull > Changes applied > Data modified > *** @/addressbook *** > no changes I assume you meant "It does NOT exit". In my experience, the appearance of syncevolution not exiting is often due to the "changes" perl script which, in may case, can take a VERY long time. I don't remember the name of the script offhand but while it is "hung" you may want to see if there is a process running perl on your system. I recommend that while initially testing you set "printChanges=0" (if you have a lot of data you may want to set dumpData=0 as well, except when you really want to save the data). Turning off both those at least means you are really just testing the sync code. That may not be your problem at all, but it is worth checking. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Handling event changes from Exchange
On 16/07/15 23:06, Graham Cobb wrote: On 13/07/15 11:53, Patrick Ohly wrote: I also wonder whether the server can be told to avoid incremental updates in the first place. I will look into whether I can find out under what circumstances the Change is being sent and whether I can avoid it. It only occurs with very a small number of events (currently 2 out of over 2000 in my calendar) but I am not sure if it is to do with the event or the type of change, etc. It seems that there is no way to ask for the full event to be provided by the server. It always sends the Change message (unless you are doing a slow sync and reading everything). In most cases, that is not a problem: the documentation says that the object will be provided pretty much in full (fields not specified in the Change should be deleted), EXCEPT for a short list of special cases (for example, for emails, sending a change to the Read flag does not mean everything else should be deleted). Although the Attendee is NOT listed in the documentation as one of those special cases, it seems it really is: if the only change to the event is the attendee list, the whole event is NOT resent -- the client is supposed to just note the update to the attendee and not change anything else! To make matter worse, the EAS protocol has no way (at least in the older versions) to retrieve a particular event! The ONLY way to get a particular event using the EAS protocol is to use the slow-sync approach to download ALL events! So, my current thought is to add (yet another) hack: if a calendar event Change is received that does not include a StartTime then the whole update is ignored. This means that (in this case) the attendee change is ignored, but that is better than corrupting the whole event and losing all the information about it. The alternatives seem to be: never do syncs -- always download everything so we always get the full content of every event (very expensive, just to resolve an unusual corner case); or require a later protocol version (which seems to allow fetching specific items) and add more logic to re-fetch anything which appears to be an incremental update. Note: the latter is only based on my reading of the spec -- I have not tested that it really works. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Handling event changes from Exchange
On 13/07/15 11:53, Patrick Ohly wrote: If not, does activesyncd have to go and refetch the entire updated object from Exchange? I think that would be the more realistic solution. Thanks for the info. I had assumed that merge/change handling was not an option but thought I would check! I also wonder whether the server can be told to avoid incremental updates in the first place. I will do more investigation. I am not sure whether the behaviour is new (e.g. a new version of Exchange): I have recently changed the way I am using syncevolution across my different devices and only actually noticed the problem because the corrupted events fail to sync with Owncloud causing the sync operation to fail with an error (note: the EAS sync where the corruption occurs does not fail or produce any user-visible errors at all!). I will look into whether I can find out under what circumstances the Change is being sent and whether I can avoid it. It only occurs with very a small number of events (currently 2 out of over 2000 in my calendar) but I am not sure if it is to do with the event or the type of change, etc. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] Handling event changes from Exchange
I have just noticed that events are being corrupted when syncing from Exchange. The problem is that when an event changes, EAS can send a change notification, with only the fields that have changed, not the whole new event. activesyncd then creates a partial (and invalid!) VEVENT with only the changed fields. Syncevolution then replaces the event with just the information from the partial VEVENT, losing all the rest of the information. To make it clearer, here is an extract from the EAS protocol message sent when one attendee's status has to be updated for an existing event: Change ServerId1:2170/ServerId ApplicationData Attendees xmlns=Calendar: Attendee Attendee_Emaila...@example.com/Attendee_Email Attendee_Namea...@example.com/Attendee_Name Attendee_Status4/Attendee_Status Attendee_Type1/Attendee_Type /Attendee /Attendees /ApplicationData /Change activesyncd generates: 1:2170 BEGIN:VCALENDAR PRODID:-//Meego//ActiveSyncD 1.0//EN VERSION:2.0 METHOD:PUBLISH BEGIN:VEVENT ATTENDEE;CN=a...@example.com;PARTSTAT=DECLINED;ROLE=REQ-PARTICIPANT: a...@example.com END:VEVENT END:VCALENDAR And syncevolution ends up replacing the whole event with: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.47//EN BEGIN:VEVENT LAST-MODIFIED:20150710T132346Z DTSTAMP:20150710T132346Z UID:syuid320541.212303337826681 SUMMARY:unnamed ATTENDEE;CN=a...@example.com;PARTSTAT=DECLINED;ROLE=REQ- PARTICIPANT:mailto:a...@example.com END:VEVENT END:VCALENDAR The question is, what do I do about this? Is there any way for syncevolution to process updates and merge them with the existing object? If not, does activesyncd have to go and refetch the entire updated object from Exchange? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Valid VEVENT from activesyncd being converted to invalid VEVENT somewhere in syncevolution?
On 19/06/15 16:06, Patrick Ohly wrote: That DTSTART and DTEND then never gets parsed is a side effect of giving up the parsing. Wouldn't it be better to completely abort the processing and reject the object rather than generating a corrupted object when an error occurs? So the fix is to remove mandatory=1 and adapt the total counts in 11calendar-profile.xml for SUMMARY. You can do that locally by copying the attached modified file to $HOME/.config/syncevolution-xml/datatypes That works, thanks (note to anyone else applying this: you may need to create the directory). This obviously isn't a big issue as no one else seems to have come across it! I saw it in 2 out of 2200 events in my calendar. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] Valid VEVENT from activesyncd being converted to invalid VEVENT somewhere in syncevolution?
I have been trying to track down a problem that occurs when syncing my Exchange calendar with local files. I am ending up with a few events with missing DTSTART (which is invalid, of course). It looks as though activesyncd is providing a valid VEVENT to syncevolution: [I have removed ATTENDEE and PARTICIPANT lines and modified my email address] BEGIN:VCALENDAR PRODID:-//Meego//ActiveSyncD 1.0//EN VERSION:2.0 METHOD:PUBLISH BEGIN:VTIMEZONE TZID:(UTC) Dublin\, Edinburgh\, Lisbon\, BEGIN:STANDARD DTSTART:19701025T02 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:+0100 TZOFFSETTO:+ TZNAME:(UTC) Dublin\, Edinburgh\, Lisbon\, END:STANDARD BEGIN:DAYLIGHT DTSTART:19700329T01 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 TZOFFSETFROM:+ TZOFFSETTO:+0100 TZNAME:(UTC) Dublin\, Edinburgh\, Lisbon\, END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20140926T083807Z DTSTART;TZID=(UTC) Dublin, Edinburgh, Lisbon,:20141007T14 UID: 04008200E00074C5B7101A82E008B029262875D2CF0110 00DD0ECC59F4B59A4AA0DDF2797B886E40 LOCATION:Online Meeting DTEND;TZID=(UTC) Dublin, Edinburgh, Lisbon,:20141007T17 X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for DESCRIPTION property. Removing entire property: CLASS:PUBLIC TRANSP:OPAQUE X-MEEGO-ACTIVESYNCD-MeetingStatus:1 X-MEEGO-ACTIVESYNCD-NativeBodyType:3 ORGANIZER;CN=Graham Cobb:graham.c...@example.com BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:Reminder TRIGGER;VALUE=DURATION:-PT15M END:VALARM END:VEVENT END:VCALENDAR I believe that is a valid VEVENT, although note that it has neither a SUMMARY: nor DESCRIPTION: line. [The UID has wrapped in the email but is really formatted correctly] When the event is saved as a file it has become: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.47//EN BEGIN:VEVENT LAST-MODIFIED:20150618T220636Z DTSTAMP:20150618T220636Z UID:04008200E00074C5B7101A82E008B029262875D2CF01000 01000DD0ECC59F4B59A4AA0DDF2797B886E40 CLASS:PUBLIC TRANSP:OPAQUE SUMMARY:unnamed LOCATION:Online Meeting ORGANIZER;CN=Graham Cobb:mailto:graham.c...@example.com BEGIN:VALARM TRIGGER;VALUE=DURATION:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR Note that there is no DTSTART! (And the DTSTAMP has been set to the current time, and a fake SUMMARY has been created). The missing DTSTART makes the VEVENT invalid. Looking through the logs, I found this section during the parsing of the event: [...lots of timezone parsing...] lii[2015-06-18 23:06:36.192]/inbsp;span class=exoticparseMimeDir: VTIMEZONE with ID='(UTC) Dublin, Edinburgh, Lisbon,' parsed to internal time zone 'GMT'/span/li lii[2015-06-18 23:06:36.192]/inbsp;span class=exoticparseMimeDir: property DTSTART parsing delayed, rank=1/span/li lii[2015-06-18 23:06:36.192]/inbsp;span class=exoticparseMimeDir: property DTEND parsing delayed, rank=1/span/li lii[2015-06-18 23:06:36.192]/inbsp;span class=incomingparseMimeDir: property not parsed (unknown or not storable): X-LIC-ERROR;X-LIC-ERRORTYPE=VA/span/li lii[2015-06-18 23:06:36.192]/inbsp;span class=incomingparseMimeDir: property not parsed (unknown or not storable): X-MEEGO-ACTIVESYNCD-MeetingSta/span/li lii[2015-06-18 23:06:36.192]/inbsp;span class=incomingparseMimeDir: property not parsed (unknown or not storable): X-MEEGO-ACTIVESYNCD-NativeBody/span/li lii[2015-06-18 23:06:36.192]/inbsp;span class=errorparseMimeDir: missing 1 of 1 mandatory properies/span/li lii[2015-06-18 23:06:36.192]/inbsp;span class=errorFailed parsing item/span/li lii[2015-06-18 23:06:36.192]/inbsp;span class=script- PARSETEXTWITHPROFILE() function result = span class=value0/span (integer)/span/li lii[2015-06-18 23:06:36.192]/inbsp;span class=exotic- Evaluated unstored expression/span/li The two lines with class=error don't look good! I think this is a syncevolution bug, not an activesyncd bug. Do you agree, or am I missing something? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] Packages for jessie?
Now that jessie is the new Debian Stable, is anyone planning to build packages for jessie? I am particularly keen on an activesync configuration -- none of the activesyncd packages on http://downloads.syncevolution.org seem to be installable. I realise the answer may be that neither Patrick nor anyone else has time/interest/inclination but before I build them myself, it would be nice to know if there will be a standard version. I try to use standard packages on my internet server when possible and keep the home built versions just for my personal machines (partly to avoid the sorts of problems Daniel has just been having!). Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Calendar events one hour later than original
On 14/04/15 14:08, Daniel CLEMENT wrote: How could I force the use of this last path? Like Patrick, I normally debug with shared libs disabled. Unfortunately library searching has now become very complicated (well beyond my understanding, particularly with multiarch). However, I have, in the past, had success using: LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/lib (it needs to be put in front of the syncevolution command in the commandline). Try: LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/lib \ LD_DEBUG=files \ /usr/local/bin/syncevolution --daemon=no 21 \ | grep libsynthesis Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] First Monday of the month event problems
On 10/11/14 15:48, Patrick Ohly wrote: Yes, that's open. Unfortunately this is rather tricky to add. One would have to extend the internal representation inside libsynthesis (src/sysync/rrules.cpp) and also the conversion to/from iCalendar 2.0 and vCalendar 1.0. I have fixed the activesyncd handling but, of course, that just triggers this problem. Maybe, if it annoys me enough, I will have a look at it some time. I'm not sure how common it is. There haven't been that many complaints about it, but that's hard to quantify. I have two monthly meetings which use it. So, I get the meetings shown in every week and can only tell which one is real by looking at my Outlook calendar. I strongly suspect it is more common in business environments (I guess casual users are probably more likely to set such events by hand instead of using a rule). So, the number of people affected are probably a fairly small subset of syncevolution users. Hopefully one of us will get sufficiently fed up to fix it one day :-) ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] First Monday of the month event problems
I have noticed (bug #86102) that activesyncd is creating the wrong RRULE for recurrences of the form nth some-weekday. Without having looked at the code yet (just the logs) this looks like an activesyncd problem. But it looks like (bug #70693) even if I fix that, that the event still won't get synced correctly. Is #70693 still unfixed? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] SyncEvolution 1.5 released
Small issue with your (unsupported) packages... syncevolution-activesync-saucy depends on activesyncd-saucy with no version. It would be nice if the dependency could be versioned to the current latest version (in this case, the new version 0.92+20141031+SE+52a7436-1). That way, upgrading syncevolution-activesync would automatically pull in the new activesyncd. Graham P.S. I saw your review comment but I have been unable to get to it this week. Sorry. I plan to test the released 1.5 version first, and then fix the activesyncd logging problem. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] All day events from Exchange
On 29/10/14 07:25, Patrick Ohly wrote: What you propose seems like the best (okay, least evil) approach. Is this something that you want to work on soonish? I'm thinking about tagging and releasing an updated of SyncEvolution (either 1.4.99.5 or 1.5) and could include an updated activesyncd. I am away for a few days over this weekend. If I can get the change made today, and enough testing to convince myself it is no worse than not making the change, I will send you a patch before Friday. If not, or if it looks like it causes other problems, you might want to leave it for the next release where it can get more testing. In any case, I would like to see the British Summer Time timezone fix get into this release. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] All day events from Exchange
On 29/10/14 10:22, Graham Cobb wrote: I am away for a few days over this weekend. If I can get the change made today, and enough testing to convince myself it is no worse than not making the change, I will send you a patch before Friday. Patch added to the bug report. I have tested that it doesn't break events which were being handled correctly. And it certainly helps a lot with events where the eventual display is in the same time zone as Outlook was when the event was created -- they now appear at the correct time instead of on the wrong day (although they don't appear as real all day events, of course). I believe it is worth including. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] All day events from Exchange
On 28/10/14 08:59, Patrick Ohly wrote: On Mon, 2014-10-27 at 23:25 +, Graham Cobb wrote: On 20/10/14 13:02, Patrick Ohly wrote: On Mon, 2014-10-20 at 10:17 +0100, Graham Cobb wrote: I have just noticed, in my testing of 1.4.99.4, that all day events are not working properly. I don't suppose this is new in this version -- I probably didn't notice it before. Right. That code hasn't changed in quite a while. The relevant code to look at are the _eas2ical_convert_datetime_property() and _eas2ical_convert_component() methods activesyncd/eas-daemon/libeas/eas-cal-info-translator.c. I haven't yet changed any code but I have looked at the code and the logs. The situation is complicated slightly by the fact that we (in the UK) are now back on winter time, which is GMT (=UTC). However, I can reproduce the problem by looking at all day events set up for next summer. In the activesyncd log I can see the event coming in from EAS with: TimeZone xmlns=Calendar:ACgAVQBUAEMAKQAgAEQAdQBiAGwAaQBuACwAIABFAGQAaQBuAGIAdQByAGcAaAAsACAATABpAHMAYgBvAG4AL AoFAAIAACgAVQBUAEMAKQAgAEQAdQBiAGwAaQBuACwAIABFAGQAaQBuAGIAdQByAGcAaAAsACAATABpAHMAYgBvAG4ALAMFAAEAxP ///w==/TimeZone StartTime xmlns=Calendar:20150728T23Z/StartTime AllDayEvent xmlns=Calendar:1/AllDayEvent The start time is midnight local time (on the day of the event, 20150729, which is BST -- summer time). I also see, in the log... (process:16804:0xcb3c50): libeas-DEBUG:process timezone ACgAVQBUAEMAKQAgAEQAdQBiAGwAaQBuACwAIABFAGQAaQBuAGIAdQByAGcAaAAsACAATABpA HMAYgBvAG4ALAoFAAIAACgAVQBUAEMAKQAgAEQAdQBiAGwAaQBuACwAIABFAGQAaQBuAGIAdQByAGcAaAAsACAATABpAHMAYgBvAG4ALAMAAA AFAAEAxP///w== = bias 0, standard bias 0, daylight bias -60, standard '(UTC) Dublin, Edinburgh, Lisbon,', daylight '(UTC) Du blin, Edinburgh, Lisbon,' I have not yet added debug logging to _eas2ical_convert_datetime_property but I assume this is not being correctly converted to midnight local time and hence is failing the sanity check in that function. Of course, if that is the case, the sanity check is not the problem -- the local time is wrong and will still be 23:00 on the day before (but a log message to warn about the sanity check failure would be useful). Any idea why icaltime_convert_to_zone would not be converting the time to 00:00 BST? No, not without actually stepping through the code. Is the timezone info Exchange is providing wrong? I am not certain exactly what the log process timezone message is showing, but it doesn't look right that daylight claims to be UTC. But I am not sure whether that text is actually important. I think it's no used. One thing to check is what time zone is used internally. Is it the one sent by Exchange converted to VTIMEZONE or some system timezone corresponding to it? I don't remember whether we got around to implementing such a matching, or how complete it is. Found it. The bug is in _eas2ical_process_timezone. This comment: // if timezone id contains character UTC and Bias is 0, then don't add it to the ICAL This attempted optimisation is not safe, of course, if the daylight time is not UTC. In fact, the code already does the correct optimisation higher up -- if **both** standard and daylight are UTC don't bother with the timezone. This only affects us in the UK (and Ireland and Portugal)! I will generate a patch shortly and add it to the bug report. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] All day events from Exchange
I have submitted three patches to bug 85239. One of them fixes the actual problem I was seeing, the other two are related but separate (see the comments in the bug report). However, as I was testing these, the improved logging found many cases where Exchange was providing the wrong timezone information. Most events had the correct timezone but some did not (some of those were invitations received from other people, others were events I created on another device using EAS, others I don't know). In all those cases, the event was actually timed to start/finish at midnight UK time, but some other timezone (normally CET) was being provided. So, when the events were converted to (apparent) local time, their times were not midnight. I don't see any good workround for this: as Exchange is lying about the timezone it is hard to fix. We could use the system timezone instead of the timezone Exchange reports, but that is likely to be wrong in many cases. At the moment, when the time check fails, the code just gives up and uses the time sent by Exchange (which is in UTC). When this gets turned into just a date, it is likely to be the wrong day (depending on whether the event is really ahead or behind UTC). My thought is to force the event to not be treated as an all day event if the time fails the midnight check. Not perfect, of course (it loses the information that it is an all day event), but it allows the user to get a better idea of what has gone wrong and gives them a better chance of recognising the correct day. Of course, it is likely to really mess up round-trip processing of the events -- they may get marked by Exchange as no longer all-day when they get synced back. Thoughts? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] All day events from Exchange
On 20/10/14 13:02, Patrick Ohly wrote: On Mon, 2014-10-20 at 10:17 +0100, Graham Cobb wrote: I have just noticed, in my testing of 1.4.99.4, that all day events are not working properly. I don't suppose this is new in this version -- I probably didn't notice it before. Right. That code hasn't changed in quite a while. The relevant code to look at are the _eas2ical_convert_datetime_property() and _eas2ical_convert_component() methods activesyncd/eas-daemon/libeas/eas-cal-info-translator.c. I haven't yet changed any code but I have looked at the code and the logs. The situation is complicated slightly by the fact that we (in the UK) are now back on winter time, which is GMT (=UTC). However, I can reproduce the problem by looking at all day events set up for next summer. In the activesyncd log I can see the event coming in from EAS with: TimeZone xmlns=Calendar:ACgAVQBUAEMAKQAgAEQAdQBiAGwAaQBuACwAIABFAGQAaQBuAGIAdQByAGcAaAAsACAATABpAHMAYgBvAG4AL AoFAAIAACgAVQBUAEMAKQAgAEQAdQBiAGwAaQBuACwAIABFAGQAaQBuAGIAdQByAGcAaAAsACAATABpAHMAYgBvAG4ALAMFAAEAxP ///w==/TimeZone StartTime xmlns=Calendar:20150728T23Z/StartTime AllDayEvent xmlns=Calendar:1/AllDayEvent The start time is midnight local time (on the day of the event, 20150729, which is BST -- summer time). I also see, in the log... (process:16804:0xcb3c50): libeas-DEBUG:process timezone ACgAVQBUAEMAKQAgAEQAdQBiAGwAaQBuACwAIABFAGQAaQBuAGIAdQByAGcAaAAsACAATABpA HMAYgBvAG4ALAoFAAIAACgAVQBUAEMAKQAgAEQAdQBiAGwAaQBuACwAIABFAGQAaQBuAGIAdQByAGcAaAAsACAATABpAHMAYgBvAG4ALAMAAA AFAAEAxP///w== = bias 0, standard bias 0, daylight bias -60, standard '(UTC) Dublin, Edinburgh, Lisbon,', daylight '(UTC) Du blin, Edinburgh, Lisbon,' I have not yet added debug logging to _eas2ical_convert_datetime_property but I assume this is not being correctly converted to midnight local time and hence is failing the sanity check in that function. Of course, if that is the case, the sanity check is not the problem -- the local time is wrong and will still be 23:00 on the day before (but a log message to warn about the sanity check failure would be useful). Any idea why icaltime_convert_to_zone would not be converting the time to 00:00 BST? Is the timezone info Exchange is providing wrong? I am not certain exactly what the log process timezone message is showing, but it doesn't look right that daylight claims to be UTC. But I am not sure whether that text is actually important. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] All day events from Exchange
I know I have had trouble with all day events before, but it might have been in my OpenSync days (or even my own OWASync!). I have just noticed, in my testing of 1.4.99.4, that all day events are not working properly. I don't suppose this is new in this version -- I probably didn't notice it before. I have an all day event in Outlook, scheduled for this Thursday (20141023). I did a one-way sync from Exchange (activesync) to files, and the file ended up with the following: DTSTART;VALUE=DATE:20141022 DTEND;VALUE=DATE:20141023 To make matters worse, I then synced those files with Owncloud and Owncloud now believes this is an all day event on the 22nd! (And so does Thunderbird when I synced that against Owncloud). I have not yet attempted to debug this (looking at what activesync sends, etc) but wondered if anyone either has seen this before, or has a view on what the correct VCALENDAR file should look like for this event. I have a very vague recollection that in OWASync I had to special case this and adjust the vcalendar info from OWA to handle all day events (but it might have been some other issue). Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Configuring Activesync in SyncEvolution 1.4.99.4
On 19/10/14 20:04, Patrick Ohly wrote: On Sat, 2014-10-18 at 15:36 +0100, Graham Cobb wrote: The (new in this release, I think) checking for mixing shared/unshared properties is causing me some logical confusion. ... That's the expected behavior, and hasn't changed in the 1.4.99.4 release candidate. The new terminology did not change the implementation, just some names. Ah, OK. I thought you had tightened some checks to reduce user errors by disallowing some combinations that had previously been accepted but might not have had the effect the user expected. I was probably confused (I had been hacking my scripts along with the earlier discussions around naming). In this case the problem is that @Exchange refers to a context, not a sync config, and only sync configs have a username property. You could use databaseUsername instead (however, I am not 100% sure whether the ActiveSync backend supports that - WebDAV does), if you don't mind repeating that for each source, ahem, datastore. I now have a recollection that I had raised something similar to this question before. I think the answer then was also if you are more comfortable, use databaseUsername. I will look into whether activesync supports that. It would be nice, one day, to make configuration of Exchange, Google and Owncloud servers look, as far as possible, the same. They all need similar information (server contact details, auth info and folder names) but the configuration for activesync is done very differently. The only way I can get it to work is if I bring step 3 to be in front of step 2. That works, but feels wrong (it also breaks my scripts in a hard to fix way, but that is my problem). Are you sure it used to work? No. I was probably confused about that. The easiest fix to my scripts seems to actually be to just configure the target-context before the sources. Thanks for the help. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] All day events from Exchange
On 20/10/14 13:02, Patrick Ohly wrote: On Mon, 2014-10-20 at 10:17 +0100, Graham Cobb wrote: I know I have had trouble with all day events before, but it might have been in my OpenSync days (or even my own OWASync!). I have just noticed, in my testing of 1.4.99.4, that all day events are not working properly. I don't suppose this is new in this version -- I probably didn't notice it before. Right. That code hasn't changed in quite a while. The relevant code to look at are the _eas2ical_convert_datetime_property() and _eas2ical_convert_component() methods activesyncd/eas-daemon/libeas/eas-cal-info-translator.c. Thanks. I will try to look at it later. Meanwhile, I have logged it as bug 85239. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] SyncEvolution 1.4.99.4
On 15/09/14 16:19, Patrick Ohly wrote: This is the first release candidate for 1.5. No further changes are planned except for fixing yet-to-be-discovered bugs - so find them now! :-) I am trying to update my various configs and check that everything works. The first problem isn't really a bug because I know the Debian packaging is not a supported feature. But when I tried to upgrade using apt-get install syncevolution-activesync, apt-get would have been happy to install the new syncevolution-activesync without upgrading syncevolution-activesync-saucy and syncevolution-bundle as well. Adding syncevolution-kde caused all four packages to be upgraded. I think the dependency of syncevolution-activesync on syncevolution-activesync-wheezy | syncevolution-activesync-saucy | syncevolution-activesync-trusty should be versioned to require the same version. I am also surprised that activesyncd-saucy hasn't been upgraded. Is that because it has not changed? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] Configuring Activesync in SyncEvolution 1.4.99.4
On 15/09/14 16:19, Patrick Ohly wrote: About 1.4.99.4 == This is the first release candidate for 1.5. No further changes are planned except for fixing yet-to-be-discovered bugs - so find them now! :-) The (new in this release, I think) checking for mixing shared/unshared properties is causing me some logical confusion. Here is (the outline of) how I used to configure my Exchange server config: 1) Remove the existing configurations 2) syncevolution --configure --template none backend=eas-contacts database=Contacts username=my-account-name @Exchange contacts 3) syncevolution --configure --template none username=my-account-name password= printChanges=1 loglevel=4 target-config@Exchange 4) syncevolution --configure sync=two-way uri=contacts loglevel=4 target-config@Exchange contacts The second step now gives the error: [ERROR] per-peer (unshared) properties not allowed: username If I remove the username, it gives the error: [ERROR] contacts: backend failed: fetching folder list: GDBus.Error:org.meego.activesyncd.Error.AccountNotFound: Failed to find account [] The only way I can get it to work is if I bring step 3 to be in front of step 2. That works, but feels wrong (it also breaks my scripts in a hard to fix way, but that is my problem). It feels like there should be one of two cases: i) The context (@Exchange) is associated with a particular account. In that case, the account id should be a property on the context, not on some peer. ii) The context (@Exchange) is generic for several activesync accounts (different users), in which case the folder mappings cannot be checked at the time they are set up. Not very user friendly. To me, option (i) seems more logical as well as much more user friendly. But then the account can't be a per-peer property (which peer do you use?). This might be because we are misusing the username property to provide a convenient way to specify the activesyncd account -- although I don't really understand what is wrong with that. I also don't understand how other backends deal with similar problems. Surely a Google server is accessed using some credentials and they are either properties of the context or the peer, with the same issues? We could, of course, just stop using username and embed the account name in the database name. It would be a bit tedious to type (as account names are usually actually email addresses, although they don't have to be). There seem to be two problems here: 1) There is a change which will force people to change the way they configure ActiveSync accounts. Can/should we do something to allow existing configs and/or existing configuration scripts to work? 2) How do we actually want it to work in the future (maybe an issue for the next release)? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Will activesyncd work with Exchange 2007?
On 08/07/14 18:45, Yury Vidineev wrote: I'm trying to set up contacts sync with Exchange 2007 as described in this manual: https://syncevolution.org/wiki/ms-exchange-and-kde-synchronization I haven't tried with Exchange 2007. Is there any way you can get me an account on an Exchange 2007 system to test with? Alternatively, you could turn on all the logging and I will see if I can work out why it isn't working. Ideally I would like you to run activesyncd with: EAS_SOUP_LOGGER=1 EAS_DEBUG=5 EAS_DEBUG_DETACHED_RECURRENCES=1 Do not post the logs here, but mail them to me directly. However, note that the logs will probably include your username and password. I will not use them but it is up to you if want to edit the logs to remove them (and/or change your password after taking the log). Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Activesync to/from office365.com
On 15/06/14 11:08, Nina Steiger wrote: and restart activesyncd I may get the calendar of my colleague with otherUsername. I will try that now. Of course I lwill loose the connection to my own calendar I think. I am not expecting that to work, unless you know the password for your colleague. The problem is that there does not seem to be any way in the ActiveSync protocol to supply the credentials of one user and access the folders of another. The credentials you supply are used to determine the list of folders which are displayed, and it does not seem to include any shared folders to which you have been given access. But please let us know what happens! Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Activesync to/from office365.com
On 14/06/14 22:18, Nina Steiger wrote: Is it possible to sync shared calendars via actice sync? I haven't tried myself, but I have just looked through the protocol documentation and I can't find any way to do it unless Exchange is willing to return the shared/public folders in the FolderSync for the account. It seems, from your test using --print-databases, that it does not do so. While it is possible to specify different account details when fetching items, there is no way to specify any account details with either FolderSync (for listing folders) or Sync (which would be used to find the items to fetch). There seem to be several articles I can find by searching the web which claim that Exchange ActiveSync does not support shared/public folders, but nothing both recent and definitive (e.g. from Microsoft). They have been accessible through davmail (an exchange caldav/carddav gateway ) by otherusern...@mycompany.com with the credentials of my account myusern...@mycompany.com. (davmail stopped working for me at least at home for some weired redirects to wrong authenticatiion servers after M$ changed their office365 version, that's why I am trying syncevolution) I don't know how davmail does it. By the way, the redirection problem is a known issue with Microsoft's hosted services. You may have some success with telling davmail to use the redirected servers. There is no easy way to find out what the redirection should be but if you can find out, the redirections seem to be stable and can be contacted directly (at least for activesync access). There are other issues with using our activesync with Microsoft's services. See SyncEvolution bug reports 76515-76518. I do not understand how to configure syncevolution with myusern...@mycompany.com and use a different username for the calendar database. There is no way to do it in the current code, and I can't see a way to do it in the protocol either (although I may have missed it, of course). May anyone give me a hint which direction to investigate further? Ask davmail how they do it? If there is a way to do it, we can look into adding it into activesyncd. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Getting the concepts clear (Was: Configuring a target)
On 14/04/14 08:36, Patrick Ohly wrote: On Mon, 2014-04-14 at 00:20 +0200, Ove Kåven wrote: But what if the server you want to talk to isn't a SyncML server, but a WebDAV or ActiveSync server? How is that possible, if SyncEvolution must talk to something that understands SyncML? But wait, SyncEvolution itself understands SyncML, and can act as server! We can just have SyncEvolution talk to itself! A big hack, but it solves the problem. Indeed. It came to be out of lack for alternatives (defining and implementing an entirely new sync protocol is no piece of cake), but it does the job pretty well (IMHO). I had to extend the sync engine occasionally (see PBAP and the new caching sync modes) and may have to do it again, but that was still less work than starting from scratch. Thank you for your contribution, Ove. Interestingly, I actually find this way of thinking about local sync (that it is a hack to sort of extend SyncML to other protocols) unhelpful. As both you and Patrick have mentioned that, I realise that this is how it came about, but I tend to think it causes additional confusion as it makes non-SyncML protocol access look like more of a special case (with its own rules to be learnt) than is really the case with the (brilliant) way Patrick has implemented it. Of course, I may be unique in this and others may find it very helpful -- just a data point. I prefer to think of local sync as purely an optimisation on a sync which happens between SyncML entities which happen to be on the same system (and which can be completely replaced with a normal SyncML sync if they are on different systems). In the context of SyncEvolution I think of WebDAV and ActiveSync not as sync protocols but primarily as database access protocols, and all the database backends in SyncEvolution as being equal. Of course, I come from an OpenSync/MultiSync background so I tend to think of all the SE backends as equivalent to OpenSync plugins (I even considered writing a GPE backend for SE and would have if I had not decided I would be moving to Jolla, and I also considered using activesyncd as the basis for writing an OpenSync ActiveSync plugin instead of my OWA TCL script -- but OpenSync is dead). Just one person's view, of course. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Getting the concepts clear (Was: Configuring a target)
On 13/04/14 19:45, Heyns Emiliano wrote: In addition to this we have 1a: Target-Configs. I think a target-config is really what binds two Sync Specifications together to form a full sync pair, but I've lost track how; the syncURL seems to play an important part here, but it has differing usage, sometimes it's used to hold a real syncURL (such as https://www.google.com/calendar/dav/%u/user/?SyncEvolution=Google), another time it's use to point to something inside the syncevolution config (such as local://@Context). It does feel a bit like a target-config is only a 'kind of' Sync Config/Peer because the required data could be shoe-horned into its data-structure, rather than there being real similarity in intended behavior of these two kinds -- I wouldn't mind to be corrected on this one. If we put aside the special case of using target-config with things like --print-items, then I think target-config makes some sense to me... If you were syncing two different systems each running SE, using SyncML, then on each server you would have to set up a peer to point to the other side. One of them would have the syncUrl to make the outbound connection with, the other would have information to route the incoming connection to a particular sync-config and context. That makes sense to me. If we then consider a local connection, I think of that as just an optimisation of the connection. It seems logical that you still need a peer set up in each of the two contexts which are going to be connected together. One has the syncUrl (local://@context), the other doesn't actually need anything really but still exists and has to have the name target-config@context. That is why I would quite like to see the special name (target-config) go away and the local URL extended to specify any peer name you choose. But that is not how it works today. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Getting the concepts clear (Was: Configuring a target)
On 13/04/14 21:58, Heyns Emiliano wrote:
So... as Patrick pointed out earlier and I might now begin to grasp...
the target-config is the receiving end of the sync pair (Patrick said
this verbatim... I think I now understand what he means).
local://@context always points to target-config@context,
Yes
and as
target-config@context has an property called 'uri' pointing to a data
source in @context, we have a full specification of the second half of
the pair.
Not quite. If I understand correctly (Patrick?), the Xmn's for each
source within target-config@context have a uri property. So the uri in
the sending end's Xmn get matched against one of the Xmn's in the
receiving end's target-config to select the source on the receiving side.
syncevolution --configure syncUrl=local://@OtherContext peerIsClient=1
Source@Peer
I normally set up Peer@Source with the local URL and the peerIsClient.
But there is no reason it wouldn't work the way round you describe.
means:
- side a: {source: @AhDamnIDontKnow.Source, peer:
@AhDamnIDontKnow.Source}, connects to
- side b: {source: @OtherContext.target-config.uri, Peer:
@OtherContext.target-config}
No... I think it means...
- side a (sending side): {context: @Peer, peer: Source@Peer}, connects to
- side b (receiving side): {context: @OtherContext, peer:
target-config@OtherContext}
After this, calling
syncevolution --sync Source@Peer
would sync exactly this one pair. Except I have no idea in which
context. Frig, this is complicated.
No. It syncs every Xmn from Source@Peer (which has sync not equal to
none) and tries to pair it with a relevant Xmn from
target-config@OtherContext. So...
- side a (sending side): {context: @Peer, peer: Source, Xmn: each one in
turn (with sync!=none), URI: taken from each Xmn}, connects to
- side b (receiving side): {context: @OtherContext, peer: target-config,
Xmn: the one with the URI matching, source: the one corresponding to the
Xmn}
If I'm understanding this correctly (and that would be a first), this
means that if I'm setting up a sync for my Google contacts and my Google
Calendar, I'd need separate contexts for those, as I'd need a separate
target-config for each, and each context can have only one of those.
You can have several sources in the context, because it is the Xmn's
which pair up and which have the important properties (like uri). You
would only need separate contexts if you needed to specify different
usernames.
If I'd want to sync an exchange contacts folder with a local vcards
folder with my google carddav folder, that's mean I'd have to set up
ContactsFolder@Exchange and ContactsFolder@Google, and give them both
the same target-config in for example @Local, which has an 'uri'
property pointing to a file datasource with vcards, setting up a
hub-and-spoke system. Please let this be correct.
Almost, but not quite. You would set up LocalFolders@Exchange and
LocalFolders@Google, and give them both the same target-config in
@Local. The uri's would be set up in the Xmn's (for example
LocalFolders@Exchange contacts, LocalFolders@Google contacts and
target-config@Local contacts). That would be the hub-and-spoke system.
If I'd then want to do
the same for my Calendar, I'd need a new context because @Local cannot
have the target-config anymore to be paired up with
CalenderColder@Exchange/CalendarFolder@Google.
No. You could also set up LocalFolders@Exchange calendar,
LocalFolders@Google calendar and target-config@Local calendar, using
the same contexts and peers (but different Xmn's).
What do you mean by saying 'target-config doesn't need anything'? At the
very least I'd expect it would need 'uri' to be set to point to a fully
self-contained data source, or a username/password if the datasource
didn't have one.
The uri's are on the target-config Xmn's. You are probably right about
the username/password.
Graham
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] merging of winning and loosing items
I have been working on sync on and off for many years but I don't have any obvious solutions to propose. The array problem, in particular, is essentially the issue that made me eventually give up on OpenSync (along with the fact that everyone had drifted away from it). Particularly when you consider that some devices will systematically appear to have changed the array on every sync due to their own limitations (number of entries supported, limited type information retained, etc). Conflict resolution/merging is a very hard problem, with no perfect solutions. It is really a separate issue which could do with much more research and co-ordinated effort, as the heart of the sync problem. I wonder if this could be separated out into a self-contained module so that different implementations could be tried (or even supported -- see below). I do have a gut feel that the best solution, one day, will be to try to merge changes, not merge databases. For now that would mean calculating differences, but in the future protocols might actually allow sending transactions instead of databases. I suspect that is the only real solution to the array problem. But that is obviously not a short-term solution. In the short term, the most critical thing is to allow the user to see what is happening, and to fix it if necessary. Ideally, that would involve a user interface that allowed the user to see the proposed changes and authorise them (accept all changes, make no changes, select which side wins particular conflicts, leave some conflicts unresolved with different data on the two sides for now, log all changes so the user can retrieve data they lost by mistake). This is how my wife's blackberry-Outlook sync seems to work. If conflict resolution was a plugin, I could imagine one implementation that had an interactive GUI to do all of the above, and another that was designed for non-interactive operation. The latter would support a --dry-run option that allowed the user to find out what changes would be made, as well as output/logging which showed what conflicts occurred and how they were resolved and which kept records of all data deleted in case the user needed to re-enter it later. In the immediate case, I would suggest allowing some sort of dry-run capability (frankly I have always been surprised this doesn't seem to exist today) and some improved output/logging to let people know what is happening with conflicts: I find SE seems to output either far too much info or far too little -- for example, enabling print-changes causes all the useful info about the sync itself to scroll off the screen (even with quite large xterm/screen scrollback buffers), but without print-changes there is no way to find out what has changed. Having to redirect output and then go through it carefully later in emacs is not the solution. Defaulting to limited output explaining what is going on, with options to retrieve more details later (from log files or from the databases themselves) would help a lot. Sorry this doesn't help with your specific questions! Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Getting the concepts clear (Was: Configuring a target)
On 09/04/14 21:39, Patrick Ohly wrote: But it can apparently also hold a property named 'sync', and that's listed as a source property. I'm confused now about what happens when you set the 'sync' property. Is the target-config changed? Then 'sync' appears to be a sync property. Is the source config changed? Then what's the role of the sync config being passed on the command line? The wording seems to imply something happens to the target-config when setting the 'sync' property, but that conflicts with how you spoke about what sync and source configs can hold. The sync property is a per-peer source property. It defines how a data source is used by a specific peer. Therefore it makes no sense to --configure sync=two-way @default addressbook, because there is no peer mentioned anywhere and this sync value cannot be stored. The addressbook source config referenced here only has the shared source properties, which do not include sync. It is this concept which I have found hard to grasp. I think part of my problem is that there is no object on which to hang these per-peer source properties. I think a diagram (or even a UML description) would help. In the absence of a diagram, let me see if I have grasped this... Imagine a context (call it @Ctx) which contains three sources (S1, S2, S3) and two sync configs representing peers (P1@Ctx, P2@Ctx). Then there are a a bunch of objects as in this matrix: | S1 | S2 | S3 | ---++++ P1 | X11| X12| X13|P1 sync config properties ---++++ P2 | X21| X22| X23|P2 sync config properties ---++++ |S1 |S2 |S3 | |shrd|shrd|shrd| |prop|prop|prop| Where Xnm presents the non-shared (=== per-peer) source properties of Sm for sync config (===peer) Pn. The property called sync is a non-shared source property, so it is a property of each of the objects called Xnm in my matrix. Is that right? If so, I think the terminology description needs to be updated to define these Xnm objects as first-class objects and give them a name. After all, they are the objects of which the non-shared source properties are properties. And then there are three types of properties: properties of the three types of objects (Pn, Sm, Xnm). The sync property is primarily a source property, because in contrast to sync properties there are multiple values for it, one for each source. You can also think of it as the sync aspect of a data source, when describing the role of a source in a sync. I don't see how that makes sync primarily a source property. Doesn't exactly the same logic make it primarily a sync property as there are multiple values for it, one for each peer (isn't that what per-peer means)? The truth seems to be that it is a matrix property with values that are per-source-peer-combination, and pretending they are some special sort of source property just causes confusion. [I have re-ordered Patrick's email here] Following that logic, the --configure sync=two-way memotoo@default addressbook operation becomes valid and sets the sync property of addressbook for syncing with memotoo. OK, that makes sense. This is setting a property of one of my Xnm objects. So, what happens when I specify --configure sync=two-way memotoo@default? Is that an error (because sync is not a property of my Pn objects)? Just like --configure sync=two-way @default addressbook is an error because sync is not a property of my Sm objects? ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] merging of winning and loosing items
On 09/04/14 15:51, Patrick Ohly wrote: To some extend that is already possible. Merging two conflicting items can be done entirely using the builtin scripting language and a custom script. Ah. Something else to look into one day. Performance and storage are important but I don't think they are what limits this today. I think it is usability. Particularly in terms of undoing individual changes (even of individual fields within a single object). I remember that Ove turned off dumpData for Maemo because it was slow. But perhaps my memory fails me here. I certainly turn it off in my Jolla syncs, for exactly the reason Ove mentions in his reply. But I think that is more to do with the need to dump the whole database than with the concept of recording changes. Particularly if we could find a way to record the changes out of the sync itself, rather than by doing comparisons after the sync is complete. The involved backends would need to support reporting changes starting from some particular state multiple times. It's doable for EDS and WebDAV (but not currently implemented), whereas ActiveSync would rely on the server to support old anchors which (as far as I remember) not all servers do. Good point. I still want to think about a way to do dry runs but I understand the issue here. Maybe we don't need dry runs if we can make user correction of incorrect conflict resolutions usable. Yes, but I was thinking of better ways to do the print-changes job, by driving it from the conflict resolution engine itself. Patches welcome, as they say. I personally don't have an idea how this could be implemented in a user-friendly way. The internal representation is fairly abstract; definitely not what the user wants to see. This seems a more solvable problem than the dry-runs problem, without completely rewriting the engine or requiring any impact on the sync protocols themselves. But, as you say, it requires someone to look into the code and come up with a solution. Maybe I will get to it one day :-( ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Getting the concepts clear (Was: Configuring a target)
On 08/04/14 19:05, Emiliano Heyns wrote: On 08/04/2014 18:21:35, Patrick Ohly patrick.o...@intel.com wrote: Ah no I understand that, but can a single command set up multiple data sources? Yes. I think I mentioned the syntax already in this thread, but I don't remember when. --configure backend=eds-events @default calender and --configure backend=eds-contacts @default addressbook can be combined into --configure calendar/eds-event \ addressbook/backend=eds-contacts \ @default addressbook calendar Okay... it's good to know that this can be done, and it answers my question, but it maps --configure backend=b1 @context s1 --configure backend=b2 @context s2 to --configure s1/b1 s2/backend=b2 @context s2 s1 for which I can't readily see a rule governing the transformation, so I'll take this as noted and stay away from it in my HOWTO. I think there was a typo in Patrick's example. I think he meant to write: can be combined into --configure calendar/backend=eds-event \ addressbook/backend=eds-contacts \ @default addressbook calendar In other words, when setting source properties on the command line you can name the property as source/property in order to set the same property in different sources to different values. This sort of thing is more useful where there are also some properties which are not supposed to be different for different sources (otherwise the single command doesn't save anything over two separate commands). So a more common example might be combining --configure backend=b1 database_user=u @context s1 --configure backend=b2 database_user=u @context s2 into --configure s1/backend=b1 s2/backend=b2 database_user=u @context s1 s2 Personally I don't use it. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Configuring a target
On 03/04/14 14:50, Patrick Ohly wrote: On Wed, 2014-04-02 at 15:20 +0100, Graham Cobb wrote: On 02/04/14 13:16, Patrick Ohly wrote: configuration property Sync and source configs contain configuration properties. Each property is a name/value pair. Sync properties are used in sync configs, source properties in source configs. The names were chosen so that they are unique, i.e., no sync property has the same name as a source property. A property can be *unshared* (has separate values for each peer, therefore sometimes also called *per-peer*; for example the `uri` property which defines the remote database), *shared* (same value for all peers; for example the `database` property for selecting the local database) or *global* (exactly one value). I have found this confusing as well. To the naive view, per-peer properties should be sync properties, shared properties should be source properties, and global properties should be context properties. So you would change the meaning of sync property from a property set in a sync config to a property set for a sync peer? That is indeed close to how the properties are used, but does not match how the implementation works. Changing the command line options would require changing the implementation. Interesting. Maybe this is close to the root of my problem, because I don't understand how a property set in a sync config and a property set for a sync peer are different. I will need to think about this when I have a bit more time. local sync Traditionally, a sync config specifies SyncML as the synchronization protocol. The peer must support SyncML for this to work. When the peer acts as SyncML server, conflict resolution happens on the peer, outside of the control of SyncEvolution. Is there some reason conflict resolution gets mentioned here? Does it really have anything to do with local sync? In a so called `local sync`_, SyncEvolution connects two of its own backends and runs all of the synchronization logic itself on the host. Again, why mention synchronization? Is there something important you are trying to convey? The key point is that it is SyncEvolution doing the synchronization, putting it under control of the user. If there is a remote server involved, for example an Exchange server, then we don't allow it to do conflict resolution for us. I understand that that is true, but I still don't understand why you feel the need to mention it. It seems to be complicating the local sync concept needlessly. My suggestion for the local sync definition: 'Traditionally, a sync config specifies SyncML as the synchonization protocol. In some cases, the desired SyncML peer is actually another context on the same SyncEvolution system (for example, the user may wish to synchronize Evolution data with a file-based database on the same system). If the peers are on the same system, then SyncEvolution can work more reliably and efficiently by using its own, internal, mechanisms instead of actually using SyncML. This is called a local sync.' I believe that provides a full and useful definition of local sync. However, I think that in the original you might also have been trying to bring out the concept of how non-SyncML peers need to be handled. My suggestion is to take that out of the local sync discussion altogether and find somewhere else to put it. Not sure where, but maybe the text could look something like... 'SyncEvolution always uses SyncML to communicate with peers. No other protocols are supported directly for synchronisation (except the internal local sync optimisation used when the SyncML peer is on the same system). All other protocols (such as ActiveSync, CalDAV/CardDAV, Google, etc) are handled indirectly. In these cases, a SyncEvolution backend is used to allow these servers to be treated as database sources and to be made available over SyncML. SyncEvolution can then manage synchronisation between any combination of these servers and traditional SyncML devices.' Anyway, thanks for taking the time to consider my comments. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Configuring a target
On 02/04/14 13:16, Patrick Ohly wrote: FWIW, here's the terminology section from the README. It's meant to introduce concepts from scratch, i.e. nothing should depend on anything not defined yet. I appreciate the effort that has gone into this: I have read it many times, and I even had it to hand while writing my earlier reply to Emile. But I have to say that it has never helped me as much as I would like :-) I realise this is my failing, but I have always found it very hard to understand what is going on with these. I am getting better as I do more, but I have been using SE for quite a while now and still am lost with configuration half the time. What we really need, I think, are more tutorial materials, not just definition materials. Maybe, one day, we will find a technical writer with some spare time who can make a contribution. One thing which may have been not ideal, with hindsight, is to have everything configured with one single command (--configure) which gives no hint to the class of the object being configured (let alone the scope of the attribute being set: shared/unshared). Leaving it up to the user to understand the niceties of command line object naming to work out what sort of thing is being configured is a task that requires a high level of experience and is frustrating for a newbie. Is it worth considering introducing new --configure commands such as --configure-context, --configure-source, --configure-peer (and deprecating --configure)? The new commands would work exactly the same way as the current --configure except they would check that the thing you were configuring actually was of the expected type? I also find the (well-intentioned) defaulting causes me more confusion -- templates, default context, target-config are powerful tools but are of much more use for the expert, I feel, than the beginner. I try to avoid them. I would very much welcome being able to specify a context in the local: URL and discard all my use of target-config. A couple of specific points: local/remote Synchronization always happens between a pair of databases and thus has two sides. One database or side of a sync is remote (the one of the peer) or local (SyncEvolution). For the sake of consistency (and lack of better terms), these terms are used even if the peer is another instance of SyncEvolution and/or all data resides on the same storage. It would be helpful (if they are true!) to add a couple of points: In all cases, the local database is the one named in the sync command line, the remote database is the one referenced in the syncUrl property. Note that local/remote is independent of client/server. sync config A sync configuration defines how to access a peer: the protocol which is to be used, how to find the peer, credentials, etc. Peers might support more than one protocol, in which case multiple sync configs have to be created. Maybe delete the last sentence: not sure it adds any very important information. Surely the more usual reason for creating multiple sync configs is that you have multiple devices to sync? source config Each data source corresponds to a local database. A source config defines how to access that database, like a sync config does for peers. This information about a local database is independent of the peers that the database might be synchronized with. Sync configs use these shared source configs and add additional, per-peer settings to each of them that define how that local database maps to a remote database in the peer. By default a source config is inactive inside a sync config and thus ignored. It must be activated by setting the unshared `sync` property to something other than `none` (aka `disabled`). This paragraph is very confusing. In what sense is a source config inside a sync config? Maybe the second and third sentences could be replaced with something like: The sync config ignores source configs in the same context unless the sync property for the source is set to something other than none (aka disabled). configuration property Sync and source configs contain configuration properties. Each property is a name/value pair. Sync properties are used in sync configs, source properties in source configs. The names were chosen so that they are unique, i.e., no sync property has the same name as a source property. A property can be *unshared* (has separate values for each peer, therefore sometimes also called *per-peer*; for example the `uri` property which defines the remote database), *shared* (same value for all peers; for example the `database` property for selecting the local database) or *global* (exactly one value). I have found this confusing as well. To the naive view, per-peer properties should be sync properties, shared properties should be source properties, and global properties should be context properties. context Sync and source
Re: [SyncEvolution] Configuring a target
On 21/03/14 14:26, Emiliano Heyns wrote: On Fri, Mar 21, 2014 at 2:59 PM, Patrick Ohly patrick.o...@intel.com mailto:patrick.o...@intel.com wrote: On Fri, 2014-03-21 at 14:32 +0100, Emiliano Heyns wrote: I'm looking to setup server-to-server sync between Exchange and a Caldav/Carddav server (Google probably, but memotoo for now). You really do like to try new things, don't you? ;-) Guilty as charged. But I have a real use-case for this: my employer uses Exchange, so I have all my work appointments there. I want my family to be able to see both my personal and my work calendar. I can't give them access to my Exchange account, but a sync between exchange and google would allow them to see when I'm busy. One-way and two way sync would both work. I could of course do this with an outlook plugin, but that requires me to have outlook open almost always. Emile, I wrote that HowTo and I apologize for the lack of clarity. My understanding of the terminology is still pretty poor so I won't try to answer our actual questions. But a couple of things you might find useful from my experience... I have a similar sort of problem -- my employer uses Exchange and I want to have my appointments and my contacts available in other contexts and on other devices. I chose not to try to do an actual server-to-server sync but have set up an environment where I sync Exchange with a local database and then sync that with various targets. In the example in the HowTo, the local database is KDE but I have since replaced that with a file backend. So, I sync Exchange with a set of files on my Linux system. I then sync that set of files with an Owncloud server (caldav/carddav). And I sync the Owncloud server with my phone (and other systems/devices sync either with the files or with the Owncloud server). Because I sync several folders (I have multiple contacts folders, for example) and because I hack on the ActiveSync support, I have a script which handles all the setup and the running of activesyncd and syncevolution for me. I will send you that script off-list (I need to remove some of my information, like my company's server address, before I can send it). You may find some stuff in there to help you. I see that the last parameter of the config command (contacts in the howto) is supposed to be a 'source', but I can't tell between the howto and the manpage what source it is supposed to refer to. I find it easiest to think of the source as the folder -- it is the place which stores the information about syncing one particular folder (such as the Exchange folder name). The source name can be chosen as you like -- but if you use a template, that template will automatically set up some sources with particular names (personally I do not use templates). But bear in mind that the source name is the default for the uri field, which is the name used with the remote end in some protocols (I *think* it is only important for SyncML). It will be interesting to hear how you get on (how about writing up another HowTo once you get it working?). Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] Activesync backend use of username property
Now that I am beginning to understand the use of the context and the difference between source and sync configs better, I tried issuing the following command: syncevolution --configure --template none \ username=my.em...@example.com backend=eas-events \ database=Calendar @Exchange calendar I think that ought to have worked, because I am configuring a source (which could be shared by several peers later). However, it fails: [ERROR] error code from SyncEvolution fatal error (local, status 10500): per-peer (unshared) properties not allowed: username Of course, the reason is because we are abusing the username, which is a sync property, to do the job of a source property (to specify the account for activesyncd). Should we change the eas backend to use (for example) databaseUser to specify the account? Or am I still confused (quite likely)? I must admit that I still don't understand how the special peer target-config works! Graham PS. I am at MWC next week, so I may have trouble responding to email. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Activesync backend use of username property
On 21/02/14 17:37, Graham Cobb wrote: Of course, the reason is because we are abusing the username, which is a sync property, to do the job of a source property (to specify the account for activesyncd). Should we change the eas backend to use (for example) databaseUser to specify the account? Or am I still confused (quite likely)? Further investigation has led me to discover that the carddav/caldav backends work the same way. They use username and password (and also cannot be set when just configuring the source). So, I am obviously confused. It seems that in both the webdav and activesync cases, we are specifying a folder (which must be in a particular user's account) in the source, but we are not specifying the access control for that account in the source. Wouldn't it be more logical to either: 1) Keep database as is, and use databaseUser/databasePassword for the access control, or 2) Modify the database to only specify the folder name and put the username, password and url in the peer? The first case makes webdav and activesync feel like local backends. The second makes them feel like SyncML peers. The current situation doesn't feel like either, to me. I also note that the current behaviour prevents running a SyncML client or server with either webdav or activesync as the backend database underneath. But presumably that is not a design goal (only file, kde or evolution are allowed?). Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Compiling syncevolution on Debian jessie
On 04/02/14 10:16, Tino Mettler wrote: Sorry for asking over and over again, what is your plan for the activesyncd package? AFAICS, it is a requirement for EAS client support in syncevolution and I think it would be nice to have this in Debian. I haven't packaged activesyncd. All I have done is submitted a few patches to Patrick. Of course, I also build it myself to test those patches, but I don't build packages. I note that Patrick does include activesyncd in his http://downloads.syncevolution.org/apt repository. I don't know who maintains that packaging (I am guessing it is Patrick). I would also be very happy if activesyncd could become part of Debian. I have not looked into that. I am familiar with the debian packaging tools (from using it in other projects) but not with the debian processes at all. A new libsynthesis package is in Jessie for a few days. I also finished a syncevolution 1.3.99.7-1 package. You can find the source at git://git.debian.org/git/collab-maint/syncevolution. Thanks for the info, but I am not going to be able to try it out for a few weeks (Mobile World Congress owns my life at the moment!). Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu)
On 06/01/14 15:43, Ove Kåven wrote: 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: http://people.debian.org/~ovek/sailfish/ Just to let you know... I have installed this and tested it as a SyncML-over-http client (with SyncEvolution also acting as the SyncML server at the other end), syncing calendar, contacts and tasks (although task DB is empty). It is working well, with only a few strangenesses, most of which don't look like they are anything to do with your port: 1) I currently use it from the command line, logged in over ssh. It starts running but very quickly stops doing anything. I think this is something to do with Jolla battery saving as it continues if I touch the screen of the phone. I have to keep interacting with the screen every few seconds to keep it running. 2) The diff function (printChanges) doesn't work. It almost never completes (before the other end times out -- several minutes). I suspect this is something to do with the logic of the diff script itself as I have seen strangenesses with it on the desktop side as well (for example it has managed to report two halves of one changed entry as two separate changes). It probably isn't helped by me having 1500 calendar entries. I have had to turn off printChanges. 3) I had one calendar entry which synced but then caused an error whenever syncevolution tried to read it from the calendar. --export got an error whenever it read it (and so did sync, of course). I couldn't even delete it using --delete-items. I eventually deleted it from the calendar GUI (but I had to delete it twice -- the first time it reappeared!). The bad entry was a recurring entry with a specific recurrence. Not sure where the problem lies -- I haven't tried to reproduce it yet. I notice that tasks will also sync (or at least, appear to -- I don't have any in the DB on my server at the moment). Do you know if there is any Jolla app which uses the task DB? Thanks very much for making the rpm's available. It helps with my goal of making this my main phone by the time I get to MWC. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Compiling syncevolution on Debian jessie
On 18/01/14 19:09, Patrick Ohly wrote: On Sat, 2014-01-18 at 09:40 +, Graham Cobb wrote: What version of synthesis is required to build the latest syncevolution? Usually the one that was bundled with the release. When compiling from source, use the libsynthesis from http://cgit.freedesktop.org/SyncEvolution/libsynthesis Thanks. As I am building from the git source I used that version of libsynthesis. One small problem: the syncevolution build finishes by creating the README, which requires executing the version of syncevolution that has just been built. In my case, that doesn't work. I built libsynthesis, installed it in /usr/local and then told syncevolution configure to look there (using PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/:/usr/lib/pkgconfig/). I did NOT put /usr/local into LD_LIBRARY_PATH. That is mainly because my syncevoution testing involves using a script which sets up several important environment variables, including LD_LIBRARY_PATH (and, in fact, I do my testing on a different machine). Anyway, the compilation all worked but the syncevolution that is built cannot be run. Which is fine by me, but not fine for this final stage of the build. It would be nice if one of several things was possible: 1) The README building script worked out how to set LD_LIBRARY_PATH (pkg-config worked out where the library was, after all). 2) I could tell configure to statically link libsynthesis. 3) I could tell configure that the built image won't run and the README step was dropped. 4) The perl script which creates the README handled syncevolution not running and put some default text in instead. The workround was, of course: LD_LIBRARY_PATH=/usr/local/lib:/usr/lib make but it would be nice if it could be handled automatically. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu)
On 17/01/14 12:58, Ove Kåven wrote: On 01/04/2014 01:24 PM, Graham Cobb wrote: However, I really hadn't started looking at it yet as I have had no time over Christmas. I would be very happy to join with your effort. Hi again. If you want to help, maybe you would like to help creating the Sailfish GUI? I can handle SyncEvolution proper myself, but writing the GUI takes time... Sorry, I am not in a position to volunteer to do that, at the moment. I am really not a GUI guy. And I am not going to have the time to look into it for the time being (at least until after MWC). Until then I will restrict myself to testing. I have been testing other things on my Jolla phone recently but I plan to install your rpm this weekend and give it a try. Sorry I can't be more help at the moment. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu)
On 04/01/14 08:56, Ove Kåven wrote: I just got my Jolla phone a few days ago, and now I'm investigating porting SyncEvolution to it. Unfortunately I can't answer any of your questions but I was also about to start looking at porting SyncEvolution to my new Jolla phone! Is your goal to run a full SyncEvolution on the phone, so it can synchronize directly with anything SyncEvolution supports? I was planning a more modest goal to use SyncEvolution to effectively act as a client for a remote SyncEvolution server, which would handle the complexities of synchronizing with everything else. I was also going to look into any other ways to get a SyncML client on the phone. However, I really hadn't started looking at it yet as I have had no time over Christmas. I would be very happy to join with your effort. If I have to, I could try to change the gSSO implementation so that it can deal with the Ubuntu implementation, but I don't run Ubuntu myself, so I'd only actually test it on Sailfish... Unfortunately neither do I. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Ubuntu Saucy + libical0 vs. libical1 + KDE
On 10/11/13 10:50, Patrick Ohly wrote: Ubuntu essentially just copies the packaging done by Tino Keitel, who recently said that he is willing to enable KDE support if he can get help testing that. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682520 I am happy to help test in a Debian Jessie environment, if that helps. I use KDE with kontact for PIM, and do not use Evolution. If this is built from Patrick's latest versions, I could even test with ActiveSync -- particularly if you felt like packaging activesyncd as well :-) Unfortunately, I cannot help with Ubuntu. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Activesync server losing state
On Tuesday 05 March 2013 10:09:08 Patrick Ohly wrote: On Mon, 2013-03-04 at 22:46 +, Graham Cobb wrote: I have found a problem with activesyncd with Exchange. In my case, the Exchange server has lost state (no idea why, but I noticed that my Android phone has thrown away all my mail and resynchronised it all so I guess it saw it too). ... 1) The easiest option seems to be to change the get_folder code to never do real folder syncs. Whenever the client asks for a folder list with retrieval from the server, just throw away the cache so the server will send all the folders (instead of updates, as happens today). This seems a bit extreme but it seems the easiest option, and folder lists seem unlikely to be much longer than a few contacts or events. It means that user intervention is necessary to fix the actual problem but the user can be told that when they see the need FolderSync first error they need to use --print-databases to force the FolderSync. ... Even if it is an uncommon problem, expecting users to perform some manual operation to resolve it is not going to work well. ... For folder sync the situation is different. There is an automatic response which does not involve data loss, so that's what should happen without involving the user. Of course, implementing it is a different matter... I understand your concern. Unfortunately, I am not up for creating the full solution at the moment. I have submitted my hack as patches in bug 61869 https://bugs.freedesktop.org/show_bug.cgi?id=61869. It works for me. Unless someone volunteers to do the full solution, I would encourage you to consider including this. It does, at least, allow a knowledgeable user to resolve the problem, using --print-databases, which they cannot do without this. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
[SyncEvolution] Future of PIM syncing? (was Re: Syncml + webdav backend)
On Monday 04 March 2013 08:43:01 Patrick Ohly wrote: It is great to be able to (from a users perspective: finally) synchronize SyncML phones with pim-data from the linux desktop in a stable an quick way. One could also say too late, because new phones are less and less likely to support SyncML. But it's good to hear that you got some value out of it :-) Interesting comment, Patrick. What is your view of how PIM syncing is evolving with new phones? Certainly they are supporting a more and more functional ActiveSync for the enterprise market but what about personal users? Will it all become specific apps for specific cloud services? For example, the Dropbox apps for phones, PCs, etc will sync your contacts/calendar on that device to Dropbox? Facebook, Evernote, etc will have similar apps? And so will mobile phone operators? That is starting to happen already. I suppose we will then need to wait for the Facebook generation to become old and cynical before they will push for open interfaces so that they can easily switch service providers. In the meantime, would it be feasible to create SyncML apps for Andorid, iPhone, etc to continue to support open syncing? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] URLs in database names and ActiveSync database names
On Tuesday 05 February 2013 07:44:00 Patrick Ohly wrote: On Mon, 2013-02-04 at 22:49 +, Graham Cobb wrote: Or, do I make it much more simple: if the string matches a CollectionId use that, else if the string matches a folder path name use that, else return an error (actually, I would probably force a FolderSync and try again before returning an error). And if you give your folders names which are the same as CollectionIds of other folders, more fool you (you can always use the CollectionId). That's the way how the other backends work. This has not caused problems in the past, so perhaps its good enough. It would also be consistent across backends. Thanks for the advice. That is what I will do, with one very small twist: it will be possible to specify a folder path with a leading /, which will be ignored (except to indicate this is a path, not a collection Id). This means that if you have created folders 1, 2 and 3 you can specify them by folder name if you want (/1, /2, /3). getDatabases will continue to display the names without a leading / and most people only use top level folders and will never use a / but it is there if someone wants to use it. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] Questions about implementing getDatabases in activesync backend
On Monday 04 February 2013 11:13:02 Woodhouse, David wrote: In the general case, you don't need to bump the soname for adding a new function; it doesn't *break* backward-compatibility. You just need to bump the *minor* number (which doesn't appear in the soname). And list it with the appropriate version in the symbol version list. Thanks - I am always making this mistake in terminology. Must try harder :-) I am an old VAX/VMS system programmer and the equivalent VMS construct contained both the major and minor numbers in a single entity (GSMATCH). I always forget that the soname doesn't include the minor number. But then VMS didn't even have true dynamic linking -- I don't miss the delights of transfer vectors! ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
[SyncEvolution] URLs in database names and ActiveSync database names
I notice that KDE database names are of the form akonadi:?collection=6 and I seem to have an Evolution database called local:system. Are these URLs meaningful outside syncevolution in any way (for example, do they mean something to the Gnome or KDE infrastructure)? I am thinking about how to specify folder names in the ActiveSync backend. At the moment, any database name is used it as a CollectionId in the protocol. I was thinking of a format to allow specifying either a CollectionId or a folder name. My current thinking is: - The empty string selects the default database of the correct type (current behaviour, and most common usage) - A string of the form activesync:?collection=XXX... would be interpreted as a CollectionId - Any other string starting activesync:? would be an error (reserved for future use) - A string of the form activesync:XXX... would be interpreted as a folder path name - Undocument, deprecate, but still support, the current usage. Any string not containing a : is just passed on and will be interpreted as a CollectionId. - Strings with a : but not starting activesync: would be an error (to catch someone mistakenly specifying a database name used for another backend). However, all this is assuming the protocol in the URL format has no meaning except to the backend so I can define the meaning. Or, do I make it much more simple: if the string matches a CollectionId use that, else if the string matches a folder path name use that, else return an error (actually, I would probably force a FolderSync and try again before returning an error). And if you give your folders names which are the same as CollectionIds of other folders, more fool you (you can always use the CollectionId). Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] Questions about implementing getDatabases in activesync backend
On Saturday 02 February 2013 22:04:16 Graham Cobb wrote: I will probably post the patch for the ActiveSync backend getDatabases code, using this new function, tomorrow. I have posted the patch in https://bugs.freedesktop.org/show_bug.cgi?id=60235. Note that I posted the wrong patch first, please use the updated patch. Of course it is dependent on the patch in bug 60204. I am no C++ programmer so you may want to review the patch before applying. It seems to work fine in my testing but you might want to check I haven't introduced memory leaks or similar issues. Note I have only tested against a MS Exchange 2010 server (all I have access to). By the way, I decided that getDatabases would force a FolderSync, even though activesyncd keeps a folder cache. FolderSyncs are not particularly expensive if nothing has changed (the server just says nothing has changed, it doesn't resend the whole list). I anticipate that getDatabases is a fairly rare event (compared with syncs, for example) and is most likely to be requested exactly when something has changed. It also, conveniently, provides a way for the user to force a FolderSync if they need to (I still haven't been able to reproduce the problem of the server insisting on a FolderSync). I considered not doing the FolderSync if the folder list is already in memory but I decided that this doesn't help the most common use case (separate syncevolution --print-databases username= backend= commands for each backend) and could be a problem if syncevolution was running as a long-lived server process. Adding timers seemed unnecessarily complicated. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] Questions about implementing getDatabases in activesync backend
On Friday 01 February 2013 10:24:15 Patrick Ohly wrote: On Thu, 2013-01-31 at 23:32 +, Graham Cobb wrote: eas_mail_handler_get_folder_list works (if I manually copy the parts of the header file that are needed). But I would prefer to use an API exported by libeassync as I don't see listing folders as mail-specific. That would mean adding a new function exported by libeassync and bumping the soname. Actually, I don't see that the library currently uses sonames -- is that right? It would mean, in any case, that the new syncevolution backend would require the new version of the libeasclient library to build. Any problem with that? No, fine with me. For the syncevolution.org binaries I am compiling and bundling activesyncd. I have created a libeassync version of the function, and moved the main logic into eas-folder so it is shared for both versions of the function. The patch is attached to https://bugs.freedesktop.org/show_bug.cgi?id=60204. I will probably post the patch for the ActiveSync backend getDatabases code, using this new function, tomorrow. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
[SyncEvolution] Questions about implementing getDatabases in activesync backend
I am working on adding --print-databases support in the activesync backend. In fact I have it working but it has raised a few questions: 1) Activesync needs an account before it can connect to a server and get the folder list. I think that WebDav has the same issue. And, in fact, I stole the solution from the WebDav code: insist that the source has a username configured. The effect of this is that using just syncevolution --print-databases doesn't show anything, even if you do have an account configured. In fact, you have to name a target-config configuration, and exactly one source, to get the listing. You can't even set up any configuration of the default context which will allow syncevolution --print-databases to work. Is this expected and desired behaviour? 2) This leads to another question. Other getDatabases implementations only list databases of the same type as the particular source. However, particularly as you can't specify several sources at the same time in the --print-databases command, I am inclined to list all the folders (of all types) whatever source is specified. Would that be regarded as a problem (it also makes the code easier :-))? 3) libeasclient exposes an API to list the databases. Unfortunately it is exposed by the libeasmail code (eas_mail_handler_get_folder_list). libeasmail is not used anywhere else in the activesync backend and, in fact, doesn't even seem to be usable (the libeasmail.h header file depends on several internal header files which are not installed)! Is any application actually using libeasmail? eas_mail_handler_get_folder_list works (if I manually copy the parts of the header file that are needed). But I would prefer to use an API exported by libeassync as I don't see listing folders as mail-specific. That would mean adding a new function exported by libeassync and bumping the soname. Actually, I don't see that the library currently uses sonames -- is that right? It would mean, in any case, that the new syncevolution backend would require the new version of the libeasclient library to build. Any problem with that? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
[SyncEvolution] Update on Exchange - KDE sync
I can now, reasonably reliably, synchronise between my company exchange account and KDE for calendar and contacts. The only code change I have made is the activesyncd patch in https://bugs.freedesktop.org/show_bug.cgi?id=59265 It works mostly, although sometimes the server insists on a FolderSync. I am currently working on trying to reproduce that reliably so I can implement a fix in activesyncd to do the FolderSync if the server complains. At the moment I haven't worked out what causes the error. Note that if the error occurs, I can force a folder sync using: dbus-send --print-reply \ --dest=org.meego.activesyncd /EasCommon \ org.meego.activesyncd.EasCommon.get_folders \ string:'u...@company.com' boolean:true I haven't yet added code to handle folder names so folders have to be set up using folder IDs (determined by looking in activesyncd's cache). I was going to add a Wiki page showing the configuration commands I use, but before doing that I thought I would post them here for comment. Is anything here wrong or unnecessary? # Activesynd setup gconftool --type string -s \ /apps/activesyncd/accounts/u...@work.com/username workdomain\username gconftool --type string --set \ /apps/activesyncd/accounts/u...@work.com/serverUri \ https://activesync.work.com/Microsoft-Server-ActiveSync # Contacts folder syncevolution --configure --template none keyring=KDE backend=kde-contacts \ database=akonadi:?collection=17 @KDE-test contacts syncevolution --configure syncURL= username=u...@work.com \ backend=eas-contacts database=2 dumpData=0 printChanges=0 \ target-config@work-test contacts syncevolution --configure --template none peerIsClient=1 \ syncURL=local://@work-test username= sync=two-way \ work-test@KDE-test contacts # Personal contacts folder syncevolution --configure --template none keyring=KDE backend=kde-contacts \ database=akonadi:?collection=21 @KDE-test personal syncevolution --configure syncURL= username=u...@work.com \ backend=eas-contacts database=25 dumpData=0 printChanges=0 \ target-config@work-test personal syncevolution --configure --template none peerIsClient=1 \ syncURL=local://@work-test username= sync=two-way \ work-test@KDE-test personal # Calendar folder syncevolution --configure --template none keyring=KDE backend=kde-calendar \ database=akonadi:?collection=19 @KDE-test calendar syncevolution --configure syncURL= username=u...@work.com \ backend=eas-events database=1 dumpData=0 printChanges=0 \ target-config@work-test calendar syncevolution --configure --template none peerIsClient=1 \ syncURL=local://@work-test username= sync=two-way \ work-test@KDE-test calendar # Sync all three folders syncevolution work-test@KDE-test ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
[SyncEvolution] Activesyncd: todos and memos
Is there any particular reason (apart from just lack of time so far) why activesyncd does not handle todos or memos? I note that syncevolution has backends called eas-todos and eas-memos, but activesyncd only has code to handle mails, events and contacts. I agree that events and contacts are much higher priority but I am just wondering whether there is any reason todos or memos cause any particular problem. Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] Naming a folder when using ActiveSync
Thanks for the guidance, Patrick. On Sunday 20 January 2013 13:36:39 Patrick Ohly wrote: I think both activesyncd and libeasclient should continue to just accept the folder ID, because it is unambiguous. The folder name is not. Ah. I had assumed that the Folder ID was transient and could change (for example, as a result of other folders being created/removed). However, reading the description of FolderSync carefully (e.g. http://msdn.microsoft.com/en-us/library/gg650851%28v=exchg.80%29.aspx) does suggest that the Folder ID does not change. For example, that page says: The ServerId element is used to identify folders that have been updated... So ServerId identifies the object, rather than being an attribute of the object which is being reported. That said, what should the user experience for SyncEvolution be if they set up a sync with a Folder called (say) Friends, which they later renamed on the server as School Friends and created a new folder called Friends? Probably not worth worrying about -- just allowing them to specify a folder by name instead of Id would be an improvement! The place to implement some more user-friendly behavior is in the SyncEvolution backend. Have a look at EvolutionSyncSource::findSource() and how that backend implements getDatabases(). Note that findSource() could (should?) be improved to detect ambiguities, for example a name matching two different sources, and then throwing an error. Currently it just picks the first one it finds. I will look at it. In the ActiveSync backend getDatabases() is just a stub. It should use the get_folders method. I don't remember why we didn't do that - perhaps because the setup code in Evolution was doing the entire configuration. I will look at that as well. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
[SyncEvolution] Naming a folder when using ActiveSync
I am trying to sync with a particular, named Exchange contacts folder. I can sync with the default contacts folder but I can't find any way to specify a name. I have tried setting the database attribute in the target-config. This gets passed to activesyncd who inserts the name in the CollectionId. Unfortunately Exchange doesn't like that -- it wants the collection ID number, not the folder name. I have not yet tried using the collection ID number of the folder in the database attribute. But even if that works, it would be much easier if activesyncd would translate the folder name into the ID using a FolderSync. Before I look at adding code to do that, can you confirm that the approach of setting the database attribute is the correct way to specify the folder? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] Naming a folder when using ActiveSync
On Saturday 19 January 2013 19:17:19 Graham Cobb wrote: Before I look at adding code to do that, can you confirm that the approach of setting the database attribute is the correct way to specify the folder? Hmm. I have looked at the activesyncd code and have noted: 1) It maintains a cache of the folder hierarchy 2) It exposes a DBUS method (get_folders) to allow a client to retrieve the folder hierarchy So, what is the desired behaviour here? Should activesyncd be interpreting the folder_id argument of the sync_folder_items method as a folder name (and translating it internally into a numeric id)? Or should the caller (libeasclient?) be translating folder names into IDs? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
[SyncEvolution] ActiveSync: need FolderSync
I solved my first problem: MIcosoft was returning a 403 error to the Sync command because there was no X-MS-PolicyKey. When I changed to code to always add X-MS-PolicyKey: 0 if there was no policy_key already set, the server was happy (it triggered provisioning, of course, so a non-zero policy key was used for later commands). I thought that a missing X-MS-PolicyKey should be the sme as X-MS-PolicyKey: 0 but that does not seem to be the case, at least with this server. That then leads me on to the next problem... The initial Sync command activesyncd sends is being rejected with an error: Mailbox folders are not synchronized, need FolderSync first Am I supposed to configure folder information in syncevolution manually? Or should activesyncd be doing a FolderSync? This http://msdn.microsoft.com/en- us/library/exchange/jj572420%28v=exchg.140%29.aspx Microsoft article seems to suggest that a full sync should start by synchronising folders. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] ActiveSync: need FolderSync
On Friday 11 January 2013 19:33:59 Patrick Ohly wrote: activesyncd should do the FolderSync automatically and then pick the default folder for address book and calendar if no specific folder was configured. The problem was my configuration (I was getting very confused between the two contexts involved). I can now sync contacts with Exchange! The only code change necessary, in the end, was to send X-MS-PolicyKey: 0 in the first message. Thanks for the help. Your pointer to the folder code helped me work out what was going wrong. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] ActiveSync debugging server?
On Wednesday 09 January 2013 22:43:43 Graham Cobb wrote: Alternatively, anyone implemented an ActiveSync proxy so I can proxy the server and log the messages? I found an answer: mitmproxy. It works well (although it would be even better if it knew how to decode wbxml). I even found the problem, I think. It seems that the Username in the command parameters should just be the username without the domain, but the domain\username format has to be used for the authorisation. I will try that out when I get a chance. If it works, I'll send a patch. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
[SyncEvolution] ActiveSync debugging server?
I am trying to work out why activesyncd is not working with a particular Microsoft server, although other clients work. The problem is a 403 rejection on the first command (with no attempt at provisioning). I would like to see what the working clients put in their messages to compare. Unfortunately, the server uses SSL so I can't just capture the traffic with wireshark. Does anyone have a simple ActiveSync server simulator or tester? I would like to configure a working client to talk to a simulator and see if I can hack up enough of a dialog to see how the clients handle the initial exchange. I already know that they start the dialogue with an OPTIONS message, and expect a reply. If not, I will craft something myself but I thought I would check if anyone has already done anything like this. Alternatively, anyone implemented an ActiveSync proxy so I can proxy the server and log the messages? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
