Re: [Vote] httpd 2.2.22 release
On 30.01.2012 03:16, William A. Rowe Jr. wrote: On 1/29/2012 3:18 PM, Rainer Jung wrote: Overview: Minor problem (not a regression): config.guess and config.sub are a bit old (2008) due to buildconf in the released apr overwriting the config.* in our svn by the system config.*. This is fixed for future apr releases. Cool, thanks. No need for current thanks, that was fixed long a go, but needs a new apr release to become effective. One new finding (but not a regression): when building with gcc 4.6.2 configure fails during the version check for an external apr-util. gcc 4.6.2 aborts when parsing apu_version.h because the file includes apr_version.h and the configure check has only includes set for apu, so the external apr_version.h is not found. Older gcc 4.1.2 also outputs an error but does not abort so for the older gcc the check succeeds. I will propose a fix. Hmmm? So, attempting to use external apr-util, where no external apr exists? That would not be possible, since apr-util required apr in the first place; right? No, apr and apr-util both were external but not in any default system path. We add apu-1-confg --includes to CPPFLAGS and then use CPP and apu_version.h to detect which version we have. That works for most gcc versions, but recent gcc chokes, because apu_version.h includes apr_version.h, which can not be found due to our setting of CPPFLAGS. gcc 4.6.2 based cpp then aborts parsing apu_version.h and our version check fails. Adding apu-1-confg --includes *plus* apr-1-confg --includes to CPPFLAGS before the version check fixes this. Regards, Rainer
Re: [Vote] httpd 2.2.22 release
On 1/30/2012 4:02 AM, Rainer Jung wrote: We add apu-1-confg --includes to CPPFLAGS and then use CPP and apu_version.h to detect which version we have. That works for most gcc versions, but recent gcc chokes, because apu_version.h includes apr_version.h, which can not be found due to our setting of CPPFLAGS. gcc 4.6.2 based cpp then aborts parsing apu_version.h and our version check fails. Adding apu-1-confg --includes *plus* apr-1-confg --includes to CPPFLAGS before the version check fixes this. That is a bug in apu-1-config; which must include the apr-1 path in its reported --includes (and --libs). An apu which isn't usable because it doesn't resolve apr is worthless. That's how all .pc and other include/lib resolvers are supposed to behave. The same must be true for the linker.
Re: [Vote] httpd 2.2.22 release
On 30.01.2012 19:10, William A. Rowe Jr. wrote: On 1/30/2012 4:02 AM, Rainer Jung wrote: We add apu-1-confg --includes to CPPFLAGS and then use CPP and apu_version.h to detect which version we have. That works for most gcc versions, but recent gcc chokes, because apu_version.h includes apr_version.h, which can not be found due to our setting of CPPFLAGS. gcc 4.6.2 based cpp then aborts parsing apu_version.h and our version check fails. Adding apu-1-confg --includes *plus* apr-1-confg --includes to CPPFLAGS before the version check fixes this. That is a bug in apu-1-config; which must include the apr-1 path in its reported --includes (and --libs). An apu which isn't usable because it doesn't resolve apr is worthless. I proposed the same patch as was applied long ago for trunk earliert today for 2.2. That patch does not change apu-1-config behaviour. Not sure whether I agree that apu should provide info about apr, since one could argue that that's what apr-1-config is for. So I cross post dev@apr and this part of the discussion could proceed there. That's how all .pc and other include/lib resolvers are supposed to behave. The same must be true for the linker. Regards, Rainer
Re: [Vote] httpd 2.2.22 release
On 1/30/2012 12:27 PM, Rainer Jung wrote: On 30.01.2012 19:10, William A. Rowe Jr. wrote: On 1/30/2012 4:02 AM, Rainer Jung wrote: We add apu-1-confg --includes to CPPFLAGS and then use CPP and apu_version.h to detect which version we have. That works for most gcc versions, but recent gcc chokes, because apu_version.h includes apr_version.h, which can not be found due to our setting of CPPFLAGS. gcc 4.6.2 based cpp then aborts parsing apu_version.h and our version check fails. Adding apu-1-confg --includes *plus* apr-1-confg --includes to CPPFLAGS before the version check fixes this. That is a bug in apu-1-config; which must include the apr-1 path in its reported --includes (and --libs). An apu which isn't usable because it doesn't resolve apr is worthless. I proposed the same patch as was applied long ago for trunk earliert today for 2.2. That patch does not change apu-1-config behaviour. Not sure whether I agree that apu should provide info about apr, since one could argue that that's what apr-1-config is for. So I cross post dev@apr and this part of the discussion could proceed there. That's how all .pc and other include/lib resolvers are supposed to behave. The same must be true for the linker. You might want to review man pkg-config --cflags. Note --includes is in the plural. If the user can't use the apu_dbd API by simply plugging in apr-util, then we did something wrong.
Re: [Vote] httpd 2.2.22 release
On 1/25/2012 4:59 PM, William A. Rowe Jr. wrote: There are two considerations, as Jim pointed out. First a choice; [ ] Include apr-util 1.4.1 in any httpd 2.2.x [ ] Remain at apr-util 1.3.12 in any httpd 2.2.x The concensus was for apr-util 1.4.1 to be included. Thanks for chiming in! +/-1 [ ] Release httpd 2.2.22 [with apr-util 1.4.1] as GA Passes with +1's from wrowe, sf, rjung, and covener, thanks for reviewing! The release will be tomorrow once the mirrors have synced. I'm happy to RM 2.0.65 just as soon as we've emptied SHOWSTOPPERS.
Re: [Vote] httpd 2.2.22 release
On Mon, Jan 30, 2012 at 4:57 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/25/2012 4:59 PM, William A. Rowe Jr. wrote: There are two considerations, as Jim pointed out. First a choice; [ ] Include apr-util 1.4.1 in any httpd 2.2.x [ ] Remain at apr-util 1.3.12 in any httpd 2.2.x The concensus was for apr-util 1.4.1 to be included. Thanks for chiming in! +/-1 [ ] Release httpd 2.2.22 [with apr-util 1.4.1] as GA Passes with +1's from wrowe, sf, rjung, and covener, thanks for reviewing! The release will be tomorrow once the mirrors have synced. cool!
Re: [Vote] httpd 2.2.22 release
On Saturday 28 January 2012, William A. Rowe Jr. wrote: On 1/25/2012 5:05 PM, William A. Rowe Jr. asked: [ ] Include apr-util 1.4.1 in any httpd 2.2.x [ ] Remain at apr-util 1.3.12 in any httpd 2.2.x So far, the tally remains 1.4.1 - jim, wrowe 1.3.12 - [none] Anyone else? Or do people believe this sort of change isn't worth some discussion/vote? Lazy consensus/silence can lead to an assortment of assumptions. I am in favor of 1.4.1, too. The likelyhood for breakage seems low enough.
Re: [Vote] httpd 2.2.22 release
On 25.01.2012 23:59, William A. Rowe Jr. wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow shortly, once I fix the release.sh breakage. There are two considerations, as Jim pointed out. First a choice; [X] Include apr-util 1.4.1 in any httpd 2.2.x [ ] Remain at apr-util 1.3.12 in any httpd 2.2.x IMHO 1.4.1 is an acceptable risk. And the vote (I'll have to resubmit if the preference is 1.3.12, but here goes); +/-1 [ +1] Release httpd 2.2.22 [with apr-util 1.4.1] as GA +1 for release using APU 1.4.1. Overview: Minor problem (not a regression): config.guess and config.sub are a bit old (2008) due to buildconf in the released apr overwriting the config.* in our svn by the system config.*. This is fixed for future apr releases. One new finding (but not a regression): when building with gcc 4.6.2 configure fails during the version check for an external apr-util. gcc 4.6.2 aborts when parsing apu_version.h because the file includes apr_version.h and the configure check has only includes set for apu, so the external apr_version.h is not found. Older gcc 4.1.2 also outputs an error but does not abort so for the older gcc the check succeeds. I will propose a fix. One non-reproducible test failure for test 150 in t/ssl/proxy.t on Solaris 10 using external libs: # Failed test 150 in .../Apache-Test/lib/Apache/TestCommonPost.pm at line 131 fail #131 #lwp request: #POST https://localhost:8549/eat_post HTTP/1.0 #User-Agent: libwww-perl/5.836 #Content-Length: 29696 # #server response: #HTTP/1.1 502 Proxy Error #Connection: close #Date: Sun, 29 Jan 2012 10:43:26 GMT #Content-Length: 396 #Content-Type: text/html; charset=iso-8859-1 #Client-Date: Sun, 29 Jan 2012 10:43:26 GMT #Client-Peer: 127.0.0.1:8549 #Client-SSL-Cert-Issuer: /C=US/ST=California/L=San Francisco/O=ASF/OU=httpd-test/CN=ca/emailAddress=test-...@httpd.apache.org #Client-SSL-Cert-Subject: /C=US/ST=California/L=San Francisco/O=ASF/OU=httpd-test/rsa-test/CN=localhost/emailAddress=test-...@httpd.apache.org #Client-SSL-Cipher: DHE-RSA-AES256-SHA #Client-SSL-Warning: Peer certificate not verified #Title: 502 Proxy Error # # testing : length posted # expected: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN # htmlhead # title502 Proxy Error/title # /headbody # h1Proxy Error/h1 # pThe proxy server received an invalid^M [Sun Jan 29 11:43:26 2012] [debug] ssl_engine_io.c(1908): OpenSSL: I/O error, 5 bytes expected to read on BIO#50841f8 [mem: 50ec3c8] [Sun Jan 29 11:43:26 2012] [debug] ssl_engine_io.c(1869): | 1260: 07 40 91 02 c8 ab a0 5e-5b 2a c0 57 1b 65 c6 39 .@.^[*.W.e.9 | [Sun Jan 29 11:43:26 2012] [info] [client 127.0.0.1] (70007)The timeout specified has expired: SSL input filter read failed. [Sun Jan 29 11:43:26 2012] [debug] ssl_engine_io.c(1869): | 1270: 2f 96 b7 bd c7 5e 28 2f-ee 9f 07 8c b2 3c 57 4e /^(/.WN | [Sun Jan 29 11:43:26 2012] [debug] ssl_engine_io.c(1869): | 1280: 86 9a 6e da e6 61 4d 2b-ec 94 70 cb a0 35 f7 74 ..n..aM+..p..5.t | ... [Sun Jan 29 11:43:26 2012] [debug] ssl_engine_kernel.c(1879): OpenSSL: Read: SSL negotiation finished successfully [Sun Jan 29 11:43:26 2012] [error] [client 127.0.0.1] (70014)End of file found: proxy: error reading status line from remote server localhost:8532 [Sun Jan 29 11:43:26 2012] [debug] mod_proxy_http.c(1466): [client 127.0.0.1] proxy: NOT Closing connection to client although reading from backend server localhost:8532 failed. [Sun Jan 29 11:43:26 2012] [error] [client 127.0.0.1] proxy: Error reading from remote server returned by /eat_post [Sun Jan 29 11:43:26 2012] [debug] proxy_util.c(2029): proxy: HTTPS: has released connection for (localhost) [Sun Jan 29 11:43:26 2012] [error] Optional function test said: POST /eat_post HTTP/1.0 [Sun Jan 29 11:43:26 2012] [error] Optional hook test said: POST /eat_post HTTP/1.0 [Sun Jan 29 11:43:26 2012] [debug] ssl_engine_kernel.c(1884): OpenSSL: Write: SSL negotiation finished successfully [Sun Jan 29 11:43:26 2012] [info] [client 127.0.0.1] Connection closed to child 65 with standard shutdown (server localhost:8549) Two additional failures only happen when I use a very recent Perl plus modules: tests 2+3 in t/security/CVE-2008-2364.t fail, because the Perl client reads status 100 instead of 200 resp. 502. Checking our logs indicates we did send the right status codes. So this seems to be a test framework problem. Details: - Signature and Hashes OK - key in KEYS file - gz and bz2 contents identical - no unexpected diff to svn tag - built and tested on - Solaris 8+10 Sparc - SuSE Linux Enterprise 10 (32Bit and 64Bit) - SLES 11 (64 Bit) - RedHat Enterprise Linux 5/6 64Bit - builds fine using gcc - out of tree - with all, most and default module sets - with either default (static) or shared linked modules - MPMs
Re: [Vote] httpd 2.2.22 release
On Wednesday 25 January 2012, William A. Rowe Jr. wrote: [ X ] Release httpd 2.2.22 [with apr-util 1.4.1] as GA +1
Re: [Vote] httpd 2.2.22 release
On 1/29/2012 3:18 PM, Rainer Jung wrote: Overview: Minor problem (not a regression): config.guess and config.sub are a bit old (2008) due to buildconf in the released apr overwriting the config.* in our svn by the system config.*. This is fixed for future apr releases. Cool, thanks. One new finding (but not a regression): when building with gcc 4.6.2 configure fails during the version check for an external apr-util. gcc 4.6.2 aborts when parsing apu_version.h because the file includes apr_version.h and the configure check has only includes set for apu, so the external apr_version.h is not found. Older gcc 4.1.2 also outputs an error but does not abort so for the older gcc the check succeeds. I will propose a fix. Hmmm? So, attempting to use external apr-util, where no external apr exists? That would not be possible, since apr-util required apr in the first place; right?
Re: [Vote] httpd 2.2.22 release
On 1/25/2012 5:05 PM, William A. Rowe Jr. asked: [ ] Include apr-util 1.4.1 in any httpd 2.2.x [ ] Remain at apr-util 1.3.12 in any httpd 2.2.x So far, the tally remains 1.4.1 - jim, wrowe 1.3.12 - [none] Anyone else? Or do people believe this sort of change isn't worth some discussion/vote? Lazy consensus/silence can lead to an assortment of assumptions.
Re: [Vote] httpd 2.2.22 release
On Sat, Jan 28, 2012 at 1:29 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/25/2012 5:05 PM, William A. Rowe Jr. asked: [ ] Include apr-util 1.4.1 in any httpd 2.2.x [ ] Remain at apr-util 1.3.12 in any httpd 2.2.x So far, the tally remains 1.4.1 - jim, wrowe 1.3.12 - [none] Anyone else? Or do people believe this sort of change isn't worth some discussion/vote? Lazy consensus/silence can lead to an assortment of assumptions. no pref here
Re: [Vote] httpd 2.2.22 release
On Sat, Jan 28, 2012 at 1:29 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/25/2012 5:05 PM, William A. Rowe Jr. asked: [ ] Include apr-util 1.4.1 in any httpd 2.2.x [ ] Remain at apr-util 1.3.12 in any httpd 2.2.x So far, the tally remains 1.4.1 - jim, wrowe 1.3.12 - [none] Anyone else? Or do people believe this sort of change isn't worth some discussion/vote? Lazy consensus/silence can lead to an assortment of assumptions. I'm leaning towards 1.3.12 for the bundled version. When there's 1.4.2 with rough edges resolved, that's another matter. I need to revisit the theory of 2.2/1.3.12 and 2.4/1.4.1 collision. I guess that implies certain non-default layouts?
Re: [Vote] httpd 2.2.22 release
On 28 Jan 2012, at 8:29 PM, William A. Rowe Jr. wrote: [ ] Include apr-util 1.4.1 in any httpd 2.2.x [ ] Remain at apr-util 1.3.12 in any httpd 2.2.x So far, the tally remains 1.4.1 - jim, wrowe 1.3.12 - [none] Anyone else? Or do people believe this sort of change isn't worth some discussion/vote? Lazy consensus/silence can lead to an assortment of assumptions. Another +1 for v1.4.1. We have a very strict ABI policy for apr and apr-util which should mean that within reason v1.4.1 should contain additions and bugfixes over v1.3.12, but no changes of existing functionality, and the bump is therefore low risk. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: [Vote] httpd 2.2.22 release
On Wed, Jan 25, 2012 at 5:59 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow shortly, once I fix the release.sh breakage. I see a t/apache/limits.t failure related to CVE-2012-0053 that I do not yet understand.
Re: [Vote] httpd 2.2.22 release
On Sat, Jan 28, 2012 at 1:50 PM, Eric Covener cove...@gmail.com wrote: On Wed, Jan 25, 2012 at 5:59 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow shortly, once I fix the release.sh breakage. I see a t/apache/limits.t failure related to CVE-2012-0053 that I do not yet understand. Luckily this turns out to be a new test that is n/a to 2.2 not an issue with backport. -- Eric Covener cove...@gmail.com
Re: [Vote] httpd 2.2.22 release
+/-1 [ ] Release httpd 2.2.22 [with apr-util 1.4.1] as GA +1 -- framework runs clean on AIX/xlc/PPC64 and linuxmint/gcc/x86 Thanks for RM'ing.
Re: [Vote] httpd 2.2.22 release
On 1/25/2012 4:59 PM, William A. Rowe Jr. wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow shortly, once I fix the release.sh breakage. All was well, in the end. Windows binaries/symbols/sources are all up in /dev/dist, along with my vote... [+1] Release httpd 2.2.22 [with apr-util 1.4.1] as GA
Re: [Vote] httpd 2.2.22 release
On 1/25/2012 4:59 PM, William A. Rowe Jr. wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow shortly, once I fix the release.sh breakage. There are two considerations, as Jim pointed out. First a choice; [X] Include apr-util 1.4.1 in any httpd 2.2.x [ ] Remain at apr-util 1.3.12 in any httpd 2.2.x My preference; as explained in a note to Jim; Shipping APU 1.3.x means that current httpd 2.4 packages would be broken with an httpd 2.2 install. Not cool. E.g. apr-1.4/configure --prefix=/usr/local/; make; make install httpd-2.4/configure --prefix=/opt/test/newhttpd/; make; make install httpd-2.2/configure --prefix=/usr/local/; make; make install Bad mojo.
Re: [Vote] httpd 2.2.22 release
On Jan 25, 2012, at 6:05 PM, William A. Rowe Jr. wrote: On 1/25/2012 4:59 PM, William A. Rowe Jr. wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow shortly, once I fix the release.sh breakage. There are two considerations, as Jim pointed out. First a choice; [X] Include apr-util 1.4.1 in any httpd 2.2.x [ ] Remain at apr-util 1.3.12 in any httpd 2.2.x My preference; as explained in a note to Jim; Shipping APU 1.3.x means that current httpd 2.4 packages would be broken with an httpd 2.2 install. Not cool. As you know, there are no httpd 2.4 packages. Also, -deps is an optional package for 2.4.x, and so although we provide it, we don't know what versions people may or may not be using... With 2.2, the dependency in much tighter. As far as whether or not 2.2.x continues w/ apu-1.3 or moves to apu-1.4, all I wanted was the *group* to decide, not it just happen by a hidden fiat. Anyway, my vote: [X] Include apr-util 1.4.x in any httpd 2.2.x With this specifically mentioned in the release announcement (yes, we do list which versions, but it would be nice if we said: This release includes the Apache Portable Runtime (APR) version 1.4.5 and APR Utility Library (APR-util) version 1.3.12, bundled with the tar and zip distributions. Previous versions of Apache httpd bundled APR-util 1.3.x. ) This is so we pre-warn people, just in case.
Re: [Vote] httpd 2.2.22 release
On 1/25/2012 5:25 PM, Jim Jagielski wrote: Anyway, my vote: [X] Include apr-util 1.4.x in any httpd 2.2.x With this specifically mentioned in the release announcement (yes, we do list which versions, but it would be nice if we said: This release includes the Apache Portable Runtime (APR) version 1.4.5 and APR Utility Library (APR-util) version 1.3.12, bundled with the tar and zip distributions. Previous versions of Apache httpd bundled APR-util 1.3.x. ) This is so we pre-warn people, just in case. ++1 to clear notice! Obviously, this aspect had escaped me until this afternoon. This decision plus a release vote can happen simultaneously, and of course I commented the commit message. We all follow bugs@ and commit@ traffic, no? Nothing hidden.
Re: [Vote] httpd 2.2.22 release
On 25.01.2012 23:59, William A. Rowe Jr. wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow shortly, once I fix the release.sh breakage. Please also provide CHANGES_2.2 and CHANGES_2.2.22 on /dev/dist. Thanks, Rainer
Re: [Vote] httpd 2.2.22 release
On 1/25/2012 10:57 PM, Rainer Jung wrote: Please also provide CHANGES_2.2 and CHANGES_2.2.22 on /dev/dist. Done. Cleaned up 2.4 too. Thanks for the hint!
