On Mon, 2016-05-16 at 10:59 +0200, Andreas Henriksson wrote: > Hello! > > Some information below which might be useful.... > > On Sun, May 15, 2016 at 09:37:24PM +0200, Michael Biebl wrote: > > Source: syncevolution > > Version: 1.4.99.4-5 > > Severity: serious > > > > Hi, > > > > during the libical transition [1], your package syncevolution was > > rebuilt and it now FTBFS: > [...] > > src/syncevo/.libs/libsyncevolution.so: undefined reference to > > `ical_tzid_prefix' > [...] > > I've quickly looked into this issue since it was discovered > (sorry I missed spotting it before the transition started). > > The global variable referenced above is indeed gone (in general > libical seems to be moving away from global variables in 2.0.0 > in favour of accessor methods). The new accessor function to > get the value is called icaltimezone_tzid_prefix(). See: > http://sources.debian.net/src/libical/2.0.0-0.4/src/libical/icaltimezone.c/?hl=150#L150 > > I looked upstream but there seemed to be very little activity in recent time.
There hasn't been much demand for new features lately, so I consider SyncEvolution fairly stable and in maintenance now. However, making it compile on newer systems certainly counts as "maintenance" - I'll look into it. The problem for me upstream nowadays is mostly around continuing to provide pre-compiled binaries for different distros. I got stuck on that the last time I tried preparing a new release, because distros have diverged in quite a few relevant libraries now (libical, EDS, even libopenobex). Perhaps I should just give up on that front. OTOH, Debian itself is still on an old, pre-release version. Tino, do you still have plans for getting SyncEvolution updated in Debian? > The libical2 transition has already been done in fedora so for comparison > they're patching their syncevolution, see: > http://pkgs.fedoraproject.org/cgit/rpms/syncevolution.git/tree/syncevolution-1.5.1-libical2.patch > > IMNSHO the fedora patch is an ugly hack since duplicating the information > instead of using accessor method isn't nice IMO. OTOH I've looked at > syncevolutions usage of the global variable and if we're going to replace > it we see it in two places. The one failing the build above + in the > syncevolution homebrew/duplicated evolution(-data-server?) API. > That one looks too scary to touch for me who has no way to test this > so I sympathize with fedoras patch and maybe it's better to go that > route. Also, the get accessor seems to be missing from the libical2.symbols > for some reason so might need fixes on the libical side to be properly > exported.... That scary code is needed only when compiling upstream binaries that must work with different EDS versions. For Debian it might be enough to just call the accessor method. -- 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.
