Ronald Oussoren added the comment:
I've committed the patch in r80179 (trunk), r80184 (2.6), r80185 (3.2), r80186
(3.1)
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python
Ronald Oussoren added the comment:
This problem is caused by this bit in Makefile.pre.in:
OPT=@OPT@
BASECFLAGS= @BASECFLAGS@
CFLAGS= $(BASECFLAGS) @CFLAGS@ $(OPT) $(EXTRA_CFLAGS)
There both 'BASECFLAGS' and 'CFLAGS' get patched in from conf
Ronald Oussoren added the comment:
Btw. this issue is caused by the fix for issue 1628484.
--
___
Python tracker
<http://bugs.python.org/issue8366>
___
___
Pytho
Ronald Oussoren added the comment:
This should now be fixed:
* r80187 (trunk)
* r80188 (2.6)
* r80191 (3.2)
* r80192 (3.1)
The fix is not ideal, there's still two '-isysroot' flags in the compiler
command-line, but at least everything compiles and works again.
--
Changes by Ronald Oussoren :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue8366>
___
___
Python-bugs-list mailing list
Unsubscri
Ronald Oussoren added the comment:
Applied as r80193, thanks for looking into this.
--
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
type: -> compile error
___
Python tracker
<http://bugs.pytho
Ronald Oussoren added the comment:
I'm closing this issue because a patch simular to the attached patch was
applied in r78835 and the issue therefore fixed.
--
resolution: -> out of date
stage: -> committed/rejected
status: ope
Ronald Oussoren added the comment:
This issue should be fixed in the repository for both python 3.1 and 3.2, could
you please test this?
--
___
Python tracker
<http://bugs.python.org/issue8
Ronald Oussoren added the comment:
Ned: I've attached a new patch, could you please test this one on an 10.3 box?
It turns out that testing if a weaklinked variable is defined should be done by
testing the address of the variable, not its value.
I've tested this new approach wit
Ronald Oussoren added the comment:
Fixing this requires duplicating a significant amount of code in posixmodule.c
and is imho not worth the effort.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.p
Ronald Oussoren added the comment:
I'm closing this issue as won't fix.
The additional fields are available if you build from source and target 10.5 or
later (set 'MACOSX_DEPLOYMENT_TARGET=10.5' when you run configure).
My current plan is to have two installers for python
New submission from Ronald Oussoren :
setup.py detects the version of openssl by looking for openssl headers on a
deduced search path. That path is not guaranteed to be equal to the real
compiler search path, in particular not when building using the OSX 10.4 SDK on
MacOSX 10.6: in that
Ronald Oussoren added the comment:
I've committed a port of _scproxies and the related code in urllib in r80198
(3.2), r80199 (3.1)
BTW. With some luck this should already include a fix for the crash your seeing
on OSX 10.3 with the trunk and 2.6.
--
resolution: -> fixe
Changes by Ronald Oussoren :
--
stage: -> committed/rejected
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue7154>
___
___
Python-bugs-
Ronald Oussoren added the comment:
I've fixed this issue in the repository earlier today, the installer for the
next 3.1 release will include that fix.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type
Ronald Oussoren added the comment:
Fix in r80201 (3.1) and r80200 (3.2). The fix is already in 2.6 and the trunk.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tr
Ronald Oussoren added the comment:
Aaron: How did you install python?
--
___
Python tracker
<http://bugs.python.org/issue8381>
___
___
Python-bugs-list mailin
Ronald Oussoren added the comment:
W.r.t. "This appears to be the case on Mac OS X": OSX 10.4 and later seem to
support posix semaphores, the program below prints "yes":
#include
int main()
{
#ifdef _POSIX_SEMAPHORES
printf("yes\n");
#else
Ronald Oussoren added the comment:
r80232 explicitly sets $PATH to the system default one, which hopefully fixes
the issue.
What would be interesting to know is which shell is the user shell on the
buildbot. The original patch worked for me because my shell is bash and bash
sets a default
Ronald Oussoren added the comment:
I've committed my proposed fix in r80243 (trunk)
--
___
Python tracker
<http://bugs.python.org/issue8095>
___
___
Pytho
Ronald Oussoren added the comment:
I've fixed this issue in all branches and can now do clean builds.
BTW. Builds with the 10.4u SDK on OSX fail at the moment for 2.7 and 3.2,
that's due to issue 7724, I've attached a patch to that issue that should fix
it (for the trunk, po
Ronald Oussoren added the comment:
The attached patch (for the trunk) fixes this issue on my machine.
The patch also fixes issue 8444.
I wouldn't mind some review of the patch, it does affect core bits of setup.py.
--
keywords: +needs review
stage: needs patch -> patch revi
Ronald Oussoren added the comment:
I've attached a patch that fixes this issue to issue 7724.
--
___
Python tracker
<http://bugs.python.org/issue8444>
___
___
Ronald Oussoren added the comment:
The test passes just fine on my machine.
--
___
Python tracker
<http://bugs.python.org/issue8447>
___
___
Python-bugs-list m
Ronald Oussoren added the comment:
I agree that the DTD should be changed.
Fixed in r80279 (trunk) and r80280 (3.2).
I won't backport to 2.6 and 3.1 because this is a mostly cosmetic issue and I
do not want to risk breaking existing scripts.
--
resolution: -> fixed
stag
Ronald Oussoren added the comment:
The patch is attached to issue 7724. As that issue notes the current version of
setup.py ignores OSX SDKs during builds, the patch in that issue makes sure
that setup.py looks in the SDK when looking for files (The patch also modifies
Ronald Oussoren added the comment:
As a short explanation of OSX SDKs: those are basicly directories containing
header files and stub libraries with the same directory structure as a real
system.
As an example, /Developer/SDKs/MacOSX10.4u.sdk contains the 10.4u SDK, that
tree contains
Ronald Oussoren added the comment:
I'd prefer to have this resolved before the next 2.7 beta.
--
___
Python tracker
<http://bugs.python.org/issue8084>
___
___
Ronald Oussoren added the comment:
test failures have been fixed a while back.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Ronald Oussoren added the comment:
The patch looks good, I will apply it over the weekend.
Thanks for looking into this.
--
___
Python tracker
<http://bugs.python.org/issue8
Ronald Oussoren added the comment:
There were some other build problems at the time, I haven't verified yet if the
fixes for those problems also fixed this issue. I will do so over the weekend.
--
___
Python tracker
<http://bugs.py
New submission from Ronald Oussoren :
When I build the trunk with srcdir != builddir test_distutils fails when
running tests.
To reproduce:
* Create a checkout of the trunk and chdir into this
* mkdir build
* cd build
* ../configure
* make test
This results in a failure for test_distutils
Ronald Oussoren added the comment:
In r80647 (trunk) you can use "configure
--enable-framework=$HOME/Library/Frameworks" to get the right situation:
- Framework in ~/Library/Frameworks
- Apps in ~/Applications/Python 2.7
- Command-line tools in ~/bin
I will port this to 3.2 lat
Ronald Oussoren added the comment:
get_config_var('srcdir') should work, with should then be combined with the
path to the Makefile, something like:
os.path.join(
os.path.dirname(os.path.abspath(
_get_makefile_filename(), get_config_var('srcdir')))
The path.join
Ronald Oussoren added the comment:
Als committed this for 3.2: r80648.
--
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
It does work just fine, see the attached patch.
--
___
Python tracker
<http://bugs.python.org/issue8577>
___
___
Python-bug
Ronald Oussoren added the comment:
Actually attaching the patch might help.
With this patch test_distutils passes, without it it doesn't.
--
keywords: +patch
Added file: http://bugs.python.org/file17147/issue8577.patch
___
Python tracker
Ronald Oussoren added the comment:
Yes, sorry about that. The patch in unixcompiler is for issue #7724.
--
___
Python tracker
<http://bugs.python.org/issue8
Ronald Oussoren added the comment:
Committed in r80653 (trunk), r80654 (2.6), r80655 (3.2) and r80656 (3.1)
--
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
Unassigning this issue from myself as I cannot reproduce the issue on OSX.
--
assignee: ronaldoussoren ->
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
I've added some notes to Mac/README.
r80657 (trunk)
r80658 (2.6)
r80659 (3.2)
r80660 (3.1)
--
___
Python tracker
<http://bugs.python.org/i
Changes by Ronald Oussoren :
--
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
I've cleaned up the patch and made it clearer that platforms other than OSX
aren't affected by rewriting code like this:
f = os.path.join(d, "db.h")
if sys.platform == "darwin" and is_macosx_sdk_path(d):
f = os.path.join(sy
Ronald Oussoren added the comment:
Firefox doesn't seem to support a full scripting api, which makes opening tabs
and windows harder.
I've committed an alternate version of your patch in r80698: This uses
osascript to open the url instead of the open command. I've also added
Ronald Oussoren added the comment:
I've ported the change to 3.2 as well.
--
___
Python tracker
<http://bugs.python.org/issue7192>
___
___
Python-bugs-list m
Ronald Oussoren added the comment:
As the bug is in the underlying platform the best we can do is to warn about
this in the documentation, as in the attached patch.
BTW. I've updated the title to be slightly more informative.
--
keywords: +patch
title: Mac OS X -> uu
Ronald Oussoren added the comment:
Because I didn't look closely enough at the source :-(
The attached patch disabled the C implementation on OSX 10.6 or later. I've
tested that 10.5 is not affected by the issue.
--
Added file: http://bugs.python.org/file17218/issue
Changes by Ronald Oussoren :
Removed file: http://bugs.python.org/file17217/issue8621-doc.patch
___
Python tracker
<http://bugs.python.org/issue8621>
___
___
Python-bug
Ronald Oussoren added the comment:
Also added a testcase that should warn if other unix-y platforms start to
suffer from the same issue.
BTW. issue8621.patch uses a runtime test in the uuid module instead of a
configure-check because a binary might be created on 10.5 (without the issue)
and
Ronald Oussoren added the comment:
I agree with Michael that something should be done.
I propose to add commit os-getgroups-v2.patch, which is the almost same as
os-getgroups.patch that I posted earlier, but adds a check for large values of
NGROUPS_MAX (see msg99913 for the rationale)
This
Changes by Ronald Oussoren :
Added file: http://bugs.python.org/file17221/os-getgroups-v2.patch
___
Python tracker
<http://bugs.python.org/issue7900>
___
___
Python-bug
Ronald Oussoren added the comment:
There are way more interesting regressions in OSX, issue8621 is one example:
basicly getgroups(2) does not reflect the results of setgroups(2) with the
compiler settings we use.
Committed in r80784 (trunk), r80785 (2.6), r80786 (3.2) and r80788 (3.1
Ronald Oussoren added the comment:
The PyMalloc error was a lame bug. I've also fixed another issue (missing
parenthesis in an error return).
os-getgroups-v3.patch also adds unittests:
* issue7900-tests.diff, but with all tests disabled on darwin (due to the
broken implementati
Ronald Oussoren added the comment:
Removed traces of MacOS9 support in r80804 (trunk) and r80805 (3.2)
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
The script works fine for me (OSX 10.6.3, /usr/bin/python2.5,
/usr/bin/python2.6, a recent build of 2.6.x, a recent build of 3.2 and the
trunk)
The breakit example in msg93828 works in 64-bit binaries, and fails on 32-bit
ones. This is almost certainly a
Changes by Ronald Oussoren :
Added file: http://bugs.python.org/file17234/os-getgroups-v3.patch
___
Python tracker
<http://bugs.python.org/issue7900>
___
___
Python-bug
Ronald Oussoren added the comment:
Installing a framework anywhere but a reasonably standard location doesn't
work. You should try to build with
"--enable-framework=$SOMEPREFIX/Library/Frameworks". Applications then get
installed in "$SOMEPREFIX/Applications"
Ronald Oussoren added the comment:
Committed to the trunk in r80963.
I'm not closing this yet because the patch needs to be ported to 3.2 at least,
and preferably 2.6 and 3.1 as well.
--
___
Python tracker
<http://bugs.python.org/i
Changes by Ronald Oussoren :
--
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue7724>
___
___
Python-bugs-list mai
Ronald Oussoren added the comment:
Closing because the patch in issue 7724 fixes this problem.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
Committed to the trunk in r80967.
Reducing the priority because this is no longer a release-blocker for the next
2.7 release.
--
priority: release blocker -> normal
___
Python tracker
<http://bugs.pyth
Ronald Oussoren added the comment:
And committed to 3.2 in r80968
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
I'll look into this in the morning.
--
___
Python tracker
<http://bugs.python.org/issue8084>
___
___
Python-bugs-list m
New submission from Ronald Oussoren :
I got a build error when building the 2.7b2 installers because the MacOS module
couldn't be build. That turns out to be caused by an issue in the configure
script: for some reason the check for the 10.5 SDK gives the wrong answer (both
with and wi
Ronald Oussoren added the comment:
I intend to forward port the fix to 3.2 in the near future, to avoid missing
real issues when I do updates to the platform support for OSX.
--
___
Python tracker
<http://bugs.python.org/issue8
Ronald Oussoren added the comment:
Cool, thanks. I'll check this later this week.
--
___
Python tracker
<http://bugs.python.org/issue8673>
___
___
Pytho
New submission from Ronald Oussoren :
The sdist command in distutils calculates the MANIFEST file from a template (by
default MANIFEST.in).
The code in sdist assumes that the contents of MANIFEST only depends on
MANIFEST.in and setup.py, which can cause files to be missed when building an
Ronald Oussoren added the comment:
The issue is indeed gone in HEAD. I've also verified the other 3 active
branches.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python
Ronald Oussoren added the comment:
The attached version should fix the issue found by Stefan. I'm going to do
builds on OSX as well as Linux before committing though.
--
Added file: http://bugs.python.org/file17316/issue7724-v3.patch
___
P
Ronald Oussoren added the comment:
I've verified that HEAD for both 3.1 and 3.2 build fine now, hence this issue
can be closed.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue8455>
___
___
Python-bugs-list mailing list
Un
Ronald Oussoren added the comment:
It prefer if it were clear why these tests fail (but don't have time to look
into this at the moment). That is, I don't mind if the tests get disabled on
darwin, but only if there is a documented reason for it because otherwise
disabling the test
Ronald Oussoren added the comment:
This issue is fixed in the trunk and python2.5 branch.
To work around this issue with the 2.5.1 source tree you have to set
MACOSX_DEPLOYMENT_TARGET when configuring python:
../configure MACOSX_DEPLOYMENT_TARGET=10.3
(the value 10.3 is what configure
New submission from Ronald Oussoren:
The scriptlet below hangs (as expected) but is also not interuptable by
Ctrl+C, at least on Linux and Mac OS X:
from Queue import Queue, Empty, Full
q = Queue()
q.get(True)
This is due to Threading.Condition.wait not being interuptable
Ronald Oussoren added the comment:
The change in the trunk seems like a good backport candidate, it fixes
an issue with float conversion on OSX compared to other platforms.
That said, I don't like the patch. This makes the current behaviour of
converting float NaN's to 0 the defined
Ronald Oussoren added the comment:
bundlebuilder should be deprecated (and removed in 3.0 / 2.7).
Currently the best tool for building bundles is py2app (which isn't part
of the stdlib)
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
New submission from Ronald Oussoren:
test_decimal fails on Mac OS X 10.3 when using Python 2.5.2c1. I haven't
tested other python versions. The same test passes on OSX 10.4 and 10.5
(both on Intel and PPC machines), this was done using the same binaries
(the Python.org build for 2.
Ronald Oussoren added the comment:
I did an upgrade install on the OSX 10.3. Doing a clean install removes
the problem.
I'm therefore closing this issue as invalid. Sorry about the noise.
--
resolution: -> invalid
status: open -> closed
___
Ronald Oussoren added the comment:
OSX installer is lame. The only way to work around this is to have pre-
and/or post-install hooks that remove the stdlib (but not site-
packages).
As this only affects the unittests I don't think this is worth the
problem right now. Especially because I
Ronald Oussoren added the comment:
That's a good idea. I'll try to get this into the installer before 2.5.2
is actually released.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Ronald Oussoren added the comment:
I've applied the workaround in revision 60903 (after testing that it
actually works).
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Unassigned as I'm unlikely to work on this.
BTW. My guess guess would be that this is an issue with Tk, not IDLE.
--
assignee: ronaldoussoren ->
__
Tracker <[EMAIL
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
To start: thanks for the patch.
I haven't done a detailed review yet, I have a minor nit: could you
change Mac/Makefile.in as well, specifically the definition:
PYTHONAPPSDIR=/Applications/MacPython $(VERSION)
This is used t
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
I'm pretty sure I get the same error when building PyObjC. It seems to be
a harmless warning though, PyObjC passes all its unittests and those
really exercise all of libffi.
__
Tracker <[E
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
The new patch looks great. I'll apply it next week.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2573>
__
___
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
This functionality is enabled as of revision 62644
The actual patch is slightly more involved than the attached patches,
the patch forgot to add a variable to Mac/Makefile.in and doesn't patch
Mac/IDLE/Makefile.in at all.
I&#
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Python Launcher assumes that Terminal.app has a specific creator code,
that's no longer true in Leopard.
The code in doscript.m was already rather hackish, I've replaced it by
a more modern way to use AppleEvents.
I'
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Fixed in revision 62651 (trunk) and 62650 (2.5 branch)
The fix doesn't use the attached patch, but explicitly sets a file
encoding for this module.
--
nosy: +ronaldoussoren
resolution: -> fixed
status:
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
I don't think this issue is relevant at this point in time.
Apple now ships a regular framework and furthermore I don't think this
build style is useful to have.
--
nosy: +ronaldoussoren
resolution: -> re
Changes by Ronald Oussoren <[EMAIL PROTECTED]>:
--
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1087737>
_
___
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
This is definitly not an issue anymore, the official releases get build
with a DESTROOT and don't suffer from this problem.
--
resolution: -> fixed
status: open -> closed
___
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
I cannot reproduce this issue with Python 2.5 or 2.6.
There was a bug in terminalcommand when running on Leopard, I fixed that
earlier tonight.
--
resolution: -> works for me
status: open -
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
See also http://www.cocoabuilder.com/archive/message/cocoa/2006/11/18/174677
The attached patch should fix this issue.
Jack, could you please check if the patch is sane? The patch works on
10.5.2, I haven't checked on 10.4 yet
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
The patch looks sane, I'm assigning the bug to myself to help me remember
that I should take a closer look.
--
assignee: jackjansen -> ronaldoussoren
nosy: +ronaldoussoren
_
T
Changes by Ronald Oussoren <[EMAIL PROTECTED]>:
--
assignee: ronaldoussoren ->
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue162>
_
___
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
AFAIK this is fixed in the trunk, you'll get a message that the filename
or mode is incorrect (but not which one).
That's the best open() can do because the underlying C API doesn't give
enough information to dec
Changes by Ronald Oussoren <[EMAIL PROTECTED]>:
--
resolution: -> wont fix
status: open -> closed
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
I don't really agree. Libedit's configuration is different from that of GN
U readline. It might be useful to document this issue in the documentation
of the readline module (and of rlcompleter).
Another alternative would b
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
This is a bug in the mercurial installer. The problem is in the Makefile,
not in setup.py.
Specially, the makefile calls "python setup.py --prefix=/usr/local".
That's not the correct prefix with a framework install
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Have you read that code? The Carbon-specific code in there is needed to
make the module behave correctly in OSX: the Carbon specific code is used
to get and set some Mac-specific file attributes.
It should be easy enough to move tha
401 - 500 of 2445 matches
Mail list logo
