From g+syncevolution at cobb.uk.net Sat Oct 1 17:00:38 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Sat, 1 Oct 2016 18:00:38 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1475153100.11658.12.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> Message-ID: <28d65f46-afd3-b82e-c625-44c913c6b22e@cobb.uk.net> 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From g+syncevolution at cobb.uk.net Sun Oct 2 13:21:39 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Sun, 2 Oct 2016 14:21:39 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <28d65f46-afd3-b82e-c625-44c913c6b22e@cobb.uk.net> References: <1475153100.11658.12.camel@intel.com> <28d65f46-afd3-b82e-c625-44c913c6b22e@cobb.uk.net> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sun Oct 2 13:39:11 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 02 Oct 2016 15:39:11 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: References: <1475153100.11658.12.camel@intel.com> <28d65f46-afd3-b82e-c625-44c913c6b22e@cobb.uk.net> Message-ID: <1475415551.13953.20.camel@intel.com> On Sun, 2016-10-02 at 14:21 +0100, Graham Cobb wrote: > 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. Thanks for tracking that down. Now I just need to figure out how to integrate those additional steps into the build process... > 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. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From g+syncevolution at cobb.uk.net Sun Oct 2 22:04:45 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Sun, 2 Oct 2016 23:04:45 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1475415551.13953.20.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> <28d65f46-afd3-b82e-c625-44c913c6b22e@cobb.uk.net> <1475415551.13953.20.camel@intel.com> Message-ID: 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 From g+syncevolution at cobb.uk.net Mon Oct 3 12:39:24 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Mon, 3 Oct 2016 13:39:24 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: References: <1475153100.11658.12.camel@intel.com> <28d65f46-afd3-b82e-c625-44c913c6b22e@cobb.uk.net> <1475415551.13953.20.camel@intel.com> Message-ID: 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. From g+syncevolution at cobb.uk.net Mon Oct 3 18:00:33 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Mon, 3 Oct 2016 19:00:33 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: References: <1475153100.11658.12.camel@intel.com> <28d65f46-afd3-b82e-c625-44c913c6b22e@cobb.uk.net> <1475415551.13953.20.camel@intel.com> Message-ID: <9a684add-5e39-9cac-7a28-b134d813d95e@cobb.uk.net> 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 From g+syncevolution at cobb.uk.net Fri Oct 7 09:59:23 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Fri, 7 Oct 2016 10:59:23 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <9a684add-5e39-9cac-7a28-b134d813d95e@cobb.uk.net> References: <1475153100.11658.12.camel@intel.com> <28d65f46-afd3-b82e-c625-44c913c6b22e@cobb.uk.net> <1475415551.13953.20.camel@intel.com> <9a684add-5e39-9cac-7a28-b134d813d95e@cobb.uk.net> Message-ID: 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 From patrick.ohly at intel.com Fri Oct 7 11:19:33 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 07 Oct 2016 13:19:33 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: References: <1475153100.11658.12.camel@intel.com> <28d65f46-afd3-b82e-c625-44c913c6b22e@cobb.uk.net> <1475415551.13953.20.camel@intel.com> <9a684add-5e39-9cac-7a28-b134d813d95e@cobb.uk.net> Message-ID: <1475839173.473.1.camel@intel.com> On Fri, 2016-10-07 at 10:59 +0100, Graham Cobb wrote: > 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). I've fixed the schema install bug and will look at the other one next, then make new binaries available. > > 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? 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. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From g+syncevolution at cobb.uk.net Fri Oct 7 18:03:18 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Fri, 7 Oct 2016 19:03:18 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1475839173.473.1.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> <28d65f46-afd3-b82e-c625-44c913c6b22e@cobb.uk.net> <1475415551.13953.20.camel@intel.com> <9a684add-5e39-9cac-7a28-b134d813d95e@cobb.uk.net> <1475839173.473.1.camel@intel.com> Message-ID: <7de97420-23d2-ebe4-b379-c515b1c23d3d@cobb.uk.net> 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. From patrick.ohly at intel.com Sun Oct 2 13:36:50 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 02 Oct 2016 15:36:50 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <28d65f46-afd3-b82e-c625-44c913c6b22e@cobb.uk.net> References: <1475153100.11658.12.camel@intel.com> <28d65f46-afd3-b82e-c625-44c913c6b22e@cobb.uk.net> Message-ID: <1475415410.13953.18.camel@intel.com> On Sat, 2016-10-01 at 18:00 +0100, Graham Cobb wrote: > 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"). Indeed, I should have mentioned activesync as something which needs manual testing :-/ I no longer have an Exchange server to test against, so all I do at the moment is to build activesyncd and the backend. I probably should bite the bullet and pay for one of the hosted Exchange services. > 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? The script is still around, and you will still need it on old systems. Some more modern distros may set up a user session bus even for headless logins. On those you won't need the script, or D-Bus may be recent enough to have dbus-run-session, which is a better alternative to dbus-session.sh. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From Justus-bulk at Piater.name Mon Oct 3 09:04:32 2016 From: Justus-bulk at Piater.name (Justus Piater) Date: Mon, 3 Oct 2016 18:04:32 +0900 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1475153100.11658.12.camel@intel.com> (Patrick Ohly's message of "Thu, 29 Sep 2016 14:45:00 +0200") References: <1475153100.11658.12.camel@intel.com> Message-ID: <87h98t3isf.fsf@uibk.ac.at> Patrick Ohly wrote on Thu, 29 Sep 2016 14:45:00 +0200: > 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. I just built it on my Arch machine, and it appears to function correctly. The only patch required is the replacement of python by python2. Note that I cannot test syncevo-http-server anymore as my use case is gone. Best, Justus _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From tino.keitel+syncevolution at tikei.de Tue Oct 4 09:21:33 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Tue, 4 Oct 2016 11:21:33 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1475153100.11658.12.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> Message-ID: <20161004092133.crno4optt67uq7pd@mac.home> Hi, I updated the Debian packaging and it builds and installs fine. I hope to get some basic testing done this week. Is it intended that there was no version bump in libsynthesis for quite some time? Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Tue Oct 4 10:29:23 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 04 Oct 2016 12:29:23 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <20161004092133.crno4optt67uq7pd@mac.home> References: <1475153100.11658.12.camel@intel.com> <20161004092133.crno4optt67uq7pd@mac.home> Message-ID: <1475576963.23779.37.camel@intel.com> On Tue, 2016-10-04 at 11:21 +0200, Tino Mettler wrote: > I updated the Debian packaging and it builds and installs fine. I hope > to get some basic testing done this week. Thanks! > Is it intended that there was no version bump in libsynthesis for quite > some time? There's been no new upstream release. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From tino.keitel+syncevolution at tikei.de Tue Oct 4 10:38:31 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Tue, 4 Oct 2016 12:38:31 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1475576963.23779.37.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> <20161004092133.crno4optt67uq7pd@mac.home> <1475576963.23779.37.camel@intel.com> Message-ID: <20161004103831.GA13472@eazy.amigager.de> On Tue, Oct 04, 2016 at 12:29:23 +0200, Patrick Ohly wrote: > On Tue, 2016-10-04 at 11:21 +0200, Tino Mettler wrote: > > Is it intended that there was no version bump in libsynthesis for quite > > some time? > > There's been no new upstream release. Hi, my understanding was that syncevolution requires changes in your libsynthesis version, so I thought that some sort of version check would be worthwhile. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Tue Oct 4 12:01:07 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 04 Oct 2016 14:01:07 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <20161004103831.GA13472@eazy.amigager.de> References: <1475153100.11658.12.camel@intel.com> <20161004092133.crno4optt67uq7pd@mac.home> <1475576963.23779.37.camel@intel.com> <20161004103831.GA13472@eazy.amigager.de> Message-ID: <1475582467.23779.47.camel@intel.com> On Tue, 2016-10-04 at 12:38 +0200, Tino Mettler wrote: > On Tue, Oct 04, 2016 at 12:29:23 +0200, Patrick Ohly wrote: > > On Tue, 2016-10-04 at 11:21 +0200, Tino Mettler wrote: > > > > Is it intended that there was no version bump in libsynthesis for quite > > > some time? > > > > There's been no new upstream release. > > Hi, > > my understanding was that syncevolution requires changes in your > libsynthesis version, so I thought that some sort of version check > would be worthwhile. Can't you do that with a libsynthesis >= Debian-Version where "Debian-Version" gets bumped each time you update the libsynthesis source code? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From tino.keitel+syncevolution at tikei.de Tue Oct 4 13:44:05 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Tue, 4 Oct 2016 15:44:05 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1475582467.23779.47.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> <20161004092133.crno4optt67uq7pd@mac.home> <1475576963.23779.37.camel@intel.com> <20161004103831.GA13472@eazy.amigager.de> <1475582467.23779.47.camel@intel.com> Message-ID: <20161004134405.GA5841@eazy.amigager.de> On Tue, Oct 04, 2016 at 14:01:07 +0200, Patrick Ohly wrote: > Can't you do that with a libsynthesis >= Debian-Version where > "Debian-Version" gets bumped each time you update the libsynthesis > source code? Hi, thats what I'm doing now. However, versions like "3.4.0.47.5+syncevolution-1.5.1-2" might scare off some people. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Wed Oct 5 07:19:03 2016 From: deloptes at gmail.com (deloptes) Date: Wed, 5 Oct 2016 09:19:03 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 References: <1475153100.11658.12.camel@intel.com> <20161004092133.crno4optt67uq7pd@mac.home> <1475576963.23779.37.camel@intel.com> <20161004103831.GA13472@eazy.amigager.de> <1475582467.23779.47.camel@intel.com> <20161004134405.GA5841@eazy.amigager.de> Message-ID: Tino Mettler wrote: > "3.4.0.47.5+syncevolution-1.5.1-2" might scare off some people. I would skip "syncevolution" and go for "3.4.0.47.5+1.5.1-2" It's just a convention, so important is, that it's written somewhere what it means. regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sun Oct 16 19:33:38 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 16 Oct 2016 21:33:38 +0200 Subject: Release preparations for 1.5.2 In-Reply-To: <1475153100.11658.12.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> Message-ID: <1476646418.14278.7.camel@intel.com> On Thu, 2016-09-29 at 14:45 +0200, Patrick Ohly wrote: > I've finished preparing source code and binaries for a 1.5.2 release of > SyncEvolution. The source code has not been tagged yet, only the master > branches of syncevolution, libsynthesis and activesyncd were updated. > activesyncd continues to receive some SyncEvolution specific patches > (the "folder sync hacks" from Graham) which are not upstream. > > The binaries are available in the "experimental" apt repo > (http://downloads.syncevolution.org/apt/ with "experimental" as release > name) or as individual .tar.gz files in > http://downloads.syncevolution.org/syncevolution. Look for version > 1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa 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). 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". Graham, the new update should fix the problems you had with libical and GSetting schemas in activesyncd. I still haven't re-enabled testing of ActiveSync myself, though. deloptes, your TDE backends are included, albeit with some changes to make them compile when disabled. Please check that this works as intended for you. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Fri Oct 21 06:07:27 2016 From: deloptes at gmail.com (deloptes) Date: Fri, 21 Oct 2016 08:07:27 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> Message-ID: Patrick Ohly wrote: > deloptes, your TDE backends are included, albeit with some changes to > make them compile when disabled. Please check that this works as > intended for you. Hi Patrick, I let it compile yesterday on a test vm and got following error src/backends/tde/TDEPlatform.cpp: In function 'void SyncEvo::TDEInitMainSlot(const char*)': src/backends/tde/TDEPlatform.cpp:69:2: error: 'syncevotdewlt' was not declared in this scope syncevotdewlt.dcopClient()->registerAs(syncevotdewallet.name()); ^ Makefile:8046: recipe for target 'src/backends/tde/src_backends_tde_platformtde_la-TDEPlatform.lo' failed I am not able to look into it now - perhaps in the evening. Can I rebuild the debian package out of the source somehow this would be really great? I think this would be the next step for me. regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From g+syncevolution at cobb.uk.net Fri Oct 21 17:04:27 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Fri, 21 Oct 2016 18:04:27 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1476646418.14278.7.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Oct 21 18:46:39 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 21 Oct 2016 20:46:39 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> Message-ID: <1477075599.21499.5.camel@intel.com> On Fri, 2016-10-21 at 18:04 +0100, Graham Cobb wrote: > 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? No, that is a regression. I'll fix it. libwbxml2.so.1 needs to be included in the .deb exactly because distros don't have a recent enough version. I know, this isn't particularly good packaging, but as long as it works, I don't care about "nice". These are all problems which should have been caught by the automated testing. I really need to sign up for some hosted Exchange service :-/ > > 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? No, "unstable" should also have had it. I must have missed one rsync invocation. I'll fix that as part of the next build. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From g+syncevolution at cobb.uk.net Sun Oct 23 09:51:41 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Sun, 23 Oct 2016 10:51:41 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1477075599.21499.5.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> <1477075599.21499.5.camel@intel.com> Message-ID: <3672a063-960c-1f7d-4aa0-465a4cc8a09e@cobb.uk.net> 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From g+syncevolution at cobb.uk.net Sun Oct 23 14:51:51 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Sun, 23 Oct 2016 15:51:51 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <3672a063-960c-1f7d-4aa0-465a4cc8a09e@cobb.uk.net> References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> <1477075599.21499.5.camel@intel.com> <3672a063-960c-1f7d-4aa0-465a4cc8a09e@cobb.uk.net> Message-ID: <8497072f-80b4-6732-5934-d69c9f5db5fe@cobb.uk.net> 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From g+syncevolution at cobb.uk.net Sun Oct 23 18:11:20 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Sun, 23 Oct 2016 19:11:20 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <8497072f-80b4-6732-5934-d69c9f5db5fe@cobb.uk.net> References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> <1477075599.21499.5.camel@intel.com> <3672a063-960c-1f7d-4aa0-465a4cc8a09e@cobb.uk.net> <8497072f-80b4-6732-5934-d69c9f5db5fe@cobb.uk.net> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Oct 26 14:21:33 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 26 Oct 2016 16:21:33 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> <1477075599.21499.5.camel@intel.com> <3672a063-960c-1f7d-4aa0-465a4cc8a09e@cobb.uk.net> <8497072f-80b4-6732-5934-d69c9f5db5fe@cobb.uk.net> Message-ID: <1477491693.2887.48.camel@intel.com> On Sun, 2016-10-23 at 19:11 +0100, Graham Cobb wrote: > On 23/10/16 15:51, Graham Cobb wrote: > > I don't think that is a regression in this version (I guess the previous > > version has the same problem), although until I can work out exactly > > what is happening I can't be sure. I will look into it a little further > > but I may not be able to fix it before I go on holiday. It might even > > require proper protocol version handling (which we have avoided so far > > -- see an earlier thread about EAS versions some time ago). > > The problem turned out to be PolicyKey related (I hate "provisioning"). > This exchange server seems to handle the need for provisioning > differently and doesn't send the 449 status unless you send a bad PolicyKey. > > The workround is to make sure that the policy-key is configured in the > account gsettings. Any non-null value will do, including 0. This > triggers provisioning, which will end up eventually with a valid PolicyKey. > > I have updated the wiki page to include setting that. Thanks for the wiki update, that has already helped one person - myself! I've signed up for a hosted Exchange 2016 service and (re-)enabled that in the nightly testing, replacing gconftool-2 commands with gsettings commands as per your instructions in the wiki. I am using the policy-key workaround, but haven't actually verified whether it is needed. With the work-around, I am running into a problem (see https://nightly.syncevolution.org/2016-10-26-05-27_exchange_sanity_release-eas-jessie-amd64_prebuilt-jessie-amd64_trusty-amd64/prebuilt-jessie-amd64/21-exchange/ and https://nightly.syncevolution.org/2016-10-26-05-27_exchange_sanity_release-eas-jessie-amd64_prebuilt-jessie-amd64_trusty-amd64/prebuilt-jessie-amd64/21-exchange/Client_Source_eas_contact_testImport.log.html): basically any attempt to create some item on the Exchange server fails with an error code 12 = GDBus.Error:org.meego.activesyncd.SyncError.FolderHierarchyChanged: Sync error: Mailbox folders are not synchronized, need FolderSync first Here's a snippet from the activesyncd.log: ... (process:111:0xf61d090): libeas-DEBUG:> POST /Microsoft-Server-ActiveSync?Cmd=Sync&User=nightly at ouvku.hostedoffice.ag&DeviceId=aaaaaaa99cb14effac6a8f447AAAAAAA&DeviceType=MeeGo HTTP/1.1 (process:111:0xf61d090): libeas-DEBUG:> Soup-Debug-Timestamp: 1477486033 (process:111:0xf61d090): libeas-DEBUG:> Soup-Debug: SoupSessionAsync 1 (0xf623b90), SoupMessage 10 (0x147a7170), SoupSocket 11 (0x147d23a0) ... (process:111:0xf61d090): libeas-DEBUG:Received 12 bytes for request 0x14793f00 (process:111:0xf61d090): libeas-DEBUG:< HTTP/1.1 200 OK (process:111:0xf61d090): libeas-DEBUG:< Soup-Debug-Timestamp: 1477486034 (process:111:0xf61d090): libeas-DEBUG:< Soup-Debug: SoupMessage 10 (0x147a7170) (process:111:0xf61d090): libeas-DEBUG:< Cache-Control: private (process:111:0xf61d090): libeas-DEBUG:< Content-Type: application/vnd.ms-sync.wbxml ... (process:111:0xf61d090): libeas-DEBUG:eas_connection - wbxml2xml++ (process:111:0xf61d090): libeas-DEBUG: === dump start: xml_len [168] === 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? > There are a few things that it might be nice to do one day (i.e. will > never happen :-) )... I have a similar list ;-} > 1) The whole gsettings stuff should be hidden from the users, with some > way to pass the necessary parameters from syncevolution. > > 2) I suspect that provisioning is now being triggered every time > activesyncd is restarted as loading the account details from gsettings > means activesyncd thinks the policy key has changed when it hasn't > really. We rely on this to get it set correctly the first time, but we > ought to find a way to work out that it hasn't actually changed. > > 3) The creation of Office365 means that for users using that service, > all the required parameters (except password) can be defaulted sensibly > if we know the email address. Maybe we should allow the case of > specifying an account which has not been set up in gsettings to use the > account name as an email address and then use the Office365 defaults. The envisioned solution was some kind of external account setup, with SyncEvolution completely hidden. All of these points would fit into such a setup helper. As it stands now, SyncEvolution is just some infrastructure component of a larger system, with a command line for power users. The only problem is that this larger system has never been implemented for most desktop systems. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From g+syncevolution at cobb.uk.net Wed Oct 26 15:05:17 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Wed, 26 Oct 2016 16:05:17 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1477491693.2887.48.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> <1477075599.21499.5.camel@intel.com> <3672a063-960c-1f7d-4aa0-465a4cc8a09e@cobb.uk.net> <8497072f-80b4-6732-5934-d69c9f5db5fe@cobb.uk.net> <1477491693.2887.48.camel@intel.com> Message-ID: <1811fbef-af99-b128-632b-778d4d228e30@cobb.uk.net> On 26/10/16 15:21, Patrick Ohly wrote: > I am using the policy-key workaround, but haven't actually verified > whether it is needed. I haven't done exhaustive testing, but I think it is needed if the policy-key in gsettings would otherwise be reset (i.e. null). In other words, if you are completely deleting the gsettings and recreating them you need something non-null in the policy-key. If you are not recreating them then they will already have a non-null (and possibly even correct) value. Yes, that raises the question of why the code doesn't check the value of policy-key when it is loaded and change a null value to something else (say 0)! >With the work-around, I am running into a problem > (see > https://nightly.syncevolution.org/2016-10-26-05-27_exchange_sanity_release-eas-jessie-amd64_prebuilt-jessie-amd64_trusty-amd64/prebuilt-jessie-amd64/21-exchange/ and https://nightly.syncevolution.org/2016-10-26-05-27_exchange_sanity_release-eas-jessie-amd64_prebuilt-jessie-amd64_trusty-amd64/prebuilt-jessie-amd64/21-exchange/Client_Source_eas_contact_testImport.log.html): basically any attempt to create some item on the Exchange server fails with an error code 12 = GDBus.Error:org.meego.activesyncd.SyncError.FolderHierarchyChanged: Sync error: Mailbox folders are not synchronized, need FolderSync first > > Here's a snippet from the activesyncd.log: > > ... > (process:111:0xf61d090): libeas-DEBUG:> POST /Microsoft-Server-ActiveSync?Cmd=Sync&User=nightly at ouvku.hostedoffice.ag&DeviceId=aaaaaaa99cb14effac6a8f447AAAAAAA&DeviceType=MeeGo HTTP/1.1 > (process:111:0xf61d090): libeas-DEBUG:> Soup-Debug-Timestamp: 1477486033 > (process:111:0xf61d090): libeas-DEBUG:> Soup-Debug: SoupSessionAsync 1 (0xf623b90), SoupMessage 10 (0x147a7170), SoupSocket 11 (0x147d23a0) > ... > (process:111:0xf61d090): libeas-DEBUG:Received 12 bytes for request 0x14793f00 > (process:111:0xf61d090): libeas-DEBUG:< HTTP/1.1 200 OK > (process:111:0xf61d090): libeas-DEBUG:< Soup-Debug-Timestamp: 1477486034 > (process:111:0xf61d090): libeas-DEBUG:< Soup-Debug: SoupMessage 10 (0x147a7170) > (process:111:0xf61d090): libeas-DEBUG:< Cache-Control: private > (process:111:0xf61d090): libeas-DEBUG:< Content-Type: application/vnd.ms-sync.wbxml > ... > (process:111:0xf61d090): libeas-DEBUG:eas_connection - wbxml2xml++ > (process:111:0xf61d090): libeas-DEBUG: > === dump start: xml_len [168] === > > > > 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Oct 26 16:10:02 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 26 Oct 2016 18:10:02 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1811fbef-af99-b128-632b-778d4d228e30@cobb.uk.net> References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> <1477075599.21499.5.camel@intel.com> <3672a063-960c-1f7d-4aa0-465a4cc8a09e@cobb.uk.net> <8497072f-80b4-6732-5934-d69c9f5db5fe@cobb.uk.net> <1477491693.2887.48.camel@intel.com> <1811fbef-af99-b128-632b-778d4d228e30@cobb.uk.net> Message-ID: <1477498202.2887.53.camel@intel.com> On Wed, 2016-10-26 at 16:05 +0100, Graham Cobb wrote: > > 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. I'll try that, thanks for the hint... yes, it helped. I'm now running into some new conversion issues for calendar data (time zone related). To be checked. > 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. I didn't run into it with older Exchange or Google's ActiveSync implementation, but now with Exchange 2016 I seem to hit it reliably. > 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. The automated testing already always starts from scratch. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From g+syncevolution at cobb.uk.net Wed Oct 26 16:44:16 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Wed, 26 Oct 2016 17:44:16 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1477498202.2887.53.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> <1477075599.21499.5.camel@intel.com> <3672a063-960c-1f7d-4aa0-465a4cc8a09e@cobb.uk.net> <8497072f-80b4-6732-5934-d69c9f5db5fe@cobb.uk.net> <1477491693.2887.48.camel@intel.com> <1811fbef-af99-b128-632b-778d4d228e30@cobb.uk.net> <1477498202.2887.53.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Sat Oct 22 22:25:31 2016 From: deloptes at gmail.com (deloptes) Date: Sun, 23 Oct 2016 00:25:31 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> Message-ID: Patrick Ohly wrote: > deloptes, your TDE backends are included, albeit with some changes to > make them compile when disabled. Please check that this works as > intended for you. Two minor problems. After applying the changes (see attached patch) it builds fine. I do not expect functional issues, but I'll test tomorrow and report back if any. The TDE wallet backend is not tested. in fact it crashes syncevolution when build. Perhaps we should either mention this or remove it for the time being. I am just not able to do some meaningful testing on it ATM. I let you decide what is the best to do. regards -------------- next part -------------- A non-text attachment was scrubbed... Name: syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf.tde.patch Type: text/x-diff Size: 1521 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Sun Oct 23 20:09:36 2016 From: deloptes at gmail.com (deloptes) Date: Sun, 23 Oct 2016 22:09:36 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> Message-ID: I splitted both (tde and tdepim) tde.patch is to prevent the wallet backend from crashing syncevolution when enabled. Again tdewallet backend is not tested by any means as I am not using it. tdepim.patch is to make the notes backend build. Unfortunately I was still not able to perform an e2e test with this version. I am looking forward to do it next. Again I do not expect any functional issues as I am using the code from the previous version on daily bases. I hope this helps regards -------------- next part -------------- A non-text attachment was scrubbed... Name: syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf.tde.patch Type: text/x-diff Size: 2256 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf.tdepim.patch Type: text/x-diff Size: 784 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Wed Oct 26 12:36:38 2016 From: deloptes at gmail.com (deloptes) Date: Wed, 26 Oct 2016 14:36:38 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> Message-ID: Patrick Ohly wrote: > On Thu, 2016-09-29 at 14:45 +0200, Patrick Ohly wrote: >> I've finished preparing source code and binaries for a 1.5.2 release of >> SyncEvolution. The source code has not been tagged yet, only the master >> branches of syncevolution, libsynthesis and activesyncd were updated. >> activesyncd continues to receive some SyncEvolution specific patches >> (the "folder sync hacks" from Graham) which are not upstream. >> >> The binaries are available in the "experimental" apt repo >> (http://downloads.syncevolution.org/apt/ with "experimental" as release >> name) or as individual .tar.gz files in >> http://downloads.syncevolution.org/syncevolution. Look for version >> 1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa > > 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). > > 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". > > Graham, the new update should fix the problems you had with libical and > GSetting schemas in activesyncd. I still haven't re-enabled testing of > ActiveSync myself, though. > > deloptes, your TDE backends are included, albeit with some changes to > make them compile when disabled. Please check that this works as > intended for you. > No functional issues on tdepim backend found. Tested with Nokia N9 and Nokia 5530 regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Sat Oct 1 07:11:31 2016 From: deloptes at gmail.com (deloptes) Date: Sat, 1 Oct 2016 09:11:31 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> <1475054654.7488.16.camel@intel.com> Message-ID: Patrick Ohly wrote: > On Tue, 2016-09-27 at 08:57 +0200, deloptes wrote: >> Patrick Ohly wrote: >> >> > On Mon, 2016-09-26 at 23:01 +0200, deloptes wrote: >> >> >> >> >> Hi, >> >> I hope you have not forgotten about this problem. Please look into my >> >> last message and let me know if I can do something more. If it is the >> >> same issue as the TDE/libkcal one, the fix should be really simple. >> > >> > There was a misunderstanding: I need you to re-run the sync as >> > explained above (loglevel=4 as command line parameter), and *then* the >> > resulting log html file will have more information. The one you sent >> > doesn't include information about the detailed item conversion. >> > >> >> Might be my bad - sorry. >> >> Here >> [2016-09-27 08:51:45.496] Created new item of datatype 'vCalendar10', >> localID='' remoteID='526' >> >> DESCRIPTION;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:=D0=A2=D0=B5=D1=81=D1=82 >> =D0=B4=D1=8A=D0=BB=D0=B3=D0=BE =D0=BE=D0=BF=D0==0D=0A= >> =B8=D1=81=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B7=D0=B0 >> =D0=B7=D0=B0=D0=B4=D0=B0==0D=0A= >> >> Note ==0D=0A= >> >> It is also visible in syncevolution-log_trm002_003_incoming.xml > > Sorry, I'm still confused about what the actual, unmodified incoming > data is. Can you attach the entire log file? > > I doubt that I will have time to fix this, but at least I should be able > to reproduce it and point you into the right direction in the code. > I am not sure how to get the raw message that comes from the phone. It might be specific to N9 and Cyrillic UTF8 I tracked the issue down to src/synthesis/src/sysync/mimedirprofile.cpp static void decodeValue I add a look ahead for the case '=' followed by '=' and '0D', which solves the problem. I still have a problem with new lines '\n'. The '\' is escaped and I see it in the text, so from aasdf??\nTest it does aasdf??\\nTest I'm not sure if it is the right place to do it as those =0D=0A are scattered all over the place. According specs "quoted-printable" line ends with '=\r\n' in my case we see '=' left over '\r\n' converted into '=0D=0A' and '=' added. I guess simple '\n' terminates the line. Is it possible that '\r\n' is converted into '=0D=0A=' before decodeValue is called? I think this is an odd bug, but I'm not sure how to proceed with it thanks _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Sat Oct 1 22:31:47 2016 From: deloptes at gmail.com (deloptes) Date: Sun, 2 Oct 2016 00:31:47 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> <1475054654.7488.16.camel@intel.com> Message-ID: Patrick Ohly wrote: > On Tue, 2016-09-27 at 08:57 +0200, deloptes wrote: >> Patrick Ohly wrote: >> >> > On Mon, 2016-09-26 at 23:01 +0200, deloptes wrote: >> >> >> >> >> Hi, >> >> I hope you have not forgotten about this problem. Please look into my >> >> last message and let me know if I can do something more. If it is the >> >> same issue as the TDE/libkcal one, the fix should be really simple. >> > >> > There was a misunderstanding: I need you to re-run the sync as >> > explained above (loglevel=4 as command line parameter), and *then* the >> > resulting log html file will have more information. The one you sent >> > doesn't include information about the detailed item conversion. >> > >> >> Might be my bad - sorry. >> >> Here >> [2016-09-27 08:51:45.496] Created new item of datatype 'vCalendar10', >> localID='' remoteID='526' >> >> DESCRIPTION;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:=D0=A2=D0=B5=D1=81=D1=82 >> =D0=B4=D1=8A=D0=BB=D0=B3=D0=BE =D0=BE=D0=BF=D0==0D=0A= >> =B8=D1=81=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B7=D0=B0 >> =D0=B7=D0=B0=D0=B4=D0=B0==0D=0A= >> >> Note ==0D=0A= >> >> It is also visible in syncevolution-log_trm002_003_incoming.xml > > Sorry, I'm still confused about what the actual, unmodified incoming > data is. Can you attach the entire log file? > > I doubt that I will have time to fix this, but at least I should be able > to reproduce it and point you into the right direction in the code. > Looking into the synthesis quoted-printable parser .... it's really a brainf**k. I'm just wondering if I am the only one on this planet to have such issues doing a sync with UTF-8 encoded text. I was expecting to find something like the versit parser, which I think is really nice in KDE3/TDE[1], but I found here something self written, not based on grammar ... and giving me a lot of headache. Very very sad story! The diff is the closest I could get to make it work acceptable for me - it at least does not mangles the text. [1] https://git.trinitydesktop.org/cgit/tdepim/tree/libkcal/versit I hope it helps come to some solution. regards -------------- next part -------------- A non-text attachment was scrubbed... Name: mimedirprofile.cpp.diff Type: text/x-diff Size: 1799 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sun Oct 2 20:28:20 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 02 Oct 2016 22:28:20 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) In-Reply-To: References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> <1475054654.7488.16.camel@intel.com> Message-ID: <1475440100.13953.32.camel@intel.com> On Sun, 2016-10-02 at 00:31 +0200, deloptes wrote: > Patrick Ohly wrote: > > > On Tue, 2016-09-27 at 08:57 +0200, deloptes wrote: > >> Patrick Ohly wrote: > >> > >> > On Mon, 2016-09-26 at 23:01 +0200, deloptes wrote: > >> > >> >> > >> >> Hi, > >> >> I hope you have not forgotten about this problem. Please look into my > >> >> last message and let me know if I can do something more. If it is the > >> >> same issue as the TDE/libkcal one, the fix should be really simple. > >> > > >> > There was a misunderstanding: I need you to re-run the sync as > >> > explained above (loglevel=4 as command line parameter), and *then* the > >> > resulting log html file will have more information. The one you sent > >> > doesn't include information about the detailed item conversion. > >> > > >> > >> Might be my bad - sorry. > >> > >> Here > >> [2016-09-27 08:51:45.496] Created new item of datatype 'vCalendar10', > >> localID='' remoteID='526' > >> > >> > DESCRIPTION;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:=D0=A2=D0=B5=D1=81=D1=82 > >> =D0=B4=D1=8A=D0=BB=D0=B3=D0=BE =D0=BE=D0=BF=D0==0D=0A= > >> =B8=D1=81=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B7=D0=B0 > >> =D0=B7=D0=B0=D0=B4=D0=B0==0D=0A= > >> > >> Note ==0D=0A= > >> > >> It is also visible in syncevolution-log_trm002_003_incoming.xml > > > > Sorry, I'm still confused about what the actual, unmodified incoming > > data is. Can you attach the entire log file? > > > > I doubt that I will have time to fix this, but at least I should be able > > to reproduce it and point you into the right direction in the code. > > > > > Looking into the synthesis quoted-printable parser .... it's really a > brainf**k. I'm just wondering if I am the only one on this planet to have > such issues doing a sync with UTF-8 encoded text. If I understand this right (disclaimer: I'm not intimately familiar with the specs anymore, and have had no time to read up on them), it is the phone which is sending bogus data, right? Your explanation in https://bugs.freedesktop.org/show_bug.cgi?id=98019 shows the broken data after "Parsing", which is the raw data as sent by the phone. Perhaps it is indeed specific to your phone? Not sure about other N9 owners. > I was expecting to find something like the versit parser, which I think is > really nice in KDE3/TDE[1], but I found here something self written, not > based on grammar ... and giving me a lot of headache. > Very very sad story! Before you get worked up too much about this: remember that this parser has to support plenty of different formats (not just the modern revisions of the standard with sane rules for encoding, but also old ones, like vCalendar, which are terribly inconsistent), and data from peers which don't follow the standard. Having to support such a mess is not leading to nice code. And one more point: the N9 uses KCalExtended (or something derived from it, I lost track of the official name) as calendar storage, which probably uses the same code that you present as the better alternative. Isn't that the code then which sends the data with a broken encoding? > The diff is the closest I could get to make it work acceptable for me - it > at least does not mangles the text. > > [1] https://git.trinitydesktop.org/cgit/tdepim/tree/libkcal/versit > > I hope it helps come to some solution. I fear I need to sit down and study this more before I can do anything about this. Please don't hold your breath. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Sun Oct 2 21:19:44 2016 From: deloptes at gmail.com (deloptes) Date: Sun, 2 Oct 2016 23:19:44 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> <1475054654.7488.16.camel@intel.com> <1475440100.13953.32.camel@intel.com> Message-ID: Patrick Ohly wrote: [old content removed for visibility] > > If I understand this right (disclaimer: I'm not intimately familiar with > the specs anymore, and have had no time to read up on them), it is the > phone which is sending bogus data, right? > > Your explanation in https://bugs.freedesktop.org/show_bug.cgi?id=98019 > shows the broken data after "Parsing", which is the raw data as sent by > the phone. > > Perhaps it is indeed specific to your phone? Not sure about other N9 > owners. > I am not sure about it. How can I see what is in the message coming from the phone? Is syncevolution-log_trm002_003_incoming.xml (attached to the log) the internal message or the one sent by the phone? Alternatively can we enforce text/calendar instead of text/x-vcalendar? I tried setting this in the ini file .config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini but the engine refused with error. I am not even sure that this is OK to modify the file and expect to work. >> I was expecting to find something like the versit parser, which I think >> is really nice in KDE3/TDE[1], but I found here something self written, >> not based on grammar ... and giving me a lot of headache. >> Very very sad story! > > Before you get worked up too much about this: remember that this parser > has to support plenty of different formats (not just the modern > revisions of the standard with sane rules for encoding, but also old > ones, like vCalendar, which are terribly inconsistent), and data from > peers which don't follow the standard. Having to support such a mess is > not leading to nice code. > Yes, I understand this! However if you compare both approaches versit vs. sysync, i would have preferred to have the versit code as a base line. Anyway talking about this leads to nothing. We could only try to correct the problems we face. > And one more point: the N9 uses KCalExtended (or something derived from > it, I lost track of the official name) as calendar storage, which > probably uses the same code that you present as the better alternative. > Isn't that the code then which sends the data with a broken encoding? > Yes I think so and this leads me to the question if it is possible to enforce text/calendar (iCal) and not as it is per default in the Nokia_N900 template text/x-vcalendar (vCal). If this is doable I can understand why only I complain, besides the fact that I use English/German/Bulgarian/Russian and my wife Italian. Another option would be to set up some cleanup before passing the data to the parser. This would be a simple rule replacing ==0D=0A= with a simple =. I have never had a chance to look into the scripting options offered by syncevolution - is it thinkable/doable? >> The diff is the closest I could get to make it work acceptable for me - >> it at least does not mangles the text. >> >> [1] https://git.trinitydesktop.org/cgit/tdepim/tree/libkcal/versit >> >> I hope it helps come to some solution. > > I fear I need to sit down and study this more before I can do anything > about this. Please don't hold your breath. > No, it is just a reference. You have the RFC, the yacc grammar and the parser code. You can just go through the readme to get an idea. If this was the base for the sysync parser, things would be much easier. Sorry for bothering that much about it. I just have a feeling there is a spell over my attempt to sync in the past 10 years, first with opensync and now with Syncevolution, I always hit the wall in some way. I now changed the code as posted in the diff, to at least have some readable text, however I noticed that ',' is displayed as '\,' and new line chars are also double escaped, but I don't want to dig into it right now. I understand that this is not the correct way or place to handle this, so this diff is not a patch, but to show where it breaks. And thank you for the good help so far. regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Tue Oct 4 11:18:02 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 04 Oct 2016 13:18:02 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) In-Reply-To: References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> <1475054654.7488.16.camel@intel.com> <1475440100.13953.32.camel@intel.com> Message-ID: <1475579882.23779.45.camel@intel.com> On Sun, 2016-10-02 at 23:19 +0200, deloptes wrote: > Patrick Ohly wrote: > > [old content removed for visibility] > > > > If I understand this right (disclaimer: I'm not intimately familiar with > > the specs anymore, and have had no time to read up on them), it is the > > phone which is sending bogus data, right? > > > > Your explanation in https://bugs.freedesktop.org/show_bug.cgi?id=98019 > > shows the broken data after "Parsing", which is the raw data as sent by > > the phone. > > > > Perhaps it is indeed specific to your phone? Not sure about other N9 > > owners. > > > > I am not sure about it. How can I see what is in the message coming from the > phone? Is syncevolution-log_trm002_003_incoming.xml (attached to the log) > the internal message or the one sent by the phone? "incoming" is sent by the phone, so yes, that's the data sent by the phone. > Alternatively can we enforce text/calendar instead of text/x-vcalendar? > I tried setting this in the ini file > .config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini > but the engine refused with error. Was it a local error or did it occur after contacting the phone? Probably the latter. > I am not even sure that this is OK to > modify the file and expect to work. The Synthesis engine is able to exchange data in different formats and the configuration options control that aspect. However, the peer it talks to must support the same formats, which is not possible in this case: in it's DevInf, the N9 only reports "type=text/x-vcalendar, version=1.0" for its ./calendar data store. The expected error then is something about "no common format" (not sure what the wording is). > However if you compare both approaches versit vs. > sysync, i would have preferred to have the versit code as a base line. > Anyway talking about this leads to nothing. We could only try to correct > the problems we face. Agreed. > > And one more point: the N9 uses KCalExtended (or something derived from > > it, I lost track of the official name) as calendar storage, which > > probably uses the same code that you present as the better alternative. > > Isn't that the code then which sends the data with a broken encoding? > > > > Yes I think so and this leads me to the question if it is possible to > enforce text/calendar (iCal) and not as it is per default in the Nokia_N900 > template text/x-vcalendar (vCal). > If this is doable I can understand why only I complain, besides the fact > that I use English/German/Bulgarian/Russian and my wife Italian. It's also possible that N9/N900 users never used the direct syncing of calendar data over Bluetooth. I think using SyncEvolution on the phone to sync with some CalDAV server was more popular. vCalendar is a very limited format and only poorly supports modern concepts (meeting series, exceptions, time zones). Shoehorning iCalendar 2.0 data into vCalendar 1.0 is problematic. > Another option would be to set up some cleanup before passing the data to > the parser. This would be a simple rule replacing ==0D=0A= with a simple =. > I have never had a chance to look into the scripting options offered by > syncevolution - is it thinkable/doable? This might indeed be the best option. Let me check this in more detail. > Sorry for bothering that much about it. I just have a feeling there is a > spell over my attempt to sync in the past 10 years, first with opensync and > now with Syncevolution, I always hit the wall in some way. I won't comment on OpenSync here. You probably know already why it didn't work for you and in what state the project has been since they dropped MultiSync and tried again. Regarding SyncEvolution: you missed the time when it was under much more active development. Intel really helped move the project along for a while (additional developers, QA) and still does to a limited extend (hosting, a little bit of my time), but mostly the project is now in maintenance. Canonical has a much larger business interest in it now; unfortunately that hasn't really replaced Intel's support in the upstream project. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Tue Oct 4 21:03:17 2016 From: deloptes at gmail.com (deloptes) Date: Tue, 4 Oct 2016 23:03:17 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> <1475054654.7488.16.camel@intel.com> <1475440100.13953.32.camel@intel.com> <1475579882.23779.45.camel@intel.com> Message-ID: Thank you for the extended explanations in your reply. Patrick Ohly wrote: [old content removed for visibility] > >> Alternatively can we enforce text/calendar instead of text/x-vcalendar? >> I tried setting this in the ini file >> .config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini >> but the engine refused with error. > > Was it a local error or did it occur after contacting the phone? > Probably the latter. > I think it was a 10500 error. >> I am not even sure that this is OK to >> modify the file and expect to work. > > The Synthesis engine is able to exchange data in different formats and > the configuration options control that aspect. However, the peer it > talks to must support the same formats, which is not possible in this > case: in it's DevInf, the N9 only reports "type=text/x-vcalendar, > version=1.0" for its ./calendar data store. > > The expected error then is something about "no common format" (not sure > what the wording is). > So once again, please confirm. The configured "type=text/x-vcalendar" in .config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini does not enforce the phone to respond, rather it is based on the capability - correct? >> However if you compare both approaches versit vs. >> sysync, i would have preferred to have the versit code as a base line. >> Anyway talking about this leads to nothing. We could only try to correct >> the problems we face. > > Agreed. > >> > And one more point: the N9 uses KCalExtended (or something derived from >> > it, I lost track of the official name) as calendar storage, which >> > probably uses the same code that you present as the better alternative. >> > Isn't that the code then which sends the data with a broken encoding? >> > >> >> Yes I think so and this leads me to the question if it is possible to >> enforce text/calendar (iCal) and not as it is per default in the >> Nokia_N900 template text/x-vcalendar (vCal). >> If this is doable I can understand why only I complain, besides the fact >> that I use English/German/Bulgarian/Russian and my wife Italian. > > It's also possible that N9/N900 users never used the direct syncing of > calendar data over Bluetooth. I think using SyncEvolution on the phone > to sync with some CalDAV server was more popular. > > vCalendar is a very limited format and only poorly supports modern > concepts (meeting series, exceptions, time zones). Shoehorning iCalendar > 2.0 data into vCalendar 1.0 is problematic. > It looks to me that indeed it only supports "type=text/x-vcalendar", although I would expect text/calendar by KCalExtended. I think I have somewhere sources - I'll try to dig a bit. >> Another option would be to set up some cleanup before passing the data to >> the parser. This would be a simple rule replacing ==0D=0A= with a simple >> =. I have never had a chance to look into the scripting options offered >> by syncevolution - is it thinkable/doable? > > This might indeed be the best option. Let me check this in more detail. > I thought it might be added by sysync after opening the wbxml or whatever. But if you say it is unmodified as sent by the phone, I'll buy it. I have not looked into the scripting options before/after etc., but it looks like an option for a work around. >> Sorry for bothering that much about it. I just have a feeling there is a >> spell over my attempt to sync in the past 10 years, first with opensync >> and now with Syncevolution, I always hit the wall in some way. > > I won't comment on OpenSync here. You probably know already why it > didn't work for you and in what state the project has been since they > dropped MultiSync and tried again. > > Regarding SyncEvolution: you missed the time when it was under much more > active development. Intel really helped move the project along for a > while (additional developers, QA) and still does to a limited extend > (hosting, a little bit of my time), but mostly the project is now in > maintenance. > Since we discussed the topic in 2011, I was dragged in a couple of big projects ... also a big private project called family+child took place :) It also became clear that I will not use the newer KDE and I was hoping that someone else will do the "dirty" work and write the plugins for TDE/KDE3 :) Anyway, I don't know what interest Intel or Canonical have in this project. It looks like a very good work so far and I hope whoever works on this further will maintain this level. Even this parser seem to work well if it gets the right data, no matter how ugly it looks. Last but not least, you are also really nice and helpful. Thanks _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Oct 5 06:09:21 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 05 Oct 2016 08:09:21 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) In-Reply-To: References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> <1475054654.7488.16.camel@intel.com> <1475440100.13953.32.camel@intel.com> <1475579882.23779.45.camel@intel.com> Message-ID: <1475647761.23779.59.camel@intel.com> On Tue, 2016-10-04 at 23:03 +0200, deloptes wrote: > Thank you for the extended explanations in your reply. > > Patrick Ohly wrote: > > [old content removed for visibility] > > > > >> Alternatively can we enforce text/calendar instead of text/x-vcalendar? > >> I tried setting this in the ini file > >> .config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini > >> but the engine refused with error. > > > > Was it a local error or did it occur after contacting the phone? > > Probably the latter. > > > > I think it was a 10500 error. The log then probably had a better explanation, but I'm sure it was what I described. > >> I am not even sure that this is OK to > >> modify the file and expect to work. > > > > The Synthesis engine is able to exchange data in different formats and > > the configuration options control that aspect. However, the peer it > > talks to must support the same formats, which is not possible in this > > case: in it's DevInf, the N9 only reports "type=text/x-vcalendar, > > version=1.0" for its ./calendar data store. > > > > The expected error then is something about "no common format" (not sure > > what the wording is). > > > > So once again, please confirm. The configured "type=text/x-vcalendar" in > .config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini > does not enforce the phone to respond, rather it is based on the > capability - correct? Correct. Basically SyncEvolution starts a sync by telling the phone what data stores it wants to sync, and then the phone describes what kind of data formats it accepts for those stores. SyncEvolution does the same, and then both sides decide based on the received information in which format they send data. SyncEvolution can try to coerce a peer to send data in a certain format by only listing that format as supported, but that only works if the peer supports that format and checks the information sent by SyncEvolution. I only know of one SyncML implementation that supports this, and that is the Synthesis engine used by SyncEvolution. > > vCalendar is a very limited format and only poorly supports modern > > concepts (meeting series, exceptions, time zones). Shoehorning iCalendar > > 2.0 data into vCalendar 1.0 is problematic. > > > > It looks to me that indeed it only supports "type=text/x-vcalendar", > although I would expect text/calendar by KCalExtended. I think I have > somewhere sources - I'll try to dig a bit. There's a bit of history, too, here: there were discussions to use SyncEvolution as SyncML implementation in MeeGo (which would have given you iCalendar support also for SyncML), but Nokia preferred their in-house implementation (which is limited to vCalendar). That implementation is what you are talking to now. > Anyway, I don't know what interest Intel or Canonical have in this project. Intel was using SyncEvolution for example in Moblin Netbooks and more recently for phone support in Tizen IVI. Canonical is using SyncEvolution for data synchronization in Ubuntu, mostly the phone flavor. > It looks like a very good work so far and I hope whoever works on this > further will maintain this level. Even this parser seem to work well if it > gets the right data, no matter how ugly it looks. > > Last but not least, you are also really nice and helpful. I still feel responsible for SyncEvolution and definitely want to ensure that users who have an interest in it have the possibility to use it. But as in your case, there's also real life and family, so the situation is different now compared to previous years. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From patrick.ohly at intel.com Wed Oct 5 15:20:12 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 05 Oct 2016 17:20:12 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) In-Reply-To: References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> <1475054654.7488.16.camel@intel.com> Message-ID: <1475680812.23779.81.camel@intel.com> On Sun, 2016-10-02 at 00:31 +0200, deloptes wrote: > The diff is the closest I could get to make it work acceptable for me - it > at least does not mangles the text. Unfortunately there is no script in the Synthesis engine that could fix up the date before parsing. See doc/SySync_script_call_flow.pdf. That means we are indeed stuck at trying to detect and deal with this problem in the parser. On the other hand, a naive global search/replace would also break the (unlikely) occurrence of ==OD=0A= where it is part of some regular, non-quoted-printable text. So doing it in the parser is the more stable approach anyway. Before I dive into trying to understand your change, let me walk through the problem. What we get from the N9 is something where the CRLF in a =CRLF soft line break according to rfc1521.txt 5.1. are encoded again and an extra = for the soft line break is added, leading to ==0D=0A= at the end of lines instead of =CRLF (where CR and LF are single octets). For example, a two-line description: some long line which needs to be folded foo bar Becomes: DESCRIPTION;ENCODING=QUOTED-PRINTABLE:some long line which needs to be folded foo=0D=0A==OD=0A= bar Correct would be: DESCRIPTION;ENCODING=QUOTED-PRINTABLE:some long line which needs to be folded foo=0D=0A= bar The ==OD=0A= part is invalid because = must be followed by two hex characters, and = itself needs to be encoded as =3D. That follows from rule #2 in rfc1521.txt which explicitly excludes the = from the range of characters which may be used without encoding. That means that we can treat ==0D=0A= as an alias for = without affecting other devices. With that in mind, let me present a more localized change: diff --git a/src/sysync/mimedirprofile.cpp b/src/sysync/mimedirprofile.cpp index 84f0271..cdc32fb 100644 --- a/src/sysync/mimedirprofile.cpp +++ b/src/sysync/mimedirprofile.cpp @@ -1937,6 +1937,22 @@ static void decodeValue( uInt16 code; const char *s; char hex[2]; + + // The Nokia N9 vCalendar implementation sends ==0A=0D= at the end of + // the line when it should send just the =. Apparently the CRLF octets + // get inserted before quoted-printable encoding and then get encoded. + // Such a sequence is invalid because = cannot be used literally + // and must be followed by characters representing the hex value, + // i.e. == is already invalid. + // + // We must skip over the entire sequence and continue at the last + // = in ==0A=0D=, otherwise the code below would insert additional + // characters into the decoded text. + if (!strcmp(p, "==0A=0D=")) { + p += strlen("==0A=0D=") - 1; + continue; + } + s=nextunfolded(p,aMimeMode,true); if (*s==0) break; // end of string hex[0]=*s; // first digit Does that make sense? More importantly, does it work? I've not tried it out myself yet with any peer which uses vCalendar 1.0 or vCard 2.1. My phone that I used to test with no longer starts up without a SIM card, so I need to find an unused one first. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Thu Oct 6 00:26:09 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 6 Oct 2016 02:26:09 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> <1475054654.7488.16.camel@intel.com> <1475680812.23779.81.camel@intel.com> Message-ID: Patrick Ohly wrote: > + ? ? ? ?// The Nokia N9 vCalendar implementation sends ==0A=0D= at the > end of + ? ? ? ?// the line when it should send just the =. Apparently the > CRLF octets + ? ? ? ?// get inserted before quoted-printable encoding and > then get encoded. + ? ? ? ?// Such a sequence is invalid because = cannot > be used literally + ? ? ? ?// and must be followed by characters > representing the hex value, + ? ? ? ?// i.e. == is already invalid. > + ? ? ? ?// > + ? ? ? ?// We must skip over the entire sequence and continue at the last > + ? ? ? ?// = in ==0A=0D=, otherwise the code below would insert > additional + ? ? ? ?// characters into the decoded text. This seems to magically work @@ -1937,6 +1938,23 @@ static void decodeValue( uInt16 code; const char *s; char hex[2]; + + // The Nokia N9 vCalendar implementation sends ==0D=0A= at the end of + // the line when it should send just the =. Apparently the CRLF octets + // get inserted before quoted-printable encoding and then get encoded. + // Such a sequence is invalid because = cannot be used literally + // and must be followed by characters representing the hex value, + // i.e. == is already invalid. + // + // We must skip over the entire sequence and continue at the last + // = in ==0D=0A=, otherwise the code below would insert additional + // characters into the decoded text. + if (strncmp(p,"==0D=0A=",8)==0) { + p += strlen("==0D=0A")-1; + // put the cursor at the next useful = + p=nextunfolded(p,aMimeMode,true); + continue; + } s=nextunfolded(p,aMimeMode,true); if (*s==0) break; // end of string hex[0]=*s; // first digit _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Thu Oct 6 06:21:16 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 06 Oct 2016 08:21:16 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) In-Reply-To: References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> <1475054654.7488.16.camel@intel.com> <1475680812.23779.81.camel@intel.com> Message-ID: <1475734876.23779.89.camel@intel.com> On Thu, 2016-10-06 at 02:26 +0200, deloptes wrote: > Patrick Ohly wrote: > > > + // The Nokia N9 vCalendar implementation sends ==0A=0D= at the > > end of + // the line when it should send just the =. Apparently the > > CRLF octets + // get inserted before quoted-printable encoding and > > then get encoded. + // Such a sequence is invalid because = cannot > > be used literally + // and must be followed by characters > > representing the hex value, + // i.e. == is already invalid. > > + // > > + // We must skip over the entire sequence and continue at the last > > + // = in ==0A=0D=, otherwise the code below would insert > > additional + // characters into the decoded text. > > This seems to magically work I don't like magic - at least not in software engineering ;-} So let's try to understand this a bit better. Compared to my proposed patch, you added "p=nextunfolded(p,aMimeMode,true)" before the "continue". Without it, we enter the next loop iteration: c=*p; // c should be = now if (isEndOfLineOrText(c) || (!escaped && aStructSep!=0 && (c==aStructSep || c==aAltSep))) break; // We haven't changed any of these, so it should continue. escaped=(!escaped) && (c=='\\'); // No change either. if (c=='=') { s=nextunfolded(p,aMimeMode,true); // Hmm, not quite the same... Okay, I think I understand. The loop expects to start after skipping over line folding, so when we enter it pointing towards the soft line break =, it does the wrong thing. The additional nextunfolded() avoids that. > @@ -1937,6 +1938,23 @@ static void decodeValue( > uInt16 code; > const char *s; > char hex[2]; > + > + // The Nokia N9 vCalendar implementation sends ==0D=0A= at the end > of > + // the line when it should send just the =. Apparently the CRLF > octets > + // get inserted before quoted-printable encoding and then get > encoded. > + // Such a sequence is invalid because = cannot be used literally > + // and must be followed by characters representing the hex value, > + // i.e. == is already invalid. > + // > + // We must skip over the entire sequence and continue at the last > + // = in ==0D=0A=, otherwise the code below would insert additional > + // characters into the decoded text. > + if (strncmp(p,"==0D=0A=",8)==0) { > + p += strlen("==0D=0A")-1; > + // put the cursor at the next useful = > + p=nextunfolded(p,aMimeMode,true); > + continue; > + } > s=nextunfolded(p,aMimeMode,true); > if (*s==0) break; // end of string > hex[0]=*s; // first digit I'll add that patch to the next test run. Thanks for testing and the correction. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Thu Oct 6 07:40:52 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 6 Oct 2016 09:40:52 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> <1475054654.7488.16.camel@intel.com> <1475680812.23779.81.camel@intel.com> <1475734876.23779.89.camel@intel.com> Message-ID: Patrick Ohly wrote: > I don't like magic - at least not in software engineering ;-} > > So let's try to understand this a bit better. Compared to my proposed > patch, you added "p=nextunfolded(p,aMimeMode,true)" before the > "continue". > > Without it, we enter the next loop iteration: > > c=*p; // c should be = now Yes exactly. > if (isEndOfLineOrText(c) || (!escaped && aStructSep!=0 && (c==aStructSep > || c==aAltSep))) break; // We haven't changed any of these, so it should > continue. escaped=(!escaped) && (c=='\\'); // No change either. if > (c=='=') { s=nextunfolded(p,aMimeMode,true); // Hmm, not quite the same... > yes this is testing from position of p forward, without modifying p. > Okay, I think I understand. The loop expects to start after skipping > over line folding, so when we enter it pointing towards the soft line > break =, it does the wrong thing. The additional nextunfolded() avoids > that. Yes this is also my understanding of that. The last problem I have with all of that is double escaped '\n' and ','. I'll try to find out where exactly it does this. It might be in the sysync parser, but also in libkcal. Thanks for the help. regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Fri Oct 7 06:33:02 2016 From: deloptes at gmail.com (deloptes) Date: Fri, 7 Oct 2016 08:33:02 +0200 Subject: [SyncEvolution] [SOLVED] Explicit type 'text/x-vcalendar' specified in command or item meta References: Message-ID: The problem is solved by the agreed solution. The second problem with the escaped ',' and '\n' also solved (it was introduced at my end while trying to resolve the former issue). Thanks and regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Tue Oct 4 09:04:38 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 04 Oct 2016 11:04:38 +0200 Subject: [SyncEvolution] Events updated with all contacts as attendee In-Reply-To: References: <1475042978.7488.13.camel@intel.com> Message-ID: <1475571878.23779.17.camel@intel.com> On Wed, 2016-09-28 at 09:18 -0300, Renato Filho wrote: > Hi Patrick, > > The events are stored on google, and for some reason all the contacts > (not local contacts) that the user have ever sent a e-mail is added on > the event as attendee. The users reported that the event description > had changed too with description from other event. > > I am guessing that the event is getting corrupted during the sync and > for some reason google is adding all contacts into the event. I still find it unlikely that SyncEvolution is to blame for this. Even if it was, without further information about the failure (in particular, detailed sync logs) I can't do anything about this. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From renato.filho at canonical.com Tue Oct 4 13:35:17 2016 From: renato.filho at canonical.com (Renato Filho) Date: Tue, 4 Oct 2016 10:35:17 -0300 Subject: [SyncEvolution] Events updated with all contacts as attendee In-Reply-To: <1475571878.23779.17.camel@intel.com> References: <1475042978.7488.13.camel@intel.com> <1475571878.23779.17.camel@intel.com> Message-ID: Hi Patrick, thanks for you time. I have the same feeling as you, I could not find any point on syncevolution code that could cause that. But the user that report the bug, told me that he is not using any other client app, only syncevolution + google web interface. I am still looking at the code trying to understand what is happening. I could not guess anything from the log. And there is no way to reliable reproduce the bug. I reported a bug[1] about that where I attached some log files that could help. Thanks again. Renato. [1] https://bugs.freedesktop.org/show_bug.cgi?id=98044#c0 2016-10-04 6:04 GMT-03:00 Patrick Ohly : > On Wed, 2016-09-28 at 09:18 -0300, Renato Filho wrote: >> Hi Patrick, >> >> The events are stored on google, and for some reason all the contacts >> (not local contacts) that the user have ever sent a e-mail is added on >> the event as attendee. The users reported that the event description >> had changed too with description from other event. >> >> I am guessing that the event is getting corrupted during the sync and >> for some reason google is adding all contacts into the event. > > I still find it unlikely that SyncEvolution is to blame for this. Even > if it was, without further information about the failure (in particular, > detailed sync logs) I can't do anything about this. > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > >