Red Hat Bugzilla – Bug 1023020
Rebuild of libical causes ABI break with the previous version
Last modified: 2013-11-25 23:00:34 EST
I recently upgraded to f20, therefore I'm using e-d-s/evolution 3.10.1 and libical 1.0. When using libical 1.0 without upstream changeset r1150, there is a bug with recurring all-day-events that are starting before 1950-01-01 (e.g. Birthday events), causing these events to start at 23:00 the day before the event and ending at 23:00 the day of the event and therefore showing up twice in Evolution calendar and gnome-shell calendar (rhbz#1021136).
Adding upstream changeset r1150 to libical fixes this (as done in libical currently in f20 updates-testing), so this seems not to be related to e-d-s, but now there is another problem, which seems to be much more serious than the problem I initially encountered and seems to be definitely related to e-d-s: Now recurring appointments that using X-EVOLUTION-ENDDATE are not handled properly anymore (see https://bugzilla.redhat.com/show_bug.cgi?id=1021136#c4 for steps to reproduce), which is serious in so far, as this is the default in Evolution to set up recurring appointments (using "until" a given date, everything is still working as expected).
I did not have time yet to have a closer look at this, but it seems like the corresponding code for X-EVOLUTION-ENDDATE creation and interpretation is to be found in "calendar/libecal/e-cal-recur.c". As you are much more familiar with e-d-s than I am and will ever be, I'd appreciate any help to track down the issue. Thanks.
Thanks for a bug report. I can reproduce this with or without the X-EVOLUTION-ENDDATE parameter, the 1.0-3 generates instances incorrectly, while 0.48-4 does the job right. I'll investigate further what's going on here and let you know my progress.
This is getting interesting. I compiled libical locally, on Fedora 19, and I cannot reproduce the issue, I get correct behaviour here. Compiling the same libical locally on Fedora 20 reproduces the issue. Doing some gdb debugging, it shows that at the e-cal-recur.c:3964, where the icalvalue_new_from_string is called with ICAL_DATETIME_VALUE parametr, is actually received (by libical, as reported by gdb) as ICAL_CARLEVEL_VALUE, which doesn't make any sense to me, especially when I copy this line into a separate test application the gdb shows correct value being passed into libical and everything looks correct. That makes me wonder of a binary incompatibility or something like that between the eds' libecal-1.2 and libical, though it seems to be unlikely and odd even to me (aka I cannot figure out right now why it is doing that).
OK, so, I have a Fedora 20 machine, fully updated. If I build eds (evolution-data-server) in koji, the recurrence generator is broken, but if I build eds locally, either in a source checkout or even with 'fedpkg local', then everything works as expected. I do not understand why, especially when I have up-to-date Fedora 20, which I might expect means the same packages as koji uses.
Created attachment 821166 [details]
The simplest test program. With eds from koji, it generates 342 instances, while with eds built locally only 2. I did not change anything in libical, only the eds build place was changed. The breakage I noticed is when icalvalue_new_from_string is called, as I wrote in comment #2. The test program calls the function the same way eds does, and it works always there. Maybe also because I build it locally, not on koji.
I joined the #fedora-devel channel on FreeNode and I was told that the
'fedpkg mockbuild' is different from the 'fedpkg local' build, which I realized is true, as I the mockbuild (initiated locally) also suffers of this issue. I've got a list of different packages being used in the local build and in mock, thus I'm currently trying to identify which package causes the problem.
So, after most of the day on this I think I found the culprit here. It's libical itself, or better the way it was built. Let me try to explain what I've found:
The mockbuild currently uses libical-1.0-2, a version built during a mass rebuild for Fedora 20, back in August 03.
My local build used libical-1.0-3, the most recent version, which only adds a simple patch and nothing else, no soname bump, no interface change, nothing.
And now, if I build eds against libical-1.0-2 and run my test program, then it works as expected, but if I update libical to 1.0-3 (and only update the package, I will not rebuild anything), then the test application breaks and shows incorrect recurrences. Rebuilding eds and the test application with libical-1.0-3 installed makes it work as expected again.
From that I _guess_ that the 1.0-2 is somehow binary incompatible with 1.0-3, which causes the breakage when binary packages are updated.
I suggest to rebuild all dependant packages of libical once the 1.0-3 version reached build root of Fedora 20.
(In reply to Milan Crha from comment #6)
> I suggest to rebuild all dependant packages of libical once the 1.0-3
> version reached build root of Fedora 20.
Probably the best option would be to edit the update  and add all the (to-be-)rebuilt packages to it, thus these are released together, in one update, avoiding inconsistencies.
Let's wait for a result of bug #1028169 first.
*** Bug 1028169 has been marked as a duplicate of this bug. ***
See bug #1028169 comment #2 for a cause, and its first comment for a simplified test.c.
It could be, I'm guessing here, that this ABI break on a libical rebuild begun in 1.0, because the .spec file calls cmake to properly generate autotools files. It was using pregenerated autotools files in the past, before 1.0.
Created attachment 827226 [details]
Looks like they forgot (in other parts the use sort) to sort keys before generating the code.
Thanks Tomas, I tested your patch and it provides consistent ICAL_..._VALUE enum values on rebuilds, which is great.
I do not have commit rights to libical, thus I cannot simply apply it in Fedora, but, Robert, please, include the patch into Fedora 20 and rawhide, and once it's there, you might need to rebuild all packages which depend on libical, to make sure they use the stabilized enum values.
May I propose this a blocker for Fedora 20?
Milan, just go for it. You also have commit rights now.
From Allen Winter's talk on IRC:
14:37 <winterz> done. svn commit 1156 (http://sourceforge.net/p/freeassociation/code/1156/)
14:37 <winterz> please add that info to the bug so we know for sure I committed
(In reply to Milan Crha from comment #13)
> May I propose this a blocker for Fedora 20?
Adam, I'm not 100% sure, but I guess this can be a Fedora 20 blocker. To summarize the issue:
libical uses some Perl script to generate list of enums, which is regenerated each full build (including cmake call). The package calls the cmake since
libical 1.0, because it provided outdated autotools files. Unfortunately, one of the enums is changed each build, the keys are not sorted, which breaks ABI between versions (code compiled against libical 1.0-2 - using those affected enums - doesn't run properly when run against libical 1.0-3).
Due to this I suggest to patch libical package in fedora 20 and rawhide and rebuild all packages which depend on libical, to get things under control again.
List of (probably) affected packages, according to
$ repoquery -q --whatrequires --alldeps --releasever=20 --enablerepo=* \
libical-1.0-4.fc20 has been submitted as an update for Fedora 20.
enough of those apps are included by default that I'd probably be +1 to this as a blocker, but F20 is not frozen for another week. Right now your update can go stable just by the normal method, you don't need it to be a blocker or FE-fixing update.
Good. I'm currently building / have built packages to which I have commit rights, and I'll add them to the update (comment #18), but these still left, I need help on them from someone else (a proven packager probably; I rebuild both rawhide and f20 packages; libmapi is tagged for buildroot for 7 days):
Package openchange-2.0-5.fc20, syncevolution-188.8.131.52-7.fc20, libopensync-plugin-evolution2-0.22-38.fc20, gnome-shell-3.10.2-3.fc20, evolution-mapi-3.10.2-2.fc20, evolution-ews-3.10.2-2.fc20, evolution-3.10.2-2.fc20, evolution-data-server-3.10.2-2.fc20, libical-1.0-4.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openchange-2.0-5.fc20 syncevolution-184.108.40.206-7.fc20 libopensync-plugin-evolution2-0.22-38.fc20 gnome-shell-3.10.2-3.fc20 evolution-mapi-3.10.2-2.fc20 evolution-ews-3.10.2-2.fc20 evolution-3.10.2-2.fc20 evolution-data-server-3.10.2-2.fc20 libical-1.0-4.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
openchange-2.0-5.fc20, syncevolution-220.127.116.11-7.fc20, libopensync-plugin-evolution2-0.22-38.fc20, gnome-shell-3.10.2-3.fc20, evolution-mapi-3.10.2-2.fc20, evolution-ews-3.10.2-2.fc20, evolution-3.10.2-2.fc20, evolution-data-server-3.10.2-2.fc20, libical-1.0-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.