[ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Bugs item #1183780, was opened at 2005-04-15 16:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&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.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 09:16 Message: Logged In: YES user_id=21627 Committed as 43286. I also added .cmd to Popen4. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 08:56 Message: Logged In: YES user_id=33168 It makes sense to remove from _active on ECHILD. I wondered the same thing about waitpid(), but left it as it was. I don't believe it's possible for waitpid to return any pid other than what you ask for unless the O/S is very, very broken. This patch is fine with me, feel free to check it in. BTW, nice comments and precondition checks in the test. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 08:40 Message: Logged In: YES user_id=21627 This looks all fine. As a further issue, I think _cleanup should also clean processes which already have been waited on. So if waitpid gives ECHILD (in _cleanup), I think the object should get removed from _active - otherwise, it would stay there forever. Of course, care is then need to avoid __del__ adding it back to _active. Putting these all together, I propose v3 of the patch. Another aspect that puzzles me is the repeated test that waitpid() really returns the pid you asked for. How could it not? If it fails, you get an os.error. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 06:17 Message: Logged In: YES user_id=33168 I agree with your comment about setting self.sts to 0. That was the problem I alluded to on python-dev. Although I dislike __del__, this does seem like an appropriate place to do the modification of _active. Note that currently all os.error's are swallowed in poll(). I'm not sure if that was the best idea, but that's the current interface. wait() does *not* catch any exceptions. I wasn't really sure what to do about threads. The threads could always manage their calls into a popen object like you propose (don't try to handle simultaneous calls to poll and wait). Another question I had was if popen should be deprecated in favor of subprocess? I've attached a patch which I think implements your suggestion. It also seems to fix all the problems. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 01:37 Message: Logged In: YES user_id=21627 I don't understand why you are setting self.sts to 0 if wait fails: most likely, there was a simultaneous call to .poll, which should have set self.sts to the real return value. So we should return that instead. I think the whole issue can be avoid if we use resurrection: If __del__ would put unwaited objects into _active, rather than __init__, it would not happen that _cleanup polls a pid which a thread still intends to wait for. In fact, it would be sufficient to only put the pid into _active (
[ python-Bugs-1456470 ] sliceobject ssize_t (and index) not completed
Bugs item #1456470, was opened at 2006-03-22 23:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Jim Jewett (jimjjewett) Assigned to: Martin v. Löwis (loewis) Summary: sliceobject ssize_t (and index) not completed Initial Comment: sliceobject and ceval changed the parameter types of slice objects to ssize_t, but the code still requires an int (sometimes not even a long); it should use the new __index__ slot; at the very least, it should be consistent about what it does accept. In http://svn.python.org/view/python/trunk/Objects/ sliceobject.c?rev=42382&view=markup [issue 1] function PySlice_GetIndices takes Py_ssize_t parameters for (length, start, stop, step) but then does a PyInt_Check on each of start, stop, step. (An XXX to allow longs was also removed.) It * should* use the new __index__ slot. [issue 2] Later in the same file, function slice_ indices takes a PyObject len parameter, but then uses PyInt_AsLong rather than __index__ (or even PyInt_ AsSsize_t) to create Py_ssize_t ilen. [issue 3] http://svn.python.org/view/python/trunk/Python/ceval.c? rev=42382&view=markup function _PyEval_SliceIndex accepts only ints and longs, and longs will be converted to ints with clipping. It should allow anything with __index__, and clip only to ssize_t rather than int. [issue 4] ISINT still insists on int or long -- I thought I saw a fix for this already in the index patches. [issue 5] apply_slice and assign_slice changed the types of ilow and ihigh, but still initializes them to INT_MAX rather than ssize_t max. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 09:33 Message: Logged In: YES user_id=21627 Would you like to work on a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457783 ] Malloc error on MacOSX/imaplib
Bugs item #1457783, was opened at 2006-03-24 10:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457783&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 Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: Malloc error on MacOSX/imaplib Initial Comment: I am using Python 2.4.2 on MacOSX (10.4.5). Fetching mails with larger attachments (2MB or so) using IMAP (with getmail) fails: python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) m
[ python-Bugs-1457823 ] cgi.FormContentDict constructor should support parse options
Bugs item #1457823, was opened at 2006-03-25 01:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457823&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: None Status: Open Resolution: None Priority: 5 Submitted By: John Belmonte (jbelmonte) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FormContentDict constructor should support parse options Initial Comment: cgi.FormContentDict (and cgi.SvFormContentDict) should take optional keep_blank_values and strict_parsing args and pass them on to cgi.parse(). In my use case neither of the parse defaults is what I want, so I'm faced with having to hack or re-implement SvFormContentDict. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457823&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457264 ] urllib.splithost parses incorrectly
Bugs item #1457264, was opened at 2006-03-23 20:49
Message generated for change (Comment added) made by onlynone
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457264&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve (onlynone)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.splithost parses incorrectly
Initial Comment:
urllib.splithost(url) requires that the url passed in
be of the form '//host[:port]/path'. Yet I've run
across some urls that are of the form
'//host[:port]?querystring'. This causes splithost to
return everything as the host and nothing as the path.
Section 3.2 of rfc2396 (Uniform Resource Identifiers:
Generic Syntax) states that 'The authority component is
preceded by a double slash "//" and is terminated by
the next slash "/", question-mark "?", or by the end of
the URI.'
Also, this is how it defines a URI:
absoluteURI = scheme ":" ( hier_part | opaque_part )
hier_part = ( net_path | abs_path ) [ "?" query ]
net_path = "//" authority [ abs_path ]
abs_path = "/" path_segments
Based on the above, you could certainly have:
'http://authority?query' as a valid url.
In python2.3 you would just need to change line 939 in
urllib.py from:
_hostprog = re.compile('^//([^/]*)(.*)$')
to:
_hostprog = re.compile('^//([^/?]*)(.*)$')
This appears to affect all python versions, I just
happened to be using 2.3.
--
>Comment By: Steve (onlynone)
Date: 2006-03-24 17:12
Message:
Logged In: YES
user_id=126
The problem I was having specifically was that the url had a
colon in the query string. Since the query string was being
parsed as part of the host, the text after the colon was
being treated as the port when urllib.splitport was called
later. The following is a simple testcase:
import urllib2
webpage = urllib2.urlopen("http://host.com?a=b:3b";)
You will then get a "httplib.InvalidURL: nonnumeric port: '3b'"
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457264&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457470 ] regs attribute on regex objects not documented
Bugs item #1457470, was opened at 2006-03-24 01:41 Message generated for change (Comment added) made by jlowery2006 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457470&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Lowery (jlowery2006) Assigned to: Nobody/Anonymous (nobody) Summary: regs attribute on regex objects not documented Initial Comment: Came across the use of .regs attribute in the tools/scripts/classfix.py program (line 162), but it's not an attribute that's documented in the Python Library Reference. -- >Comment By: Jeff Lowery (jlowery2006) Date: 2006-03-24 19:21 Message: Logged In: YES user_id=1484419 It was pointed out to me on the comp.lang.python list that regs is part of the now-defunction regex package. Perhaps it would be possible to denote the module as deprecated in the regex.py code? Dunno, but I do know that PyLint didn't pick up on it as being deprecated. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457470&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1458017 ] Log._log needs to be more forgiving...
Bugs item #1458017, was opened at 2006-03-24 15:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&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: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Log._log needs to be more forgiving... Initial Comment: The _log method of distutils' Log class executes print msg % args where args might be an empty tuple (the methods that call _log all have varargs signatures). If that's the case and msg happens to contain a % sign, it barfs. It should be more forgiving, for instance: def _log(self, level, msg, args): if level >= self.threshold: try: print msg % args except TypeError: if not args: print msg else: raise sys.stdout.flush() I just corrected this locally for our 2.3 and 2.4 installations. The above is a bit ugly, but it does allow the common case (msg contains a % but an empty args list) to pass while still catching most programmer errors. Distutils is trying to log this message (wrapped): gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/opt/app/mysql-5.0.19/include -I/opt/app/mysql-5.0.19/include -I/opt/lang/python/include/python2.3 -c _mysql.c -o build/temp.solaris-2.8-i86pc-2.3/_mysql.o -I/opt/app/mysql-5.0.19/include -xO3 -mt -fsimple=1 -ftrap=%none -nofstore -xbuiltin=%all -xlibmil -xlibmopt -xtarget=generic I suppose it would be better if all the places in distutils which log compiler commands without extra args escaped their % signs. This seems like an acceptable compromise though. Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-892939 ] Race condition in popen2
Bugs item #892939, was opened at 2004-02-08 09:31 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892939&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.3 >Status: Pending >Resolution: Fixed Priority: 6 Submitted By: Ken McNeil (kenmcneil) Assigned to: Neal Norwitz (nnorwitz) Summary: Race condition in popen2 Initial Comment: The "fix" for bug #761888 created a race condition in Popen3 . The interaction between wait and _cleanup is the root of the problem. def wait(self): """Wait for and return the exit status of the child process.""" if self.sts < 0: pid, sts = os.waitpid(self.pid, 0) if pid == self.pid: self.sts = sts return self.sts def _cleanup(): for inst in _active[:]: inst.poll() In wait, between the check of self.sts and the call to os.waitpid a new Popen3 object can be created in another thread which will trigger a call to _cleanup. Since the call to _cleanup polls the process, when the thread running wait starts back up again it will try to poll the process using os.waitpid, which will throw an OSError because os.waitpid has already been called for the PID indirectly in _cleanup. A work around is for the caller of wait to catch the OSError and check the sts field, and if sts is non-negative then the OSError is most likely because of this problem and can be ignored. However, sts is undocumented and should probably stay that way. My suggestion is that the patch that added _active, _cleanup, and all be removed and a more suitable mechanism for fixing bug #761888 be found. As it has been said in the discussion of bug #761888, magically closing FDs is not a "good thing". It seems to me that surrounding the call to os.fork with a try/except, and closing the pipes in the except, would be suitable but I don't know how this would interact with a failed call to fork, therefore I wont provide a patch. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 20:56 Message: Logged In: YES user_id=33168 Martin and I worked out a patch which should solve this problem and it was committed. For more info see bug 1183780, If this does not solve the problem, change the status from pending to open. Otherwise, this bug report should close automatically in a couple of weeks since it's pending. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 00:47 Message: Logged In: YES user_id=33168 I believe this is basically a duplicate of 1183780. There is a patch attached there. Can you verify if it fixes your problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892939&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-998246 ] Popen3.poll race condition
Bugs item #998246, was opened at 2004-07-26 12:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&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: None >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Tres Seaver (tseaver) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen3.poll race condition Initial Comment: poll() swallows all IOErrors, including ENOCHILD; if the child process exits before poll is called, then an applications which loops on poll() will never exit. I am working around this (against Python 2.3.3) via the following: try: pid, status = os.waitpid(proc.pid, os.WNOHANG) except os.error, e: if e.errno == 10: # ENOCHILD result = 0 else: raise else: if pid == proc.pid: result = status where 'proc' is an instance of Popen3. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 20:59 Message: Logged In: YES user_id=33168 Tres, Martin and I worked out a patch that we thinks solves the problem. It's checked in. See the other bug report for more info. If you don't believe the patch will fix your problem, change the status from pending to open. Otherwise, this bug should automatically close in a couple of weeks. -- Comment By: Tres Seaver (tseaver) Date: 2006-03-23 04:21 Message: Logged In: YES user_id=127625 1183780 is indeed a similar bug, although he reports it against Popen4 rather than Popen3. His patch needs to be modified to re-raise errors which are not ENOCHILD, however. I no longer have accees to either the application or the machine where I found this issue, and hence can't verify that the patch fixes the code which triggered the problem. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 00:45 Message: Logged In: YES user_id=33168 I believe this is basically a duplicate of 1183780. There is a patch attached there. Can you verify if it fixes your problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1033390 ] build doesn't pick up bsddb w/Mandrake 9.2
Bugs item #1033390, was opened at 2004-09-23 06:58 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033390&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.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Neal Norwitz (nnorwitz) Summary: build doesn't pick up bsddb w/Mandrake 9.2 Initial Comment: Mandrake 9.2 installs bsddb 4.1 under /usr/lib, and apparently Python 2.4a3's setup.py doesn't pick it up -- adding /usr/lib to the list of directories where bsddb 4 is being searched for, and rerunning make, seems to fix the problem. (Problem does not appear on Mandrake 9.1, where I had installed sleepycat's stuff under /usr/local/BerkeleyDB.4.1 "by hand"; nor on MacOSX, where I had a fink-installed one in /sw/lib; no similar problem with any other module on any of these platforms, except bsddb). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 22:10 Message: Logged In: YES user_id=33168 Alex? I suspect this isn't a problem any longer. If we don't hear back within a month, we'll close this report. -- Comment By: Gregory P. Smith (greg) Date: 2004-12-13 04:15 Message: Logged In: YES user_id=413 Could you try this again using python CVS HEAD. I just committed a rework of setup.py's bsddb library+include file finding code that hopefully does the right thing for you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033390&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
