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
Jim Gallacher wrote .. > 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. I can't remember whether you need to actually be hosting a project on SourceForge, or whether you get access just with a normal user account, but the SourceForge compile farm provides a range of different hosts that might be able to be used. I host a project on SF so can access it, but at the moment am way too busy to try and debug anything for FreeBSD. Hopefully will get some time back in a few more weeks. :-) 32-bit x86 Architecture: x86-linux2: Fedora Linux FC2 running Linux 2.6 kernel x86-openbsd1: OpenBSD 3.4 x86-solaris1: Sun Solaris 9 x86-linux1: Debian GNU/Linux 3.0 running Linux 2.4 kernel x86-freebsd1: FreeBSD 4.8 x86-netbsd1: NetBSD 1.6.1 AMD 64-bit (Opteron) Architecture: amd64-linux1: Fedora Core release 3 running Linux 2.6 kernel DEC Alpha (ev67) Architecture: alpha-linux1: Debian GNU/Linux 3.0 running Linux 2.2 kernel PowerPC Architecture: ppc-osx1: Apple Mac OS X 10.1 Server with Fink running on an Apple Mac G4 ppc-osx2: Apple Mac OS X 10.2 Server with Fink running on an Apple Mac G4 Sparc (UltraSPARC-II) Architecture: sparc-solaris1, sparc-solaris2: Sun Solaris 9, running on two Sun Enterprise 220R systems IBM Power5 Architecture: openpower-linux1: SuSE Enterprise Linux 9, running on an IBM OpenPower 720 (e-Series) host.
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
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 (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 (gentoo issues)
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... > 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 > 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.). Regards, Nicolas
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
Sure enough /tmp/mp_sess.dbm was present, and owned by apache. I
removed the file and tested again with the same results. In doing so
/tmp/mp_sess.dbm was re-created and owned by the user running the test.
John M.
Jim Gallacher wrote:
> John McFarlane wrote:
>> 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
>
> Is there any chance /tmp/mp_sess.dbm already exists but with a different
> owner than the user running the tests?
>
> Try the following in the test directory:
>
> grep DBAccessError logs/error_log
>
> My guess is you'll see 'Permission denied' popping up.
>
> This makes me realize that there is a flaw in this test. The default
> location for mp_sess.db is /tmp so if a user is already running
> mod_python with sessions there will be a conflict. We should use
> 'PythonOption session_directory' to specify a location which will not
> conflict. How about test/tmp or test/var? We could stick our other
> temporary files in there as well and then do a cleanup at the successful
> completion of the tests.
>
>> --
>> 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)
>
> This failure is not a suprise since you don't have ab. We need to make
> this test conditional on ab being found or perhaps in a future release
> provide an alternative to ab in pure python.
>
> Jim
>
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
+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
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
John McFarlane wrote:
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
Is there any chance /tmp/mp_sess.dbm already exists but with a different
owner than the user running the tests?
Try the following in the test directory:
grep DBAccessError logs/error_log
My guess is you'll see 'Permission denied' popping up.
This makes me realize that there is a flaw in this test. The default
location for mp_sess.db is /tmp so if a user is already running
mod_python with sessions there will be a conflict. We should use
'PythonOption session_directory' to specify a location which will not
conflict. How about test/tmp or test/var? We could stick our other
temporary files in there as well and then do a cleanup at the successful
completion of the tests.
--
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)
This failure is not a suprise since you don't have ab. We need to make
this test conditional on ab being found or perhaps in a future release
provide an alternative to ab in pure python.
Jim
Re: mod_python 3.2.5b available for testing
Nicolas Lehuen wrote: Being the guy who provide the Win32 binaries, I feel obliged to answer :) Brilliant :-) download, untar, then do (substituting your apache directory for the one below) cd dist set APACHESRC="c:\Program Files\Apache Group\Apache2" build_installer.bat Note that without setting APACHESRC, the setup will try and locate apxs to find the include and library directories, which will fail on a default (non-source) apache install (and which requires running configure which is wierd on windows anyway...) Perhaps a note on the could be added to the README? Yes, and I'll add a test to build_installer.bat which will display a nice error message when APACHESRC is not set. Great, thanks 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). Again, you can't do this on Windows without running configure. Did those who tested on Windows run configure or how did they get it to work? I'm curious as to the setup :-) No need to run configure (which would cause a bunch of problems on Windows). Just copy testconf.py.in to testconf.py and replace the @..@ macros manually. Surely we could write code to figure these out? We work out many of them in setup.py.in / win32_postinstall.py anyway... I tried building myself and testing the py2.4 installer, but with both the tests failed to start the Apache service and so universally failed. This was with a manually created testconf.py I'm not giving a -1 until I know I'm doing the right thing though :-) You're doing the right thing if you have something like this in testconf.py : HTTPD=r'c:\apache\bin\apache.exe' TESTHOME=r'D:\projets\mod_python\test' MOD_PYTHON_SO=r'C:\apache\MODULES\mod_python.so' LIBEXECDIR=r'C:\apache\modules' In any case this would be a -1 on the test framework, not on mod_python... OK - it seems the test framework leads at least a bit of documentation as to how to run on Windows And I'd like to provide a way of doing this on Windows without configure if possible All right, all right, I'll add a few lines of documentation to test/README. Nothing like bothering people :-) So do these tests run for you? The disturbing thing for me was that the seem to fail without any error messages being produced by apache, even in the test/logs/* files It turns out that if the service can't write to the error log file, it fails and logs a message in the Windows Event log, rather than to the console. This is odd because it actually opens the log files itself. I suspect this is because it actually runs using a different user as a service... Anyway I should have been testing the earlier betas so I'm doing catchup :-) Cheers David
Re: mod_python 3.2.5b available for testing
Being the guy who provide the Win32 binaries, I feel obliged to answer :) 2005/11/15, David Fraser <[EMAIL PROTECTED]>: > Jim Gallacher wrote: > > > A new mod_python 3.2.5 beta tarball is now available for testing. A > > windows binary should be available shortly. > > I thought I'd add a note on building on Windows... > > > Please download it, then do the usual > > > > $ ./configure --with-apxs=/wherever/it/is > > $ make > > $ (su) > > # make install > > download, untar, then do (substituting your apache directory for the one > below) > cd dist > set APACHESRC="c:\Program Files\Apache Group\Apache2" > build_installer.bat > > Note that without setting APACHESRC, the setup will try and locate apxs > to find the include and library directories, which will fail on a > default (non-source) apache install (and which requires running > configure which is wierd on windows anyway...) > > Perhaps a note on the could be added to the README? Yes, and I'll add a test to build_installer.bat which will display a nice error message when APACHESRC is not set. > > 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). > > Again, you can't do this on Windows without running configure. > Did those who tested on Windows run configure or how did they get it to > work? I'm curious as to the setup :-) No need to run configure (which would cause a bunch of problems on Windows). Just copy testconf.py.in to testconf.py and replace the @..@ macros manually. > I tried building myself and testing the py2.4 installer, but with both > the tests failed to start the Apache service and so universally failed. > This was with a manually created testconf.py > I'm not giving a -1 until I know I'm doing the right thing though :-) You're doing the right thing if you have something like this in testconf.py : HTTPD=r'c:\apache\bin\apache.exe' TESTHOME=r'D:\projets\mod_python\test' MOD_PYTHON_SO=r'C:\apache\MODULES\mod_python.so' LIBEXECDIR=r'C:\apache\modules' In any case this would be a -1 on the test framework, not on mod_python... > And I'd like to provide a way of doing this on Windows without configure > if possible All right, all right, I'll add a few lines of documentation to test/README. Regards, Nicolas
Re: mod_python 3.2.5b available for testing
Jim Gallacher wrote: A new mod_python 3.2.5 beta tarball is now available for testing. A windows binary should be available shortly. I thought I'd add a note on building on Windows... Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install download, untar, then do (substituting your apache directory for the one below) cd dist set APACHESRC="c:\Program Files\Apache Group\Apache2" build_installer.bat Note that without setting APACHESRC, the setup will try and locate apxs to find the include and library directories, which will fail on a default (non-source) apache install (and which requires running configure which is wierd on windows anyway...) Perhaps a note on the could be added to the README? 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). Again, you can't do this on Windows without running configure. Did those who tested on Windows run configure or how did they get it to work? I'm curious as to the setup :-) I tried building myself and testing the py2.4 installer, but with both the tests failed to start the Apache service and so universally failed. This was with a manually created testconf.py I'm not giving a -1 until I know I'm doing the right thing though :-) And I'd like to provide a way of doing this on Windows without configure if possible Cheers David
Re: mod_python 3.2.5b available for testing
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
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.
Re: mod_python 3.2.5b available for testing
Graham Dumpleton wrote: I can't find the old mail about this, but Grisha suggested that this can occur in virtual hosting environments, eg, OpenVPS. No, no virtual hosting, jails, or other obviously unusual stuff. >> > FreeBSD 6.0 >> > Apache 2.0.55 port built WITH_THREADS=1 >> > Python 2.4.2 == 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' -- Looking at my logs/error_log I see [Mon Nov 14 23:10:23 2005] [notice] child pid 53034 exit signal Segmentation fault (11), possible coredump in /home/barryp/mod_python-3.2.5b/test I rebuilt apache and mod_python with debugging turned on, went into gdb with "gdb /usr/local/sbin/httpd httpd.core", did a "bt", and got: -- #0 0x0058 in ?? () #1 0x284b5ad6 in _conn_read (c=0x8258128, mode=AP_MODE_GETLINE, len=0) at connobject.c:117 #2 0x284b5d63 in conn_readline (self=0x86b6780, args=0x819002c) at connobject.c:193 #3 0x285014fa in PyEval_EvalFrame () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #4 0x28501699 in PyEval_EvalFrame () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #5 0x28501cec in PyEval_EvalCodeEx () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #6 0x2853b3ea in function_call () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #7 0x284c254c in PyObject_Call () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #8 0x284c7f8e in instancemethod_call () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #9 0x284c254c in PyObject_Call () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #10 0x284c2721 in PyObject_CallMethod () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #11 0x284bea7d in python_connection (con=0x8258128) at mod_python.c:1281 #12 0x284bfbd5 in PythonConnectionHandler (con=0x8258128) at mod_python.c:1929 #13 0x08075546 in ap_run_process_connection (c=0x8258128) at connection.c:43 #14 0x08075940 in ap_process_connection (c=0x8258128, csd=0x8258050) at connection.c:176 #15 0x08068971 in child_main (child_num_arg=0) at prefork.c:610 #16 0x08068afb in make_child (s=0x80b5df8, slot=0) at prefork.c:704 #17 0x08068b71 in startup_children (number_to_start=3) at prefork.c:722 #18 0x08068f6e in ap_mpm_run (_pconf=0x80b4018, plog=0x80e0018, s=0x80b5df8) at prefork.c:941 #19 0x0806fd5e in main (argc=5, argv=0xbfbfea90) at main.c:638 Not sure where to look next. Barry
Re: mod_python 3.2.5b available for testing
I can't find the old mail about this, but Grisha suggested that this can occur in virtual hosting environments, eg, OpenVPS. Barry Pederson wrote .. > 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
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
H having a look at :
http://httpd.apache.org/docs/2.0/mod/mpm_common.html#user
I'm finally not so sure we should integrate the User directive.
Wouldn't that require that the computer the test runs on has a user
named www with sufficient privileges plus that the test are started as
root ?
Regards,
Nicolas
2005/11/15, Nicolas Lehuen <[EMAIL PROTECTED]>:
> 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
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
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
+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
