From janumix at poczta.fm Sat Jan 2 16:46:22 2016 From: janumix at poczta.fm (Janusz) Date: Sat, 2 Jan 2016 17:46:22 +0100 Subject: [SyncEvolution] Syncevolution --print-databases In-Reply-To: <1451591860.23712.11.camel@intel.com> References: <1627825.lz3JYRGpPR@delle5450> <1904727.yb8XxoKel8@domowy> <1451591860.23712.11.camel@intel.com> Message-ID: <1597409.WHt9kJYVeR@domowy> Dnia Thursday 31 of December 2015 20:57:40 Patrick Ohly pisze: > On Wed, 2015-12-30 at 23:23 +0100, Janusz wrote: > > Thanks for answer. > > > > I forgot to add that the same behaviour is on 2 PCs - both Ubuntu > > Wily. > > > > > > > > This output is from second one: > > > > > > > > $ SYNCEVOLUTION_DEBUG=1 syncevolution loglevel=3 --print-databases > > --daemon=no > > ... > > > Evolution Task List = Evolution Tasks = evolution-tasks: > > Osobiste (system-task-list) > > > > Evolution Memos = evolution-memos: > > Osobiste (system-memo-list) > > And it gets stuck here? > > If yes, then run under gdb: > > gdb --args syncevolution loglevel=10 --print-databases --daemon=no > # run > ... > CTRL-C once it is stuck > # threads all apply bt > > What is the output? Yes, it stuck there. Here is output: $ gdb --args syncevolution loglevel=10 --print-databases --daem BRJanusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Sat Jan 2 19:48:55 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sat, 02 Jan 2016 20:48:55 +0100 Subject: [SyncEvolution] Syncevolution --print-databases In-Reply-To: <1597409.WHt9kJYVeR@domowy> References: <1627825.lz3JYRGpPR@delle5450> <1904727.yb8XxoKel8@domowy> <1451591860.23712.11.camel@intel.com> <1597409.WHt9kJYVeR@domowy> Message-ID: <1451764135.23712.21.camel@intel.com> On Sat, 2016-01-02 at 17:46 +0100, Janusz wrote: > Dnia Thursday 31 of December 2015 20:57:40 Patrick Ohly pisze: > Yes, it stuck there. > > Here is output: > > > > $ gdb --args syncevolution loglevel=10 --print-databases --daem > on=no > GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10 [...] > Thread 1 (Thread 0x7ffff7f2b880 (LWP 5810)): > #0 0x00007ffff66638dd in poll () > at ../sysdeps/unix/syscall-template.S:81 > #1 0x00007ffff71241ec in ?? () > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #2 0x00007ffff71242fc in g_main_context_iteration () > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #3 0x00007fffead461ee in > QEventDispatcherGlib::processEvents(QFlags > to continue, or q to quit--- > :ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 > #4 0x00007fffead140d1 in > QEventLoop::processEvents(QFlags) () > from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 > #5 0x00007fffead14445 in > QEventLoop::exec(QFlags) () > from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 > #6 0x00007fffea7d8363 in KJob::exec() () > from /usr/lib/libkdecore.so.5 > #7 0x00007fffeb5afcf0 in SyncEvo::AkonadiSyncSource::getDatabases ( > this=0x793d00) > at /data/runtests/work/sources/syncevolution/src/backends/akonadi/akonadisyncsource.cpp:137 > #8 0x00007ffff758c3c5 in SyncEvo::Cmdline::listDatabases ( > this=, source=0x793d00, header= > "KDE Address Book = KDE Contacts = kde-contacts") > at /data/runtests/work/sources/syncevolution/src/syncevo/Cmdline.cpp:2087 > #9 0x00007ffff759efe0 in SyncEvo::Cmdline::run (this=0x7fffffffd700) > at /data/runtests/work/sources/syncevolution/src/syncevo/Cmdline.cpp:839 > #10 0x000000000041a90d in SyncEvo::main (argc=, > argv=) > at /data/runtests/work/sources/syncevolution/src/syncevolution.cpp:531 > (gdb) KJob::exec() is supposed to return when the work is done; that doesn't seem to work anymore. Have you tried with SYNCEVOLUTION_DEBUG=1 and --log-level=10? There might be some error output from Akonadi which is hidden during normal command line operation (many libs typically used by graphical applications are fairly noisy, so SyncEvolution hides normal stdout). Perhaps try simplifying the process in which the call happens: temporarily move away all backends except syncakonadi.so and platformkde.so, then try again. If that fails, also move away platformkde.so and try one last time. If that still fails, one could try to write a very simple test program with getDatabases() as main(): http://cgit.freedesktop.org/SyncEvolution/syncevolution/tree/src/backends/akonadi/akonadisyncsource.cpp#n116 Do you think you can do that? I don't have Ubuntu 15.10 installed at the moment. -- 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 janumix at poczta.fm Sun Jan 3 15:24:21 2016 From: janumix at poczta.fm (Janusz) Date: Sun, 3 Jan 2016 16:24:21 +0100 Subject: [SyncEvolution] Syncevolution --print-databases In-Reply-To: <1451764135.23712.21.camel@intel.com> References: <1627825.lz3JYRGpPR@delle5450> <1597409.WHt9kJYVeR@domowy> <1451764135.23712.21.camel@intel.com> Message-ID: <3863546.ztQrUHjVRk@domowy> Dnia Saturday 02 of January 2016 20:48:55 Patrick Ohly pisze: > On Sat, 2016-01-02 at 17:46 +0100, Janusz wrote: > > Dnia Thursday 31 of December 2015 20:57:40 Patrick Ohly pisze: > > Yes, it stuck there. > > > > Here is output: > > > > > > > > $ gdb --args syncevolution loglevel=10 --print-databases --daem > > on=no > > GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10 > > [...] > > > Thread 1 (Thread 0x7ffff7f2b880 (LWP 5810)): > > #0 0x00007ffff66638dd in poll () > > at ../sysdeps/unix/syscall-template.S:81 > > #1 0x00007ffff71241ec in ?? () > > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > > #2 0x00007ffff71242fc in g_main_context_iteration () > > > > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > > > > #3 0x00007fffead461ee in > > QEventDispatcherGlib::processEvents(QFlags > > to continue, or q to quit--- > > > > :ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 > > > > #4 0x00007fffead140d1 in > > QEventLoop::processEvents(QFlags) () > > from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 > > #5 0x00007fffead14445 in > > QEventLoop::exec(QFlags) () > > from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 > > #6 0x00007fffea7d8363 in KJob::exec() () > > from /usr/lib/libkdecore.so.5 > > #7 0x00007fffeb5afcf0 in SyncEvo::AkonadiSyncSource::getDatabases ( > > > > this=0x793d00) > > at > > /data/runtests/work/sources/syncevolution/src/backends/akonadi/akonadi > > syncsource.cpp:137> > > #8 0x00007ffff758c3c5 in SyncEvo::Cmdline::listDatabases ( > > > > this=, source=0x793d00, header= > > "KDE Address Book = KDE Contacts = kde-contacts") > > at > > /data/runtests/work/sources/syncevolution/src/syncevo/Cmdline.cpp:2087 > > > > #9 0x00007ffff759efe0 in SyncEvo::Cmdline::run (this=0x7fffffffd700) > > > > at > > /data/runtests/work/sources/syncevolution/src/syncevo/Cmdline.cpp:839 > > > > #10 0x000000000041a90d in SyncEvo::main (argc=, > > > > argv=) > > at /data/runtests/work/sources/syncevolution/src/syncevolution.cpp:531 > > > > (gdb) > > KJob::exec() is supposed to return when the work is done; that doesn't > seem to work anymore. > > Have you tried with SYNCEVOLUTION_DEBUG=1 and --log-level=10? There > might be some error output from Akonadi which is hidden during normal > command line operation (many libs typically used by graphical > applications are fairly noisy, so SyncEvolution hides normal stdout). > > Perhaps try simplifying the process in which the call happens: > temporarily move away all backends except syncakonadi.so and > platformkde.so, then try again. If that fails, also move away > platformkde.so and try one last time. > > If that still fails, one could try to write a very simple test program > with getDatabases() as main(): > http://cgit.freedesktop.org/SyncEvolution/syncevolution/tree/src/backends/ak > onadi/akonadisyncsource.cpp#n116 > > Do you think you can do that? I don't have Ubuntu 15.10 installed at the > moment. With SYNCEVOLUTION_DEBUG=1 (--log-level=10 is unkonw parameter) : $ SYNCEVOLUTION_DEBUG=1 syncevolution --print-databases I moved all backend to temporary directory and did these test. Result seems to be the same (finally I killed syncevol porcesses). $ s dpkg -l \*evol\* :/usr/lib/syncevolution/backends$ ls -la total 98936 drwxr-xr-x 2 root root 4096 Dec 29 23:37 . drwxr-xr-x 4 root root 4096 Dec 29 23:37 .. -rwxr-xr-x 1 root root 1369 Jun 5 2015 platformgnome.la -rwxr-xr-x 1 root root 891771 Jun 5 2015 platformgnome.so -rwxr-xr-x 1 root root 1397 Jun 5 2015 platformkde.la -rwxr-xr-x 1 root root 1354257 Jun 5 2015 platformkde.so -rwxr-xr-x 1 root root 1341 Jun 5 2015 providergoa.la -rwxr-xr-x 1 root root 1371751 Jun 5 2015 providergoa.so -rwxr-xr-x 1 root root 1379 Jun 5 2015 provideroauth2.la -rwxr-xr-x 1 root root 266882 Jun 5 2015 provideroauth2.so -rwxr-xr-x 1 root root 460278 Jun 5 2015 provideruoa-2.so -rwxr-xr-x 1 root root 1386 Jun 5 2015 syncactivesync.la -rwxr-xr-x 1 root root 1411 Jun 5 2015 syncakonadi.la -rwxr-xr-x 1 root root 5588925 Jun 5 2015 syncakonadi.so -rwxr-xr-x 1 root root 1344 Jun 5 2015 syncdav.la -rwxr-xr-x 1 root root 12045467 Jun 5 2015 syncdav.so -rwxr-xr-x 1 root root 8311188 Jun 5 2015 syncebook-2.so -rwxr-xr-x 1 root root 8311188 Jun 5 2015 syncebook-3.so -rwxr-xr-x 1 root root 8311188 Jun 5 2015 syncebook-4.so -rwxr-xr-x 1 root root 1329 Jun 5 2015 syncebook.la -rwxr-xr-x 1 root root 5085031 Jun 5 2015 syncebook.so -rwxr-xr-x 1 root root 7642379 Jun 5 2015 syncecal-2.so -rwxr-xr-x 1 root root 7642379 Jun 5 2015 syncecal-3.so -rwxr-xr-x 1 root root 7642379 Jun 5 2015 syncecal-4.so -rwxr-xr-x 1 root root 7642379 Jun 5 2015 syncecal-5.so -rwxr-xr-x 1 root root 7642379 Jun 5 2015 syncecal-6.so -rwxr-xr-x 1 root root 1323 Jun 5 2015 syncecal.la -rwxr-xr-x 1 root root 5256249 Jun 5 2015 syncecal.so -rwxr-xr-x 1 root root 1323 Jun 5 2015 syncfile.la -rwxr-xr-x 1 root root 4750854 Jun 5 2015 syncfile.so -rwxr-xr-x 1 root root 1371 Jun 5 2015 synckcalextended.la -rwxr-xr-x 1 root root 167058 Jun 5 2015 synckcalextended.so -rwxr-xr-x 1 root root 1347 Jun 5 2015 syncmaemocal.la -rwxr-xr-x 1 root root 165612 Jun 5 2015 syncmaemocal.so -rwxr-xr-x 1 root root 1323 Jun 5 2015 syncpbap.la -rwxr-xr-x 1 root root 163423 Jun 5 2015 syncpbap.so -rwxr-xr-x 1 root root 1359 Jun 5 2015 syncqtcontacts.la -------------- next part -------------- An HTML attachment was scrubbed... URL: From singpolyma at singpolyma.net Sat Jan 9 16:55:00 2016 From: singpolyma at singpolyma.net (Stephen Paul Weber) Date: Sat, 9 Jan 2016 11:55:00 -0500 Subject: [SyncEvolution] Sync to a flat file? Message-ID: <20160109165500.GA2983@singpolyma-liberty> Is it possible to configure syncevolution to have the "local" side be an ical or vcard file (for events or contacts)? If not, does anyone know of an application that would allow me to sync caldav/carddav to files like this? -- Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sat Jan 9 19:04:35 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sat, 09 Jan 2016 20:04:35 +0100 Subject: [SyncEvolution] Sync to a flat file? In-Reply-To: <20160109165500.GA2983@singpolyma-liberty> References: <20160109165500.GA2983@singpolyma-liberty> Message-ID: <1452366275.17716.57.camel@intel.com> On Sat, 2016-01-09 at 11:55 -0500, Stephen Paul Weber wrote: > Is it possible to configure syncevolution to have the "local" side be an > ical or vcard file (for events or contacts)? Not directly. The closest options are: * file backend (internal to SyncEvolution, no other dependencies) with one item (contact or event) per file in a directory * EDS calendar, with a single ical file stored under ~/.local/share/evolution/calendar/ - does not work for contacts, which EDS stores in a database * KDE backend with suitable KDE resources defined - I believe those can be plain ical and vcard files -- 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 singpolyma at singpolyma.net Tue Jan 12 15:18:02 2016 From: singpolyma at singpolyma.net (Stephen Paul Weber) Date: Tue, 12 Jan 2016 10:18:02 -0500 Subject: [SyncEvolution] Sync to a flat file? In-Reply-To: <1452366275.17716.57.camel@intel.com> References: <20160109165500.GA2983@singpolyma-liberty> <1452366275.17716.57.camel@intel.com> Message-ID: <20160112151802.GC2687@singpolyma-liberty> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >Not directly. The closest options are: > * file backend (internal to SyncEvolution, no other dependencies) > with one item (contact or event) per file in a directory This sounds like a good start, at least. How do I set that up? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWlRkqAAoJENEcKRHOUZzenMgP/0QDk3tskQsK5EV2DfUVKJqI 84Ag5JXUdufQgnqieIxV0ztTZd43YptjubA6jSzFveT5Rc+S7Muc6AptKggYsRPN eZO4oAx9C3e8K6ZqUz+FIQh+wzGQxy7u5kzyMfCRvyMoDPtd0kbTWcgjc5VWcuQ0 wslNJP4FkRgg2WuiWU2IpaxDrkd0JdYzmeRI651oguNvZe1ZXMV7+kwlLiUVbmTX g7ZB3rINMGNXtGtt0bHj9WdMmbixwkUfoRSd4zkzsDPXYp6Df+sSOneE7OIlJQqi jlQhu/cqJj1ACTyO9MabwRz57sp+LQ4RO+g9cR0P9aL7reWaCg2inPZljpK20QuY g7Etclrx1OZkTwp+xhgHOd/6fDUDlTzoK/I3k1m+Rj3xi4UhiQX8G972Vm2pwkNI 606iFjMfamApBDB5W9tu5R+SrHOoTP/cBNFHvD0b/kbyBwhCPTWVU0xMYIZzem1I FaFwfS1nrx1s8uu1t0tlA0cm9UCc8b767F59TsRvqfmWeIPlFYeqVvACLFAbrAnR iyjB8g2wrZjNQrS3qVgzTTx3Fabn1UvOKeV1NYxWNOfvqT+OQUrbLGL89dy/0+Ah p1I3qU9Ti6kkN4BFS3j84ne+G5XYU/XNvdmRlz/7HRwS/QaJp/csoNPxcu0F4Auq 8Ze+jVdbr/2RQ5OXXxIF =xo3M -----END PGP SIGNATURE----- From patrick.ohly at intel.com Tue Jan 12 15:26:20 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 12 Jan 2016 16:26:20 +0100 Subject: [SyncEvolution] Sync to a flat file? In-Reply-To: <20160112151802.GC2687@singpolyma-liberty> References: <20160109165500.GA2983@singpolyma-liberty> <1452366275.17716.57.camel@intel.com> <20160112151802.GC2687@singpolyma-liberty> Message-ID: <1452612380.32091.0.camel@intel.com> On Tue, 2016-01-12 at 10:18 -0500, Stephen Paul Weber wrote: > >Not directly. The closest options are: > > * file backend (internal to SyncEvolution, no other dependencies) > > with one item (contact or event) per file in a directory > > This sounds like a good start, at least. How do I set that up? Here's a HOWTO using that backend: https://syncevolution.org/wiki/http-server-howto -- 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 singpolyma at singpolyma.net Tue Jan 12 15:32:11 2016 From: singpolyma at singpolyma.net (Stephen Paul Weber) Date: Tue, 12 Jan 2016 10:32:11 -0500 Subject: [SyncEvolution] Sync to a flat file? In-Reply-To: <1452612380.32091.0.camel@intel.com> References: <20160109165500.GA2983@singpolyma-liberty> <1452366275.17716.57.camel@intel.com> <20160112151802.GC2687@singpolyma-liberty> <1452612380.32091.0.camel@intel.com> Message-ID: <20160112153211.GD2687@singpolyma-liberty> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Somebody claiming to be Patrick Ohly wrote: >On Tue, 2016-01-12 at 10:18 -0500, Stephen Paul Weber wrote: >> >Not directly. The closest options are: >> > * file backend (internal to SyncEvolution, no other dependencies) >> > with one item (contact or event) per file in a directory >> >> This sounds like a good start, at least. How do I set that up? > >Here's a HOWTO using that backend: > >https://syncevolution.org/wiki/http-server-howto That page seems to be about using syncevo as an HTTP server (not sure what that would even do...). I want to use it as a client (for a CalDAV server) with the "file" backend. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWlRx7AAoJENEcKRHOUZzenIcP/Rv+B0iAYDRvPwCiUu0vgFlt omMupli99zaA1LXrdA6gfkeNCf5j/KLi61KAKdqr+aLsjqwyyVt7Effz4+I+T18o diBwrgA85BBFAW9d366knG0ySk1atErw33VYNUKSpqGUz43PKztvDIy4/NYVmpa5 zCrDN3ScppCJq4YHRAIJWjR+6GOFP1URkdylbgBiIgLpTX0IIKIdlJTy7PZgA2rB 3kEfbrz+icUiTtpsU3HGzVVQ/hpHy6ab+ukw7Hom9oPvvdOtQAyfubqDV39IBJat 0FZ4HnclAIAj9279a3nwm1cEFlzecjA2TFXvw/V+WsHd1pp5vFpUSCUrl6sM66Kb fHWL0HVYZL1vzWVb3W3d03bJOYrfOB8meWUMIDTR0aLPfdaX/chLjWgkZcEr+R0M 2lY77vMt2IPTmRAnaHgBpBnopzstFeyjFyMwRn5RQW5w2N+RJa3QpcEfCkibhxEF DICmZaSljW73LtDFu9UbVtoUjgU1DRXBs45gtQb9BBF/F1GZk3hlhmseUJu30ypB f9TDZUsQ01sP2XIkxapvxi8YDOHg7Ag3zv4hQXJnQ0Bk6YMfgp+uwg/zfz26Lnkp KMoyKCOcxVlsU0AyihCTWEMbzo0GxQPeSdzlvUD2INukQAllFOAQttGXD6Ldy/cf Z43sx93gjpRGmcBWp63j =K7P0 -----END PGP SIGNATURE----- From patrick.ohly at intel.com Tue Jan 12 15:36:27 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 12 Jan 2016 16:36:27 +0100 Subject: [SyncEvolution] Sync to a flat file? In-Reply-To: <20160112153211.GD2687@singpolyma-liberty> References: <20160109165500.GA2983@singpolyma-liberty> <1452366275.17716.57.camel@intel.com> <20160112151802.GC2687@singpolyma-liberty> <1452612380.32091.0.camel@intel.com> <20160112153211.GD2687@singpolyma-liberty> Message-ID: <1452612987.32091.8.camel@intel.com> On Tue, 2016-01-12 at 10:32 -0500, Stephen Paul Weber wrote: > Somebody claiming to be Patrick Ohly wrote: > >On Tue, 2016-01-12 at 10:18 -0500, Stephen Paul Weber wrote: > >> >Not directly. The closest options are: > >> > * file backend (internal to SyncEvolution, no other dependencies) > >> > with one item (contact or event) per file in a directory > >> > >> This sounds like a good start, at least. How do I set that up? > > > >Here's a HOWTO using that backend: > > > >https://syncevolution.org/wiki/http-server-howto > > That page seems to be about using syncevo as an HTTP server (not sure what > that would even do...). I want to use it as a client (for a CalDAV server) > with the "file" backend. For that you need to adapt the part about configuring the local side of the CalDAV such that the local side uses the file. That part is identical to setting up the datastores (called sources in those HOWTOs) in the server case. -- 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 singpolyma at singpolyma.net Tue Jan 12 15:54:19 2016 From: singpolyma at singpolyma.net (Stephen Paul Weber) Date: Tue, 12 Jan 2016 10:54:19 -0500 Subject: [SyncEvolution] Sync to a flat file? In-Reply-To: <1452612987.32091.8.camel@intel.com> References: <20160109165500.GA2983@singpolyma-liberty> <1452366275.17716.57.camel@intel.com> <20160112151802.GC2687@singpolyma-liberty> <1452612380.32091.0.camel@intel.com> <20160112153211.GD2687@singpolyma-liberty> <1452612987.32091.8.camel@intel.com> Message-ID: <20160112155419.GF2687@singpolyma-liberty> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >Here's a HOWTO using that backend: >> > >> >https://syncevolution.org/wiki/http-server-howto >> >For that you need to adapt the part about configuring the local side of >the CalDAV such that the local side uses the file. That part is >identical to setting up the datastores (called sources in those HOWTOs) >in the server case. Thanks! I think I'm getting closer. Combining with , here is my attempted config script: (obviously I have revoked that password after pasting) and the output when running with `sh - -x`: -- should I be using - --template none ? Thanks for the help. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWlSGrAAoJENEcKRHOUZzemycQALy0r56uWGN+bzOHj/KVUOPc vD0k5OWJxrl+WSjruotIeFvoLi9eq2wfIAgAeGRZsb4wVYrjhsj+3uY4ZHqUBdR9 KqJkP0/MWxyCeXKFzZbMmxWmV9UJYSJENhZPQHNFH7PF9XmNMfJPTZfRcGHBi51c k8xcuYBEebj60J8/7B2wEWckK16pG7XhItU+1Kbe8m46/p2hykLFBqzwdgnRj21o AmGg9CUa4nFu2U3fAyKGLc72ONVWHh+Mbylk0/08oO+zAbOqGkJmqASwj+KnvvlE owCiMH4YHgJ1GqNmVVWGTfvo9K7rhzkhp7gUNaoEzxHM5NfgPGYYEO2k1p7UjXNN w+dtFeen4TKjXry64HTPwT38gC128CWL6Kc5Lxr9uqLj+JSC2oQvl84lajJ0Kigl YcCdTOXZhHYkQ5yReYR9vc8ki3NJwBICS8ud2intml9AFy1NaOie9TkOd7/hyOHu 3LAvaGUJdPC7vNgh0XsONqoZR802MDnbVmtJPopEmM04OO9iojAdWezdtGDLVfWn efHlnOGntYn88ElZyBiU2hUu8SAOQafC1uACCJ7RbkPtKvwY3sQcodJ4Am/zBf3q kMHHx6XHSQRALxg10zswUAspAUwZ7N9iTh6FTaq3OU9HByK36nKv6KROYWEud5Ap +w7lTy4yq6YKOP2aZfRN =pYOI -----END PGP SIGNATURE----- From patrick.ohly at intel.com Sun Jan 24 13:00:31 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 24 Jan 2016 14:00:31 +0100 Subject: [SyncEvolution] Sync to a flat file? In-Reply-To: <20160112155419.GF2687@singpolyma-liberty> References: <20160109165500.GA2983@singpolyma-liberty> <1452366275.17716.57.camel@intel.com> <20160112151802.GC2687@singpolyma-liberty> <1452612380.32091.0.camel@intel.com> <20160112153211.GD2687@singpolyma-liberty> <1452612987.32091.8.camel@intel.com> <20160112155419.GF2687@singpolyma-liberty> Message-ID: <1453640431.19402.28.camel@intel.com> On Tue, 2016-01-12 at 10:54 -0500, Stephen Paul Weber wrote: > >> >Here's a HOWTO using that backend: > >> > > >> >https://syncevolution.org/wiki/http-server-howto > >> > >For that you need to adapt the part about configuring the local side of > >the CalDAV such that the local side uses the file. That part is > >identical to setting up the datastores (called sources in those HOWTOs) > >in the server case. > > Thanks! I think I'm getting closer. Combining with > , here is my > attempted config script: (obviously I have > revoked that password after pasting) and the output when running with `sh > -x`: -- should I be using > --template none ? Sorry for the late reply. When I tried looking at the output today, I got an error from the pastie.org frontend (CloudFare) about pastie.org being down. Can you repost the text as compressed (if large) attachments? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Thu Jan 28 20:30:34 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 28 Jan 2016 21:30:34 +0100 Subject: [SyncEvolution] Syncevolution for TDE (8) Message-ID: Patrick, thanks for replying! (I had to repost this from this gmail, because I got non dlivrable msg from yahoo server - "5.3.0 - Other mail system problem 550-"5.7.1 Unauthenticated email from yahoo.com is not accepted due to domain's\n5.7.1 DMARC policy.") So here is what I see when I build "shared" ("statics" - I see only one desc of the module) Currently active:: CalDAV ... TDE PIM Address Book = TDE PIM Contacts = addressbook = contacts = tdepim-contacts ... TDE PIM Address Book = TDE PIM Contacts = addressbook = contacts = tdepim-contacts ... TDE PIM Calendar = calendar = events = tdepim-events ... TDE PIM Task List = TDE Tasks = todo = tasks = tdepim-tasks ... TDE PIM Memos = memo = memos = tdepim-memos ... TDE PIM Calendar = calendar = events = tdepim-events ... TDE PIM Task List = TDE Tasks = todo = tasks = tdepim-tasks ... TDE PIM Memos = memo = memos = tdepim-memos ... bin/syncevolution --version SyncEvolution 1.5.1 Loading backend library /tmp/test/lib/syncevolution/backends/syncxmlrpc.so Loading backend library /tmp/test/lib/syncevolution/backends/synctdepimcal.so <<<< my cal module Loading backend library /tmp/test/lib/syncevolution/backends/synctdepimabc.so <<<< my address book module Loading backend library /tmp/test/lib/syncevolution/backends/syncsqlite.so ... Loading backend library /tmp/test/lib/syncevolution/backends/syncdav.so Loading backend library /tmp/test/lib/syncevolution/backends/syncakonadi.so Loading backend library /tmp/test/lib/syncevolution/backends/syncactivesync.so Loading backend library /tmp/test/lib/syncevolution/backends/providergoa.so Loading backend library /tmp/test/lib/syncevolution/backends/platformkde.so Loading backend library /tmp/test/lib/syncevolution/backends/platformgnome.so Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From deloptes at yahoo.com Thu Jan 28 17:56:08 2016 From: deloptes at yahoo.com (Emanoil Kotsev) Date: Thu, 28 Jan 2016 17:56:08 +0000 Subject: [SyncEvolution] Syncevolution for TDE In-Reply-To: <1811077177.1597401.1450743211222.JavaMail.yahoo@mail.yahoo.com> References: <1450735349.18547.141.camel@intel.com> <1811077177.1597401.1450743211222.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1362627232.1372588.1454003768915.JavaMail.yahoo@mail.yahoo.com> Hi again, When I compile with --enable-shared my module comes up twice when I call --datastore-properties ?When I compile static it shows up just once. I installed in /tmp/test or ~/test-syncevo and setup some variables. What could be the reason? thanks in advance - regards On Tuesday, December 22, 2015 1:13 AM, Emanoil Kotsev wrote: >> TDE is the former KDE3 project. I'll need to have a look into the >> details on the interfaces, but it looks possible. > >I don't know how far back KCal goes, but perhaps at least that API is >similar. Well KCal might have not changed much, but in KDE4 akonadi provides a unified interface afaik.Thanks again for the summary, I now have a much better understanding what is there for what reason in syncevolution. I think I'll find my way through that. > >> >> 1. Is there a way to sync with TDE? without writing backends for TDE? >> >> I ask this in the bluetooth/usb context. >> > >> >I don't know what kind of storage TDE supports. It's likely that you >> >will have to write a backend for its PIM API. >> >> Thanks I had a look in the past days just to find out that new bluez5 >> works much different (and perhaps better), but still could be the real >> challenge here. > >SyncEvolution interfaces to Bluetooth via libopenobex, which talks >directly to the kernel. That part should work right away, also with >Bluez5.Yes indeed I was able to configure, pair and connect to the Nokia 5530 and N9 also from within TDE using the gnome tools The problem is that bluetooth was poorly supported in KDE3, so I think if one aims to do the bluetooth part without gnome tools could be chalinging. But it might be off topic here. >From what I recall from the opensync project the KDE3 did not have unified API, but it shouldn't be hard to get working and I have never had issues on that side. > >> >> 2. Where do I start and what process should I follow to integrate the >> >> code into the build and in the gui? >> > >> >Backends get detected automatically when placed in src/backends, so just >> >copy-and-paste, modify, then re-run autogen + configure + make. >> >> Oh, thanks, however I have seen some checks and options to >> disable/enable KDE4+ and Gnome linking in the code (I got from git). >> So the question was more about how could I disable nearly everything >> else except for what I want to test. Is there any (documented) process >> on how to modify or just hack the automake files > >Once you ran autogen.sh, the resulting configure has enable/disable >options for all backends. There's no need to change the autotools source Ok thanks, so it really adopts the backend specific features as provided by the am and configure-sub.in files thanks a lot, wish me luck On Monday, December 21, 2015 11:02 PM, Patrick Ohly wrote: On Mon, 2015-12-21 at 20:45 +0000, Emanoil Kotsev wrote: > >> May I ask for your opinion please - what would be the steps or send me > >> web links to docs as I'm getting lost in the documentation? > > > >Depending on the kind of PIM storage you need to interface with you need > >to implement different interfaces. Most storages support > >importing/exporting items in a standard format (like vCard or iCalendar) > >and offer some kind of item listing. The TrackingSyncSource is a good > >base class for this and comes with full documentation of all virtua > >methods that one may have to implement. > > TDE is the former KDE3 project. I'll need to have a look into the > details on the interfaces, but it looks possible. I don't know how far back KCal goes, but perhaps at least that API is similar. > >> 1. Is there a way to sync with TDE? without writing backends for TDE? > >> I ask this in the bluetooth/usb context. > > > >I don't know what kind of storage TDE supports. It's likely that you > >will have to write a backend for its PIM API. > > Thanks I had a look in the past days just to find out that new bluez5 > works much different (and perhaps better), but still could be the real > challenge here. SyncEvolution interfaces to Bluetooth via libopenobex, which talks directly to the kernel. That part should work right away, also with Bluez5. > >> 2. Where do I start and what process should I follow to integrate the > >> code into the build and in the gui? > > > >Backends get detected automatically when placed in src/backends, so just > >copy-and-paste, modify, then re-run autogen + configure + make. > > Oh, thanks, however I have seen some checks and options to > disable/enable KDE4+ and Gnome linking in the code (I got from git). > So the question was more about how could I disable nearly everything > else except for what I want to test. Is there any (documented) process > on how to modify or just hack the automake files Once you ran autogen.sh, the resulting configure has enable/disable options for all backends. There's no need to change the autotools source files. -- 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 Thu Jan 28 19:46:55 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 28 Jan 2016 20:46:55 +0100 Subject: [SyncEvolution] Syncevolution for TDE In-Reply-To: <1362627232.1372588.1454003768915.JavaMail.yahoo@mail.yahoo.com> References: <1450735349.18547.141.camel@intel.com> <1811077177.1597401.1450743211222.JavaMail.yahoo@mail.yahoo.com> <1362627232.1372588.1454003768915.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1454010415.24815.50.camel@intel.com> On Thu, 2016-01-28 at 17:56 +0000, Emanoil Kotsev wrote: > Hi again, > > When I compile with --enable-shared my module comes up twice when I > call --datastore-properties ? Can you show the output? Also check "syncevolution --version". It has some information about loaded modules. -- 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 mcrha at redhat.com Tue Jan 19 10:25:31 2016 From: mcrha at redhat.com (Milan Crha) Date: Tue, 19 Jan 2016 11:25:31 +0100 Subject: [SyncEvolution] Build fails with libical 2.0.0 Message-ID: <1453199131.2505.21.camel@redhat.com> Hello, I just realized that the syncevolution fails to build against libical 2.0.0. The problem is synevolution's extract of icaltz-util.c/.h, referencing?extern const char *ical_tzid_prefix; This variable had been made private and there is no way to get to it from the outside of libical (the added?icaltimezone_tzid_prefix() is not exported in the libical library). I do not know the rationale with the icaltz-util extract in the syncevolution, but I'd say it's time to get rid of it when new-enough libical is used for the build. What do you think? I placed a lame workaround in my build and defined the missing variable with the value copied from the libical 2.0.0 sources. I know it doesn't scale and can easily break in the future, but I expect that there will be done a proper fix upstream meanwhile and I'll be able to drop the workaround once the fix will be released. Bye, Milan _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Tue Jan 19 12:49:17 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 19 Jan 2016 13:49:17 +0100 Subject: [SyncEvolution] Build fails with libical 2.0.0 In-Reply-To: <1453199131.2505.21.camel@redhat.com> References: <1453199131.2505.21.camel@redhat.com> Message-ID: <1453207757.1161.7.camel@intel.com> On Tue, 2016-01-19 at 11:25 +0100, Milan Crha wrote: > Hello, > I just realized that the syncevolution fails to build against > libical 2.0.0. The problem is synevolution's extract of > icaltz-util.c/.h, referencing extern const char *ical_tzid_prefix; > This variable had been made private and there is no way to get to it > from the outside of libical (the added icaltimezone_tzid_prefix() is > not exported in the libical library). > > I do not know the rationale with the icaltz-util extract in the > syncevolution, but I'd say it's time to get rid of it when new-enough > libical is used for the build. What do you think? Does the libical 2.0 return "simple" VTIMEZONE definitions again, i.e. ones with RRULEs for summer and winter time? The reason for icaltz-util.c is this: commit 9d13210d0bc5eba1e280fde7742a198e5631974f Author: Patrick Ohly Date: Wed Mar 19 13:13:50 2014 +0100 ical: workaround for libical 1.0 builtin timezone change libical 1.0 started to return VTIMEZONE definitions with multiple absolute transition times instead of RRULEs. This causes problems when exchanging data with peers (see https://sourceforge.net/p/freeassociation/bugs/95/). In SyncEvolution, this affected sending an event using New Zealand time in vCalendar 1.0 format to a phone, because the internal, out-dated definition of the time zone in libsynthesis was used as fallback when loading RRULE-based timezone definitions from libical failed (see "[SyncEvolution] Some events showing wrong time on phone"). It might also affect exchanging data with CalDAV peers (not tested). The workaround is to include the original code from libical from before the change in SyncEvolution and override icaltimezone_get_component() with a version that uses the original timezone loading code. This does not fix cases where other code causes libical itself to load a timezone, but for libsynthesis it is good enough because it does the loading early when no other code should have used libical. [...] I don't remember whether ical_tzid_prefix absolutely has to be the one from libical or whether it can also be something else. I've not tested with libical 2.0 yet. I started testing, but ran out of time and patience. This whole "let's break the ABI, people will recompile anyway" is making it harder and harder to provide pre-compiled SyncEvolution binaries. -- 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 mcrha at redhat.com Wed Jan 20 11:44:15 2016 From: mcrha at redhat.com (Milan Crha) Date: Wed, 20 Jan 2016 12:44:15 +0100 Subject: [SyncEvolution] Build fails with libical 2.0.0 In-Reply-To: <1453207757.1161.7.camel@intel.com> References: <1453199131.2505.21.camel@redhat.com> <1453207757.1161.7.camel@intel.com> Message-ID: <1453290255.10173.2.camel@redhat.com> On Tue, 2016-01-19 at 13:49 +0100, Patrick Ohly wrote: > Does the libical 2.0 return "simple" VTIMEZONE definitions again, i.e. > ones with RRULEs for summer and winter time? Hi, they do return expanded timezones, unless the library is built with ? ?-DUSE_INTEROPERABLE_VTIMEZONES=true or unless the application (library user) calls: ? ?icaltzutil_set_exact_vtimezones_support (0); That restores the previous behaviour. I'm going to call that function in the evolution(-data-server) code, if available. Bye, Milan _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution