#28 Use upstream architecture names on Fedora 34+
Merged 6 months ago by churchyard. Opened 7 months ago by churchyard.
rpms/ churchyard/python3.9 upstream-archnames  into  master

@@ -1,83 +0,0 @@ 

- From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

- From: Petr Viktorin <pviktori@redhat.com>

- Date: Mon, 28 Aug 2017 17:16:46 +0200

- Subject: [PATCH] 00274: Upstream uses Debian-style architecture naming, change

-  to match Fedora

- MIME-Version: 1.0

- Content-Type: text/plain; charset=UTF-8

- Content-Transfer-Encoding: 8bit

- 

- Co-authored-by: Petr Viktorin <pviktori@redhat.com>

- Co-authored-by: Miro Hrončok <miro@hroncok.cz>

- Co-authored-by: Tomas Orsava <torsava@redhat.com>

- ---

-  config.sub   |  2 +-

-  configure.ac | 16 ++++++++--------

-  2 files changed, 9 insertions(+), 9 deletions(-)

- 

- diff --git a/config.sub b/config.sub

- index ba37cf99e2..52a9ec6662 100755

- --- a/config.sub

- +++ b/config.sub

- @@ -1042,7 +1042,7 @@ case $basic_machine in

-  		;;

-  	ppc64)	basic_machine=powerpc64-unknown

-  		;;

- -	ppc64-*) basic_machine=powerpc64-`echo "$basic_machine" | sed 's/^[^-]*-//'`

- +	ppc64-* | ppc64p7-*) basic_machine=powerpc64-`echo "$basic_machine" | sed 's/^[^-]*-//'`

-  		;;

-  	ppc64le | powerpc64little)

-  		basic_machine=powerpc64le-unknown

- diff --git a/configure.ac b/configure.ac

- index d60f05251a..6a95964657 100644

- --- a/configure.ac

- +++ b/configure.ac

- @@ -759,9 +759,9 @@ cat >> conftest.c <<EOF

-          alpha-linux-gnu

-  # elif defined(__ARM_EABI__) && defined(__ARM_PCS_VFP)

-  #  if defined(__ARMEL__)

- -        arm-linux-gnueabihf

- +        arm-linux-gnueabi

-  #  else

- -        armeb-linux-gnueabihf

- +        armeb-linux-gnueabi

-  #  endif

-  # elif defined(__ARM_EABI__) && !defined(__ARM_PCS_VFP)

-  #  if defined(__ARMEL__)

- @@ -801,7 +801,7 @@ cat >> conftest.c <<EOF

-  #  elif _MIPS_SIM == _ABIN32

-          mips64el-linux-gnuabin32

-  #  elif _MIPS_SIM == _ABI64

- -        mips64el-linux-gnuabi64

- +        mips64el-linux-gnu

-  #  else

-  #   error unknown platform triplet

-  #  endif

- @@ -811,22 +811,22 @@ cat >> conftest.c <<EOF

-  #  elif _MIPS_SIM == _ABIN32

-          mips64-linux-gnuabin32

-  #  elif _MIPS_SIM == _ABI64

- -        mips64-linux-gnuabi64

- +        mips64-linux-gnu

-  #  else

-  #   error unknown platform triplet

-  #  endif

-  # elif defined(__or1k__)

-          or1k-linux-gnu

-  # elif defined(__powerpc__) && defined(__SPE__)

- -        powerpc-linux-gnuspe

- +        ppc-linux-gnuspe

-  # elif defined(__powerpc64__)

-  #  if defined(__LITTLE_ENDIAN__)

- -        powerpc64le-linux-gnu

- +        ppc64le-linux-gnu

-  #  else

- -        powerpc64-linux-gnu

- +        ppc64-linux-gnu

-  #  endif

-  # elif defined(__powerpc__)

- -        powerpc-linux-gnu

- +        ppc-linux-gnu

-  # elif defined(__s390x__)

-          s390x-linux-gnu

-  # elif defined(__s390__)

00353-architecture-names-upstream-downstream.patch 00353-Original-names-for-architectures-with-different-name.patch
file renamed
+24 -11
@@ -4,15 +4,19 @@ 

  Subject: [PATCH] 00353: Original names for architectures with different names

   downstream

  

- Pythons in RHEL/Fedora use different names for some architectures

+ https://fedoraproject.org/wiki/Changes/Python_Upstream_Architecture_Names

+ 

+ Pythons in RHEL/Fedora used different names for some architectures

  than upstream and other distros (for example ppc64 vs. powerpc64).

- See patch 274.

- That means that an extension built with the default upstream settings

- (on other distro or as an manylinux wheel) cannot be found by Python

- on RHEL/Fedora because it has a different suffix.

- This patch adds the original names to importlib so Python is able

- to import extensions with an original architecture name in its

+ This was patched in patch 274, now it is sedded if %with legacy_archnames.

+ 

+ That meant that an extension built with the default upstream settings

+ (on other distro or as an manylinux wheel) could not been found by Python

+ on RHEL/Fedora because it had a different suffix.

+ This patch adds the legacy names to importlib so Python is able

+ to import extensions with a legacy architecture name in its

  file name.

+ It work both ways, so it support both %with and %without legacy_archnames.

  

  WARNING: This patch has no effect on Python built with bootstrap

  enabled because Python/importlib_external.h is not regenerated
@@ -21,11 +25,11 @@ 

  Python/importlib_external.h to this patch but it'd make rebasing

  a nightmare because it's basically a binary file.

  ---

-  Lib/importlib/_bootstrap_external.py | 31 ++++++++++++++++++++++++++--

-  1 file changed, 29 insertions(+), 2 deletions(-)

+  Lib/importlib/_bootstrap_external.py | 40 ++++++++++++++++++++++++++--

+  1 file changed, 38 insertions(+), 2 deletions(-)

  

  diff --git a/Lib/importlib/_bootstrap_external.py b/Lib/importlib/_bootstrap_external.py

- index 25a3f8c0e0..db4bb4d02d 100644

+ index 25a3f8c0e0..a2edbebc88 100644

  --- a/Lib/importlib/_bootstrap_external.py

  +++ b/Lib/importlib/_bootstrap_external.py

  @@ -1566,7 +1566,7 @@ def _get_supported_file_loaders():
@@ -46,7 +50,7 @@ 

       if builtin_os == 'nt':

           SOURCE_SUFFIXES.append('.pyw')

           if '_d.pyd' in EXTENSION_SUFFIXES:

- @@ -1635,3 +1635,30 @@ def _install(_bootstrap_module):

+ @@ -1635,3 +1635,39 @@ def _install(_bootstrap_module):

       supported_loaders = _get_supported_file_loaders()

       sys.path_hooks.extend([FileFinder.path_hook(*supported_loaders)])

       sys.meta_path.append(PathFinder)
@@ -61,6 +65,15 @@ 

  +    "-ppc-linux-gnuspe.": "-powerpc-linux-gnuspe.",

  +    "-ppc64-linux-gnu.": "-powerpc64-linux-gnu.",

  +    "-ppc64le-linux-gnu.": "-powerpc64le-linux-gnu.",

+ +    # The above, but the other way around:

+ +    "-arm-linux-gnueabihf.": "-arm-linux-gnueabi.",

+ +    "-armeb-linux-gnueabihf.": "-armeb-linux-gnueabi.",

+ +    "-mips64-linux-gnuabi64.": "-mips64-linux-gnu.",

+ +    "-mips64el-linux-gnuabi64.": "-mips64el-linux-gnu.",

+ +    "-powerpc-linux-gnu.": "-ppc-linux-gnu.",

+ +    "-powerpc-linux-gnuspe.": "-ppc-linux-gnuspe.",

+ +    "-powerpc64-linux-gnu.": "-ppc64-linux-gnu.",

+ +    "-powerpc64le-linux-gnu.": "-ppc64le-linux-gnu.",

  +}

  +

  +

file modified
+57 -21
@@ -17,7 +17,7 @@ 

  %global prerel rc2

  %global upstream_version %{general_version}%{?prerel}

  Version: %{general_version}%{?prerel:~%{prerel}}

- Release: 1%{?dist}

+ Release: 2%{?dist}

  License: Python

  

  
@@ -99,6 +99,19 @@ 

  %bcond_with valgrind

  %endif

  

+ # https://fedoraproject.org/wiki/Changes/Python_Upstream_Architecture_Names

+ # For a very long time we have converted "upstream architecture names" to "Fedora names".

+ # This made sense at the time, see https://github.com/pypa/manylinux/issues/687#issuecomment-666362947

+ # However, with manylinux wheels popularity growth, this is now a problem.

+ # Wheels built on a Linux that doesn't do this were not compatible with ours and vice versa.

+ # We now have a compatibility layer to workaround a problem,

+ # but we also no longer use the legacy arch names in Fedora 34+.

+ # This bcond controls the behavior. The defaults should be good for anybody.

+ %if 0%{?fedora} >= 34 || 0%{?rhel} >= 9

+ %bcond_with legacy_archnames

+ %else

+ %bcond_without legacy_archnames

+ %endif

  

  # =====================

  # General global macros
@@ -122,8 +135,21 @@ 

  %global LDVERSION_optimized %{pybasever}%{ABIFLAGS_optimized}

  %global LDVERSION_debug     %{pybasever}%{ABIFLAGS_debug}

  

- %global SOABI_optimized cpython-%{pyshortver}%{ABIFLAGS_optimized}-%{_arch}-linux%{_gnu}

- %global SOABI_debug     cpython-%{pyshortver}%{ABIFLAGS_debug}-%{_arch}-linux%{_gnu}

+ # When we use the upstream arch triplets, we convert them from the legacy ones

+ # This is reversed in prep when %%with legacy_archnames, so we keep both macros

+ %global platform_triplet_legacy %{_arch}-linux%{_gnu}

+ %global platform_triplet_upstream %{expand:%(echo %{platform_triplet_legacy} | sed -E \\

+     -e 's/^arm(eb)?-linux-gnueabi$/arm\\1-linux-gnueabihf/' \\

+     -e 's/^mips64(el)?-linux-gnu$/mips64\\1-linux-gnuabi64/' \\

+     -e 's/^ppc(64)?(le)?-linux-gnu$/powerpc\\1\\2-linux-gnu/')}

+ %if %{with legacy_archnames}

+ %global platform_triplet %{platform_triplet_legacy}

+ %else

+ %global platform_triplet %{platform_triplet_upstream}

+ %endif

+ 

+ %global SOABI_optimized cpython-%{pyshortver}%{ABIFLAGS_optimized}-%{platform_triplet}

+ %global SOABI_debug     cpython-%{pyshortver}%{ABIFLAGS_debug}-%{platform_triplet}

  

  # All bytecode files are in a __pycache__ subdirectory, with a name

  # reflecting the version of the bytecode.
@@ -287,10 +313,6 @@ 

  # Downstream only: Awaiting resources to work on upstream PEP

  Patch251: 00251-change-user-install-location.patch

  

- # 00274 # 1e9258f6e8f70e86d5130113d3eed22993cf3da9

- # Upstream uses Debian-style architecture naming, change to match Fedora

- Patch274: 00274-fix-arch-names.patch

- 

  # 00328 # 367fdcb5a075f083aea83ac174999272a8faf75c

  # Restore pyc to TIMESTAMP invalidation mode as default in rpmbuild

  #
@@ -305,18 +327,22 @@ 

  # Ideally, we should talk to upstream and explain why we don't want this

  Patch328: 00328-pyc-timestamp-invalidation-mode.patch

  

- # 00353 # f3c11e227c715450b3c1e945a5004e84cce41a58

+ # 00353 # ab4cc97b643cfe99f567e3a03e5617b507183771

  # Original names for architectures with different names downstream

  #

- # Pythons in RHEL/Fedora use different names for some architectures

+ # https://fedoraproject.org/wiki/Changes/Python_Upstream_Architecture_Names

+ #

+ # Pythons in RHEL/Fedora used different names for some architectures

  # than upstream and other distros (for example ppc64 vs. powerpc64).

- # See patch 274.

- # That means that an extension built with the default upstream settings

- # (on other distro or as an manylinux wheel) cannot be found by Python

- # on RHEL/Fedora because it has a different suffix.

- # This patch adds the original names to importlib so Python is able

- # to import extensions with an original architecture name in its

+ # This was patched in patch 274, now it is sedded if %%with legacy_archnames.

+ #

+ # That meant that an extension built with the default upstream settings

+ # (on other distro or as an manylinux wheel) could not been found by Python

+ # on RHEL/Fedora because it had a different suffix.

+ # This patch adds the legacy names to importlib so Python is able

+ # to import extensions with a legacy architecture name in its

  # file name.

+ # It work both ways, so it support both %%with and %%without legacy_archnames.

  #

  # WARNING: This patch has no effect on Python built with bootstrap

  # enabled because Python/importlib_external.h is not regenerated
@@ -324,7 +350,7 @@ 

  # upstream without this feature. It's possible to include

  # Python/importlib_external.h to this patch but it'd make rebasing

  # a nightmare because it's basically a binary file.

- Patch353: 00353-Original-names-for-architectures-with-different-name.patch

+ Patch353: 00353-architecture-names-upstream-downstream.patch

  

  # (New patches go here ^^^)

  #
@@ -683,6 +709,12 @@ 

  # (This is after patching, so that we can use patches directly from upstream)

  rm configure pyconfig.h.in

  

+ # When we use the legacy arch names, we need to change them in configure.ac

+ %if %{with legacy_archnames}

+ sed -i configure.ac \

+     -e 's/\b%{platform_triplet_upstream}\b/%{platform_triplet_legacy}/'

+ %endif

+ 

  

  # ======================================================

  # Configuring and building the code:
@@ -1381,8 +1413,8 @@ 

  # "Makefile" and the config-32/64.h file are needed by

  # distutils/sysconfig.py:_init_posix(), so we include them in the core

  # package, along with their parent directories (bug 531901):

- %dir %{pylibdir}/config-%{LDVERSION_optimized}-%{_arch}-linux%{_gnu}/

- %{pylibdir}/config-%{LDVERSION_optimized}-%{_arch}-linux%{_gnu}/Makefile

+ %dir %{pylibdir}/config-%{LDVERSION_optimized}-%{platform_triplet}/

+ %{pylibdir}/config-%{LDVERSION_optimized}-%{platform_triplet}/Makefile

  %dir %{_includedir}/python%{LDVERSION_optimized}/

  %{_includedir}/python%{LDVERSION_optimized}/%{_pyconfig_h}

  
@@ -1400,9 +1432,9 @@ 

  %{_bindir}/2to3

  %endif

  

- %{pylibdir}/config-%{LDVERSION_optimized}-%{_arch}-linux%{_gnu}/*

+ %{pylibdir}/config-%{LDVERSION_optimized}-%{platform_triplet}/*

  %if %{without flatpackage}

- %exclude %{pylibdir}/config-%{LDVERSION_optimized}-%{_arch}-linux%{_gnu}/Makefile

+ %exclude %{pylibdir}/config-%{LDVERSION_optimized}-%{platform_triplet}/Makefile

  %exclude %{_includedir}/python%{LDVERSION_optimized}/%{_pyconfig_h}

  %endif

  %{_includedir}/python%{LDVERSION_optimized}/*.h
@@ -1593,7 +1625,7 @@ 

  %{_libdir}/%{py_INSTSONAME_debug}

  

  # Analog of the -devel subpackage's files:

- %{pylibdir}/config-%{LDVERSION_debug}-%{_arch}-linux%{_gnu}

+ %{pylibdir}/config-%{LDVERSION_debug}-%{platform_triplet}

  %{_includedir}/python%{LDVERSION_debug}

  %{_bindir}/python%{LDVERSION_debug}-config

  %{_bindir}/python%{LDVERSION_debug}-*-config
@@ -1640,6 +1672,10 @@ 

  # ======================================================

  

  %changelog

+ * Fri Sep 25 2020 Miro Hrončok <mhroncok@redhat.com> - 3.9.0~rc2-2

+ - Use upstream architecture names on Fedora 34+

+ - https://fedoraproject.org/wiki/Changes/Python_Upstream_Architecture_Names

+ 

  * Thu Sep 17 2020 Miro Hrončok <mhroncok@redhat.com> - 3.9.0~rc2-1

  - Update to 3.9.0rc2

  

  • repalce patch 274 witch a sed call
  • update patch 353 to work both ways
  • add a new bcond to control the behavior: legacy_archnames

See also https://github.com/fedora-python/cpython/pull/16

This is completely untested. I don't even know if it builds. Scratch builds are running on f34 and f33.

Change proposal: https://fedoraproject.org/wiki/Changes/Python_Upstream_Architecture_Names

Name changes:

s/^arm(eb)?-linux-gnueabi$/arm\1-linux-gnueabihf/
s/^mips64(el)?-linux-gnu$/mips64\1-linux-gnuabi64/
s/^ppc(64)?(le)?-linux-gnu$/powerpc\1\2-linux-gnu/

It builds and files have the proper filenames:

Fedora 34:

$ rpm -qlp python3-libs-3.9.0~rc1-3.fc34.ppc64le.rpm | grep so$ | head
/usr/lib64/libpython3.so
/usr/lib64/python3.9/lib-dynload/_asyncio.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_bisect.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_blake2.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_bz2.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_cn.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_hk.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_iso2022.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_jp.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_kr.cpython-39-powerpc64le-linux-gnu.so

Fedora 33:

$ rpm -qlp python3-libs-3.9.0~rc1-3.fc33.ppc64le.rpm | grep so$ | head
/usr/lib64/libpython3.so
/usr/lib64/python3.9/lib-dynload/_asyncio.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_bisect.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_blake2.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_bz2.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_cn.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_hk.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_iso2022.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_jp.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_kr.cpython-39-ppc64le-linux-gnu.so

Fedora 34:

<mock-chroot> sh-5.0# rpm -ql python3-libs | grep so$ | head
/usr/lib64/libpython3.so
/usr/lib64/python3.9/lib-dynload/_asyncio.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_bisect.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_blake2.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_bz2.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_cn.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_hk.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_iso2022.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_jp.cpython-39-powerpc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_kr.cpython-39-powerpc64le-linux-gnu.so
<mock-chroot> sh-5.0# rpm -ql python3-numpy | grep so$ | head
/usr/lib64/python3.9/site-packages/numpy/core/_multiarray_tests.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/core/_multiarray_umath.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/core/_operand_flag_tests.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/core/_rational_tests.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/core/_struct_ufunc_tests.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/core/_umath_tests.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/fft/_pocketfft_internal.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/linalg/_umath_linalg.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/linalg/lapack_lite.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/random/_bounded_integers.cpython-39-ppc64le-linux-gnu.so
<mock-chroot> sh-5.0# python3 -c 'import numpy'
<mock-chroot> sh-5.0# pip install simple-manylinux-demo
WARNING: The directory '/builddir/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
WARNING: Running pip install with root privileges is generally not a good idea. Try `pip install --user` instead.
Collecting simple-manylinux-demo
  Downloading simple_manylinux_demo-1.0-cp39-cp39-manylinux2014_ppc64le.whl (17 kB)
Installing collected packages: simple-manylinux-demo
Successfully installed simple-manylinux-demo-1.0
<mock-chroot> sh-5.0# ls /usr/local/lib64/python3.9/site-packages/
dummyextension/                      simple_manylinux_demo-1.0.dist-info/ 
<mock-chroot> sh-5.0# ls /usr/local/lib64/python3.9/site-packages/dummyextension/
__init__.py  __pycache__  extension.cpython-39-powerpc64le-linux-gnu.so  tests
<mock-chroot> sh-5.0# python3 -c 'import dummyextension.extension'

Fedora 33:

<mock-chroot> sh-5.0# rpm -ql python3-libs | grep so$ | head
/usr/lib64/libpython3.so
/usr/lib64/python3.9/lib-dynload/_asyncio.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_bisect.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_blake2.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_bz2.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_cn.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_hk.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_iso2022.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_jp.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/lib-dynload/_codecs_kr.cpython-39-ppc64le-linux-gnu.so
<mock-chroot> sh-5.0# rpm -ql python3-numpy | grep so$ | head
/usr/lib64/python3.9/site-packages/numpy/core/_multiarray_tests.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/core/_multiarray_umath.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/core/_operand_flag_tests.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/core/_rational_tests.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/core/_struct_ufunc_tests.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/core/_umath_tests.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/fft/_pocketfft_internal.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/linalg/_umath_linalg.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/linalg/lapack_lite.cpython-39-ppc64le-linux-gnu.so
/usr/lib64/python3.9/site-packages/numpy/random/_bounded_integers.cpython-39-ppc64le-linux-gnu.so
<mock-chroot> sh-5.0# python3 -c 'import numpy'
<mock-chroot> sh-5.0# pip install simple-manylinux-demo
WARNING: The directory '/builddir/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
WARNING: Running pip install with root privileges is generally not a good idea. Try `pip install --user` instead.
Collecting simple-manylinux-demo
  Downloading simple_manylinux_demo-1.0-cp39-cp39-manylinux2014_ppc64le.whl (17 kB)
Installing collected packages: simple-manylinux-demo
Successfully installed simple-manylinux-demo-1.0
<mock-chroot> sh-5.0# ls /usr/local/lib64/python3.9/site-packages/dummyextension/
__init__.py  __pycache__  extension.cpython-39-powerpc64le-linux-gnu.so  tests
<mock-chroot> sh-5.0# python3 -c 'import dummyextension.extension'

As far as I can tell, this works.

Build succeeded.

At least a cauple packages might be affected:

rpm-specs/tre.spec
125:%attr(0755,root,root) %{python3_sitearch}/tre.cpython-%{python3_version_nodots}*-%{_arch}-linux%{_gnu}.so

rpm-specs/python-zstandard.spec
74:%{python3_sitearch}/_zstd_cffi.cpython-%{python3_version_nodots}-%{_arch}-linux%{_gnu}.so
75:%{python3_sitearch}/zstd.cpython-%{python3_version_nodots}-%{_arch}-linux%{_gnu}.so

rpm-specs/sword.spec
154:%{python3_sitearch}/_Sword.cpython-%{python3_version_nodots}*-%{_arch}-linux-gnu*.so

rpm-specs/cryptlib.spec
227:cp %{_builddir}/%{name}-%{version}/bindings/build/lib.linux-*%{python3_version}/cryptlib_py.cpython-3*-%{_arch}-linux-gnu.so %{buildroot}%{python3_sitelib}/cryptlib_py.so

rpm-specs/dlib.spec
24:ExcludeArch: ppc64le
119:%ifarch armv7l
120:{python3_sitearch}/%{name}.cpython-%{python3_version_nodots}-%{_arch}-linux-gnueabi.so
121:%else
122:%{python3_sitearch}/%{name}.cpython-%{python3_version_nodots}-%{_arch}-linux-gnu.so
%endif

Not sure if this shouldn't go trough a self contained change proposal.

mhroncok++ patch-- that's the way I like it :smile:

Do we want to test releases inter-compatibility? I mean that a wheel built on F33 will work on F34 and vice versa?

Welcome back :)

It should work but feel free to do more testing, that is always appreciated.

I am currently working on https://fedoraproject.org/wiki/Changes/Python_Upstream_Architecture_Names

rebased onto b369c23870769c9df5169df6726ab605e7ffb612

7 months ago

Build succeeded.

The change proposal looks very good to me. I'd change just one small thing: auditwheelauditwheel repair because auditwheel itself does nothing.

I'd also like to come with a solution for already identified incompatible packages and include it to the proposal with an example so readers will know what to do if their packages are affected. Do we want to define a macro for extensions' suffixes? For example rust has this is its specfile:

# Get the Rust triple for any arch.
%{lua: function rust_triple(arch)
  local abi = "gnu"
  if arch == "armv7hl" then
    arch = "armv7"
    abi = "gnueabihf"
  elseif arch == "ppc64" then
    arch = "powerpc64"
  elseif arch == "ppc64le" then
    arch = "powerpc64le"
  end

  return arch.."-unknown-linux-"..abi

end}

%global rust_triple %{lua: print(rust_triple(rpm.expand("%{_target_cpu}")))}

I think we can adapt it and provide it in our macros (complex for us, simple usage for others) or provide it as a snipet in the proposal (simple for us, complex for others).

I'm testing it on two ppc64le machines with Python 3.9.0~rc1-3.fc34 and 3.9.0~rc1-2.fc34 and I can confirm that:

  • upstream manylinux wheel of simple-manylinux-demo works well on both machines (current status is preserved)
  • when I create a wheel from simple-manylinux-demo on the first machine, it's installable and importable on the second machine and vice versa

I can keep mentioned machines for a couple of hours today if you can think about more possible tests for this.

Thank you!

I'd change just one small thing...

Please do.

I think we can adapt it and provide it in our macros...

We already have %{python3_platform} which expands to linux-ppc64le or linux-x86_64. We can definitively add %{python3_archlet} or %{python3_platform_triplet} or even %{python3_ext_suffix}. Lucky thing is that we can just ask %__python3 for the value:

$ python3 -c 'import sysconfig; print(sysconfig.get_config_var("EXT_SUFFIX"))'
.cpython-37m-ppc64le-linux-gnu.so

$ python3 -c 'import sysconfig; print(sysconfig.get_config_var("MULTIARCH"))'
ppc64le-linux-gnu

I can keep mentioned machines for a couple of hours today...

No need, we have a permanent access to ppc64le-test.fedorainfracloud.org.

I'd change just one small thing...

Please do.

Done.

I think we can adapt it and provide it in our macros...

We already have %{python3_platform} which expands to linux-ppc64le or linux-x86_64. We can definitively add %{python3_archlet} or %{python3_platform_triplet} or even %{python3_ext_suffix}. Lucky thing is that we can just ask %__python3 for the value:

```
$ python3 -c 'import sysconfig; print(sysconfig.get_config_var("EXT_SUFFIX"))'
.cpython-37m-ppc64le-linux-gnu.so

$ python3 -c 'import sysconfig; print(sysconfig.get_config_var("MULTIARCH"))'
ppc64le-linux-gnu

```

%{python3_platform} would be useful here in reverse order. I'd go with the second option (MULTIARCH) so for example it will be necessary to change

%{python3_sitearch}/%{name}.cpython-%{python3_version_nodots}-%{_arch}-linux-gnu.so

to

%{python3_sitearch}/%{name}.cpython-%{python3_version_nodots}-%{NEW_MACRO}.so

I'm tempted to use the first option (EXT_SUFFIX) because it contains all important info but it'd look weird to me that a file definition would end with macro with no explicit file extension.

%{python3_sitearch}/%{name}%{NEW_MACRO}

What do you think?

So with some useful names, that would be:

%{python3_sitearch}/%{name}.cpython-%{python3_version_nodots}-%{python3_multiarch}.so

Or:

%{python3_sitearch}/%{name}%{python3_ext_suffix}

I think that both have pros and cons (one is really mouthful but can be used at multiple places, the other one is a tad tricky to read in the spec but shorter, also solves the 37m vs 38 problem).

We can add both.

Build succeeded.

The change was approved.

@lbalhar final ack here before the merge?

I'll go implement the new macros.

Should I rename "archlet" to "platform_triplet" here to be consistent with the new macro?

Build succeeded.

Should I rename "archlet" to "platform_triplet" here to be consistent with the new macro?

Please do, for consistency and because archlet sounds bad and is not that intuitive.

Code looks good to me.

One nitpick, the patch name is 00353-Original-names-for-architectures-with-different-name.patch. What does original mean here? Legacy? If so, I'd consider renaming it. Other mentions of "original" were removed.

Should I rename "archlet" to "platform_triplet" here to be consistent with the new macro?

+1

Code looks good to me.

One nitpick, the patch name is 00353-Original-names-for-architectures-with-different-name.patch. What does original mean here? Legacy? If so, I'd consider renaming it. Other mentions of "original" were removed.

The full name should be 00353-Original-names-for-architectures-with-different-names-downstream.patch so either we can rename it to something else and shorter or we can add the last word which makes the name more meaningful IMHO.

The code looks good to me and I think we have already tested it enough. Good job.

rebased onto f749d5e0c984cc12edcfbc0dad72ff096d65bb18

6 months ago

Rebased up on rc2. Added a fixup commit with the discussed changes. Please ack, so I can squash.

Build succeeded.

ack from me, the diff looks good and the resulting packages have correctly named files

rebased onto 62490dd

6 months ago

Pull-Request has been merged by churchyard

6 months ago

Build succeeded.