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 - [epel7s390x] python-zmq SRPM does not build correctly on s390x
Summary: [epel7s390x] python-zmq SRPM does not build correctly on s390x
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: python-zmq
Version: epel7
Hardware: s390x
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Thomas Spura
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: epel7s390x
TreeView+ depends on / blocked
 
Reported: 2015-12-05 16:50 UTC by IBM Bug Proxy
Modified: 2020-04-14 11:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-14 11:07:41 UTC
Type: ---
Embargoed:

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


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 133857 0 None None None 2019-04-29 21:15:20 UTC

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.
Note You need to log in before you can comment on or make changes to this bug.