Re: mod_python 3.2.5b available for testing

2005-11-18 Thread Gregory (Grisha) Trubetskoy



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

2005-11-17 Thread Gregory (Grisha) Trubetskoy


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

2005-11-17 Thread Jim Gallacher

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)

2005-11-16 Thread Jim Gallacher

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

2005-11-15 Thread David Fraser

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

2005-11-15 Thread David Fraser

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

2005-11-15 Thread David Fraser

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

2005-11-15 Thread Gregory (Grisha) Trubetskoy


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

2005-11-15 Thread Ron Reisor

+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

2005-11-15 Thread Indrek Järve

+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)

2005-11-15 Thread Jim Gallacher

+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

2005-11-14 Thread Jim Gallacher

+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

2005-11-14 Thread Barry Pederson
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

2005-11-14 Thread Nicolas Lehuen
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

2005-11-14 Thread Nicolas Lehuen
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

2005-11-14 Thread Barry Pederson

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

2005-11-14 Thread Graham Dumpleton
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

2005-11-14 Thread John McFarlane
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.