You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Gregory (Grisha) Trubetskoy" <gr...@apache.org> on 2003/10/15 05:35:36 UTC
Please help test on 3.1.1b
You can get the sneak preview of 3.1.1 beta here:
http://www.modpython.org/tmp/3.1.1b/
Please download it, then do the usual
$ ./configure --with-apxs=/wherever/it/is
$ make
$ (su)
# make install
Then
$ cd test
$ python test.py
And see if any tests fail. I have tested this on FreeBSD 4.8 and OS X
10.2.8, but not on Linux, as my Linux box is dead ATM. Also Solaris would
be nice... (as well as Panther, if you have it).
Also, Windows folks - please make sure that this binary isn't screwed
like the last one. This one I think _really_ works with 2.3 :-)
Please respond to the list with your results ASAP so we can announce this
puppy!
Thank you very much,
Grisha
Re: [REPEAT] Please help test 3.1.1b
Posted by Barry Pederson <bp...@barryp.org>.
Gregory (Grisha) Trubetskoy wrote:
>>After that, it still wouldn't run the tests, the logs/error_log showed:
>>----------
>>[Wed Oct 15 16:23:41 2003] [alert] (2)No such file or directory: getpwuid:
>>couldn't determine user name from uid 4294967295, you probably need to modify
>>the User directive
>>-----------
>
>
> Were you running tests as root? (I usually don't)
If I run the tests under the same non-root userid I built mod-python, and
tweak test.py to find the DSOs in the right place, it still dies with the error:
[emerg] (2)No such file or directory: Couldn't create accept lock
I did try running as root to see if that helped, being closer to how Apache
normally starts - and got those other errors.
---------
By default, at least on this box, the Apache "LockFile" is
/var/run/accept.lock.{pid}, which my non-root userid didn't have permission
to create. If I tweak the permissions on /var/run then it works OK.
Maybe the test harness should specify a different LockFile, somewhere where
it's sure it has write permissions. I tried adding a "LockFile" class to
test/httpdconf.py, and slipped in a: LockFile("logs/accept.lock")
into test/test.py, and the tests ran OK without requiring different
permissions on /var/run, and without requiring a "User" or "Group" directive
in apache config (although I still think it'd be good to be able to test with
those directives, starting as root).
You shouldn't have to do the "make install" to run the tests, should you?
I'd suggest adding another target to the Makefile like:
---------
test_modpy:
cd test && python test.py
----------
Then your testing instructions could be:
./configure
make
make test_modpy
su
make install
--------------
I wonder if there would be a conflict between the session database file that
may exist from a preexisting mod_python instance (in /tmp I guess), and one
that may exist because you're running the tests. "SessionDbm" should
probably be specified in the tests too, instead of using the default filename.
Barry
Re: [REPEAT] Please help test 3.1.1b
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Wed, 15 Oct 2003, Barry Pederson wrote:
> # where other modules might be
> modpath = os.path.split(os.path.split(HTTPD)[0])[0]
> modpath = os.path.join(modpath, "modules")
>
> That resulted in modpath being set to '/usr/local/modules', which was
> incorrect. I replaced that with this and got a better result:
>
> modpath = os.popen('apxs -q LIBEXECDIR', 'r').read().strip()
cool
>
> After that, it still wouldn't run the tests, the logs/error_log showed:
> ----------
> [Wed Oct 15 16:23:41 2003] [alert] (2)No such file or directory: getpwuid:
> couldn't determine user name from uid 4294967295, you probably need to modify
> the User directive
> -----------
Were you running tests as root? (I usually don't)
Grisha
RE: [REPEAT] Please help test 3.1.1b
Posted by Sean Treadway <se...@superchannel.org>.
Maybe a little bit late, and I haven't had a chance to test this, but
the debian package apache2-dev installs apxs as /usr/bin/apxs2 so the
following command to find the module directory will fail on a recent
debian system. A kludge would be to check the results and if it fails,
try apxs2 as well.
The results of "apxs2 -q LIBEXECDIR" on my debian system is:
"/usr/lib/apache2/modules"
-Sean
> That resulted in modpath being set to '/usr/local/modules', which was
> incorrect. I replaced that with this and got a better result:
>
> modpath = os.popen('apxs -q LIBEXECDIR', 'r').read().strip()
Re: [REPEAT] Please help test 3.1.1b
Posted by Barry Pederson <bp...@barryp.org>.
Gregory (Grisha) Trubetskoy wrote:
> I think I didn't make it clear in the last message:
>
> In order for this release to be officially announced, at least a few
> people on this list need to try it and send in a +1 indicating that it
> worked on their system (along with some desciption of what their system
> is). *Anyone* on this list can do this, you don't have to be an official
> committer or anything of that sort.
>
> Doing a test could probably take as little as 10 minutes, and I'd
> encourage you to do it sooner than later.
>
> Looking at the www.modpython.org log we've only had one download of the
> tgz file so far, which isn't encouraging :-)
>
> Grisha
>
> On Tue, 14 Oct 2003, Gregory (Grisha) Trubetskoy wrote:
>
>
>>You can get the sneak preview of 3.1.1 beta here:
>>
>>http://www.modpython.org/tmp/3.1.1b/
>>
>>Please download it, then do the usual
>>
>>$ ./configure --with-apxs=/wherever/it/is
>>$ make
>>$ (su)
>># make install
>>
>>Then
>>
>>$ cd test
>>$ python test.py
>>
>>And see if any tests fail. I have tested this on FreeBSD 4.8 and OS X
>>10.2.8, but not on Linux, as my Linux box is dead ATM. Also Solaris would
>>be nice... (as well as Panther, if you have it).
I gave it a try on a FreeBSD 4.8 box with Apache 2.0.47 and Python 2.3.2
installed from the ports. mod_python itself seems ok, but the unittests gave
me trouble.
First, in test/test.py this section guessed wrong about where my DSOs were:
# where other modules might be
modpath = os.path.split(os.path.split(HTTPD)[0])[0]
modpath = os.path.join(modpath, "modules")
That resulted in modpath being set to '/usr/local/modules', which was
incorrect. I replaced that with this and got a better result:
modpath = os.popen('apxs -q LIBEXECDIR', 'r').read().strip()
After that, it still wouldn't run the tests, the logs/error_log showed:
----------
[Wed Oct 15 16:23:41 2003] [alert] (2)No such file or directory: getpwuid:
couldn't determine user name from uid 4294967295, you probably need to modify
the User directive
-----------
I patched test/httpdconf.py to allow for "User" and "Group" directives to be
added:
--- httpdconf.py.original Wed Oct 15 16:24:55 2003
+++ httpdconf.py Wed Oct 15 16:25:56 2003
@@ -147,6 +147,10 @@
def __init__(self, val):
Directive.__init__(self, self.__class__.__name__, val)
+class Group(Directive):
+ def __init__(self, val):
+ Directive.__init__(self, self.__class__.__name__, val)
+
class IfModule(ContainerTag):
def __init__(self, dir, *args):
ContainerTag.__init__(self, self.__class__.__name__, dir, args)
@@ -291,6 +295,9 @@
def __init__(self, addr, *args):
ContainerTag.__init__(self, self.__class__.__name__, addr, args)
+class User(Directive):
+ def __init__(self, val):
+ Directive.__init__(self, self.__class__.__name__, val)
and then hardcoded in some calls to set those in test/test.py:
--- test.py.original Wed Oct 15 16:26:24 2003
+++ test.py Wed Oct 15 16:26:56 2003
@@ -255,6 +254,8 @@
LoadModule("dir_module %s" %
quoteIfSpace(os.path.join(modpath,
"mod_dir.so")))),
ServerRoot(SERVER_ROOT),
+ User('www'),
+ Group('www'),
ErrorLog("logs/error_log"),
LogLevel("debug"),
LogFormat(r'"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-Agent}i\"" combined'),
Not sure how that should be put in in a non-hardwired fashion, but I'd think
it'd be important to be able to test using other userids/groups, since it
caused trouble before with the mutex creation/graceful restarts/cleanup (was
fixed back in August).
After that, the unittests ran and passed OK. I'll see about trying it on a
FreeBSD 5.1 box later.
Barry
Re: [REPEAT] Please help test 3.1.1b
Posted by James Pye <fl...@rhid.com>.
Greets,
Another correction: just played with it a bit, and python couldn't find the psp module as I ran the test without having mod_python3.1 installed.
After installing it, the test completed successfully. Sorry for the noise. :)
Regards,
James Pye
Re: [REPEAT] Please help test 3.1.1b
Posted by James Pye <fl...@rhid.com>.
Greets,
Sorry about the last report, I just doubled kern.maxfiles(to 4096), and it passed that test, but failed on some cookies parsing, so here is a more useful error:
.
* Testing | .ext syntax
.
* Testing mod_python.cgihandler
.
* Testing mod_python.psp
F
* Testing Cookie.Cookie
F
* Testing Cookie.MarshalCookie
F
* Testing Session.Session
F
* Testing internally (status messages go to error_log)
.
======================================================================
FAIL: test_psphandler (__main__.PerRequestTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test.py", line 875, in test_psphandler
self.fail("test failed")
File "/usr/local/lib/python2.3/unittest.py", line 270, in fail
raise self.failureException, msg
AssertionError: test failed
======================================================================
FAIL: test_Cookie_Cookie (__main__.PerRequestTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test.py", line 906, in test_Cookie_Cookie
self.fail("cookie parsing failed")
File "/usr/local/lib/python2.3/unittest.py", line 270, in fail
raise self.failureException, msg
AssertionError: cookie parsing failed
======================================================================
FAIL: test_Cookie_MarshalCookie (__main__.PerRequestTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test.py", line 936, in test_Cookie_MarshalCookie
self.fail("cookie parsing failed")
File "/usr/local/lib/python2.3/unittest.py", line 270, in fail
raise self.failureException, msg
AssertionError: cookie parsing failed
======================================================================
FAIL: test_Session_Session (__main__.PerRequestTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test.py", line 963, in test_Session_Session
self.fail("session did not set a cookie")
File "/usr/local/lib/python2.3/unittest.py", line 270, in fail
raise self.failureException, msg
AssertionError: session did not set a cookie
----------------------------------------------------------------------
Ran 25 tests in 8.368s
FAILED (failures=4)
F Stopping Apache...
/usr/local/sbin/httpd -k stop -f /void/users/flaw/src/mod_python-3.1.1b/test/conf/test.conf
======================================================================
FAIL: testPerRequestTests (__main__.PerInstanceTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test.py", line 1074, in testPerRequestTests
self.failUnless(result.wasSuccessful())
File "/usr/local/lib/python2.3/unittest.py", line 278, in failUnless
if not expr: raise self.failureException, msg
AssertionError
----------------------------------------------------------------------
Ran 4 tests in 28.229s
FAILED (failures=1)
Access log and error log are attached this time..
regards,
James Pye
Re: [REPEAT] Please help test 3.1.1b
Posted by Oden Eriksson <od...@kvikkjokk.net>.
onsdagen den 15 oktober 2003 22.09 skrev Gregory (Grisha) Trubetskoy:
> Thanks Ville.
>
> Your kernel.sem says you have 128 semaphores, of which 6 must be used for
> something else as mod_python choked on the 122-nd...
>
> What produces the fatal error though, is not mod_python, but mod_rewrite.
> I thought I fixed this problem by freeing one semaphore if we stumble on
> trying to allocate them, but it obviously didn't work. Either something
> else needs a semaphore (and mod_python should try to free a couple
> instead of just one), or the freeing doesn't work like I thought it
> should...
>
> BTW "no space left" really means "no more semaphores". Don't know if this
> is a Linux-specific thing or on all of Sys V IPC, but it's rather
> unintuitive :-)
This a problem, well to many people it seems.
http://qa.mandrakesoft.com/show_bug.cgi?id=5629
Re: [REPEAT] Please help test 3.1.1b
Posted by Ville Skyttä <vi...@iki.fi>.
On Wed, 2003-10-15 at 23:09, Gregory (Grisha) Trubetskoy wrote:
> Your kernel.sem says you have 128 semaphores, of which 6 must be used for
> something else as mod_python choked on the 122-nd...
Ok, after bumping the number of semaphores, Apache starts and all tests
run fine.
While at it, I added support for staged installs using DESTDIR, see the
attachment.
BTW, RELEASE in Doc/Makefile.in should probably be bumped.
Re: [REPEAT] Please help test 3.1.1b
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Thanks Ville.
Your kernel.sem says you have 128 semaphores, of which 6 must be used for
something else as mod_python choked on the 122-nd...
What produces the fatal error though, is not mod_python, but mod_rewrite.
I thought I fixed this problem by freeing one semaphore if we stumble on
trying to allocate them, but it obviously didn't work. Either something
else needs a semaphore (and mod_python should try to free a couple
instead of just one), or the freeing doesn't work like I thought it
should...
BTW "no space left" really means "no more semaphores". Don't know if this
is a Linux-specific thing or on all of Sys V IPC, but it's rather
unintuitive :-)
Grisha
On Wed, 15 Oct 2003, Ville [ISO-8859-1] Skytt? wrote:
> On Wed, 2003-10-15 at 21:58, Gregory (Grisha) Trubetskoy wrote:
>
> > In order for this release to be officially announced, at least a few
> > people on this list need to try it and send in a +1 indicating that it
> > worked on their system (along with some desciption of what their system
> > is). *Anyone* on this list can do this, you don't have to be an official
> > committer or anything of that sort.
>
> I'm afraid I'll have to send you a -1 :(
>
> System: Red Hat Linux 9 (i386) up to date with latest errata, Apache
> 2.0.40 (httpd-2.0.40-21.5), Python 2.2.2 (python-2.2.2-26).
>
> Compiling went fine, but trying to start Apache spits this into the
> error log and fails:
>
> -----
> [Wed Oct 15 22:33:15 2003] [notice] mod_python: Creating 150 session mutexes based on 150 max processes and 0 max threads.
> [Wed Oct 15 22:33:15 2003] [error] (28)No space left on device: mod_python: Failed to create global mutex 122 of 150 (/tmp/mpmtx29532122).
> [Wed Oct 15 22:33:15 2003] [error] mod_python: We can probably continue, but with diminished ability to process session locks.
> [Wed Oct 15 22:33:15 2003] [error] mod_python: Hint: On Linux, the problem may be the number of available semaphores, check 'sysctl kernel.sem'
> [Wed Oct 15 22:33:15 2003] [notice] Digest: generating secret for digest authentication ...
> [Wed Oct 15 22:33:15 2003] [notice] Digest: done
> [Wed Oct 15 22:33:16 2003] [crit] (28)No space left on device: mod_rewrite: could not create rewrite_log_lock
> Configuration Failed!
> -----
>
> # /sbin/sysctl kernel.sem
> kernel.sem = 250 32000 32 128
>
> Running out of disk space (the "No space left on device" error) isn't
> probably an issue, all partitions have plenty of space.
>
> Note that I updated the latest Red Hat Rawhide source RPM to 3.1.1b and
> tried with it. It includes a couple of patches, attached in case you
> find them useful.
>
>
[REPEAT] Please help test 3.1.1b
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
I think I didn't make it clear in the last message:
In order for this release to be officially announced, at least a few
people on this list need to try it and send in a +1 indicating that it
worked on their system (along with some desciption of what their system
is). *Anyone* on this list can do this, you don't have to be an official
committer or anything of that sort.
Doing a test could probably take as little as 10 minutes, and I'd
encourage you to do it sooner than later.
Looking at the www.modpython.org log we've only had one download of the
tgz file so far, which isn't encouraging :-)
Grisha
On Tue, 14 Oct 2003, Gregory (Grisha) Trubetskoy wrote:
>
> You can get the sneak preview of 3.1.1 beta here:
>
> http://www.modpython.org/tmp/3.1.1b/
>
> Please download it, then do the usual
>
> $ ./configure --with-apxs=/wherever/it/is
> $ make
> $ (su)
> # make install
>
> Then
>
> $ cd test
> $ python test.py
>
> And see if any tests fail. I have tested this on FreeBSD 4.8 and OS X
> 10.2.8, but not on Linux, as my Linux box is dead ATM. Also Solaris would
> be nice... (as well as Panther, if you have it).
>
> Also, Windows folks - please make sure that this binary isn't screwed
> like the last one. This one I think _really_ works with 2.3 :-)
>
> Please respond to the list with your results ASAP so we can announce this
> puppy!
>
> Thank you very much,
>
> Grisha
>
Re: Please help test on 3.1.1b
Posted by James Pye <fl...@rhid.com>.
Greets,
Here is my run of test.py..
System:
FreeBSD void 4.9-RC FreeBSD 4.9-RC #4: Fri Oct 3 00:03:34 MST 2003 root@void:/usr/src/sys/compile/void i386
Apache:
Server version: Apache/2.0.47
Server built: Oct 15 2003 20:57:44
Server's Module Magic Number: 20020903:4
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_FLOCK_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/usr/local"
-D SUEXEC_BIN="/usr/local/bin/suexec"
-D DEFAULT_PIDLOG="/var/run/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="/var/run/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="etc/apache2/mime.types"
-D SERVER_CONFIG_FILE="etc/apache2/httpd.conf"
First Problems with test.py:
I had the same issues with the missing User and LockFile directives, and I'm not running as root. And also, a minor location assumption of apache modules being at /usr/local/modules, I just symlinked to the location on my disk..
After that, the test ran, but failed with:
* Testing LoadModule
Creating config....
listen port: 1528
Starting Apache....
/usr/local/sbin/httpd -k start -f /void/users/flaw/src/mod_python-3.1.1b/test/conf/test.conf
Stopping Apache...
/usr/local/sbin/httpd -k stop -f /void/users/flaw/src/mod_python-3.1.1b/test/conf/test.conf
.
* Testing server.register_cleanup()...
Creating config....
listen port: 1532
Starting Apache....
/usr/local/sbin/httpd -k start -f /void/users/flaw/src/mod_python-3.1.1b/test/conf/test.conf
Stopping Apache...
/usr/local/sbin/httpd -k stop -f /void/users/flaw/src/mod_python-3.1.1b/test/conf/test.conf
Fatal error 'Cannot create pthread kernel pipe for forked process' at line ? in file /usr/src/lib/libc_r/uthread/uthread_fork.c (errno = ?)
E
* Testing _global_lock
Creating config....
EE
* Running the per-request test suite...
EE
======================================================================
ERROR: test_srv_register_cleanup (__main__.PerInstanceTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test.py", line 1099, in test_srv_register_cleanup
IOError: [Errno 23] Too many open files in system: '/void/users/flaw/src/mod_python-3.1.1b/test/logs/error_log'
======================================================================
ERROR: test_global_lock (__main__.PerInstanceTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test.py", line 1008, in test_global_lock
File "test.py", line 219, in makeConfig
File "test.py", line 210, in checkFiles
File "/usr/local/lib/python2.3/shutil.py", line 140, in rmtree
OSError: [Errno 23] Too many open files in system removing /void/users/flaw/src/mod_python-3.1.1b/test/logs
access log:
127.0.0.1 - - [15/Oct/2003:22:54:16 -0700] "GET /tests.py HTTP/1.0" 200 48 "-" "Python-urllib/1.15"
error log:
[Wed Oct 15 22:54:15 2003] [notice] mod_python: Creating 256 session mutexes based on 256
max processes and 0 max threads.
[Wed Oct 15 22:54:15 2003] [notice] Apache/2.0.47 (Unix) mod_python/3.1.1b Python/2.3.2 co
nfigured -- resuming normal operations
[Wed Oct 15 22:54:15 2003] [info] Server built: Oct 15 2003 20:57:44
[Wed Oct 15 22:54:15 2003] [debug] prefork.c(1037): AcceptMutex: flock (default: flock)
[Wed Oct 15 22:54:16 2003] [notice] mod_python: (Re)importing module 'tests'
(23)Too many open files in system: mod_python: Failed to reinit global mutex /tmp/mpmtx813
53122.
(23)Too many open files in system: mod_python: Failed to reinit global mutex /tmp/mpmtx813
53201.
[Wed Oct 15 22:54:45 2003] [error] [client 127.0.0.1] test ok
[Wed Oct 15 22:54:45 2003] [warn] child process 81354 still did not exit, sending a SIGTER
M
[Wed Oct 15 22:54:45 2003] [warn] child process 81356 still did not exit, sending a SIGTER
M
[Wed Oct 15 22:54:45 2003] [warn] child process 81357 still did not exit, sending a SIGTER
M
[Wed Oct 15 22:54:45 2003] [warn] child process 81359 still did not exit, sending a SIGTER
M
[Wed Oct 15 22:54:46 2003] [info] removed PID file /void/users/flaw/src/mod_python-3.1.1b/
test/logs/httpd.pid (pid=81353)
[Wed Oct 15 22:54:46 2003] [notice] caught SIGTERM, shutting down
After all of that, I had to killall httpd. I couldn't even ls.
regards,
James Pye
Re: Please help test on 3.1.1b
Posted by David Fraser <da...@sjsoft.com>.
Gregory (Grisha) Trubetskoy wrote:
>On Wed, 15 Oct 2003, David Fraser wrote:
>
>
>
>>Thanks for this Grisha! BTW, what was the fix? Also, I presume 3.1 will
>>still be Python-2.2 compatible... any chance of a binary?
>>
>>
>
>The installer, which is created by distutils, uses a feature available
>only in Python 2.3 (The --install-script option). In the past I've been
>able to compile it against 2.2, then use 2.3 to create the installer, but
>now that we have _psp.so which is also built by distutils, it would take
>additional wizardry to create the binary.
>
>
Right. I have found that you can patch the Python 2.2 distutils with
code from the Python 2.3 distutils.
(The actual Python modules don't neccessarily always require that
version of Python).
Maybe I should take a look at this. What are the exact steps you take on
Python 2.3? I'll try apply those on 2.2
>Are you sure, btw, that the 2.3 binary won't work with 2.2?
>
>
I wasn't, but now I am
At least, the installer won't run: "Python version 2.3 required, which
was not found in the registry"
>Grisha
>
>
David
Re: Please help test on 3.1.1b
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Wed, 15 Oct 2003, David Fraser wrote:
> Thanks for this Grisha! BTW, what was the fix? Also, I presume 3.1 will
> still be Python-2.2 compatible... any chance of a binary?
The installer, which is created by distutils, uses a feature available
only in Python 2.3 (The --install-script option). In the past I've been
able to compile it against 2.2, then use 2.3 to create the installer, but
now that we have _psp.so which is also built by distutils, it would take
additional wizardry to create the binary.
Are you sure, btw, that the 2.3 binary won't work with 2.2?
Grisha
Re: Please help test on 3.1.1b
Posted by David Fraser <da...@sjsoft.com>.
Gregory (Grisha) Trubetskoy wrote:
>You can get the sneak preview of 3.1.1 beta here:
>
>http://www.modpython.org/tmp/3.1.1b/
>
>Please download it, then do the usual
>
>$ ./configure --with-apxs=/wherever/it/is
>$ make
>$ (su)
># make install
>
>Then
>
>$ cd test
>$ python test.py
>
>And see if any tests fail. I have tested this on FreeBSD 4.8 and OS X
>10.2.8, but not on Linux, as my Linux box is dead ATM. Also Solaris would
>be nice... (as well as Panther, if you have it).
>
>Also, Windows folks - please make sure that this binary isn't screwed
>like the last one. This one I think _really_ works with 2.3 :-)
>
>Please respond to the list with your results ASAP so we can announce this
>puppy!
>
>Thank you very much,
>
>Grisha
>
>
>
Yes! At last! Hurrah! It works!
Thanks for this Grisha! BTW, what was the fix? Also, I presume 3.1 will
still be Python-2.2 compatible... any chance of a binary?
OOTH I would be happy to create binaries for 3.0-branch Python 2.3 (I
know this would need patches) and/or 3.1-branch Python 2.2 if you can
help step me through the creation procedure.
David