Ned Deily added the comment:
Committed for release in 2.7.9.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
The OS X installer integration backport has been committed in Issue22877.
--
___
Python tracker
<http://bugs.python.org/issue22
Changes by Ned Deily :
--
assignee: ned.deily
components: Build
nosy: ned.deily
priority: normal
severity: normal
status: open
title: PEP 477 (ensurepip backport to 2.7.9): "make install" and "make
altinstall" integration
New submission from Ned Deily:
As part of PEP 477, the attached patch backports to Python 2.7.9 the configure
and Makefile integration for ensurepip from Python 3 (PEP 453 / Issue19553).
As described in PEP 477, for Python 2 ensurepip is not enabled by default by
configure. If there are no
Changes by Ned Deily :
--
components: -Macintosh
nosy: +ezio.melotti, michael.foord, rbcollins -ned.deily, ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue22
Ned Deily added the comment:
Thanks for the report. It appears that all that is needed to trigger the hang
is any operation that invokes the IDLE EncodingMessage dialog ("Non-ASCII
found, yet no encoding declared. Add a line like [...]") in IOBinding.py during
a Save when IDLE is l
Changes by Ned Deily :
Removed file: http://bugs.python.org/file37232/readme.exe
___
Python tracker
<http://bugs.python.org/issue22905>
___
___
Python-bugs-list mailin
Changes by Ned Deily :
--
Removed message: http://bugs.python.org/msg231412
___
Python tracker
<http://bugs.python.org/issue22905>
___
___
Python-bugs-list mailin
Changes by Ned Deily :
--
nosy: -glynnc
resolution: -> rejected
stage: -> resolved
status: open -> closed
title: Returned mail: see transcript for details -> spam
___
Python tracker
<http://bugs.python
Ned Deily added the comment:
Committed for release in 2.7.9.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
The configure and Makefile integration backport has been committed in
Issue22878. Unlike with Python 3, the default is to not install pip unless
specifically enabled at configure time or on the "make altinstall" or "make
install" targets.
Ned Deily added the comment:
Sorry, I'm unable to reproduce the problem using various systems and various
version of Python 2.7. And, as I read the StackOverflow comments, it appears
that no one else was able to reproduce the problem, either. To investigate
further, we would need
Ned Deily added the comment:
This is very unlikely to be a problem in Python itself, rather a problem with
the third-party python-sfml package or a build interaction issue. Have you
asked on either an Arch or a python-sfml list about this? What happens if you
you try "dir(s)&quo
Ned Deily added the comment:
FWIW, your test does seem to run if the C test program is instead built in
32-bit mode (modifying CFLAGS to include "-arch i386"). For example, with the
Apple OS X 10.10 system Python:
DYLD_LIBRARY_PATH=.. arch -i386 /usr/bin/python2.7 test.py
Gizmo 1:
Ned Deily added the comment:
Python is supported on many platforms and the techniques and support for
address layout randomization and similar techniques vary greatly. Also, in
many cases, Python is being used from a distribution built by a third-party,
such as an operating system vendor or
Ned Deily added the comment:
../../source/Python/codecs.c:1022:16: error: use of undeclared identifier
'out'; did you
mean 'outp'?
assert(out == start + ressize);
^~~
outp
--
nosy: +ned.deily
st
Ned Deily added the comment:
Fixed in ce8a8531d29a
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue19676>
___
___
Python-bugs-list mai
Changes by Ned Deily :
--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
___
Python tracker
<http://bugs.python.org/issue22961>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
Clearly we need to support openssl's without SSLv3 so I think some version of
this needs to be applied to all branches (preferably in time for 2.7.9,
Benjamin?). Kurt, if you haven't already, could you sign the contributor
agreement so we can use
Changes by Ned Deily :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue22356>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: -ned.deily
___
Python tracker
<http://bugs.python.org/issue1178>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Re PEP 3149 file names: it hadn't struck me until fairly recently that PEP
3149-style extension file names were never implemented for OS X, i.e. they are
still of the form _helperlib.so. I'm not sure why that is the case since other
aspects of PEP 3149
Changes by Ned Deily :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue22991>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
(Currently, it is not possible to edit a particular message in an issue. You
could add a replacement comment to the issue and ask that the older message be
delete.)
This seems to be a problem date. As documented, plistlib converts plist dates
to/from Python
Changes by Ned Deily :
--
assignee: -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python -ned.deily
versions: -Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Ned Deily added the comment:
The -export-dynamic compile option is not supported nor selected at configure
time for normal builds on OS X. Exactly what configure options did you use? I
see that you have checked Cross-Build for components. What sort of
cross-building are you attempting
Ned Deily added the comment:
That should work just fine, assuming you are using an unmodified Python 3.4.x
source download or the 3.4 branch of a source repo. My best guess as to why you
are running into problems is that you may be picking up build tools other than
those supplied by Apple
New submission from Ned Deily:
As of 2.7.9, OS X installer builds now build and link with a private copy of
OpenSSL when building for deployment targets of 10.5 or earlier (see
Issue17128). Although we no longer produce installers for earlier than 10.5
and even then built them on 10.5
Ned Deily added the comment:
Sorry, I wasn't able to reproduce this. What platform are you running on and
what is the output from the following?
python2.7 -c 'import sys;print(sys.version)'
--
nosy: +ned.deily
___
Python
Changes by Ned Deily :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
The changes for 3.4 are incomplete:
>>> import ssl
Traceback (most recent call last):
File "", line 1, in
File "/py/dev/34/source/Lib/ssl.py", line 122, in
from _ssl import PROTOCOL_SSLv3, PROTOCOL_SSLv23, PROTOCOL_TLSv1
Im
Changes by Ned Deily :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue23051>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Ned Deily added the comment:
Thanks, eryksun. Any objections to closing this issue?
--
___
Python tracker
<http://bugs.python.org/issue22945>
___
___
Python-bug
Changes by Ned Deily :
--
nosy: +orsenthil -ned.deily
___
Python tracker
<http://bugs.python.org/issue22912>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: -ned.deily
___
Python tracker
<http://bugs.python.org/issue22672>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue23100>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Changes by Ned Deily :
--
assignee: -> ned.deily
components: +Build
stage: -> needs patch
versions: +Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/i
Ned Deily added the comment:
By default Python, do you mean the Apple supplied Python in /usr/bin? If so, it
uses an old Apple supplied Tk 8.5. Can you reproduce the problem with the
current python.org 2.7.9 with the current ActiveState Tk 8.5 installed?
--
nosy: +ned.deily
Changes by Ned Deily :
--
nosy: +ezio.melotti, michael.foord, rbcollins
___
Python tracker
<http://bugs.python.org/issue23142>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
I'm no expert on Tk but, as best I can tell, Tix is a very old third-party set
of Tk extension widgets that has been made obsolete by the Ttk widget set
integrated into standard Tk 8.5. See, for example, Kevin Walzer's comments
h
Ned Deily added the comment:
Note that this change causes _ssl.so builds to fail on at least one buildbot,
the OS X Tiger one, where the system OpenSSL version is 0.9.7. I've asked the
buildbot owner to consider installing a local copy of a current OpenSSL. There
may be other buil
Changes by Ned Deily :
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue23163>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Setting to release blocker since this needs to be resolved for 3.4.3. FYI, the
OS X x86 Tiger 3.4 buildbot has been updated to use a local copy of OpenSSL
1.0.1j with SSLv3 disabled and multiple tests now fail (2.7 and default do not
fail, as expected).
http
Ned Deily added the comment:
My guess is that you have an older 32-bit-only Scripting Addition from Adobe
installed. This has nothing to do with Python.
--
___
Python tracker
<http://bugs.python.org/issue23
Ned Deily added the comment:
The solution is to either remove or update /Library/ScriptingAdditions/Adobe
Unit Types.osax/Contents/MacOS/Adobe Unit.
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python track
Ned Deily added the comment:
P.S. See https://discussions.apple.com/thread/4355847?start=0&tstart=0
--
___
Python tracker
<http://bugs.python.org/iss
Changes by Ned Deily :
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue23195>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
The initial difference appears to be a long-standing BSD (including OS X)
versus GNU/Linux platform difference. See, for example:
http://www.postgresql.org/message-id/18c8a481-33a6-4483-8c24-b8ce70db7...@eggerapps.at
Why there is no difference between en and fr
Changes by Ned Deily :
--
title: Sorting with locale (strxfrm) does not work properly with Python3 on
Macos -> Sorting with locale (strxfrm) does not work properly with Python3 on
BSD or OS X
___
Python tracker
<http://bugs.python.org/issu
New submission from Ned Deily:
https://www.openssl.org/news/secadv_20150108.txt
--
components: Build, Macintosh, Windows
messages: 233780
nosy: ned.deily, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Update
Ned Deily added the comment:
It's helpful to keep in mind that IDLE is a Tk application written in Python
and, as such, depends on Tk to do nearly everything associated with writing to
displays and reading from keyboards and pointing devices. If you try
outputting the same string usin
Ned Deily added the comment:
Also, the IDLE help text file (Lib/idlelib/help.txt) and the IDLE documentation
in the Standard Library Reference (Doc/library/idle.rst) refer to the "Windows"
menu and would need to be updated.
--
nosy:
Ned Deily added the comment:
So it does. Thanks, Martin.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Ned Deily :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue23232>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
The patch LGTM (it doesn't hurt) but I'm not sure under what circumstances
anyone would run into this problem. The only scenario I can think of is where
somehow ./configure, Makefile, and setup.py are out-of-sync (not all at the
same rev) and the Makef
Ned Deily added the comment:
Yes, this has the same root cause as the failure in Issue20605 since SMTPServer
in smtpd.py uses getaddrinfo. I'm now able to reliably reproduce the failure.
The system getaddrinfo failure is seen when the OS X 10.6 system's network
configuration is *
Ned Deily added the comment:
OK, the workaround is applied for 3.4.3 and 3.5.0.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
I *thought* I had tested 3.4 before; sorry about that!
--
___
Python tracker
<http://bugs.python.org/issue23211>
___
___
Python-bug
Ned Deily added the comment:
LGTM. Terry, should I apply them?
--
___
Python tracker
<http://bugs.python.org/issue23180>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
Thanks for the patches, Al. Pushed for release in 2.7.10, 3.4.3, and 3.5.0.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
Thanks for the suggested patch. Distutils support for xz compression is the
subject of already open Issue16314. Perhaps you can review and/or comment on
the suggested patch there.
--
nosy: +ned.deily
resolution: -> duplicate
stage: -> resolved
Changes by Ned Deily :
--
nosy: +sbt, vinay.sajip
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue23278>
___
___
Python-bugs-list mai
Ned Deily added the comment:
(It may be several days before I can spend much time on it but I will take a
look.)
--
___
Python tracker
<http://bugs.python.org/issue23
Ned Deily added the comment:
Are the Windows 3.4 and 3.x builds on the buildbot using different versions of
OpenSSL? Certificate verifies would fail with 0.9.7.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue23
New submission from Ned Deily:
_ssl.c compilation is broken on default and 27 when building with older
(pre-1.0.1 ?) versions of OpenSSL:
/py/dev/3x/source/Modules/_ssl.c:2296:24: error: use of undeclared identifier
'OPENSSL_NPN_NEGOTIATED'
if (alpn && ret != OPEN
Ned Deily added the comment:
_ssl.c cannot be compiled with pre-NPN versions of OpenSSL: see Issue23335.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue20
Ned Deily added the comment:
I added a few prints to the send and receive loops of _test_send. When running
on a reasonably current Debian testing Linux:
./python Lib/test/eintrdata/eintr_tester.py
test_read (__main__.OSEINTRTest) ... ok
test_wait (__main__.OSEINTRTest) ... ok
test_wait3
Ned Deily added the comment:
It turns out the times are not important; the hangup is the default size of the
socket buffers on OS X and possibly BSD in general. In my case, the send and
receive buffers are 8192, which explains why the chunks written are so small.
I somewhat arbitrarily
Ned Deily added the comment:
Update: 1.0.1l is now released as of 1/15. (1.0.2 was released as of 1/22 but
it might be premature to go to that.)
--
nosy: -ronaldoussoren
title: Update Windows and OS X installer copies of OpenSSL to 1.0.1k -> Update
Windows and OS X installer cop
New submission from Ned Deily:
With the latest maintenance release of OS X 10.10 (10.10.2), the OpenSSL libs
have reached a patch level that fails the sanity test in test_ssl:
test_ssl: testing with 'OpenSSL 0.9.8zc 15 Oct 2014' (0, 9, 8, 28, 15)
under Mac
Ned Deily added the comment:
eintr-1.diff doesn't seem to make any significant difference from eintr.diff on
my system. It's still pegging a CPU at 100% and takes 7 minutes wall time to
complete.
$ time ./python
~/Projects/PyDev/active/dev/3x/source/Lib/test/eintrdata/eintr
Ned Deily added the comment:
Yep, 0.9.8 is the newest and presumably last major of version of OpenSSL in OS
X. OpenSSL has been officially deprecated by Apple in OS X since OS X 10.7;
it's only there for third-party products shipped by Apple in OS X, like Python.
Their own apps use Ap
Ned Deily added the comment:
With eintr-2.diff, fast!:
$ time ./python
~/Projects/PyDev/active/dev/3x/source/Lib/test/eintrdata/eintr_tester.py
test_read (__main__.OSEINTRTest) ... ok
test_wait (__main__.OSEINTRTest) ... ok
test_wait3 (__main__.OSEINTRTest) ... ok
test_wait4 (__main__
Ned Deily added the comment:
Fixed for 2.7.10, 3.4.3, and 3.5.0.
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Ned Deily :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
The test case appears to only fail with OS X Cocoa Tk (tested with Tk 8.5.17
and 8.6.3); it does not fail with the older OS X Carbon Tk 8.4.20 nor with X11
Tk 8.6.3. It also fails similarly with Python 3.4.x. FWIW, there have been
other reported problems with
Ned Deily added the comment:
Try using "make touch" before "make". Because hg does not preserve precise
time stamps when creating working directories, some build steps are run
unnecessarily after an initial checkout. 'make touch' updates the file time
stamps s
Ned Deily added the comment:
https://docs.python.org/devguide/setup.html#avoiding-re-creating-auto-generated-files
--
___
Python tracker
<http://bugs.python.org/issue23
Changes by Ned Deily :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue23404>
___
Ned Deily added the comment:
Using code signing on OS X sounds like a good idea but does require careful
analysis to ensure it is being used correctly. However, in your example, you
are using and signing the Apple-supplied system Python. It is not advisable to
modify system resources like
Ned Deily added the comment:
Unfortunately, those syntax differences aren't the only problems you could run
into so making these syntax changes isn't really a general solution, IMO. 'make
touch' is the documented and supported way to ensure that the unnecessary build
ste
New submission from Ned Deily:
While investigating another freeze-related issue, I found that Tools/freeze
seems to not work when used with an installed shared unix build. The symptom
is that the linkage step in the freeze-produced Makefile fails with:
gcc -pthread -Xlinker -export-dynamic
Ned Deily added the comment:
Sorry, I've finally gotten around to taking a longer look at this and it seems
that freeze support is kind of a mess. First, it looks like some of the issues
you ran into were fixed in 3.4.1 (changes associated with Issue11824 and
Issue16047). Unfortunately
Changes by Ned Deily :
--
versions: +Python 3.5 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue21502>
___
___
Python-bugs-list mailing list
Unsub
Ned Deily added the comment:
Try launching IDLE from a Terminal window command line shell with:
/usr/local/bin/python3.4 -m idlelib
and see if any error messages are reported. Also please report what is printed
when this is run in a command shell:
/usr/local/bin/python3.4 -c 'impor
Ned Deily added the comment:
Without more information it is hard to provide a meaningful response. You
don't say which version of Python nor which platform you are trying to install
on. Be aware that the default for --prefix is '/usr/local'. On most POSIX
platforms, yo
Changes by Ned Deily :
--
Removed message: http://bugs.python.org/msg235727
___
Python tracker
<http://bugs.python.org/issue23435>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
Without more information it is hard to provide a meaningful response. You
don't say which version of Python nor which platform you are trying to install
on. Be aware that the default for --prefix is '/usr/local'. On most POSIX
platforms, yo
Ned Deily added the comment:
Sorry, I tried using your ./configure with a 2.7.9 tarball on a Debian VM from
which I removed the system Python 2.7 and, despite installing into the
non-standard locations, at a quick look everything seemed to work OK. For
example,
>>> import _co
Ned Deily added the comment:
--enable-shared builds in some cases can erroneously link with an already
installed Python library of the same version. That's what happened on my first
try, before removing the system 2.7. In any case, I'm closing this issue for
now. Feel free to reo
Changes by Ned Deily :
--
nosy: +David.Edelsohn
___
Python tracker
<http://bugs.python.org/issue23457>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Since there has been no followup to this issue, I'm going to close it. Feel
free to reopen if you can document a reproducible problem with a Python source
release.
--
resolution: -> works for me
stage: -> resolved
status: ope
Ned Deily added the comment:
So the real problem here is configuring with --prefix=/ and then using make
install DESTDIR to install to a temporary location. This is a duplicate of
Issue9674; the problem is that --prefix=/ results in build variable the start
with '//', like '/
Changes by Ned Deily :
--
nosy: +davin, sbt
___
Python tracker
<http://bugs.python.org/issue23484>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Without diving into the details of your test program, I get the same results on
a 64-bit Debian Python 2.7.9 as with a 64-bit OS X 2.7.10:
c_uint32 TESTS:
Class Name exponentnumber Signfloat
binary repr
Changes by Ned Deily :
--
nosy: +pje
versions: +Python 3.6 -Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue24291>
___
___
Python-bug
Changes by Ned Deily :
--
nosy: +pje
versions: +Python 3.6 -Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue24292>
___
___
Python-bug
Ned Deily added the comment:
Yury, I'm not seeing that compile error with current head of default on OS X.
Try a clean build, perhaps?
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/is
Ned Deily added the comment:
I think you have a Python installed in /usr/local that is interfering.
--
___
Python tracker
<http://bugs.python.org/issue24
Ned Deily added the comment:
Wild guess: perhaps you did a ./configure or the Makefile did an implicit call
to configure recently and/or you did a make install (to /usr/local) before?
--
___
Python tracker
<http://bugs.python.org/issue24
6201 - 6300 of 6927 matches
Mail list logo
