Ned Deily added the comment:
Thanks for the patch! Committed for release with 3.3.6 and 3.4.1.
--
nosy: +ned.deily
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.3
___
Python track
Ned Deily added the comment:
Looks like the tests were being run on an NFS-based file system. It's not
surprising that the some of the pathlib tests might fail when using NFS due to
subtle differences in semantics and timing. Is it possible for you to run the
tests again using a local
Ned Deily added the comment:
"I hope this can be resolved before the 3.4 final release or it will not be
possible to use cxFreeze with Python 3.4 without additional workarounds in
cxFreeze."
It's too late for this to go into 3.4.0 unless someone can make a really good
case
Changes by Ned Deily :
--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
___
Python tracker
<http://bugs.python.org/issue20885>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
- Along with checking for the latest version of pip, there should be an item to
inspect the installed bundled version of pip to check for changes in the
licenses of pip and its chain of vendored dependencies to ensure we do not
inadvertently taint a Python release
Changes by Ned Deily :
--
nosy: +ghaering
___
Python tracker
<http://bugs.python.org/issue20901>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
@keflavich: To include 64-bit support for Tcl/Tk on OSX, you'll need to
modify python's setup.py file. Search down for
"All existing framework builds of Tcl/Tk don't support 64-bit"
around line 1500 in 2.6; there is explicit code there
Ned Deily added the comment:
This is a side effect of the fix for Issue6202. Prior to r73268,
locale.getpreferredencoding always returned "mac-roman" regardless of the
setting of LANG, so this wasn't a problem in py3k (or 3.0.x builds) up
through 3.1rc1. I can reproduce it
Ned Deily added the comment:
Note, you can produce the same error on OS X or linux by setting
PYTHONIOENCODING="", which effectively overrides the value returned
nl_langinfo(CODESET). In pythonrun.c, create_stdio passes
PYTHONENCODING, if set, on as the "encoding" va
Ned Deily added the comment:
"... create_stdio passes PYTHONIOENCODING ..."
--
___
Python tracker
<http://bugs.python.org/issue6393>
___
___
Python-b
Ned Deily added the comment:
Looks good and the "patched" patch also works in a py3k installer build.
BTW, Mark, I was curious as to why you were unable to reproduce the
problem with your own build. I should have mentioned that my testing
was with complete installer (framework)
Ned Deily added the comment:
FWIW, I've just seen a couple of intermittent 'test_two' failures with a
current py3k on OS X but, in each case, the test passed when auto rerun
in verbose mode.
test test_xmlrpc failed -- Traceback (most recent call last):
File
"
Ned Deily added the comment:
I can't reproduce a hang with the python.org 3.1 IDLE on either 10.4 or
10.5 and with the system Tcl/Tk or with a newer Active Tcl/Tk 8.4
installed. Do you have another version of Tcl/Tk installed in
/Library/Frameworks? Can you give a step-by-step proc
Changes by Ned Deily :
--
assignee: -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue6463>
___
_
Ned Deily added the comment:
Thanks, I'm now able to reproduce on both 10.4 and 10.5 with the Apple-
supplied Tcl/Tk 8.4.7 but apparently not with a newer Tcl/Tk nor with
2.6.2. Investigating further.
--
___
Python tracker
<http://bugs.py
Ned Deily added the comment:
As Jeese points out, there are suspicious signs of MacPorts in the log:
"/opt/local/bin/ginstall -c -d -m 755 Python.framework/Versions/2.6"
Try removing all /opt/local entries from your $PATH and try again with
export MACOSX_DEPLOYMENT_T
Changes by Ned Deily :
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue6806>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
With the patch installed, no regressions were seen running my standard set
of OSX installer builds/installs/regtests on 10.4 and 10.5.
--
___
Python tracker
<http://bugs.python.org/issue6
Ned Deily added the comment:
Reproducible here. Fails with Apple 2.6.1 in 64-bit mode but *not* in
32-bit mode. Also does not fail on 10.6 with recent 64-bit 4-way trunk
built on 10.5.
$ arch -i386 /usr/bin/python2.6
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc
Ned Deily added the comment:
See also Issue6934 for Python3 fix.
--
assignee: -> ronaldoussoren
components: +Macintosh
___
Python tracker
<http://bugs.python.org/iss
Ned Deily added the comment:
Issue5652 suggests removing the Mac/Tools references here and in trunk.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue6
Ned Deily added the comment:
Works for me (2.6.2 tarball, 10.5.8 PPC, gcc build 5493).
Check configure.log and search for the failing "wchar_t" section. Also,
try stripping your $PATH down to bare essentials, removing /opt/local/bin
(MacPorts), /sw/bin (Fink), /usr/local/bin,
New submission from Ned Deily :
Release blocker
On OS X IDLE 2.6 shows two Preference menu items, the second dimmed out,
but only when running with an installed Tk 8.4 > 8.4.7.
This is the same problem identified in Issue6100 and was fixed in trunk
but not backported. Now that the Ap
Ned Deily added the comment:
Here's a status update:
After testing 2.6.3-pre-rc1 with various combinations of Apple and
ActiveState Tk 8.4 and 8.5 on 10.5 and 10.6, so far I have only seen the
"new window hang" problem with Apple's Tk 10.5 (10.5.7) as supplied wit
Ned Deily added the comment:
@Kevin: I didn't say it runs fine with ActiveState TK 8.5.7; that's what
the "other serious issues" refer to. I need to do some more work to
isolate those problems.
--
___
Python tracker
<
Ned Deily added the comment:
I also can verify that the problem is not reproducible using a current
trunk (2.7) and the 10.6 Apple Tk 8.5.7. Further testing of this issue
with both Apple Tk 8.4.x and ActiveState Tk 8.4.19 on 10.4, 10.5, and
10.6 has been hang-free.
It looks like there were
Ned Deily added the comment:
I noticed this while investigating Issue6834. Is this still an open issue
for OS X? Could it explain the symptoms in 6834?
--
nosy: +ned.deily, ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue5
Ned Deily added the comment:
Sorry, that should be Issue6864.
--
___
Python tracker
<http://bugs.python.org/issue5120>
___
___
Python-bugs-list mailing list
Unsub
New submission from Ned Deily :
Potential 2.6.3 release blocker
On OS X 10.6 (Snow Leopard), if you attempt to install a package with a
extension module using a Python from a python.org OS X installer (say,
2.6.x or 3.1.x), the c compilation steps will likely fail in one of two
ways:
1
Changes by Ned Deily :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue6957>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Ned Deily added the comment:
By default on 10.6, gcc builds in 64-bit mode. Nav is one of the
deprecated "classic" Macintosh platform modules and has been removed in
Python 3. It and many other of the deprecated Mac modules use Carbon
interfaces that are only available in 32-b
Ned Deily added the comment:
Tweaking distutils as you propose sounds like a good idea to help with
future releases. Also, the proposed installer variant to support 64-bit
would not have this problem as it would only work with 10.5 and above.
(Perhaps there's a warning in all this
Ned Deily added the comment:
> (that is, assuming the remaining builds and tests
in progress complete normally - I'll update the status when they
finish)
No regressions noted:
- DEPTARGET=10.3, 2-way i386/ppc, built on 10.5:
regrtest on 10.4 ppc, 10.5 ppc, 10.6 i386
- DEPTARGET
Ned Deily added the comment:
Explicitly defining CC during the installer build does seem to fix the
extension build problem, at least for well-behaved extensions. I
successfully tested building simplejson (using both easy_install and
direct setup.py installs) and MySQLdb, both on 10.6 using
Ned Deily added the comment:
Also seen on Python 2.6.3rc1.
--
versions: +Python 2.6
___
Python tracker
<http://bugs.python.org/issue6186>
___
___
Python-bug
Ned Deily added the comment:
Is this a release blocker problem for 2.6.3?
--
nosy: +barry, ned.deily
___
Python tracker
<http://bugs.python.org/issue7
Ned Deily added the comment:
"The Mac version of os.path.normpath doesn't change the path, as per the
posix version, which isn't correct on HFS+, which is not case sensitive."
Not so. Case-sensitive vs case-insensitive behavior is chosen when
initializing an HFS+ file sys
Ned Deily added the comment:
Yes, as shipped from the factory, the default "root" file system is
still case-insensitive but the user can change that. There there are
file systems on attached disk images and NFS-mounted file systems, etc
etc. More to the point, it's not a s
Ned Deily added the comment:
This is a duplicate of Issue5798, the fix for which has not been
backported to 2.6. It is also not limited to OS X 10.6.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue7
Ned Deily added the comment:
Running the test standalone works for me running under Terminal.app:
$ echo $TERM
xterm-color
$ cd /Library/Frameworks/Python.framework/Versions/2.6
$ bin/python2.6 lib/python2.6/test/regrtest.py -u curses test_curses
test_curses
1 test OK.
It's probably fa
Ned Deily added the comment:
I don't know how it works on other platforms but test_get_python_inc is
incorrect when run, as in this case, from a user-installed python rather
than as part of a build of python.
The relevant code in test_sysconfig.py:
>>> (srcdir,) = sysconfig.g
Ned Deily added the comment:
Appears to be a duplicate of Issue3620. It is also not limited to 10.6.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue7
Ned Deily added the comment:
This test works for me using the 2.6.3 installer which is 32-bit only.
It will fail, though, on a 64-bit build since Apple does not supply 64-bit
versions of the Carbon frameworks used by these modules. That's why they
are deprecated and have been remov
Ned Deily added the comment:
test_signal does not fail for me on 10.6 using the python.org 2.6.3
installer (which is 32-bit). The test hangs (presumably in the wait
loop) with a 10.6 64-bit build of Python 2.6.3rc1. FWIW, the 2.6.3
test_signal seems to run OK with Apple's 6
Ned Deily added the comment:
Thanks, I should have looked in trunk first. I thought you had fixed this
already.
--
___
Python tracker
<http://bugs.python.org/issue7
Ned Deily added the comment:
By default, 10.6 prefers to run 64-bit architectures when available. You
can easily tell whether a python 2.x is running as 32-bit or 64-bit by
checking sys.maxint:
$ /usr/local/bin/python2.6 -c 'import sys; print sys.maxint'
2147483647
$ /usr/bin/py
New submission from Ned Deily :
Due to a change in distutils released with Python 2.6.3, packages that
use setuptools (version 0.6c9, as of this writing), or the easy_install
command, to build C extension modules fail with a cryptic message ending
with:
... .egg/setuptools/command
Ned Deily added the comment:
UPDATE for users: With the change to distutils now added in r75256 and a
2.6.4 release in the works, option (3) in the original message should now
read:
(3) patch distutils to restore the previous behavior or
install Python 2.6.4 which is expected to be
Ned Deily added the comment:
It fails for me as well on 10.6 (Intel) with 2.6 and trunk and did not
fail on 10.5 (ppc). time.strptime does an import of a python module from C
code so, not surprisingly, adding a time.strptime call in the main module
prior to the thread.start_new_thread avoids
Ned Deily added the comment:
>gcc-4.0 -arch ppc -arch i386 -fno-strict-aliasing ...
>
>followed, unsurprisingly, by:
>gcc-4.0: installation problem, cannot exec
>'i686-apple-darwin8-gcc-4.0.0': No such file or directory
>From at least OS X 10.4 on, Xcode installs b
Ned Deily added the comment:
10.3 is a red herring, that is the deployment target and is as expected.
If you install the current proper versions of Xcode for your 10.4 or later
systems, things will work as designed. Again, this is not the proper
forum to discuss build problems. If you
Changes by Ned Deily :
--
nosy: -ned.deily
___
Python tracker
<http://bugs.python.org/issue4064>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
As far as I know, there is no documented way to totally install a
python.org OS X installation and the OS X installer does not provide a
general way to uninstall a package. So it would be nice for the Python
installer to provide some sort of uninstall script
New submission from Ned Deily :
Possible Release Blocker
A number of proxy test cases in test_urllib2 are now failing with:
ERROR: test_proxy (test.test_urllib2.HandlerTests)
--
Traceback (most recent call last):
File
Ned Deily added the comment:
See also Issue7149.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue7044>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
I'll test it on 2.6 later today.
--
___
Python tracker
<http://bugs.python.org/issue7149>
___
___
Python-bugs-list mailing list
Ned Deily added the comment:
The supplied patch looks good and applies cleanly to 2.6 as well. I built
and tested it with both 2.6 and trunk and the tests now all pass as
expected.
--
versions: +Python 2.7
___
Python tracker
<h
New submission from Ned Deily :
On OS X, urllib.request in Python 3 is supposed to use the operating
system's proxy configuration by default, unless overridden by
environment variables or by the caller providing an explicit proxy
configuration.
In Python 2, urllib (and, indirectly, ur
Ned Deily added the comment:
In Python 2, urllib2.getproxies is one of a number of helper functions
imported from urllib. It's not externally documented there, either, and
likely not intended to be used externally.
--
nosy: +ned.deily
___
P
New submission from Ned Deily :
Several issues with urllib/urllib2 documentation regarding proxy usage:
1. The Macintosh proxy description in section 21.5.1 is out-of-date:
"In a Macintosh environment, urlopen() will retrieve
proxy information from Internet Config."
Ned Deily added the comment:
BTW, I did test manually changing the system proxy configuration via the
Network preference panel and verified that urllib/urllib2 used the default
proxy settings. I suppose it would be possible to set up some tests using
the OS X scutil command but it would be
Ned Deily added the comment:
One comment:
+ :envvar:`_proxy`. In a Windows environment, if no proxy
+ environment variables are set, proxy settings are obtained from the
+ registry's Internet Settings section. In a Mac OS X environment,
proxy
+ information is retrieved from fro
Ned Deily added the comment:
While you're poking around in urllib2, perhaps I can interest you in
looking at these patches.
--
nosy: +orsenthil
versions: +Python 3.2 -Python 3.0
___
Python tracker
<http://bugs.python.org/i
Ned Deily added the comment:
FYI, approximately 20 of the gamma test cases fail on PPC Macs. Attached
are snippets from regrtest runs with trunk and with py3k, both on a G4 ppc
(32-bit) running OS X 10.5. Identical failures for trunk (did not try
py3k) were observed on a G3 ppc with OS X
Ned Deily added the comment:
For the record, these OS X installer build scripts (running on 10.5)
results in these gcc options:
gcc-4.0 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -
fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -
I/tmp/_py/libraries/usr/local
Ned Deily added the comment:
Verified that r75454 makes the gamma test errors go away on a PPC Mac.
--
___
Python tracker
<http://bugs.python.org/issue3
Ned Deily added the comment:
Verified that the original regression reported against 2.6.3 when using
setuptools 0.6c9 has been fixed and no longer exists in 2.6.4rc2.
--
___
Python tracker
<http://bugs.python.org/issue7
Ned Deily added the comment:
Verified that test_urllib2 no longer fails with 2.6.4rc2.
--
___
Python tracker
<http://bugs.python.org/issue7149>
___
___
Python-bug
Changes by Ned Deily :
--
assignee: -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue7179>
___
_
Ned Deily added the comment:
Building a batteries-included framework on OS X is not a simple task,
especially on 10.6 Snow Leopard where the system default is to build 64-
bit archs. There are several known build issues with building a
complete framework on 10.6. It's not clear what
Changes by Ned Deily :
--
assignee: -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue7192>
___
_
Ned Deily added the comment:
Duplicate of Issue6186?
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue7194>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
/etc is definitely not the right place to put files for OS X framework
builds; if necessary, an etc directory could be added under the
framework version directory as a sibling of bin and lib. It's also very
un-OS X like to be putting things into ~/.pytho
Ned Deily added the comment:
I don't think there's a misunderstanding. By "putting", I meant "reading"
or "writing". IMO, /etc is not the place on OS X to be looking for
python-related configuration files, certainly not for framework install
Ned Deily added the comment:
For people searching the bug tracker, I've modified the title of the
issue to make it clearer that there is a problem here on OS X 10.6 Snow
Leopard with multiple architecture builds.
As Ronald mentions above, the effect of using the pythonw "launcher
Changes by Ned Deily :
--
versions: +Python 2.6, Python 3.1
___
Python tracker
<http://bugs.python.org/issue6834>
___
___
Python-bugs-list mailing list
Unsub
Ned Deily added the comment:
Philip is correct:
>>> p.stdout.flush()
Traceback (most recent call last):
File "", line 1, in
IOError: [Errno 9] Bad file descriptor
>>> p.stdout
', mode 'rb' at 0x100527470>
You'll get the same error on OS X
Changes by Ned Deily :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue7243>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Ned Deily added the comment:
The missing return result in the else case has been subsequently fixed in
r75539 (py3k) and r75541 (3.0) so this issue should be re-closed.
--
___
Python tracker
<http://bugs.python.org/issue6
Changes by Ned Deily :
--
assignee: -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren
versions: -Python 3.0
___
Python tracker
<http://bugs.python.org/iss
Ned Deily added the comment:
The test program depends on an external third-party module graphics.
>From the problem description and a web search, I assume the file is:
http://mcsp.wartburg.edu/zelle/python/graphics.py
Can you confirm that?
Using that module, target.py runs on 1
Ned Deily added the comment:
Can you be more specific about how to reproduce the problem you saw?
Also, which version of Python were you using? Please copy the information
from the the first line of IDLE's Python Shell window, like so:
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
Ned Deily added the comment:
>I initially came across the error when attempting to get a modules list
>and was returned a list of errors. One of them was the [errno 13].
OK, now that makes more sense!
The problem is that somehow you had a write-only directory ("~/Public/Drop
Bo
Ned Deily added the comment:
More precisely: you should check for and remove whatever is adding
"Drop Box" or a directory within it to your Python sys.path.
--
___
Python tracker
<http://bugs.python.
Ned Deily added the comment:
Also seeing it on 10.5 ...
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue7408>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
This does seem to be a long standing Unix*-flavor behavior difference.
The open(2) man page on OS X (and presumably FreeBSD) reads:
When a new file is created, it is given the group of the directory
which contains it.
The Linux open(2) page has
Ned Deily added the comment:
BTW, it's trivial to demonstrate the difference.
On OS X:
$ cd $HOME
$ mkdir test
$ touch test/test
$ chown :musicg test
$ touch test/test2
$ ls -l test
total 0
-rw-r- 1 nad staff 0 Nov 29 14:01 test
-rw-r- 1 nad musicg 0 Nov 29 14:01 test2
New submission from Ned Deily :
Release blocker
The changes for Issue7211 to support 64-bit kevent ident fields
in 64-bit builds cause compile errors on those OS X multi-arch
builds which include both 32-bit and 64-bit variants.
Problem is reproducible by this simplified build config
Ned Deily added the comment:
This patch causes build errors on 32-bit/64-bit multi-architecture builds
on OS X. See Issue7416 for more info and a patch.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue7
Ned Deily added the comment:
Another reminder: when implementing, make sure platform.architecture()
always returns the correct results for bits. It seems the Apple patches
in 10.6 don't handle that (it seems to always report 64-bit), probably
because the code in platform.archite
New submission from Ned Deily :
See the thread starting at http://mail.python.org/pipermail/pythonmac-
sig/2009-December/021907.html for full details.
It appears two vestigial gif files included in the 2.6.4 OS installer
are being installed under corrupted file names by the OS X Installer.app
Ned Deily added the comment:
Works for me on 10.4.11 PPC (G3) machine rather than Intel (which
shouldn't make a difference). But from your config.log, the gcc version
is older than what I have on 10.4 (build 5250 vs build 5370). Suggest
ensuring you have the most recent Xcode for
Ned Deily added the comment:
"PPC (G3) machine rather than Intel (which shouldn't make a difference)"
... but did in this case. Perhaps it's too early in the morning yet but I
don't see why that error doesn't show up for me when building trunk on an
Intel machi
Ned Deily added the comment:
Ronald, it's a more complicated configure issue. I'm in the middle of
pinning down the details. More shortly ...
--
___
Python tracker
<http://bugs.python.
Ned Deily added the comment:
I agree that adding the definitions of HAVE_GCC_ASM_FOR_X87 to
pymacconfig.h solves the problem.
[mini-rant on]
This problem is another illustration of how easy it is to inadvertently
introduce significant bugs in the OS X multi-architecture support, bugs
which
Ned Deily added the comment:
Mark, I wasn't ranting at you or Ronald or anyone in particular. It's no
secret that Python's build system is complex and fragile in some areas.
On the other hand, the build system is ambitious, covering a wide variety
of platforms and variants,
Ned Deily added the comment:
I've built an installer image to test this consisting of 2.6.4 plus r76715. If
you're still willing to test this on 10.3, I'll contact you via email with the
download details.
--
___
Python
New submission from Ned Deily :
r77031 (trunk) and r77032 (py3k) for Issue6834 enhanced the
the OS X python interpreter launcher, python/pythonw, to
allow user-selection of the interpreter execution architecture
for multiple architecture builds, i.e. 32-bit vs 64-bit, by
using the enhanced
Ned Deily added the comment:
Note, r77031 and r77032 cause compile errors for OS X deployment targets of
10.4 or earlier. See Issue7658 for details and patch.
--
___
Python tracker
<http://bugs.python.org/issue6
Ned Deily added the comment:
Not cleanly, I think. The problem is there's no spawn.h in the 10.4u SDK so it
can't be built on 10.4 without supplying a copy of a system header file.
--
title: OS X pythonw.c compile error with 10.4 or earlier deployment target ->
O
5501 - 5600 of 6927 matches
Mail list logo
