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


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.