From helge at kraak.info Sun Jan 12 02:55:07 2014 From: helge at kraak.info (Helge Kraak) Date: Sun, 12 Jan 2014 03:55:07 +0100 Subject: [SyncEvolution] Setup of SyncML to WebDAV synchronization bridge: Problem with SSLVerifyServer switch in configuration command Message-ID: Hi, during my journey of setting up a synchronization of a Palm Tungsten TX running the Synthesis SyncML application and a SabreDAV server I tried the following configuration command adapted from the syncevolution manual: syncevolution --configure ? ? ? ? ? ? ? ? ? ? ?SSLVERIFYSERVER=FALSE databaseUser=admin "databasePassword=admin" addressbook/backend=carddav addressbook/database=HTTPS://LOCALHOST:443/SABREDAV/ADDRESSBOOKSERVER.PHP/ calendar/backend=caldav calendar/database=HTTPS://LOCALHOST:443/SABREDAV/ADDRESSBOOKSERVER.PHP/ @webdav calendar addressbook It returns this error message: [ERROR 00:00:00] per-peer (unshared) properties not allowed: SSLVerifyServer With other configuration commands not dealing with this specific SyncML - WebDAV setup I can use this switch. Thanks. Helge -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Mon Jan 13 08:11:19 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 13 Jan 2014 09:11:19 +0100 Subject: [SyncEvolution] Setup of SyncML to WebDAV synchronization bridge: Problem with SSLVerifyServer switch in configuration command In-Reply-To: References: Message-ID: <1389600679.5855.404.camel@pohly-mobl1.fritz.box> On Sun, 2014-01-12 at 03:55 +0100, Helge Kraak wrote: > Hi, > > during my journey of setting up a synchronization of a Palm Tungsten > TX running the Synthesis SyncML application and a SabreDAV server I > tried the following configuration command adapted from the > syncevolution manual: > > syncevolution --configure \ > > SSLVerifyServer=False \ > > databaseUser=admin \ > > "databasePassword=admin" \ > > addressbook/backend=carddav \ > > > addressbook/database=https://localhost:443/sabredav/addressbookserver.php/ \ > > calendar/backend=caldav \ > > > calendar/database=https://localhost:443/sabredav/addressbookserver.php/ \ > > @webdav \ > > calendar addressbook > > > > It returns this error message: > > [ERROR 00:00:00] per-peer (unshared) properties not allowed: > SSLVerifyServer > > With other configuration commands not dealing with this specific > SyncML - WebDAV setup I can use this switch. Configure options are applied to what is mentioned as target of the configuration change. In this case, that are four things: 1. The @webdav context = ~/.config/syncevolution/webdav/config.ini 2. The calendar source in that context = ~/.config/syncevolution/webdav/sources/calendar/config.ini 3. The addressbook source in that context = ~/.config/syncevolution/webdav/sources/addressbook/config.ini 4. The global config = ~/.config/syncevolution/config.ini The last one is a somewhat unfortunate special case; only very few options go into it, so typically it doesn't get changed. In you case, SSLVerifyServer cannot be set in any of these places. Instead of silently ignoring it, you get the error. What you can do is set SSLVerifyServer in the sync config for the Palm. It'll be picked up from there by the backend. Not very intuitive, I know, and might even lead to potential conflicts (what if the option has some meaning there different from what the source expects?). I just don't have a good solution. One solution would be to have databaseSSLVerify* options which can go into the source configs. But that's leading to a further proliferation of similar options. -- 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 helge at kraak.info Tue Jan 14 11:43:42 2014 From: helge at kraak.info (Helge Kraak) Date: Tue, 14 Jan 2014 12:43:42 +0100 Subject: [SyncEvolution] Setup of SyncML to WebDAV synchronization bridge: Problem with SSLVerifyServer switch in configuration command In-Reply-To: <1389684576.19530.7.camel@pohly-mobl1.fritz.box> References: <1389600679.5855.404.camel@pohly-mobl1.fritz.box> <52D4BEF3.4080101@kraak.info> <1389684576.19530.7.camel@pohly-mobl1.fritz.box> Message-ID: <52D522EE.6040606@kraak.info> Thank you, Patrick. I tried your suggestion for the third command but when I start initiate a sync I get the error message that no configuration could be found for the deviceID (like with the third variation below). It's correct that I don't need to use the keyring=no option again in the third command but I have to apply the *SSLVerifyServer=False *option also in the third command for creating the Palm peer, otherwise I get a SSL verification error. As a result of these observations I tried to initiate a sync with the following three versions of the third command (for every variation I started with an empty syncevolution config and reapplied the first two commands before every time as well): *1. *My previous version without *keyring=no*: /syncevolution --configure /*SSLVerifyServer=False --template *SyncEvolution_Client/--sync-property remoteDeviceId=ST23K3J5I4JX// username=admin password=admin /--source-property addressbook/uri=addressbook Palm-TH55 at webdav RETURNS: "First ERROR encountered: error code from SyncEvolution fatal error (local, status 10500): no sources active, check configuration" *2.* My previous version without *keyring=no* but with *sync=two-way* as you suggested: /syncevolution --configure /*SSLVerifyServer=False --template *SyncEvolution_Client/ --sync-property remoteDeviceId=ST23K3J5I4JX// username=admin password=admin /--source-property addressbook/uri=addressbook sync=two-way Palm-TH55 at webdav RETURNS: "First ERROR encountered: error code from SyncEvolution fatal error (local, status 10500): no sources active, check configuration" --> Same error message *3.* My previous version without *keyring=no* but with *sync=two-way* and *addressbook* like you suggested: /syncevolution --configure /*SSLVerifyServer=False --template *SyncEvolution_Client/ --sync-property remoteDeviceId=/PN70M9J5V7JX/ username=admin password=admin /--source-property addressbook/uri=addressbook sync=two-way Palm-TH55 at webdav addressbook RETURNS for the command: "[INFO] addressbook: looking for databases... [INFO] addressbook: no database to synchronize [ERROR] addressbook: no database to synchronize" AND for the sync initiation: "no configuration found for deviceID ST23K3J5I4JX" On 1/14/14 8:29 AM, Patrick Ohly wrote: > On Tue, 2014-01-14 at 05:37 +0100, Helge Kraak wrote: >> ### Third command ### >> >> syncevolution --configure >> keyring=no SSLVerifyServer=False >> --template SyncEvolution_Client >> --sync-property remoteDeviceId=ST23K3J5I4JX >> username=admin password=admin >> --source-property addressbook/uri=addressbook >> --source-property calendar/uri=events >> --source-property todo/uri=tasks >> --source-property memo/uri=memo >> Palm-TH55 at webdav >> >> >> RETURNS: >> >> [INFO] addressbook: looking for databases... >> [INFO] addressbook: no database to synchronize > This might be a false message. I think it is not actually checking for > anything because the address book was already configured. > >> [INFO] calendar: looking for databases... >> [INFO] calendar: backend failed: error code from SyncEvolution >> authorization failed (remote, status 401): calendar: syncURL not >> configured and username admin does not contain a domain >> [INFO] memo: looking for databases... >> [INFO] memo: backend failed: error code from SyncEvolution >> authorization failed (remote, status 401): memo: syncURL not >> configured and username admin does not contain a domain >> [INFO] todo: looking for databases... >> [INFO] todo: backend failed: error code from SyncEvolution >> authorization failed (remote, status 401): todo: syncURL not >> configured and username admin does not contain a domain > This of course is correct. It's merely informational, so what you end up > with should be a config where these sources are simply not enabled > ("sync" = "none" or "disabled"). > >> Here I'm stuck. What am I missing so that the database on at the >> WebDAV server cannot be found? > If you want to enable just contacts, then use: > > > syncevolution --configure \ > --template SyncEvolution_Client \ > remoteDeviceId=ST23K3J5I4JX \ > username=admin password=admin \ > sync=two-way \ > Palm-TH55 at webdav \ > addressbook > > You don't need to repeat values like keyring=no which were already set > earlier. "--source-property addressbook/uri=addressbook" is redundant, > because the name of the source and URI are identical in this case. > > What I added is "sync=two-way", to ensure that the addressbook source > really gets enabled for the Palm-TH55 client. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Tue Jan 14 12:23:11 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 14 Jan 2014 13:23:11 +0100 Subject: [SyncEvolution] Setup of SyncML to WebDAV synchronization bridge: Problem with SSLVerifyServer switch in configuration command In-Reply-To: <52D522EE.6040606@kraak.info> References: <1389600679.5855.404.camel@pohly-mobl1.fritz.box> <52D4BEF3.4080101@kraak.info> <1389684576.19530.7.camel@pohly-mobl1.fritz.box> <52D522EE.6040606@kraak.info> Message-ID: <1389702191.19530.15.camel@pohly-mobl1.fritz.box> On Tue, 2014-01-14 at 12:43 +0100, Helge Kraak wrote: > I tried your suggestion for the third command but when I start > initiate a sync I get the error message that no configuration could be > found for the deviceID (like with the third variation below). > > It's correct that I don't need to use the keyring=no option again in > the third command but I have to apply the SSLVerifyServer=False option > also in the third command for creating the Palm peer, otherwise I get > a SSL verification error. That should only happen if you try to use WebDAV sources which have not been configured before. It's unfortunate that the SSL options don't have a good place in the config hierarchy. > 3. My previous version without keyring=no but with sync=two-way and > addressbook like you suggested: > > syncevolution --configure SSLVerifyServer=False > --template SyncEvolution_Client --sync-property > remoteDeviceId=PN70M9J5V7JX username=admin > password=admin --source-property addressbook/uri=addressbook > sync=two-way Palm-TH55 at webdav addressbook > > RETURNS for the command: > > "[INFO] addressbook: looking for databases... > [INFO] addressbook: no database to synchronize > [ERROR] addressbook: no database to synchronize" > > AND for the sync initiation: > > "no configuration found for deviceID ST23K3J5I4JX" This is the right approach. The key question is if the command from the second step has configured the "addressbook". If it has, then the third step should not need to look for databases. What does "syncevolution --print-config -q @webdav addressbook" say? Either way, does it work if you combine steps 2 and 3? syncevolution --configure \ --template SyncEvolution_Client \ remoteDeviceId=PN70M9J5V7JX username=admin password=admin \ sync=two-way \ databaseUser=admin \ databasePassword=admin \ backend=carddav \ database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ \ Palm-TH55 at webdav addressbook -- 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 helge at kraak.info Tue Jan 14 13:25:46 2014 From: helge at kraak.info (Helge Kraak) Date: Tue, 14 Jan 2014 14:25:46 +0100 Subject: [SyncEvolution] Setup of SyncML to WebDAV synchronization bridge: Problem with SSLVerifyServer switch in configuration command In-Reply-To: <1389702191.19530.15.camel@pohly-mobl1.fritz.box> References: <1389600679.5855.404.camel@pohly-mobl1.fritz.box> <52D4BEF3.4080101@kraak.info> <1389684576.19530.7.camel@pohly-mobl1.fritz.box> <52D522EE.6040606@kraak.info> <1389702191.19530.15.camel@pohly-mobl1.fritz.box> Message-ID: When I apply as third command (no ADDRESSBOOK at the end of the command) _syncevolution --configure _SSLVERIFYSERVER=FALSE --TEMPLATE?SyncEvolution_Client_ --sync-property remoteDeviceId=ST23K3J5I4JX__ username=admin password=admin _--source-property addressbook/uri=addressbook sync=two-way Palm-TH55 at webdav the command syncevolution --print-config -q @webdav addressbook RETURNS: "[addressbook] backend = CardDAV database = https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ # databaseFormat = databaseUser = admin databasePassword = admin" When I try your combined command (I have to include SSLVerifyServer=False again to make it work) syncevolution --configure SSLVERIFYSERVER=FALSE --template SyncEvolution_Client remoteDeviceId=PN70M9J5V7JX username=admin password=admin sync=two-way databaseUser=admin databasePassword=admin backend=carddav database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ [2] Palm-TH55 at webdav addressbook IT RETURNS "[INFO] addressbook: looking for databases... [INFO] addressbook: no database to synchronize [ERROR] addressbook: no database to synchronize" AND FOR syncevolution --print-config -q @webdav addressbook IT RETURNS "[addressbook] backend = CardDAV # database = # databaseFormat = # databaseUser = # databasePassword =" Am 2014-01-14 13:23, schrieb Patrick Ohly: > On Tue, 2014-01-14 at 12:43 +0100, Helge Kraak wrote: > >> I tried your suggestion for the third command but when I start initiate a sync I get the error message that no configuration could be found for the deviceID (like with the third variation below). It's correct that I don't need to use the keyring=no option again in the third command but I have to apply the SSLVerifyServer=False option also in the third command for creating the Palm peer, otherwise I get a SSL verification error. > > That should only happen if you try to use WebDAV sources which have not > been configured before. > > It's unfortunate that the SSL options don't have a good place in the > config hierarchy. > >> 3. My previous version without keyring=no but with sync=two-way and addressbook like you suggested: syncevolution --configure SSLVerifyServer=False --template SyncEvolution_Client --sync-property remoteDeviceId=PN70M9J5V7JX username=admin password=admin --source-property addressbook/uri=addressbook sync=two-way Palm-TH55 at webdav addressbook > >> RETURNS for the command: > >> "[INFO] addressbook: looking for databases... >> [INFO] addressbook: no database to synchronize >> [ERROR] addressbook: no database to synchronize" > >> AND for the sync initiation: > >> "no configuration found for deviceID ST23K3J5I4JX" > > This is the right approach. The key question is if the command from the > second step has configured the "addressbook". If it has, then the third > step should not need to look for databases. > > What does "syncevolution --print-config -q @webdav addressbook" say? > > Either way, does it work if you combine steps 2 and 3? > > syncevolution --configure > --template SyncEvolution_Client > remoteDeviceId=PN70M9J5V7JX username=admin password=admin > sync=two-way > databaseUser=admin > databasePassword=admin > backend=carddav > database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ [1] > Palm-TH55 at webdav addressbook Links: ------ [1] https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ [2] https://localhost/sabredav/addressbookserver.php/addressbooks/admin/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Tue Jan 14 14:32:21 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 14 Jan 2014 15:32:21 +0100 Subject: [SyncEvolution] Setup of SyncML to WebDAV synchronization bridge: Problem with SSLVerifyServer switch in configuration command In-Reply-To: References: <1389600679.5855.404.camel@pohly-mobl1.fritz.box> <52D4BEF3.4080101@kraak.info> <1389684576.19530.7.camel@pohly-mobl1.fritz.box> <52D522EE.6040606@kraak.info> <1389702191.19530.15.camel@pohly-mobl1.fritz.box> Message-ID: <1389709941.16995.20.camel@pohly-mobl1.fritz.box> On Tue, 2014-01-14 at 14:25 +0100, Helge Kraak wrote: > When I apply as third command (no addressbook at the end of the > command) > > syncevolution --configure SSLVerifyServer=False > --template SyncEvolution_Client --sync-property > remoteDeviceId=ST23K3J5I4JX username=admin > password=admin --source-property addressbook/uri=addressbook > sync=two-way Palm-TH55 at webdav > > the command > > syncevolution --print-config -q @webdav addressbook > > RETURNS: > > "[addressbook] > backend = CardDAV > database = > https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ > # databaseFormat = > databaseUser = admin > databasePassword = admin" When you show the config of addressbook for the Palm-TH55 peer, is the "sync" property set? In other words, what do you get from: syncevolution --print-config -q Palm-TH55 at webdav addressbook > When I try your combined command (I have to > include SSLVerifyServer=False again to make it work) > > syncevolution --configure SSLVerifyServer=False \ > --template SyncEvolution_Client \ > remoteDeviceId=PN70M9J5V7JX username=admin password=admin \ > sync=two-way \ > databaseUser=admin \ > databasePassword=admin \ > backend=carddav \ > database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ \ > Palm-TH55 at webdav addressbook > > IT RETURNS > > "[INFO] addressbook: looking for databases... > [INFO] addressbook: no database to synchronize > [ERROR] addressbook: no database to synchronize" I can't reproduce the problem here, using SyncEvolution 1.3.99.6 plus (probably irrelevant) patches. Which version of SyncEvolution are you using? I can reproduce that the last step, adding a peer, will try to verify databases again. But that works for me: $ ./syncevolution --configure --daemon=no databaseUser=test databasePassword=testing calendar/database=http://localhost:8009/caldav.php/test/Test_davical_caldav_1/ todo/database=http://localhost:8009/caldav.php/test/Test_davical_caldav_1/ addressbook/database=http://localhost:8009/caldav.php/test/Test_davical_carddav_1/ calendar/backend=caldav todo/backend=caldavtodo addressbook/backend=carddav @webdav addressbook calendar todo [INFO] addressbook: looking for databases... [INFO] addressbook: okay [INFO] calendar: looking for databases... [INFO] calendar: okay [INFO] todo: looking for databases... [INFO] todo: okay $ ./syncevolution --daemon=no --configure --template SyncEvolution_Client sync=two-way remoteDeviceId=PN70M9J5V7JX username=admin password=admin foo at webdav addressbook [INFO] addressbook: looking for databases... [INFO] addressbook: okay So perhaps SSLVerifyServer simply doesn't get picked up in your case where it is needed. Can you try this: SYNCEVOLUTION_DEBUG=1 syncevolution --configure SSLVerifyServer=False \ --template SyncEvolution_Client \ remoteDeviceId=PN70M9J5V7JX username=admin password=admin \ loglevel=4 \ sync=two-way \ databaseUser=admin \ databasePassword=admin \ backend=carddav \ database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ \ Palm-TH55 at webdav addressbook It should show more information about the "[INFO] addressbook: no database to synchronize" problem. -- 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 helge at kraak.info Tue Jan 14 21:43:27 2014 From: helge at kraak.info (Helge Kraak) Date: Tue, 14 Jan 2014 22:43:27 +0100 Subject: [SyncEvolution] Setup of SyncML to WebDAV synchronization bridge: Problem with SSLVerifyServer switch in configuration command In-Reply-To: <1389709941.16995.20.camel@pohly-mobl1.fritz.box> References: <1389600679.5855.404.camel@pohly-mobl1.fritz.box> <52D4BEF3.4080101@kraak.info> <1389684576.19530.7.camel@pohly-mobl1.fritz.box> <52D522EE.6040606@kraak.info> <1389702191.19530.15.camel@pohly-mobl1.fritz.box> <1389709941.16995.20.camel@pohly-mobl1.fritz.box> Message-ID: Am 14.01.2014 um 15:32 schrieb Patrick Ohly: > On Tue, 2014-01-14 at 14:25 +0100, Helge Kraak wrote: >> When I apply as third command (no addressbook at the end of the >> command) >> >> syncevolution --configure SSLVerifyServer=False >> --template SyncEvolution_Client --sync-property >> remoteDeviceId=ST23K3J5I4JX username=admin >> password=admin --source-property addressbook/uri=addressbook >> sync=two-way Palm-TH55 at webdav >> >> the command >> >> syncevolution --print-config -q @webdav addressbook >> >> RETURNS: >> >> "[addressbook] >> backend = CardDAV >> database = >> https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ >> # databaseFormat = >> databaseUser = admin >> databasePassword = admin" > > When you show the config of addressbook for the Palm-TH55 peer, is the > "sync" property set? In other words, what do you get from: > syncevolution --print-config -q Palm-TH55 at webdav addressbook [addressbook] sync = disabled uri = addressbook backend = CardDAV # syncFormat = # forceSyncFormat = 0 database = https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ # databaseFormat = databaseUser = admin databasePassword = admin I then edited /.config/syncevolution/webdav/peers/palm-th55/sources/addressbook/config.ini so that this command now gives [addressbook]sync = two-way uri = addressbook backend = CardDAV # syncFormat = # forceSyncFormat = 0 database = https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ # databaseFormat = databaseUser = admin databasePassword = admin When I now initiate a sync I get: [INFO] syncevo-dbus-server: /org/syncevolution/Server: matched deviceID PN70M9J5V7JX against config palm-th55 at webdav (/root/.config/syncevolution/webdav/peers/palm-th55) [INFO] sync: /org/syncevolution/Session/15596840391389733215: calendar: inactive [INFO] sync: /org/syncevolution/Session/15596840391389733215: memo: inactive [INFO] sync: /org/syncevolution/Session/15596840391389733215: todo: inactive [INFO] sync: /org/syncevolution/Session/15596840391389733215: addressbook: starting first time sync, two-way (peer is client) [INFO] sync: /org/syncevolution/Session/15596840391389733215: creating complete data backup of source addressbook before sync (enabled with dumpData and needed for printChanges) [INFO] sync: /org/syncevolution/Session/15596840391389733215: Local data changes to be applied during synchronization: [INFO] sync: /org/syncevolution/Session/15596840391389733215: *** addressbook *** [INFO] sync: /org/syncevolution/Session/15596840391389733215: Comparison was impossible. [INFO] sync: /org/syncevolution/Session/15596840391389733215: [INFO] sync: /org/syncevolution/Session/15596840391389733215: addressbook: started [INFO] sync: /org/syncevolution/Session/15596840391389733215: adding "Jasmin Heinrich" [ERROR] sync: /org/syncevolution/Session/15596840391389733215: error code from SyncEvolution operation not allowed (remote, status 405): PUT: bad HTTP status: > >> When I try your combined command (I have to >> include SSLVerifyServer=False again to make it work) >> >> syncevolution --configure SSLVerifyServer=False \ >> --template SyncEvolution_Client \ >> remoteDeviceId=PN70M9J5V7JX username=admin password=admin \ >> sync=two-way \ >> databaseUser=admin \ >> databasePassword=admin \ >> backend=carddav \ >> database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ \ >> Palm-TH55 at webdav addressbook >> >> IT RETURNS >> >> "[INFO] addressbook: looking for databases... >> [INFO] addressbook: no database to synchronize >> [ERROR] addressbook: no database to synchronize" > > I can't reproduce the problem here, using SyncEvolution 1.3.99.6 plus > (probably irrelevant) patches. > > Which version of SyncEvolution are you using? Same version like you without patches. > > I can reproduce that the last step, adding a peer, will try to verify > databases again. But that works for me: > > $ ./syncevolution --configure --daemon=no databaseUser=test databasePassword=testing calendar/database=http://localhost:8009/caldav.php/test/Test_davical_caldav_1/ todo/database=http://localhost:8009/caldav.php/test/Test_davical_caldav_1/ addressbook/database=http://localhost:8009/caldav.php/test/Test_davical_carddav_1/ calendar/backend=caldav todo/backend=caldavtodo addressbook/backend=carddav @webdav addressbook calendar todo > [INFO] addressbook: looking for databases... > [INFO] addressbook: okay > [INFO] calendar: looking for databases... > [INFO] calendar: okay > [INFO] todo: looking for databases... > [INFO] todo: okay > $ ./syncevolution --daemon=no --configure --template SyncEvolution_Client sync=two-way remoteDeviceId=PN70M9J5V7JX username=admin password=admin foo at webdav addressbook > [INFO] addressbook: looking for databases... > [INFO] addressbook: okay > > So perhaps SSLVerifyServer simply doesn't get picked up in your case > where it is needed. > > Can you try this: > > SYNCEVOLUTION_DEBUG=1 syncevolution --configure SSLVerifyServer=False \ > --template SyncEvolution_Client \ > remoteDeviceId=PN70M9J5V7JX username=admin password=admin \ > loglevel=4 \ > sync=two-way \ > databaseUser=admin \ > databasePassword=admin \ > backend=carddav \ > database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ \ > Palm-TH55 at webdav addressbook > > It should show more information about the "[INFO] addressbook: no > database to synchronize" problem. > > -- > 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. > > The output of your suggested command above is (beneath I inserted the debugging output which I get for the split command version of yours with which I had come up before): root at srv:~/.config# SYNCEVOLUTION_DEBUG=1 syncevolution --configure SSLVerifyServer=False --template SyncEvolution_Client remoteDeviceId=PN70M9J5V7JX username=admin password=admin loglevel=4 sync=two-way databaseUser=admin databasePassword=admin backend=carddav database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ Palm-TH55 at webdav addressbook[INFO 00:00:00] addressbook: looking for databases... [DEBUG 00:00:00] checking password property 'databasePassword' in source 'addressbook' of config 'palm-th55 at webdav' with user identity 'admin' [DEBUG 00:00:00] using username 'admin' from source config for WebDAV, password was set [DEBUG 00:00:00] using plain username/password for admin [DEBUG 00:00:00] addressbook: timout 300s, retry 5s => resending allowed HTTP session to https://localhost:443 begins. [DEBUG 00:00:00] client cert is missing [DEBUG 00:00:00] testing /sabredav/addressbookserver.php/addressbooks/admin/ [DEBUG 00:00:00] debugging: read all WebDAV properties of /sabredav/addressbookserver.php/addressbooks/admin/ [DEBUG 00:00:00] starting PROPFIND, credentials unverified, no deadline ah_create, for WWW-Authenticate Running pre_send hooks Sending request headers: PROPFIND /sabredav/addressbookserver.php/addressbooks/admin/ HTTP/1.1 Keep-Alive: Connection: TE, Keep-Alive TE: trailers Host: localhost Depth: 0 Content-Length: 84 Content-Type: application/xml Sending request-line and headers: Doing DNS lookup on localhost... req: Connecting to ::1:443 [DEBUG 00:00:00] https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/: SSL verification problem: hostname mismatch, untrusted certificate [DEBUG 00:00:00] ignoring bad certificate Sending request body: Body block (84 bytes): [ ] Request sent; retry is 0. [status-line] < HTTP/1.1 401 Unauthorized [hdr] Date: Tue, 14 Jan 2014 21:12:49 GMT Header Name: [date], Value: [Tue, 14 Jan 2014 21:12:49 GMT] [hdr] Server: Apache Header Name: [server], Value: [Apache] [hdr] WWW-Authenticate: Digest realm="SabreDAV",qop="auth",nonce="52d5a852013e4",opaque="df58bdff8cf60599c939187d0b5c54de" Header Name: [www-authenticate], Value: [Digest realm="SabreDAV",qop="auth",nonce="52d5a852013e4",opaque="df58bdff8cf60599c939187d0b5c54de"] [hdr] Content-Length: 292 Header Name: [content-length], Value: [292] [hdr] Keep-Alive: timeout=5, max=100 Header Name: [keep-alive], Value: [timeout=5, max=100] [hdr] Connection: Keep-Alive Header Name: [connection], Value: [Keep-Alive] [hdr] Content-Type: application/xml; charset=utf-8 Header Name: [content-type], Value: [application/xml; charset=utf-8] [hdr] End of headers. Running post_headers hooks Reading 292 bytes of response body. Got 292 bytes. Read block (292 bytes): [ Sabre\DAV\Exception\NotAuthenticated No digest authentication headers were found 1.8.6 ] Running post_send hooks ah_post_send (#0), code is 401 (want 401), WWW-Authenticate is Digest realm="SabreDAV",qop="auth",nonce="52d5a852013e4",opaque="df58bdff8cf60599c939187d0b5c54de" auth: Got challenge (code 401). auth: Got 'Digest' challenge. auth: Trying Digest challenge... [DEBUG 00:00:00] retry request with credentials auth: Got qop, using 2617-style. auth: H(A1) is [87fd274b7b6c01e48d7c2f965da8ddf7] auth: Accepting digest challenge. auth: Accepted Digest challenge. Running pre_send hooks auth: Sending 'Digest' response. auth: H(A2): a21fa4f74b0a105f86364fa6154d8206 Sending request headers: PROPFIND /sabredav/addressbookserver.php/addressbooks/admin/ HTTP/1.1 Keep-Alive: Connection: TE, Keep-Alive TE: trailers Host: localhost Depth: 0 Content-Length: 84 Content-Type: application/xml Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Sending request-line and headers: Sending request body: Body block (84 bytes): [ ] Request sent; retry is 1. [status-line] < HTTP/1.1 207 Multi-Status [hdr] Date: Tue, 14 Jan 2014 21:12:50 GMT Header Name: [date], Value: [Tue, 14 Jan 2014 21:12:50 GMT] [hdr] Server: Apache Header Name: [server], Value: [Apache] [hdr] Vary: Brief,Prefer Header Name: [vary], Value: [Brief,Prefer] [hdr] DAV: 1, 3, extended-mkcol, addressbook, access-control, calendarserver-principal-property-search Header Name: [dav], Value: [1, 3, extended-mkcol, addressbook, access-control, calendarserver-principal-property-search] [hdr] Content-Length: 382 Header Name: [content-length], Value: [382] [hdr] Keep-Alive: timeout=5, max=99 Header Name: [keep-alive], Value: [timeout=5, max=99] [hdr] Connection: Keep-Alive Header Name: [connection], Value: [Keep-Alive] [hdr] Content-Type: application/xml; charset=utf-8 Header Name: [content-type], Value: [application/xml; charset=utf-8] [hdr] End of headers. Running post_headers hooks Reading 382 bytes of response body. Got 382 bytes. Read block (382 bytes): [ /sabredav/addressbookserver.php/addressbooks/admin/HTTP/1.1 200 OK ] Running post_send hooks ah_post_send (#1), code is 207 (want 401), WWW-Authenticate is (none) Request ends, status 207 class 2xx, error line: 207 Multi-Status [DEBUG 00:00:00] credentials accepted Running destroy hooks. Request ends. [DEBUG 00:00:00] read relevant properties of /sabredav/addressbookserver.php/addressbooks/admin/ [DEBUG 00:00:00] starting PROPFIND, credentials okay, deadline in 299.9s ah_create, for WWW-Authenticate Running pre_send hooks auth: Sending 'Digest' response. auth: H(A2): a21fa4f74b0a105f86364fa6154d8206 [DEBUG 00:00:00] forced sending credentials Sending request headers: PROPFIND /sabredav/addressbookserver.php/addressbooks/admin/ HTTP/1.1 Connection: TE TE: trailers Host: localhost Depth: 0 Content-Length: 628 Content-Type: application/xml Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Sending request-line and headers: Sending request body: Body block (628 bytes): [ ] Request sent; retry is 1. [status-line] < HTTP/1.1 207 Multi-Status [hdr] Date: Tue, 14 Jan 2014 21:12:50 GMT Header Name: [date], Value: [Tue, 14 Jan 2014 21:12:50 GMT] [hdr] Server: Apache Header Name: [server], Value: [Apache] [hdr] Vary: Brief,Prefer Header Name: [vary], Value: [Brief,Prefer] [hdr] DAV: 1, 3, extended-mkcol, addressbook, access-control, calendarserver-principal-property-search Header Name: [dav], Value: [1, 3, extended-mkcol, addressbook, access-control, calendarserver-principal-property-search] [hdr] Content-Length: 823 Header Name: [content-length], Value: [823] [hdr] Content-Type: application/xml; charset=utf-8 Header Name: [content-type], Value: [application/xml; charset=utf-8] [hdr] End of headers. Running post_headers hooks Reading 823 bytes of response body. Got 823 bytes. Read block (823 bytes): [ /sabredav/addressbookserver.php/addressbooks/admin//sabredav/addressbookserver.php/principals/admin/HTTP/1.1 200 OKHTTP/1.1 404 Not Found ] Running post_send hooks ah_post_send (#0), code is 207 (want 401), WWW-Authenticate is (none) Request ends, status 207 class 2xx, error line: 207 Multi-Status [DEBUG 00:00:00] credentials accepted Running destroy hooks. Request ends. [DEBUG 00:00:00] follow current-user-prinicipal to /sabredav/addressbookserver.php/principals/admin/ [DEBUG 00:00:00] testing /sabredav/addressbookserver.php/principals/admin/ [DEBUG 00:00:00] debugging: read all WebDAV properties of /sabredav/addressbookserver.php/principals/admin/ [DEBUG 00:00:00] starting PROPFIND, credentials okay, no deadline ah_create, for WWW-Authenticate Running pre_send hooks auth: Sending 'Digest' response. auth: H(A2): e802051c2a3c9c0bc6064e32d800a784 Sending request headers: PROPFIND /sabredav/addressbookserver.php/principals/admin/ HTTP/1.1 Connection: TE TE: trailers Host: localhost Depth: 0 Content-Length: 84 Content-Type: application/xml Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Sending request-line and headers: Sending request body: Body block (84 bytes): [ ] Request sent; retry is 1. [status-line] < HTTP/1.1 207 Multi-Status [hdr] Date: Tue, 14 Jan 2014 21:12:50 GMT Header Name: [date], Value: [Tue, 14 Jan 2014 21:12:50 GMT] [hdr] Server: Apache Header Name: [server], Value: [Apache] [hdr] Vary: Brief,Prefer Header Name: [vary], Value: [Brief,Prefer] [hdr] DAV: 1, 3, extended-mkcol, addressbook, access-control, calendarserver-principal-property-search Header Name: [dav], Value: [1, 3, extended-mkcol, addressbook, access-control, calendarserver-principal-property-search] [hdr] Content-Length: 447 Header Name: [content-length], Value: [447] [hdr] Content-Type: application/xml; charset=utf-8 Header Name: [content-type], Value: [application/xml; charset=utf-8] [hdr] End of headers. Running post_headers hooks Reading 447 bytes of response body. Got 447 bytes. Read block (447 bytes): [ /sabredav/addressbookserver.php/principals/admin/Tue, 14 Jan 2014 21:12:50 GMTHTTP/1.1 200 OK ] Running post_send hooks ah_post_send (#0), code is 207 (want 401), WWW-Authenticate is (none) Request ends, status 207 class 2xx, error line: 207 Multi-Status Running destroy hooks. Request ends. [DEBUG 00:00:00] read relevant properties of /sabredav/addressbookserver.php/principals/admin/ [DEBUG 00:00:00] starting PROPFIND, credentials okay, deadline in 299.8s ah_create, for WWW-Authenticate Running pre_send hooks auth: Sending 'Digest' response. auth: H(A2): e802051c2a3c9c0bc6064e32d800a784 [DEBUG 00:00:00] forced sending credentials Sending request headers: PROPFIND /sabredav/addressbookserver.php/principals/admin/ HTTP/1.1 Connection: TE TE: trailers Host: localhost Depth: 0 Content-Length: 628 Content-Type: application/xml Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Sending request-line and headers: Sending request body: Body block (628 bytes): [ ] Request sent; retry is 1. [status-line] < HTTP/1.1 207 Multi-Status [hdr] Date: Tue, 14 Jan 2014 21:12:50 GMT Header Name: [date], Value: [Tue, 14 Jan 2014 21:12:50 GMT] [hdr] Server: Apache Header Name: [server], Value: [Apache] [hdr] Vary: Brief,Prefer Header Name: [vary], Value: [Brief,Prefer] [hdr] DAV: 1, 3, extended-mkcol, addressbook, access-control, calendarserver-principal-property-search Header Name: [dav], Value: [1, 3, extended-mkcol, addressbook, access-control, calendarserver-principal-property-search] [hdr] Content-Length: 1120 Header Name: [content-length], Value: [1120] [hdr] Content-Type: application/xml; charset=utf-8 Header Name: [content-type], Value: [application/xml; charset=utf-8] [hdr] End of headers. Running post_headers hooks Reading 1120 bytes of response body. Got 1120 bytes. Read block (1120 bytes): [ /sabredav/addressbookserver.php/principals/admin//sabredav/addressbookserver.php/addressbooks/admin//sabredav/addressbookserver.php/mailto:admin at example.org/sabredav/addressbookserver.php/principals/admin/Administrator/sabredav/addressbookserver.php/principals/admin/HTTP/1.1 200 OKHTTP/1.1 404 Not Found ] Running post_send hooks ah_post_send (#0), code is 207 (want 401), WWW-Authenticate is (none) Request ends, status 207 class 2xx, error line: 207 Multi-Status [DEBUG 00:00:00] credentials accepted Running destroy hooks. Request ends. [INFO 00:00:00] addressbook: no database to synchronize [ERROR 00:00:00] addressbook: no database to synchronize sess: Destroying session. Your suggested command above results in a "no configuration found for deviceID" like before when I initiate a sync afterwards (no surprise of course as you just added the debugging options). ################ ################ Using these two commands like in my previous mail (split version of your combined command version) syncevolution --configure databaseUser=admin "databasePassword=admin" addressbook/backend=carddav addressbook/database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ @webdav addressbook and SYNCEVOLUTION_DEBUG=1 syncevolution --configure SSLVerifyServer=False --template SyncEvolution_Client --sync-property remoteDeviceId=PN70M9J5V7JX username=admin password=admin --source-property addressbook/uri=addressbook sync=two-way Palm-TH55 at webdav addressbook the debugging output looks like this: root at srv:~/.config# SYNCEVOLUTION_DEBUG=1 syncevolution --configure SSLVerifyServer=False --template SyncEvolution_Client --sync-property remoteDeviceId=PN70M9J5V7JX username=admin password=admin --source-property addressbook/uri=addressbook sync=two-way Palm-TH55 at webdav addressbook [INFO 00:00:00] addressbook: looking for databases... [DEBUG 00:00:00] checking password property 'databasePassword' in source 'addressbook' of config 'palm-th55 at webdav' with user identity 'admin' [DEBUG 00:00:00] using username 'admin' from source config for WebDAV, password was set [DEBUG 00:00:00] using plain username/password for admin [DEBUG 00:00:00] addressbook: timout 300s, retry 5s => resending allowed [DEBUG 00:00:00] client cert is missing [DEBUG 00:00:00] testing /sabredav/addressbookserver.php/addressbooks/admin/ [DEBUG 00:00:00] debugging: read all WebDAV properties of /sabredav/addressbookserver.php/addressbooks/admin/ [DEBUG 00:00:00] starting PROPFIND, credentials unverified, no deadline [DEBUG 00:00:00] https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/: SSL verification problem: hostname mismatch, untrusted certificate [DEBUG 00:00:00] ignoring bad certificate [DEBUG 00:00:00] retry request with credentials [DEBUG 00:00:00] credentials accepted [DEBUG 00:00:00] read relevant properties of /sabredav/addressbookserver.php/addressbooks/admin/ [DEBUG 00:00:00] starting PROPFIND, credentials okay, deadline in 299.9s [DEBUG 00:00:00] forced sending credentials [DEBUG 00:00:00] credentials accepted [DEBUG 00:00:00] follow current-user-prinicipal to /sabredav/addressbookserver.php/principals/admin/ [DEBUG 00:00:00] testing /sabredav/addressbookserver.php/principals/admin/ [DEBUG 00:00:00] debugging: read all WebDAV properties of /sabredav/addressbookserver.php/principals/admin/ [DEBUG 00:00:00] starting PROPFIND, credentials okay, no deadline [DEBUG 00:00:00] read relevant properties of /sabredav/addressbookserver.php/principals/admin/ [DEBUG 00:00:00] starting PROPFIND, credentials okay, deadline in 299.8s [DEBUG 00:00:00] forced sending credentials [DEBUG 00:00:00] credentials accepted [INFO 00:00:00] addressbook: no database to synchronize [ERROR 00:00:00] addressbook: no database to synchronize When initiate a sync I also get the "no configuration found for deviceID" error as stated in my previous mail. ##################### ##################### Last but not least I also tried the same two commands again but without "addressbook" at the end of the second command (as I also already did before in my previous mail) syncevolution --configure databaseUser=admin "databasePassword=admin" addressbook/backend=carddav addressbook/database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ @webdav addressbook and SYNCEVOLUTION_DEBUG=1 syncevolution --configure SSLVerifyServer=False --template SyncEvolution_Client --sync-property remoteDeviceId=PN70M9J5V7JX username=admin password=admin --source-property addressbook/uri=addressbook sync=two-way Palm-TH55 at webdav the debugging output looks like this: root at srv:~/.config# SYNCEVOLUTION_DEBUG=1 syncevolution --configure SSLVerifyServer=False --template SyncEvolution_Client --sync-property remoteDeviceId=PN70M9J5V7JX username=admin password=admin --source-property addressbook/uri=addressbook sync=two-way Palm-TH55 at webdav [INFO 00:00:00] addressbook: looking for databases... [DEBUG 00:00:00] checking password property 'databasePassword' in source 'addressbook' of config 'palm-th55 at webdav' with user identity 'admin' [DEBUG 00:00:00] using username 'admin' from source config for WebDAV, password was set [DEBUG 00:00:00] using plain username/password for admin [DEBUG 00:00:00] addressbook: timout 300s, retry 5s => resending allowed [DEBUG 00:00:00] client cert is missing [DEBUG 00:00:00] testing /sabredav/addressbookserver.php/addressbooks/admin/ [DEBUG 00:00:00] debugging: read all WebDAV properties of /sabredav/addressbookserver.php/addressbooks/admin/ [DEBUG 00:00:00] starting PROPFIND, credentials unverified, no deadline [DEBUG 00:00:00] https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/: SSL verification problem: hostname mismatch, untrusted certificate [DEBUG 00:00:00] ignoring bad certificate [DEBUG 00:00:00] retry request with credentials [DEBUG 00:00:00] credentials accepted [DEBUG 00:00:00] read relevant properties of /sabredav/addressbookserver.php/addressbooks/admin/ [DEBUG 00:00:00] starting PROPFIND, credentials okay, deadline in 299.7s [DEBUG 00:00:00] forced sending credentials [DEBUG 00:00:00] credentials accepted [DEBUG 00:00:00] follow current-user-prinicipal to /sabredav/addressbookserver.php/principals/admin/ [DEBUG 00:00:00] testing /sabredav/addressbookserver.php/principals/admin/ [DEBUG 00:00:00] debugging: read all WebDAV properties of /sabredav/addressbookserver.php/principals/admin/ [DEBUG 00:00:00] starting PROPFIND, credentials okay, no deadline [DEBUG 00:00:00] read relevant properties of /sabredav/addressbookserver.php/principals/admin/ [DEBUG 00:00:00] starting PROPFIND, credentials okay, deadline in 299.7s [DEBUG 00:00:00] forced sending credentials [DEBUG 00:00:00] credentials accepted [INFO 00:00:00] addressbook: no database to synchronize [INFO 00:00:00] calendar: looking for databases... [DEBUG 00:00:00] checking password property 'databasePassword' in source 'calendar' of config 'palm-th55 at webdav' with user identity '' [DEBUG 00:00:00] using username 'admin' from source context for WebDAV, password was set [DEBUG 00:00:00] using plain username/password for admin [DEBUG 00:00:00] calendar: timout 300s, retry 5s => resending allowed [DEBUG 00:00:00] exception thrown at /data/runtests/work/sources/syncevolution/src/syncevo/SyncContext.cpp:2113 [DEBUG 00:00:00] error code from SyncEvolution authorization failed (remote, status 401): calendar: syncURL not configured and username admin does not contain a domain [INFO 00:00:00] calendar: backend failed: error code from SyncEvolution authorization failed (remote, status 401): calendar: syncURL not configured and username admin does not contain a domain [INFO 00:00:00] memo: looking for databases... [DEBUG 00:00:00] checking password property 'databasePassword' in source 'memo' of config 'palm-th55 at webdav' with user identity '' [DEBUG 00:00:00] using username 'admin' from source context for WebDAV, password was set [DEBUG 00:00:00] using plain username/password for admin [DEBUG 00:00:00] memo: timout 300s, retry 5s => resending allowed [DEBUG 00:00:00] exception thrown at /data/runtests/work/sources/syncevolution/src/syncevo/SyncContext.cpp:2113 [DEBUG 00:00:00] error code from SyncEvolution authorization failed (remote, status 401): memo: syncURL not configured and username admin does not contain a domain [INFO 00:00:00] memo: backend failed: error code from SyncEvolution authorization failed (remote, status 401): memo: syncURL not configured and username admin does not contain a domain [INFO 00:00:00] todo: looking for databases... [DEBUG 00:00:00] checking password property 'databasePassword' in source 'todo' of config 'palm-th55 at webdav' with user identity '' [DEBUG 00:00:00] using username 'admin' from source context for WebDAV, password was set [DEBUG 00:00:00] using plain username/password for admin [DEBUG 00:00:00] todo: timout 300s, retry 5s => resending allowed [DEBUG 00:00:00] exception thrown at /data/runtests/work/sources/syncevolution/src/syncevo/SyncContext.cpp:2113 [DEBUG 00:00:00] error code from SyncEvolution authorization failed (remote, status 401): todo: syncURL not configured and username admin does not contain a domain [INFO 00:00:00] todo: backend failed: error code from SyncEvolution authorization failed (remote, status 401): todo: syncURL not configured and username admin does not contain a domain [DEBUG 00:00:00] possibly saving password property 'password' in config 'palm-th55 at webdav' with user identity 'admin' [DEBUG 00:00:00] saving password in keyring with key user=admin server=PN70M9J5V7JX [DEBUG 00:00:00] not using GNOME keyring [DEBUG 00:00:00] possibly saving password property 'databasePassword' in source 'addressbook' of config 'palm-th55 at webdav' with user identity 'admin' [DEBUG 00:00:00] saving password in keyring with key user=admin object=@webdav addressbook backend [DEBUG 00:00:00] not using GNOME keyring When initiate a sync now I get "First ERROR encountered: error code from SyncEvolution fatal error (local, status 10500): no sources active, check configuration". This is also the expected same error message as in my previously described attempt with the same commands. -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Wed Jan 15 09:34:44 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 15 Jan 2014 10:34:44 +0100 Subject: [SyncEvolution] Setup of SyncML to WebDAV synchronization bridge: Problem with SSLVerifyServer switch in configuration command In-Reply-To: References: <1389600679.5855.404.camel@pohly-mobl1.fritz.box> <52D4BEF3.4080101@kraak.info> <1389684576.19530.7.camel@pohly-mobl1.fritz.box> <52D522EE.6040606@kraak.info> <1389702191.19530.15.camel@pohly-mobl1.fritz.box> <1389709941.16995.20.camel@pohly-mobl1.fritz.box> Message-ID: <1389778484.16995.72.camel@pohly-mobl1.fritz.box> On Tue, 2014-01-14 at 22:43 +0100, Helge Kraak wrote: > Am 14.01.2014 um 15:32 schrieb Patrick Ohly: > > > On Tue, 2014-01-14 at 14:25 +0100, Helge Kraak wrote: > > > When I apply as third command (no addressbook at the end of the > > > command) > > > > > > syncevolution --configure SSLVerifyServer=False > > > --template SyncEvolution_Client --sync-property > > > remoteDeviceId=ST23K3J5I4JX username=admin > > > password=admin --source-property addressbook/uri=addressbook > > > sync=two-way Palm-TH55 at webdav > > > > > > the command > > > > > > syncevolution --print-config -q @webdav addressbook > > > > > > RETURNS: > > > > > > "[addressbook] > > > backend = CardDAV > > > database = > > > https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ > > > # databaseFormat = > > > databaseUser = admin > > > databasePassword = admin" > > > > When you show the config of addressbook for the Palm-TH55 peer, is > > the > > "sync" property set? In other words, what do you get from: > > syncevolution --print-config -q Palm-TH55 at webdav addressbook > > > > > [addressbook] > sync = disabled [...] > [addressbook] > sync = two-way [...] > > When I now initiate a sync I get: > > > [INFO] syncevo-dbus-server: /org/syncevolution/Server: matched > deviceID PN70M9J5V7JX against config palm-th55 at webdav > (/root/.config/syncevolution/webdav/peers/palm-th55) Okay, so it is as I thought - configuring unnecessarily/incorrectly checks the source datatabase again and then fails to set the "sync" property because it believes the source to be unusable. I briefly considered disabling that check, but I think it is necessary: otherwise users choosing a template may end up with a sync config which has more sources enabled than possible in the context. The check has to work, of course. > [INFO] sync: /org/syncevolution/Session/15596840391389733215: > addressbook: started > [INFO] sync: /org/syncevolution/Session/15596840391389733215: adding > "Jasmin Heinrich" > [ERROR] sync: /org/syncevolution/Session/15596840391389733215: error > code from SyncEvolution operation not allowed (remote, status 405): > PUT: bad HTTP status: Allowed> So that's another issue to look at. You don't need a SyncML client for it, just use "--import @webdav addressvbook". For debugging purposes, use "SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 --import ...". That'll show the actual WebDAV commands. The SabreDAV server log may also have additional information. > The output of your suggested command above is (beneath I inserted the > debugging output which I get for the split command version of yours > with which I had come up before): > > > root at srv:~/.config# SYNCEVOLUTION_DEBUG=1 syncevolution --configure > SSLVerifyServer=False --template SyncEvolution_Client > remoteDeviceId=PN70M9J5V7JX username=admin password=admin loglevel=4 > sync=two-way databaseUser=admin databasePassword=admin backend=carddav > database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ Palm-TH55 at webdav addressbook[INFO 00:00:00] addressbook: looking for databases... > [DEBUG 00:00:00] checking password property 'databasePassword' in > source 'addressbook' of config 'palm-th55 at webdav' with user identity > 'admin' > [DEBUG 00:00:00] using username 'admin' from source config for WebDAV, > password was set > [DEBUG 00:00:00] using plain username/password for admin > [DEBUG 00:00:00] addressbook: timout 300s, retry 5s => resending > allowed > HTTP session to https://localhost:443 begins. > [DEBUG 00:00:00] client cert is missing [...] > [DEBUG 00:00:00] > https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/: SSL verification problem: hostname mismatch, untrusted certificate > [DEBUG 00:00:00] ignoring bad certificate Okay, so SSLVerifyServer=False is working. The URL is the configured one, too. > [DEBUG 00:00:00] read relevant properties > of /sabredav/addressbookserver.php/addressbooks/admin/ This is checking whether that URL actually is a CardDAV address book. > [ > xmlns:card="urn:ietf:params:xml:ns:carddav">/sabredav/addressbookserver.php/addressbooks/admin//sabredav/addressbookserver.php/principals/admin/HTTP/1.1 200 OKHTTP/1.1 404 Not Found > ] And it turns out it isn't (none of the CardDAV properties are set). It's a normal collection. However, and that is the real problem, SyncEvolution doesn't check the content of the collection. If it did, it would list its content and find the actual address book(s) ("list items in ..."). Instead, the next step then is to check out the principal (= current user) and see where its address books are (addressbook-home-set), but that leads us just back to that same URL. > [DEBUG 00:00:00] read relevant properties > of /sabredav/addressbookserver.php/principals/admin/ [...] > [ > xmlns:card="urn:ietf:params:xml:ns:carddav">/sabredav/addressbookserver.php/principals/admin//sabredav/addressbookserver.php/addressbooks/admin//sabredav/addressbookserver.php/mailto:admin at example.org/sabredav/addressbookserver.php/principals/admin/Administrator/sabredav/addressbookserver.php/principals/admin/HTTP/1.1 200 OKHTTP/1.1 404 Not Found > ] It turns out, we were already looking at the URL under which the address books are to be found. Because we already looked there, SyncEvolution doesn't look again and gives up. Where did the database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ URL come from? Was it the result of a database discovery done by SyncEvolution? You can do that discovery without any config with: syncevolution --print-databases \ backend=carddav \ syncURL=https://localhost:443/sabredav/ \ username=admin \ password=.... \ SSLVerifyServer=False I expect that to fail, too, but it'll be easier to debug. How comfortable are you using gdb and/or compiling from source? I can't reproduce the problem with DAViCal, but I see a relevant difference (DAViCal doesn't have a separate principal URL, so instead of following that, SyncEvolution lists the content right away). If my hunch is right, then uncommenting the "next.empty()" clause in an if check in src/backends/webdav/WebDAV.cpp should fix it: // finally, recursively descend into collections, // unless we identified it as a result (because those // cannot be recursive) if (/* next.empty() && */ !isResult) { // ^^^^^^^^^^^^^^^^^^ std::string type; if (props) { type = (*props)["DAV::resourcetype"]; } if (type.find("") != type.npos) { -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From patrick.ohly at intel.com Wed Jan 22 11:24:34 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 22 Jan 2014 12:24:34 +0100 Subject: [SyncEvolution] Setup of SyncML to WebDAV synchronization bridge: Problem with SSLVerifyServer switch in configuration command In-Reply-To: <1389778484.16995.72.camel@pohly-mobl1.fritz.box> References: <1389600679.5855.404.camel@pohly-mobl1.fritz.box> <52D4BEF3.4080101@kraak.info> <1389684576.19530.7.camel@pohly-mobl1.fritz.box> <52D522EE.6040606@kraak.info> <1389702191.19530.15.camel@pohly-mobl1.fritz.box> <1389709941.16995.20.camel@pohly-mobl1.fritz.box> <1389778484.16995.72.camel@pohly-mobl1.fritz.box> Message-ID: <1390389874.30349.14.camel@pohly-mobl1.fritz.box> On Wed, 2014-01-15 at 10:34 +0100, Patrick Ohly wrote: > On Tue, 2014-01-14 at 22:43 +0100, Helge Kraak wrote: > > > [INFO] sync: /org/syncevolution/Session/15596840391389733215: > > addressbook: started > > [INFO] sync: /org/syncevolution/Session/15596840391389733215: adding > > "Jasmin Heinrich" > > [ERROR] sync: /org/syncevolution/Session/15596840391389733215: error > > code from SyncEvolution operation not allowed (remote, status 405): > > PUT: bad HTTP status: > Allowed> > > So that's another issue to look at. You don't need a SyncML client for > it, just use "--import @webdav addressvbook". For debugging > purposes, use "SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no > loglevel=4 --import ...". Actually, this error is not surprising. As I noticed later while replying to your email, database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ is not correct, so the server correctly refuses to create contacts there. That's another argument in favor of keeping the check during --configure, because it correctly prevented enabling a source with a broken config. Arguably the error messages have to become better. I just don't know how. Suggestions welcome... > > [ > > > xmlns:card="urn:ietf:params:xml:ns:carddav">/sabredav/addressbookserver.php/principals/admin//sabredav/addressbookserver.php/addressbooks/admin//sabredav/addressbookserver.php/mailto:admin at example.org/sabredav/addressbookserver.php/principals/admin/Administrator/sabredav/addressbookserver.php/principals/admin/HTTP/1.1 200 OKHTTP/1.1 404 Not Found > > ] > > It turns out, we were already looking at the URL under which the address > books are to be found. Because we already looked there, SyncEvolution > doesn't look again and gives up. > > Where did the > database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ URL come from? Was it the result of a database discovery done by SyncEvolution? [...] > If my hunch is right, then uncommenting the "next.empty()" clause in an > if check in src/backends/webdav/WebDAV.cpp should fix it: > > // finally, recursively descend into collections, > // unless we identified it as a result (because those > // cannot be recursive) > if (/* next.empty() && */ !isResult) { > // ^^^^^^^^^^^^^^^^^^ > std::string type; > if (props) { > type = (*props)["DAV::resourcetype"]; > } > if (type.find("") != type.npos) { It's not that easy. The "next.empty()" plays a crucial role when scanning a WebDAV server starting with just the server URL (= http://example.com/). In that case, we want to go to the principal first instead of recursively listing all folders on the server. So the solution in your case might be simple: don't use database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ Instead use "syncURL=https://localhost:443/sabredav/" or perhaps even just "syncURL=https://localhost:443" (if the web server has either .well-known or principal support at the root). Please let me know whether --print-databases with that SyncURL works. -- 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 helge at kraak.info Tue Jan 14 04:40:12 2014 From: helge at kraak.info (Helge Kraak) Date: Tue, 14 Jan 2014 05:40:12 +0100 Subject: [SyncEvolution] Setup of SyncML to WebDAV synchronization bridge: Problem with SSLVerifyServer switch in configuration command In-Reply-To: <1389600679.5855.404.camel@pohly-mobl1.fritz.box> References: <1389600679.5855.404.camel@pohly-mobl1.fritz.box> Message-ID: <52D4BFAC.4010102@kraak.info> Thank you very much for your explanations, Patrick. Following your advices I think I'm (hopefully) close to having a correct configuration. Starting from an empty syncevolution configuration I apply the following commands: *### First command**###* syncevolution --configure \ *keyring=no* *SSLVerifyServer=False* \ --template webdav syncURL=https://localhost:443/sabredav/addressbookserver.php/ \ username=admin password=admin \ target-config at webdav RETURNS: [INFO] addressbook: looking for databases... [INFO] addressbook: okay [INFO] calendar: looking for databases... [INFO] calendar: no database to synchronize [INFO] memo: looking for databases... [INFO] memo: no database to synchronize [INFO] todo: looking for databases... [INFO] todo: no database to synchronize This is the expected output because on the WebDAV server I have only set up an address book so far. *### Second command ###* syncevolution --configure \ databaseUser=admin \ "databasePassword=admin" \ addressbook/backend=carddav \ addressbook/database=*https://localhost:443/sabredav/addressbookserver.php/*addressbooks/admin/ \ @webdav addressbook *### Third command ###* /syncevolution --configure /* keyring=no**SSLVerifyServer=False *--template**SyncEvolution_Client/ --sync-property remoteDeviceId=/ST23K3J5I4JX/ username=admin password=admin / --source-property addressbook/uri=addressbook --source-property calendar/uri=events --source-property todo/uri=tasks --source-property memo/uri=memo Palm-TH55 at webdav RETURNS: [INFO] addressbook: looking for databases... [INFO] addressbook: no database to synchronize [INFO] calendar: looking for databases... [INFO] calendar: backend failed: error code from SyncEvolution authorization failed (remote, status 401): calendar: syncURL not configured and username admin does not contain a domain [INFO] memo: looking for databases... [INFO] memo: backend failed: error code from SyncEvolution authorization failed (remote, status 401): memo: syncURL not configured and username admin does not contain a domain [INFO] todo: looking for databases... [INFO] todo: backend failed: error code from SyncEvolution authorization failed (remote, status 401): todo: syncURL not configured and username admin does not contain a domain Here I'm stuck. What am I missing so that the database on at the WebDAV server cannot be found? Thanks. Helge On 1/13/14 9:11 AM, Patrick Ohly wrote: > On Sun, 2014-01-12 at 03:55 +0100, Helge Kraak wrote: >> Hi, >> >> during my journey of setting up a synchronization of a Palm Tungsten >> TX running the Synthesis SyncML application and a SabreDAV server I >> tried the following configuration command adapted from the >> syncevolution manual: >> >> syncevolution --configure \ >> >> SSLVerifyServer=False \ >> >> databaseUser=admin \ >> >> "databasePassword=admin" \ >> >> addressbook/backend=carddav \ >> >> >> addressbook/database=https://localhost:443/sabredav/addressbookserver.php/ \ >> >> calendar/backend=caldav \ >> >> >> calendar/database=https://localhost:443/sabredav/addressbookserver.php/ \ >> >> @webdav \ >> >> calendar addressbook >> >> >> >> It returns this error message: >> >> [ERROR 00:00:00] per-peer (unshared) properties not allowed: >> SSLVerifyServer >> >> With other configuration commands not dealing with this specific >> SyncML - WebDAV setup I can use this switch. > Configure options are applied to what is mentioned as target of the > configuration change. In this case, that are four things: > 1. The @webdav context = ~/.config/syncevolution/webdav/config.ini > 2. The calendar source in that context = > ~/.config/syncevolution/webdav/sources/calendar/config.ini > 3. The addressbook source in that context = > ~/.config/syncevolution/webdav/sources/addressbook/config.ini > 4. The global config = ~/.config/syncevolution/config.ini > > The last one is a somewhat unfortunate special case; only very few > options go into it, so typically it doesn't get changed. > > In you case, SSLVerifyServer cannot be set in any of these places. > Instead of silently ignoring it, you get the error. What you can do is > set SSLVerifyServer in the sync config for the Palm. It'll be picked up > from there by the backend. > > Not very intuitive, I know, and might even lead to potential conflicts > (what if the option has some meaning there different from what the > source expects?). I just don't have a good solution. > > One solution would be to have databaseSSLVerify* options which can go > into the source configs. But that's leading to a further proliferation > of similar options. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emiliano.heyns at iris-advies.com Tue Jan 7 23:49:42 2014 From: emiliano.heyns at iris-advies.com (Emiliano Heyns) Date: Tue, 7 Jan 2014 23:49:42 +0000 Subject: [SyncEvolution] Syncing two servers References: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> <1387361516.5855.139.camel@pohly-mobl1.fritz.box> <1387390427.5855.157.camel@pohly-mobl1.fritz.box> Message-ID: Patrick Ohly writes: > I see. The package dependencies aren't defined correctly in the package, > libebook-1.2-14 is also acceptable but not listed. FWIW, I already > revised the automated testing the last view days. It now includes real > install tests of these packages. I'm not with it yet, so I haven't > actually seen the results for Saucy (= 13.10), but I expect I'll see the > same failure as you did. > > Anyway, you can install with "aptitude install syncevolution-bundle". > That installs the same package, without enforcing dependencies on > Evolution. The resulting binaries will then work with EDS 3.8 (that's > something that I had tested when releasing 1.3.99.6). Has any progress been made in this domain? I'm looking to use a setup like this to sync my work (Exchange 2010SP2) calendar with my personal (Google calendar). Preferably I'd use ActiveSync (or EWS) on the Exchange side and CalDav on the Google side, but have a running davmail instance that mostly works with Exchange which I could use to do DAV-DAV sync. Thanks, Emile _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Jan 8 15:10:50 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 08 Jan 2014 16:10:50 +0100 Subject: [SyncEvolution] Syncing two servers In-Reply-To: References: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> <1387361516.5855.139.camel@pohly-mobl1.fritz.box> <1387390427.5855.157.camel@pohly-mobl1.fritz.box> Message-ID: <1389193850.5855.318.camel@pohly-mobl1.fritz.box> On Tue, 2014-01-07 at 23:49 +0000, Emiliano Heyns wrote: > Patrick Ohly writes: > > > I see. The package dependencies aren't defined correctly in the package, > > libebook-1.2-14 is also acceptable but not listed. FWIW, I already > > revised the automated testing the last view days. It now includes real > > install tests of these packages. I'm not with it yet, so I haven't > > actually seen the results for Saucy (= 13.10), but I expect I'll see the > > same failure as you did. > > > > Anyway, you can install with "aptitude install syncevolution-bundle". > > That installs the same package, without enforcing dependencies on > > Evolution. The resulting binaries will then work with EDS 3.8 (that's > > something that I had tested when releasing 1.3.99.6). > > Has any progress been made in this domain? Todd is still working though the various instructions. I helped him with some issues in a private email discussion - nothing major, just some ambiguities around how to do certain operations. The package install testing is done, so 1.3.99.7 should not have the install issues that Todd ran into. Another issue on OpenSUSE was also reported recently (https://bugs.freedesktop.org/show_bug.cgi?id=73347) - I still need to fix that. -- 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 Jan 2 08:37:06 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 02 Jan 2014 09:37:06 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1380634455.5818.13.camel@pohly-mobl1.fritz.box> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> Message-ID: <1388651826.5855.243.camel@pohly-mobl1.fritz.box> On Tue, 2013-10-01 at 15:34 +0200, Patrick Ohly wrote: > On Tue, 2013-10-01 at 15:24 +0200, Daniel CLEMENT wrote: > > Hmm... Partially answering to myself, it seems to be a dependency issue. > > > > Evolution 3.8 wants (and installs as dependency) libebook-1.2-14. > > > > Syncevolution then complains that libebook-1.2-13 is missing and not > > installable, whereas it should be content with version 1.2-14 (?) > > No, these two versions of libebook are incompatible. There have been > considerable API changes between 3.4 and 3.6. For the sake of those landing in this mail thread via search engines: the syncevolution-bundle package >= 1.3.99.6 works with old (< 3.6) and new EDS (>= 3.6) versions. There was a bug in the syncevolution-eds 1.3.99.6 meta data which prevents installing it with EDS >= 3.6; just install the bundle, it has the necessary binaries. This will be fixed (and covered by automated tests) in SyncEvolution > 1.3.99.6. -- 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 Sat Jan 18 09:40:00 2014 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Sat, 18 Jan 2014 09:40:00 +0000 Subject: [SyncEvolution] Compiling syncevolution on Debian jessie Message-ID: <52DA4BF0.4050108@cobb.uk.net> I am trying to update my syncevolution and activesyncd build environment, which I haven't touched for a while. I updated syncevolution (git pull) and tried to build it. I am getting errors because sysync::LOCERR_AGAIN is not defined. What version of synthesis is required to build the latest syncevolution? The version of libsynthesis currently in Debian Jessie is 3.4.0.16.8-1. Graham _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sat Jan 18 19:09:40 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sat, 18 Jan 2014 20:09:40 +0100 Subject: [SyncEvolution] Compiling syncevolution on Debian jessie In-Reply-To: <52DA4BF0.4050108@cobb.uk.net> References: <52DA4BF0.4050108@cobb.uk.net> Message-ID: <1390072180.21270.8.camel@pohly-mobl1.fritz.box> On Sat, 2014-01-18 at 09:40 +0000, Graham Cobb wrote: > I am trying to update my syncevolution and activesyncd build > environment, which I haven't touched for a while. > > I updated syncevolution (git pull) and tried to build it. I am getting > errors because sysync::LOCERR_AGAIN is not defined. Which version of SyncEvolution are you trying to compile? Usually I try to remember to bump the libsynthesis version and add a configure check for that in SyncEvolution; I must have forgotten that in the version you are compiling. > What version of synthesis is required to build the latest syncevolution? Usually the one that was bundled with the release. When compiling from source, use the libsynthesis from http://cgit.freedesktop.org/SyncEvolution/libsynthesis -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From g+syncevolution at cobb.uk.net Sun Jan 19 16:56:52 2014 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Sun, 19 Jan 2014 16:56:52 +0000 Subject: [SyncEvolution] Compiling syncevolution on Debian jessie In-Reply-To: <1390072180.21270.8.camel@pohly-mobl1.fritz.box> References: <52DA4BF0.4050108@cobb.uk.net> <1390072180.21270.8.camel@pohly-mobl1.fritz.box> Message-ID: <52DC03D4.5090608@cobb.uk.net> On 18/01/14 19:09, Patrick Ohly wrote: > On Sat, 2014-01-18 at 09:40 +0000, Graham Cobb wrote: >> What version of synthesis is required to build the latest syncevolution? > > Usually the one that was bundled with the release. When compiling from > source, use the libsynthesis from > http://cgit.freedesktop.org/SyncEvolution/libsynthesis Thanks. As I am building from the git source I used that version of libsynthesis. One small problem: the syncevolution build finishes by creating the README, which requires executing the version of syncevolution that has just been built. In my case, that doesn't work. I built libsynthesis, installed it in /usr/local and then told syncevolution configure to look there (using PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/:/usr/lib/pkgconfig/). I did NOT put /usr/local into LD_LIBRARY_PATH. That is mainly because my syncevoution testing involves using a script which sets up several important environment variables, including LD_LIBRARY_PATH (and, in fact, I do my testing on a different machine). Anyway, the compilation all worked but the syncevolution that is built cannot be run. Which is fine by me, but not fine for this final stage of the build. It would be nice if one of several things was possible: 1) The README building script worked out how to set LD_LIBRARY_PATH (pkg-config worked out where the library was, after all). 2) I could tell configure to statically link libsynthesis. 3) I could tell configure that the built image won't run and the README step was dropped. 4) The perl script which creates the README handled syncevolution not running and put some default text in instead. The workround was, of course: LD_LIBRARY_PATH=/usr/local/lib:/usr/lib make but it would be nice if it could be handled automatically. Graham _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sun Jan 19 20:11:47 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 19 Jan 2014 21:11:47 +0100 Subject: [SyncEvolution] Compiling syncevolution on Debian jessie In-Reply-To: <52DC03D4.5090608@cobb.uk.net> References: <52DA4BF0.4050108@cobb.uk.net> <1390072180.21270.8.camel@pohly-mobl1.fritz.box> <52DC03D4.5090608@cobb.uk.net> Message-ID: <1390162307.21270.20.camel@pohly-mobl1.fritz.box> On Sun, 2014-01-19 at 16:56 +0000, Graham Cobb wrote: > One small problem: the syncevolution build finishes by creating the > README, which requires executing the version of syncevolution that has > just been built. In my case, that doesn't work. > > I built libsynthesis, installed it in /usr/local and then told > syncevolution configure to look there (using > PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/:/usr/lib/pkgconfig/). I did > NOT put /usr/local into LD_LIBRARY_PATH. That is mainly because my > syncevoution testing involves using a script which sets up several > important environment variables, including LD_LIBRARY_PATH (and, in > fact, I do my testing on a different machine). Anyway, the compilation > all worked but the syncevolution that is built cannot be run. Which is > fine by me, but not fine for this final stage of the build. > > It would be nice if one of several things was possible: > > 1) The README building script worked out how to set LD_LIBRARY_PATH > (pkg-config worked out where the library was, after all). I disagree here slightly. I think pkg-config is meant to find installed, usable versions of the libraries. When installing a lib into a non-standard local (non-standard = not search by default) then whoever installs it there needs to ensure that it works. This means setting PKG_CONFIG_PATH and, if the .pc file doesn't contain an rpath setting for the lib, also LD_LIBRARY_PATH. Having to second-guess how the lib was installed IMHO makes using it too complex and shouldn't be in the user of the lib. > 2) I could tell configure to statically link libsynthesis. If libsynthesis was configured with "--disable-dynamic --enable-static", SyncEvolution will use the static library. However, because it gets linked into a dynamic library, one also has to use "-DPIC -fpic" as CFLAGS and CXXFLAGS when configuring libsynthesis. > 3) I could tell configure that the built image won't run and the README > step was dropped. > > 4) The perl script which creates the README handled syncevolution not > running and put some default text in instead. The building of the README is already more tolerant if doing cross-compilation. In that case, the compiled executable might not work on the build machine. It is tried to run it, but when it fails, a fallback text about sync and source properties gets inserted into the README. I did not want that tolerant behavior as default because then it would be very easy to not notice the incomplete doc when building a release and something broke (like not having LD_LIBRARY_PATH set). I'm fine with adding a configure option. Should the more tolerant behavior be the default or the stricter, current approach? -- 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 Mon Jan 20 10:02:07 2014 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Mon, 20 Jan 2014 11:02:07 +0100 Subject: [SyncEvolution] Compiling syncevolution on Debian jessie In-Reply-To: <52DA4BF0.4050108@cobb.uk.net> References: <52DA4BF0.4050108@cobb.uk.net> Message-ID: <20140120100207.GA31172@mac.home> On Sat, Jan 18, 2014 at 09:40:00 +0000, Graham Cobb wrote: > I am trying to update my syncevolution and activesyncd build > environment, which I haven't touched for a while. Hi, do you intend to publish your activesyncd packaging, or even make it an official Debian package? > > I updated syncevolution (git pull) and tried to build it. I am getting > errors because sysync::LOCERR_AGAIN is not defined. > > What version of synthesis is required to build the latest syncevolution? > The version of libsynthesis currently in Debian Jessie is 3.4.0.16.8-1. Jessie should get an updated libsynthesis soon: http://packages.qa.debian.org/libs/libsynthesis.html I also have syncevolution 1.3.99.6 packages finished, I just got no time for some final checks and an E-Mail to my sponsor yet. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Mon Jan 20 10:49:12 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 20 Jan 2014 11:49:12 +0100 Subject: [SyncEvolution] Compiling syncevolution on Debian jessie In-Reply-To: <20140120100207.GA31172@mac.home> References: <52DA4BF0.4050108@cobb.uk.net> <20140120100207.GA31172@mac.home> Message-ID: <1390214952.21270.26.camel@pohly-mobl1.fritz.box> On Mon, 2014-01-20 at 11:02 +0100, Tino Mettler wrote: > I also have syncevolution 1.3.99.6 packages finished, I just got no > time for some final checks and an E-Mail to my sponsor yet. FYI, I am preparing the 1.3.99.7 release right now. I might finish that today. libsynthesis is the same as in 1.3.99.6. -- 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 Jan 31 20:16:39 2014 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Fri, 31 Jan 2014 21:16:39 +0100 Subject: [SyncEvolution] Compiling syncevolution on Debian jessie In-Reply-To: <20140120100207.GA31172@mac.home> References: <52DA4BF0.4050108@cobb.uk.net> <20140120100207.GA31172@mac.home> Message-ID: <20140131201639.GA462@mac.home> On Mon, Jan 20, 2014 at 11:02:07 +0100, Tino Mettler wrote: > On Sat, Jan 18, 2014 at 09:40:00 +0000, Graham Cobb wrote: > > I am trying to update my syncevolution and activesyncd build > > environment, which I haven't touched for a while. > > Hi, > > do you intend to publish your activesyncd packaging, or even make it an > official Debian package? Sorry for asking over and over again, what is your plan for the activesyncd package? AFAICS, it is a requirement for EAS client support in syncevolution and I think it would be nice to have this in Debian. > > I updated syncevolution (git pull) and tried to build it. I am getting > > errors because sysync::LOCERR_AGAIN is not defined. > > > > What version of synthesis is required to build the latest syncevolution? > > The version of libsynthesis currently in Debian Jessie is 3.4.0.16.8-1. > > Jessie should get an updated libsynthesis soon: > > http://packages.qa.debian.org/libs/libsynthesis.html > > I also have syncevolution 1.3.99.6 packages finished, I just got no > time for some final checks and an E-Mail to my sponsor yet. A new libsynthesis package is in Jessie for a few days. I also finished a syncevolution 1.3.99.7-1 package. You can find the source at git://git.debian.org/git/collab-maint/syncevolution. The source package can be generated this way: $ sudo apt-get install pristine-tar gitpkg $ git clone git://git.debian.org/git/collab-maint/syncevolution $ cd syncevolution $ git config gitpkg.deb-export-hook /usr/share/gitpkg/hooks/quilt-patches-deb-export-hook $ git config gitpkg.pre-export-hook /usr/share/gitpkg/hooks/pristine-tar-pre-export-hook $ gitpkg master The source package is now in ../deb-packages/syncevolution/. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From ovek at arcticnet.no Mon Jan 13 13:49:08 2014 From: ovek at arcticnet.no (=?ISO-8859-1?Q?Ove_K=E5ven?=) Date: Mon, 13 Jan 2014 14:49:08 +0100 Subject: [SyncEvolution] building with Qt5 Message-ID: <52D3EED4.90502@arcticnet.no> Well, I'm trying to build a GUI for Sailfish, which is Qt5-based. But Qt5 is not really supported by SyncEvolution. Although I've added some workarounds in the backends, it would probably be nice if Qt5 was more directly supported by the build system. Most importantly, perhaps, is that I'm not sure how to cleanly build the Qt D-Bus bindings. For example, syncevolution-qt-dbus.pc should contain "Requires: Qt5DBus" instead of "QtDBus". What's the least hackish way to achieve that? The build patches I've had to make so far include, with comments: > --- a/src/backends/kcalextended/configure-sub.in > +++ b/src/backends/kcalextended/configure-sub.in > @@ -13,5 +13,6 @@ SE_ARG_ENABLE_BACKEND(kcalextended, > > if test "$enable_kcalextended" = "yes"; then > AC_DEFINE(ENABLE_KCALEXTENDED, 1, [KCalExtended available]) > - PKG_CHECK_MODULES(KCALEXTENDED, libmkcal libkcalcoren) > + PKG_CHECK_MODULES(KCALEXTENDED, libmkcal-qt5 libkcalcoren-qt5 Qt5Core,, > + [PKG_CHECK_MODULES(KCALEXTENDED, libmkcal libkcalcoren)]) > fi (Fairly straightforward, but the Qt5Core part would probably not be needed if the build system supported Qt5) > --- a/src/backends/qtcontacts/configure-sub.in > +++ b/src/backends/qtcontacts/configure-sub.in > @@ -13,11 +13,11 @@ SE_ARG_ENABLE_BACKEND(qtcontacts, > > if test "$enable_qtcontacts" = "yes"; then > AC_DEFINE(ENABLE_QTCONTACTS, 1, [QtContacts available]) > - # AC_WITH_QT() will be called in configure-post if need_qt_modules is not empty, > - # setting QT_* flags. > - need_qt_modules="$need_qt_modules +gui" # GUI needed for QVersit > - qt_config="$qt_config +mobility" > - qt_misc="$qt_misc > -MOBILITY += contacts versit" > + PKG_CHECK_MODULES(QT_CONTACTS, Qt5Contacts Qt5Versit,,[ > + # AC_WITH_QT() will be called in configure-post if need_qt_modules is not empty, > + # setting QT_* flags. > + need_qt_modules="$need_qt_modules +gui" # GUI needed for QVersit > + qt_config="$qt_config +mobility" > + qt_misc="$qt_misc > +MOBILITY += contacts versit"]) > fi > -AC_SUBST(QT_CONTACTS_LIBS) > --- a/src/backends/qtcontacts/qtcontacts.am > +++ b/src/backends/qtcontacts/qtcontacts.am > @@ -19,4 +19,4 @@ src_backends_qtcontacts_syncqtcontacts_la_DEPENDENCIES = src/syncevo/libsyncevol > # Allow Qt to set some compile flags, but not the ones normally set via configure. > # In particular -W is not compatible with the SyncEvolution header files (we have > # unused parameters in some inline functions). > -src_backends_qtcontacts_syncqtcontacts_la_CXXFLAGS = $(SYNCEVOLUTION_CXXFLAGS) $(filter-out -O2 -g -W -Wall, $(QT_CXXFLAGS)) $(SYNCEVO_WFLAGS) > +src_backends_qtcontacts_syncqtcontacts_la_CXXFLAGS = $(SYNCEVOLUTION_CXXFLAGS) $(QT_CONTACTS_CFLAGS) $(filter-out -O2 -g -W -Wall, $(QT_CXXFLAGS)) $(SYNCEVO_WFLAGS) (The AC_SUBST is removed because presumably the new PKG_CHECK_MODULES already does that) And some bugfixes for the Qt bindings: > --- a/src/dbus/qt/qt.am > +++ b/src/dbus/qt/qt.am > @@ -69,7 +69,7 @@ src/dbus/qt/syncevo-%-full.cpp src/dbus/qt/syncevo-%-full.h: src/dbus/qt/stamp-% > > # work around #ifndef SYNCEVO-SERVER-FULL_H_1305547804 bug > src/dbus/qt/stamp-%: $(top_srcdir)/src/dbus/interfaces/syncevo-%-full.xml > - $(AM_V_at)@QDBUSXML_TO_CPP@ -p src/dbus/qt/syncevo-$*-full -i src/dbus/qt/dbustypes.h $< \ > + $(AM_V_at)@QDBUSXML_TO_CPP@ -p src/dbus/qt/syncevo-$*-full -i dbustypes.h $< \ > && perl -pi -e 's/SYNCEVO-(\w*)-FULL_H/SYNCEVO_$$1_FULL_H/' src/dbus/qt/syncevo-$*-full.* \ > && echo 'timestamp' >$@ > (The -i is for generating the #include, and using the source path doesn't work for installed files) > --- a/src/dbus/interfaces/syncevo-connection-full.xml > +++ b/src/dbus/interfaces/syncevo-connection-full.xml > @@ -102,8 +102,8 @@ > "URL" - the URL for an HTTP POST. > > > - > > + > > > > --- a/src/dbus/interfaces/syncevo-server-full.xml > +++ b/src/dbus/interfaces/syncevo-server-full.xml > @@ -129,8 +129,8 @@ > "system" - some plain text information about system libraries, > "backends" - available backend libraries > > - > > + > > > > @@ -585,8 +585,8 @@ > version of the transport entity. > > > - > > + > > > > --- a/src/dbus/interfaces/syncevo-session-full.xml > +++ b/src/dbus/interfaces/syncevo-session-full.xml > @@ -345,8 +345,8 @@ > > > Environment variables in clients > - > > + > > > (The annotations can't be inside the args, the xml-to-c++ tool doesn't recognize them there.) _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Mon Jan 13 14:56:24 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 13 Jan 2014 15:56:24 +0100 Subject: [SyncEvolution] building with Qt5 In-Reply-To: <52D3EED4.90502@arcticnet.no> References: <52D3EED4.90502@arcticnet.no> Message-ID: <1389624984.5855.414.camel@pohly-mobl1.fritz.box> On Mon, 2014-01-13 at 14:49 +0100, Ove K?ven wrote: > Well, I'm trying to build a GUI for Sailfish, which is Qt5-based. But > Qt5 is not really supported by SyncEvolution. Although I've added some > workarounds in the backends, it would probably be nice if Qt5 was more > directly supported by the build system. I don't know what the best way to handle Qt5 with autoconf/automake is these days. I'm open for suggestions. The existing Qt[5] D-Bus bindings are not used by anything at the moment. Feel free to make whatever changes you need. > > --- a/src/backends/kcalextended/configure-sub.in > > +++ b/src/backends/kcalextended/configure-sub.in > > @@ -13,5 +13,6 @@ SE_ARG_ENABLE_BACKEND(kcalextended, > > > > if test "$enable_kcalextended" = "yes"; then > > AC_DEFINE(ENABLE_KCALEXTENDED, 1, [KCalExtended available]) > > - PKG_CHECK_MODULES(KCALEXTENDED, libmkcal libkcalcoren) > > + PKG_CHECK_MODULES(KCALEXTENDED, libmkcal-qt5 libkcalcoren-qt5 Qt5Core,, > > + [PKG_CHECK_MODULES(KCALEXTENDED, libmkcal libkcalcoren)]) > > fi > > (Fairly straightforward, but the Qt5Core part would probably not be > needed if the build system supported Qt5) Would you prefer something like a --enable-qt5 switch? Something explicit instead of this implicit "pick the most recent version that we can find"? It might be a bit clearer, but other than that, such an automatic fallback isn't that bad, is it? -- 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 ovek at arcticnet.no Wed Jan 22 23:46:29 2014 From: ovek at arcticnet.no (=?UTF-8?B?T3ZlIEvDpXZlbg==?=) Date: Thu, 23 Jan 2014 00:46:29 +0100 Subject: [SyncEvolution] building with Qt5 In-Reply-To: <1389624984.5855.414.camel@pohly-mobl1.fritz.box> References: <52D3EED4.90502@arcticnet.no> <1389624984.5855.414.camel@pohly-mobl1.fritz.box> Message-ID: <52E05855.8080907@arcticnet.no> Den 13. jan. 2014 15:56, skrev Patrick Ohly: > Would you prefer something like a --enable-qt5 switch? Something > explicit instead of this implicit "pick the most recent version that we > can find"? Well, it seems a bit ugly too. I've tried to look into things a bit more, and perhaps the existing autotroll.m4 thing (which seems to call qmake) might still do the job for QtContacts, at least. The main problem in that regard is that SyncEvolution doesn't have any way to check whether any given Qt module is available and fall back to another module if not. With Qt5, there's no longer a "QtMobility", but a "QtPim" or something. So, to import QtContacts with autotroll, you should now just add "+contacts +versit" to the main "need_qt_modules" thing, I think, instead of having special imports for mobility. There's just no way to know that beforehand with the current approach. But given that knowledge of the Qt version is needed for --enable-qt-dbus (where the syncevolution-qt-dbus.pc file needs to know that it's now Qt5DBus, not QtDBus), and for --enable-kcalextended (where the kcalextended modules aren't known to qmake at all, only to pkg-config), perhaps it really is best to migrate to a completely pkg-config-based approach, instead of using autotroll. But, of course, a pkg-config-based approach would work for Qt4 too, since Qt4 also has full pkg-config support. Perhaps it's best to just use pkg-config all the way, and completely remove all uses of autotroll.m4? From patrick.ohly at intel.com Wed Jan 29 15:57:17 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 29 Jan 2014 16:57:17 +0100 Subject: [SyncEvolution] building with Qt5 In-Reply-To: <52E05855.8080907@arcticnet.no> References: <52D3EED4.90502@arcticnet.no> <1389624984.5855.414.camel@pohly-mobl1.fritz.box> <52E05855.8080907@arcticnet.no> Message-ID: <1391011037.30349.98.camel@pohly-mobl1.fritz.box> On Thu, 2014-01-23 at 00:46 +0100, Ove K?ven wrote: > But, of course, a pkg-config-based approach would work for Qt4 too, > since Qt4 also has full pkg-config support. Perhaps it's best to just > use pkg-config all the way, and completely remove all uses of autotroll.m4? I would be fine with that. Feel free to implement what works for you. I don't think anyone else currently uses the QtContacts backend or the Qt D-Bus binding library. -- 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 Mon Jan 27 15:20:29 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 27 Jan 2014 16:20:29 +0100 Subject: baseline distro for SyncEvolution 1.4? In-Reply-To: <1367831050.21612.260.camel@pohly-mobl1.fritz.box> References: <1367831050.21612.260.camel@pohly-mobl1.fritz.box> Message-ID: <1390836029.30349.46.camel@pohly-mobl1.fritz.box> On Mon, 2013-05-06 at 11:04 +0200, Patrick Ohly wrote: > Hello! > > So far, syncevolution.org binaries were compiled on Ubuntu Lucid 10.04 > LTS, which made the binaries compatible with pretty much all distros > since then, including Debian Stable. Since then, another Ubuntu LTS > (Precise Pangolin, 12.04) was released and Debian Wheezy became Debian > Stable this weekend. > > Does anyone still need SyncEvolution binaries for Ubuntu Lucid 10.04 and > Debian Squeeze? > > I'd like to switch to Ubuntu Precise as new baseline distro because then > binaries can use features from glib 3.32.0, more precisely, the revised > multithreading API. Then SyncEvolution can prevent premature client > timeouts when acting as SyncML HTTP server by running long-running local > storage initialization in a background thread. I've not received any feedback on this; if no-one objects, I'll go ahead and bump the requirement of SyncEvolution to glib >= 3.32. At the same time I will drop support for libdbus as alternative for glib gio D-Bus. This will make the code simpler and allow me to use more secure D-Bus IPC (use pipes instead of the less reliable and secure listening socket that is used at the moment). Ove, I suspect that this will prevent building SyncEvolution 1.4 for older Maemo. Do you know which devices have which glib version? Would you and/or users care? -- 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 ovek at arcticnet.no Mon Jan 27 15:47:53 2014 From: ovek at arcticnet.no (=?ISO-8859-1?Q?Ove_K=E5ven?=) Date: Mon, 27 Jan 2014 16:47:53 +0100 Subject: baseline distro for SyncEvolution 1.4? In-Reply-To: <1390836029.30349.46.camel@pohly-mobl1.fritz.box> References: <1367831050.21612.260.camel@pohly-mobl1.fritz.box> <1390836029.30349.46.camel@pohly-mobl1.fritz.box> Message-ID: <52E67FA9.5060102@arcticnet.no> Den 27. jan. 2014 16:20, skrev Patrick Ohly: > Ove, I suspect that this will prevent building SyncEvolution 1.4 for > older Maemo. Do you know which devices have which glib version? Would > you and/or users care? Let's see. The build environments I'm using have these installed: Harmattan: glib 2.28.4 Fremantle: glib 2.20.3 I think many people are still using SyncEvolution on these devices, so yes, I think I would care a bit. Now, I don't want to stop you from using shiny new GLib features, but it would certainly be nice if there were at least some #ifs to make basic stuff continue to work on older GLib versions. From patrick.ohly at intel.com Wed Jan 29 15:31:16 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 29 Jan 2014 16:31:16 +0100 Subject: baseline distro for SyncEvolution 1.4? In-Reply-To: <52E67FA9.5060102@arcticnet.no> References: <1367831050.21612.260.camel@pohly-mobl1.fritz.box> <1390836029.30349.46.camel@pohly-mobl1.fritz.box> <52E67FA9.5060102@arcticnet.no> Message-ID: <1391009476.30349.96.camel@pohly-mobl1.fritz.box> On Mon, 2014-01-27 at 16:47 +0100, Ove K?ven wrote: > Den 27. jan. 2014 16:20, skrev Patrick Ohly: > > Ove, I suspect that this will prevent building SyncEvolution 1.4 for > > older Maemo. Do you know which devices have which glib version? Would > > you and/or users care? > > Let's see. The build environments I'm using have these installed: > > Harmattan: glib 2.28.4 > Fremantle: glib 2.20.3 > > I think many people are still using SyncEvolution on these devices, so > yes, I think I would care a bit. Now, I don't want to stop you from > using shiny new GLib features, but it would certainly be nice if there > were at least some #ifs to make basic stuff continue to work on older > GLib versions. Okay, I guess I have to keep the libdbus support alive a bit longer. I'll rework my patch before merging into 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 chingupt at gmail.com Mon Jan 27 14:03:32 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Mon, 27 Jan 2014 09:03:32 -0500 Subject: backend = file: not one of the valid values In-Reply-To: References: Message-ID: + Forum On Mon, Jan 27, 2014 at 9:03 AM, Sachin Gupta wrote: > Hi Patrick, > > When running syncevolution, i am getting the following error: > > efault/sources/addressbook/config.ini: backend = file: not one of the > valid values (virtual, calendar = events, addressbook = contacts, todo = > tasks, memo = memos = notes, SQLite Address Book = sqlite-contacts = sqlite) > > With the same settings, i had installed syncevolution on another machine > and it works fine there. Using the same config.ini files on the new machine. > > Please suggest what is missing here. > > Regards > Sachin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Mon Jan 27 14:41:44 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 27 Jan 2014 15:41:44 +0100 Subject: backend = file: not one of the valid values In-Reply-To: References: Message-ID: <1390833704.30349.39.camel@pohly-mobl1.fritz.box> On Mon, 2014-01-27 at 09:03 -0500, Sachin Gupta wrote: > + Forum > > On Mon, Jan 27, 2014 at 9:03 AM, Sachin Gupta > wrote: > Hi Patrick, > > > When running syncevolution, i am getting the following error: > > efault/sources/addressbook/config.ini: backend = file: not one > of the valid values (virtual, calendar = events, addressbook = > contacts, todo = tasks, memo = memos = notes, SQLite Address > Book = sqlite-contacts = sqlite) How was SyncEvolution compiled and/or installed? Looks like the file backend is not installed. Check "syncevolution --version" and in particular the list of loaded backends. If you enabled a shared build, there should be a syncfile.so. -- 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 chingupt at gmail.com Wed Jan 29 12:41:53 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Wed, 29 Jan 2014 18:11:53 +0530 Subject: backend = file: not one of the valid values In-Reply-To: <1390833704.30349.39.camel@pohly-mobl1.fritz.box> References: <1390833704.30349.39.camel@pohly-mobl1.fritz.box> Message-ID: Hi Patrick, the syncfile.so was not copied. Now i am faced with another issue: when running syncevolution, getting error: Exception Unsupported transport type:SyncContext.cpp:1571 Basically, it is unable to fetch the SyncURL from config.ini. I have verified that the file has permissions, tested the config.ini on another machine, works there. But here it just doesnt read the server URL. Please guide. Regards Sachin On Mon, Jan 27, 2014 at 8:11 PM, Patrick Ohly wrote: > On Mon, 2014-01-27 at 09:03 -0500, Sachin Gupta wrote: > > + Forum > > > > On Mon, Jan 27, 2014 at 9:03 AM, Sachin Gupta > > wrote: > > Hi Patrick, > > > > > > When running syncevolution, i am getting the following error: > > > > efault/sources/addressbook/config.ini: backend = file: not one > > of the valid values (virtual, calendar = events, addressbook = > > contacts, todo = tasks, memo = memos = notes, SQLite Address > > Book = sqlite-contacts = sqlite) > > How was SyncEvolution compiled and/or installed? Looks like the file > backend is not installed. > > Check "syncevolution --version" and in particular the list of loaded > backends. If you enabled a shared build, there should be a syncfile.so. > > -- > 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. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Wed Jan 29 13:16:06 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 29 Jan 2014 14:16:06 +0100 Subject: backend = file: not one of the valid values In-Reply-To: References: <1390833704.30349.39.camel@pohly-mobl1.fritz.box> Message-ID: <1391001366.30349.72.camel@pohly-mobl1.fritz.box> On Wed, 2014-01-29 at 18:11 +0530, Sachin Gupta wrote: > Hi Patrick, > > > the syncfile.so was not copied. > > > Now i am faced with another issue: > when running syncevolution, getting error: > > > Exception Unsupported transport type:SyncContext.cpp:1571 > > > Basically, it is unable to fetch the SyncURL from config.ini. It can read the SyncURL, but it can't find a transport for it. Check the HTTP support was enabled during compilation. You need either libcurl or libsoup. If in doubt, step through the function that generates the error. You have the source... -- 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 ovek at arcticnet.no Sat Jan 4 08:56:18 2014 From: ovek at arcticnet.no (=?ISO-8859-1?Q?Ove_K=E5ven?=) Date: Sat, 4 Jan 2014 09:56:18 +0100 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) Message-ID: <52C7CCB2.7080108@arcticnet.no> I just got my Jolla phone a few days ago, and now I'm investigating porting SyncEvolution to it. Since Sailfish is based on Mer (the fork of Nokia's MeeGo), the base platform seems very similar to Harmattan. From what I can tell, QtContacts and KCalExtended is still used on Sailfish, so the existing SyncEvolution backends can probably be used. The SSO implementation on Sailfish, though, is also based on Nokia's SSO implementation. From what I can tell, this implementation is from Ubuntu. It seems to me that Sailfish is using the SSO implementation from Ubuntu Online Accounts. Then, what's the plan for supporting UOA in SyncEvolution? If I have to, I could try to change the gSSO implementation so that it can deal with the Ubuntu implementation, but I don't run Ubuntu myself, so I'd only actually test it on Sailfish... _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From g+syncevolution at cobb.uk.net Sat Jan 4 12:24:38 2014 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Sat, 4 Jan 2014 12:24:38 +0000 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) In-Reply-To: <52C7CCB2.7080108@arcticnet.no> References: <52C7CCB2.7080108@arcticnet.no> Message-ID: <52C7FD86.3020908@cobb.uk.net> On 04/01/14 08:56, Ove K?ven wrote: > I just got my Jolla phone a few days ago, and now I'm investigating > porting SyncEvolution to it. Unfortunately I can't answer any of your questions but I was also about to start looking at porting SyncEvolution to my new Jolla phone! Is your goal to run a full SyncEvolution on the phone, so it can synchronize directly with anything SyncEvolution supports? I was planning a more modest goal to use SyncEvolution to effectively act as a client for a remote SyncEvolution server, which would handle the complexities of synchronizing with everything else. I was also going to look into any other ways to get a SyncML client on the phone. However, I really hadn't started looking at it yet as I have had no time over Christmas. I would be very happy to join with your effort. > If I have to, I could try to change the gSSO implementation so that it > can deal with the Ubuntu implementation, but I don't run Ubuntu myself, > so I'd only actually test it on Sailfish... Unfortunately neither do I. Graham _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From ovek at arcticnet.no Sat Jan 4 12:59:25 2014 From: ovek at arcticnet.no (=?ISO-8859-1?Q?Ove_K=E5ven?=) Date: Sat, 4 Jan 2014 13:59:25 +0100 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) In-Reply-To: <52C7FD86.3020908@cobb.uk.net> References: <52C7CCB2.7080108@arcticnet.no> <52C7FD86.3020908@cobb.uk.net> Message-ID: <52C805AD.3070108@arcticnet.no> Den 04.01.2014 13:24, skrev Graham Cobb: > On 04/01/14 08:56, Ove K?ven wrote: >> I just got my Jolla phone a few days ago, and now I'm investigating >> porting SyncEvolution to it. > > Unfortunately I can't answer any of your questions but I was also about > to start looking at porting SyncEvolution to my new Jolla phone! > > Is your goal to run a full SyncEvolution on the phone, so it can > synchronize directly with anything SyncEvolution supports? I want to make a full port. I did that with both Maemo Fremantle (N900) and Harmattan (N9) before, now it's time for the new platform generation that continues the work Nokia started. SyncEvolution on Maemo Extras: http://maemo.org/packages/view/syncevolution/ I also wrote the frontend: http://maemo.org/packages/view/syncevolution-frontend/ Harmattan: http://people.debian.org/~ovek/harmattan/ I never did get around to making a GUI for Harmattan, but at least the CLI is perfectly usable... though not sure how to handle SSO on it either if I am to compile newer SyncEvolution releases for it. The N9's SSO library is relatively old, backporting to it may take some work. > I was planning a more modest goal to use SyncEvolution to effectively > act as a client for a remote SyncEvolution server, which would handle > the complexities of synchronizing with everything else. Oh, I could probably make a build of that very easily. (Perhaps I should, so I can transfer my contacts over. I just need to read up on building rpms instead of the debs that Harmattan used.) But I've also been very interested in the CalDAV stuff, as are many others. In addition to Google Calendar, many people seem to use ownCloud, which I think requires CalDAV. _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From ovek at arcticnet.no Mon Jan 6 15:43:09 2014 From: ovek at arcticnet.no (=?ISO-8859-1?Q?Ove_K=E5ven?=) Date: Mon, 6 Jan 2014 16:43:09 +0100 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) In-Reply-To: <52C7FD86.3020908@cobb.uk.net> References: <52C7CCB2.7080108@arcticnet.no> <52C7FD86.3020908@cobb.uk.net> Message-ID: <52CACF0D.2070605@arcticnet.no> OK, it took me all weekend and then some, but I think I've got a somewhat functional rpm now. I uploaded what I've got so far to: http://people.debian.org/~ovek/sailfish/ (Though it's not a Debian package, hopefully Debian won't mind me using their web space for this...) In theory, everything (including CardDAV and CalDAV) should work except for SSO (and hence OAuth2), but I haven't yet tested much beyond "syncevolution --export", will do that later. Some notes on what is done: General * The D-Bus service is enabled in this build. * On Sailfish, accessing PIM data requires being in the unix group "privileged" (gid 998). I've thus made syncevo-dbus-helper sgid privileged. (Not sure if it's cleaner to do that, or doing it to syncevo-dbus-server. Also, perhaps there's a more elegant way than making the executable sgid, but it works for now.) * The Bluetooth support is disabled in this build. (After all, maybe there's already a bluetooth SyncML on the phone? Haven't checked.) * I have made no attempt to follow the Harbour rules, mostly because they're ridiculous and violate the FHS for no good reason at all. Contacts * Had to do some pkg-config magic in configure-sub.in (Qt5 seems to rely on pkg-config a lot more than Qt4 did). * I filter the contacts by SyncTarget "local", so that it won't try to sync all your social media buddies. By default, Sailfish's backend filters by SyncTarget "aggregate", so I have to use this filter even from readItem (which already knows the luid it wants), since otherwise the default filter will filter out the requested luid. * The QtContacts API from Qt5 QtPIM turns out to be somewhat different from the QtContacts API from Qt4 QtMobility. Some of the changes are: - QtContacts luids are now strings, not integers (and the APIs for these ids have been renamed from "LocalId" to just "Id"). The strings include the manager id, so they're surprisingly long strings... - QtContacts no longer support adding arbitrary detail (the set of supported detail types now appears fixed), all detail are indexed by enums instead of strings. Hence, I've had to disable the X-SYNCEVO-QTCONTACTS stuff. Calendar/Tasks/Notes * mKCal for Qt5 required some more messing with pkg-config, but otherwise, the code seemed to compile and work without modifications. (Thus, haven't really checked whether I should have done any.) * Haven't yet investigated what happens with notes - if they're stored in mKCal anymore, perhaps support for them should be disabled? _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From ovek at arcticnet.no Tue Jan 7 09:31:41 2014 From: ovek at arcticnet.no (=?ISO-8859-1?Q?Ove_K=E5ven?=) Date: Tue, 7 Jan 2014 10:31:41 +0100 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) In-Reply-To: <52CACF0D.2070605@arcticnet.no> References: <52C7CCB2.7080108@arcticnet.no> <52C7FD86.3020908@cobb.uk.net> <52CACF0D.2070605@arcticnet.no> Message-ID: <52CBC97D.5000407@arcticnet.no> Den 06. jan. 2014 16:43, skrev Ove K?ven: > OK, it took me all weekend and then some, but I think I've got a > somewhat functional rpm now. I uploaded what I've got so far to: > http://people.debian.org/~ovek/sailfish/ After testing importing/syncing contacts, I've now done a small fix and uploaded again. For some undetermined reason, the "readback" (fetching the saved contact back) in writeItem doesn't read anything back (thus causing a crash), even though the new contact is saved succesfully, but that code is also probably not needed on Sailfish (the sqlite engine code I've studied seems to update the timestamps properly), so I've disabled that. Now syncing should hopefully work without crashing... Also, added LD_FLAGS="-Wl,--as-needed", so now the rpm shouldn't depend on cppunit and stuff anymore, I think... _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From g+syncevolution at cobb.uk.net Fri Jan 24 16:44:11 2014 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Fri, 24 Jan 2014 16:44:11 +0000 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) In-Reply-To: <52CACF0D.2070605@arcticnet.no> References: <52C7CCB2.7080108@arcticnet.no> <52C7FD86.3020908@cobb.uk.net> <52CACF0D.2070605@arcticnet.no> Message-ID: <52E2985B.2010007@cobb.uk.net> On 06/01/14 15:43, Ove K?ven wrote: > OK, it took me all weekend and then some, but I think I've got a > somewhat functional rpm now. I uploaded what I've got so far to: > http://people.debian.org/~ovek/sailfish/ Just to let you know... I have installed this and tested it as a SyncML-over-http client (with SyncEvolution also acting as the SyncML server at the other end), syncing calendar, contacts and tasks (although task DB is empty). It is working well, with only a few strangenesses, most of which don't look like they are anything to do with your port: 1) I currently use it from the command line, logged in over ssh. It starts running but very quickly stops doing anything. I think this is something to do with Jolla battery saving as it continues if I touch the screen of the phone. I have to keep interacting with the screen every few seconds to keep it running. 2) The "diff" function (printChanges) doesn't work. It almost never completes (before the other end times out -- several minutes). I suspect this is something to do with the logic of the diff script itself as I have seen strangenesses with it on the desktop side as well (for example it has managed to report two halves of one changed entry as two separate changes). It probably isn't helped by me having 1500 calendar entries. I have had to turn off printChanges. 3) I had one calendar entry which synced but then caused an error whenever syncevolution tried to read it from the calendar. --export got an error whenever it read it (and so did sync, of course). I couldn't even delete it using --delete-items. I eventually deleted it from the calendar GUI (but I had to delete it twice -- the first time it reappeared!). The bad entry was a recurring entry with a specific recurrence. Not sure where the problem lies -- I haven't tried to reproduce it yet. I notice that tasks will also sync (or at least, appear to -- I don't have any in the DB on my server at the moment). Do you know if there is any Jolla app which uses the task DB? Thanks very much for making the rpm's available. It helps with my goal of making this my main phone by the time I get to MWC. Graham _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From ovek at arcticnet.no Fri Jan 24 23:02:49 2014 From: ovek at arcticnet.no (=?ISO-8859-1?Q?Ove_K=E5ven?=) Date: Sat, 25 Jan 2014 00:02:49 +0100 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) In-Reply-To: <52E2985B.2010007@cobb.uk.net> References: <52C7CCB2.7080108@arcticnet.no> <52C7FD86.3020908@cobb.uk.net> <52CACF0D.2070605@arcticnet.no> <52E2985B.2010007@cobb.uk.net> Message-ID: <52E2F119.2010907@arcticnet.no> Den 24. jan. 2014 17:44, skrev Graham Cobb: > On 06/01/14 15:43, Ove K?ven wrote: >> OK, it took me all weekend and then some, but I think I've got a >> somewhat functional rpm now. I uploaded what I've got so far to: >> http://people.debian.org/~ovek/sailfish/ > > Just to let you know... > > I have installed this and tested it as a SyncML-over-http client (with > SyncEvolution also acting as the SyncML server at the other end), > syncing calendar, contacts and tasks (although task DB is empty). > > It is working well, with only a few strangenesses, most of which don't > look like they are anything to do with your port: > > 1) I currently use it from the command line, logged in over ssh. It > starts running but very quickly stops doing anything. I think this is > something to do with Jolla battery saving as it continues if I touch the > screen of the phone. I have to keep interacting with the screen every > few seconds to keep it running. Yes. Everything running on the CPU gets suspended. There's some discussions, workarounds, and explanations here: http://talk.maemo.org/showthread.php?t=92183 It seems to me that incoming network packets also wakes up the CPU, so if I have an open ssh session to the phone, I can just press some key (like Enter) to wake it up whenever necessary. Or just have a terminal window with "ping jolla" running while I'm working, whatever. > 2) The "diff" function (printChanges) doesn't work. It almost never > completes (before the other end times out -- several minutes). I > suspect this is something to do with the logic of the diff script itself > as I have seen strangenesses with it on the desktop side as well (for > example it has managed to report two halves of one changed entry as two > separate changes). It probably isn't helped by me having 1500 calendar > entries. I have had to turn off printChanges. Haven't noticed problems with it myself, but then I haven't done very much testing with it turned on, I suppose. It's certainly possible that things could get a bit slow with a large database, but it shouldn't be *that* slow. Perhaps it has something to do with the powersaving problem mentioned above. If this deep suspend mode kicks in (quite possible during printChanges, since there's probably no network traffic while that's processing data), it would also completely stop SyncEvolution dead in its tracks, until the user wakes the phone. If that could be a problem, perhaps it would be a good idea to look into ways to prevent the phone from suspending while a sync is in progress. > 3) I had one calendar entry which synced but then caused an error > whenever syncevolution tried to read it from the calendar. --export got > an error whenever it read it (and so did sync, of course). I couldn't > even delete it using --delete-items. I eventually deleted it from the > calendar GUI (but I had to delete it twice -- the first time it > reappeared!). The bad entry was a recurring entry with a specific > recurrence. Not sure where the problem lies -- I haven't tried to > reproduce it yet. Well, I can't do much without more information (unless I experience it myself, I suppose I might once I start using this more actively). > I notice that tasks will also sync (or at least, appear to -- I don't > have any in the DB on my server at the moment). Do you know if there is > any Jolla app which uses the task DB? No, I don't think there's one yet. Jolla themselves haven't made a Tasks app yet, and I don't know of any third-party tasks app that's using the mKCal backend. The Jolla Notes app also doesn't use the mKCal backend. I think syncing those would require writing a SQLite-based backend for notes. (They use a very simple database. "CREATE TABLE notes (pagenr INTEGER, color TEXT, body TEXT);", so no GUIDs or creation time or anything that might help resolve conflicts. It's apparently not designed to be synced.) For now, I'm considering just disabling tasks and notes support in the rpms for Jolla, since trying to sync those is currently useless. However, I've been toying with the idea of writing my own calendar and tasks app. After all, Jolla's own calendar app is not very sophisticated. Apart from not supporting tasks, it also doesn't show the location of the events in my calendar, and sometimes that's information I need. But then again, it's possible that Jolla will improve their calendar app soon. _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From ovek at arcticnet.no Fri Jan 17 12:58:13 2014 From: ovek at arcticnet.no (=?ISO-8859-1?Q?Ove_K=E5ven?=) Date: Fri, 17 Jan 2014 13:58:13 +0100 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) In-Reply-To: <52C7FD86.3020908@cobb.uk.net> References: <52C7CCB2.7080108@arcticnet.no> <52C7FD86.3020908@cobb.uk.net> Message-ID: <52D928E5.7070001@arcticnet.no> On 01/04/2014 01:24 PM, Graham Cobb wrote: > However, I really hadn't started looking at it yet as I have had no time > over Christmas. I would be very happy to join with your effort. Hi again. If you want to help, maybe you would like to help creating the Sailfish GUI? I can handle SyncEvolution proper myself, but writing the GUI takes time... So far I've written something which can start a sync using an existing configuration, but there's no way to create or edit a configuration, nor any handling of sync errors, yet. _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From g+syncevolution at cobb.uk.net Fri Jan 17 13:21:58 2014 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Fri, 17 Jan 2014 13:21:58 +0000 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) In-Reply-To: <52D928E5.7070001@arcticnet.no> References: <52C7CCB2.7080108@arcticnet.no> <52C7FD86.3020908@cobb.uk.net> <52D928E5.7070001@arcticnet.no> Message-ID: <52D92E76.3000506@cobb.uk.net> On 17/01/14 12:58, Ove K?ven wrote: > On 01/04/2014 01:24 PM, Graham Cobb wrote: >> However, I really hadn't started looking at it yet as I have had no time >> over Christmas. I would be very happy to join with your effort. > > Hi again. If you want to help, maybe you would like to help creating the > Sailfish GUI? I can handle SyncEvolution proper myself, but writing the > GUI takes time... Sorry, I am not in a position to volunteer to do that, at the moment. I am really not a GUI guy. And I am not going to have the time to look into it for the time being (at least until after MWC). Until then I will restrict myself to testing. I have been testing other things on my Jolla phone recently but I plan to install your rpm this weekend and give it a try. Sorry I can't be more help at the moment. Graham _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From ovek at arcticnet.no Sun Jan 19 13:10:50 2014 From: ovek at arcticnet.no (=?ISO-8859-1?Q?Ove_K=E5ven?=) Date: Sun, 19 Jan 2014 14:10:50 +0100 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) In-Reply-To: <52D92E76.3000506@cobb.uk.net> References: <52C7CCB2.7080108@arcticnet.no> <52C7FD86.3020908@cobb.uk.net> <52D928E5.7070001@arcticnet.no> <52D92E76.3000506@cobb.uk.net> Message-ID: <52DBCEDA.9060405@arcticnet.no> Den 17. jan. 2014 14:21, skrev Graham Cobb: > On 17/01/14 12:58, Ove K?ven wrote: >> On 01/04/2014 01:24 PM, Graham Cobb wrote: >>> However, I really hadn't started looking at it yet as I have had no time >>> over Christmas. I would be very happy to join with your effort. >> >> Hi again. If you want to help, maybe you would like to help creating the >> Sailfish GUI? I can handle SyncEvolution proper myself, but writing the >> GUI takes time... > > Sorry, I am not in a position to volunteer to do that, at the moment. I > am really not a GUI guy. And I am not going to have the time to look > into it for the time being (at least until after MWC). Allright. But maybe you know of other people that might? It's not necessary to be a hardcore programmer to write some QML, after all. (But I've found it can be tedious and time-consuming if you don't have much experience with it...) For my own GUI design attempt, I'm also not sure about what the best interface would be. How should users start a sync? How should its progress be displayed? And how should users abort a sync? Well, once it's working, I can maybe put what I have on openrepos or something and find out how other users would like it to work... _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Mon Jan 6 07:05:14 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 06 Jan 2014 08:05:14 +0100 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) In-Reply-To: <52C7CCB2.7080108@arcticnet.no> References: <52C7CCB2.7080108@arcticnet.no> Message-ID: <1388991914.5855.290.camel@pohly-mobl1.fritz.box> On Sat, 2014-01-04 at 09:56 +0100, Ove K?ven wrote: > The SSO implementation on Sailfish, though, is also based on Nokia's SSO > implementation. From what I can tell, this implementation is from > Ubuntu. It seems to me that Sailfish is using the SSO implementation > from Ubuntu Online Accounts. I'm not sure which one came first, but yes, this is the same solution (libaccounts + libsignon, aka Ubuntu Online Accounts). An alternative implementation is gSSO (forked libsignon with a new, glib-based implementation of the daemon and plugins). > Then, what's the plan for supporting UOA in SyncEvolution? The gSSO that was discussed on this list last year pretty much already covered it. See http://cgit.freedesktop.org/SyncEvolution/syncevolution/tree/src/backends/signon/README Since then Canonical has contributed a patch to make it work with Ubuntu Online Accounts, see https://bugs.freedesktop.org/show_bug.cgi?id=72263 I'll merge that patch soon, it's only blocked by my current work on parallelizing the nightly test system. Well, that, and Christmas/New Year Eve's vacation :-) Regarding Sailfish, you'll probably need to compare docs to find out whether it works exactly as the current Ubuntu Online Accounts. -- 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 ovek at arcticnet.no Mon Jan 6 09:58:20 2014 From: ovek at arcticnet.no (=?UTF-8?B?T3ZlIEvDpXZlbg==?=) Date: Mon, 6 Jan 2014 10:58:20 +0100 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) In-Reply-To: <1388991914.5855.290.camel@pohly-mobl1.fritz.box> References: <52C7CCB2.7080108@arcticnet.no> <1388991914.5855.290.camel@pohly-mobl1.fritz.box> Message-ID: <52CA7E3C.3020003@arcticnet.no> Den 06. jan. 2014 08:05, skrev Patrick Ohly: > On Sat, 2014-01-04 at 09:56 +0100, Ove K?ven wrote: >> The SSO implementation on Sailfish, though, is also based on Nokia's SSO >> implementation. From what I can tell, this implementation is from >> Ubuntu. It seems to me that Sailfish is using the SSO implementation >> from Ubuntu Online Accounts. > > I'm not sure which one came first, Oh, I'm pretty sure which came first. I'm just not sure which came second... In the Harmattan version of libsignon, the author is listed as Alberto Mardegan, with a nokia.com email address, and all copyrights are Nokia's. In the Sailfish version of libsignon, Alberto Mardegan is still the only author, but he now has a canonical.com email address, and some Canonical copyrights have been added in some places. Hence, Canonical has continued with Nokia's implementation (as did gSSO, I suppose, but whereas Ubuntu's implementation seems to be backwards compatible with Nokia's original implementation, gSSO is not). But I think it is also reasonable to assume the ex-Nokia people at Jolla would know this guy. So, whether it was originally Jolla's idea that Alberto could work on this, or Canonical's, I don't know... >> Then, what's the plan for supporting UOA in SyncEvolution? > > The gSSO that was discussed on this list last year pretty much already > covered it. See > http://cgit.freedesktop.org/SyncEvolution/syncevolution/tree/src/backends/signon/README But the updates I've read said that gSSO was implemented, but that UOA was not. Was just wondering whether it would happen anytime soon, or if volunteers were needed, or whatever. > Since then Canonical has contributed a patch to make it work with Ubuntu > Online Accounts, see https://bugs.freedesktop.org/show_bug.cgi?id=72263 > > I'll merge that patch soon, it's only blocked by my current work on > parallelizing the nightly test system. Well, that, and Christmas/New > Year Eve's vacation :-) Allright. > Regarding Sailfish, you'll probably need to compare docs to find out > whether it works exactly as the current Ubuntu Online Accounts. For now, I think I can fairly safely assume the system is the same or close enough (just perhaps different UI, which doesn't matter). From alberto.mardegan at canonical.com Tue Jan 7 20:40:35 2014 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Tue, 7 Jan 2014 22:40:35 +0200 Subject: [SyncEvolution] SyncEvolution and SSO on SailfishOS (and Ubuntu) In-Reply-To: <52CA7E3C.3020003@arcticnet.no> References: <52C7CCB2.7080108@arcticnet.no> <1388991914.5855.290.camel@pohly-mobl1.fritz.box> <52CA7E3C.3020003@arcticnet.no> Message-ID: <52CC6643.5080202@canonical.com> Hi Ove, On 01/06/2014 11:58 AM, Ove K?ven wrote: > Hence, Canonical has continued with Nokia's implementation (as did gSSO, > I suppose, but whereas Ubuntu's implementation seems to be backwards > compatible with Nokia's original implementation, gSSO is not). But I > think it is also reasonable to assume the ex-Nokia people at Jolla would > know this guy. So, whether it was originally Jolla's idea that Alberto > could work on this, or Canonical's, I don't know... That's correct. In Canonical I simply continued doing what I was doing in Nokia, along with other ex-Nokians working at Intel (for Tizen). :-) Some time ago Tizen plans about Qt changed, and they rewrote signond using GLib+GObject, and unfortunately a few API-incompatible changes also sneaked in during the process. Also Jolla picked up the software at the same time as Canonical did, but initially they didn't contribute much, most likely because the existing implementation was working just fine for them. Chris Adams (chriadam in IRC) from Jolla is now very active on it. KDE has also decided to adopt the technology, though they haven't implemented it yet. You can find us on IRC (freenode), on the #accounts-sso channel. Chris is probably on holidays now, but for anything Jolla-specific you can ask Valerio (VDVsx). For all the rest you're welcome to ping me (mardy). > But the updates I've read said that gSSO was implemented, but that UOA > was not. Was just wondering whether it would happen anytime soon, or if > volunteers were needed, or whatever. Both are implemented, but the UOA branch is still not merged into master. You can surely help with testing, because my testing was not extensive at all. >> Regarding Sailfish, you'll probably need to compare docs to find out >> whether it works exactly as the current Ubuntu Online Accounts. > > For now, I think I can fairly safely assume the system is the same or > close enough (just perhaps different UI, which doesn't matter). Yes, the UI is different, but the APIs are just the same. Ciao, Alberto _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Thu Jan 23 13:16:30 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 23 Jan 2014 14:16:30 +0100 Subject: SyncEvolution 1.3.99.7 released - release candidate for 1.4! Message-ID: <1390482990.30349.25.camel@pohly-mobl1.fritz.box> This the final release candidate for 1.4. No further changes planned unless new problems are found. Details: * SSO: support Ubuntu Online Accounts When compiling from source on recent Ubuntu it becomes possible to use Ubuntu Online Accounts for authenticating against Google's CalDAV and CardDAV servers. * D-Bus server: fix abort when mixing auto-sync and manual operations (FDO #73562) When enabling auto-sync for a config and then accessing or syncing the config manually via the command line tool, the server would abort at the time when the auto-sync was originally scheduled. * D-Bus server: accept WBXML with charset in incoming connections A user reported via email that the Nokia 515 sends 'application/vnd.syncml+wbxml; charset=UTF-8' as type of its messages. This tripped up the syncevo-http-server, leading to: [ERROR] syncevo-dbus-server: /org/syncevolution/Server: message type 'application/vnd.syncml+wbxml; charset=UTf-8' not supported for starting a sync We need to strip the '; charset=UTF-8' suffix also when checking for WBXML. * packaging: compatible with EDS up to and including 3.10 The packages now contain three versions of syncecal.so: - one for EDS < 3.6 - one for EDS >= 3.6 < 3.10 - one for EDS >= 3.10 with the libecal-1.2 soname patched The third flavor became necessary because EDS 3.10 accidentally changed the soname. The API and ABI actually is the same. Package meta-data was fixed to reflect the extended range of compatible EDS libraries, so syncevolution-evolution can be installed again with recent EDS. * packaging: update syncevolution-kde dependencies kdebase-runtime became kde-runtime in Debian Wheezy. Accept both as prerequisite of syncevolution-kde to allow installation on newer distros without pulling in the transitional kdebase-runtime package. * packaging: fix rpm (FDO #73347) After installing the syncevolution.org rpm on OpenSUSE, SyncEvolution was not starting because its shared libraries were not found unless "ldconfig" was called manually. Now the package does that automatically. * packaging: fix description The syncevolution-bundle description of both rpm and deb packagesaccidentally used the same description as syncevolution-evolution. * test improvements, integration of cppcheck and clang's scan-build Source, Installation, Further information ========================================= http://syncevolution.org/blogs/pohly/2014/syncevolution-13997-released Source code bundles for users are available in http://downloads.syncevolution.org/syncevolution/sources and the original source is in the git repositories http://cgit.freedesktop.org/SyncEvolution/ i386, lpia and amd64 binaries for Debian-based distributions are available via the "unstable" syncevolution.org repository. Add the following entry to your /apt/source.list: deb http://downloads.syncevolution.org/apt stable main Then install "syncevolution-evolution", "syncevolution-kde" and/or "syncevolution-activesync". These binaries include the "sync-ui" GTK GUI and were compiled for Ubuntu 8.04 LTS (Hardy), except for "syncevolution-activesync" which depends on libraries in Debian Squeeze, for example EDS 3.4. Older distributions like Debian 4.0 (Etch) can no longer be supported with precompiled binaries because of missing libraries, but the source still compiles when not enabling the GUI (the default). The same binaries are also available as .tar.gz and .rpm archives in http://downloads.syncevolution.org/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. After installation, follow the http://syncevolution.org/documentation/getting-started steps. -- Patrick Ohly, on behalf of everyone who has helped to make SyncEvolution possible: http://syncevolution.org/about/contributors From chingupt at gmail.com Thu Jan 16 18:32:24 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Fri, 17 Jan 2014 00:02:24 +0530 Subject: Changing the .config/syncevolution directory path Message-ID: Hi Patrick, Is it possible to force syncevolution to look for the configuration files (.config/syncevolution) in another folder than the home directory of the user? Best Regards Sachin From patrick.ohly at intel.com Thu Jan 16 19:36:04 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 16 Jan 2014 20:36:04 +0100 Subject: Changing the .config/syncevolution directory path In-Reply-To: References: Message-ID: <1389900964.16995.114.camel@pohly-mobl1.fritz.box> On Fri, 2014-01-17 at 00:02 +0530, Sachin Gupta wrote: > Hi Patrick, > > Is it possible to force syncevolution to look for the configuration > files (.config/syncevolution) in another folder than the home > directory of the user? SyncEvolution follows the XDG spec. You can override $HOME/.config by setting the XDG_CONFIG_HOME env variable. -- 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 chingupt at gmail.com Fri Jan 17 04:28:18 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Fri, 17 Jan 2014 09:58:18 +0530 Subject: Changing the .config/syncevolution directory path In-Reply-To: <1389900964.16995.114.camel@pohly-mobl1.fritz.box> References: <1389900964.16995.114.camel@pohly-mobl1.fritz.box> Message-ID: Hi, I did try that. exported XDG_CONFIG_HOME from .profile and then ran the syncevolution. Getting error. No such source(s): addressbook. I copied the .config contents to a dir and set the XDG_CONFIG_HOME to this path. Still getting the same. Regards Sachin On Fri, Jan 17, 2014 at 1:06 AM, Patrick Ohly wrote: > On Fri, 2014-01-17 at 00:02 +0530, Sachin Gupta wrote: >> Hi Patrick, >> >> Is it possible to force syncevolution to look for the configuration >> files (.config/syncevolution) in another folder than the home >> directory of the user? > > SyncEvolution follows the XDG spec. You can override $HOME/.config by > setting the XDG_CONFIG_HOME env variable. > > -- > 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 chingupt at gmail.com Fri Jan 17 05:51:40 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Fri, 17 Jan 2014 11:21:40 +0530 Subject: Changing the .config/syncevolution directory path In-Reply-To: References: <1389900964.16995.114.camel@pohly-mobl1.fritz.box> Message-ID: Hi, Pls ignore. Its working fine by setting this. Regrds On Jan 17, 2014 9:58 AM, "Sachin Gupta" wrote: > Hi, > > I did try that. exported XDG_CONFIG_HOME from .profile and then ran > the syncevolution. > Getting error. No such source(s): addressbook. > > I copied the .config contents to a dir and set the XDG_CONFIG_HOME to this > path. > Still getting the same. > > Regards > Sachin > > On Fri, Jan 17, 2014 at 1:06 AM, Patrick Ohly > wrote: > > On Fri, 2014-01-17 at 00:02 +0530, Sachin Gupta wrote: > >> Hi Patrick, > >> > >> Is it possible to force syncevolution to look for the configuration > >> files (.config/syncevolution) in another folder than the home > >> directory of the user? > > > > SyncEvolution follows the XDG spec. You can override $HOME/.config by > > setting the XDG_CONFIG_HOME env variable. > > > > -- > > 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. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From acdoon at gmail.com Wed Jan 15 11:54:10 2014 From: acdoon at gmail.com (anuj chauhan) Date: Wed, 15 Jan 2014 05:54:10 -0600 Subject: [SyncEvolution] How to defie the Maximum number of occurances for a property. Message-ID: Dear Patrick, I am developing a synevolution client using libsynthesis.I want to know that how do i tell a server maximum occurance supported by my client for a property.For Example: I have two different synchml clients as A and B. Client A can support 8 addresses under Email property. Client B supports only 3 address under email property. client A has saved contacts on a server where under Email property it has saved 8 mail addresses. Now how does B tells server that Max occuances of Email property supported by it can be 3 only. Regards , Anuj Chauhan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From chingupt at gmail.com Tue Jan 7 07:59:57 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Tue, 7 Jan 2014 13:29:57 +0530 Subject: Syncevolution for Windows Message-ID: Hi Patrick, Is there a Windows based version of Syncevolution also? Or is it possible to port the codebase to Windows? Regards From patrick.ohly at intel.com Tue Jan 7 08:24:50 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 07 Jan 2014 09:24:50 +0100 Subject: Syncevolution for Windows In-Reply-To: References: Message-ID: <1389083090.5855.302.camel@pohly-mobl1.fritz.box> On Tue, 2014-01-07 at 13:29 +0530, Sachin Gupta wrote: > Is there a Windows based version of Syncevolution also? Or is it > possible to port the codebase to Windows? There is no Windows version. Depending on which features you enable, porting may range from easy (no D-Bus, just SyncML, only the file backends) to hard (with D-Bus, local sync, CalDAV/CardDAV). Probably patches to the source code will be needed, both in SyncEvolution and libsynthesis. -- 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 chingupt at gmail.com Thu Jan 9 10:46:37 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Thu, 9 Jan 2014 16:16:37 +0530 Subject: Syncevolution for Windows In-Reply-To: <1389083090.5855.302.camel@pohly-mobl1.fritz.box> References: <1389083090.5855.302.camel@pohly-mobl1.fritz.box> Message-ID: Thanks Patrick, Can Syncevolution run under cygwin? Has it been tested with cygwin or you forsee any limitations/issues running in cygwin? Regards Sachin On Tue, Jan 7, 2014 at 1:54 PM, Patrick Ohly wrote: > On Tue, 2014-01-07 at 13:29 +0530, Sachin Gupta wrote: >> Is there a Windows based version of Syncevolution also? Or is it >> possible to port the codebase to Windows? > > There is no Windows version. Depending on which features you enable, > porting may range from easy (no D-Bus, just SyncML, only the file > backends) to hard (with D-Bus, local sync, CalDAV/CardDAV). > > Probably patches to the source code will be needed, both in > SyncEvolution and libsynthesis. > > -- > 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 Jan 9 11:51:34 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 09 Jan 2014 12:51:34 +0100 Subject: Syncevolution for Windows In-Reply-To: References: <1389083090.5855.302.camel@pohly-mobl1.fritz.box> Message-ID: <1389268294.5855.324.camel@pohly-mobl1.fritz.box> On Thu, 2014-01-09 at 16:16 +0530, Sachin Gupta wrote: > Can Syncevolution run under cygwin? > Has it been tested with cygwin or you forsee any limitations/issues > running in cygwin? I have not tested that. You'll still need to ensure that all required libraries are available. -- 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 T.Leiser at gmx.de Wed Jan 8 10:34:41 2014 From: T.Leiser at gmx.de (Thorsten Leiser) Date: Wed, 8 Jan 2014 11:34:41 +0100 Subject: [SyncEvolution] utf-8 not supported-error using syncevo-http-server Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Jan 8 11:24:32 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 08 Jan 2014 12:24:32 +0100 Subject: [SyncEvolution] utf-8 not supported-error using syncevo-http-server In-Reply-To: References: Message-ID: <1389180272.5855.311.camel@pohly-mobl1.fritz.box> On Wed, 2014-01-08 at 11:34 +0100, Thorsten Leiser wrote: > Hi, > > I'm using syncevolution-bundle 1.3.2-2 for syncing my nokia 515 dual > sim (S40 / V 09.04) with my OwnCloud 5-Server. > Currently it's a bluetooth sync one-way from my ubuntu 12.04 laptop to > the phone. > The sync goes like this: > Server via Cal-/CardDAV ==> local SyncEvo-DB via Bluetooth/OBEX ==> > Nokia 515 > The construct is runnig stable, so far so good. > Now I'm trying to use the syncevo-http-server to make a direct sync > between a ubuntu 12.04 server with my nokia phone. > I start the server with "syncevo-http-server > http://localhost:9000/syncml". > Now, if the phone tries to connect to the server, the sync stops and i > got the following error on the console: > > [INFO] syncevo-http: new SyncML session for 2.205.150.113 > [INFO] syncevo-dbus-server: /org/syncevolution/Server: ready to run > [ERROR] syncevo-dbus-server: /org/syncevolution/Server: message type > 'application/vnd.syncml+wbxml; charset=UTF-8' not supported for > starting a sync > > I tried the same procedure with the latest unstable version of the > syncevo-bundle, same error. Has anyone an idea? There is code to handle the extra "; charset=UTF-8", but only for XML messages (where it makes sense), and not for wbxml (where it probably is useless): src/dbus/server/connection.cpp: } else if (// relaxed checking for XML: ignore stuff like "; CHARSET=UTF-8" message_type.substr(0, message_type.find(';')) == TransportAgent::m_contentTypeSyncML || message_type == TransportAgent::m_contentTypeSyncWBXML) { Change the second comparison to message_type.substr(0, message_type.find(';')) == TransportAgent::m_contentTypeSyncWBXML and it should work. Can you recompile SyncEvolution? Otherwise you'll have to wait for 1.3.99.7. -- 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 Jan 2 08:12:29 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 02 Jan 2014 09:12:29 +0100 Subject: [SyncEvolution] Backend as Mysql In-Reply-To: References: Message-ID: <1388650349.5855.239.camel@pohly-mobl1.fritz.box> On Tue, 2013-12-31 at 16:45 +0530, Sachin Gupta wrote: > Is there support for MySQL as backend? i see that sqllite is > supported, but it seems to be used only for contacts, but not for cal > and todo. The sqlite backend is just a demo for programmers. It shows how to write a backend which converts directly from the internal data representation into a different, complex format (database schema in this case) without going through an intermediate text representation (like vCard). Using MySQL instead would be possible, but not very useful, because the conversion is not very complete. > Which one is suitable for Contacts, Calendar, Tasks together? > I need to be able to access this backend do some manipulation at > runtime before syncing with the server. For your purpose, you better use either: 1. The file backend (as in https://syncevolution.org/wiki/http-server-howto). Then you can directly manipulate each item with a text editor, shell tools or in your own program. 2. EDS or Akonadi with SyncEvolution's command line to manipulate items. See https://syncevolution.org/wiki/item-operations -- 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 chingupt at gmail.com Thu Jan 2 09:25:14 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Thu, 2 Jan 2014 14:55:14 +0530 Subject: [SyncEvolution] Backend as Mysql In-Reply-To: <1388650349.5855.239.camel@pohly-mobl1.fritz.box> References: <1388650349.5855.239.camel@pohly-mobl1.fritz.box> Message-ID: Thanks Patrick. Could you please elaborate more on "but not very useful, because the conversion is not very complete." What conversion you are referring to? PS: We have dropped the idea of using MySQL as a backend and plan to extend sqlite to calenders also. Best Regards Sachin On Thu, Jan 2, 2014 at 1:42 PM, Patrick Ohly wrote: > On Tue, 2013-12-31 at 16:45 +0530, Sachin Gupta wrote: >> Is there support for MySQL as backend? i see that sqllite is >> supported, but it seems to be used only for contacts, but not for cal >> and todo. > > The sqlite backend is just a demo for programmers. It shows how to write > a backend which converts directly from the internal data representation > into a different, complex format (database schema in this case) without > going through an intermediate text representation (like vCard). Using > MySQL instead would be possible, but not very useful, because the > conversion is not very complete. > >> Which one is suitable for Contacts, Calendar, Tasks together? >> I need to be able to access this backend do some manipulation at >> runtime before syncing with the server. > > For your purpose, you better use either: > 1. The file backend (as in > https://syncevolution.org/wiki/http-server-howto). Then you can > directly manipulate each item with a text editor, shell tools or > in your own program. > 2. EDS or Akonadi with SyncEvolution's command line to manipulate > items. See https://syncevolution.org/wiki/item-operations > > -- > 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 Jan 2 09:38:49 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 02 Jan 2014 10:38:49 +0100 Subject: [SyncEvolution] Backend as Mysql In-Reply-To: References: <1388650349.5855.239.camel@pohly-mobl1.fritz.box> Message-ID: <1388655529.5855.249.camel@pohly-mobl1.fritz.box> On Thu, 2014-01-02 at 14:55 +0530, Sachin Gupta wrote: > Thanks Patrick. > > Could you please elaborate more on > "but not very useful, because the conversion is not very complete." > > What conversion you are referring to? The conversion of the internal representation to and from the demo sqlite schema. Several properties are not getting stored. > PS: We have dropped the idea of using MySQL as a backend and plan to > extend sqlite to calenders also. That's certainly a useful programming exercise. I am not sure whether it's suitable for a production system, though, if that's what you intend to achieve. If you need a database as storage instead of EDS or the plain files, then you might also want to look at the sqlite support in libsynthesis. See chapter "12. , : SQL/ODBC based Server or Client Config" in libsynthesis/doc/SySync_config_reference.pdf It's probably going to be more complete and better tested. SyncEvolution does not use that mode, it always runs as server or client type='plugin'. It should be possible to change that. -- 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 chingupt at gmail.com Fri Jan 3 16:03:05 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Fri, 3 Jan 2014 21:33:05 +0530 Subject: [SyncEvolution] Backend as Mysql In-Reply-To: <1388655529.5855.249.camel@pohly-mobl1.fritz.box> References: <1388650349.5855.239.camel@pohly-mobl1.fritz.box> <1388655529.5855.249.camel@pohly-mobl1.fritz.box> Message-ID: Will try and let you know. I however tried compiling syncevolution with --enable-sqlite, still uses file based data store for contacts. There were no compilation issues and configure showed sqlite selected as Yes. Do i need to do something else to enable sqlite? Or sqlite backend is showcased only as an example in the bundle? Regards Sachin On Thu, Jan 2, 2014 at 3:08 PM, Patrick Ohly wrote: > On Thu, 2014-01-02 at 14:55 +0530, Sachin Gupta wrote: >> Thanks Patrick. >> >> Could you please elaborate more on >> "but not very useful, because the conversion is not very complete." >> >> What conversion you are referring to? > > The conversion of the internal representation to and from the demo > sqlite schema. Several properties are not getting stored. > >> PS: We have dropped the idea of using MySQL as a backend and plan to >> extend sqlite to calenders also. > > That's certainly a useful programming exercise. I am not sure whether > it's suitable for a production system, though, if that's what you intend > to achieve. > > If you need a database as storage instead of EDS or the plain files, > then you might also want to look at the sqlite support in libsynthesis. > See chapter "12. , : > SQL/ODBC based Server or Client Config" in > libsynthesis/doc/SySync_config_reference.pdf > > It's probably going to be more complete and better tested. > > SyncEvolution does not use that mode, it always runs as server or client > type='plugin'. It should be possible to change that. > > -- > 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 Mon Jan 6 06:58:09 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 06 Jan 2014 07:58:09 +0100 Subject: [SyncEvolution] Backend as Mysql In-Reply-To: References: <1388650349.5855.239.camel@pohly-mobl1.fritz.box> <1388655529.5855.249.camel@pohly-mobl1.fritz.box> Message-ID: <1388991489.5855.283.camel@pohly-mobl1.fritz.box> On Fri, 2014-01-03 at 21:33 +0530, Sachin Gupta wrote: > Will try and let you know. I however tried compiling syncevolution > with --enable-sqlite, still uses file based data store for contacts. > There were no compilation issues and configure showed sqlite selected as Yes. > > Do i need to do something else to enable sqlite? Or sqlite backend is > showcased only as an example in the bundle? You need to select the backend for your source. It does not automatically become the default "backend=addressbook" provider. In other words, explicitly do "syncevolution --configure backend=sqlite database= @default addressbook". -- 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.