Description of problem: dnf can't be invoked in rawhide atm b/c of this $ dnf Traceback (most recent call last): File "/usr/bin/dnf", line 57, in <module> from dnf.cli import main File "/usr/lib/python3.8/site-packages/dnf/__init__.py", line 30, in <module> import dnf.base File "/usr/lib/python3.8/site-packages/dnf/base.py", line 29, in <module> import libdnf.transaction File "/usr/lib64/python3.8/site-packages/libdnf/__init__.py", line 12, in <module> from . import conf File "/usr/lib64/python3.8/site-packages/libdnf/conf.py", line 13, in <module> from . import _conf ImportError: /lib64/libsolvext.so.1: undefined symbol: rpmdbFStat Version-Release number of selected component (if applicable): $ rpm -q libsolv libsolv-0.7.12-1.fc33.x86_64 $ koji list-tagged f33 libsolv Build Tag Built by ---------------------------------------- -------------------- ---------------- libsolv-0.7.11-2.fc32 f33 releng libsolv-0.7.12-1.fc33 f33 ignatenkobrain $ rpm -q python3-libdnf python3-libdnf-0.47.0-2.fc33.x86_64 $ koji list-tagged f33 libdnf Build Tag Built by ---------------------------------------- -------------------- ---------------- libdnf-0.43.1-3.fc32 f33 adamwill libdnf-0.45.0-1.fc33 f33 amatej libdnf-0.47.0-1.fc33 f33 amatej libdnf-0.47.0-2.fc33 f33 besser82
I am running rawhide and have the same versions installed (libsolv-0.7.12-1.fc33.x86_64 and libdnf-0.47.0-2.fc33.x86_64) and everything works fine for me. I am able to use dnf without issues. Are you sure you don't have some other installations of libdnf or libsolv present? Possibly manual installations in /local for example? Are you able to reproduce it on a clean system?
I tried in the container and was able to verify that what you say is true: it worked fine while my rawhide workstation being borked. I had to go down the ldd & nm route to literally find the symbols in the libraries. The problem was that rpmdbFStat is defined in librpm, not libsolvext. I had rpm-4.15-1 which did not have the symbol defined and had to update to rpm-4.15.90 - that was fun doing the update by rpm and not by dnf :> I guess this dependency requirement should be updated in libsolv spec, right?
Yes I thinks so, lets move it to the libsolv component. Thanks for the investigation.
I think it would be good if RPM will start using symbols versioning: https://github.com/rpm-software-management/rpm/issues/1127 I'll work it around for the time being in libsolv…
Something fishy here, as this is what libtool versioning is supposed to solve: rpm 4.15 library version is 9.0.x and 4.16.x is 9.1.x, which means that something built against 4.15 will run on 4.16 as-is, but not vice versa. So the library versions should have stopped this from happening. But yeah, symbol versioning is a more powerful mechanism.
Hi, Any progress here? I just did 'dnf upgrade' in my Rawhide VM and `dnf' is broken now: $ dnf search rpm Traceback (most recent call last): File "/usr/bin/dnf", line 57, in <module> from dnf.cli import main File "/usr/lib/python3.8/site-packages/dnf/__init__.py", line 30, in <module> import dnf.base File "/usr/lib/python3.8/site-packages/dnf/base.py", line 29, in <module> import libdnf.transaction File "/usr/lib64/python3.8/site-packages/libdnf/__init__.py", line 12, in <module> from . import conf File "/usr/lib64/python3.8/site-packages/libdnf/conf.py", line 13, in <module> from . import _conf ImportError: /lib64/libsolvext.so.1: undefined symbol: rpmdbFStat $ rpm -q rpm rpm-4.15.1-2.fc32.1.x86_64 Given that I'll have to manually install the upgraded package now, can we maybe raise priority of this ticket? Also, why does it exist for over a month and "nobody" seems to complain? Does this happen in some corner-case only? Cheers, Phil
OK, I just died: $ rpm -U https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/r/rpm-4.16.0-0.beta1.1.fc33.1.x86_64.rpm https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/r/rpm-build-4.16.0-0.beta1.1.fc33.1.x86_64.rpm https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/r/rpm-libs-4.16.0-0.beta1.1.fc33.1.x86_64.rpm https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/r/rpm-plugin-selinux-4.16.0-0.beta1.1.fc33.1.x86_64.rpm https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/r/rpm-build-libs-4.16.0-0.beta1.1.fc33.1.x86_64.rpm https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/r/rpm-plugin-systemd-inhibit-4.16.0-0.beta1.1.fc33.1.x86_64.rpm https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/r/rpm-sign-libs-4.16.0-0.beta1.1.fc33.1.x86_64.rpm https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/p/python3-rpm-4.16.0-0.beta1.1.fc33.1.x86_64.rpm error: Failed dependencies: python(abi) = 3.9 is needed by python3-rpm-4.16.0-0.beta1.1.fc33.1.x86_64 python3.8dist(rpm) is needed by (installed) rebase-helper-0.21.0-1.fc33.noarch How do I get out of this again?
> Also, why does it exist for over a month and "nobody" seems to complain? Does this happen in some corner-case only? Yes, if you don't fully update your system. Anyhow, this is fixed in libsolv-0.7.14-2.fc33.
(In reply to Phil Sutter from comment #7) > OK, I just died: > > $ rpm -U > https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/ > Everything/x86_64/os/Packages/r/rpm-4.16.0-0.beta1.1.fc33.1.x86_64.rpm > https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/ > Everything/x86_64/os/Packages/r/rpm-build-4.16.0-0.beta1.1.fc33.1.x86_64.rpm > https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/ > Everything/x86_64/os/Packages/r/rpm-libs-4.16.0-0.beta1.1.fc33.1.x86_64.rpm > https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/ > Everything/x86_64/os/Packages/r/rpm-plugin-selinux-4.16.0-0.beta1.1.fc33.1. > x86_64.rpm > https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/ > Everything/x86_64/os/Packages/r/rpm-build-libs-4.16.0-0.beta1.1.fc33.1. > x86_64.rpm > https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/ > Everything/x86_64/os/Packages/r/rpm-plugin-systemd-inhibit-4.16.0-0.beta1.1. > fc33.1.x86_64.rpm > https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/ > Everything/x86_64/os/Packages/r/rpm-sign-libs-4.16.0-0.beta1.1.fc33.1.x86_64. > rpm > https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/ > Everything/x86_64/os/Packages/p/python3-rpm-4.16.0-0.beta1.1.fc33.1.x86_64. > rpm > error: Failed dependencies: > python(abi) = 3.9 is needed by python3-rpm-4.16.0-0.beta1.1.fc33.1.x86_64 > python3.8dist(rpm) is needed by (installed) > rebase-helper-0.21.0-1.fc33.noarch > > How do I get out of this again? you need to remove rebase-helper because that is failing to build and is just broken in rawhide.
(In reply to Igor Raits from comment #8) > > Also, why does it exist for over a month and "nobody" seems to complain? Does this happen in some corner-case only? > > Yes, if you don't fully update your system. All I did was call 'dnf upgrade'. If that breaks the box, there's a bug, no? > Anyhow, this is fixed in libsolv-0.7.14-2.fc33. Which you pushed less than three hours ago ... (In reply to Igor Raits from comment #9) > (In reply to Phil Sutter from comment #7) [...] > > error: Failed dependencies: > > python(abi) = 3.9 is needed by python3-rpm-4.16.0-0.beta1.1.fc33.1.x86_64 > > python3.8dist(rpm) is needed by (installed) > > rebase-helper-0.21.0-1.fc33.noarch > > > > How do I get out of this again? > > you need to remove rebase-helper because that is failing to build and is > just broken in rawhide. The critical point is python3-rpm requiring python3-3.9. I didn't try, but I guess manual python update without a usable dnf is a pretty masochistic experience, no?
Restored my box by downgrading libsolv: # rpm --oldpackage -U https://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/32/Everything/x86_64/os/Packages/l/libsolv-0.7.11-2.fc32.x86_64.rpm Essentially the problem was python3-IPy package blocking Python update and therefore quite a bunch of packages from being updated.