Bug 1023020 - Rebuild of libical causes ABI break with the previous version
Rebuild of libical causes ABI break with the previous version
Product: Fedora
Classification: Fedora
Component: libical (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Robert Scheck
Fedora Extras Quality Assurance
: 1028169 (view as bug list)
Depends On: 1028169
  Show dependency treegraph
Reported: 2013-10-24 09:10 EDT by Gert Michael Kulyk
Modified: 2013-11-25 23:00 EST (History)
8 users (show)

See Also:
Fixed In Version: openchange-2.0-5.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-25 23:00:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test.c (2.76 KB, text/plain)
2013-11-07 09:27 EST, Milan Crha
no flags Details
Proposed patch (517 bytes, patch)
2013-11-21 09:23 EST, Tomas Popela
no flags Details | Diff

  None (edit)
Description Gert Michael Kulyk 2013-10-24 09:10:04 EDT
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.
Comment 1 Milan Crha 2013-11-05 15:40:18 EST
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.
Comment 2 Milan Crha 2013-11-06 15:06:49 EST
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).
Comment 3 Milan Crha 2013-11-07 09:06:02 EST
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.
Comment 4 Milan Crha 2013-11-07 09:27:23 EST
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.
Comment 5 Milan Crha 2013-11-07 12:40:04 EST
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.
Comment 6 Milan Crha 2013-11-07 13:11:13 EST
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.
Comment 7 Milan Crha 2013-11-07 13:15:10 EST
(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 [1] and add all the (to-be-)rebuilt packages to it, thus these are released together, in one update, avoiding inconsistencies.

[1] https://admin.fedoraproject.org/updates/FEDORA-2013-19543/libical-1.0-3.fc20
Comment 8 Milan Crha 2013-11-07 15:00:23 EST
Let's wait for a result of bug #1028169 first.
Comment 9 Milan Crha 2013-11-08 02:50:19 EST
*** Bug 1028169 has been marked as a duplicate of this bug. ***
Comment 10 Milan Crha 2013-11-08 02:52:19 EST
See bug #1028169 comment #2 for a cause, and its first comment for a simplified test.c.
Comment 11 Milan Crha 2013-11-08 05:09:58 EST
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.
Comment 12 Tomas Popela 2013-11-21 09:23:06 EST
Created attachment 827226 [details]
Proposed patch

Looks like they forgot (in other parts the use sort) to sort keys before generating the code.
Comment 13 Milan Crha 2013-11-21 09:27:52 EST
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?
Comment 14 Robert Scheck 2013-11-21 09:33:38 EST
Milan, just go for it. You also have commit rights now.
Comment 15 Fabiano Fidêncio 2013-11-21 09:40:31 EST
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
Comment 16 Milan Crha 2013-11-21 10:08:20 EST
(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.
Comment 17 Milan Crha 2013-11-21 10:34:52 EST
List of (probably) affected packages, according to
   $ repoquery -q --whatrequires --alldeps --releasever=20 --enablerepo=* \

Comment 18 Fedora Update System 2013-11-21 10:57:34 EST
libical-1.0-4.fc20 has been submitted as an update for Fedora 20.
Comment 19 Adam Williamson 2013-11-21 14:50:17 EST
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.
Comment 20 Milan Crha 2013-11-21 15:16:18 EST
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):
Comment 21 Fedora Update System 2013-11-23 22:43:59 EST
Package openchange-2.0-5.fc20, syncevolution-, 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- 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).
Comment 22 Fedora Update System 2013-11-25 23:00:34 EST
openchange-2.0-5.fc20, syncevolution-, 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.

Note You need to log in before you can comment on or make changes to this bug.