httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: [Vote] httpd 2.2.23 release
Date Thu, 23 Aug 2012 19:58:51 GMT
On 21.08.2012 21:25, 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 sometime later
> this evening.
>
> Feedback and edits to the draft announcement are greatly appreciated,
> since we need to better position 2.2 as 'just maintenance' and we can
> drop some of the 'shiny new' bits of that Announcement text, given that
> it is old hat now, and they should be reading the 2.4 Announce (which
> this document now links to).
>
> So, for your consideration, a vote...
>
>   +/-1
>   [+1]  Release httpd 2.2.23 as GA

Build problems:

Build problems on SLES 10 when using bundled APR and OpenSSL 1.0.1c as 
static libs. It's due to a bug in pkg-config on SuSe Linux, which does 
not preserve order of -l flags when a.pc file also contains a 
Libs.private entry. I built a pkg-config 0.23 which contains a patch for 
that and the problem was gone. Not httpd's fault.

Problem with configure on Linux when using external PCRE in a non-system 
path. configure puts -lpcre into the LIBS early and the later tests all 
fail, when they try to run the contest binary, because the pcre lib can 
not be found. IT#s a bit unfortunate, that all libs needed to build 
httpd are added as libs during all configure tests after the respective 
--with flag. Workaround is setting LD_LIBRARY_PATH just during 
configure. Works out of the box on Solaris, because "pcre-config --libs" 
on Solaris also outputs a "-R" flag.

Test suite:

Two failures only happen when I use a very recent LWP Perl module 
(version 6.0.3 and above): 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. Don't know how a workaround in the 
framework would be.

Failed test 2 in t/ssl/extlookup.t and 9 in t/ssl/require.t - not a 
regression.

Details:

- win32 artefacts not checked, because not yet available
- 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.6/1.4.1/2.1.0/8.30/1.0.1c
   - configure fails for external non system pcre
     (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.22:
     - 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.
   - Failed tests 2+3 in t/security/CVE-2008-2364.t when
     using LWP 6.0.3 or above

Regards,

Rainer

Mime
View raw message