[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 heimlicher changed: What|Removed |Added Resolution|--- |WORKSFORME Status|REPORTED|RESOLVED -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 --- Comment #11 from heimlicher --- 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 -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 --- Comment #10 from Antonio Rojas --- > 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. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 --- Comment #9 from Harald Sitter --- (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 :| -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 --- Comment #8 from Antonio Rojas --- (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 :) -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 --- Comment #7 from Harald Sitter --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 Antonio Rojas changed: What|Removed |Added CC||aro...@archlinux.org --- Comment #6 from Antonio Rojas --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 --- Comment #5 from Christophe Giboudeaux --- The Leap 15.2 build uses akonadi-server-20.04.2, the Tumbleweed one uses 20.12.2 -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 --- Comment #4 from Christophe Giboudeaux --- We have two patches to make it build with different versions, check https://build.opensuse.org/package/show/KDE:Extra/zanshin -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 --- Comment #3 from Harald Sitter --- Why would we? The soversion hasn't changed. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 --- Comment #2 from Christophe Giboudeaux --- Looks like you didn't rebuild zanshin? -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 Harald Sitter changed: What|Removed |Added Component|Packages User Edition |general CC||dvra...@kde.org Product|neon|Akonadi Assignee|neon-b...@kde.org |kdepim-bugs@kde.org --- Comment #1 from Harald Sitter --- Surely this broke the ABI https://invent.kde.org/pim/akonadi/-/commit/261678d504a27d75eaa1d8b1730e837f39858952 > template 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); 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 -- You are receiving this mail because: You are the assignee for the bug.
