Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Do you mean the -rpath option?
Note that this is (IMHO) less useful than on other systems because the
linked-to library needs to have a specific link path (@rpath/mylib.dylib).
It can be useful for linking extentions though.
Usin
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Annoyingly enough my patch isn't good enough, it turns out that ctypes
has introduced a SIZEOF__BOOL definition in configure.in and that needs
special caseing as well.
pymacconfig.h.patch2 fixes that issue as well. Do you have
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
The attached patch fixes this issue.
--
keywords: +patch
Added file: http://bugs.python.org/file11725/issue4064-fix.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Ronald Oussoren <[EMAIL PROTECTED]>:
--
keywords: +needs review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4064>
___
_
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
IMHO the best fix would be to use "/bin/cp" instead of plain "cp". It is
not possible to use $(INSTALL) here because this step does a recursive
copy.
NOTE: The same fix should also be applied to the trunk a
Changes by Ronald Oussoren <[EMAIL PROTECTED]>:
--
versions: +Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3433>
___
_
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
The basic idea is that the architecture bit of get_platform() should
tell you something about the archicture for which a build is valid.
That's why 'i386' or 'ppc' is not very useful for a universal bui
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
On 7 Oct, 2008, at 18:29, Trent Mick wrote:
>
> Trent Mick <[EMAIL PROTECTED]> added the comment:
>
>> I get:
>>
>> sizeof(_Bool)=4 bytes
>>
>> on a G4 PPC.
>
> Same thing on
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
On 7 Oct, 2008, at 22:13, Martin v. Löwis wrote:
>
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
>> Somewhere along the way the calculation of the architecture string
>> got
>> messed
Ronald Oussoren added the comment:
I agree with Ned: the correct patch is to hardcode usage of /usr/bin/arch,
because that's the one the build environment is expecting to use and the only
one I care to support.
--
___
Python tracker
Ronald Oussoren added the comment:
Thanks for the patch, I didn't know of the -dumpversion flag.
--
___
Python tracker
<http://bugs.python.org/issue7714>
___
___
Ronald Oussoren added the comment:
Steve: the "report this..." message is generated by the configure script and is
added by autoconf, AFAIK we cannot change that message.
That said: there is a problem on your system with a python build: configure now
thinks that is has found
New submission from Ronald Oussoren :
On OSX it is possible to compile using an SDK, which is basicly a directory
tree containing include files and shared library stubs. When building using an
SDK (such as the 10.4u SDK) the compiler looks in the SDK subtree instead of /
(that is, look for
Ronald Oussoren added the comment:
I've committed this in 77585 (trunk) and will port this to the other branches
soon.
--
resolution: -> fixed
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue7714>
___
___
Python-bugs-list mailing list
Un
Ronald Oussoren added the comment:
I've committed a fix for this in r77585, please test.
I can now compile python-trunk on OSX 10.6 while targetting the 10.4 SDK, and
have compiled on OSX 10.4 as well.
I will forward port this t
Changes by Ronald Oussoren :
--
resolution: -> fixed
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue7658>
___
___
Pyth
Ronald Oussoren added the comment:
Issue7713 is not the same: it asks for a way to affect the hardcoded paths in
setup.py, this issue asks to honor the SDK-root by setup.py.
I've done some further research and this affects distutils in general: the
compiler has methods to look for file
Ronald Oussoren added the comment:
I agree, our usage of -isysroot seems to be correct.
What's rather annoying is that the documentation seems to claim that the
sysroot value gets prepended to every search location, while that is obviously
not try. My guess is that it is only prepende
Changes by Ronald Oussoren :
--
resolution: -> works for me
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
(I've removed 3.0 from the list because we no longer do maintenance releases
for that).
My gut feeling is that this an issue with Tkinter.
--
resolution: -> accepted
stage: -> needs patch
type: -> behavior
versions
Changes by Ronald Oussoren :
--
resolution: -> works for me
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Ronald Oussoren :
--
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org
Ronald Oussoren added the comment:
I've committed a small change in r77587 (trunk) that disables usage of the
10.4u SDK when that SDK is not present.
That may or may not fix this issue. I'm not going to do anything more to this
issue and am therefore closing it.
--
Ronald Oussoren added the comment:
I've applied a patch to use /usr/bin/arch instead of just 'arch' in r7715
(trunk).
I will port this to the other branches soonish.
--
resolution: -> fixed
stage: patch review -> committed/rejected
_
New submission from Ronald Oussoren :
The output of platform.system() should IMO be "macosx" on OSX to ensure that
platform.platform() is consistent with distutils.util.get_platform().
The same is true for sys.platform, although it is unclear how much code that
would break.
The
Ronald Oussoren added the comment:
re: msg98913
The addition of an #include of stdlib.h is unnecessary because Python.h already
does that.
re: msg98908
Building against with a 10.3 deployment target should be harmless. A universal
build targets 10.3 on purpose because that results in
Ronald Oussoren added the comment:
Two short notes:
1) The call to gestalt('sysu') is basicly dead code and will be removed
2) Running the GUI runloop in a thread that is not the main thread is AFAIK not
supported by Apple. I'm not 100% sure about the Carbon libraries, but in
Ronald Oussoren added the comment:
Removed the call to gestalt('sysu') in r78056 (trunk), r78057 (2.6), r78058
(3.x), r78060 (3.1)
(Also changing the type to 'behavior' instead of 'crash' because this is not a
crashing bug in python).
--
resolution:
Ronald Oussoren added the comment:
I've disabled the tests (and updated documentation) in r78061 (trunk), r78062
(2.6)
The root cause is that the implemention of macostools uses FSSpecs to implement
the failing APIs and those aren't available in 64-bit code. I haven't
re
Changes by Ronald Oussoren :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
TJ: thanks for testing on 10.3.9.
--
stage: test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Ronald Oussoren added the comment:
Ported to 2.6 (r78065), 3.x (r78066) and 3.1 (r78068)
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
I have a question about this bit of the patch:
@@ -38,10 +38,31 @@
#if defined(_RL_FUNCTION_TYPEDEF)
extern char **completion_matches(char *, rl_compentry_func_t *);
#else
+#if !defined(__APPLE__)
extern char **completion_matches(char *, CPFunction
Ronald Oussoren added the comment:
This is now fixed in the 3.2 branch as well.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
Committed in r78097 (trunk) and r78098 (3.2). This includes the documentation
change suggested in msg88437
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
_
Ronald Oussoren added the comment:
I don't understand the second message: you should use make instead of setup.py
during the build/installation of python from source.
The build warnings are harmless, although you aren't building what you think
you are.
The configure line
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue7852>
___
___
Python-bugs-list mailing list
Un
New submission from Ronald Oussoren :
build_ext calculates which files for an Extension need to be recompiled. This
calculation is way to aggrasive: if any source file for an Extension has
changed all source files get recompiled.
It would be nice if distutils would only recompile the sources
Changes by Ronald Oussoren :
--
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue7895>
___
___
Python-bug
Ronald Oussoren added the comment:
Do you use your an installer from python.org or your own build? The crashlog
seems to indicate the latter (because of the Code Type).
Which version of Tk are you using? Which OS release?
I know there are issues with the system Tk 8.5 on OSX 10.6, although
Ronald Oussoren added the comment:
I've added the tests to the 2.6 branch and have ported the #ifdef guard around
the prototype for completion_matches to the trunk and 3.2.
I'm therefore closing the issue.
--
status: open -> closed
_
Ronald Oussoren added the comment:
Ned: I fixed the ARCH_RUN_32BIT definition for 3-way universal builds in
r78150.
Also ported the patch to 2.6, 3.2 and 3.1.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
New submission from Ronald Oussoren :
The attached patch removes all traces to os.name == 'mac' from the source tree
(setup.py and stdlib), that is the leftover traces for MacOS9 support.
A simular patch needs to be created of the 3.x tree.
--
assignee: ronaldoussoren
Changes by Ronald Oussoren :
--
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue7908>
___
___
Python-bugs-list mailing list
Unsub
Changes by Ronald Oussoren :
--
keywords: +needs review
___
Python tracker
<http://bugs.python.org/issue7908>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
The reason I'd like a patch review is that it affects a lot of files and want a
second pair of eyes to check that I haven't been too agressive.
The patch itself doesn't cause regressions i
Ronald Oussoren added the comment:
Katherine: how did you install Python, did you use the installer on the
python.org website or some other installer (or even by building from source)?
--
___
Python tracker
<http://bugs.python.org/issue5
Ronald Oussoren added the comment:
Michael:
* which configure options do you use?
* which xcode version do you use?
(this shouldn't be relevant, I'm interested in what causes the dot 1
suffix)
* If you use --enable-universalsdk: do you have the 10.4 SDK installed
(should be in
Ronald Oussoren added the comment:
A related question: is this issue present in the 3.x trunk?
(BTW: feel free to assign all OSX related issues to me)
--
assignee: -> ronaldoussoren
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
That's odd, they should exist and do for me:
Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Ronald Oussoren added the comment:
This test seems to trigger an issue in site.py, adding '-v' to the code that
starts the interpreter in test_platform.py gives the following output (amongst
a lot more text that doesn't seem to be relevant):
'import site' failed; t
Ronald Oussoren added the comment:
And as usual they can't be bothered to describe what the patch does, or even
use regular universal diffs.
--
___
Python tracker
<http://bugs.python.org/i
Ronald Oussoren added the comment:
Alexander: What makes you think r63955 introduced the problem?
Btw. This does not crash the interpreter: the example you give causes an
exception and cleanly shuts down the interpreter. The exception is unwanted,
but I wouldn't call it a crash.
Ronald Oussoren added the comment:
On my system with the attached patch (os-getgroups.patch):
$ sudo ./python.exe
Python 2.7a3+ (trunk:78371M, Feb 23 2010, 09:19:44)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "licens
Ronald Oussoren added the comment:
My patch is very lightly tested and I didn't try to use the additional
testcases.
I get test failures, but no crashes, when I do run the additional tests. I
haven't had time to review the testcases though.
What I did notice though is that the t
New submission from Ronald Oussoren :
The stat implementation on osx 10.5 or later can provide additional fields
beyond the tradional unix ones (such as "st_birthtimespec"). Those are by
default only available when using 'stat64' instead of the regular stat, but
that ca
Ronald Oussoren added the comment:
To be more precise: see issue8001.
The OSX 10.5 introduces a new version of stat 'stat64' that exposes additional
information to posix-style programs, amongst which is the file creation date.
This field is not present in earlier editions of OSX a
Ronald Oussoren added the comment:
I'm -1 w.r.t changing the definition of _DARWIN_C_SOURCE, at least not without
a thorough investigation on what else this changes. Removing _DARWIN_C_SOURCE
without setting some other defines may well cause in removal of functions from
header files
Ronald Oussoren added the comment:
I'm probably being extremely dense at the moment, but the program below doesn't
behave as I'd expect on OSX:
#include
int main(void)
{
#if 1
gid_t gids[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
17, 18, 19, 20 }
Ronald Oussoren added the comment:
I've filed issue #7681618 in Apple's bugtracker with the attached file
"getsetgroups-bug.tar" as a way to reproduce the issue.
I want to wait a little to see how Apple responds (although I don't expect a
quick response).
--
Ronald Oussoren added the comment:
quoting compat(5) on OSX 10.6.2:
Defining _POSIX_C_SOURCE or _DARWIN_C_SOURCE causes library and kernel
calls to conform to the SUSv3
standards even if doing so would alter the behavior of functions used in
10.3. Defining
_POSIX_C_SOURCE
Ronald Oussoren added the comment:
I'd expect more failures, the failure is caused by the way the sysconfig module
calculates the root of the installation, and whether or not it is running in
the source tree.
Tarek: could you please review sysconfig.
Ronald Oussoren added the comment:
On 7 Mar, 2010, at 1:02, Alexander Belopolsky wrote:
>
>
> Does anyone know where libedit bugs should be reported?
Apple's bugreporter. (bugreport.apple.com, you need an ADC account to report
bugs).
--
Added file: http://bugs.python
Ronald Oussoren added the comment:
Fix in r78755 (2.7) and r78756 (3.2)
(the issue doesn't affect 2.6 or 3.1 because those have another implementation
of the python/pythonw command)
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
version
Ronald Oussoren added the comment:
Barry and Benjamin: IMHO this should be fixed before 2.6.5 and 3.1.2 are
released, the patch is safe and works (and is already in the trunk).
--
nosy: +barry, benjamin.peterson
priority: -> release bloc
Ronald Oussoren added the comment:
Barry: this definitely needs to be applied before 2.6.5 is released, without
the patch I cannot build the mac installers.
The patch disables support for libedit when targetting 10.4, which is IMHO
correct because as Ned notes libedit's readline emulati
Ronald Oussoren added the comment:
I've removed 2.5 and added 3.2 because there won't be further bugfix releases
of 2.5 and the issue also affects 3.2.
IMHO changing this behavior is not a bugfix and is therefore out of scope for
2.6.x, in particular because this change might break
Ronald Oussoren added the comment:
I propose to at least change the code in pythonlauncher to warn if it is the
default association for python files, that is to reverse the test that it
currently does.
That way users can still set pythonlauncher as the launcher for a specific
files, but
New submission from Ronald Oussoren :
The proxy support code in urllib is imho too specific and cannot easily support
dynamic proxy configuration using a proxy.pac file.
That is, the code assumes that there is at most one proxy per protocol, while
this is not quite true in practice. A
Ronald Oussoren added the comment:
I've done some research: the st_birthtime field is available when the python
executable is build using MACOSX_DEPLOYMENT_TARGET=10.5 (or later), not for
10.4.
Adding support for st_birthtime for MACOSX_DEPLOYMENT_TARGET=10.4 is possible
but req
Ronald Oussoren added the comment:
I've attached a patch that fixes the issue and enables all test_locale tests on
OSX 10.6.
(I will test if the tests can also be enabled on 10.5 when applying the patch).
--
keywords: +needs review, patch
resolution: -> accepted
Added fi
New submission from Ronald Oussoren :
The implementation of pep-0370 treats OSX like any other unix platform.
This is problemantic for two reasons: first of all OSX already had a per-user
directory before pep-0370 was implement: ~/Library/Python/X.Y, which means
there are now two per-user
Ronald Oussoren added the comment:
The attached patch is untested an implements the proposed behavior for
framework builds, unix builds would keep the unix-style behavior (and would
lose access to ~/Library/Python).
The patch is slightly complicated by adding support for --with-framework
Ronald Oussoren added the comment:
Committed in r78781 (2.6), r78782 (3.2) and r78783 (3.1)
--
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Ronald Oussoren added the comment:
Committed in r78784 (trunk), r78785 (2.6) and r78786 (3.2)
(BTW. I applied the patch to the trunk then used svnmerge to merge the patch
into the other branches)
--
stage: -> committed/rejected
status: open ->
Ronald Oussoren added the comment:
2.6 should be fixed in r78805. I won't have time to merge the fix into the
other branches until at best later tonight.
--
___
Python tracker
<http://bugs.python.org/i
Ronald Oussoren added the comment:
3.2 and 3.1 should now also be fixed (in r78808 and r78809)
Please test.
--
___
Python tracker
<http://bugs.python.org/issue8
Changes by Ronald Oussoren :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8067>
___
___
Python-bugs-list mailing list
Unsubscri
Ronald Oussoren added the comment:
I don't have a 10.3 system to test on, and definitely don't want to spent
effort on enabling compiles on 10.3
The patch below would probably fix the crash when running a binary created on
10.4 or later on osx 10.3:
Index: ../Mac/Modules/
Ronald Oussoren added the comment:
I've commited a fix for 2.6 in r78813.
I will port that fix to 3.1 later today, but don't have time to test right now.
My fix is simular to the patch by Ned.
--
___
Python tracker
<http://bu
Ronald Oussoren added the comment:
Ned: I fixed the typo in r78816
--
___
Python tracker
<http://bugs.python.org/issue8089>
___
___
Python-bugs-list mailin
Ronald Oussoren added the comment:
Changing get_history_item to be 0-based would be a backward incompatible change.
The point of my report is that the documentation of the readline documentation
should mention how the APIs actually behave, you currently have to hunt down
that information in
Changes by Ronald Oussoren :
Removed file: http://bugs.python.org/file16480/smime.p7s
___
Python tracker
<http://bugs.python.org/issue8065>
___
___
Python-bugs-list mailin
Ronald Oussoren added the comment:
Without filing a bug Apple won't know that something is wrong and they will
definitly not fix the issue. If you file an issue and post the radar number
I'll ping the Python maintainer inside Apple. There's little change that this
will be
Ronald Oussoren added the comment:
This issue is off-topic for the python bugtracker.
But: to install pyobjc you need to do three things:
1) Download and install easy_install or distribute
(download from pypi.python.org)
2) Check that 'which easy_install' refers to a
f
Ronald Oussoren added the comment:
IMHO stuffing xxmodule.c inside the distutils test tree (see msg100815) is the
right solution because the python source tree might not be present during
testing (such as when the user does a binary install and then runs the
unittests to check if everything
Ronald Oussoren added the comment:
This doesn't fail on OSX when using a framework build of Python because that
uses a different way to find sys.prefix: in Python.framework the shared library
with the interpreter (libpython.so on Linux) is always in a known location
relative to sys.p
New submission from Ronald Oussoren :
If I understand the code correct Python 2.6 has the same value for
PYTHON_API_VERSION, even though extensions are not compatible.
In particular: when you compile an extension that uses PyInt_Check with
python2.6 and load that extension with python 2.5 you
Ronald Oussoren added the comment:
On 15 Mar, 2010, at 16:22, Tom Loredo wrote:
>
> Tom Loredo added the comment:
>
> Ned-
>
> I *did* run "make install"; everything I reported was about the situation
> *after* running "make install". In particul
Ronald Oussoren added the comment:
But should PYTHON_API_VERSION be increased for the 2.7 release?
I think it should because of the binary incompatible differences between 2.5
and 2.6. In a perfect world that would have resulted in an increase of
PYTHON_API_VERSION for the 2.6.0 release
Ronald Oussoren added the comment:
Barry: these patches affect 2.6, but can easily wait for 2.6.6: its basically
sync-ing the OSX package-building infrastructure between the 4 active Python
branches. This does not directly affect anything seen by users
Ronald Oussoren added the comment:
Setting CPPFLAGS is needed to ensure that the configure tests use the correct
header files, as Ned noted.
I agree that this should be cleaned up, I also agree with MAL's comment in
Issue8211: the entire machinery for setting up the compiler in Pyt
Ronald Oussoren added the comment:
Ned: the patch does have a (positive) effect when building the OSX installer:
the build-installer script creates private builds of a number of libraries, but
setup.py can detect other libraries (such as libintl) as well and we don't
guard against th
New submission from Ronald Oussoren :
I cannot build a framework build of the 3.2 branch at the moment due to
unresolved references to "_Py_char2wchar" when linking the dylib that gets
placed into the framework:
Undefined symbols:
"__Py_char2wchar", referenced fro
Changes by Ronald Oussoren :
--
components: +Build
___
Python tracker
<http://bugs.python.org/issue8441>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
Fixed in r80181 (3.2)
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> compile error
___
Python tracker
<http://bugs.pytho
Ronald Oussoren added the comment:
Fixed in r80178 (trunk), r80180 (2.6), r80182 (3.2), r80183 (3.1)
--
resolution: accepted -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
New submission from Ronald Oussoren :
In the output of test_distutils with python 3.2 (current version checkout):
==
ERROR: test_prune_file_list (distutils.tests.test_sdist.SDistTestCase
New submission from Ronald Oussoren :
In the output of test_distutils with python 3.2 (current version checkout):
==
ERROR: test_prune_file_list (distutils.tests.test_sdist.SDistTestCase
301 - 400 of 2445 matches
Mail list logo
