[Python-Dev] Python and Linux Standard Base
LSB (Linux Standard Base) is a set of standards defined from the Linux Foundation for linux distributions [0][1] with the latest version (LSB 5.0) released on 3rd of June, 2015. Python is also mentioned there but the information is horribly outdated [2]. For example here are the necessary modules that a python interpreter should include in an lsb compliant system [3] and the minimum python version should be 2.4.2. Also the python3 interpreter is never mentioned [4]. My question is, if there is any incentive to try and ask for modernization/amendment of the standards? I really doubt that any linux distro at that point can be considered lsb compliant at least from the python side of things. [0] https://en.wikipedia.org/wiki/Linux_Standard_Base [1] https://wiki.linuxfoundation.org/lsb/lsb-50 [2] https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Languages/LSB-Languages/python.html [3] https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Languages/LSB-Languages/pymodules.html [4] https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3677 -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and Linux Standard Base
- Original Message - > From: "Antoine Pitrou" > To: python-dev@python.org > Sent: Wednesday, June 27, 2018 3:42:53 PM > Subject: Re: [Python-Dev] Python and Linux Standard Base > > On Wed, 27 Jun 2018 09:18:24 -0400 (EDT) > Charalampos Stratakis wrote: > > > > My question is, if there is any incentive to try and ask for > > modernization/amendment of the standards? > > I really doubt that any linux distro at that point can be considered lsb > > compliant at least from the > > python side of things. > > One question: who maintains the LSB? > > The fact that the Python portion was never updated may hint that nobody > uses it... > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/cstratak%40redhat.com > That could definitely be the case here. I stumbled upon that when checking shebang requirements on Fedora and apparently every distro has a sort of meta package that adheres to those standards. In Fedora's case [0]. I don't have a good answer on who maintains it or even how compliant some distros are, but I was wondering if that topic came up beforehand and if any requirements were placed from either side. [0] https://src.fedoraproject.org/rpms/redhat-lsb/blob/master/f/redhat-lsb.spec#_419 -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] [RELEASED] Python 3.4.9 and Python 3.5.6 are now available
- Original Message - > From: "Michael" > To: "Larry Hastings" , python-dev@python.org > Sent: Sunday, August 5, 2018 8:57:40 PM > Subject: Re: [Python-Dev] [python-committers] [RELEASED] Python 3.4.9 and > Python 3.5.6 are now available > On 03/08/2018 03:22, Larry Hastings wrote: > > On 08/02/2018 07:17 AM, Victor Stinner wrote: > > > > 3.4.9 and 3.5.6 have no more known security vulnerabilities :-) > > > > > Well, not to be a complete pill, but... > > > https://bugs.python.org/issue17180 > > > https://bugs.python.org/issue17239 > > > https://bugs.python.org/issue19050 > > > Sadly, just because they're languishing on bpo doesn't mean they aren't > > valid > > security vulnerabilities. > > +1 - Sadly, not fixed after 5 years - Why? Because it isn't sexy, or fear for > breaking things? > Breaking things could be valid - when it is a feature/design change, but the > whole point of security fixes is because we believe the security > vulnerability is breakage. Not fixing it keeps everything that depends on it > (intentional or not) also broken. Any app that depends on 'broken' behavior > needs to be fixed - rather than let a known vulnerability go from 0-day to > 1825-day vulnerability (or is it 2000 already?) > Only read the discussion for 17180 - but it seems anything old does not get > fixed because it did not get fixed years ago. > my two cents! > On a side note: I have been trying to test python on different "enterprise" > distros of linux and am amazed to see Python2-2.7.5 as the 'standard'. > Rather disheartening for the all the good work that gets done. i.e., I am > amazed that CVE's like the ones fixed in 3.4.9 and 3.5.6 (and maybe > already/later in 2.7.X) do not motivate distributions to update to current > levels. A side note on your side note. Different distro's have different standards, use/customer cases to address etc. In enterprise distributions the usual scheme is that the version that you see is the minimum one and many fixes coming from upstream or the redistributor are incorporated on top of that version. Just check the package changelogs. :) CVE's do get fixed and there is actually cooperation with upstream on different levels in regards to those. And speaking here as one of the people doing that for one of the enterprise distros. > oh my - up to 4 cents! :) > Thanks for the work - I'll get to packaging them for AIX. > > //arry/ > > > ___ > > > Python-Dev mailing list Python-Dev@python.org > > https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: > > https://mail.python.org/mailman/options/python-dev/aixtools%40felt.demon.nl > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/cstratak%40redhat.com -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!
- Original Message - > From: "Serhiy Storchaka" > To: python-dev@python.org > Cc: python-committ...@python.org > Sent: Wednesday, December 19, 2018 10:14:41 AM > Subject: Re: [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x > bugfix release! > > 04.12.18 10:42, Ned Deily пише: > > A reminder: as previously announced, 3.6.8 is planned to be the last bugfix > > release of the 3.6 series. Python 3.6.0 was released on 2016-12-23, so by > > the time 3.6.8 is released, 3.6.x will have been in bugfix mode almost > > exactly 2 years. When a new feature release is made and enters "bugfix" > > mode, our policy has long been to continue to maintain the previous bugfix > > branch for at least one more release and then move that branch to > > "security fix only" mode. 3.7.0 (and 3.6.6) was released nearly six > > months ago and, with the release of 3.6.8, there will have been two > > additional 3.6.x bugfix releases since then. So, barring any showstopper > > issues that might arise, the upcoming 3.6.8rc1 is your last chance to make > > bugfix changes for 3.6.x. Following the successful release of 3.6.8, only > > sec > > urity fixes will be accepted for the 3.6 branch and future 3.6.x releases > > will be source-only and scheduled as needed; no further binary > > installers will be produced for 3.6. Refer to the Dev Guide > > sections and release PEPs linked below for more information. > > Can we revise our policy and prolong the bug fixing mode for 3.6? 3.6 is > the default Python in Ubuntu 18.04 LTS and RHEL 8. And due to several > important syntax features it can be a minimal required version for long > time. > That would actually be a great move, even if it doesn't happen, thanks for considering it. > I merged several PRs before releasing 3.6.8rc1, but there are still less > trivial bugfix PRs which need more time for reviewing, and there are > bugs for which no PR is created yet. There is also a number of > documentation PRs. I propose to allow backporting bugfixes to 3.6 if > they do not need excessive work, but stop to fix 3.6 only bugs. After > migrating to GitHab, backporting became less painful, most of backports > to 3.6 can be done automatically from master or from 3.7. > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/cstratak%40redhat.com > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: 3.7.3 Compile error on CentOS 7 (but 3.6.8 Compiles OK)
- Original Message - > From: "Victor Stinner" > To: python-dev@python.org > Sent: Tuesday, July 2, 2019 10:41:40 AM > Subject: [Python-Dev] Re: 3.7.3 Compile error on CentOS 7 (but 3.6.8 Compiles > OK) > > Hi, > > Le 02/07/2019 à 06:22, cso...@uol.com.br a écrit : > > I am trying to compile Python 3 on Centos7 and I am getting > > "ModuleNotFoundError: No module named '_ctypes'" > > I'm not sure that you are asking on the right mailing list. Anyway. > > Red Hat provides precompiled Python 3.6 for Centos 7: > https://www.softwarecollections.org/en/scls/rhscl/rh-python36/ > > About your error, you likely miss some header files, like libffi-devel: > > sudo yum install -y libffi-devel That issue has been reported some times before as well at bpo. Maybe providing a proper error message for the missing libffi headers would be good, as the current one is quite cryptic. > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/MERA4UA2KLZJVQ7IEMNYOTD7FCSZY24I/ > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GSEAOBVOUQ4NVZD2IXYFW44S4KPDCBNG/
[Python-Dev] Re: Why aren't we allowing the use of C11?
- Original Message - > From: "Mark Shannon" > To: "Python Dev" > Sent: Thursday, January 28, 2021 5:26:37 PM > Subject: [Python-Dev] Why aren't we allowing the use of C11? > > Hi everyone, > > PEP 7 says that C code should conform to C89 with a subset of C99 allowed. > It's 2021 and all the major compilers support C11 (ignoring the optional > parts). > > C11 has support for thread locals, static asserts, and anonymous structs > and unions. All useful features. > > Is there a good reason not to start using C11 now? > > Cheers, > Mark. > > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/PLXETSQE7PRFXBXN2QY6VNPKUTM6I7OD/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > Depends what platforms the python core developers are willing to support. Currently downstream on e.g. RHEL7 we compile versions of CPython under gcc 4.8.2 which does not support C11. In addition the manylinux2014 base image is also based on CentOS 7, which wouldn't support C11 as well. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PCOZN5NHNZ7HIANOKQQ7GQQMV3A3JF72/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Why aren't we allowing the use of C11?
- Original Message - > From: "Nathaniel Smith" > To: "Gregory P. Smith" > Cc: "Charalampos Stratakis" , "Python Dev" > > Sent: Friday, January 29, 2021 6:29:58 AM > Subject: Re: [Python-Dev] Re: Why aren't we allowing the use of C11? > > On Thu, Jan 28, 2021 at 9:03 PM Gregory P. Smith wrote: > > > > On Thu, Jan 28, 2021 at 10:52 AM Charalampos Stratakis > > wrote: > >> > >> > >> > >> - Original Message - > >> > From: "Mark Shannon" > >> > To: "Python Dev" > >> > Sent: Thursday, January 28, 2021 5:26:37 PM > >> > Subject: [Python-Dev] Why aren't we allowing the use of C11? > >> > > >> > Hi everyone, > >> > > >> > PEP 7 says that C code should conform to C89 with a subset of C99 > >> > allowed. > >> > It's 2021 and all the major compilers support C11 (ignoring the optional > >> > parts). > >> > > >> > C11 has support for thread locals, static asserts, and anonymous structs > >> > and unions. All useful features. > >> > > >> > Is there a good reason not to start using C11 now? > >> > > >> > Cheers, > >> > Mark. > >> > > >> > > >> > ___ > >> > Python-Dev mailing list -- python-dev@python.org > >> > To unsubscribe send an email to python-dev-le...@python.org > >> > https://mail.python.org/mailman3/lists/python-dev.python.org/ > >> > Message archived at > >> > https://mail.python.org/archives/list/python-dev@python.org/message/PLXETSQE7PRFXBXN2QY6VNPKUTM6I7OD/ > >> > Code of Conduct: http://python.org/psf/codeofconduct/ > >> > > >> > > >> > >> Depends what platforms the python core developers are willing to support. > >> > >> Currently downstream on e.g. RHEL7 we compile versions of CPython under > >> gcc 4.8.2 which does not support C11. > >> > >> In addition the manylinux2014 base image is also based on CentOS 7, which > >> wouldn't support C11 as well. > > > > > > I suspect this is the primary technical reason not to adopt C11 left. > > > > But aren't things like manylinux2014 defined by the contents of a centrally > > maintained docker container? > > If so (I'm not one who knows how wrong my guess likely is...), can we get > > those updated to include a more modern compiler so we can move on sooner > > than the deprecation of manylinux2014? > > RedHat maintains builds of gcc 8.2.1 for CentOS/RHEL 7, that have some > clever hacks to guarantee that the resulting binaries will work on > CentOS/RHEL 7: > https://www.softwarecollections.org/en/scls/rhscl/devtoolset-8/ > > I'm pretty sure that's what the manylinux2014 image is using. > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > > That is correct, Software Collections allow that (I'm also one of the maintainers of the Python collection), not sure though if indeed that's the case for manylinux2014. Apart from that though, in general Python is compatible with a wide variety of Platforms and operating systems. Are all those supported platforms compatible with C11 or later? RHEL7 is not (apart from using scl's) for example. If the standard changes that will also render useless a number of buildbots for Python's later branches. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EP2NGZY6RZVVU567HUHX5QFVPOST747T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Steering Council update for February
- Original Message - > From: "Chris Angelico" > To: "Python-Dev" > Sent: Wednesday, March 10, 2021 4:20:19 PM > Subject: [Python-Dev] Re: Steering Council update for February > > On Thu, Mar 11, 2021 at 12:16 AM Evpok Padding > wrote: > > > > Dear all, > > > > Apparently renaming a git branch to follow the general convention is now an > > unbearable outrage. > > It is NOT a general convention. It is a push by Microsoft (owners of > GitHub). Outside of GitHub, the git command still uses "master" as the > default name. > The git project is working on that for a long time and the default will be switched at some point: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006091126540.482@ZVAVAG-DN14RQO.ybpnyqbznva/#r Gitlab is also transitioning. It was changed in all the Fedora's repositories as well. > This is a *political* move made for *political* reasons, and has > consequences downstream. Why is it so important to cause actual real > problems for no reason other than to feel good about one insignificant > piece of language - and, as Steve pointed out, not even the most > significant one? > > Let's take ChainMap as an example. Would you propose renaming it in > Python 3.11? Would there be pushback against such a proposal? Things > in the Python standard library, when renamed, can have aliases to > ensure backward compatibility. Can you do that with a branch rename? > What plans are there to ensure that scripts and tooling can work on > both sides of such a rename? > On Fedora we use a git symbolic reference for the old branches. > Why has there been no discussion of the technical implications of this > change prior to now? > > ChrisA > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/4VZ7GM6EXNG5PKV3RBBQ7T2R43CJPE6L/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4Q3UJRCHXMHXAACMO4OVQ5RAQ53GW7BT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Thanks for your work in Python 3.10
Seconding that. I'd also like to add a big thank you to all the contributors for engaging through each release with the downstream Python redistributors as well, hearing us, working with us, helping us shape the future of a big part of the linux (and not only) ecosystem. On Tue, Oct 5, 2021 at 6:26 PM Pablo Galindo Salgado wrote: > Hi everyone, > > Now that 3.10.0 is finally released I wanted to take the time to thank you > all for all your fantastic > work this past year. Is because of the sum of all your fantastic work that > Python 3.10 is going to be > such a fantastic release. No matter if you have been working in fixing > bugs, adding features, > improving the documentation, reviewing contributor PRs, helping with the > infrastructure, helping with > the buildbot fleet, triaging bugs or discussing PEPs and features, your > work is tremendously appreciated: > you make a tremendous impact in Python and its community. > > I also wanted to make sure to thank again all the people that helped with > the release itself and with the > numerous release blockers and also for your patience when I had to delay > your feature to 3.11 or your > bugfix to 3.10.1. > > It has been a privilege to be able to release the result of your work to > the community! > > Thank you all, your work really makes a difference. > > Regards from sunny London, > Pablo Galindo Salgado > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/YIZ4XLYW25UA3UVQLQHHIEYUK77ZE5XE/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/OLLLFPUIRIPK32AXMSDFYLRLZC7J4BVM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Tests breakage with latest openssl (issue28689)
Hello, Escalating here an issue that seems that it should be tagged as blocker. Currently the latest version of openssl-1.1.0c breaks Python's test suite. The problematic commit was identified [0] and reverted [1] at openssl's upstream, however when running the test suite on a Fedora Rawhide machine, which includes the fix, the tests currently hang (not just failing like before). The issue, with some more details, is tracked here: https://bugs.python.org/issue28689 [0] https://github.com/openssl/openssl/issues/1903 [1] https://github.com/openssl/openssl/commit/beacb0f0c1ae7b0542fe053b95307f515b578eb7 Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tests breakage with latest openssl (issue28689)
Hi Christian and thanks for the fast reply, It's great to hear that the latest version is working fine. Do you have anymore details on the fix/breakage? The latest commit at Fedora's rawhide openssl package is at [0]. Is it missing something? [0] http://pkgs.fedoraproject.org/cgit/rpms/openssl.git/commit/?id=e443a79334446ac0dc14fdf7c062386f92bbc7a0 Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat - Original Message - From: "Christian Heimes" To: python-dev@python.org Sent: Monday, November 28, 2016 6:03:34 PM Subject: Re: [Python-Dev] Tests breakage with latest openssl (issue28689) On 2016-11-28 16:35, Charalampos Stratakis wrote: > Hello, > > Escalating here an issue that seems that it should be tagged as blocker. > > Currently the latest version of openssl-1.1.0c breaks Python's test suite. > > The problematic commit was identified [0] and reverted [1] at openssl's > upstream, however when running the test suite on a Fedora Rawhide machine, > which includes the fix, the tests currently hang (not just failing like > before). > > The issue, with some more details, is tracked here: > https://bugs.python.org/issue28689 > > [0] https://github.com/openssl/openssl/issues/1903 > [1] > https://github.com/openssl/openssl/commit/beacb0f0c1ae7b0542fe053b95307f515b578eb7 Hi Charalampos, Python's 3.6 and default (3.7) tests suite is passing with OpenSSL 1.1.0d-dev (OpenSSL_1_1_0-stable branch). Maybe your backport is missing a fix? Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/cstratak%40redhat.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have problem when building python3.5.1 rpm with default SPEC file
Hello, This is a distro specific issue so this list might not be the best for resolving that, you should contact your distro's package maintainers of python. For Fedora 25 we currently ship Python 3.5.2, which builds fine with this SPEC file [0], so maybe you could give this a try. [0] http://pkgs.fedoraproject.org/cgit/rpms/python3.git/tree/python3.spec?h=f25 Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat - Original Message - From: "Dahui Jiang" To: python-dev@python.org Sent: Thursday, January 19, 2017 12:54:16 PM Subject: [Python-Dev] Have problem when building python3.5.1 rpm with default SPEC file Hi all: I’m try to build a python rpm from source python3.5.1, and I use the spec file in the source tree. But the building is not success as print the following error: *** running build running build_ext error: [Errno 2] No such file or directory: 'Modules/Setup' error: Bad exit status from /var/tmp/rpm-tmp.DDm3jI (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.DDm3jI (%build) Regards Dahui ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/cstratak%40redhat.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have problem when building python3.5.1 rpm with default SPEC file
Hello Dahui, So I'll wear my downstream maintainer hat and try to elaborate on the situation that you are facing. Currently Red Hat does not ship Python 3 with rhel 7, so it is not supported. However package maintainers have created a SPEC file for python 3 that works for EPEL7 (aka centos7 or rhel7 etc). The name of the package is python34 [1] and you can install it by following the instructions at [0], it is at version 3.4.5 Currently there is no package for Python 3.5 in the EPEL repositories, you could request that at epel-devel mailing list [2], which is for these kind of queries, someone could be able to provide you with more info there. [0] https://admin.fedoraproject.org/pkgdb/package/rpms/python34/ [1] https://fedoraproject.org/wiki/EPEL [2] https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/ Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat - Original Message - From: "Dahui Jiang" To: "Charalampos Stratakis" Cc: python-dev@python.org Sent: Sunday, January 22, 2017 2:58:39 AM Subject: RE: [Python-Dev] Have problem when building python3.5.1 rpm with default SPEC file Hi Charalampos: Thank you very much for your help, and I have built python3.5.1 rpm on redhat7 successfully. But I find that there are quite a few content in SPEC file of fedora, and it seems that the file has been developed for a long time for patches and other supplementary, now that the SPEC file of fedora is open source, how about redhat's, how could I get it? Regards Dahui -----Original Message----- From: Charalampos Stratakis [mailto:cstra...@redhat.com] Sent: Friday, January 20, 2017 2:40 To: Dahui Jiang Cc: python-dev@python.org Subject: Re: [Python-Dev] Have problem when building python3.5.1 rpm with default SPEC file Hello, This is a distro specific issue so this list might not be the best for resolving that, you should contact your distro's package maintainers of python. For Fedora 25 we currently ship Python 3.5.2, which builds fine with this SPEC file [0], so maybe you could give this a try. [0] http://pkgs.fedoraproject.org/cgit/rpms/python3.git/tree/python3.spec?h=f25 Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat - Original Message - From: "Dahui Jiang" To: python-dev@python.org Sent: Thursday, January 19, 2017 12:54:16 PM Subject: [Python-Dev] Have problem when building python3.5.1 rpm with default SPEC file Hi all: I’m try to build a python rpm from source python3.5.1, and I use the spec file in the source tree. But the building is not success as print the following error: *** running build running build_ext error: [Errno 2] No such file or directory: 'Modules/Setup' error: Bad exit status from /var/tmp/rpm-tmp.DDm3jI (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.DDm3jI (%build) Regards Dahui ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/cstratak%40redhat.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help requested with Python 2.7 performance regression
PGO is not enabled in RHEL and Fedora. I did some initial testing for Fedora, however it increased the compilation time of the RPM by approximately two hours, so for the time being I left it out. Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat - Original Message - From: "Victor Stinner" To: "Nick Coghlan" Cc: "Barry Warsaw" , "Python-Dev" Sent: Friday, March 3, 2017 11:21:49 AM Subject: Re: [Python-Dev] Help requested with Python 2.7 performance regression 2017-03-03 8:27 GMT+01:00 Nick Coghlan : > Victor, do you know if you or anyone else has compared the RHEL/CentOS 7.x > binaries (Python 2.7.5 + patches, built with GCC 4.8.x) with the Fedora 25 > binaries (Python 2.7.13 + patches, built with GCC 6.3.x)? I didn't and I'm not aware of anyone who did that. It would be nice to run performance since this benchmark suite should now be much more reliable. By the way, I always forget to check if Fedora and RHEL compile Python using PGO. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/cstratak%40redhat.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help requested with Python 2.7 performance regression
And that is the reason I wanted to test this a bit more. However it adds a maintenance burden when fast fixes need to be applied (aka now that Fedora 26 alpha is being prepared). The build now due to the arm architecture and the huge test suite takes approximately 3 hours and 30 minutes. Increasing that by two hours is not something I would do during the development phase. On another note, RHEL's python does not have the PGO functionality backported to it. Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat - Original Message - From: "Victor Stinner" To: "Charalampos Stratakis" Cc: "Nick Coghlan" , "Barry Warsaw" , "Python-Dev" Sent: Friday, March 3, 2017 12:53:00 PM Subject: Re: [Python-Dev] Help requested with Python 2.7 performance regression 2017-03-03 12:18 GMT+01:00 Charalampos Stratakis : > PGO is not enabled in RHEL and Fedora. > > I did some initial testing for Fedora, however it increased the compilation > time of the RPM by approximately two hours, so for the time being I left it > out. Two hours in a *single* build server is very cheap compared to the 10-20% speedup on *all* computers using this PGO build, no? Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Blocking the main branch due to too many buildbots failing
On Sat, Jan 29, 2022 at 1:01 AM Pablo Galindo Salgado wrote: > Hi everyone, > > We have a huge amount of buildbots failing and seems to be related to > different issues > that keep piling up. To prevent this from going worse,* I am blocking the > main branch* > *until these issues are resolved.* > > Only release managers and the developer in residence will be able to merge > pull requests > until these issues are fixed. Please, ping me if you have a pull request > for fixing any of these > issues so we can merge. > > I apologize for the inconvenience. > > Thanks for your understanding, > > Regards from rainy London, > Pablo Galindo Salgado > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/HU2LH5MX44QZXZ36YS4SOG4ZUPT4E7QT/ > Code of Conduct: http://python.org/psf/codeofconduct/ > Noting here that I've recently added some CentOS Stream 9 buildbots to the fleet, however many are failing unfortunately. Since they are new additions and the failures haven't been ironed out, I've created a PR to move them to unstable as to not block anything, till things get sorted out: https://github.com/python/buildmaster-config/pull/308 -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HOY3K4NJGJCQEQ4FVWHHAZXCHD5VQRW2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Defining tiered platform support
its default compiler. I've already changed the config to some RHEL7 buildbots to use a later GCC version through the Developer Toolset 8, so GCC 8. The latest Python shipped through Red Hat Software Collection channels in RHEL7 is Python 3.8, built using Developer Toolset 9 (GCC 9). However, me and David Edelsohn are the only ones providing RHEL7 buildbots, so coordinating a change to all the configs to use a later GCC version should be easy enough. Another thing to consider is since PEP644 was implemented, it's not possible to compile the _hashlib and _ssl modules on RHEL7 from Python >= 3.10. RHEL7's official maintenance support phase ends at June 30, 2024, which can be considered its EOL (followed by the extended life cycle support, but that's not relevant for this discussion). Now I don't have a strong opinion here and I think targeting what manylinux2014 is targeting, is a good option till RHEL7 goes out of support, or even earlier than that should manylinux change the requirements. > Christian > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/5LDLSPQVYLVKNEJADOFBQQ3TKBCFEDEV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WUBX4B6I5R7EIYDPAVIYANS6ZQPHR64B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Fwd: Issue with Python Debug Libraries
- Original Message - > From: "Ankur Srivastava" > To: python-dev@python.org > Sent: Friday, September 6, 2019 7:56:38 AM > Subject: [Python-Dev] Fwd: Issue with Python Debug Libraries > > Hi All, > > I am facing some trouble in viewing python objects in a core dump file > through gdb it seems the python debug info is not working correctly on > red hat systems, Please help me out connecting with the right person > for this. > Hi Ankur, This list is for the upstream development of python. If you use the python interpreter packaged by any distribution you should go to the respective bug trackers and file a bug there. For Red Hat distros that would be https://bugzilla.redhat.com/ > > Thanks in advance. > > Ankur > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/JNERJQECBZCY5P55B6LVVA2ALMQGO4EL/ > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LXP44NLSMWO63FC45DGM67YAJNSCWS5V/
[Python-Dev] Re: How do I install Python 3.8.0 on Linux (not possible? no one is doing this?)
- Original Message - > From: devloca...@gmail.com > To: python-dev@python.org > Sent: Wednesday, October 16, 2019 1:35:17 AM > Subject: [Python-Dev] How do I install Python 3.8.0 on Linux (not possible? > no one is doing this?) > > I cannot get Python 3.8.0 installed on Linux ( RHEL 8 / CentOS 8). > > It's not available in any package repo. When I try to build from source, > there are dependencies missing (3), that I cannot find anywhere. > > More info here: (I did not want to write this up twice) > > https://www.reddit.com/r/Python/comments/digewe/python_38_not_possible_to_install_on_linux_why/ > > The latest version of Python 3 available to me on Linux was released over > three years ago ( Python 3.6.0 ), I don't understand why. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/ZP3RSTYWBCPBEYNUGH2THA5OVRLYO3RX/ > Code of Conduct: http://python.org/psf/codeofconduct/ > Hello, I am sorry for your experience. I can understand it can be frustrating, however I find the overall condescending tone of the email and the reddit thread a little bit unnecessary. So I'll try and shed some light here as one of the folks maintaining Python for RHEL and Fedora. For RHEL8 and CentOS 8 most of the development headers were moved to a different repository. You will need to enable it first and then you can do dnf builddep: On CentOS 8 it's the Powertools repo: yum config-manager --set-enabled PowerTools On RHEL8 it's the coder ready builder repo: subscription-manager repos --enable "codeready-builder-for-rhel-8-*-rpms" Now as numerous other have pointed out, RHEL is a stable slow moving distribution, subject to various procedures and rigorous testing. Every package change needs to go through a long chain which ensures that the package will work flawlessly with the rest of the distribution. Unfortunately we can't just dump a new interpreter in the system and expect things to work, this applies for many other distros as well since python is at the moment really intertwined with the linux ecosystem. You can read this comment from LWN which does a far better job explaining what is happening than I: https://lwn.net/Articles/796301/ Also I would advise against installing Python 3.8 systemwide, as this will most possibly break the operating system, since many packages depend on it and will be incompatible with the new release, dnf being only one example. However you can install it on whatever other location you would like in the system and develop on top of it (be sure to use the --prefix= flag during configure). A rolling distribution might be a better fit for you. However if you use Fedora we already package Python 3.8 as the python38 package. The system interpreter will be updated to 3.8 with Fedora 32. Finally as mentioned by others, this would be a better fit for python-list, as this mailing list is mostly used to the development of cpython itself. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PRICMR3LPGJGYAVFJCMOTKGZQDRZW2MH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP for libffi + _ctypes
- Original Message - > From: "Tom Kacvinsky" > To: python-dev@python.org > Sent: Thursday, October 17, 2019 4:26:39 PM > Subject: [Python-Dev] Re: PEP for libffi + _ctypes > > > > > -Original Message- > > From: Victor Stinner > > Sent: Thursday, October 17, 2019 10:06 AM > > To: Kacvinsky, Tom > > Cc: python-dev@python.org > > Subject: Re: [Python-Dev] PEP for libffi + _ctypes > > > > Hi, > > > > Our bundled copy of libffi has been removed from Python 3.7 by this change > > which should explain the rationale: > > https://bugs.python.org/issue27979 > > Thanks. > > > > > Not all Python changes need a PEP. For Windows builds, we provide prebuilt > > binaries of our dependencies: > > https://github.com/python/cpython-source-deps/blob/master/README.rst > > > > I am OK with Windows, it is Linux, as below. > > > My notes on Python dependencies: > > https://pythondev.readthedocs.io/files.html > > > > Again, thanks for this. > > > > > > we support older Linux distributions that don't have libffi > > > > I'm curious, which old Linux distributions don't have libffi? Usually, > > libffi is > > preinstalled on Linux, only the development header files are required (a > > package with a name like "libffi-devel"). Can't you install libffi on these > > old > > distributions? IMHO libffi installation should not be the Python problem, > > bundling a library copy in Python is causing more issues compared to > > advantages. > > RHEL/CentOS 5 come to mind. We don't want to get into the use case where > we have to have customers install libffi as we try to minimize the hassles > our > customers might have to go through for installing and using our product. > > Tom > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/A34TOQS5XBMWO5Q7AOPXDFEI3DDXAUBP/ > Code of Conduct: http://python.org/psf/codeofconduct/ > Well RHEL5 doesn't include libffi in its default repos, however you can find it from the EPEL5 repositories. Also available directly through the fedora build system [0]. It seems that you are asking for libffi to continue to be bundled with cpython upstream, however if you are compiling python from source, why is it a hassle to install an rpm from the EPEL repos? Is it some form of installer/scripts/automation? [0] https://koji.fedoraproject.org/koji/buildinfo?buildID=108124 -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ISYRGFJWYXNEPWS6S25URB3U2PPVFBT3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Multiple reference leaks in master
- Original Message - > From: "Pablo Galindo Salgado" > To: "Python Dev" > Sent: Tuesday, December 3, 2019 10:14:01 PM > Subject: [Python-Dev] Multiple reference leaks in master > > Hi, > > Me (and Victor) have not been able to attend the buildbots for a while > unfortunately and today > I was checking them out after some fixes to the SSL tests and sadly the > refleaks buildbots have many > independent issues. At least these tests are failing due to reference leaks: > > test__xxsubinterpreters, test_atexit, test_capi, test_httpservers, > test_threading > > I am trying to slowly fix them but finding them and debugging often takes > several hours per leak. I was tracking them > in https://bugs.python.org/issue38962 until I discover that there are > multiple sources of leaks so I may open more issues. > > Please, when you merge a PR, take a look at the buildbots (especially the > refleak buildbots that do not report still to the PR > in case of failure) so the issues don't keep piling up, as multiple refleaks > together are much difficult to deal with. > > Thanks, everyone! > > Regards from cloudy London, > Pablo Galindo Salgado > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/6DWAFYZGH3X34VJHSOUVCEAHLZ4KZNPQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > Also noting here that the reference leaks builds are triggered once a day so many times it's not possible to find the commit that triggered a leak through the web ui of buildbot. In this case it's good to also check the previous builds of the same worker to figure out what changed. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZP25JNHP5R5VIAQFYXTWANXSETW4V6MC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Handling cross-distro variations when running autoreconf?
- Original Message - > From: "Nick Coghlan" > To: "python-dev" > Sent: Sunday, December 8, 2019 2:58:24 PM > Subject: [Python-Dev] Handling cross-distro variations when running > autoreconf? > > Hi folks, > > While reviewing https://github.com/python/cpython/pull/17303/files, I > noticed that the configure script update removed the options for > `--runstatedir`. Those options appear to come from a Debian patch that > other distros don't yet have: > https://sources.debian.org/patches/autoconf/2.69-11/add-runstatedir.patch/ > > Since I use Fedora, running autoreconf locally on the review branch > didn't add those options back, but did add in various macros related > to Fedora's modular build system (we don't use those macros explicitly > ourselves, but presumably some of the m4 macros we do use include them > in their expansions when run on Fedora systems, so aclocal picked them > up). > > Does anyone have any recommendations for dealing with this? My current > plan is to revert back to the configure script from master, run > autoreconf, and then use `git add -p` to only add in the desired > changes, leaving everything else as it was on master. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/L3EBGBFEE5WHSHZOWKUWX2NR4RZOWLMK/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > Yep I've seen many PR's having the same things, basically the runstatedir options just keep appearing and disappearing on the cpython repo. I think 'git add -p' is the most sensible option and maybe a warning on the dev guide to check the configure when running autoreconf. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CPPUR2MCGSS674CIMVLEGIRZ7HPJ2SFD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Remove COUNT_ALLOCS special build
- Original Message - > From: "Victor Stinner" > To: "Python Dev" > Sent: Wednesday, January 29, 2020 10:57:02 PM > Subject: [Python-Dev] Remove COUNT_ALLOCS special build > > Hi, > > I would like to confirm that there is no user of the Python > "COUNT_ALLOCS" special build, because I plan to remove it from Python > 3.9. If you use it, please raise your hand and explain why other debug > tools don't fit your specific use case. > > -- > > I'm always annoyed by "#ifdef COUNT_ALLOCS" code which is common in > code related to reference counting (object.h, object.c, typeobject.c). > It makes the code harder to read and harder to maintain. It's a 27 > years old feature which always required to rebuild Python with > COUNT_ALLOCS macro defined. In clear, you have to know about the > feature and build your own Python binary to use it. > > COUNT_ALLOCS was used for 6 years (2010-2015) in the debug build of > Python of the Fedora package. Sadly, C extensions provided by Fedora > are only built in release mode, and so cannot be used by the debug > build. python2.7-debug requires to rebuild all C extensions in debug > mode. IMHO nobody ever used python2.7-debug to debug real > applications. > > The feature was added to Fedora debug build by Dave Malcolm in 2010 to > help him to debug memory leaks. Later, he wrote: "I don't think this > patch ever really bought us much, and it sounds like there are better > tools for this now, so feel free to drop the COUNT_ALLOC patches." So > the feature was dropped from Python 3 package in 2015. > > I never ever used this feature. I consider that there are now way > better tools to debug memory leaks in Python 3, like tracemalloc and > multiple tools based on gc.get_objects(). > > I failed to find any user of COUNT_ALLOCS on the Internet. I'm quite > sure that many core developers never heard about this special build. > > I proposed https://bugs.python.org/issue39489 and > https://github.com/python/cpython/pull/18259 to remove the feature. My > PR basically only removes code: > > 34 files changed, 24 insertions(+), 470 deletions(-) > > Do you see any reason to keep COUNT_ALLOCS in Python 3.9? If yes, > please elaborate :-) > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/YEY2TZIWC6HGMM5Y3QKWKMEBT5Y5C324/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > I've never used this feature and it was quite the hassle to maintain those patches downstream, so in my biased opinion, I would welcome the removal. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4BI64IXNZMJGXNHOA34UJ35V74IGJNZF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Unpacking native bools in the struct module: Is Python relying on undefined behavior?
Hello folks,
I recently observed a failure on the s390x fedora rawhide buildbot, on the
clang builds, when clang got updated to version 10:
https://bugs.python.org/issue39689
The call:
struct.unpack('>?', b'\xf0')
means to unpack a "native bool", i.e. native size and alignment. Internally,
this does:
static PyObject *
nu_bool(const char *p, const formatdef *f)
{
_Bool x;
memcpy((char *)&x, p, sizeof x);
return PyBool_FromLong(x != 0);
}
i.e., copies "sizeof x" (1 byte) of memory to a temporary buffer x, and then
treats that as _Bool.
While I don't have access to the C standard, I believe it says that assignment
of a true value to _Bool can coerce to a unique "true" value. It seems that if
a char doesn't have the exact bit pattern for true or false, casting to _Bool
is undefined behavior. Is that correct?
Clang 10 on s390x seems to take advantage of this: it probably only looks at
the last bit(s) so a _Bool with a bit pattern of 0xf0 turns out false.
But the tests assume that 0xf0 should unpack to True.
--
Regards,
Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/O742VLCYX2AE3RWQK5RBQ3BGUOHESLF5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change
~Ethan~ > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/PJPZBLXM3ERJP66O5IEZYLRSBDN66HI5/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > Without having followed the discussion (I just read that specific message), and with the danger of sounding arrogant and wrong, how can you equate a commit message with such a strong wording regarding betrayal, especially when the intention seems to be about being more inclusive? Why is that this change, evokes such strong emotions? When something doesn't practically affect you one way or another and the end-result would be to be more open and inclusive as a community I believe it should be welcomed. You might disagree with the premise but that doesn't make the change and the results any less valid. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DND67BYURZRKSKUFEVAYHCCRF27NRRJB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [python-committers] Resignation from Stefan Krah
- Original Message - > From: "Antoine Pitrou" > To: python-dev@python.org > Sent: Friday, October 9, 2020 4:02:51 PM > Subject: [Python-Dev] Re: [python-committers] Resignation from Stefan Krah > > > Le 09/10/2020 à 15:57, Christian Heimes a écrit : > > On 09/10/2020 15.48, Antoine Pitrou wrote: > >> On Fri, 9 Oct 2020 05:04:55 +0300 > >> Ivan Pozdeev via Python-Dev wrote: > >>> I don't see the point of requiring to "write an apology", especially > >>> *before a 12-month ban*. If they understand that their behavior is > >>> wrong, there's no need for a ban, at least not such a long one; if they > >>> don't, they clearly aren't going to write it, at least not now (they > >>> might later, after a few weeks or months, having cooled down and thought > >>> it over). So all it would achieve is public shaming AFAICS. Same > >>> issue with the threat of "zero tolerance policy" -- it's completely > >>> unnecessary and only serves to humiliate and alienate the recipient. > >> > >> That's my impression as well. Also, we now have an unmaintained module > >> (_decimal) requiring specific competence. > > > > Please elaborate. I feel like you are insinuating something with your > > "unmaintained module" remark. > > Well, it's not hard to notice that Stefan was the maintainer (as well as > the primary or sole author) of the C _decimal module, right? I think that is irrelevant to the decision of the steering council though. > > I wouldn't say for sure, but I don't expect him to transmit patches > through a third party, now that the SC banned him for 12 months, and > that he publicly resigned (signalling that he has probably no intention > to try to come back). > > Do you think otherwise? Or do you think there's someone else ready to > take up maintenance? Are you volunteering for that? Does it really matter that much in regards to the specific context? If someone poses problematic behavior (as it seems, as I'm not familiar with any specifics here), maintenance of a module should be the last of the worries. There are many pieces in the stdlib which remain or have remained unmaintained for years. Maybe someone could pick up the pace, maybe not. > > Regards > > Antoine. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/5WX63I23WZ4ZBJALWDA3VBSGV3J5KLM5/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6QCFOVUS5PIPXWWHNXPWB26EPM26UHAR/ Code of Conduct: http://python.org/psf/codeofconduct/
