2012/3/30 Patrick Ohly <patrick.o...@intel.com>: > On Thu, 2012-03-29 at 12:56 +0200, Krzesimir Nowak wrote: >> [DEBUG syncevo-dbus-helper 00:00:00] exception thrown at >> ../../../projekty/cxx/syncevolution/src/syncevo/DevNullConfigNode.h:46 >> [ERROR syncevo-dbus-helper 00:00:00] : virtual read-only configuration >> node, cannot write property sync = two-way > > Fixed, I think: > > commit 287cf501936fe06c3e2940bc22f16e3aae5fabd4 > Author: Patrick Ohly <patrick.o...@intel.com> > Date: Fri Mar 30 14:30:21 2012 +0200 > > D-Bus server: fixed running a sync inside a command line session > > CmdlineWrapper::createSyncClient() must pass a valid config name, > taken from the base Cmdline, to the DBusSync. Otherwise the sync runs > without access to a writeable sync config, leading to errors about > "virtual read-only configuration node, cannot write ..." > > I've also experimented with output handling. Not done yet: > > commit 40e29611476b6d7c048382f27eb5e7c5a134f72d > Author: Patrick Ohly <patrick.o...@intel.com> > Date: Fri Mar 30 14:58:12 2012 +0200 > > D-Bus server: handle syncevo-dbus-helper output > > This is a first shot at making the user-visible output created during > operations visible to the user again. It's based on the same idea as > output handling in the syncevo-dbus-server: > - Session registers itself as the top-most logger and sends > SyncEvolution logging via D-Bus to the parent, which re-sends > it with the right D-Bus object path as output of the session. > - Output redirection catches all other output and feeds it back > to the Session log handler, from where it goes via D-Bus > to the parent. > > The advantage of this approach is that level information is made > available directly to the parent and that message boundaries are > preserved properly. > > The disadvantage is that the current solution is racy: depending on > the order in which events are processed, the command line client quits > before it has printed all output from the helper. This needs further > work... > > A better solution might be to capture stdout and stderr in > ForkExec.cpp, translate it back into messages and relay that to the > command line client. That would be guaranteed to capture everything > happening inside the helper.
Neat, and found why I had GConf errors - I was compiling syncevolution under jhbuild, because system's GLib was too old (racy GDBus). I guess that some parts of jhbuilded libs were not cooperating with system libraries. For now I switched to bluez wrapper. > I'll be away next week, so I'll put this aside for now. Yeah, me too. Have a nice holidays then. > > -- > 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@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
