Re: installing binaries in sbin?
On Thu, Feb 28, 2002 at 10:41:09PM -0800, Brian Pane wrote:
> Did something break just recently in the configure script for 2.0?
> A 'make install' is installing the httpd binary in prefix/sbin rather
> than prefix/bin
Yes. Due to some changes I committed we've fallen back on the autoconf
defaults. I apologise for the inconvience until this gets sorted
out, but in the mean time you can actually specify your own paths now
(as this didn't work before):
./configure --prefix=/foo --exec_prefix='${prefix}' --sysconfdir='${prefix}/conf'
--sbindir='${prefix}/bin' --datadir='${prefix}'
(The literal '${prefix}'s will be replaced properly.)
We (Thom and I) are working on a fix for this, but it's a bit involved,
-aaron
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Cliff Woolley wrote: >On Thu, 28 Feb 2002, Cliff Woolley wrote: > >>On Thu, 28 Feb 2002, Greg Stein wrote: >> /* prepend ctx->ssi_tag_brigade onto bb */ APR_BRIGADE_CONCAT(ctx->ssi_tag_brigade, bb); APR_BRIGADE_CONCAT(bb, ctx->ssi_tag_brigade); >>>That is *very* obtuse. I can't imagine anybody figuring out that idiom >>>means "prepend". Yes, please add an appropriate macro. >>> >>Okay, will add. >> > >Committed. Brian, can you please run your tests on it for me? I've yet >to find the exact test case to get into that block of code. > I just finished testing against my test cases that exercise this part of the code, and the new version using APR_BRIGADE_PREPEND works fine. All my test cases for this are variants of a technique that Ian created: use mod_bucketeer in front of mod_include, and insert ctrl-B's (force new bucket), ctrl-P's (pass brigade now), and ctrl-F's (flush brigade) after '<' symbols that aren't the start of a "
Re: installing binaries in sbin?
On Thu, Feb 28, 2002 at 10:41:09PM -0800, Brian Pane wrote: > Did something break just recently in the configure script for 2.0? > A 'make install' is installing the httpd binary in prefix/sbin rather > than prefix/bin Welcome to autoconf. I believe Aaron and Thom are writing their own parsers to parse the arguments because what autoconf has doesn't support our concept of layouts. So, until then, paths are a bit broken. They promise it'll be fixed soon (perhaps tomorrow). -- justin
installing binaries in sbin?
Did something break just recently in the configure script for 2.0? A 'make install' is installing the httpd binary in prefix/sbin rather than prefix/bin --Brian
Re: daemontools/foreground support in 1.3.*
On Fri, Mar 01, 2002 at 01:03:33AM -0500, Michael Handler wrote: > | I am of the mind that it should not be added, but I won't stop anyone > | if they garner 3 +1s from actual testing and feedback. Does my +1 count? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: daemontools/foreground support in 1.3.*
| I am of the mind that it should not be added, but I won't stop anyone | if they garner 3 +1s from actual testing and feedback. Anyone willing to step up with any +1s? It's an easy compile and test, folks; just remember to run it under a shell without job control. Justin Erenkrantz <[EMAIL PROTECTED]> writes: > I have added it to our contrib section for now: > http://www.apache.org/dist/httpd/contrib/patches/1.3/daemontools.patch Are you, or someone else, willing to commit to updating this location with the new version of the patch I'll generate for each successive version of 1.3? If not, I'd rather you removed this patch from this location, as I'd rather maintain it on my web server where I can update it without having to wait on the free time of anyone else. > I have also added a note in 1.3's STATUS. Thank you. > And, BTW, I would appreciate it if people would stop spreading > FUD like 2.0 "arguably won't be [ready] for some time." It's > in production usage right now. *You* may not judge it production > quality - most of us do. You're entitled to your opinion, and me to mine. The simple truth from my perspective is that on March 10, 2002, it will have been two years since the first release of Apache 2.0 alpha. That's an awfully long development period, and unabashed ground-up rewrites of giant software projects that ALSO introduce substantial new features are, to me and most of my sysadmin friends that I have discussed this with, something that makes us nervous. I'm going to have to do exhaustive testing of the various functionality of 2.0 before I'm comfortable releasing it into production in my environment, and I'm going to do so slowly, cautiously, and while closely watching the experiences of others. I'm not directly critiquing the development process for 2.0; I wasn't involved, and I have no claim that I could have done it better. I AM saying that I think you are underestimating the initial resistance that the 2.0 final release is going to encounter, and how long the later/final releases of 1.3.* are going to hang around. This is not an argument for backporting a substantial portion of 2.0's new functionality, or making any other substantial changes, but merely for applying a twenty line patch that has been tested for the last eleven versions and would demonstratably simplify the lives of sysadmins who gratefully run your package at many, many sites. What high-volume sites is 2.0 running on other than daedalus and icarus? -- [EMAIL PROTECTED] (michael handler) washington, dc
Re: 1.3.24??
Brad Nicholes <[EMAIL PROTECTED]> writes: > I would like to get the NetWare log rotation module checked in. I > should have it in fairly quickly. I thought no new features were going into the 1.3.* tree? -- [EMAIL PROTECTED] (michael handler) washington, dc
[ANNOUNCE] Debian packages for 2.0.32
Hi, as the topic suggests, I've finally got a package set that I think is releasable. If some people would like to test it, that would be great. To do so, simply point apt to: deb http://pandora.debian.org/~thom/apache2 ./ deb-src http://pandora.debian.org/~thom/apache2 ./ or use your favourite browser to grab the packages from http://pandora.debian.org/~thom/apache2 Please _DON'T_ use the Debian Bug tracking system to report packaging bugs yet. These package are not yet officially part of Debian, and the BTS won't have a clue what to do with your reports. Please send mail to either the [EMAIL PROTECTED] mailing list, or to me: [EMAIL PROTECTED] or preferably to both. Cheers, -Thom msg06491/pgp0.pgp Description: PGP signature
Re: [PATCH] (1.3, 2.0) config.layout update for SuSE
> Should I just create a new section labled ? No, just replace it. The worst that could happen is the man directory not being found on an old SuSE 6.x, which is an easy fix to the user. Keep in mind that the layout is normally only used by the package installers prior to burning the CD. A normal user would default to the Apache layout. The Layout config is just a way for us to reduce vendor-specific changes to our released code. Roy
Re: [PATCH] (1.3, 2.0) config.layout update for SuSE
On Thu, Feb 28, 2002 at 03:13:10PM -0800, Aaron Bannert wrote: > Should I just create a new section labled ? Yes, why not... while I doubt that the SuSE 6.x section is still needed, it would not harm to keep it of course. The transition with the man path was actually between 6.4 and 7.0 (just looked it up), so it would fit. This would also be the layout for the next release (8.0). Peter -- VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Thu, 28 Feb 2002, Cliff Woolley wrote: > On Thu, 28 Feb 2002, Greg Stein wrote: > > > > /* prepend ctx->ssi_tag_brigade onto bb */ > > > APR_BRIGADE_CONCAT(ctx->ssi_tag_brigade, bb); > > > APR_BRIGADE_CONCAT(bb, ctx->ssi_tag_brigade); > > > > That is *very* obtuse. I can't imagine anybody figuring out that idiom > > means "prepend". Yes, please add an appropriate macro. > > Okay, will add. Committed. Brian, can you please run your tests on it for me? I've yet to find the exact test case to get into that block of code. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: [PATCH] (1.3, 2.0) config.layout update for SuSE
Should I just create a new section labled ? -aaron On Thu, Feb 28, 2002 at 08:19:46PM +0100, Peter Poeml wrote: > another small patch... an update for config.layout for SuSE's > distributions. > > It applies to 1.3.23 as well as to 2.0.32 (with some offset). > > Thanks, > Peter > > -- > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... > --- config.layout.origMon Jan 14 10:39:25 2002 > +++ config.layout Thu Feb 28 20:13:10 2002 > @@ -178,14 +178,14 @@ > proxycachedir: $localstatedir/proxy > > > -# SuSE 6.x layout > +# SuSE 7.x layout > > prefix:/usr > exec_prefix: $prefix > bindir:$prefix/bin > sbindir: $prefix/sbin > libexecdir:$prefix/lib/apache > -mandir:$prefix/man > +mandir:$prefix/share/man > sysconfdir:/etc/httpd > datadir: /usr/local/httpd > iconsdir: $datadir/icons
Re: cvs commit: httpd-2.0/modules/ssl mod_ssl.h ssl_engine_config.c ssl_engine_ds.c ssl_engine_init.c
On Thu, Feb 28, 2002 at 12:01:57AM -, [EMAIL PROTECTED] wrote: >... > +++ mod_ssl.h 28 Feb 2002 00:01:57 - 1.60 > @@ -516,7 +516,7 @@ >apr_lock_t *pMutex; >apr_array_header_t *aRandSeed; >int nScoreboardSize; /* used for builtin random seed */ > -ssl_ds_table *tTmpKeys; > +apr_hash_t *tTmpKeys; >void *pTmpKeys[SSL_TKPIDX_MAX]; >ssl_ds_table *tPublicCert; >ssl_ds_table *tPrivateKey; > @@ -740,6 +740,13 @@ >void *ssl_ds_table_get(ssl_ds_table *, char *); >void ssl_ds_table_wipeout(ssl_ds_table *); >void ssl_ds_table_kill(ssl_ds_table *); > + > +unsigned char *ssl_asn1_table_set(apr_hash_t *table, > + const void *key, > + long int length); > + > +void ssl_asn1_table_unset(apr_hash_t *table, > + const void *key); Those keys are strings, so the signature should be "const char *". That type is compatible with the hash table key type. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Thu, 28 Feb 2002, Greg Stein wrote: > > /* prepend ctx->ssi_tag_brigade onto bb */ > > APR_BRIGADE_CONCAT(ctx->ssi_tag_brigade, bb); > > APR_BRIGADE_CONCAT(bb, ctx->ssi_tag_brigade); > > That is *very* obtuse. I can't imagine anybody figuring out that idiom means > "prepend". Yes, please add an appropriate macro. Okay, will add. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Thu, Feb 28, 2002 at 12:57:50PM -0500, Cliff Woolley wrote: >... > The following is equivalent to the above (except it runs in constant > time): > > /* prepend ctx->ssi_tag_brigade onto bb */ > APR_BRIGADE_CONCAT(ctx->ssi_tag_brigade, bb); > APR_BRIGADE_CONCAT(bb, ctx->ssi_tag_brigade); > > But I'd be fine with adding a prepend macro in the API if others agree > it's useful. That is *very* obtuse. I can't imagine anybody figuring out that idiom means "prepend". Yes, please add an appropriate macro. thx! -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Cliff Woolley wrote:
>On Wed, 27 Feb 2002, Brian Pane wrote:
>
+if (!APR_BRIGADE_EMPTY(ctx->ssi_tag_brigade)) {
+for (;;) {
+apr_bucket *e = APR_BRIGADE_LAST(ctx->ssi_tag_brigade);
+if (e == APR_BRIGADE_SENTINEL(ctx->ssi_tag_brigade)) {
+break;
+}
+APR_BUCKET_REMOVE(e);
+APR_BRIGADE_INSERT_HEAD(bb, e);
+}
}
>>I was thinking about APR_BRIGADE_CONCAT, but what I really needed
>>was APR_BRIGADE_PREPEND because _CONCAT would have left bb empty.
>>Is there a "prepend" variant anywhere?
>>
>
>The following is equivalent to the above (except it runs in constant
>time):
>
>/* prepend ctx->ssi_tag_brigade onto bb */
>APR_BRIGADE_CONCAT(ctx->ssi_tag_brigade, bb);
>APR_BRIGADE_CONCAT(bb, ctx->ssi_tag_brigade);
>
Thanks, I'll update this in mod_include later today.
>But I'd be fine with adding a prepend macro in the API if others agree
>it's useful.
>
+1
--Brian
[PATCH] (1.3, 2.0) config.layout update for SuSE
Hi, another small patch... an update for config.layout for SuSE's distributions. It applies to 1.3.23 as well as to 2.0.32 (with some offset). Thanks, Peter -- VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... --- config.layout.orig Mon Jan 14 10:39:25 2002 +++ config.layout Thu Feb 28 20:13:10 2002 @@ -178,14 +178,14 @@ proxycachedir: $localstatedir/proxy -# SuSE 6.x layout +# SuSE 7.x layout prefix:/usr exec_prefix: $prefix bindir:$prefix/bin sbindir: $prefix/sbin libexecdir:$prefix/lib/apache -mandir:$prefix/man +mandir:$prefix/share/man sysconfdir:/etc/httpd datadir: /usr/local/httpd iconsdir: $datadir/icons
Re: --enable-layout and overriding --prefix
* Rodent of Unusual Size ([EMAIL PROTECTED]) wrote : > Aaron Bannert wrote: > > > > As I pointed out in my message *and* on irc where we were just having > > this discussion, there is no way to let --prefix override the layout > > with autoconf in a way that is guaranteed to work across versions > > of autoconf, at least as far as I can see. > > Am I being especially thick to-day? If the layout is processed > earlier in configure than the other arguments, why doesn't that > solve the problem? I wasn't aware of any parallelisation done > by configure.. :-) Layout is processed as early in configure as we can do it(before any other custom arguments), but autoconf handles --prefix and friends first as part of its default code. Thus, prefix etc get set, and then layout blows them away. (Autoconf also doesn't provide any way to check whether the variables are defaults or have been set with arguments passed to configure.) The way 1.3 worked was to run layout first and then handle the other variables. Cheers, -Thom
[PATCH] 1.3: fix Content-Length in 416 response for files >2GB
Hi,
the attached patch for 1.3 fixes the Content-Length header in the 416
"range not satisfiable" response, that shows an overflow with files
larger than 2 GB.
Note that while this fix "makes it work", there are likely other places
where the incorrect number still shows up, like in the log files.
Details:
- clength should match the off_t type of st_size, the file size as
returned with stat(2).
- Just to be sure, it is casted to AP_LONGEST_LONG before giving it out.
Peter
--
VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
diff -ur apache_1.3.19.orig/src/include/http_protocol.h
apache_1.3.19/src/include/http_protocol.h
--- apache_1.3.19.orig/src/include/http_protocol.h Mon Jan 15 18:04:35 2001
+++ apache_1.3.19/src/include/http_protocol.h Mon Apr 16 17:59:00 2001
@@ -113,7 +113,7 @@
* permit_cache argument is set to one).
*/
-API_EXPORT(int) ap_set_content_length(request_rec *r, long length);
+API_EXPORT(int) ap_set_content_length(request_rec *r, off_t length);
API_EXPORT(int) ap_set_keepalive(request_rec *r);
API_EXPORT(time_t) ap_rationalize_mtime(request_rec *r, time_t mtime);
API_EXPORT(char *) ap_make_etag(request_rec *r, int force_weak);
diff -ur apache_1.3.19.orig/src/main/http_protocol.c
apache_1.3.19/src/main/http_protocol.c
--- apache_1.3.19.orig/src/main/http_protocol.c Fri Feb 16 15:53:24 2001
+++ apache_1.3.19/src/main/http_protocol.c Mon Apr 16 18:41:53 2001
@@ -406,10 +406,11 @@
return 0;
}
-API_EXPORT(int) ap_set_content_length(request_rec *r, long clength)
+API_EXPORT(int) ap_set_content_length(request_rec *r, off_t clength)
{
r->clength = clength;
-ap_table_setn(r->headers_out, "Content-Length", ap_psprintf(r->pool, "%ld",
clength));
+ap_table_setn(r->headers_out, "Content-Length", ap_psprintf(r->pool, "%qd",
+(AP_LONGEST_LONG) clength));
+ /* see src/ap/ap_snprintf.c:787 for the definition of %qd */
return 0;
}
Re: --enable-layout and overriding --prefix
On Thu, Feb 28, 2002 at 01:06:21PM -0500, Rodent of Unusual Size wrote:
> > As I pointed out in my message *and* on irc where we were just having
> > this discussion, there is no way to let --prefix override the layout
> > with autoconf in a way that is guaranteed to work across versions
> > of autoconf, at least as far as I can see.
>
> Am I being especially thick to-day? If the layout is processed
> earlier in configure than the other arguments, why doesn't that
> solve the problem? I wasn't aware of any parallelisation done
> by configure.. :-)
In my version of autoconf (2.13), AC_INIT calls AC_INIT_PARSE_ARG,
which initializes all of the popular values to the autoconf defaults
(eg. prefix=NONE, exec_prefix=NONE, bindir='${exec_prefix}/bin', etc.)
and then immediately proceeds to parse the args to configure, possibly
overwriting the defaults. Since there is no way to know what those
defaults might be on current or future versions of autoconf, we have
no way to detect if the user actually explicitly set --prefix, or
if the value we got was just the default. This is a problem since
we'd like our --enable-layout to only override those variables.
I would love to find a way around this, but for now I'm thinking that
the only way is to have apache's configure.in reparse the args to
configure (like --prefix, etc) and set our own defaults for each.
-aaron
Re: --enable-layout and overriding --prefix
On Thu, Feb 28, 2002 at 01:06:21PM -0500, Rodent of Unusual Size wrote: > Am I being especially thick to-day? If the layout is processed > earlier in configure than the other arguments, why doesn't that > solve the problem? I wasn't aware of any parallelisation done > by configure.. :-) autoconf explicitly resets all prefix-variables before parsing its arguments. So, we can't set the layout before then. -- justin
Re: --enable-layout and overriding --prefix
Aaron Bannert wrote: > > As I pointed out in my message *and* on irc where we were just having > this discussion, there is no way to let --prefix override the layout > with autoconf in a way that is guaranteed to work across versions > of autoconf, at least as far as I can see. Am I being especially thick to-day? If the layout is processed earlier in configure than the other arguments, why doesn't that solve the problem? I wasn't aware of any parallelisation done by configure.. :-) -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
On Wed, 27 Feb 2002, Brian Pane wrote:
> >> +if (!APR_BRIGADE_EMPTY(ctx->ssi_tag_brigade)) {
> >> +for (;;) {
> >> +apr_bucket *e = APR_BRIGADE_LAST(ctx->ssi_tag_brigade);
> >> +if (e == APR_BRIGADE_SENTINEL(ctx->ssi_tag_brigade)) {
> >> +break;
> >> +}
> >> +APR_BUCKET_REMOVE(e);
> >> +APR_BRIGADE_INSERT_HEAD(bb, e);
> >> +}
> >> }
> >>
>
> I was thinking about APR_BRIGADE_CONCAT, but what I really needed
> was APR_BRIGADE_PREPEND because _CONCAT would have left bb empty.
> Is there a "prepend" variant anywhere?
The following is equivalent to the above (except it runs in constant
time):
/* prepend ctx->ssi_tag_brigade onto bb */
APR_BRIGADE_CONCAT(ctx->ssi_tag_brigade, bb);
APR_BRIGADE_CONCAT(bb, ctx->ssi_tag_brigade);
But I'd be fine with adding a prepend macro in the API if others agree
it's useful.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
Re: daemontools/foreground support in 1.3.*
On Thu, Feb 28, 2002 at 08:03:50AM -0500, Mike Gerdts wrote: > Also, the patch that was put in place at > http://www.apache.org/dist/httpd/contrib/patches/1.3/daemontools.patch > is not readable. Could someone do a chmod a+r on it? Oops. Fixed. -- justin
Re: 1.3.24??
I would like to get the NetWare log rotation module checked in. I should have it in fairly quickly. Brad Brad Nicholes Senior Software Engineer Novell, Inc., a leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Thursday, February 28, 2002 6:52:20 AM >>> There are some outstanding patches still for 1.3.24, no? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
RE: [BUG] doesn't work as expected when there is a /dir in the DocumentRoot
> From: Joshua Slive [mailto:[EMAIL PROTECTED]] > Sent: 28 February 2002 16:54 > To: [EMAIL PROTECTED] > Subject: RE: [BUG] doesn't work as expected when there > is a /dir in the DocumentRoot > > From: Sander Striker [mailto:[EMAIL PROTECTED]] > > > Today Vlad Skvortsov <[EMAIL PROTECTED]> stumbled over > > a, IMO, showstopper. > > > > He was trying out subversion and had a config where > > (simplified): > > > > DocumentRoot /home/svn > > > > > >DAV svn > >SVNPath /home/svn/repos > > > > > > In the /home/svn path, there is a directory repos. > > The directory seems to win over the Location (badness!). > > I may be missing something obvious, but let me make sure that you aren't: > > That location section only matches http://example.com/home/svn/repos/ so it > seems perfectly resonable that if you request http://example.com/repos/ it > will fall through to the actual directory. Ick, my bad: The location _is_: > I think what you want is or > > Joshua. I'll try to reproduce it myself in an hour. Sander
RE: [BUG] doesn't work as expected when there is a /dir in the DocumentRoot
> From: Sander Striker [mailto:[EMAIL PROTECTED]] > Today Vlad Skvortsov <[EMAIL PROTECTED]> stumbled over > a, IMO, showstopper. > > He was trying out subversion and had a config where > (simplified): > > DocumentRoot /home/svn > > >DAV svn >SVNPath /home/svn/repos > > > In the /home/svn path, there is a directory repos. > The directory seems to win over the Location (badness!). I may be missing something obvious, but let me make sure that you aren't: That location section only matches http://example.com/home/svn/repos/ so it seems perfectly resonable that if you request http://example.com/repos/ it will fall through to the actual directory. I think what you want is or Joshua.
Re: cvs commit: httpd-2.0 configure.in acinclude.m4
On Thu, Feb 28, 2002 at 01:19:54PM +, Thom May wrote: > Patch attached to move it back, and add the warning back in. Committed, thanks guys. -aaron
[PATCH] Fix configure.in for autoconf 2.52 WAS: RE: cvs commit: httpd-2.0 configure.in acinclude.m4
Hi, Reposted with a clearer subject line. This fixes the problem for me (although I didn't apply the patch, but moved AC_PREFIX_DEFAULT manually). Sander > * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote : > > aaron 02/02/27 17:38:11 > > > > Modified:.configure.in acinclude.m4 > > Log: > > Fix a typo in the default cgidir variable. > > Set a couple more defaults if they haven't already been set, just > > as a precaution. > > > Sadly this breaks under autoconf 2.52 - AC_PREFIX_DEFAULT needs to be run > after the apr m4 files are included, not before. (buildconf chokes like > this otherwise: > > Creating configure ... > rebuilding srclib/pcre/configure > rebuilding include/ap_config_auto.h.in > configure.in:8: error: m4_defn: undefined macro: _m4_divert_diversion > acgeneral.m4:616: AC_PREFIX_DEFAULT is expanded from... > configure.in:8: the top level > autoconf: tracing failed > rebuilding configure > configure.in:8: error: m4_defn: undefined macro: _m4_divert_diversion > acgeneral.m4:616: AC_PREFIX_DEFAULT is expanded from... > configure.in:8: the top level > > Sander Striker spotted this one. > > Patch attached to move it back, and add the warning back in. > Cheers, > -Thom > > > Index: configure.in > === > RCS file: /home/cvspublic/httpd-2.0/configure.in,v > retrieving revision 1.204 > diff -u -u -r1.204 configure.in > --- configure.in 28 Feb 2002 02:56:15 - 1.204 > +++ configure.in 28 Feb 2002 13:18:32 - > @@ -5,7 +5,6 @@ > dnl > > AC_PREREQ(2.13) > -AC_PREFIX_DEFAULT(/usr/local/apache2) > AC_INIT(ABOUT_APACHE) > > AC_CONFIG_HEADER(include/ap_config_auto.h) > @@ -18,6 +17,11 @@ > sinclude(srclib/apr/build/apr_network.m4) > sinclude(srclib/apr/build/apr_threads.m4) > sinclude(acinclude.m4) > + > +dnl XXX we can't just use AC_PREFIX_DEFAULT because that isn't subbed in > +dnl by configure until it is too late. Is that how it should be or not? > +dnl Something seems broken here. > +AC_PREFIX_DEFAULT(/usr/local/apache2) > > dnl Get the layout here, so we can pass the required variables to apr > dnl APACHE_ENABLE_LAYOUT
1.3.24??
There are some outstanding patches still for 1.3.24, no? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: cvs commit: httpd-2.0 configure.in acinclude.m4
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote : > aaron 02/02/27 17:38:11 > > Modified:.configure.in acinclude.m4 > Log: > Fix a typo in the default cgidir variable. > Set a couple more defaults if they haven't already been set, just > as a precaution. > Sadly this breaks under autoconf 2.52 - AC_PREFIX_DEFAULT needs to be run after the apr m4 files are included, not before. (buildconf chokes like this otherwise: Creating configure ... rebuilding srclib/pcre/configure rebuilding include/ap_config_auto.h.in configure.in:8: error: m4_defn: undefined macro: _m4_divert_diversion acgeneral.m4:616: AC_PREFIX_DEFAULT is expanded from... configure.in:8: the top level autoconf: tracing failed rebuilding configure configure.in:8: error: m4_defn: undefined macro: _m4_divert_diversion acgeneral.m4:616: AC_PREFIX_DEFAULT is expanded from... configure.in:8: the top level Sander Striker spotted this one. Patch attached to move it back, and add the warning back in. Cheers, -Thom Index: configure.in === RCS file: /home/cvspublic/httpd-2.0/configure.in,v retrieving revision 1.204 diff -u -u -r1.204 configure.in --- configure.in28 Feb 2002 02:56:15 - 1.204 +++ configure.in28 Feb 2002 13:18:32 - @@ -5,7 +5,6 @@ dnl AC_PREREQ(2.13) -AC_PREFIX_DEFAULT(/usr/local/apache2) AC_INIT(ABOUT_APACHE) AC_CONFIG_HEADER(include/ap_config_auto.h) @@ -18,6 +17,11 @@ sinclude(srclib/apr/build/apr_network.m4) sinclude(srclib/apr/build/apr_threads.m4) sinclude(acinclude.m4) + +dnl XXX we can't just use AC_PREFIX_DEFAULT because that isn't subbed in +dnl by configure until it is too late. Is that how it should be or not? +dnl Something seems broken here. +AC_PREFIX_DEFAULT(/usr/local/apache2) dnl Get the layout here, so we can pass the required variables to apr dnl APACHE_ENABLE_LAYOUT
Re: daemontools/foreground support in 1.3.*
On Thu, 2002-02-28 at 04:00, Michael Handler wrote: > > This is a tiny change, and the functionality already exists in 2.0. > Lots of sysadmins are going to be stuck with 1.3.* for a while from > now, and this is a clear benefit to those of us who utilize > daemontools, without causing any harm to anyone. > Am I reaching anyone here, or should I just be quiet? This is a useful patch. So useful to me that I just wrote an equivalent one yesterday. This is one time that I really should have read the list archives before I started hacking. http://marc.theaimsgroup.com/?l=apache-new-httpd&m=101484615220466&w=2 My aim was only for Cygwin, but should work on most unix-like platforms with the removal of some ifdefs. The implementation in daemontools.patch appears to be a bit cleaner than the one I submitted. Also, the patch that was put in place at http://www.apache.org/dist/httpd/contrib/patches/1.3/daemontools.patch is not readable. Could someone do a chmod a+r on it? Mike
Re: Small change to default log file names
Pier Fumagalli wrote: > > "Ryan Bloom" <[EMAIL PROTECTED]> wrote: > > > Can we change the default log file names form _log to .log? I have > > moved to Windows recently (work requires it), and on Windows, files must > > have an extension in order to be able to associate the file with a > > program. I think it would be useful to our users to change this in the > > default config file. > > +1 :) That's the first thing I touch also on unix in the httpd.conf file > when I install a new one... > +1 as well, on both cases. Should warrant a nice big entry in CHANGES though. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: Small change to default log file names
On Thu, 28 Feb 2002, Pier Fumagalli wrote: > "Ryan Bloom" <[EMAIL PROTECTED]> wrote: > > > Can we change the default log file names form _log to .log? I have > > moved to Windows recently (work requires it), and on Windows, files must > > have an extension in order to be able to associate the file with a > > program. I think it would be useful to our users to change this in the > > default config file. > > +1 :) That's the first thing I touch also on unix in the httpd.conf file > when I install a new one... +0 - but PLEASE - put a large note in the RELEASE notes - as this will break many a script :-). Dw
Re: Small change to default log file names
"Ryan Bloom" <[EMAIL PROTECTED]> wrote: > Can we change the default log file names form _log to .log? I have > moved to Windows recently (work requires it), and on Windows, files must > have an extension in order to be able to associate the file with a > program. I think it would be useful to our users to change this in the > default config file. +1 :) That's the first thing I touch also on unix in the httpd.conf file when I install a new one... Pier
RE: daemontools/foreground support in 1.3.*
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > Sent: 28 February 2002 10:30 > To: Michael Handler > Cc: [EMAIL PROTECTED] > Subject: Re: daemontools/foreground support in 1.3.* > > > On Thu, Feb 28, 2002 at 04:00:34AM -0500, Michael Handler wrote: > > I completely understand the desire to not to introduce substantial > > changes into 1.3.* at this point, as well as encouraging people to > > test the stability and correctness of 2.0. However: > > I have added it to our contrib section for now: > > http://www.apache.org/dist/httpd/contrib/patches/1.3/daemontools.patch > > This should give you an "official" place to download it. I > have also added a note in 1.3's STATUS. > > And, BTW, I would appreciate it if people would stop spreading > FUD like 2.0 "arguably won't be [ready] for some time." It's > in production usage right now. *You* may not judge it production > quality - most of us do. The only thing stopping a GA is some API > changes (Cliff!) *caugh* and *caugh* me *caugh* I need to change the pools api one more time. The allocators can be abstracted out and that best be done before GA IMO. To be changed:apr_pool_create_ex To be introduced: apr_allocator_create, apr_allocator_destroy, apr_allocator_alloc, apr_allocator_free, ... > and small bugfixes (fast_redirect, worker > robustness). We also need to wait to give the 3rd-party providers > one last chance to get their modules working (php). -- justin Sander
Re: daemontools/foreground support in 1.3.*
On Thu, Feb 28, 2002 at 04:00:34AM -0500, Michael Handler wrote: > I completely understand the desire to not to introduce substantial > changes into 1.3.* at this point, as well as encouraging people to > test the stability and correctness of 2.0. However: I have added it to our contrib section for now: http://www.apache.org/dist/httpd/contrib/patches/1.3/daemontools.patch This should give you an "official" place to download it. I have also added a note in 1.3's STATUS. And, BTW, I would appreciate it if people would stop spreading FUD like 2.0 "arguably won't be [ready] for some time." It's in production usage right now. *You* may not judge it production quality - most of us do. The only thing stopping a GA is some API changes (Cliff!) and small bugfixes (fast_redirect, worker robustness). We also need to wait to give the 3rd-party providers one last chance to get their modules working (php). -- justin
Re: daemontools/foreground support in 1.3.*
Sorry for the lack of quick response, I had to go home for a family funeral. Justin Erenkrantz <[EMAIL PROTECTED]> writes: > -0. I personally believe that this shouldn't be backported. If > you want this, you should use 2.0. Others will disagree vehemently > though, and you may indeed garner enough +1s to get it in. > > IMHO, 1.3 should be in bug-fix mode only. No new features - as > witnessed by our addition of AcceptMutex which screwed up 1.3.23 > on Solaris. If you need this functionality, why not use 2.0 and > help us get 2.0 to be GA? I completely understand the desire to not to introduce substantial changes into 1.3.* at this point, as well as encouraging people to test the stability and correctness of 2.0. However: * 2.0 is not ready for production deployment, and arguably won't be for some time. Thus, we need to keep running 1.3 in production until that time, and will need minor support to keep it running optimally in our environments. I'm perfectly happy to deploy 2.0 in testing environments, and the daemontools support will make that abundantly easier, but I still need 1.3.* right now, and that means patching every release each time to run under daemontools. I first wrote this patch for 1.3.14 when I was doing the first software deploy at my current employer (August 2000). I thought about contributing it back to Apache then, but decided against it, since I was (mistakenly) informed that 2.0 already had this functionality, and I thought that 2.0 would be production quality "soon". * This is a very minor change, on the order of 20 lines of code. I've personally been running this patch in production since 1.3.14, and I've found patches on the Internet that date back to 1.3.11 and earlier, so there is clearly historical demand for this functionality, as well as reason to believe that the current patch is functional and correct. Traffic on the daemontools mailing list and the number of people who have downloaded the patches from my web server since I have announced them here and elsewhere shows that there is clearly substantial interest in daemontools and running all available server processes under supervise and svscan, including Apache's httpd. Yes, nothing stops me from distributing this functionality as a patch in the contrib tarball for each release, or from my web page, but that also means that binary packages or OS distributions most likely won't have this trivial but extremely useful bit of functionality included, and that means each binary maintainer either has to be lobbied to include this, or each sysadmin has to compile their own binaries, which strikes me as clear inefficiency that could easily be avoided. This is a tiny change, and the functionality already exists in 2.0. Lots of sysadmins are going to be stuck with 1.3.* for a while from now, and this is a clear benefit to those of us who utilize daemontools, without causing any harm to anyone. I've had to write patches for several server applications to get them running cleanly under daemontools, as have many other sysadmins, but thanks to the work of Jos Backus and others, they've been integrated back into the mainline of the distribution (rsync and SAMBA come to mind as two recent examples). The 1.3.* Apache tree is the final outlier in this regard in my common set of UNIX server applications, and it would save many people work in the future to have this integrated into the next 1.3.* release. Am I reaching anyone here, or should I just be quiet? -- [EMAIL PROTECTED] (michael handler) washington, dc
Re: Small change to default log file names
Aaron Bannert wrote: >On Wed, Feb 27, 2002 at 11:33:36PM -0800, Ryan Bloom wrote: > >>Can we change the default log file names form _log to .log? I have >>moved to Windows recently (work requires it), and on Windows, files must >>have an extension in order to be able to associate the file with a >>program. I think it would be useful to our users to change this in the >>default config file. >> > >How about just calling it "foo_log.txt" on Windows, the same way >we have .exe on the end of our support binaries? The only reason >I wouldn't want to change what we have now is for the sake of >the billions of places where it's hardcoded to error_log and >access_log in automated scripts. This may or may not be a valid >concern. > I agree: better to change it to *.log just on Windows and leave the original *_log for the other platforms, for compatibility with external scripts. --Brian
