#10782 broken rawhide buildroot: dnf in buildSRPMfromSCM taks fails to find `libffi.so.8`
Closed: Fixed by kevin. Opened by decathorpe.

  • Describe the issue

As of ~about half an hour ago, rawhide builds have started to fail for me (and in koschei) because dnf is broken:

DEBUG util.py:444:  Traceback (most recent call last):
DEBUG util.py:444:    File "/usr/bin/dnf", line 61, in <module>
DEBUG util.py:444:      from dnf.cli import main
DEBUG util.py:444:    File "/usr/lib/python3.10/site-packages/dnf/__init__.py", line 30, in <module>
DEBUG util.py:444:      import dnf.base
DEBUG util.py:444:    File "/usr/lib/python3.10/site-packages/dnf/base.py", line 29, in <module>
DEBUG util.py:444:      import libdnf.transaction
DEBUG util.py:444:    File "/usr/lib64/python3.10/site-packages/libdnf/__init__.py", line 12, in <module>
DEBUG util.py:444:      from . import conf
DEBUG util.py:444:    File "/usr/lib64/python3.10/site-packages/libdnf/conf.py", line 13, in <module>
DEBUG util.py:444:      from . import _conf
DEBUG util.py:444:  ImportError: libffi.so.8: cannot open shared object file: No such file or directory
DEBUG util.py:597:  Child return code was: 1

I tried looking into which packages were built in that timeframe, but it doesn't look like there were any changes to dnf / libdnf / libffi in the last few hours. Maybe libffi was kicked out of the default buildroot for some reason, and dnf doesn't explicitly pull it in? Although I think python3 should already do that ...

  • When do you need this? (YYYY/MM/DD)

2022-05-07 :wink:

  • When is this no longer needed or useful? (YYYY/MM/DD)

Never.

  • If we cannot complete your request, what is the impact?

All koji builds for rawhide will fail (including from-dist-git scratch builds launched by koschei etc.).


This was also caught by MBI CI as can be seen here: https://mbi-artifacts.s3.eu-central-1.amazonaws.com/a270f095-0c79-4775-a4c4-790178457031/result.html
This started to happen after ghc9.4-9.4.0.20220501-1.fc37 build was tagged into f37 by bodhi.
ghc9.4-base subpackage provides libffi.so.8()(64bit) virtual package, so DNF can pick it up instead of proper libffi.
Example dependency change can be seen in Koschei: https://koschei.fedoraproject.org/build/12813323

Reported in Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2082827

I've untagged the package. Should be gone after the next newrepo.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Thanks! My failed build now succeeded.

Metadata