From jane at janeatkinson.co.nz Sat Feb 1 03:36:29 2014 From: jane at janeatkinson.co.nz (Jane Atkinson) Date: Sat, 1 Feb 2014 16:36:29 +1300 Subject: [SyncEvolution] Calendar entries not syncing when date changed Message-ID: <52EC6BBD.1060604@janeatkinson.co.nz> >>From time to time, I need to change the date, but not the time, of an appointment. When I do this, the change is not being propagated to the client. If I change the time of an appointment, the change is propagated correctly. I'm running syncevolution 1.3.99.7 on Xubuntu 14.04 (pre-release). The client is a Nokia E63. The configuration type is webdav. Evolution is not installed on this system. I'm not sure exactly when this started happening, but I think it's of recent origin. No configuration options have been changed for a long time. Please let me know where to send the logs. Also, any further tests I can do. Regards Jane Atkinson _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sat Feb 1 13:04:12 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sat, 01 Feb 2014 14:04:12 +0100 Subject: [SyncEvolution] Calendar entries not syncing when date changed In-Reply-To: <52EC6BBD.1060604@janeatkinson.co.nz> References: <52EC6BBD.1060604@janeatkinson.co.nz> Message-ID: <1391259852.30349.203.camel@pohly-mobl1.fritz.box> On Sat, 2014-02-01 at 16:36 +1300, Jane Atkinson wrote: > From time to time, I need to change the date, but not the time, of an > appointment. When I do this, the change is not being propagated to the > client. If I change the time of an appointment, the change is propagated > correctly. > > I'm running syncevolution 1.3.99.7 on Xubuntu 14.04 (pre-release). The > client is a Nokia E63. The configuration type is webdav. Evolution is > not installed on this system. > > I'm not sure exactly when this started happening, but I think it's of > recent origin. No configuration options have been changed for a long time. > > Please let me know where to send the logs. Also, any further tests I can do. Send me a syncevolution-log.html created with loglevel=4 where a change should be transmitted and doesn't get transmitted to patrick.ohly at intel.com. Please identify the event (say, by quoting its description). -- 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 jane at janeatkinson.co.nz Sat Feb 1 22:22:38 2014 From: jane at janeatkinson.co.nz (Jane Atkinson) Date: Sun, 2 Feb 2014 11:22:38 +1300 Subject: [SyncEvolution] Calendar entries not syncing when date changed In-Reply-To: <1391259852.30349.203.camel@pohly-mobl1.fritz.box> References: <52EC6BBD.1060604@janeatkinson.co.nz> <1391259852.30349.203.camel@pohly-mobl1.fritz.box> Message-ID: <52ED73AE.40402@janeatkinson.co.nz> On 02/02/14 02:04, Patrick Ohly wrote: > On Sat, 2014-02-01 at 16:36 +1300, Jane Atkinson wrote: >> From time to time, I need to change the date, but not the time, of an >> appointment. When I do this, the change is not being propagated to the >> client. If I change the time of an appointment, the change is propagated >> correctly. >> >> I'm running syncevolution 1.3.99.7 on Xubuntu 14.04 (pre-release). The >> client is a Nokia E63. The configuration type is webdav. Evolution is >> not installed on this system. >> >> I'm not sure exactly when this started happening, but I think it's of >> recent origin. No configuration options have been changed for a long time. >> >> Please let me know where to send the logs. Also, any further tests I can do. > Send me a syncevolution-log.html created with loglevel=4 where a change > should be transmitted and doesn't get transmitted to > patrick.ohly at intel.com. Please identify the event (say, by quoting its > description). > Strange... I set log-level=4 in ~/.config/syncevolution/config.ini. Then the test event synced correctly when I ran the sync! On reverting log-level to the default (commented out in config.ini) the sync is still working correctly with changed dates, both on new and existing events. I'll keep watching it and if the problem recurs I'll send a log. Probably not connected with this behaviour, but I regularly see an error message: [ERROR] GLib: Source ID 9 was not found when attempting to remove it Usually it's ID 9 but occasionally is another number. Regards Jane Atkinson From patrick.ohly at intel.com Mon Feb 3 08:16:27 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 3 Feb 2014 09:16:27 +0100 Subject: [SyncEvolution] source ID not found (was: Re: Calendar entries not syncing when date changed) In-Reply-To: <52ED73AE.40402@janeatkinson.co.nz> References: <52EC6BBD.1060604@janeatkinson.co.nz> <1391259852.30349.203.camel@pohly-mobl1.fritz.box> <52ED73AE.40402@janeatkinson.co.nz> Message-ID: <1391415387.30349.221.camel@pohly-mobl1.fritz.box> On Sun, 2014-02-02 at 11:22 +1300, Jane Atkinson wrote: > Probably not connected with this behaviour, but I regularly see an error > message: > [ERROR] GLib: Source ID 9 was not found when attempting to remove it Where exactly do you see that? Does it appear in any of the log files? > Usually it's ID 9 but occasionally is another number. That looks like a real bug. I can't reproduce it here because the warning was only added in a fairly recent glib version (the one for GNOME 3.12). commit a919be3d39150328874ff647fb2c2be7af3df996 Author: Bastien Nocera Date: Wed Oct 23 15:38:58 2013 +0200 gmain: Warn when g_source_remove() fails Trying to remove a non-existent source should really be a programming error, as the programmer could be trying to use the wrong function to remove a callback, as seen when GtkScrolledWindow tried to remove ID from another function using g_source_remove(). Can you try to track it down? Attached is a test program which should trigger the warning. Compile with: gcc -g -o test-remove test-remove.c `pkg-config --cflags --libs glib-2.0` Then run with G_DEBUG=fatal_criticals gdb ./test-remove $ run [crash] $ where At least I think it'll crash, thanks to G_DEBUG=fatal_criticals. Once you can catch it like this, try the same with syncevo-dbus-server (assuming that this is where the problem occurs - see my question above). -- 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 -------------- A non-text attachment was scrubbed... Name: test-remove.c Type: text/x-csrc Size: 389 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From jane at janeatkinson.co.nz Mon Feb 3 08:48:46 2014 From: jane at janeatkinson.co.nz (Jane Atkinson) Date: Mon, 3 Feb 2014 21:48:46 +1300 Subject: source ID not found In-Reply-To: <1391415387.30349.221.camel@pohly-mobl1.fritz.box> References: <52EC6BBD.1060604@janeatkinson.co.nz> <1391259852.30349.203.camel@pohly-mobl1.fritz.box> <52ED73AE.40402@janeatkinson.co.nz> <1391415387.30349.221.camel@pohly-mobl1.fritz.box> Message-ID: <52EF57EE.5060109@janeatkinson.co.nz> On 03/02/14 21:16, Patrick Ohly wrote: > On Sun, 2014-02-02 at 11:22 +1300, Jane Atkinson wrote: >> Probably not connected with this behaviour, but I regularly see an error >> message: >> [ERROR] GLib: Source ID 9 was not found when attempting to remove it > Where exactly do you see that? Does it appear in any of the log files? > > I run syncevolution from the command line. The error appears in the terminal as the final message just as the program terminates. I can't find it in the html log file. As far as I can tell, it doesn't cause any problems. It's getting a bit late for me to do testing now; I'll look at it in the morning. Regards Jane Atkinson From patrick.ohly at intel.com Mon Feb 3 09:26:19 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 03 Feb 2014 10:26:19 +0100 Subject: source ID not found In-Reply-To: <52EF57EE.5060109@janeatkinson.co.nz> References: <52EC6BBD.1060604@janeatkinson.co.nz> <1391259852.30349.203.camel@pohly-mobl1.fritz.box> <52ED73AE.40402@janeatkinson.co.nz> <1391415387.30349.221.camel@pohly-mobl1.fritz.box> <52EF57EE.5060109@janeatkinson.co.nz> Message-ID: <1391419579.30349.223.camel@pohly-mobl1.fritz.box> On Mon, 2014-02-03 at 21:48 +1300, Jane Atkinson wrote: > On 03/02/14 21:16, Patrick Ohly wrote: > > On Sun, 2014-02-02 at 11:22 +1300, Jane Atkinson wrote: > >> Probably not connected with this behaviour, but I regularly see an error > >> message: > >> [ERROR] GLib: Source ID 9 was not found when attempting to remove it > > Where exactly do you see that? Does it appear in any of the log files? > > > > > I run syncevolution from the command line. The error appears in the > terminal as the final message just as the program terminates. I can't > find it in the html log file. As far as I can tell, it doesn't cause any > problems. So it could come from either syncevo-dbus-server or from the syncevolution command line tool; better run both under gdb, just to be sure to catch it. > It's getting a bit late for me to do testing now; I'll look at it in the > morning. Sure, no hurry. -- 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 jane at janeatkinson.co.nz Mon Feb 3 22:22:31 2014 From: jane at janeatkinson.co.nz (Jane Atkinson) Date: Tue, 4 Feb 2014 11:22:31 +1300 Subject: source ID not found In-Reply-To: <1391419579.30349.223.camel@pohly-mobl1.fritz.box> References: <52EC6BBD.1060604@janeatkinson.co.nz> <1391259852.30349.203.camel@pohly-mobl1.fritz.box> <52ED73AE.40402@janeatkinson.co.nz> <1391415387.30349.221.camel@pohly-mobl1.fritz.box> <52EF57EE.5060109@janeatkinson.co.nz> <1391419579.30349.223.camel@pohly-mobl1.fritz.box> Message-ID: <52F016A7.9060400@janeatkinson.co.nz> On 03/02/14 22:26, Patrick Ohly wrote: > On Mon, 2014-02-03 at 21:48 +1300, Jane Atkinson wrote: >> On 03/02/14 21:16, Patrick Ohly wrote: >>> On Sun, 2014-02-02 at 11:22 +1300, Jane Atkinson wrote: >>>> Probably not connected with this behaviour, but I regularly see an error >>>> message: >>>> [ERROR] GLib: Source ID 9 was not found when attempting to remove it >>> Where exactly do you see that? Does it appear in any of the log files? >>> >>> >> I run syncevolution from the command line. The error appears in the >> terminal as the final message just as the program terminates. I can't >> find it in the html log file. As far as I can tell, it doesn't cause any >> problems. > So it could come from either syncevo-dbus-server or from the > syncevolution command line tool; better run both under gdb, just to be > sure to catch it. > >> It's getting a bit late for me to do testing now; I'll look at it in the >> morning. > Sure, no hurry. > I've run some tests. I'm not sure if the second and third ones give what you're looking for - I'm not very familiar with gdb. ---- $G_DEBUG=fatal_criticals gdb ./test-remove GNU gdb (GDB) 7.6.50.20131218-cvs-ubuntu Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./test-remove...done. (gdb) run Starting program: /home/ja/Desktop/test-remove warning: File "/lib/i386-linux-gnu/libglib-2.0.so.0.3903.0-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /lib/i386-linux-gnu/libglib-2.0.so.0.3903.0-gdb.py line to your configuration file "/home/ja/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/ja/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". tag: 1 first remove: okay (process:13707): GLib-CRITICAL **: Source ID 1 was not found when attempting to remove it Program received signal SIGTRAP, Trace/breakpoint trap. 0xb7f1115a in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 (gdb) where #0 0xb7f1115a in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 #1 0xb7f11273 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 #2 0xb7f08cbc in g_source_remove () from /lib/i386-linux-gnu/libglib-2.0.so.0 #3 0x0804863c in main (argc=1, argv=0xbffff1f4) at test-remove.c:11 (gdb) ---- running syncevolution from the command line: (normal sync details removed) Data modified locally during synchronization: *** addressbook *** no changes *** calendar *** no changes *** memo *** no changes *** todo *** no changes [ERROR] GLib: Source ID 9 was not found when attempting to remove it [Inferior 1 (process 13791) exited normally] (gdb) ---- running gdb sync-evo-dbus-server in one terminal and syncevolution from command line in another: G_DEBUG=fatal_criticals gdb "/usr/libexec/syncevo-dbus-server" GNU gdb (GDB) 7.6.50.20131218-cvs-ubuntu Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/libexec/syncevo-dbus-server...done. (gdb) run Starting program: /usr/libexec/syncevo-dbus-server warning: File "/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3903.0-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3903.0-gdb.py line to your configuration file "/home/ja/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/ja/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: File "/lib/i386-linux-gnu/libglib-2.0.so.0.3903.0-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [New Thread 0xb6ba8b40 (LWP 13875)] [New Thread 0xb61ffb40 (LWP 13876)] Program received signal SIGTRAP, Trace/breakpoint trap. 0xb7b7b15a in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 (gdb) where #0 0xb7b7b15a in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 #1 0xb7b7b273 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 #2 0xb7b72cbc in g_source_remove () from /lib/i386-linux-gnu/libglib-2.0.so.0 #3 0xb7de2d99 in SyncEvo::ForkExecParent::~ForkExecParent (this=0x8213518, __in_chrg=) at /data/runtests/work/sources/syncevolution/src/syncevo/ForkExec.cpp:125 #4 0xb7decac9 in boost::detail::sp_counted_impl_p::dispose() () from /usr/lib/libsyncevolution.so.0 #5 0x081055dd in release (this=) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:145 #6 ~shared_count (this=, __in_chrg=) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:217 #7 ~shared_ptr (this=, __in_chrg=) at /usr/include/boost/smart_ptr/shared_ptr.hpp:169 #8 SyncEvo::Session::~Session (this=0x8210e00, __in_chrg=) at /data/runtests/work/sources/syncevolution/src/dbus/server/session.cpp:754 #9 0x08111178 in checked_delete (x=) at /usr/include/boost/checked_delete.hpp:34 #10 boost::detail::sp_counted_impl_p::dispose (this=0x81e63e0) at /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78 #11 0x080bf2c8 in release (this=) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:145 #12 boost::detail::shared_count::~shared_count (this=0x8215be4, __in_chrg=) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:217 #13 0x080d8e0b in boost::detail::function::functor_manager const&), boost::_bi::list1 > > > >::manage(boost::detail::function::function_buffer const&, boost::detail::function::function_buffer&, boost::detail::function::functor_manager_operation_type) () #14 0x080d4131 in clear (functor=..., this=) at /usr/include/boost/function/function_template.hpp:504 #15 boost::function0::clear (this=0x8215bd8) at /usr/include/boost/function/function_template.hpp:856 #16 0x080dd439 in boost::detail::function::functor_manager const&, boost::function const&>, boost::_bi::list3, boost::reference_wrapper >, boost::_bi::value > > > >::manage(boost::detail::function::function_buffer const&, boost::detail::function::function_buffer&, boost::detail::function::functor_manager_operation_type) () #17 0x080e0826 in SyncEvo::Timeout::triggered(void*) () #18 0xb7b74971 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #19 0xb7b73e37 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0 #20 0xb7b741f8 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #21 0xb7b744fb in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0 #22 0x080c8216 in SyncEvo::Server::run (this=0x81e3898) at /data/runtests/work/sources/syncevolution/src/dbus/server/server.cpp:534 #23 0x080bdf8a in main (argc=136186288, argv=0xffe798bf, envp=0xbffff1ec) at /data/runtests/work/sources/syncevolution/src/dbus/server/main.cpp:223 (gdb) Regards Jane Atkinson From patrick.ohly at intel.com Tue Feb 4 08:29:34 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 04 Feb 2014 09:29:34 +0100 Subject: source ID not found In-Reply-To: <52F016A7.9060400@janeatkinson.co.nz> References: <52EC6BBD.1060604@janeatkinson.co.nz> <1391259852.30349.203.camel@pohly-mobl1.fritz.box> <52ED73AE.40402@janeatkinson.co.nz> <1391415387.30349.221.camel@pohly-mobl1.fritz.box> <52EF57EE.5060109@janeatkinson.co.nz> <1391419579.30349.223.camel@pohly-mobl1.fritz.box> <52F016A7.9060400@janeatkinson.co.nz> Message-ID: <1391502574.10641.1.camel@pohly-mobl1.fritz.box> On Tue, 2014-02-04 at 11:22 +1300, Jane Atkinson wrote: > Program received signal SIGTRAP, Trace/breakpoint trap. > 0xb7b7b15a in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 > (gdb) where > #0 0xb7b7b15a in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #1 0xb7b7b273 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #2 0xb7b72cbc in g_source_remove () from > /lib/i386-linux-gnu/libglib-2.0.so.0 > #3 0xb7de2d99 in SyncEvo::ForkExecParent::~ForkExecParent > (this=0x8213518, __in_chrg=) at > /data/runtests/work/sources/syncevolution/src/syncevo/ForkExec.cpp:125 Thanks, that's it. I think I know why the source tag is invalid in that destructor. Here's a patch which should fix it: diff --git a/src/syncevo/ForkExec.cpp b/src/syncevo/ForkExec.cpp index 31009b8..aabffed 100644 --- a/src/syncevo/ForkExec.cpp +++ b/src/syncevo/ForkExec.cpp @@ -333,11 +333,14 @@ gboolean ForkExecParent::outputReady(GIOChannel *source, // Will remove event source from main loop. cont = false; - // Free channel. + // Free channel and forget source tag (source will be free + // when returning false). if (source == me->m_out) { me->m_out = NULL; + me->m_outID = 0; } else { me->m_err = NULL; + me->m_errID = 0; } g_io_channel_unref(source); Can compile from source and try that out? -- 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 jane at janeatkinson.co.nz Tue Feb 4 08:41:22 2014 From: jane at janeatkinson.co.nz (Jane Atkinson) Date: Tue, 4 Feb 2014 21:41:22 +1300 Subject: source ID not found In-Reply-To: <1391502574.10641.1.camel@pohly-mobl1.fritz.box> References: <52EC6BBD.1060604@janeatkinson.co.nz> <1391259852.30349.203.camel@pohly-mobl1.fritz.box> <52ED73AE.40402@janeatkinson.co.nz> <1391415387.30349.221.camel@pohly-mobl1.fritz.box> <52EF57EE.5060109@janeatkinson.co.nz> <1391419579.30349.223.camel@pohly-mobl1.fritz.box> <52F016A7.9060400@janeatkinson.co.nz> <1391502574.10641.1.camel@pohly-mobl1.fritz.box> Message-ID: <52F0A7B2.604@janeatkinson.co.nz> On 04/02/14 21:29, Patrick Ohly wrote: > On Tue, 2014-02-04 at 11:22 +1300, Jane Atkinson wrote: >> Program received signal SIGTRAP, Trace/breakpoint trap. >> 0xb7b7b15a in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> (gdb) where >> #0 0xb7b7b15a in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #1 0xb7b7b273 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #2 0xb7b72cbc in g_source_remove () from >> /lib/i386-linux-gnu/libglib-2.0.so.0 >> #3 0xb7de2d99 in SyncEvo::ForkExecParent::~ForkExecParent >> (this=0x8213518, __in_chrg=) at >> /data/runtests/work/sources/syncevolution/src/syncevo/ForkExec.cpp:125 > Thanks, that's it. > > I think I know why the source tag is invalid in that destructor. Here's > a patch which should fix it: > > diff --git a/src/syncevo/ForkExec.cpp b/src/syncevo/ForkExec.cpp > index 31009b8..aabffed 100644 > --- a/src/syncevo/ForkExec.cpp > +++ b/src/syncevo/ForkExec.cpp > @@ -333,11 +333,14 @@ gboolean ForkExecParent::outputReady(GIOChannel *source, > // Will remove event source from main loop. > cont = false; > > - // Free channel. > + // Free channel and forget source tag (source will be free > + // when returning false). > if (source == me->m_out) { > me->m_out = NULL; > + me->m_outID = 0; > } else { > me->m_err = NULL; > + me->m_errID = 0; > } > g_io_channel_unref(source); > > Can compile from source and try that out? > What specifically do I need to compile? syncevolution, syncevo-dbus-server or something else? It's been a while since I've compiled anything, so I'll need slightly more detailed instructions. Regards Jane Atkinson From patrick.ohly at intel.com Tue Feb 4 10:52:47 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 04 Feb 2014 11:52:47 +0100 Subject: source ID not found In-Reply-To: <52F0A7B2.604@janeatkinson.co.nz> References: <52EC6BBD.1060604@janeatkinson.co.nz> <1391259852.30349.203.camel@pohly-mobl1.fritz.box> <52ED73AE.40402@janeatkinson.co.nz> <1391415387.30349.221.camel@pohly-mobl1.fritz.box> <52EF57EE.5060109@janeatkinson.co.nz> <1391419579.30349.223.camel@pohly-mobl1.fritz.box> <52F016A7.9060400@janeatkinson.co.nz> <1391502574.10641.1.camel@pohly-mobl1.fritz.box> <52F0A7B2.604@janeatkinson.co.nz> Message-ID: <1391511167.10641.19.camel@pohly-mobl1.fritz.box> On Tue, 2014-02-04 at 21:41 +1300, Jane Atkinson wrote: > On 04/02/14 21:29, Patrick Ohly wrote: > > Can compile from source and try that out? > > > > What specifically do I need to compile? syncevolution, > syncevo-dbus-server or something else? syncevo-dbus-server. > It's been a while since I've compiled anything, so I'll need slightly > more detailed instructions. Then it's probably easier if I set up another chroot where I can reproduce the problem myself. Thanks for your help, though. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From tino.keitel+syncevolution at tikei.de Mon Feb 24 11:26:05 2014 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Mon, 24 Feb 2014 12:26:05 +0100 Subject: [SyncEvolution] Fix build failure with eglibc 2.18 Message-ID: <20140224112605.GA1655@mac.home> Hi, syncevolution 1.4 fails to build with glibc headers from eglibc 2.18 in Debian Sid. Attatched is a patch. Regards, Tino -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Include-missing-stdint.h.patch Type: text/x-diff Size: 711 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From renato.filho at canonical.com Fri Feb 28 18:20:33 2014 From: renato.filho at canonical.com (Renato Filho) Date: Fri, 28 Feb 2014 15:20:33 -0300 Subject: [SyncEvolution] Syncing with webdav in a different evolution database Message-ID: Hi guys, I wrote a small daemon that integrates syncevolution DBUS and online accounts. Basically it listen for online account creation/enable/removal and setup the sync configuration on syncevolution. This is working fine sync with default evolution address book, but I want to create one addressbook for each account, right now I am using eds api for that (I am not sure if syncevolution does that). But the problem cames when configuring syncevolution to sync with different database. I am not sure how to do that right now I am creating the config in this way: session = server.StartSessionWithFlags("onlineaccount-1". ["all-configs"]) //config target config = session.getConfig("WebDAV", true); config[""]["syncURL"] = "https://www.googleapis.com/.well-known/carddav" config[""]["username"] = "uoa:1,google-carddav" config[""]["consumerReady"] = "0" config[""]["dumpData"] = "0" config[""]["printChanges"] = "0" config[""]["PeerName"] = "onlineaccount-1" session.SetNamedConfig("target-config at onlineaccount-1") //config sync config = session->getConfig("SyncEvolution_Client", true) // config server side config[""]["syncURL"] = "local://@onlineaccount-1" config[""]["username"] = "" config[""]["password"] = "" config[""]["dumpData"] = "0" config[""]["printChanges"] = "0" // remove unecessary sources delete config["source/calendar"] delete config["source/todo"] delete config["source/memo"] session.saveConfig("onlineaccount-1", config) session.deatach() // sync session = server.StartSession("onlineaccount-1") session.sync("", ("addressbook", "slow")) This works fine but stores the contacts on default database in evolution. I want to change that to store each account in a different database, I tried several configurations changes but does not works. I tried to set the sync config database like: config["source/addressbook"]["backend"] = "addressbook" config["source/addressbook"]["database"] = "logion at gmail.com" but his cause the default source config (.config/syncevolution/sources/addressbook.ini) to get update and does not work for multiple accounts. I tried add a new source on sync config but the source is not created. Something like: config["source/onlineaccount"]["backend"] = "addressbook" config["source/onlineaccount"]["database"] = "logion at gmail.com" I am really lost here. Looks like I need to create a source and link that with my server database but I do not know how to do that with dbus api. Thanks Renato _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Feb 28 20:41:29 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 28 Feb 2014 21:41:29 +0100 Subject: [SyncEvolution] Syncing with webdav in a different evolution database In-Reply-To: References: Message-ID: <1393620089.581.8.camel@pohly-mobl1.fritz.box> On Fri, 2014-02-28 at 15:20 -0300, Renato Filho wrote: > This works fine but stores the contacts on default database in evolution. > I want to change that to store each account in a different database, I > tried several configurations changes but does not works. You need to create a new local source with its own "database" property and use that instead if the default "addressbook" source (which is the same for all peers). Something like this: // remove unecessary sources delete config["source/addressbook"] delete config["source/calendar"] delete config["source/todo"] delete config["source/memo"] // Use a specific EDS database locally and "addressbook" remotely. config["source/onlineaccount-1"] = {} config["source/onlineaccount-1"]["backend"] = "evolution-contacts" config["source/onlineaccount-1"]["database"] = ... // unique-id config["source/onlineaccount-1"]["uri"] = "addressbook" config["source/onlineaccount-1"]["sync"] = "two-way" session.saveConfig("onlineaccount-1", config) From renato.filho at canonical.com Fri Feb 28 21:30:47 2014 From: renato.filho at canonical.com (Renato Filho) Date: Fri, 28 Feb 2014 18:30:47 -0300 Subject: [SyncEvolution] Syncing with webdav in a different evolution database In-Reply-To: <1393620089.581.8.camel@pohly-mobl1.fritz.box> References: <1393620089.581.8.camel@pohly-mobl1.fritz.box> Message-ID: Hi Patrick, Thanks again for the help. This works as expected. Thanks Renato On Fri, Feb 28, 2014 at 5:41 PM, Patrick Ohly wrote: > On Fri, 2014-02-28 at 15:20 -0300, Renato Filho wrote: >> This works fine but stores the contacts on default database in evolution. >> I want to change that to store each account in a different database, I >> tried several configurations changes but does not works. > > You need to create a new local source with its own "database" property > and use that instead if the default "addressbook" source (which is the > same for all peers). > > Something like this: > > // remove unecessary sources > delete config["source/addressbook"] > delete config["source/calendar"] > delete config["source/todo"] > delete config["source/memo"] > > // Use a specific EDS database locally and "addressbook" remotely. > config["source/onlineaccount-1"] = {} > config["source/onlineaccount-1"]["backend"] = "evolution-contacts" > config["source/onlineaccount-1"]["database"] = ... // unique-id > config["source/onlineaccount-1"]["uri"] = "addressbook" > config["source/onlineaccount-1"]["sync"] = "two-way" > > session.saveConfig("onlineaccount-1", config) > > From g+syncevolution at cobb.uk.net Fri Feb 21 17:37:18 2014 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Fri, 21 Feb 2014 17:37:18 +0000 Subject: [SyncEvolution] Activesync backend use of username property Message-ID: <53078ECE.5000605@cobb.uk.net> Now that I am beginning to understand the use of the context and the difference between source and sync configs better, I tried issuing the following command: syncevolution --configure --template none \ username=my.email at example.com backend=eas-events \ database=Calendar @Exchange calendar I think that ought to have worked, because I am configuring a source (which could be shared by several peers later). However, it fails: [ERROR] error code from SyncEvolution fatal error (local, status 10500): per-peer (unshared) properties not allowed: username Of course, the reason is because we are abusing the username, which is a sync property, to do the job of a source property (to specify the account for activesyncd). Should we change the eas backend to use (for example) databaseUser to specify the account? Or am I still confused (quite likely)? I must admit that I still don't understand how the special peer "target-config" works! Graham PS. I am at MWC next week, so I may have trouble responding to email. _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From g+syncevolution at cobb.uk.net Fri Feb 21 18:54:44 2014 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Fri, 21 Feb 2014 18:54:44 +0000 Subject: [SyncEvolution] Activesync backend use of username property In-Reply-To: <53078ECE.5000605@cobb.uk.net> References: <53078ECE.5000605@cobb.uk.net> Message-ID: <5307A0F4.9070807@cobb.uk.net> On 21/02/14 17:37, Graham Cobb wrote: > Of course, the reason is because we are abusing the username, which is a > sync property, to do the job of a source property (to specify the > account for activesyncd). Should we change the eas backend to use (for > example) databaseUser to specify the account? > > Or am I still confused (quite likely)? Further investigation has led me to discover that the carddav/caldav backends work the same way. They use username and password (and also cannot be set when just configuring the source). So, I am obviously confused. It seems that in both the webdav and activesync cases, we are specifying a folder (which must be in a particular user's account) in the source, but we are not specifying the access control for that account in the source. Wouldn't it be more logical to either: 1) Keep database as is, and use databaseUser/databasePassword for the access control, or 2) Modify the database to only specify the folder name and put the username, password and url in the peer? The first case makes webdav and activesync feel like local backends. The second makes them feel like SyncML peers. The current situation doesn't feel like either, to me. I also note that the current behaviour prevents running a SyncML client or server with either webdav or activesync as the backend database underneath. But presumably that is not a design goal (only file, kde or evolution are allowed?). Graham _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From ovek at arcticnet.no Sat Feb 22 03:33:29 2014 From: ovek at arcticnet.no (=?ISO-8859-1?Q?Ove_K=E5ven?=) Date: Sat, 22 Feb 2014 04:33:29 +0100 Subject: [SyncEvolution] Activesync backend use of username property In-Reply-To: <5307A0F4.9070807@cobb.uk.net> References: <53078ECE.5000605@cobb.uk.net> <5307A0F4.9070807@cobb.uk.net> Message-ID: <53081A89.8090109@arcticnet.no> Den 21. feb. 2014 19:54, skrev Graham Cobb: > So, I am obviously confused. It seems that in both the webdav and > activesync cases, we are specifying a folder (which must be in a > particular user's account) in the source, but we are not specifying the > access control for that account in the source. I only have experience with WebDAV, but I don't see a problem. That is just like how SyncML works: each source specifies a database, but the credentials are in the sync config that the source belongs to (the target-config, in this case). That way, contacts, calendars, tasks, etc, on the same server can share the same credentials. There's no reason you should need to specify the credentials more than once for the same peer. > Wouldn't it be more > logical to either: > > 1) Keep database as is, and use databaseUser/databasePassword for the > access control, or In my opinion, no, for the reasons above. > 2) Modify the database to only specify the folder name and put the > username, password and url in the peer? By what do you mean "peer"? I thought that, by sync config, you already meant the peer. Then this is more or less how it's already done (except for the url mangling, but I think the current system is more flexible the way it is, and doesn't need changing). However, if, by peer, you mean to take them out of the target-config and into the main config, then I think that's a bad idea. By keeping them in the target-config, it is possible for SyncEvolution to act as a sync bridge between different remote services, such as between two WebDAV servers, or between ActiveSync and WebDAV, or between SyncML and WebDAV/ActiveSync, and so on. _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sun Feb 23 14:50:27 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 23 Feb 2014 15:50:27 +0100 Subject: [SyncEvolution] Activesync backend use of username property In-Reply-To: <5307A0F4.9070807@cobb.uk.net> References: <53078ECE.5000605@cobb.uk.net> <5307A0F4.9070807@cobb.uk.net> Message-ID: <1393167027.5772.21.camel@pohly-mobl1.fritz.box> On Fri, 2014-02-21 at 18:54 +0000, Graham Cobb wrote: > On 21/02/14 17:37, Graham Cobb wrote: > > Of course, the reason is because we are abusing the username, which is a > > sync property, to do the job of a source property (to specify the > > account for activesyncd). Should we change the eas backend to use (for > > example) databaseUser to specify the account? > > > > Or am I still confused (quite likely)? > > Further investigation has led me to discover that the carddav/caldav > backends work the same way. They use username and password (and also > cannot be set when just configuring the source). They can be set. WebDAV checks databaseUser/Password before it falls back to the target-config setting in the context of the source. > I also note that the current behaviour prevents running a SyncML client > or server with either webdav or activesync as the backend database > underneath. But presumably that is not a design goal (only file, kde or > evolution are allowed?). No, all backends are meant to work also in a SyncML client or server. For example, some people have used SyncEvolution as a transparent SyncML frontend for a WebDAV server. I have not comment further on your mail because Ove already explained the concept correctly: the "target-config" contains properties that can be shared by all sources in the same context. The goal was to avoid redundancy in the configuration. Has that answered your questions? I'd like to add that for credentials, SyncEvolution 1.4 also has the possibility to set username/password once and then refer to that via "id:" in the username property. From the 1.4 NEWS entry: * config: enhanced password handling It is possible to configure a plain username/password combination once in SyncEvolution and then use references to it in other configurations, instead of having to set (and update) the credentials in different places. This is useful in particular with WebDAV, where credentials had to be repeated several times (target config, in each database when used as part of SyncML) or when using a service which requires several configs (Google via SyncML and CalDAV). To use this, create a sync config for a normal peer or a dedicated config just for the credentials, with "username/password/syncURL" set. The "syncURL" must be set to something identifying the peer if GNOME Keyring is used for the password storage. Then set "username", "databaseUser" and "proxyUser" properties to "id:" and all read and write access to those properties will be redirected by SyncEvolution into that other configuration. This even works in the GTK UI. For user names which contain colons, the new "user:" format must be used. Strings without colons are assumed to be normal user names, so most old configurations should continue to work. This only covers credentials and can be used in addition or instead of sharing via target-config. At least with WebDAV, syncURL and loglevel are also relevant for multiple sources. At least with some servers, the same syncURL can be used to find CalDAV and CardDAV collections. -- 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 Tue Feb 18 15:51:36 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 18 Feb 2014 16:51:36 +0100 Subject: SyncEvolution 1.4 released Message-ID: <1392738696.6118.20.camel@pohly-mobl1.fritz.box> About SyncEvolution =================== SyncEvolution synchronizes personal information management (PIM) data via various protocols (SyncML, CalDAV/CardDAV, ActiveSync). It syncs contacts, appointments, tasks and memos. It syncs to web services or to SyncML-capable phones via Bluetooth. Binaries are available for Linux desktops (using GNOME Evolution, or KDE's Akonadi), for MeeGo and for Maemo (Nokia N900, N9). About 1.4 ========= The 1.4 release of SyncEvolution replaces 1.3.2 as the stable, supported release. Changes since that release are summarized in this section. For changes since the last pre-release see below. 1.4 is the first stable version with the in-vehicle infotainment (IVI) PIM Manager included. GENIVI Diagnostic Log and Trace (DLT) is also supported. For more information about this aspect of SyncEvolution, see the PBAP and PIM entries in the 1.3.99 release notes and https://syncevolution.org/blogs/pohly/2013/pim-its-all-about-contacts The biggest change for normal Linux users is Google CalDAV/CardDAV authentication with OAuth2. These are the open protocol that Google currently supports and thus the recommended way of syncing with Google, replacing ActiveSync and SyncML (both no longer available to all Google customers). Support for Google CardDAV is new. Like Evolution, SyncEvolution does not yet support some of the advanced features of the server, in particular custom labels for phone numbers, emails and addresses. Likewise, some client properties are not supported by the server: CALURI, CATEGORIES, FBURL, GEO and ROLE are not supported. Of ORG, only the first two components are supported. Currently, properties not supported by one side get lost in a full roundtrip sync. Instant Messaging information is supported by both sides with different vCard extensions; the server stores these extensions without showing the information, while SyncEvolution drops the data sent by the server. SyncEvolution depends on external components for OAuth2. It can be compiled to use gSSO [1] or GNOME Online Accounts [2]. The latter is enabled in binaries from syncevolution.org. GNOME Online Accounts >= 3.10 works out of the box for CalDAV and CardDAV. 3.8 is guaranteed to work for CardDAV and may also work for CalDAV, if the Linux distribution ships a patched version (like Debian Wheezy does). If it does not, then GNOME Online Accounts 3.8 binary can be patched to also support CalDAV, see [2]. Anything older than 3.8 does not work. Support for Ubuntu Online Accounts is available when compiling from source. For setup instructions see these READMEs. [1] https://01.org/gsso and http://cgit.freedesktop.org/SyncEvolution/syncevolution/plain/src/backends/signon/README [2] http://cgit.freedesktop.org/SyncEvolution/syncevolution/plain/src/backends/goa/README Binary packages of 1.4 on syncevolution.org have enhanced support for recent distros. They now work with EDS >= 3.6 *and* < 3.6. Distros with libical1 like Ubuntu Saucy are also supported. The HTTP server became better at handling message resends when the server is slow with processing a message. The server is able to keep a sync session alive while loading the initial data set by sending acknowledgment replies before the client times out. Some issues in CalDAV, WebDAV and SyncML were fixed. Graham R. Cobb contributed several patches for enhancing ActiveSync support and making it work with Exchange 2010. Guido G?nther provided some patches addressing problems when compiling SyncEvolution for Maemo. Details: -------- * D-Bus server: support DLT (FDO #66769) Diagnostic Log and Trace (DLT) manages a sequence of log messages, with remote controllable level of detail. SyncEvolution optionally (can be chosen at compile time and again at runtime) uses DLT instead of its own syncevolution-log.html files. See README-DLT.rst for more information. To use the feature, configure SyncEvolution with "--enable-dbus-server=--dlt --no-syslog" * 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 * D-Bus server: command line options for controlling output and startup The system log is used by default now. New command line options can be used to change this: -d, --duration=seconds/'unlimited' Shut down automatically when idle for this duration (default 300 seconds) -v, --verbosity=level Choose amount of output, 0 = no output, 1 = errors, 2 = info, 3 = debug; default is 1. --dbus-verbosity=level Choose amount of output via D-Bus signals, 0 = no output, 1 = errors, 2 = info, 3 = debug; default is 2. -o, --stdout Enable printing to stdout (result of operations) and stderr (errors/info/debug). -s, --no-syslog Disable printing to syslog. -p, --start-pim Activate the PIM Manager (= unified address book) immediately. * D-Bus: missing out parameters in D-Bus introspection XML (FDO #57292) The problem was in the C++ D-Bus binding. If the method that gets bound to D-Bus returns a value, that value was ignored in the signature: int foo() => no out parameter It works when the method was declared as having a retval: void foo (int &result) => integer out parameter This problem existed for both the libdbus and the GIO D-Bus bindings. In SyncEvolution it affected methods like GetVersions(). * D-Bus server: avoid progress outside of 0-100% range For example in the new TestLocalCache.testItemDelete100, the percentage value in the ProgressChanged signal become larger than 100 and then revert to 100 at the end of the sync. Seems the underlying calculation is faulty or simply inaccurate. This is not fixed. Instead the result is just clipped to the valid range. * sync: less verbose output, shorter runtime For each incoming change, one INFO line with "received x[/out of y]" was printed, immediately followed by another line with total counts "added x, updated y, removed z". For each outgoing change, a "sent x[/out of y]" was printed. In addition, these changes were forwarded to the D-Bus server where a "percent complete" was calculated and broadcasted to clients. All of that caused a very high overhead for every single change, even if the actual logging was off. The syncevo-dbus-server was constantly consuming CPU time during a sync when it should have been mostly idle. To avoid this overhead, the updated received/sent numbers that come from the Synthesis engine are now cached and only processed when done with a SyncML message or some other event happens (whatever happens first). To keep the implementation simple, the "added x, updated y, removed z" information is ignored completely and no longer appears in the output. * command line: implement --create/remove-database Creating a database is only possible with a chosen name. The UID is chosen automatically by the storage. Only implemented in the EDS backend. * command line: execute --export and --print-items while the source is still reading Instead of reading all item IDs, then iterating over them, process each new ID as soon as it is available. With sources that support incremental reading (only the PBAP source at the moment) that provides output sooner and is a bit more memory efficient. * command line: recover from slow sync with new sync modes The error message for an unexpected slow sync still mentioned the old and obsolete "refresh-from-client/server" sync modes. Better mention "refresh-from-local/remote". * command line: show backend error when listing databases fails The command line swallowed errors thrown by the backend while listing databases. Instead it just showed ": backend failed". The goal was to not distract users who accidentally access a non-functional backend. But the result is that operations like --configure or --print-databases could fail without giving the user any hint about the root cause of the issue. Now the error explanation in all its gory details is included. For example, not having activesyncd running leads to: INFO] eas_contact: backend failed: fetching folder list: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.meego.activesyncd was not provided by any .service files And running activesyncd without the necessary gconf keys shows up as: [INFO] eas_contact: backend failed: fetching folder list: GDBus.Error:org.meego.activesyncd.Error.AccountNotFound: Failed to find account [syncevolution at lists.intel.com] * password handling: fix usage of GNOME Keyring and KWallet (FDO #66110) When clients like the GTK sync-ui stored a password, it was always stored as plain text in the config.ini file by the syncevo-dbus-server. The necessary code for redirecting the password storage in a keyring (GNOME or KWallet) simply wasn't called in that case. The command line tool, even when using the D-Bus server to run the operation, had the necessary code active and thus was not affected. Now all SyncEvolution components use the same default: use safe password storage if either GNOME Keyring or KWallet were enabled during compilation, don't use it if not. Fixing this revealed other problems, like not being able to store certain passwords that lacked the necessary lookup criteria (like syncURL and/or username). To address this, the lookup criteria where extended and a new check was added to avoid accidentally removing other passwords. As a result, it may be possible that SyncEvolution no longer finds passwords that were stored with older versions of SyncEvolution. In such a case the passwords must be set again. * GNOME: clean up keyring access and require libgnome-keyring >= 2.20 The updated error messages now always include information about the password and libgnome-keyring error texts. A workaround is used for the "Error communicating with gnome-keyring-daemon" problem that started to appear fairly frequently in the automated testing once the keyring was actually used. The problem shows up with some additional debug messages: Gkr: received an invalid, unencryptable, or non-utf8 secret Gkr: call to daemon returned an invalid response: (null).(null)() It seems that sometimes setting up a session with GNOME keyring fails such that all further communication leads to decoding problem. There is an internal method to reset the session, but it cannot be called directly. As a workaround, fake the death of the GNOME keyring daemon and thus trigger a reconnect when retrying the GNOME keyring access. This is done by sending a D-Bus message, which will also affect other clients of GNOME keyring, but hopefully without user-visible effects. * config: enhanced password handling It is possible to configure a plain username/password combination once in SyncEvolution and then use references to it in other configurations, instead of having to set (and update) the credentials in different places. This is useful in particular with WebDAV, where credentials had to be repeated several times (target config, in each database when used as part of SyncML) or when using a service which requires several configs (Google via SyncML and CalDAV). To use this, create a sync config for a normal peer or a dedicated config just for the credentials, with "username/password/syncURL" set. The "syncURL" must be set to something identifying the peer if GNOME Keyring is used for the password storage. Then set "username", "databaseUser" and "proxyUser" properties to "id:" and all read and write access to those properties will be redirected by SyncEvolution into that other configuration. This even works in the GTK UI. For user names which contain colons, the new "user:" format must be used. Strings without colons are assumed to be normal user names, so most old configurations should continue to work. * signon: new backend using libgsignond-glib + libaccounts-glib The code works with gSSO (https://01.org/gsso) and Ubuntu Online Accounts. * GOA: get OAuth2 tokens out of GNOME Online Accounts "username = goa:..." selects an account in GOA and retrieves the OAuth2 token from that. * WebDAV: support OAuth2 If given an authentication configuration which can handle OAuth2, then OAuth2 is used instead of plain username/password authentication. * WebDAV: support Google CardDAV, break Yahoo Google CardDAV has one peculiarity: it renames new contacts during PUT without returning the new path to the client. See also http://lists.calconnect.org/pipermail/caldeveloper-l/2013-July/000524.html SyncEvolution already had a workaround for that (PROPGET on old path, extract new path from response) which happened to work. This workaround was originally added for Yahoo, which sometimes merges contacts into existing ones. In contrast to Yahoo, Google really seems to create new items. Without some server specific hacks, the client cannot tell what happened. Because Google is currently supported and Yahoo is not, let's change the hard-coded behavior to "renamed items are new". * WebDAV: started testing with owndrive.com = OwnCloud * WebDAV: avoid segfault during collection lookup Avoid referencing pathProps->second when the set of paths that PROPFINDs returns is empty. Apparently this can happen in combination with Calypso. * CalDAV: more workarounds for Google CalDAV + unique IDs Google became even more strict about checking REV. Tests which reused a UID after deleting the original item started to fail sometime since middle of December 2012. * CalDAV: work around Google server regression (undeclared namespace prefix in XML) Google CalDAV for a while (December 2012 till January 2013) sent invalid XML back when asked to include CardDAV properties in a PROPFIND. This got rejected in the XML parser, which prevents syncing calendar data: Neon error code 1: XML parse error at line 55: undeclared namespace prefix In the meantime Google fixed the issue in response to a bug report via email. But the workaround, only asking for the properties which are really needed, still makes sense and thus is kept. * WebDAV: auto-discovery fix With Google Contact + CardDAV the auto-discovery failed after finding the default address book, without reporting that result. * WebDAV: don't send Basic Auth via http proactively (FDO #57248) Sending basic authentication headers via http is insecure. Only do it proactively when the connection is encrypted and thus protects the information or when the server explicitly asks for it. * file backend: sub-second mod time stamps Change tracking in the file backend used to be based on the modification time in seconds. When running many syncs quickly (as in testing), that can lead to changes not being detected when they happen within a second. Now the file backend also includes the sub-second part of the modification time stamp, if available. This change is relevant when upgrading SyncEvolution: most of the items will be considered "updated" once during the first sync after the upgrade (or a downgrade) because the revision strings get calculated differently. * GTK UI: fixed two crashes - running a sync with no service selected and a 64 bit pointer problem recently discovered by Tino Keitel when compiling the Debian package with -fPIE. * packaging: compatible with EDS up to and including 3.10 and both libical.so.0 and libical.so.1 The binary packages now contain different versions of syncecal.so and syncebooks.so to cover different combinations of EDS and libical. * libical: compatibiliy mode for libical.so.0 and libical.so.1 libical 1.0 broke the ABI, leading to libical.so.1. The only relevant change for SyncEvolution is the renumbering of ICAL_*_PROPERTY enum values. We can adapt to that change at runtime, which allows us to compile once with libical.so.0, then patch executables or use dynamic loading to run with the more recent libical.so.1 if we add 1 to the known constants. * 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. * glib: fix double-free of source tags glib 2.39.0 (aka GNOME 3.10) as found in Ubuntu Trusty introduces warnings when g_source_remove() is passed an unknown tag. SyncEvolution did this in two cases: in both, the source callback returned false and thus caused the source to be removed by the caller. In that case, the explicit g_source_remove() is redundant and must be avoided. Such a call is faulty and might accidentally remove a new source with the same tag (unlikely though, given that tags seem to get assigned incrementally). The only noticable effect were additional error messages with different numbers: [ERROR] GLib: Source ID 9 was not found when attempting to remove it * EDS: fix compile problem with boost and EDS > 3.36 This fixes the following problem, seen with Boost 1.53.0 on altlinux when compiling for EDS >= 3.6: /usr/include/boost/smart_ptr/shared_ptr.hpp: In instantiation of 'typename boost::detail::sp_array_access::type boost::shared_ptr::operator[](std::ptrdiff_t) const [with T = char*; typename boost::detail::sp_array_access::type = void; std::ptrdiff_t = long int]': src/backends/evolution/EvolutionSyncSource.cpp:163:38: required from here /usr/include/boost/smart_ptr/shared_ptr.hpp:663:22: error: return-statement with a value, in function returning 'void' [-fpermissive] make[2]: *** [src/backends/evolution/src_backends_evolution_syncecal_la-EvolutionSyncSource.lo] * EDS contacts: avoid unnecessary DB writes during slow sync Traditionally, contacts were modified shortly before writing into EDS to match with Evolution expectations (must have N, only one CELL TEL, VOICE flag must be set). During a slow sync, the engine compare the modified contacts with the unmodified, incoming one. This led to mismatches and/or merge operations which end up not changing anything in the DB because the only difference would be removed again before writing. * EDS contacts: read-ahead cache Performance is improved by requesting multiple contacts at once and overlapping reading with processing. On a fast system (SSD, CPU fast enough to not be the limiting factor), testpim.py's testSync takes 8 seconds for a "match" sync where 1000 contacts get loaded and compared against the same set of contacts. Read-ahead with only 1 contact per query speeds that up to 6.7s due to overlapping IO and processing. Read-ahead with the default 50 contacts per query takes 5.5s. It does not get much faster with larger queries. * PBAP: add support for obexd 0.47, 0.48 and Bluez 5 obexd 0.48 is almost the same as obexd 0.47, except that it dropped the SetFilter and SetFormat methods in favor of passing a Bluex 5-style filter parameter to PullAll. * PBAP: various enhancements for efficient caching of contacts * HTTP server: handle message resends If a client gave up waiting for the server's response and resent its message while the server was still processing the message, syncing failed with "protocol error: already processing a message" raised by the syncevo-dbus-server because it wasn't prepared to handle that situation. The right place to handle this is inside the syncevo-http-server, because it depends on the protocol (HTTP in this case) whether resending is valid or not. It handles that now by tracking the message that is currently in processing and matching it against each new message. If it matches, the new request replaces the obsolete one without sending the message again to syncevo-dbus-server. When syncevo-dbus-server replies to the old message, the reply is used to finish the newer request. * engine: prevent timeouts in HTTP server mode HTTP SyncML clients give up after a certain timeout (SyncEvolution after RetryDuration = 5 minutes by default, Nokia e51 after 15 minutes) when the server fails to respond. This can happen with SyncEvolution as server when it uses a slow storage with many items, for example via WebDAV. In the case of slow session startup, multithreading is now used to run the storage initializing in parallel to sending regular "keep-alive" SyncML replies to the client. By default, these replies are sent every 2 minutes. This can be configured with another extensions of the SyncMLVersion property: SyncMLVersion = REQUESTMAXTIME=5m Other modes do not use multithreading by default, but it can be enabled by setting REQUESTMAXTIME explicitly. It can be disabled by setting the time to zero. The new feature depends on a libsynthesis with multithreading enabled and glib >= 2.32.0, which is necessary to make SyncEvolution itself thread-safe. With an older glib, multithreading is disabled, but can be enabled as a stop-gap measure by setting REQUESTMAXTIME explicitly. * Various testing and stability enhancements. SyncEvolution had to be made thread-safe for the HTTP timeout prevention. * Nokia: always add TYPE=INTERNET to EMAIL (FDO #61784) Without the explicit TYPE=INTERNET, email addresses sent to a Nokia e51 were not shown by the phone and even got lost eventually (when syncing back). This commit ensures that the type is set for all emails sent to any Nokia phone, because there may be other phones which need it and phones which don't, shouldn't mind. This was spot-checked with a N97 mini, which works fine with and without the INTERNET type. This behavior can be disabled again for specific Nokia phones by adding a remote rule which sets the addInternetEmail session variable to FALSE again. Non-Nokia phones can enable the feature in a similar way, by setting the variable to TRUE. * SyncML: config option for broken peers Some peers have problems with meta data (CtCap, old Nokia phones) and the sync mode extensions required for advertising the restart capability (Oracle Beehive). The default in SyncEvolution is to advertise the capability, so manual configuration is necessary when working with a peer that fails in that mode. Because the problem occurs when SyncEvolution contacts the peers before it gets the device information from the peer, dynamic rules based on the peer identifiers cannot be used. Instead the local config must already disable these extra features in advance. The "SyncMLVersion" property gets extended for this. Instead of just "SyncMLVersion = 1.0" (as before) it now becomes possible to say "SyncMLVersion = 1.0, noctcap, norestart". "noctcap" disables sending CtCap. "norestart" disables the sync mode extensions and thus doing multiple sync cycles in the same session (used between SyncEvolution instances in some cases to get client and server into sync in one session). Both keywords are case-insensitive. There's no error checking for typos, so beware! The "SyncMLVersion" property was chosen because it was already in use for configuring SyncML compatibility aspects and adding a new property would have been harder. * ActiveSync: added support for specifying folder names Previously, the database field was interpreted as a Collection ID. This adds logic to allow the database to be interpreted as a folder path. The logic is: 1) If the database is an empty string, pass it through (this is the most common case as it is interpreted as "use the default folder for the source type"). 2) If the database matches a Collection ID, use the ID (this is the same as the previous behaviour). 3) If the database matches a folder path name, with an optional leading "/", use the Collection ID for the matching folder. 4) Otherwise, force a FolderSync to get the latest folder changes from the server and repeat steps 2 and 3 5) If still no match, throw an error. * ActiveSync: support for listing databases Now --print-databases scans folders on the ActiveSync server and shows suitable folders for the ActiveSync backends instead of the previous, hard-coded help text. Invoking --print-databases can be used as a workaround for "SyncFolder error: Invalid synchronization key" errors. A better solution would be to do that automatically, but there was no time to implement that. See FDO #61869 and "[SyncEvolution] Activesync server losing state" http://thread.gmane.org/gmane.comp.mobile.syncevolution/4295 * SyncML: workarounds for broken peers Some peers have problems with meta data (CtCap, old Nokia phones) and the sync mode extensions required for advertising the restart capability (Oracle Beehive). Because the problem occurs when SyncEvolution contacts the peers before it gets the device information from the peer, dynamic rules based on the peer identifiers cannot be used. Instead the local config must already disable these extra features in advance. The "SyncMLVersion" property gets extended for this. Instead of just "SyncMLVersion = 1.0" (as before) it now becomes possible to say "SyncMLVersion = 1.0, noctcap, norestart". "noctcap" disables sending CtCap. "norestart" disables the sync mode extensions and thus doing multiple sync cycles in the same session (used between SyncEvolution instances in some cases to get client and server into sync in one session). Both keywords are case-insensitive. There's no error checking for typos, so beware! The "SyncMLVersion" property was chosen because it was already in use for configuring SyncML compatibility aspects and adding a new property would have been harder. * engine: local cache sync mode This patch introduces support for true one-way syncing ("caching"): the local datastore is meant to be an exact copy of the data on the remote side. The assumption is that no modifications are ever made locally outside of syncing. This is different from one-way sync modes, which allows local changes and only temporarily disables sending them to the remote side. Another goal of the new mode is to avoid data writes as much as possible. This new mode only works on the server side of a sync, where the engine has enough control over the data flow. Setting "sync" to: - "local-cache-incremental" will do an incremental sync (if possible) or a slow sync (otherwise). This is usually the right mode to use, and thus has "local-cache" as alias. - "local-cache-slow" will always do a slow sync. Useful for debugging or after (accidentally) making changes on the local side. An incremental sync will ignore such changes because they are not meant to happen, aren't checked for to improve performance and thus will leave client and server out-of-sync! Both modes are recorded in the sync report of the local side. The target side is the client and records the normal "two-way" or "slow" sync modes. With the current SyncEvolution contact field list, first, middle and last name are used to find matches for contacts. For events, tasks and memos, time, summary and description are used. * Minor memory leak fix when using GDBus GIO: GDBusMethodInfo Also depends on a glib fix, see https://bugzilla.gnome.org/show_bug.cgi?id=695376 * build fixes Avoid -lrt in make dependencies. Add missing pcre libs to syncevo-dbus-server. sqlite backend needs "#include " (patch from Mario Kicherer). * autotools: fix temp file vulnerability during compilation (CVE-2014-1639) We must use the temporary file that was created for us securily, not a temp file named after that file. This caused a temp file vulnerability and the real temporary files were not deleted by the script. * workarounds for warnings from g++ 4.5 Upgrading from releases <= 1.3.99.4: ------------------------------------ If the value of "username/databaseUser/proxyUser" contains a colon, the "user:" prefix must be added to the value, to continue treating it like a plain user name and not some reference to an unknown identity provider (like "id:", "goa:", "signon:", etc.). The lookup of passwords in GNOME Keyring was updated slightly in 1.3.99.5. It may be necessary to set passwords anew if the old one is no longer found. Upgrading from release 1.2.x: ----------------------------- The sync format of existing configurations for Mobical (aka Everdroid) must be updated manually, because the server has encoding problems when using vCard 3.0 (now the default for Evolution contacts): syncevolution --configure \ syncFormat=text/x-vcard \ mobical addressbook The Funambol template explicitly enables usage of the "refresh-from-server" sync mode to avoid getting throttled with 417 'retry later' errors. The same must be added to existing configs manually: syncevolution --configure \ enableRefreshSync=TRUE \ funambol Upgrading from releases before 1.2: ----------------------------------- Old configurations can still be read. But writing, as it happens during a sync, must migrate the configuration first. Releases >= 1.2 automatically migrates configurations. The old configurations will still be available (see "syncevolution --print-configs") but must be renamed manually to use them again under their original names with older SyncEvolution releases. SyncEvolution 1.3.99.7 -> 1.4 ============================= Compared to the pre-release, 1.4 mostly just enhanced the testing. Compatibility with GNOME 3.10 and a glib-related issue that existed almost forever without causing obvious problems were fixed. syncevolution.org binaries now finally work with distros using libical.so.1 (for example, Ubuntu Saucy and Trusty). Details: * autotools: fix temp file vulnerability during compilation (CVE-2014-1639) We must use the temporary file that was created for us securily, not a temp file named after that file. This caused a temp file vulnerability and the real temporary files were not deleted by the script. * glib: fix double-free of source tags glib 2.39.0 (aka GNOME 3.10) as found in Ubuntu Trusty introduces warnings when g_source_remove() is passed an unknown tag. SyncEvolution did this in two cases: in both, the source callback returned false and thus caused the source to be removed by the caller. In that case, the explicit g_source_remove() is redundant and must be avoided. Such a call is faulty and might accidentally remove a new source with the same tag (unlikely though, given that tags seem to get assigned incrementally). The only noticable effect were additional error messages with different numbers: [ERROR] GLib: Source ID 9 was not found when attempting to remove it * libical: compatibiliy mode for libical.so.0 and libical.so.1 libical 1.0 broke the ABI, leading to libical.so.1. The only relevant change for SyncEvolution is the renumbering of ICAL_*_PROPERTY enum values. We can adapt to that change at runtime, which allows us to compile once with libical.so.0, then patch executables or use dynamic loading to run with the more recent libical.so.1 if we add 1 to the known constants. Source, Installation, Further information ========================================= http://syncevolution.org/blogs/pohly/2014/syncevolution-14-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 "stable" 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 10.04 LTS (Lucid), except for ActiveSync binaries which were compiled for Debian Wheezy, Ubuntu Saucy and Ubuntu Trusty. The packages mentioned above are meta-packages which pull in suitable packages matching the distro during installation. 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 tino.keitel+syncevolution at tikei.de Wed Feb 19 13:05:21 2014 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Wed, 19 Feb 2014 14:05:21 +0100 Subject: [SyncEvolution] SyncEvolution 1.4 released In-Reply-To: <1392738696.6118.20.camel@pohly-mobl1.fritz.box> References: <1392738696.6118.20.camel@pohly-mobl1.fritz.box> Message-ID: <20140219130521.GA20387@mac.home> Hi Patrick, as the libsynthesis version was not bumped, am I right that syncevolution 1.4 is compatible with libsynthesis from libsynthesis_3.4.0.47+syncevolution-1-3-99-6? Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Feb 19 14:17:29 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 19 Feb 2014 15:17:29 +0100 Subject: [SyncEvolution] SyncEvolution 1.4 released In-Reply-To: <20140219130521.GA20387@mac.home> References: <1392738696.6118.20.camel@pohly-mobl1.fritz.box> <20140219130521.GA20387@mac.home> Message-ID: <1392819449.6118.46.camel@pohly-mobl1.fritz.box> On Wed, 2014-02-19 at 14:05 +0100, Tino Mettler wrote: > Hi Patrick, > > as the libsynthesis version was not bumped, am I right that > syncevolution 1.4 is compatible with libsynthesis from > libsynthesis_3.4.0.47+syncevolution-1-3-99-6? Correct. There have been some changes and fixes, but none of them are really important. Probably the most important one is the "support sending NumberOfChanges" change, because that ensures that progress in percent can be reported for a local sync. Details: $ git log libsynthesis_3.4.0.47+syncevolution-1-3-99-6..libsynthesis_3.4.0.47+syncevolution-1-4 commit 17087c460472faeed2dc6679e186eee847b845a7 Author: Patrick Ohly Date: Mon Jan 27 16:33:34 2014 +0100 debuglogger: close log file on exec When using fork+exec on Linux, open files get inherited by the child process unless explicitly marked as FD_CLOEXEC. We should set that flag at least for files which remain open (like the log file when dbgflush_openclose is not active). A truly thread-safe approach would have to use open(O_CLOEXEC), but setting the flag later is sufficient for us. This change is limited to Linux to avoid interfering with other platforms. commit 60c14f7816f674297bde11476d15f7a729185e94 Author: Patrick Ohly Date: Fri Jan 24 08:44:33 2014 +0100 binfileclient: support sending NumberOfChanges In a binfileclient, the NumberOfChanges value became available to late to get included in the TSyncCommand when constructing that command. Even when it got calculated later in TBinfileImplDS::changeLogPreflight() it never got sent to the server. Making the value available earlier is not possible (changeLogPreflight depends on information calculated after generating the sync command), but it is possible to re-check the NumberOfChanges before continuing the sync in the next message. The result is a sync where the first several items are sent without NumberOfChanges, then the next message has NumberOfChanges. commit cbd03b0516c5a699604ef278781e9d458fad6530 Author: Patrick Ohly Date: Wed Jan 8 05:13:13 2014 -0800 sysync_b64: avoid false positive with scan-build clang's scan-build warned: Result of 'malloc' is converted to a pointer of type 'uInt8', which is incompatible with sizeof operand type 'char'. This is not a real problem, because it is safe to assume that sizeof(uInt8) == sizeof(char). But better be explicit about what the code is supposed to do and use sizeof(uInt8). commit 07db39df146a63fcc3a2cbf9295b99d67f386458 Author: Patrick Ohly Date: Wed Jan 8 05:09:55 2014 -0800 syncsession: track pointer clang's scan-build reported a "use after free" error. Probably a false positive, caused by clang not knowing that a function call will always return the same value. Nevertheless it is safer to really track whether the pointer is still non-null, in particular because there are exception handlers which might do a double free. commit 4265685eb93d28bcb6e21853131b51a89291bd5b Author: Patrick Ohly Date: Wed Jan 8 05:07:28 2014 -0800 SyncML TK: fix invalid memory allocation Some unused code allocated memory sufficient for only for a *pointer* instead a *structure* as it should have done. Found by clang's scan-build, for example: Result of 'malloc' is converted to a pointer of type 'struct sml_filter_s', which is incompatible with sizeof operand type 'SmlFilterPtr_t' commit 38970617f539e6b08be4b2c81a211952aa52ced9 Author: Patrick Ohly Date: Wed Jan 8 05:03:24 2014 -0800 enginesessiondispatch: additional NULL check HandleDecodingException() checks for aSessionP for NULL in some places, but not all. Found by clang. Let's assume that the function might get called with a NULL pointer and hence check for that everywhere. commit d89d803eee538bada7d7b2acd81ec28d28a83619 Author: Patrick Ohly Date: Wed Jan 8 05:01:01 2014 -0800 binfileimplclient: simplify code flow analysis When the first if check fails, the second one also fails and thus it and its code only need to be executed when the first one succeeds. This is irrelevant for performance. The reason for changing it is that it avoids a false positive in cppcheck. commit c018d7a53b42e84fe8a6a124a9cebfd147d4b940 Author: Patrick Ohly Date: Wed Jan 8 04:58:46 2014 -0800 fix delete/delete [] mistakes clang's scan-build found some more cases where delete was used instead of delete []. commit fc91177e218f5d6fcf9f80d34842bda4e658a226 Author: Patrick Ohly Date: Mon Jan 6 23:45:32 2014 -0800 binfilebase: avoid virtual methods in destructor cppcheck complains about the virtual method call to platformFileIsOpen that happens indirectly inside the destructor if the instance has not been deconstructed. Because all derived classes must deconstruct the base class first (mentioned in the binfilebase comments), the base class destructor should never have to do anything. If it did, the program would crash. Therefore it is better to not even attempt to do anything in the destructor. commit b2bede775fe523c30c6b14366b49edac1384d3ff Author: Patrick Ohly Date: Mon Jan 6 23:40:51 2014 -0800 fix new [] and delete mismatch Static code analysis with cppcheck found some cases where an array was allocated with new [] and freed with a simple delete instead of delete []. -- 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 christof.schulze at gmx.net Wed Feb 19 13:32:24 2014 From: christof.schulze at gmx.net (Christof Schulze) Date: Wed, 19 Feb 2014 14:32:24 +0100 Subject: [SyncEvolution] SyncEvolution 1.4 released In-Reply-To: <1392738696.6118.20.camel@pohly-mobl1.fritz.box> References: <1392738696.6118.20.camel@pohly-mobl1.fritz.box> Message-ID: <3420280.y01jRLOqpo@lappi> On Tuesday 18 February 2014 16:51:36 Patrick Ohly wrote: > About SyncEvolution > =================== > SyncEvolution synchronizes personal information management (PIM) data > via various protocols (SyncML, CalDAV/CardDAV, ActiveSync). It syncs > contacts, appointments, tasks and memos. It syncs to web services or to > SyncML-capable phones via Bluetooth. > Binaries are available for Linux desktops (using GNOME Evolution, or > KDE's Akonadi), for MeeGo and for Maemo (Nokia N900, N9). Congratulations for finishing this release! Keep up the great work.:) Christof -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From sunnysigara at gmail.com Mon Feb 17 15:46:25 2014 From: sunnysigara at gmail.com (Sunny Sigara) Date: Mon, 17 Feb 2014 15:51:25 +0005 Subject: [SyncEvolution] Google Contacts vCard Incompatibility (cardDAV) Message-ID: <53022edd.25fa420a.3029.0202@mx.google.com> Hi, I was trying to sync evolution contacts with Google using syncevolution on saucy. 1) First I created a single contact (i.e. Tony Stark) in evolution. Now when I try to sync it syncs but not all the vcard fields. For example, it completely ignores instant messaging fields. LOG: @default data changes to be applied during synchronization: *** @default/gadb *** after last sync | current data removed since last sync < > added since last sync ------------------------------------------------------------------------------- > BEGIN:VCARD > N:Stark;Tony > EMAIL;TYPE=HOME;X-EVOLUTION-UI-SLOT=2 > :tony.stark at ironman.com > FN:Tony Stark > VERSION:3.0 > X-EVOLUTION-FILE-AS:Stark\, Tony > X-JABBER;TYPE=HOME;X-EVOLUTION-UI-SLO > T=2:tony.stark at jabber.org > X-SKYPE;TYPE=HOME;X-EVOLUTION-UI-SLOT > =1:tony_stark > X-TWITTER;TYPE=HOME;X-EVOLUTION-UI-SL > OT=3:ironman > END:VCARD ------------------------------------------------------------------------------- [INFO] @default/gadb: started [INFO] @default/gadb: sent 1 [INFO @gcon] @gcon/gadb: started [INFO @gcon] adding "Tony Stark" [INFO @gcon] @gcon/gadb: received 1/1 [INFO] @default/gadb: normal sync done successfully [INFO @gcon] @gcon/gadb: normal sync done successfully Synchronization successful. 2) If I add a msn address in google-contacts & then run the sync, it creates a duplicate in evolution/eds. And even the duplicate doesn't have msn instant-messaging address. LOG: Data modified @default during synchronization: *** @default/gadb *** before sync | after sync removed during sync < > added during sync ------------------------------------------------------------------------------- > BEGIN:VCARD > N:Stark;Tony > EMAIL;TYPE=HOME:tony.stark at ironman.co > m > FN:Tony Stark > VERSION:3.0 > X-EVOLUTION-FILE-AS:Stark\, Tony > X-JABBER;X-EVOLUTION-UI-SLOT=2:tony.s > tark at jabber.org > X-SKYPE;X-EVOLUTION-UI-SLOT=1:tony_st > ark > X-TWITTER;TYPE=HOME;X-EVOLUTION-UI-SL > OT=3:ironman > END:VCARD ------------------------------------------------------------------------------- 3) If I create a new contact in google then sync, again it doesn't sync instant messaging-fields. Contact created in google (exported as vcf): BEGIN:VCARD VERSION:3.0 FN:Bruce Banner N:Banner;Bruce;;; EMAIL;TYPE=INTERNET;TYPE=HOME:bruce\,banner at gammalab.org X-JABBER:bruce.banner at jabber.org X-SKYPE:bruce_banner TEL;TYPE=CELL:9999555555 END:VCARD LOG: Data modified @default during synchronization: *** @default/gadb *** before sync | after sync removed during sync < > added during sync ------------------------------------------------------------------------------- > BEGIN:VCARD > N:Banner;Bruce > EMAIL;TYPE=HOME:bruce\,banner at gammala > b.org > FN:Bruce Banner > TEL;TYPE=CELL:9999555555 > VERSION:3.0 > X-EVOLUTION-FILE-AS:Banner\, Bruce > item1.X-ABLabel:Other > item2.X-ABLabel:Other > END:VCARD ------------------------------------------------------------------------------- 4) If I change anything on "Bruce Banner" locally, log says changes added but doesn't appear in Google(?). LOG: screenshot: http://i.imgur.com/zSnR59w.png While I don't expect to sync evolution related vcard properties (like X-Evolution-Callback, X-Evolution-Radio), It should able to sync normal vcard extensions. Thanks. -------------- 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 Feb 17 19:21:05 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 17 Feb 2014 20:21:05 +0100 Subject: [SyncEvolution] Google Contacts vCard Incompatibility (cardDAV) In-Reply-To: <53022edd.25fa420a.3029.0202@mx.google.com> References: <53022edd.25fa420a.3029.0202@mx.google.com> Message-ID: <1392664865.5951.273.camel@pohly-mobl1.fritz.box> On Mon, 2014-02-17 at 15:51 +0005, Sunny Sigara wrote: > I was trying to sync evolution contacts with Google using > syncevolution on saucy. It's unrelated to your problem, I'm just curious: did you use GNOME Online Accounts or did you compile from source for Ubuntu Online Accounts? > 1) First I created a single contact (i.e. Tony Stark) in evolution. > Now when I try to sync it syncs but not all the vcard fields. > For example, it completely ignores instant messaging fields. With "it" you mean the Google web interface, right? Instant messaging fields do get synchronized to the server and come back, but the server probably doesn't understand the properties used by Evolution (X-AIM, etc.) and SyncEvolution does not yet translate between Evolution and Google. My summary of the current status from the initial release still applies because I haven't had the time to improve the data mapping: Support for Google CardDAV is new. Like Evolution, SyncEvolution does not yet support some of the advanced features of the server, in particular custom labels for phone numbers, emails and addresses. Likewise, some client properties are not supported by the server: CALURI, CATEGORIES, FBURL, GEO and ROLE are not supported. Of ORG, only the first two components are supported. Currently, properties not supported by one side get lost in a full roundtrip sync. Although not mentioned, instant messaging fields fall into the same problem space. > 2) If I add a msn address in google-contacts & then run the sync, it > creates a duplicate in evolution/eds. The duplication shouldn't happen. I'll test that tomorrow, and/or you can send me the syncevolution-log.html files (sync config and target config) from such a sync. Best run the sync with loglevel=4. > And even the duplicate doesn't have msn instant-messaging address. That's expected - SyncEvolution parses the vCard and only stores known elements locally. > 4) If I change anything on "Bruce Banner" locally, log says changes > added but doesn't appear in Google(?). Again, logs with loglevel 4 would be more useful than the sync ouput in the shell window. > While I don't expect to sync evolution related vcard properties (like > X-Evolution-Callback, X-Evolution-Radio), It should able to > sync normal vcard extensions. Yes, that's the goal. It's not there yet, unfortunately. I decided to release SyncEvolution 1.4 anyway, because a limited sync may still be better than none for some users. -- 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 sunnysigara at gmail.com Tue Feb 18 23:28:04 2014 From: sunnysigara at gmail.com (Sunny Sigara) Date: Tue, 18 Feb 2014 23:33:04 +0005 Subject: [SyncEvolution] Google Contacts vCard Incompatibility (cardDAV) In-Reply-To: <1392664865.5951.273.camel@pohly-mobl1.fritz.box> References: <53022edd.25fa420a.3029.0202@mx.google.com> <1392664865.5951.273 .camel@pohly-mobl1.fritz.box> Message-ID: <5303ee67.626d440a.3979.209b@mx.google.com> On Tue, Feb 18, 2014 at 12:51 AM, Patrick Ohly wrote: > It's unrelated to your problem, I'm just curious: did you use GNOME > Online Accounts or did you compile from source for Ubuntu Online > Accounts? > Its GOA. But one thing I like to mention here is that: v1 api endpoints are still working for calDAV & cardDAV with basic http authentication (only for whitelisted applications, I suppose). For example, "syncevolution --print-databases \ backend=carddav \ username=username at gmail.com password=****** \ syncURL=https://www.googleapis.com:443/ " gives same default database as this: "syncevolution --print-databases \ backend=carddav \ username=goa:username at gmail.com \ syncURL=https://www.googleapis.com/.well-known/carddav ". Here is the test setup for both (caldav): http://paste.ubuntu.com/6957096/ > With "it" you mean the Google web interface, right? > Yes. Its Google Web interface. > Instant messaging > fields do get synchronized to the server and come back, but the server > probably doesn't understand the properties used by Evolution (X-AIM, > etc.) and SyncEvolution does not yet translate between Evolution and > Google. > > My summary of the current status from the initial release still > applies > because I haven't had the time to improve the data mapping: > > Support for Google CardDAV is new. Like Evolution, > SyncEvolution does > not yet support some of the advanced features of the server, > in > particular custom labels for phone numbers, emails and > addresses. Likewise, some client properties are not supported > by the > server: CALURI, CATEGORIES, FBURL, GEO and ROLE are not > supported. Of > ORG, only the first two components are supported. Currently, > properties not supported by one side get lost in a full > roundtrip > sync. > > Although not mentioned, instant messaging fields fall into the same > problem space. > That explains everything. Also also from 1.4 release notes, its crystal clear: "Instant Messaging information is supported by both sides with different vCard extensions; the server stores these extensions without showing the information, while SyncEvolution drops the data sent by the server." > The duplication shouldn't happen. I'll test that tomorrow, and/or you > can send me the syncevolution-log.html files (sync config and target > config) from such a sync. Best run the sync with loglevel=4. > I think, I spoke too soon here. After reformatting local & remote databases I couldn't able to reproduce the problem. >> 4) If I change anything on "Bruce Banner" locally, log says changes >> added but doesn't appear in Google(?). >> > Again, logs with loglevel 4 would be more useful than the sync ouput > in > the shell window. > I attached the log. But I don't think further investigation on this is necessary, as you explained, how some client properties ((CALURI, CATEGORIES, FBURL, GEO) are not supported by the server (yet). Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Wed Feb 19 09:26:20 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 19 Feb 2014 10:26:20 +0100 Subject: [SyncEvolution] Google Contacts vCard Incompatibility (cardDAV) In-Reply-To: <5303ee67.626d440a.3979.209b@mx.google.com> References: <53022edd.25fa420a.3029.0202@mx.google.com> <1392664865.5951.273 .camel@pohly-mobl1.fritz.box> <5303ee67.626d440a.3979.209b@mx.google.com> Message-ID: <1392801980.6118.34.camel@pohly-mobl1.fritz.box> On Tue, 2014-02-18 at 23:33 +0005, Sunny Sigara wrote: > > On Tue, Feb 18, 2014 at 12:51 AM, Patrick Ohly > wrote: > > It's unrelated to your problem, I'm just curious: did you use GNOME > > Online Accounts or did you compile from source for Ubuntu Online > > Accounts? > > > Its GOA. > > > But one thing I like to mention here is that: v1 api endpoints are > still working for calDAV & cardDAV > with basic http authentication (only for whitelisted applications, I > suppose). For example, > > > "syncevolution --print-databases \ > backend=carddav \ > username=username at gmail.com password=****** \ > syncURL=https://www.googleapis.com:443/ " > > > gives same default database as this: > > > "syncevolution --print-databases \ > backend=carddav \ > username=goa:username at gmail.com \ > syncURL=https://www.googleapis.com/.well-known/carddav ". The syncURL is effectively the same, because https://www.googleapis.com:443/ will cause .well-known/carddav to be checked. But it is interesting that plain authentication still works. I stopped testing that because it was meant to be disabled. > > Instant messaging fields do get synchronized to the server and come > > back, but the server probably doesn't understand the properties used > > by Evolution (X-AIM, etc.) and SyncEvolution does not yet translate > > between Evolution and Google. My summary of the current status from > > the initial release still applies because I haven't had the time to > > improve the data mapping: Support for Google CardDAV is new. Like > > Evolution, SyncEvolution does not yet support some of the advanced > > features of the server, in particular custom labels for phone > > numbers, emails and addresses. Likewise, some client properties are > > not supported by the server: CALURI, CATEGORIES, FBURL, GEO and ROLE > > are not supported. Of ORG, only the first two components are > > supported. Currently, properties not supported by one side get lost > > in a full roundtrip sync. Although not mentioned, instant messaging > > fields fall into the same problem space. > > > That explains everything. Also also from 1.4 release notes, its > crystal clear: > > > "Instant Messaging information is supported by both sides with > different vCard extensions; the server stores these extensions without > showing the information, while SyncEvolution drops the data sent by > the server." I added that in response to your report. Thanks for pointing it out, I hadn't thought about all user-visible consequences before. BTW, the "properties not supported by one side" only applies to the standard vCard properties. As seen with X-AIM, extensions are preserved by both Google. SyncEvolution/Evolution does something similar for simple extensions, but has support for grouping (used for custom labels) not enabled yet. > > The duplication shouldn't happen. I'll test that tomorrow, and/or > > you can send me the syncevolution-log.html files (sync config and > > target config) from such a sync. Best run the sync with loglevel=4. > > > I think, I spoke too soon here. After reformatting local & remote > databases I > couldn't able to reproduce the problem. It might make sense to enable loglevel=4 permanently and increase maxLogDirs to keep the most recent logs around. Then if something unexpected happens, there is still a full trace of it. > > 4) If I change anything on "Bruce Banner" locally, log says > > changes added but doesn't appear in Google(?). > > Again, logs with loglevel 4 would be more useful than the sync ouput > > in the shell window. > > > > > I attached the log. But I don't think further investigation on this is > necessary, > as you explained, how some client properties ((CALURI, CATEGORIES, > FBURL, GEO) > are not supported by the server (yet). Okay. I thought you had modified one of the supported properties and that change did not make it across. -- 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 sunnysigara at gmail.com Thu Feb 13 21:29:44 2014 From: sunnysigara at gmail.com (Sunny Sigara) Date: Thu, 13 Feb 2014 21:34:44 +0005 Subject: [SyncEvolution] Syncevlution --import could not import all events for some calendars(?) Message-ID: <52fd3953.0458440a.6d18.ffff89e5@mx.google.com> Hello Patrick, I am trying to import a google holiday calendar with "syncevolution --import function. While it can import all events from a evolution-ical file just fine, it fails to do so for google calendar. I am using syncevolution-1.3.2 on saucy. ''' cd ~/Desktop/calendar wget https://www.google.com/calendar/ical/en.indian%23holiday%40group.v.calendar.google.com/public/basic.ics syncevolution --configure backend=evolution-calendar database=Holidays @default hdcal syncevolution --import ~/Desktop/calendar/basic.ics @default hdcal #0: 20140204_60o30d36cgo30c1g60o30dr4ck%40google%2ecom-rid ''' As it is visible from the output, it could only import one single event. If I manually import all events using evolution & then export like this: "syncevolution --export calendar.ics backend=evolution-calendar database=Holidays" & then try to import.....it imports all events properly. Only for google holidays(& some other) calendar it can import only a single event. Here is the holiday-ical-file: http://paste.ubuntu.com/6927791/ -------------- 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 Fri Feb 14 09:47:50 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 14 Feb 2014 10:47:50 +0100 Subject: [SyncEvolution] Syncevlution --import could not import all events for some calendars(?) In-Reply-To: <52fd3953.0458440a.6d18.ffff89e5@mx.google.com> References: <52fd3953.0458440a.6d18.ffff89e5@mx.google.com> Message-ID: <1392371270.5951.225.camel@pohly-mobl1.fritz.box> On Thu, 2014-02-13 at 21:34 +0005, Sunny Sigara wrote: > I am trying to import a google holiday calendar with "syncevolution > --import function. > While it can import all events from a evolution-ical file just fine, > it fails to do so for google calendar. I am using syncevolution-1.3.2 > on saucy. > > > ''' > cd ~/Desktop/calendar > > > wget https://www.google.com/calendar/ical/en.indian%23holiday% > 40group.v.calendar.google.com/public/basic.ics The problem is that SyncEvolution cannot split up .ics files which have multiple VEVENT/VTODO/VJOURNAL components in a single big VCALENDAR. This is what the Google calendar file contains. The --import code which splits the file and then passes individual chunks of it to the backend into which they are to be imported only knows how to split at empty lines (the default). From the man page: syncevolution --print-items syncevolution [--delimiter ] --export ||- [ [ [ ...]]] syncevolution [--delimiter |none] --import ||- [ ] syncevolution --update syncevolution [--delimiter |none] --update |- ... syncevolution --delete-items ( ... | *) [...] --export Writes all items in the source or all items whose is given into a directory if the --export parameter exists and is a directory. The of each item is used as file name. Otherwise it cre? ates a new file under that name and writes the selected items separated by the chosen delimiter string. stdout can be selected with a dash. The default delimiter (two line breaks) matches a blank line. As a special case, it also matches a blank line with DOS line ending (line break, carriage return, line break). This works for vCard 3.0 and iCalendar 2.0, which never contain blank lines. When exporting, the default delimiter will always insert two line breaks regardless whether the items contain DOS line ends. As a special case, the initial newline of a delimiter is skipped if the item already ends in a newline. --import Adds all items found in the directory or input file to the source. When reading from a directory, each file is treated as one item. Otherwise the input is split at the chosen delimiter. "none" as delimiter disables splitting of the input. If someone was interested in fixing this, he or she would have to add methods in SyncSource for splitting up text according to the expected content and then have the generic --import code call that. Until then one has to pre-process input files to get the format that SyncEvolution knows how to import. I'm attaching such a script. It handles .ics files with one or more VCALENDAR inside. -- 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 -------------- A non-text attachment was scrubbed... Name: split-ics.py Type: text/x-python Size: 2084 bytes Desc: not available URL: From sunnysigara at gmail.com Sat Feb 15 13:23:23 2014 From: sunnysigara at gmail.com (Sunny Sigara) Date: Sat, 15 Feb 2014 13:28:23 +0005 Subject: [SyncEvolution] Syncevlution --import could not import all events for some calendars(?) In-Reply-To: <1392371270.5951.225.camel@pohly-mobl1.fritz.box> References: <52fd3953.0458440a.6d18.ffff89e5@mx.google.com> <1392371270.5951 .225.camel@pohly-mobl1.fritz.box> Message-ID: <52ff6a57.635e440a.5c0b.3669@mx.google.com> On Fri, Feb 14, 2014 at 3:17 PM, Patrick Ohly wrote: > If someone was interested in fixing this, he or she would have to add > methods in SyncSource for splitting up text according to the expected > content and then have the generic --import code call that. > > Until then one has to pre-process input files to get the format that > SyncEvolution knows how to import. I'm attaching such a script. It > handles .ics files with one or more VCALENDAR inside. > Thanks For the explanation & the script. -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Fri Feb 14 13:47:05 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 14 Feb 2014 14:47:05 +0100 Subject: [SyncEvolution] ActiveSync binaries (was: Re: Syncing two servers) In-Reply-To: <1391411357.30349.215.camel@pohly-mobl1.fritz.box> References: <1389552631.5855.391.camel@pohly-mobl1.fritz.box> <1391411357.30349.215.camel@pohly-mobl1.fritz.box> Message-ID: <1392385625.5951.236.camel@pohly-mobl1.fritz.box> On Mon, 2014-02-03 at 08:09 +0100, Patrick Ohly wrote: > On Mon, 2014-02-03 at 00:35 +0100, Emiliano Heyns wrote: > > OK, I just saw 1.3.99.7 roll in (yay!), but when I try to install > > activesyncd and syncevolution-activesync I get: > > > > > > sudo aptitude install activesyncd syncevolution-activesync > > The following NEW packages will be installed: > > activesyncd{b} syncevolution-activesync > > 0 packages upgraded, 2 newly installed, 0 to remove and 8 not > > upgraded. > > Need to get 2,120 kB of archives. After unpacking 8,962 kB will be > > used. > > The following packages have unmet dependencies: > > activesyncd : Depends: libebook-1.2-13 which is a virtual package. > > Depends: libical0 which is a virtual package. > > activesyncd has hard dependencies on specific EDS versions, in this case > EDS < 3.6. I wasn't planning to change that. What I fixed was the > installation of SyncEvolution itself, for non-ActiveSync usage. > > I guess I could try to compile activesyncd multiple times, on different > platforms. SyncEvolution 1.4 will have activesyncd-wheezy/saucy/trusty and syncevolution-activesync-wheezy/saucy/trusty .deb/.rpm/.tar.gz. In addition, the apt repo also has meta activesyncd and syncevolution-activesync packages which causes "apt-get install activesyncd syncevolution-activesync" to pull in a suitable real package. -- 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. _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From Juergen.Dankoweit at T-Online.de Mon Feb 10 14:42:35 2014 From: Juergen.Dankoweit at T-Online.de (=?ISO-8859-15?Q?J=FCrgen_Dankoweit?=) Date: Mon, 10 Feb 2014 15:42:35 +0100 Subject: [SyncEvolution] Synching my Nokia N900 does not work Message-ID: <52F8E55B.9010604@T-Online.de> Hello to the list. On my Smartphone Nokai N900 I use SyncEvolution 1.3 to sync my calenders and addressbook. But it does not work! Everytime I enter $ syncevolution --sync slw heimnetz_kal_berr I get the following output [INFO] @default/addressbook: inactive [INFO] @default/contacts: inactive [INFO] @default/memo: inactive [INFO] @default/todo: inactive [INFO @heimnetz_kal_berr] target side of local sync ready [INFO @heimnetz_kal_berr] @heimnetz_kal_berr/addressbook: inactive [INFO @heimnetz_kal_berr] @heimnetz_kal_berr/memo: inactive [INFO @heimnetz_kal_berr] @heimnetz_kal_berr/todo: inactive [INFO @heimnetz_kal_berr] @heimnetz_kal_berr/calendar: starting normal sync from client (peer is server) [INFO] @default/calendar: starting normal sync from client (peer is client) [INFO] creating complete data backup of source calendar before sync (enabled with dumpData and needed for printChanges) @default data changes to be applied during synchronization: *** @default/calendar *** Comparison was impossible. [INFO] @default/calendar: started [INFO @heimnetz_kal_berr] @heimnetz_kal_berr/calendar: started [INFO] @default/calendar: normal sync done successfully [INFO @heimnetz_kal_berr] @heimnetz_kal_berr/calendar: normal sync done successfully Synchronization successful. Changes applied during synchronization (@heimnetz_kal_berr): +---------------|-----------------------|-----------------------|-CON-+ | | @heimnetz_kal_berr | @default | FLI | | Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | one-way-from-local, 0 KB sent by client, 0 KB received | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | start Mon Feb 10 15:33:00 2014, duration 0:02min | | synchronization completed successfully | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ [INFO] creating complete data backup after sync (enabled with dumpData and needed for printChanges) Synchronization successful. Changes applied during synchronization: +---------------|-----------------------|-----------------------|-CON-+ | | @default | @heimnetz_kal_berr | FLI | | Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | one-way-from-remote, 0 KB sent by client, 0 KB received | | item(s) in database backup: 0 before sync, 0 after it | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | start Mon Feb 10 15:32:58 2014, duration 0:04min | | synchronization completed successfully | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ Data modified @default during synchronization: *** @default/calendar *** Comparison was impossible. And the Apache-LOG says: x.x.x.x - juergen [10/Feb/2014:15:29:32 +0100] "REPORT /cal.php/calendars/juergen/berrreisen/ HTTP/1.1" 200 303 x.x.x.x - juergen [10/Feb/2014:15:29:32 +0100] "PROPFIND /cal.php/calendars/juergen/berrreisen/ HTTP/1.1" 200 303 x.x.x.x - juergen [10/Feb/2014:15:31:08 +0100] "REPORT /cal.php/calendars/juergen/berrreisen/ HTTP/1.1" 200 303 x.x.x.x - juergen [10/Feb/2014:15:31:09 +0100] "PROPFIND /cal.php/calendars/juergen/berrreisen/ HTTP/1.1" 200 303 My question: Why aren't there any datas transferred? I don't understand it. Thanks for the answers in advance Best regards Juergen _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Mon Feb 10 15:49:30 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 10 Feb 2014 16:49:30 +0100 Subject: [SyncEvolution] Synching my Nokia N900 does not work In-Reply-To: <52F8E55B.9010604@T-Online.de> References: <52F8E55B.9010604@T-Online.de> Message-ID: <1392047370.5951.147.camel@pohly-mobl1.fritz.box> On Mon, 2014-02-10 at 15:42 +0100, J?rgen Dankoweit wrote: > Hello to the list. > > On my Smartphone Nokai N900 I use SyncEvolution 1.3 to sync my calenders > and addressbook. > But it does not work! > > Everytime I enter > $ syncevolution --sync slw heimnetz_kal_berr ^^^ Do you actually use "slw" on the N900 or is this a typo in your email? > Changes applied during synchronization: > +---------------|-----------------------|-----------------------|-CON-+ > | | @default | @heimnetz_kal_berr | FLI | > | Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS | > +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > | calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > | one-way-from-remote, 0 KB sent by client, 0 KB received | > | item(s) in database backup: 0 before sync, 0 after it | > +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > | start Mon Feb 10 15:32:58 2014, duration 0:04min | > | synchronization completed successfully | > +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ It is a bit strange that the sync mode is listed as "one-way-from-remote" here. It should be "slow" if that's what you asked for. > Data modified @default during synchronization: > *** @default/calendar *** > Comparison was impossible. > > And the Apache-LOG says: > x.x.x.x - juergen [10/Feb/2014:15:29:32 +0100] "REPORT > /cal.php/calendars/juergen/berrreisen/ HTTP/1.1" 200 303 > x.x.x.x - juergen [10/Feb/2014:15:29:32 +0100] "PROPFIND > /cal.php/calendars/juergen/berrreisen/ HTTP/1.1" 200 303 > x.x.x.x - juergen [10/Feb/2014:15:31:08 +0100] "REPORT > /cal.php/calendars/juergen/berrreisen/ HTTP/1.1" 200 303 > x.x.x.x - juergen [10/Feb/2014:15:31:09 +0100] "PROPFIND > /cal.php/calendars/juergen/berrreisen/ HTTP/1.1" 200 303 > > > My question: Why aren't there any datas transferred? I don't understand it. Question back: what data should be transferred? Does the cal.php/calendars/juergen/berrreisen/ really contain any events? You can test this with syncevolution --print-items @heimnetz_kal_berr calendar If that should list items and doesn't, then the output of "SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 --print-items @heimnetz_kal_berr calendar" would be useful. Which CalDAV server is this? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From Juergen.Dankoweit at T-Online.de Mon Feb 10 18:58:39 2014 From: Juergen.Dankoweit at T-Online.de (=?UTF-8?B?SsO8cmdlbiBEYW5rb3dlaXQ=?=) Date: Mon, 10 Feb 2014 19:58:39 +0100 Subject: [SyncEvolution] Synching my Nokia N900 does not work In-Reply-To: <1392047370.5951.147.camel@pohly-mobl1.fritz.box> References: <52F8E55B.9010604@T-Online.de> <1392047370.5951.147.camel@pohly-mobl1.fritz.box> Message-ID: <52F9215F.1030403@T-Online.de> Hello Patrick, many thanks for your fast reply. Am 10.02.2014 16:49, schrieb Patrick Ohly: > On Mon, 2014-02-10 at 15:42 +0100, J?rgen Dankoweit wrote: >> Hello to the list. >> >> On my Smartphone Nokai N900 I use SyncEvolution 1.3 to sync my calenders >> and addressbook. >> But it does not work! >> >> Everytime I enter >> $ syncevolution --sync slw heimnetz_kal_berr > ^^^ > Do you actually use "slw" on the N900 or is this a typo in your email? Oh, sorry. This is a typo :) > > If that should list items and doesn't, then the output of > "SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 > --print-items @heimnetz_kal_berr calendar" would be useful. Oh my god. I found the error which isn't displayed in any log file. The author of that CalDAV server made a great mistake: he didn't check whether an array element contains information or not. > > Which CalDAV server is this? > It is Baikal http://http://baikal-server.com/ It is based on SabreDAV. But it doesn't work because I don't get any authorisation. It always tells me that the username isn't correct but it is. So I will search for an other CalDAV or buy a new smartphone with a working CalDAV client. Best regards From patrick.ohly at intel.com Mon Feb 10 22:31:13 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 10 Feb 2014 23:31:13 +0100 Subject: [SyncEvolution] Synching my Nokia N900 does not work In-Reply-To: <52F9215F.1030403@T-Online.de> References: <52F8E55B.9010604@T-Online.de> <1392047370.5951.147.camel@pohly-mobl1.fritz.box> <52F9215F.1030403@T-Online.de> Message-ID: <1392071473.5951.196.camel@pohly-mobl1.fritz.box> On Mon, 2014-02-10 at 19:58 +0100, J?rgen Dankoweit wrote: > Hello Patrick, > > many thanks for your fast reply. > > Am 10.02.2014 16:49, schrieb Patrick Ohly: > > On Mon, 2014-02-10 at 15:42 +0100, J?rgen Dankoweit wrote: > > If that should list items and doesn't, then the output of > > "SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 > > --print-items @heimnetz_kal_berr calendar" would be useful. > > Oh my god. I found the error which isn't displayed in any log file. > The author of that CalDAV server made a great mistake: he didn't check > whether an array element contains information or not. So the error is clearly on the server side? > > Which CalDAV server is this? > > > > It is Baikal http://http://baikal-server.com/ > It is based on SabreDAV. But it doesn't work because I don't get any > authorisation. It always tells me that the username isn't correct but it is. > So I will search for an other CalDAV or buy a new smartphone with a > working CalDAV client. When you say "working CalDAV client", do you mean one which works around the server bug? If that's possible, not breaking other servers and not introducing egregious special cases, then I don't mind adapting SyncEvolution. But for that I need to know more about this server bug. -- 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 Juergen.Dankoweit at T-Online.de Wed Feb 12 19:57:54 2014 From: Juergen.Dankoweit at T-Online.de (=?UTF-8?B?SsO8cmdlbiBEYW5rb3dlaXQ=?=) Date: Wed, 12 Feb 2014 20:57:54 +0100 Subject: [SyncEvolution] Synching my Nokia N900 does not work In-Reply-To: <1392071473.5951.196.camel@pohly-mobl1.fritz.box> References: <52F8E55B.9010604@T-Online.de> <1392047370.5951.147.camel@pohly-mobl1.fritz.box> <52F9215F.1030403@T-Online.de> <1392071473.5951.196.camel@pohly-mobl1.fritz.box> Message-ID: <52FBD242.2010205@T-Online.de> Hello Patrick, forget Baikal. This piece of "software" is so buggy. One example: there is an SQL statement "SELECT * FROM users HERE id=''" the field id has type integer. Here is an comparison between integer an string. And there are many bugs where the author hopes that every client fullfills the standarts for 100 percent. Meanwhile I found out that Baikal works with SyncEvolution when 1) the default calendar is addressed 2) the default calendar belongs to the first created user And therefore I will stop the whole thing. Tnanks for your time. Best regards J?rgen From Ralf-Luederitz at onlinehome.de Wed Feb 12 15:10:15 2014 From: Ralf-Luederitz at onlinehome.de (Ralf =?ISO-8859-1?Q?L=FCderitz?=) Date: Wed, 12 Feb 2014 16:10:15 +0100 Subject: [SyncEvolution] syncevolution -relocation error- Message-ID: <1392217815.5145.2.camel@ralf-Inspiron-N5050> syncevolution -relocation error- Submitted by Ralf on 12 February, 2014 - 14:14. syncevolution will not work. There is an relocation error. /usr/lib/libsyncevolution.so.0: Symbol SySync ConsolePrintf, version VER-1.0 not defined in file libsynthesis.so.0 with link time reference OS: linuxmint 15 Olivia evolution 3.6.4 server funambol 10.0.3 In sync-ui configuration impossible the command gksu syncevolution comes in terminal without relocation error Can you help me? Ralf -------------- 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 Wed Feb 12 18:33:58 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 12 Feb 2014 19:33:58 +0100 Subject: [SyncEvolution] syncevolution -relocation error- In-Reply-To: <1392217815.5145.2.camel@ralf-Inspiron-N5050> References: <1392217815.5145.2.camel@ralf-Inspiron-N5050> Message-ID: <1392230038.5951.213.camel@pohly-mobl1.fritz.box> On Wed, 2014-02-12 at 16:10 +0100, Ralf L?deritz wrote: > /usr/lib/libsyncevolution.so.0: Symbol SySync ConsolePrintf, version > VER-1.0 not defined in file libsynthesis.so.0 with link time reference > > OS: linuxmint 15 Olivia evolution 3.6.4 server funambol 10.0.3 How did you install SyncEvolution? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From dclement1 at laposte.net Fri Feb 7 14:32:30 2014 From: dclement1 at laposte.net (Daniel CLEMENT) Date: Fri, 7 Feb 2014 15:32:30 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1388651826.5855.243.camel@pohly-mobl1.fritz.box> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> Message-ID: <1391783550.4213.8.camel@m6400> Le jeudi 02 janvier 2014 ? 09:37 +0100, Patrick Ohly a ?crit : > 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. > Hello, I was waiting for the latest update pack in Linux Mint Debian to try this. Evolution 3.8 is part of the updates, so I needed Syncevo. 1.3.99. I pulled it from the unstable repo., but it doesn't look good. The GUI is sort of empty (no icon, no status) and if I choose "Change or modify sync service", I get: "Impossible to retrieve the list of supported services from Syncevolution". (I try my best to translate from French.) I tried to rename ~/.config/syncevolution, but no luck. Fortunately this happened on a "test" PC, but I'd like to get it fixed before applying these upgrades to the production PC. I'm trying to attach a snapshot, but I'm not sure it will reach the list. Best regards, -- Daniel CLEMENT -------------- next part -------------- A non-text attachment was scrubbed... Name: syncevo_1399.png Type: image/png Size: 40139 bytes Desc: not available URL: From patrick.ohly at intel.com Fri Feb 7 16:22:07 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 07 Feb 2014 17:22:07 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1391783550.4213.8.camel@m6400> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> Message-ID: <1391790127.5951.104.camel@pohly-mobl1.fritz.box> On Fri, 2014-02-07 at 15:32 +0100, Daniel CLEMENT wrote: > Le jeudi 02 janvier 2014 ? 09:37 +0100, Patrick Ohly a ?crit : > > 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. > > > Hello, I was waiting for the latest update pack in Linux Mint Debian to > try this. Evolution 3.8 is part of the updates, so I needed Syncevo. > 1.3.99. I pulled it from the unstable repo., but it doesn't look good. > > The GUI is sort of empty (no icon, no status) and if I choose "Change or > modify sync service", I get: "Impossible to retrieve the list of > supported services from Syncevolution". (I try my best to translate from > French.) Looks like syncevo-dbus-server isn't running properly. Please start it in a shell with "/usr/libexec/syncevo-dbus-server" and check what it reports. Then start the UI. -- 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 dclement1 at laposte.net Fri Feb 7 17:16:18 2014 From: dclement1 at laposte.net (Daniel CLEMENT) Date: Fri, 7 Feb 2014 18:16:18 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1391790127.5951.104.camel@pohly-mobl1.fritz.box> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> <1391790127.5951.104.camel@pohly-mobl1.fritz.box> Message-ID: <1391793378.9264.3.camel@m6400> Le vendredi 07 f?vrier 2014 ? 17:22 +0100, Patrick Ohly a ?crit : > On Fri, 2014-02-07 at 15:32 +0100, Daniel CLEMENT wrote: > > Le jeudi 02 janvier 2014 ? 09:37 +0100, Patrick Ohly a ?crit : > > > 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. > > > > > Hello, I was waiting for the latest update pack in Linux Mint Debian to > > try this. Evolution 3.8 is part of the updates, so I needed Syncevo. > > 1.3.99. I pulled it from the unstable repo., but it doesn't look good. > > > > The GUI is sort of empty (no icon, no status) and if I choose "Change or > > modify sync service", I get: "Impossible to retrieve the list of > > supported services from Syncevolution". (I try my best to translate from > > French.) > > Looks like syncevo-dbus-server isn't running properly. > > Please start it in a shell with "/usr/libexec/syncevo-dbus-server" and > check what it reports. Then start the UI. > It was not running at all, which explains the odd-looking UI. But the trouble is, I can't start it from the command line either: it reports nothing, and does not appear among the running processes. -- Daniel CLEMENT _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Feb 7 18:46:51 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 07 Feb 2014 19:46:51 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1391793378.9264.3.camel@m6400> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> <1391790127.5951.104.camel@pohly-mobl1.fritz.box> <1391793378.9264.3.camel@m6400> Message-ID: <1391798811.5951.112.camel@pohly-mobl1.fritz.box> On Fri, 2014-02-07 at 18:16 +0100, Daniel CLEMENT wrote: > Le vendredi 07 f?vrier 2014 ? 17:22 +0100, Patrick Ohly a ?crit : > > Looks like syncevo-dbus-server isn't running properly. > > > > Please start it in a shell with "/usr/libexec/syncevo-dbus-server" and > > check what it reports. Then start the UI. > > > It was not running at all, which explains the odd-looking UI. But the > trouble is, I can't start it from the command line either: it reports > nothing, and does not appear among the running processes. So you type the command and you get a prompt? What does /usr/libexec/syncevo-dbus-server --no-syslog --stdout say? -- 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 dclement1 at laposte.net Fri Feb 7 21:23:04 2014 From: dclement1 at laposte.net (Daniel CLEMENT) Date: Fri, 7 Feb 2014 22:23:04 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1391798811.5951.112.camel@pohly-mobl1.fritz.box> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> <1391790127.5951.104.camel@pohly-mobl1.fritz.box> <1391793378.9264.3.camel@m6400> <1391798811.5951.112.camel@pohly-mobl1.fritz.box> Message-ID: <1391808184.4097.6.camel@m6400> Le vendredi 07 f?vrier 2014 ? 19:46 +0100, Patrick Ohly a ?crit : > On Fri, 2014-02-07 at 18:16 +0100, Daniel CLEMENT wrote: > > Le vendredi 07 f?vrier 2014 ? 17:22 +0100, Patrick Ohly a ?crit : > > > Looks like syncevo-dbus-server isn't running properly. > > > > > > Please start it in a shell with "/usr/libexec/syncevo-dbus-server" and > > > check what it reports. Then start the UI. > > > > > It was not running at all, which explains the odd-looking UI. But the > > trouble is, I can't start it from the command line either: it reports > > nothing, and does not appear among the running processes. > > So you type the command and you get a prompt? Exactly. > > What does > > /usr/libexec/syncevo-dbus-server --no-syslog --stdout > > say? > It still leaves me with an empty prompt !? Perhaps there is a residue of an old config. which is still interfering? On this (test) PC I could try and purge and reinstall everything. -- Daniel CLEMENT _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From dclement1 at laposte.net Sun Feb 9 14:20:21 2014 From: dclement1 at laposte.net (Daniel CLEMENT) Date: Sun, 9 Feb 2014 15:20:21 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1391808184.4097.6.camel@m6400> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> <1391790127.5951.104.camel@pohly-mobl1.fritz.box> <1391793378.9264.3.camel@m6400> <1391798811.5951.112.camel@pohly-mobl1.fritz.box> <1391808184.4097.6.camel@m6400> Message-ID: <1391955621.4106.6.camel@m6400> Le vendredi 07 f?vrier 2014 ? 22:23 +0100, Daniel CLEMENT a ?crit : > [...] > > Perhaps there is a residue of an old config. which is still interfering? > On this (test) PC I could try and purge and reinstall everything. Something must have gone wrong on this particular PC. I reinstalled, no luck. Out of ideas I tried Syncevo 1.3.2 (from the normal repos.). Granted, it's not compatible with Evolution 3.8, but let's pretend I try to sync something else... The result is that I get the same weird UI and the inability to run syncevo-dbus-server. To be complete, the last batch of updates in Linux Mint Debian essentially brings it on the current level of Debian Testing. -- Daniel CLEMENT _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sun Feb 9 19:05:39 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 09 Feb 2014 20:05:39 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1391808184.4097.6.camel@m6400> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> <1391790127.5951.104.camel@pohly-mobl1.fritz.box> <1391793378.9264.3.camel@m6400> <1391798811.5951.112.camel@pohly-mobl1.fritz.box> <1391808184.4097.6.camel@m6400> Message-ID: <1391972739.5951.128.camel@pohly-mobl1.fritz.box> On Fri, 2014-02-07 at 22:23 +0100, Daniel CLEMENT wrote: > Perhaps there is a residue of an old config. which is still interfering? > On this (test) PC I could try and purge and reinstall everything. Even if it fails there should be some indication how. Please type the commands below in a shell and send the resulting /tmp/syncevo.out text file. script /tmp/syncevo.out syncevolution --daemon=no --version SYNCEVOLUTION_DEBUG=1 gdb --args /usr/libexec/syncevo-dbus-server --no-syslog --stdout --verbosity 3 -d unlimited run Now it should still be running (no gdb command prompt). Run the sync-ui separately. If it crashes or quits, gdb will tell you. In that case, type thread apply all bt -- 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 dclement1 at laposte.net Mon Feb 10 14:22:17 2014 From: dclement1 at laposte.net (Daniel CLEMENT) Date: Mon, 10 Feb 2014 15:22:17 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1391972739.5951.128.camel@pohly-mobl1.fritz.box> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> <1391790127.5951.104.camel@pohly-mobl1.fritz.box> <1391793378.9264.3.camel@m6400> <1391798811.5951.112.camel@pohly-mobl1.fritz.box> <1391808184.4097.6.camel@m6400> <1391972739.5951.128.camel@pohly-mobl1.fritz.box> Message-ID: <1392042137.4099.4.camel@m6400> Le dimanche 09 f?vrier 2014 ? 20:05 +0100, Patrick Ohly a ?crit : > On Fri, 2014-02-07 at 22:23 +0100, Daniel CLEMENT wrote: > > Perhaps there is a residue of an old config. which is still interfering? > > On this (test) PC I could try and purge and reinstall everything. > > Even if it fails there should be some indication how. Please type the > commands below in a shell and send the resulting /tmp/syncevo.out text > file. > > script /tmp/syncevo.out > syncevolution --daemon=no --version > SYNCEVOLUTION_DEBUG=1 gdb --args /usr/libexec/syncevo-dbus-server --no-syslog --stdout --verbosity 3 -d unlimited > run > > Now it should still be running (no gdb command prompt). Run the sync-ui > separately. If it crashes or quits, gdb will tell you. In that case, > type > > thread apply all bt > I get this: ----- SyncEvolution 1.3.99.5 Loading backend library /usr/local/lib/syncevolution/backends/platformgnome.so Loading backend library /usr/local/lib/syncevolution/backends/platformkde.so Loading backend library /usr/local/lib/syncevolution/backends/providergoa.so Loading backend library /usr/local/lib/syncevolution/backends/providergsso.so Loading backend library /usr/local/lib/syncevolution/backends/syncactivesync.so Loading backend library /usr/local/lib/syncevolution/backends/syncaddressbook.so Loading backend library /usr/local/lib/syncevolution/backends/syncakonadi.so Loading backend library /usr/local/lib/syncevolution/backends/syncdav.so Loading backend library /usr/local/lib/syncevolution/backends/syncebook.so Loading backend library /usr/local/lib/syncevolution/backends/syncecal.so Loading backend library /usr/local/lib/syncevolution/backends/syncfile.so Loading backend library /usr/local/lib/syncevolution/backends/synckcalextended.so Loading backend library /usr/local/lib/syncevolution/backends/syncmaemocal.so Loading backend library /usr/local/lib/syncevolution/backends/syncpbap.so Loading backend library /usr/local/lib/syncevolution/backends/syncqtcontacts.so Loading backend library /usr/local/lib/syncevolution/backends/syncsqlite.so Loading backend library /usr/local/lib/syncevolution/backends/syncxmlrpc.so ----- ...but the 2nd command produces no further output. I tried to rerun everything, but on the next runs the syncevo.out remains empty!? If I try and launch the UI, it remains "strange" as before (doesn't crash, though). -- Daniel CLEMENT From patrick.ohly at intel.com Mon Feb 10 15:40:16 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 10 Feb 2014 16:40:16 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1392042137.4099.4.camel@m6400> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> <1391790127.5951.104.camel@pohly-mobl1.fritz.box> <1391793378.9264.3.camel@m6400> <1391798811.5951.112.camel@pohly-mobl1.fritz.box> <1391808184.4097.6.camel@m6400> <1391972739.5951.128.camel@pohly-mobl1.fritz.box> <1392042137.4099.4.camel@m6400> Message-ID: <1392046816.5951.142.camel@pohly-mobl1.fritz.box> On Mon, 2014-02-10 at 15:22 +0100, Daniel CLEMENT wrote: > Le dimanche 09 f?vrier 2014 ? 20:05 +0100, Patrick Ohly a ?crit : > > On Fri, 2014-02-07 at 22:23 +0100, Daniel CLEMENT wrote: > > > Perhaps there is a residue of an old config. which is still interfering? > > > On this (test) PC I could try and purge and reinstall everything. > > > > Even if it fails there should be some indication how. Please type the > > commands below in a shell and send the resulting /tmp/syncevo.out text > > file. > > > > script /tmp/syncevo.out > > syncevolution --daemon=no --version > > SYNCEVOLUTION_DEBUG=1 gdb --args /usr/libexec/syncevo-dbus-server --no-syslog --stdout --verbosity 3 -d unlimited > > run > > > > Now it should still be running (no gdb command prompt). Run the sync-ui > > separately. If it crashes or quits, gdb will tell you. In that case, > > type > > > > thread apply all bt > > > I get this: > ----- [...] > ...but the 2nd command produces no further output. I tried to rerun > everything, but on the next runs the syncevo.out remains empty!? Can you please follow the instructions step-by-step and then attach the entire /tmp/syncevo.out file? I can't believe that gdb quits without printing anything. Therefore I want to see exactly what you doing. Otherwise I can't help. Copy-paste each line, press return after each line. The first command starts a script session, the third commands starts gdb (must be installed), then "run" inside gdb starts syncevo-dbus-server. -- 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 dclement1 at laposte.net Mon Feb 10 16:17:38 2014 From: dclement1 at laposte.net (Daniel CLEMENT) Date: Mon, 10 Feb 2014 17:17:38 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1392046816.5951.142.camel@pohly-mobl1.fritz.box> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> <1391790127.5951.104.camel@pohly-mobl1.fritz.box> <1391793378.9264.3.camel@m6400> <1391798811.5951.112.camel@pohly-mobl1.fritz.box> <1391808184.4097.6.camel@m6400> <1391972739.5951.128.camel@pohly-mobl1.fritz.box> <1392042137.4099.4.camel@m6400> <1392046816.5951.142.camel@pohly-mobl1.fritz.box> Message-ID: <1392049058.4099.16.camel@m6400> Le lundi 10 f?vrier 2014 ? 16:40 +0100, Patrick Ohly a ?crit : > On Mon, 2014-02-10 at 15:22 +0100, Daniel CLEMENT wrote: > > Le dimanche 09 f?vrier 2014 ? 20:05 +0100, Patrick Ohly a ?crit : > > > On Fri, 2014-02-07 at 22:23 +0100, Daniel CLEMENT wrote: > > > > Perhaps there is a residue of an old config. which is still interfering? > > > > On this (test) PC I could try and purge and reinstall everything. > > > > > > Even if it fails there should be some indication how. Please type the > > > commands below in a shell and send the resulting /tmp/syncevo.out text > > > file. > > > > > > script /tmp/syncevo.out > > > syncevolution --daemon=no --version > > > SYNCEVOLUTION_DEBUG=1 gdb --args /usr/libexec/syncevo-dbus-server --no-syslog --stdout --verbosity 3 -d unlimited > > > run > > > > > > Now it should still be running (no gdb command prompt). Run the sync-ui > > > separately. If it crashes or quits, gdb will tell you. In that case, > > > type > > > > > > thread apply all bt > > > > > I get this: > > ----- > [...] > > > ...but the 2nd command produces no further output. I tried to rerun > > everything, but on the next runs the syncevo.out remains empty!? > > Can you please follow the instructions step-by-step and then attach the > entire /tmp/syncevo.out file? I can't believe that gdb quits without > printing anything. Therefore I want to see exactly what you doing. > Otherwise I can't help. > > Copy-paste each line, press return after each line. The first command > starts a script session, the third commands starts gdb (must be > installed), then "run" inside gdb starts syncevo-dbus-server. > My apology for not understanding that "run" was separated (thought it was an automated linebreak). But I assure you that syncevo.out remains empty hereafter, so I'm trying to attach instead the whole contents of the shell screen. That's really all I see, I hope it's useful. To me it looks as if the syncevo-dbus-server tries to start but exits immediately. The UI has the same empty look. Thank you for your patience, -- Daniel CLEMENT -------------- next part -------------- daniel at e6330v ~ $ syncevolution --daemon=no --version SyncEvolution 1.3.99.5 Loading backend library /usr/local/lib/syncevolution/backends/platformgnome.so Loading backend library /usr/local/lib/syncevolution/backends/platformkde.so Loading backend library /usr/local/lib/syncevolution/backends/providergoa.so Loading backend library /usr/local/lib/syncevolution/backends/providergsso.so Loading backend library /usr/local/lib/syncevolution/backends/syncactivesync.so Loading backend library /usr/local/lib/syncevolution/backends/syncaddressbook.so Loading backend library /usr/local/lib/syncevolution/backends/syncakonadi.so Loading backend library /usr/local/lib/syncevolution/backends/syncdav.so Loading backend library /usr/local/lib/syncevolution/backends/syncebook.so Loading backend library /usr/local/lib/syncevolution/backends/syncecal.so Loading backend library /usr/local/lib/syncevolution/backends/syncfile.so Loading backend library /usr/local/lib/syncevolution/backends/synckcalextended.so Loading backend library /usr/local/lib/syncevolution/backends/syncmaemocal.so Loading backend library /usr/local/lib/syncevolution/backends/syncpbap.so Loading backend library /usr/local/lib/syncevolution/backends/syncqtcontacts.so Loading backend library /usr/local/lib/syncevolution/backends/syncsqlite.so Loading backend library /usr/local/lib/syncevolution/backends/syncxmlrpc.so daniel at e6330v ~ $ SYNCEVOLUTION_DEBUG=1 gdb --args /usr/libexec/syncevo-dbus-server --no-syslog --stdout --verbosity 3 -d unlimited GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/libexec/syncevo-dbus-server...done. (gdb) run Starting program: /usr/libexec/syncevo-dbus-server --no-syslog --stdout --verbosity 3 -d unlimited warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [DEBUG syncevo-dbus-server 00:00:00] syncevo-dbus-server: catch SIGINT/SIGTERM in our own shutdown function [DEBUG syncevo-dbus-server 00:00:00] SuspendFlags: (re)activating, currently inactive [DEBUG syncevo-dbus-server 00:00:00] SuspendFlags: activating signal handler(s) with fds 5->4 [New Thread 0x7fffec763700 (LWP 5638)] /usr/libexec/syncevo-dbus-server: symbol lookup error: /usr/libexec/syncevo-dbus-server: undefined symbol: _Z21intrusive_ptr_add_refP14DBusConnection [Thread 0x7fffec763700 (LWP 5638) exited] [Inferior 1 (process 5634) exited with code 0177] From patrick.ohly at intel.com Mon Feb 10 16:53:30 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 10 Feb 2014 17:53:30 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1392049058.4099.16.camel@m6400> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> <1391790127.5951.104.camel@pohly-mobl1.fritz.box> <1391793378.9264.3.camel@m6400> <1391798811.5951.112.camel@pohly-mobl1.fritz.box> <1391808184.4097.6.camel@m6400> <1391972739.5951.128.camel@pohly-mobl1.fritz.box> <1392042137.4099.4.camel@m6400> <1392046816.5951.142.camel@pohly-mobl1.fritz.box> <1392049058.4099.16.camel@m6400> Message-ID: <1392051210.5951.162.camel@pohly-mobl1.fritz.box> On Mon, 2014-02-10 at 17:17 +0100, Daniel CLEMENT wrote: > Le lundi 10 f?vrier 2014 ? 16:40 +0100, Patrick Ohly a ?crit : > > On Mon, 2014-02-10 at 15:22 +0100, Daniel CLEMENT wrote: > > > Le dimanche 09 f?vrier 2014 ? 20:05 +0100, Patrick Ohly a ?crit : > > > > On Fri, 2014-02-07 at 22:23 +0100, Daniel CLEMENT wrote: > > > > > Perhaps there is a residue of an old config. which is still interfering? > > > > > On this (test) PC I could try and purge and reinstall everything. > > > > > > > > Even if it fails there should be some indication how. Please type the > > > > commands below in a shell and send the resulting /tmp/syncevo.out text > > > > file. > > > > > > > > script /tmp/syncevo.out > > > > syncevolution --daemon=no --version > > > > SYNCEVOLUTION_DEBUG=1 gdb --args /usr/libexec/syncevo-dbus-server --no-syslog --stdout --verbosity 3 -d unlimited > > > > run > > > > > > > > Now it should still be running (no gdb command prompt). Run the sync-ui > > > > separately. If it crashes or quits, gdb will tell you. In that case, > > > > type > > > > > > > > thread apply all bt > > > > > > > I get this: > > > ----- > > [...] > > > > > ...but the 2nd command produces no further output. I tried to rerun > > > everything, but on the next runs the syncevo.out remains empty!? > > > > Can you please follow the instructions step-by-step and then attach the > > entire /tmp/syncevo.out file? I can't believe that gdb quits without > > printing anything. Therefore I want to see exactly what you doing. > > Otherwise I can't help. > > > > Copy-paste each line, press return after each line. The first command > > starts a script session, the third commands starts gdb (must be > > installed), then "run" inside gdb starts syncevo-dbus-server. > > > My apology for not understanding that "run" was separated (thought it > was an automated linebreak). > > But I assure you that syncevo.out remains empty hereafter, Perhaps one has to quit the sub-shell after leaving gdb. I expected "script" to copy everything into the file without buffering, but you are right, that needs to be enabled with "script --flush /tmp/syncevo.out" explicitly. > so I'm trying > to attach instead the whole contents of the shell screen. That's really > all I see, I hope it's useful. To me it looks as if the > syncevo-dbus-server tries to start but exits immediately. Yes, and there *is* an error message: /usr/libexec/syncevo-dbus-server: symbol lookup error: /usr/libexec/syncevo-dbus-server: undefined symbol: _Z21intrusive_ptr_add_refP14DBusConnection That symbol should be provided by a library that syncevo-dbus-server is linked against: $ objdump -T /usr/lib/libgdbussyncevo.so.0 | grep _Z21intrusive_ptr_add_refP14DBusConnection 000000000000a640 g DF .text 0000000000000005 Base _Z21intrusive_ptr_add_refP14DBusConnection $ objdump -T /usr/libexec/syncevo-dbus-server | grep _Z21intrusive_ptr_add_refP14DBusConnection 0000000000000000 DF *UND* 0000000000000000 _Z21intrusive_ptr_add_refP14DBusConnection $ objdump -T /usr/lib/libgdbussyncevo.so.0 | grep _Z21intrusive_ptr_add_refP14DBusConnection 000000000000a640 g DF .text 0000000000000005 Base _Z21intrusive_ptr_add_refP14DBusConnection $ readelf -a /usr/libexec/syncevo-dbus-server | grep NEED [ 9] .gnu.version_r VERNEED 0000000000477198 00077198 0x0000000000000001 (NEEDED) Shared library: [libgdbussyncevo.so.0] ... $ ldd /usr/libexec/syncevo-dbus-server | grep libgdbussyncevo.so.0 libgdbussyncevo.so.0 => /usr/lib/libgdbussyncevo.so.0 (0x00007f02d5764000) Do you get similar output on your system for these commands? To debug this, run LD_DEBUG=all /usr/libexec/syncevo-dbus-server 2>/tmp/ld.log and attach the resulting ld.log. When I run that, _Z21intrusive_ptr_add_refP14DBusConnection is not needed, which is a bit unexpected. Therefore there is one more test that you could run: * Start syncevo-dbus-server und gdb, as before. * Before "run", enter "b _Z21intrusive_ptr_add_refP14DBusConnection". * Then run. * When it stops, "where". I am not sure whether it'll work. On Debian Wheezy, gdb segfaults. -- 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 dclement1 at laposte.net Mon Feb 10 17:42:09 2014 From: dclement1 at laposte.net (Daniel CLEMENT) Date: Mon, 10 Feb 2014 18:42:09 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1392051210.5951.162.camel@pohly-mobl1.fritz.box> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> <1391790127.5951.104.camel@pohly-mobl1.fritz.box> <1391793378.9264.3.camel@m6400> <1391798811.5951.112.camel@pohly-mobl1.fritz.box> <1391808184.4097.6.camel@m6400> <1391972739.5951.128.camel@pohly-mobl1.fritz.box> <1392042137.4099.4.camel@m6400> <1392046816.5951.142.camel@pohly-mobl1.fritz.box> <1392049058.4099.16.camel@m6400> <1392051210.5951.162.camel@pohly-mobl1.fritz.box> Message-ID: <1392054129.4099.24.camel@m6400> Le lundi 10 f?vrier 2014 ? 17:53 +0100, Patrick Ohly a ?crit : > On Mon, 2014-02-10 at 17:17 +0100, Daniel CLEMENT wrote: > > Le lundi 10 f?vrier 2014 ? 16:40 +0100, Patrick Ohly a ?crit : > > > On Mon, 2014-02-10 at 15:22 +0100, Daniel CLEMENT wrote: > > > > Le dimanche 09 f?vrier 2014 ? 20:05 +0100, Patrick Ohly a ?crit : > > > > > On Fri, 2014-02-07 at 22:23 +0100, Daniel CLEMENT wrote: > > > > > > Perhaps there is a residue of an old config. which is still interfering? > > > > > > On this (test) PC I could try and purge and reinstall everything. > > > > > > > > > > Even if it fails there should be some indication how. Please type the > > > > > commands below in a shell and send the resulting /tmp/syncevo.out text > > > > > file. > > > > > > > > > > script /tmp/syncevo.out > > > > > syncevolution --daemon=no --version > > > > > SYNCEVOLUTION_DEBUG=1 gdb --args /usr/libexec/syncevo-dbus-server --no-syslog --stdout --verbosity 3 -d unlimited > > > > > run > > > > > > > > > > Now it should still be running (no gdb command prompt). Run the sync-ui > > > > > separately. If it crashes or quits, gdb will tell you. In that case, > > > > > type > > > > > > > > > > thread apply all bt > > > > > > > > > I get this: > > > > ----- > > > [...] > > > > > > > ...but the 2nd command produces no further output. I tried to rerun > > > > everything, but on the next runs the syncevo.out remains empty!? > > > > > > Can you please follow the instructions step-by-step and then attach the > > > entire /tmp/syncevo.out file? I can't believe that gdb quits without > > > printing anything. Therefore I want to see exactly what you doing. > > > Otherwise I can't help. > > > > > > Copy-paste each line, press return after each line. The first command > > > starts a script session, the third commands starts gdb (must be > > > installed), then "run" inside gdb starts syncevo-dbus-server. > > > > > My apology for not understanding that "run" was separated (thought it > > was an automated linebreak). > > > > But I assure you that syncevo.out remains empty hereafter, > > Perhaps one has to quit the sub-shell after leaving gdb. I expected > "script" to copy everything into the file without buffering, but you are > right, that needs to be enabled with "script --flush /tmp/syncevo.out" > explicitly. > > > so I'm trying > > to attach instead the whole contents of the shell screen. That's really > > all I see, I hope it's useful. To me it looks as if the > > syncevo-dbus-server tries to start but exits immediately. > > Yes, and there *is* an error message: > > /usr/libexec/syncevo-dbus-server: symbol lookup error: /usr/libexec/syncevo-dbus-server: undefined symbol: _Z21intrusive_ptr_add_refP14DBusConnection > > That symbol should be provided by a library that syncevo-dbus-server is > linked against: > > $ objdump -T /usr/lib/libgdbussyncevo.so.0 | grep _Z21intrusive_ptr_add_refP14DBusConnection > 000000000000a640 g DF .text 0000000000000005 Base _Z21intrusive_ptr_add_refP14DBusConnection > $ objdump -T /usr/libexec/syncevo-dbus-server | grep _Z21intrusive_ptr_add_refP14DBusConnection > 0000000000000000 DF *UND* 0000000000000000 _Z21intrusive_ptr_add_refP14DBusConnection > $ objdump -T /usr/lib/libgdbussyncevo.so.0 | grep _Z21intrusive_ptr_add_refP14DBusConnection > 000000000000a640 g DF .text 0000000000000005 Base _Z21intrusive_ptr_add_refP14DBusConnection > $ readelf -a /usr/libexec/syncevo-dbus-server | grep NEED > [ 9] .gnu.version_r VERNEED 0000000000477198 00077198 > 0x0000000000000001 (NEEDED) Shared library: [libgdbussyncevo.so.0] > ... > $ ldd /usr/libexec/syncevo-dbus-server | grep libgdbussyncevo.so.0 > libgdbussyncevo.so.0 => /usr/lib/libgdbussyncevo.so.0 (0x00007f02d5764000) > > Do you get similar output on your system for these commands? Quite similar: daniel at e6330v ~ $ ldd /usr/libexec/syncevo-dbus-server | grep libgdbussyncevo.so.0 libgdbussyncevo.so.0 => /usr/local/lib/libgdbussyncevo.so.0 (0x00007f7848888000) > > To debug this, run > LD_DEBUG=all /usr/libexec/syncevo-dbus-server 2>/tmp/ld.log > and attach the resulting ld.log. I can't, it's 38+ Mb! 38 Mb of error messages !? > > When I run that, _Z21intrusive_ptr_add_refP14DBusConnection is not > needed, which is a bit unexpected. > > Therefore there is one more test that you could run: > * Start syncevo-dbus-server und gdb, as before. > * Before "run", enter "b > _Z21intrusive_ptr_add_refP14DBusConnection". > * Then run. > * When it stops, "where". > > I am not sure whether it'll work. On Debian Wheezy, gdb segfaults. > Yes I get a segfault at the 2nd step, so I even don't get a chance to type "run". (The Linux Mint running on this PC is about Debian testing.) -- Daniel CLEMENT _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Mon Feb 10 18:08:52 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 10 Feb 2014 19:08:52 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1392054129.4099.24.camel@m6400> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> <1391790127.5951.104.camel@pohly-mobl1.fritz.box> <1391793378.9264.3.camel@m6400> <1391798811.5951.112.camel@pohly-mobl1.fritz.box> <1391808184.4097.6.camel@m6400> <1391972739.5951.128.camel@pohly-mobl1.fritz.box> <1392042137.4099.4.camel@m6400> <1392046816.5951.142.camel@pohly-mobl1.fritz.box> <1392049058.4099.16.camel@m6400> <1392051210.5951.162.camel@pohly-mobl1.fritz.box> <1392054129.4099.24.camel@m6400> Message-ID: <1392055732.5951.166.camel@pohly-mobl1.fritz.box> On Mon, 2014-02-10 at 18:42 +0100, Daniel CLEMENT wrote: > Le lundi 10 f?vrier 2014 ? 17:53 +0100, Patrick Ohly a ?crit : > > $ objdump -T /usr/lib/libgdbussyncevo.so.0 | grep _Z21intrusive_ptr_add_refP14DBusConnection > > 000000000000a640 g DF .text 0000000000000005 Base _Z21intrusive_ptr_add_refP14DBusConnection > > $ objdump -T /usr/libexec/syncevo-dbus-server | grep _Z21intrusive_ptr_add_refP14DBusConnection > > 0000000000000000 DF *UND* 0000000000000000 _Z21intrusive_ptr_add_refP14DBusConnection > > $ objdump -T /usr/lib/libgdbussyncevo.so.0 | grep _Z21intrusive_ptr_add_refP14DBusConnection > > 000000000000a640 g DF .text 0000000000000005 Base _Z21intrusive_ptr_add_refP14DBusConnection > > $ readelf -a /usr/libexec/syncevo-dbus-server | grep NEED > > [ 9] .gnu.version_r VERNEED 0000000000477198 00077198 > > 0x0000000000000001 (NEEDED) Shared library: [libgdbussyncevo.so.0] > > ... > > $ ldd /usr/libexec/syncevo-dbus-server | grep libgdbussyncevo.so.0 > > libgdbussyncevo.so.0 => /usr/lib/libgdbussyncevo.so.0 (0x00007f02d5764000) > > > > Do you get similar output on your system for these commands? > > Quite similar: > > daniel at e6330v ~ $ ldd /usr/libexec/syncevo-dbus-server | grep libgdbussyncevo.so.0 ^^^^^^^^^^^^^^^ > libgdbussyncevo.so.0 => /usr/local/lib/libgdbussyncevo.so.0 (0x00007f7848888000) ^^^^^^^^^^^^^^ Not similar enough. Why is /usr/libexec/syncevo-dbus-server referencing a lib in /usr/local/lib? Where does that library come from? You seem to have an inconsistent installation of SyncEvolution on your system. Fix that and SyncEvolution should work again. -- 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 dclement1 at laposte.net Tue Feb 11 13:08:39 2014 From: dclement1 at laposte.net (Daniel CLEMENT) Date: Tue, 11 Feb 2014 14:08:39 +0100 Subject: [SyncEvolution] Compatibility with Evolution 3.8 In-Reply-To: <1392055732.5951.166.camel@pohly-mobl1.fritz.box> References: <1380631516.5079.9.camel@m6400> <1380633871.5079.15.camel@m6400> <1380634455.5818.13.camel@pohly-mobl1.fritz.box> <1388651826.5855.243.camel@pohly-mobl1.fritz.box> <1391783550.4213.8.camel@m6400> <1391790127.5951.104.camel@pohly-mobl1.fritz.box> <1391793378.9264.3.camel@m6400> <1391798811.5951.112.camel@pohly-mobl1.fritz.box> <1391808184.4097.6.camel@m6400> <1391972739.5951.128.camel@pohly-mobl1.fritz.box> <1392042137.4099.4.camel@m6400> <1392046816.5951.142.camel@pohly-mobl1.fritz.box> <1392049058.4099.16.camel@m6400> <1392051210.5951.162.camel@pohly-mobl1.fritz.box> <1392054129.4099.24.camel@m6400> <1392055732.5951.166.camel@pohly-mobl1.fritz.box> Message-ID: <1392124119.4114.4.camel@m6400> Le lundi 10 f?vrier 2014 ? 19:08 +0100, Patrick Ohly a ?crit : > On Mon, 2014-02-10 at 18:42 +0100, Daniel CLEMENT wrote: > > Le lundi 10 f?vrier 2014 ? 17:53 +0100, Patrick Ohly a ?crit : > > > $ objdump -T /usr/lib/libgdbussyncevo.so.0 | grep _Z21intrusive_ptr_add_refP14DBusConnection > > > 000000000000a640 g DF .text 0000000000000005 Base _Z21intrusive_ptr_add_refP14DBusConnection > > > $ objdump -T /usr/libexec/syncevo-dbus-server | grep _Z21intrusive_ptr_add_refP14DBusConnection > > > 0000000000000000 DF *UND* 0000000000000000 _Z21intrusive_ptr_add_refP14DBusConnection > > > $ objdump -T /usr/lib/libgdbussyncevo.so.0 | grep _Z21intrusive_ptr_add_refP14DBusConnection > > > 000000000000a640 g DF .text 0000000000000005 Base _Z21intrusive_ptr_add_refP14DBusConnection > > > $ readelf -a /usr/libexec/syncevo-dbus-server | grep NEED > > > [ 9] .gnu.version_r VERNEED 0000000000477198 00077198 > > > 0x0000000000000001 (NEEDED) Shared library: [libgdbussyncevo.so.0] > > > ... > > > $ ldd /usr/libexec/syncevo-dbus-server | grep libgdbussyncevo.so.0 > > > libgdbussyncevo.so.0 => /usr/lib/libgdbussyncevo.so.0 (0x00007f02d5764000) > > > > > > Do you get similar output on your system for these commands? > > > > Quite similar: > > > > daniel at e6330v ~ $ ldd /usr/libexec/syncevo-dbus-server | grep libgdbussyncevo.so.0 > ^^^^^^^^^^^^^^^ > > libgdbussyncevo.so.0 => /usr/local/lib/libgdbussyncevo.so.0 (0x00007f7848888000) > ^^^^^^^^^^^^^^ > > Not similar enough. Why is /usr/libexec/syncevo-dbus-server referencing > a lib in /usr/local/lib? Where does that library come from? Ouch, /usr/local/lib! This ought to come from a previous attempt at compiling SyncEvolution 1.3.99 from source. It's been uninstalled since, but obviously not completely. Done now. > > You seem to have an inconsistent installation of SyncEvolution on your > system. Fix that and SyncEvolution should work again. Confirmed. Glad I can upgrade Linux Mint Debian with confidence. Very sorry for having waisted your time and cluttered the list. Best regards, -- Daniel CLEMENT _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From g+syncevolution at cobb.uk.net Sun Feb 9 23:44:56 2014 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Sun, 9 Feb 2014 23:44:56 +0000 Subject: [SyncEvolution] Compiling syncevolution on Debian jessie In-Reply-To: <20140204101657.GA28642@mac.home> References: <52DA4BF0.4050108@cobb.uk.net> <20140120100207.GA31172@mac.home> <20140204101657.GA28642@mac.home> Message-ID: <52F812F8.3060604@cobb.uk.net> On 04/02/14 10:16, Tino Mettler wrote: > Sorry for asking over and over again, what is your plan for the > activesyncd package? AFAICS, it is a requirement for EAS client > support in syncevolution and I think it would be nice to have this in > Debian. I haven't packaged activesyncd. All I have done is submitted a few patches to Patrick. Of course, I also build it myself to test those patches, but I don't build packages. I note that Patrick does include activesyncd in his http://downloads.syncevolution.org/apt repository. I don't know who maintains that packaging (I am guessing it is Patrick). I would also be very happy if activesyncd could become part of Debian. I have not looked into that. I am familiar with the debian packaging tools (from using it in other projects) but not with the debian processes at all. > A new libsynthesis package is in Jessie for a few days. I also finished > a syncevolution 1.3.99.7-1 package. You can find the source at > git://git.debian.org/git/collab-maint/syncevolution. Thanks for the info, but I am not going to be able to try it out for a few weeks (Mobile World Congress owns my life at the moment!). Graham _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Mon Feb 10 07:29:08 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 10 Feb 2014 08:29:08 +0100 Subject: [SyncEvolution] Compiling syncevolution on Debian jessie In-Reply-To: <52F812F8.3060604@cobb.uk.net> References: <52DA4BF0.4050108@cobb.uk.net> <20140120100207.GA31172@mac.home> <20140204101657.GA28642@mac.home> <52F812F8.3060604@cobb.uk.net> Message-ID: <1392017348.5951.135.camel@pohly-mobl1.fritz.box> On Sun, 2014-02-09 at 23:44 +0000, Graham Cobb wrote: > I note that Patrick does include activesyncd in his > http://downloads.syncevolution.org/apt repository. I don't know who > maintains that packaging (I am guessing it is Patrick). I package the files that I get out of the nightly build/testing. It's mostly a quick hack, though, and not something that a distro should adopt. Also note that activesyncd depends on a more recent libwbxml than the one currently found in Linux distros. I'm currently trying out packaging of activesyncd and syncevolution-activesyncd per distro (currently Wheezy, Saucy, Trusty -> activesyncd-wheezy, syncevolution-activesyncd-wheezy, etc.) and the base name just being a meta package which depends on one of the others. That is necessary because each of these distros has seen incompatible changes in EDS (3.4 -> 3.6 -> 3.10) and/or libical (.so.0 -> .so.1). Debian Testing/Unstable would not be covered at the moment. I pinged the libical maintainer and asked him to package libical1; once that is in, the Saucy package (EDS 3.8 + libical1) should work. -- 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 Thu Feb 6 03:17:39 2014 From: ovek at arcticnet.no (=?ISO-8859-1?Q?Ove_K=E5ven?=) Date: Thu, 6 Feb 2014 04:17:39 +0100 Subject: [SyncEvolution] Keepalives when syncing Message-ID: <52F2FED3.2080504@arcticnet.no> Well, it turns out that to prevent the Jolla from suspending itself in the middle of a sync (or more likely, data backup or data diff), I should send some D-Bus message to the MCE daemon at the start of a sync, and then keep sending it regularly until the sync is done, at which point I should send a final message. Here's the interface: https://github.com/nemomobile/mce-dev/blob/master/include/mce/dbus-names.h#L329 Now where in the SyncEvolution code would it be wise to hook in to do something like that? _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Thu Feb 6 14:50:45 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 06 Feb 2014 15:50:45 +0100 Subject: [SyncEvolution] Keepalives when syncing In-Reply-To: <52F2FED3.2080504@arcticnet.no> References: <52F2FED3.2080504@arcticnet.no> Message-ID: <1391698245.5951.17.camel@pohly-mobl1.fritz.box> On Thu, 2014-02-06 at 04:17 +0100, Ove K?ven wrote: > Well, it turns out that to prevent the Jolla from suspending itself in > the middle of a sync (or more likely, data backup or data diff), I > should send some D-Bus message to the MCE daemon at the start of a sync, > and then keep sending it regularly until the sync is done, at which > point I should send a final message. Here's the interface: > https://github.com/nemomobile/mce-dev/blob/master/include/mce/dbus-names.h#L329 > > Now where in the SyncEvolution code would it be wise to hook in to do > something like that? Are you using syncevo-dbus-server to run the syncs? Do you want to enable auto-syncing? If it's just about preventing suspend during a sync and you want that to work also when using the command line (syncevolution --daemon=no, or when D-Bus server was not enabled during compilation), then the keep-alive ping needs to go into SyncContext::doSync(). You could either add some code directly before SessionStep() which checks the current time, or you set up a glib idle timer at the start of doSync() and send the ping in the idle callback. There is some C++ utility code for that in src/dbus/server/timeout.h/cpp. Arguably that code should be in src/syncevo. I can move it before releaseing 1.4. The approach with an idle callback is better than relying on doSync() loop iterations, because those won't happen while waiting for a SyncML message. However, make sure you use libsoup, because only then is the event loop kept alive while waiting for messages. Alternatively, one could change src/dbus/server/session.cpp and add code there which pings MCE while a session is active. This code is guaranteed to always run because syncevo-dbus-server does not block event processing. But it won't prevent suspending of "syncevolution --daemon=no" syncs. For auto-syncing, more work would be needed in syncevo-dbus-server. The process sets up timeouts for the time when it might run the next sync. I assume that these timeouts in glib alone will not wake up the device from suspend. See src/server/auto-sync-manager.cpp and AutoSyncManager::schedule(). There are several runOnce() calls which must wake up the device. -- 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 Thu Feb 6 20:21:58 2014 From: ovek at arcticnet.no (=?UTF-8?B?T3ZlIEvDpXZlbg==?=) Date: Thu, 6 Feb 2014 21:21:58 +0100 Subject: [SyncEvolution] Keepalives when syncing In-Reply-To: <1391698245.5951.17.camel@pohly-mobl1.fritz.box> References: <52F2FED3.2080504@arcticnet.no> <1391698245.5951.17.camel@pohly-mobl1.fritz.box> Message-ID: <52F3EEE6.7050209@arcticnet.no> Den 06. feb. 2014 15:50, skrev Patrick Ohly: > On Thu, 2014-02-06 at 04:17 +0100, Ove K?ven wrote: >> Well, it turns out that to prevent the Jolla from suspending itself in >> the middle of a sync (or more likely, data backup or data diff), I >> should send some D-Bus message to the MCE daemon at the start of a sync, >> and then keep sending it regularly until the sync is done, at which >> point I should send a final message. Here's the interface: >> https://github.com/nemomobile/mce-dev/blob/master/include/mce/dbus-names.h#L329 >> >> Now where in the SyncEvolution code would it be wise to hook in to do >> something like that? > > Are you using syncevo-dbus-server to run the syncs? Do you want to > enable auto-syncing? Yes, I'm using syncevo-dbus-server. (If someone uses --daemon=no, they probably don't need this stuff anyway.) I'm allowing autosyncing, but perhaps that's another thing I should ask you about: currently, SyncEvolution's autosync delay setting seems designed for computers that connect to the Internet in the background whenever they are powered on. But that doesn't necessarily work so well for devices that connect to the Internet on demand. SailfishOS uses Connman. It seems that if an app wants an Internet connection, it can start a Connman session and send a "Connect" message (http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/session-api.txt?id=HEAD). I think Connman also provides proxy settings and such. (Nokia's N900 and N9 devices use a proprietary Nokia Internet Connectivity Daemon, but the model is very similar. Apps should tell the ICD whenever they want an Internet connection.) Although the Jolla phones do try to keep an Internet connection active as long as the phone is in use, they don't try very hard when the screen is off and the phone suspended. Thus, for autosync to work reliably while the screen is off (which is probably less annoying for the user than only syncing when the phone is in use), a different model is needed: when SyncEvolution decides that it's time for a sync, it tells MCE to prevent a suspend, then it tells Connman to establish an Internet connection, and waits for a response; if successful, start a sync; when finished, tell Connman that an Internet connection is no longer needed, and tell MCE that it's OK to go back to suspend. > If it's just about preventing suspend during a sync and you want that to > work also when using the command line (syncevolution --daemon=no, or > when D-Bus server was not enabled during compilation), then the > keep-alive ping needs to go into SyncContext::doSync(). You could either > add some code directly before SessionStep() which checks the current > time, or you set up a glib idle timer at the start of doSync() and send > the ping in the idle callback. There is some C++ utility code for that > in src/dbus/server/timeout.h/cpp. Arguably that code should be in > src/syncevo. I can move it before releaseing 1.4. > > The approach with an idle callback is better than relying on doSync() > loop iterations, because those won't happen while waiting for a SyncML > message. However, make sure you use libsoup, because only then is the > event loop kept alive while waiting for messages. No, I'm not using libsoup. That's not a standard library on these devices. (Though I know libcurl has a progress callback that's called at least every second, which could perhaps be used for such things.) But since I don't care about the --daemon=no case, I guess this is nothing to worry about. > Alternatively, one could change src/dbus/server/session.cpp and add code > there which pings MCE while a session is active. This code is guaranteed > to always run because syncevo-dbus-server does not block event > processing. But it won't prevent suspending of "syncevolution > --daemon=no" syncs. Well, it's a possibility. The logic isn't so easy to follow, though. Which methods are the best ones to fiddle with here? > For auto-syncing, more work would be needed in syncevo-dbus-server. The > process sets up timeouts for the time when it might run the next sync. I > assume that these timeouts in glib alone will not wake up the device > from suspend. See src/server/auto-sync-manager.cpp and > AutoSyncManager::schedule(). There are several runOnce() calls which > must wake up the device. No, glib timeouts aren't enough. To schedule a wakeup from deep suspend you're supposed to talk to the IPHB service or something. (I think it's a service that ensures that if several tasks need to wake up on similar schedules, then it tries to wake them all up at the same time, so that the CPU doesn't have to be powered up any longer than necessary. Of course, the tasks still need to talk to the MCE to keep the CPU powered for as long as they need it to be.) From ovek at arcticnet.no Fri Feb 7 00:25:35 2014 From: ovek at arcticnet.no (=?ISO-8859-1?Q?Ove_K=E5ven?=) Date: Fri, 7 Feb 2014 01:25:35 +0100 Subject: [SyncEvolution] Keepalives when syncing In-Reply-To: <52F3EEE6.7050209@arcticnet.no> References: <52F2FED3.2080504@arcticnet.no> <1391698245.5951.17.camel@pohly-mobl1.fritz.box> <52F3EEE6.7050209@arcticnet.no> Message-ID: <52F427FF.9050601@arcticnet.no> Come to think of it: Regardless of how SyncEvolution uses Connman (even if just checking if the network is online, like it does now), perhaps there should be a config option for only autosyncing when a WLAN connection is in use, never over a cellular network (which could be expensive, depending on the data plan and whether the user is roaming). From patrick.ohly at intel.com Fri Feb 7 09:08:45 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 07 Feb 2014 10:08:45 +0100 Subject: [SyncEvolution] Keepalives when syncing In-Reply-To: <52F3EEE6.7050209@arcticnet.no> References: <52F2FED3.2080504@arcticnet.no> <1391698245.5951.17.camel@pohly-mobl1.fritz.box> <52F3EEE6.7050209@arcticnet.no> Message-ID: <1391764125.5951.57.camel@pohly-mobl1.fritz.box> On Thu, 2014-02-06 at 21:21 +0100, Ove K?ven wrote: > Den 06. feb. 2014 15:50, skrev Patrick Ohly: > > On Thu, 2014-02-06 at 04:17 +0100, Ove K?ven wrote: > >> Well, it turns out that to prevent the Jolla from suspending itself in > >> the middle of a sync (or more likely, data backup or data diff), I > >> should send some D-Bus message to the MCE daemon at the start of a sync, > >> and then keep sending it regularly until the sync is done, at which > >> point I should send a final message. Here's the interface: > >> https://github.com/nemomobile/mce-dev/blob/master/include/mce/dbus-names.h#L329 > >> > >> Now where in the SyncEvolution code would it be wise to hook in to do > >> something like that? > > > > Are you using syncevo-dbus-server to run the syncs? Do you want to > > enable auto-syncing? > > Yes, I'm using syncevo-dbus-server. (If someone uses --daemon=no, they > probably don't need this stuff anyway.) > > I'm allowing autosyncing, but perhaps that's another thing I should ask > you about: currently, SyncEvolution's autosync delay setting seems > designed for computers that connect to the Internet in the background > whenever they are powered on. But that doesn't necessarily work so well > for devices that connect to the Internet on demand. Syncing is meant to piggyback on an Internet connection created for some other purpose (enabling Wifi, plugging into an Ethernet), but yes, that's a model that does not work so well for a phone. > Although the Jolla phones do try to keep an Internet connection active > as long as the phone is in use, they don't try very hard when the screen > is off and the phone suspended. Thus, for autosync to work reliably > while the screen is off (which is probably less annoying for the user > than only syncing when the phone is in use), a different model is > needed: when SyncEvolution decides that it's time for a sync, it tells > MCE to prevent a suspend, then it tells Connman to establish an Internet > connection, and waits for a response; if successful, start a sync; when > finished, tell Connman that an Internet connection is no longer needed, > and tell MCE that it's OK to go back to suspend. Agreed. autoSyncDelay=0 could be interpreted as such a new "don't wait for Internet, enable it when the time for a sync comes" mode. The ConnmanClient class in connman-client.h/cpp is the C++ class which talks to org.connman.Manager via D-Bus. It could be extended to also allow calling these extra methods. However, an abstract API that the ConnmanClient and (perhaps later) the NetworkManager class can implement would be better. The place that prevents suspend could also use that abstract API to ensure Internet connectivity. BTW, reliably detecting whether a sync config needs Internet is not that easy. There's no information that "backend = caldav" needs Internet while "backend = evolution-contacts" does not (normally; it might need Internet, depending on which database is used...). Local syncs involving just two different local databases on both sides will not. It's probably easier to just continue ignoring this. > > Alternatively, one could change src/dbus/server/session.cpp and add code > > there which pings MCE while a session is active. This code is guaranteed > > to always run because syncevo-dbus-server does not block event > > processing. But it won't prevent suspending of "syncevolution > > --daemon=no" syncs. > > Well, it's a possibility. The logic isn't so easy to follow, though. Basically it starts with Session::sync(), continues in Session::sync2() and finishes with Session::dbusResultCb(). Having to split up sync() because of one asynchronous call in the middle is not nice. This is one thing which, for example, Vala does better than C++. At least in C++, we can pass extra parameters via boost::bind() without having to define our own structs, as in C. > Which methods are the best ones to fiddle with here? Session::sync() and Session::dbusResultCb(). > > For auto-syncing, more work would be needed in syncevo-dbus-server. The > > process sets up timeouts for the time when it might run the next sync. I > > assume that these timeouts in glib alone will not wake up the device > > from suspend. See src/server/auto-sync-manager.cpp and > > AutoSyncManager::schedule(). There are several runOnce() calls which > > must wake up the device. > > No, glib timeouts aren't enough. Right, that's what I meant. I should have said "runOnce() should wake up the device, but must be extended to actually do so". On Fri, 2014-02-07 at 01:25 +0100, Ove K?ven wrote: > Come to think of it: Regardless of how SyncEvolution uses Connman (even > if just checking if the network is online, like it does now), perhaps > there should be a config option for only autosyncing when a WLAN > connection is in use, never over a cellular network (which could be > expensive, depending on the data plan and whether the user is roaming). Yes, that would make sense. -- 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 Feb 3 13:38:29 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Mon, 3 Feb 2014 19:08:29 +0530 Subject: Adding new HTTP Header extensions Message-ID: Hi Patrick, I need to pass some attributes in HTTP Header while connecting to the server for Auth. Does Syncevo client support http header addition presently or do i need to customize the client for this? Regards Sachin -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Mon Feb 3 13:50:01 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 03 Feb 2014 14:50:01 +0100 Subject: Adding new HTTP Header extensions In-Reply-To: References: Message-ID: <1391435401.30349.239.camel@pohly-mobl1.fritz.box> On Mon, 2014-02-03 at 19:08 +0530, Sachin Gupta wrote: > I need to pass some attributes in HTTP Header while connecting to the > server for Auth. > Does Syncevo client support http header addition presently or do i > need to customize the client for this? You need customize the client. Have a look at CurlTransportAgent.cpp or SoupTransportAgent.cpp, depending on what you are using. -- 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 Feb 3 13:59:32 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Mon, 3 Feb 2014 19:29:32 +0530 Subject: Adding new HTTP Header extensions In-Reply-To: <1391435401.30349.239.camel@pohly-mobl1.fritz.box> References: <1391435401.30349.239.camel@pohly-mobl1.fritz.box> Message-ID: Thanx patrick. Regards On Feb 3, 2014 7:20 PM, "Patrick Ohly" wrote: > On Mon, 2014-02-03 at 19:08 +0530, Sachin Gupta wrote: > > > I need to pass some attributes in HTTP Header while connecting to the > > server for Auth. > > Does Syncevo client support http header addition presently or do i > > need to customize the client for this? > > You need customize the client. Have a look at CurlTransportAgent.cpp or > SoupTransportAgent.cpp, depending on what you are using. > > -- > 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: