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 <[email protected]> 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 [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
