You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2012/01/25 23:59:27 UTC
[Vote] httpd 2.2.22 release
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;
[ ] 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
And the vote (I'll have to resubmit if the preference is 1.3.12, but here goes);
+/-1
[ ] Release httpd 2.2.22 [with apr-util 1.4.1] as GA
Re: [Vote] httpd 2.2.22 release
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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
Posted by Eric Covener <co...@gmail.com>.
On Sat, Jan 28, 2012 at 1:50 PM, Eric Covener <co...@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
covener@gmail.com
Re: [Vote] httpd 2.2.22 release
Posted by Eric Covener <co...@gmail.com>.
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
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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!
Re: [Vote] httpd 2.2.22 release
Posted by Rainer Jung <ra...@kippdata.de>.
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
Posted by Eric Covener <co...@gmail.com>.
> +/-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: [Discuss] httpd 2.2.22 release
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Jan 28, 2012 at 2:16 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 1/28/2012 12:36 PM, Jeff Trawick wrote:
>>
>> When there's 1.4.2 with rough edges resolved, that's another matter.
>
> Depending on which rough edges, remember that autoconf is
> regenerated, ergo the legacy one. Not sure which rough
> edges you are most concerned about.
That's all I was thinking of. So no concern here. Thanks!
>> 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?
>
> --with-apr-util=builtin of 1.3 for httpd 2.2 - and yet installing
> to the /usr or /usr/local path, overwriting an already-installed 1.4.
>
> Nonstandard; httpd 2.2 and 2.4 in two different trees.
--
Born in Roswell... married an alien...
Re: [Discuss] httpd 2.2.22 release
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/28/2012 12:36 PM, Jeff Trawick wrote:
>
> When there's 1.4.2 with rough edges resolved, that's another matter.
Depending on which rough edges, remember that autoconf is
regenerated, ergo the legacy one. Not sure which rough
edges you are most concerned about.
> 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?
--with-apr-util=builtin of 1.3 for httpd 2.2 - and yet installing
to the /usr or /usr/local path, overwriting an already-installed 1.4.
Nonstandard; httpd 2.2 and 2.4 in two different trees.
Re: [Vote] httpd 2.2.22 release
Posted by Jeff Trawick <tr...@gmail.com>.
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
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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
Posted by Eric Covener <co...@gmail.com>.
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
Posted by Graham Leggett <mi...@sharp.fm>.
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
--
Re: [Vote] httpd 2.2.22 release
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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
Posted by Rainer Jung <ra...@kippdata.de>.
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
Posted by Rainer Jung <ra...@kippdata.de>.
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
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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
Posted by Rainer Jung <ra...@kippdata.de>.
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
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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
Posted by Rainer Jung <ra...@kippdata.de>.
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-dev@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-dev@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">
# <html><head>
# <title>502 Proxy Error</title>
# </head><body>
# <h1>Proxy Error</h1>
# <p>The 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 prefork, worker, event (where applicable)
- dependencies apr/apu/expat/pcre/openssl:
a) all bundled
b) 1.4.5/(1.3.12|1.4.1)/2.0.1/8.21/0.9.8t
- config.(guess|sub) outdated (see above)
- configure fails for gcc 4.6.2 with external apr/apu
(see above)
- test suite ran for all those builds with log levels
info and debug
- no test regressions w.r.t. at least 2.2.16-2.2.21:
- Failed test 2 in t/ssl/extlookup.t at line 27
- Failed test 9 in t/ssl/require.t at line 44
For details about both see my 2.2.19 voting mail.
- 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.
- one non-reproducible test failure in t/ssl/proxy for test 150
Note that on the platforms RHEL 5/6, SLES 11 and Solaris 8 tests are
still running, but for the other platforms I have complete results and
for the remaining platforms until now all results are consistent.
Regards,
Rainer
Re: [Vote] httpd 2.2.22 release
Posted by Jeff Trawick <tr...@gmail.com>.
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
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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.