Re: mod_python 3.2.3b available for testing
-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 /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf . * Testing server.register_cleanup()... Creating config listen port: 32774 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf . * Testing apache.register_cleanup()... Creating config listen port: 32777 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf . * Running the per-request test suite... Creating config listen port: 32781 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf * Testing req.document_root() . * Testing req.add_handler() . * Testing req.allow_methods() . * Testing req.get_basic_auth_pw() . * Testing req.requires() . * Testing req.internal_redirect() . * Testing req.read() writing 10 bytes... response size: 10 read/write ok, now lets try causing a timeout (should be 5 secs) . * Testing req.readline() writing 120004 bytes... response size: 120004 . * Testing req.readlines() writing 120004 bytes... response size: 120004 . * Testing req.register_cleanup() . * Testing req.headers_out E * Testing req.sendfile() with offset and length . * Testing req.sendfile() without offset and length . * Testing req.sendfile() for a file which is a symbolic link . * Testing PythonOption . * Testing PythonOption override . * Testing PythonOption remove . * Testing PythonOption remove2 . * Testing util_fieldstorage() . * Testing PostReadRequestHandler . * Testing TransHandler . * Testing PythonOutputFilter . * Testing PythonConnectionHandler . * Testing PythonImport . * Testing | .ext syntax . * Testing mod_python.cgihandler . * Testing mod_python.psp . * Testing Cookie.Cookie . * Testing Cookie.MarshalCookie . * Testing Session.Session . * Testing interpreter per directive . * Testing interpreter per directory . * Testing mod_python.publisher . * Testing mod_python.publisher old-style instance publishing . * Testing mod_python.publisher instance publishing . * Testing mod_python.publisher security . * Testing mod_python.publisher iterators . * Testing mod_python.publisher hierarchy . == ERROR: test_req_headers_out (__main__.PerRequestTestCase) -- Traceback (most recent call last): File test.py, line 596, in test_req_headers_out response = conn.getresponse() File /usr/lib/python2.4/httplib.py, line 863, in getresponse response.begin() File /usr/lib/python2.4/httplib.py, line 333, in begin version, status, reason = self._read_status() File /usr/lib/python2.4/httplib.py, line 297, in _read_status raise BadStatusLine(line) BadStatusLine -- Ran 38 tests in 9.759s FAILED (errors=1) F Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf == FAIL: testPerRequestTests (__main__.PerInstanceTestCase) -- Traceback (most recent call last): File test.py, line 1488, in testPerRequestTests self.failUnless(result.wasSuccessful()) AssertionError -- Ran 4 tests in 26.496s FAILED (failures=1) Jim Gallacher wrote: A new mod_python 3.2.3 beta tarball is now available for testing. A Windows binary is also available. This release is similar to 3.2.2b but fixes a couple a small issues where a non-threaded python is used. 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
Re: mod_python 3.2.3b available for testing
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 suggestions, if any).
Thank you,
Jim Gallacher
+1 on SuSE Linux 9.2 (i586)
+1 on SuSE Linux 9.2 (x86-64) once I edited the configure script and
replaced lib/ with lib64/ in PY_STD_LIB and PyLIBP
I wonder how we might correctly determine the 'lib' part of the path.
The relevant section of configure.in is:
# find out compiled in install prefix
AC_MSG_CHECKING(Python install prefix)
PyEXEC_INSTALLDIR=`$PYTHON_BIN -c import sys; print sys.exec_prefix`
AC_MSG_RESULT($PyEXEC_INSTALLDIR)
# this is where the Python libraries will get installed
AC_SUBST(PY_STD_LIB)
PY_STD_LIB=${PyEXEC_INSTALLDIR}/lib/python${PyVERSION}
# set python std library variable
AC_SUBST(LIBS)
PyLIBP=${PyEXEC_INSTALLDIR}/lib/python${PyVERSION}
For those of you not familiar with autoconf, we use configure.in as the
source file to generate the configure file.
Personally, I would try and use distutils to make these judgements
as to
where things live rather than constructing the standard lib directory
path
from prefix and version. For example:
python -c 'import distutils.sysconfig; print
distutils.sysconfig.get_python_lib(plat_specific=1, standard_lib=1)'
Yields:
/usr/local/sys/python/lib/python2.3
On one Solaris platform I use. On Mac OS X it yields:
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3
Indrek, can you see what this command yields for you and whether it
correctly yields what you need. Maybe it is a better of way of working
this out.
Graham
The distutils example above correctly yields /usr/lib64/python2.3/ on
the Opteron box.
OK, that looks like the way to go. I will make the correction to
configure.in and configure.
Jim
Re: mod_python 3.2.3b available for testing
+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 D5 6E FF 3B B9 7C 2C
Re: mod_python 3.2.3b available for testing
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 === --- test/test.py(revision 327731) +++ test/test.py(working copy) @@ -590,6 +590,7 @@ print \n * Testing req.headers_out conn = httplib.HTTPConnection(127.0.0.1:%s % PORT) +conn.set_debuglevel(1) conn.putrequest(GET, /, skip_host=1) conn.putheader(Host, test_req_headers_out:%s % PORT) conn.endheaders()
Re: mod_python 3.2.3b available for testing
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] /usr/local/src/mod_python-3.2.3b/test $ python test.py * Testing LoadModule Creating config listen port: 32863 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf . * Testing server.register_cleanup()... Creating config listen port: 32866 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf . * Testing apache.register_cleanup()... Creating config listen port: 32869 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf . * Running the per-request test suite... Creating config listen port: 32873 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf * Testing req.document_root() . * Testing req.add_handler() . * Testing req.allow_methods() . * Testing req.get_basic_auth_pw() . * Testing req.requires() . * Testing req.internal_redirect() . * Testing req.read() writing 10 bytes... response size: 10 read/write ok, now lets try causing a timeout (should be 5 secs) . * Testing req.readline() writing 120004 bytes... response size: 120004 . * Testing req.readlines() writing 120004 bytes... response size: 120004 . * Testing req.register_cleanup() . * Testing req.headers_out connect: (127.0.0.1, 32873) send: 'GET / HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: test_req_headers_out:32873\r\n\r\n' reply: '' E * Testing req.sendfile() with offset and length . * Testing req.sendfile() without offset and length . * Testing req.sendfile() for a file which is a symbolic link . * Testing PythonOption . * Testing PythonOption override . * Testing PythonOption remove . * Testing PythonOption remove2 . * Testing util_fieldstorage() . * Testing PostReadRequestHandler . * Testing TransHandler . * Testing PythonOutputFilter . * Testing PythonConnectionHandler . * Testing PythonImport . * Testing | .ext syntax . * Testing mod_python.cgihandler . * Testing mod_python.psp . * Testing Cookie.Cookie . * Testing Cookie.MarshalCookie . * Testing Session.Session . * Testing interpreter per directive . * Testing interpreter per directory . * Testing mod_python.publisher . * Testing mod_python.publisher old-style instance publishing . * Testing mod_python.publisher instance publishing . * Testing mod_python.publisher security . * Testing mod_python.publisher iterators . * Testing mod_python.publisher hierarchy . == ERROR: test_req_headers_out (__main__.PerRequestTestCase) -- Traceback (most recent call last): File test.py, line 597, in test_req_headers_out response = conn.getresponse() File /usr/lib/python2.4/httplib.py, line 863, in getresponse response.begin() File /usr/lib/python2.4/httplib.py, line 333, in begin version, status, reason = self._read_status() File /usr/lib/python2.4/httplib.py, line 297, in _read_status raise BadStatusLine(line) BadStatusLine -- Ran 38 tests in 9.836s FAILED (errors=1) F Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf == FAIL: testPerRequestTests (__main__.PerInstanceTestCase) -- Traceback (most recent call last): File test.py, line 1489, in testPerRequestTests self.failUnless(result.wasSuccessful()) AssertionError -- Ran 4 tests in 26.450s FAILED (failures=1) /snip Cheers, Dom
Re: async write completion prototype
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 lingering close finding that the connection is closed as soon as it does the wait for I/O or timeout--meaning that the reason the server spends a lot of time in lingering close is simply that the code for lingering close (poll+read+close plus various setsockopt calls) takes a while? Brian
Re: APR version of support/logresolve.c
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; http://people.apache.org/~colm/logresolve.c is an APR version, it's also a lot shorter than the current version. Looks good; some nits: - odd style in places, some if(/while( without enough whitespace and declarations with too much whitespace: apr_file_t * etc; - apr_hash_* can use APR_HASH_KEY_STRING rather than strlen(key) - odd casts to/from (const void *) in hash handling which shouldn't be necessary? joe
Re: Apache 2.0.x Binary distribution for HPUX
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 nicely if you tweak libtool's archive_cmds from +b to +s +b
in the hpux* section of acinclude.m4, aclocal.m4 and configure, also
toggling...
hardcode_libdir_flag_spec='${wl}+s ${wl}+b ${wl}$libdir'
hardcode_minus_L=no
and a bit further down (line after SHLIB_PATH)...
shlibpath_overrides_runpath=yes
That does looks nice!
Re: APR version of support/logresolve.c
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 absolutely everything ;-) But I'll make consistent and less wasteful. - apr_hash_* can use APR_HASH_KEY_STRING rather than strlen(key) - odd casts to/from (const void *) in hash handling which shouldn't be necessary? No, they're not. I've forgotten why I even have them. Thanks for spotting them. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[RFC] require apr/apr-util 1.2.x for 2.2.x
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: configure.in
===
--- configure.in(revision 328042)
+++ configure.in(working copy)
@@ -87,6 +87,11 @@
APR_VERSION=`$apr_config --version`
APR_CONFIG=$APR_BINDIR/apr-`echo ${APR_VERSION} | sed 's,\..*,,'`-config
+if test ${apr_found} = yes; then
+ # Require APR 1.2.x otherwise fail
+ APACHE_CHECK_APxVER([apr], 1, 2)
+fi
+
echo $ac_n ${nl}Configuring Apache Portable Runtime Utility library...${nl}
APR_FIND_APU($srcdir/srclib/apr-util, ./srclib/apr-util, 1, 1)
@@ -112,6 +117,9 @@
dnl We must be the last to build and the first to be cleaned
AP_BUILD_SRCLIB_DIRS=$AP_BUILD_SRCLIB_DIRS apr-util
AP_CLEAN_SRCLIB_DIRS=apr-util $AP_CLEAN_SRCLIB_DIRS
+else
+ # Require APR-util 1.2.x otherwise fail
+ APACHE_CHECK_APxVER([apu], 1, 2)
fi
APR_ADDTO(LDFLAGS, `$apu_config --ldflags`)
Re: [RFC] require apr/apr-util 1.2.x for 2.2.x
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 unconditional use of 1.2.x features) +1 Indeed, given not least the close relationship of the projects, I see no real downside in requiring APR to be latest-at-time-of-2.2-release, whether that be 1.2 or some later version. -- Nick Kew
Re: [RFC] require apr/apr-util 1.2.x for 2.2.x
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 code to allow unconditional use of 1.2.x features) +1 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 apr/apr-util are in the install prefix - they are preferred over the bundled versions. That's fine behaviour, but it's also a real hassle for development :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: The 2.2.0 Process
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 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 for more than a handful of people to give feedback. (Why did I bother with the beta?)
Re: [RFC] require apr/apr-util 1.2.x for 2.2.x
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, event MP, and it will simplify the code to allow unconditional use of 1.2.x features) +1 +1 here as well
Re: The 2.2.0 Process
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 On Oct 23, 2005, at 9:18 PM, Paul Querna wrote: As we get closer to the next stable/GA branch, I want to clarify with everyone how I imagine the process will happen. This isn't the process that is documented in VERSIONING, but I think it deals better with the 2.1.x - 2.2.0 jump. 1) 2.1.N is tagged. 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. 4) If the vote passes, the 2.1.N tag will be copied to 2.2.0. Only the version numbers will be changed in Subversion. This 2.2.0 tarball will be placed in /dev/dist/ for final sanity voting. This final vote *should* be used only to verify that the packaging of the tag is correct. The code is identical to what passed the GA vote in step 3. 5) 2.2.0 will be released. Thoughts/Concerns? Thanks, -Paul
Re: The 2.2.0 Process
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
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
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 from the peanut gallery - and it would make a good selling point for people to upgrade from 2.0.x. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: The 2.2.0 Process
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 http://httpd.apache.org/docs/2.1/ , I'd like to fix these (primarily by making them relative links, but there may still be exceptions). -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: mod_authn_dbd and 2.2.0
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 of using DBD, as well as in its primary purpose. +1 from the peanut gallery :-) - and it would make a good selling point for people to upgrade from 2.0.x. It'll do better if someone completes the job by hacking an authz_dbd too. Oh for a nice juicy round tuit! -- Nick Kew
Re: APR version of support/logresolve.c
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
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'? Yes, it's at; http://httpd.apache.org/dev/styleguide.html It doesn't cover quite everything though. There are two common multi-mine comment formats, for example. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [RFC] require apr/apr-util 1.2.x for 2.2.x
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 apr/apr-util are in the install prefix - they are preferred over the bundled versions. That's fine behaviour, but it's also a real hassle for development :-) So? Specify the path to your installed development copy directly. But bundled will be treated as a directory - hence, your hack isn't a valid solution. -- justin
Re: [RFC] require apr/apr-util 1.2.x for 2.2.x
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 code to allow unconditional use of 1.2.x features) -0. I don't think it's appropriate and pushes us even further on the bleeding edge of what vendors will provide. -- justin
Re: APR version of support/logresolve.c
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: http://httpd.apache.org/dev/styleguide.html There are also .indent.pro files in most of the httpd tree, and even some emacs-style macros. Of course these resources may not agree with each other... it's generally best to not put indentation changes and code changes in the same patch. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: The 2.2.0 Process
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 for more than a handful of people to give feedback. (Why did I bother with the beta?) I think it's prudent to release just one more beta release for public review and see how it fares before we jump to GA. So, I think we should do a 2.1.9 beta and then issue a complete feature freeze on the branch (i.e. move to RTC on the branch; which we're doing a piss-poor job of right now as everybody and their sister is merging unreviewed feature changes into 2.2.x). Then, our next release can be a GA target after we know that 2.1.9 had no problems and that branch is essentially frozen so it can be stabilized. I'd like to be more conservative about a 2.2.0 GA than we were with the 2.0 GAs which were extremely rushed. There's no reason for us to rush a GA out right now: we've waited this long, duing another round of betas will only help our eventual 2.2.0 GA quality. -- justin
[Fwd: Re: [RFC] require apr/apr-util 1.2.x for 2.2.x]
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 unconditional use of 1.2.x features) +1, and that being the very latest 1.2.x (or 1.3.x) in the release tarball. But 1.2.0 and later should be 'sufficient' to run httpd 2.2, since there are no API/ABI changes IIRC. Bill
Re: [RFC] require apr/apr-util 1.2.x for 2.2.x
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 argument, which means that if apr/apr-util are in the install prefix - they are preferred over the bundled versions. That's fine behaviour, but it's also a real hassle for development :-) +1 but Justin is right, the syntax becomes --with-apr-bundled (or with-bundled-apr). The =bundled path syntax is simply wrong.
authz: file-group ugliness
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 satisfied before returning, instead of faffing about with Notes and complicating the AuthAuthoritativeness logic? We could implement that using a file-group optional hook in mod_authz_owner. The normal authz_FOO modules can then implement the hook and properly preserve modularity. Any thoughts? -- Nick Kew
Re: authz: file-group ugliness
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 causes a problem because if both of these modules are loaded and the configuration contains the directive: require group foo or require file-group which authorization module handles it? Well it seems to be completely dependant on load order and/or the use of the directives AuthzXXXAuthoritative. In addition to implementing an optional function in mod_authz_owner to get the owner id, all authorization types should probably be renamed to be unique. group - mod_authz_groupfile dbm-group - mod_authz_dbm dbd-group - mod_authz_dbd ldap-group - mod_authnz_ldap (already done) etc... thoughts on this...? Brad On 10/24/2005 at 4:08:39 pm, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: 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 satisfied before returning, instead of faffing about with Notes and complicating the AuthAuthoritativeness logic? We could implement that using a file-group optional hook in mod_authz_owner. The normal authz_FOO modules can then implement the hook and properly preserve modularity. Any thoughts?
