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 1288729

Summary: [epel7s390x] python-zmq SRPM does not build correctly on s390x
Product: [Fedora] Fedora EPEL Reporter: IBM Bug Proxy <bugproxy>
Component: python-zmqAssignee: Thomas Spura <tomspur>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: epel7CC: dan, denis.arnaud_fedora, dhorak, hannsj_uhl, jkachuck, mrunge, tomspur
Target Milestone: ---   
Target Release: ---   
Hardware: s390x   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-14 11:07:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1267648    
Attachments:
Description Flags
build.log none

Description IBM Bug Proxy 2015-12-05 16:50:30 UTC

Comment 1 IBM Bug Proxy 2015-12-05 16:50:33 UTC
The EPEL 7 SRPM for python-zmq from
https://dl.fedoraproject.org/pub/epel/7/SRPMS/p/python-zmq-14.3.1-1.el7.src.rpm
does not build correctly in Mock on s390x.

The following error is observed within build.log file: 

make sure Poller.poll timeout has the right units (milliseconds). ... FAIL
======================================================================
FAIL: make sure Poller.poll timeout has the right units (milliseconds).
----------------------------------------------------------------------
Traceback (most recent call last):
   File "/builddir/build/BUILD/pyzmq-14.3.1/zmq/tests/test_poll.py", line 164, in test_timeout
   self.assertTrue(toc-tic < 0.1)
AssertionError: False is not true
----------------------------------------------------------------------
Ran 122 tests in 14.838s
FAILED (SKIP=37, failures=1)

Comment 2 IBM Bug Proxy 2015-12-05 16:50:40 UTC
Created attachment 1102578 [details]
build.log

Comment 3 Thomas Spura 2015-12-07 09:37:14 UTC
Which zeromq was in use while rebuilding?
This [1] fix for x390x should be in zeromq-4, but it seems zeromq3-3 was used in python-zmq. So maybe switching back to the zeromq package would be best also for epel.

(CCing Denis as he has done the most recent zeromq-4 build on epel7 [2])


[1] https://github.com/zeromq/libzmq/commit/245c75aad6a58d8c5c4c3e2732b7a8edbc925dd8
[2] http://koji.fedoraproject.org/koji/buildinfo?buildID=645945

Comment 4 IBM Bug Proxy 2015-12-08 09:40:33 UTC
------- Comment From hannsj_uhl.com 2015-12-08 09:42 EDT-------
Comment from  Mohammad Zaman 2015-12-07 19:17:49 EST

Tested using zeromq-4.0.5-4.el7
https://kojipkgs.fedoraproject.org//packages/zeromq/4.0.5/4.el7/src/zeromq-4.0.5-4.el7.src.rpm
which built python-zmq successfully.

To successfully use the correct version of zeromq (4.0.5) the python-zmq spec file needs to be changed from:

BuildRequires:  zeromq3-devel
To:
BuildRequires:  zeromq-devel

Comment 5 Hanns-Joachim Uhl 2020-04-14 11:07:41 UTC
With no activity in this bug for years, I'm now closing this on the IBM side.
If the problem still needs to be addressed, please re-open or preferably open a
new bug.

Thanks.