12:03 p.m.
I'm trying to configure the SyncEvolution server to replace the service
I was getting from ScheduleWorld. I've run into a problem that's not
covered by the HOWTO.
I have multiple Evolution calendars and todo lists. With ScheduleWorld,
I configured my clients so that each calendar/todo category had its own
context. Each context had a unique deviceID, and then within that
context's configuration, I specified the category in the evolutionsource
property.
On the server side, that translates to multiple peers per client, one
for each category.
I've been trying to use the Evolution databases as the backing store on
the server side. However, I'm running into problems specifying the
evolutionsource property. It appears that evolutionsource can only be
specified in the default/sources directory, and is ignored if I specify
it in the peers/foo/sources directory.
I tried making each category a different context (on the server side),
but it appears that SE only finds device IDs that are within
default/peers.
Is there a way that I can configure the server so that it uses the
Evolution database? If not, will the filesystem database allow me to do
what I need?
-- John
1 a.m.
On So, 2011-01-02 at 01:03 +0000, John Dykstra wrote:
I've been trying to use the Evolution databases as the backing
store on
the server side. However, I'm running into problems specifying the
evolutionsource property. It appears that evolutionsource can only be
specified in the default/sources directory, and is ignored if I specify
it in the peers/foo/sources directory.
There's no need to create multiple configurations per client. Just add
additional sources to it.
Here's how you can synchronize multiple databases per peer (using a second calendar as
example):
* on the server side, configure a second calendar in the default context:
syncevolution --configure \
--source-property evolutionsource=<name of second calendar on
server> \
--source-property "type=Evolution Calendar" \
@default calendar2
* on the client, enable the second calendar:
syncevolution --configure \
--source-property evolutionsource=<name of second calendar on
client> \
--source-property "type=Evolution Calendar" \
--source-property sync=two-way \
<config name> calendar2
* Now synchronize using the <config name> client config.
Is there a way that I can configure the server so that it uses the
Evolution database? If not, will the filesystem database allow me to do
what I need?
There's no difference between Evolution and filesystem databases in this
regard. Performance with filesystem is better, so unless you really want
your data in EDS on the server side, the filesystem storage is
recommended.
BTW, I updated the syncevo-http-server.py script. You can use the
current version from git with an existing SyncEvolution installation:
http://meego.gitorious.org/meego-middleware/syncevolution/blobs/raw/maste...
Feedback on the new command line options and the new code in general
would be appreciated. I haven't updated the HOWTO yet, so just follow
"syncevo-http-server.py --help".
--
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.
6:04 a.m.
On Sun, 2011-01-02 at 15:00 +0100, Patrick Ohly wrote:
Here's how you can synchronize multiple databases per peer (using
a second calendar as example):
* on the server side, configure a second calendar in the default context:
syncevolution --configure \
--source-property evolutionsource=<name of second calendar on
server> \
--source-property "type=Evolution Calendar" \
@default calendar2
* on the client, enable the second calendar:
syncevolution --configure \
--source-property evolutionsource=<name of second calendar on
client> \
--source-property "type=Evolution Calendar" \
--source-property sync=two-way \
<config name> calendar2
* Now synchronize using the <config name> client config.
Thanks for the fast reply!
In addition to the recipe you provided, I had to explicitly set the
uri's on both sides, and enable the source on the server side.
-- John
4:02 a.m.
On Sun, 2011-01-02 at 15:00 +0100, Patrick Ohly wrote:
Here's how you can synchronize multiple databases per peer (using
a
second calendar as example):
* on the server side, configure a second calendar in the default
context:
syncevolution --configure \
--source-property evolutionsource=<name of second
calendar on server> \
--source-property "type=Evolution Calendar" \
@default calendar2
* on the client, enable the second calendar:
syncevolution --configure \
--source-property evolutionsource=<name of second
calendar on client> \
--source-property "type=Evolution Calendar" \
--source-property sync=two-way \
<config name> calendar2
* Now synchronize using the <config name> client config.
I've had no luck installing SE 1.1 on my work desktop machine, which is
a SLES 11 box that I don't have root on. There are just too many
missing libraries.
Is there a way to get SE 0.9.1 to use more than the four canonical
sources, so that it can work as a client accessing the server configured
as above? So far, I haven't been able to figure it out.
-- John
4:02 a.m.
On Sun, 2011-01-02 at 15:00 +0100, Patrick Ohly wrote:
Here's how you can synchronize multiple databases per peer (using
a
second calendar as example):
* on the server side, configure a second calendar in the default
context:
syncevolution --configure \
--source-property evolutionsource=<name of second
calendar on server> \
--source-property "type=Evolution Calendar" \
@default calendar2
* on the client, enable the second calendar:
syncevolution --configure \
--source-property evolutionsource=<name of second
calendar on client> \
--source-property "type=Evolution Calendar" \
--source-property sync=two-way \
<config name> calendar2
* Now synchronize using the <config name> client config.
I've had no luck installing SE 1.1 on my work desktop machine, which is
a SLES 11 box that I don't have root on. There are just too many
missing libraries.
Is there a way to get SE 0.9.1 to use more than the four canonical
sources, so that it can work as a client accessing the server configured
as above? So far, I haven't been able to figure it out.
-- John
6:24 p.m.
On Di, 2011-01-04 at 17:02 +0000, John Dykstra wrote:
I've had no luck installing SE 1.1 on my work desktop machine,
which is
a SLES 11 box that I don't have root on. There are just too many
missing libraries.
Is there a way to get SE 0.9.1 to use more than the four canonical
sources, so that it can work as a client accessing the server configured
as above? So far, I haven't been able to figure it out.
0.9.1 is ancient, I successfully managed to forget everything about it.
Seriously, I really wouldn't bother with 0.9.1 anymore.
When you say "too many missing libraries", do you mean for compiling
from source or at runtime with the precompiled binaries?
You can unpack the .tar.gz binary distribution like
http://downloads.syncevolution.org/syncevolution/evolution/syncevolution-...
(also available for amd64), then after setting some env variables use it without copying
to /usr. The server HOWTO and the README contain a list of relevant variables.
--
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.
2:36 a.m.
On Wed, 2011-01-05 at 08:24 +0100, Patrick Ohly wrote:
0.9.1 is ancient, I successfully managed to forget everything about
it.
Yeah, they tell me I added IPv6 support to a number of router products,
but I doubt I'd spend my time on something so commercially useless.
When you say "too many missing libraries", do you mean for
compiling
from source or at runtime with the precompiled binaries?
I tried the precompiled binaries first, getting them from a downloaded
tarball. I believe the first library they complained about not finding
was libcpre.
I could have extracted needed libraries from distribution RPMs and added
them to my local library path, but it seemed more efficient to build
from source and let ./configure do its job.
The Synthesis ./configure kept finding missing libraries too. I worked
around the first couple by disabling features, but I ended up feeling I
was creating a Frankenstein configuration that was probably missing key
functionality, and that you had never tested.
So I asked about alternative paths.
It sounds like I need to go back to assembling my own set of libraries
installed in the home directory.
Thanks for the help.
-- John
2:37 a.m.
On Wed, 2011-01-05 at 08:24 +0100, Patrick Ohly wrote:
0.9.1 is ancient, I successfully managed to forget everything about
it.
Yeah, they tell me I added IPv6 support to a number of router products,
but I doubt I'd spend my time on something so commercially useless.
When you say "too many missing libraries", do you mean for
compiling
from source or at runtime with the precompiled binaries?
I tried the precompiled binaries first, getting them from a downloaded
tarball. I believe the first library they complained about not finding
was libcpre.
I could have extracted needed libraries from distribution RPMs and added
them to my local library path, but it seemed more efficient to build
from source and let ./configure do its job.
The Synthesis ./configure kept finding missing libraries too. I worked
around the first couple by disabling features, but I ended up feeling I
was creating a Frankenstein configuration that was probably missing key
functionality, and that you had never tested.
So I asked about alternative paths.
It sounds like I need to go back to assembling my own set of libraries
installed in the home directory.
Thanks for the help.
-- John
5:35 a.m.
On Mi, 2011-01-05 at 15:36 +0000, John Dykstra wrote:
I tried the precompiled binaries first, getting them from a
downloaded
tarball. I believe the first library they complained about not finding
was libcpre.
I assume you mean libpcre. Are you sure that this was with a recent
release? libpcre usage is optional and was turned off intentionally a
while back to increase compatibility.
In 1.1.1, ldd still shows it, but only as an indirect dependency. The
libs and binaries in SyncEvolution do not depend on it:
$ for i in usr/lib/libsyncevolution.so usr/lib/libsynthesis.so usr/lib/libsmltk.so
usr/bin/syncevolution usr/libexec/syncevo-dbus-server usr/lib/syncevolution/*.so
usr/lib/syncevolution/backends/*.so; do echo $i:; if readelf -a $i | grep NEED | grep -q
pcre; then echo has pcre; else echo no pcre; fi; done
usr/lib/libsyncevolution.so:
no pcre
usr/lib/libsynthesis.so:
no pcre
usr/lib/libsmltk.so:
no pcre
usr/bin/syncevolution:
no pcre
usr/libexec/syncevo-dbus-server:
no pcre
usr/lib/syncevolution/libgdbus.so:
no pcre
usr/lib/syncevolution/backends/syncaddressbook.so:
no pcre
usr/lib/syncevolution/backends/syncebook.so:
no pcre
usr/lib/syncevolution/backends/syncecal.so:
no pcre
usr/lib/syncevolution/backends/syncfile.so:
no pcre
usr/lib/syncevolution/backends/synckcalextended.so:
no pcre
usr/lib/syncevolution/backends/syncmaemocal.so:
no pcre
usr/lib/syncevolution/backends/syncqtcontacts.so:
no pcre
usr/lib/syncevolution/backends/syncsqlite.so:
no pcre
usr/lib/syncevolution/backends/syncxmlrpc.so:
no pcre
--
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.
1:52 p.m.
On Wed, 2011-01-05 at 19:35 +0100, Patrick Ohly wrote:
On Mi, 2011-01-05 at 15:36 +0000, John Dykstra wrote:
> I tried the precompiled binaries first, getting them from a downloaded
> tarball. I believe the first library they complained about not finding
> was libcpre.
I assume you mean libpcre. Are you sure that this was with a recent
release? libpcre usage is optional and was turned off intentionally a
while back to increase compatibility.
In 1.1.1, ldd still shows it, but only as an indirect dependency. The
libs and binaries in SyncEvolution do not depend on it:
I went back and tried again when I had more time. It turns out it's the
source build that requires libpcre:
configure: error: libpcre not found, required for --enable-regex
configure: error: configuring Synthesis library failed
I'm not sure what the implications of disabling regular expressions are,
but when I did, I ran into more serious problems:
checking for EPACKAGE... no
checking for EPACKAGE... no
checking for EPACKAGE... no
checking for ECAL... no
checking for ECAL... no
checking for ECAL... no
checking for EBOOK... no
checking for EBOOK... no
checking for EBOOK... no
configure: error: libebook not found. Use --disable-ebook to compile without or
install the necessary development files.
I _know_ I need the evolution backends to work. The libraries
themselves are installed--it's just the header files I'm missing. And I
can probably grab them from somewhere and hack the build to find them if
I have to.
However, the SE binary distribution requires two libraries that are not
installed:
libnotify.so.1 => not found
libopenobex.so.1 => not found
I don't need libopenobex (unless it's used for LAN HTTP traffic). Will
--disable-blue-tooth remove this dependency in the source build, and is
there an equivalent (undocumented) commandline option?
I imagine libnotify is used for the automatic sync notify feature.
Again, will --disable-notify do what I need, and is there a commandline
option?
Thanks!
-- John
6:42 p.m.
On Do, 2011-01-06 at 02:52 +0000, John Dykstra wrote:
I went back and tried again when I had more time. It turns out
it's the
source build that requires libpcre:
configure: error: libpcre not found, required for --enable-regex
configure: error: configuring Synthesis library failed
I'm not sure what the implications of disabling regular expressions are,
Some features in libsynthesis that SyncEvolution doesn't need aren't
available.
However, the SE binary distribution requires two libraries that are
not
installed:
libnotify.so.1 => not found
libopenobex.so.1 => not found
I don't need libopenobex (unless it's used for LAN HTTP traffic). Will
--disable-blue-tooth remove this dependency in the source build, and is
there an equivalent (undocumented) commandline option?
I imagine libnotify is used for the automatic sync notify feature.
Again, will --disable-notify do what I need, and is there a commandline
option?
Yes, you can disable these two dependencies at compile time with
--disable-bluetooth --disable-notify.
There's no command line option at the moment, although it wouldn't be
too hard to make these libs optional: put the OBEX transport class and
the notify code into loadable modules that are skipped when they cannot
be loaded. As you said, libnotify is used for autosync notifications,
which may not be used at all and will work without notifications. OBEX
is only needed for direct sync with phones.
This sounds like a useful improvement. Patches welcome :-/
--
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.
4273
days inactive
4277
days old
syncevolution@synevolution.org
10 comments
3 participants
participants (3)
-
John Dykstra -
John Dykstra -
Patrick Ohly