[issue39482] Write 2to3 fixer for MutableMapping
New submission from Orion Poplawski : fail2ban currently relies on 2to3 for python 3 support. Build now fails with python 3.9: Traceback (most recent call last): File "/builddir/build/BUILD/fail2ban-0.11.1/bin/fail2ban-testcases", line 61, in tests = gatherTests(regexps, opts) File "./fail2ban/tests/utils.py", line 373, in gatherTests from . import clientreadertestcase File "./fail2ban/tests/clientreadertestcase.py", line 34, in from ..client.jailreader import JailReader, extractOptions, splitWithOptions File "./fail2ban/client/jailreader.py", line 34, in from .actionreader import ActionReader File "./fail2ban/client/actionreader.py", line 31, in from ..server.action import CommandAction File "./fail2ban/server/action.py", line 33, in from collections import MutableMapping ImportError: cannot import name 'MutableMapping' from 'collections' (/usr/lib64/python3.9/collections/__init__.py) -- components: 2to3 (2.x to 3.x conversion tool) messages: 360936 nosy: opoplawski priority: normal severity: normal status: open title: Write 2to3 fixer for MutableMapping type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders
New submission from Orion Poplawski: Trying to build Python 3.4.0 for Fedora we are seeing test_asyncio test_subprocess_send_signal hang every time, on all architectures. Unfortunately I cannot reproduce this locally. These builds are done inside of chroots, and the host has the kernel version 3.12.8-300.fc20 which is used for all build targets. We see hangs building for Fedora Rawhide and RHEL 7. We do *not* see hangs on our COPR builders which among other possible differences use RHEL6 hosts with kernel 2.6.32-358.el6. I've attached an strace of the hanging test. The calling process seems to be stuck in epoll_wait(). Tried using the watchdog patch from issue #19652 but that doesn't seem to manage to kill things. In fact, the tests are never killed but the 1 hour timeout in the test runner. -- files: test_signal.out messages: 216392 nosy: opoplawski priority: normal severity: normal status: open title: test_asyncio: test_subprocess_send_signal hangs on Fedora builders type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file34899/test_signal.out ___ Python tracker <http://bugs.python.org/issue21247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders
Orion Poplawski added the comment: Hmm, looking at things a little closer, it looks like the SIGHUP is arriving very early, perhaps too early? -- ___ Python tracker <http://bugs.python.org/issue21247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders
Orion Poplawski added the comment: It may also be possible that something has set the SIGHUP handler to SIG_IGN when the test is run. -- ___ Python tracker <http://bugs.python.org/issue21247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders
Orion Poplawski added the comment: Looks like in the Fedora koji builds, the SIGHUP sigaction is set to SIG_IGN, which causes the processes that the python tests are trying to kill with SIGHUP not to die. Perhaps the koji builders should not be doing that, perhaps the python tests should reset the SIGHUP sigaction to SIG_DFL. -- ___ Python tracker <http://bugs.python.org/issue21247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders
Orion Poplawski added the comment: We have determined that the koji builder is indeed setting the SIGHUP sigaction to SIG_IGN, which the python test is inheriting, and are working on trying to get that fixed. However, it may be worth considering something like https://github.com/pexpect/pexpect/commit/1fbfddf33d196fd1f211fb95efdaa810b8b5dad3 in the python tests to ensure that the test run properly in situations like this (I can imagine someone running them under "nohup"). -- ___ Python tracker <http://bugs.python.org/issue21247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders
Orion Poplawski added the comment: That appears to work. Thanks! -- ___ Python tracker <http://bugs.python.org/issue21247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders
Orion Poplawski added the comment: I'm really sorry, I thought I had done the test build properly, but a second attempt has resulted in the same hang: http://koji.fedoraproject.org/koji/taskinfo?taskID=7165208 So I don't think it does the trick. -- ___ Python tracker <http://bugs.python.org/issue21247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19884] Importing readline produces erroneous output
Orion Poplawski added the comment: I'm still seeing this test failure on EL6.8 with python 3.4.5: [268/391] test_readline testHistoryUpdates (test.test_readline.TestHistoryManipulation) ... ok test_init (test.test_readline.TestReadline) ... test test_readline failed FAIL == FAIL: test_init (test.test_readline.TestReadline) -- Traceback (most recent call last): File "/builddir/build/BUILD/Python-3.4.5/Lib/test/test_readline.py", line 57, in test_init self.assertEqual(stdout, b'') AssertionError: b'\x1b[?1034h' != b'' -- Ran 2 tests in 0.111s FAILED (failures=1) With readline-devel-6.0-4.el6.x86_64. -- nosy: +opoplawski ___ Python tracker <https://bugs.python.org/issue19884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19884] Importing readline produces erroneous output
Orion Poplawski added the comment: Updating the version check to 6.1 as in the patch from Martin certainly avoids the failing test. -- ___ Python tracker <https://bugs.python.org/issue19884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17706] Segfault in PyErr_SetObject
New submission from Orion Poplawski:
I'm seeing a segfault running the scipy 0.12 tests against numpy 1.7.1 with
python 3.3.1. The crash is here:
test_ticket_1645 (test_lapack.TestRegression) ...
Program received signal SIGSEGV, Segmentation fault.
PyErr_SetObject (exception=exception@entry=,
value=value@entry='On entry to SGERQF parameter number 7 had an illegal
value')
at /usr/src/debug/Python-3.3.1/Python/errors.c:67
67 exc_value = tstate->exc_value;
(gdb) print tstate
$1 = (PyThreadState *) 0x0
So it appears that PyThreadState_GET() is returning NULL and PyErr_SetOject()
is not handling that condition. Not sure if this is a sign of another issue.
(gdb) bt
#0 PyErr_SetObject (exception=exception@entry=,
value=value@entry='On entry to SGERQF parameter number 7 had an illegal
value')
at /usr/src/debug/Python-3.3.1/Python/errors.c:67
#1 0x77c93bbf in PyErr_SetString (exception=,
string=string@entry=0x7fff8160 "On entry to SGERQF parameter number 7
had an illegal value") at /usr/src/debug/Python-3.3.1/Python/errors.c:125
#2 0x7fffeea223f1 in xerbla_ (srname=, info=)
at numpy/linalg/python_xerbla.c:35
#3 0x7fffee4925d9 in sgerqf_ () from /usr/lib64/atlas/liblapack.so.3
#4 0x7fffe6d5a56f in f2py_rout__flapack_sgerqf ()
from
/scratch/orion/redhat/BUILDROOT/scipy-0.12.0-1.fc20.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/_flapack.cpython-33m.so
#5 0x77bda0cc in PyObject_Call (func=func@entry=,
arg=arg@entry=(,), kw=kw@entry={'lwork':
2})
at /usr/src/debug/Python-3.3.1/Objects/abstract.c:2082
#6 0x77c859b2 in ext_do_call (nk=, na=,
flags=, pp_stack=0x7fff85f8, func=)
at /usr/src/debug/Python-3.3.1/Python/ceval.c:4406
#7 PyEval_EvalFrameEx (
f=f@entry=Frame 0x11ae310, for file /usr/lib64/python3.3/unittest/case.py,
line 173, in handle
(self=<_AssertRaisesContext(test_case=: 'assertMultiLineEqual',
: 'assertListEqual', : 'assertDictEqual', :
'assertTupleEqual', : 'assertSetEqual', : 'assertSetEqual'}) at remote 0x7fffecd1c390>, msg=None,
obj_name='', expected=,
expected_regex=None) at remote 0x7fffe0716cd0>, name='assertRaises',
callable_obj=, args=(,), kwargs={'lwork': 2}),
throwflag=throwflag@entry=0) at
/usr/src/debug/Python-3.3.1/Python/ceval.c:2744
#8 0x77c879cc in fast_function (nk=, na=5, n=5,
pp_stack=0x7fff8770, func=)
at /usr/src/debug/Python-3.3.1/Python/ceval.c:4179
#9 call_function (oparg=, pp_stack=0x7fff8770)
at /usr/src/debug/Python-3.3.1/Python/ceval.c:4112
..
it goes on a long ways down.
--
components: Interpreter Core
messages: 186684
nosy: opoplawski
priority: normal
severity: normal
status: open
title: Segfault in PyErr_SetObject
type: crash
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue17706>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17706] Segfault in PyErr_SetObject
Orion Poplawski added the comment: Despite numpy not calling the library properly, it stills seems to me that python should not segfault due to not handling a null pointer. But thanks for the help. -- ___ Python tracker <http://bugs.python.org/issue17706> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27004] Handle script shbang options
New submission from Orion Poplawski: Fedora would like to enforce that python scripts installed into /usr/bin use the "-s" option. We have tried to enforce this by doing: python setup.py build --executable '/usr/bin/python2 -s' However, as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1335203 this breaks scripts that already have options in them as the options are tacked onto the end, e.g.: #!/usr/bin/python2 -s -E Which linux doesn't handle. It seems we have a couple options: - Replace the entire shbang line with the argument to --executable - Try to merge options into a single one (-sE) - Have a separate option, say --executable-args to specify the options. Although the question still remains as to whether or not to replace the existing option or append. -- components: Distutils messages: 265343 nosy: dstufft, eric.araujo, opoplawski priority: normal severity: normal status: open title: Handle script shbang options versions: Python 2.7, Python 3.6 ___ Python tracker <http://bugs.python.org/issue27004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10
Orion Poplawski added the comment: We're running into this building python 3.4.3 on EL6 ppc64. The os kernel is 4.7.2-201.fc24.ppc64, but the EL6 chroot kernel-headers are 2.6.32-642.4.2.el6. Any progress here? -- nosy: +opoplawski ___ Python tracker <http://bugs.python.org/issue21131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
