[issue40170] [C API] Prepare PyTypeObject structure for a stable ABI: avoid accessing members in the public API
Change by Michael Felt : -- nosy: -Michael.Felt ___ Python tracker <https://bugs.python.org/issue40170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38021] pep425 tag for AIX is inadequate
New submission from Michael Felt :
PEP425 stats the platform tag is what distutils.util.get_platform() (and
sysconfig.get_platform()) returns.
By that definition - anything is okay, as long as something is returned.
However, in practice, it is insufficient. Simplest case - there is no
indication of the fitness of the running Python. This, by itself, may be a
reason that VARs and others have never attempted to develop binary (compatible)
eggs or wheels.
Looking further at missed potential - AIX has an algorithm that can be used to
permit a forward (binary) compatible ABI for packaging. The current state of
packaging for AIX is to create an RPM or INSTALLP formatted package - and
install that. Even pure-python modules must be packaged in this way - to
satisfy the "binary" dependencies.
For a binary compatible algorithm to be possible changes will be needed in pypa
tools. However, rather than "patch" three sets of tools to correct the
inadequacy of the current PEP425 tag for AIX I propose to tag AIX as:
AIX-VRTL-YYWW-BT or
AIX.{}{}{:02d}.{}.{}".format(v,r,int(tl),bd,sz)
where v=version, r=release, tl=technology_level, bd=builddate, and sz=fitness
(32|64).
Further, rather than place this code "inline" in distutils or sysconfig create
a new support module for AIX - similar to the _osx_support module (I.e.
_aix_support).
--
components: Distutils, Library (Lib)
messages: 351096
nosy: Michael.Felt, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: pep425 tag for AIX is inadequate
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue38021>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38021] pep425 tag for AIX is inadequate
Michael Felt added the comment: Thank you Ned. Not a justification perhaps, but a way to specify that it is support. Three+ years ago when I first worked on something for Lib/ctypes to get find_library() et al working for AIX I was also asked to add it as _aix.py similar to the macos support (with, iirc is more than just a single file) being separate from util.py. To me, it just seemed that is the way it is done to keep maintenance of the core (external) code cleaner. After I post the PR I welcome your perspective on the sense or nonsense of having a separate _xxx_support.py file (where _xxx could be any platform, not merely osx or aix. -- ___ Python tracker <https://bugs.python.org/issue38021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38021] pep425 tag for AIX is inadequate
Change by Michael Felt : -- keywords: +patch pull_requests: +15337 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15678 ___ Python tracker <https://bugs.python.org/issue38021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38021] pep425 tag for AIX is inadequate
Michael Felt added the comment:
When testing the PR with --with-pydebug I started getting the following error:
root@x066:[/data/prj/python/git/pr-test]./python '-X' 'tracemalloc' -m test
test_venv
Run tests sequentially
0:00:00 [1/1] test_venv
test test_venv failed -- Traceback (most recent call last):
File "/data/prj/python/git/pr-test/Lib/test/test_venv.py", line 501, in
test_with_pip
self.do_test_with_pip(False)
File "/data/prj/python/git/pr-test/Lib/test/test_venv.py", line 459, in
do_test_with_pip
self.assertEqual(err, "")
AssertionError: '/data/prj/python/git/pr-test/Lib/_aix_sup[277 chars]t,\n' != ''
- /data/prj/python/git/pr-test/Lib/_aix_support.py:47: ResourceWarning:
unclosed file <_io.TextIOWrapper name=4 encoding='ISO8859-1'>
- return aix_pep425()
- Object allocated at (most recent call last):
- File "/data/prj/python/git/pr-test/Lib/subprocess.py", lineno 837
- self.stdout = io.TextIOWrapper(self.stdout,
test_venv failed in 34 sec 401 ms
== Tests result: FAILURE ==
1 test failed:
test_venv
Total duration: 34 sec 485 ms
Tests result: FAILURE
+++ capturing some debug output:
root@x066:[/data/prj/python/git/pr-test]cat /tmp/test_venv.debug
env:/tmp/tmppcl06489/bin/python '-X', 'tracemalloc', '-W',
'ignore::DeprecationWarning', '-I', -m pip --version
err:/data/prj/python/git/pr-test/Lib/_aix_support.py:47: ResourceWarning:
unclosed file <_io.TextIOWrapper name=4 encoding='ISO8859-1'>
return aix_pep425()
Object allocated at (most recent call last):
File "/data/prj/python/git/pr-test/Lib/subprocess.py", lineno 837
self.stdout = io.TextIOWrapper(self.stdout,
out:pip 19.2.1 from /tmp/tmppcl06489/lib/python3.9/site-packages/pip (python
3.9)
+++
I thought -
p = Popen()
p.wait()
that the call p.wait() was waiting for the process to complete (and close
files).
Apparently, that is not the case.
Note: changing p.wait() to p.wait is not the solution: the message changes to:
AssertionError: '/data/prj/python/git/pr-test/Lib/subproce[609 chars]t,\n' != ''
- /data/prj/python/git/pr-test/Lib/subprocess.py:933: ResourceWarning:
subprocess 11337774 is still running
- _warn("subprocess %s is still running" % self.pid,
- Object allocated at (most recent call last):
- File "/data/prj/python/git/pr-test/Lib/_aix_support.py", lineno 35
- p = Popen(["/usr/bin/lslpp", "-Lqc", "bos.mp64"],
- /data/prj/python/git/pr-test/Lib/_aix_support.py:47: ResourceWarning:
unclosed file <_io.TextIOWrapper name=4 encoding='ISO8859-1'>
- return aix_pep425()
- Object allocated at (most recent call last):
- File "/data/prj/python/git/pr-test/Lib/subprocess.py", lineno 837
- self.stdout = io.TextIOWrapper(self.stdout,
root@x066:[/data/prj/python/git/pr-test]cat /tmp/test_venv.debug
env:/tmp/tmp8wpnz193/bin/python '-X', 'tracemalloc', '-W',
'ignore::DeprecationWarning', '-I', -m pip --version
err:/data/prj/python/git/pr-test/Lib/subprocess.py:933: ResourceWarning:
subprocess 11337774 is still running
_warn("subprocess %s is still running" % self.pid,
Object allocated at (most recent call last):
File "/data/prj/python/git/pr-test/Lib/_aix_support.py", lineno 35
p = Popen(["/usr/bin/lslpp", "-Lqc", "bos.mp64"],
/data/prj/python/git/pr-test/Lib/_aix_support.py:47: ResourceWarning: unclosed
file <_io.TextIOWrapper name=4 encoding='ISO8859-1'>
return aix_pep425()
Object allocated at (most recent call last):
File "/data/prj/python/git/pr-test/Lib/subprocess.py", lineno 837
self.stdout = io.TextIOWrapper(self.stdout,
out:pip 19.2.1 from /tmp/tmp8wpnz193/lib/python3.9/site-packages/pip (python
3.9)
I was able to resolve the issue by changing Popen() to run():
oot@x066:[/data/prj/python/git/pr-test]diff -u
/data/prj/python/git/pr-test/Lib/_aix_support.py /tmp/_aix_support.py
--- /data/prj/python/git/pr-test/Lib/_aix_support.py2019-09-08
16:24:51.0 +
+++ /tmp/_aix_support.py2019-09-08 16:17:14.0 +
@@ -1,7 +1,7 @@
"""Shared AIX support functions."""
import sys
- from subprocess import Popen, PIPE, DEVNULL
+ from subprocess import run
from sysconfig import get_config_var as get_var
_is_32bit = sys.maxsize == 2147483647
@@ -32,10 +32,9 @@
The pep425 platform tag for AIX becomes:
AIX.VRTL.YYWW.SZ, e.g., AIX.6107.1415.32
"""
- p = Popen(["/usr/bin/lslpp", "-Lqc", "bos.mp64"],
- universal_newlines=True, stdout=PIPE, stderr=DEVNULL)
- _lslppLqc = p.stdout.read().strip().split(":"
[issue36210] correct AIX logic in setup.py for (non-existant) optional extensions
Michael Felt added the comment: Hi all, Now that I have finally noticed that the 3.8 branches are active for AIX bots I see something that I had always thought was in the 3.8 branch, but is not yet. https://github.com/python/cpython/pull/12202 Seems the backport never succeeded. Although, iirc it was, then, very near the day that "3.9" started. So, surprised that it failed the backport. Can that process be started again, or will I need to do this manually, so that the PPC64 bot also passes. -- ___ Python tracker <https://bugs.python.org/issue36210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36210] correct AIX logic in setup.py for (non-existant) optional extensions
Change by Michael Felt : -- pull_requests: +15955 pull_request: https://github.com/python/cpython/pull/16376 ___ Python tracker <https://bugs.python.org/issue36210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36210] correct AIX logic in setup.py for (non-existant) optional extensions
Michael Felt added the comment: Added a backport for 3.8. p.s. - what is the file "name of the past"? -- ___ Python tracker <https://bugs.python.org/issue36210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36752] test multiprocessing: test_rapid_restart() crash on AIX
Michael Felt added the comment: Please let me be much more specific. This specific bot failure is from when I ran the bot using XLC as a compiler. Because I could not solve it on my own, and did not get any hints in time (see issue35828) Since my work schedule intensified I switched the bot to use gcc - and this test failure disappeared. Considering that the bot no longer uses XLC - it may make better sense to close this one. No AIX bots are using XLC aka vac(pp) compiler. Should I have time, I'll look into it again as issue35828. Note also, that manually I still build using XLC and the issue rarely occurs. That is part of what makes debugging so difficult. Michael -- ___ Python tracker <https://bugs.python.org/issue36752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
New submission from Michael Felt : Since issue42789 the AIX bot's have crashed - to the extent that the bot's did not even return results. Part of this has been resolved, for now, by using: $ export TERM=unknown $ buildbot start buildarea However, the test still crash because AIX default libcurses.a does not include support for update_lines_cols(). This patch should allow test_curses.py to pass in the buildbot. When run from command-line as: $ TERM=unknown ./python Lib/test/test_curses.py .ss..ss -- Ran 71 tests in 0.121s OK (skipped=64) aixtools@cpython2:[/home/aixtools/py3a-10.0] (When TERM is defined - a core dump still occurs - that will be a new issue and a new PR). -- components: Tests messages: 389716 nosy: Michael.Felt priority: normal severity: normal status: open title: AIX: test_curses crashes buildbot versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
Change by Michael Felt : -- keywords: +patch pull_requests: +23824 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25074 ___ Python tracker <https://bugs.python.org/issue43659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
Michael Felt added the comment: backports needed for 3.8 and 3.9 -- versions: +Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
Michael Felt added the comment:
my default TERM=xterm
I'll also use 'ansi'
The filenames will be ${TERM}.err and ${TERM}.out
for TERM in xterm ansi; do
./python -m test -vuall test_curses 2>${TERM}.err >${TERM}.out
done
After TERM=ansi - my terminal is in raw mode (i.e.,
$ stty sane ^J
needed).
--
Added file: https://bugs.python.org/file49917/issue43659.zip
___
Python tracker
<https://bugs.python.org/issue43659>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43665] AIX: test_importlib regression (ENV change)
New submission from Michael Felt : Since issue43517 test_importlib 'fails' (bot status) with ENV_CHANGED. The core dump is caused by SIGTRAP. I need help to learn how to stop the core dump from being cleaned up so I can load it into dbx and hopefully understand/learn with sub-test is actually having issues. e.g., see https://buildbot.python.org/all/#/builders/438/builds/1031/steps/5/logs/stdio for current bot exit status Thx for assistance. -- components: Tests messages: 389797 nosy: Michael.Felt priority: normal severity: normal status: open title: AIX: test_importlib regression (ENV change) versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43666] AIX: Lib/_aix_support.py may break in a WPAR environment
New submission from Michael Felt : When working in a WPAR (workload partition) the routines supporting aix_platform() may fail if there is no related builddate for bos.mp64. a) the fileset queried is changed to `bos.rte` b) an extreme value (9988) is returned for any similar (unexpected) situations - so that, in any case, the build of Python can proceed. -- components: Library (Lib) messages: 389804 nosy: Michael.Felt priority: normal severity: normal status: open title: AIX: Lib/_aix_support.py may break in a WPAR environment versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43666> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
Michael Felt added the comment: ./python -m test -vuall -i test_output_string -i test_insert_delete test_curses 2>test.err 1>test.out returns four failures: see attached '-i test_output_string' stops the crash -- Added file: https://bugs.python.org/file49918/test.out ___ Python tracker <https://bugs.python.org/issue43659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43666] AIX: Lib/_aix_support.py may break in a WPAR environment
Change by Michael Felt : -- keywords: +patch pull_requests: +23845 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25095 ___ Python tracker <https://bugs.python.org/issue43666> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
Michael Felt added the comment: FYI: from a core dump - top of where is: Segmentation fault in winsnstr at 0xd3ebc050 0xd3ebc050 (winsnstr+0x190) a4190002 lhzu r0,0x2(r25) (dbx) where winsnstr(??, ??, ??) at 0xd3ebc050 unnamed block in IPRA.$_curses_window_insstr_impl(self = 0x100fd954, group_left_1 = -739652824, y = 804382672, x = 804382676, str = 0x2ff1e7dc, group_right_1 = -739620304, attr = 0), line 1855 in "_cursesmodule.c" IPRA.$_curses_window_insstr_impl(self = 0x100fd954, group_left_1 = -739652824, y = 804382672, x = 804382676, str = 0x2ff1e7dc, group_right_1 = -739620304, attr = 0), line 1855 in "_cursesmodule.c" _curses_window_insstr(self = 0x100a96ec, args = 0x20088288), line 1160 in "_cursesmodule.c.h" cfunction_call(func = 0x305337d0, args = 0x20088288, kwargs = 0x2ff1e8b0), line 567 in "methodobject.c" _PyObject_MakeTpCall(tstate = (nil), callable = 0x20088288, args = 0x2ff1e930, nargs = 131, keywords = 0x10167b48), line 215 in "call.c" _PyEval_EvalFrameDefault(tstate = 0x100b2a6c, f = 0x303a1268, throwflag = 806335952), line 1429 in "abstract.h" _PyEval_Vector(tstate = 0x100ef278, con = 0x300fd59a, locals = 0x2ff1ea90, args = 0x20045994, argcount = 806339296, kwnames = 0x300ff6a0), line 46 in "pycore_ceval.h" -- ___ Python tracker <https://bugs.python.org/issue43659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43665] AIX: test_importlib regression (ENV change)
Michael Felt added the comment: On 30/03/2021 09:40, STINNER Victor wrote: > STINNER Victor added the comment: > > A core dump is a very bad sign of health. > > Can you please try to bisect which test is causing the segfault using > bisect_cmd? Try the command: > > ./python -m test.bisect_cmd -o bisect --fail-env-changed test_importlib > > The command should takes 10-60 minutes, and you should see the number of > tests decreasing. I hope that at the end, the command will identify a single > method triggering the crash. > > At the end, the create "bisect" file contains the test methods causing the > bug. > > Then you can re-run tests with: > > ./python -m test --fail-env-changed test_importlib --matchfile=bisect I like this!: Fortunately, it did not take 10 minutes: Writing 1 tests into bisect Tests (1): * test.test_importlib.test_threaded_import.ThreadedImportTests.test_multiprocessing_pool_circular_import Output written into bisect Bisection completed in 34 iterations and 0:00:28 > > >> The core dump is caused by SIGTRAP. I need help to learn how to stop the >> core dump from being cleaned up so I can load it into dbx and hopefully >> understand/learn with sub-test is actually having issues. > You can re-run the test without libregrtest by running it directly. Example: > > ./python -m test.test_importlib > test_spec.Frozen_ModuleSpecMethodsTests.test_reload -v While - to use your example - using the normal verbose test syntax I do see the test you reference: * test_reload (test.test_importlib.test_spec.Frozen_ModuleSpecMethodsTests) ... ok but, when I run your example (and many variations) I always get something such as: So, still - closer - but not quite there with: + ./python -m test.test_importlib test_spec.Frozen_ModuleSpecMethodsTests.test_reload -v test_spec (unittest.loader._FailedTest) ... ERROR == ERROR: test_spec (unittest.loader._FailedTest) -- AttributeError: module '__main__' has no attribute 'test_spec' -- Ran 1 test in 0.000s FAILED (errors=1) + > It should create a core dump in the current directory, or you run the command > in your favorite debugger. > > > My notes on debugging a Python crash: > https://pythondev.readthedocs.io/debug_tools.html#core-dump > > -- > nosy: +vstinner > > ___ > Python tracker > <https://bugs.python.org/issue43665> > ___ > -- Added file: https://bugs.python.org/file49922/OpenPGP_0x722BFDB61F396FC2.asc ___ Python tracker <https://bugs.python.org/issue43665> ___ OpenPGP_0x722BFDB61F396FC2.asc Description: application/pgp-keys ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist
Michael Felt added the comment: Sure. Probably have to rebase first. -- ___ Python tracker <https://bugs.python.org/issue28276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43665] AIX: test_importlib regression (ENV change)
Michael Felt added the comment: On 31/03/2021 18:46, STINNER Victor wrote: > STINNER Victor added the comment: > > test.test_importlib.test_threaded_import.ThreadedImportTests.test_multiprocessing_pool_circular_import > > This test comes from bpo-41567 and it simply runs a script. You can run the script directly: > > ./python -X dev Lib/test/test_importlib/partial/pool_in_threads.py ; echo $? Status is zero -0 but I get a core dump! aixtools@cpython2:[/home/aixtools/py3a-10.0]./python -X dev Lib/test/test_importlib/partial/pool_in_threads.py ; echo $? 0 aixtools@cpython2:[/home/aixtools/py3a-10.0]ls -ltr core -rw-r--r-- 1 aixtools staff 129435720 Mar 31 16:58 core +++ Looking at the core dump - part 1. +++ The address (0xd118ff80) hints at a shared library (pthread?) I'll try to find it - but maybe you can just remind me - the CLI arguments to make Python more verbose about what it is doing. Note: all addresses beginning with 0x1 (as in 0x101ca238) are program code addresses. 0x3 (0x30163ad8) imply a shared memory segment being created and used by the application. Perhaps more relevant aree all these lines with what appear to be extreme argcount values, e.g., from the bottom: _PyEval_Vector(tstate = 0x30187038, con = 0x20107b40, locals = 0x30111768, args = 0x301219b8, argcount = 806560272, kwnames = 0x301314d8), line 46 in "pycore_ceval.h" _PyFunction_Vectorcall(func = (nil), stack = (nil), nargsf = 570570720, kwnames = (nil)), line 361 in "call.c" _PyEval_EvalFrameDefault(tstate = (nil), f = 0x4000, throwflag = -257396708), line 1431 in "abstract.h" _PyEval_Vector(tstate = 0x22023cf0, con = 0x2000120c, locals = 0x22023960, args = 0x220239f0, argcount = 3508213100, kwnames = 0x22023cf0), line 46 in "pycore_ceval.h" _PyFunction_Vectorcall(func = 0x220239f0, stack = (nil), nargsf = 570572016, kwnames = 0x220239f0), line 361 in "call.c" method_vectorcall(method = 0x10103bdc, args = (nil), nargsf = 0, kwnames = 0x20045994), line 119 in "abstract.h" PyVectorcall_Call(callable = 0x, tuple = 0x, kwargs = 0x), line 255 in "call.c" _PyObject_Call(tstate = (nil), callable = (nil), args = (nil), kwargs = (nil)), line 298 in "call.c" thread_run(boot_raw = (nil)), line 1076 in "_threadmodule.c" pythread_wrapper(arg = (nil)), line 240 in "thread_pthread.h" +++ Looking at the core dump - the complete 'where' results: +++ aixtools@cpython2:[/home/aixtools/py3a-10.0]dbx ./python core Type 'help' for help. [using memory image in core] reading symbolic information ... Trace/BPT trap in _internal_error at 0xd118ff80 ($t1) 0xd118ff80 (_internal_error+0x80) 80410014 lwz r2,0x14(r1) (dbx) where _internal_error(??, ??, ??) at 0xd118ff80 pth_usched._usched_dispatch_front._event_notify_locked@AF34_24(??, ??, ??, ??, ??) at 0xd119fc2c _event_notify(??, ??, ??) at 0xd119ee38 _cond_broadcast(??, ??, ??) at 0xd11af588 pthread_cond_signal@AF29_12(??, ??) at 0xd11b1568 pthread_cond_signal(??) at 0xd11afc88 PyThread_release_lock(lock = 0x10119354), line 692 in "thread_pthread.h" release_sentinel(wr_raw = 0x10118f14), line 1289 in "_threadmodule.c" PyThreadState_Clear(tstate = 0x101ca238), line 873 in "pystate.c" _PyThreadState_DeleteExcept(runtime = 0xd5c234d0, tstate = 0x22021d30), line 987 in "pystate.c" _PyEval_ReInitThreads(tstate = 0x30163ad8), line 506 in "ceval.c" PyOS_AfterFork_Child(), line 600 in "posixmodule.c" os_fork_impl(module = 0x3033a030), line 6659 in "posixmodule.c" cfunction_vectorcall_NOARGS(func = 0x30337330, args = 0x302ec7d0, nargsf = 570564304, kwnames = 0x30337328), line 485 in "methodobject.c" _PyEval_EvalFrameDefault(tstate = 0x302e058c, f = 0x302e847a, throwflag = 0), line 1431 in "abstract.h" _PyEval_Vector(tstate = 0x302f2350, con = 0x20107b40, locals = 0x302e8478, args = 0x302e79b8, argcount = 808016112, kwnames = 0x302cd898), line 46 in "pycore_ceval.h" _PyFunction_Vectorcall(func = 0x0008, stack = 0x3004d6e8, nargsf = 570564752, kwnames = 0x302f6030), line 361 in "call.c" _PyEval_EvalFrameDefault(tstate = 0x101c9554, f = 0x20107b40, throwflag = 570565024), line 1431 in "abstract.h" _PyEval_Vector(tstate = 0x0018, con = 0x200084a0, locals = 0x220221f0, args = 0x88000284, argcount = 269576140, kwnames = 0x2007a390), line 46 in "pycore_ceval.h" _PyFunction_Vectorcall(func = 0x2007a4e0, stack = 0x20107b40, nargsf = 570565168, kwnames = 0x20045994), line 361 in "call.c" _PyObject_FastCallDictTstate(tstate = 0x100a7e84, callable = 0x302ed780, args = 0x220222b0, nargsf = 537155988, kwargs = 0x100a8a54), line 142 in "call.c&qu
[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child
Michael Felt added the comment: Adding 3.10. While a (sort of) duplicate I also would like to add that before revision "7cb033c423b65def1632d6c3c747111543b342a2" this was not showing up as an issue with test_importlib. my issue was with test_importlib suddenly going into error. As this seem to be a long-standing issue is it perhaps a possibility to change the test so that the bot can go green again? -- nosy: +Michael.Felt versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue40092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child
Michael Felt added the comment: OK: further. Two options are suggested: There are different options to solve this issue: * Reset _tstate_lock before using it... not sure that it's worth it, since we are going to delete the threading.Thread object with its _tstate_lock object anymore. After calling fork, the child process has exactly 1 thread: all other threads have been removed. * Modify release_sentinel() to not use the lock: avoid PyThread_release_lock() call. ** as to option 1 - it is 'worth it' if it stops the crashes ** This is deeper than I usually go in Python code - but I'll make an effort - help is appreciated. -- ___ Python tracker <https://bugs.python.org/issue40092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child
Michael Felt added the comment:
OK. Please explain. Looking at tstate assignment
In posixmodule.c:PyOSAfterFork_Child()
PyStatus status;
_PyRuntimeState *runtime = &_PyRuntime;
...
PyThreadState *tstate = _PyThreadState_GET();
and later calls
status = _PyRuntimeState_ReInitThreads(runtime);
Yet in Posix/ceval.c
PyStatus
_PyEval_ReInitThreads(PyThreadState *tstate)
{
_PyRuntimeState *runtime = tstate->interp->runtime;
** this looks like runtime->interp->runtime
And then we get down to:
/* Destroy all threads except the current one */
_PyThreadState_DeleteExcept(runtime, tstate);
Is this correct - as it looks like:
_PyThreadState_DeleteExcept(runtime->interp->runtime, runtime) -- where runtime
== &_PyRuntime;
--
___
Python tracker
<https://bugs.python.org/issue40092>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child
Michael Felt added the comment: Willing to spend more time on this - but the variable names chosen blind me - looks like a circle. And, thinking about the address in the core dump starting with 0xd (segment 13) - confuses me somewhat - as from memory - I thought the shared library code/data converged on segment 14 (ie, addresses would begin with 0xe). So, perhaps it is the 0xd* address that is killing everything. See: https://bugs.python.org/issue43665#msg389923 -- as I am also still confused re: this line - looks suspect: with all arguments at 0x PyVectorcall_Call(callable = 0x, tuple = 0x, kwargs = 0x), line 255 in "call.c" And also this line, and lines like it - notice the value for what looks like a variable for argument_count: _PyEval_Vector(tstate = 0x22023cf0, con = 0x2000120c, locals = 0x22023960, args = 0x220239f0, argcount = 3508213100, kwnames = 0x22023cf0), line 46 in "pycore_ceval.h" _PyFunction_Vectorcall(func = 0x220239f0, stack = (nil), nargsf = 570572016, kwnames = 0x220239f0), line 361 in "call.c" method_vectorcall(method = 0x10103bdc, args = (nil), nargsf = 0, kwnames = 0x20045994), line 119 in "abstract.h" -- ___ Python tracker <https://bugs.python.org/issue40092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40878] Use c99 on the aixtools bot
Michael Felt added the comment: Disregard the last mail -seems many routines go to unresolved. On 15/08/2020 20:43, Stefan Krah wrote: > Change by Stefan Krah : > > > -- > assignee: -> skrah > resolution: -> fixed > stage: patch review -> resolved > status: open -> closed > type: -> compile error > > ___ > Python tracker > <https://bugs.python.org/issue40878> > ___ > -- Added file: https://bugs.python.org/file49986/OpenPGP_0x722BFDB61F396FC2.asc ___ Python tracker <https://bugs.python.org/issue40878> ___ OpenPGP_0x722BFDB61F396FC2.asc Description: application/pgp-keys ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
Michael Felt added the comment:
Dome some 'dumb' testing - and I hope this helps understand why it is failing:
With the the last two func() calls commented out, the function passes:
def test_output_string(self):
stdscr = self.stdscr
encoding = stdscr.encoding
# addstr()/insstr()
for func in [stdscr.addstr, stdscr.insstr]:
with self.subTest(func.__qualname__):
stdscr.move(0, 0)
func('abcd')
func(b'abcd')
s = 'à▒^▒ç▒^▒'
try:
func(s)
except UnicodeEncodeError:
self.assertRaises(UnicodeEncodeError, s.encode, encoding)
func('abcd', curses.A_BOLD)
# func(1, 2, 'abcd')
# func(2, 3, 'abcd', curses.A_BOLD)
--
___
Python tracker
<https://bugs.python.org/issue43659>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
Change by Michael Felt : -- type: -> crash ___ Python tracker <https://bugs.python.org/issue43659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35828] test_multiprocessing_fork: segmentation error in PyDict_GetItem on AIX
Michael Felt added the comment: I stopped running my bot. I have no idea if this is also an issue on 3.9+ And since noone will look at this in it's present state. I'd recommend closing. -- ___ Python tracker <https://bugs.python.org/issue35828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)
Michael Felt added the comment: @corona10 The AIX bot's are also in the red zone with PR17010. This was examined earlier See: https://bugs.python.org/issue35633#msg333662 In short, the recommendation by Victor was to skip the test: quote: > On AIX the test for flock() passes, but the test for lockf() fails: (...) I would prefer to simply skip the lockf() test rather than ignoring PermissionError for flock() and lockf() on all platforms. And so, Lib/test/eintrdata/eintr_tester.py now has: @unittest.skipIf(platform.system() == "AIX", "AIX returns PermissionError") def test_lockf(self): self._lock(fcntl.lockf, "lockf") Thanks for your understanding. -- nosy: +Michael.Felt ___ Python tracker <https://bugs.python.org/issue22367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)
Michael Felt added the comment: Could PR17010 be reverted? For 10 days now several bots, AIX and x86-64 High Sierra - afaik, are failing the tests. re: https://bugs.python.org/issue22367#msg356614 - while that may address High Sierra, it does not address AIX. See message https://bugs.python.org/issue35633#msg333662 - wherein Victor states his preference to ignore the test (for AIX). A additional change to your next PR could be to also ignore AIX for this test. AIX returns a different error, "Permission Error", iirc. -- versions: +Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue22367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)
Michael Felt added the comment: ignore my last comment - I missed your comment about skipping the test. My apologies. I'll be patient. Thanks for the update! -- ___ Python tracker <https://bugs.python.org/issue22367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)
Michael Felt added the comment: FYI: I loaded the pr just now and tested on AIX. $ ./python -m test test_fcntl 0:00:00 Run tests sequentially 0:00:00 [1/1] test_fcntl == Tests result: SUCCESS == 1 test OK. Total duration: 767 ms Tests result: SUCCESS $ git status On branch pr_17154 Thanks -- ___ Python tracker <https://bugs.python.org/issue22367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38021] pep425 tag for AIX is inadequate
Change by Michael Felt : -- pull_requests: +16795 pull_request: https://github.com/python/cpython/pull/17303 ___ Python tracker <https://bugs.python.org/issue38021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38021] pep425 tag for AIX is inadequate
Michael Felt added the comment:
a) - thanks Ned, for the kind words.
b) - the proposed (change to the tag) is "AIX.VRTL.YYWW.SZ".
"AIX" - in caps, to distinguish from current tag starting as "aix"
VRTL - 4 digit number, one digit for Version, one digit as Revision, and two
digits for Technology Level
YYWW - builddata with two digits for year (7 becomes 07) and two digits for
week of year.
SZ - 32, or 64 bit size of executable (or pointer).
The builddate is crucial as system updates are possible, in oslevel -s terms,
from 6100-09-11-1810 to 7100-05-02-1810 but not from 6100-09-12-1846 to
7100-05-02-1810. Using the proposed PEP425 tag the VRTL-YYWW numbers here would
be: 6109-1810, 6109-1846 and 7105-1810.
The build-date of the executable is essential, as it specifies the lowest date
of any AIX release that it is supported on. This is something CPython must
provide, as it does for other platforms, in the form of
sysconfig.get_config_var("AIX_BUILDDATE"). The VRTL values of the executable
are already available via sysconfig.get_config_var("BUILD_GNU_TYPE") while SZ
is typically determined from sys.maxsize.
Happy to answer additional questions - and write additional .rst documentation
as desired.
e.g., an
--
___
Python tracker
<https://bugs.python.org/issue38021>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)
Michael Felt added the comment: Thanks for the update to the PR FYI One AIX bot seems to be having support issues atm (and stays red), but the other one turned green again. :smile: -- ___ Python tracker <https://bugs.python.org/issue22367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)
Michael Felt added the comment: p.s. the new PR also needs to be backported for the 3.8 bots. -- ___ Python tracker <https://bugs.python.org/issue22367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)
Michael Felt added the comment: And the other AIX bot has been repaired, and is running green as well! :) -- ___ Python tracker <https://bugs.python.org/issue22367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38021] pep425 tag for AIX is inadequate
Michael Felt added the comment: @paul.moore - thanks for the comment. I am trying to work from both https://packaging.python.org/specifications/platform-compatibility-tags/ which describes in a few words the goals of PEP425. As to the PEP425 itself, it does not specify what a tag looks like. Within the EPE the only description is: The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore _. Like the platform-compatibility-tags reference says - the rational (aka requirement) "distributions should have a file naming convention that includes enough information to decide whether or not a particular archive is compatible with a particular implementation." The tag I am proposing 'includes enough information'. Further, as to the comparison of Linux and macos approaches to tags and deciding "whether or not a particular archive is compatible" AIX system architecture does not have to deal with the diversity that Linux platforms do - so it would be closer to macos approach. Actually, deciding if a bdist is compatible or not will not be the hard part. However, I prefer to discuss that after a starting point - the platform tag itself - is achieved. The last bit I am looking into is how, e.g., ``pip`` looks/searches pypi for candidates. -- ___ Python tracker <https://bugs.python.org/issue38021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38021] pep425 tag for AIX is inadequate
Michael Felt added the comment: On 22/11/2019 10:42, Paul Moore wrote: > Paul Moore added the comment: > > PyPA member here - if this PR is defining new compatibility tags, replacement platform_tag, not compatibility tag. > I would have expected it to need discussion as a revision to PEP 425, much > like the manylinux efforts did. (It may actually be a closer parallel with > MacOS, which didn't have a tagging PEP - I'm not sure how that would relate > here, but as MacOS is a much more mainstream platform I'd be inclined to err > on the side of caution and look for AIX to be explicitly covered in the tag > specs). As I understand the 'manylinux*' compatibility tags - which are used as a replacement for platform tags - these compatibility tags are added on by the packager who works in a carefully configured environment in order to support binary compatibility over multiple Linux distributions and releases. Before AIX 6.1 binary compatibility in AIX was not guaranteed upfront. Starting with AIX 6.1 IBM has a policy of guaranteeing binary compatibility for applications. >From https://www.recarta.co.uk/our-partners/software-partners/ibm-aix/ This page, from IBM, speaks of binary compatibility even going back to AIX 3.2 - https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/install/binary_compatability.html So, again - the PR is to provide an adequate platform tag. As is, an adequate tag works on equality. Once the platform tag is established - then - "we" (I guess that will mean me writing and "the community" providing feedback) can look at how to use the tags over different `releases` of AIX. Like MacOS, unlike Linux - there is only one distributor. I am willing to work on an informational PEP - as long as waiting for that process to complete does not mean an adequate platform_tag is left in limbo for months to years. This new PEP would have two pieces - a) describe the AIX platform tag; b) describe how tags of different releases are compared and accepted or rejected as binary compatible. Please note: the PR does not address any aspect of point b). Without point a) there is no basis for point b). Sincerely, Michael > > I thought that was something that had been discussed on the Pip tracker, but > maybe the implications weren't clear (I don't really understand the AIX > scheme, so I'm relying on someone else, probably Michael, to propose > something that could be added to PEP 425 and to lead/guide the discussion). > > -- > nosy: +paul.moore > > ___ > Python tracker > <https://bugs.python.org/issue38021> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38021] pep425 tag for AIX is inadequate
Michael Felt added the comment: On 26/11/2019 20:10, Paul Moore wrote: > Paul Moore added the comment: > >> replacement platform_tag, not compatibility tag. > Ah, I see, sorry. In that case, this should be fine, it's purely a CPython > question. There's obviously a follow-on discussion about how that platform > tag is *incorporated* into the compatibility tags, but as you say, that's a > separate point. Still an excellent question - as it clarified at least one vital point! Thanks for the feedback and question. > -- > > ___ > Python tracker > <https://bugs.python.org/issue38021> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38021] Modify AIX platform_tag so it provides PEP425 needs
Change by Michael Felt : -- title: pep425 tag for AIX is inadequate -> Modify AIX platform_tag so it provides PEP425 needs ___ Python tracker <https://bugs.python.org/issue38021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38021] Modify AIX platform_tag so it provides PEP425 needs
Michael Felt added the comment: Updated this PR, and PRs in pypa/pip and pypa/packaging to all be "in sync". -- ___ Python tracker <https://bugs.python.org/issue38021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38021] Modify AIX platform_tag so it provides PEP425 needs
Michael Felt added the comment:
Well, I certainly had not considered people would be using
distutils.get_platform().startswith('aix') as I have, in my limited
reading, only seen sys.platform.startswith("aix"). Likewise, do not want
to break things.
I thought this was easier to grasp than my first idea: e.g., tag[-2:] in
["32", "64"].
I'll start counting hypens, but am also curious about what is good/bad
about looking how the string ends, e.g., would there be a clear
performance difference?
Many thanks for the review!
On 12/8/2019 1:45 PM, Nick Coghlan wrote:
> Nick Coghlan added the comment:
>
> There's a compatibility problem with changing the AIX distutils platform
> prefix from aix to AIX: any existing code that does
> "distutils.get_platform().startswith('aix')" will break. (There isn't any
> code in the standard library that does that, it all checks sys.platform()
> instead, but it's a reasonable assumption that there's going to be code in
> the wild that does a prefix check on the distutils API output).
>
> So I think we'll want to make the distinction between the two formats based
> on the number of hyphens they contain, rather than changing the prefix.
>
> I *haven't* made that change directly to the PR myself, as I want to give you
> a chance to consider the question first, but I do think it's a required
> compatibility improvement before we move ahead with this.
>
> --
>
> ___
> Python tracker
> <https://bugs.python.org/issue38021>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue38021>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39020] [AIX] module _ctypes fails to build since ESCDELAY has been added
New submission from Michael Felt :
Did not notice this earlier - as the buildbot does not report it: issue38312
introduced a regression with regard to AIX.
Not sure how to classify component (as Build, C API, or Library, so left blank)
Failed to build these modules:
_curses
commit b32cb97bce472dad337c6b2f071883f6234e21d8
Author: Anthony Sottile
Date: Thu Oct 31 02:13:48 2019 -0700
bpo-38312: Add curses.{get,set}_escdelay and curses.{get,set}_tabsize.
(GH-16938)
Background: ncurses is not part of AIX; curses. ncurses packages provided by
other parties are not stable enough for, among other things, allow the buildbot
to pass.
Prior to this commit AIX passed all tests related to _curses.
--
messages: 358210
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: [AIX] module _ctypes fails to build since ESCDELAY has been added
type: compile error
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue39020>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39020] [AIX] module _ctypes fails to build since ESCDELAY has been added
Change by Michael Felt : -- components: +Extension Modules ___ Python tracker <https://bugs.python.org/issue39020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39020] [AIX] module _ctypes fails to build since ESCDELAY has been added
Michael Felt added the comment: I am thinking along two lines: a) tell setup.py to not build _curses, just as _curses_panel b) figure out how to use configure tests, to establish that ESCDELAY is not available AND then tell _cursesmodule.* that these routines are not available (and add that to the new docs for these routines). -- ___ Python tracker <https://bugs.python.org/issue39020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added
Michael Felt added the comment: quote: Interesting, a comment in curses.h: * Notes: * a. ESCDELAY was an undocumented feature under AIX curses. * It gives the ESC expire time in milliseconds. iirc - that is a symbolic link to ncurses.h from ncurses-devel RPM package, not something from AIX itself. On my test partitions - where I do not install RPMs, I do not have that comment. Likewise, I did see that comment on the gccfarm POWER8 provided by IBM (which has ncurses-devel installed, or I would have never known :) ) -- ___ Python tracker <https://bugs.python.org/issue39020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39396] AIX: math.nextafter(a, b) breaks AIX bot
New submission from Michael Felt : As issue39288 (that introduces this breakage) is closed, opening a new issue. Back from away - and only starting my investigation - and that will probably be slow. Have not done anything with IEEE754 in over 30 years. -- messages: 360312 nosy: Michael.Felt priority: normal severity: normal status: open title: AIX: math.nextafter(a, b) breaks AIX bot versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39396> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39396] AIX: math.nextafter(a, b) breaks AIX bot
Michael Felt added the comment: As I said, was investigating. a) is a bug in most AIX system libraries. b) there is a fix, but not one I can install - as my bots and build systems run on AIX 6.1 and AIX 7.1 c) the fix is APAR IV95512 which includes fixes in the following filesets: IV95512 shipped nextafter(+0.0, -0.0) returns +0.0 instead of -0.0. bos.rte.shell 7.2.2.0 bos.adt.prof 7.2.2.0 bos.adt.libm 7.2.2.0 So, nothing for me "to fix" -- see https://www-01.ibm.com/support/docview.wss?uid=isg1IV95512 FYI: The document URL (above) was last modified on 30 October 2017 -- ___ Python tracker <https://bugs.python.org/issue39396> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0), +0.0) test fails on AIX
Michael Felt added the comment: A hard call to make, imho. Thinking aloud... Currently, for AIX 6.1 and AIX 7.1 your proposal for the code change would be great, but less so for AIX 7.2. However! Since libm (on AIX) is a static library - the behavior depends on the support libm has on the build system. I'll have to puzzle a bit with the configure process and figure out how to best determine the behavior of the build system. On a properly patched AIX 7.2 system the standard code would apply, on others the "adjusted behavior". So, would you go for modified based on what version of libm is installed, better how this function is behaving? -- ___ Python tracker <https://bugs.python.org/issue39396> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0), +0.0) test fails on AIX
Michael Felt added the comment:
FYI: On AIX 5.3, after your proposal I get:
==
FAIL: test_specific_values (test.test_cmath.CMathTests)
--
Traceback (most recent call last):
File "/data/prj/python/git/python3-3.9/Lib/test/test_cmath.py", line 418, in
test_specific_values
self.rAssertAlmostEqual(expected.imag, actual.imag,
File "/data/prj/python/git/python3-3.9/Lib/test/test_cmath.py", line 130, in
rAssertAlmostEqual
self.fail(msg or 'zero has wrong sign: expected {!r}, '
AssertionError: exp0001: exp(complex(0.0, -0.0))
Expected: complex(1.0, -0.0)
Received: complex(1.0, 0.0)
Received value insufficiently close to expected value.
--
So, test_nextafter works with the patch, but test_specific_values remains
'active'
--
___
Python tracker
<https://bugs.python.org/issue39396>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39409] AIX: FAIL: test_specific_values (test.test_cmath.CMathTests)
New submission from Michael Felt : Per message: https://bugs.python.org/issue39396#msg360362 opening new issue. Research (as requested) to follow. -- components: Tests messages: 360389 nosy: Michael.Felt, vstinner priority: normal severity: normal status: open title: AIX: FAIL: test_specific_values (test.test_cmath.CMathTests) versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39409> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39409] AIX: FAIL: test_specific_values (test.test_cmath.CMathTests)
Michael Felt added the comment: I am looking at this, as/when I can. Was hoping for a ancient school option to have the compiler stop with assembly code generation ipv objdump. However, I have not been successful there. Found objdump, and I'll work from that - and also do some of the tests from the closed issues suggested. Also, noticed that at least one AIX bot turned green again (23-01-2020), so I'll have to look into what else has changed. -- ___ Python tracker <https://bugs.python.org/issue39409> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39502] test_zipfile fails on AIX due to time.localtime
Change by Michael Felt : -- nosy: +Michael.Felt ___ Python tracker <https://bugs.python.org/issue39502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39502] test_zipfile fails on AIX due to time.localtime
Michael Felt added the comment:
Probably this broke the 64-bit usage.
diff --git a/Python/pytime.c b/Python/pytime.c
index 54ddfc952b..6f13e62490 100644
--- a/Python/pytime.c
+++ b/Python/pytime.c
@@ -1059,7 +1059,7 @@ _PyTime_localtime(time_t t, struct tm *tm)
return 0;
#else /* !MS_WINDOWS */
-#ifdef _AIX
+#ifdef defined(_AIX) and (SIZEOF_LONG ==4)
/* bpo-34373: AIX does not return NULL if t is too small or too large */
if (t < -2145916800 /* 1902-01-01 */
|| t > 2145916800 /* 2038-01-01 */) {
Testing...
--
___
Python tracker
<https://bugs.python.org/issue39502>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39502] test_zipfile fails on AIX due to time.localtime
Michael Felt added the comment: >From memory I recall the 64-bit version worked with values above the threshold >value that broke the 32-bit library. And the additional test was needed because the AIX library (iirc did not return NULL on error) - so had to test range before the call to get an overflow. Working up a test of 32 and 64-bit enviornments. -- ___ Python tracker <https://bugs.python.org/issue39502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39502] test_zipfile fails on AIX due to time.localtime
Michael Felt added the comment: Seems to be working on 64-bit, starting 32-bit test (with overflow expected). Once finished will post a PR. root@x065:[/data/prj/python/python3-3.9]./python Python 3.9.0a3+ (heads/bpo-39502-dirty:8d49f7ceb4, Jan 30 2020, 14:47:52) [C] on aix Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.localtime(4325562452) time.struct_time(tm_year=2107, tm_mon=1, tm_mday=27, tm_hour=9, tm_min=7, tm_sec=32, tm_wday=3, tm_yday=27, tm_isdst=0) >>> time.gmtime(4325562452) time.struct_time(tm_year=2107, tm_mon=1, tm_mday=27, tm_hour=9, tm_min=7, tm_sec=32, tm_wday=3, tm_yday=27, tm_isdst=0) >>> -- components: +Interpreter Core versions: +Python 3.7, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39502] test_zipfile fails on AIX due to time.localtime
Change by Michael Felt : -- pull_requests: +17660 pull_request: https://github.com/python/cpython/pull/18285 ___ Python tracker <https://bugs.python.org/issue39502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39502] test_zipfile fails on AIX due to time.localtime
Michael Felt added the comment: OK. There have been some comments/questions re: PR18282. a) my PR is missing that PR, seems we just missed each other. b) when using my patch I took a suggestion from issue39460 to test again: root@x065:[/home/python/python3-3.9]./python -m test -v test_zipfile -m test_add_file_after_2107 --tempdir /tmp == CPython 3.9.0a3+ (heads/bpo-39502-dirty:c54fe56362, Jan 30 2020, 15:52:37) [C] == AIX-3-00C291F54C00-powerpc-64bit big-endian == cwd: /tmp/test_python_303120 == CPU count: 4 == encodings: locale=ISO8859-1, FS=iso8859-1 0:00:00 Run tests sequentially 0:00:00 [1/1] test_zipfile test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile) ... ok -- Ran 1 test in 0.257s OK == Tests result: SUCCESS == 1 test OK. Total duration: 653 ms Tests result: SUCCESS Without the --tempdir setting it "skips" to PASS: root@x065:[/home/python/python3-3.9]./python -m test -v test_zipfile -m test_add_file_after_2107 == CPython 3.9.0a3+ (heads/bpo-39502-dirty:c54fe56362, Jan 30 2020, 15:52:37) [C] == AIX-3-00C291F54C00-powerpc-64bit big-endian == cwd: /data/prj/python/python3-3.9/build/test_python_364784 == CPU count: 4 == encodings: locale=ISO8859-1, FS=iso8859-1 0:00:00 Run tests sequentially 0:00:00 [1/1] test_zipfile test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile) ... skipped 'Linux VFS/XFS kernel bug detected: mtime_ns=913015040' -- Ran 1 test in 0.010s OK (skipped=1) == Tests result: SUCCESS == 1 test OK. Total duration: 252 ms Tests result: SUCCESS FYI -- ___ Python tracker <https://bugs.python.org/issue39502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39502] test_zipfile fails on AIX due to time.localtime
Michael Felt added the comment: p.s., I manually added #18282 to the test, and the results are the same as without - using 64-bit. Will rebuild the 32-bit and try test again. -- ___ Python tracker <https://bugs.python.org/issue39502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added
Michael Felt added the comment: Adding 3.8 before I post a PR - as I think the initial merge that introduced the regression was before master was considered 3.9. -- versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue39020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added
Michael Felt added the comment: removed 3.8, this is new for 3.9. Have established that all four functions added in issue38132 do not exist in stock AIX libcurses.a Was working on my own PR, but shall look at yours first. -- versions: -Python 3.8 ___ Python tracker <https://bugs.python.org/issue39020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added
Michael Felt added the comment: Have looked at your PR. It will not work on AIX because AIX libcurses is missing all four new functions. Once I finished my test on AIX - shall I add my patch as a file here, so you can integrate into yours? I hope that is easier than two PRs. -- ___ Python tracker <https://bugs.python.org/issue39020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added
Michael Felt added the comment: Here is the patch I am working on. I appreciate your example on how to deal with the undefined variables. I had done that incorrectly initially. -- Added file: https://bugs.python.org/file48876/bpo-39020-AIX.patch ___ Python tracker <https://bugs.python.org/issue39020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added
Change by Michael Felt : -- pull_requests: +17680 pull_request: https://github.com/python/cpython/pull/18303 ___ Python tracker <https://bugs.python.org/issue39020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added
Michael Felt added the comment: Thanks again for PR 18202. I followed your lead and made the additional changes and posted as PR 18203. -- ___ Python tracker <https://bugs.python.org/issue39020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added
Michael Felt added the comment: Blinded - got the numbers wrong! So, again: Thanks for PR 18302. I followed your lead and made the additional changes and posted as PR 18303 in the hope this is easier for all. -- ___ Python tracker <https://bugs.python.org/issue39020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist
Michael Felt added the comment: This is something from long long ago - time to get it completed. The (remaining) issue is: "c" and "m" may not be shared libraries - so nothing is ever found and the test is "skipped" but reports itself as PASSED. The original issue (fixed for AIX in Python3.7) would be if find_library itself is broken and always returns NULL/None. Again, the tests says "PASSED" when actually it was skipped. Following this - Martin's suggestion seems a viable solution. -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue28276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist
Change by Michael Felt : -- keywords: +patch pull_requests: +17688 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18312 ___ Python tracker <https://bugs.python.org/issue28276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist
Change by Michael Felt : -- versions: +Python 3.8, Python 3.9 -Python 2.7 ___ Python tracker <https://bugs.python.org/issue28276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28312] Minor change - more direct hint re: multiple machine sizes and LONG_BIT conflicts
Change by Michael Felt : -- keywords: +patch pull_requests: +17689 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18313 ___ Python tracker <https://bugs.python.org/issue28312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28290] BETA report: Python-3.6 build messages to stderr: AIX and "not GCC"
Michael Felt added the comment: Closing, as not longer relevant. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue28290> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32542] memory not freed, aka memory leak continues...
Michael Felt added the comment: Not an issue in 3.9, so, closing: "not relevant" -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue32542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36034] Suprise halt caused by -Werror=implicit-function-declaration in ./Modules/posixmodule.c
Michael Felt added the comment: closing. Will open a new issue with a correct description of the issue at hand. The problem is related to 64-bit mode (which was not mentioned before) and minor() major() macro definitions. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39502] test_zipfile fails on AIX due to time.localtime
Michael Felt added the comment: Not sure I understand what bug I am supposed to report. I apologize if my message https://bugs.python.org/issue39502#msg361116. I assume your comment re: time.localtime(91301504) comes from this bit of the test message (mtime_ns=913015040). Assuming our TZ used are different I am verifying AIX works correctly for the constant 91301504 root@x065:[/data/prj/python/python3-3.9]./python Python 3.9.0a3+ (heads/master-dirty:78c7183f47, Feb 3 2020, 14:10:40) [C] on aix Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.gmtime(91301504) time.struct_time(tm_year=1972, tm_mon=11, tm_mday=22, tm_hour=17, tm_min=31, tm_sec=44, tm_wday=2, tm_yday=327, tm_isdst=0) >>> time.localtime(91301504) time.struct_time(tm_year=1972, tm_mon=11, tm_mday=22, tm_hour=17, tm_min=31, tm_sec=44, tm_wday=2, tm_yday=327, tm_isdst=0) root@x065:[/data/prj/python/python3-3.9]set | grep TZ TZ=UTC0 Again, my apologies for the confusion: the message "skipped 'Linux VFS/XFS kernel bug detected: mtime_ns=913015040" only occurs when the test is run on a NFS mount hosted by a SAN based on a Linux kernel. When I specify --tempdir=/tmp (i.e., using jfs2 as filesystem) the test passes normally. On 03/02/2020 09:40, STINNER Victor wrote: > STINNER Victor added the comment: > >> test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile) ... >> skipped 'Linux VFS/XFS kernel bug detected: mtime_ns=913015040' > AIX kernel seems to have a bug. You should report it to AIX. > >>>> time.localtime(91301504) > time.struct_time(tm_year=1972, tm_mon=11, tm_mday=22, tm_hour=18, tm_min=31, > tm_sec=44, tm_wday=2, tm_yday=327, tm_isdst=0) > > -- > > ___ > Python tracker > <https://bugs.python.org/issue39502> > ___ > -- ___ Python tracker <https://bugs.python.org/issue39502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37336] os.sendfile() support missing for AIX platform
Michael Felt added the comment: OK. Couple of months later. Would appreciate guidance before submitting a patch. In advance: Thank you for your time and consideration. Short: socket.sendfile() and AIX send_file() are very close in terms of functionality - especially the requirement that "out_fd" is a non-blocking socket. os.sendfile() and AIX send_file(), imho, do not match because it appears that os.sendfile(in_fd, out_fd, ...) will work with any kind of open file descriptor. Longer: .. method:: socket.sendfile(file, offset=0, count=None) Send a file until EOF is reached by using high-performance :mod:`os.sendfile` and return the total number of bytes which were sent. *file* must be a regular file object opened in binary mode. If :mod:`os.sendfile` is not available (e.g. Windows) or *file* is not a regular file :meth:`send` will be used instead. ... The socket must be of :const:`SOCK_STREAM` type. Non-blocking sockets are not supported. .. versionadded:: 3.5 AIX #include < sys/socket.h > ssize_t send_file(Socket_p, sf_iobuf, flags) int * Socket_p; struct sf_parms * sf_iobuf; uint_t flags; Description The send_file subroutine sends data from the opened file specified in the sf_iobuf parameter, over the connected socket pointed to by the Socket_p parameter. Note Currently, the send_file only supports the TCP/IP protocol (SOCK_STREAM socket in AF_INET). An error will be returned when this function is used on any other types of sockets. These match in terms of goals. Considering the requirements of AIX send_file() os.sendfile() does not seem to fit. I read (Doc/library/os.rst) os.sendfile to imply that any open file descriptors will be "sent" whereas with socket.sendfile - in_fd is binary file, out_fd is a SOCK_STREAM socket descriptor. So, would like some feedback on how to proceed: e.g., A. a new os.send_file - only available for AIX (and only accessible to socket.sendfile(), B. os.sendfile "returns" one of the following when the input parameters are not appropriate: EBADF Either the socket or the file descriptor parameter is not valid. ENOTSOCKThe socket parameter refers to a file, not a socket. (There are other errno results, not important for the discussion atm). Again, thank you for your time! -- ___ Python tracker <https://bugs.python.org/issue37336> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36843] AIX build fails with failure to get random numbers
Michael Felt added the comment: FYI: I was contacted this week by someone with this problem. The problem was resolved after they updated AIX (was 7100-04-00-). Please note: any oslevel -s reporting six zeros at the end needs the SP that is released in parallel with the base. -- nosy: +Michael.Felt ___ Python tracker <https://bugs.python.org/issue36843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12915] Add inspect.locate and inspect.resolve
Michael Felt added the comment: PR18517 has, likely, a utf-8 dependency. AIX, default latin-1 does not accept the new test. Starting with this merge AIX bot fails with: == ERROR: test_name_resolution (test.test_pkgutil.PkgutilTests) -- Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_pkgutil.py", line 249, in test_name_resolution os.makedirs(d, exist_ok=True) File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/os.py", line 223, in makedirs mkdir(name, mode) UnicodeEncodeError: 'latin-1' codec can't encode characters in position 17-19: ordinal not in range(256) Not completely resolved. -- nosy: +Michael.Felt ___ Python tracker <https://bugs.python.org/issue12915> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12915] Add inspect.locate and inspect.resolve
Michael Felt added the comment:
I am very busy with normal work this week. However I’ll attempt to add a pr
with your (Victor”s) suggestion.
Sent from my iPhone
> On 29 Feb 2020, at 23:36, STINNER Victor wrote:
>
>
> STINNER Victor added the comment:
>
>> File
>> "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_pkgutil.py",
>> line 249, in test_name_resolution
>> os.makedirs(d, exist_ok=True)
> (...)
>> UnicodeEncodeError: 'latin-1' codec can't encode characters in position
>> 17-19: ordinal not in range(256)
>
> The test should be modified to skip the current uw value in the loop
> ("continue") if the filesystem encoding cannot encode the Unicode string
> (catch UnicodeEncodeError on the makedirs() call).
>
> --
>
> ___
> Python tracker
> <https://bugs.python.org/issue12915>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue12915>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12915] Add inspect.locate and inspect.resolve
Change by Michael Felt : -- pull_requests: +18078 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/18720 ___ Python tracker <https://bugs.python.org/issue12915> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added
Michael Felt added the comment: This issue was resolved by issue39802. Marking as fixed, and closed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)
Michael Felt added the comment: The PR for 3.9 breaks AIX build (since https://buildbot.python.org/all/#/builders/119/builds/384) reporting the following: Traceback (most recent call last): File "/data/prj/python/python3-3.9/../git/python3-3.9/setup.py", line 69, in from distutils.command.build_ext import build_ext File "/data/prj/python/git/python3-3.9/Lib/distutils/command/build_ext.py", line 33, in class build_ext(Command): File "/data/prj/python/git/python3-3.9/Lib/distutils/command/build_ext.py", line 63, in build_ext "(default: %s)" % get_platform()), File "/data/prj/python/git/python3-3.9/Lib/distutils/util.py", line 107, in get_platform return get_host_platform() File "/data/prj/python/git/python3-3.9/Lib/distutils/util.py", line 83, in get_host_platform return aix_platform() File "/data/prj/python/git/python3-3.9/Lib/_aix_support.py", line 83, in aix_platform vrmf, bd = _aix_bosmp64() File "/data/prj/python/git/python3-3.9/Lib/_aix_support.py", line 53, in _aix_bosmp64 out = subprocess.check_output(["/usr/bin/lslpp", "-Lqc", "bos.mp64"]) AttributeError: module 'subprocess' has no attribute 'check_output' Will post a PR for this. The cause: Briefly, due to the addition of an importable subprocess must now test specifically for check_output during the early build process. -- nosy: +Michael.Felt ___ Python tracker <https://bugs.python.org/issue39763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)
Change by Michael Felt : -- pull_requests: +18204 pull_request: https://github.com/python/cpython/pull/18847 ___ Python tracker <https://bugs.python.org/issue39763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39798] Update and Improve README.AIX
Michael Felt added the comment: Thanks for asking! Last December I was thinking about this - and what would be the best way to proceed. The reply I liked best suggested working on this - outside of CPython "bugfixes" - perhaps later moving bits into the core. So, motivated by your question I opened an area in github - https://github.com/aixtools/pythonAIXDOC. a) I have done a quick re-write of the current README.AIX - with stress on re-write. b) I have several years experience with packaging Python for AIX (for which I use the IBM compiler) and also manage a Python-buildbot that uses gcc. What I don't want to do is just pour forth lots of notes re: things I have discovered and learned. c) I would appreciate hearing your experiences re: using Python on AIX. Report issues via pythonAIXDOC or my packaging forums (http://forums.rootvg.net/aixtools) and I will reply, study, etc.. as much as I have time to. The experiences (especially frustrations when it works this way (...) on platform Y, but not (the same, or at all) on AIX. Hope this helps! -- versions: +Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)
Michael Felt added the comment:
Almost. The command is run, but not enough of the bootstrap is finished - it
seems.
File "/data/prj/python/git/python3-3.9/Lib/_aix_support.py", line 54, in
_aix_bosmp64
out = out.decode("utf-8").strip().split(":") # type: ignore
AttributeError: 'str' object has no attribute 'decode'
Just skipping the subprocess bit (which is what the original does, waiting for
better moments) is sufficient for the bootstrap phase.
--
___
Python tracker
<https://bugs.python.org/issue39763>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)
Michael Felt added the comment: Comes further. The build finishes, but socket and asyncio are missing... At least a build will proceed, and I can look into this new, perhaps unrelated issue re: socket later. *** WARNING: renaming "_asyncio" since importing it failed: No module named '_socket' -- ___ Python tracker <https://bugs.python.org/issue39763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)
Michael Felt added the comment: re: _socket - I'll start researching now, but it may still be related to this. a) if it looks like related to this issue I'll add a some report here b) in any case, as requested, I'll start a new issue - and leave it to you to decide to close that and continue here, or with the new issue. -- ___ Python tracker <https://bugs.python.org/issue39763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)
Michael Felt added the comment: OK. BEFORE I open a new issue, I am going to guess that something is wrong with finding _socket.so - because it exists, but "something" is not finding it. Following modules built successfully but were removed because they could not be imported:^M _asyncio ^M ^M running build_scripts^M copying and adjusting /data/prj/python/git/python3-3.9/Tools/scripts/pydoc3 -> build/scripts-3.9^M copying and adjusting /data/prj/python/git/python3-3.9/Tools/scripts/idle3 -> build/scripts-3.9^M copying and adjusting /data/prj/python/git/python3-3.9/Tools/scripts/2to3 -> build/scripts-3.9^M changing mode of build/scripts-3.9/pydoc3 from 644 to 755^M changing mode of build/scripts-3.9/idle3 from 644 to 755^M changing mode of build/scripts-3.9/2to3 from 644 to 755^M renaming build/scripts-3.9/pydoc3 to build/scripts-3.9/pydoc3.9^M renaming build/scripts-3.9/idle3 to build/scripts-3.9/idle3.9^M renaming build/scripts-3.9/2to3 to build/scripts-3.9/2to3-3.9^M xlc_r -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I../git/python3-3.9/Include/internal -IObjects -IInclude -IPython -I. -I../git/python3-3.9/Include -I/opt/include -DPy_BUILD_CORE -o Programs/_testembed.o ../git /python3-3.9/Programs/_testembed.c^M ../git/python3-3.9/Modules/makexp_aix Modules/python.exp . libpython3.9.a; xlc_r /opt/lib/libintl.a -L/opt/lib -liconv -lexpat -Wl,-bE:Modules/python.exp -lld -o Programs/_testembed Programs/_testembed.o libpython3.9.so -lintl -l dl -lm -lm ^M NOTE: The module was built successfully, but not found. root@x065:[/data/prj/python/python3-3.9]find . -name _socket.so ./build/lib.aix-5307-0747-32-3.9/_socket.so -- ___ Python tracker <https://bugs.python.org/issue39763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)
Michael Felt added the comment:
I am confused.
The bot complains nearly immediately about missing _socket
Following modules built successfully but were removed because they could not be
imported:
_asyncio
running build_scripts
copying and adjusting
/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Tools/scripts/pydoc3
-> build/scripts-3.9
copying and adjusting
/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Tools/scripts/idle3
-> build/scripts-3.9
copying and adjusting
/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Tools/scripts/2to3
-> build/scripts-3.9
changing mode of build/scripts-3.9/pydoc3 from 600 to 755
changing mode of build/scripts-3.9/idle3 from 600 to 755
changing mode of build/scripts-3.9/2to3 from 600 to 755
renaming build/scripts-3.9/pydoc3 to build/scripts-3.9/pydoc3.9
renaming build/scripts-3.9/idle3 to build/scripts-3.9/idle3.9
renaming build/scripts-3.9/2to3 to build/scripts-3.9/2to3-3.9
./python -E -c 'import sys ; from sysconfig import get_platform ;
print("%s-%d.%d" % (get_platform(), *sys.version_info[:2]))' >platform
./python ./Tools/scripts/run_tests.py -j 1 -u all -W --slowest
--fail-env-changed --timeout=900 -j2 --junit-xml test-results.xml
Traceback (most recent call last):
File
"/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/./Tools/scripts/run_tests.py",
line 12, in
import test.support
File
"/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/support/__init__.py",
line 6, in
import asyncio.events
File
"/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/asyncio/__init__.py",
line 8, in
from .base_events import *
File
"/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/asyncio/base_events.py",
line 23, in
import socket
File
"/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/socket.py",
line 51, in
import _socket
ModuleNotFoundError: No module named '_socket'
while if I use my (now closed) pr18847 I do not get the results immediately -
it starts the whole test series, and then fails - but not because _socket does
not exist, instead:
0:00:48 [ 53/420/2] test_socket failed (30.4 sec) -- running:
test_multiprocessing_fork (48.3 sec)
/data/prj/python/git/python3-3.9/Lib/test/test_socket.py:2557: RuntimeWarning:
received malformed or improperly-truncated ancillary data
result = sock.recvmsg(bufsize, *args)
/data/prj/python/git/python3-3.9/Lib/test/test_socket.py:2648: RuntimeWarning:
received malformed or improperly-truncated ancillary data
result = sock.recvmsg_into([buf], *args)
test test_socket failed -- Traceback (most recent call last):
File "/data/prj/python/git/python3-3.9/Lib/test/test_socket.py", line 1481,
in testGetaddrinfo
self.assertEqual(socktype, socket.SOCK_STREAM)
AssertionError: 0 !=
In short, stumped...
--
___
Python tracker
<https://bugs.python.org/issue39763>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)
Michael Felt added the comment: This was already confirmed by both bots... The last bot build that worked (and for both AIX bots) is: dffe4c07095e0c693e094d3c140e85a68bd8128e The first build that failed (for both) is: 1ec63b62035e73111e204a0e03b83503e1c58f2e See (pass) https://buildbot.python.org/all/#/builders/119/builds/383 and https://buildbot.python.org/all/#/builders/227/builds/369; fail https://buildbot.python.org/all/#/builders/119/builds/384 and https://buildbot.python.org/all/#/builders/227/builds/370 I'll checkout dffe4c07095e0c693e094d3c140e85a68bd8128e to verify it still works successfully. -- ___ Python tracker <https://bugs.python.org/issue39763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)
Michael Felt added the comment:
After a checkout the build finishes (successfully) with:
Python build finished successfully!
The necessary bits to build these optional modules were not found:
_gdbm _lzma _sqlite3
_tkinter _uuid readline
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.
The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc atexitpwd
time
running build_scripts
creating build/scripts-3.9
copying and adjusting /data/prj/python/git/python3-3.9/Tools/scripts/pydoc3 ->
build/scripts-3.9
copying and adjusting /data/prj/python/git/python3-3.9/Tools/scripts/idle3 ->
build/scripts-3.9
copying and adjusting /data/prj/python/git/python3-3.9/Tools/scripts/2to3 ->
build/scripts-3.9
changing mode of build/scripts-3.9/pydoc3 from 644 to 755
changing mode of build/scripts-3.9/idle3 from 644 to 755
changing mode of build/scripts-3.9/2to3 from 644 to 755
renaming build/scripts-3.9/pydoc3 to build/scripts-3.9/pydoc3.9
renaming build/scripts-3.9/idle3 to build/scripts-3.9/idle3.9
renaming build/scripts-3.9/2to3 to build/scripts-3.9/2to3-3.9
/opt/bin/install -c -m 644 ../git/python3-3.9/Tools/gdb/libpython.py
python-gdb.py
xlc_r -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include
-O2 -qmaxmem=-1 -qarch=pwr5-I../git/python3-3.9/Include/internal -IObjects
-IInclude -IPython -I. -I../git/python3-3.9/Include -I/opt/include -I/op
t/include -DPy_BUILD_CORE -o Programs/_testembed.o
../git/python3-3.9/Programs/_testembed.c
../git/python3-3.9/Modules/makexp_aix Modules/python.exp . libpython3.9.a;
xlc_r /opt/lib/libintl.a -L/opt/lib -liconv -lexpat /opt/lib/libintl.a
-L/opt/lib -liconv -lexpat -Wl,-bE:Modules/python.exp -lld -o
Programs/_testembed
Programs/_testembed.o libpython3.9.a -lintl -ldl -lm -lm
sed -e "s,@EXENAME@,/opt/bin/python3.9," <
../git/python3-3.9/Misc/python-config.in >python-config.py
LC_ALL=C sed -e 's,\$(\([A-Za-z0-9_]*\)),\$\{\1\},g' < Misc/python-config.sh
>python-config
root@x065:[/data/prj/python/python3-3.9]./python
Python 3.9.0a4+ (tags/v3.9.0a4-59-gdffe4c0709-dirty:dffe4c0709, Mar 11 2020,
17:09:06) [C] on aix
Type "help", "copyright", "credits" or "license" for more information.
>>>
--
___
Python tracker
<https://bugs.python.org/issue39763>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39936] Python fails to build _asyncio on module on AIX
Michael Felt added the comment: While looking through the history of bot builds - I consistently see 420 tests being done on one bot - but test_socket does not always show up in the list. I'll look at this as I can, but "free-time" is limited. Delay is not a lack of interest. -- nosy: +Michael.Felt ___ Python tracker <https://bugs.python.org/issue39936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39936] Python fails to build _asyncio on module on AIX
Michael Felt added the comment: I'll take a look at what you are suggesting. The starting point (before the rm command) is the make command that I run again. What I notice - read am thinking - is that _socket.so is being created by the "setup.py build" - so, if you can help me make that bit more verbose, I'll work on that too. +++ Script command is started on Wed Mar 11 15:29:44 CDT 2020. $ $ $ $ rm ./build/lib.aix-7200-1543-32-3.9/_socket.so ./build/temp.aix-7200-1543-32-3.9/home/aixtools/python/cpython-master/Modules/socketmodule.o $ $ $ make V=1 CC='gcc -pthread' LDSHARED='Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp' OPT='-DNDEBUG -g -fwrapv -O3 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ./setup.py build running build running build_ext ldd: /lib/libreadline.a: File is an archive. building '_asyncio' extension gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I./Include -I. -I/home/aixtools/python/cpython-master/Include -I/home/aixtools/python/cpython-master -c /home/aixtools/python/cpython-master/Modules/_asynciomodule.c -o build/temp.aix-7200-1543-32-3.9/home/aixtools/python/cpython-master/Modules/_asynciomodule.o Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp build/temp.aix-7200-1543-32-3.9/home/aixtools/python/cpython-master/Modules/_asynciomodule.o -o build/lib.aix-7200-1543-32-3.9/_asyncio.so building '_socket' extension gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I./Include -I. -I/home/aixtools/python/cpython-master/Include -I/home/aixtools/python/cpython-master -c /home/aixtools/python/cpython-master/Modules/socketmodule.c -o build/temp.aix-7200-1543-32-3.9/home/aixtools/python/cpython-master/Modules/socketmodule.o Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp build/temp.aix-7200-1543-32-3.9/home/aixtools/python/cpython-master/Modules/socketmodule.o -o build/lib.aix-7200-1543-32-3.9/_socket.so *** WARNING: renaming "_asyncio" since importing it failed: No module named '_socket' The following modules found by detect_modules() in setup.py, have been built by the Makefile instead, as configured by the Setup files: _abc atexitpwd time Following modules built successfully but were removed because they could not be imported: _asyncio -- ___ Python tracker <https://bugs.python.org/issue39936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39936] Python fails to build _asyncio on module on AIX
Michael Felt added the comment: So, with the patch - the process stops at: aixtools@x064:[/home/aixtools/python-3.9]make CC='xlc_r' LDSHARED='Modules/ld_so_aix xlc_r -bI:Modules/python.exp' OPT='-DNDEBUG -O' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ./setup.py build Traceback (most recent call last): File "/home/aixtools/python-3.9/Lib/subprocess.py", line 72, in import msvcrt ModuleNotFoundError: No module named 'msvcrt' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/aixtools/python-3.9/./setup.py", line 4, in import subprocess File "/home/aixtools/python-3.9/Lib/subprocess.py", line 77, in import _posixsubprocess ModuleNotFoundError: No module named '_posixsubprocess' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/aixtools/python-3.9/./setup.py", line 16, in sys.modules['subprocess'] = _bootsubprocess NameError: name 'sys' is not defined make: 1254-004 The error code from the last command is 1. Stop. -- ___ Python tracker <https://bugs.python.org/issue39936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39936] Python fails to build _asyncio on module on AIX
Michael Felt added the comment: So, this is what I have on screen. Will add the log in a moment. [1] + Donemake 2>&1|tee make.log & aixtools@x064:[/home/aixtools/python-3.9]find . | grep socket ./Doc/howto/sockets.rst ./Doc/library/socket.rst ./Doc/library/socketserver.rst ./Lib/__pycache__/socket.cpython-39.opt-1.pyc ./Lib/__pycache__/socket.cpython-39.opt-2.pyc ./Lib/__pycache__/socket.cpython-39.opt-4.pyc ./Lib/__pycache__/socket.cpython-39.pyc ./Lib/__pycache__/socketserver.cpython-39.pyc ./Lib/socket.py ./Lib/socketserver.py ./Lib/test/__pycache__/mock_socket.cpython-39.pyc ./Lib/test/__pycache__/test_socket.cpython-39.pyc ./Lib/test/__pycache__/test_socketserver.cpython-39.pyc ./Lib/test/mock_socket.py ./Lib/test/test_socket.py ./Lib/test/test_socketserver.py ./Modules/socketmodule.c ./Modules/socketmodule.h ./PCbuild/_socket.vcxproj ./PCbuild/_socket.vcxproj.filters ./build/lib.aix-7104-1806-32-3.9/_socket.so ./build/temp.aix-7104-1806-32-3.9/home/aixtools/python-3.9/Modules/socketmodule.o aixtools@x064:[/home/aixtools/python-3.9]rm ./build/lib.aix-7104-1806-32-3.9/_socket.so ./build/temp.aix-7104-1806-32-3.9/home/aixtools/python-3.9/Modules/socketmodule.o aixtools@x064:[/home/aixtools/python-3.9]make V=1 CC='xlc_r' LDSHARED='Modules/ld_so_aix xlc_r -bI:Modules/python.exp' OPT='-DNDEBUG -O' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ./setup.py build running build running build_ext INFO: Can't locate Tcl/Tk libs and/or headers building '_asyncio' extension xlc_r -DNDEBUG -O -I./Include/internal -I./Include -I. -I/home/aixtools/python-3.9/Include -I/home/aixtools/python-3.9 -c /home/aixtools/python-3.9/Modules/_asynciomodule.c -o build/temp.aix-7104-1806-32-3.9/home/aixtools/python-3.9/Modules/_asynciomodule.o Modules/ld_so_aix xlc_r -bI:Modules/python.exp build/temp.aix-7104-1806-32-3.9/home/aixtools/python-3.9/Modules/_asynciomodule.o -o build/lib.aix-7104-1806-32-3.9/_asyncio.so building '_socket' extension xlc_r -DNDEBUG -O -I./Include/internal -I./Include -I. -I/home/aixtools/python-3.9/Include -I/home/aixtools/python-3.9 -c /home/aixtools/python-3.9/Modules/socketmodule.c -o build/temp.aix-7104-1806-32-3.9/home/aixtools/python-3.9/Modules/socketmodule.o 1500-030: (I) INFORMATION: PyInit__socket: Additional optimization may be attained by recompiling and specifying MAXMEM option with a value greater than 8192. Modules/ld_so_aix xlc_r -bI:Modules/python.exp build/temp.aix-7104-1806-32-3.9/home/aixtools/python-3.9/Modules/socketmodule.o -o build/lib.aix-7104-1806-32-3.9/_socket.so *** WARNING: renaming "_asyncio" since importing it failed: No module named '_socket' Python build finished successfully! The necessary bits to build these optional modules were not found: _gdbm _lzma _sqlite3 _tkinter readline To find the necessary bits, look in setup.py in detect_modules() for the module's name. The following modules found by detect_modules() in setup.py, have been built by the Makefile instead, as configured by the Setup files: _abc atexitpwd time Following modules built successfully but were removed because they could not be imported: _asyncio -- ___ Python tracker <https://bugs.python.org/issue39936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39936] Python fails to build _asyncio on module on AIX
Change by Michael Felt : Added file: https://bugs.python.org/file48971/make.log ___ Python tracker <https://bugs.python.org/issue39936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39936] Python fails to build _asyncio on module on AIX
Michael Felt added the comment:
OK. I removed the _aix_support.py from the formula.
After make see the new (rather) old build paths for "socket"
aixtools@x064:[/home/aixtools/python-3.9]find . | grep socket
./Doc/howto/sockets.rst
./Doc/library/socket.rst
./Doc/library/socketserver.rst
./Lib/__pycache__/socket.cpython-39.opt-1.pyc
./Lib/__pycache__/socket.cpython-39.opt-2.pyc
./Lib/__pycache__/socket.cpython-39.opt-4.pyc
./Lib/__pycache__/socket.cpython-39.pyc
./Lib/__pycache__/socketserver.cpython-39.pyc
./Lib/socket.py
./Lib/socketserver.py
./Lib/test/__pycache__/mock_socket.cpython-39.pyc
./Lib/test/__pycache__/test_socket.cpython-39.pyc
./Lib/test/__pycache__/test_socketserver.cpython-39.pyc
./Lib/test/mock_socket.py
./Lib/test/test_socket.py
./Lib/test/test_socketserver.py
./Modules/socketmodule.c
./Modules/socketmodule.h
./PCbuild/_socket.vcxproj
./PCbuild/_socket.vcxproj.filters
./build/lib.aix-7.1-3.9/_socket.so
./build/temp.aix-7.1-3.9/home/aixtools/python-3.9/Modules/socketmodule.o
I remove these two files again and run make:
aixtools@x064:[/home/aixtools/python-3.9]make
CC='xlc_r' LDSHARED='Modules/ld_so_aix xlc_r -bI:Modules/python.exp'
OPT='-DNDEBUG -O' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ./setup.py
build
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
building '_asyncio' extension
xlc_r -DNDEBUG -O -I./Include/internal -I./Include -I.
-I/home/aixtools/python-3.9/Include -I/home/aixtools/python-3.9 -c
/home/aixtools/python-3.9/Modules/_asynciomodule.c -o
build/temp.aix-7.1-3.9/home/aixtools/python-3.9/Modules/_asynciomodule.o
Modules/ld_so_aix xlc_r -bI:Modules/python.exp
build/temp.aix-7.1-3.9/home/aixtools/python-3.9/Modules/_asynciomodule.o -o
build/lib.aix-7.1-3.9/_asyncio.so
building '_socket' extension
xlc_r -DNDEBUG -O -I./Include/internal -I./Include -I.
-I/home/aixtools/python-3.9/Include -I/home/aixtools/python-3.9 -c
/home/aixtools/python-3.9/Modules/socketmodule.c -o
build/temp.aix-7.1-3.9/home/aixtools/python-3.9/Modules/socketmodule.o
1500-030: (I) INFORMATION: PyInit__socket: Additional optimization may be
attained by recompiling and specifying MAXMEM option with a value greater than
8192.
Modules/ld_so_aix xlc_r -bI:Modules/python.exp
build/temp.aix-7.1-3.9/home/aixtools/python-3.9/Modules/socketmodule.o -o
build/lib.aix-7.1-3.9/_socket.so
*** WARNING: renaming "_asyncio" since importing it failed: No module named
'_socket'
Python build finished successfully!
The necessary bits to build these optional modules were not found:
_gdbm _lzma _sqlite3
_tkinter readline
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.
The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc atexitpwd
time
Following modules built successfully but were removed because they could not be
imported:
_asyncio
The diff!
diff --git a/Lib/_aix_support.py b/Lib/_aix_support.py
index 2c5cd3297d..c7f4491633 100644
--- a/Lib/_aix_support.py
+++ b/Lib/_aix_support.py
@@ -12,7 +12,8 @@ try:
_tmp_bd = get_config_var("AIX_BUILDDATE")
_bgt = get_config_var("BUILD_GNU_TYPE")
except ImportError: # pragma: no cover
-_have_subprocess = False
+import _bootsubprocess as subprocess
+_have_subprocess = True
_tmp_bd = None
_bgt = "powerpc-ibm-aix6.1.7.0"
diff --git a/Lib/distutils/util.py b/Lib/distutils/util.py
index 4b002ecef1..513af52ecd 100644
--- a/Lib/distutils/util.py
+++ b/Lib/distutils/util.py
@@ -79,8 +79,9 @@ def get_host_platform():
machine += ".%s" % bitness[sys.maxsize]
# fall through to standard osname-release-machine representation
elif osname[:3] == "aix":
-from _aix_support import aix_platform
-return aix_platform()
+return "%s-%s.%s" % (osname, version, release)
+# from _aix_support import aix_platform
+# return aix_platform()
elif osname[:6] == "cygwin":
osname = "cygwin"
rel_re = re.compile (r'[\d.]+', re.ASCII)
diff --git a/Lib/sysconfig.py b/Lib/sysconfig.py
index 4003726dc9..b116e96007 100644
--- a/Lib/sysconfig.py
+++ b/Lib/sysconfig.py
@@ -666,8 +666,9 @@ def get_platform():
machine += ".%s" % bitness[sys.maxsize]
# fall through to standard osname-release-machine representation
elif osname[:3] == "aix":
-from _aix_support import aix_platform
-return aix_platform()
+return "%s-%s.%s" % (osname, version, release)
+# from _aix_support import aix_platform
+# return aix_platform()
elif osname[:6] == "
[issue39936] Python fails to build _asyncio on module on AIX
Michael Felt added the comment:
Actually, I had already done that:
diff --git a/Lib/_aix_support.py b/Lib/_aix_support.py
index 2c5cd3297d..c7f4491633 100644
--- a/Lib/_aix_support.py
+++ b/Lib/_aix_support.py
@@ -12,7 +12,8 @@ try:
_tmp_bd = get_config_var("AIX_BUILDDATE")
_bgt = get_config_var("BUILD_GNU_TYPE")
except ImportError: # pragma: no cover
-_have_subprocess = False
+import _bootsubprocess as subprocess
+_have_subprocess = True
_tmp_bd = None
_bgt = "powerpc-ibm-aix6.1.7.0"
And after that test, I tried with no calls to _aix_support.py
diff --git a/Lib/distutils/util.py b/Lib/distutils/util.py
index 4b002ecef1..513af52ecd 100644
--- a/Lib/distutils/util.py
+++ b/Lib/distutils/util.py
@@ -79,8 +79,9 @@ def get_host_platform():
machine += ".%s" % bitness[sys.maxsize]
# fall through to standard osname-release-machine representation
elif osname[:3] == "aix":
-from _aix_support import aix_platform
-return aix_platform()
+return "%s-%s.%s" % (osname, version, release)
+# from _aix_support import aix_platform
+# return aix_platform()
elif osname[:6] == "cygwin":
osname = "cygwin"
rel_re = re.compile (r'[\d.]+', re.ASCII)
diff --git a/Lib/sysconfig.py b/Lib/sysconfig.py
index 4003726dc9..b116e96007 100644
--- a/Lib/sysconfig.py
+++ b/Lib/sysconfig.py
@@ -666,8 +666,9 @@ def get_platform():
machine += ".%s" % bitness[sys.maxsize]
# fall through to standard osname-release-machine representation
elif osname[:3] == "aix":
-from _aix_support import aix_platform
-return aix_platform()
+return "%s-%s.%s" % (osname, version, release)
+# from _aix_support import aix_platform
+# return aix_platform()
elif osname[:6] == "cygwin":
osname = "cygwin"
import re
So, even when _aix_support.py is not involved at all, _socket.so is being
ignored - even though it was built.
--
___
Python tracker
<https://bugs.python.org/issue39936>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39936] Python fails to build _asyncio on module on AIX
Michael Felt added the comment: re: Michael: this issue is about bootstraping Python. If you want to test a patch or test something else, you must restart from a clean copy of the source code. Either use "make distclean", "git clean -fdx", or recreate the source directory (git clone, decompress an archive, etc.). Then restart from scratch: ./configure && make. Understood: between these two timestamps: Date: 2020-03-11 18:55 and Date: 2020-03-11 21:36 - I was doing just that on 4 different VM's: AIX 5.3, 6.1, 7.1 and 7.2 - just in case there may be anything specific re: AIX versions (the bots run on AIX 7.1 and 7.2). I also switched away from any NFS based builds because test behaves differently when the build area is an NFS area compared to jfs2. FYI: I have decided to focus on AIX 7.1 and AIX 7.2 - and am only using gcc (I was also testing runs with both xlc and gcc before I started posting). Further, I like your suggestion to try: subprocess except _bootsubprocess and shall make a PR to that end. Much more clear about what is going on. What I am going to do bewtween now and my next post is again - clean slate - update master to latest version - on two servers. On one server I'll apply your suggestion to _aix_platform.py; on the other I'll patch Lib/distutils/util.py and Lib/sysconfig.py to not even call _aix_platform.py. Ideally, there will be a difference that leads to an understanding of the root cause. -- ___ Python tracker <https://bugs.python.org/issue39936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
