2012/3/30 Krzesimir Nowak <[email protected]>: > 2012/3/30 Patrick Ohly <[email protected]>: >> 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 <[email protected]> >> 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 <[email protected]> >> 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.
Actually, probably culprit is probably elsewhere - I have to run syncevolution in similar manner like described in link below: http://www.estamos.de/blog/2009/05/08/running-syncevolution-as-cron-job/ >> 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 [email protected] http://lists.syncevolution.org/listinfo/syncevolution
