[issue46999] test_multiprocessing_fork running without any timeout
New submission from Matthias Klose : the test_multiprocessing_fork test is a bit unreliable, at least on both the Debian and Ubuntu test infrastructures, sometimes running for 100+ hours. When running locally, I cannot reproduce these issues. Note that the test and build infrastructure is usually limited to 4-6 cores and 20GB of RAM (including swap). What else could be an issue for these hangs? How can this test reliably timeout? I know it takes a few hours on slow architectures even when succeeding. -- components: Tests messages: 415027 nosy: doko priority: normal severity: normal status: open title: test_multiprocessing_fork running without any timeout ___ Python tracker <https://bugs.python.org/issue46999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45778] libpython.so 3.9.8 drops symbol used by third party extension module(s)
Matthias Klose added the comment: the two users of typed-ast (at least in Debian) are black and mypy. Apparently black stopped using typed-ast recently. -- ___ Python tracker <https://bugs.python.org/issue45778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45778] libpython.so 3.9.8 drops symbol used by third party extension module(s)
New submission from Matthias Klose : [reported in Debian as https://bugs.debian.org/998854] 3.9.8, compared to 3.9.7 introduces a regression, making at least one third party extension fail at runtime. The symbol changes in 3.9.8 are: - _PyUnicode_DecodeUnicodeEscape@Base + _PyUnicode_DecodeRawUnicodeEscapeStateful@Base + _PyUnicode_DecodeUnicodeEscapeInternal@Base + _PyUnicode_DecodeUnicodeEscapeStateful@Base Affected at least is the typed-ast extension. Yes, you can rebuild the extension with 3.9.8, but then it doesn't work with earlier 3.9 versions. Just dropping the symbol on a stable branch is suboptimal. -- components: Interpreter Core keywords: 3.9regression messages: 406085 nosy: doko, lukasz.langa priority: release blocker severity: normal status: open title: libpython.so 3.9.8 drops symbol used by third party extension module(s) type: crash versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44982] Add vendor information
Matthias Klose added the comment: A bunch of people, consisting of Filipe Lains himself, Geoffrey Thomas, Donald Stufft, Tzu-Ping Chung, Pradyun Gedam, Stefano Rivera, Elana Hashman, and myself (Matthias Klose), and with feedback from Carol Willing and Christian Heimes were preparing a PEP to address issues with vendored or system Python versions. It looks like Filipe was unable to give feedback or follow-up after the initial meetings at PyCon. I am unsure if having two different interpreters is a good solution, and it certainly requires some cooperation with distros. -- nosy: +Marcus.Smith, dstufft, ncoghlan, paul.moore, pradyunsg ___ Python tracker <https://bugs.python.org/issue44982> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44230] lookup extensions with the stable ABI under a platform specific name
Matthias Klose added the comment: > How will these filenames be generated? Won't build tools like setuptools need > to be changed as well? If the preferred file name stays the same, it would be up to the distro specific packaging tools. But yes, if the platform specific name would be the preferred one, then it needs documentation and coordination with build tools. -- ___ Python tracker <https://bugs.python.org/issue44230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44230] lookup extensions with the stable ABI under a platform specific name
New submission from Matthias Klose : On Posix targets, the file names for extensionsions are currently foo.cpython-39-x86_64-linux-gnu.so foo.abi3.so for platforms which have PLATFORM_TRIPLET defined. This makes it clear which extension belongs to which interpreter, and at least on Debian and Ubuntu, it allowes cross-building of extensions by installing both the required build and host (or host and target) packages in the same environment. Of course, the stable ABI is stable, so introducing another extension suffix to lookup has to be optional. Having such a lookup only as a local patch in a CPython build would make these extensions not loadable by other CPython builds. Proposing to also look up an extension with the stable ABI as foo.x86_64-linux-gnu.abi3.so Not using foo.x86_64-linux-gnu-abi3.so (with a dash) to keep possible .endswith() matches working. Adding this new lookup to _PyImport_DynLoadFiletab, before or after the original .abi3.so should be possible. - Adding it after the original one has the advantage that lookups won't get penalized with one extra lookup for people not using it. - Adding it before the original one has the advantage that the more specific one is looked up before the more general one. That behavior could also become the default on Debian builds using a local patch. One more question would be how to document that change, or if the platform specific extension file name should be the preferred name for the future. Adding here just a minimal patch for discussion. -- components: Extension Modules files: platform-stable-abi.diff keywords: patch messages: 394325 nosy: barry, doko, petr.viktorin priority: normal severity: normal status: open title: lookup extensions with the stable ABI under a platform specific name type: enhancement versions: Python 3.10, Python 3.11 Added file: https://bugs.python.org/file50062/platform-stable-abi.diff ___ Python tracker <https://bugs.python.org/issue44230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23767] Library and include paths not added when cross-compiling on localized system
Matthias Klose added the comment: that looks fine. Maybe also set LANG=C ? -- ___ Python tracker <https://bugs.python.org/issue23767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment
Matthias Klose added the comment: The Debian/Ubuntu packages have a local patch for distutils/setuptools introducing an --install-layout option. Maybe have the same for pip? The intention with renaming/moving site-packages to /usr/lib/python3/dist-packages is to avoid users damaging their system installation, like sudo python3 setup.py install sudo pip install overriding packages installed with the distro package manager. Just making this schema known, and making it the default would again allow pip acting on packages managed by the distro package manager. Otoh, there are use cases, where you want to use the Python provided by the Linux distro and run into issues with the custom dist-packages. - Creating a venv using the system Python probably should use the versioned site-packages. - Building on top of a docker image for e.g. a Python App, you probably want to install into the dist-packages provided by the system Python. So the problem to solve is - let a "sudo pip install" fail by default on the real system - let the same install succeed in a docker environment, or any other "image". - behave transparently on venv and virtualenv installations. -- ___ Python tracker <https://bugs.python.org/issue43312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment
Matthias Klose added the comment: see also https://github.com/pypa/pip/issues/9617 -- nosy: +doko ___ Python tracker <https://bugs.python.org/issue43312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43229] freeze searches libpython3.9.so in /usr/lib instead /usr/lib/x86_64-linux-gnu
Matthias Klose added the comment: Please could you edit /usr/lib/python3.9/_sysconfigdata__x86_64-linux-gnu.py setting LIBDIR to /usr/lib/x86_64-linux-gnu and see if that fixes the freeze issue? that could also be fixed by configuring with --libdir=/usr/lib/x86_64-linux-gnu but that also moves lib-dynload into the new libdir. # Detailed destination directories BINLIBDEST= $(LIBDIR)/python$(VERSION) LIBDEST=$(SCRIPTDIR)/python$(VERSION) DESTSHARED= $(BINLIBDEST)/lib-dynload -- ___ Python tracker <https://bugs.python.org/issue43229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42580] ctypes.util.find_library("libc") fails
Matthias Klose added the comment:
ctypes.util.find_library("libc") used to work in 3.8, not working in 3.9. As I
said before, ctypes.util.find_library("c") works in both 3.8 and 3.9.
--
___
Python tracker
<https://bugs.python.org/issue42580>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43137] webbrowser to support "gio open "
New submission from Matthias Klose : [forwarded from https://bugs.debian.org/969776] """ rust-webbrowser tries to open URLs via "gvfs-open $URL" and "gnome-open $URL". Both are obsolete; the replacement is "gio open $URL", using the gio(1) tool from the libglib2.0-bin package. The gvfs-open tool was superseded by gio(1) in 2015, and removed from upstream GNOME in 2018. The version in Debian is currently a Debian-specific patch, which we would like to remove before Debian 11. The gnome-open tool was superseded by gvfs-open in 2008, ceased to be part of GNOME releases after about 2011, most recently appeared in a Debian stable release as part of Debian 9, and was finally removed from Debian in 2019. """ The current list of browser could need some cleanup, e.g.: - remove "The Netscape and old Mozilla browsers" - remove grail? - remove gvfs-open - gnome-open? - can't find galeon anymore, but epiphany -- components: Library (Lib) messages: 386526 nosy: doko priority: normal severity: normal status: open title: webbrowser to support "gio open " versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43030] signed/unsigned mismatch in Py_UNICODE_ISSPACE macro
Matthias Klose added the comment: # 26 "/usr/include/stdlib.h" 2 3 4 # 1 "/usr/lib/gcc/x86_64-linux-gnu/10/include/stddef.h" 1 3 4 # 321 "/usr/lib/gcc/x86_64-linux-gnu/10/include/stddef.h" 3 4 typedef int wchar_t; # 32 "/usr/include/stdlib.h" 2 3 4 [...] # 1 "/usr/include/python3.9/cpython/unicodeobject.h" 1 # 14 "/usr/include/python3.9/cpython/unicodeobject.h" typedef wchar_t Py_UNICODE; # 53 "/usr/include/python3.9/cpython/unicodeobject.h" yes, x86_64-linux-gnu. -- ___ Python tracker <https://bugs.python.org/issue43030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43030] signed/unsigned mismatch in Py_UNICODE_ISSPACE macro
New submission from Matthias Klose :
[forwarded from https://bugs.debian.org/961396]
$ cat > foo.c
#include
int main(int argc, char *argv[])
{
Py_UNICODE x = 0;
return Py_UNICODE_ISSPACE(x);
}
$ gcc -Wsign-compare -Werror $(pkg-config --cflags python3) foo.c
In file included from /usr/include/python3.9/unicodeobject.h:1026,
from /usr/include/python3.9/Python.h:97,
from foo.c:1:
foo.c: In function ‘main’:
/usr/include/python3.9/cpython/unicodeobject.h:25:11: error: comparison of
integer expressions of different signedness: ‘Py_UNICODE’ {aka ‘int’} and
‘unsigned int’ [-Werror=sign-compare]
25 | ((ch) < 128U ? _Py_ascii_whitespace[(ch)] :
_PyUnicode_IsWhitespace(ch))
| ^
foo.c:7:16: note: in expansion of macro ‘Py_UNICODE_ISSPACE’
7 | return Py_UNICODE_ISSPACE(x);
|^~
cc1: all warnings being treated as errors
--
components: Extension Modules
messages: 385707
nosy: doko
priority: normal
severity: normal
status: open
title: signed/unsigned mismatch in Py_UNICODE_ISSPACE macro
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue43030>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42843] What min_sphinx for Python 3.10
Matthias Klose added the comment: Ubuntu 20.04 LTS still sees subminor Python 3.8 version updates, and needs to use sphinx 1.8.5. -- nosy: +doko ___ Python tracker <https://bugs.python.org/issue42843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42580] ctypes.util.find_library("libc") fails
Matthias Klose added the comment:
ctypes.util.find_library("c") works in both 3.8 and 3.9
--
___
Python tracker
<https://bugs.python.org/issue42580>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42580] ctypes.util.find_library("libc") fails
New submission from Matthias Klose :
regression compared to 3.8:
$ python3.9
Python 3.9.1rc1 (default, Nov 27 2020, 19:38:39)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ctypes.util.find_library("libc")
Traceback (most recent call last):
File "", line 1, in
NameError: name 'ctypes' is not defined
>>> import ctypes.util
>>> ctypes.util.find_library("libc")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.9/ctypes/util.py", line 341, in find_library
_get_soname(_findLib_gcc(name)) or _get_soname(_findLib_ld(name))
File "/usr/lib/python3.9/ctypes/util.py", line 147, in _findLib_gcc
if not _is_elf(file):
File "/usr/lib/python3.9/ctypes/util.py", line 99, in _is_elf
with open(filename, 'br') as thefile:
FileNotFoundError: [Errno 2] No such file or directory: b'liblibc.a'
also note that the shared library is installed.
--
components: ctypes
keywords: 3.9regression
messages: 382592
nosy: doko
priority: normal
severity: normal
status: open
title: ctypes.util.find_library("libc") fails
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue42580>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28468] Add platform.freedesktop_os_release()
Matthias Klose added the comment: I don't agree with this decision, but ok. In this case, please also provide a way to provide the value of the VERSION_ID field. It doesn't make sense to blacklist whole distributions in tests. -- ___ Python tracker <https://bugs.python.org/issue28468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28468] Add platform.freedesktop_os_release()
Matthias Klose added the comment: > I just needed such functionality for PTY tests another use case for a test. so please add it to the test framework, also suggested by Marc. -- ___ Python tracker <https://bugs.python.org/issue28468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28468] Add platform.freedesktop_osrelease()
Matthias Klose added the comment: > Where do you draw the line? there's a module available outside cpython. Your use case is to add some work around for some tests (like issue42142). If you need it for the tests, add it to the test framework. -- ___ Python tracker <https://bugs.python.org/issue28468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28468] Add platform.freedesktop_osrelease()
Matthias Klose added the comment: > In the case of this it's mood to even discuss requiring > os-release. (a) the PR does not add a hard dependency > on os-release, and (b) the file is present anyway. For anything outside cpython, there is the distro module, and the distro module is checking os-release first if it exists. I don't see a good value to add a second API for a subset of the distro module. Apparently the distro module is used by other projects. $ apt rdepends python3-distro | grep '^ [DRS]' | wc -l 33 If you think, distro information is needed to run cpython's tests, then make that function available as part of the tests, and don't promote that as a new API, although it is better in many cases to rely on feature tests instead of version information and distro names. Don't expose it as yet another API. -- ___ Python tracker <https://bugs.python.org/issue28468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42142] test_ttk timeout: FAIL tkinter ttk LabeledScale test_resize, and more
Matthias Klose added the comment: how is this test run on the CI? at least it succeeds for me when run locally. -- ___ Python tracker <https://bugs.python.org/issue42142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28468] Add platform.freedesktop_osrelease()
Matthias Klose added the comment: Christian, is it necessary to start with threats? > Python could also follow the lead of other software like D-Bus > and make the presence of os-release mandatory on Linux. > Any Linux platform without it would be considered broken. > I don't think it is necessary to impose such restriction on vendors. Python *does* follow this lead with the distro module. And no, I don't see yet any argument why you need a second API for that. -- ___ Python tracker <https://bugs.python.org/issue28468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28468] Add platform.freedesktop_osrelease()
Matthias Klose added the comment: > * /etc/os-release file <= this PR > * /etc/*release file <= covered by the PyPI distro module no Victor, you are wrong. os-release is covered by the distro module. There's no need to expose a second implementation as another API in the standard library. -- ___ Python tracker <https://bugs.python.org/issue28468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28468] Add platform.freedesktop_osrelease()
Matthias Klose added the comment: the Chef repo seems to be a little bit out-of-date, but anyway. I don't see the relevance for this issue. -- ___ Python tracker <https://bugs.python.org/issue28468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28468] Add platform.freedesktop_osrelease()
Matthias Klose added the comment: "The os-release file has been a well-defined standard for over 8 years." ... doesn't implicate that it's a good style to base your checks on that information. -- ___ Python tracker <https://bugs.python.org/issue28468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28468] Add platform.freedesktop_osrelease()
Matthias Klose added the comment: > Since the filename is now fixed and the format is well specified, > IMO it's perfectly fine to add PR 23492. I disagree with that. The distro module is the preferred way to do this (which cannot be used in the Python core). The rationale given is an not yet investigated issue with a timeout in tk/ttk, which from my point of view is not good enough to add a public API. -- ___ Python tracker <https://bugs.python.org/issue28468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42142] test_ttk timeout: FAIL tkinter ttk LabeledScale test_resize, and more
Matthias Klose added the comment: I became aware of this by the patch proposal "Please submit a PR to skip on Ubuntu", which results in the re-introduction of a distro specific API. I would rather help fixing this issue, instead on relying on some distro behavor. -- nosy: +doko ___ Python tracker <https://bugs.python.org/issue42142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28468] Add platform.freedesktop_osrelease()
Matthias Klose added the comment: it's easy to say "we need it". It took a while to remove that, so I don't think it should be easily re-introduced. so why do you need it, and why should it be exposed as part of the standard library? -- ___ Python tracker <https://bugs.python.org/issue28468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41760] 3.8.6 rc1 documentation fails to build with sphinx 3.2.1
Change by Matthias Klose : -- nosy: +lukasz.langa ___ Python tracker <https://bugs.python.org/issue41760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41760] 3.8.6 rc1 documentation fails to build with sphinx 3.2.1
Change by Matthias Klose : -- nosy: +ned.deily ___ Python tracker <https://bugs.python.org/issue41760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41760] 3.8.6 rc1 documentation fails to build with sphinx 3.2.1
New submission from Matthias Klose : the 3.8.6 rc1 documentation fails to build with sphinx 3.2.1: [...] reading sources... [ 98%] whatsnew/3.1 reading sources... [ 98%] whatsnew/3.2 reading sources... [ 98%] whatsnew/3.3 reading sources... [ 98%] whatsnew/3.4 reading sources... [ 98%] whatsnew/3.5 reading sources... [ 99%] whatsnew/3.6 reading sources... [ 99%] whatsnew/3.7 reading sources... [ 99%] whatsnew/3.8 reading sources... [ 99%] whatsnew/changelog reading sources... [100%] whatsnew/index /<>/Doc/tools/extensions/pyspecific.py:245: RemovedInSphinx40Warning: PyModulelevel is deprecated. Please check the implementation of return PyModulelevel.run(self) /<>/Doc/tools/extensions/pyspecific.py:277: RemovedInSphinx40Warning: PyClassmember is deprecated. Please check the implementation of return PyClassmember.run(self) /<>/Doc/tools/extensions/pyspecific.py:289: RemovedInSphinx40Warning: PyClassmember is deprecated. Please check the implementation of return PyClassmember.run(self) /<>/Doc/tools/extensions/pyspecific.py:271: RemovedInSphinx40Warning: PyModulelevel is deprecated. Please check the implementation of return PyModulelevel.run(self) /<>/Doc/tools/extensions/pyspecific.py:283: RemovedInSphinx40Warning: PyClassmember is deprecated. Please check the implementation of return PyClassmember.run(self) /<>/Doc/tools/extensions/pyspecific.py:302: RemovedInSphinx40Warning: PyClassmember is deprecated. Please check the implementation of return PyClassmember.run(self) Warning, treated as error: /<>/Doc/library/string.rst:311:duplicate token description of sign, other instance in library/functions make[1]: *** [Makefile:52: build] Error 2 -- components: Build messages: 376711 nosy: doko priority: normal severity: normal status: open title: 3.8.6 rc1 documentation fails to build with sphinx 3.2.1 versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue41760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration
Matthias Klose added the comment: 3.9.0 rc1 fails to build the docs with Sphinx 3.2.0, even with setting c_allow_pre_v3 = True c_warn_on_allowed_pre_v3 = False Warning, treated as error: /packages/python/3.9/python3.9-3.9.0~rc1/Doc/c-api/buffer.rst:92:Error in declarator or parameters Invalid C declaration: Expected identifier in nested name. [error at 5] void \*buf -^ make[1]: *** [Makefile:52: build] Error 2 With 3.2.0, you still need to build without -W -- ___ Python tracker <https://bugs.python.org/issue40204> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41295] CPython 3.8.4 regression on __setattr__ in multiinheritance with metaclasses
Matthias Klose added the comment: David, which issue number is this? -- nosy: +doko ___ Python tracker <https://bugs.python.org/issue41295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41282] Deprecate and remove distutils
Matthias Klose added the comment: > A PEP may be a good idea, but I do think the change doesn't have a > particularly large magnitude. Anyone using setuptools or pip has > already been getting setuptools' monkey-patched version of distutils > for ages now, and soon they will be getting setuptools' vendored > version. The documentation already indicates that distutils is at > least soft-deprecated in favor of setuptools and we've already been > directing issues and PRs to setuptools instead of distutils. I don't think it's a good idea to replace bad habits from distutils with bad habits in setuptools._distutils. And this is exactly what you get with pointing directly to setuptools. While splitting out distutils to a separate package in a Linux distro, I found some creative usages at runtime of a package (see my lightning talk at the language summit 2018, and [1]). From my point of view, CPython should provide documentation how to forward-port these issues without using setuptools._distutils. Currently setuptools only has one component (pkg_resources, [2]) which is used at runtime. I dislike it if more than that is used at runtime of a package. [1] https://mail.python.org/archives/list/distutils-...@python.org/thread/74WZ7D3ARF7B3N6MAV2JBV3DW6TRHFIV/ [2] https://github.com/pypa/setuptools/issues/863 -- ___ Python tracker <https://bugs.python.org/issue41282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41282] Deprecate and remove distutils
Matthias Klose added the comment: Renaming distutils to _buildutils only delays the problem to remove it. But yes, it explicitly makes it explicit that code needs to be changed. I would like to see that neither distutils or _buildutils is installed by default, and only is available internally for building the extensions of CPython. The "old" build system to build builtins instead of extensions is still functional, so it should be ok to build the extensions also with the old build system. That would require moving all the config stuff in setup.py to autoconf tests, which is perfectly doable. The MacOS and Windows builds would need some attention too, but afaicr when asking Ned Deily and Steve Dower at the language summits, they didn't have a concern about this approach. -- ___ Python tracker <https://bugs.python.org/issue41282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41282] Deprecate and remove distutils
Matthias Klose added the comment: > It's too late to add a new deprecation in the Python 3.9 cycle Please can we add a note in 3.9, that it will be deprecated in 3.10? -- nosy: +doko ___ Python tracker <https://bugs.python.org/issue41282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration
Matthias Klose added the comment: please note that pinning usually is not a solution for Linux distributions. Yes, the most wanted fix would be to fix sphinx 3.x not to break compatibility with 2.x. Or limit 3.9 to 2.x features for now. -- nosy: +doko ___ Python tracker <https://bugs.python.org/issue40204> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41206] behaviour change with EmailMessage.set_content
Matthias Klose added the comment: that's a regression for the 3.8 branch, marking as a release blocker for 3.8.4. This should be a documented change for 3.9, and probably reverted/fixed for 3.8. -- keywords: +3.8regression, 3.9regression nosy: +doko, lukasz.langa priority: normal -> release blocker ___ Python tracker <https://bugs.python.org/issue41206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41206] behaviour change with EmailMessage.set_content
Change by Matthias Klose : -- nosy: +ivyl ___ Python tracker <https://bugs.python.org/issue41206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40874] Update to libmpdec-2.5.0
Matthias Klose added the comment: I'm +-0 on if that should be integrated into 3.9. Only a few people are using --with-system-libmpdec. However the way that mpdecimal 2.4 and 2.5 are released, they are not usable for Debian or Ubuntu for the transition from 3.8 to 3.9. For that, both 3.8 and 3.9 have to be available on the systems for the transition period, and that's just not possible without mpdecimal changing it's soname, or building one Python version with the internal libmpdec. -- ___ Python tracker <https://bugs.python.org/issue40874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40734] /usr/bin surprisingly in sys.path under IDLE
Matthias Klose added the comment: I can't reproduce that: $ python3.7 -c 'import sys; print (sys.path)' ['', '/usr/lib/python37.zip', '/usr/lib/python3.7', '/usr/lib/python3.7/lib-dynload', '/usr/local/lib/python3.7/dist-packages', '/usr/lib/python3/dist-packages'] -- resolution: -> works for me ___ Python tracker <https://bugs.python.org/issue40734> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22699] Module source files not found when cross-compiling
Matthias Klose added the comment: the multiarch approach allows you to install libraries and headers for many architectures in the same installation/chroot. This can then be used to cross-build stuff. you can check that on WSL with having Debian or Ubuntu installed. A short reference is https://wiki.debian.org/Multiarch/HOWTO you don't need to build packages, you can build upstream sources as well, just use apt to install the required packages for the target architecture. -- ___ Python tracker <https://bugs.python.org/issue22699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22699] Module source files not found when cross-compiling
Matthias Klose added the comment: I think the patch is wrong. why would you want to differentiate between native and cross builds? There should be a generic way to pick up those for both cross and native builds. -- ___ Python tracker <https://bugs.python.org/issue22699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38913] Py_BuildValue("(s#O)", ...) segfaults if entered with exception raised
Matthias Klose added the comment: seen with the current 3.8 branch. -- keywords: +3.8regression nosy: +doko, lukasz.langa priority: normal -> release blocker ___ Python tracker <https://bugs.python.org/issue38913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36852] Python3.7.2 fails to cross-compile (yocto / openembedded) when target is mips softfloat
Matthias Klose added the comment: You misunderstand. The GNU triplets are ambiguous. mips 32bit big endian soft float, and mips 32bit big endian hard float are *not* ABI compatible, but map to the same GNU triplet. The check *is* cross compiler aware, it's run with the target preprocessor/compiler. -- ___ Python tracker <https://bugs.python.org/issue36852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36852] Python3.7.2 fails to cross-compile (yocto / openembedded) when target is mips softfloat
Matthias Klose added the comment: The idea with the extension names is to have different names for different ABIs. See https://wiki.debian.org/Multiarch/Tuples for the list of ABIs that are "known", or documented. mips-linux-gnu is documented as MIPS32r2+FPXX, which is a different ABI than MIPS32r2 apparently, and not compatible, so it should have a different name. Other architectures like arm-linux-gnueabi and arm-linux-gnueabihf have the hard/soft difference encode in their GNU triplet name, and apparently nobody did that for mips. One solution would be to define a mips-linux-gnusf Multiarch name, which then would be different than the GNU triplet. Note that there's no "authority" to define the Multiarch names, however in most cases the GNU quadruplet without the vendor is chosen as the MA name. Other solutions could be to define no MA name, or go with your solution, just ignoring things. I'd still prefer something defining a name for this ABI. -- ___ Python tracker <https://bugs.python.org/issue36852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36852] Python3.7.2 fails to cross-compile (yocto / openembedded) when target is mips softfloat
Matthias Klose added the comment: I'll get back on this -- ___ Python tracker <https://bugs.python.org/issue36852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38620] Shell python-config --includes returns the same path twice
Matthias Klose added the comment: Some distros have two include directories in the path, /usr/include /usr/include/ The latter for architecture specific files, so on these distributions the python config file is installed there. Then you'll need to have both include directories. Unfortunately most third party only expect one, and because the config file is installed in a subdir, then fail to build. So the solution is to provide a rather arch specific ugly wrapper file to get away with one include directory. https://salsa.debian.org/cpython-team/python3/blob/master/debian/multiarch.h.in Also done on other distros like https://src.fedoraproject.org/rpms/gmp/blob/master/f/gmp.h I still think the two directories should be emitted, maybe check in the script if they are different. -- ___ Python tracker <https://bugs.python.org/issue38620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38368] Crash when subclassing ctypes.Union
Change by Matthias Klose : -- keywords: +3.7regression -patch ___ Python tracker <https://bugs.python.org/issue38368> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33439] python-config.py should be part of the stdlib
Matthias Klose added the comment: what are the situations where the path for python and python-config is different? This proposal doesn't say anything how to retrieve the correct information for cross builds using this module. From my point of view, python-config should stay outside the standard library. -- ___ Python tracker <https://bugs.python.org/issue33439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37577] ModuleNotFoundError: No module named '_sysconfigdata__linux_x86_64-linux-gnu'
Matthias Klose added the comment: Luis, I'm still trying to figure out why you are seeing that. Please could you report the package versions which are installed on the system? dpkg -l python3.7 python3.8 python3-distutils -- ___ Python tracker <https://bugs.python.org/issue37577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37577] ModuleNotFoundError: No module named '_sysconfigdata__linux_x86_64-linux-gnu'
Matthias Klose added the comment: this is issue #37561, making the sysconfigdata file name not changing with the kernel version of the OS. I need to commit that patch to the trunk and 3.8. But apparently pip needs to be aware of that as well ... -- ___ Python tracker <https://bugs.python.org/issue37577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37561] the _sysconfigdata name should not encode MACHDEP and PLATFORM_TRIPLET
New submission from Matthias Klose : so issue28046 decided to encode both MACHDEP and PLATFORM_TRIPLET/MULTIARCH in the _sysconfigdata name. Unfortunately on KFreeBSD MACHDEP includes the kernel version, so you end up with a changing MACHDEP. The _sysconfigdata name should only encode the MULTIARCH triplet, and if that's not define, the MACHDEP. Working on a fix. -- messages: 347670 nosy: doko priority: normal severity: normal status: open title: the _sysconfigdata name should not encode MACHDEP and PLATFORM_TRIPLET versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue37561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37504] 3.8 b2 now requires sphinx2, but only has documented 1.8
Matthias Klose added the comment: so this might not be a sphinx 2.x issue, the docs build fine for the html output, but the reported error is for building the texinfo files: make -C Doc texinfo That worked for 3.8 b1. -- ___ Python tracker <https://bugs.python.org/issue37504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37504] 3.8 b2 now requires sphinx2, but only has documented 1.8
New submission from Matthias Klose : 3.8 b2 now requires sphinx2 (according to SilentGhost on IRC), but only has documented 1.8. I'm aware of issue #36007, the last time that the requirements were bumped. So again, the dependencies were bumped without documenting, and why do we require the latest sphinx again? It's difficult to provide the documentation as a Linux distro when you always have to provide the latest build tools. Please compare that to other projects that are usually fine to build with any doxygen, texinfo, or whatever doc tool. Any hint where the new dependency was introduced, and probably can be backed out? The actuall error is: writing... Exception occurred: File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 567, in __getitem__ return self.attributes[key] KeyError: 'cols' # Sphinx version: 1.8.4 # Python version: 3.7.3 (CPython) # Docutils version: 0.14 # Jinja2 version: 2.10 # Last messages: # distutils/sourcedist # distutils/builtdist # distutils/examples # distutils/extending # distutils/commandref # distutils/apiref # install/index # # resolving references... # writing... # Loaded extensions: # sphinx.ext.mathjax (1.8.4) from /usr/lib/python3/dist-packages/sphinx/ext/mathjax.py # alabaster (0.7.8) from /usr/lib/python3/dist-packages/alabaster/__init__.py # sphinx.ext.coverage (1.8.4) from /usr/lib/python3/dist-packages/sphinx/ext/coverage.py # sphinx.ext.doctest (1.8.4) from /usr/lib/python3/dist-packages/sphinx/ext/doctest.py # pyspecific (1.0) from /home/packages/python/3.8/python3.8-3.8.0~b2/Doc/tools/extensions/pyspecific.py # c_annotations (1.0) from /home/packages/python/3.8/python3.8-3.8.0~b2/Doc/tools/extensions/c_annotations.py # escape4chm (1.0) from /home/packages/python/3.8/python3.8-3.8.0~b2/Doc/tools/extensions/escape4chm.py Traceback (most recent call last): File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 304, in build_main app.build(args.force_all, filenames) File "/usr/lib/python3/dist-packages/sphinx/application.py", line 341, in build self.builder.build_update() File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 342, in build_update self.build(['__all__'], to_build) File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 412, in build self.write(docnames, list(updated_docnames), method) File "/usr/lib/python3/dist-packages/sphinx/builders/texinfo.py", line 187, in write docwriter.write(doctree, destination) File "/usr/lib/python3/dist-packages/docutils/writers/__init__.py", line 80, in write self.translate() File "/usr/lib/python3/dist-packages/sphinx/writers/texinfo.py", line 139, in translate self.document.walkabout(visitor) File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 174, in walkabout if child.walkabout(visitor): File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 174, in walkabout if child.walkabout(visitor): File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 174, in walkabout if child.walkabout(visitor): [Previous line repeated 9 more times] File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 166, in walkabout visitor.dispatch_visit(self) File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 1882, in dispatch_visit return method(node) File "/usr/lib/python3/dist-packages/sphinx/writers/texinfo.py", line 1126, in visit_tgroup self.n_cols = node['cols'] File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 567, in __getitem__ return self.attributes[key] KeyError: 'cols' -- assignee: docs@python components: Documentation messages: 347322 nosy: docs@python, doko priority: normal severity: normal status: open title: 3.8 b2 now requires sphinx2, but only has documented 1.8 versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue37504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37162] new importlib dependencies csv, email and zipfile
Matthias Klose added the comment: yes, that's for the minimal package. zipfile is found in Lib/importlib/_bootstrap_external.py Again, it's just a question here, having found an unmotivated distutils import before in one of the standard modules. -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue37162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37162] new importlib dependencies csv, email and zipfile
New submission from Matthias Klose : compared to 3.8 alpha4, beta1's importlib has three new dependencies csv, email and zipfile. Is this intended, or should the toplevel imports in importlib.metadata be moved into the functions where these are once used? -- components: Library (Lib) messages: 344703 nosy: brett.cannon, doko, eric.snow, ncoghlan priority: normal severity: normal status: open title: new importlib dependencies csv, email and zipfile versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue37162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36721] Add pkg-config python-3.8-embed
Matthias Klose added the comment: "AFAICT, the purpose of python-config is to provide configuration info for embedding Python" If that's the intention, then at least it's not used as such. It's also used to build/configure extensions using automake/cmake based build systems. There is one tool, and two different use cases. I think Victor's suggestion is appropriate -- ___ Python tracker <https://bugs.python.org/issue36721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36753] Python modules not linking to libpython causes issues for RTLD_LOCAL system-wide
Matthias Klose added the comment: why is this an issue on Debian? Debian is already not linking with libpython. -- nosy: +doko ___ Python tracker <https://bugs.python.org/issue36753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36445] bus error in test_gil test on armhf running with 64bit kernel
Change by Matthias Klose : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> unaligned memory access in the _sha3 extension ___ Python tracker <https://bugs.python.org/issue36445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36515] unaligned memory access in the _sha3 extension
New submission from Matthias Klose : This was seen when running an armhf binary on a 64bit kernel. The problem is that the implementation uses unaligned memory accesses, and even is well aware of that. The module allows misaligned memory accesses by default. The NO_MISALIGNED_ACCESSES macro is never defined. Now you can define it only on architectures where unaligned memory accesses are not allowed (ARM32 on 64bit kernels), or where there are performance penalties (AArch64), or just don't try to outsmart modern compilers and always define this macro. The attached patch only fixes the issue on ARM32 and AArch64, however the safe fix should be to always define the macro. -- components: Extension Modules files: arm-alignment.diff keywords: patch messages: 339379 nosy: christian.heimes, doko priority: high severity: normal status: open title: unaligned memory access in the _sha3 extension type: crash versions: Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file48243/arm-alignment.diff ___ Python tracker <https://bugs.python.org/issue36515> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36445] bus error in test_gil test on armhf running with 64bit kernel
New submission from Matthias Klose : seen with 3.7,3, not 3.8 alpha3. bus error in test_gil test on armhf with 64bit kernel, one more unaligned access. not seen in debug builds. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/armhf/p/python3.7/20190327_025457_8b623@/log.gz test_extra_sha3 (test.test_hashlib.HashLibTestCase) ... ok test_get_builtin_constructor (test.test_hashlib.HashLibTestCase) ... ok test_gil (test.test_hashlib.HashLibTestCase) ... Fatal Python error: Bus error Current thread 0xf7bcd210 (most recent call first): File "/usr/lib/python3.7/test/test_hashlib.py", line 788 in test_gil File "/usr/lib/python3.7/unittest/case.py", line 615 in run File "/usr/lib/python3.7/unittest/case.py", line 663 in __call__ File "/usr/lib/python3.7/unittest/suite.py", line 122 in run File "/usr/lib/python3.7/unittest/suite.py", line 84 in __call__ File "/usr/lib/python3.7/unittest/suite.py", line 122 in run File "/usr/lib/python3.7/unittest/suite.py", line 84 in __call__ File "/usr/lib/python3.7/unittest/suite.py", line 122 in run File "/usr/lib/python3.7/unittest/suite.py", line 84 in __call__ File "/usr/lib/python3.7/unittest/runner.py", line 176 in run File "/usr/lib/python3.7/test/support/__init__.py", line 1899 in _run_suite File "/usr/lib/python3.7/test/support/__init__.py", line 1995 in run_unittest File "/usr/lib/python3.7/test/libregrtest/runtest.py", line 178 in test_runner File "/usr/lib/python3.7/test/libregrtest/runtest.py", line 182 in runtest_inner File "/usr/lib/python3.7/test/libregrtest/runtest.py", line 137 in runtest File "/usr/lib/python3.7/test/libregrtest/main.py", line 305 in rerun_failed_tests File "/usr/lib/python3.7/test/libregrtest/main.py", line 623 in _main File "/usr/lib/python3.7/test/libregrtest/main.py", line 586 in main File "/usr/lib/python3.7/test/libregrtest/main.py", line 640 in main File "/usr/lib/python3.7/test/__main__.py", line 2 in File "/usr/lib/python3.7/runpy.py", line 85 in _run_code File "/usr/lib/python3.7/runpy.py", line 193 in _run_module_as_main Bus error (core dumped) -- components: Extension Modules keywords: 3.7regression messages: 338944 nosy: doko priority: normal severity: normal status: open title: bus error in test_gil test on armhf running with 64bit kernel versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28190] Cross-build _curses failed if host ncurses headers and target ncurses headers have different layouts
Matthias Klose added the comment: no, please don't assume that if it builds for one cross build variant, that it builds for all. re-opening. -- resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue28190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on Fedora 29
Matthias Klose added the comment: setting to release-blocker for evaluation. the freebsd solution seems to be wrong, just avoiding the error. Is the test correct, or do we have an issue that TLSv1.3 isn't properly handled? -- keywords: +3.7regression nosy: +lukasz.langa, ned.deily priority: normal -> release blocker versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue35998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on Fedora 29
Matthias Klose added the comment: seen in Ubuntu 19.04 as well. Started after the openssl update form 1.1.1 to 1.1.1b. -- nosy: +doko ___ Python tracker <https://bugs.python.org/issue35998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35908] build with building extension modules as builtins is broken in 3.8
Matthias Klose added the comment: found it, Setup.dist was renamed to Setup. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35908] build with building extension modules as builtins is broken in 3.8
Matthias Klose added the comment: Setup.local used: # Edit this file for local setup changes array arraymodule.c # array objects cmath cmathmodule.c _math.c # -lm # complex math library functions math mathmodule.c _math.c # -lm # math library functions, e.g. sin() _struct _struct.c # binary structure packing/unpacking _random _randommodule.c # Random number generator _elementtree _elementtree.c -lexpat # elementtree accelerator _pickle _pickle.c # pickle accelerator _datetime _datetimemodule.c # datetime accelerator _bisect _bisectmodule.c # Bisection algorithms _heapq _heapqmodule.c # Heap queue algorithm unicodedata unicodedata.c# static Unicode character database fcntl fcntlmodule.c # fcntl(2) and ioctl(2) spwd spwdmodule.c # spwd(3) grp grpmodule.c # grp(3) select selectmodule.c # select(2); not on ancient System V _socket socketmodule.c _posixsubprocess _posixsubprocess.c # POSIX subprocess module helper _md5 md5module.c _sha1 sha1module.c _sha256 sha256module.c _sha512 sha512module.c _sha3 _sha3/sha3module.c _blake2 _blake2/blake2module.c _blake2/blake2b_impl.c _blake2/blake2s_impl.c syslog syslogmodule.c # syslog daemon interface binascii binascii.c zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz -- ___ Python tracker <https://bugs.python.org/issue35908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35908] build with building extension modules as builtins is broken in 3.8
New submission from Matthias Klose : the build with building extension modules as builtins is broken in 3.8. I assume that is some fallout from the header re-organization. It shows in the link step by having undefined references. Undefined symbols are listed below. Still looking where the behavior change was introduced, but help would be appreciated. ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(longobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Objects/longobject.c:1742: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Objects/longobject.c:2769: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(longobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Objects/longobject.c:3309: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Objects/longobject.c:3271: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(longobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Objects/unicodeobject.c:3766: undefined reference to `PyOS_FSPath' ./build-static/../Objects/unicodeobject.c:3808: undefined reference to `PyOS_FSPath' ./build-static/../Python/pylifecycle.c:2019: undefined reference to `_PyFaulthandler_Fini' /usr/bin/ld: ./build-static/../Python/pylifecycle.c:2019: undefined reference to `_PyFaulthandler_Fini' ./build-static/../Python/pylifecycle.c:1091: undefined reference to `PyOS_FiniInterrupts' /usr/bin/ld: ./build-static/../Python/pylifecycle.c:1143: undefined reference to `_PyTraceMalloc_Fini' /usr/bin/ld: ./build-static/../Python/pylifecycle.c:1152: undefined reference to `_PyFaulthandler_Fini' ./build-static/../Python/pylifecycle.c:860: undefined reference to `_PyFaulthandler_Init' ./build-static/../Python/pylifecycle.c:2150: undefined reference to `PyOS_InitInterrupts' ./build-static/../Python/pylifecycle.c:877: undefined reference to `_PyTraceMalloc_Init' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(bytesobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Python/ceval.c:383: undefined reference to `PyErr_CheckSignals' ./build-static/../Python/errors.c:497: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Python/errors.c:497: undefined reference to `PyErr_Check
[issue35472] python 3.7.2 rc1 bumped the build requirements for no reason
Matthias Klose added the comment: "if one uses the doc Makefile venv target". which is not possible for distributions which are not allowed to use anything but the distro to build the distro. so why bumping the version requirement to 1.7 instead of 1.6.6? Afaicu this is the required version. I don't argue against introducing new build requirements in major versions, but having them introduced on the branches. -- ___ Python tracker <https://bugs.python.org/issue35472> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35472] python 3.7.2 rc1 bumped the build requirements for no reason
New submission from Matthias Klose : python 3.7.2 rc1 bumped the build requirements apparently for no reason, now requiring sphinx 1.7 instead of 1.6.x before. This is a major pain, if you want to provide the build including the documentation on a stable release. Pretty please can we avoid such version bumps on the branches? Plus the documentation seems to build fine with 1.6.7. -- assignee: docs@python components: Documentation keywords: 3.7regression messages: 331705 nosy: docs@python, doko, ned.deily priority: release blocker severity: normal status: open title: python 3.7.2 rc1 bumped the build requirements for no reason versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35472> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35468] [3.6/3.7] idlelib/help.html mentions 3.8alpha0 docs
New submission from Matthias Klose : [3.6/3.7] idlelib/help.html mentions 3.8alpha0 docs: Seen in the 3.6.8 and 3.7.2 release candidates -- assignee: terry.reedy components: IDLE keywords: 3.6regression, 3.7regression messages: 331671 nosy: doko, ned.deily, terry.reedy priority: normal severity: normal status: open title: [3.6/3.7] idlelib/help.html mentions 3.8alpha0 docs versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue35468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35340] global symbol "freegrammar" should be made static ore renamed
New submission from Matthias Klose : seen at least on the 2.7, a new symbol polluting the symbol namespace. the global symbol "freegrammar" should be made static ore renamed -- components: Interpreter Core messages: 330615 nosy: doko priority: normal severity: normal status: open title: global symbol "freegrammar" should be made static ore renamed versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue35340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34814] makesetup: must link C extensions to libpython when compiled in shared mode
Matthias Klose added the comment: Debian/Ubuntu doesn't link against the library because it would add dependencies on all supported Python versions. Normally this is just during transition times, but e.g. for the upcoming Ubuntu 18.10 release we didn't finish the transition and so ship two Python3 versions. The packaging tools would add package dependencies on both 3.6 and 3.7 what you don't want. -- ___ Python tracker <https://bugs.python.org/issue34814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34806] distutils tests fail with recent 3.7 branch
Matthias Klose added the comment: well, it was top of the branch yesterday -- ___ Python tracker <https://bugs.python.org/issue34806> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34806] distutils tests fail with recent 3.7 branch
Matthias Klose added the comment: issue34530 was already fixed on 20180904, so there's something else... -- ___ Python tracker <https://bugs.python.org/issue34806> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34806] distutils tests fail with recent 3.7 branch
Change by Matthias Klose : -- nosy: +serhiy.storchaka, steve.dower ___ Python tracker <https://bugs.python.org/issue34806> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34806] distutils tests fail with recent 3.7 branch
New submission from Matthias Klose :
two distutils tests fail when running the tests from an installed location. 3.7
branch 20180925, succeeded with a 20180911 snapshot. Is there any locale
setting required?
==
ERROR: test_non_ascii (distutils.tests.test_log.TestLog)
(errors='surrogateescape')
--
Traceback (most recent call last):
File "/usr/lib/python3.7/distutils/tests/test_log.py", line 26, in
test_non_ascii
log.debug('Dεbug\tMėssãge')
File "/usr/lib/python3.7/distutils/log.py", line 41, in debug
self._log(DEBUG, msg, args)
File "/usr/lib/python3.7/distutils/log.py", line 34, in _log
stream.write('%s\n' % msg)
File "/usr/lib/python3.7/encodings/cp437.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u0117' in position
7: character maps to
==
ERROR: test_find_executable (distutils.tests.test_spawn.SpawnTestCase)
--
Traceback (most recent call last):
File "/usr/lib/python3.7/distutils/tests/test_spawn.py", line 95, in
test_find_executable
rv = find_executable(program)
File "/usr/lib/python3.7/distutils/spawn.py", line 176, in find_executable
path = os.environ['PATH']
File "/usr/lib/python3.7/os.py", line 678, in __getitem__
raise KeyError(key) from None
KeyError: 'PATH'
--
--
components: Distutils
keywords: 3.7regression
messages: 326428
nosy: doko, dstufft, eric.araujo, ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: distutils tests fail with recent 3.7 branch
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue34806>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26544] platform.libc_ver() returns incorrect version number
Matthias Klose added the comment: +1 -- ___ Python tracker <https://bugs.python.org/issue26544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26544] platform.libc_ver() returns incorrect version number
Matthias Klose added the comment: fine! what prevents merging and backporting this issue? -- ___ Python tracker <https://bugs.python.org/issue26544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26544] platform.libc_ver() returns incorrect version number
Change by Matthias Klose : Added file: https://bugs.python.org/file47755/platform-no-distutils.diff ___ Python tracker <https://bugs.python.org/issue26544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26544] platform.libc_ver() returns incorrect version number
Matthias Klose added the comment: proposed patch attached -- ___ Python tracker <https://bugs.python.org/issue26544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26544] platform.libc_ver() returns incorrect version number
Matthias Klose added the comment: no, it's not fixed at all. Setting as a release blocker for 3.6 and 3.7. -- keywords: +3.6regression, 3.7regression nosy: +benjamin.peterson, ned.deily priority: normal -> release blocker ___ Python tracker <https://bugs.python.org/issue26544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34286] lib2to3 tests fail on the 3.7 branch (used to work with 3.7.0)
Matthias Klose added the comment: strange. I see it succeeding in the build location, not the install location. Did you make sure to cd /tmp before running the test? I still can reproduce it: $ python3.7 -m test test_lib2to3 Run tests sequentially 0:00:00 load avg: 0.24 [1/1] test_lib2to3 test test_lib2to3 failed -- multiple errors occurred; run in verbose mode for details test_lib2to3 failed == Tests result: FAILURE == 1 test failed: test_lib2to3 Total duration: 5 sec 211 ms Tests result: FAILURE -- ___ Python tracker <https://bugs.python.org/issue34286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34286] lib2to3 tests fail on the 3.7 branch (used to work with 3.7.0)
New submission from Matthias Klose : running the lib2to3 tests from an installed location, I see the following failures on the 3.7 branch: == FAIL: test (lib2to3.tests.test_fixers.Test_reload) -- Traceback (most recent call last): File "/usr/lib/python3.7/lib2to3/tests/test_fixers.py", line 294, in test self.check(b, a) File "/usr/lib/python3.7/lib2to3/tests/test_fixers.py", line 36, in check tree = self._check(before, after) File "/usr/lib/python3.7/lib2to3/tests/test_fixers.py", line 32, in _check self.assertEqual(after, str(tree)) AssertionError: 'import importlib\nimportlib.reload(a)\n\n' != 'import imp\nimp.reload(a)\n\n' - import importlib ? -- + import imp - importlib.reload(a) ?-- + imp.reload(a) == FAIL: test_comment (lib2to3.tests.test_fixers.Test_reload) -- Traceback (most recent call last): File "/usr/lib/python3.7/lib2to3/tests/test_fixers.py", line 299, in test_comment self.check(b, a) File "/usr/lib/python3.7/lib2to3/tests/test_fixers.py", line 36, in check tree = self._check(before, after) File "/usr/lib/python3.7/lib2to3/tests/test_fixers.py", line 32, in _check self.assertEqual(after, str(tree)) AssertionError: 'import importlib\nimportlib.reload( a ) # comment\n\n' != 'import imp\nimp.reload( a ) # comment\n\n' - import importlib ? -- + import imp - importlib.reload( a ) # comment ?-- + imp.reload( a ) # comment == FAIL: test_space (lib2to3.tests.test_fixers.Test_reload) -- Traceback (most recent call last): File "/usr/lib/python3.7/lib2to3/tests/test_fixers.py", line 309, in test_space self.check(b, a) File "/usr/lib/python3.7/lib2to3/tests/test_fixers.py", line 36, in check tree = self._check(before, after) File "/usr/lib/python3.7/lib2to3/tests/test_fixers.py", line 32, in _check self.assertEqual(after, str(tree)) AssertionError: 'import importlib\nimportlib.reload( a )\n\n' != 'import imp\nimp.reload( a )\n\n' - import importlib ? -- + import imp - importlib.reload( a ) ?-- + imp.reload( a ) -- Ran 650 tests in 27.363s FAILED (failures=3) test test_lib2to3 failed 1 test failed again: test_lib2to3 == Tests result: FAILURE then FAILURE == 390 tests OK. 1 test failed: test_lib2to3 -- components: Library (Lib) keywords: 3.7regression messages: 322714 nosy: brett.cannon, doko, eric.snow, ncoghlan priority: normal severity: normal status: open title: lib2to3 tests fail on the 3.7 branch (used to work with 3.7.0) ___ Python tracker <https://bugs.python.org/issue34286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27201] expose the ABI name as a config variable
Matthias Klose added the comment: ok, not working on that currently -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue27201> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34178] test_tcl fails on the 3.7 branch
Matthias Klose added the comment: this is the python3.7 build for Debian, so yes, installed via a package manager ;) see https://ci.debian.net/data/packages/unstable/amd64/p/python3.7/ for the test results. and yes, that seems to be a regression compared to the 3.7.0 release. -- ___ Python tracker <https://bugs.python.org/issue34178> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34178] test_tcl fails on the 3.7 branch
Matthias Klose added the comment: seen on Linux x86_64, using Tcl 8.6.8, running the tests in the installed location. -- ___ Python tracker <https://bugs.python.org/issue34178> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34178] test_tcl fails on the 3.7 branch
New submission from Matthias Klose :
test_tcl fails at least on the 3.7 branch with:
==
FAIL: test_join (test.test_tcl.TclTest)
--
Traceback (most recent call last):
File "/usr/lib/python3.7/test/test_tcl.py", line 670, in test_join
check('{spam}')
File "/usr/lib/python3.7/test/test_tcl.py", line 660, in check
self.assertEqual(unpack(unpack(join([[value]]))), value)
AssertionError: 'spam' != '{spam}'
- spam
+ {spam}
? ++
--
components: Tkinter
messages: 322086
nosy: doko
priority: normal
severity: normal
status: open
title: test_tcl fails on the 3.7 branch
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue34178>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34171] Lib/trace.cover not removed by the clean target
New submission from Matthias Klose : Lib/trace.cover is not removed by the clean target, and apparently this file is always created in the source tree, not in the build tree. It should be created in the build tree, if that's not possible, it should be cleaned in any case. -- components: Build messages: 322026 nosy: doko priority: normal severity: normal status: open title: Lib/trace.cover not removed by the clean target versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34171> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26544] platform.libc_ver() returns incorrect version number
Matthias Klose added the comment: a tuple comparison should be good enough -- ___ Python tracker <https://bugs.python.org/issue26544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26544] platform.libc_ver() returns incorrect version number
Matthias Klose added the comment: please don't close this yet. the patch introduces a dependency on the distutils package. I don't see any reason to compare the libc version as a python egg version, so please avoid that. if we need to have a module to compare arbitrary version strings, then we should think about adding one in the standard library, but I think that's what the packaging module is for. -- nosy: +doko ___ Python tracker <https://bugs.python.org/issue26544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33917] idlelib/idle_test/template.py has invalid syntax
New submission from Matthias Klose : Seen with the 3.6 branch and the 3.7 branch at least. This file is installed by default, so should be valid syntax? If it's supposed to be that way, maybe call the template like template.py.in? Unpacking libpython3.6-testsuite (3.6.6~rc1-3) ... Setting up libpython3.6-testsuite (3.6.6~rc1-3) ... File "/usr/lib/python3.6/idlelib/idle_test/template.py", line 3 from idlelib import ^ SyntaxError: invalid syntax -- assignee: terry.reedy components: IDLE keywords: 3.6regression, 3.7regression messages: 320099 nosy: doko, terry.reedy priority: release blocker severity: normal status: open title: idlelib/idle_test/template.py has invalid syntax ___ Python tracker <https://bugs.python.org/issue33917> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33465] test_from_import_missing_attr_has_name_and_so_path fails when select is a builtin instead of an extension
New submission from Matthias Klose : == ERROR: test_from_import_missing_attr_has_name_and_so_path (test.test_import.ImportTests) -- Traceback (most recent call last): File "/usr/lib/python3.7/test/test_import/__init__.py", line 98, in test_from_import_missing_attr_has_name_and_so_path self.assertEqual(cm.exception.path, select.__file__) AttributeError: module 'select' has no attribute '__file__' -- Ran 75 tests in 0.618s FAILED (errors=1, skipped=1) test test_import failed -- components: Tests messages: 316403 nosy: brett.cannon, doko, eric.snow, ncoghlan priority: normal severity: normal status: open title: test_from_import_missing_attr_has_name_and_so_path fails when select is a builtin instead of an extension type: behavior versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25109] test_code_module tests fail when run from the installed location
Matthias Klose added the comment: this seems to be fixed in 3.6 (3.6.5) and 3.7 (beta4). -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue25109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28167] remove platform.linux_distribution()
Matthias Klose added the comment: there is https://pypi.org/project/distro/ -- ___ Python tracker <https://bugs.python.org/issue28167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33393] update config.guess and config.sub
Matthias Klose added the comment: New changeset 9da7ee40037fa30d0d28fd8d7c652cde14e5a834 by Matthias Klose (Miss Islington (bot)) in branch '3.7': bpo-33393: Update config.guess and config.sub files (GH-6658) (#6661) https://github.com/python/cpython/commit/9da7ee40037fa30d0d28fd8d7c652cde14e5a834 -- ___ Python tracker <https://bugs.python.org/issue33393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33393] update config.guess and config.sub
Matthias Klose added the comment: New changeset 7e3545c70cdecd86ffa8fcbffd79b4f78560679f by Matthias Klose in branch 'master': bpo-33393: Update config.guess and config.sub files (#6658) https://github.com/python/cpython/commit/7e3545c70cdecd86ffa8fcbffd79b4f78560679f -- ___ Python tracker <https://bugs.python.org/issue33393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33394] the build of the shared modules is quiet/non-visible when GNU make gets passed macros
Change by Matthias Klose : -- pull_requests: +6355 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33394] the build of the shared modules is quiet/non-visible when GNU make gets passed macros
New submission from Matthias Klose : the build of the shared modules is quiet/non-visible when GNU make gets passed macros. This is was introduced by the change to support BSD make. GNU make adds all make macros passed on the command line to MAKEFLAGS. If one of these macros contains -s, the build of the extensions get quiet. Also print out how setup.py is called. -- components: Build files: verbose.diff keywords: patch messages: 315956 nosy: doko priority: normal severity: normal status: open title: the build of the shared modules is quiet/non-visible when GNU make gets passed macros Added file: https://bugs.python.org/file47558/verbose.diff ___ Python tracker <https://bugs.python.org/issue33394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
