[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[Florian Weimer]

Florian Weimer  added the comment:

The report/justification for the removal is simply incorrect. Linux still 
supports s390-*-linux-gnu in user mode. The GNU toolchain is maintained, and 
the glibc testsuite is in good shape. Some distributions still support s390 
(31-bit) applications. Others (Fedora 24 or later, for example) no longer do so.

I expect that 31-bit s390 Linux Python is really unusual these days, so 
removing it could still be fine, but lack of support from the GNU toolchain or 
the Linux kernel is not the correct justification for its removal.

If you have questions about the maintenance status of various parts of the GNU 
toolchain, please feel free to reach out to any of the GNU lists.

https://gcc.gnu.org/mailman/listinfo/gcc
https://sourceware.org/mailman/listinfo/binutils
https://sourceware.org/mailman/listinfo/libc-alpha

--
nosy: +fweimer

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset dec075754960dd85972ce5170df76e862f966132 by Jessica Clarke in 
branch 'master':
bpo-43179: Generalise alignment for optimised string routines (GH-24624)
https://github.com/python/cpython/commit/dec075754960dd85972ce5170df76e862f966132


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[Jessica Clarke]

Change by Jessica Clarke :


--
nosy: +jrtc27
nosy_count: 7.0 -> 8.0
pull_requests: +23855
pull_request: https://github.com/python/cpython/pull/24624

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

I think there is one productive result of this discussion which is this patch 
by Jessica Clark which gets rid of architecture-specific alignment code:

> https://github.com/python/cpython/pull/24624

Unfortunately, it has not seen any positive reviews yet. Getting this merged 
would remove some maintenance burden from the CPython maintainers.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[STINNER Victor]

STINNER Victor  added the comment:

https://bugs.python.org/issue43179 and 
https://mail.python.org/archives/list/python-...@python.org/thread/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/
 discussions didn't reach kind of consensus. I'm tired of these discussions, so 
I just closed my PR 24534. If someone wants to drop support of the 31-bit Linux 
s390 platform, please go ahead, feel free to copy my patch.

--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[Christian Heimes]

Christian Heimes  added the comment:

My offer still stands: If you can fulfill the requirements of PEP 11 for s390, 
then I'm fine with keeping the code for s390 around. Victor has a different 
opinion, so you have to contact the Steering Council and get their approval, 
too.

Our ticket system doesn't permit amending comments. Otherwise I would have 
clarified my comment. Also I used the words "might" and "at a later point" in 
my initial ticket.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[David Edelsohn]

David Edelsohn  added the comment:

Christian,

The Python Community Code of Conduct also states:

Being respectful of differing viewpoints and experiences.
Showing empathy towards other community members.

Various developers are passionate about this topic and the entire series of 
comments has been respectful, IMHO. I don't believe that it is helpful when you 
cherry-pick a rule from the code of conduct in response to someone providing 
additional evidence. That is intimidation and shutting down the conversation 
with an implicit threat.

You specifically mentioned m68k when you opened the issue.

This conversation feels very much that you and Victor have pre-determined an 
outcome and are not open to other points of view.  I and others have proposed 
compromises, but the response appears, at least to me, as shifting requirements.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[Christian Heimes]

Christian Heimes  added the comment:

For the last time: This ticket is solely about s390 platform. Please stop 
derailing this ticket with comments about unrelated platforms like m68k. 
I'm considering your diversion as "sustained disruption of online community 
discussions", https://www.python.org/psf/conduct/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

Oh, and LLVM is currently gaining support M68k which you consider "legacy":

> https://reviews.llvm.org/D95315

It might be a good idea to do some research first before making such statements.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> "Move support of legacy platforms/architectures outside Python"
> https://mail.python.org/archives/list/python-...@python.org/thread/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/

Motorola 68k isn't a 16-bit architecture, it's a 32-bit architecture.

Also, I am starting to get the feeling that you are trying to escalate a 
conflict here. None of the code that you are complaining about is hurting 
anyone. Yet, you think it is important to keep this discussion and ruining my 
day.

The fact that you take sides for OpenBSD but consider m68k legacy and 
unmaintained (which isn't correct at all - look at the kernel), shows that you 
are biased in this discussion.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[STINNER Victor]

STINNER Victor  added the comment:

I created a thread on python-dev:

"Move support of legacy platforms/architectures outside Python"
https://mail.python.org/archives/list/python-...@python.org/thread/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> But I don't see the benefit of annoying and discouraging users who want to 
> experiment with Python and with Linux on Z in 31 bit mode.

Fully agree.

> Yes, maintenance theoretically is a burden, but there have been no recent 
> issues that were specific to Linux on Z in 31 bit mode.

As I have mentioned before, the Python interpreter in general has been very 
very unproblematic on any platform. The only real issue that I am aware of is 
that the testsuite can get stuck on machines with a large number of CPUs (we're 
seeing that on our SPARC T5 in Debian).

> In fact, most of the original Linux on Z support issues that I opened were 
> endianness issues, which aren't ameliorated by removing 31 bit support.

And there is still MIPS-BE, PPC-BE, M68k, HPPA among other which are all 
big-endian.

> As others have expressed, deprecating 31 bit mode only removes the 
> configuration option with no other code simplification.

Exactly my point. If it removed a considerable amount of code, I would actually 
see a point. But just removing a few lines of autoconf or preprocessor code 
makes no differences from a maintainer's point of view.

> It seems that it would be better to leave the configuration alone until there 
> actually was an unresolved issue that motivated removal.

Jepp, fully agree.

> But I am not aware of any client requirement to continue the support. 

Sure. But free software shouldn't be solely about commercial customers. If 
someone wants to play with Python on the s390 emulator Hercules, for example, 
upstream projects shouldn't be keeping them from doing that.

> Leaving the 31 bit configuration unchanged is more about maintaining good 
> will among the volunteers who are interested in the platform.

Absolutely. And about not limiting choices when there is no technical argument 
for it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[Matej Cepl]

Matej Cepl  added the comment:

> Do you actually know someone who is actively interested in the usecase of 
> building a 32 bit python on an s390x system? Or do you know someone who owns 
> an s390 system?

Well, yes, I have just got it confirmed from our PM, SUSE has living and 
breathing (and what’s even more interesting, paying) clients using SLE-12 on 
s390 (i.e., s390x kernel with 32bit libraries). Of course, it doesn’t mean they 
are eager to run Python 3.10 in such configuration (how do you call such 
package? python3a so that “python3a” > “python39”?), we will have to evaluate 
with them what are their plans in the post-36 world with the modern Python 
there.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[David Edelsohn]

David Edelsohn  added the comment:

Victor: https://en.wikipedia.org/wiki/31-bit_computing :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[David Edelsohn]

David Edelsohn  added the comment:

I am not aware of significant use of 31 bit mode.

But I don't see the benefit of annoying and discouraging users who want to 
experiment with Python and with Linux on Z in 31 bit mode.  Yes, maintenance 
theoretically is a burden, but there have been no recent issues that were 
specific to Linux on Z in 31 bit mode.  In fact, most of the original Linux on 
Z support issues that I opened were endianness issues, which aren't ameliorated 
by removing 31 bit support.  As others have expressed, deprecating 31 bit mode 
only removes the configuration option with no other code simplification.

It seems that it would be better to leave the configuration alone until there 
actually was an unresolved issue that motivated removal.  But I am not aware of 
any client requirement to continue the support.  Leaving the 31 bit 
configuration unchanged is more about maintaining good will among the 
volunteers who are interested in the platform.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[STINNER Victor]

STINNER Victor  added the comment:

I'm not sure why people insists to say that it's 31 bit CPU, gcc-s390.txt shows 
that it uses a classic 32-bit ABI (32-bit long/size_t):

#define __SIZE_MAX__ 0xUL
#define __LONG_WIDTH__ 32

31-bit is a limit of the address space (memory), not the ALU.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[David Edelsohn]

David Edelsohn  added the comment:

gcc -dM -E - < /dev/null

--
Added file: https://bugs.python.org/file49818/gcc-s390x.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[David Edelsohn]

David Edelsohn  added the comment:

gcc -m31 -dM -E - < /dev/null

--
Added file: https://bugs.python.org/file49817/gcc-s390.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

> You do not need to support every platform. Just allow your users to use them.

This is kinda missing the point though. For example I've dealt a lot with the 
CPython codebase (and I'm also one of the Red Hat maintainers for RHEL and 
Fedora) and although I'm not a core developer, the codebase can be quite 
intimidating.

I agree that some lines of code do not seem like much but they add up. If noone 
actually has a use case here, removing them would be the best option overall 
just from a cognitive perspective.

Now I agree there are hobbyist's and so forth but you present an example, which 
is irrelevant to this case (m68k is not s390, right?). Do you actually know 
someone who is actively interested in the usecase of building a 32 bit python 
on an s390x system? Or do you know someone who owns an s390 system? Maybe 
someone who sends related fixes to another project?

You claim to speak for other maintainers, yet I'd like to actually hear their 
position on that. Feel free to add them to the nosy list. If the latest kernel 
is not even booting, I don't think many people actually care about this arch to 
at least keep it running.

On the other hand I do think though here that David would be the best person to 
speak about those use cases, as he is the most experienced here with the 
s390(x) architecture.

Now from my personal point of view, I don't mind actually keeping the support 
there, but it will never come up downstream for me, hence it won't affect me as 
Fedora doesn't build anymore for s390 (and already posted before the case for 
RHEL).

So again, do you know of this specific usecase, of someone either owning an 
s390 machine and compiling python, or actually utilizing an s390x machine and 
using the multilib packages to build a 32 bit python? If so, would you (or 
they) step up to fix related issues when they come up and assuming a buildbot 
would be set? Or would you know someone who would?

While your arguments make sense up to a point, claiming that others will step 
up or saying what others have done for different architectures, doesn't really 
help your arguments to hold.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> To get a platform supported by Python, we also need a volunteer to fix issues 
> specific to the 31 bit s390 platform: see PEP 11.

You do not need to support every platform. Just allow your users to use them.

If something breaks downstream on a certain platform, distribution maintainers 
are usually happy to send patches to fix these issues.

I think I can speak for myself here and many of my colleagues at SUSE, my 
fellow Debian Developers and the guys over at Gentoo who have also lots of 
talented folk who keep sending fixes for many upstream projects.

My colleague Andreas, for example, has contributed multiple fixes in cpython on 
m68k:

> https://github.com/python/cpython/search?q=Andreas+Schwab&type=commits

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[Christian Heimes]

Christian Heimes  added the comment:

David, could you please provide the output of "gcc -dM -E - < /dev/null" on 
s390x in 31 bit mode? I'm curious and would like to see the platform constants.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[STINNER Victor]

STINNER Victor  added the comment:

> I understand the issue is s390, not s390x.  I am offering that there already 
> is an s390x worker, so would it be sufficient to build and test Python in 31 
> bit mode on that worker as opposed to installing a complete s390 Debian 
> system?

To get a platform supported by Python, we also need a volunteer to fix issues 
specific to the 31 bit s390 platform: see PEP 11.

The policy for platform support evolved last years.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[David Edelsohn]

David Edelsohn  added the comment:

I understand the issue is s390, not s390x.  I am offering that there already is 
an s390x worker, so would it be sufficient to build and test Python in 31 bit 
mode on that worker as opposed to installing a complete s390 Debian system?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[Christian Heimes]

Christian Heimes  added the comment:

David, this bug is about s390, not s390x. The s390x platform is supported and 
tested.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[David Edelsohn]

David Edelsohn  added the comment:

I already am running a Debian s390x buildbot for Python.  Someone can adjust 
the rules for the buildbot to include a 31-bit builder.  The Debian buildbot 
has relatively few builder variants relative to the other s390x targets.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[Christian Heimes]

Christian Heimes  added the comment:

> That's not really the question. The question is whether an upstream project 
> should prevent downstreams from using unsupported target configurations and I 
> think the answer to that question is no.

We are not (actively) prevent unsupported target. We are merely removing unused 
code that we cannot test. Downstream is free to re-apply or maintain additional 
patches to enable platforms that we don't support. The rules for platform 
support are explained in PEP 11.

> Python is free software (as opposed to just open source software) and one of 
> the key features of free software is that you don't tell your users how they 
> use your software.

Free software doesn't mean free labor. Upstream is free to choose how we spend 
our time on the project or which patches we accept. For platform support we 
have (IMHO) reasonable rules for code: Python must compile, work, and pass a 
sufficient set of its test suite.

While "Python" software is free, the trademark, logo, and rights to the name 
"Python" are owned by the PSF. The trademark rules are also reasonable. On very 
few occasions the PSF has asked developers to choose a different name to avoid 
confusion. For example we asked the developer of a Python 2.8 fork to rename. 
The fork is now known a Tauthon. Platform compatibility patches are fine.

I see three ways to resolve the dispute:

1) You provide and support CI for s390, we keep the platform triplet. I would 
be even fine with an unstable buildbot or external CI that builds and runs out 
test suite regularly.
2) We remove the platform, you maintain downstream patches. The patch in 
GH-24534 is small and trivial.
3) You contact the Python Steering Council and request a decision. The SC is 
our elect government and makes final decisions.

I'm going to hold off and delay PR 24534 for at least two weeks to give you 
time to work on (1) or (3).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> What is the use case or benefit of building Python for 32-bit rather than 
> 64-bit?

That's not really the question. The question is whether an upstream project 
should prevent downstreams from using unsupported target configurations and I 
think the answer to that question is no.

Python is free software (as opposed to just open source software) and one of 
the key features of free software is that you don't tell your users how they 
use your software. Open source licenses that limit use cases of software are 
considered non-free by most if not all Linux distributions for that very reason.

There are valid reasons for preventing your software from being built on 
certain targets - such as the maintenance burden for architecture-specific code 
- but none of them apply here. A few lines of autoconf plus some preprocessor 
macros don't pose any burden and therefore the choice should be in favor of 
allowing downstreams to build unsupported configurations.

As for providing a CI: Setting up a CI machine for individual upstream projects 
is not a problem for big corporations like IBM or Intel, but it is certainly a 
hassle for individual open source developers and hobbyists. And while we 
(Debian Ports) have provided some CI machines for individual upstream projects 
such as GCC and LLVM, it should be sufficient for most upstream projects to 
rely on Debian's buildd infrastructure as we simply don't have the resources 
that big corporations have.

As for your original question: We still maintain multiple 32-bit ports in 
Debian, both as official and unofficial releases, and the same is done in other 
Linux distributions such as Gentoo, openSUSE, Void and others. Lots of 
hobbyists are pouring a lot of lifeblood and efforts into these ports such as 
m68k - which has still a surprisingly large user base thanks to retro-computing 
fans - which is why I am kindly asking you to not put up any obstacles into our 
ways.

As I said before, the Python interpreter is one of these excellent works of 
engineering that just work. Other interpreters/compilers such as OpenJDK, Ruby, 
Go or Rust require much more attention to keep them portable while the Python 
interpreter has never caused any issues which is something I am very grateful 
for, in particular given the fact how much other code directly depends on the 
Python interpreter to work (just think of the many package managers and other 
system tools written in Python).

So I think I can speak for Debian, Gentoo and many other downstream projects 
that it is important for many that it stays that way. Of course, that shouldn't 
Python development keep from moving forward and if the dependence on 
architecture-dependent code should increase at some point, we can still discuss 
this issue again and we will be more than happy to help with the porting 
efforts.

Thank You!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[STINNER Victor]

STINNER Victor  added the comment:

> builds a 31/32 bit Python 3.10 on an s390x system.

What is the use case or benefit of building Python for 32-bit rather than 
64-bit?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> Are you sure about that? It seems SLE-12 support s390x not s390. Maybe it's 
> multilib support in a similar manner that I've mentioned about RHEL7?

I work at SUSE. I looked at the internal build system. Debian also still build 
s390 multilib libraries, i.e. on zelenka.debian.org, I can still install 
"libc6-s390".

And I still don't understand why you are so keen at keeping people from 
building Python 3.10 on a certain architecture. You don't gain anything by 
removing these few lines of codes. But you risk at making someone unhappy who - 
for whatever reason - builds a 31/32 bit Python 3.10 on an s390x system.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)

[STINNER Victor]

Change by STINNER Victor :


--
title: Remove 32-bit s390 Linux support (s390-linux-gnu triplet) -> Remove 
31/32-bit s390 Linux support (s390-linux-gnu triplet)

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com