On Mon, 2011-10-31 at 13:57 +0100, Frederik Elwert wrote:
>On Tue, 2011-10-25 at 13:41 +0200, Frederik Elwert wrote:
>> >> 2. On my work machine, where I am still running Ubuntu Lucid, the
>> >> syncevo-dbus-server fails silently. I could manage to sync using
>> >> "--daemon=no", but for everyday use s-d-s is more
>SIGPIPE is triggered, apparently by a writev() inside libdbus.
>SyncEvolution doesn't do anything with SIGPIPE. I wonder whether libdbus
>expects that the process ignores it. The gdbus example does that.
>Can you compile a test executable which adds the following lines to
> struct sigaction sa;
> memset(&sa, 0, sizeof(sa));
> sa.sa_handler = SIG_IGN;
> sigaction(SIGPIPE, &sa, NULL);
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?
So with that little fix, bluetooth syncing with the built-in
capabilities of the N9 seems to be relatively easy. There is just one
issue that I could not yet identify: There is always a number of
calendar entries in ERR state, which get re-submitted with the next
sync, and then again be rejected. On the N9, at a first glance no
recent entries seem to be missing, so I did not do too much to triage
this issue. On the other hand, this probably makes each sync use more
time than necessary. Any ideas where these errors might sttem from?
Most likely the device rejects certain events because it cannot parse
I’ll send you a loglevel=4 log in private, maybe you can make more
sense of it than I can.
I'll have a look.
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.