Re: mod_python 3.2.5b available for testing
On Thu, 17 Nov 2005, Jim Gallacher wrote: Gregory (Grisha) Trubetskoy wrote: OK, I think we got enough +1's and no show-stopping problems (for a beta at least). I copied it over the apache server, once the mirrors sync I'll update the site and send the big announcement. I was also thinking it was time for a wider release, but was hoping to see a +1 for FreeBSD 4 or 5 first. +1 FreeBSD 4.9-RC apache 2.0.53 Python 2.3 Grisha
Re: mod_python 3.2.5b available for testing
OK, I think we got enough +1's and no show-stopping problems (for a beta at least). I copied it over the apache server, once the mirrors sync I'll update the site and send the big announcement. Grisha On Mon, 14 Nov 2005, Jim Gallacher wrote: A new mod_python 3.2.5 beta tarball is now available for testing. A windows binary should be available shortly. This release is similar to 3.2.4b but fixes a couple of minor issues - MODPYTHON-87 (psp_parser), and MODPYTHON-40 (file upload). Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you, Jim Gallacher
Re: mod_python 3.2.5b available for testing
Gregory (Grisha) Trubetskoy wrote: OK, I think we got enough +1's and no show-stopping problems (for a beta at least). I copied it over the apache server, once the mirrors sync I'll update the site and send the big announcement. I was also thinking it was time for a wider release, but was hoping to see a +1 for FreeBSD 4 or 5 first. I've been sporadically trying to test mod_python on FreeBSD 5.4 using qemu but with no success. Not a big suprise since I can't get 3.1.4 to work either. I've likely messed something up as this was my first attempt with either FreeBSD or qemu. FreeBSD feels like a foreign country where everyone speaks English but with a funny accent. I'm sure I'll adjust. On the subject of qemu, one of my longer term projects is to setup an automated test environment using qemu images of the most popular linux and bsd distros. I get to decide what's popular. No arguments. No flamewars. ;) Qemu ain't fast, but it is effective and cheap. (To put things in context the unit tests alone take approx 10 minutes. Granted my computer is not a screamer, but still...) So far I have working images of Debian stable, Debian unstable and Gentoo, plus the afore mentioned but messed up FreeBSD. As time (and disk space) permit I'll add some combination of Fedora, maybe one of the RHEL clones, SUSE, Ubuntu or whatever else strikes my fancy. Once I cobble together some scripts to control qemu and automate the configure/make/test cycle we'll have ourselves a nice little virtual build farm. Let the computers work while we sleep, I say. If I ever get around to fully implementing this grand scheme we'll have a tool which will hopefully speed up the release cycle. Is this Friday? It sure feels like Friday. Usually I only ramble on like this on Fridays. :) Dang. It's not Friday. Back to work. Jim
Re: mod_python 3.2.5b available for testing (gentoo issues)
Nicolas Lehuen wrote: Hi Jim, 2005/11/16, Jim Gallacher [EMAIL PROTECTED]: +1 with patch Linux gentoo 2.6.12-gentoo-r6 apache 2.0.54 (mpm-prefork) python 2.4.2 gcc 3.3.6 There are 2 issues with the unit tests in Gentoo that are fixed by the attached patch. (Just to be clear, I mean the problems are with the unit test code, not with mod_python). First, test_global_lock uses ab in the test. In Gentoo, ab is named ab2, so this test fails. The attached patch just skips the test if ab doesn't exist. We can improve on this later. My bad, I'm the one who put back this test... It was commented out before mentioning a bug in ab with AFAIK the test ran perfectly. I didn't think about ab being renamed ab2... FYI, on debian ab2 is a symlink to ab. The second issue is with test_req_headers_out, first reported by Dominic Wong a couple of weeks ago. The fix is simple, but I want to understand why it was failing under Gentoo and not other platforms. The culprit seems to be the use of DirectoryIndex directive in the test.conf. The existence of DirectoryIndex /tests.py causes apache to segfault. Removing DirectoryIndex and giving the full url in the putrequest allows the test to complete successfully. So my questions are: 1. Why would DirectoryIndex cause a segfault on gentoo but not other platforms? I don't know why, but isn't it strange to put a slash in front of tests.py ? Shouldn't the directive be just DirectoryIndex tests.py N I tried using 'tests.py' as well, and it still segfaults. Weird. 2. This test is the only one that uses DirectoryIndex. Is there any special reason for this? 3. This test is the only one that uses AddHandler instead of SetHandler. Is there a reason for this? 4. This test is the only one that sets a PythonAccessHandler directive in test.conf. Is there a reason for this? Can anyone offer any insights? It also uses httplib and not vhost_get. It's as if this test was one of the first that have been written, and that ways to write better tests have been improved since (using vhost_get etc.). It makes sense to use httplib directly since it needs access to the headers. I did wonder if this was an early test though, and thus the different pattern used for the config. To be consistent with the other tests I think I'll remove the PythonAccessHandler from test_req_document_root_conf as well, unless you can see a reason it should stay. Jim
Re: mod_python 3.2.5b available for testing
hehe - sorry about that, should be fixed now Grisha On Tue, 15 Nov 2005, David Fraser wrote: Jim Gallacher wrote: A new mod_python 3.2.5 beta tarball is now available for testing. A windows binary should be available shortly. The windows binary for python 2.3 is borked, and contains its own md5sum, being only 68 bytes long. This did raise the interesting thought of how easy it would be to create a file which contains its own md5sum, but aside from that, I think it should be reuploaded :-) David
Re: mod_python 3.2.5b available for testing
+1 MacOSX 10.4.3, gcc 4.0.0 (apple), Python-2.4.2, Apache-2.0.55 cheers, Ron On Mon, 14 Nov 2005, Jim Gallacher wrote: A new mod_python 3.2.5 beta tarball is now available for testing. A windows binary should be available shortly. This release is similar to 3.2.4b but fixes a couple of minor issues - MODPYTHON-87 (psp_parser), and MODPYTHON-40 (file upload). Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you, Jim Gallacher Ron Reisor [EMAIL PROTECTED] (RWR3) University of Delaware Information Technologies/Network and Systems Services Computing Center/192 South Chapel Street/Newark DE, 19716 pgp finger print: 0D 73 06 6F D3 6A 99 D3 F5 D5 6E FF 3B B9 7C 2C
Re: mod_python 3.2.5b available for testing
+1 on SuSE Linux 9.2 (x86-64) Best regards, Indrek Jim Gallacher wrote: A new mod_python 3.2.5 beta tarball is now available for testing. A windows binary should be available shortly. This release is similar to 3.2.4b but fixes a couple of minor issues - MODPYTHON-87 (psp_parser), and MODPYTHON-40 (file upload). Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you, Jim Gallacher
Re: mod_python 3.2.5b available for testing (gentoo issues)
+1 with patch Linux gentoo 2.6.12-gentoo-r6 apache 2.0.54 (mpm-prefork) python 2.4.2 gcc 3.3.6 There are 2 issues with the unit tests in Gentoo that are fixed by the attached patch. (Just to be clear, I mean the problems are with the unit test code, not with mod_python). First, test_global_lock uses ab in the test. In Gentoo, ab is named ab2, so this test fails. The attached patch just skips the test if ab doesn't exist. We can improve on this later. The second issue is with test_req_headers_out, first reported by Dominic Wong a couple of weeks ago. The fix is simple, but I want to understand why it was failing under Gentoo and not other platforms. The culprit seems to be the use of DirectoryIndex directive in the test.conf. The existence of DirectoryIndex /tests.py causes apache to segfault. Removing DirectoryIndex and giving the full url in the putrequest allows the test to complete successfully. So my questions are: 1. Why would DirectoryIndex cause a segfault on gentoo but not other platforms? 2. This test is the only one that uses DirectoryIndex. Is there any special reason for this? 3. This test is the only one that uses AddHandler instead of SetHandler. Is there a reason for this? 4. This test is the only one that sets a PythonAccessHandler directive in test.conf. Is there a reason for this? Can anyone offer any insights? Regards, Jim Index: test/test.py === --- test/test.py(revision 344202) +++ test/test.py(working copy) @@ -136,7 +136,6 @@ MOD_PYTHON_SO = testconf.MOD_PYTHON_SO LIBEXECDIR = testconf.LIBEXECDIR AB = os.path.join(os.path.split(HTTPD)[0], ab) - SERVER_ROOT = TESTHOME CONFIG = os.path.join(TESTHOME, conf, test.conf) DOCUMENT_ROOT = os.path.join(TESTHOME, htdocs) @@ -379,7 +378,6 @@ return rsp ### Tests begin here - def test_req_document_root_conf(self): c = VirtualHost(*, @@ -668,8 +666,7 @@ ServerName(test_req_headers_out), DocumentRoot(DOCUMENT_ROOT), Directory(DOCUMENT_ROOT, - AddHandler(mod_python .py), - DirectoryIndex(/tests.py), + SetHandler(mod_python), PythonHandler(tests::req_headers_out), PythonAccessHandler(tests::req_headers_out_access), PythonDebug(On))) @@ -680,7 +677,7 @@ print \n * Testing req.headers_out conn = httplib.HTTPConnection(127.0.0.1:%s % PORT) -conn.putrequest(GET, /, skip_host=1) +conn.putrequest(GET, /tests.py, skip_host=1) conn.putheader(Host, test_req_headers_out:%s % PORT) conn.endheaders() response = conn.getresponse() @@ -1733,6 +1730,10 @@ t1 = time.time() print , time.ctime() ab = quoteIfSpace(AB) +if not os.path.exists(ab): +print ab not found. Skipping _global_lock test +return + if os.name == nt: cmd = '%s -c 5 -n 5 http://127.0.0.1:%s/tests.py NUL:' \ % (ab, PORT)
Re: mod_python 3.2.5b available for testing
+1 Linux Debian 3.1 stable (sarge) apache 2.0.54-5 (mpm-worker) python 2.3.5 gcc 3.3.5 +1 Linux Debian unstable (sid) apache 2.0.54-4 (mpm-prefork) python 2.3.5 gcc 4.0.2
Re: mod_python 3.2.5b available for testing
Thanks for the information, I'll add your patch to the test suite. Regards, Nicolas 2005/11/15, Barry Pederson [EMAIL PROTECTED]: I've got failures that seem to be caused by the tests themselves, but with a bit of tweaking they pass. FreeBSD 6.0 Apache 2.0.55 port built WITH_THREADS=1 Python 2.4.2 The error_log shows: -- [Mon Nov 14 19:38:15 2005] [notice] mod_python: Creating 8 session mutexes based on 256 max processes and 0 max threads. [Mon Nov 14 19:38:15 2005] [alert] (2)No such file or directory: getpwuid: couldn't determine user name from uid 4294967295, you probably need to modify the User directive [Mon Nov 14 19:38:15 2005] [notice] Apache/2.0.55 (FreeBSD) mod_python/3.2.5b Python/2.4.2 configured -- resuming normal operations [Mon Nov 14 19:38:15 2005] [info] Server built: Nov 12 2005 23:05:22 [Mon Nov 14 19:38:15 2005] [debug] prefork.c(956): AcceptMutex: flock (default: flock) [Mon Nov 14 19:38:15 2005] [alert] Child 9492 returned a Fatal error... Apache is exiting! [Mon Nov 14 19:38:15 2005] [emerg] (2)No such file or directory: Couldn't initialize cross-process lock in child [Mon Nov 14 19:38:15 2005] [emerg] (2)No such file or directory: Couldn't initialize cross-process lock in child Googling that last message comes up with a suggesting that you specify a User in the http config. With the attached patch, the tests run httpd with a User www directive, and pass. Barry --- mod_python-3.2.5b-old/test/httpdconf.py Tue Sep 13 15:35:57 2005 +++ mod_python-3.2.5b/test/httpdconf.py Mon Nov 14 19:43:07 2005 @@ -264,6 +264,10 @@ def __init__(self, val='Off'): Directive.__init__(self, self.__class__.__name__, val) +class User(Directive): +def __init__(self, val='www'): +Directive.__init__(self, self.__class__.__name__, val) + class VirtualHost(ContainerTag): def __init__(self, addr, *args): ContainerTag.__init__(self, self.__class__.__name__, addr, args) --- mod_python-3.2.5b-old/test/test.py Mon Nov 14 12:09:49 2005 +++ mod_python-3.2.5b/test/test.py Mon Nov 14 19:56:03 2005 @@ -229,6 +229,7 @@ IfModule(!mod_dir.c, LoadModule(dir_module %s % quoteIfSpace(os.path.join(modpath, mod_dir.so, +User(www), ServerRoot(SERVER_ROOT), ErrorLog(logs/error_log), LogLevel(debug),
Re: mod_python 3.2.5b available for testing
Barry Pederson wrote: I've got failures that seem to be caused by the tests themselves, but with a bit of tweaking they pass. FreeBSD 6.0 Apache 2.0.55 port built WITH_THREADS=1 Python 2.4.2 DOH! nevermind - just realized I missed this part of Jim's very clear instructions: - Then (as non-root user!) $ cd test $ python test.py - However I get some other errors now: == ERROR: test_connectionhandler (__main__.PerRequestTestCase) -- Traceback (most recent call last): File test.py, line 1220, in test_connectionhandler f = urllib.urlopen(url) File /usr/local/lib/python2.4/urllib.py, line 77, in urlopen return opener.open(url) File /usr/local/lib/python2.4/urllib.py, line 185, in open return getattr(self, name)(url) File /usr/local/lib/python2.4/urllib.py, line 317, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File /usr/local/lib/python2.4/urllib.py, line 334, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File /usr/local/lib/python2.4/urllib.py, line 574, in http_error_default return addinfourl(fp, headers, http: + url) File /usr/local/lib/python2.4/urllib.py, line 863, in __init__ addbase.__init__(self, fp) File /usr/local/lib/python2.4/urllib.py, line 813, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' -- Ran 43 tests in 16.807s FAILED (errors=1) F Stopping Apache... /usr/local/sbin/httpd -k stop -f /home/barryp/mod_python-3.2.5b/test/conf/test.conf == FAIL: testPerRequestTests (__main__.PerInstanceTestCase) -- Traceback (most recent call last): File test.py, line 1805, in testPerRequestTests self.failUnless(result.wasSuccessful()) AssertionError -- Ran 6 tests in 63.714s FAILED (failures=1) -- Not sure why running under a different userid is causing this - I cleaned out my /tmp of things owned by www. Will keep looking at this. Barry
Re: mod_python 3.2.5b available for testing
Not sure if this is helpfull, but here goes... To run test.py I did the following: Overlay: http://thinkflat.com/files/public/?d=/ebuilds/mod_python user# sudo emerge -a mod_python user# tar zxvf mod_python-3.2.5b.tgz user# cd mod_python-3.2.5b user# ./configure --with-apxs=/usr/sbin/apxs2 user# cp /usr/lib/apache2/modules/mod_python.so src user# cd test python test.py After which I received the following results: Gentoo (current) Apache 2.0.54 Python 2.4 GCC 3.3.6 *Note: I don't have ab which is needed for the global_lock test?* == FAIL: test_Session_Session (__main__.PerRequestTestCase) -- Traceback (most recent call last): File test.py, line 1472, in test_Session_Session self.fail(session did not set a cookie) AssertionError: session did not set a cookie -- Ran 43 tests in 19.479s FAILED (failures=1, errors=1) F Stopping Apache... /usr/sbin/apache2 -k stop -f /home/jmcfarlane/Desktop/mod_python-3.2.5b/test/conf/test.conf == FAIL: test_global_lock (__main__.PerInstanceTestCase) -- Traceback (most recent call last): File test.py, line 1747, in test_global_lock self.fail(global_lock is broken (too quick)) AssertionError: global_lock is broken (too quick) == FAIL: testPerRequestTests (__main__.PerInstanceTestCase) -- Traceback (most recent call last): File test.py, line 1805, in testPerRequestTests self.failUnless(result.wasSuccessful()) AssertionError -- Ran 6 tests in 44.204s FAILED (failures=2) Cheers, John M.
