You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Ames <gr...@remulak.net> on 2001/11/12 23:19:17 UTC
2_0_28 tarballs rolled and available
...in http://dev.apache.org/dist/ . Please download, test, and vote for
beta.
I made separate tarballs available for Mac OS X. Tarballs rolled with
daedalus's libtool do not work on Darwin, so I used libtool 1.4.2 for
that one. I used daedalus's libtool 1.4.2 for the others, which works
on HP-UX. I stuck a READ-ME.Darwin file in the directory so hopefully
Mac OS X users can figure it out.
Thanks to Chuck M., Madhu, and Cliff for testing preliminary tarballs,
and to OtherBill and Justin for taking care of serious issues after the
original tag.
Greg
Re: 2_0_28 tarballs rolled and available
Posted by Bill Stoddard <bi...@wstoddard.com>.
+1 on beta.
Bill
----- Original Message -----
From: "Greg Ames" <gr...@remulak.net>
To: "httpd" <de...@httpd.apache.org>
Sent: Monday, November 12, 2001 5:19 PM
Subject: 2_0_28 tarballs rolled and available
> ...in http://dev.apache.org/dist/ . Please download, test, and vote for
> beta.
>
> I made separate tarballs available for Mac OS X. Tarballs rolled with
> daedalus's libtool do not work on Darwin, so I used libtool 1.4.2 for
> that one. I used daedalus's libtool 1.4.2 for the others, which works
> on HP-UX. I stuck a READ-ME.Darwin file in the directory so hopefully
> Mac OS X users can figure it out.
>
> Thanks to Chuck M., Madhu, and Cliff for testing preliminary tarballs,
> and to OtherBill and Justin for taking care of serious issues after the
> original tag.
>
> Greg
>
Re: 2_0_28 tarballs rolled and available
Posted by Austin Gonyou <au...@coremetrics.com>.
I'll put them up on digitalroadkill.net tonight also so we can test some
real world stuff. Feel free to bang on it as much as you want. I'd
prefer real news articles and such submitted though. :) But please,
register users, etc.
On Mon, 2001-11-12 at 16:19, Greg Ames wrote:
> ...in http://dev.apache.org/dist/ . Please download, test, and vote for
> beta.
>
> I made separate tarballs available for Mac OS X. Tarballs rolled with
> daedalus's libtool do not work on Darwin, so I used libtool 1.4.2 for
> that one. I used daedalus's libtool 1.4.2 for the others, which works
> on HP-UX. I stuck a READ-ME.Darwin file in the directory so hopefully
> Mac OS X users can figure it out.
>
> Thanks to Chuck M., Madhu, and Cliff for testing preliminary tarballs,
> and to OtherBill and Justin for taking care of serious issues after the
> original tag.
>
> Greg
--
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com
Re: 2_0_28 tarballs rolled and available
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Nov 12, 2001 at 10:52:32PM -0800, Ryan Bloom wrote:
> I see the problem you are refering to now. I'm not going to fix it tonight. This
> is just inicitive of some of the problems with the proxy. I'll try to fix it tomorrow.
> I would do it tonight, but my brain is fried, and I have two more patches to finish.
No rush since you will be able to get to it before I can. If
someone else can beat us to it, wonderful. =) That code looks
like it needs some rethinking:
/* we are acting as a tunnel - the output filter stack should
* be completely empty, because when we are done here we are done
* completely.
* We add the NULL filter to the stack to do this...
*/
r->output_filters = NULL;
r->connection->output_filters = NULL;
Ack. That can't be good.
/me asks what am I doing replying to email when I should be studying.
-- justin
Re: 2_0_28 tarballs rolled and available
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 12 November 2001 10:44 pm, Ryan Bloom wrote:
> On Monday 12 November 2001 10:51 pm, Justin Erenkrantz wrote:
> > On Mon, Nov 12, 2001 at 10:35:36PM -0800, Ryan Bloom wrote:
> > > Where is your tree breaking during the build? I have three trees, all
> > > synch'ed, and all three build just fine.
> >
> > mod_proxy as described earlier because it wants to use
> > r->connection->client_socket.
> >
> > I don't feel like disabling it now in my config as I really
> > have other things to do. -- justin
>
> Okay. I'll try to fix that tonight.
I see the problem you are refering to now. I'm not going to fix it tonight. This
is just inicitive of some of the problems with the proxy. I'll try to fix it tomorrow.
I would do it tonight, but my brain is fried, and I have two more patches to finish.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2_0_28 tarballs rolled and available
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 12 November 2001 10:51 pm, Justin Erenkrantz wrote:
> On Mon, Nov 12, 2001 at 10:35:36PM -0800, Ryan Bloom wrote:
> > Where is your tree breaking during the build? I have three trees, all
> > synch'ed, and all three build just fine.
>
> mod_proxy as described earlier because it wants to use
> r->connection->client_socket.
>
> I don't feel like disabling it now in my config as I really
> have other things to do. -- justin
Okay. I'll try to fix that tonight.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2_0_28 tarballs rolled and available
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Nov 12, 2001 at 10:35:36PM -0800, Ryan Bloom wrote:
> Where is your tree breaking during the build? I have three trees, all synch'ed,
> and all three build just fine.
mod_proxy as described earlier because it wants to use
r->connection->client_socket.
I don't feel like disabling it now in my config as I really
have other things to do. -- justin
Re: 2_0_28 tarballs rolled and available
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 12 November 2001 10:35 pm, Justin Erenkrantz wrote:
> On Mon, Nov 12, 2001 at 10:59:14PM -0800, sterling wrote:
> > Hi -
> >
> > I still have an outstanding bug (and patch) that hasn't gotten a
> > response. I consider it a showstopper. Given the current default config
> > simply add a <Location /> stanza with auth enabled and that triggers the
> > bug I reported previously (the one where headers filters are never
> > called).
>
> Try this patch on for size (my tree is non-buildable since I synced
> up). The thing here is that we walk up the request tree when we see
> a non-HTTP_OK code. So, if we were to save the request_rec* BEFORE
> we walk up the tree, I think we end up with the correct request_rec
> and save some time to boot.
>
> > There is a workaround - to disable the ErrorDocument stuff - but still,
> > it seems to me like it should at least be double checked before 'beta'.
>
> FWIW, the only thing I see stopping a beta is a segfault. Anything
> else, I don't give a rats ass about. =) And, *especially* if there
> is a workaround. Because at this point, 2.0.29-dev is
> non-buildable, so I think it is unlikely we can get 2.0.29 out in
> a reasonable time-frame. Remember, beta != bug-free. -- justin
Where is your tree breaking during the build? I have three trees, all synch'ed,
and all three build just fine.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2_0_28 tarballs rolled and available
Posted by Cliff Woolley <cl...@yahoo.com>.
On Mon, 12 Nov 2001, Justin Erenkrantz wrote:
> Try this patch on for size (my tree is non-buildable since I synced
> up). The thing here is that we walk up the request tree when we see
> a non-HTTP_OK code. So, if we were to save the request_rec* BEFORE
> we walk up the tree, I think we end up with the correct request_rec
> and save some time to boot.
Ahhh, now that's starting to make sense. :) I'm reviewing the patch
right now (I still have a version of 2.0.29-dev from this afternoon). I
tried Sterling's patch and it worked and passed httpd-test, but I think I
like yours better, so I'll try it next and commit it for you if it passes
the tests.
> FWIW, the only thing I see stopping a beta is a segfault. Anything
> else, I don't give a rats ass about. =) And, *especially* if there
> is a workaround. Because at this point, 2.0.29-dev is
> non-buildable, so I think it is unlikely we can get 2.0.29 out in
> a reasonable time-frame. Remember, beta != bug-free. -- justin
Agreed. And even if it does build (I haven't tried HEAD), there are
still lingering close issues AFAIK.
(I keep having to tell myself this, or I lose sight of it. beta !=
bugfree, beta != bugfree, beta != bugfree...) :)
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2_0_28 tarballs rolled and available
Posted by sterling <st...@covalent.net>.
My point exactly.
And take note - they are guarenteed to do the same thing *assuming* the
request is passed in is the last request in the chain. I was avoiding
coding to avoid that implicit assumption (an assert(r->next == NULL)
would serve the same purpose).
sterling
On Mon, 12 Nov 2001, Ryan Bloom wrote:
> On Monday 12 November 2001 11:52 pm, sterling wrote:
>
> > As far as your suggested patch - why is that better (and don't say
> > performance wise - with all the string comparisons going on in a request
> > a small while loop in an error case won't affect that much)? Really, we
> > want to ensure that the filters are added to the last request (since those
> > are the filters that are going to be called). Sure, either patch fixes the
> > bug though -
>
> Actually the two patches are gauranteed to do the same thing. By definition,
> when we get into this function, the request that is passed in is the last request
> in the chain. Since the two patches are equivalent functionally, it really doesn't
> matter which is applied. The reality is that Justin's will perform better, but we
> are talking about an error condition, so the incredibly small performance
> benefit will never be big enough to make any difference at all.
>
> Ryan
>
> ______________________________________________________________
> Ryan Bloom rbb@apache.org
> Covalent Technologies rbb@covalent.net
> --------------------------------------------------------------
>
Re: 2_0_28 tarballs rolled and available
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 12 November 2001 11:52 pm, sterling wrote:
> As far as your suggested patch - why is that better (and don't say
> performance wise - with all the string comparisons going on in a request
> a small while loop in an error case won't affect that much)? Really, we
> want to ensure that the filters are added to the last request (since those
> are the filters that are going to be called). Sure, either patch fixes the
> bug though -
Actually the two patches are gauranteed to do the same thing. By definition,
when we get into this function, the request that is passed in is the last request
in the chain. Since the two patches are equivalent functionally, it really doesn't
matter which is applied. The reality is that Justin's will perform better, but we
are talking about an error condition, so the incredibly small performance
benefit will never be big enough to make any difference at all.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2_0_28 tarballs rolled and available
Posted by Austin Gonyou <au...@coremetrics.com>.
I got a build error using my old config last night. Sorry for the delay.
I'm going to try again this after noon for those who want to bang on
digitalroadkill.
On Tue, 2001-11-13 at 10:26, sterling wrote:
> Thanks Cliff -
>
> Yeah, was mentioned before they are technically the same functionality
> as the server works today - the while loop is to mimic
> ap_finalize_request's
> logic before it fires up the filter chain etc.
>
> As far as the assert - there are so many assumptions in this server
> another one probably won't hurt much :) - but it would be nice.
>
> thanks -
> sterling
>
> On Tue, 13 Nov 2001, Cliff Woolley wrote:
>
> > On Mon, 12 Nov 2001, sterling wrote:
> >
> > > As far as your suggested patch - why is that better (and don't say
> > > performance wise - with all the string comparisons going on in a
> > > request a small while loop in an error case won't affect that much)?
> >
> > I personally just think it's more clear what's going on without the
> loop
> > than with it.
> >
> > Anyway, they both passed the httpd-test suite. (Not that the test
> suite
> > actually catches this problem right now, but that's another matter. I
> > verified this fix by hand with the test case you provided, and
> httpd-test
> > tells me it didn't break anything else.) I just committed Justin's
> > version because I think it's more clear. If somebody wants to stick
> in an
> > AP_DEBUG_ASSERT to make sure r->next is NULL when we enter the
> function,
> > that's fine by me.
> >
> > Thanks!
> > --Cliff
> >
> > --------------------------------------------------------------
> > Cliff Woolley
> > cliffwoolley@yahoo.com
> > Charlottesville, VA
> >
> >
> >
> >
> >
> >
> >
> >
--
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com
Re: 2_0_28 tarballs rolled and available
Posted by sterling <st...@covalent.net>.
Thanks Cliff -
Yeah, was mentioned before they are technically the same functionality
as the server works today - the while loop is to mimic ap_finalize_request's
logic before it fires up the filter chain etc.
As far as the assert - there are so many assumptions in this server
another one probably won't hurt much :) - but it would be nice.
thanks -
sterling
On Tue, 13 Nov 2001, Cliff Woolley wrote:
> On Mon, 12 Nov 2001, sterling wrote:
>
> > As far as your suggested patch - why is that better (and don't say
> > performance wise - with all the string comparisons going on in a
> > request a small while loop in an error case won't affect that much)?
>
> I personally just think it's more clear what's going on without the loop
> than with it.
>
> Anyway, they both passed the httpd-test suite. (Not that the test suite
> actually catches this problem right now, but that's another matter. I
> verified this fix by hand with the test case you provided, and httpd-test
> tells me it didn't break anything else.) I just committed Justin's
> version because I think it's more clear. If somebody wants to stick in an
> AP_DEBUG_ASSERT to make sure r->next is NULL when we enter the function,
> that's fine by me.
>
> Thanks!
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
>
>
>
>
>
>
>
>
Re: 2_0_28 tarballs rolled and available
Posted by Cliff Woolley <cl...@yahoo.com>.
On Mon, 12 Nov 2001, sterling wrote:
> As far as your suggested patch - why is that better (and don't say
> performance wise - with all the string comparisons going on in a
> request a small while loop in an error case won't affect that much)?
I personally just think it's more clear what's going on without the loop
than with it.
Anyway, they both passed the httpd-test suite. (Not that the test suite
actually catches this problem right now, but that's another matter. I
verified this fix by hand with the test case you provided, and httpd-test
tells me it didn't break anything else.) I just committed Justin's
version because I think it's more clear. If somebody wants to stick in an
AP_DEBUG_ASSERT to make sure r->next is NULL when we enter the function,
that's fine by me.
Thanks!
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2_0_28 tarballs rolled and available
Posted by sterling <st...@covalent.net>.
Hrm -
No one ever said beta was bug free. but to me, beta should generally work
as expected out of the box. If I were to be standing behind a piece
of software as beta, I sure as hell would give 'a rats ass' about
bugs that are fairly likely, and are not easy for the configurator to
triage and fix - adding auth to <Location /> is not an edge case - it is
probabably a very likely scenario.... especially when we have a fix.
anyhoo - I'm pretty sure I understand what beta means - but a serious bug
like that posted to the list with *no* response sent up a little red flag
- so I raised it publicly.
As far as your suggested patch - why is that better (and don't say
performance wise - with all the string comparisons going on in a request
a small while loop in an error case won't affect that much)? Really, we
want to ensure that the filters are added to the last request (since those are the
filters that are going to be called). Sure, either patch fixes the bug
though -
sterling
On Mon, 12 Nov 2001, Justin Erenkrantz wrote:
> On Mon, Nov 12, 2001 at 10:59:14PM -0800, sterling wrote:
> > Hi -
> >
> > I still have an outstanding bug (and patch) that hasn't gotten a response.
> > I consider it a showstopper. Given the current default config simply add
> > a <Location /> stanza with auth enabled and that triggers the bug I
> > reported previously (the one where headers filters are never called).
>
> Try this patch on for size (my tree is non-buildable since I synced
> up). The thing here is that we walk up the request tree when we see
> a non-HTTP_OK code. So, if we were to save the request_rec* BEFORE
> we walk up the tree, I think we end up with the correct request_rec
> and save some time to boot.
>
> > There is a workaround - to disable the ErrorDocument stuff - but still, it
> > seems to me like it should at least be double checked before 'beta'.
>
> FWIW, the only thing I see stopping a beta is a segfault. Anything
> else, I don't give a rats ass about. =) And, *especially* if there
> is a workaround. Because at this point, 2.0.29-dev is
> non-buildable, so I think it is unlikely we can get 2.0.29 out in
> a reasonable time-frame. Remember, beta != bug-free. -- justin
>
> Index: modules/http/http_request.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/modules/http/http_request.c,v
> retrieving revision 1.118
> diff -u -r1.118 http_request.c
> --- modules/http/http_request.c 2001/11/11 22:31:03 1.118
> +++ modules/http/http_request.c 2001/11/13 06:10:41
> @@ -123,6 +123,11 @@
> int error_index = ap_index_of_response(type);
> char *custom_response = ap_response_code_string(r, error_index);
> int recursive_error = 0;
> + /* There are some cases where we walk up the request hierarchy
> + * to obtain the original error, but when adding the required_filters,
> + * we need to do so against the one we came in with. So, save it.
> + */
> + request_rec *cur = r;
>
> if (type == AP_FILTER_ERROR) {
> return;
> @@ -223,7 +229,7 @@
> custom_response);
> }
> }
> - add_required_filters(r);
> + add_required_filters(cur);
> ap_send_error_response(r, recursive_error);
> }
>
>
>
Re: 2_0_28 tarballs rolled and available
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Nov 12, 2001 at 10:59:14PM -0800, sterling wrote:
> Hi -
>
> I still have an outstanding bug (and patch) that hasn't gotten a response.
> I consider it a showstopper. Given the current default config simply add
> a <Location /> stanza with auth enabled and that triggers the bug I
> reported previously (the one where headers filters are never called).
Try this patch on for size (my tree is non-buildable since I synced
up). The thing here is that we walk up the request tree when we see
a non-HTTP_OK code. So, if we were to save the request_rec* BEFORE
we walk up the tree, I think we end up with the correct request_rec
and save some time to boot.
> There is a workaround - to disable the ErrorDocument stuff - but still, it
> seems to me like it should at least be double checked before 'beta'.
FWIW, the only thing I see stopping a beta is a segfault. Anything
else, I don't give a rats ass about. =) And, *especially* if there
is a workaround. Because at this point, 2.0.29-dev is
non-buildable, so I think it is unlikely we can get 2.0.29 out in
a reasonable time-frame. Remember, beta != bug-free. -- justin
Index: modules/http/http_request.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/http_request.c,v
retrieving revision 1.118
diff -u -r1.118 http_request.c
--- modules/http/http_request.c 2001/11/11 22:31:03 1.118
+++ modules/http/http_request.c 2001/11/13 06:10:41
@@ -123,6 +123,11 @@
int error_index = ap_index_of_response(type);
char *custom_response = ap_response_code_string(r, error_index);
int recursive_error = 0;
+ /* There are some cases where we walk up the request hierarchy
+ * to obtain the original error, but when adding the required_filters,
+ * we need to do so against the one we came in with. So, save it.
+ */
+ request_rec *cur = r;
if (type == AP_FILTER_ERROR) {
return;
@@ -223,7 +229,7 @@
custom_response);
}
}
- add_required_filters(r);
+ add_required_filters(cur);
ap_send_error_response(r, recursive_error);
}
Re: 2_0_28 tarballs rolled and available
Posted by sterling <st...@covalent.net>.
Hi -
I still have an outstanding bug (and patch) that hasn't gotten a response.
I consider it a showstopper. Given the current default config simply add
a <Location /> stanza with auth enabled and that triggers the bug I
reported previously (the one where headers filters are never called).
There is a workaround - to disable the ErrorDocument stuff - but still, it
seems to me like it should at least be double checked before 'beta'.
thanks -
sterling
On Mon, 12 Nov 2001, Justin Erenkrantz wrote:
> On Mon, Nov 12, 2001 at 05:19:17PM -0500, Greg Ames wrote:
> > ...in http://dev.apache.org/dist/ . Please download, test, and vote for
> > beta.
>
> +1 for beta. Compiles on Linux 2.4 and passes all httpd-tests.
>
> *Crosses fingers*
>
> -- justin
>
>
Re: 2_0_28 tarballs rolled and available
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Nov 12, 2001 at 05:19:17PM -0500, Greg Ames wrote:
> ...in http://dev.apache.org/dist/ . Please download, test, and vote for
> beta.
+1 for beta. Compiles on Linux 2.4 and passes all httpd-tests.
*Crosses fingers*
-- justin
Re: 2_0_28 tarballs rolled and available
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Nov 12, 2001 at 05:19:17PM -0500, Greg Ames wrote:
> ...in http://dev.apache.org/dist/ . Please download, test, and vote for
> beta.
+1 for beta
Compiles and passes all tests on Solaris 8/intel under prefork and worker.
-aaron
Re: 2_0_28 tarballs rolled and available
Posted by Sander Temme <sc...@covalent.net>.
on 11/12/01 3:46 PM, William A. Rowe, Jr. at wrowe@covalent.net wrote:
> Both Greg and I are curious, will OS X users really grok their build is
> darwin,
> or will we need lots of colorful notes? Or, do we choose a different name?
I can speak for myself only, but the ones that will build an Apache alpha
from source, will. I would advocate keeping 'darwin' as identifier for the
platform, because on the unix level it makes itself known as such:
[monalisa:~] sctemme% uname -a
Darwin MonaLisa 1.4 Darwin Kernel Version 1.4: Sun Sep 9 15:39:59 PDT 2001;
root:xnu/xnu-201.obj~1/RELEASE_PPC Power Macintosh powerpc
Upon a release, we could put a line in the release notes or README of the
dist/httpd directory that says 'For MacOSX, use the darwin distribution' and
/or rely on the Mac download sites to clue users in.
Downloading the darwin tarball right now.
S.
--
Covalent Technologies sctemme@covalent.net
Engineering group Voice: (415) 536 5214
645 Howard St. Fax: (415) 536 5210
San Francisco CA 94105
PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1
=======================================================
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message
=======================================================
Re: 2_0_28 tarballs rolled and available
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
Just chatted with Greg (his key is now signed on pgp.mit.edu), and I've renamed
the following to better get along with our mime-typing:
httpd-2_0_28-alpha.tar.gz.darwin[.asc] -> httpd-2_0_28-alpha-darwin.tar.gz[.asc]
Both Greg and I are curious, will OS X users really grok their build is darwin,
or will we need lots of colorful notes? Or, do we choose a different name?
I've just moved up:
httpd-2_0_28-alpha-win32.zip[.asc]
includes the .rc and .mak file intermediates for the Win32 build schema.
We need clearer docs in HEADER.html about source code 'flavors' at /dist/httpd/
before moving these to beta, to spare us the inevitable question, "Where are the
binarys???"
Bill
----- Original Message -----
From: "Greg Ames" <gr...@remulak.net>
To: "httpd" <de...@httpd.apache.org>
Sent: Monday, November 12, 2001 4:19 PM
Subject: 2_0_28 tarballs rolled and available
> ...in http://dev.apache.org/dist/ . Please download, test, and vote for
> beta.
>
> I made separate tarballs available for Mac OS X. Tarballs rolled with
> daedalus's libtool do not work on Darwin, so I used libtool 1.4.2 for
> that one. I used daedalus's libtool 1.4.2 for the others, which works
> on HP-UX. I stuck a READ-ME.Darwin file in the directory so hopefully
> Mac OS X users can figure it out.
>
> Thanks to Chuck M., Madhu, and Cliff for testing preliminary tarballs,
> and to OtherBill and Justin for taking care of serious issues after the
> original tag.
>
> Greg
>
Re: 2_0_28 tarballs rolled and available
Posted by Austin Gonyou <au...@coremetrics.com>.
I didnt' realize but I was using 2.0.29-dev. My apologies. I'll go get
the tarball and just compile that. 2.0.29 as of today though, works with
NO problems!
On Tue, 2001-11-13 at 13:45, William A. Rowe, Jr. wrote:
> From: "Sander Temme" <sc...@covalent.net>
> Sent: Tuesday, November 13, 2001 1:39 PM
>
>
> > I say Advisory +1 For Beta provided a release note entry that DSO
> currently
> > doesn't work on Darwin/MacOSX.
>
> Nor is HFS secure until someone goes in and hacks the case-insenstive
> define
> plus the APR_FILEINFO_TRUENAME gook for that platform's filesystem.
>
> Given the samba shares and other nightmares, I'm thinking that this
> becomes
> a <Directory > scoped option, either inferred at config time, or
> specified
> by the admin. If someone _really_ wants to skip all canonicalization on
> a
> given tree, that's fine [as long as they know what they are in for ;]
>
> Bill
--
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com
Re: 2_0_28 tarballs rolled and available
Posted by Sander Temme <sc...@covalent.net>.
on 11/13/01 11:45 AM, William A. Rowe, Jr. at wrowe@covalent.net wrote:
>> I say Advisory +1 For Beta provided a release note entry that DSO currently
>> doesn't work on Darwin/MacOSX.
>
> Nor is HFS secure until someone goes in and hacks the case-insenstive define
> plus the APR_FILEINFO_TRUENAME gook for that platform's filesystem.
That should go into the release notes too.
S.
--
Covalent Technologies sctemme@covalent.net
Engineering group Voice: (415) 536 5214
645 Howard St. Fax: (415) 536 5210
San Francisco CA 94105
PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1
=======================================================
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message
=======================================================
Re: 2_0_28 tarballs rolled and available
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Sander Temme" <sc...@covalent.net>
Sent: Tuesday, November 13, 2001 1:39 PM
> I say Advisory +1 For Beta provided a release note entry that DSO currently
> doesn't work on Darwin/MacOSX.
Nor is HFS secure until someone goes in and hacks the case-insenstive define
plus the APR_FILEINFO_TRUENAME gook for that platform's filesystem.
Given the samba shares and other nightmares, I'm thinking that this becomes
a <Directory > scoped option, either inferred at config time, or specified
by the admin. If someone _really_ wants to skip all canonicalization on a
given tree, that's fine [as long as they know what they are in for ;]
Bill
Re: 2_0_28 tarballs rolled and available
Posted by Sander Temme <sc...@covalent.net>.
on 11/12/01 2:19 PM, Greg Ames at gregames@remulak.net wrote:
> ...in http://dev.apache.org/dist/ . Please download, test, and vote for
> beta.
MacOS X 10.0 with the following ./configure line:
"./configure" \
"--prefix=/tmp/apache2" \
"--enable-mods-shared=most" \
"--with-port=8080" \
"--enable-maintainer-mode" \
"--with-layout=Apache" \
The following result:
[batmobile:apache2] sctemme$bin/apachectl start
Syntax error on line 198 of /tmp/apache2/conf/httpd.conf:
Can't locate API module structure `access_module' in file
/tmp/apache2/modules/mod_access.so: undefined symbol
bin/apachectl start: httpd could not be started
[batmobile:apache2] sctemme$
Note that this is a different error than the one we get on 10.1: that one
talks about a garbled module structure. I wouldn't be surprised if it's the
same problem though.
The same tarball, compiled statically:
"./configure" \
"--prefix=/tmp/apache2" \
"--enable-modules=most" \
"--with-port=8080" \
"--enable-maintainer-mode" \
"--with-layout=Apache" \
Starts up and serves pages. I haven't run the test suite on this machine
because it requires DSO.
Onwards to MacOS X 10.1... shared compile protests as above, static runs and
serves pages. I ran the perl-framework tests after commenting out all the
LoadModule lines and their collateral in the generated httpd.conf (as I have
a static compile):
Failed Test Status Wstat Total Fail Failed List of failed
----------------------------------------------------------------------------
---
apache/limits.t 0 13 10 1 10.00% 10
apache/post.t 9 2304 51 51 100.00% 1-51
apache/rwrite.t 57 57 100.00% 1-57
apr/uri.t 1 1 100.00% 1
filter/input_bo 2 2 100.00% 1-2
modules/access. 9 2304 408 405 99.26% 4-408
10 tests skipped.
Failed 6/28 test scripts, 78.57% okay. 517/1167 subtests failed, 55.70%
okay.
Is there a cleaner way to run static-only? I'll ask that of the test-dev
list.
I say Advisory +1 For Beta provided a release note entry that DSO currently
doesn't work on Darwin/MacOSX.
S.
--
Covalent Technologies sctemme@covalent.net
Engineering group Voice: (415) 536 5214
645 Howard St. Fax: (415) 536 5210
San Francisco CA 94105
PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1
=======================================================
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message
=======================================================