Ned Deily added the comment:
Does it matter what the contents of the file are, i.e. what do you mean by a
"blank .py" file? I am not able to reproduce that problem.
Be aware that, because of problems with the Apple-suppled Cocoa Tk 8.5 in OS X
10.6, the 2.7.1 IDLE from the 10.6-o
Ned Deily added the comment:
To uninstall, you can do the following:
sudo rm -rf /Library/Frameworks/Python.framework/Versions/2.7
sudo rm -rf /Applications/"Python 2.7"
If you've installed any site-packages, you would need to
Ned Deily added the comment:
r88242 for 3.1
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue11053>
___
___
Python-bugs-list mai
Ned Deily added the comment:
The problem was caused by a minor change in IDLE during the port of IDLE from
2.x to 3.x. It is fixed by the changes for Issue11053: r88234 (3.2rc2) and
r88242 (planned for 3.1.4).
--
resolution: -> duplicate
stage: -> committed/rejected
status
Ned Deily added the comment:
For the record: The problem was caused by a minor change in IDLE during the
port of IDLE from 2.x to 3.x. It is fixed by the changes for Issue11053:
r88234 (3.2rc2) and r88242 (planned for 3.1.4).
--
assignee: ronaldoussoren -> ned.deily
st
Ned Deily added the comment:
7. Backported to 2.7 in r88243 (to appear in 2.7.2).
--
priority: release blocker ->
status: pending -> open
___
Python tracker
<http://bugs.python.org/i
Changes by Ned Deily :
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue10907>
___
___
Python-bugs-list mailing list
Unsubscri
Ned Deily added the comment:
Merged to 2.7 in r88248 (for 2.7.2).
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue10842>
___
_
Ned Deily added the comment:
Merged to 2.7 in r88248 (for 2.7.2).
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue11054>
___
_
Ned Deily added the comment:
According to the StackOverflow report, the crash occurs on Python 3.1.2 with
IDLE 3.1.2 on Windows 7.
--
components: +Windows
nosy: +brian.curtin, kbk, ned.deily
___
Python tracker
<http://bugs.python.org/issue11
Ned Deily added the comment:
Committed in r88270 for release in 2.7.2.
--
status: pending -> closed
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issu
Ned Deily added the comment:
Since IDLE and the turtle modules both use Tkinter and thus are both Tcl/Tk
applications, it wouldn't be surprising if you had problems trying to run a
program using the IDLE module from within IDLE. However, I find I can
successfully run at least one o
Ned Deily added the comment:
er, "trying to run a program using the turtle module from within IDLE"
--
___
Python tracker
<http://bugs.python.o
Ned Deily added the comment:
Now that I looked at the documentation
(http://docs.python.org/library/turtle.html), I see that it is clear that
Turtle is designed to work from IDLE *but*, as is noted, "when using the module
from within IDLE run with the -n switch", which means run ID
New submission from Ned Deily :
As reported by Alex McNerney in Issue11075 msg127687:
"... running Python 2.7.1:88286 (maintenance) [built from source] on
ActiveState Tcl/Tk 8.5.9 causes the idle to hang when a simple script like:
"
x = raw_input("x: ")
print x
"
is
Ned Deily added the comment:
[Please don't add new topics to the same tracker issue. As David mentioned, it
would be better to ask for help on one of the user lists to be sure before
opening an issue. Besides the general python-list, there is an active OS X
users list (pythonmac-sig)
Ned Deily added the comment:
I agree that adding a link to the installed documentation set would be an
improvement. Currently, the only easy way to find it is within IDLE: Help ->
Python Docs (or F1). I'll propose an installer patch for that for 3.2.
-0.5 for removing the Extras d
Ned Deily added the comment:
It's clear from testing it and from some searches that -n is, in fact, required.
--
___
Python tracker
<http://bugs.python.org/is
Ned Deily added the comment:
I saw this post by Gregor:
http://thread.gmane.org/gmane.comp.python.general/334881/focus=334996
I don't know applicable it still is on Windows. But it does seem to be still
true on OS X.
--
___
Python tracker
Changes by Ned Deily :
--
assignee: -> ned.deily
resolution: -> works for me
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
Thanks for the problem report. And thanks for noticing the fix.
--
nosy: +ned.deily
resolution: -> out of date
stage: -> committed/rejected
status: open -> closed
versions: +Python 2.7
___
Python track
Ned Deily added the comment:
After discussions with Raymond, I now agree that it would be better to not copy
the Tools into the Applications/Python 3.x directory since everything else
there is of the double-clickable nature, i.e. aimed at the user more
comfortable with a GUI interface
Changes by Ned Deily :
Added file: http://bugs.python.org/file20662/issue11079_extras_py3k.patch
___
Python tracker
<http://bugs.python.org/issue11079>
___
___
Python-bug
Changes by Ned Deily :
--
keywords: -after moratorium, buildbot, easy, gsoc, patch
___
Python tracker
<http://bugs.python.org/issue11079>
___
___
Python-bug
Ned Deily added the comment:
After looking into these two test failures a bit more, it looks like both are
due to regressions and/or bugs in the ActiveState Tk 8.5.9 Cocoa behavior
versus the Apple Cocoa Tk 8.5.7, with which neither test fails.
The test_tab_identifiers failure may be a test
Ned Deily added the comment:
Thanks for the report. That does indeed seem to be a bug in the test:
"UDPTimeoutTest(SocketTCPTest)" should be "UDPTimeoutTest(SocketUDPTest)"
As the 3.2 release is in its final release candidate stage and this is not a
release critical i
Changes by Ned Deily :
--
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> posix.getgroups() failure on Mac OS X
___
Python tracker
<http://bugs.python
Changes by Ned Deily :
--
assignee: astrand -> docs@python
nosy: +docs@python
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/iss
Ned Deily added the comment:
Ping! Raymond, this needs review and release manager approval to make it into
3.2 final.
--
___
Python tracker
<http://bugs.python.org/issue11
Ned Deily added the comment:
In the paragraph on OS X builds, suggest changing "OS X" to "Mac OS X".
Also, instead of the direct recommendation to install ActiveState Tcl, a
recommendation that could very well change over the lifetime of the 3.2 release
and the released
Ned Deily added the comment:
I understand your point and it is not a huge issue but let me make an attempt
to expand on the rationale.
> * for right now, it is needed to get tkinter to work and if we're too
> indirect about the fix, no one will find it and their install won'
Ned Deily added the comment:
Committed in r88374 and r88375 to py3k for 3.2 and the documentation links part
only in r88376 to 27 for release in 2.7.2.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -&g
Ned Deily added the comment:
Taking a quick look at it, it appears that the Mac Makefile "installunixtools"
target could/should create those links. Note, this is not a problem for the
standard OS X installers as Mac/BuildScript/build-installer.py (in buildPython)
ensures that link
Changes by Ned Deily :
--
assignee: -> ned.deily
___
Python tracker
<http://bugs.python.org/issue11222>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Ned Deily :
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue11229>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
"import time" works for me with the patched build. There should have been a
warning message during the build if the time module failed to build. Perhaps
you have a file permissions problem? Check your lib/python3.2/lib-dynload/ for
file time.so
BTW
Ned Deily added the comment:
You did run "sudo make install"?
--
___
Python tracker
<http://bugs.python.org/issue11222>
___
___
Python-bugs-l
Ned Deily added the comment:
Here's a minimal patch (a subset of Victor's original) that fixes the release
blocker issue. It has been tested in both a shared library build (which now
works) and a framework build (which is not affected as expected). I recommend
that it be appl
Changes by Ned Deily :
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Ned Deily :
--
nosy: +orsenthil
___
Python tracker
<http://bugs.python.org/issue11261>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
If a version of Python 3.2 has been previously installed, a subsequent
re-install of Python 3.2 may fail attempting to install the Documentation
package. On Mac OS X 10.6, the message reported by the installer is:
"The following installation step failed
Changes by Ned Deily :
--
priority: critical -> high
versions: +Python 2.7, Python 3.3
___
Python tracker
<http://bugs.python.org/issue10736>
___
___
Python-
Ned Deily added the comment:
The attached patch corrects the problem in the installer. I'll apply it after
py3k is re-opened.
--
keywords: +patch
stage: needs patch -> commit review
versions: +Python 2.7
Added file:
http://bugs.python.org/f
Ned Deily added the comment:
Applied in py3k (r88475), 32 (r88477) for 3.2.1, and 27 (r88479) unreleased.
--
keywords: +3.2regression -patch
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Pytho
Ned Deily added the comment:
Current OS X zlib is 1.2.3. Test crashes with most recently released zlib,
1.2.5, as well.
--
___
Python tracker
<http://bugs.python.org/issue11
Ned Deily added the comment:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 10 at address: 0x00010170e000
0x0001016eeaa0 in crc32 ()
(gdb) backtrace
#0 0x0001016eeaa0 in crc32 ()
#1 0x0001016e806d in PyZlib_crc32 (self=0x1016aa588, args=0x1016bf220
Ned Deily added the comment:
>>> from test.support import _4G
>>> _4G
4294967296
>>> mapping.size()
4294967300
pbuf.len = 4294967300, len = 4294967300
UINT_MAX = 4294967295
--
___
Python tracker
<htt
Ned Deily <[EMAIL PROTECTED]> added the comment:
"Of course, Mac OS X is both Unix and case-insensitive"
Not so. Case-{in|}sensitivity is an attribute of HFS+ file systems that is
specifiable when a file system is created; it's true that the default is
still case-insens
Ned Deily added the comment:
Note that with current trunk and in-the-pipeline proposed changes, configure is
depending on using the Apple-supplied enhanced version of arch on 10.5+ (e.g.
to force execution in 32-bit mode) so, while the patch here doesn't harm
anything, it points to an
Ned Deily added the comment:
See also newly opened Issue7713 which expands the issue to other platforms .
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue7
Ned Deily added the comment:
See also Issue7724 which addresses the particular case of building with OS X
SDKs.
--
nosy: +ned.deily, ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue7
Ned Deily added the comment:
It's not exactly the same issue but I think it is closely related since
effectively both document the need for setup.py to build with a non-default
system root (or SDK) and some of the hardcoded paths should be being satisfied
from the SDK. So at least par
Ned Deily added the comment:
I suppose all of the relevant setup.py build-time tests could be restructured
as autoconf-style tests using gcc & friends with consistent arguments (with the
build and with Distutils) so there wouldn't need to be special knowledge in
setup.py or config
Ned Deily added the comment:
BTW, I believe there is a problem with ARCH_RUN_32BIT as it stands: as far as I
can tell, unlike lipo, /usr/bin/arch requires -ppc and rejects -ppc7400
regardless if the executable is -arch ppc7400 or -arch ppc
Ned Deily added the comment:
It's not a configuration bug. All current python.org python installers are
built with MACOSX_DEPLOYMENT_TARGET=10.3 and with the 10.4u SDK to allow one
installer to work on systems from 10.3.9 through 10.6.
--
nosy: +ned.
Ned Deily added the comment:
If you have installed Python 2.6.4 using the python.org OS X installer, it was
linked with Tk 8.4, and will not use Tk 8.5. OS X 10.4 has an old version of
Tk 8.4; your best bet is to install the most recent Tcl/Tk 8.4 from ActiveState
Tcl/Tk
Ned Deily added the comment:
Ah, earlier you said you installed Python 2.6.4 but, in your most recent
message, it shows:
katrinewhiteson$ python
Python 2.6 (trunk:66714:66715M, Oct 1 2008, 18:36:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
I'm not sure what that is but
New submission from Ned Deily :
potential 2.6.5 release blocker
The changes introduced for Issue7999 in r78546, r78547, r78548, r78549 cause
test_tcl to fail when it is run after test_os, as is normal under regrtest.
The problem is that the posixmodule was modified to accept values of -1 for
Ned Deily added the comment:
(Thanks to Tom Loredo for bringing up the issue on the pythonmac-sig list.)
--
___
Python tracker
<http://bugs.python.org/issue8
Ned Deily added the comment:
Apparently there is a side effect on OS X 10.6 of setting to -1. See Issue8045.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue7
New submission from Ned Deily :
2.6.5 release blocker
Changes for Issue6877 to enable the readline module to use the
native OS X editline library instead of GNU readline introduce
a problem for OS X installer builds or other builds using
MACOSX_DEPLOYMENT_TARGET. The test in setup.py to
New submission from Ned Deily :
When building on 10.6 with a deployment target of 10.3 or 10.4,
various build errors occur, like:
warning: 'struct winsize' declared inside parameter list
error: 'struct rusage' has no member named 'ru_maxrss'
The problem
New submission from Ned Deily :
Since the split of Python3, the OS X installer build scripts in the
four active source trees have diverged due to multiple edits at
different times such that most changes can no longer be easily
merged across branches without significant hand editing, even
though
Ned Deily added the comment:
Also note that these patches effectively take care of backporting to py3k and
31 the most recent installer script changes that were made to 2.6 and trunk in
support of 10.6 and the newer universal build options
Ned Deily added the comment:
Moving the test to a child process does avoid the problem.
(BTW, so far I've only seen the failure when Tkinter is linked with the
Apple-supplied Tk 8.5 in 10.6, not with Tk 8.4.)
--
___
Python tracker
Ned Deily added the comment:
It looks like the patches were not applied correctly.
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/iss
New submission from Ned Deily :
2.6.5 release blocker
3.1.2 release blocker
For 10.6, new universal build options were added to reflect the dropping of
support in 10.6 for the ppc64 arch. The new options:
--universal-archs=3-way -> -arch {i386,x86_64,ppc)
--universal-archs=intel ->
Ned Deily added the comment:
The attached patches fix the problem for 2.6 and 3.1:
1. configure(.in) is changed to invoke the existing "4way" build targets for
--with-universal-archs values of 3-way and intel as well as all.
2. configure(.in) passes the necessary lipo -extract arch v
Changes by Ned Deily :
Added file: http://bugs.python.org/file16505/issue-sl-configure-32-31.txt
___
Python tracker
<http://bugs.python.org/issue8089>
___
___
Python-bug
Ned Deily added the comment:
Correct inadvertent deletion in the 3.1 Mac/README.
--
Added file: http://bugs.python.org/file16506/issue-sl-configure-32-31-rev1.txt
___
Python tracker
<http://bugs.python.org/issue8
Changes by Ned Deily :
Removed file: http://bugs.python.org/file16505/issue-sl-configure-32-31.txt
___
Python tracker
<http://bugs.python.org/issue8089>
___
___
Python-bug
Ned Deily added the comment:
Also note that this feature has not been backported to 3.1 which means it will
not be in the upcoming 3.1.2 release. (It will not be an issue for the
python.org 3.1.2 installer which will be built with GNU readline as usual to
support older systems
Ned Deily added the comment:
Fix verified for 2.6.
It should still be considered a release blocker for 3.1.2.
--
___
Python tracker
<http://bugs.python.org/issue8
Ned Deily added the comment:
Fix verified for 3.1 and py3k(3.2).
--
___
Python tracker
<http://bugs.python.org/issue8067>
___
___
Python-bugs-list mailin
New submission from Ned Deily :
The current mechanism for urllib and urllib2 on OS X to retrieve network proxy
information is to call _scproxy.c to query the OS X SystemConfiguration
Framework. _scproxy.c uses a schema key,
kSCPropNetProxiesExcludeSimpleHostnames, that was introduced in OS X
Changes by Ned Deily :
Added file: http://bugs.python.org/file16508/Python.crash.log
___
Python tracker
<http://bugs.python.org/issue8095>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
Almost! There's a small but significant typo that needs to be fixed in
the change (r78813) that was committed for 2.6:
- UNIVERSAL_ARCH64_FLAGS="-arch x86_64 -arch x86_64"
+ UNIVERSAL_ARCH64_FLAGS="-arc
New submission from Ned Deily :
Current 2.6.5rc1+ building on OS X:
==
ERROR: test_setuptools_compat (distutils.tests.test_build_ext.BuildExtTestCase
Ned Deily added the comment:
(I should add that this appears to be simply a missing test file. There is no
indication that distutils itself has a problem.)
--
___
Python tracker
<http://bugs.python.org/issue8
Ned Deily added the comment:
Still failing as of 2.6.5rc1.
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue7037>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
Still failing as of 2.6.5rc1.
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue7040>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
The file is the source tree but it doesn't seem to get installed in the
framework which is where the tests are being run from:
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/tests$
ls -l setuptools*
-rw-rw-r-- 1 root admin 159
Ned Deily added the comment:
OK, I tried the patch. Reversing the default sense causes the proxy tests in
test_urllib2 to fail on 10.6 et al. So I changed the sense of the tests in the
patch to match previous behavior; the modified patch is attached.
Unfortunately, it didn't help on
Ned Deily added the comment:
Looks good for 2.6.5 (with 10.6 'intel' build).
--
___
Python tracker
<http://bugs.python.org/issue8089>
___
___
Python-b
Ned Deily added the comment:
I'm guessing this falls into the same category as Issue8102, that is, since the
python tests are also installed and run on end-user systems by various
installers, it is important that none of the tests depend on files from a
python build directory or source
Ned Deily added the comment:
It's not that "srcdir" is broken - that undoubtedly was the value of the source
directory on the *build* machine. The problem is that "srcdir", (and likely
some other build related config variables) has no meaning other than on the
*buil
Ned Deily added the comment:
Note: "Python.framework/Versions/3.2/Python".
You appear to be building from py3k (which will become 3.2), and not Python
3.1.2rc2. There are pending fixes for py3k for OS X framework targeted builds
and there is at least one as yet unmerged fix for
Ned Deily added the comment:
You are correct: setuptools_build_ext.py should have been there. It turns out
the file was missing in my installer builds due to a combination of issues
summarized below. The bottom line is that this is not a problem for 2.6.5 and
my apologies for causing extra
Ned Deily added the comment:
Neither of these problems are new to Python 2.6.5: see Issue7037
(test_asynchat) and Issue7040 (test_smtplib). They have been fixed in trunk
(2.7). Since both failures existed in previous Python 2.6.x releases, my
recommendation is to not treat them as release
Ned Deily added the comment:
You need to run 'make install'. The various "python-32" and "python-64" files
are created and installed by the Mac/Makefile "install_python4way" target which
should be getting called by the main Makefile "instal
Ned Deily added the comment:
Re-opening for 3.1.2: the corresponding fixes have not made it into 3.1.2 yet.
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/iss
Changes by Ned Deily :
--
versions: +Python 3.1 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue8089>
___
___
Python-bugs-list mailing list
Unsub
New submission from Ned Deily :
3.1.2 Release Blocker
If Python 3.1.2rc1 is built with openssl 0.9.7 (which lacks support for sha256
and sha512), hashlib is supposed to substitute use of built-in C
implementations for them. With 3.1.2rc1, the "built-in" versions are avai
Ned Deily added the comment:
Should be: "Still later, r77608 was auto-merged [...]"
--
___
Python tracker
<http://bugs.python.org/issue8166>
___
___
Ned Deily added the comment:
Test failing on 3.1.2rc1. Should this be considered a release blocker?
Perhaps just disable temporarily?
--
nosy: +benjamin.peterson, ned.deily
___
Python tracker
<http://bugs.python.org/issue8
New submission from Ned Deily :
When installation tests are run on a user system using the OS X installer, the
three tests fail with a crash. Similar results would be expected on other
unix-y platforms when tests are run from the install destination, and not the
source or build directories
New submission from Ned Deily :
$ cat bom3.py
# coding: utf-8
print("BOM BOOM!")
$ file bom3.py
bom3.py: UTF-8 Unicode (with BOM) text
$ python3.1
Python 3.1.1+ (r311:74480, Jan 20 2010, 00:37:31)
[GCC 4.4.3 20100108 (prerelease)] on linux2
Type "help", "copyright&quo
New submission from Ned Deily :
On Python 3.1.2rc1 and py3k, "make install" results in two identical spurious
error messages:
Compiling /path/to/lib/python3.1/lib2to3/tests/data/bom.py ...
*** File "/usr/local/lib/python3.1/lib2to3/tests/data/bom.py", line 1
Ned Deily added the comment:
'bad_coding' is still needed in the -x regexp. BTW, it's easy enough to test
by doing something like:
make install DESTDIR=/tmp/p/
--
___
Python tracker
<http://bugs.py
Ned Deily added the comment:
Fix verified.
--
___
Python tracker
<http://bugs.python.org/issue8166>
___
___
Python-bugs-list mailing list
Unsubscribe:
801 - 900 of 6927 matches
Mail list logo
