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

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

> s390 is being built for SLE-12, for example, on the internal SUSE build 
> system and SLE-12 is still supported. So if a customer wants to use Python 
> 3.10 in a SLE-12 s390 environment, why keep them from doing so?

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?

--

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

> s390 is being built for SLE-12, for example, on the internal SUSE build 
> system and SLE-12 is still supported. So if a customer wants to use Python 
> 3.10 in a SLE-12 s390 environment, why keep them from doing so?

I don't think that SuSE plans to provide Python 3.10 on SLE-12.

cc @mcepl

--
nosy: +mcepl

___
Python tracker 

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

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

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> This thread is an excellent example why ignoring platforms comes at a cost. 
> It will only get worse when are going to introduce platform and architecture 
> specific code for optimizations and features.

Which is purely hypothetical at the moment. You are arguing with something that 
might happen in the future but currently doesn't exist to justify the removal 
of 5 lines of preprocessor and autoconf "code".

You can still drop these lines in the future _if_ they happen to cause any 
headache. But that is currently not the case, so there isn't really a burden.

>> You can view test results any time by going to https://buildd.debian.org/ 
>> and searching for "pythonX.Y". So there is actually a CI for release builds.

> The site does not list a s390 builder. There is only a s390x builder.

s390 is being built for SLE-12, for example, on the internal SUSE build system 
and SLE-12 is still supported. So if a customer wants to use Python 3.10 in a 
SLE-12 s390 environment, why keep them from doing so?

In my experience some upstream projects make the mistake that they think they 
always know how users are using their software. But since there is no dedicated 
feedback channel, you have no means in knowing whether someone is building 
Python for a given architecture for their custom project. After all, there are 
source-only distributions like Gentoo, so you don't have to rely on any 
existing binary builds.

--

___
Python tracker 

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

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

[Christian Heimes]

Christian Heimes  added the comment:

> You don't need to support a platform. Just call it unsupported and ignore 
> issues if people report them unless they provide a patch themselves.

This thread is an excellent example why ignoring platforms comes at a cost. It 
will only get worse when are going to introduce platform and architecture 
specific code for optimizations and features.

> You can view test results any time by going to https://buildd.debian.org/ and 
> searching for "pythonX.Y". So there is actually a CI for release builds.

The site does not list a s390 builder. There is only a s390x builder.

--

___
Python tracker 

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

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

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> So IMO it's fine to remove the support.

You are not removing "support". You're just disallowing users to use the Python 
interpreter - which works perfectly fine on all architectures we have in 
current and previous releases - on Debian.

A few preprocessor macros plus some lines in a configure.ac aren't something 
that would qualify as platform support. There is no architecture-specific code 
and the Python interpreter is highly portable and just works whereever we build 
it in Debian (and openSUSE).

I would unterstand the reasoning of such a change if there was a swath of users 
filing bug reports about s390 and you just don't want to deal with that any 
longer. But that's not the case as far as I can see.

--

___
Python tracker 

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

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

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> The guidelines for platform support are explained in PEP 11 
> (https://www.python.org/dev/peps/pep-0011/#supporting-platforms). We don't 
> support platforms unless we have maintainers and CI (builtbots) in place for 
> the platform.

You don't need to support a platform. Just call it unsupported and ignore 
issues if people report them unless they provide a patch themselves.

FWIW, the Python interpreter has never caused any issues on any platform that 
we support in Debian. We are regularly building the latest upstream versions of 
all available Python interpreters thanks to the packaging work of Matthias 
Klose.

You can view test results any time by going to https://buildd.debian.org/ and 
searching for "pythonX.Y". So there is actually a CI for release builds.

--

___
Python tracker 

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

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

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

And to dig a bit further with a semi-official answer.

RHEL4 had standalone support for s390, while since RHEL5+ we've had only 
multilib support (64 bits kernel and possibility of s390 userspace packages).

RHEL7 that is the oldest currently supported RHEL OS, does have multilib 
support, meaning that 32 bit (s390) userspace packages are available for s390x 
booting on 64 bit kernel.

Although a later base python version for RHEL7 will not be shipped as we 
already have python2.7.5 and python3.8.6 supported there, which already builds 
for s390 for the aforementioned multilib support.

On Software Collections where we actually sometimes ship later Python versions, 
we compile only for 64 bits so the removal of the s390 pieces wouldn't pose an 
issue here.

Hence the only problem I can figure out from my analysis would be for users on 
s390x who would download the necessary 32bit libraries and dependencies from 
the repos and use the -m32 CFLAGS and LDFLAGS to get a 32 bits build.

--

___
Python tracker 

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

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

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

For RHEL7 which is the older OS that buildbots are still running, only the 
System Z architecture is supported. From the release notes [0]:

Note that Red Hat Enterprise Linux 7 supports IBM zEnterprise 196 hardware or 
later; IBM System z10 mainframe systems are no longer supported and will not 
boot Red Hat Enterprise Linux 7.

Also 32 (31 bits) in this case are only supported through virtualization with 
older OS's. So IMO it's fine to remove the support.

[0] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.0_release_notes/chap-red_hat_enterprise_linux-7.0_release_notes-architectures

--
nosy: +cstratak

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

Łukasz Langa:
> +1 from me. Whatever few users s390 still has, they can keep using Python 3.9 
> which is 5 years newer than the latest kernel they can use.

Nowadays, it became trivial to maintain downstream patches. It is easy to fork 
the Python Git repository and put your patches on top of it. Here it's only a 
matter of doing the maintenance upstream or not.


> Moving forward, s390 will be unambiguously unsupported as we cannot test 
> against this platform.  Unless we get a buildbot provided for this purpose, 
> as well as somebody willing to fix broken builds on that buildbot long-term, 
> it is what it is.

Wait. I would prefer to not have a buildbot worker unless there is a volunteer 
to fix all s390 specific issues. Otherwise, setting a buildbot worker will not 
solve any problem. I'm talking about build failures, test failures and issues 
on the worker directly.

--

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

> s390 is a 31-bit platform, not a 32-bit platform.

ARM64 only uses 48 bits for the address, but it uses 64-bit CPU words. Usually, 
we refer to an architecture by its CPU word, 32 or 64 bits. s390 uses 32-bit 
CPU words, no?

The Wikipedia article says:

"ESA/390 is arguably a 32-bit architecture; as with System/360, System/370, 
370-XA, and ESA/370, the general-purpose registers are 32 bits long, and the 
arithmetic instructions support 32-bit arithmetic. Only byte-addressable real 
memory (Central Storage) and Virtual Storage addressing is limited to 31 bits."

> s390 packages are still being built for SUSE Linux Enterprise 12 which is 
> still actively supported. I assume the same applies to RHEL LTS releases but 
> I can't verify that as I have no insight into RedHat's internal build system.

Red Hat maintains Fedora and RHEL, none is supporting s390, but both support 
s390x:

* https://fedoraproject.org/wiki/Architectures
* 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/architectures_considerations-in-adopting-rhel-8

Note: The correct name is Red Hat ;-)

--

___
Python tracker 

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

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

[David Edelsohn]

David Edelsohn  added the comment:

This has nothing to do with AIX.

This conversation should include Charalampos Stratakis, but I don't see him as 
an option for Nosy.

It probably is easy to add a s390 31-bit build to one of the buildbots.

--
nosy:  -aixto...@gmail.com

___
Python tracker 

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

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

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> Moving forward, s390 will be unambiguously unsupported as we cannot test 
> against this platform.  Unless we get a buildbot provided for this purpose, 
> as well as somebody willing to fix broken builds on that buildbot long-term, 
> it is what it is.

There is no s390-specifc code in Python in the first place, is there?

--

___
Python tracker 

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

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

[Łukasz Langa]

Łukasz Langa  added the comment:

+1 from me. Whatever few users s390 still has, they can keep using Python 3.9 
which is 5 years newer than the latest kernel they can use.

Moving forward, s390 will be unambiguously unsupported as we cannot test 
against this platform.  Unless we get a buildbot provided for this purpose, as 
well as somebody willing to fix broken builds on that buildbot long-term, it is 
what it is.

--
nosy: +lukasz.langa

___
Python tracker 

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

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

[Christian Heimes]

Christian Heimes  added the comment:

The guidelines for platform support are explained in PEP 11 
(https://www.python.org/dev/peps/pep-0011/#supporting-platforms). We don't 
support platforms unless we have maintainers and CI (builtbots) in place for 
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 32-bit s390 Linux support (s390-linux-gnu triplet)

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> I want to make it obvious that the platform has been dropped half a decade 
> ago.

That's a political statement, not a technical one.

The change has zero functional impact on the other targets. It just makes the 
use of Python in a potential s390 VM harder.

s390 packages are still being built for SUSE Linux Enterprise 12 which is still 
actively supported. I assume the same applies to RHEL LTS releases but I can't 
verify that as I have no insight into RedHat's internal build system.

--

___
Python tracker 

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

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

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

s390 is a 31-bit platform, not a 32-bit platform.

I also don't see what this change achieves other than making the use of Python 
3.10 on s390 harder.

It's not like the removal of support for non-threaded builds which actually 
saved quite some code:

> https://github.com/python/cpython/commit/a6a4dc816d68df04a7d592e0b6af8c7ecc4d4344

--

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

I created PR 24534 "Drop 32-bit Linux s390 platform support".

> We might also want to remove __alpha__, __hppa__, and __m68k__ at a later 
> point. DEC hasn't been around for a long time.

I would prefer to have one ticket per platform support removal.

--

___
Python tracker 

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

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

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +23321
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24534

___
Python tracker 

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

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

[STINNER Victor]

Change by STINNER Victor :


--
title: Remove s390 Linux support (s390-linux-gnu triplet) -> Remove 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