Hello Milan, I've selectively updated evolution, and this is what I got when running evolution after reboot: $ evolution > evolution: symbol lookup error: /lib64/libebook-contacts-1.2.so.3: undefined symbol: _ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE This ABI incompatibility may denote some versions should have been bumped? SONAME, Requires in the spec, or something like that. Let me know if there's something I can help with wrt. troubleshooting. Respective DNF transaction that turned working Evolution into broken one: Upgrade evolution-3.37.3-1.fc33.x86_64 @rawhide Upgraded evolution-3.37.2-1.fc33.x86_64 @@System Upgrade evolution-data-server-3.37.3-3.fc33.x86_64 @rawhide Upgraded evolution-data-server-3.37.2-1.fc33.x86_64 @@System Upgrade evolution-data-server-langpacks-3.37.3-3.fc33.noarch @rawhide Upgraded evolution-data-server-langpacks-3.37.2-1.fc33.noarch @@System Upgrade evolution-ews-3.37.3-1.fc33.x86_64 @rawhide Upgraded evolution-ews-3.37.2-1.fc33.x86_64 @@System Upgrade evolution-ews-langpacks-3.37.3-1.fc33.noarch @rawhide Upgraded evolution-ews-langpacks-3.37.2-1.fc33.noarch @@System Upgrade evolution-langpacks-3.37.3-1.fc33.noarch @rawhide Upgraded evolution-langpacks-3.37.2-1.fc33.noarch @@System
Ok, running "dnf update protobuf" helped. Whole transaction: Upgrade libphonenumber-8.12.3-3.fc33.x86_64 @rawhide Upgraded libphonenumber-8.12.3-2.fc33.x86_64 @@System Upgrade protobuf-3.12.3-1.fc33.x86_64 @rawhide Upgraded protobuf-3.11.4-2.fc33.x86_64 @@System Looks like evolution-data-server, or any element on the transitive dependency chain, has a bad/missing requires, or the dependency extractor in rpm (or macros subpackages) is botched. Or SONAME bumping was botched around protobuf? This shall not happen in a standard DNF flow, correct? AFAIK, no rpm --nodeps nor anything like that was involved on my side.
See also what Adam Williamson noticed: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JJP6J5N4BY4UF7OZEYNDN6NTAYNQLQIM/
Thanks for a bug report. I thought this is fixed since Adam's findings/rebuilds. Looking into koji, there are these successful builds: protobuf-3.12.3-1.fc33 from 2020-06-19 21:08:52 libphonenumber-8.12.3-3.fc33 from 2020-06-21 15:33:41 evolution-data-server-3.37.3-3.fc33 from 2020-07-14 07:04:38 The evolution-data-server version you have is from 2020-07-03 08:31:44, thus should depend on the same libphonenumber. Checking the root.log there's used: libphonenumber-devel x86_64 8.12.3-3.fc33 thus the latest, and correct, version. The evolution-data-server has set in the spec file [1]: BuildRequires: libphonenumber-devel BuildRequires: protobuf-devel BuildRequires: boost-devel It doesn't have any other dependency mentioned for the libphonenumber, fully relying on the rpm dependency "extractor". Looking into the REQUIRES for the current latest evolution-data-server package it mentions only: libphonenumber.so.8()(64bit) from the three BuildRequires mentioned above. As Adam said in his post, the libphonenumber soname version did not change, thus dnf/rpm properly thinks the version you had installed is fine and it left it unchanged for you (I suppose you did something like `dnf update evolution-data-server`, not the full `dnf update`, which would bring in everything recent). It seems this gonna be fun (in the future), when a package rebuild changes also exported symbol names. Nonetheless, also as Adam said, there is not much to be done here. The things are set correctly, only the packaging failed, the ABI (in fact API) change was not noticed and libphonenumber soname version was not bumped. Do you agree? [1] https://src.fedoraproject.org/rpms/evolution-data-server/blob/master/f/evolution-data-server.spec#_117
> suppose you did something like `dnf update evolution-data-server` That's why I provided full atomic transactions I ran, first one being "selective update of evolution" (OK, it wasn't entirely clear these were the only lines of the transaction log ... they were).
I think this puts libabigail results closer to the gating position, since unnoticed binary level breakages is something distro would ideally strive to eliminate, as the basic pillar (bit consistency based usability) is being undermined. Adding Dodji so he is possibly aware of this very use case.
Okay, thanks. I'm really unsure whether there's anything on the eds side to be done. Maybe this bug should be moved to other component? I'm not sure which that should be.
Will this problem go away automatically for people updating F32 -> F33 (or so) package piece-wise? If not (and I doubt that), I think some artificial package version enforcement shall also be added to eds' spec to overcome (or rather workaround, since the root cause seems to reside elsewhere with the packaging automatisms or the way protobuf generates self-incompatible stuff?) this trouble with the hidden, opaque binary incompatibility. Likely that minimum protobuf version is the one it was built with?
I think, and only think, that libphonenumber should have bumped its soname version and its dependencies be rebuilt, rather than ask each dependency to add workarounds in its spec files. That it's not a libphonenumber fault (at least not direct) is another story (I suppose the problem is that the rebuild against new protobuf changed the libphonenumber ABI - that's how I understand the issue at least).
Sounds reasonable, let's try moving this bug then...
Thanks. Let me know in case there would be anything to be done on the evolution-data-server side.
We don't really support "piece wise" upgrading. The official line is that you have to upgrade all at once. I'd generally tend to consider this more of an upstream issue (for missing the soname bump). Downstream if we did rebuild everything I'd say there isn't really a bug here, exactly.
Adam, I believe you just want to adjust the expectations here, and it's fair to state that less usual "configuration sets" will get less attention, but I think you exaggerate the opposite stance just as well: > We don't really support "piece wise" upgrading. It's the basic and _vital_ feature to make your mix wisely if you want, e.g. to stay conservative for most of the time, updating for CVE fixes only, or per recent example, avoiding anything but particular package update so as to avoid a boot breakage ([bug 1861977], which coincidentally happens exactly because of a CVE fix ... OK, I couldn't find if Fedora was also affected like this, but good for illustration). In a standard shared libraries model, everything works just fine in this RPM/DNF ecosystem. Only when these libraries fail to comply with ABI discipline, things go haywire. So please, _don't blame the use case_. It shall be about as supported as any other valid mix within the reasonable time frame (it's to be expected some stuff will break, e.g., when you go with a rusty old kernel, for instance, since such compatibility cannot be considered for a lack of practicality ... interestingly, some audience is bound to older kernels virtually forever for problems with graphical drivers, for instance [bug 1618906 comment 24]). Alternatively, please point me to where "own mix of packages satisfying RPM constraints (and within a reasonable timeframe, say +- release, which is satisfied here) not supported" statement is explicitly claimed. Maybe I just missed it. Putting more weight on abigail-based analysis would be a wise step in this light otherwise, I think.
I don't know if it's explicitly written down anywhere, but it's fairly consistently what people supporting Fedora tend to say when someone complains about an issue that occurred when trying to upgrade piecewise :) Installing only security updates *is* a case we care about, so if a problem like this occurs in that context it's something we'd want to fix. But I don't think that's the case here, it affected only Rawhide, which is something you really should upgrade as a unit. Like I said, not doing an soname bump upstream is clearly a bug *in the upstream project*. But particularly as this only affected Rawhide, there just doesn't seem to be anything much we can do about it downstream. If this libphonenumber bump goes to F31 or F32 we should definitely make sure all the rebuilds are included in the same update, and there would be a case for doing a downstream soname bump patch for the library, even. But for Rawhide it's kinda water under the bridge.
"Putting more weight on abigail-based analysis would be a wise step in this light otherwise, I think." That's certainly a valid direction, but a bug report on a single past case where it would have been useful but everything has now been cleaned up probably isn't the place for it. A ticket for Fedora CI or something would be more useful.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.