[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
John Paul Adrian Glaubitz added the comment: > Awesome, thanks! I'll give it a try later today or tomorrow. I have applied the patch and the problem seems to have been fixed. \o/ -- ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
John Paul Adrian Glaubitz added the comment: Awesome, thanks! I'll give it a try later today or tomorrow. -- ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
John Paul Adrian Glaubitz added the comment: Hi Serhiy! > The simple fix is to add UnicodeEncodeError to "except LookupError". But > there may be other places where we can get a similar error. They should be > fixed too. I would be very interested to test this as this issue currently blocks my use of offlineimap. Would you mind creating a proof-of-concept patch for me if it's not too much work? Thanks! -- ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
John Paul Adrian Glaubitz added the comment: I'm running into exactly this issue when using 'offlineimap' which is written in Python. -- nosy: +glaubitz ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ 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 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 <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove s390 support
John Paul Adrian Glaubitz added the comment: > I opened this ticket after a user told me that they grepped the source code > of Python, found the string "s390", and concluded that s390 is still > supported by us. Because one user was surprised by a few lines in configure.ac, the conclusion is to remove support for that architecture? That's a very odd justification. If it really just affects configure.ac, I don't really see a point in removing them. Even in OpenJDK we keep such unofficial architectures in configure.ac (with my OpenJDK upstream maintainer hat on). -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove s390 support
John Paul Adrian Glaubitz added the comment: That's an argument I have personally never heard before and I have been dealing with a lot of architecture support in many packages. FWIW, lots of upstream projects have targets which are officially supported and others which are there but not supported and that was never really a problem. As long as the architectures are being maintained in the Linux kernel, GCC, binutils and glibc, they can be considered usable and maintained. The m68k architecture for example has a very active and large community due to the popularity of retro computing. This has lead to efforts which will soon bring Rust support to M68k and the Amiga. I therefore don't really understand what you gain when you make it harder for downstreams to use Python. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove s390 support
John Paul Adrian Glaubitz added the comment: And, FWIW, I generally don't quite understand what the problem with old triplet definitions in configure.ac are. I assume they don't hurt anyone, do they? You never know what usecases your users have and as long as a code snippet doesn't interfere with other code, I don't see little point in removing it. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove s390 support
John Paul Adrian Glaubitz added the comment: I'm a Debian Developer and maintainer for multiple Debian Ports architectures. Please don't remove support for Alpha, HPPA, m68k, ia64, PowerPC, SuperH, SPARC as we're still maintaining these in Debian. Here are the latest build results for Python3.9 in Debian with build logs for all these architectures: > https://buildd.debian.org/status/package.php?p=python3.9&suite=sid There are no issues reported and we heavily rely on Python. -- nosy: +glaubitz ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
