Source package wxPython-18.104.22.168-4 used by EPEL7 does not support ppc64le.
A newer version supporting this architecture should be used instead.
What is wrong with it? It looks like it successfully built on Jan 24:
We are trying to build epel 7 on ppc64le arch (ppc64 little endian).
Currently in koji epel 7 is built on ppc64 (ppc64 big endian) and if we keep same source version to build ppc64LE, then we have a problem because this wxPython-22.214.171.124-4 version is to old and does not support yet ppc64 little endian.
It seems to me that the first version supporting ppc64 little endian is wxPython-126.96.36.199-6 but I don't know if to fix ppc64le epel 7 build we need to push on epel 7 sources a newer version (188.8.131.52-6 or even newer) or if we need to backport a ppc64le patch on the older 184.108.40.206-4 version.
Ah. I missed the little endian vs big endian thing. Is there a ppc64le builder available somewhere?
not yet, I just have "not reachable" local environment but I can test what ever you need for you.
Or, alternatively, is there a mock config for ppc64le?
For epel 7 ppc64le, the environement is not usable as is but you have a ppc64le koji environment where you can do a scratch build if you need to test a patch.
Here are wxPython builds already done for ppc64le http://ppc.koji.fedoraproject.org/koji/packageinfo?packageID=8634
Hi, I built 220.127.116.11-8 on F22 PPC koji and it seems it built fine for both ppc64 and ppc64le:
Do you want to try building that SRPM on your local epel7 environment and make sure it builds? Then I'll bump the epel7 branch.
Hum , I am still have a problem with ppc64le arch but it should come from a dependency package and not from wxPython-18.104.22.168-8
building '_core_' extension
gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mcpu=power7 -mtune=power8 -D_GNU_SOURCE -fPIC -fwrapv -O3 -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mcpu=power7 -mtune=power8 -D_GNU_SOURCE -fPIC -fwrapv -O3 -fPIC -DSWIG_TYPE_TABLE=_wxPython_table -DSWIG_PYTHON_OUTPUT_TUPLE -DWXP_USE_THREAD=1 -UNDEBUG -Iinclude -Isrc -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/libdrm -I/usr/include/harfbuzz -I/usr/include/python2.7 -c src/helpers.cpp -o build-gtk2.unicode/temp.linux-ppc64le-2.7/src/helpers.o Unsupported architecture 'ppc64le' -O2 -pthread
gcc: error: Unsupported: No such file or directory
gcc: error: architecture: No such file or directory
gcc: error: 'ppc64le': No such file or directory
it seems the expended line gives to gcc contains "Unsupported architecture 'ppc64le' -O2 -pthread"
fixing it wxGTK now ...
and should be fixed with wxGTK-2.8.12-13.el7
Can you confirm wxPython now builds with the updated wxGTK? I am building wxPython-22.214.171.124-8.el7 now.
wxPython-126.96.36.199-8 builds correctly now with update of wxGTK-2.8.12-13 in my epel7 ppc64le local environment.