SyncEvolution fails to sync with my Evolution calendar, it gives me
the following error on the command line:

[ERROR] Error allocating calendar

Synchronization failed, see /home/bloom/.cache/syncevolution/funambol-2011-03-07-19-50/syncevolution-log.html for details.

And the log file is attached.

(Some quick googling suggests that this bug is related to
https://bugzilla.gnome.org/show_bug.cgi?id=638080)

I discovered that SyncEvolution 1.1+ds1 is still linked against
various libs from Evolution 2.30.3. When I upgraded SyncEvolution to
1.1.1a and rebuilt against Evolution 2.32.2 (the current unstable).

To work around bug #615263, I added -lsmltk to the end of CORE_LDADD
(line 115) in src/Makefile-gen.am.

Thanks for the followup.  If you could try Debian version 1.1.99.3+ds1-1
(just uploaded to experimental) to see if it works for you, that would be
helpful.

d

the upgrade process:

First, the new syncevolution doesn't have a versioned dependency on
libsynthesis0 and libsmltk0, so I had to upgrade those separately.

Second, I had to kill syncevo-dbus-server and restart it in order for
things to work. I'm not 100% certain about why I needed to do either of
those things, but here's my take:

I hadn't run syncevolution today before upgrading. (That means I hadn't
run it since the last time I powercycled the computer)

aptitude install -t experimental syncevolution

I tried to run syncevolution -- and an error message with lots of XML
I remembered I needed to migrate the configuration. (You need to make
this automatic somehow.)
I tried to run syncevolution again -- same error message with lots of
XML

aptitude install -t experimental libsynthesis0 libsmltk0,

I tried to run syncevolution again -- same error message with lots of
XML

kill syncevo-dbus-server

I ran syncevolution again, and this time I succeeded.

The only thing I can think of is that the first time I ran synceovlution
after the upgrade, it started the new syncevo-dbus-server with the old
libsynthesis0, with which it's incompatible. It didn't actually pick up
the new libsynthesis0 (even after I installed the new version) until I
killed syncevo-dbus-server so that it could start again linked to the
new version.

The moral of the story: I think you need a versioned dependency on
libsynthesis0 and libsmltk0, you need a way to kill syncevo-dbus-server
after the upgrade, and you need a way to automatically migrate the
configuration.

the upgrade process:

First, the new syncevolution doesn't have a versioned dependency on
libsynthesis0 and libsmltk0, so I had to upgrade those separately.

Second, I had to kill syncevo-dbus-server and restart it in order for
things to work. I'm not 100% certain about why I needed to do either of
those things, but here's my take:

I hadn't run syncevolution today before upgrading. (That means I hadn't
run it since the last time I powercycled the computer)

aptitude install -t experimental syncevolution

I tried to run syncevolution -- and an error message with lots of XML
I remembered I needed to migrate the configuration. (You need to make
this automatic somehow.)
I tried to run syncevolution again -- same error message with lots of
XML

aptitude install -t experimental libsynthesis0 libsmltk0,

I tried to run syncevolution again -- same error message with lots of
XML

kill syncevo-dbus-server

I ran syncevolution again, and this time I succeeded.

The only thing I can think of is that the first time I ran synceovlution
after the upgrade, it started the new syncevo-dbus-server with the old
libsynthesis0, with which it's incompatible. It didn't actually pick up
the new libsynthesis0 (even after I installed the new version) until I
killed syncevo-dbus-server so that it could start again linked to the
new version.

The moral of the story: I think you need a versioned dependency on
libsynthesis0 and libsmltk0, you need a way to kill syncevo-dbus-server
after the upgrade, and you need a way to automatically migrate the
configuration.

It sounds like we need to go back to forcing the versions of
libsynthesis and libsmltk like we used to; somehow the compatability of
these libraries is not very well reflected by the SONAME/set of symbols.

At the moment upstream (hi Patrick!) explicitly makes the migration
manual because it isn't backward compatible. Perhaps the next
stable upstream release will have a smoother migration path.

I don't know of a clean way to have the package upgrade process restart
a bunch of user processes. This seems to be a bit dangerous in general
in a multi-user environment.  I'm open to suggestions, but for the
moment the best I can think of is to add a message to NEWS.Debian.

d

He changes the configuration so that you don't *downgrade* without
having to do some manual stuff to make the downgrade work. I'm not sure
that's a reason not to automatically update the configuration on
upgrade.

One could solve the problem by making the new version of syncevolution
put a version number in its DBUS interface (just like they've been
discussing doing with Evolution, which broke its DBUS interface) -- then
the new SyncEvolution *can't* call the old DBUS service.

I would also speculate the old dbus service will still work properly
(assuming one didn't migrate the configuration) so long as you didn't
make the mistake of loading the old dbus service with the new
libsynthesis.

He changes the configuration so that you don't *downgrade* without
having to do some manual stuff to make the downgrade work. I'm not sure
that's a reason not to automatically update the configuration on
upgrade.

One could solve the problem by making the new version of syncevolution
put a version number in its DBUS interface (just like they've been
discussing doing with Evolution, which broke its DBUS interface) -- then
the new SyncEvolution *can't* call the old DBUS service.

I would also speculate the old dbus service will still work properly
(assuming one didn't migrate the configuration) so long as you didn't
make the mistake of loading the old dbus service with the new
libsynthesis.

Well, maybe you could discuss this with upstream. It isn't the kind of
change I'm likely to undertake as a debian maintainer.

All the best,

David

I admit that I don't know enough about DBUS to know whether this is
the solution (or even whether we have a real problem here). I don't
think I have the expertise to raise it with anyone myself.

I already bumped the libtool versioning (admittedly after releasing
1.1.99.3), but that alone is probably not enough, because the soname
stays libsynthesis.so.0. David, please add a minimum version to
SyncEvolution.

My only explanation for that is out-dated libsynthesis. More recent
SyncEvolution uses XML elements not supported by the older libsynthesis.

It will be automatic in the next stable SyncEvolution release. In the
current pre-releases it is not, because I don't want to get users who
are unaware of the config rewriting into a state where they don't know
how to downgrade.

Yes, that's also my interpretation.

Agreed. David, I believe there are ways to restart daemons in Debian
(think glibc security update) - can you investigate how that could be
applied to SyncEvolution updates?

I already bumped the libtool versioning (admittedly after releasing
1.1.99.3), but that alone is probably not enough, because the soname
stays libsynthesis.so.0. David, please add a minimum version to
SyncEvolution.

My only explanation for that is out-dated libsynthesis. More recent
SyncEvolution uses XML elements not supported by the older libsynthesis.

It will be automatic in the next stable SyncEvolution release. In the
current pre-releases it is not, because I don't want to get users who
are unaware of the config rewriting into a state where they don't know
how to downgrade.

Yes, that's also my interpretation.

Agreed. David, I believe there are ways to restart daemons in Debian
(think glibc security update) - can you investigate how that could be
applied to SyncEvolution updates?

I would have to introduce a "restart as soon as possible" feature. A
hard-kill during a sync wouldn't be very nice, and not restarting would
prevent further automatic syncing.

That won't help, because it would keep the old syncevo-dbus-server
running, if automatic syncing is enabled. Those sync attempts then will
fail.

No, it will use the old libsynthesis (loaded during process startup) and
incompatible XML files from current SyncEvolution (loaded during each
sync).

I would have to introduce a "restart as soon as possible" feature. A
hard-kill during a sync wouldn't be very nice, and not restarting would
prevent further automatic syncing.

That won't help, because it would keep the old syncevo-dbus-server
running, if automatic syncing is enabled. Those sync attempts then will
fail.

No, it will use the old libsynthesis (loaded during process startup) and
incompatible XML files from current SyncEvolution (loaded during each
sync).

Hi Patrick;

As far as I know, the daemons restarted are system daemons, started
through /etc/init.d/blah. They therefore have mechanisms in place (e.g
pid files) to restart them.  The obvious mechanism to restart
syncevo-dbus-daemon is via dbus. I suppose it would be possible to send
a message from the install process via the system dbus session, but it
would need support on the application side, and I don't know what the
security implications would be.  Maybe some real dbus expert can think
about this?

All the best,

David

Hi,

a new version was uploaded to experimental. If you can test this, it
would be nice to know if all of your issues are fixed.

Regards,
Tino

Hi,

a new version was uploaded to experimental. If you can test this, it
would be nice to know if all of your issues are fixed.

Regards,
Tino

Dear submitter,

as the package syncevolution has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/935239

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

This bug has likely been fixed in the last decade, please check
syncevolution version 2.0.0-3 from Debian testing/bookworm or later.
If you still have the same issue, please report it upstream and let us
know the URL of the new upstream issue.

https://syncevolution.org/support