Changes by Ned Deily :
--
nosy: +georg.brandl
stage: -> patch review
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue24084>
___
___
Py
Changes by Ned Deily :
--
nosy: +lukasz.langa
versions: +Python 3.5 -Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue24086>
___
___
Pytho
Changes by Ned Deily :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue24124>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue24120>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
stage: -> patch review
type: crash ->
___
Python tracker
<http://bugs.python.org/i
Changes by Ned Deily :
--
nosy: +haypo
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue24111>
___
___
Python-bugs-list mailing list
Unsub
Changes by Ned Deily :
--
stage: -> patch review
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Changes by Ned Deily :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> argparse assertion failure with brackets in metavars
___
Python tracker
<http://bugs.python
Ned Deily added the comment:
This checkin also breaks OS X framework builds. For some reason, framework
builds are compiled with the gcc -fno-common option. The code in configure.ac
to add that option dates back to the initial OS X framework support
(c3c87ce4afdc from 2001). It's not
New submission from Ned Deily:
As noted in msg242635 of issue23911, for some reason configure.ac adds the gcc
-fno-common option for OS X framework builds. Is this still necessary? I'm
guessing it might be vestigial code left over from the Mac toolbox support in
Python 2 that was remov
Ned Deily added the comment:
Sorry, that second patch should have been:
diff -configure.ac
--- a/configure.ac Tue May 05 12:04:35 2015 -0700
+++ b/configure.ac Tue May 05 18:22:39 2015 -0700
@@ -2346,7 +2346,7 @@
Linux*|GNU*) LINKFORSHARED="-Xlinker -export-dy
Changes by Ned Deily :
--
nosy: +lukasz.langa
___
Python tracker
<http://bugs.python.org/issue24131>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue24132>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +ghaering
___
Python tracker
<http://bugs.python.org/issue24139>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue24140>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Thanks for the report. This problem and solution was just reported recently in
Issue24111.
--
nosy: +ned.deily
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Valgrind suppression file shoul
Changes by Ned Deily :
--
nosy: +christian.heimes
___
Python tracker
<http://bugs.python.org/issue24111>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
[Thanks for the headsup about the contributor agreement form, now reported as
https://github.com/python/pythondotorg/issues/747]
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue24
Changes by Ned Deily :
--
nosy: -ned.deily
___
Python tracker
<http://bugs.python.org/issue24142>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Ned Deily:
This has come up in the past (for example, Issue549764) but, AFAIK, no one has
shown much interest in pursuing such a feature by providing a patch. Note that
it would likely be very tricky to cover all the edge cases properly. As a
practical matter, one reason
Ned Deily added the comment:
[Note, this is in response to the opening of this issue by krichter; the
opening did not generate a message itself]
This has come up in the past (for example, Issue549764) but, AFAIK, no one has
shown much interest in pursuing such a feature by providing a patch
Changes by Ned Deily :
--
Removed message: http://bugs.python.org/msg242728
___
Python tracker
<http://bugs.python.org/issue24143>
___
___
Python-bugs-list mailin
Changes by Ned Deily :
--
priority: normal -> low
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue24143>
___
___
Python-bugs-list
Ned Deily added the comment:
Thanks for the report. This problem was just introduced and just fixed an hour
ago: see issue22906. Try updating to the very latest tip and try again.
--
nosy: +ned.deily
resolution: -> out of date
stage: -> resolved
status: open -&g
Ned Deily added the comment:
Thanks for the report. This problem has just been fixed. Please update and
try again.
--
nosy: +ned.deily
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python track
Ned Deily added the comment:
(See Issue22906 for details.)
--
___
Python tracker
<http://bugs.python.org/issue24150>
___
___
Python-bugs-list mailing list
Unsub
Ned Deily added the comment:
Thanks for the report. I'm not able to reproduce the failure myself. Can you
give more information on what platform this was run on (OS version) and at what
changeset the build was with (hg summary)? Perhaps you could try debugging the
execution of that
Ned Deily added the comment:
I can reproduce the failure by arbitrarily adding a non-ascii character to one
of the mailcap files searched for by the mailcap module
(https://docs.python.org/3/library/mailcap.html#mailcap.getcaps), like
$HOME/.mailcap, and by setting the process to an ascii
Ned Deily added the comment:
The failures seem pretty clear:
OSError: [Errno 28] No space left on device
Are you allocating enough disk space in the chrooted environments? The amount
of free space needed to run all the tests varies by platform, by architecture,
by test options selected, etc
Ned Deily added the comment:
Skip, looking at the test, it seems likely that there is unexpected writing to
stdout in the subprocess. Can you add a print(out) in the test (around
test_os.py:1273) to see what is actually being written on your machine?
--
nosy: +ned.deily
Changes by Ned Deily :
--
nosy: +alexandre.vassalotti, pitrou
___
Python tracker
<http://bugs.python.org/issue24159>
___
___
Python-bugs-list mailing list
Unsub
Changes by Ned Deily :
--
nosy: +ghaering
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue16864>
___
___
Python-bugs-list mai
Changes by Ned Deily :
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.org/issue20362>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Possibly related: Issue15238 (msg165591 re root)
--
nosy: +hynek, ned.deily
___
Python tracker
<http://bugs.python.org/issue24
Ned Deily added the comment:
There are places in the test suite that assume 127.0.0.1 is the standard
loopback address and will fail if the system under test doesn't follow that
convention; see, for example, the discussion in Issue22753. I suspect that, in
your case, the system
Ned Deily added the comment:
If you are using a Python 3.4.3 from a python.org installer for OS X or have
built your own, have you installed the latest ActiveTcl 8.5.x as described
here?
https://www.python.org/download/mac/tcltk/
If not, you should have received a warning when you launched
Ned Deily added the comment:
Thanks for the additional info. I don't know what possible configuration
options might affect this other than that I would expect to see 127.0.0.1 as
the primary IPv4 address on the loopback interface, like:
# ifconfig
[...]
loLink encap:Local Loo
Changes by Ned Deily :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue23882>
___
___
Python-bugs-list mailing list
Un
Ned Deily added the comment:
This is undoubtedly a crash in Tk, not in Python itself, so there won't be any
Python traceback.
--
___
Python tracker
<http://bugs.python.org/is
Ned Deily added the comment:
Unless I'm very much mistaken, this is another instance of the old Cocoa Tk
problem documented here (http://sourceforge.net/p/tktoolkit/bugs/2722/) and
referred to in https://www.python.org/download/mac/tcltk/. It's not like a
normal TclError in that
Ned Deily added the comment:
Lots of "LookupError: unknown encoding: koi8_t" test failures (on OS X 10.10)
after this commit, for example, in test_codecs:
==
ERROR: test_basics (test.test_codecs.BasicU
Ned Deily added the comment:
Also the 10.6 (Snow Leopard) buildbot:
http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/3125/steps/test/logs/stdio
--
___
Python tracker
<http://bugs.python.org/issue22
Ned Deily added the comment:
Thanks! I'm going to assume then that installing a current ActiveTcl 8.5.x
will fix the problem for you.
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python
Ned Deily added the comment:
All better, thanks!
--
___
Python tracker
<http://bugs.python.org/issue22681>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
OK, that explains the failure. You must have set the OS X crash reporter
default to "Developer" mode on that machine at some point. In that case, code
that is now in the SuppressCrashReport context manager in
Lib/test/support/__init__.py checks for th
Ned Deily added the comment:
@doko, are you referring to the results of
{sysconfig,distutils.util}.get_platform()? What effect would this have on
third-party packages that currently support multiple versions of Python?
Also, if get_platform() is meant, I don't understand the comment &q
Ned Deily added the comment:
OK, but I still don't understand your comment about OS X. get_platform() on OS
X in general returns info about the platform build environment (e.g. the
implied set of all OS versions and CPU archs supported), not about the specific
machine environment
Ned Deily added the comment:
Thanks for your report. Alas, according to the W3C XML 1.0 specification:
"For compatibility, the string " -- " (double-hyphen) MUST NOT occur within
comments."
So, it appears minidom (and other XML parsers) are correct in rejecting your
Ned Deily added the comment:
The test for lzma being importable is not sufficient.
==
ERROR: test_make_archive_xztar
(distutils.tests.test_archive_util.ArchiveUtilTestCase
Changes by Ned Deily :
--
nosy: +steve.dower
___
Python tracker
<http://bugs.python.org/issue9377>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
I can reproduce a crash with your sample program using the current numpy wheel
(1.9.2) and the python.org 3.4.3. The significant parts of the OS X crash dump:
Crashed Thread:0 Dispatch queue: com.apple.main-thread
Exception Type:EXC_BAD_ACCESS
Ned Deily added the comment:
This appears to be a BSD-ism: I get the same result on FreeBSD 10 as with OS X
10.10. For whatever reason, mkdir('/') returns IsADirectoryError while
mkdir('/other/existing/directory') returns FileExistsError.
--
nosy: +ned.deily
st
Ned Deily added the comment:
Try building python with debug on:
./configure --with-pydebug [...]
Also, 3.4.2 has been replaced by 3.4.3 which includes the fixes from Issue22653.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.
Ned Deily added the comment:
It doesn't seem to be true for other mount points; the ones I tried raise
FileExistsError. I suppose one could dig into the OS sources. I see that none
of the FreeBSD or OS X mkdir man pages nor the POSIX 2013 spec document EISDIR
as an expected error from
Ned Deily added the comment:
Majeed, the fixes for this issue were released several years ago and the issue
has been closed. Comments on it will likely be ignored. If you believe there
is a problem in the current versions of Python 3 (3.4.3) or Python 2 (2.7.9),
please open a new issue with
Changes by Ned Deily :
--
nosy: +ezio.melotti, michael.foord, rbcollins
___
Python tracker
<http://bugs.python.org/issue24247>
___
___
Python-bugs-list mailin
Changes by Ned Deily :
--
components: +Library (Lib) -Argument Clinic
nosy: +bethard, r.david.murray -larry
___
Python tracker
<http://bugs.python.org/issue24
Ned Deily added the comment:
FWIW, the random segfault seems to be triggered by hash randomization. If I
disable randomization, it does not seem to fail:
for i in `seq 1 20`; do PYTHONHASHSEED=1 ./python -m test.regrtest -m
test_basic test_configparser ; done
Presumably, the --forever
Ned Deily added the comment:
This is really a duplicate of Issue5831 which ended up being closed as a
duplicate of Issue10968. The resolution of the latter issue was to change
threading.Timer in Python 3.3 to actually be a class, a new feature. But it
appears that along the way the issue of
Changes by Ned Deily :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue24258>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue24259>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue24262>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
components: -Unicode
nosy: +rbcollins
versions: +Python 3.5 -Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue24
Ned Deily added the comment:
Ronald, the change to set the SOABI was pushed several weeks ago (but, because
I left out a #, the commit message did not also show up here as I intended):
New changeset 32c24eec035f by Ned Deily in branch 'default':
Issues #22980, 23969: For OS X, us
Changes by Ned Deily :
--
nosy: +serhiy.storchaka
___
Python tracker
<http://bugs.python.org/issue24264>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
"If you want to recognize architecture specific sonames"
For OS X we don't have a need to recognize architecture specific sonames
because we want to continue to defer to the operating system to make the
decisions about which, if any, architecture
Changes by Ned Deily :
--
nosy: +dstufft, ncoghlan
___
Python tracker
<http://bugs.python.org/issue24267>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Problems with the python.org website are tracked at
https://github.com/python/pythondotorg/issues. This is a duplicate of
https://github.com/python/pythondotorg/issues/531.
--
nosy: +ned.deily
resolution: -> third party
stage: -> resolved
status
Ned Deily added the comment:
One workaround should be to disable network proxy lookups by defining the
environment variable 'no_proxy' with value '*' in the Python process, for
example:
env no_proxy='*' python3.4 ...
--
___
Changes by Ned Deily :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> exception error in _scproxy.so
___
Python tracker
<http://bugs.python
Ned Deily added the comment:
(@suki, I assume this is the issue reported here:
https://github.com/jupyter/notebook/issues/111 ?)
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue23
Ned Deily added the comment:
The problem you are seeing is due to MacPort's non-standard method of building
the gdbm module separately in a stand-alone build instead of during the normal
building of the complete Python standard library. As of 3.5.0a4 with
49910ff21ba5 for Issue20184, Mo
Changes by Ned Deily :
--
nosy: +serhiy.storchaka, terry.reedy
___
Python tracker
<http://bugs.python.org/issue27918>
___
___
Python-bugs-list mailing list
Unsub
Ned Deily added the comment:
You used "pip uninstall" to uninstall the Fedora-supplied pip (/usr/bin/pip)?
That would be a really *bad* thing to do. And does Fedora supply a modified
ensurepip / pip? What happens if you try this with a vanilla Python 3.5.x
built from source?
Changes by Ned Deily :
--
nosy: +dstufft, ncoghlan
___
Python tracker
<http://bugs.python.org/issue27924>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Sorry, 2.7.12 built from source.
--
___
Python tracker
<http://bugs.python.org/issue27924>
___
___
Python-bugs-list mailing list
Unsub
Ned Deily added the comment:
It would be nice to use the existing @requires_mac_ver() decorator to skip the
tests (see Lib/test/support/__init__.py).
--
___
Python tracker
<http://bugs.python.org/issue27
Ned Deily added the comment:
Mark, ah, yes, that's true. So the tests would have to be separated out into a
separate test case method. So, not worth the effort.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Ned Deily :
--
components: +Windows -Documentation
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<http://bugs.python.org/issue27
Changes by Ned Deily :
--
nosy: +scoder -skrah
___
Python tracker
<http://bugs.python.org/issue27899>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Thanks for the new option. Perhaps the top-level README should be updated to
mention --with-optimizations?
--
nosy: +ned.deily
versions: +Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue26
Ned Deily added the comment:
We could also ask David, the buildbot owner, if he could update the Python used
for hg. I'm pretty sure it's not the system Python since that's too old.
--
nosy: +db3l, ned.deily
___
Python
Ned Deily added the comment:
We will no longer use the OS X system OpenSSL for 3.6.
--
resolution: not a bug -> third party
stage: -> resolved
status: pending -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
Thanks, David!
--
___
Python tracker
<http://bugs.python.org/issue28039>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
priority: release blocker ->
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
Thanks for the patch, Brett. Having done a quick test, I'd like to review this
in more detail before applying but that will have to wait until after b1. If
you want, you can reassign this to me.
--
priority: release blocker -> deferred block
Ned Deily added the comment:
Stephen, thanks for submitting the patch. Unless another core developer has
time to review and commit this prior to the feature code off tomorrow, this
will probably need to wait for 3.7. Also, at the moment, your tracker user
record does not indicate that there
Ned Deily added the comment:
One could argue that it is a bug that the other constants are missing. Ethan,
if you can work with Christian to get them in by b2, that would be acceptable.
--
nosy: -larry
___
Python tracker
<http://bugs.python.
Ned Deily added the comment:
This change touches a lot of files and affect both the unix* and Windows build
processes so, yeah, I think it's too risky to go in to b1. Let's get it in as
soon as possible after b1.
--
___
Python trac
Ned Deily added the comment:
Thanks for the report. This seems to be a problem visible in the public betas
of the upcoming macOS 12 release, not in previous releases (10.11 and earlier).
Do you know if the problem has been reported to Apple? Also, I've uploaded a
reviewable version of
Ned Deily added the comment:
OK, if you get a chance, it would be helpful to submit a RADAR on it and update
this issue. I neglected to mention that your patch does seem to work, e.g.,
test_eintr no longer fails.
--
___
Python tracker
<h
Ned Deily added the comment:
I'm not sure it should be a permanent fix. Perhaps you could add the test
decorator so that it is only tested on 10.12. I don't have time to look at it
more myself before b1.
--
___
Python trac
New submission from Ned Deily:
Issue28082, for 3.6.0b1, modified the re module to use enum.IntFlag. As
described in Issue19325, on interpreter startup site.py imports sysconfig
which, on OS X, imports _osx_support which imports, among other things, re.
Now that re imports enum, a number of
Changes by Ned Deily :
--
dependencies: +_osx_support imports many modules
___
Python tracker
<http://bugs.python.org/issue28095>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
(The OS X Tiger buildbot uses a version of GCC 4.0.)
--
___
Python tracker
<http://bugs.python.org/issue28092>
___
___
Python-bug
Ned Deily added the comment:
Serhiy, what do you think?
--
___
Python tracker
<http://bugs.python.org/issue28086>
___
___
Python-bugs-list mailing list
Unsub
Ned Deily added the comment:
Do we know for sure that the manylinux1 builds are affected by this, i.e. can
someone try building manylinux1 for 3.6?
On the one hand, it is clear that many core developers would like to use these
newer features of C, features that have been available for many
Ned Deily added the comment:
If it has waited this long and is truly low priority, I think it can wait a
little longer until 3.7.
--
___
Python tracker
<http://bugs.python.org/issue24
Ned Deily added the comment:
Let's target it for 3.7 and when it is ready we can discuss whether to backport
it to 3.6 as well.
--
versions: +Python 3.7 -Python 3.6
___
Python tracker
<http://bugs.python.org/is
Ned Deily added the comment:
Thanks for the info, Nick. With that in mind, I"m removing this as a "release
blocker" for now. Steven, would it be possible to upgrade gcc on your system?
We'll have to deal with the Tiger buildbot separately.
--
prior
6701 - 6800 of 6927 matches
Mail list logo