Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm

2002-01-06 Thread Stas Bekman
Rodent of Unusual Size wrote:
Stas Bekman wrote:
How the other starting server is supposed to know whether port X is busy
because the first server is still running or it didn't quit cleanly?
{sigh}  It doesn't.  But the user tries to run the tests, gets
a 'port in use' error, and runs again with '-port select'.  Now
there are two servers running -- and potentially *left* running.
He gets this a few times, and codes '-port select' into his
script.  Now they're propagating like rabbits because of a bug
in the harness.

If you want to ensure that all the servers are always killed run,
% killall httpd
A wonderful alternative if the test suite is the ONLY server
running.  Not.  And the fact that you say that's how you kill them
might explain why they sometimes get left around -- it's a bug
you don't see.
OK, I got you. So we should make sure that the test suite will never 
leave the server running when the testing is done.

Currently if for some reason this happens, harness will tell you that it 
has failed to stop the server. What are the alternative, keeping on 
trying to kill the server indefinitely? You realize that the server may 
go into uninterruptable sleep state and no kill -9 will help.

_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestServer.pm

2002-01-06 Thread Stas Bekman
Doug MacEachern wrote:
On Fri, 4 Jan 2002, Stas Bekman wrote:
 

Any idea how to disable the END blocks inheritance in the forked child? 

my $Pid = $$;
sub is_parent {
$$ == $Pid;
}
my $pid = fork;
exit unless $pid;
END {
print END pid=$$\n;
return unless is_parent();
print stuff\n;
}
prints:
END pid=2687
END pid=2688
stuff
without 'return unless is_parent()' prints 'stuff' twice.

nice :) I was thinking there is some magic way to tell Perl not to run END 
block.
I've done with this:
-eval 'END {
+eval 'my $parent_pid = $$;
+  END {
+ return unless $$ == $parent_pid; # because of fork
  local $?; # preserve the exit status
--
_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm

2002-01-06 Thread Rodent of Unusual Size
Stas Bekman wrote:
 
 OK, I got you. So we should make sure that the test suite will never
 leave the server running when the testing is done.

Bingo.

 Currently if for some reason this happens, harness will tell
 you that it has failed to stop the server.

I am not sure that is actually the case, although your recent
changes may have made it so.

 What are the alternative, keeping on trying to kill the server
 indefinitely?

Just exit with an error status.  Perhaps a spectrum of such
exit values should be defined so a script can tell *what*
aspect of the testing failed.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

All right everyone!  Step away from the glowing hamburger!


Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestServer.pm

2002-01-06 Thread Doug MacEachern
On Sun, 6 Jan 2002, Stas Bekman wrote:
 
 I've done with this:
 
 
 -eval 'END {
 +eval 'my $parent_pid = $$;
 +  END {
 + return unless $$ == $parent_pid; # because of fork

ok.  i thought is_parent() could be useful elsewhere, but i guess we could
worry about that later if needed.



Digest::MD5 in TestSmoke?

2002-01-06 Thread Doug MacEachern
perl-framework does not work with 5.6.1 due to Digest::MD5 requirement.

i don't see any reason why this:
 my $digest = Digest::MD5::md5_hex(join '', @$ra_tests);

cannot just be this:
 my $digest = join '', @$ra_tests;

??



Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestServer.pm

2002-01-06 Thread Doug MacEachern
On Mon, 7 Jan 2002, Stas Bekman wrote:
 
 I needed it TestRun, whereas the fork was happening in TestServer. So it 
 was definitely easier to do it locally.

are you saying the following patch would not work?

Index: Apache-Test/lib/Apache/TestRun.pm
===
RCS file: 
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.82
diff -u -r1.82 TestRun.pm
--- Apache-Test/lib/Apache/TestRun.pm   6 Jan 2002 07:08:05 -   1.82
+++ Apache-Test/lib/Apache/TestRun.pm   6 Jan 2002 18:45:46 -
@@ -248,6 +248,9 @@
 $opts-{'run-tests'} ||= @$tests;
 }
 
+my $parent_pid = $$;
+sub is_parent { $$ == $parent_pid }
+
 my $caught_sig_int = 0;
 
 sub install_sighandlers {
@@ -276,9 +279,8 @@
 #must eval  to install this END block, otherwise it will
 #always run, a subclass might not want that
 
-eval 'my $parent_pid = $$;
-  END {
- return unless $$ == $parent_pid; # because of fork
+eval 'END {
+ return unless is_parent(); # because of fork
  local $?; # preserve the exit status
  eval {
 Apache::TestRun-new(test_config =




Re: Digest::MD5 in TestSmoke?

2002-01-06 Thread Doug MacEachern
On Mon, 7 Jan 2002, Stas Bekman wrote:

 Sorry, can we put it into the Bundle?

that's fine, but we cannot 'use Digest::MD5' the way it was before.  else
'perl Makefile.PL' doesn't work without it.

 Because there can be hundreds of tests in @$ra_tests; Remember that the 
 first run by default does 10 * #tests. In case of httpd-test it's 910 
 strings, at the average of 10 char/string it's about 10K chars, now add 
 many iterations and the memory demands are growing fast. Not talking 
 about lookups of the 10k keys in the hash.

ok, that makes sense.
 
 Any alternatives under 5.6.1?

dunno.  if you want to require Digest::MD5 just for running t/SMOKE that's
ok, but not for t/TEST.



Re: Digest::MD5 in TestSmoke?

2002-01-06 Thread Stas Bekman
Doug MacEachern wrote:
On Mon, 7 Jan 2002, Stas Bekman wrote:

Sorry, can we put it into the Bundle?
that's fine, but we cannot 'use Digest::MD5' the way it was before.  else
'perl Makefile.PL' doesn't work without it.
I understand. So is that +1 to add Digest::MD5 to the Apache::Test Bundle?

_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestServer.pm

2002-01-06 Thread Stas Bekman
Doug MacEachern wrote:
On Mon, 7 Jan 2002, Stas Bekman wrote:
 

I needed it TestRun, whereas the fork was happening in TestServer. So it 
was definitely easier to do it locally.

are you saying the following patch would not work?
+1
better move it to the top, in case it needs to be used earlier.
_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


Re: Outch - what a tangled web.

2002-01-06 Thread Randy Kobes
- Original Message -
From: Doug MacEachern [EMAIL PROTECTED]
To: William A. Rowe, Jr. [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; dev@apr.apache.org
Sent: Saturday, January 05, 2002 6:38 PM
Subject: Re: Outch - what a tangled web.


 i wouldn't object to special casing to make win32 happy.  though i find it
 odd that things are working ok as-is on my win32 box and on others.  is
 there any info i can give you about my win32 setup that would help?  fwiw
 your script outputs the following on my box:

 localhost is at 127.0.0.1
 127.0.0.1 is named bramble
 bramble is at 10.0.1.2
 10.0.1.2 is named bramble

For one more data point, on my Win98 machine, which is on a
dial-up network without a permanent ip address, the script gives

localhost is at 127.0.0.1
127.0.0.1 is named localhost
localhost is at 127.0.0.1
127.0.0.1 is named localhost

and the modules/access.t tests all pass.

best regards,
randy kobes




Re: Outch - what a tangled web.

2002-01-06 Thread William A. Rowe, Jr.
From: Randy Kobes [EMAIL PROTECTED]
Sent: Sunday, January 06, 2002 5:13 PM


 From: Doug MacEachern [EMAIL PROTECTED]
 Sent: Saturday, January 05, 2002 6:38 PM
 
  i wouldn't object to special casing to make win32 happy.  though i find it
  odd that things are working ok as-is on my win32 box and on others.  is
  there any info i can give you about my win32 setup that would help?  fwiw
  your script outputs the following on my box:
 
  localhost is at 127.0.0.1
  127.0.0.1 is named bramble
  bramble is at 10.0.1.2
  10.0.1.2 is named bramble

Ok... so your machine gets to identity in 3 reversions (lh-ip-lh-ip)

Which flavor OS, doug?

 For one more data point, on my Win98 machine, which is on a
 dial-up network without a permanent ip address, the script gives
 
 localhost is at 127.0.0.1
 127.0.0.1 is named localhost
 localhost is at 127.0.0.1
 127.0.0.1 is named localhost
 
 and the modules/access.t tests all pass.

Useful to know, Randy, thanks!  Windows NT and prior can be trivially
configured for the right name stuff; it's 2000 that gets prickly.

I need to iterate through the local name, the flipflop (that middle case
on my system example, 'v505') and the absolute name.

Is there an option to t/TEST to pass the local machine name?

Bill




Re: mod_deflate as a DSO on Solaris (perhaps generic?)

2002-01-06 Thread Jeff Trawick

Albert Chin [EMAIL PROTECTED] writes:

 On Sat, Jan 05, 2002 at 05:03:04PM -0800, Justin Erenkrantz wrote:
  On Sat, Jan 05, 2002 at 06:53:43PM -0600, Albert Chin wrote:
   You'll note that there is *no* -lz anywhere. So, I don't see how
   mod_deflate would ever get loaded. Looking at config.status, -lz is in
   EXTRA_LIBS. So:
  
  Correct.  We specify the libraries in EXTRA_LIBS when we build 
  httpd not when building the modules - the run-time link path comes 
  from the executable.  (Didn't we just go over this on another list?)
 
 Is that this thread on the libtool list?
   http://mail.gnu.org/pipermail/libtool/2001-November/005830.html
 
 It ended with Jeff saying he'd whip up a small test case but I don't
 know if one was ever submitted.

I sent one directly to RB.  The testcase was intended to show how
without run-time linking the scenario below was doomed to fail on AIX
unless an import file was used with apr-util to specify that it needed
to resolve apr functions from libapr.

  httpd - libaprutil:some_function - libapr:some_function.

I thought libtool should take care of the import list (I was hacking
up the aprutil build at the time to do that).  For AIX, it is clearly
documented that a shared library depending on another shared library
must be linked using an import file (unless using run-time linking)

Unfortunately, I didn't really convince RB of anything with the
testcase.  Meanwhile, I moved Apache+apr+aprutil to run-time linking
in order to use libtool like most other projects on AIX.

-- 
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...



Re: mod_deflate as a DSO on Solaris (perhaps generic?)

2002-01-06 Thread Jeff Trawick

Justin Erenkrantz [EMAIL PROTECTED] writes:

 On Sat, Jan 05, 2002 at 06:53:43PM -0600, Albert Chin wrote:
  You'll note that there is *no* -lz anywhere. So, I don't see how
  mod_deflate would ever get loaded. Looking at config.status, -lz is in
  EXTRA_LIBS. So:
 
 Correct.  We specify the libraries in EXTRA_LIBS when we build 
 httpd not when building the modules - the run-time link path comes 
 from the executable.  (Didn't we just go over this on another list?)

Justin, what I keep trying to say w.r.t. the other thread is that it
seems that adding extra .la dependencies is what causes the problem on
AIX, not adding plain libraries.  On AIX we already are adding
EXTRA_LIBS to SH_LDFLAGS on AIX.  That doesn't cause a problem.  If it
is needed (or at least not harmful) everywhere then cool!!!

-- 
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...



Libtool library dependencies was Re: mod_deflate as a DSO on Solaris (perhaps generic?)

2002-01-06 Thread Justin Erenkrantz

On Sun, Jan 06, 2002 at 09:35:26AM -0500, Jeff Trawick wrote:
 Justin, what I keep trying to say w.r.t. the other thread is that it
 seems that adding extra .la dependencies is what causes the problem on
 AIX, not adding plain libraries.  On AIX we already are adding
 EXTRA_LIBS to SH_LDFLAGS on AIX.  That doesn't cause a problem.  If it
 is needed (or at least not harmful) everywhere then cool!!!

Oh, that's slightly different from what I understood was happening.
Hmm.  So, libtool can't handle having its own files as a library
dependency?  That seems like that should be an easy fix for the
libtool people.  Have you reported this to them?  -- justin




ap_get_local_host

2002-01-06 Thread David Reid

Is there a reason this isn't using apr functions?

david




Re: cvs commit: httpd-2.0/modules/loggers mod_log_config.c

2002-01-06 Thread Ben Laurie

[EMAIL PROTECTED] wrote:
 
 brianp  02/01/06 00:01:34
 
   Modified:modules/loggers mod_log_config.c
   Log:
   Bypass a strdup and an 8KB local variable in the common case where
   the logger is using the default time format

Does that really stop the stack space from being allocated? It seems
unlikely to me (I haven't checked).

Cheers,

Ben.

 
   Revision  ChangesPath
   1.73  +4 -5  httpd-2.0/modules/loggers/mod_log_config.c
 
   Index: mod_log_config.c
   ===
   RCS file: /home/cvs/httpd-2.0/modules/loggers/mod_log_config.c,v
   retrieving revision 1.72
   retrieving revision 1.73
   diff -u -r1.72 -r1.73
   --- mod_log_config.c  16 Dec 2001 09:54:14 -  1.72
   +++ mod_log_config.c  6 Jan 2002 08:01:34 -   1.73
   @@ -450,7 +450,6 @@
{
apr_exploded_time_t xt;
apr_size_t retcode;
   -char tstr[MAX_STRING_LEN];
 
/*
 hi.  i think getting the time again at the end of the request
   @@ -469,7 +468,9 @@
ap_explode_recent_localtime(xt, r-request_time);
#endif
if (a  *a) {  /* Custom format */
   -apr_strftime(tstr, retcode, MAX_STRING_LEN, a, xt);
   +char tstr[MAX_STRING_LEN];
   +apr_strftime(tstr, retcode, sizeof(tstr), a, xt);
   +return apr_pstrdup(r-pool, tstr);
}
else {  /* CLF format */
 char sign;
   @@ -484,13 +485,11 @@
 sign = '+';
 }
 
   -apr_snprintf(tstr, sizeof(tstr), [%02d/%s/%d:%02d:%02d:%02d %c%.2d%.2d],
   +return apr_psprintf(r-pool, [%02d/%s/%d:%02d:%02d:%02d %c%.2d%.2d],
xt.tm_mday, apr_month_snames[xt.tm_mon], xt.tm_year+1900,
xt.tm_hour, xt.tm_min, xt.tm_sec,
sign, timz / (60*60), timz % (60*60));
}
   -
   -return apr_pstrdup(r-pool, tstr);
}
 
static const char *log_request_duration(request_rec *r, char *a)
 
 
 

--
http://www.apache-ssl.org/ben.html



Re: cvs commit: httpd-2.0/modules/loggers mod_log_config.c

2002-01-06 Thread Brian Pane

Ben Laurie wrote:

[EMAIL PROTECTED] wrote:

brianp  02/01/06 00:01:34

  Modified:modules/loggers mod_log_config.c
  Log:
  Bypass a strdup and an 8KB local variable in the common case where
  the logger is using the default time format


Does that really stop the stack space from being allocated? It seems
unlikely to me (I haven't checked).


You're right.  I just checked, and it didn't stop the space
from being allocated.  I'll move that branch of the code to
separate function so that it really works.  (The alternative
would be to alloc that buffer from a pool, allocating 8KB
from a pool would cause its own set of problems, because a
typical pool block doesn't have enough free space to handle
an alloc that large, so we'd often be allocating a new,
odd-sized block.)

--Brian






RE: cvs commit: httpd-2.0/modules/loggers mod_log_config.c

2002-01-06 Thread Sander Striker

 -Original Message-
 From: Brian Pane [mailto:[EMAIL PROTECTED]]
 Sent: 06 January 2002 21:49
 To: [EMAIL PROTECTED]
 Subject: Re: cvs commit: httpd-2.0/modules/loggers mod_log_config.c
 
 
 Ben Laurie wrote:
 
 [EMAIL PROTECTED] wrote:
 
 brianp  02/01/06 00:01:34
 
   Modified:modules/loggers mod_log_config.c
   Log:
   Bypass a strdup and an 8KB local variable in the common case where
   the logger is using the default time format
 
 
 Does that really stop the stack space from being allocated? It seems
 unlikely to me (I haven't checked).
 
 
 You're right.  I just checked, and it didn't stop the space
 from being allocated.  I'll move that branch of the code to
 separate function so that it really works.  (The alternative
 would be to alloc that buffer from a pool, allocating 8KB
 from a pool would cause its own set of problems, because a
 typical pool block doesn't have enough free space to handle
 an alloc that large, so we'd often be allocating a new,
 odd-sized block.)

Not odd-sized.  It would be the next multiple of 4k.  This is a
property of the new pools code.
 
 --Brian

Sander




Re: Emacs stanza?

2002-01-06 Thread Justin Erenkrantz

On Wed, Jan 02, 2002 at 04:50:06PM -0500, Rodent of Unusual Size wrote:
 I don't know how many people use Emacs to edit the Apache stuff,
 but would anyone object to a stanza at the bottom of the source
 files to help put Emacs in the right stylistic mood?  To wit,
 something like:

I don't know if this got purposely resent on the 6th, but I'll
chime in now and say that I think this isn't a good idea at all.
I think you should be able to configure your editor yourself.  =)

However, if you *must* do this (I don't think you should at all,
but I'll stop short of a veto), I'd think it'd be a better idea 
to follow SVN's convention by adding this to all files:

/* -
 * local variables:
 * eval: (load-file ../emacs-style)
 * end:
 */

Where ../emacs-style is obviously the relative path to emacs-style.
This way we can change the global style by just modifying 
emacs-style rather than all files.  And, it allows some useful 
macros in emacs-style.

FWIW, I don't use emacs...  Go vi.  =)  -- justin




[PATCH] Split out libtool dependencies

2002-01-06 Thread Justin Erenkrantz

Jeff (and anyone else interested),

Can you please test out this patch on AIX and report on what you 
get back?  Per your earlier email, this tries to separate out any
libexpat.la's so that it is not specified when linking libaprutil.la.
This *may* work around the bug you are seeing in libtool.  If you
want to compile a program with libaprutil.la, we'll still have to
specify any libexpat.la's, but this should remove the -ldb... crap.

This patch is against httpd-2.0 and a srclib/apr-util.  (Works here
on Linux 2.4.)

This also moves the acquisiton of the apr-util libraries to much
earlier on in httpd's configure.  We would still need 
APRUTIL_EXPORT_LIBS during configure-time, but we wouldn't need 
them once configure is complete.  -- justin

Index: configure.in
===
RCS file: /home/cvs/httpd-2.0/configure.in,v
retrieving revision 1.196
diff -u -r1.196 configure.in
--- configure.in30 Dec 2001 14:05:55 -  1.196
+++ configure.in6 Jan 2002 22:55:33 -
@@ -81,6 +81,12 @@
 EXTRA_LIBS=
 EXTRA_INCLUDES=
 
+dnl get the exported vars from APRUTIL
+. ./srclib/apr-util/export_vars.sh
+APR_ADDTO(LIBS, $APRUTIL_EXPORT_LIBS)
+APR_ADDTO(LIBTOOL_LIBS, $APRUTIL_EXPORT_LIBTOOL_LIBS)
+APACHE_SUBST(LIBTOOL_LIBS)
+
 dnl Absolute source/build directory
 abs_srcdir=`(cd $srcdir  pwd)`
 abs_builddir=`pwd`
@@ -402,10 +428,10 @@
 APACHE_FAST_OUTPUT(test/Makefile)
 fi
 
-dnl get the exported vars from APRUTIL
-. ./srclib/apr-util/export_vars.sh
-APR_ADDTO(LIBS, $APRUTIL_EXPORT_LIBS)
+dnl These are special libtool-only libraries that must be added after all
+dnl configure tests.  This may potentially invalidate some configure
+dnl tests if there are useful things here (such as Expat).
 AP_LIBS=$AP_LIBS $LIBTOOL_LIBS
 
 dnl ## Finalize the variables
 echo $ac_n ${nl}Restore user-defined environment settings...${nl}
Index: srclib/apr-util/Makefile.in
===
RCS file: /home/cvs/apr-util/Makefile.in,v
retrieving revision 1.56
diff -u -r1.56 Makefile.in
--- srclib/apr-util/Makefile.in 4 Jan 2002 21:54:49 -   1.56
+++ srclib/apr-util/Makefile.in 6 Jan 2002 22:55:39 -
@@ -9,6 +9,8 @@
 INCLUDES=-I./include -I$(srcdir)/include @APR_INCLUDES@
 
 TARGET_LIB = libaprutil.la
+DEPEND_LIBS = @APRUTIL_EXPORT_LIBS@
+DEPEND_LIBTOOL_LIBS = @APRUTIL_EXPORT_LIBTOOL_LIBS@
 INSTALL_SUBDIRS = @APR_XML_DIR@
 
 TARGETS = delete-lib $(TARGET_LIB) delete-exports aprutil.exp export_vars.h
@@ -61,7 +63,7 @@
 
 $(TARGET_LIB):
@objects=`find $(SUBDIRS) -name expat -prune -o -name 
'gen_uri_delims.@so_ext@' -prune -o -name '*.@so_ext@' -print`; \
-   tmpcmd=$(LINK) @lib_target@ @EXTRA_OS_LINK@; \
+   tmpcmd=$(LINK) @lib_target@ @EXTRA_OS_LINK@ $(DEPEND_LIBS); \
echo $$tmpcmd; \
$$tmpcmd
 
Index: srclib/apr-util/configure.in
===
RCS file: /home/cvs/apr-util/configure.in,v
retrieving revision 1.41
diff -u -r1.41 configure.in
--- srclib/apr-util/configure.in4 Jan 2002 21:54:49 -   1.41
+++ srclib/apr-util/configure.in6 Jan 2002 22:55:39 -
@@ -82,8 +82,10 @@
 APR_ADDTO(LIBS, [$APR_EXPORT_LIBS])
 
 AC_SUBST(APRUTIL_EXPORT_LIBS)
+AC_SUBST(APRUTIL_EXPORT_LIBTOOL_LIBS)
 AC_SUBST(LDFLAGS)
 APR_ADDTO(LIBS,[$APRUTIL_EXPORT_LIBS])
+APR_ADDTO(LIBS,[$APRUTIL_EXPORT_LIBTOOL_LIBS])
 
 dnl
 dnl BSD/OS (BSDi) needs to use a different include syntax in the Makefiles
Index: srclib/apr-util/export_vars.sh.in
===
RCS file: /home/cvs/apr-util/export_vars.sh.in,v
retrieving revision 1.1
diff -u -r1.1 export_vars.sh.in
--- srclib/apr-util/export_vars.sh.in   12 Dec 2000 09:44:52 -  1.1
+++ srclib/apr-util/export_vars.sh.in   6 Jan 2002 22:55:39 -
@@ -9,3 +9,4 @@
 #
 
 APRUTIL_EXPORT_LIBS=@APRUTIL_EXPORT_LIBS@
+APRUTIL_EXPORT_LIBTOOL_LIBS=@APRUTIL_EXPORT_LIBTOOL_LIBS@
Index: srclib/apr-util/build/apu-conf.m4
===
RCS file: /home/cvs/apr-util/build/apu-conf.m4,v
retrieving revision 1.24
diff -u -r1.24 apu-conf.m4
--- srclib/apr-util/build/apu-conf.m4   2 Jan 2002 23:59:26 -   1.24
+++ srclib/apr-util/build/apu-conf.m4   6 Jan 2002 22:55:39 -
@@ -454,6 +454,7 @@
   expat_include_dir=$top_builddir/$bundled_subdir/lib
   expat_libs=$top_builddir/$bundled_subdir/lib/libexpat.la
   APR_XML_SUBDIRS=`echo $bundled_subdir | sed -e 's%xml/%%'`
+  APR_ADDTO(APRUTIL_EXPORT_LIBTOOL_LIBS, [$expat_libs])
 else
 if test $expat_include_dir = $srcdir/xml/expat/include -o $expat_include_dir = 
$srcdir/xml/expat/lib; then
   dnl This is a bit of a hack.  This only works because we know that
@@ -463,6 +464,10 @@
   expat_include_dir=$top_builddir/$bundled_subdir/lib
   expat_libs=$top_builddir/$bundled_subdir/lib/libexpat.la
   APR_XML_SUBDIRS=`echo 

Re: [PATCH] Split out libtool dependencies

2002-01-06 Thread Jeff Trawick

Justin Erenkrantz [EMAIL PROTECTED] writes:

 Jeff (and anyone else interested),
 
 Can you please test out this patch on AIX and report on what you 
 get back?

no problems caused by/exposed by your patch as far as I can tell!!!

I did hit a problem loading mod_disk_cache, but that is because it
can't find ap_hook_store_cache and ap_hook_serve_cache which don't
seem to be in our tree -- i.e., no AP_DECLARE_HOOK invocations.  I
don't normally build mod_disk_cache so I don't know when that broke,
but it would seem to have absolutely nothing to do with your patch.

-- 
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...



where are ap_hook_store_cache and ap_hook_serve_cache?

2002-01-06 Thread Jeff Trawick

... as used by mod_disk_cache

-- 
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...



Re: Running Apache in the foreground

2002-01-06 Thread Ryan Bloom

On Friday 04 January 2002 03:59 pm, Jos Backus wrote:
 On Thu, Jan 03, 2002 at 08:28:14AM -0800, Aaron Bannert wrote:
  I see no reason why this can't be implemented in apache2, and I'll
  even test and commit a patch that properly implements it. :) Sorry
  I can't offer much more than that. Maybe if I get some more time
  later this week I can look into it, but the more surefire way to get
  it in would be to provide a patch.
 
 Here's a patch that appears to dtrt. I chose DONT_FORK as the keyword but I
 would happily change this or any other name to something else, just let me
 know. The main thing is that the patch goes in :-) Btw, the patch is against
 2.0.28, I hope that is not too big of a problem; I can look into bringing it
 up to HEAD if desired.

I'm 100% in favor of this stuff, but please just keep using NO_DETACH for 
this.  I didn't get the use case correct for NO_DETACH, but that doesn't mean
we should add another option.

Ryan
__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--



Re: [PATCH] Allow DocumentRoot within Location blocks

2002-01-06 Thread Ryan Bloom

On Saturday 05 January 2002 06:27 am, Sander Striker wrote:
 Hi,
 
 I've tried to tackle this issue in STATUS:
 
 * Allow the DocumentRoot directive within Location  scopes?  This
   allows the beloved (crusty) Alias /foo/ /somepath/foo/ followed
   by a Directory /somepath/foo to become simply
   Location /foo/ DocumentRoot /somefile/foo (IMHO a bit more legible
   and in-your-face.)  DocumentRoot unset would be accepted [and would
   not permit content to be served, only virtual resources such as
   server-info or server-status.
 This proposed change would _not_ depricate Alias.
 
 My patch probably is incomplete (and most likely I broke something), but it
 is a first cut I'd like some feedback on.  For starters, document_root is
 moved for core_server_conf to core_dir_conf.  core_dir_conf got an extra
 field telling you what type of dir conf it is.  Wrowe suggested that we might
 want a registration API for this, but I decided to go with an enum for
 starters.  Registration can come in a later iteration.

I would like to discuss the reasoning behind this change.  Why are we trying
to overload the meaning of DocumentRoot this way?

Ryan

__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--



Re: [PATCH] Allow DocumentRoot within Location blocks

2002-01-06 Thread William A. Rowe, Jr.

From: Ryan Bloom [EMAIL PROTECTED]
Sent: Sunday, January 06, 2002 11:34 PM


 I would like to discuss the reasoning behind this change.  Why are we trying
 to overload the meaning of DocumentRoot this way?

Because it allows the DocumentRoot to be, well, nonexistant.

It allows us to have the following section;

Location /nowhere
DocumentRoot unset
/Location

that makes it 100% clear where nowhere goes.  It is also possibly easier
than alias, since

Location /private
DocumentRoot /some/private/resource
Options deny,allow
Allow from only.me
/Location

works the same as 

Alias /private /some/private/resource

Location /private
Options deny,allow
Allow from only.me
/Location

but the former is very explicit.

That was the reasoning, at least, for the suggestion in STATUS.

It would allow us to transition to a more flexible schema, where Location s
are mounted to the filesystem, or JK space, or some other mechanism for serving
content.  And it certainly neither breaks the existing DocumentRoot, nor the
Alias directive [which will still, as always, override DocumentRoot.)

Bill




Re: [PATCH] Split out libtool dependencies

2002-01-06 Thread Justin Erenkrantz

On Sun, Jan 06, 2002 at 10:03:13PM -0500, Jeff Trawick wrote:
 Justin Erenkrantz [EMAIL PROTECTED] writes:
 
  Jeff (and anyone else interested),
  
  Can you please test out this patch on AIX and report on what you 
  get back?
 
 no problems caused by/exposed by your patch as far as I can tell!!!

Very cool.  We might actually be close to nailing this sucker.  
I'll give people another day or so to comment and then commit 
it.  -- justin




beos: RequestsPerThread vs. MaxRequestsPerThread

2002-01-06 Thread Lars Eilebrecht

Hi,

the RequestsPerThread logs the warning
MaxRequestsPerThread was set below 0 if it is set to
a negativ value (note the Max).

The name MaxRequestsPerThread makes IMHO more sense
for this directive, because it specifies the max value,
like the MaxRequestsPerChild directive.

If there are no objections I'll change the Name of
the directive to MaxRequestsPerThread and update the
docs and httpd.conf.


ciao...
-- 
Lars Eilebrecht - Unix is like Sex: If you don't know it,
[EMAIL PROTECTED]   - you don't miss is. But if you know it,
- you'll need it.




Re: [PATCH] Allow DocumentRoot within Location blocks

2002-01-06 Thread Sander van Zoest

On Mon, 7 Jan 2002, William A. Rowe, Jr. wrote:

 From: Ryan Bloom [EMAIL PROTECTED]
  I would like to discuss the reasoning behind this change.  Why are we trying
  to overload the meaning of DocumentRoot this way?
 Because it allows the DocumentRoot to be, well, nonexistant.

This is very useful in environments where you want an URI space that
doesn't necessarily line up with anything on a file system.

This would be very useful for things such as mod_perl, XML/XSLT solutions,
RTSP/Icecast servers, etc.

 It allows us to have the following section;
 Location /nowhere
 DocumentRoot unset
 /Location
 that makes it 100% clear where nowhere goes.  It is also possibly easier
 than alias, since

I am not sure if I like the unset keyword. In the mime and handler case
we use Add/Remove and we use On and Off already. Maybe using
Off is valid here? Then we could probably also use On to enable
the DocumentRoot again, where it would enable it to a previously set
DocumentRoot higher up in the tree or default to the compiled in default
if there was nothing defined elsewhere.

 works the same as
 Alias /private /some/private/resource
 Location /private
 Options deny,allow
 Allow from only.me
 /Location

(I assume here you meant Order instead of Options)
You could also potentially consider writing this as

Directory /some/private/resource
   Alias /private # Or maybe Uri /private
   Options deny,allow
   Allow from only.me
/Directory

This does not change the notion of having a single DocumentRoot and
allows for the same flexibility (if we remove the requirement for a
DocumentRoot and allow for DocumentRoot [Off|unset|path] or whatever).

Cheers,

--
Sander van Zoest  [EMAIL PROTECTED]
High Geek http://Sander.vanZoest.com/