On Wed, 2011-11-02 at 10:52 +0100, Frederik Elwert wrote:
----Ursprüngliche Nachricht-----
Von: "Patrick Ohly" <patrick.ohly(a)intel.com>
Gesendet: 01.11.2011 13:47:13
An: "Frederik Elwert" <frederik.elwert(a)web.de>
Betreff: Re: [SyncEvolution] syncevo-dbus-server dies - SIGPIPE
>On Mon, 2011-10-31 at 13:57 +0100, Frederik Elwert wrote:
>> Finally, I managed to do so, and it seems it worked. I executed the
>> newly comipled syncevo-dbus-server, and then used the newly compiled
>> syncevolution binary as a client. Syncing worked over bluetooth.
>> However, at the end I got the message "[ERROR] command line execution
>> failure". I don’t know of which kind this failure could be, since
>> everything seems to have worked just fine.
>
>If you run the syncevo-dbus-server in a shell window with
>SYNCEVOLUTION_DEBUG=1 set as env variable, does it print anything? Does
>it perhaps crash again?
No, it does not crash. At the end, the dbus server prints this:
[DEBUG 00:01:52] removing /home/frederik/.cache/syncevolution/nokia_+n9-2011-10-25-11-33
[DEBUG 00:01:52] exception thrown at syncevo-dbus-server.cpp:2466
[ERROR 00:01:52] command line execution failure
[DEBUG 00:01:52] D-Bus client :1.191 has disconnected
[DEBUG 00:01:52] activating idle termination in 600 seconds because idle
[DEBUG 00:01:52] D-Bus client :1.191 is destructing
[DEBUG 00:01:52] delaying destruction of session 20904865301320227226 by one minute
[DEBUG 00:01:52] session /org/syncevolution/Session/20904865301320227226 done
[DEBUG 00:02:53] session 20904865301320227226 expired
[DEBUG 00:02:53] session /org/syncevolution/Session/20904865301320227226 deconstructing
Maybe the cause of the error message is the exception?
No, I the exception *is* the error message ;-)
I think the error message is only a result of the incomplete sync. If
that problem was resolved, the "command line execution failure" will
also be gone.
--
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.