[ python-Bugs-1508369 ] logging module formatter problem with %(filename)s
Bugs item #1508369, was opened at 2006-06-19 04:08 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: David Hess (david_k_hess) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: logging module formatter problem with %(filename)s Initial Comment: With Python 2.4.3 installed via the .dmg on to MacOS, when the python modules are compiled, they are compiled by specifying the path in such a way that it contains a double slash. This causes the logging module to not be able to figure out which module is the correct one to replace for % (filename)s. The following is the crux of the issue: >>> logging.debug.func_code.co_filename '/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/ logging/__init__.py' >>> logging.__file__ '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ logging/__init__.pyc' >>> These two strings need to match for %(filename)s to work. I deleted /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/logging/__init__.pyc and recompiled it by just importing logging. That fixed the problem. I assume the fix will be in the installer somewhere. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:32 Message: Logged In: YES user_id=580910 Originator: NO Closing because this is fixed in 2.5 and beyond and 2.4 is closed for maintainance -- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-03 09:46 Message: Logged In: YES user_id=1326842 Originator: NO The 2.4 branch is not maintained anymore. Can this bug be closed? -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:16 Message: Logged In: YES user_id=580910 Fixed in revision #47093 for python2.5. I'm not closing the bug yet because I haven't backported this to 2.4 yet. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530142 ] Mac Universal Build of Python confuses distutils
Bugs item #1530142, was opened at 2006-07-28 08:02
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Richard Jones (richard)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Mac Universal Build of Python confuses distutils
Initial Comment:
I'm sorry I can't provide a fully-detailed report
here, but I'm not in a position to be able to
reproduce the problem.
In short, I installed the Universal build of Python
2.4.3 for the Mac downloaded from:
http://pythonmac.org/packages/py24-fat/index.html
I don't know whether this is the same as the download
from:
http://www.python.org/download/releases/2.4.3/
Once installed, I attempted to build ctypes.
The build failed due to an assembly error (unknown
instruction). I'm not familiar with the PPC or x86
assembler code so couldn't do a thorough analysis.
I needed Python2.4 to work, so I found an older
PPC-only installer and used that.
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-09 09:35
Message:
Logged In: YES
user_id=580910
Originator: NO
I'm closing this bug, the problem is in ctypes installer you used.
For the record: you can build a ppc/intel only version of an extension by
patching the setup.py of the project your building and adding ('-arch',
'i386') or ('-arch', 'ppc') to the extra_compile_args and extra_link_args
of Extension objects (I'm typing this without looking at the documention
and have probably misspelled these argument names)
--
Comment By: Richard Jones (richard)
Date: 2006-11-28 22:56
Message:
Logged In: YES
user_id=6405
Originator: YES
I just successfully built ctypes 1.0.1 on a MacBook (ie. x86) OS X
machine. I don't know whether it builds on a PPC machine.
--
Comment By: Richard Jones (richard)
Date: 2006-08-16 23:52
Message:
Logged In: YES
user_id=6405
I successfully built ctypes on PPC OSX using a
non-universal build. Also, I wasn't running on x86 OSX so
it shouldn't have tried to build that.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-08-16 15:25
Message:
Logged In: YES
user_id=21627
This might be a ctypes limitation: it might be that ctypes
doesn't support x86-OSX (atleast in this release).
--
Comment By: Richard Jones (richard)
Date: 2006-07-28 08:47
Message:
Logged In: YES
user_id=6405
0.9.9.6
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-28 08:28
Message:
Logged In: YES
user_id=580910
Which version of ctypes did you try to build?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1563046 ] MacPython ignores user-installed Tcl/Tk
Feature Requests item #1563046, was opened at 2006-09-21 19:55 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1563046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Macintosh >Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Russell Owen (reowen) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: MacPython ignores user-installed Tcl/Tk Initial Comment: MacPython ignores any user-installed Framework Tcl/Tk. This is a significant issue for Tcl/Tk users because the Tcl/Tk included with Tiger is buggy and really shouldn't be used. Bob Ippolito supplied me a recipe to fix _tkinter.so: install_name_tool \ -change /System/Library/Frameworks/Tcl.framework/Versions/8.4/ Tcl \ /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl \ -change /System/Library/Frameworks/Tk.framework/Versions/8.4/ Tk \ /Library/Frameworks/Tk.framework/Versions/8.4/Tk \ _tkinter.so I encapsulated this recipe into the attached python script "fixtkinter.py", which modifies _tkinter.so to use the user's Tcl/Tk, if found. Please consider running this script while installing MacPython. If you want any refinements to the script, I am happy to provide them (or feel free to modify it yourself of course). Subtleties: - The script uses Carbon.Folder.FSFindFolder to find the "/Library/ Framework" directory, so it should work in any country. - The script fixes the _tkinter.so for the python that executes the script (finding it relative to the "os" module). - The script silently exits without doing anything if no /Library/ Framework Tcl/Tk is found. Thus it is safe to run for all MacPython installations. - It can safely be run more than once; it silently does not modify _tkinter.so file the second time. - It finds the link using ...Tcl.Framework/Versions/Current but resolves the link before modifying _tkinter.so. So if a user upgrades a major Tcl/ Tk version the _tkinter.so file will keep using the old version. I think this is a good thing, since compatilibility is likely to be an issue. - It only looks for a user-installed Tcl/Tk in "/Library/Frameworks"; it does NOT look in the user's private library (~/Library). This was intentional, but I'm not sure it was the right decision. I'm happy to change it, but will want some advice on the best algorithm. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:40 Message: Logged In: YES user_id=580910 Originator: NO Current builds of python look in /Library and /System/Library (in that order). IMHO that is good enough(tm), as that's where one would expect Tcl/Tk to be unless a really savy user did a manual install from source. I don't like shipping the proposed fix module, IMHO it would be better to publish that somewhere else (such as the python cookbook) as scripts like this will otherwise likely be overlooked. Changing the link path should also not be necessary with current builds of python. -- Comment By: Russell Owen (reowen) Date: 2006-09-25 22:43 Message: Logged In: YES user_id=431773 I see what you mean about different installations. I think the following might work better: - Always modify _tkinter.so to point to Tcl/Tk 8.4 in /Library/Frameworks. This will fall back to the built in /System/Library/Frameworks if the user has not installed an 8.4 of their own. It avoids a few of the issues you bring up and is simpler and more robust than what I originally suggested. Advantages: - All installations would be the same. - If the user installs a new Tcl/Tk after installing Python, it would be used (unless it's 8.5, which would not be safe to try with Python). It still does not address your concern than a user might accidentally have a Tcl/Tk that they don't want to use. I'd personally be happier if users could easily upgrade their Tcl/Tk (since the installed one is so bad), so I see this as more of an advantage than a disadvantage. Users aren't going to typically install Tcl/Tk unless they want to use it, I think. Still...I'm sure you've seen more requests for help than I have over the years. I'm not keen on including a Tcl/Tk for several reasons: - It can be tricky to add needed additions (my app uses the "snack" sound library, for example). A standard Tcl/Tk makes this much easier (and in fact ActiveState Tcl/Tk already includes all additions most folks would want). - There is no universal Tcl/Tk yet (though one is planned). I personally don't want to try to build one. - Which version would you use? Even 8.4.11 has some important known bugs, and 8.4.13 has different ones (at leas
[ python-Feature Requests-1555501 ] Please include pliblist for all plattforms
Feature Requests item #101, was opened at 2006-09-09 22:07 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=101&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido Guenther (guidog) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Please include pliblist for all plattforms Initial Comment: Hi, plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too (e.g. in apples calendar server which runs on OS X and Linux). Could this be moved to Lib/ for 2.5 so that other platforms can benefit from it too? Cheers, -- Guido -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:44 Message: Logged In: YES user_id=580910 Originator: NO assigning to me to help me remember that I should write documentation. -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-12 11:08 Message: Logged In: YES user_id=580910 As an aside: adding plistlib to the standard library seems to be a good idea. I've discussed this with Jack Jansen and Bob Ippolito and they agree. The only thing that's missing at the moment is documentation. -- Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 11:05 Message: Logged In: YES user_id=849994 Currently, there is no documentation for plistlib. Would you be willing to help writing one? -- Comment By: Guido Guenther (guidog) Date: 2006-09-17 22:27 Message: Logged In: YES user_id=696207 That's sad since it looks unproblematic. Please add it to 2.6 then. Thanks a lot, -- Guido -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 21:27 Message: Logged In: YES user_id=580910 this is too late for 2.5. Adding it to the general library could be done for 2.6. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=101&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1738250 ] Universal MacPython 2.5.1 installation fails
Bugs item #1738250, was opened at 2007-06-16 10:03 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738250&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shinichiro Wachi (swachi) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Universal MacPython 2.5.1 installation fails Initial Comment: Cannot install package due to file errors. Somehow related to wrong archive format. Install log is attached. Google search indicates that at least one other person has reported this error in external forum. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:48 Message: Logged In: YES user_id=580910 Originator: NO What version of OSX are you using and on what CPU-type? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738250&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1736103 ] Mac build fails if not building universal due to libtool
Bugs item #1736103, was opened at 2007-06-12 23:12 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736103&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Mac build fails if not building universal due to libtool Initial Comment: If you try to build the svn trunk without universalsdk the make will fail: the Makefile tries to use libtool to create the shared library, but on (unmodified) OSX it should use glibtool. I have no idea who to assign this to, I hope you have a bettter idea. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:52 Message: Logged In: YES user_id=580910 Originator: NO Which configure arguments are you using? Are you building a framework or a plain unix install? IMHO the call to libtool in Makefile.pre.in is correct, but that's only used when building a framework. The call to libtool is supposed to be a call to Apple's libtool, not the GNU tool with the same name. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736103&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1738250 ] Universal MacPython 2.5.1 installation fails
Bugs item #1738250, was opened at 2007-06-16 01:03 Message generated for change (Comment added) made by swachi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738250&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shinichiro Wachi (swachi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Universal MacPython 2.5.1 installation fails Initial Comment: Cannot install package due to file errors. Somehow related to wrong archive format. Install log is attached. Google search indicates that at least one other person has reported this error in external forum. -- >Comment By: Shinichiro Wachi (swachi) Date: 2007-07-09 00:53 Message: Logged In: YES user_id=279950 Originator: YES Sorry, I forgot to specify those: 1) OSX ver. 10.4.9 2) Processor: 1.5 GHz PPC G4 -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 00:48 Message: Logged In: YES user_id=580910 Originator: NO What version of OSX are you using and on what CPU-type? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738250&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627543 ] Status bar on OSX garbled
Bugs item #1627543, was opened at 2007-01-04 05:49 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: sigzero (sigzero) Assigned to: Nobody/Anonymous (nobody) Summary: Status bar on OSX garbled Initial Comment: The way that OSX windows work there is always a resizing handle in the lower right hand corner of windows. The way that IDLE currently does the statusbar is: |Ln: 13|Col: 4 This cause the Col number to be placed over the resizer. Something along the lines of: |Ln: 13|Col: 4| would probably ensure that the resizer is not overlayed. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 10:09 Message: Logged In: YES user_id=580910 Originator: NO Don't run OSX GUI applications outside of an application bundle, that is unsupported behaviour as far as the OS is concerned. Python has a workaround that makes it possible to do this, but that's mostly meant to be used during development only. If you want to open a file in idle from the command-line use 'open -a IDLE somefile.py'. I'm closing this bug as wont-fix because of this. -- Comment By: Gus Tabares (gtabares) Date: 2007-04-17 17:04 Message: Logged In: YES user_id=834009 Originator: NO This is only reproducible when invoking IDLE from the Terminal. Invoking IDLE from the Finder is not affected. Here is the broken code in question: Line 299 EditorWindow.py if macosxSupport.runningAsOSXApp(): This will always return False from the Terminal because IDLE.app is not in sys.argv[0] (see macosxSupport.py line 9). -- Comment By: sigzero (sigzero) Date: 2007-01-04 05:49 Message: Logged In: YES user_id=1339209 Originator: YES This is for IDLE 1.1.4 and I am using Python 2.4.4 on OSX Tiger. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627543&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590864 ] import deadlocks when using PyObjC threads
Bugs item #1590864, was opened at 2006-11-05 17:06
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Tsai (michaeltsai)
Assigned to: Nobody/Anonymous (nobody)
Summary: import deadlocks when using PyObjC threads
Initial Comment:
When I use subprocess.py from a child thread, sometimes it deadlocks. I
determined that the new process is blocked during an import:
#0 0x90024427 in semaphore_wait_signal_trap ()
#1 0x90028414 in pthread_cond_wait ()
#2 0x004c77bf in PyThread_acquire_lock (lock=0x3189a0, waitflag=1)
at Python/thread_pthread.h:452
#3 0x004ae2a6 in lock_import () at Python/import.c:266
#4 0x004b24be in PyImport_ImportModuleLevel (name=0xaad74 "errno",
globals=0xbaed0, locals=0x502aa0, fromlist=0xc1378, level=-1) at
Python/import.c:2054
#5 0x0048d2e2 in builtin___import__ (self=0x0, args=0x53724c90,
kwds=0x0) at Python/bltinmodule.c:47
#6 0x0040decb in PyObject_Call (func=0xa94b8, arg=0x53724c90,
kw=0x0) at Objects/abstract.c:1860
and that the code in question is in os.py:
def _execvpe(file, args, env=None):
from errno import ENOENT, ENOTDIR
I think the problem is that since exec (the C function) hasn't yet been
called in the new process, it's inherited from the fork a lock that's already
held. The main process will eventually release its copy of the lock, but this
will not unlock it in the new process, so it deadlocks.
If I change os.py so that it imports the constants outside of
_execvpe, the new process no longer blocks in this way.
This is on Mac OS X 10.4.8.
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-09 10:15
Message:
Logged In: YES
user_id=580910
Originator: NO
Do you have sample code that reproduces this problem? (Not necessarily
code that has this problem 100% of the time)
--
Comment By: Kosuha (kosuha)
Date: 2007-02-27 17:54
Message:
Logged In: YES
user_id=1684258
Originator: NO
I confirm that problem with deadlock on execution of
PyImport_ImportModuleLevel exists. Here is a working example:
1) Python was embbeded with C++ application using Python for scripting
support:
--
PyThreadState * InitThreadScripting()
{
ASSERT_KOBOLD( g_pyMainThreadState );
// get the global lock
PyEval_AcquireLock();
// get a reference to the PyInterpreterState
PyInterpreterState * mainInterpreterState = g_pyMainThreadState->interp;
ASSERT_KOBOLD( mainInterpreterState );
// create a thread state object for this thread
PyThreadState * myThreadState = PyThreadState_New(mainInterpreterState);
// free the lock
PyEval_ReleaseLock();
return myThreadState;
}
-
void DeadLock()
{
Py_Initialize();
PyEval_InitThreads();
g_AiGlobals = new Py::Dict();
g_pyInterpState = PyInterpreterState_New();
// save a pointer to the main PyThreadState object
g_pyMainThreadState = PyThreadState_Get();
ASSERT_KOBOLD( g_pyMainThreadState );
// release the lock
PyEval_ReleaseLock();
g_pyWorldThreadState = InitThreadScripting();
// import sys
// sys.path.append ("./scripts")
//
PyObject*p = PyImport_ImportModuleEx ("sys", **g_AiGlobals, NULL, NULL);
Py::Module mod_sys (p);
Py::Listpath = mod_sys.getAttr ("path");
path.append (Py::String ("scripts"));
path.append (Py::String ("scripts/sys"));
path.append (Py::String ("../../scripts"));
path.append (Py::String ("../../scripts/sys"));
Py_XDECREF (p);
// HERE IT OCCURS //
Log.ScriptsSrc("Python", "Running startup python scripts...");
PyObject *p = PyImport_ImportModuleEx ("startup", **g_AiGlobals, NULL,
NULL); // <<< Here
if (reload) PyImport_ReloadModule (p);
Py::Module module (p);
Py_XDECREF (p);
}
Execution locks right on PyImport_ImportModuleEx.
Code from sturtup.py:
# This module is sturtup script.
# Here we are redirecting output and checking for server version.
import sys
from consts import * # Import of constants
import config as cfg # Import of configuration constants
reload(cfg)
#
-
[ python-Bugs-1736103 ] Mac build fails if not building universal due to libtool
Bugs item #1736103, was opened at 2007-06-12 23:12
Message generated for change (Comment added) made by jackjansen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736103&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Jack Jansen (jackjansen)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Mac build fails if not building universal due to libtool
Initial Comment:
If you try to build the svn trunk without universalsdk the make will fail: the
Makefile tries to use libtool to create the shared library, but on (unmodified)
OSX it should use glibtool.
I have no idea who to assign this to, I hope you have a bettter idea.
--
>Comment By: Jack Jansen (jackjansen)
Date: 2007-07-09 22:57
Message:
Logged In: YES
user_id=45365
Originator: YES
Tried it again ("../configure --enable-framework" on an Intel mac) and the
problem does not occur. Assume the last time it was a pilot error, sorry!
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-09 09:52
Message:
Logged In: YES
user_id=580910
Originator: NO
Which configure arguments are you using? Are you building a framework or
a plain unix install?
IMHO the call to libtool in Makefile.pre.in is correct, but that's only
used when building a framework. The call to libtool is supposed to be a
call to Apple's libtool, not the GNU tool with the same name.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736103&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1694950 ] Bad documentation of SMTPException
Bugs item #1694950, was opened at 2007-04-05 21:48 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694950&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed Resolution: None Priority: 2 Private: No Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Bad documentation of SMTPException Initial Comment: The documentation of the SMTP object http://docs.python.org/lib/SMTP-objects.html lists "SMTPError" as a possible exception. It should be "SMTPException" instead of "SMTPError". Also, the "SMTPAuthenticationError" needs to be listed on the first page of the smtlib documentation http://docs.python.org/lib/module-smtplib.html -- >Comment By: George Yoshida (quiver) Date: 2007-07-10 10:55 Message: Logged In: YES user_id=671362 Originator: NO > "SMTPException" instead of "SMTPError". This one was fixed in r53370. > the "SMTPAuthenticationError" needs to be listed This one was fixed in r56129. You can check them in development version documentation. http://docs.python.org/dev/lib/module-smtplib.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694950&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1738559 ] Python-2.5.1.tar.bz2 build failed at Centos-4.5 server
Bugs item #1738559, was opened at 2007-06-17 15:29 Message generated for change (Comment added) made by dhuang You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shuvo (shuvo1470) Assigned to: Nobody/Anonymous (nobody) Summary: Python-2.5.1.tar.bz2 build failed at Centos-4.5 server Initial Comment: I tried to build Python-2.5.1.tar.bz2 at my Centos-4.5 server but unable to build it. there is the error i am getting File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ChipViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TypeinViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/pyColorChooser.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Main.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TextViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ColorDB.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/StripViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/DetailsViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ListViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/PyncheWidget.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Switchboard.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/__init__.pyo -- Comment By: David Huang (dhuang) Date: 2007-07-10 11:48 Message: Logged In: YES user_id=97663 Originator: NO I've just installed this package on 2 CentOS 4.5 Server without any problem. -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-23 19:37 Message: Logged In: YES user_id=21627 Originator: NO Please report the first errors; the errors you show are likely follow-up errors. If possible, attach the entire build output as a compressed file to this report. -- Comment By: shuvo (shuvo1470) Date: 2007-06-20 21:02 Message: Logged In: YES user_id=1819895 Originator: YES No. These are last error messages while exiting build process. -- Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 20:41 Message: Logged In: YES user_id=849994 Originator: NO Are these the first error messages in the build process? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1738559 ] Python-2.5.1.tar.bz2 build failed at Centos-4.5 server
Bugs item #1738559, was opened at 2007-06-17 09:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: shuvo (shuvo1470) Assigned to: Nobody/Anonymous (nobody) Summary: Python-2.5.1.tar.bz2 build failed at Centos-4.5 server Initial Comment: I tried to build Python-2.5.1.tar.bz2 at my Centos-4.5 server but unable to build it. there is the error i am getting File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ChipViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TypeinViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/pyColorChooser.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Main.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TextViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ColorDB.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/StripViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/DetailsViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ListViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/PyncheWidget.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Switchboard.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/__init__.pyo -- >Comment By: Martin v. Löwis (loewis) Date: 2007-07-10 07:36 Message: Logged In: YES user_id=21627 Originator: NO Closing as "fixed" then. -- Comment By: David Huang (dhuang) Date: 2007-07-10 05:48 Message: Logged In: YES user_id=97663 Originator: NO I've just installed this package on 2 CentOS 4.5 Server without any problem. -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-23 13:37 Message: Logged In: YES user_id=21627 Originator: NO Please report the first errors; the errors you show are likely follow-up errors. If possible, attach the entire build output as a compressed file to this report. -- Comment By: shuvo (shuvo1470) Date: 2007-06-20 15:02 Message: Logged In: YES user_id=1819895 Originator: YES No. These are last error messages while exiting build process. -- Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 14:41 Message: Logged In: YES user_id=849994 Originator: NO Are these the first error messages in the build process? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
