[issue44762] getpass.getpass on Windows fallback detection is bad
Change by jan matejek : -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue44762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44762] getpass.getpass on Windows fallback detection is bad
Change by jan matejek : -- versions: -Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44762] getpass.getpass on Windows fallback detection is bad
jan matejek added the comment: For that matter, in standard Windows Command Prompt `sys.stdin` and `sys.__stdin__` are also identical, but `isatty()` reports True. I suspect is that the code has drifted and `sys.stdin` is _always_ identical to `sys.__stdin__` ? -- ___ Python tracker <https://bugs.python.org/issue44762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44762] getpass.getpass on Windows fallback detection is bad
jan matejek added the comment: ...this is a problem because: When the check incorrectly infers that it can use `msvcrt` while its stdin is a pipe, the calls to `putwch` and `getwch` are going into the void and the program effectively freezes waiting for input that never comes. See also: https://stackoverflow.com/questions/49858821/python-getpass-doesnt-work-on-windows-git-bash-mingw64/54046572 https://github.com/ipython/ipython/issues/854 -- ___ Python tracker <https://bugs.python.org/issue44762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44762] getpass.getpass on Windows fallback detection is bad
New submission from jan matejek : The fallback detection for `win_getpass` checks that `sys.stdin` is different from `sys.__stdin__`. If yes, it assumes that it's incapable of disabling echo, and calls `default_getpass` which reads from stdin. If they are the same object, it assumes it's in a terminal and uses `msvcrt` to read characters. I was not able to find any rationale for this check, it seems to have been introduced, oh wow, in 2001, to fix something IDLE-related. Anyway, the check is trivially incorrect. It fails when such script is launched from `subprocess.Popen(stdin=PIPE)`, where both `sys.stdin` and `sys.__stdin__` are the same instance of `TextIOWrapper`. Same actually happens in MinTTY (Git Bash etc.) which is not a true terminal as far as I was able to find out? It seems that a better check would be, e.g., `sys.stdin.isatty()`, which correctly returns `False` both in subprocesses and in MinTTY. -- components: Library (Lib) messages: 398370 nosy: matejcik priority: normal severity: normal status: open title: getpass.getpass on Windows fallback detection is bad type: behavior versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
Changes by jan matejek <jmate...@suse.com>: -- pull_requests: +3682 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue1294959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29324] test_aead_aes_gcm fails on Kernel 4.9
Changes by jan matejek <jmate...@suse.com>: -- pull_requests: +94 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29324] test_aead_aes_gcm fails on Kernel 4.9
jan matejek added the comment: the attached patch fixes the test for me -- keywords: +patch Added file: http://bugs.python.org/file46494/test_socket_aead_kernel49.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29324] test_aead_aes_gcm fails on Kernel 4.9
jan matejek added the comment: The "'0' * taglen" part is now considered part of plaintext. Which makes a lot of sense :) Removing the "empty taglen" fixes the encryption part of the tests for me. Similarly, for the decryption test, we must only read and check the message without the tag. -- nosy: +matejcik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
jan matejek added the comment: Attached is a patch that I'd like to propose for inclusion. It introduces a new configure option "--with-custom-platlibdir=", which defaults to `basename $libdir`. This is converted to makefile variable "platlibdir", which is used in getpath.c to generate value of the lib_python variable. sysconfig and distutils.sysconfig retrieve the variable from makefile (i learned about existence of _sysconfigdata so that is where the variable now lives) to correctly substitute in posix_prefix (and unix_prefix for distutils install) scheme. Sysconfig is then used in pydoc and trace module, instead of locally calculating paths. Perhaps distutils.sysconfig should also use more of sysconfig instead of duplicating the functionality? As it stands, the python stdlib is installed into /usr/$platlibdir, because I changed SCRIPTDIR to $libdir instead of $prefix/lib. Maybe this should be also separately configurable? In any case, third-party modules get installed either into /usr/lib or /usr/$platlibdir depending on whether they are arch-independent or not. Hence the final modification in site.py that adds /usr/lib to search path on systems where $platlibdir != "lib". This caused test_sysconfig to fail because it checks that posix_user and posix_prefix schemes generate "similar" paths. I have left the posix_user scheme alone, so all its paths are based on "lib", where the posix_prefix scheme uses $platlibdir. Maybe posix_user scheme should be modified as well? Anyway, for now, I have accounted for the changes in the test. What now? (please don't make me write a PEP please don't make me write a PEP please don't make..) -- versions: +Python 3.7 Added file: http://bugs.python.org/file46301/python-3.6.0-multilib-new.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1294959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29283] duplicate README in site-packages
New submission from jan matejek: Lib/site-packages directory now contains README.txt in addition to README. Both files are identical. One of them should probably go away? -- components: Installation messages: 28 nosy: matejcik priority: normal severity: normal status: open title: duplicate README in site-packages type: enhancement versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29283> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
jan matejek added the comment: at this again, when porting SUSE patches to 3.6.0 :) ( :( ) Last time there was a discussion, Barry suggested using sysconfig variables to find the proper libdir. Trouble is, to fill out the variables, sysconfig itself uses two sources: a) compiled-in information from the binary, and b) Makefile items Makefile seems an obvious location for storing the libdir info, except, well, to FIND the makefile in the first place, we are using sysconfig variables you see where this is heading. So, given that sysconfig is the correct Primary Source for libdir info, we have three options to get it there: 1. compile it into the binary. sys.implementation.platlibdir seems as good as any -- i'm not completely convinced that this is a property of the _implementation_, but, well. 2. modify sysconfig.py at build time 3. guess it from the environment And options (2) and (3) seem wrong, so i'm going with (1) for now -- versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1294959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29145] failing overflow checks in replace_*
jan matejek added the comment: some instances are present in unicodeobject.c too -- Added file: http://bugs.python.org/file46156/unicode-overflow.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29145] failing overflow checks in replace_*
jan matejek added the comment:
No, your changes from issue 27473 are OK. However functions like
replace_interleave and replace_single_character etc. still use the broken code:
/* use the difference between current and new, hence the "-1" */
/* result_len = self_len + count * (to_len-1) */
product = count * (to_len-1);
if (product / (to_len-1) != count) {
PyErr_SetString(PyExc_OverflowError, "replace bytes is too long");
return NULL;
}
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29145>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29145] failing overflow checks in replace_*
jan matejek added the comment: It does, but "-fwrapv" is not automatically added when you specify custom OPT flags. I should have clarified that in the original report. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29145] failing overflow checks in replace_*
New submission from jan matejek: Related to http://bugs.python.org/issue1621 and http://bugs.python.org/issue27473 GCC 6 optimizes away broken overflow checks. This leads to segfaults on test_replace_overflow, at least for strings and bytearrays. -- components: Interpreter Core messages: 284588 nosy: matejcik priority: normal severity: normal status: open title: failing overflow checks in replace_* type: crash versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25420] "import random" blocks on entropy collection on Linux with low entropy
jan matejek added the comment: unlike #26839, however, there is no workaround for "import random". so i maintain that this issue is in fact very specific to the random module -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26252] Add an example to importlib docs on setting up an importer
Changes by jan matejek <jmate...@suse.cz>: -- nosy: +matejcik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25420] "import random" blocks on entropy collection on Linux with low entropy
jan matejek added the comment: let me reiterate that what I consider a bug is the fact that "import random" statement calls os.urandom (which per the proposed documentation may sometimes block) IOW, "import random" may sometimes block, even though it is not actually used at any point (could be pulled in through some dependencies) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25420] "import random" blocks on entropy collection on Linux with low entropy
jan matejek added the comment: attaching a first draft of what i'd consider a solution? not sure if this is the right way to go, and i don't know how to write a test for an import statement -- Added file: http://bugs.python.org/file40820/random.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25420] "import random" blocks on entropy collection on Linux with low entropy
jan matejek added the comment: On 18.10.2015 23:09, STINNER Victor wrote: > Hum ok, so your issue is specific to Linux. yes, should have specified that, sorry > Hum, the problem was already fixed some months/years ago: you must attach a > RNG virtio device to your VM. Python is just one example, a lot of > applications need entropy. i disagree that this is a good solution; similar to your haveged suggestion, this is a workaround. Unless a program specifically uses randomness, it should not need to read any entropy. For the python runtime itself, this is preventable by setting fixed PYTHONHASHSEED. For `random` module, there is no clean way to prevent it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23053] test_urllib2_localnet fails without ssl
New submission from jan matejek: The pep 476 commit to Python 2.7 [1] adds unconditional import ssl to test_urllib2_localnet.py. This causes the test to fail with an ImportError if ssl module is not built. Note that like 5 lines later, ssl is imported conditionally, and all the relevant tests are configured to skip if ssl is not present. So to fix this, all that is needed is to remove the import ssl line. Attached patch does just that. [1] https://hg.python.org/cpython/rev/fb83916c3ea1 -- components: Tests files: python-2.7-urllib2-localnet-ssl.patch keywords: patch messages: 232663 nosy: matejcik priority: normal severity: normal status: open title: test_urllib2_localnet fails without ssl type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file37454/python-2.7-urllib2-localnet-ssl.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16043] xmlrpc: gzip_decode has unlimited read()
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16043 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21070] test_xmlrpc waits forever instead of reporting failure
New submission from jan matejek: Testcases derived from BaseServerTestCase will launch a server process in a separate thread. This server will shut itself down after handling a specified number of requests. If the test case fails before performing enough requests, the server thread will continue to wait indefinitely. Fix for issue 14001 removed timeout from the wait on server thread, so now if a test fails, it will hang forever. To reproduce: put self.assertTrue(False) at start of any testcase. This matters in two cases: 1. If a testcase performs more than one request, an assertion failure on the first one will freeze the rest 2. If you make a mistake when writing a testcase, the test will hang instead of telling you that you did something wrong, and with no indication of what caused the problem (because your testcase won't be part of the backtrace when you break the wait) -- components: Tests messages: 214902 nosy: matejcik priority: normal severity: normal status: open title: test_xmlrpc waits forever instead of reporting failure type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21070 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21070] test_xmlrpc waits forever instead of reporting failure
Changes by jan matejek jmate...@suse.cz: -- versions: -Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21070 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20763] old sys.path_hooks importer does not work with Python 3.4.0rc1
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20763 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20354] tracemalloc causes segfault in make profile-opt
New submission from jan matejek: When compiling make profile-opt, the instrumented python executable segfaults upon exit, even though it appears to run fine. This breaks the build process, because make evaluates the segfault as if the respective compilation step failed. GDB yields the following backtrace for the crash: #0 gcov_exit () at ../../../libgcc/libgcov.c:397 #1 0x769b875f in __cxa_finalize (d=0x77c38a60) at cxa_finalize.c:56 #2 0x7771b983 in __do_global_dtors_aux () from ./libpython3.4m.so.1.0 #3 0x7fffdd60 in ?? () #4 0x77debe6a in _dl_fini () at dl-fini.c:252 Backtrace stopped: frame did not save the PC This problem first appears with changeset 6e2089dbc5ad [1] that introduced tracemalloc. It is still reproducible on today's tip. AFAICT, the mere presence of tracemalloc in the compiled executable causes this crash; I tried commenting out _PyTraceMalloc_Init from pythonrun.c and it did not help. To reproduce: ./configure --enable-shared make profile-opt i'm on x86_64 SUSE Linux, gcc version is 4.8.1 [1] hg.python.org/cpython/rev/6e2089dbc5ad -- messages: 208842 nosy: matejcik priority: normal severity: normal status: open title: tracemalloc causes segfault in make profile-opt type: crash versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20354 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
jan matejek added the comment: Yes. We still have a patch for two things: 1. fix setup.py script to look for libraries in correct (lib64) prefixes, and 2. fix values returned from sysconfig, to reflect that python resides in lib64 $prefix/lib is hardcoded in many places. Lib64 is probably not going away anytime soon, so it would be nice if this was solved once and for all ;) The good thing is that with sysconfig, we don't have to do much beyond teaching sysconfig about the right values. To reiterate, our current solution is to introduce sys.lib (and sys.arch, but that is never used anymore) that is either lib or lib64, and use this in place of the string lib wherever appropriate. We find the value for sys.lib through configure magic. -- Added file: http://bugs.python.org/file32529/Python-3.3.0b2-multilib.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
jan matejek added the comment: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 7.11.2013 16:56, Matthias Klose napsal(a): Matthias Klose added the comment: the patch in msg202343 is wrong, hardcoding lib64 on Debian/Ubuntu. This patch is provided for reference only - it works for us at SUSE. I'll be happy to spend some time improving it for general usage, if this has any chance of being commited. At least the configure check should check for lib64 as a directory and not a symlink, and only then default to lib64. Maybe this should be detected differently altogether. Perhaps by working with LIBDIR, which is known to configure? two other issues with the patch: - I would like to see any new OS-dependent locations in the sysconfig module, not the sys module. how would you propose to put the value into sysconfig in the first place? It seems to rely heavily on existing attributes from sys. - Please don't depend on uname for the autoconf check, but on the gnu host triplet. - Please don't add another `arch' attribute to sys. We already have enough of these in sysconfig. We don't use this one anymore, and i'm not entirely sure that we ever did. I am happy to drop it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSe7pdAAoJEIskb84DCy7LvwcP/2n74K2XDsRu7K6OV9S4SzDa v7vpDVhAgTBQlHglY+wavUQU2WLBlGyVEk2xHDV8WdI4zU7rAbn7XAW5URxznctq t/Ptvt0IsDAqONrF8ezg8/eTUkcP3nV2Hk90RNe0gliDH6uc0wekKUZzVaTObO1L 3vM8XfEtTQstmK1VxQVpYolUPZm8n7Fe8NEPA6A8bu8CU736cg+wWdbDrr6Mjowo OuO4b56J1P3BIQkBcOLe3mH20Bv8O03P9iNADwYHUOayvgthFWCmoDzh0Y1dQa9/ ynT+G9BuYyXOli6Yr15W0L8OFU+nwxByK81lEClz6UonCvoStnEWnXIN3JYW15Yb rNwb5HKNmKB16yx/RuV3WCvlKbg6ziMlfWGW6qTA1g0P0ivU+sRVQXv5gI8NHcQ9 /4jmaUh7Dr1T4KHujI57Z99kLQHvSlHEM3v4aT96IZNaPghkA+e7TjhMdHmvYtQz YoY75FIy0xVStdXzw8zbM2LVlKp8vxncrjYbuzJYgG1jiYwmF6gDoztXRVP/zwei PypIiui4QaQc32V5dCwpQYpAvpgCVHm6sGSO0HbLWSUK71M8f1YU2BPwvglHb6jh N9tmYfmahvQSyIFOZdb4C6HLlzEezENdYYIf7oMW07z8SOOLU+8eKP13dp6NWINP HCSU34LLYTfwnQ+27aMk =raBO -END PGP SIGNATURE- -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17928] PowerLinux getargs.c FETCH_SIZE endianness bug
jan matejek added the comment: The fix causes regression on my 64bit little-endian machine. It seems that while parsing the arguments, the length value overwrites part of the string pointer. -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17928 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17928] PowerLinux getargs.c FETCH_SIZE endianness bug
jan matejek added the comment: hmm, but it's caused by a private patch claiming that _testcapimodule.c is PY_SSIZE_T_CLEAN. sorry for the noise. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17928 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12466] sporadic failures of test_close_fds and test_pass_fds in test_subprocess
jan matejek added the comment: i don't think that's it, look at the result output in comment #183756: the list of fds is correct, except that they aren't closed as they should be. i can't reproduce the result when running code by hand, so it's either a race or an issue with test setup. so far i figured out that this goes away when patch from issue #16962 is reverted -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12466] sporadic failures of test_close_fds and test_pass_fds in test_subprocess
jan matejek added the comment: so apparently the problem was that we're using the borked original patch for issue #16962, instead of the fixed version that's actually in repos. (The d_type field was missing, so every filename had an extra character prepended to it. AFAICT, all mysterious circumstances that I reported would trace back to workplace mess, like running the test in a terminal with a different build than i thought...) sorry for taking your time, folks, the bug can be closed now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12466] sporadic failures of test_close_fds and test_pass_fds in test_subprocess
jan matejek added the comment: Ismail, the sem_open thing is because in autobuild you don't get /proc or somesuch - it's a problem of our buildsystem, otherwise the test passes. I can reproduce the failure in autobuild, but not separately yet. Will keep you posted, signs point to yet another misfeature of our buildsystem, but maybe it's something with test ordering... -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12466] sporadic failures of test_close_fds and test_pass_fds in test_subprocess
jan matejek added the comment: Not just yet, please. I can now reproduce the test_subprocess failures outside autobuild too. Interestingly, it's the reverse here: test_subprocess passes when /proc is not present, but fails when it is. I'm pretty sure that we hijacked a completely different bug with a similar symptom :e) but whatever. I'll just go ahead and debug this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12987] Demo/scripts/newslist.py has non-commercial license clause
New submission from jan matejek jmate...@suse.cz: from Demo/scripts/newslist.py : # Feel free to copy, distribute and modify this code for # non-commercial use. If you make any useful modifications, let me # know! # # (c) Quentin Stafford-Fraser 1994 # fra...@europarc.xerox.com qs...@cl.cam.ac.uk this is not very nice for commercial distros - we have to drop the file (for now anyway) i'm not sure what the right solution for upstream is - you might want to remove the file, ask Quentin to relicense it, or just acknowledge its existence and keep it -- components: Demos and Tools messages: 144088 nosy: matejcik priority: normal severity: normal status: open title: Demo/scripts/newslist.py has non-commercial license clause versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12801] C realpath not used by os.path.realpath
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12801 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1731717] race condition in subprocess module
jan matejek jmate...@suse.cz added the comment: please check my logic here, but the patched code seems to throw away perfectly valid return codes: in wait(), self._handle_exitstatus(sts) gets called unconditionally, and it resets self.returncode also unconditionally. now, if a _cleanup() already did _internal_poll and set self.returncode that way, it is lost when wait() catches the ECHILD, in the one place where it actually matters, by setting sts=0 for the _handle_exitstatus call IMHO it could be fixed by moving _handle_exitstatus to the try: section, and returning self.returncode or 0 or something like that -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1731717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9539] python-2.6.4: test failure in test_distutils due to linking to system libpython2.6
jan matejek jmate...@suse.cz added the comment: i was able to reproduce this in clean 2.7 Sandro, this is only reproducible on systems without python - so by definition, you can hit this only during installation as for issue8335, yes, i think that it's a duplicate distutils2 is irrelevant here, because you can only install it on top of existing python. The problem here is that stdlib's distutils must use the newly built libpython, *not* the systemwide one - a problem that distutils2 don't need to solve until they become part of stdlib. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9539 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6706] asyncore's accept() is broken
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9539] python-2.6.4: test failure in test_distutils due to linking to system libpython2.6
jan matejek jmate...@suse.cz added the comment: this affects 2.7 as well. the problem was introduced by r78136 which skips out of the directory containing newly built libpython2.7, so the linking command cannot find it in -L. and fails (unless a systemwide libpython is already present) the tests should probably specify that they want to link to a specific file, instead of relying on -lpython however, i have no idea how to do that in general, let alone within distutils :/ see also issue8335 -- nosy: +matejcik versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9539 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue858809] Use directories from configure rather than hardcoded
jan matejek jmate...@suse.cz added the comment: the problem this patch was solving is python libraries install into prefix/lib regardless of what is the correct local LIBDIR - which is obviously broken on systems where LIBDIR is something other than prefix/lib, most notable example being prefix/lib64 on current 64bit linuxes. but as far i can tell, this problem was fixed (to an extent) in 2.7 by partially applying this patch. SCRIPTDIR is still prefix/lib, but the correctness of that is up for a long and winded debate. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue858809 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8335] distutils test_build_ext's test_get_outputs fails in bootstrap environment
jan matejek jmate...@suse.cz added the comment: Tarek, the error output is this: /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lpython2.6 the chdir is the problem - because in an environment where you don't have an existing Python installation, you will not find -lpython2.6. the linker from unixccompiler.py:link() is this: ['gcc', '-pthread', '-shared', '/tmp/pythontest_eosQ1d/tempt/tmp/tmphIMDH2/foo.o', '-L.', '-lpython2.6', '-o', '/tmp/tmppAsk00/foo.so'] and since you're in new temporary directory, -L. does not include libpython2.6 (unless you copy it in that directory or change -L. to the right place) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8335 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8335] distutils test_build_ext's test_get_outputs fails in bootstrap environment
jan matejek jmate...@suse.cz added the comment: yes, reverting r72637 fixes this problem for me it reintroduces the original bug (there is some temporary file left behind), but i don't care about that -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8335 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8335] distutils test_build_ext's test_get_outputs fails in bootstrap environment
New submission from jan matejek jmate...@suse.cz: when running testsuite in a clean environment without pre-installed system python, test_distutils fail in test_build_ext, test_get_outputs: /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lpython2.6 LinkError: command 'gcc' failed with exit status 1 full traceback is below. this is most likely caused by change in r72637: http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/tests/test_build_ext.py?r1=72637r2=72636pathrev=72637 this changes compiler's working directory, so that it can no longer find libpython2.6.so with -L. (related to issue 6022 - the comments there point it out) not sure about proper fix - personally, i don't care much about leaving one more file in builddir, whereas i do care about tests passing in clean env, so for SUSE i'm reverting r72637 full traceback: test_distutils /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lpython2.6 collect2: ld returned 1 exit status test test_distutils failed -- Traceback (most recent call last): File /usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/tests/test_build_ext.py, line 261, in test_get_outputs cmd.run() File /usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/command/build_ext.py, line 340, in run self.build_extensions() File /usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/command/build_ext.py, line 449, in build_extensions self.build_extension(ext) File /usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/command/build_ext.py, line 531, in build_extension target_lang=language) File /usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/ccompiler.py, line 769, in link_shared_object extra_preargs, extra_postargs, build_temp, target_lang) File /usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/unixccompiler.py, line 259, in link raise LinkError, msg LinkError: command 'gcc' failed with exit status 1 -- assignee: tarek components: Distutils messages: 102552 nosy: matejcik, tarek severity: normal status: open title: distutils test_build_ext's test_get_outputs fails in bootstrap environment type: compile error versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8335 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6022] test_distutils leaves a 'foo' file behind in the cwd
jan matejek jmate...@suse.cz added the comment: see issue 8335 -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6022 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
jan matejek jmate...@suse.cz added the comment: well in our patch, at least, the directory is governed by sys.lib which is defined through configure. i don't understand the configure language well enough, but i'd assume that making it parametrized isn't too hard? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
jan matejek jmate...@suse.cz added the comment: for completenes, here's a patch that's in use in SUSE. it's advantage over Fedora's is that it works on both 32bit and 64bit installs -- Added file: http://bugs.python.org/file14726/Python-2.6.2-multilib.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6604] test_distutils subtest test_get_exe_bytes fails depending on execution order
New submission from jan matejek jmate...@suse.cz: test_bdist_wininst.py fails in non-windows environment, depending on the order of execution of tests in the test_distutils suite When this test is not run on windows, msvccompiler.py fails to load win32 registry modules and emits a warning-level message to the log. Depending on which tests run before this test, the log threshold might be set lower than WARN. in such case, The warning is actually printed, test runner detects it and fails the test (which otherwise passes). the attached patch sets log threshold to ERROR, silencing the warning and producing a happier test ;e) -- assignee: tarek components: Distutils files: python-2.6.2-test_distutils.patch keywords: patch messages: 91100 nosy: matejcik, tarek severity: normal status: open title: test_distutils subtest test_get_exe_bytes fails depending on execution order type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file14607/python-2.6.2-test_distutils.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6604 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5103] ssl.SSLSocket timeout not working correctly when remote end is hanging
jan matejek jmate...@suse.cz added the comment: i believe that the bug lies in bad implementation/backport of feature from 3.0 patch for issue1251. see this revision: http://svn.python.org/view/python/branches/release30-maint/Lib/ssl.py?r1=59339r2=59340 where the code was added for py3k branch. the logic behind that code is that when the timeout is zero (non-blocking socket), but the caller explicitly specifies that they want to block (which only happens when an application handles do_handshake by itself), timeout is set to None and reset to zero after the call. and this change was made to better support non-blocking sockets, the original patch ( http://svn.python.org/view/python/branches/py3k/Lib/ssl.py?view=diffr1=58996r2=58997 ) did not have this code at all on the other hand, what the 2.6 version does is not making any sense. i don't even see how it got to be that way instead of using py3k's do_handshake with optional block parameter - seeing as the change was made six months later and changed the API anyway the correct thing to do here is simply if do_handshake_on_connect: self.do_handshake() without the timeout setting/resetting stuff -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5103 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5103] ssl.SSLSocket timeout not working correctly when remote end is hanging
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5103 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6386] importing yields unexpected results when initial script is a symbolic link
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6386 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1298813] sysmodule.c: realpath() is unsafe
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1298813 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue891930] configure argument --libdir is ignored
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik nosy_count: 3.0 - 4.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue891930 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1019715] distutils ignores configure's --includedir
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik nosy_count: 3.0 - 4.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1019715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue858809] Use directories from configure rather than hardcoded
Changes by jan matejek jmate...@suse.cz: -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue858809 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue858809] Use directories from configure rather than hardcoded
jan matejek jmate...@suse.cz added the comment: well, seeing as redesign of distutils probably won't happen anytime soon... why don't we fix the obvious bug (broken configure) now and redesign distutils later? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue858809 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue858809] Use directories from configure rather than hardcoded
jan matejek jmate...@suse.cz added the comment: ...the patch is absolutely trivial, doesn't have any deep consequences and applies cleanly to head and all branches i know of. ...i wonder if the patch-fasttracking offer still applies... ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue858809 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5144] PySys_SetArgv has wrong documentation
New submission from jan matejek jmate...@suse.cz: documentation for PySys_SetArgv states that the function sets sys.argv, but fails to mention that it also resolves script's path and prepends it to sys.path. Or, in case no script was specified, it prepends empty string (which in versions 2.6 allowed relative imports from cwd) -- assignee: georg.brandl components: Documentation messages: 81067 nosy: georg.brandl, matejcik severity: normal status: open title: PySys_SetArgv has wrong documentation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5144 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5038] urrlib2/httplib doesn't reset file position between requests
New submission from jan matejek jmate...@suse.cz: since 2.6 httplib supports reading from file-like objects. Now consider the following situation: There are two handlers in urrlib2, first is plain http, second is basic auth. I want to POST a file to a service, and pass the open file object as data parameter to urllib2.urlopen. First handler is invoked, it sends the file data, but gets 401 Unauthorized return code and fails with that. Second handler in chain is invoked (at least that's how i understand urrlib2, please correct me if i'm talking rubbish). At that point the open file is at EOF, so empty data is sent. furthermore, the obvious solution you can't do this through urllib so go read the file yourself doesn't apply that well - the file object in question is actually a mmap.mmap instance. This code is in production since python 2.4. Until file object support in httplib was introduced, it worked fine, handling the mmap'ed file as a string. Now it is picked up as read()-able and this problem occurs. Only workaround to restore pre-2.6 behavior that comes to mind is building a wrapper class for the mmap object that hides its read() method. -- components: Library (Lib) messages: 80419 nosy: matejcik severity: normal status: open title: urrlib2/httplib doesn't reset file position between requests type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5038 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3620] test_smtplib is flaky
Changes by jan matejek [EMAIL PROTECTED]: -- nosy: +matejcik ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Changes by jan matejek [EMAIL PROTECTED]: -- nosy: +matejcik ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1424152 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3910] 2.6 regression in socket.ssl method
New submission from jan matejek [EMAIL PROTECTED]: python 2.6's compatibility socket.ssl() method does not handle 'sock' parameter in the same way. in 2.5, ssl() looked like this: def ssl(sock, keyfile=None, certfile=None): if hasattr(sock, _sock): sock = sock._sock return _realssl(sock, keyfile, certfile) in 2.6 the call is handed to ssl.sslwrap_simple, which then blindly does _ssl.sslwrap(sock._sock, 0, keyfile, certfile, CERT_NONE, PROTOCOL_SSLv23, None) instead of checking whether the sock is the socket itself or the socket object. This causes code that passes the socket directly to fail with AttributeError: '_socket.socket' object has no attribute '_sock' the attached patch fixes the behavior. -- components: Library (Lib) files: bug-sslwrap-simple.patch keywords: patch messages: 73434 nosy: matejcik severity: normal status: open title: 2.6 regression in socket.ssl method type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file11526/bug-sslwrap-simple.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3910 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
Changes by jan matejek [EMAIL PROTECTED]: -- nosy: +matejcik ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3886 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3879] 2.6 regression in urllib.getproxies_environment
Changes by jan matejek [EMAIL PROTECTED]: -- nosy: +matejcik ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3879 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3111] multiprocessing ppc Debian/ ia64 Ubuntu compilation error
jan matejek [EMAIL PROTECTED] added the comment: as it doesn't seem /dev/shm is the culprit Mounting /dev/shm seems to fix the problem in suse's autobuild (chroot) environment, so for me it actually was the culprit. Perhaps you should recheck your buildbots? -- nosy: +matejcik ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1179] [CVE-2007-4965] Integer overflow in imageop module
Changes by jan matejek [EMAIL PROTECTED]: -- nosy: +matejcik __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1179 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Changes by jan matejek [EMAIL PROTECTED]: -- nosy: +matejcik __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1044] tarfile insecure pathname extraction
jan matejek added the comment: if that can be considered official stance, it's fine by me. feel free to close the bug. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1044 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1044] tarfile insecure pathname extraction
jan matejek added the comment: no change to extract() ? otherwise looks good to me. if you don't object, i am applying this to SUSE's python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1044 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
