Ronald Oussoren added the comment:
I cannot reproduce this with the py3k branch, I'm currently building
r31rc1 to check if I can reproduce the issue with that.
--
___
Python tracker
<http://bugs.python.org/i
Ronald Oussoren added the comment:
I also cannot reproduce this, using both the py3k branch and the r31rc1
tag.
My build procedure:
* cd r31rc1
* mkdir build
* cd build
* ../configure --enable-framework --enable-universalsdk
* make
* make install DESTDIR=$PWD/image
The resulting framework
Ronald Oussoren added the comment:
Now I'm really confused, I tried to install a second time and this time I
do get an error.
Time to start hunting down an issue...
--
___
Python tracker
<http://bugs.python.org/i
Ronald Oussoren added the comment:
The build was quicker than expected. I also cannot reproduce using
r31rc1.
Or rather, I can reproduce this using "make frameworkinstallframework",
but not using "make install".
The latter is the correct way to install the framewo
Ronald Oussoren added the comment:
Manually running "make frameworkinstallframework" (and the other ones) is
not supported, those are internal makefile targets that are are used to
implement "make install".
"make framworkinstall" is supported as an alias f
Ronald Oussoren added the comment:
I found the issue.
In r72899 antoine.pitrou checked in a change that adds these two lines
to the bininstall target in Makefile.pre.in:
-rm -f $(DESTDIR)$(LIBPC)/python3.pc
(cd $(DESTDIR)$(LIBPC); $(LN) -s python-$(VERSION).pc python3.pc)
This exposes
Ronald Oussoren added the comment:
This should be fixed in r73142, please test.
--
resolution: -> fixed
status: open -> pending
___
Python tracker
<http://bugs.python.org/
Ronald Oussoren added the comment:
Fixed for 3.1 in r73187, and for 3.0 in r73188.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Ronald Oussoren added the comment:
Do you have a copy of libintl in /usr/local or ~brett//local/lib? If so,
could you run 'file' on that library to check if it is a universal
library?
All system libraries on OSX are universal binaries and work just fine
with a universal build
Ronald Oussoren added the comment:
I have two procedural questions:
1) Who should I contact to get e-mail for all bugs that get tagged with
the Macintosh component?
2) Please tag all mac-related bugs with the 'Macintosh' component, that's
the one I most often check
Ronald Oussoren added the comment:
I just noticed the update of the title.
I propose to close this issue if this is caused by a non-universal version
of libintl that's installed by macports.
Macports can install universal binaries of its packages (the +universal
variant), use that i
Ronald Oussoren added the comment:
On 4 Jun, 2009, at 0:59, Evan Behar wrote:
>
> Evan Behar added the comment:
>
> I haven't got any library issues using --enable-universalsdk, it won't
> get to the linking stage becaue it doesn't find libintl.h
>
> A
Ronald Oussoren added the comment:
On 4 Jun, 2009, at 0:59, Benjamin Peterson wrote:
>
> Benjamin Peterson added the comment:
>
> 2009/6/3 Ronald Oussoren :
>>
>> Ronald Oussoren added the comment:
>>
>> I just noticed the update of the title.
>>
&
Ronald Oussoren added the comment:
On 4 Jun, 2009, at 0:59, Benjamin Peterson wrote:
>
> Benjamin Peterson added the comment:
>
> 2009/6/3 Ronald Oussoren :
>>
>> Ronald Oussoren added the comment:
>>
>> I just noticed the update of the title.
>>
&
Ronald Oussoren added the comment:
On 4 Jun, 2009, at 0:59, Evan Behar wrote:
>
> Evan Behar added the comment:
>
> I haven't got any library issues using --enable-universalsdk, it won't
> get to the linking stage becaue it doesn't find libintl.h
>
> A
Ronald Oussoren added the comment:
Don't do that, use 'make install DESTDIR=$PWD/image'. As I mentioned
earlier 'make frameworkinstallframework' is an internal step that
shouldn't be used on its own.
--
___
Python tr
Ronald Oussoren added the comment:
On 4 Jun, 2009, at 2:24, Brett Cannon wrote:
>
>
> Ronald, can you look at the changes I proposed on Makefile.pre.in to
> make sure LIBS from configure get used in the framework builds? If you
> do then that change with the configure.in cha
Changes by Ronald Oussoren :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue5648>
___
___
Python-bugs-list
Ronald Oussoren added the comment:
I'm setting the priority to "release blocker" because the current
behaviour is completely unwanted, the "mac-roman" encoding is no longer
used by default on OSX. All system tools write UTF-8 encoded files by
default, and the LANG v
Ronald Oussoren added the comment:
The patch looks good, and tests pass on 10.5.7.
I've committed this as r73268
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python
Ronald Oussoren added the comment:
The attached file libintl-framework-ronald.patch should do the trick.
Could someone who is affected by this issue test this patch (and feel free
to commit it if it works). I don't have libintl on my system and hence
cannot test right now.
--
Ronald Oussoren added the comment:
Fixed in r73305 (trunk), r73306 (2.6) and r73307 (3.1)
That is, with the above mentioned checkins configure will give a clear
error message when you specify both --enable-framework and --enable-
shared.
--
resolution: -> fixed
status: o
New submission from Ronald Oussoren :
Apple just announced that MacOSX 10.6 ("Snow Leopard") will be released
in September, and will only support intel systems.
This means that the --with-universal-archs option is not 100% usable if
you want to build a version of Python that sp
Ronald Oussoren added the comment:
The details of snow leopard are under NDA, but based on public
information :
* Snow Leopard will only support Intel-based systems
* Apple's "rosetta" dynamaic translation subsystem for running PPC code
on an intel system only supports
Ronald Oussoren added the comment:
I cannot reproduce this on my machine (running OSX) using 2.5, 2.6 and 3.1
(latest rc).
--
___
Python tracker
<http://bugs.python.org/issue1
Ronald Oussoren added the comment:
I've filed an issue for this in the Tcl/Tk tracker:
<https://sourceforge.net/tracker/?func=detail&aid=3002320&group_id=10894&atid=110894>
(Assuming that this is the canonical tracker for the Tcl/Tk project, it was the
first hit in goo
Ronald Oussoren added the comment:
BTW. Another way of testing, assuming you have two accounts: use 'su -
otheraccount' to get a shell session as another user then try to start tk using:
import Tkinter
root = Tkinter.Tk()
This will currently crash the interpreter due to an uncaught
Ronald Oussoren added the comment:
The attached patch is a first start at working around the crash. With this
patch I can use Tk without a crash:
>>> import Tkinter
>>> Tkinter.Tk()
Sun May 16 12:11:08 Rivendell.local python.exe[55984] : kCGErrorFailure:
Set a breakpoint @
Ronald Oussoren added the comment:
Something I forgot to mention: the patch introduces "_tkinter.m" to enable
compiling the _tkinter extension as Objective-C code. The compiler also
supports passing "-x objective-c" to compile _tkinter.c in Objective-C mode,
but this fl
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue5766>
___
___
Python-bugs-list mailing list
Un
Ronald Oussoren added the comment:
One way to fix this: is to always recreate MANIFEST when an explicit
MANIFEST.in file exists, as in the attached patch.
(The patch is not perfect: I'd rename "template_newer" before committing)
--
keywords: +needs review, patch
A
New submission from Ronald Oussoren :
Output of test_distutils on a older SuSE Linux system:
FAILED (errors=1, skipped=5)
Traceback (most recent call last):
File "../Lib/test/test_distutils.py", line 18, in
test_main()
File "../Lib/test/test_distutils.py", l
Ronald Oussoren added the comment:
$ compress --version
compress - sharutils 4.2c
And yes, this is jucky behavior. Most systems shouldn't be affected by this
because sharutils isn't used a lot these days.
--
___
Python trac
Ronald Oussoren added the comment:
Tk has a different tracker than tcl itself, the upstream issue is now
<https://sourceforge.net/tracker/?func=detail&aid=3002484&group_id=12997&atid=112997>
--
___
Python tracker
<http://bugs
Ronald Oussoren added the comment:
I'd also skip the test, this is not a bug in Python but a broken compress
executable.
--
___
Python tracker
<http://bugs.python.org/i
Ronald Oussoren added the comment:
The --user directory for framework installs of python on OSX has changed from a
subdirectory of ~/.local to a subdirectory ~/Library. As described in the NEWS
file:
- Issue #8084: PEP 370 now conforms to system conventions for framework
builds on MacOS X
Ronald Oussoren added the comment:
Shridar: that is correct a framework install will not look in ~/.local, but
only in ~/Library/Python/2.7 (there is an install scheme in distutils that
describes the exact layout).
Technically the name "Python" subdirectory is
sysconfig.get_
Ronald Oussoren added the comment:
The patch somewhat works, in that it makes test_py3kwarn pass but I'd add more
filterwarning calls:
filterwarnings("ignore", ".*the icglue module is removed",
DeprecationWarning)
filterwarnings("i
New submission from Ronald Oussoren :
It would be nice if the binary installer supported both Tk 8.4 and Tk 8.5: the
former is present on all current versions of OSX as part of the system, the
latter is the only one that is supported in 64-bit code on OSX 10.6.
A number of Tkinter users have
Changes by Ronald Oussoren :
--
assignee: ronaldoussoren ->
___
Python tracker
<http://bugs.python.org/issue8798>
___
___
Python-bugs-list mailing list
Un
Ronald Oussoren added the comment:
The root cause of this test failure is that test_macos runs before
test_py3kwarn.
That causes MacOS to be imported before test_py3k runs and that results in not
raising the py3k warning by the time test_py3kwarn runs.
I propose removing MacOS from the list
Ronald Oussoren added the comment:
The pythonw executable always uses execv on OSX 10.4 because posix_spawnv isn't
available there.
A possibly significant change is the value of argv[0] as passed to the
Python.app executable.
Could you check if this patch fixes the issue?
Index: Mac/
Ronald Oussoren added the comment:
Note that the subject is not entirely correct: the framework install is a
framework install, but the python commandline doesn't behave like an
application bundle.
--
priority: normal -> high
stage: ->
Ronald Oussoren added the comment:
Thanks for testing.
I've applied the patch (with some additional documentation) in r81649 (2.7) and
r81650 (3.2). Other versions are not affected.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> c
Ronald Oussoren added the comment:
I've applied a new version of the patch in r81662.
I'll be monitoring the buildbot farm to ensure that any issues that might crop
up get fixed ASAP.
--
___
Python tracker
<http://bugs.python.
Ronald Oussoren added the comment:
Patchs looks file, although the 'None' branch might be a bit too fancy. I
haven't found a spec either, and therefore your code is probably the safest way
to deduce a mask.
--
assignee: -> ronaldoussoren
nos
Ronald Oussoren added the comment:
2.7 and 3.x use the SystemConfiguration framework (through the _scproxy
extension)
--
___
Python tracker
<http://bugs.python.org/issue8
Ronald Oussoren added the comment:
Ported to 3.2 in r81673.
--
___
Python tracker
<http://bugs.python.org/issue7724>
___
___
Python-bugs-list mailing list
Unsub
Ronald Oussoren added the comment:
Committed for 2.6 in r81674
--
___
Python tracker
<http://bugs.python.org/issue7724>
___
___
Python-bugs-list mailin
Ronald Oussoren added the comment:
And for 3.1 in r81677.
--
___
Python tracker
<http://bugs.python.org/issue7724>
___
___
Python-bugs-list mailing list
Unsub
Ronald Oussoren added the comment:
I haven't looked at the actual test yet, but the filesystem encoding on OSX is
UTF-8.
--
___
Python tracker
<http://bugs.python.org/i
Changes by Ronald Oussoren :
--
nosy: -ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue8142>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
This is no longer a problem, I cannot reproduce the issue with the current
trunk.
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Ronald Oussoren added the comment:
I've fixed this issue for the 3.2 branch in r81999.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python
Ronald Oussoren added the comment:
Sigh. test.test_distutils behaves different when run through regrtest than when
run directly.
I have a fix, but am running an extended test cycle before committing (that is,
both with and without srcdir==builddir
Ronald Oussoren added the comment:
This should be fixed in r82005, this passes all tests both with and without
srcdir==builddir
--
___
Python tracker
<http://bugs.python.org/issue8
Ronald Oussoren added the comment:
Tarek: I'm not 100% that all my changes in Lib/distutils were backported to
3.1. This last patch definitely wasn't, but isn't also isn't relevant for 3.1.
--
___
Python tracker
<http://bu
Ronald Oussoren added the comment:
I'll fire up my 10.4 system to further investigate this.
--
___
Python tracker
<http://bugs.python.org/issue9046>
___
___
Ronald Oussoren added the comment:
A patch to fix this issue would be appreciated. However, there is are two
reasons why _tkinter is build for 32-bit architectures only:
1) Apple didn't ship a 64-bit Tk until OSX 10.6, and that is Tk 8.5 while
earlier releases of the OS use Tk 8.4
2) T
Ronald Oussoren added the comment:
The mac-related code in urllib is correct, it uses the SystemConfiguration
framework on MacOSX to get the proxy settings. That said, the code in _scproxy
is not entirly correct, it makes the wrong assumption w.r.t. the value of
exclude_simple when the
Ronald Oussoren added the comment:
This should be fixed with r82149.
--
___
Python tracker
<http://bugs.python.org/issue8446>
___
___
Python-bugs-list mailin
Ronald Oussoren added the comment:
I've applied my patch in r82150, which fixes the issue for me in the trunk.
I'll merge the patch into the other branches if this does indeed fix the
buildbot issue.
--
___
Python tracker
<http://bu
Ronald Oussoren added the comment:
Odd, unless someone already checked in a fix on the trunk.
I currently have a clean test run on the trunk on OSX 10.6.4 (intel). I haven't
checked this on my 10.5 VM yet.
--
___
Python tracker
Ronald Oussoren added the comment:
Stefan: we already new that, see msg105018.
This issue was closed as fixed because the uuid module contains a workaround
for this issue (by not using the broken C API on OSX 10.6).
It seems that OSX 10.5.8 and 10.4 is also affected by this issue. I'll
Ronald Oussoren added the comment:
Bill, please test the patch below on a 10.5 system:
Index: Lib/uuid.py
===
--- Lib/uuid.py (revision 82148)
+++ Lib/uuid.py (working copy)
@@ -416,7 +416,7 @@
import sys
if
Ronald Oussoren added the comment:
scott:
* Which OSX version are you using?
* Which Python are you using?
- What is the value of sys.prefix?
- How did you install it?
* Does 'import readline' work?
--
___
Python trac
Ronald Oussoren added the comment:
Pavel: does the problem also happen with newer versions of Python?
--
___
Python tracker
<http://bugs.python.org/issue8
Ronald Oussoren added the comment:
Sigh.
-isysroot was added to CPPFLAGS because Python wouldn't build as a universal
binary anymore due a fix for issue 1628484. (According to the SVN log for
r80187).
I'll see what can be done to avoid adding -isysroot twice to the comp
Ronald Oussoren added the comment:
R. David Murray: the issue you refer to isn't the one you intend to link to, it
is related to proxy settings and doesn't contain a patch related to firefox.
--
___
Python tracker
<http://bugs.python.
Ronald Oussoren added the comment:
BTW. The firebox-bin binary in Firefox.app/Contents/MacOS does not support the
command-line arguments that Firefox on Linux supports. That is, the following
command does not work:
/Applications/Firefox.app/Contents/MacOS/firefox-bin -remote
'openURL(
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
components: +Macintosh -None
___
Python tracker
<http://bugs.python.org/issue3362>
___
___
Python-
Ronald Oussoren added the comment:
Then why bother providing binaries?
I'm trying to keep the OSX port in good shape, but at times have to hunt down
issues that were introduced by other bugfixes.
A problem with adding OSX to the list of stable buildbots is IMHO that there
seem to be
Ronald Oussoren added the comment:
I'm closing this issue:
1) webbrowser.get("firefox") currently works
2) firefox on OSX doesn't provide hooks to open tabs instead of windows
(neither through the command line nor though AppleScript) which means that the
'new&#x
Ronald Oussoren added the comment:
Marc-Andre: what version of Xcode do you use? (the version in the About menu of
Xcode.app).
I'm getting clean builds with '--enable-universalsdk' on OSX 10.4.11 (PPC) with
Xcode 2.5 (the last Xcode for OSX 10.4). That is, all extension bui
Ronald Oussoren added the comment:
Reaction from scot w.r.t. my questions:
os x 10.5.8
python 2.5.1
/System/Library/Frameworks/Python.framework/Versions/2.5
came default with system
i'm going to try activestate python 2.6 and see if that solves the problem.
import readline does
Ronald Oussoren added the comment:
Some notes: The system python on OSX 10.5 and 10.6 is linked to libedit, not
GNU readline, and doesn't seem to contain patches that convert stdlib usage of
readline APIs to the correct way to bind keystrokes to action with libedit.
This results in fa
Ronald Oussoren added the comment:
This (untested) patch should fix the issue for the cmd module:
+++ Lib/cmd.py (working copy)
@@ -112,7 +112,18 @@
import readline
self.old_completer = readline.get_completer()
readline.set_completer
Ronald Oussoren added the comment:
What I don't quite understand is why the build fails for you but passes for me.
What configure flags did you use?
This version should fare better:
def is_macosx_sdk_path(path):
"""
Returns True if 'path'
Ronald Oussoren added the comment:
The search code must look in the SDK and not fall back on looking into the
system to avoid finding new headers and libraries when trying to build using an
older SDK on a newer system.
I don't think this is a problem at the moment, but it could be i
Ronald Oussoren added the comment:
I don't agree that there must be an option to fall back to system provided
libs. The point of using an SDK is to avoid doing that because you might end up
with a binary that won't work on an earlier version of the OS (the OpenSSL one
is an examp
Ronald Oussoren added the comment:
I tested on OSX with a current version of FF and it didn't work.
--
___
Python tracker
<http://bugs.python.org/i
Ronald Oussoren added the comment:
That (/usr/local/src) explains why I haven't been able to reproduce the
problem, that worried me a little.
W.r.t. to the SDK:
1) You don't have to use an SDK: use
configure --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5
(or whate
Ronald Oussoren added the comment:
Wrt. non-gcc compilers: we do need to worry about those (there have been
bugreports in the past about using the Intel compiler), but those compilers
still have to be able to process system headers and Martin's patch basicly adds
the definition fro
Ronald Oussoren added the comment:
Martin: sorry about my first question. My interpretation of your first message
was that you thought that the OSX port itself wasn't stable, and you've already
mentioned that you didn't mean to imply that.
I'm unassigning the issue from m
Ronald Oussoren added the comment:
AFAIK there is no 64-bit installer for 3.1. There will be one for 3.2.
Sridhar: building using the 10.5 SDK should also work by using
--enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk. I've recently patched
setup.py and distutils to honor th
Ronald Oussoren added the comment:
This still is a problem, the Carbon wrappers assume that Py_UNICODE has the
same representation as the Unicode type in Carbon and that is a 16-bit type.
--
___
Python tracker
<http://bugs.python.org/issue763
Ronald Oussoren added the comment:
I've committed a fix in r82272 (2.7), r82273 (3.2), r82274 (2.6), r82273 (3.1)
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> compile error
___
Pyth
Ronald Oussoren added the comment:
Committed a fix in r82276 (2.7), r82277 (2.6), r82278 (3.2) and r82279 (3.1).
Please reopen the issue if you notice that the problem does not go away on the
buildbots.
--
status: open -> closed
___
Python trac
Ronald Oussoren added the comment:
Even when building using an SDK you can use frameworks in /Library/Frameworks
because $SDKROOT/Library/Frameworks is a symlink to the real
/Library/Frameworks.
--
___
Python tracker
<http://bugs.python.
Ronald Oussoren added the comment:
Applied to 2.6 (r82280), r82281 (3.2), r82282 (3.1).
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://
Ronald Oussoren added the comment:
Marc-Andre: is this still relevant or did the fix for SDK support enough to fix
the build.
BTW. Is this for OSX 10.4 instead of 10.3? AFAIK the compiler on 10.3 doesn't
support SDKs at all.
--
___
Python tr
Changes by Ronald Oussoren :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
This was committed a while back, I guess I forgot to close this issue.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Ronald Oussoren added the comment:
As r82005 fixed the problem this issue can be closed.
--
assignee: ronaldoussoren -> nobody
nosy: +nobody
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Ronald Oussoren added the comment:
Committed the patch with some minor modifications in r82284 (2.7), r82285
(2.6), r82286 (3.2), r82287 (3.1)
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: crash -&
Ronald Oussoren added the comment:
Bill: can you do some debugging on the buildbot itself? I cannot reproduce the
problem locally.
--
___
Python tracker
<http://bugs.python.org/issue8
Ronald Oussoren added the comment:
The attached patch is a workaround for the issue, but isn't someone I'd want to
commit without some serious cleanup.
As I noted when support for linking with libedit was merged it would be better
to add a translation layer that translates GN
Ronald Oussoren added the comment:
The comment is wrong, os.path.normcase should not return s.lower(), as the
other issue notes the case sensitivity is filesystem dependent.
Returning s.lower() will break code when dealing with paths that refer to an
NFS share on a Linux server, or to a
Ronald Oussoren added the comment:
The tests no longer fail.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8084>
___
___
Python-
Ronald Oussoren added the comment:
I cannot reproduce this with both 3.1.2 and 3.2a (py3k:80693), in both cases I
get the same output as you do on Linux. This is on OSX 10.6 though, I haven't
tested on 10.4 yet.
What is the output of the locale command on your OSX system? Mine
2101 - 2200 of 2445 matches
Mail list logo
