Bug 1288729 - [epel7s390x] python-zmq SRPM does not build correctly on s390x
[epel7s390x] python-zmq SRPM does not build correctly on s390x
Status: NEW
Product: Fedora EPEL
Classification: Fedora
Component: python-zmq (Show other bugs)
epel7
s390x Linux
unspecified Severity medium
: ---
: ---
Assigned To: Thomas Spura
Fedora Extras Quality Assurance
:
Depends On:
Blocks: epel7s390x
  Show dependency treegraph
 
Reported: 2015-12-05 11:50 EST by IBM Bug Proxy
Modified: 2016-04-08 15:49 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
build.log (78.89 KB, application/octet-stream)
2015-12-05 11:50 EST, IBM Bug Proxy
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 133857 None None None Never

  None (edit)
Description IBM Bug Proxy 2015-12-05 11:50:30 EST

    
Comment 1 IBM Bug Proxy 2015-12-05 11:50:33 EST
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 11:50:40 EST
Created attachment 1102578 [details]
build.log
Comment 3 Thomas Spura 2015-12-07 04:37:14 EST
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 04:40:33 EST
------- Comment From hannsj_uhl@de.ibm.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

Note You need to log in before you can comment on or make changes to this bug.