Bug 1271234 - [epel7s390x] uwsgi SRPM does not build correctly on s390x
Summary: [epel7s390x] uwsgi SRPM does not build correctly on s390x
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: uwsgi
Version: epel7
Hardware: s390x
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jorge Gallegos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: epel7s390x
TreeView+ depends on / blocked
 
Reported: 2015-10-13 12:51 UTC by IBM Bug Proxy
Modified: 2020-04-14 11:08 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-04-14 11:08:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
uwsgi-build-log (24.73 KB, text/plain)
2015-10-13 12:51 UTC, IBM Bug Proxy
no flags Details


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 131681 0 None None None 2019-02-21 09:28:16 UTC

Description IBM Bug Proxy 2015-10-13 12:51:49 UTC

Comment 1 IBM Bug Proxy 2015-10-13 12:51:50 UTC
The EPEL 7 SRPM for uwsgi-2.0.11.1-1 
https://dl.fedoraproject.org/pub/epel/7/SRPMS/u/uwsgi-2.0.11.1-1.el7.src.rpm
does not build correctly in Mock on s390x.

The build message is copied below, jvm cannot be found by the build:

############## end of uWSGI configuration #############
total build time: 25 seconds
*** uWSGI is ready, launch it with ./uwsgi ***
+ CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -march=z196 -mtune=zEC12 -Wno-unused-but-set-variable'
+ python uwsgiconfig.py --plugin plugins/systemd_logger fedora
using profile: buildconf/fedora.ini
detected include path: ['/usr/lib/gcc/s390x-redhat-linux/4.8.3/include', '/usr/local/include', '/usr/include']
*** uWSGI building and linking plugin plugins/systemd_logger ***
[gcc -pthread] systemd_logger_plugin.so
build time: 0 seconds
*** systemd_logger plugin built and available in systemd_logger_plugin.so ***
+ CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -march=z196 -mtune=zEC12 -Wno-unused-but-set-variable'
+ python uwsgiconfig.py --plugin plugins/jvm fedora
/usr/bin/ld: cannot find -ljvm
collect2: error: ld returned 1 exit status
using profile: buildconf/fedora.ini
detected include path: ['/usr/lib/gcc/s390x-redhat-linux/4.8.3/include', '/usr/local/include', '/usr/include']
*** uWSGI building and linking plugin plugins/jvm ***
[gcc -pthread] jvm_plugin.so
*** unable to build jvm plugin ***
ins/jvm ***
[gcc -pthread] jvm_plugin.so
*** unable to build jvm plugin ***

Comment 2 IBM Bug Proxy 2015-10-13 12:51:55 UTC
Created attachment 1082408 [details]
uwsgi-build-log

Comment 3 Jorge Gallegos 2016-01-08 04:54:39 UTC
Would love if you could provide me with the mock config you're using, I don't have an epel7 config here.

Comment 4 IBM Bug Proxy 2016-03-29 16:02:00 UTC
------- Comment From hannsj_uhl.com 2016-03-29 11:55 EDT-------
Comment from  Bryan Chan 2016-03-29 11:35:39 EDT

Sorry for the delay. Our mock config was a home-made config based on the EPEL 7 mock config for x86, however all the repos were replaced with internal ones that we had to populate manually by rebuilding all EPEL 7 SRPMs. This is because s390x is not yet a supported EPEL architecture.

I think the problem is reproducible with rpmbuild, outside the mock. So a mock config for s390x shouldn't be a prerequisite for fixing the issue.

Comment 5 IBM Bug Proxy 2017-03-20 06:30:29 UTC
------- Comment From urjawere.com 2017-03-20 02:28 EDT-------
Any Updates?

Comment 6 Fedora Admin XMLRPC Client 2020-04-06 19:34:13 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 7 Fedora Admin XMLRPC Client 2020-04-07 04:30:28 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 8 Hanns-Joachim Uhl 2020-04-14 11:08:24 UTC
With no real 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.