RE: Tagged 2.0
> From: Sander Striker [mailto:[EMAIL PROTECTED] > Sent: Sunday, September 28, 2003 2:44 AM [...] > Ok, I've tagged pre3. I consider this the last tag and I'd like to > turn that into the next 2.0 release. Due to the received feedback I had to do a pre4 tag (STRIKER_2_0_48_PRE4). Tarballs are up at: http://www.apache.org/~striker/httpd-2.0.48-pre4/. Please give it a whirl. I'd really like to get this release out of the door. Sander
Re: Tagged 2.0
+1 on BSD/OS!! On Mon, Sep 29, 2003 at 10:19:07AM -0600, Brad Nicholes wrote: > -1 on NetWare. With the new call to apr_atomic_init() that was added to > apr_pool.c, apr_pool.c must now #include apr_atomic.h in order to pick > up the NETWARE macro for apr_atomic_init. Without it, it doesn't > compile. > > Brad > > Brad Nicholes > Senior Software Engineer > Novell, Inc., the leading provider of Net business solutions > http://www.novell.com > > >>> [EMAIL PROTECTED] Saturday, September 27, 2003 6:43:53 PM >>> > > From: Sander Striker [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 17, 2003 2:24 PM > > > Tell you what, if I see those merges start trickling in, I'll hold > the > > pre3 tag til friday. We'll put the thing on minotaur directly, and > > announce to stable-testers. I'm hoping we can get enough +1s around > > tuesday/wednesday to push out the final release. > > Ok, I've tagged pre3. I consider this the last tag and I'd like to > turn that into the next 2.0 release. > > Testing tarballs are up at: > > http://www.apache.org/~striker/httpd-2.0.48-pre3/ > > > > I haven't been pushing this release hard enough. It's dragging > > on way too long... Sorry about that. > > I guess I didn't really make a difference last week... > > > > Sander -- Member - Liberal International On 11 Sept 2001 the WORLD was violated. This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED] Society MUST be saved! Extremists must dissolve. Ontario on 2 Octo 2003, VOTE LIBERAL!!
RE: Tagged 2.0
-1 on NetWare. With the new call to apr_atomic_init() that was added to apr_pool.c, apr_pool.c must now #include apr_atomic.h in order to pick up the NETWARE macro for apr_atomic_init. Without it, it doesn't compile. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Saturday, September 27, 2003 6:43:53 PM >>> > From: Sander Striker [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 17, 2003 2:24 PM > Tell you what, if I see those merges start trickling in, I'll hold the > pre3 tag til friday. We'll put the thing on minotaur directly, and > announce to stable-testers. I'm hoping we can get enough +1s around > tuesday/wednesday to push out the final release. Ok, I've tagged pre3. I consider this the last tag and I'd like to turn that into the next 2.0 release. Testing tarballs are up at: http://www.apache.org/~striker/httpd-2.0.48-pre3/ > I haven't been pushing this release hard enough. It's dragging > on way too long... Sorry about that. I guess I didn't really make a difference last week... Sander
RE: Tagged 2.0
> From: Sander Striker [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 17, 2003 2:24 PM > Tell you what, if I see those merges start trickling in, I'll hold the > pre3 tag til friday. We'll put the thing on minotaur directly, and > announce to stable-testers. I'm hoping we can get enough +1s around > tuesday/wednesday to push out the final release. Ok, I've tagged pre3. I consider this the last tag and I'd like to turn that into the next 2.0 release. Testing tarballs are up at: http://www.apache.org/~striker/httpd-2.0.48-pre3/ > I haven't been pushing this release hard enough. It's dragging > on way too long... Sorry about that. I guess I didn't really make a difference last week... Sander
RE: Tagged 2.0
> From: Jeff Trawick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 17, 2003 2:15 PM > Sander Striker wrote: > > > I've re tagged the 2.0 tree with STRIKER_2_0_48_PRE2. I've > > put some tarballs containing that tag up at: > > There are some other fixes merged back since then, and it looks like > another set of fixes that are close to being approved. > > Here is one issue I'd strongly suggest resolving for 2.0.48: > > Greg indicated in the last couple of days that www.apache.org had almost > 12000 error messages (at that point) related to mutex errors with > mod_rewrite. That affects flock users (e.g., FreeBSD) starting the > server as root. I would suggest picking up this change to resolve that: *nod* That'd be a good one to include. > Beyond this one, I'm afraid that I'm not very familiar with the > real-world implications of not picking up the other available fixes. Everything that was voted upon can go in IMO. I was kind of hoping that we could get this release out this week, but I'm afraid that's not going to happen, if we want pre3 to serve on minotaur for a few days. > I'd like to think that within a couple of days we could get 7 or 8 more > fixes merged back, at which point we'd be ready for another release > anyway. But it wouldn't be prudent to count on that happening ;) Tell you what, if I see those merges start trickling in, I'll hold the pre3 tag til friday. We'll put the thing on minotaur directly, and announce to stable-testers. I'm hoping we can get enough +1s around tuesday/wednesday to push out the final release. I haven't been pushing this release hard enough. It's dragging on way too long... Sorry about that. Sander
Re: Tagged 2.0
Sander Striker wrote: I've re tagged the 2.0 tree with STRIKER_2_0_48_PRE2. I've put some tarballs containing that tag up at: There are some other fixes merged back since then, and it looks like another set of fixes that are close to being approved. Here is one issue I'd strongly suggest resolving for 2.0.48: Greg indicated in the last couple of days that www.apache.org had almost 12000 error messages (at that point) related to mutex errors with mod_rewrite. That affects flock users (e.g., FreeBSD) starting the server as root. I would suggest picking up this change to resolve that: -* Unix: Handle permissions settings for flock-based mutexes in - unixd_set_global|proc_mutex_perms(). Allow the functions to - be called for any type of mutex. PR 20312 -modules/mappers/mod_rewrite.c 1.153 -modules/ssl/mod_ssl.h 1.136 -modules/ssl/ssl_engine_config.c 1.81 -modules/ssl/ssl_engine_mutex.c 1.26 -os/unix/unixd.c 1.58 -os/unix/unixd.h 1.38 -+1: trawick, jerenkrantz, gregames - 0: jim (it seems to me that the locking mech itself - should have the required flags to determine whether - uid/gid and chown is required, rather than placing - that knowledge in unixd.c (kind of what is done for - the SSL stuff already with ChownMutexFile). Thus - unixd would simply check those out and do what is - required rather than having internal APR knowledge - it shouldn't). I think the critical issue with this one is that, while the lessor-used lock in mod_rewrite had this problem all along, another fix in 2.0.47 started doing the child-init on the other mod_rewrite lock and it too picked up the root/flock issue. Beyond this one, I'm afraid that I'm not very familiar with the real-world implications of not picking up the other available fixes. I'd like to think that within a couple of days we could get 7 or 8 more fixes merged back, at which point we'd be ready for another release anyway. But it wouldn't be prudent to count on that happening ;)
Re: Tagged 2.0
* Sander Striker wrote: > I've re tagged the 2.0 tree with STRIKER_2_0_48_PRE2. Compiles fine on Win32 and my linux box (with prefork). A test suite run on the latter gives the known mod_include failures plus the ssl/http.t failure, because plain http on ssl port gives a HTTP/0.9 response. We should consider to change that test ... :) So +1 from me. nd
Re: Tagged 2.0
--On Wednesday, September 10, 2003 5:58 PM -0700 Sander Temme <[EMAIL PROTECTED]> wrote: configure:24363: checking whether getnameinfo resolves IPv4-mapped IPv6 addresses configure:24426: gcc -o conftest -DDEBUG -O0 -DDYNAMIC_MODULE_LIMIT=128 -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp conftest.c >&5 configure:24393: warning: return type of `main' is not `int' configure: In function `main': configure:24400: warning: implicit declaration of function `inet_addr' configure:24417: warning: implicit declaration of function `exit' configure:24429: $? = 0 configure:24431: ./conftest configure:24434: $? = 0 configure:24450: result: yes configure:24476: checking if APR supports IPv6 configure:24478: result: yes This may be doing what it does for the wrong reasons. Just to point out that those warnings in APR_CHECK_GETNAMEINFO_IPV4_MAPPED derive from exactly the same snippet in APR_CHECK_GETNAMEINFO. So, any warnings here are red herrings (or that check has exactly the same warnings). Regardless, the macro was passing NI_NUMERICHOST instead of NI_NAMEREQD which is what is needed to trigger the IPv4-IPv6 mapping oddity. I'll have to leave it to someone else to backport to APR 0.9.x so it can be used in httpd 2.0.x. -- justin
Re: Tagged 2.0
Sander Temme wrote: The include failures are wholly new and generate two cores: from observing the run it looks like test 74 and 78 are crashing the server. Stack trace of the first crash (should be test 74: No need to worry about this. The failures are old, just the tests producing them are new. The rewrite of mod_include solves all these problems (but wasn't applied yet to the 2.0 branch, since there there are unresolved compat concerns). nd
Re: Tagged 2.0
> Testers, please test this release candidate. Darwin 6.6 (MacOSX 10.2.6) gives me some new failures: Failed Test Stat Wstat Total Fail Failed List of Failed modules/access.t408 31 7.60% 4 20-21 24 26 28 30 38 55 72 89 106-107 123-124 141 154 168 170 175 192 209 226 277 290 304 306 311 328 345 362 modules/include.t78 10 12.82% 9 18 34-35 40 42 74-75 77-78 ssl/http.t 255 65280 22 100.00% 1-2 The access failures look to me like a regression in the IPv6 issue: some smarter logic was added to the apr build system to determine IPv6 brokenness, but I have seen this do strange things on my Powerbook... to wit, consider the following snippet from srclib/apr/config.log: configure:24363: checking whether getnameinfo resolves IPv4-mapped IPv6 addresses configure:24426: gcc -o conftest -DDEBUG -O0 -DDYNAMIC_MODULE_LIMIT=128 -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp conftest.c >&5 configure:24393: warning: return type of `main' is not `int' configure: In function `main': configure:24400: warning: implicit declaration of function `inet_addr' configure:24417: warning: implicit declaration of function `exit' configure:24429: $? = 0 configure:24431: ./conftest configure:24434: $? = 0 configure:24450: result: yes configure:24476: checking if APR supports IPv6 configure:24478: result: yes This may be doing what it does for the wrong reasons. The include failures are wholly new and generate two cores: from observing the run it looks like test 74 and 78 are crashing the server. Stack trace of the first crash (should be test 74: Date/Time: 2003-09-10 17:42:09 -0700 OS Version: 10.2.6 (Build 6L60) Host: MonaLisa Command:httpd PID:4788 Exception: EXC_BAD_INSTRUCTION (0x0002) Code[0]:0x0002Code[1]:0x00789910 Thread 0 Crashed: #0 0x00789910 in 0x789910 #1 0x003ed654 in send_parsed_content (mod_include.c:3153) #2 0x003ee444 in includes_filter (mod_include.c:3426) #3 0x0001b528 in ap_pass_brigade (util_filter.c:550) #4 0x00442918 in bucketeer_out_filter (mod_bucketeer.c:133) #5 0x0001b528 in ap_pass_brigade (util_filter.c:550) #6 0x00017a3c in default_handler (core.c:3558) #7 0x000301fc in ap_run_handler (config.c:195) #8 0x00030ef8 in ap_invoke_handler (config.c:401) #9 0xb0d4 in ap_process_request (http_request.c:288) #10 0x2cbc in ap_process_http_connection (http_core.c:295) #11 0x00025ebc in ap_run_process_connection (connection.c:85) #12 0x00026420 in ap_process_connection (connection.c:213) #13 0xd2ac in child_main (prefork.c:695) #14 0xd498 in make_child (prefork.c:791) #15 0xd890 in perform_idle_server_maintenance (prefork.c:913) #16 0xdea4 in ap_mpm_run (prefork.c:1118) #17 0xfc20 in main (main.c:660) #18 0x2274 in _start (crt.c:267) #19 0x20f4 in start PPC Thread State: srr0: 0x00789910 srr1: 0x0208f030vrsave: 0x xer: 0x lr: 0x0014c74c ctr: 0x00789910 mq: 0x r0: 0x00789910 r1: 0xbfffeee0 r2: 0x00789928 r3: 0x003928e4 r4: 0x0078b730 r5: 0x r6: 0x r7: 0x0033 r8: 0x20646972 r9: 0x0078c5a4 r10: 0xbfffced6 r11: 0x00168328 r12: 0x00789910 r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x r23: 0x r24: 0x r25: 0x r26: 0xbc50 r27: 0x001c r28: 0x0006 r29: 0xbfffefb2 r30: 0xbfffeee0 r31: 0x003eca08 And the second crash (should be test 78): Date/Time: 2003-09-10 17:42:23 -0700 OS Version: 10.2.6 (Build 6L60) Host: MonaLisa Command:httpd PID:4785 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0058 Thread 0 Crashed: #0 0x0058 in 0x58 #1 0x003ed264 in send_parsed_content (mod_include.c:3072) #2 0x003ee444 in includes_filter (mod_include.c:3426) #3 0x0001b528 in ap_pass_brigade (util_filter.c:550) #4 0x00442ca8 in bucketeer_out_filter (mod_bucketeer.c:157) #5 0x0001b528 in ap_pass_brigade (util_filter.c:550) #6 0x00017a3c in default_handler (core.c:3558) #7 0x000301fc in ap_run_handler (config.c:195) #8 0x00030ef8 in ap_invoke_handler (config.c:401) #9 0xb0d4 in ap_process_request (http_request.c:288) #10 0x2cbc in ap_process_http_connection (http_core.c:295) #11 0x00025ebc in ap_run_process_connection (connection.c:85) #12 0x00026420 in ap_process_connection (connection.c:213) #13 0xd2ac in child_main (prefork.c:695) #14 0xd498 in make_child (prefork.c:791) #15 0x0
Re: Tagged 2.0
No worries. It's no hurry, just wanted to find out if it's still on the radar. I have a workaround for the problem at hand (i.e. I'm inserting flush buckets), so that's cool. Once I'm out of the main work on my module, I might even take a look myself. I don't think it'll be before Xmas, though :-( On Thu, 2003-09-11 at 07:27, Cliff Woolley wrote: > On Thu, 11 Sep 2003, Bojan Smojver wrote: > > > Just wanted to ask if there was any progress on the core_output_filter > > in relation to multiple file buckets being passed through it? > > Not yet. I keep running out of time to look at it. Sorry for the delay... > will get to it as soon as I can. Just wanted to let you know it hasn't > completely fallen through the cracks. If anybody else wants to take a > stab, feel free. Bojan posted a little sample module that demonstrates > the problem a while back. It should be in the archive. > > --Cliff -- Bojan
Re: Tagged 2.0
On Thu, 11 Sep 2003, Bojan Smojver wrote: > Just wanted to ask if there was any progress on the core_output_filter > in relation to multiple file buckets being passed through it? Not yet. I keep running out of time to look at it. Sorry for the delay... will get to it as soon as I can. Just wanted to let you know it hasn't completely fallen through the cracks. If anybody else wants to take a stab, feel free. Bojan posted a little sample module that demonstrates the problem a while back. It should be in the archive. --Cliff
Re: Tagged 2.0
Just wanted to ask if there was any progress on the core_output_filter in relation to multiple file buckets being passed through it? On Wed, 2003-09-10 at 21:12, Sander Striker wrote: > Hi, > > I've re tagged the 2.0 tree with STRIKER_2_0_48_PRE2. I've > put some tarballs containing that tag up at: > > http://www.apache.org/~striker/httpd-2.0.48-pre2/ > > Testers, please test this release candidate. > > Thanks! > > > Sander > > NB: I'll lay the final tag once the release candidate proves > to be ok. This also includes bumping the version numbers > to their final state (read: minus -dev). -- Bojan
