SUMMARY Calling Zanshin on the console in neon results in the following error: c@neon ~$ zanshin zanshin: symbol lookup error: zanshin: undefined symbol: _ZN7Akonadi16AttributeFactory17registerAttributeEPNS_9AttributeE zanshin version: zanshin_0.5.71-1+20.04+focal+build6 Operating System: KDE neon 5.21 KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.8.0-43-generic OS Type: 64-bit Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-3230M CPU @ 2.60GHz Memory: 15.2 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4000 Testing and unstable lead to the same error.
Surely this broke the ABI https://invent.kde.org/pim/akonadi/-/commit/261678d504a27d75eaa1d8b1730e837f39858952 > template <typename T> inline static void registerAttribute() would be code that ends up in the caller of the template function, in this case zanshin, calling into the public symbol (albeit private function) > void registerAttribute(std::unique_ptr<Attribute> attribute); which has a different calling signature as per that commit Namely the new symbol is (from a master build): > _ZN7Akonadi16AttributeFactory17registerAttributeESt10unique_ptrINS_9AttributeESt14default_deleteIS2_EE while the one before was (from a 20.04 build): > _ZN7Akonadi16AttributeFactory17registerAttributeEPNS_9AttributeE
Looks like you didn't rebuild zanshin?
Why would we? The soversion hasn't changed.
We have two patches to make it build with different versions, check https://build.opensuse.org/package/show/KDE:Extra/zanshin
The Leap 15.2 build uses akonadi-server-20.04.2, the Tumbleweed one uses 20.12.2
(In reply to Harald Sitter from comment #3) > Why would we? The soversion hasn't changed. kdepim developers don't care about soversions. akonadi breaks ABI very frequently and applications linking to it need to be rebuilt.
That may well be but then the soversion will still have to change. The only options for any library are: a) when ABI is broken the soversion is bumped b) nobody checks if ABI is broken and the soversion is directly tied to the release version e.g. the there is no libfoo.so.5 but only a libfoo.so.5.20.12.2 c) the library has no version, is considered private, and doesn't advertise itself for external use (install with NAMELINK_SKIP + no cmake config) One may pick any of the three.
(In reply to Harald Sitter from comment #7) > That may well be but then the soversion will still have to change. > > The only options for any library are: > > a) when ABI is broken the soversion is bumped > b) nobody checks if ABI is broken and the soversion is directly tied to the > release version e.g. the there is no libfoo.so.5 but only a > libfoo.so.5.20.12.2 > c) the library has no version, is considered private, and doesn't advertise > itself for external use (install with NAMELINK_SKIP + no cmake config) > > One may pick any of the three. (b) would be a nightmare for packagers, we'd need to rebuild everything after every bug fix release (note that this affects every PIM library, not just akonadi) For (c) it is too late, there is stuff using pim libraries already. The right way is (a), but good luck trying to convince kdepim devs of that :)
(In reply to Antonio Rojas from comment #8) > (In reply to Harald Sitter from comment #7) > > That may well be but then the soversion will still have to change. > > > > The only options for any library are: > > > > a) when ABI is broken the soversion is bumped > > b) nobody checks if ABI is broken and the soversion is directly tied to the > > release version e.g. the there is no libfoo.so.5 but only a > > libfoo.so.5.20.12.2 > > c) the library has no version, is considered private, and doesn't advertise > > itself for external use (install with NAMELINK_SKIP + no cmake config) > > > > One may pick any of the three. > > (b) would be a nightmare for packagers, we'd need to rebuild everything > after every bug fix release (note that this affects every PIM library, not > just akonadi) > For (c) it is too late, there is stuff using pim libraries already. > The right way is (a), but good luck trying to convince kdepim devs of that :) Heh. Distros can always opt out of b) and patch it to a) ;). Though I'm not sure I understand the concern. If pim devs don't pay attention to the ABI then in what scenario would a distro not rebuild everything? Or I guess to preempt the answer a bit, if distros can tell if ABI was broken, why can't we, KDE, and bump the version when that happens. The bottom line here is that proper so versioning is not the same as ABI stability. Just because pim doesn't care about ABI stability doesn't mean we should release clearly incorrectly versioned libraries. In particular when even our own software outside the release-service is using it, so the "oh but this library is not for third parties" excuse doesn't even fly here :|
> Though I'm not sure I understand the concern. If pim devs don't pay > attention to the ABI then in what scenario would a distro not rebuild > everything? Or I guess to preempt the answer a bit, if distros can tell if > ABI was broken, why can't we, KDE, and bump the version when that happens. My current workflow is to manually test every out-of-release-service user after each major release, and rebuild stuff when necessary. I suppose bigger distros have resources to check for ABI breakage properly. I was assuming your alternative (b) would mean bumping the soversion on every release, including minor ones (using only the major version number wouldn't make sense given the date-based versioning that release service uses). But, given that PIM packages have a different internal version number from the release service version, (5.16.x currently), having 5.16 as the soversion would be a reasonable implementation of (b), so it only gets bumped on major releases.
todays update fixed the error for now: http://archive.neon.kde.org/user focal/main amd64 zanshin amd64 0.5.71-1+20.04+focal+build8