[issue31897] RecursionError in plistlib.loads

Serhiy Storchaka added the comment: Thank you for your report Ned. But there are no crashes. The term crash means a segmentation fault or similar error that causes the interpreter to exit immediately. -- assignee: -> serhiy.storchaka components: +Library (Lib) nosy: +serhiy.storchaka

[issue31897] Unexpected exceptions in plistlib.loads

Change by Serhiy Storchaka : -- title: RecursionError in plistlib.loads -> Unexpected exceptions in plistlib.loads ___ Python tracker ___ __

[issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files

Change by Tal Einat : -- pull_requests: +4139 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue31895] Native hijri calendar support

Gareth Rees added the comment: It is a substantial undertaking, requiring a great deal of expertise, to implement the Islamic calendar. The difficulty is that there are multiple versions of the calendar. In some places the calendar is based on human observation of the new moon, and so a datab

[issue31897] Unexpected exceptions in plistlib.loads

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +4140 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-

[issue31897] Unexpected exceptions in plistlib.loads

Change by Serhiy Storchaka : -- nosy: +ronaldoussoren ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://

[issue31114] 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used

Change by Xavier de Gaye : -- components: +Cross-Build -Build nosy: +Alex.Willmer stage: -> needs patch title: 'make install' fails when exec_prefix is '/' and DESTDIR not empty -> 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used versions: -Python 3.5 _

[issue31883] Cygwin: heap corruption bug in wcsxfrm

Erik Bray added the comment: Well, I agree there's an unfortunate trade-off here: One can skip the test, allowing the test suite to work on slightly older versions of Cygwin, from before this issue was fixed. However, I then lose regression testing on newer versions. My personal feeling in

[issue31897] Unexpected exceptions in plistlib.loads

Serhiy Storchaka added the comment: PR 4171 fixes the following errors: 1. OverflowError is raised by seek() for too large offsets of objects or the offset table. 2. Since read() past the file returns b'' and int.from_bytes() used for non-standard sizes accepts b'', bogus offsets and referen

[issue31883] Cygwin: heap corruption bug in wcsxfrm

Serhiy Storchaka added the comment: This is a problem of AppVeyor. It should update Cygwin to a bugfix release. 2.8.0 contains other bugs. -- resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue31114] 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used

Change by Xavier de Gaye : -- keywords: +patch pull_requests: +4141 stage: needs patch -> patch review ___ Python tracker ___ ___ Pyt

[issue31114] 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used

Xavier de Gaye added the comment: To test PR 4172 on linux one needs a chroot. The following test is run on archlinux using systemd-nspawn (a chroot on steroids, see https://wiki.archlinux.org/index.php/Systemd-nspawn). 1) Setup systemd-nspawn by installing arch-install-scripts and by using

[issue31895] Native hijri calendar support

Marc-Andre Lemburg added the comment: I agree with Steven: It's best to use a PyPI package for calendar support such as https://pypi.python.org/pypi/convertdate/. We only have the standard Gregorian calendar support in datetime and calendar modules. -- nosy: +lemburg ___

[issue25612] nested try..excepts don't work correctly for generators

Mark Shannon added the comment: Looking at the docs: https://docs.python.org/3.6/library/sys.html#sys.exc_info states: If the current stack frame is not handling an exception, the information is taken from the calling stack frame, or its caller, and so on until a stack frame is found tha

[issue31114] 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used

Xavier de Gaye added the comment: Clarification about the test results: On archlinux /bin is a symlink to /usr/bin, so on archlinux the value of sys.prefix is '/usr' instead of the expected '/'. This is because in Modules/getpath.c, 'argv0_path' is the directory of the link target when the ex

[issue31895] Native hijri calendar support

Gareth Rees added the comment: convertdate does not document which version of the Islamic calendar it uses, but looking at the source code, it seems that it uses a rule-based calendar which has a 30-year cycle with 11 leap years. This won't help Haneef, who wants the Umm al-Qura calendar. --

[issue25612] nested try..excepts don't work correctly for generators

Serhiy Storchaka added the comment: Thank you for the clarification Mark. I agree that the current behavior is well justified. Cython was fixed in https://github.com/cython/cython/commit/2d3392463b77eb550bd54a69bd28cc161947acb5. -- status: open -> closed

[issue31883] Cygwin: heap corruption bug in wcsxfrm

Erik Bray added the comment: Well, we'll see how long it takes me to get them to respond on that. If it's not too much trouble then I'll be happy to drop this issue. -- ___ Python tracker __

[issue31895] Native hijri calendar support

Haneef added the comment: Thanks @steven.daprano, yeah, it would be good to have support for other calendars as well. In my case, I use the Hijri Umm al-Qura, Gregorian and obviously UnixTime calendars. You're right, maybe it would be wiser to implement it in the PyPi first and then move it

[issue31895] Native hijri calendar support

Marc-Andre Lemburg added the comment: There are other PyPI packages available for this specific calendar as well, e.g. https://pypi.python.org/pypi/umalqurra/ Perhaps you could send Neil a PR to make the calculation more accurate ?! In any case, the stdlib is not meant to cover everything, on

[issue31900] UnicodeDecodeError in localeconv() makes test_float fail with glibc 2.26.90

New submission from Charalampos Stratakis : Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1484497 It seems that on the development branch of Fedora, when we updated glibc from 2.26 to 2.26.90, test_float_with_comma started failing. Details from the original bug report: Unde

[issue31245] Asyncio UNIX socket and SOCK_DGRAM

Yury Selivanov added the comment: New changeset fe4ea9cf1ee04f5a60e4ed928d8624b95b031e18 by Yury Selivanov (Quentin Dawans) in branch 'master': bpo-31245: Asyncio unix socket datagram (#3164) https://github.com/python/cpython/commit/fe4ea9cf1ee04f5a60e4ed928d8624b95b031e18 -- __

[issue31245] Asyncio UNIX socket and SOCK_DGRAM

Change by Yury Selivanov : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs

[issue31900] UnicodeDecodeError in localeconv() makes test_float fail with glibc 2.26.90

STINNER Victor added the comment: I can reproduce the bug with Python 3.6 on Fedora 26 and these locales: * LC_ALL = LC_CTYPE = fr_FR (encoding = ISO8859-1) * LC_NUMERIC= es_MX.utf8 (encoding = UTF-8) Good: LC_NUMERIC = LC_CTYPE = LC_ALL = "es_MX.utf8" haypo@selma$ env -i python3 -c 'import

[issue31900] localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Change by STINNER Victor : -- title: UnicodeDecodeError in localeconv() makes test_float fail with glibc 2.26.90 -> localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding ___ Python tracker

[issue31900] localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Change by STINNER Victor : -- keywords: +patch pull_requests: +4142 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue31900] localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Change by STINNER Victor : -- versions: -Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue31900] localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Charalampos Stratakis added the comment: Tested the PR on a system with glibc 2.26.90 where the test was failing, and it successfully passed. -- ___ Python tracker ___ ___

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Change by STINNER Victor : -- title: localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding -> localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding ___ Python tracker

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Serhiy Storchaka added the comment: This is a duplicate of issue28604. See also issue25812. -- nosy: +serhiy.storchaka ___ Python tracker ___ __

[issue31273] [2.7] unittest: Unicode support in TestCase.skip

STINNER Victor added the comment: > Could be fixed with by changing to unicode(e) Replacing str(e) with unicode(e) can introduce Unicode errors regressions. I'm not confident in doing such change late in the old 2.7 branch. I suggest you to only use native strings (byte strings, "str" type) i

[issue31901] atexit callbacks only called for current subinterpreter

New submission from Marcel Plch : `Py_FinalizeEx()` only executes callbacks from the subinterpreter from which Py_FinalizeEx is called. What is the expected behavior here? Should the callbacks be specific to individual subinterpreters? -- components: Extension Modules messages: 305233

[issue31273] [2.7] unittest: Unicode support in TestCase.skip

Serhiy Storchaka added the comment: I concur with Victor. Unlikely this affects many people since skipping messages usually are ASCII strings. As a workaround you can implement your own skip() method that encodes unicode to 8-bit string. def skip(self, reason): if isinstance(reas

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Stefan Krah added the comment: Same as #7442, I think. -- nosy: +skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: Oh wow, this bug is older than what I expected :-) I added support for non-ASCII thousands separator in 2012: https://bugs.python.org/issue13706#msg151733 -- ___ Python tracker

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: inconsistent_locale_encodings.py of closed issue #7442 is interesting: I copy it here. -- Added file: https://bugs.python.org/file47246/inconsistent_locale_encodings.py ___ Python tracker

[issue31902] Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef, AsyncWith

Change by Guo Ci Teo : -- components: Library (Lib) nosy: guoci priority: normal severity: normal status: open title: Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef, AsyncWith versions: Python 3.5, Python 3.6, Python 3.7 ___ Python tracker

[issue31902] Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef, AsyncWith

Change by Guo Ci Teo : -- keywords: +patch pull_requests: +4143 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list m

[issue30333] test_multiprocessing_forkserver: poll() failed on AMD64 FreeBSD CURRENT Non-Debug 3.5

STINNER Victor added the comment: I didn't see this bug recently. I fixed many bugs in the meanwhile, so maybe I fixed the bug? See for example https://haypo.github.io/contrib-cpython-2017q3-part2.html -- resolution: -> out of date stage: -> resolved status: open -> closed

[issue29205] col_offset for AsyncFunctionDef AST nodes is wrong

Change by Guo Ci Teo : -- pull_requests: +4144 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue31222] datetime.py implementation of .replace inconsistent with C implementation

Change by Paul Ganssle : -- keywords: +patch pull_requests: +4145 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue31222] datetime.py implementation of .replace inconsistent with C implementation

Paul Ganssle added the comment: Some time ago this was fixed in pypy3: https://bitbucket.org/pypy/pypy/issues/2635/datetimereplace-always-returns I made a PR fixing this for `datetime`, `date` and `time`. -- ___ Python tracker

[issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows

Change by Jan Gosmann : -- nosy: +jgosmann ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

Change by STINNER Victor : -- title: test_multiprocessing_fork failure on FreeBSD -> test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD ___ Python tracker ___

[issue31629] test_multiprocessing_fork failure on FreeBSD

STINNER Victor added the comment: test_many_processes() was added by bpo-30589. Antoine Pitrou commented: "In the end, I'm glad I added a stress test (test_many_processes) as part of this issue.". I confirm that test_multiprocessing_fork fails with "./python -m test -vuall" on FreeBSD CURREN

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

STINNER Victor added the comment: Latest change in test_many_processes(): commit e6cfdefa0c2f5bda177e49b228c2c7528f7c239c of bpo-31510 which was specific to macOS. -- ___ Python tracker

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

STINNER Victor added the comment: See also commit c08177a1ccad2ed0d50898c2731b518c631aed14 of bpo-30703. -- ___ Python tracker ___ _

[issue31304] Update doc for starmap_async error_back kwarg

Mariatta Wijaya added the comment: New changeset 11225753a89c2907bb717e6c050fe907e5e11829 by Mariatta (Pablo Galindo) in branch 'master': bpo-31304: Update starmap_async documentation. (GH-4168) https://github.com/python/cpython/commit/11225753a89c2907bb717e6c050fe907e5e11829 -- nosy

[issue31304] Update doc for starmap_async error_back kwarg

Change by Roundup Robot : -- pull_requests: +4147 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue31304] Update doc for starmap_async error_back kwarg

Mariatta Wijaya added the comment: New changeset 2702380870b63ebe0161dfa29a2d0a3de02401b4 by Mariatta (Miss Islington (bot)) in branch '3.6': bpo-31304: Update starmap_async documentation. (GH-4168) (GH-4177) https://github.com/python/cpython/commit/2702380870b63ebe0161dfa29a2d0a3de02401b4 -

[issue31304] Update doc for starmap_async error_back kwarg

Mariatta Wijaya added the comment: This has been fixed. Thanks! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ _

[issue31903] `_scproxy` calls SystemConfiguration functions in a way that can cause deadlocks

New submission from Maxime Belanger : Through the use of various Python packages (such as `pyobjc`), it is possible for a deadlock to occur due to how `_scproxy.c` calls `SCDynamicStoreCopyProxies`. In more recent versions of macOS (10.7+), this function can block on acquiring a lock deep ins

[issue31904] Python should support VxWorks RTOS

New submission from Brian Kuhl : With the trend to use REST APIs between the cloud and the IoT there is increasing interest in Python on embedded devices. Cloud developer’s typical release a reference REST implementation of JSON and/or Python on Linux and leave it to the device developer to a

[issue31114] 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used

Xavier de Gaye added the comment: Actually, sys.prefix is '/usr' because '/usr/bin' is in PATH while '/bin' is not in PATH. After adding '/bin' to the start of PATH, then sys.prefix becomes '/.' when Python is run as 'python3'. The confusion comes from the '/bin' symlink (archlinux is not a p

[issue31903] `_scproxy` calls SystemConfiguration functions in a way that can cause deadlocks

Change by Max Bélanger : -- keywords: +patch pull_requests: +4148 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue31904] Python should support VxWorks RTOS

Change by Brian Kuhl : -- keywords: +patch pull_requests: +4149 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list m

[issue31905] IPv4Networkcontains raises exception on None

New submission from Gerard Weatherby : Given a IPvNetwork network if x in network: ... raises an AttributeError instead of returning False. -- components: Library (Lib) files: ne.py messages: 305250 nosy: Gerard Weatherby priority: normal severity: normal status: open title: IPv4Netw

[issue31905] IPv4Networkcontains raises exception on None

Change by Roundup Robot : -- keywords: +patch pull_requests: +4150 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-lis

[issue31905] IPv4Networkcontains raises exception on None

R. David Murray added the comment: It is not obvious that this is a bug. Why should None be a valid value for 'in network'? -- nosy: +r.david.murray ___ Python tracker ___ __

[issue31906] String literals next to each other does not cause error

New submission from Sam Lobel : This seems too obvious to have been missed, but also too strange behaviour to be on purpose. The following works for some reason (note there's no + between the words) >>> variable = "first" "second" >>> print(variable) "firstsecond" In a file, if you're missing

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

STINNER Victor added the comment: Running these two tests is enough to reproduce the issue: test.test_curses.TestCurses.test_new_curses_panel test.test_multiprocessing_fork.WithProcessesTestProcess.test_many_processes Command: CURRENT-amd64% ./python -m test -vuall test_curses test_multiproc

[issue31906] String literals next to each other does not cause error

Change by Sam Lobel : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue31897] Unexpected exceptions in plistlib.loads

Ned Williamson added the comment: Thank you for the quick PR! I will report as behavior next time. I'm also following the library reference and reporting only unexpected exceptions. I trust you to reject any bugs that are expected functionality. I may follow up with additional testcases once

[issue31906] String literals next to each other does not cause error

Dmitry Kazakov added the comment: This is a documented feature: https://docs.python.org/3/reference/lexical_analysis.html#string-literal-concatenation And yes, it was discussed before: https://mail.python.org/pipermail/python-ideas/2013-May/020527.html -- nosy: +vaultah

[issue31906] String literals next to each other does not cause error

Mariatta Wijaya added the comment: What Dmitry said :) I'm closing this as "not a bug". -- nosy: +Mariatta resolution: -> not a bug stage: -> resolved status: open -> closed versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python trac

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

STINNER Victor added the comment: The bug can be reproduced with attached bug.py. With "curses.initscr(); curses.endwin()", the exit code becomes 1. Without, the child processes exits with code -15 (-SIGTERM). -- Added file: https://bugs.python.org/file47248/bug.py __

[issue31739] socket.close recommended but not demonstrated in same-page example code

Change by Roundup Robot : -- keywords: +patch pull_requests: +4152 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-lis

[issue31739] socket.close recommended but not demonstrated in same-page example code

Adam Mitchell added the comment: I submitted a pull request, #4181, to fix this issue. I am now waiting for my contributor agreement to be approved. -- nosy: +AdamMitchell ___ Python tracker

[issue31739] socket.close recommended but not demonstrated in same-page example code

Change by Todd Rovito : -- nosy: +Todd.Rovito ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

Pablo Galindo Salgado added the comment: I have tracked the issue down to the call inside the call to initscr in _cursesmodule.c. The issue *seems* related to the fact that all processes are sharing the same initialization of the curses internal structures, that (probably) is also related to

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

Pablo Galindo Salgado added the comment: Also, it seems that calling initscr registers signal handlers for SIGTERM: Without calling initscr: ... rt_sigaction(SIGINT, {sa_handler=0x55d9351a9155, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f7d22b36da0}, {sa_handler=SIG_DFL, sa_mask=[],

[issue31905] IPv4Networkcontains raises exception on None

Eric V. Smith added the comment: I agree with David. And since the PR says "not other", then it makes even less sense, since it's checking for any False-y object. I recommend closing this as "not a bug". -- nosy: +eric.smith ___ Python tracker

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

Change by STINNER Victor : -- keywords: +patch pull_requests: +4154 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue31907] Clarify error message when attempting to call function via str.format()

New submission from mickey695 : PEP 3101 states that format strings may only use the "."(getattr) or the "[]" (getitem) operators to address either attributes or items of parameters. Should a programmer attempt to, for example, call a function of a parameter as follows: >>> d = datetime.datet

[issue31629] Running test_curses on FreeBSD changes signal handlers

STINNER Victor added the comment: Pablo Galindo Salgado: > Also, it seems that calling initscr registers signal handlers for SIGTERM: > (...) The problem is that endwin() doesn't restore the old handler. Attached PR 4183 fixes the bug, it saves/restores signal handlers: ./python -m test -vua

[issue31852] Crashes with lines of the form "async \"

STINNER Victor added the comment: New changeset 690c36f2f1085145d364a89bfed5944dd2470308 by Victor Stinner (Pablo Galindo) in branch '3.6': [3.6] bpo-31852: Fix segfault caused by using the async soft keyword (GH-4122) https://github.com/python/cpython/commit/690c36f2f1085145d364a89bfed5944dd2

[issue31852] Crashes with lines of the form "async \"

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue31852] Crashes with lines of the form "async \"

STINNER Victor added the comment: Thank you Alexandre Hamelin for the bug report and Pablo Galindo for the fix ;-) -- ___ Python tracker ___ ___

[issue31852] Crashes with lines of the form "async \"

Alexandre Hamelin added the comment: Awesome work, thanks to you! Would it also be the case for 'await' ? -- ___ Python tracker ___ ___

[issue31908] trace module cli does not write cover files

New submission from Michael Selik : The trace module command-line utility doesn't write cover files. I've noticed this issue for some years now. It works fine in Python 2. When using Python 3, no ".cover" files are written, regardless of how "--coverdir" is specified. mike on macbook in ~/

[issue31904] Python should support VxWorks RTOS

Change by Brian Kuhl : -- pull_requests: +4155 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue31908] trace module cli does not write cover files

Raymond Hettinger added the comment: It worked in Python 3.4, but not afterwards. -- components: +Library (Lib) nosy: +rhettinger versions: +Python 3.5, Python 3.7 ___ Python tracker _

[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM

New submission from Ilya Kulakov : Python 3.5 and 3.6 in their corresponding configure.ac try to detect presence of sys_getrandom. The result is written into the `HAVE_GETRANDOM_SYSCALL` definition. libexpact checks for `HAVE_SYSCALL_GETRANDOM` and since it's not defined, does not use it. Thi

[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM

Change by Roundup Robot : -- keywords: +patch pull_requests: +4156 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-lis

[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM

Benjamin Peterson added the comment: This is supposed to be handled by setup.py defining XML_POOR_ENTROTPY. Are you doing something non-standard? -- nosy: +benjamin.peterson ___ Python tracker __

[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM

Ilya Kulakov added the comment: Just compiling Python 3.6.3 from sources on Ubuntu 16.04 Is there any reason to fall back to XML_POOR_ENTROTPY when proper source is actually available? -- ___ Python tracker ___

[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM

Ilya Kulakov added the comment: nvm my last question. My process is as per README: ./configure && make I'll take a further look at what's wrong. -- ___ Python tracker ___ ___

[issue31629] Running test_curses on FreeBSD changes signal handlers

Serhiy Storchaka added the comment: Thank you Victor and Pablo! Great work! -- ___ Python tracker ___ ___ Python-bugs-list mailing l