On Mon, Sep 07, 2015 at 12:01:31PM +0200, Alexander Kurtz wrote: > Hi, > > evolution-data-server 3.16.5-1 (which was uploaded *after* libical > 1.0.1-0.1 [0] [1] and therefore already built with the newer version) > migrated to testing yesterday [2], followed by evolution itself today. > > Upgrading evolution and evolution-data-server therefore makes the > calendar functionality work correctly again, just like last time [3].
Yes, everything built after/against the new libical will pick up the new ABI and work (only) with the new version. In debian we try to support partial upgrades though (eg. mixtures of stable and testing), so this is still considered a bug even if we rebuild all reverse dependencies of libical. > > I have also taken a closer look at the diff between libical 1.0-1.3 and > 1.0.1-0.1 [4] and libicals ABI specification [5] and now *think* that > it does actually ship a stable ABI and the break we have experienced is Yes upstream seems to think so, that's what fooled me into believing the update was safe. It doesn't seem to be true though. Every time new header files are generated there's a risk of ABI breakage since something new might have been added to the source database which will get *sorted* during header/enum generation which means the new addition might get added to the middle (rather then the end, which would have been perferctly fine,) of the enum breaking ABI for everything in the enum after the new addition. This was actually caught when the sorting patch was first introduced .... see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773916#27 > simply the result of the transition from the previous, unstable ABI > (which Debian changed again to make the build reproducible [6]) to the > new stable ABI. Please also see [7] in regard to that. > > This means, that this bug (#797003) is actually not a bug, but rather a > symptom of a bugfix and the actual bug is the missing transition [8] > for libical. It might be worth checking the other reverse dependencies > of libical, since there's a good chance most of them have already been > rebuilt with the new version because of the GCC 5 transition. > > With any luck, both this bug and the transition bug can be closed > without any further action. Adding the ABI check you proposed [9] is > probably still a *very* good idea, as is making the build reproducible > [A], but this can be done in a regular upload. Since we support partial upgrades, the broken ABI is still a bug and needs a transition. Regards, Andreas Henriksson
