Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1542728 - libiscsi uninstallable on Fedora Rawhide s390x
Summary: libiscsi uninstallable on Fedora Rawhide s390x
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libiscsi
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Paolo Bonzini
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2018-02-06 22:12 UTC by Richard W.M. Jones
Modified: 2018-03-23 19:50 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-23 19:50:00 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Richard W.M. Jones 2018-02-06 22:12:39 UTC 
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

See:
https://kojipkgs.fedoraproject.org//work/tasks/40/24760040/root.log
https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023

Version-Release number of selected component (if applicable):

qemu 2:2.11.0-4.fc28

What's strange here is that iscsi-initiator-utils has libiscsi.so.0
but this is missing .8 ... that makes no sense.
Comment 1 Cole Robinson 2018-02-06 22:42:29 UTC 
libiscsi.so.8 is from libiscsi package, which is different than iscsi-initiator-utils. For example:

https://koji.fedoraproject.org/koji/rpminfo?rpmID=11564058

So probably some mixup due to that
Comment 2 Richard W.M. Jones 2018-02-06 22:48:05 UTC 
Good point.  Looking at the recent libiscsi build on s390x:

https://koji.fedoraproject.org/koji/rpminfo?rpmID=11564085

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.
Comment 3 Richard W.M. Jones 2018-02-06 22:49:30 UTC 
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)
Comment 4 Richard W.M. Jones 2018-02-06 22:50:22 UTC 
Sorry, ignore previous 2 comments, Provides *is* being generated
and included in the package.
Comment 5 Mamoru TASAKA 2018-02-06 23:57:31 UTC 
Well, these dnf dependency problems should be read as:

> nothing provides libibverbs.so.1()(64bit) needed by libiscsi-1.18.0-1.fc28.s390x
So,
> 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:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1024409
Comment 6 Mamoru TASAKA 2018-02-07 00:03:35 UTC 
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.
Comment 7 Richard W.M. Jones 2018-02-07 00:11:27 UTC 
I see .. I've moved the bug to libiscsi according to comment 5 & 6.
Comment 8 Fedora End Of Life 2018-02-20 15:34:58 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.
Comment 9 Cole Robinson 2018-03-23 19:50:00 UTC 
Latest build of rdma-core is built for s390x, so I guess this is solved (but I don't have a machine to test)
Note You need to log in before you can comment on or make changes to this bug.