From deloptes at gmail.com Sat Nov 12 09:17:26 2016 From: deloptes at gmail.com (deloptes) Date: Sat, 12 Nov 2016 10:17:26 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth Message-ID: Hi, I am wondering if it is possible to sync Intex Aqua Fish with SailFish OS via SyncEvolution. sdp browse Service Name: SyncML Client Service RecHandle: 0x10008 Service Class ID List: UUID 128: 00000002-0000-1000-8000-0002ee000002 Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 25 "OBEX" (0x0008) Profile Descriptor List: "" (0x00000002-0000-1000-8000-0002ee000002) Version: 0x0100 Service Name: SyncML Server Service RecHandle: 0x10009 Service Class ID List: UUID 128: 00000001-0000-1000-8000-0002ee000001 Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 26 "OBEX" (0x0008) Profile Descriptor List: "" (0x00000001-0000-1000-8000-0002ee000001) Version: 0x0100 How can I get a working template/config for the device I tried phone-setup, but the python script dies with an error. I read that someone was using syncevolution for arm - but the version there mentioned (post from 2014 about Jolla phone) was 1.3.x Thank in advance _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sat Nov 12 13:20:29 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sat, 12 Nov 2016 14:20:29 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: References: Message-ID: <1478956829.4896.2.camel@intel.com> On Sat, 2016-11-12 at 10:17 +0100, deloptes wrote: > Hi, > I am wondering if it is possible to sync Intex Aqua Fish with SailFish OS > via SyncEvolution. > > > sdp browse > > Service Name: SyncML Client > Service RecHandle: 0x10008 > Service Class ID List: > UUID 128: 00000002-0000-1000-8000-0002ee000002 > Protocol Descriptor List: > "L2CAP" (0x0100) > "RFCOMM" (0x0003) > Channel: 25 > "OBEX" (0x0008) > Profile Descriptor List: > "" (0x00000002-0000-1000-8000-0002ee000002) > Version: 0x0100 > > Service Name: SyncML Server > Service RecHandle: 0x10009 > Service Class ID List: > UUID 128: 00000001-0000-1000-8000-0002ee000001 > Protocol Descriptor List: > "L2CAP" (0x0100) > "RFCOMM" (0x0003) > Channel: 26 > "OBEX" (0x0008) > Profile Descriptor List: > "" (0x00000001-0000-1000-8000-0002ee000001) > Version: 0x0100 > > How can I get a working template/config for the device I would start with the Nokia template. > I tried phone-setup, but the python script dies with an error. Which one? The script hasn't been used much, I suspect. The only remaining phones with SyncML support were Nokia, and those typically all used the same settings. -- 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 Mon Nov 14 19:27:53 2016 From: deloptes at gmail.com (deloptes) Date: Mon, 14 Nov 2016 20:27:53 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth References: <1478956829.4896.2.camel@intel.com> Message-ID: Patrick Ohly wrote: >> How can I get a working template/config for the device > > I would start with the Nokia template. > This is what I did - it loops in ObexTransportAgent::wait(): iteration for quite some time, but I guess I have to remove PC suite parameter and who knows what I also have to modify. >> I tried phone-setup, but the python script dies with an error. > > Which one? > > The script hasn't been used much, I suspect. The only remaining phones > with SyncML support were Nokia, and those typically all used the same > settings. syncevo-phone-config syncevo-phone-config --bt-address 94:XX:XX:XX:XX:8D --advanced --create-config=aquafish Running test with test data inside /tmp/syncevo-phone-config1_7yeN/data and test results inside /tmp/syncevo-phone-config1_7yeN/cache Starting test for 1188 configurations... Start 1/1188 test [DEBUG 00:00:00] checking password property 'databasePassword' in datastore 'addressbook' of config 'test-phone' with user identity '' [ERROR 00:00:00] addressbook: backend addressbook is ambiguous, avoid the alias and pick a specific backend instead directly Traceback (most recent call last): File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 728, in main() File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 725, in main config.run() File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 557, in run (status, interrupt) = self.testWithCurrentConfiguration () File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 438, in testWithCurrentConfiguration runCommand ("%s -c --template 'SyncEvolution Client' --sync-property peerIsClient=1 %s" % (syncevoTest, configName)) File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 271, in runCommand raise Exception("%s: failed (return code %d)" % (cmd, result>>8)) Exception: XDG_CACHE_HOME=/tmp/syncevo-phone-config1_7yeN/cache XDG_CONFIG_HOME=/tmp/syncevo-phone-config1_7yeN/config syncevolution --daemon=no -c --template 'SyncEvolution Client' --sync-property peerIsClient=1 test-phone >/dev/null: failed (return code 1) I think there was a way to send the SAN or whatever command to get the config ... If you have time and help a bit, it would be great advantage for the whole community regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Mon Nov 14 20:28:11 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 14 Nov 2016 21:28:11 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: References: <1478956829.4896.2.camel@intel.com> Message-ID: <1479155291.3240.21.camel@intel.com> On Mon, 2016-11-14 at 20:27 +0100, deloptes wrote: > Patrick Ohly wrote: > > >> How can I get a working template/config for the device > > > > I would start with the Nokia template. > > > > This is what I did - it loops in ObexTransportAgent::wait(): iteration for > quite some time, but I guess I have to remove PC suite parameter and who > knows what I also have to modify. That doesn't look good :-( Is the phone still supported? Is it possible to see logs from the phone side or get someone to describe how the phone is supposed to be used for syncing via SyncML? > >> I tried phone-setup, but the python script dies with an error. > > > > Which one? > > > > The script hasn't been used much, I suspect. The only remaining phones > > with SyncML support were Nokia, and those typically all used the same > > settings. > > syncevo-phone-config > > syncevo-phone-config --bt-address > 94:XX:XX:XX:XX:8D --advanced --create-config=aquafish > Running test with test data inside /tmp/syncevo-phone-config1_7yeN/data and > test results inside /tmp/syncevo-phone-config1_7yeN/cache > Starting test for 1188 configurations... > Start 1/1188 test > [DEBUG 00:00:00] checking password property 'databasePassword' in > datastore 'addressbook' of config 'test-phone' with user identity '' > [ERROR 00:00:00] addressbook: backend addressbook is ambiguous, avoid the > alias and pick a specific backend instead directly That error comes from not knowing whether the Evolution or TDE backend is supposed to be used by the script. After a quick look at the script it seems that this cannot be specified. For you, the easiest solution probably is to disable the Evolution backends when compiling SyncEvolution. -- 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 Mon Nov 14 21:24:00 2016 From: deloptes at gmail.com (deloptes) Date: Mon, 14 Nov 2016 22:24:00 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> Message-ID: Patrick Ohly wrote: >> This is what I did - it loops in ObexTransportAgent::wait(): iteration >> for quite some time, but I guess I have to remove PC suite parameter and >> who knows what I also have to modify. > > That doesn't look good :-( > > Is the phone still supported? Is it possible to see logs from the phone > side or get someone to describe how the phone is supposed to be used for > syncing via SyncML? > Actually it is pretty new. After making sync possible with TDE and N9 I am pretty happy, so now is the time to plan for the future. It is produced by Intex and sold since earlier this year. I thought it will be a nice try since the price is not that high. I still don't know whos in charge on Jolla side ... but I was able to sync the contacts from N9 to Intex Aqua Fish via bluetooth. I don't know how it did it in the background >> >> I tried phone-setup, but the python script dies with an error. >> > >> > Which one? >> > >> > The script hasn't been used much, I suspect. The only remaining phones >> > with SyncML support were Nokia, and those typically all used the same >> > settings. >> >> syncevo-phone-config >> >> syncevo-phone-config --bt-address >> 94:XX:XX:XX:XX:8D --advanced --create-config=aquafish >> Running test with test data inside /tmp/syncevo-phone-config1_7yeN/data >> and test results inside /tmp/syncevo-phone-config1_7yeN/cache >> Starting test for 1188 configurations... >> Start 1/1188 test >> [DEBUG 00:00:00] checking password property 'databasePassword' in >> datastore 'addressbook' of config 'test-phone' with user identity '' >> [ERROR 00:00:00] addressbook: backend addressbook is ambiguous, avoid the >> alias and pick a specific backend instead directly > > That error comes from not knowing whether the Evolution or TDE backend > is supposed to be used by the script. After a quick look at the script > it seems that this cannot be specified. For you, the easiest solution > probably is to disable the Evolution backends when compiling > SyncEvolution. these are the options I compiled with --enable-maintainer-mode \ --enable-shared \ --enable-gui \ --enable-gtk=3 \ --enable-core \ --enable-bluetooth \ --enable-tdepimabc \ --enable-tdepimcal \ --enable-tdepimnotes \ --enable-tdewallet \ --enable-sqlite \ --enable-file \ --enable-dav \ --without-gio-gdbus \ --disable-ssl-certificate-check \ --disable-akonadi \ --disable-ebook \ --disable-ecal \ --disable-goa \ --disable-kcalextended \ --disable-kwallet \ --disable-maemocal \ --disable-oauth2 \ --disable-qtcontacts \ --disable-gsso \ --disable-uoa \ --disable-sign I'll try to find information how this version is supposed to work. Perhaps it is missing a service in the background. regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Tue Nov 15 20:57:03 2016 From: deloptes at gmail.com (deloptes) Date: Tue, 15 Nov 2016 21:57:03 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> Message-ID: deloptes wrote: > I'll try to find information how this version is supposed to work. Perhaps > it is missing a service in the background. Jolla/Sailfish OS does not have syncml implemented (yet). Work is in progress, was the answer. thanks and regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Tue Nov 15 21:26:38 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 15 Nov 2016 22:26:38 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> Message-ID: <1479245198.18151.5.camel@intel.com> On Tue, 2016-11-15 at 21:57 +0100, deloptes wrote: > deloptes wrote: > > > I'll try to find information how this version is supposed to work. Perhaps > > it is missing a service in the background. > > Jolla/Sailfish OS does not have syncml implemented (yet). Work is in > progress, was the answer. Huh? Then how did you sync between your N9 and the Sail Fish OS phone? Why does it advertise SyncML support via Bluetooth? I thought Sail Fish OS had continued to use Buteo as its sync solution because that's what they got from MeeGo, and there was a SyncML implementation for that (most recent repo probably https://github.com/kavuri/buteo-syncml). If that's the code, then it has been "in progress" for several years now. During all that time, SyncEvolution has had a functional SyncML implementation and backends for the PIM storage in MeeGo... -- 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 Nov 15 22:04:23 2016 From: deloptes at gmail.com (deloptes) Date: Tue, 15 Nov 2016 23:04:23 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> Message-ID: Patrick Ohly wrote: > Huh? Then how did you sync between your N9 and the Sail Fish OS phone? > Why does it advertise SyncML support via Bluetooth? > > I thought Sail Fish OS had continued to use Buteo as its sync solution > because that's what they got from MeeGo, and there was a SyncML > implementation for that (most recent repo probably > https://github.com/kavuri/buteo-syncml). If that's the code, then it has > been "in progress" for several years now. > I had the same impression. > During all that time, SyncEvolution has had a functional SyncML > implementation and backends for the PIM storage in MeeGo... Here is what they said: Sync via Bluetooth isn't well supported at the moment. We allow importing contacts from another device, and adding capability to import calendars via Bluetooth is work-in-progress (see https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 and MER#1222 for that), but true synchronisation via Bluetooth is significantly more difficult to achieve with the current stack. https://together.jolla.com/question/46789/when-can-we-get-pim-functionality-on-par-with-n9/?comment=151330#comment-151330 I guess I have to wait, or get involved. I asked why not use syncevolution? but still it would need a backend ... I don't know when I'll be able to have a look into the sdk and mer regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Nov 16 07:16:29 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 16 Nov 2016 08:16:29 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> Message-ID: <1479280589.18151.13.camel@intel.com> On Tue, 2016-11-15 at 23:04 +0100, deloptes wrote: > Patrick Ohly wrote: > > During all that time, SyncEvolution has had a functional SyncML > > implementation and backends for the PIM storage in MeeGo... > > Here is what they said: > > Sync via Bluetooth isn't well supported at the moment. We allow importing > contacts from another device, and adding capability to import calendars via > Bluetooth is work-in-progress (see > https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 and > MER#1222 for that), but true synchronisation via Bluetooth is significantly > more difficult to achieve with the current stack. Reminds me of the discussions we had about comparing Bueto with SyncEvolution. SyncEvolution always had a strong focus on actually making syncing work (and yes, that gets ugly sometimes), while Buteo was a "cleanly designed" framework which avoided doing any of the hard work and delegated that to "plugins". In other words, it didn't actually solve the problems. Too late to say "told you so" now, there's literally no-one left from those discussions and it wouldn't matter anyway. > I guess I have to wait, or get involved. I asked why not use syncevolution? > but still it would need a backend ... I don't know when I'll be able to > have a look into the sdk and mer I don't know how much current PIM storage in SailFish OS has diverged from MeeGo; for MeeGo, kcalextended and qtcontacts were the relevant backends. -- 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 Wed Nov 16 07:45:11 2016 From: deloptes at gmail.com (deloptes) Date: Wed, 16 Nov 2016 08:45:11 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> Message-ID: Patrick Ohly wrote: > On Tue, 2016-11-15 at 23:04 +0100, deloptes wrote: >> Patrick Ohly wrote: >> > During all that time, SyncEvolution has had a functional SyncML >> > implementation and backends for the PIM storage in MeeGo... >> >> Here is what they said: >> >> Sync via Bluetooth isn't well supported at the moment. We allow importing >> contacts from another device, and adding capability to import calendars >> via Bluetooth is work-in-progress (see >> https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 >> and MER#1222 for that), but true synchronisation via Bluetooth is >> significantly more difficult to achieve with the current stack. > > Reminds me of the discussions we had about comparing Bueto with > SyncEvolution. SyncEvolution always had a strong focus on actually > making syncing work (and yes, that gets ugly sometimes), while Buteo was > a "cleanly designed" framework which avoided doing any of the hard work > and delegated that to "plugins". In other words, it didn't actually > solve the problems. Too late to say "told you so" now, there's literally > no-one left from those discussions and it wouldn't matter anyway. > >> I guess I have to wait, or get involved. I asked why not use >> syncevolution? but still it would need a backend ... I don't know when >> I'll be able to have a look into the sdk and mer > > I don't know how much current PIM storage in SailFish OS has diverged > from MeeGo; for MeeGo, kcalextended and qtcontacts were the relevant > backends. > I'll light a candle for my N9 every night and say a prayer for it :) so that it may live long and be healthy :) until Sailfish gets usable. I hope I'll find some time soon to setup an environment to have a look into the sdk. For now I don't see a way to progress there, but thank you for the hints. regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From tino.keitel+syncevolution at tikei.de Wed Nov 16 08:43:21 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Wed, 16 Nov 2016 09:43:21 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: <1479280589.18151.13.camel@intel.com> References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> Message-ID: <20161116084321.GA7467@eazy.amigager.de> On Wed, Nov 16, 2016 at 08:16:29 +0100, Patrick Ohly wrote: [...] > while Buteo was a "cleanly designed" framework which avoided doing > any of the hard work and delegated that to "plugins". In other > words, it didn't actually solve the problems. OpenSync reloaded? :-) Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From g+syncevolution at cobb.uk.net Wed Nov 16 09:48:43 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Wed, 16 Nov 2016 09:48:43 +0000 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: <20161116084321.GA7467@eazy.amigager.de> References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <20161116084321.GA7467@eazy.amigager.de> Message-ID: On 16/11/16 08:43, Tino Mettler wrote: > On Wed, Nov 16, 2016 at 08:16:29 +0100, Patrick Ohly wrote: > > [...] > >> while Buteo was a "cleanly designed" framework which avoided doing >> any of the hard work and delegated that to "plugins". In other >> words, it didn't actually solve the problems. > > OpenSync reloaded? :-) Oooh, a bit of a low blow :-) I certainly learnt a lot from spending quite a lot of effort trying to make OpenSync work! The main one (and the main reason I am here) is that sync is **really** hard to do in the general case. Syncevolution does a great job on two-way sync but it would be really good to solve the multi-way problem one day :-) But that would require some significant work by a team who are willing to look at and learn from all the previous attempts. I sometimes wish Philippe Kahn had not lost interest in sync. _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Wed Nov 16 20:10:05 2016 From: deloptes at gmail.com (deloptes) Date: Wed, 16 Nov 2016 21:10:05 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <20161116084321.GA7467@eazy.amigager.de> Message-ID: Graham Cobb wrote: > Oooh, a bit of a low blow :-) > > I certainly learnt a lot from spending quite a lot of effort trying to > make OpenSync work! ?The main one (and the main reason I am here) is > that sync is **really** hard to do in the general case. > > Syncevolution does a great job on two-way sync but it would be really > good to solve the multi-way problem one day :-) But that would require > some significant work by a team who are willing to look at and learn > from all the previous attempts. I sometimes wish Philippe Kahn had not > lost interest in sync. Hi Graham, they confirmed it is not working on SailFish - who knows when they will implement it and how it will be implemented ... given the comments above ... Perhaps we have to work closer with the Jolla team on it. Or ... get proper SyncEvolution backend for SailFish. I'm just wondering what happened to the MeeGo part and why it was not adopted by SailFish ... but anyway. From what I learned with the whole backend exercise for TDE/KDE3, the best is to do the work yourself ... For the time being I read the only supported way is via Cal/CardDav ... and people reported to be using own service ... which s*cks ... I have put on the todo list to have a look into the SDK - no idea when, but it is tempting regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From g+syncevolution at cobb.uk.net Wed Nov 16 21:10:57 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Wed, 16 Nov 2016 21:10:57 +0000 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <20161116084321.GA7467@eazy.amigager.de> Message-ID: On 16/11/16 20:10, deloptes wrote: > Hi Graham, > they confirmed it is not working on SailFish - who knows when they will > implement it and how it will be implemented ... given the comments > above ... > Perhaps we have to work closer with the Jolla team on it. Or ... get proper > SyncEvolution backend for SailFish. I am sure I used to have a version of SyncEvo on my Jolla, due to the kindness of someone on the list who built it. I seem to remember it worked sort of -- was it for calendar or contacts? Anyway it stopped working (did Jolla change the underlying data store or something? I can't remember). I haven't bothered recently and have never even looked for it to try to install on my Jolla C. > For the time being I read the only supported way is via Cal/CardDav ... and > people reported to be using own service ... which s*cks ... I do sync with my personal owncloud instance so I have calendar and contacts in Cal/CardDav form. I have not got around to trying the Sailfish Cal/CardDav support to see if it works with owncloud but plan to when I have time. Graham _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Wed Nov 16 21:57:41 2016 From: deloptes at gmail.com (deloptes) Date: Wed, 16 Nov 2016 22:57:41 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <20161116084321.GA7467@eazy.amigager.de> Message-ID: Graham Cobb wrote: > I am sure I used to have a version of SyncEvo on my Jolla, due to the > kindness of someone on the list who built it. I seem to remember it > worked sort of -- was it for calendar or contacts? ?Anyway it stopped > working (did Jolla change the underlying data store or something? ?I > can't remember). I haven't bothered recently and have never even looked > for it to try to install on my Jolla C. > I just got this phone last week, so no idea and ATM I am preoccupied, but I am curious to see what the sdk and emulator can do. I read that there was syncevolution 1.3 for jolla, but no confirmation that it works, so now we know that it does not work anymore. >> For the time being I read the only supported way is via Cal/CardDav ... >> and people reported to be using own service ... which s*cks ... > > I do sync with my personal owncloud instance so I have calendar and > contacts in Cal/CardDav form. ?I have not got around to trying the > Sailfish Cal/CardDav support to see if it works with owncloud but plan > to when I have time. > doesn't syncevolution support a cal/carddav server ... or just a client? regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From tino.keitel+syncevolution at tikei.de Thu Nov 17 07:58:46 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Thu, 17 Nov 2016 08:58:46 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: References: <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <20161116084321.GA7467@eazy.amigager.de> Message-ID: <20161117075846.GA10027@eazy.amigager.de> On Wed, Nov 16, 2016 at 22:57:41 +0100, deloptes wrote: > doesn't syncevolution support a cal/carddav server ... or just a client? Hi, it is just the client side. For the server side, you can try DAViCal if you don't want to run a full blown ownCloud service just for PIM sync. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Nov 18 13:03:49 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 18 Nov 2016 14:03:49 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <20161116084321.GA7467@eazy.amigager.de> Message-ID: <1479474229.27625.36.camel@intel.com> On Wed, 2016-11-16 at 09:48 +0000, Graham Cobb wrote: > On 16/11/16 08:43, Tino Mettler wrote: > > On Wed, Nov 16, 2016 at 08:16:29 +0100, Patrick Ohly wrote: > > > > [...] > > > >> while Buteo was a "cleanly designed" framework which avoided doing > >> any of the hard work and delegated that to "plugins". In other > >> words, it didn't actually solve the problems. > > > > OpenSync reloaded? :-) > > Oooh, a bit of a low blow :-) Emotions running high ;-) > I certainly learnt a lot from spending quite a lot of effort trying to > make OpenSync work! The main one (and the main reason I am here) is > that sync is **really** hard to do in the general case. Amen to that. I don't have a problem with trying out different ways of doing syncing. Sometimes people have to try first before they realize how hard it is. I'm just a bit sad and disappointed when those attempts then tie up resources for years without actually leading to something that helps users. Then there are the projects with great claims ("Synchronize your your PIM data to your mobile phone, iPod, Nokia Internet tablet, or between computers" - search for it, it's a verbatim copy) although that's at best a goal for the future. At least users find out about that as soon as they dig deeper. Worse is to sync data and then break it along the way, because then users stop using sync software. > Syncevolution does a great job on two-way sync but it would be really > good to solve the multi-way problem one day :-) With multi-way you mean a sync topology that has cycles? Yes, that's indeed not possible with SyncEvolution. I also don't see a way to do it as long as one is stuck with existing data formats. -- 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 Nov 18 14:08:28 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Fri, 18 Nov 2016 14:08:28 +0000 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: <1479474229.27625.36.camel@intel.com> References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <20161116084321.GA7467@eazy.amigager.de> <1479474229.27625.36.camel@intel.com> Message-ID: <50e1ff23-b5bf-92ca-72de-ba345056e348@cobb.uk.net> On 18/11/16 13:03, Patrick Ohly wrote: > With multi-way you mean a sync topology that has cycles? Yes, that's > indeed not possible with SyncEvolution. I also don't see a way to do it > as long as one is stuck with existing data formats. Actually, I meant even without cycles. It seems to me from my own experiments that it is impossible (in the real world) to keep N > 2 devices in sync just using pairwise syncs (assuming changes on any device, but disallowing conflicting changes). The main problem is different sets of supported attributes. That was the problem OpenSync tried to solve (with its centralised database and lists of supported attributes) but SyncEvolution ignores (a very reasonable but large simplification). I have tried to simulate this by using a files backend as a common point to synchronise everything with, but I still see a lot of spurious changes and corruptions being propagated around. That means that, for the time being, I am forced to treat Outlook as my master and only do one-way syncs from there to my other devices. Graham _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Nov 18 15:06:54 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 18 Nov 2016 16:06:54 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: <50e1ff23-b5bf-92ca-72de-ba345056e348@cobb.uk.net> References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <20161116084321.GA7467@eazy.amigager.de> <1479474229.27625.36.camel@intel.com> <50e1ff23-b5bf-92ca-72de-ba345056e348@cobb.uk.net> Message-ID: <1479481614.27625.66.camel@intel.com> On Fri, 2016-11-18 at 14:08 +0000, Graham Cobb wrote: > On 18/11/16 13:03, Patrick Ohly wrote: > > With multi-way you mean a sync topology that has cycles? Yes, that's > > indeed not possible with SyncEvolution. I also don't see a way to do it > > as long as one is stuck with existing data formats. > > Actually, I meant even without cycles. It seems to me from my own > experiments that it is impossible (in the real world) to keep N > 2 > devices in sync just using pairwise syncs (assuming changes on any > device, but disallowing conflicting changes). The main problem is > different sets of supported attributes. > > That was the problem OpenSync tried to solve (with its centralised > database and lists of supported attributes) but SyncEvolution ignores (a > very reasonable but large simplification). SyncEvolution can be used in such a mode - one just needs a central hub which supports the full semantic and attributes of everything that one wants to sync, and the description of what each peer supports has to be accurate. Unfortunately, in practice both conditions aren't completely met. SyncEvolution has to be the SyncML server, too, which it is, under the hood, when using SyncEvolution with ActiveSync or CalDAV/CardDAV. As soon as one allows to let a remote SyncML server do conflict handling, one is pretty much at the mercy of that server. > I have tried to simulate this by using a files backend as a common point > to synchronise everything with, but I still see a lot of spurious > changes and corruptions being propagated around. The file backend is a bit limited in that it does not fully support iCalendar 2.0 semantic. It can store individual VEVENTs, but it doesn't know about relationships between items sharing the same UID. I'm not sure anymore what the implication was in practice - might only be relevant when dealing with peers which themselves do not support the semantic. > That means that, for the time being, I am forced to treat Outlook as my > master and only do one-way syncs from there to my other devices. I suspect the reason for the spurious changes was more related to poor conversion between Outlook data formats and the master storage. As soon as a peer is expected to store data correctly and then doesn't, that undesired modification may get propagated back. That happens also in 1:1 syncs and is unrelated to multi-way syncing. -- 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 Nov 18 16:35:13 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Fri, 18 Nov 2016 16:35:13 +0000 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: <1479481614.27625.66.camel@intel.com> References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <20161116084321.GA7467@eazy.amigager.de> <1479474229.27625.36.camel@intel.com> <50e1ff23-b5bf-92ca-72de-ba345056e348@cobb.uk.net> <1479481614.27625.66.camel@intel.com> Message-ID: <66c9a7a4-52a9-5a07-12fc-9828f60b8784@cobb.uk.net> On 18/11/16 15:06, Patrick Ohly wrote: > SyncEvolution can be used in such a mode - one just needs a central hub > which supports the full semantic and attributes of everything that one > wants to sync, and the description of what each peer supports has to be > accurate. Unfortunately, in practice both conditions aren't completely > met. I don't think either condition is anywhere near being met. What backend would you suggest can be used which "supports the full semantic and attributes of everything that one wants to sync"? I am not aware of one, but I have only tried a few. The second condition is the most serious. In my experience of my many devices over the years, the question of support is the hardest. The combinations of design limitations, bugs and strange interactions (attribute X can't be set if attribute Y is set) is really hard to define. Even in the case where I knew the code intimately (the GPE implementation for Maemo) the description language could not express the restrictions I knew about (let alone the unknown bugs!). > The file backend is a bit limited in that it does not fully support > iCalendar 2.0 semantic. It can store individual VEVENTs, but it doesn't > know about relationships between items sharing the same UID. I'm not > sure anymore what the implication was in practice - might only be > relevant when dealing with peers which themselves do not support the > semantic. If I remember correctly, this restriction is an issue for recurrence exception handling. But I haven't looked into it recently. > I suspect the reason for the spurious changes was more related to poor > conversion between Outlook data formats and the master storage. As soon > as a peer is expected to store data correctly and then doesn't, that > undesired modification may get propagated back. There is certainly a serious issue with Outlook as some of the object semantics are just different from the implied semantics in the vformats and cannot be reliably converted. But I also see problems with Owncloud & KDE. It particularly affects non-standard attributes, which keep coming and going and never stabilise even when no changes are happening on any device. > That happens also in 1:1 syncs and is unrelated to multi-way syncing. In my experience it is a much smaller problem in 1:1 cases: typically things are either supported or not and the worst I see is that syncs may keep trying to set data which is being ignored -- but no database changes actually occur on either side if nothing has changed. In the multi-way case, that turns into the data changing with attributes toggling on and off or changing values as syncs with different devices occur, even when no data has actually changed. I haven't looked into it for some time but I seem to remember that it is partly due to the syncs not being part of a single sync but appearing to be subsequent events, making changes that then have to be propagated to other devices. I am not blaming SyncEvolution -- I am just not convinced that multi-way sync can ever be replaced by a series of two-way syncs. Maybe when I retire I will have time to do more work on this. _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Nov 18 19:35:39 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 18 Nov 2016 20:35:39 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: <66c9a7a4-52a9-5a07-12fc-9828f60b8784@cobb.uk.net> References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <20161116084321.GA7467@eazy.amigager.de> <1479474229.27625.36.camel@intel.com> <50e1ff23-b5bf-92ca-72de-ba345056e348@cobb.uk.net> <1479481614.27625.66.camel@intel.com> <66c9a7a4-52a9-5a07-12fc-9828f60b8784@cobb.uk.net> Message-ID: <1479497739.27625.85.camel@intel.com> On Fri, 2016-11-18 at 16:35 +0000, Graham Cobb wrote: > On 18/11/16 15:06, Patrick Ohly wrote: > > SyncEvolution can be used in such a mode - one just needs a central hub > > which supports the full semantic and attributes of everything that one > > wants to sync, and the description of what each peer supports has to be > > accurate. Unfortunately, in practice both conditions aren't completely > > met. > > I don't think either condition is anywhere near being met. Darn, there goes my self-delusion. > What backend would you suggest can be used which "supports the full > semantic and attributes of everything that one wants to sync"? I am not > aware of one, but I have only tried a few. The EDS backend has full iCalendar 2.0 support and fairly complete vCard 3.0. In both cases, additional properties can be (okay, could be) stored as extensions. However, Evolution itself does not know about custom SyncEvolution-specific extensions (should they get added), so while in theory it should leave them alone, in practice that's not guaranteed. The same is true for CalDAV and CardDAV servers: extensions are supposed to be stored and preserved, but not everyone follows that. > The second condition is the most serious. In my experience of my many > devices over the years, the question of support is the hardest. The > combinations of design limitations, bugs and strange interactions > (attribute X can't be set if attribute Y is set) is really hard to > define. Even in the case where I knew the code intimately (the GPE > implementation for Maemo) the description language could not express the > restrictions I knew about (let alone the unknown bugs!). True. The profiles in SyncEvolution try to take care of different representations, but there are always differences that are going to be problematic. > > That happens also in 1:1 syncs and is unrelated to multi-way syncing. > > In my experience it is a much smaller problem in 1:1 cases: typically > things are either supported or not and the worst I see is that syncs may > keep trying to set data which is being ignored -- but no database > changes actually occur on either side if nothing has changed. In the > multi-way case, that turns into the data changing with attributes > toggling on and off or changing values as syncs with different devices > occur, even when no data has actually changed. I haven't looked into it > for some time but I seem to remember that it is partly due to the syncs > not being part of a single sync but appearing to be subsequent events, > making changes that then have to be propagated to other devices. Hmm, when items don't change, no changes should be applied and syncing repeatedly should be stable. > I am not blaming SyncEvolution -- I am just not convinced that multi-way > sync can ever be replaced by a series of two-way syncs. That's something that would be worthwhile investigating in depth. Until then we have to agree to disagree ;-} -- 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 Nov 16 09:27:47 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Wed, 16 Nov 2016 09:27:47 +0000 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: <1479280589.18151.13.camel@intel.com> References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> Message-ID: <154864c5-2f2d-eb47-85e8-ae19312930d1@cobb.uk.net> On 16/11/16 07:16, Patrick Ohly wrote: > Reminds me of the discussions we had about comparing Bueto with > SyncEvolution. SyncEvolution always had a strong focus on actually > making syncing work (and yes, that gets ugly sometimes), while Buteo was > a "cleanly designed" framework which avoided doing any of the hard work > and delegated that to "plugins". In other words, it didn't actually > solve the problems. Too late to say "told you so" now, there's literally > no-one left from those discussions and it wouldn't matter anyway. Some of us who remember the discussions are still around! But we never understood the decisions anyway. I will admit that I have given up on syncing to my Jolla phone for now, even though it is my day-to-day phone. If anyone has any ideas on how to actually make it work I would be happy to join in. _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Thu Nov 17 06:41:25 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 17 Nov 2016 07:41:25 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <154864c5-2f2d-eb47-85e8-ae19312930d1@cobb.uk.net> Message-ID: Graham Cobb wrote: > On 16/11/16 07:16, Patrick Ohly wrote: >> Reminds me of the discussions we had about comparing Bueto with >> SyncEvolution. SyncEvolution always had a strong focus on actually >> making syncing work (and yes, that gets ugly sometimes), while Buteo was >> a "cleanly designed" framework which avoided doing any of the hard work >> and delegated that to "plugins". In other words, it didn't actually >> solve the problems. Too late to say "told you so" now, there's literally >> no-one left from those discussions and it wouldn't matter anyway. > > Some of us who remember the discussions are still around! But we never > understood the decisions anyway. I will admit that I have given up on > syncing to my Jolla phone for now, even though it is my day-to-day phone. > > If anyone has any ideas on how to actually make it work I would be happy > to join in. And another one http://neo900.org/ you never knew it existed _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Mon Nov 21 07:00:33 2016 From: deloptes at gmail.com (deloptes) Date: Mon, 21 Nov 2016 08:00:33 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> Message-ID: Hi Patrick, Graham, all, Patrick Ohly wrote: > On Tue, 2016-11-15 at 23:04 +0100, deloptes wrote: >> Patrick Ohly wrote: >> > During all that time, SyncEvolution has had a functional SyncML >> > implementation and backends for the PIM storage in MeeGo... >> >> Here is what they said: >> >> Sync via Bluetooth isn't well supported at the moment. We allow importing >> contacts from another device, and adding capability to import calendars >> via Bluetooth is work-in-progress (see >> https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 >> and MER#1222 for that), but true synchronisation via Bluetooth is >> significantly more difficult to achieve with the current stack. > > Reminds me of the discussions we had about comparing Bueto with > SyncEvolution. SyncEvolution always had a strong focus on actually > making syncing work (and yes, that gets ugly sometimes), while Buteo was > a "cleanly designed" framework which avoided doing any of the hard work > and delegated that to "plugins". In other words, it didn't actually > solve the problems. Too late to say "told you so" now, there's literally > no-one left from those discussions and it wouldn't matter anyway. > >> I guess I have to wait, or get involved. I asked why not use >> syncevolution? but still it would need a backend ... I don't know when >> I'll be able to have a look into the sdk and mer > > I don't know how much current PIM storage in SailFish OS has diverged > from MeeGo; for MeeGo, kcalextended and qtcontacts were the relevant > backends. > the discussion is very interesting. However I am very pragmatic and I would bring you back to the original topic. It should work at least for N=2 devices for me and the question is can be done something for SailFish and what, so that I can use SyncEvolution with it via bluetooth. If you know more than me, can you share or draft a plan what should be done. Thanks _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From tino.keitel+syncevolution at tikei.de Mon Nov 21 08:12:58 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Mon, 21 Nov 2016 09:12:58 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> Message-ID: <20161121081258.GA28952@eazy.amigager.de> On Mon, Nov 21, 2016 at 08:00:33 +0100, deloptes wrote: > devices for me and the question is can be done something for SailFish and > what, so that I can use SyncEvolution with it via bluetooth. If you know Hi, is Bluetooth the only option for you? It looks like Sailfish can sync via CalDAV/CardDAV OOTB. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Mon Nov 21 18:04:02 2016 From: deloptes at gmail.com (deloptes) Date: Mon, 21 Nov 2016 19:04:02 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth References: <1478956829.4896.2.camel@intel.com> <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <20161121081258.GA28952@eazy.amigager.de> Message-ID: Tino Mettler wrote: > On Mon, Nov 21, 2016 at 08:00:33 +0100, deloptes wrote: > > >> devices for me and the question is can be done something for SailFish and >> what, so that I can use SyncEvolution with it via bluetooth. If you know > > Hi, > > is Bluetooth the only option for you? It looks like Sailfish can sync via > CalDAV/CardDAV OOTB. > Hi, yes I would prefer bluetooth as I do not use wireless, or at least avoid using it. + I don't have Cal/CardDav server setup. Can SyncEvolution offer Cal/CardDav functionality as server? It could be interim solution. regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From tino.keitel+syncevolution at tikei.de Tue Nov 22 08:47:31 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Tue, 22 Nov 2016 09:47:31 +0100 Subject: [SyncEvolution] Sync with SailFish OS via Bluetooth In-Reply-To: References: <1479155291.3240.21.camel@intel.com> <1479245198.18151.5.camel@intel.com> <1479280589.18151.13.camel@intel.com> <20161121081258.GA28952@eazy.amigager.de> Message-ID: <20161122084731.GA9603@eazy.amigager.de> On Mon, Nov 21, 2016 at 19:04:02 +0100, deloptes wrote: > Hi, > yes I would prefer bluetooth as I do not use wireless, or at least avoid > using it. I must have missed something, as I never saw a Bluetooth cable yet. :-) > + I don't have Cal/CardDav server setup. Can SyncEvolution offer Cal/CardDav > functionality as server? It could be interim solution. As already mentioned earlier, syncevolution is not a CalDAV/CardDAV server. I use DAViCal and all my clients (Linux, macOS, iOS) sync with this server. _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From tino.keitel+syncevolution at tikei.de Fri Nov 18 09:50:11 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Fri, 18 Nov 2016 10:50:11 +0100 Subject: [SyncEvolution] Running test cases without network access Message-ID: <20161118095010.6izlalbpiiynkgkn@mac.home> Hi Patrick, for the Debian build, I'd like to enable the part of the test suite that does not require network access. Is this possible in a trivial way? If yes, how? Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Nov 18 12:21:04 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 18 Nov 2016 13:21:04 +0100 Subject: [SyncEvolution] Running test cases without network access In-Reply-To: <20161118095010.6izlalbpiiynkgkn@mac.home> References: <20161118095010.6izlalbpiiynkgkn@mac.home> Message-ID: <1479471664.27625.16.camel@intel.com> On Fri, 2016-11-18 at 10:50 +0100, Tino Mettler wrote: > Hi Patrick, > > for the Debian build, I'd like to enable the part of the test suite > that does not require network access. Is this possible in a trivial > way? If yes, how? "client-test SyncEvolution" runs the unit tests. However, those depend on adding additional code into the binaries via the --enable-unit-tests configure option, which is probably better avoided for the Debian binaries. "client-test SyncSource::eds_contact SyncSource::eds_event ...eds_memo...eds_task" runs the tests for the corresponding PIM backends. For EDS, those are local. This depends on --enable-integration-tests, which is fine for production binaries. For production binaries, there's also the test-dbus.py testing. But some of those tests depend on a peer and there's no easy way of skipping just those tests. This could be added, though. -- 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 Fri Nov 18 13:16:12 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Fri, 18 Nov 2016 14:16:12 +0100 Subject: [SyncEvolution] Running test cases without network access In-Reply-To: <1479471664.27625.16.camel@intel.com> References: <20161118095010.6izlalbpiiynkgkn@mac.home> <1479471664.27625.16.camel@intel.com> Message-ID: <20161118131612.GA32750@eazy.amigager.de> On Fri, Nov 18, 2016 at 13:21:04 +0100, Patrick Ohly wrote: [...] > "client-test SyncSource::eds_contact > SyncSource::eds_event ...eds_memo...eds_task" > runs the tests for the corresponding PIM backends. For EDS, those are > local. This depends on --enable-integration-tests, which is fine for > production binaries. > > For production binaries, there's also the test-dbus.py testing. But some > of those tests depend on a peer and there's no easy way of skipping just > those tests. This could be added, though. Hi, thanks a lot. That sounds less complicated than I expected. Btw., I just uploaded 1.5.2 to Debian Sid. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Nov 18 13:38:49 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 18 Nov 2016 14:38:49 +0100 Subject: [SyncEvolution] Running test cases without network access In-Reply-To: <20161118131612.GA32750@eazy.amigager.de> References: <20161118095010.6izlalbpiiynkgkn@mac.home> <1479471664.27625.16.camel@intel.com> <20161118131612.GA32750@eazy.amigager.de> Message-ID: <1479476329.27625.54.camel@intel.com> On Fri, 2016-11-18 at 14:16 +0100, Tino Mettler wrote: > Btw., I just uploaded 1.5.2 to Debian Sid. Thanks! :-) -- 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 Nov 10 08:15:53 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 10 Nov 2016 09:15:53 +0100 Subject: [SyncEvolution] Problem syncing with two profiles Message-ID: Hi, sorry to bother again, but I observed an issue performing following use case: 1. Sync at home with my user profile A (it says normal sync) 2. Sync in the office with my user profile B 2.1 do refresh-from-remote 2.2 do a sync after some time (it says slow sync) My question is why it does slow sync in 2.2? What could be the reason? Thanks _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Thu Nov 10 08:34:39 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 10 Nov 2016 09:34:39 +0100 Subject: [SyncEvolution] Problem syncing with two profiles In-Reply-To: References: Message-ID: <1478766879.3449.46.camel@intel.com> On Thu, 2016-11-10 at 09:15 +0100, deloptes wrote: > Hi, > sorry to bother again, but I observed an issue performing following use > case: > > 1. Sync at home with my user profile A (it says normal sync) > 2. Sync in the office with my user profile B > 2.1 do refresh-from-remote > 2.2 do a sync after some time (it says slow sync) Sync with what? Mobile phone? > My question is why it does slow sync in 2.2? What could be the reason? This should only happen if something went wrong. The latest syncevolution-log.html should tell whether it was the local (= SyncEvolution) or the remote (= phone) side which decided to do a slow sync. Then one has to check whether the previous sync completed normally. There was a bug that affected some phones such that the sync itself completed, but the OBEX connection was closed prematurely, causing some phones to believe that an error occurred. But that should be fixed in master. -- 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 Nov 10 21:27:28 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 10 Nov 2016 22:27:28 +0100 Subject: [SyncEvolution] Problem syncing with two profiles References: <1478766879.3449.46.camel@intel.com> Message-ID: Patrick Ohly wrote: > Sync with what? Mobile phone? > Yes! I use Nokia N9. >> My question is why it does slow sync in 2.2? What could be the reason? > > This should only happen if something went wrong. The latest > syncevolution-log.html should tell whether it was the local (= > SyncEvolution) or the remote (= phone) side which decided to do a slow > sync. > I was using syncevolution-1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa > Then one has to check whether the previous sync completed normally. > The previous sync (refresh-from-remote) finished without error. I will retest tomorrow and inspect the log more carefully but I did not see any sign of problem > There was a bug that affected some phones such that the sync itself > completed, but the OBEX connection was closed prematurely, causing some > phones to believe that an error occurred. But that should be fixed in > master. Perhaps I use loglevel=10 ? regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Thu Nov 10 22:09:12 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 10 Nov 2016 23:09:12 +0100 Subject: [SyncEvolution] Problem syncing with two profiles References: <1478766879.3449.46.camel@intel.com> Message-ID: deloptes wrote: > Patrick Ohly wrote: > >> Sync with what? Mobile phone? >> > > Yes! I use Nokia N9. > >> There was a bug that affected some phones such that the sync itself >> completed, but the OBEX connection was closed prematurely, causing some >> phones to believe that an error occurred. But that should be fixed in >> master. > > Perhaps I use loglevel=10 ? > > regards FYI: I tried now without refresh-from-remote. I synced last time in the office and now first time at home. It went into slow sync immediately with following result. The next sync was normal. [INFO] addressbook: slow sync done successfully [INFO] calendar: slow sync done successfully [INFO] memo: slow sync done successfully [INFO] todo: slow sync done successfully Synchronization successful. Changes applied during synchronization: +---------------|-----------------------|-----------------------|-CON-+ | | LOCAL | REMOTE | FLI | | Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | addressbook | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 7 | | slow, 0 KB sent by client, 403 KB received | | 5 client item(s) discarded | | 2 server item(s) discarded | | 0 item(s) duplicated | | 211 item(s) matched | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | calendar | 6 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 3 | | slow, 2 KB sent by client, 39 KB received | | 1 client item(s) discarded | | 2 server item(s) discarded | | 0 item(s) duplicated | | 40 item(s) matched | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | memo | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | slow, 0 KB sent by client, 18 KB received | | 88 item(s) matched | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | todo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | | slow, 0 KB sent by client, 0 KB received | | 0 client item(s) discarded | | 1 server item(s) discarded | | 0 item(s) duplicated | | 20 item(s) matched | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | start Thu 10 Nov 2016 10:30:56 PM CET, duration 0:37min | | synchronization completed successfully | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ [ERROR] GLib: Source ID 4 was not found when attempting to remove it _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Nov 11 07:37:32 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 11 Nov 2016 08:37:32 +0100 Subject: [SyncEvolution] Problem syncing with two profiles In-Reply-To: References: <1478766879.3449.46.camel@intel.com> Message-ID: <1478849852.3449.99.camel@intel.com> On Thu, 2016-11-10 at 23:09 +0100, deloptes wrote: > deloptes wrote: > > > Patrick Ohly wrote: > > > >> Sync with what? Mobile phone? > >> > > > > Yes! I use Nokia N9. > > > > >> There was a bug that affected some phones such that the sync itself > >> completed, but the OBEX connection was closed prematurely, causing some > >> phones to believe that an error occurred. But that should be fixed in > >> master. > > > > Perhaps I use loglevel=10 ? > > > > regards > > FYI: I tried now without refresh-from-remote. I synced last time in the > office and now first time at home. It went into slow sync immediately with > following result. The next sync was normal. So switching between home and office triggers a slow sync? I wonder whether the phone sees different deviceIds for the SyncEvolution side in that case. There are two settings in SyncEvolution for this. From a config for the Nokia N97: # the identifier sent to the remote peer for a server initiated sync. # if not set, deviceId will be used instead remoteIdentifier = PC Suite # The SyncML server gets this string and will use it to keep track of # changes that still need to be synchronized with this particular # client; it must be set to something unique (like the pseudo-random # string created automatically for new configurations) among all clients # accessing the same server. # myFUNAMBOL also requires that the string starts with sc-pim- # deviceId = We do server initiated syncs with phones, so "PC Suite" is sent to the phone in the initial message. If I remember correctly, that had to be that fixed string, at least with some Nokia phones. Note that there's no unique deviceId here, which means that different computers will all look alike to the phone, which then notices a mismatch of sync anchors when moving between computers and thus forces a slow sync. Hrm, there's a nice fat TODO in src/syncevo/SyncContext.cpp about this: if (m_serverMode) { // TODO: set the device ID for an OBEX server } else { substTag(xml, "fakedeviceid", getDevID()); } I don't remember why that if() check is there, and why SyncConfig::createPeerTemplate()'s config->setDevID(string("syncevolution-") + UUID()) is not used to set a unique deviceId when configuring phones. Answering that would require some further code archeology and experimenting; not sure when I will have time for that. Perhaps you can check? Here's an example of a sync with a SyncML server: http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-5-2/testing-amd64/34-synthesis/Client_Sync_eds_contact_testItems.send.client.A/syncevolution-log_trm001_001_outgoing.xml syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65syncevolution at lists.intel.com The server then replies with: http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-5-2/testing-amd64/34-synthesis/Client_Sync_eds_contact_testItems.send.client.A/syncevolution-log_trm001_002_incoming.xml syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65syncevolution at lists.intel.com http://www.plan44.ch/fsync_nightly Perhaps that's the reason for the if() check: a HTTP server might require a different LocURI (?) than an OBEX server, and the code does not immediately know what it is (depends on the transport). -- 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 Nov 11 19:11:53 2016 From: deloptes at gmail.com (deloptes) Date: Fri, 11 Nov 2016 20:11:53 +0100 Subject: [SyncEvolution] Problem syncing with two profiles References: <1478766879.3449.46.camel@intel.com> <1478849852.3449.99.camel@intel.com> Message-ID: Patrick Ohly wrote: > So switching between home and office triggers a slow sync? I wonder > whether the phone sees different deviceIds for the SyncEvolution side in > that case. > > There are two settings in SyncEvolution for this. From a config for the > Nokia N97: > > # the identifier sent to the remote peer for a server initiated sync. > # if not set, deviceId will be used instead > remoteIdentifier = PC Suite > Yes this is true. I use actually the Nokia_N900 template > # The SyncML server gets this string and will use it to keep track of > # changes that still need to be synchronized with this particular > # client; it must be set to something unique (like the pseudo-random > # string created automatically for new configurations) among all clients > # accessing the same server. > # myFUNAMBOL also requires that the string starts with sc-pim- > # deviceId = > > We do server initiated syncs with phones, so "PC Suite" is sent to the > phone in the initial message. If I remember correctly, that had to be > that fixed string, at least with some Nokia phones. > > Note that there's no unique deviceId here, which means that different > computers will all look alike to the phone, which then notices a > mismatch of sync anchors when moving between computers and thus forces a > slow sync. > > Hrm, there's a nice fat TODO in src/syncevo/SyncContext.cpp about this: > > if (m_serverMode) { > // TODO: set the device ID for an OBEX server > } else { > substTag(xml, "fakedeviceid", getDevID()); > } > > I don't remember why that if() check is there, and why > SyncConfig::createPeerTemplate()'s > config->setDevID(string("syncevolution-") + UUID()) is not used to set a > unique deviceId when configuring phones. > > Answering that would require some further code archeology and > experimenting; not sure when I will have time for that. Perhaps you can > check? > > Here's an example of a sync with a SyncML server: > > http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-5-2/testing-amd64/34-synthesis/Client_Sync_eds_contact_testItems.send.client.A/syncevolution-log_trm001_001_outgoing.xml > syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65syncevolution at lists.intel.com > > The server then replies with: > http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-5-2/testing-amd64/34-synthesis/Client_Sync_eds_contact_testItems.send.client.A/syncevolution-log_trm001_002_incoming.xml > syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65syncevolution at lists.intel.com > http://www.plan44.ch/fsync_nightly > > Perhaps that's the reason for the if() check: a HTTP server might > require a different LocURI (?) than an OBEX server, and the code does > not immediately know what it is (depends on the transport). I don't see it in the sync via bluetooth. I see in the html log device ID: syncevolution-33702b00-09b0-4a05-8eb0-4057b41667a6 device ID: syncevolution-5c646a89-d7bb-4338-b5b5-3e6f4eb6e1f9 In the xml I see only the Nokia/Phone ID IMEI:xxxxxxxxxxxxxxxx/LocURI> .... ./devinf12 .... ./contacts I was also thinking that based on the device ID it might be deciding to compare all items, which perhaps makes also sense. I'm not sure. regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Nov 11 19:50:00 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 11 Nov 2016 20:50:00 +0100 Subject: [SyncEvolution] Problem syncing with two profiles In-Reply-To: References: <1478766879.3449.46.camel@intel.com> <1478849852.3449.99.camel@intel.com> Message-ID: <1478893800.3449.110.camel@intel.com> On Fri, 2016-11-11 at 20:11 +0100, deloptes wrote: > Patrick Ohly wrote: > > Perhaps that's the reason for the if() check: a HTTP server might > > require a different LocURI (?) than an OBEX server, and the code does > > not immediately know what it is (depends on the transport). > > I don't see it in the sync via bluetooth. I see in the html log > > device ID: syncevolution-33702b00-09b0-4a05-8eb0-4057b41667a6 > device ID: syncevolution-5c646a89-d7bb-4338-b5b5-3e6f4eb6e1f9 Where do you see that? > In the xml I see only the Nokia/Phone ID > > > IMEI:xxxxxxxxxxxxxxxx/LocURI> > > .... > > ./devinf12 > > .... > > ./contacts > > > I was also thinking that based on the device ID it might be deciding to > compare all items, which perhaps makes also sense. I'm not sure. The initial, so called SAN message, is not getting dumped. See SyncContext::sendSAN() for the code which generates it. That there's no LocURI for SyncEvolution confirms my theory that the phone can't distinguish between the different computers. However, after thinking some more about it I suspect that sending a LocURI as part of the SyncML session wouldn't help: basically the phone picks the configuration (and thus the sync anchors) based on the information in the SAN message. At least that's how SyncEvolution does it. It's worth trying with remoteIdentifier set differently on the two computers. -- 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 Thu Nov 10 09:53:05 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 10 Nov 2016 10:53:05 +0100 Subject: [SyncEvolution] survey: providing SyncEvolution binaries In-Reply-To: <20160921120527.GA9214@eazy.amigager.de> References: <1471872151.24499.9.camel@intel.com> <20160913185814.l2effqh3bcdkya5j@mac.home> <20160921081805.GA10850@eazy.amigager.de> <1474448983.8363.18.camel@intel.com> <20160921120527.GA9214@eazy.amigager.de> Message-ID: <1478771585.3449.63.camel@intel.com> On Wed, 2016-09-21 at 14:05 +0200, Tino Mettler wrote: > On Wed, Sep 21, 2016 at 11:09:43 +0200, Patrick Ohly wrote: > > On Wed, 2016-09-21 at 10:18 +0200, Tino Mettler wrote: > > > may I assume that nothing release-ish is scheduled for the next few > > > months? Otherwise it would be nice to be as recent as possible > > > regarding the version in Debian when the freeze starts. > > > > Quite the opposite, I am determined to finally get a 1.5.2 out ;-} > > I might have some pre-release binaries for testing this week or early > > next week. > > Hi, > > I would like to know about the relevant git tags for syncevolution and > libsynthesis when this happens, and also when the tags are moved due to > late changes (which at least happened in the past). I've released 1.5.2 and the associated tags should all be in place and final. I understand that this is closer to the Debian Stretch freeze than originally hope, but perhaps you can still get it in. Thanks for your help! -- 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 Thu Nov 10 13:04:00 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Thu, 10 Nov 2016 14:04:00 +0100 Subject: [SyncEvolution] survey: providing SyncEvolution binaries In-Reply-To: <1478771585.3449.63.camel@intel.com> References: <1471872151.24499.9.camel@intel.com> <20160913185814.l2effqh3bcdkya5j@mac.home> <20160921081805.GA10850@eazy.amigager.de> <1474448983.8363.18.camel@intel.com> <20160921120527.GA9214@eazy.amigager.de> <1478771585.3449.63.camel@intel.com> Message-ID: <20161110130400.GA19357@eazy.amigager.de> On Thu, Nov 10, 2016 at 10:53:05 +0100, Patrick Ohly wrote: [...] > I understand that this is closer to the Debian Stretch freeze than > originally hope, but perhaps you can still get it in. Thanks for > your help! Hi, the timing is currently not a problem. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Thu Nov 10 09:50:56 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 10 Nov 2016 10:50:56 +0100 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> <1477491693.2887.48.camel@intel.com> Message-ID: <1478771456.3449.61.camel@intel.com> On Wed, 2016-10-26 at 17:44 +0100, Graham Cobb wrote: > 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). After checking I came to the conclusion that the differences are harmless and merely come from slightly different names getting assigned to the daylight resp. standard component of the time zone. Perhaps Exchange 2016 and/or recent time zone definition changes caused that. I've updated the test cases to get clean test passes. -- 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 Thu Nov 3 07:42:38 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 03 Nov 2016 08:42:38 +0100 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: <1478158958.13356.97.camel@intel.com> On Sun, 2016-10-23 at 22:09 +0200, deloptes wrote: > 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. Thanks. I've merged the patches and will prepare a final release candidate now. The nightly build machine needs to go through some maintenance soon, so I might have to finish 1.5.2 this weekend. In the future, can you commit the changes in your local git repo with a suitable commit message and then export them with "git format-patch"? Alternatively I could also revive the github mirror of the repos and you could do a pull request. -- 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 Nov 3 19:21:59 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 3 Nov 2016 20:21:59 +0100 Subject: [SyncEvolution] Release preparations for 1.5.2 References: <1475153100.11658.12.camel@intel.com> <1476646418.14278.7.camel@intel.com> <1478158958.13356.97.camel@intel.com> Message-ID: Patrick Ohly wrote: > Thanks. I've merged the patches and will prepare a final release > candidate now. The nightly build machine needs to go through some > maintenance soon, so I might have to finish 1.5.2 this weekend. > > In the future, can you commit the changes in your local git repo with a > suitable commit message and then export them with "git format-patch"? > Alternatively I could also revive the github mirror of the repos and you > could do a pull request. Thank you, Patrick! I will love to do so in the future. I used git diff to create the patches. Thanks a lot for the valuable help. I can't stop telling this :) regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Thu Nov 10 09:36:06 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 10 Nov 2016 10:36:06 +0100 Subject: SyncEvolution 1.5.2 released Message-ID: <1478770566.3449.59.camel@intel.com> About SyncEvolution =================== SyncEvolution synchronizes personal information management (PIM) data via various protocols (SyncML, CalDAV/CardDAV, ActiveSync). It syncs contacts, appointments, tasks and memos. It syncs to web services or to SyncML-capable phones via Bluetooth. Binaries are available for Linux desktops (using GNOME Evolution, or KDE's Akonadi) and the source code also supports the Trinity Desktop Environment (TDE). About 1.5.2 =========== Maintenance release. syncevolution.org binaries are now getting compiled for distros >= Ubuntu Trusty 14.04 LTS, which allowed removing several hacks that were needed when building binaries that also had to run on older distros. Compilation from source for old distros should still work as before, but is not getting tested anymore. Compile problems with recent libraries (libical v2) and tools (GCC v6) were resolved. Syncing via Bluetooth with certain phones now should work reliably in incremental mode. New backends for the Trinity Desktop Environment (TDE) were added to the source code. Details: * ObexTransportAgent.cpp: properly shut down connection (FDO #91485) Apparently there's a race condition in the OBEX transport that causes the connection to phones via Bluetooth to be shut down prematurely. Some phones react by doing a slow sync instead of an incremental sync the next time. * support non-readable parent directories (FDO #91000) The previous mkdir_p() walked down top to bottom and checked each path entry as it went along. That approach failed unnecessarily when some existing parent directory could not be read (non-readable /home, for example). * avoid using dbus-launch (Debian #836399) dbus-launch is considered deprecated because of the X11 dependency. See https://lists.debian.org/debian-devel/2016/08/msg00554.html "Mass bug filing: use and misuse of dbus-launch (dbus-x11)" The dbus-session.sh script still needs to start the D-Bus daemon when used in the nightly testing, so the code now does it by invoking the dbus-daemon directly. syncevo-http-server still has some usage of dbus-launch left, but that's strictly for systems which don't have the more modern D-Bus. * syncevo-dbus-server integrates better with systemd (FDO #92164) A .service file allows the D-Bus daemon to start the service via systemd, thus ensuring that the process environment is correct. Patch from Simon McVittie. Auto-starting as part of the desktop login uses D-Bus activation if the "dbus-send" tool is installed. * syncevolution.org: compile on Ubuntu Trusty, libical v1/v2 compatibility syncevolution.org binaries are now getting compiled on Ubuntu Trusty and thus no longer support distros with older EDS. The code should still compile against older EDS (for example, for Maemo), but that is not getting tested anymore. This allows removing the dynamic linker hacks related to older libraries, which was only used in those binaries. Instead, backends using libical or EDS get compiled on Ubuntu Trusty and then the soname of those libs get patched to make the backend module usable in combination with a different set of libs. That patching is part of a script maintained in the syncevolution.org build infrastructure. This approach was already used before to generate different EDS backends for EDS versions with the newer EClient API, because that turned out to be easier than the dynamic loading approach. It works because none of the methods used by SyncEvolution changed their ABI, only some other parts of the libraries did. Should there ever be a situation again that cannot be handled like this, then backends also get compiled on different distros than Ubuntu Trusty (for example, the ActiveSync backend for Debian Stretch is built on Debian Stretch). libical still requires one special hack: system time zone loading in libical v1 (and only in that version, v2 has builtin support again) must be overridden such that time zones are generated with rules instead of transitions because that is more compatible with the peers that SyncEvolution exchanges data with. That hack now relies on overriding the two relevant functions inside the main binaries (has to be there, otherwise libical still ends up calling its own internal implementation). The overriding code is in libsyncevo-icaltz-util.so.0 and depends on libical.so.1. If libsyncevo-icaltz-util.so.0 can be loaded, the wrappers in the main binary use it, otherwise they fall through to the code from the current libical.so, which then should be libical.so.2 or more recent. This hack is active by default when libical v1 is detected during configuration. * optionally show debug output in --version output SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --version now dumps also the debug information gathered by the binary compatibility code. It was only available in sync logs before. * various build fixes for libical v2, GCC v6/C++14 Source, Installation, Further information ========================================= http://syncevolution.org/blogs/pohly/2016/syncevolution-152-released Source code bundles for users are available in https://download.01.org/syncevolution/syncevolution/sources and the original source is in the git repositories http://cgit.freedesktop.org/SyncEvolution/ i386 and amd64 binaries for Debian-based distributions are available via the "stable" syncevolution.org repository. Add the following entry to your /etc/apt/source.list: deb https://download.01.org/syncevolution/apt stable main The GPG key for the repository needs to be imported as root with: apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 43D03AD9 The signing key was renewed for this release. If the key was already added earlier, refresh it with: apt-key adv --keyserver keyserver.ubuntu.com --refresh-keys 43D03AD9 Then install "syncevolution-evolution", "syncevolution-kde" and/or "syncevolution-activesync". These binaries include the "sync-ui" GTK GUI and were compiled for Ubuntu 14.04 LTS (Trusty) and should be compatible also with more recent distros. ActiveSync binaries were compiled for Debian Jessie, the upcoming Debian Stretch (based on current Testing), and Ubuntu Trusty. The packages mentioned above are meta-packages which pull in suitable packages matching the distro during installation. Older distributions can no longer be supported with precompiled binaries because of missing or incompatible libraries, but the source should still compile on older distros. The same binaries are also available as .tar.gz archives in https://download.01.org/syncevolution/syncevolution/. In contrast to 0.8.x archives, the 1.x .tar.gz archives have to be unpacked and the content must be moved to /usr, because several files would not be found otherwise. When using activesyncd, run "glib-compile-schemas /usr/share/glib-2.0/schemas" as root after unpacking the archive. rpm packages are no longer provided due to lack of demand; SyncEvolution is provided by Fedora as a distro package. After installation, follow the http://syncevolution.org/documentation/getting-started steps. More specific HOWTOs can be found in the Wiki: https://syncevolution.org/wiki/howto -- Patrick Ohly, on behalf of everyone who has helped to make SyncEvolution possible: http://syncevolution.org/about/contributors From deloptes at gmail.com Sun Nov 6 23:13:51 2016 From: deloptes at gmail.com (deloptes) Date: Mon, 7 Nov 2016 00:13:51 +0100 Subject: [SyncEvolution] Building a debian package for the backend Message-ID: Hi, perhaps this question should be addressed to Tino. I am wondering how I can build the TDE backend in a debian package. Is it possible to build and distribute this package only? It is regarding a long term plan to provide TDE ready to install packages. I think RH and Deb are mostly used. Thanks in advance regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From tino.keitel+syncevolution at tikei.de Mon Nov 7 08:00:43 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Mon, 7 Nov 2016 09:00:43 +0100 Subject: [SyncEvolution] Building a debian package for the backend In-Reply-To: References: Message-ID: <20161107080043.GA10328@eazy.amigager.de> On Mon, Nov 07, 2016 at 00:13:51 +0100, deloptes wrote: > Hi, > perhaps this question should be addressed to Tino. > > I am wondering how I can build the TDE backend in a debian package. > Is it possible to build and distribute this package only? Hi, just add a TDE package for the backend libs, as already done for Gnome and KDE. Builing only the TDE libs package won't be that easy, but it's also somewhat pointless I think as you need the internal libs that are create during build. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Mon Nov 7 22:37:15 2016 From: deloptes at gmail.com (deloptes) Date: Mon, 7 Nov 2016 23:37:15 +0100 Subject: [SyncEvolution] Building a debian package for the backend References: <20161107080043.GA10328@eazy.amigager.de> Message-ID: Tino Mettler wrote: > On Mon, Nov 07, 2016 at 00:13:51 +0100, deloptes wrote: >> Hi, >> perhaps this question should be addressed to Tino. >> >> I am wondering how I can build the TDE backend in a debian package. >> Is it possible to build and distribute this package only? > > Hi, > Hi and thank you for coming back to me on this subject. Let me explain what I need, because I am not sure that I understand correctly your answer. We have the deb packages build and offered recently, but we don't have the TDE packages( pim + wallet ). Who's suppose to build them together with the other packages? I don't think I can or should rebuild all packages for trinity desktop just to have support for two extra backends. > just add a TDE package for the backend libs, as already done for Gnome > and KDE. Builing only the TDE libs package won't be that easy, but it's > also somewhat pointless I think as you need the internal libs that are > create during build. > Do you mean add to Debian/RH etc the file to build the packages? Not sure what you mean. I mean I can use the source to build syncevolution with tdepim and tdewallet, but I can not afford it to build all other packages (that are already build anyway like activesync or evolution) And what I am missing is the debian directory for the new 1.5.2. Where can this be found (for jessie,testing and sid) thanks _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From tino.keitel+syncevolution at tikei.de Tue Nov 8 08:02:13 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Tue, 8 Nov 2016 09:02:13 +0100 Subject: [SyncEvolution] Building a debian package for the backend In-Reply-To: References: <20161107080043.GA10328@eazy.amigager.de> Message-ID: <20161108080212.GA23236@eazy.amigager.de> On Mon, Nov 07, 2016 at 23:37:15 +0100, deloptes wrote: [...] > Hi and thank you for coming back to me on this subject. > Let me explain what I need, because I am not sure that I understand > correctly your answer. > > We have the deb packages build and offered recently, but we don't have the > TDE packages( pim + wallet ). Who's suppose to build them together with the > other packages? I don't know how TDE is supposed to be packaged/distributed. I took a look and it doesn't seem to be part of Debian, so I can't enable TDE support in the Debian packages. > I don't think I can or should rebuild all packages for trinity desktop just > to have support for two extra backends. Why not? Shipping only the backends might also cause problems with the already installed syncevolution, for instance the backend search path, which depends on the distribution/architecture/build type/etc. > I mean I can use the source to build syncevolution with tdepim and > tdewallet, but I can not afford it to build all other packages That shouldn't be neccessary. > And what I am missing is the debian directory for the new 1.5.2. Where can > this be found (for jessie,testing and sid) 1.5.2 is not released yet. The debian packaging for 1.5.1 should work, though. At least it worked for me when I did a test build/test run a few weeks ago with the git source. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution