2012/3/30 Krzesimir Nowak <qdlacz(a)gmail.com>:
2012/3/30 Patrick Ohly <patrick.ohly(a)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.ohly(a)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.ohly(a)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.
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.
>
>