Re: [SyncEvolution] syncevolution --daemon=yes/no (was: RE: Alarms in the calendar: Evolution vs. vcal)
On Wed, 2010-04-07 at 07:53 +0100, Tino Keitel wrote:
On Wed, Apr 07, 2010 at 08:13:28 +0200, Patrick Ohly wrote:
[...]
> Now this is a somewhat unusual situation, not affecting users. Tino, why
> do you want to avoid daemon mode? Should we introduce an env variable
> an/or a global property to turn it off?
I did it the following way: I just built the Debian packages (which are
currently at 1.0.0 alpha2) with the syncevolution source from git, and
installed the packages.
I tend to use "checkinstall" for such purposes. Doesn't result in nice
packages, but is good enough for local installs, and you have full
control over configure flags.
I don't know very much about the server mode in syncevolution
(but I'll
try it out soon), but for me the default did not work after I installed
the new packages. I always got the message "[ERROR] Background sync
daemon has gone.".
This might be a bug. It indicates that the syncevo-dbus-server quit
unexpectedly.
Can you run /usr/libexec/syncevo-dbus-server in a separate shell
manually, then try "syncevolution"? If all works, you should see output
from the server and the command line.
If the server dies, please run under gdb and collect a stack back trace.
Maybe this is all nonsense and I have an incomplete installation or
something like this. Please ignore this suggestion in this case.
Also, I want to point out that I like the server addition. I hope it
can be made to run on a headless server with Debian Lenny, so I don't
have to use some external service for private data anymore.
I've already switched to such a setup:
http://syncevolution.org/development/http-server-howto
The installation instructions are a bit tricky when not having root
access and using one of the precompiled .tar.gz (need to set several env
variables, not all mentioned yet on that page - will fix this), but it
works.
--
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.