Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale
On Mar 15, 2017, at 12:29 PM, Nick Coghlan wrote: >From a mainstream Linux point of view, it's not common - on systemd-managed >systems, for example, the only way to get the C locale these days is to >either specify it in /etc/locale.conf, or to set it specifically in the >environment. I think it's still the case that some isolation environments (e.g. Debian chroots) default to bare C locales. Often it doesn't matter, but sometimes tests or other applications run inside those environments will fail in ways they don't in a normal execution environment. The answer is almost always to explicitly coerce those environments to C.UTF-8 for Linuxes that support that. -Barry ___ 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] python(_hashlib.so) compiled with libssl.so.1.0.1e cannot work with libssl.so.0.9.8e
Hi, I just want to confirm that _hashlib.so in python references something new in libssl.so.1.0.1e(hmac related?). And if we want to work on platforms with libssl.so.0.9.8e, we should compile python with this lower version, right? Thanks. Regards, -Meiling ___ 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(_hashlib.so) compiled with libssl.so.1.0.1e cannot work with libssl.so.0.9.8e
On 2017-03-15 11:28, Meiling Ge wrote: > Hi, > > I just want to confirm that _hashlib.so in python references something > new in libssl.so.1.0.1e(hmac related?). > > And if we want to work on platforms with libssl.so.0.9.8e, we should > compile python with this lower version, right? OpenSSL 0.9.8 and 1.0.1 have an incompatible ABI. You cannot use 0.9.8 builds with 1.0.1 or the other way around. You have to re-compile _hashlib.so. By the way, you should neither use 0.9.8 nor 1.0.1. Both versions are no longer supported by upstream and receive no security fixes. Some vendors (RH, Ubuntu) still maintain 1.0.1, though. 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale
On 16 March 2017 at 00:30, Barry Warsaw wrote: > On Mar 15, 2017, at 12:29 PM, Nick Coghlan wrote: > > >From a mainstream Linux point of view, it's not common - on > systemd-managed > >systems, for example, the only way to get the C locale these days is to > >either specify it in /etc/locale.conf, or to set it specifically in the > >environment. > > I think it's still the case that some isolation environments (e.g. Debian > chroots) default to bare C locales. Often it doesn't matter, but sometimes > tests or other applications run inside those environments will fail in ways > they don't in a normal execution environment. Yeah, I think mock (the Fedora/RHEL/CentOS build environment for RPMs) still defaults to a bare C locale, and Docker environments usually aren't systemd-managed in the first place (since PID 1 inside a container typically isn't an init system at all). The general trend for all of those seems to be "they don't use C.UTF-8... yet", though (even though some of them may not shift until the default changes at the level of the given distro's libc implementation). The answer is almost always to > explicitly coerce those environments to C.UTF-8 for Linuxes that support > that. > I also double checked that "LANG=C ./python -m test" still worked with the reference implementation. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
