Re: Time for 2.4.4
On 16.02.2013 15:50, Jim Jagielski wrote: > I plan to T&R on Monday (Feb 18) afternoon (eastern time)... > > On Feb 1, 2013, at 9:15 AM, Jim Jagielski wrote: > >> I think it's about time for 2.4.4... just a handful >> of proposed backports are still open. I propose we >> do a T&R the end of next week with a release the >> week after that. I'll be RM. Info: I ran the test suite and got no failures. Tested configuration: - current 2.4.4 HEAD with APR/APU 1.4.6/1.5.1 - using shared modules "reallyall" and --enable-load-all-modules - tested for prefork, worker and event - each MPM tested with log level info, debug and trace8 - platform Solaris 10 Sparc 32 Bit build - Libraries Expat 2.1.0, PCRE 8.32, OpenSSL 1.0.1e with a few patches, Lua 5.2.1, LibXML2 2.9.0. - Tool chain: gcc 4.7.2, CFLAGS -O2 -g -Wall -fno-strict-aliasing -mpcu=v9 Regards, Rainer
Re: Time [also] for 2.2.24
On 16.02.2013 19:07, William A. Rowe Jr. wrote: > On Fri, 15 Feb 2013 04:48:42 -0600 > "William A. Rowe Jr." wrote: >> >> I plan to tag between late Friday 15 Feb eve, and Saturday. The >> remaining STATUS items only have a vote or two, or are contested >> and can't really be expected to hit this tag. It might be a bit >> late to add more to STATUS for consideration, but if you were >> going to evalute any of these patches, now is your opportunity. > > Shifting this to Mon 18 Feb afternoon to be in sync with 2.4.4, so > feel free to work on late additions this weekend through STATUS. Info: I ran the test suite and got no unknown or unexpected failures (details see below). Tested configuration: - current 2.2.x HEAD with APR/APU 1.4.6/1.5.1 - using shared modules "all" - tested for prefork, worker and event - each MPM tested with log level info and debug - platform Solaris 10 Sparc 32 Bit build - Libraries Expat 2.1.0 and PCRE 8.32 (or both bundled), OpenSSL 1.0.1e with a few patches - Tool chain: gcc 4.7.2, CFLAGS -O2 -g -Wall -fno-strict-aliasing -mpcu=v9 Known or expected failures: t/security/CVE-2005-3352.t (Wstat: 0 Tests: 2 Failed: 1) Failed test: 2 It fails, because the test is already adjusted for a 2.4 backport that's waiting for the third vote in 2.2 STATUS (last item in the proposed backports list). t/security/CVE-2008-2364.t (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 Perl problem, no regression. t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1) Failed test: 2 t/ssl/require.t(Wstat: 0 Tests: 10 Failed: 1) Failed test: 9 Both fail at least since 2.2.16, so no regression. Regards, Rainer
2.4 rewritebase
I am on the road right now, but a user reported that my fix to make rewritebase merging opt-in is busted and breaks normal override by default. Can someone look/repair/propose for 24?
Re: Time [also] for 2.2.24
I really need to learn how to do the tests you guys do. iirc it is not as simple as "make check" or "make test". It will wait til 2.2.25 if it must, but I have some scripts to autostart/stop httpd on AIX - must load a system to see if they are already in 2.2.X. If not, who can I send the changes to? Congratulations on the new release btw! Michael On Mon, Feb 18, 2013 at 4:47 PM, Rainer Jung wrote: > On 16.02.2013 19:07, William A. Rowe Jr. wrote: > > On Fri, 15 Feb 2013 04:48:42 -0600 > > "William A. Rowe Jr." wrote: > >> > >> I plan to tag between late Friday 15 Feb eve, and Saturday. The > >> remaining STATUS items only have a vote or two, or are contested > >> and can't really be expected to hit this tag. It might be a bit > >> late to add more to STATUS for consideration, but if you were > >> going to evalute any of these patches, now is your opportunity. > > > > Shifting this to Mon 18 Feb afternoon to be in sync with 2.4.4, so > > feel free to work on late additions this weekend through STATUS. > > Info: I ran the test suite and got no unknown or unexpected failures > (details see below). > > Tested configuration: > > - current 2.2.x HEAD with APR/APU 1.4.6/1.5.1 > - using shared modules "all" > - tested for prefork, worker and event > - each MPM tested with log level info and debug > - platform Solaris 10 Sparc 32 Bit build > - Libraries Expat 2.1.0 and PCRE 8.32 (or both bundled), > OpenSSL 1.0.1e with a few patches > - Tool chain: gcc 4.7.2, > CFLAGS -O2 -g -Wall -fno-strict-aliasing -mpcu=v9 > > Known or expected failures: > > t/security/CVE-2005-3352.t (Wstat: 0 Tests: 2 Failed: 1) > Failed test: 2 > It fails, because the test is already adjusted for a 2.4 backport that's > waiting for the third vote in 2.2 STATUS (last item in the proposed > backports list). > > t/security/CVE-2008-2364.t (Wstat: 0 Tests: 3 Failed: 2) > Failed tests: 2-3 > Perl problem, no regression. > > t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1) > Failed test: 2 > t/ssl/require.t(Wstat: 0 Tests: 10 Failed: 1) > Failed test: 9 > Both fail at least since 2.2.16, so no regression. > > Regards, > > Rainer >
Re: 2.4 rewritebase
Clue finally sunk in, now proposed. Thanks Rainer for the quick attn. On Mon, Feb 18, 2013 at 1:02 PM, Eric Covener wrote: > I am on the road right now, but a user reported that my fix to make > rewritebase merging opt-in is busted and breaks normal override by default. > Can someone look/repair/propose for 24? -- Eric Covener cove...@gmail.com
Re: 2.4 rewritebase
On 18.02.2013 19:02, Eric Covener wrote: > I am on the road right now, but a user reported that my fix to make > rewritebase merging opt-in is busted and breaks normal override by > default. Can someone look/repair/propose for 24? You beat me to it. If we think that the merging/inheritance of RewriteBase by default is wrong, we should also backport your RewriteOption MergeBase (r1418954) and the tiny fix for it you just now added to the 2.4 STATUS to 2.2 as well? At least we have PR 53963 open about the new merge behavior in 2.2.23. I guess I will add a backport suggestion to the 2.2.x STATUS. Regards, Rainer
Re: 2.4 rewritebase
On Mon, Feb 18, 2013 at 2:00 PM, Rainer Jung wrote: > On 18.02.2013 19:02, Eric Covener wrote: >> I am on the road right now, but a user reported that my fix to make >> rewritebase merging opt-in is busted and breaks normal override by >> default. Can someone look/repair/propose for 24? > > You beat me to it. > > If we think that the merging/inheritance of RewriteBase by default is > wrong, we should also backport your RewriteOption MergeBase (r1418954) > and the tiny fix for it you just now added to the 2.4 STATUS to 2.2 as > well? At least we have PR 53963 open about the new merge behavior in 2.2.23. > > I guess I will add a backport suggestion to the 2.2.x STATUS. Yes I agree, that original report actually has no relief queued up in 2.2.24. The reporter contacted me off-list and was running a personal build with the trunk change in 2.2 and realized it was broken.
Re: Time [also] for 2.2.24
On 18.02.2013 19:45, Michael Felt wrote: > I really need to learn how to do the tests you guys do. iirc it is not > as simple as "make check" or "make test". For starters there's a README at: http://svn.apache.org/viewvc/httpd/test/framework/trunk/README?view=co You'll need Perl plus the Perl module bundle Apache-Test/lib/Bundle/ApacheTest.pm as explained in the README. If your Perl is old, the bundle might install more dependency modules. The modules also require some libraries installed, especially openssl. Then you'll need an installed httpd and make sure the you load all modules you want to test in the httpd.conf. Finally you check out http://svn.apache.org/repos/asf/httpd/test/framework/trunk/ and run the Perl test framework from there as described in the README. Regards, Rainer
Re: Time [also] for 2.2.24
On 18.02.2013 19:45, Michael Felt wrote: > It will wait til 2.2.25 if it must, but I have some scripts to > autostart/stop httpd on AIX - must load a system to see if they are > already in 2.2.X. If not, who can I send the changes to? You should start with a script for 2.4.x. Example is the file build/rpm/httpd.init in the source tree which gets installed via the SPEC file ./build/rpm/httpd.spec.in. Patches or additions can always be attached to a new Bugzilla entry. If needed you can send a heads-up to this list here. Unrelated note: please do start a separate mail thread with a subject that reflects the discussion topic. Following long mail threads that completely change their topic is hard. Regards, Rainer
Re: 2.4 rewritebase
On Mon, 18 Feb 2013 14:15:45 -0500 Eric Covener wrote: > On Mon, Feb 18, 2013 at 2:00 PM, Rainer Jung > wrote: > > On 18.02.2013 19:02, Eric Covener wrote: > >> I am on the road right now, but a user reported that my fix to make > >> rewritebase merging opt-in is busted and breaks normal override by > >> default. Can someone look/repair/propose for 24? > > > > You beat me to it. > > > > If we think that the merging/inheritance of RewriteBase by default > > is wrong, we should also backport your RewriteOption MergeBase > > (r1418954) and the tiny fix for it you just now added to the 2.4 > > STATUS to 2.2 as well? At least we have PR 53963 open about the new > > merge behavior in 2.2.23. > > > > I guess I will add a backport suggestion to the 2.2.x STATUS. > > Yes I agree, that original report actually has no relief queued up in > 2.2.24. > > The reporter contacted me off-list and was running a personal build > with the trunk change in 2.2 and realized it was broken. Ok, so 2.2.23 had not suffered this regression yet? If not, we should just move ahead and then can consider any improved behavior in 2.2.x. There are no changes to mod_rewrite in 2.2.x since 2.2.23 was tagged.
[VOTE] Release Apache httpd 2.4.4 as GA
The pre-release test tarballs for Apache httpd 2.4.4 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.4 GA. NOTE: The -deps tarballs are included here *only* to make life easier for the tester. They will not be, and are not, part of the official release. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs.
Re: 2.4 rewritebase
> Ok, so 2.2.23 had not suffered this regression yet? If not, we should > just move ahead and then can consider any improved behavior in 2.2.x. > There are no changes to mod_rewrite in 2.2.x since 2.2.23 was tagged. 2.2.23 has _a_ rewritebase regression reported a number of places. My recent fire drill was a regression in the fix for that original regression. I'd like it in, but appreciate tough spot as RM -- your call.
Re: 2.4 rewritebase
On Mon, 18 Feb 2013 15:36:17 -0500 Eric Covener wrote: > > Ok, so 2.2.23 had not suffered this regression yet? If not, we > > should just move ahead and then can consider any improved behavior > > in 2.2.x. There are no changes to mod_rewrite in 2.2.x since 2.2.23 > > was tagged. > > 2.2.23 has _a_ rewritebase regression reported a number of places. My > recent fire drill was a regression in the fix for that original > regression. > > I'd like it in, but appreciate tough spot as RM -- your call. What version was this introduced? Is there a good reference PR?
Re: 2.4 rewritebase
On 18.02.2013 21:36, Eric Covener wrote: >> Ok, so 2.2.23 had not suffered this regression yet? If not, we should >> just move ahead and then can consider any improved behavior in 2.2.x. >> There are no changes to mod_rewrite in 2.2.x since 2.2.23 was tagged. > > 2.2.23 has _a_ rewritebase regression reported a number of places. My > recent fire drill was a regression in the fix for that original > regression. > > I'd like it in, but appreciate tough spot as RM -- your call. Same here. The regression in 2.2.23 is that RewriteBase started to get merged in 2.2.23. It wasn't before. This seems to have broken certain setups. PR 53963. Eric has provided a "RewriteOptions MergeBase" which is off by default (no more merging) and allows to switch the bahvior on if wanted. The first impl of that had a bug, which is why we had a last minute change to it today. Regards, Rainer
Re: 2.4 rewritebase
On 18.02.2013 21:47, Rainer Jung wrote: > On 18.02.2013 21:36, Eric Covener wrote: >>> Ok, so 2.2.23 had not suffered this regression yet? If not, we should >>> just move ahead and then can consider any improved behavior in 2.2.x. >>> There are no changes to mod_rewrite in 2.2.x since 2.2.23 was tagged. >> >> 2.2.23 has _a_ rewritebase regression reported a number of places. My >> recent fire drill was a regression in the fix for that original >> regression. >> >> I'd like it in, but appreciate tough spot as RM -- your call. > > Same here. > > The regression in 2.2.23 is that RewriteBase started to get merged in > 2.2.23. It wasn't before. This seems to have broken certain setups. PR > 53963. > > Eric has provided a "RewriteOptions MergeBase" which is off by default > (no more merging) and allows to switch the bahvior on if wanted. The > first impl of that had a bug, which is why we had a last minute change > to it today. Two more data points for 2.2: - the merging of RewriteBase was a side effect of *) mod_rewrite: Fix the RewriteEngine directive to work within a location. Previously, once RewriteEngine was switched on globally, it was impossible to switch off. - the commit was r1375113 Regards, Rainer
Re: 2.4 rewritebase
On Mon, 18 Feb 2013 21:53:16 +0100 Rainer Jung wrote: > On 18.02.2013 21:47, Rainer Jung wrote: > > On 18.02.2013 21:36, Eric Covener wrote: > > > > The regression in 2.2.23 is that RewriteBase started to get merged > > in 2.2.23. It wasn't before. This seems to have broken certain > > setups. PR 53963. > > > > Eric has provided a "RewriteOptions MergeBase" which is off by > > default (no more merging) and allows to switch the bahvior on if > > wanted. The first impl of that had a bug, which is why we had a > > last minute change to it today. > > Two more data points for 2.2: > > - the merging of RewriteBase was a side effect of > > *) mod_rewrite: Fix the RewriteEngine directive to work within a > location. Previously, once RewriteEngine was switched on > globally, it was impossible to switch off. > > - the commit was r1375113 Technically the fix appears correct, when compared to the initial patch. I would rather not race through this without one more folk to test out this change, needs not be a committer, I just added a beg on PR 53963 for review (there seem to be three watchers right now). I'll tag and roll an 1.25 hrs from now so you are welcome to do the backport honors Rainer... then hopefully nobody raises the red flag before I lay down that tag.
Re: 2.4 rewritebase
On 18.02.2013 22:16, William A. Rowe Jr. wrote: > On Mon, 18 Feb 2013 21:53:16 +0100 > Rainer Jung wrote: > >> On 18.02.2013 21:47, Rainer Jung wrote: >>> On 18.02.2013 21:36, Eric Covener wrote: >>> >>> The regression in 2.2.23 is that RewriteBase started to get merged >>> in 2.2.23. It wasn't before. This seems to have broken certain >>> setups. PR 53963. >>> >>> Eric has provided a "RewriteOptions MergeBase" which is off by >>> default (no more merging) and allows to switch the bahvior on if >>> wanted. The first impl of that had a bug, which is why we had a >>> last minute change to it today. >> >> Two more data points for 2.2: >> >> - the merging of RewriteBase was a side effect of >> >> *) mod_rewrite: Fix the RewriteEngine directive to work within a >> location. Previously, once RewriteEngine was switched on >> globally, it was impossible to switch off. >> >> - the commit was r1375113 > > Technically the fix appears correct, when compared to the initial > patch. I would rather not race through this without one more folk > to test out this change, needs not be a committer, I just added a > beg on PR 53963 for review (there seem to be three watchers right > now). I'll tag and roll an 1.25 hrs from now so you are welcome > to do the backport honors Rainer... then hopefully nobody raises > the red flag before I lay down that tag. I committed it now with a slightly clarified docs section about MergeBase. The OP in the PR has responded positively although I think he might have tested the previous, broken version. One would only notice the difference if one would actually set a RewriteBase in a dir and also in a sub dir. The original problem was I think just having one set in a dir and not wanting it inherited in the sub dirs. So in this case the broken fix would have kind of worked as well. Will hang around for another 1-2 hours before it's getting late here. Rainer
[VOTE] Release Apache httpd 2.2.24 as GA
The tarball candidates for Apache httpd 2.2.24 can be found at the usual place: http://httpd.apache.org/dev/dist/ Please VOTE for releasing this Apache httpd 2.2.24 candidate as GA. [ ] +1 for GA: Happy Birthday, 2.2.24. [ ] -1: Exterminate. (What broke?) Vote will last the normal 72 hrs.
Re: [VOTE] Release Apache httpd 2.4.4 as GA
On Mon, 2013-02-18 at 15:34 -0500, Jim Jagielski wrote: > The pre-release test tarballs for Apache httpd 2.4.4 can be found > at the usual place: > > http://httpd.apache.org/dev/dist/ > > I'm calling a VOTE on releasing these as Apache httpd 2.4.4 GA. > NOTE: The -deps tarballs are included here *only* to make life > easier for the tester. They will not be, and are not, part > of the official release. > > [ ] +1: Good to go > [ ] +0: meh > [ ] -1: Danger Will Robinson. And why. > > Vote will last the normal 72 hrs. -1 Slackware 13.1 and 13.37 Builds fine but operation now fails on all mysql auths (included APR problem from -deps ??) reports: APR-util Version: 1.5.1 [Tue Feb 19 13:16:33.487932 2013] [auth_basic:error] [pid 24811:tid 2996689776] [client xxx] AH01617: user noel: authentication failure for "/": Password Mismatch This is browser stored password , cleared, entered still fails, different browser, same, fails make install back in 2.4.3, and all mysql auths once again succeed have tested overwrites, and clearing of all bin/ build/ lib/ and fresh installs no change. SQL: 29 Prepare SELECT Password FROM users WHERE User = ? 29 Close stmt 29 Quit Built as (no change since 2.4.0): ./configure --prefix=/usr/local/apache --enable-so --enable-modules=all --enable-mods-static=all --disable-dav --enable-suexec --with-suexec-docroot=/var/www --with-suexec-caller=apache --with-suexec-logfile=/var/log/apache/suexec_log --with-included-apr --with-mysql --disable-util-dso --enable-ssl ldd /usr/local/apache/bin/httpd libmysqlclient.so.18 => /usr/lib/mysql/libmysqlclient.so.18 (0xb7159000) libaprutil-1.so.0 => /usr/local/apache/lib/libaprutil-1.so.0 (0xb742a000) /usr/local/apache/bin/httpd -t Syntax OK -t -D DUMP_MODULES |grep dbd authn_dbd_module (static) authz_dbd_module (static) dbd_module (static) session_dbd_module (static) signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache httpd 2.4.4 as GA
On Tue, 2013-02-19 at 13:35 +1000, Noel Butler wrote: > reports: APR-util Version: 1.5.1 I note the APR version in -deps is only 1.4.6, but APR-utils is 1.5.1 could this be the issue? signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache httpd 2.4.4 as GA
On Tue, 19 Feb 2013 14:11:59 +1000 Noel Butler wrote: > On Tue, 2013-02-19 at 13:35 +1000, Noel Butler wrote: > > > > reports: APR-util Version: 1.5.1 > > > I note the APR version in -deps is only 1.4.6, but APR-utils is 1.5.1 > could this be the issue? No. APR doesn't care about the APR-util version at all. APR-util should not compile if it is missing an APR feature. Their version numbers do not correspond (except at the version major level). > Builds fine but operation now fails on all mysql auths (included APR > problem from -deps ??) > reports: APR-util Version: 1.5.1 > > [Tue Feb 19 13:16:33.487932 2013] [auth_basic:error] [pid 24811:tid > 2996689776] [client xxx] AH01617: user noel: authentication > failure for "/": Password Mismatch > > This is browser stored password , cleared, entered still fails, > different browser, same, fails > make install back in 2.4.3, and all mysql auths once again succeed > > have tested overwrites, and clearing of all bin/ build/ lib/ and fresh > installs no change. You cleaned lib/ of all *subdirectories*? Does an older lib/apr-util-1/apr_dbd_mysql-1.so appear in that tree? Or in your LD_LIBRARY_PATH? Or did apr-util fail to detect mysql? You will need to review your ./configure output to work out what apr-util thinks it found. Maybe you are simply missing a mysql-devel package?
Re: [VOTE] Release Apache httpd 2.4.4 as GA
Hi Bill, On Mon, 2013-02-18 at 23:23 -0600, William A. Rowe Jr. wrote: > in -deps is only 1.4.6, but APR-utils is 1.5.1 > > have tested overwrites, and clearing of all bin/ build/ lib/ and fresh > > installs no change. > > You cleaned lib/ of all *subdirectories*? > I install httpd under /usr/local/apache, so its all safe as clearing it out simulates as a fresh install, fresh with 2.4.4 fails mysql based auths, fresh install 2.4.3 (like all others since 2.18 when it got incorporated) succeed happily. > Does an older lib/apr-util-1/apr_dbd_mysql-1.so appear in that tree? I also build everything in, not as DSO's, I always found that horribly messy, what I do have is libapr stuff in there, and yes, fresh copies. > Or in your LD_LIBRARY_PATH? Or did apr-util fail to detect mysql? You > will need to review your ./configure output to work out what apr-util > thinks it found. > configure:19751: checking for mysql_config configure:19769: found /usr/bin/mysql_config configure:19781: result: /usr/bin/mysql_config configure:19841: checking for mysql.h configure:19841: gcc -c -g -O2 -pthread -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include/mysql conftest.c >&5In file included from /usr/include/mysql/my_global.h:77, from conftest.c:20: configure:19872: gcc -o conftest -g -O2 -pthread -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include/mysql conftest.c -lmysqlclient_r -L/usr/lib/mysql -lmysqlclient_r -lpthread -lz -lm -lrt -lssl -lcrypto -ldl >&5 configure:19872: $? = 0 configure:19881: result: yes seems it found it and is mostly happy, I am only assuming its APR related, it might not be. > Maybe you are simply missing a mysql-devel package? We only use sources, and even the official Slackware mysql packages is "as designed" IOW, none of this -dev or -devel or splitting something up into 150 different packages like a certain distro takes delight in, type of rubbish :) <> signature.asc Description: This is a digitally signed message part
