Bug 1375026 - dnf fails with unknown symbol in libcurl.so.4 with latest updates of both in rawhide, f26.
Summary: dnf fails with unknown symbol in libcurl.so.4 with latest updates of both in ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: librepo
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tomas Mlcoch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-11 23:00 UTC by stan
Modified: 2018-11-27 16:00 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-27 16:00:27 UTC
Type: Bug


Attachments (Terms of Use)

Description stan 2016-09-11 23:00:05 UTC
Description of problem:
I was updating a f25 rawhide to an f26 rawhide.  I updated dnf and its dependencies, and python and its dependencies.  When I tried to install a new kernel, dnf complained that libcurl.so.4 was missing a symbol, a long name starting with nghttpd2_... (I'm not in rawhide right now, so don't have name).
So there is no way to further update or downgrade or anything with dnf itself.  Download from koji, then use rpm to update directly seems the only way.


Version-Release number of selected component (if applicable):
curl-7.50.2-1.fc26
dnf-1.1.10-2.fc26

How reproducible:
I could only do it once, but I assume every time with these packages


Steps to Reproduce:
1.  Upgrade curl and dnf in rawhide to latest versions in repositories.
2.
3.

Actual results:
dnf will no longer start because of missing symbol in libcurl.so.4

Expected results:
dnf still functions


Additional info:

Maybe I'm doing something wrong, but I couldn't see how to work around this.  The packages all seemed to be installed correctly, and latest versions.

Comment 1 stan 2016-09-11 23:13:40 UTC
Here's the actual traceback.

Traceback (most recent call last):
  File "/usr/bin/dnf", line 57, in <module>
    from dnf.cli import main
  File "/usr/lib/python3.5/site-packages/dnf/__init__.py", line 31, in <module>
    import dnf.base
  File "/usr/lib/python3.5/site-packages/dnf/base.py", line 26, in <module>
    from dnf.comps import CompsQuery
  File "/usr/lib/python3.5/site-packages/dnf/comps.py", line 29, in <module>
    import dnf.util
  File "/usr/lib/python3.5/site-packages/dnf/util.py", line 31, in <module>
    import librepo
  File "/usr/lib64/python3.5/site-packages/librepo/__init__.py", line 1077, in <module>
    import librepo._librepo
ImportError: /lib64/libcurl.so.4: undefined symbol: nghttp2_session_callbacks_set_error_callback

Comment 2 stan 2016-09-15 16:03:53 UTC
It turns out that libcurl has a dependency on libnghttpd2.  When I downloaded the latest version of the nghttpd2 packages from koji, and updated them using rpm, the problem was fixed.  dnf is working as usual.  Now, onward to resolving all the dependency issues.

Closing this as worksforme.

Thanks for the fast response.

Comment 3 Paul Jakma 2017-08-12 10:46:52 UTC
This bug still exists. The reporter 'fixed' it by updating the dependency, however dnf or librepo /still/ is missing the dependency on the required version of nghttpd2.

I did a dnf upgrade the other day from F24 to F26. I was left with a half-upgraded system, where nghttpd2 had not been updated, but curl, dnf, etc. had been and I could no longer use dnf.

Please re-open!

Comment 4 stan 2017-08-12 13:52:33 UTC
Trying to reopen by changing status.

Comment 5 Jan Kurik 2017-08-15 06:56:56 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 6 Erik del Toro Streb 2018-09-15 15:21:54 UTC
To me happened exactly the same as to @PaulJakma (upgrade from version 24 to 26).

Comment 7 Ben Cotton 2018-11-27 14:40:13 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. 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 '27'.

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 27 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 8 Jaroslav Mracek 2018-11-27 16:00:27 UTC
I think that the problem is already fixed due to rebuild of library.


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