Ned Deily added the comment:
[wrong issue number in commit]
New changeset 381c7f897207 by Ned Deily in branch 'default':
Issue #13590: Improve support for OS X Xcode 4:
http://hg.python.org/cpython/rev/381c7f897207
I think this is now in decent shape for 3.3.0b1.
Remaining work incl
Ned Deily added the comment:
An initial set of changes to support Xcode 4.3+ have been applied for Python
3.3.0b1 have been applied via Issue13590. As noted there, a back port of some
subset is needed for 3.2 and 2.7. I'll update this after 3.3.0b1 has been
rel
Changes by Ned Deily :
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue15184>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
This test failure points at a few issues:
- The CFLAGS modification should only be taking place on OS X systems.
AFAICT, all of that code is protected by sys.platform checks. One possible
culprit, though, might be distutils test test_unixccompiler which
Changes by Ned Deily :
Added file: http://bugs.python.org/file26164/issue15184_osx_support.patch
___
Python tracker
<http://bugs.python.org/issue15184>
___
___
Python-bug
New submission from Ned Deily :
==
FAIL: test_ldshared_value (test.test_sysconfig.TestSysConfig)
--
Traceback (most recent call last):
File
"/Li
Changes by Ned Deily :
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue15194>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
assignee: -> ned.deily
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue15195>
___
___
Python-bugs-list mai
Ned Deily added the comment:
It looks like the Python you are using was built without GNU readline. You
probably need to install the libreadline-dev package from Ubuntu and rebuild
Python.
--
nosy: +ned.deily
resolution: -> invalid
status: open -> p
Ned Deily added the comment:
3x is now using clang to compile on 10.7 Lion; 32 is failing back to the Xcode
4 default of llvm-gcc which has proved problematic fox 3x. Rather than tweak
the test again, try appending a CC=clang to the ./configure for the 3.2
buildbot until the clang changes
Ned Deily added the comment:
Looks like using clang brought the size back down again. Closing.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Ned Deily added the comment:
Thanks of the patch! I reworded it slightly to completely remove the reference
to the script.
--
nosy: +ned.deily
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Pytho
Ned Deily added the comment:
Thanks for the patch!
--
nosy: +ned.deily
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
What version of OS X?
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue15285>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
That's an odd failure. I've not seen it nor can I reproduce it on 10.7 using
the standard Apple Xcode 4.3.3 clang nor on 10.6 using the Apple Xcode 3.2.6
gcc-4.2. You appear to be using a MacPorts-built gcc-4.2. Can you try with an
Apple-supplie
Ned Deily added the comment:
Actually this is a real test case error. The problem is observed when the
system under test is connected to subnet "10.0.x.x". The requested address
(10.0.0.0) is then a broadcast address for the subnet. On OS X and (I believe)
BSD networking sy
Ned Deily added the comment:
Also OS X universal builds have many of the characteristics of a cross-build.
In particular, one executable (like the python interpreter) can contain both
32-bit and 64-bit architecture files. So tests for 32-bit vs 64-bit at build
time using the running
Ned Deily added the comment:
As usual, there seem to be small but significant differences among the
implementations. Testing with the three OS X Tk implementations shows that
currently:
1. Aqua Tk 8.5 and Aqua Tk 8.4 do not supply a default extension
when saving. With patch issue4832.diff
Ned Deily added the comment:
The web update hook is broken at the moment:
http://article.gmane.org/gmane.comp.python.devel/134057
--
nosy: +ned.deily
versions: -Python 3.3
___
Python tracker
<http://bugs.python.org/issue15
Ned Deily added the comment:
The resolution of this test failure is dependent on the resolution of
Issue15298, which will change the approach needed. Since this is a relatively
minor issue, I don't think there is a need for a interim fix.
--
components: +Tests
priority:
Ned Deily added the comment:
(Once this issue is resolved, a permanent fix for the minor OS X test case
failure of Issue15188 can be developed and applied.)
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue15
Changes by Ned Deily :
--
dependencies: +_sysconfigdata is generated in srcdir, not builddir
___
Python tracker
<http://bugs.python.org/issue15188>
___
___
Pytho
Ned Deily added the comment:
I think you're right that the casts are incorrect. I think the existing cast
ia a day one bug in Python 3. The question is why hasn't it been a problem?
That area needs fixing up since NSModuleForSymbol, NSLookupAndBindSymbol, and
NSLibraryNameFor
Ned Deily added the comment:
See open Issue12978.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue15238>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
Terry, are you planning to commit this? If not, I can do it. It would be good
to get this into 3.3.0b2 since it does fix an important usability issue.
--
___
Python tracker
<http://bugs.python.org/issue4
Ned Deily added the comment:
os.path.join is working as documented. See
http://docs.python.org/library/os.path.html#os.path.join
"If any component is an absolute path, all previous components (on Windows,
including the previous drive letter, if there was one) are thrown away, and
jo
Ned Deily added the comment:
Fixing sys.executable to point to the stub launcher instead of the interpreter
in the fw will also fix other unrelated issues, like making python3-32 work
properly in 64-/32-bit builds for IDLE and for tests that spawn interpreters in
subprocesses. Today, while
Ned Deily added the comment:
Committed for 3.3. I'm +0.5 for 2.7 and 3.2. It seems like a bug to me.
Terry, I'll leave it up to you to handle that and any further doc updates you
want to make.
--
title: idle filename extension -> IDLE does not supply a default
Ned Deily added the comment:
That's correct, the failing test was being run from a venv. I see now that
what had changed is that the fixes for Issue15241 recently added the
test_prefixes test case to test_venv and that fails when the test is run from
within a venv. Without that new
Ned Deily added the comment:
Possible duplicate of Issue4591?
--
nosy: +haypo, ned.deily
___
Python tracker
<http://bugs.python.org/issue15301>
___
___
Python-bug
Ned Deily added the comment:
There is a proposed patch by haypo with Issue4591.
--
___
Python tracker
<http://bugs.python.org/issue15301>
___
___
Python-bug
Ned Deily added the comment:
v5 fixes the non normalized path issue. However, the PYTHONEXECUTABLE env var
-> argv processing is still broken, as detected by the test_osx_env failure.
It's definitely caused by interaction between pythonw.c and the main
interpreter; if the interp
Changes by Ned Deily :
--
assignee: ronaldoussoren -> ned.deily
___
Python tracker
<http://bugs.python.org/issue15353>
___
___
Python-bugs-list mailing list
Un
Changes by Ned Deily :
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue15364>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
v7 looks good to me
--
stage: -> commit review
___
Python tracker
<http://bugs.python.org/issue15307>
___
___
Python-bugs-lis
Ned Deily added the comment:
Georg, are you still able to reproduce this? I've subsequently tried on a
Debian platform with an installed clang and could not reproduce. And, after
further inspecting the current code, I really don't see how the clang
substitution could happen on a
Changes by Ned Deily :
Removed file:
http://bugs.python.org/file26163/issue15184_preserve_config_vars.patch
___
Python tracker
<http://bugs.python.org/issue15
Ned Deily added the comment:
Distribute is not part of Distutils. According to its PyPI page
(http://pypi.python.org/pypi/distribute#feedback-and-getting-involved), the
project has its own issue tracker at
https://bitbucket.org/tarek/distribute/issues/
--
nosy: +ned.deily
resolution
Changes by Ned Deily :
--
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue15380>
___
___
Python-bugs-list mailing list
Unsubscri
Ned Deily added the comment:
> This is a little arbitrary, but seems as sensible a value as any other.
> (Or maybe it would be better to have get_config_var('srcdir') == None
> instead.)
'srcdir' is problematic for any installed build. Once "make install
Ned Deily added the comment:
Upon further consideration, while it sounds appealing, perhaps returning None
is not the better choice. As far as I know, up until now all config vars are
either of type str or type int. Adding None to the mix might be asking for
trouble.
With no patch, running
Ned Deily added the comment:
I should have noted that, in the above tests,
distutils.sysconfig.get_makefile_filename() is already doing the right thing:
>>> dsc.get_makefile_filename()
'/py/dev/default/b10.7_t10.7_x4.3_cclang_d/fw/root/Library/Frameworks/pytest_10_7.framework/Ve
Ned Deily added the comment:
I don't see how this is related to Issue15298. In the failure here, sysconfig
returns the expected value; the problem is with what distutils.sysconfig
returns.
--
___
Python tracker
<http://bugs.python.org/is
Ned Deily added the comment:
I haven't been able to reproduce this failure on either 10.6 or 10.7 with or
without pydebug and either at 3fbfa61634de or the now slightly more current
tip. What filesystem are you running the test under? What ./configure options
did you use? What com
Ned Deily added the comment:
And OS X doesn't support the *at system calls so HAVE_RENAMEAT will always be
false on OS X. I don't recall every seeing this test fail before.
--
___
Python tracker
<http://bugs.python.o
Ned Deily added the comment:
Thanks, Flávio. That configuration looks perfectly normal and what I use so
that should not be an issue.
Interesting link, David. I'm not able to reproduce that failure on 10.6.8
using the procedure in the link but I am running 10.6.8 on a virtual machi
Ned Deily added the comment:
I've committed an updated version of the refactoring patch which attempts to
handle some additional edge cases and which includes a number of additional
tests. I still have not been able to reproduce the original failure so I'm
setting the status
Ned Deily added the comment:
This problem has been fixed in changeset d76b83803e7e for Issue15184 which,
among other things, tries to make the handling of ARCHFLAGS more consistent.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
superseder:
Ned Deily added the comment:
Buildbot test failure:
http://buildbot.python.org/all/builders/AMD64%20Snow%20Leopard%203.x/builds/66
--
resolution: fixed ->
status: pending -> open
___
Python tracker
<http://bugs.python.org/i
Ned Deily added the comment:
The problem isn't with clang. The problem was that the test appeared to be
taking an OS X only code path apparently because a clang was installed on a
Gentoo machine.
--
___
Python tracker
<http://bugs.py
Ned Deily added the comment:
The new buildbot failure is due to that buildbot using env variables for some
of the config variables during execution. The new tests need to isolate
themselves from that. Should have a fix shortly.
--
___
Python
Ned Deily added the comment:
Pending the final resolution of Issue15298, this changes ensures that the
temporary build paths do not leak into the installed interpreter. At the
moment, the test is still failing because the CFLAGS values returned by the two
sysconfigs differ in whitespace
Ned Deily added the comment:
I believe I've fixed the buildbot failure but the buildbot is not very stable
and test runs aren't always completing. I'll check back on it later.
--
resolution: -> fixed
status: open -> pending
_
Ned Deily added the comment:
With the changes here along with the fixes in Issue15184, I'm declaring this
resolved for 3.3. If and when _sysconfigdata.py gets moved, build-installer.py
will need to be tweaked.
--
dependencies: -_sysconfigdata is generated in srcdir, not bui
Ned Deily added the comment:
The buildbot failures were reproducible on OS X 10.6 with Xcode 3. With the
latest two fixes and with the fixes for Issue15188, I believe this issue is
resolved for 3.3.
--
status: open -> closed
___
Python trac
Ned Deily added the comment:
The attached patch ensures that additional SOABI-suffixed symlinks are created
in the framework lib and lib/pythonx.x/config-yy directories and fixes
pythons.x-config to not return garbage data for the --ldflags option.
# current
$ ls -l /Library/Frameworks
Ned Deily added the comment:
Georg, I'd like to apply this for both 3.2.4 and 3.3.0b2. It's a low risk bug
fix but does solve a real problem for users wanting to embed Python on OS X.
Issue15353 is also fixed by this.
--
nosy: +ge
Ned Deily added the comment:
Fix applied for release in 3.2.4 and (with release manager approval) for
3.3.0b2.
--
components: +Build -Macintosh, None
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: comp
Ned Deily added the comment:
Thanks for the report. The python-3.3.pc file is correct. It is a symlink to
the python-3.3m.pc. What isn't correct is that OS X framework builds were not
creating the proper libpython3.3m.{dylib,a} symlinks for use with
python3.x-config and with pkg-c
Changes by Ned Deily :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue15438>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
LGTM
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue15364>
___
___
Python-bugs-list mai
Changes by Ned Deily :
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue11602>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Ned Deily :
==
FAIL: test_dump_traceback_threads (test.test_faulthandler.FaultHandlerTests)
--
Traceback (most recent call last):
File
Ned Deily added the comment:
Without investigating further, my instinct would be to prefer to truncate in
the middle, if possible, otherwise truncate the head of the path, rather than
truncate the tail.
--
___
Python tracker
<h
Ned Deily added the comment:
I believe you'll find that the "update" target in the Doc Makefile will install
or update all the necessary doc tools including Sphinx.
--
___
Python tracker
<http://bugs.pyt
Ned Deily added the comment:
Sorry, of course! The devguide is not the docset.
--
___
Python tracker
<http://bugs.python.org/issue15311>
___
___
Python-bug
Ned Deily added the comment:
Thanks for the patch.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Ned Deily :
==
FAIL: testAtanSign (test.test_cmath.CMathTests)
--
Traceback (most recent call last):
File
"/Library/Frame
Ned Deily added the comment:
> I assume the failure still happens in debug mode?
Yes
> Are there any math module failures?
No
> What do math.log1p(0.0) and math.log1p(-0.0) give? (Answers *should* be 0.0
> and -0.0 respectively.)
>>> math.log1p(0.0)
0.0
>
Ned Deily added the comment:
>>It also doesn't agree with what 'man log1p' says on my OS X 10.6
>>Macbook: under 'SPECIAL VALUES', it says: 'log1p(+-0) returns +-0.'
That manpage is unchanged for 10.8.
>>I'm puzzled about one thing, t
Ned Deily added the comment:
It looks like the buildbot is still building them:
http://buildbot.python.org/all/buildslaves/bolen-dmg
I'm not sure who set up the web site link.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Ned Deily:
getpath.c uses three OS X APIs that have been producing deprecation warnings
since at least OS X 10.5: NSModuleForSymbol, NSLookupAndBindSymbol, and
NSLibraryNameForModule. We should figure out how to live without them.
--
assignee: ronaldoussoren
Ned Deily added the comment:
The SDK test in setup.py has been extended to include files in
/Library/Frameworks (see OS X ld man page). The test in IDLE
to issue a warning message about unstable Tcl/Tk versions was
updated to include the Apple-supplied Tcl/Tk 8.5 in OS X 10.7
and 10.8. All of
Ned Deily added the comment:
BTW, the applied patch does fix the problem originally reported. Thanks.
--
___
Python tracker
<http://bugs.python.org/issue15
Ned Deily added the comment:
That would be nice although if you use your documented trick in Mac/README:
./configure --enable-framework=/Users/ronald/Library/Frameworks
everything including the Applications directory is installed relative to the
frameworks directory, so, in this case
Ned Deily added the comment:
Notice in the reply to Issue3907, "with 2.6, you have to use io.open()
explicitly". This is still true in Python 2.7, i.e. the new 3.x-compatible io
library is not used by default in Python 2. If you want to use it with
subprocess.Popen, one way is t
Ned Deily added the comment:
Tcl/Tk 8.5.12 has now been released. After installing ActiveTcl 8.5.12 for OS
X, your 3.2 test case that previously readily failed for me no longer does. So
I hope you also find that the problem is now resolved.
--
stage: -> committed/rejected
sta
Ned Deily added the comment:
There already is a hook in place for the main python.org repository that checks
for and rejects changesets that include files with space issues:
http://hg.python.org/hooks/file/bd04c6b37749/checkwhitespace.py
You can add it to your local repo to check patches
Changes by Ned Deily :
--
nosy: +ezio.melotti, michael.foord
___
Python tracker
<http://bugs.python.org/issue15551>
___
___
Python-bugs-list mailing list
Unsub
Ned Deily added the comment:
-1 for making wholesale whitespace changes. It potentially makes merging harder
for little benefit. Imported files from other projects should definitely not be
touched. IMO, the only thing potentially worth considering is extending the
existing hook to C files
New submission from Ned Deily:
setup.py supports building Python with an OS X SDK to allow building Python
executables and libraries that will run on multiple versions of OS X. There is
an error in the SDK support code in detect_modules() for building the _sqlite3
extension that has the
Changes by Ned Deily :
--
keywords: +patch
Added file: http://bugs.python.org/file26698/issue15560_sqlite3_sdk.patch
___
Python tracker
<http://bugs.python.org/issue15
Changes by Ned Deily :
--
stage: patch review -> commit review
Added file: http://bugs.python.org/file26699/issue15560_sqlite3_sdk_27_32.patch
___
Python tracker
<http://bugs.python.org/issu
Ned Deily added the comment:
Committed for release in 2.7.4, 3.2.4, and 3.3.0.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
I've updated the OS X installers to build and link with a local copy of ncurses
5.9 rather than older Apple-supplied ones, thus avoiding the library bug.
test_curses now passes for them.
--
___
Python tracker
Ned Deily added the comment:
P.P.S. I've updated the OS X installers as of 3.3.0b2 to build and link with a
local copy of ncurses 5.9 rather than older Apple-supplied ones. test_curses
now passes.
--
___
Python tracker
<http://bugs.py
Ned Deily added the comment:
Ouch! That appears to be a major regression in the newly released ActiveTcl
8.5.12. I can easily reproduce a crash just using wish8.5 so the problem is
strictly in Tcl/Tk itself, not Python. If you have an older version of
ActiveTcl 8.5 available, you can revert
Ned Deily added the comment:
The Mac Tcl community has jumped on the problem and there is now a tentative
patch for Tk:
http://permalink.gmane.org/gmane.comp.lang.tcl.core/14173
I've opened a formal issue on the Tcl/Tk bug tracker here:
https://sourceforge.net/tracker/?func=detai
Changes by Ned Deily :
--
status: pending -> open
title: IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12 -> IDLE crashes
using clipboard copy command on OS X with ActiveTcl 8.5.12
___
Python tracker
<http://bugs.python.org/i
Changes by Ned Deily :
--
status: open -> pending
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue15574>
___
___
Python-
Ned Deily added the comment:
Text rendering in Tkinter applications like IDLE is a service of the underlying
Tcl/Tk implementation. Essentially, all that IDLE does is to pass text in a
requested font face and font size through Tkinter to Tcl/Tk which may then use
whatever approach it wants
Ned Deily added the comment:
Since we've established that python files are already covered by 'make
patchcheck' and the hg checkin hook and that there does not appear to be much
enthusiasm for extending the hook to C files or to wholesale whitespace
cleanup, the remaining issu
Ned Deily added the comment:
Is it by any chance a --shared build being run from the build directory without
having been installed (and without a LD_LIBRARY_PATH and with an older version
already installed)?
--
nosy: +ned.deily
___
Python tracker
Ned Deily added the comment:
There is something odd about the setup for that buildbot. Notice the other
failures. The mkfifo() call on OS X isn't even documented as returning EINVAL
(22). I've never seen this kind of failure on other OS X systems. Łukasz,
any ideas?
-
New submission from Ned Deily:
== CPython 3.3.0b1 (default:efb30bdcfa1e, Aug 8 2012, 15:43:49) [GCC 4.0.1
(Apple Inc. build 5493)]
== Darwin-8.11.0-Power_Macintosh-powerpc-32bit big-endian
== /private/tmp/test_python_13864
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0
Ned Deily added the comment:
It appears similar failures are occuring on Sparc platforms (see issue15589)
another big-endian platform.
--
___
Python tracker
<http://bugs.python.org/issue15
Changes by Ned Deily :
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue15597>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
The patch does indeed fix all of the __suppress_context__ related test failures
previously seen, i.e. test_exceptions, test_ipaddress, test_raise, and
test_traceback.
--
___
Python tracker
<http://bugs.python.
New submission from Ned Deily:
==
FAIL: test_get (tkinter.test.test_tkinter.test_variables.TestStringVar)
--
Traceback (most recent call last):
File
Ned Deily added the comment:
The program works as expected. After the first two writes, the buffer contains
b'abcdef'. Then the seek(0) moves the stream pointer to the beginning of the
buffer and the next write overwrites buffer positions 0 through 2, replacing
b'abc'
4401 - 4500 of 6927 matches
Mail list logo
