Ned Deily added the comment:
Also, the new functionality is really only needed for 32-bit/64-bit multi-arch
builds which aren't support with the 10.4u SDK anyway.
--
___
Python tracker
<http://bugs.python.org/i
Ned Deily added the comment:
As far as I can see, the only possible shortcoming of the patch is that it
restores the current behavior with a 2-way fat ppc/i386 build with 10.4u (i.e.
the way python.org installers are currently built); that is, you would still
not be able to use "arc
Ned Deily added the comment:
"* The change to LIPO_32BIT_FLAGS is unconditional, the current values
are needed to build on modern system, I guess the proposed new
value would be needed for building on 10.4?"
Ah, yes, sorry. I built and tested with and on 10.6 with 10.5 SDK/g
Ned Deily added the comment:
Martin, just to be clear: the purpose of the new feature *is* to allow the
choice between 32-bit/64-bit and that is important. My comment was that the
downside of the submitted fix, as it stands, would be to not allow choosing
archs only for pythons built with
Ned Deily added the comment:
Works for me.
GNU gettext, which provides libintl, is not included in OS X 10.6. Chances are
your build is being contaminated by packages installed via MacPorts or Fink or
in /usr/local. If you do want to build with it, check config.log in your build
directory
Ned Deily added the comment:
Thanks, Ronald. The patch looks good. I've got a patch in progress for the
LIPO flags part: looks like the key is 'ppc' for DEPLOYMENT_TARGET <= 10.4 and
'ppc7400' for DEPLOYMENT_TARGET >= 10.5 for either gcc-4.0 or -4.2. I&#
Ned Deily added the comment:
@Sridhar: that's the part that's not fixed yet. We'll have a patch for that
shortly.
--
___
Python tracker
<http://bugs.py
Changes by Ned Deily :
--
nosy: +nad
___
Python tracker
<http://bugs.python.org/issue5408>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Ned Deily added the comment:
It appears the test doesn't work correctly for non-framework builds,
something I didn't test. A patch is forthcoming.
___
Python tracker
<http://bugs.python.
Ned Deily added the comment:
ANALYSISIn a non-framework build, when PYTHONEXECUTABLE is set to a
invalid value, getpath.c is unable to determine appropriate
values for sys.prefix and sys.path so the interpreter fails
in initialization.
SOLUTION
Ned Deily added the comment:
For more info, see discussion starting here:
<http://mail.python.org/pipermail/python-list/2009-March/703067.html>
I suspect a difference in the proxy configuration available between OS X
and OS X Server, although I don't have a OS X Server configurat
Ned Deily added the comment:
I don't have strong feelings about it one way or the other. As far as I
can tell from the code and testing and the documented behavior, the effect
on sys.executable is independent of whether it is a framework build or
not. But I'm fine with narrowing
Ned Deily added the comment:
The ReadMe is not quite correct. For 3.x, the OS X installers do not by
default install links in /usr/local. Note that the installer's Welcome
screen correctly notes this. To install the /usr/local/ links, you need
to go back to the Installer, select Cust
Ned Deily added the comment:
I believe r69307, checked in after 3.0.1, removes the faulty test in
test_get_python_inc so this failure no longer occurs on py3k builds snd
this issue can probably be closed.
--
nosy: +nad
___
Python tracker
<h
Ned Deily added the comment:
Also seeing on OS X. Without having looked at the code yet, I wonder if
this might be related to Issue1711605.
--
nosy: +nad
___
Python tracker
<http://bugs.python.org/issue4
New submission from Ned Deily :
wrong error from curses.wrapper if curses initialization fails
One way to reproduce is trying under IDLE.app in OS X:
import curses
def scr(a):
a.getch()
curses.wrapper(scr)
Traceback before patch:
UnboundLocalError: local variable 's
New submission from Ned Deily :
[NOTE: applies to 2.x urllib2 and similar code in merged 3.x urllib]
test_urllib2 can fail because urllib2.FileHandler assumes incorrectly
that the local host has only a single IP address. It is not uncommon
to have host IP configurations where a host has more
Changes by Ned Deily :
Added file: http://bugs.python.org/file13515/patch-nad0017-py3k-30.txt
___
Python tracker
<http://bugs.python.org/issue5625>
___
___
Python-bug
Ned Deily added the comment:
Note also Issue5625 - any work for IPv6 should keep in mind that local
hosts may have more than one IP address.
--
nosy: +nad
___
Python tracker
<http://bugs.python.org/issue1675
New submission from Ned Deily :
The documentation for socket.gethostname() contains the following
comment:
"If you want to know the current machine’s IP address, you may want to
use gethostbyname(gethostname()). This operation assumes that there is a
valid address-to-host mapping fo
New submission from Ned Deily :
Prevent "hidden" obsolete and unused MacPython documentation
files from being installed within framework Python.app bundle.
(The current documentation continues to be installed elsewhere.)
--
components: Build
files: patch-nad0010-py3k-30.tx
Changes by Ned Deily :
Added file: http://bugs.python.org/file13541/patch-nad0010-trunk-26.txt
___
Python tracker
<http://bugs.python.org/issue5648>
___
___
Python-bug
New submission from Ned Deily :
The PythonSystemFixes package of the OS X installer fixes a specific
compatibility problem with the Apple-supplied Python 2.3 on OS X 10.3. The
attached patches changes the build installer script to include that
package in the installer only if the installer
Changes by Ned Deily :
Added file: http://bugs.python.org/file13544/patch-nad0008-trunk-26.txt
___
Python tracker
<http://bugs.python.org/issue5649>
___
___
Python-bug
New submission from Ned Deily :
Because OS X 10.4 and 10.5 ship with an old 8.4 version of Aqua Tcl and
Tk frameworks, current practice is to build the installer image on a
machine with user-installed newer 8.4 Tcl/Tk frameworks in /Library.
This ensures the correct dylib search sequence is
New submission from Ned Deily :
The OS X Installer postflight script still tries to compileall scripts in
the framework Mac/Tools directory even though it no longer exists.
--
components: Installation
files: patch-nad0009-trunk-26.txt
messages: 85044
nosy: nad, ronaldoussoren
severity
Changes by Ned Deily :
Added file: http://bugs.python.org/file13547/patch-nad0009-py3k-30.txt
___
Python tracker
<http://bugs.python.org/issue5652>
___
___
Python-bug
New submission from Ned Deily :
For 3.0, the OS X installer was changed to disable the default
installation of the Unix Command Line Tools package, the package that
installs links in /usr/local/bin to the corresponding entries in the
framework bin directory. The intent was to follow the
New submission from Ned Deily :
Observed failure of regression test:
==
FAIL: test_count (test.test_itertools.TestBasicOps)
--
Traceback (most recent call last
Ned Deily added the comment:
Closes duplicate Issue3586?
--
nosy: +nad
___
Python tracker
<http://bugs.python.org/issue5705>
___
___
Python-bugs-list mailin
New submission from Ned Deily :
RELEASE BLOCKER
r71400 and r71401 changed py3k setup.py to comment out the installation
of the scripts for pydoc, idle, 2to5, and smtpd.py. This was in
response to issue1590 noting that python3 should not overwrite python2
versions of the scripts. However
Changes by Ned Deily :
--
nosy: +benjamin.peterson, ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue5756>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
r71400 breaks installer builds. See issue5756.
--
nosy: +nad
___
Python tracker
<http://bugs.python.org/issue1590>
___
___
Pytho
New submission from Ned Deily :
r70727 and related merges changed the OS X build-installer script to
build documentation from scratch using sphinx rather than the previous
error-prone downloading. However, it appears the documentation is
ending up at a different location in the framework
Ned Deily added the comment:
--enable-framework and --enable-shared are mutually exclusive options.
See, for example, the discussion in Issue4472. Use one or the other, not
both.
As a side comment, I think this error crops up often enough that it would
make sense to add a check somewhere
Ned Deily added the comment:
Can not reproduce with 3.0.1. A number of fixes were checked in for OS X
Python builds and specifically for IDLE menus between 3.0rc3 and 3.0.1.
See, for example, Issue5196 and Issue5194.
--
nosy: +nad, ronaldoussoren
Ned Deily added the comment:
Another good reason not to install Stuffit or Stuffit Expander. These
days OS X expands the standard open formats (i.e. .gz, .zip, .tar, etc)
all by itself, and there are the standard command line tools as well.
If you need Stuffit for actual stuffit archives
Ned Deily added the comment:
Reopening as RELEASE BLOCKER.
r71936 does indeed install pydoc and idle with a 3 suffix. However, it
also removed the 2to3 and smtp.py scripts previously installed by
setup.py without providing any replacements for them, versioned or not.
Section 25.4.1 of the
Ned Deily added the comment:
With the decision to have references to py3k scripts always contain a
"3", I agree that "make fullinstall" is no longer appropriate.
With r72723 and current py3k, however, there are still some issues.
Compare ls -l bin from 2.6.2, 3.0.1, and
Ned Deily added the comment:
Ronald, no changes were made to the makefiles, just to setup.py in
r71400 and r71936 (which also renamed idle and pydoc):
[...]
Modified: python/branches/py3k/setup.py
==
--- python
Ned Deily added the comment:
Sorry, my assertion "no changes were made to the makefiles" is not quite
correct. r71372 did change the altinstall target for Issue1590, the
precipitator of this issue.
--
___
Python tracker
<http://bu
New submission from Ned Deily :
Undefined symbols:
"_CFStringConvertEncodingToIANACharSetName", referenced from:
_PyLocale_getdefaultlocale in libpython3.1.a(_localemodule.o)
"_CFStringGetSystemEncoding", referenced from:
_PyLocale_getdefaultlocale in libpython3
Ned Deily added the comment:
Yep, r72866 does restore 2to3. And r72857, which removes the fullinstall
target, also fixes the problem of unversioned "python" and "python-config"
files being created in bin. Thanks!
--
___
P
Ned Deily added the comment:
Issues update:
1. Benjamin fixed this in r72857.
2. Also fixed in r72857.
3. Fixed in r72866.
4. open - all that is needed is to add a NEWS item about smtpd.py no
longer being installed as script
--
___
Python
Ned Deily added the comment:
With the recent py3k changes to ensure that the bin directory only has
versioned file names (and 2to3), the submitted patch can be simplified as
the file name check is no longer needed. Re-enabling the Unix Command
Line Tools package by default is still
Ned Deily added the comment:
Removing the newer 8.4 /Library/Frameworks/Tcl.framework/ at runtime makes
the problem go away. (Also the official 3.0.1 python wasn't linked with
the newer Tcl in place so it doesn't exhibit these symptoms).
--
Ned Deily added the comment:
Apparently, also caused by using the newer Tcl 8.4 in
/Library/Frameworks/Tcl.
--
nosy: +nad
___
Python tracker
<http://bugs.python.org/issue6
Ned Deily added the comment:
The URL you provide for the log doesn't seem to be accessible externally
so it is difficult to guess exactly what was being done. However, there
were changes between 3.1b2 and 3.1rc1 to the top-level Makefile
(Makefile.pre.in) and to the Mac/Makefi
Ned Deily added the comment:
See also Issue6170.
--
nosy: +nad, ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue6172>
___
___
Python-bugs-list m
Ned Deily added the comment:
That seems to work. However, while testing that, I found another, minor
problem in that same area. In Makefile.pre.in bininstall target just
before the lines you cite, there is also this added in r71935:
-rm -f $(DESTDIR)$(BINDIR)/python3-config
(cd $(DESTDIR
New submission from Ned Deily :
[...]
Compiling
/tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.
1/lib2to3/tests/__init__.py ...
Listing
/tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.
1/lib2to3/tests/data ...
Compiling
/tmp/image/Library
Ned Deily added the comment:
r73160 does make the spurious errors go away - along with the compiles
of all the other modules! Suggest removing the spurious "!"'s:
926c926
< -x 'bad_coding|badsyntax|site-
packages|py2_test_grammar|
Ned Deily added the comment:
er, spurious "|"'s
--
___
Python tracker
<http://bugs.python.org/issue6184>
___
___
Python-bugs-list mailing li
Ned Deily added the comment:
Still happening on 3.1rc1.
Should this be considered a release blocker for 3.1?
--
nosy: +benjamin.peterson, nad
___
Python tracker
<http://bugs.python.org/issue5
New submission from Ned Deily :
I've recently started seeing occasional regression test error messages
on OS X from test_thread. The test reports running OK but tracebacks
are displayed. It's not reproducible at will but has shown up on both
10.5 Intel and 10.5 PPC machines wi
Ned Deily added the comment:
Further investigation reveals that the underlying script
Mac/Tools/fixapplepython23.py is broken on 3.x:
1. the version test using platform.mac_ver is incorrect
Traceback (most recent call last):
File "fixapplepython23.py", line 131, in
mai
Ned Deily added the comment:
Verified test_asynchat no longer fails in trunk nor py3k. Thanks!
--
___
Python tracker
<http://bugs.python.org/issue5798>
___
___
Ned Deily added the comment:
Verified fixed by r72779 in trunk and r72791 in py3k. Can be closed.
--
___
Python tracker
<http://bugs.python.org/issue5
New submission from Ned Deily :
Potential Release Blocker
The default file encoding for 3.x file objects is the value of
locale.getpreferredencoding(). Currently, the locale module behavior on
OS X deviates from other python POSIX platforms in a few unexpected and
bad ways:
1. On OS X
New submission from Ned Deily :
In the Library Reference section 22.2.1 for locale, it states:
"Initially, when a program is started, the locale is the C locale, no
matter what the user’s preferred locale is. The program must explicitly
say that it wants the user’s preferred locale set
Ned Deily added the comment:
A very quick test of the patch on trunk for 10.4 and 10.5 looks good,
though it should be re-tested once the unrelated current breakage of
test__locale is fixed.
--
___
Python tracker
<http://bugs.python.org/issue6
Ned Deily added the comment:
(and committed to trunk in r73270 by Benjamin)
--
___
Python tracker
<http://bugs.python.org/issue6202>
___
___
Python-bugs-list m
Ned Deily added the comment:
This was probably fixed by the checkins for Issue6202.
$ python3.1
Python 3.1rc1+ (py3k, Jun 8 2009, 22:53:59)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more i
Changes by Ned Deily :
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue4388>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
As far as I know, it is not supported to "upbuild" Python (or anything else) on
OS X, i.e. you cannot use a higher level SDK (i.e. 10.4u) to build on an
earlier system (i.e. 10.3). In particular, to build Python with a deployment
target of 10.3, y
Ned Deily added the comment:
I believe the issue was that there was no supported 64-bit non-X Tk available
for 10.5. Has that changed? Otherwise, the build process and Tkinter need to
be modified to dynamically link with more than one version of Tk, something
that has been discussed but
Ned Deily added the comment:
The Python 2 Tkinter has been renamed to tkinter in Python 3 and the lib-tk no
longer exists. See http://docs.python.org/py3k/library/tkinter.html
--
assignee: -> ronaldoussoren
components: +Macintosh
nosy: +ned.deily, ronaldousso
Changes by Ned Deily :
--
assignee: -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren
versions: +Python 3.2 -Python 3.0
___
Python tracker
<http://bugs.python.org/iss
New submission from Ned Deily :
For 2.7, the set of default installed packages for the OS installer was changed
for some reason to no longer select the "UNIX command-line tools" package by
default so the traditional symlinks in /usr/local/bin are not being created by
default.
Ned Deily added the comment:
Note that in the interim, there is a workaround for Snow Leopard users who want
to use IDLE or Tkinter: use the 32-bit-only 2.7 OS X installer ("10.3") instead.
--
nosy: +ned.deily
___
Python trac
Ned Deily added the comment:
@Sarth: Odd, works for me. Using the standard GUI installer on a
64-bit-capable machine running 10.6.4, I first installed the "10.5" 2.7
metapackage and verified that both IDLE.app and /usr/local/bin/idle2.7 fail.
Then, even without manually deletin
Ned Deily added the comment:
Keep in mind that, on OS X, there are two ways to invoke IDLE: one, by command
line in a terminal window, and, two, by launching IDLE.app (explicitly, say by
double-clicking on the app icon, or implictily, say by double-clicking on a .py
file where IDLE.app is
Ned Deily added the comment:
"instead of (on a Mac)
$ cd /Applications/Python\ 2.6/Extras/Demo/turtle/
$ python turtleDemo.py
and I still cannot find where Apple decided to put Tools."
This has nothing to do with Apple. "/Applications/Python x.y" is created by
the pytho
Ned Deily added the comment:
>Does this mean that Apple distributes neither Tools nor Demo? That
>would be another reason to move anything anyone cares about to Lib.
I believe that neither are included in the Apple-supplied Python in OS X, which
resides primarily in /System/L
Ned Deily added the comment:
There have been similar problems reported in the past when subprocesses cause
OS X CoreFoundation interfaces to be first called from the subprocess and not
the main process. A quick workaround is to make a call from the main process.
In this case, adding a call
Ned Deily added the comment:
There should be a way to provide a permanent fix to avoid the problem; that
will take more investigation. This was just a workaround suggestion.
--
___
Python tracker
<http://bugs.python.org/issue9
Ned Deily added the comment:
@Danielle: Are you sure you are launching the correct IDLE? In a terminal
window, enter the following shell commands and report the output:
cd /Library/Frameworks/Python.framework/Versions/2.7/
file lib/python2.7/lib-dynload/_tkinter.so
otool -L lib
Ned Deily added the comment:
[FYI: Comments at the beginning of a patch file are ignored by the standard
Unix-y patch utilities. They are there for a reason.]
--
___
Python tracker
<http://bugs.python.org/issue5
Changes by Ned Deily :
--
nosy: +akuchling
___
Python tracker
<http://bugs.python.org/issue5622>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
For OS X installer builds, this was fixed by r72723 prior to the final release
of 3.1; idle is installed in the framework bin directory as idle3 with a
symlink to the versioned name, i.e. idle3.n, and the optional UNIX command-line
tools package installs symlinks
Changes by Ned Deily :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<http://bugs.python.org/issue28
Ned Deily added the comment:
I'd like one of the other Windows folks to review it but, in principle, LGTM.
--
___
Python tracker
<http://bugs.python.org/is
Ned Deily added the comment:
FWIW, hg bisect finds:
changeset 103444:a77756e480c2: bad
The first bad revision is:
changeset: 103444:a77756e480c2
parent: 103442:914a81781291
user:Victor Stinner
date:Fri Sep 09 10:17:08 2016 -0700
summary: Rework CALL_FUNCTION* opcodes
Ned Deily added the comment:
Guido, doc fixes are welcome!
--
___
Python tracker
<http://bugs.python.org/issue28773>
___
___
Python-bugs-list mailing list
Unsub
Ned Deily added the comment:
Nick, that seems like the right thing to do. Thanks for following up on it.
--
nosy: +larry
priority: normal -> release blocker
versions: +Python 3.7
___
Python tracker
<http://bugs.python.org/issu
Ned Deily added the comment:
Also, if there is indeed a suspected error in the underlying library, has the
issue been reported to the SQLite project?
--
___
Python tracker
<http://bugs.python.org/issue28
Ned Deily added the comment:
Berker asks in IRC whether this change should go into 3.6.0 (at rc1). While it
is affecting a relatively self-contained part of the standard library (cgi),
the issue doesn't seem to be "release critical". Further, it is changing
behavior that was
Ned Deily added the comment:
After discussing this offline with Łukasz, I'm going to take the risk of
allowing the non-conforming 3.6 checkin to remain in for 3.6.0.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/is
Changes by Ned Deily :
--
nosy: +larry
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue28808>
___
___
Python-bugs-list mai
Ned Deily added the comment:
I'd like @haypo to review and approve this change as well since he was involved
in the predecessor (Issue28701). Victor?
--
___
Python tracker
<http://bugs.python.org/is
Ned Deily added the comment:
(Victor also merged this into default branch for 3.7.0 in 6453ff3328b8)
--
priority: release blocker ->
stage: commit review -> resolved
___
Python tracker
<http://bugs.python.org/i
Changes by Ned Deily :
--
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: -Python 3.4
___
Python tracker
<http://bugs.python.org/issue15
Ned Deily added the comment:
Nick, as the original shepherd of PEP 487 (Issue27366), can you review Serhiy's
proposed patch for 3.6.0rc1? Thanks!
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/is
Ned Deily added the comment:
I don't have a good sense of the severity of this issue but it doesn't seem
like it qualifies as release critical. On the other hand, the changes are
isolated to typing and typing is more fluid than older, more established
modules. If you think it sh
Ned Deily added the comment:
> Is that the right procedure still?
Yes, thanks!
--
stage: commit review -> resolved
___
Python tracker
<http://bugs.python.org/i
Ned Deily added the comment:
Where do we stand on this issue? At the moment, 3.6.0 is on track to be
released as is.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue28
Ned Deily added the comment:
Where do we stand on this issue? At the moment, 3.6.0 is going to be released
without these fixes.
--
___
Python tracker
<http://bugs.python.org/issue27
Changes by Ned Deily :
--
resolution: out of date ->
stage: -> needs patch
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue5225>
___
___
Ned Deily added the comment:
OK for 3.6.0rc1 (before it times out)
--
stage: patch review -> commit review
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issu
Changes by Ned Deily :
--
stage: commit review -> resolved
___
Python tracker
<http://bugs.python.org/issue28790>
___
___
Python-bugs-list mailing list
Un
5601 - 5700 of 6927 matches
Mail list logo
