Re: mod_python 3.2.3b available for testing

2005-10-24 Thread Dominic Wong
-1 for Gentoo Linux 2.6.13-gentoo-r3 Apache 2.0.54 Python 2.4.1 Haven't really got time to see what it is that's causing it right now: [EMAIL PROTECTED] /usr/local/src/mod_python-3.2.3b/test $ python test.py * Testing LoadModule Creating config listen port: 32771 Starting Apache

Re: mod_python 3.2.3b available for testing

2005-10-24 Thread Jim Gallacher
Indrek Järve wrote: Graham Dumpleton wrote: Jim Gallacher wrote .. Indrek Järve wrote: Jim Gallacher wrote: 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

Re: mod_python 3.2.3b available for testing

2005-10-24 Thread Ron Reisor
+1 MacOSX 10.4.2 gcc 4.0.0 (apple) Python-2.4.2 Apache-2.0.55 cheers, Ron 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

Re: mod_python 3.2.3b available for testing

2005-10-24 Thread Jim Gallacher
Dominic Wong wrote: -1 for Gentoo Linux 2.6.13-gentoo-r3 Apache 2.0.54 Python 2.4.1 Hi Dominic, When you have a chance could you apply the following patch and re-run the tests? Thanks, Jim Index: test/test.py === ---

Re: mod_python 3.2.3b available for testing

2005-10-24 Thread Dominic Wong
Jim Gallacher wrote: Dominic Wong wrote: -1 for Gentoo Linux 2.6.13-gentoo-r3 Apache 2.0.54 Python 2.4.1 Hi Dominic, When you have a chance could you apply the following patch and re-run the tests? Thanks, Jim Hi Jim, I pretty much get the same output: snip [EMAIL PROTECTED]

Re: async write completion prototype

2005-10-24 Thread Brian Pane
On Oct 10, 2005, at 5:15 PM, Greg Ames wrote: - event-ize lingering close. it eats up roughly the same number of worker threads as synchronous writes for SPECweb99. Is this because the lingering close is waiting a while for the client to close the inbound side of the connection? Or is the

Re: APR version of support/logresolve.c

2005-10-24 Thread Joe Orton
On Fri, Oct 21, 2005 at 10:10:51PM +0100, Colm MacCarthaigh wrote: support/logresolve doesn't support IPv6 addresses, which is a pain, because while logresolve is not a brilliant log resolver, it's useful for putting at the end of brief command lines, grepping things and so on. Anyway;

Re: Apache 2.0.x Binary distribution for HPUX

2005-10-24 Thread chris
hi guys, it works fine for me this way ;o) thanks a lot ;o) Jeff Trawick wrote: On 10/21/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jeff Trawick wrote: I use some hacks for binbuild-like binary distributions on HP-UX: a) add -Wl,+s for SHLIB_PATH (you tried that) It works

Re: APR version of support/logresolve.c

2005-10-24 Thread Colm MacCarthaigh
On Mon, Oct 24, 2005 at 12:58:21PM +0100, Joe Orton wrote: - odd style in places, some if(/while( without enough whitespace Ahh that old habit. and declarations with too much whitespace: apr_file_t * etc; This comes directly from the old logresolve.c. Didn't want to change

[RFC] require apr/apr-util 1.2.x for 2.2.x

2005-10-24 Thread Joe Orton
There was a thread about this previously; just checking for consensus, is there any objection to bumping the apr/apr-util version requirements to 1.2.x? (1.2.x is already required for mod_dbd, event MP, and it will simplify the code to allow unconditional use of 1.2.x features) Index:

Re: [RFC] require apr/apr-util 1.2.x for 2.2.x

2005-10-24 Thread Nick Kew
On Monday 24 October 2005 13:22, Joe Orton wrote: There was a thread about this previously; just checking for consensus, is there any objection to bumping the apr/apr-util version requirements to 1.2.x? (1.2.x is already required for mod_dbd, event MP, and it will simplify the code to allow

Re: [RFC] require apr/apr-util 1.2.x for 2.2.x

2005-10-24 Thread Colm MacCarthaigh
On Mon, Oct 24, 2005 at 01:22:36PM +0100, Joe Orton wrote: There was a thread about this previously; just checking for consensus, is there any objection to bumping the apr/apr-util version requirements to 1.2.x? (1.2.x is already required for mod_dbd, event MP, and it will simplify the

Re: The 2.2.0 Process

2005-10-24 Thread Jeff Trawick
On 10/23/05, Paul Querna [EMAIL PROTECTED] wrote: 2) 2.1.N is voted on for BETA. 3) Assuming the vote passes, several days after releasing 2.1.N-BETA, a vote to mark 2.1.N-BETA as Stable/General Availability will be called for by the 2.1.N Release Manager. 3 days is maybe enough time to

Re: [RFC] require apr/apr-util 1.2.x for 2.2.x

2005-10-24 Thread Jeff Trawick
On 10/24/05, Nick Kew [EMAIL PROTECTED] wrote: On Monday 24 October 2005 13:22, Joe Orton wrote: There was a thread about this previously; just checking for consensus, is there any objection to bumping the apr/apr-util version requirements to 1.2.x? (1.2.x is already required for mod_dbd,

Re: The 2.2.0 Process

2005-10-24 Thread Jim Jagielski
I agree with Jeff. The time between Beta and GM should ideally by longer that several days (depending on how you define several :) ). With 2.2, we should consider such terms as release candidate and make things easier for us and the community as well. So the process is: -dev - Beta - RC - GA

Re: The 2.2.0 Process

2005-10-24 Thread Graham Leggett
Jim Jagielski said: With 2.2, we should consider such terms as release candidate and make things easier for us and the community as well. So the process is: -dev - Beta - RC - GA +1. Regards, Graham --

mod_authn_dbd and 2.2.0

2005-10-24 Thread Nick Kew
mod_authn_dbd seemed to get the thumbs-up from those who test-drove it from trunk. Any thoughts on backporting to 2.2-branch at this stage? It'll serve as a small and simple demo of using DBD, as well as in its primary purpose. -- Nick Kew

Re: mod_authn_dbd and 2.2.0

2005-10-24 Thread Mads Toftum
On Mon, Oct 24, 2005 at 02:27:36PM +0100, Nick Kew wrote: mod_authn_dbd seemed to get the thumbs-up from those who test-drove it from trunk. Any thoughts on backporting to 2.2-branch at this stage? It'll serve as a small and simple demo of using DBD, as well as in its primary purpose. +1

Re: The 2.2.0 Process

2005-10-24 Thread Colm MacCarthaigh
On Sun, Oct 23, 2005 at 06:18:09PM -0700, Paul Querna wrote: Thoughts/Concerns? Can the PMC ask infra to make /docs-2.2/ work? The redirect needs explicit exclusions. There are quite a few instances of httpd 2.1 in the docs tree right now, including explicit links to

Re: mod_authn_dbd and 2.2.0

2005-10-24 Thread Nick Kew
On Monday 24 October 2005 14:59, Mads Toftum wrote: On Mon, Oct 24, 2005 at 02:27:36PM +0100, Nick Kew wrote: mod_authn_dbd seemed to get the thumbs-up from those who test-drove it from trunk. Any thoughts on backporting to 2.2-branch at this stage? It'll serve as a small and simple demo

Re: APR version of support/logresolve.c

2005-10-24 Thread Joost de Heer
Looks good; some nits: - odd style in places, some if(/while( without enough whitespace and declarations with too much whitespace: apr_file_t * etc; Is there an indent command line overview for 'ASF approved coding'? Joost

Re: APR version of support/logresolve.c

2005-10-24 Thread Colm MacCarthaigh
On Mon, Oct 24, 2005 at 06:16:14PM +0200, Joost de Heer wrote: Looks good; some nits: - odd style in places, some if(/while( without enough whitespace and declarations with too much whitespace: apr_file_t * etc; Is there an indent command line overview for 'ASF approved coding'?

Re: [RFC] require apr/apr-util 1.2.x for 2.2.x

2005-10-24 Thread Justin Erenkrantz
On Mon, Oct 24, 2005 at 01:41:18PM +0100, Colm MacCarthaigh wrote: If I might also ask, would anyone mind if; ./configure --with-apr=bundled --with-apr-util=bundled were added as options? Right now APR_FIND_APU and APR_FIND_APR are given 1 as the third argument, which means that if

Re: [RFC] require apr/apr-util 1.2.x for 2.2.x

2005-10-24 Thread Justin Erenkrantz
On Mon, Oct 24, 2005 at 01:22:36PM +0100, Joe Orton wrote: There was a thread about this previously; just checking for consensus, is there any objection to bumping the apr/apr-util version requirements to 1.2.x? (1.2.x is already required for mod_dbd, event MP, and it will simplify the

Re: APR version of support/logresolve.c

2005-10-24 Thread Sander Temme
On Oct 24, 2005, at 9:16 AM, Joost de Heer wrote: Looks good; some nits: - odd style in places, some if(/while( without enough whitespace and declarations with too much whitespace: apr_file_t * etc; Is there an indent command line overview for 'ASF approved coding'? We have:

Re: The 2.2.0 Process

2005-10-24 Thread Justin Erenkrantz
On Mon, Oct 24, 2005 at 08:52:35AM -0400, Jeff Trawick wrote: 3 days is maybe enough time to catch a couple of build issues that we didn't see, but not anything else. I don't see the value in making a big deal about it to the general public if the thing is likely to be GA before there is time

[Fwd: Re: [RFC] require apr/apr-util 1.2.x for 2.2.x]

2005-10-24 Thread William A. Rowe, Jr.
On Monday 24 October 2005 13:22, Joe Orton wrote: There was a thread about this previously; just checking for consensus, is there any objection to bumping the apr/apr-util version requirements to 1.2.x? (1.2.x is already required for mod_dbd, event MP, and it will simplify the code to allow

Re: [RFC] require apr/apr-util 1.2.x for 2.2.x

2005-10-24 Thread William A. Rowe, Jr.
Justin Erenkrantz wrote: On Mon, Oct 24, 2005 at 01:41:18PM +0100, Colm MacCarthaigh wrote: If I might also ask, would anyone mind if; ./configure --with-apr=bundled --with-apr-util=bundled were added as options? Right now APR_FIND_APU and APR_FIND_APR are given 1 as the third

authz: file-group ugliness

2005-10-24 Thread Nick Kew
I've just looked at authz. There's an IMO ugly hack whereby every authz provider has to run after authz_file and make a special case for file-group. It's repitition of identical code, and breaks modularity. Wouldn't it be better for mod_authz_owner to be able to determine whether file-group is

Re: authz: file-group ugliness

2005-10-24 Thread Brad Nicholes
This would be OK except that there is a bigger problem that I looked into trying to fix at one point but never completed it. The problem is the duplication of authorization types. Currently we have both mod_authz_groupfile and mod_authz_dbm implementing the types group and file-group. This