Re: 3.2.6 or not
On Thu, Feb 02, 2006 at 10:54:27PM -0500, Jim Gallacher wrote: Graham Dumpleton wrote: To confirm Jim's arithmetic anyway, I say -1 on 3.2.6 as it stands. As to 3.2.7, I say +1, subject to removal of problematic test case as already raised and with us at least confirming tests run OK for version out of SVN prior to packaging. Oh, so *that's* where you said we should disable the test. ;) I've disabled the publisher_cache test and the connection handler fix has been checked in. We are good to go for 3.2.7. As Graham suggests perhaps we could get some people to confirm the current version in SVN trunk prior to packaging. A couple of thumbs up from some FreeBSD'ers would be especially nice since the connection handler problem seemed to be most prevalent on that platform. If everything looks ok I'll create the 3.2.7 tarball sometime Friday. I've tested trunk (rev 374588): FreeBSD 4.9, Apache 2.0.55 (prefork), Python 2.4.2 FreeBSD 4.9, Apache 2.0.50 (prefork), Python 2.3.4 All tests passed successfully.
Re: 3.2.6 or not
Jim Gallacher writes: Graham Dumpleton wrote: To confirm Jim's arithmetic anyway, I say -1 on 3.2.6 as it stands. As to 3.2.7, I say +1, subject to removal of problematic test case as already raised and with us at least confirming tests run OK for version out of SVN prior to packaging. Oh, so *that's* where you said we should disable the test. ;) I've disabled the publisher_cache test and the connection handler fix has been checked in. We are good to go for 3.2.7. As Graham suggests perhaps we could get some people to confirm the current version in SVN trunk prior to packaging. A couple of thumbs up from some FreeBSD'ers would be especially nice since the connection handler problem seemed to be most prevalent on that platform. If everything looks ok I'll create the 3.2.7 tarball sometime Friday. Just checked out the trunk... +1 trunk + Apache/2.0.55 + Python/2.3.5 + Debian/testing(etch)
Re: 3.2.6 or not
+1 trunk rev 374588 + Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4 +1 trunk rev 374588 + Apache/2.0.55 + ActivePython/2.3.5 + Windows 2000 SP4 +1 trunk rev 374588 + Apache/2.0.55 + ActivePython/2.4.2 + Windows XP SP2 All three installers for win32 are available at http://nicolas.lehuen.com/download/mod_python Regards, Nicolas 2006/2/3, Daniel J. Popowich [EMAIL PROTECTED]: Jim Gallacher writes: Graham Dumpleton wrote: To confirm Jim's arithmetic anyway, I say -1 on 3.2.6 as it stands. As to 3.2.7, I say +1, subject to removal of problematic test case as already raised and with us at least confirming tests run OK for version out of SVN prior to packaging. Oh, so *that's* where you said we should disable the test. ;) I've disabled the publisher_cache test and the connection handler fix has been checked in. We are good to go for 3.2.7. As Graham suggests perhaps we could get some people to confirm the current version in SVN trunk prior to packaging. A couple of thumbs up from some FreeBSD'ers would be especially nice since the connection handler problem seemed to be most prevalent on that platform. If everything looks ok I'll create the 3.2.7 tarball sometime Friday. Just checked out the trunk... +1 trunk + Apache/2.0.55 + Python/2.3.5 + Debian/testing(etch)
Re: 3.2.6 or not
Jim Gallacher wrote: +1 trunk rev 374588 Debian (sid), Apache 2.0.55-prefork, Python 2.3.5 +1 trunk rev 374588 Debian (sarge), Apache 2.0.54-worker, Python 2.3.5 +1 trunk rev 374588 Debian (sarge), Apache 2.0.54-prefork, Python 2.3.5 If I can get just one more test from FreeBSD 5 or 6, I'll produce the 3.2.7 tarball. +1 trunk rev 374709 FreeBSD 6.0 Apache 2.0.55-prefork, Python 2.4.2 This is a machine that always had trouble with that connectionhandler test before. Ran the entire unittest 5 times in a row with no trouble. Barry
Change to test_Session_Session_conf() of test/test.py.
Jim, Nicolas
Would it make sense to change test_Session_Session_conf() function in
unit tests to something like:
def test_Session_Session_conf(self):
import tempfile
tempdir = tempfile.gettempdir()
database = os.path.join(tempdir,mp_sess_test.dbm)
c = VirtualHost(*,
ServerName(test_Session_Session),
DocumentRoot(DOCUMENT_ROOT),
Directory(DOCUMENT_ROOT,
PythonOption('session_dbm %s' %
database),
SetHandler(mod_python),
PythonHandler(tests::Session_Session),
PythonDebug(On)))
return str(c)
Ie., explicitly set session_dbm to some other location than default.
Without this the test can fail if main Apache is run as different
account to what test is run as. I put database in /tmp under a
different
name, but might be better somewhere in the test directory of the source
code.
Does this make sense?
That gets rid of one of the failures, now for the others. :-)
Graham
Re: Cookies in IE/Non-dev libapreq2 version for apache2?
Jason Younker wrote: I recently upgraded to the following (on a rhel3 box mason2.2): Apache/2.0.55 mod_ssl/2.0.55 OpenSSL/0.9.8 mod_apreq2-20050712/2.1.3-dev mod_perl/2.0.2 Perl/v5.8.0 Everything has been running fine on my linux dev box (using firefox 1.5). However, when I switch over to my windows box and use internet explorer, I can't get any cookie info. Here is a simple test which shows the problem (where $r below is an Apache2::RequestRec object): my $jar = Apache2::Cookie::Jar-new($r); $m-out(Jar Status: . $jar-status() .br); At this point, I want to install a reliably stable, non-dev version of libapreq2 so that I be sure the problem is not something with a Apache2::Cookie stuff. Or, better yet, if you have *any* ideas where I have gone wrong (missing module, perhaps an entry missing from my httpd.conf), I would really, really appreciate any suggestions. You may want to try this cooking recipe[1] to determine if your setup functions under it. If that's the case the error is probably in your implementation. I'm not familiar with the Cookie::Jar approach you're using. But I have experienced what you are describing with regards to the IE/Firefox behavior, it occurred when the cookie had an invalid domain or path. [1] http://perl.apache.org/docs/2.0/user/coding/cooking.html#Sending_Cookies_Using_libapreq2
Re: Outch, a few problems for 2.0/2.2
On 2/2/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Finally vpath + symlink builds were broken, there is a set of patches over on http://people.apache.org/~wrowe/ named fixbuild-n.n.patch where -n.n is -2.0 -0.9, -2.2 -1.2, and -2.3 1.3 for the corresponding httpd and apr-util versions. The patches; * ensure we don't look for srclib/apr*** directories, but simply the file contained within. Seems reasonable to me... * avoid looking from apr-util to ../apr, since on symlinked environments in solaris this can be erronious. +1 * ensure we don't bomb on vpath builds looking for .h files in both the source and vpath target trees (because they don't exist in both). Consistently looking in one place seems reasonable. * properly check if we are vpath'ing for apr-util/xml/expat, creating that directory in the vpath target, and introduce the syntax --with-expat=builtin to resolve the ambiguity that vpath builds of the builtin expat introduces. Again, working in vpath builds is a good thing ;-) * never configure apr-iconv from apr-util. Since we won't configure apr from apr-util this was inconsistent. Assuming you mean buildconf, not configure, +1, I was surprised we did this at all. AFAICT the patches don't have anything to do with running apr-iconv's configure. In general the APR part of these patches looks reasonable to me, although I haven't actually tested them. Didn't look at the httpd side though. -garrett
Re: Accessing POST request body from a module
I am porting some CGI code to run as a module. It is all pretty
straightforward, except that I can't work out how to get at a POST
request's body.
Thanks to Michael for this:
while (ap_get_brigade(r-input_filters, brigade, AP_MODE_READBYTES,
APR_BLOCK_READ, len) == APR_SUCCESS) {
apr_brigade_flatten(brigade, buf, len);
apr_brigade_cleanup(brigade);
tlen += len;
if (tlen == count_bytes || !len) {
break;
}
buf += len;
len = count_bytes - tlen;
}
That looks good and I've tried something like it, but it seems to
segfault as soon as ap_get_brigade is called. I'm guessing that I need
to create the brigade first, but apr_brigade_create has a second
mysterious parameter that I can't work out. Michael, maybe you just
need to post the five lines before those??
BTW, is there any better documentation for this than
http://docx.webperf.org/group__APR__Util__Bucket__Brigades.html?
Nick Kew wrote:
If you had a usable-looking email address. I could reply with
exactly what you need
I'm sorry that it doesn't look useable to you, but I can assure you that
it does work; it's not even filtered. It would be quite hard to
subscribe to this list with a non-functioning address, I think.
Regards,
--Phil.
Re: svn commit: r374754 - in /httpd/site/trunk: docs/ docs/mod_smtpd/ docs/modules/ xdocs/ xdocs/mod_smtpd/ xdocs/modules/
On 2/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +ttmod_smtpd/tt started it's life as a 2005 Google Summer of Code project +taken on by strongRian Hunter/strong and strongJem Berkes/strong with +mentors strongNick Kew/strong and strongPaul Querna/strong. It continues +its life being developed and maintained by Rian Hunter with help from the httpd +developers. Ok, now we're seeing this both in the mod_mbox and mod_smtpd web pages. This is supposed to be a community project, ASF projects don't have lead developers, and they don't generally go out of their way to assign credit like this, that's normally kept to the CHANGES file and the svn commit logs. Putting this sort of thing on the web pages seems quite inappropriate to me. -garrett
Re: svn commit: r374754 - in /httpd/site/trunk: docs/ docs/mod_smtpd/ docs/modules/ xdocs/ xdocs/mod_smtpd/ xdocs/modules/
Garrett Rooney wrote: On 2/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +ttmod_smtpd/tt started it's life as a 2005 Google Summer of Code project +taken on by strongRian Hunter/strong and strongJem Berkes/strong with +mentors strongNick Kew/strong and strongPaul Querna/strong. It continues +its life being developed and maintained by Rian Hunter with help from the httpd +developers. Ok, now we're seeing this both in the mod_mbox and mod_smtpd web pages. This is supposed to be a community project, ASF projects don't have lead developers, and they don't generally go out of their way to assign credit like this, that's normally kept to the CHANGES file and the svn commit logs. Putting this sort of thing on the web pages seems quite inappropriate to me. +1. It is perhaps notable that it was _started_ as a SoC project, but the rest of it can most likely be nuked. We do have some similar language under http://httpd.apache.org/ABOUT_APACHE.html too. -Paul
Re: svn commit: r374754 - in /httpd/site/trunk: docs/ docs/mod_smtpd/ docs/modules/ xdocs/ xdocs/mod_smtpd/ xdocs/modules/
On Feb 3, 2006, at 5:36 PM, Paul Querna wrote: Garrett Rooney wrote: On 2/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +ttmod_smtpd/tt started it's life as a 2005 Google Summer of Code project +taken on by strongRian Hunter/strong and strongJem Berkes/strong with +mentors strongNick Kew/strong and strongPaul Querna/ strong. It continues +its life being developed and maintained by Rian Hunter with help from the httpd +developers. Ok, now we're seeing this both in the mod_mbox and mod_smtpd web pages. This is supposed to be a community project, ASF projects don't have lead developers, and they don't generally go out of their way to assign credit like this, that's normally kept to the CHANGES file and the svn commit logs. Putting this sort of thing on the web pages seems quite inappropriate to me. +1. It is perhaps notable that it was _started_ as a SoC project, but the rest of it can most likely be nuked. We do have some similar language under http://httpd.apache.org/ABOUT_APACHE.html too. -Paul +1 I used mod_mbox as the model for the mod_smtpd page. Excuse my ignorance. Rian
Re: Outch, a few problems for 2.0/2.2
Garrett Rooney wrote: On 2/2/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Finally vpath + symlink builds were broken, there is a set of patches over on http://people.apache.org/~wrowe/ named fixbuild-n.n.patch where -n.n is -2.0 -0.9, -2.2 -1.2, and -2.3 1.3 for the corresponding httpd and apr-util versions. The patches; * ensure we don't bomb on vpath builds looking for .h files in both the source and vpath target trees (because they don't exist in both). Consistently looking in one place seems reasonable. Actually the patch looks in both. We wrap that search in ( ) to avoid make (solaris make) discovering there was an error invoking ls ap[ru].u, for example, because those two files exist as generated objects on the target tree, not the source, while ap[ru]_*.h generally live on the source tree. * never configure apr-iconv from apr-util. Since we won't configure apr from apr-util this was inconsistent. Assuming you mean buildconf, not configure, +1, I was surprised we did this at all. AFAICT the patches don't have anything to do with running apr-iconv's configure. Right; long day yesterday, was in need of caffene replentishment.
