Re: [SyncEvolution] Syncing to local machine
On Mon, 2010-05-10 at 14:27 +0100, Alec Leamas wrote:
I'm a newbie having a somewhat working setup where my phone and
some
laptops are synchronized to my home server using the http server. The
problem is the home server itself.
The syncevolution server side uses a file backend.
You know that this is not absolutely required? The server will use the
normal Evolution backends if you drop the "--evolution-source" parameter
in the HOWTO:
http://syncevolution.org/development/http-server-howto
So what I want to do
is to synchronize an evolution datasource against a file backend on the
same machine. I have created a client configuration for the server which
is a clone of the working client setups. Trying to sync, I get various
errors depending on using the 'daemon=no' option or not.
You definitely need --daemon=no. Otherwise you cannot have a client and
server sync session in the same user account on the same machine. But
with a proper setup and --daemon=no it should work.
Can you quote the output of "--print-config -q" for the client and
server config involved in this local sync?
Occasionally,
using 'daemon=no' makes the sync works almost completely, but it still
fails in the very end.
A log is available on ftp://mumin.dnsalias.net/pub/local-sync-log.html.
Part of this is an embedded html file which seems to contain some
clues, at ftp://mumin.dnsalias.net/pub/local-sync-log.html.
Is this the client side of the sync? In any case, at some point the peer
starts sending empty VCALENDAR items:
[2010-05-10 15:03:03.100]
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.6//EN
END:VCALENDAR
This leads to failures like "calendar: extracting event". The original
error is on the other side. Do you see something in the log of that side
or the data it accesses which explains the origin of this item?
--
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.