Bug 1861027 - Fishiness around "i18n::phonenumbers::PhoneNumber::PhoneNumber(google::protobuf::Arena*)" symbol (missed SONAME bump?)
Summary: Fishiness around "i18n::phonenumbers::PhoneNumber::PhoneNumber(google::protob...
Alias: None
Product: Fedora
Classification: Fedora
Component: libphonenumber
Version: 33
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Nikhil Jha
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2020-07-27 16:41 UTC by Jan Pokorný [poki]
Modified: 2021-11-30 16:17 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-11-30 16:17:48 UTC
Type: Bug

Attachments (Terms of Use)

Description Jan Pokorný [poki] 2020-07-27 16:41:25 UTC
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

Comment 1 Jan Pokorný [poki] 2020-07-27 19:01:57 UTC
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.

Comment 2 Jan Pokorný [poki] 2020-07-27 19:18:13 UTC
See also what Adam Williamson noticed:

Comment 3 Milan Crha 2020-07-28 06:52:22 UTC
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:
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

Comment 4 Jan Pokorný [poki] 2020-07-28 13:07:36 UTC
> 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).

Comment 5 Jan Pokorný [poki] 2020-07-28 13:28:09 UTC
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.

Comment 6 Milan Crha 2020-07-28 13:56:27 UTC
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.

Comment 7 Jan Pokorný [poki] 2020-07-28 14:04:11 UTC
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?

Comment 8 Milan Crha 2020-07-28 14:23:27 UTC
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).

Comment 9 Jan Pokorný [poki] 2020-07-28 14:55:02 UTC
Sounds reasonable, let's try moving this bug then...

Comment 10 Milan Crha 2020-07-28 15:03:08 UTC
Thanks. Let me know in case there would be anything to be done on the evolution-data-server side.

Comment 11 Adam Williamson 2020-07-29 22:14:09 UTC
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.

Comment 12 Jan Pokorný [poki] 2020-08-01 15:00:18 UTC
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.

Comment 13 Adam Williamson 2020-08-01 16:28:55 UTC
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.

Comment 14 Adam Williamson 2020-08-01 16:32:06 UTC
"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.

Comment 15 Ben Cotton 2020-08-11 13:50:02 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Comment 16 Ben Cotton 2021-11-04 17:37:35 UTC
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.

Comment 17 Ben Cotton 2021-11-30 16:17:48 UTC
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

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.