Xavier de Gaye added the comment:
Oh it seems your Fedora 27 also uses systemd and uses the same configuration as
archlinux, see https://wiki.archlinux.org/index.php/Core_dump. In that case
according to this wiki your core dumps go to /var/lib/systemd/coredump and this
may explain the
Xavier de Gaye added the comment:
issue #32031: Do not use the canonical path in pydoc
test_mixed_case_module_names_are_lower_cased
issue #32059: detect_modules() in setup.py must also search the sysroot paths
issue #32126: [asyncio] test failure when the platform lacks a functional
sem_open
Change by Xavier de Gaye :
--
dependencies: +Add platform.android_ver() to test.pythoninfo for Android
platforms, Do not use the canonical path in pydoc
test_mixed_case_module_names_are_lower_cased, [asyncio] test failure when the
platform lacks a functional sem_open(), [ctypes
Xavier de Gaye added the comment:
issue 22724 is fixed for Android.
--
dependencies: -byte-compile fails for cross-builds
___
Python tracker
<https://bugs.python.org/issue26
Xavier de Gaye added the comment:
This problem does not occur at API 24.
--
title: setting SO_REUSEPORT fails -> setting SO_REUSEPORT fails at API 21
___
Python tracker
<https://bugs.python.org/issu
Xavier de Gaye added the comment:
Remove depencies that are not specific to Android.
--
dependencies: -add the '--disable-test-suite' option to configure, add the
'--enable-sourceless-distribution' option to configure, cross compilation of
third-par
Change by Xavier de Gaye :
--
versions: +Python 3.7 -Python 3.6
___
Python tracker
<https://bugs.python.org/issue26865>
___
___
Python-bugs-list mailing list
Unsub
Xavier de Gaye added the comment:
This is issue 26855.
--
___
Python tracker
<https://bugs.python.org/issue26858>
___
___
Python-bugs-list mailing list
Unsub
Xavier de Gaye added the comment:
To debug and reproduce the problem on Android, one must checkout from the
bpo-30386 branch
https://github.com/python/cpython/pull/1629/commits/c0ca089220cd39851d7625b55510be63b340e188.
faulthandler._sigsegv() does crash the crasher in test_crashed, so
Xavier de Gaye added the comment:
What is now the content of the 'build/' subdirectory of the source tree ?
--
___
Python tracker
<https://bugs.python.o
Xavier de Gaye added the comment:
> Ah! I misunderstood the bug report. I was looking for a ENV_FAILED failure,
> but no, regrtest fails to remove its temporary directory but no warning is
> emitted in this case.
Yes :-)
--
___
Pytho
Xavier de Gaye added the comment:
> So running test_regrtest creates build/test_python_816/ but fails to remove
> it because it contains a core dump: core-python.11.816.
Not sure that it is because it contains a core file. Maybe it just does not
remove it because the test c
Xavier de Gaye added the comment:
On a Samsung device with Android 5.1 and tethering enabled, only one network
device has a MAC address and it is not an all-zero MAC address.
Ivan can you please provide more information about this problem: which device,
what Android version, what is the
Xavier de Gaye added the comment:
> I'm not sure that is better than a random address.
I agree, getnode() when obtained from a MAC address should not return 0.
RFC 4122 states (emphasis on 'uniqueness' is mine):
This document specifies three algorithms to g
Xavier de Gaye added the comment:
> C:\> ipconfig -all
So the all-zero MAC address occurs on a Windows box and that explains the
test_windll_getnode failure (this test is skipped on Android). I missed that
point in your initial post and knowing what Android device you are us
Change by Xavier de Gaye :
--
pull_requests: +4833
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue30697>
___
___
Python-
Xavier de Gaye added the comment:
As a reference the discussion about the removal of PyExc_RecursionErrorInst
took place at PR 1981.
The new PR 4941 restores PyExc_RecursionErrorInst on 3.6, not sure if this
should be merged. The same operation could be done on 3.7. Python is not using
Xavier de Gaye added the comment:
The PPC64 AIX 3.x Python buildbot
(http://buildbot.python.org/all/#/builders/10) has been failing upon this same
error for over a month.
Can you please try with:
PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong(st.f_fsid.val[0]));
Or if
Xavier de Gaye added the comment:
But the documentation does say "The arguments shown above are merely the most
common ones...The full function signature is largely the same as that of the
Popen constructor...", no ?
--
nosy: +xdegaye
Xavier de Gaye added the comment:
> The PPC64 AIX 3.x Python buildbot
> (http://buildbot.python.org/all/#/builders/10) has been failing upon this
> same error for over a month.
Michael Felt answered by email:
> Not quite a month: 8 days ago (test 357 was the first with this e
Xavier de Gaye added the comment:
I get the same build failure when the following line is commented out in
Modules/Setup:
_thread _threadmodule.c # low-level threading interface
Can you please attach the full output of the build.
--
nosy: +xdegaye
Xavier de Gaye added the comment:
Your build failure output shows that _threadmodule.c is not compiled and
therefore the _thread module is missing.
You just need to overwrite the current Modules/Setup file (it is possibly
corrupted somehow) as suggested at the start of your attached build
Change by Xavier de Gaye :
--
resolution: -> not a bug
___
Python tracker
<https://bugs.python.org/issue32335>
___
___
Python-bugs-list mailing list
Unsubscrib
Xavier de Gaye added the comment:
It seems that it is possible to keep the current behavior for those that want
to customize the configuration of Modules/Setup.dist (knowing that they can
just use Modules/Setup.local if they are only doing additions to the Setup
configuration) and at the
New submission from Xavier de Gaye :
After applying the attached Makefile.pre.in.diff that changes the text of the
message printed by the 'Makefile' target, the make command gives:
$ make
CONFIG_FILES=Makefile.pre CONFIG_HEADERS= /bin/sh config.status
config.status: creating Makefil
Change by Xavier de Gaye :
--
keywords: +patch
pull_requests: +4938
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32430>
___
___
Py
Xavier de Gaye added the comment:
The Setup files are configuration files, so their handling is different from
the handling of Makefile.pre.in or the handling of the source files.
The only reference to Setup.local in the Python documentation is at
https://docs.python.org/3/extending
Xavier de Gaye added the comment:
> and I've never seen it done by anyone else
In msg294174 Thomas says he intends to use it for Python at Google in order to
"avoid third-party libraries even when they are available on the build system".
I do not have a strong
Xavier de Gaye added the comment:
Yes 3.8 and this leaves plenty of time for writing some documentation on the
build process :-)
--
___
Python tracker
<https://bugs.python.org/issue32
Xavier de Gaye added the comment:
Can you please post the definition of the statvfs structure on AIX.
--
___
Python tracker
<https://bugs.python.org/issue32
Xavier de Gaye added the comment:
Hum, GNU make does re-execute the updated Makefile [1] after the 'Makefile'
target has been remade.
The problem occurs though with the other make variants that do not have this
feature.
[1] This may be shown by updating Makefile.pre.in and addin
Xavier de Gaye added the comment:
Two problems:
* It is not clear whether one should re-run make after the Makefile file has
been updated since the (stale when not using GNU make) Makefile is run to
completion.
* The 'Makefile' target is remade twice when Makefile.pre.in has be
Xavier de Gaye added the comment:
The _ALL_SOURCE feature test macro is set by the AC_USE_SYSTEM_EXTENSIONS macro
in configure.ac.
It is not clear why the _ALL_SOURCE macro is currently needed by Python.
The _ALL_SOURCE feature test macro is defined here:
https://www.ibm.com/support
Xavier de Gaye added the comment:
The following patch may be less invasive and more explicit:
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
index 38b6c80e6b..e0bb4ba869 100644
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -9325,7 +9325,11
Xavier de Gaye added the comment:
New changeset 502d551c6d782963d26957a9e5ff1588946f233f by xdegaye (Michael
Felt) in branch 'master':
bpo-32390: Fix compilation failure on AIX after f_fsid was added to
os.statvfs() (#4972)
https://github.com/python/cpyt
Xavier de Gaye added the comment:
Thanks Michael for your contribution in fixing this issue.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Xavier de Gaye added the comment:
gcc is a little bit lost and prints now the following (false) warning:
gcc -pthread -Wno-unused-result -Wsign-compare -g -Og -Wall -Wstrict-prototypes
-std=c99 -Wextra
-Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers
-Werror
Xavier de Gaye added the comment:
The compilation error occurs only on the master branch, issue 32143 is the
enhancement that is the initial cause of this problem. This went unnoticed
when issue 32143 was resolved because the AIX buildbots were already failing at
that time for another
Xavier de Gaye added the comment:
Both the change in my previous post or using a definition for 'res' are not
needed if 'dup3_works' is removed. That would make the code more clear for both
gcc and a human reader. The attached patch removes it.
Using a definition
Xavier de Gaye added the comment:
Good catch, the code makes much more sense now :-)
--
___
Python tracker
<https://bugs.python.org/issue32441>
___
___
Python-bug
Xavier de Gaye added the comment:
> Let's add 'env=None' to the signature of subprocess.run():
+1
--
___
Python tracker
<https://bugs.
Xavier de Gaye added the comment:
I propose to enhance the changes made by PR 6748 and PR 6749 so that gcc 8
triggers a warning when the function type of a PyMethodDef element does not
match its flags by using a macro (see below) that casts the function first to
the function type
Change by Xavier de Gaye :
--
pull_requests: +6767
___
Python tracker
<https://bugs.python.org/issue13886>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
As stated in msg285810, issue 28180 removed the need for an Android workaround.
After checking this point on the Android API 24 emulator with the current
master branch, I have opened PR 7133 which is Martin's input-readline.v3.patch
with the An
Xavier de Gaye added the comment:
> But the problem is that additional flags can be used, e.g. METH_CLASS.
Right, https://docs.python.org/3/c-api/structures.html says: "The individual
flags indicate either a calling convention or a binding convention". This may
be overcome b
Xavier de Gaye added the comment:
> Pedantically the correct way is to cast to a function pointer with no
> prototype (empty parentheses)
Thanks for raising this point Antti. This is hinted at by the gcc 8
documentation on -Wcast-function-type: "The function type void (*) (void)
Xavier de Gaye added the comment:
> There are still quite a few similar warnings on git-master. Do they indicate
> the same problem or should I open new issues?
This is the same issue, the warning line ends with [-Wcast-functio
Xavier de Gaye added the comment:
All checks have passed on PR 7133, even on macOs, and the PR is ready to be
reviewed :-)
--
___
Python tracker
<https://bugs.python.org/issue13
Xavier de Gaye added the comment:
This is fixed with:
diff --git a/Lib/test/test_pdb.py b/Lib/test/test_pdb.py
index 4f9d28afd3..7b3624fb99 100644
--- a/Lib/test/test_pdb.py
+++ b/Lib/test/test_pdb.py
@@ -1045,7 +1045,7 @@ def test_pdb_next_command_in_generator_for_loop
Change by Xavier de Gaye :
--
keywords: +patch
pull_requests: +7195
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33757>
___
___
Py
Xavier de Gaye added the comment:
> Downstream (RHEL) issue:
> https://bugzilla.redhat.com/show_bug.cgi?id=1585201
Not sure that this is a bug. As Petr Viktorin points out in Comment #4, the
reproducer is not expected to work because of the semantics of RTLD_LOCAL.
So the current bpo
Change by Xavier de Gaye :
--
Removed message: https://bugs.python.org/msg326509
___
Python tracker
<https://bugs.python.org/issue34814>
___
___
Python-bug
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue34814>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
The problem is that when the fifo contains a producer and the more()
method of the producer returns a non-empty bytes sequence, then the
producer must be put back in the fifo first. This is what does the
following change made to Pierrick patch:
diff --git a/Lib
Xavier de Gaye added the comment:
extendleft is an extension module C function (in the _collections
module) that does not release the GIL, so it is thread safe.
--
___
Python tracker
<http://bugs.python.org/issue17
Xavier de Gaye added the comment:
Attached are two test cases for this patch.
test_simple_producer still fails with the new patch because it should be:
self.producer_fifo.extendleft([first, data])
instead of:
self.producer_fifo.appendleft([data, first])
The order of the items in the
Xavier de Gaye added the comment:
> I think you mean:
>
> self.producer_fifo.extendleft([data, first])
>
> Instead of:
>
> self.producer_fifo.extendleft([first, data])
>
> No?
No, I do mean:
self.producer_fifo.extendleft([first, data])
See the doc
Xavier de Gaye added the comment:
After applying the last patch cpython.asyncore_3.patch (while
cpython.asyncore_2.patch does not fail):
==
FAIL: test_simple_producer (test.test_asynchat.TestAsynchat
Xavier de Gaye added the comment:
Hi Senthil,
Thanks for your help with this issue.
self.frame_returning is both a flag to indicate that we are returning
from the current frame and a value (the current frame). We need both
as set_step() (the method invoked when the user runs the step command
Xavier de Gaye added the comment:
My fault :(
The call to print is useless for the test, so I suggest to replace it
with a plain 'pass' statement.
--
___
Python tracker
<http://bugs.python.o
Xavier de Gaye added the comment:
The test has been changed in the default branch by changeset
1b174a117e19. This change replaces the assertIn by a less restrictive
assertTrue. These changes should also probably be made in 3.2 and 2.7
and hopefully this will fix the problem in 3.2 and 2.7
New submission from Xavier de Gaye :
The issue 13183 raises the problem that when the trace function is not
set in the caller frame, the step command fails at a return statement.
This new issue raises the point that, for the same reason:
* the next, until and return statements fail also at
Xavier de Gaye added the comment:
Uploaded pdb_default.patch that applies on the default branch with
minor changes to the initial pdb.patch.
--
Added file: http://bugs.python.org/file25463/pdb_default.patch
___
Python tracker
<h
Xavier de Gaye added the comment:
Uploaded pdb_2.7.patch that applies on the 2.7 branch.
--
Added file: http://bugs.python.org/file25464/pdb_2.7.patch
___
Python tracker
<http://bugs.python.org/issue14
New submission from Xavier de Gaye :
All the problems raised in this issue are caused by self.botframe
being set in a Pdb frame.
In the following pdb session run with python 3.2.2, the first two
frames in the printed stack are Pdb frames, this is wrong. And the
second step command steps
Xavier de Gaye added the comment:
Note that now that this issue is fixed, issue 14743 has become more
visible.
--
___
Python tracker
<http://bugs.python.org/issue13
Xavier de Gaye added the comment:
Uploaded a new patch, pdb_botframe_default_2.patch (that applies to
the current tip of the default branch) with:
* a correction to the initial change made to fix sigint_handler()
* the two test cases
--
Added file: http://bugs.python.org
New submission from Xavier de Gaye :
When a breakpoint is set in one of the frames of the frame stack, Pdb
may not stop at that breakpoint when the frame does not have a trace
function. This problem is closely related to issue 13183 and issue
14728. The following scenario demonstrates this
Xavier de Gaye added the comment:
The previous patch only fixed the problem when the debugger is started
from its main function. Uploaded new patch
pdb_botframe_default_3.patch that fixes pdb.main and the pdb.run*
function.
This patch also corrects pdb.runcall(): in the following session, the
New submission from Xavier de Gaye :
When a breakpoint is set anywhere (in which case the global system's
trace function is set), interrupting the debuggee causes Pdb to stop
into its own code. See the following pdb session run with python on
the current head of the default branch from the
New submission from Xavier de Gaye :
In the following test run with python on the current head of the
default branch, Pdb stops at line 3 where there is no breakpoint after
two breakpoints have been set on the same function (setting two bps on
the same location is useful, for example one bp to
New submission from Xavier de Gaye :
Setting a breakpoint on a function from within that functions makes
pdb to stop at the following line (where no breakpoint is set) after a
continue command. In the following test pdb stops at line 3 where
there is no breakpoint.
=== main.py
New submission from Xavier de Gaye :
In the following test, breakpoint 2 is set incorrectly at line 1 and
pdb does not know how to set a breakpoint on method C.c_foo. However
setting those two breakpoints on both methods is ok after the class
definition has been executed.
=== main.py
Xavier de Gaye added the comment:
Uploaded pdb_default_2.patch that corrects the initial patch: the
trace function must be set in all frames whose co_filename is the
breakpoint file name and not just the first frame of this set.
--
Added file: http://bugs.python.org/file25561
New submission from Xavier de Gaye :
pyclbr must raise ImportError instead of KeyError.
The attached patch fixes the problem. A test case is included.
--
components: Library (Lib)
files: pdb_default.patch
keywords: patch
messages: 160523
nosy: xdegaye
priority: normal
severity: normal
New submission from Xavier de Gaye :
In the following test both breakpoints are set on the line of a
function definition. However pdb does not stop when entering foo whose
breakpoint has been set with 'break 1' while pdb stops when entering
bar whose breakpoint has been set with '
Xavier de Gaye added the comment:
Hi Petri
I have just sent the Contributor Agreement to PSF.
--
___
Python tracker
<http://bugs.python.org/issue14798>
___
___
New submission from Xavier de Gaye :
In the following session, main.py is changed just before the restart
command. Pdb does not stop at Breakpoint 1 after the last continue.
$ python -m pdb main.py
> /path_to/main.py(1)()
-> def foo():
(Pdb) import sys; print(sys.version)
3.2.2 (default,
New submission from Xavier de Gaye :
Pdb behavior is not consistent with GNU gdb behavior when setting a
breakpoint on an empty line, a comment or a multi-line statement (the
breakpoint is ignored by pdb on a non-first line of a multi-line
statement and rejected on empty lines or comment lines
Xavier de Gaye added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker
<http://bugs.python.org/issue14
Xavier de Gaye added the comment:
Uploaded pdb_default_2.patch.
This new patch fixes the previous patch that fails to stop at
breakpoints set in nested functions, and extends the previous patch in
allowing breakpoints outside function and method definitions.
> When a breakpoint is set at
New submission from Xavier de Gaye:
The attached script, named find_duplicate_test_names.py, prints
duplicate regression test method names in a given directory tree.
Running this script on the standard library test suite shows few
duplicates, see below. It means that some of those tests are not
Xavier de Gaye added the comment:
Running find_duplicate_test_names.py (after changing the print
statements) on the 2.7 branch, gives the following output:
$ ./python find_duplicate_test_names.py Lib/test/
Duplicate test method names:
Lib/test/test_unicode.py: .UnicodeTest.test_capitalize
Lib
Xavier de Gaye added the comment:
The attached patch uses the infrastructure of patchcheck.py and
merges the script into patchcheck.py instead of adding a new script.
--
keywords: +patch
Added file: http://bugs.python.org/file27320/duplicate_test_names.patch
Xavier de Gaye added the comment:
patchcheck output with the patch applied:
$ make patchcheck
./python ./Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... 1 file
Fixing whitespace ... 0 files
Fixing C file whitespace ... 0 files
Fixing docs whitespace ... 0
New submission from Xavier de Gaye:
See also issue 16056 for the current list of duplicate test names in
the std lib.
The attached patch improves patchcheck.py to list duplicate test
names when running 'make patchcheck'. This patch to the default
branch can also be applied asis
Xavier de Gaye added the comment:
> To simplify and keep the discussions more focused, etc, I would
> create a new issue for the patch to patchcheck
New issue 16079 has been created.
The proposed patch in the new issue 16079 is slightly improved to
produce a cleaner output by printi
Xavier de Gaye added the comment:
Note that using the module code object to find duplicates does not
allow for selecting among the different code types: function, nested
function, method or class.
Duplicates are extensively used within the std lib:
Running find_duplicate_test_names.py, the
Xavier de Gaye added the comment:
Using the python class browser (pyclbr.py) in conjunction with the
search for duplicates in the module code object would allow to
restrict the listing of duplicates to functions and methods or even
just to methods (depending on the feature requirements), without
Xavier de Gaye added the comment:
> I'm not sure if there is ever a use case for duplicate method
> names. Is there?
property getter, setter, and deleter methods do have the same name.
--
___
Python tracker
<http://bugs.python.
Xavier de Gaye added the comment:
> Here are a couple examples of test method names that don't begin
> with "test_":
>
> def testLoadTk(self):
> def testLoadTkFailure(self):
Also Lib/test/test_smtplib.py test method names start with 'test'
ins
Xavier de Gaye added the comment:
The attached script, named duplicate_code_names.py, takes a file
name list as argument and prints duplicate code names found in these
files ordered by function, class, method and nested class or
function.
The script output on the whole std lib (see the result
Changes by Xavier de Gaye :
Added file: http://bugs.python.org/file27376/std_lib_duplicates.txt
___
Python tracker
<http://bugs.python.org/issue16079>
___
___
Python-bug
Xavier de Gaye added the comment:
Another example where pdb does not stop at breakpoints set at
global, else and finally statements:
$ nl -ba foo.py
1 x = 1
2 def main():
3 global x
4 try:
5 if not x:
6 x = 2
7 else
New submission from Xavier de Gaye:
$ tmp=`mktemp /tmp/foo.XX`; echo 'def foo: pass' > $tmp; python3 -m pdb
$tmp; rm $tmp
Traceback (most recent call last):
File "/usr/local/lib/python3.2/pdb.py", line 1556, in main
pdb._runscript(mainpyfile)
File &q
Xavier de Gaye added the comment:
Attached patch pdb_lnotab.patch uses lnotabs (see
Objects/lnotab_notes.txt) to find the actual breakpoint line number and
parses the module source with tokenize to find the set of function and
fully qualified method names in a module.
The patch fixes issues
501 - 600 of 1492 matches
Mail list logo
