On 11.07.2013 20:54, Jim Jagielski wrote:
> The pre-release test tarballs for Apache httpd 2.4.5 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.5 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.
> 
> [X] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
> 
> Vote will last the normal 72 hrs.

+1 to release, thanks for RM.

Detailed report:

- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
  except for expected deltas
  (we could cleanup some m4 files in apr-util/xml/expat/conftools
   at the end of buildconf, no regression)

Built on

- Solaris 8+10 Sparc as 32 Bit Binaries
- SLES 10 (32/64 Bits)
- SLES 11 (64 Bits)
- RHEL 5 and 6 (64 Bits)
- FreeBSD 9 64 Bits

- with default (shared) and static modules
  - FreeBSD only shared
- with module sets none, few, most, all, reallyall and default
  (always mod_privileges disabled, FreeBSD only "all")
- using --enable-load-all-modules (except FreeBSD)
- against "included" APR/APU from later removed deps tarball,
  external APR/APU 1.4.8/1.5.2 (FreeBSD only bundled)

- using external libraries
  - expat 2.1.0 (FreeBSD 2.0.1)
  - pcre 8.33 (FreeBSD 8.32)
  - openssl 1.0.1e (plus a few patches)
  - lua 5.2.2 (not on FreeBSD)
  - distcache 1.5.1 (not on FreeBSD)
  - libxml2 2.9.1 (FreeBSD 2.8.0)

- Tool chain:
    - platform gcc except for Solaris
      (gcc 4.1.2 for Solaris 8 and 4.8.1 for Solaris 10)
    - CFLAGS: -O2 -g -Wall -fno-strict-aliasing
              (and -mpcu=v9 on Solaris)

All builds succeeded except for

- RHEL 6 64 Bits one of 20 builds crashed with a segfault in ksh.

Tested for

- Solaris 8+10 (32), SLES 10 (32/64), SLES 11 (64), RHEL 5+6 (64),
  FreeBSD 9 (64)
- MPMs prefork, worker, event (except for Solaris 8 - no event)
- default (shared) and static modules (FreeBSD only shared)
- log levels info, debug and trace8
- module set reallyall (121 modules plus MPMs), FreeBSD "all"
  - tests for "all", "most", "few", "none" and default module sets
    still running, but "reallyall" has best coverage

All Tests passed with the following exceptions (a-c not on FreeBSD):

a Test 5 in t/modules/dav.t:
  12 out of 680 runs had the "created" time after
  the "modified" time.
  This seems to be a system issue, all tests done on NFS,
  many tested on virtualized guests.
  Not a regression.

b Test 8 in t/ssl/pr12355.t:
  6 out of 680 runs failed this test,
  (4 RHEL 5, 1 on SLES 10 32 Bits, 1 64 Bits,
   mixture of static and shared builds).
  60000 bytes were posted, but only between 40KB and 45KB bytes
  received.
  Not reproducible, very rare.
  PR 12355 is: POST incompatible w/ renegotiate https: connection
  Not a regression.

c Various tests in t/apache/expr_string.t:
  116 out of 680 runs failed this test, (all on Linux).
  The failure is mostly on line 68 plus 2 times on line 82
  of the tests, where the error_log contents are checked.
  Inspecting the file after the test shows all needed lines are there
  but again it seems to be an NFS problem, that the test script
  can not see the contents quickly enough.
  Adding a 0.1 seconds sleep before reading the file fixes the problem.
  Not a regression.

d Only on FreeBSD: Failed test 8 in t/apache/limits.t at line 141
  Some read timeout if the kernel accept filter is activated.
  Not a regression.

e Only on FreeBSD: hanging in t/protocol/nntp-like.t
  Not a regression.

FreeBSD problem seems to be related to the use of accept filter. Jeff
can reproduce and he doesn't get it when the accept filter is not in
place. My test system has them activated.

Some more test failures were due to insufficient "need" declarations in
the test files, so the test failed when running e.g. with the "few"
module set. I fixed those now:

- apache/server_name_port.t
- t/modules/alias.t

Plus t/modules/include.t had a problem when TZ was not set. I hope I
fixed that now (Use of uninitialized value in line 346).


Regards,

Rainer

Reply via email to