Change by Michael Felt :
--
nosy: -Michael.Felt
___
Python tracker
<https://bugs.python.org/issue40170>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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/issu
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 -- Tr
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
Change by Michael Felt :
--
pull_requests: +15955
pull_request: https://github.com/python/cpython/pull/16376
___
Python tracker
<https://bugs.python.org/issue36
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.o
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
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 A
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/issu
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/issue43
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
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 s
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
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/fi
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/issu
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
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:
>
> ./p
Michael Felt added the comment:
Sure. Probably have to rebase first.
--
___
Python tracker
<https://bugs.python.org/issue28276>
___
___
Python-bugs-list mailin
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 scri
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
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
an
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
st
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
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
&
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 = stdsc
Change by Michael Felt :
--
type: -> crash
___
Python tracker
<https://bugs.python.org/issue43659>
___
___
Python-bugs-list mailing list
Unsubscrib
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.o
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
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
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/is
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
Change by Michael Felt :
--
pull_requests: +16795
pull_request: https://github.com/python/cpython/pull/17303
___
Python tracker
<https://bugs.python.org/issue38
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
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/issue22
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>
___
___
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/issue22
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
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 revisio
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
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/issu
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.o
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 eas
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
Change by Michael Felt :
--
components: +Extension Modules
___
Python tracker
<https://bugs.python.org/issue39020>
___
___
Python-bugs-list mailing list
Unsub
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
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
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 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
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
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
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
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
Change by Michael Felt :
--
nosy: +Michael.Felt
___
Python tracker
<https://bugs.python.org/issue39502>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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 "
Change by Michael Felt :
--
pull_requests: +17660
pull_request: https://github.com/python/cpython/pull/18285
___
Python tracker
<https://bugs.python.org/issue39
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
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/issue39
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/issue39
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
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
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
Change by Michael Felt :
--
pull_requests: +17680
pull_request: https://github.com/python/cpython/pull/18303
___
Python tracker
<https://bugs.python.org/issue39
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/issue39
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
<ht
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 or
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/issu
Change by Michael Felt :
--
versions: +Python 3.8, Python 3.9 -Python 2.7
___
Python tracker
<https://bugs.python.org/issue28276>
___
___
Python-bugs-list mailin
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/issu
Michael Felt added the comment:
Closing, as not longer relevant.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Michael Felt added the comment:
Not an issue in 3.9, so, closing: "not relevant"
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.py
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 ->
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
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
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
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
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:
>
>> Fil
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/issu
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.or
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
Change by Michael Felt :
--
pull_requests: +18204
pull_request: https://github.com/python/cpython/pull/18847
___
Python tracker
<https://bugs.python.org/issue39
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, motivat
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(":") # typ
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 mo
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 th
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:^
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
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
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
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 la
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 m
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=
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
./
Change by Michael Felt :
Added file: https://bugs.python.org/file48971/make.log
___
Python tracker
<https://bugs.python.org/issue39936>
___
___
Python-bugs-list mailin
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
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")
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
1 - 100 of 737 matches
Mail list logo
