Description of problem:
package qemu-block-iscsi-2:2.11.0-4.fc28.s390x requires libiscsi.so.8()(64bit), but none of the providers can be installed
Version-Release number of selected component (if applicable):
What's strange here is that iscsi-initiator-utils has libiscsi.so.0
but this is missing .8 ... that makes no sense.
libiscsi.so.8 is from libiscsi package, which is different than iscsi-initiator-utils. For example:
So probably some mixup due to that
Good point. Looking at the recent libiscsi build on s390x:
I can't see any libiscsi.so.8()(64bit) dependency being generated
by RPM. However the same is true also on x86_64, so I don't
understand what's going on right now.
Even stranger, the build log shows the Provides is generated:
Provides: config(libiscsi) = 1.18.0-1.fc28 libiscsi = 1.18.0-1.fc28 libiscsi(s390-64) = 1.18.0-1.fc28 libiscsi.so.8()(64bit)
Sorry, ignore previous 2 comments, Provides *is* being generated
and included in the package.
Well, these dnf dependency problems should be read as:
> nothing provides libibverbs.so.1()(64bit) needed by libiscsi-1.18.0-1.fc28.s390x
> package qemu-block-iscsi-2:2.11.0-4.fc28.s390x requires libiscsi.so.8()(64bit), but [as libiscsi.so.8()(64bit) is provided only by libiscsi-1.18.0-1.fc28.s390x but nothing provides libibverbs.so.1()(64bit) needed by libiscsi-1.18.0-1.fc28.s390x] none of the providers can be installed
So the problem is that "nothing provides libibverbs.so.1()(64bit) needed by libiscsi-1.18.0-1.fc28.s390x".
Actually on rawhide, on x86_64 libibverbs.so.1()(64bit) is provided by libibverbs, which is rebuild from rdma-core, but rdma-core is currently not built on s390x:
Previously libibverbs.so.1()(64bit) is provided by libibverbs-1.2.1-4.fc26, which is rebuilt from "libibverbs" srpm. Now libibverbs "srpm" is blocked on F-27 and above, and libibverbs binary rpm is rebuilt from rdma-core srpm, but rdma-core is not built on s390x.
I see .. I've moved the bug to libiscsi according to comment 5 & 6.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.
Latest build of rdma-core is built for s390x, so I guess this is solved (but I don't have a machine to test)