Bug 1023020

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]
test.c

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 [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

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]
Proposed patch

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 

   asterisk-calendar
   bluez
   evolution
   evolution-data-server
   evolution-ews
   evolution-mapi
   gnokii
   gnome-shell
   kdepimlibs
   kmymoney
   libmapi
   libopensync-plugin-evolution2
   openchange-client
   orage
   osmo
   syncevolution
   syncevolution-libs
   zarafa-ical

libical-1.0-4.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libical-1.0-4.fc20

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):
   asterisk-calendar
   bluez
   gnokii
   kdepimlibs
   kmymoney
   libmapi
   orage
   osmo
   zarafa-ical

Package openchange-2.0-5.fc20, syncevolution-1.3.99.3-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-1.3.99.3-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:
https://admin.fedoraproject.org/updates/FEDORA-2013-21989/openchange-2.0-5.fc20,syncevolution-1.3.99.3-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
then log in and leave karma (feedback).

openchange-2.0-5.fc20, syncevolution-1.3.99.3-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.