On Tue, 2016-01-19 at 11:25 +0100, Milan Crha wrote:
> Hello,
> I just realized that the syncevolution fails to build against
> libical 2.0.0. The problem is synevolution's extract of
> icaltz-util.c/.h, referencing extern const char *ical_tzid_prefix;
> This variable had been made private and there is no way to get to it
> from the outside of libical (the added icaltimezone_tzid_prefix() is
> not exported in the libical library).
>
> I do not know the rationale with the icaltz-util extract in the
> syncevolution, but I'd say it's time to get rid of it when new-enough
> libical is used for the build. What do you think?
Does the libical 2.0 return "simple" VTIMEZONE definitions again, i.e.
ones with RRULEs for summer and winter time?
The reason for icaltz-util.c is this:
commit 9d13210d0bc5eba1e280fde7742a198e5631974f
Author: Patrick Ohly
Date: Wed Mar 19 13:13:50 2014 +0100
ical: workaround for libical 1.0 builtin timezone change
libical 1.0 started to return VTIMEZONE definitions with multiple
absolute transition times instead of RRULEs. This causes problems when
exchanging data with peers (see
https://sourceforge.net/p/freeassociation/bugs/95/).
In SyncEvolution, this affected sending an event using New Zealand
time in vCalendar 1.0 format to a phone, because the internal,
out-dated definition of the time zone in libsynthesis was used as
fallback when loading RRULE-based timezone definitions from libical
failed (see "[SyncEvolution] Some events showing wrong time on
phone"). It might also affect exchanging data with CalDAV peers (not
tested).
The workaround is to include the original code from libical from
before the change in SyncEvolution and override
icaltimezone_get_component() with a version that uses the original
timezone loading code. This does not fix cases where other code causes
libical itself to load a timezone, but for libsynthesis it is good
enough because it does the loading early when no other code should
have used libical.
[...]
I don't remember whether ical_tzid_prefix absolutely has to be the one
from libical or whether it can also be something else. I've not tested
with libical 2.0 yet.
I started testing, but ran out of time and patience. This whole "let's
break the ABI, people will recompile anyway" is making it harder and
harder to provide pre-compiled SyncEvolution binaries.
--
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.
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution
