You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2004/05/07 17:15:40 UTC
Apache 1.3.31 RC Tarballs available
Via:
http://httpd.apache.org/dev/dist/
I'd like to announce and release the 11th.
Re: Apache 1.3.31 RC Tarballs available
Posted by Chuck Short <ch...@rogers.com>.
Looks good on gentoo as well.
chuck
On Sunday 09 May 2004 17:02, Kean Johnston wrote:
> Jim Jagielski wrote:
> > Via:
> >
> > http://httpd.apache.org/dev/dist/
>
> Looks good on SCO OpenServer 5.0.7 and UnixWare 7.1.3.
>
> Kean
Re: Apache 1.3.31 RC Tarballs available
Posted by Kean Johnston <jk...@sco.com>.
Jim Jagielski wrote:
> Via:
>
> http://httpd.apache.org/dev/dist/
Looks good on SCO OpenServer 5.0.7 and UnixWare 7.1.3.
Kean
Re: Apache 1.3.31 RC Tarballs available
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Use of uninitialized value in concatenation (.) or string at
> /home/sctemme/asf/perl-framework/Apache-Test/lib/Apache/TestRequest.pm
> The single request for /index.html is the framework's ping to see if
> the server has started. It is not part of the errordoc tests, which
> suggests that these don't get to the server at all.
yes. with 'use warnings FATAL => 'all'' the above error is causing the test
to die before it ever starts.
the problem seems to be in Apache::TestRequest::resolve_url(), but there is
no way for me to tell from here which part isn't being found properly.
are you running ssl? maybe putting this line
Apache::TestRequest::scheme('http');
just prior to the
Apache::TestRequest::module('error_document');
line in t/apache/errordoc.t would help. this appears to be the only
difference between errordoc.t and other modules that use a similar set of
directives to configure the test.
outside of that make sure that it's a fresh, pristine checkout, as if you
have some files hanging around it might collide with some of the
autogenerated stuff.
if neither of these work we'll have to poke around a bit in the internals,
but let's wait and see.
>>
>> it would be great to have the tests at 100% for current 1.3, 2.0, and
>> 2.1.
>> if we can get it to that point I volunteer to be the project watchdog
>> who
>> will pipe up if some commit causes the framework to suddenly fail (at
>> least
>> on the platform I run, currently fedora). but until we get to 100% the
>> framework is kinda useless for RC testing as far as I'm concerned -
>> "known
>> failures" don't really mean much for this kind of thing.
>
>
> It has long been one of my desires to do an automated nightly
> build/test run on all three branches. As I get my lab set up here
> (which should happen in the next couple of weeks), I may be able to
> finally get that set up.
cool, that would be great.
>
> When I was testing a product based on httpd 2.0, I would keep a list of
> known failures (we had some patches that the framework didn't deal
> with) on our internal Wiki, so I would know that a test had been
> failing and I wouldn't have to analyze every failure to death every
> time.
yeah, that's the problem, wasting time trying to figure out whether the
failure is real or not, then somebody else doing the same thing. and it's
not an easy process, getting gritty with the code to make absolutely sure
whether the failure is in the codebase or the test expectations.
> That was stuff like OpenSSL would put the email field name of a
> certificate DN in uppercase, and RSA SSLC would put it in lowercase. Or
> was it the other way around?
it would be great if we could capture that kind of thing in the test itself,
either in the actual test or in the framework (allow for case-insensitive
matches, for instance).
if you're willing (and can share internal knowledge publically, etc), I can
help integrate this particular issue into the framework. really, I'll do
whatever is required to get us at 100% - massive handholding if you know
what the issue is but can't quite grok the framework, verbose non-RTFM
explanations over irc or email, whatever...
>
> Anyway, it would be great to get something like that going on a daily
> basis. Kinda like an httpd project interpretation of Gump, like, Httpump.
agreed. well, let's see about what we can do to get the framework at 100%
and we can go from there. it's great to have someone else interested in all
of this :)
--Geoff
Re: Apache 1.3.31 RC Tarballs available
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Use of uninitialized value in concatenation (.) or string at
> /home/sctemme/asf/perl-framework/Apache-Test/lib/Apache/TestRequest.pm
> The single request for /index.html is the framework's ping to see if
> the server has started. It is not part of the errordoc tests, which
> suggests that these don't get to the server at all.
yes. with 'use warnings FATAL => 'all'' the above error is causing the test
to die before it ever starts.
the problem seems to be in Apache::TestRequest::resolve_url(), but there is
no way for me to tell from here which part isn't being found properly.
are you running ssl? maybe putting this line
Apache::TestRequest::scheme('http');
just prior to the
Apache::TestRequest::module('error_document');
line in t/apache/errordoc.t would help. this appears to be the only
difference between errordoc.t and other modules that use a similar set of
directives to configure the test.
outside of that make sure that it's a fresh, pristine checkout, as if you
have some files hanging around it might collide with some of the
autogenerated stuff.
if neither of these work we'll have to poke around a bit in the internals,
but let's wait and see.
>>
>> it would be great to have the tests at 100% for current 1.3, 2.0, and
>> 2.1.
>> if we can get it to that point I volunteer to be the project watchdog
>> who
>> will pipe up if some commit causes the framework to suddenly fail (at
>> least
>> on the platform I run, currently fedora). but until we get to 100% the
>> framework is kinda useless for RC testing as far as I'm concerned -
>> "known
>> failures" don't really mean much for this kind of thing.
>
>
> It has long been one of my desires to do an automated nightly
> build/test run on all three branches. As I get my lab set up here
> (which should happen in the next couple of weeks), I may be able to
> finally get that set up.
cool, that would be great.
>
> When I was testing a product based on httpd 2.0, I would keep a list of
> known failures (we had some patches that the framework didn't deal
> with) on our internal Wiki, so I would know that a test had been
> failing and I wouldn't have to analyze every failure to death every
> time.
yeah, that's the problem, wasting time trying to figure out whether the
failure is real or not, then somebody else doing the same thing. and it's
not an easy process, getting gritty with the code to make absolutely sure
whether the failure is in the codebase or the test expectations.
> That was stuff like OpenSSL would put the email field name of a
> certificate DN in uppercase, and RSA SSLC would put it in lowercase. Or
> was it the other way around?
it would be great if we could capture that kind of thing in the test itself,
either in the actual test or in the framework (allow for case-insensitive
matches, for instance).
if you're willing (and can share internal knowledge publically, etc), I can
help integrate this particular issue into the framework. really, I'll do
whatever is required to get us at 100% - massive handholding if you know
what the issue is but can't quite grok the framework, verbose non-RTFM
explanations over irc or email, whatever...
>
> Anyway, it would be great to get something like that going on a daily
> basis. Kinda like an httpd project interpretation of Gump, like, Httpump.
agreed. well, let's see about what we can do to get the framework at 100%
and we can go from there. it's great to have someone else interested in all
of this :)
--Geoff
Re: Apache 1.3.31 RC Tarballs available
Posted by Sander Temme <sa...@temme.net>.
On May 9, 2004, at 4:18 PM, Geoffrey Young wrote:
>> t/apache/errordoc.t 2 512 14 14 100.00% 1-14
>
> I added that test recently and it passes for me on fedora. can you try
>
> $ t/TEST t/apache/errordoc.t -v
>
> and send that along (along with any relevant error_log messages).
> that all
> tests fail probably mean that it's not picking up on a required
> configuration thingy.
Same exact configuration I originally posted about, on same somewhat
updated RH 8 box.
tty says:
t/TEST -httpd /tmp/ap/bin/httpd -apxs /tmp/ap/bin/apxs -v
t/apache/errordoc.t
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl
/home/sctemme/asf/perl-framework/t/TEST -httpd '/tmp/ap/bin/httpd'
-apxs '/tmp/ap/bin/apxs' -v 't/apache/errordoc.t'
[ notice] mod_test_ssl.c requires Apache version 2, skipping.
[ notice] mod_test_pass_brigade.c requires Apache version 2, skipping.
[ notice] mod_test_apr_uri.c requires Apache version 2, skipping.
[ notice] mod_nntp_like.c requires Apache version 2, skipping.
[ notice] mod_input_body_filter.c requires Apache version 2, skipping.
[ notice] mod_client_add_filter.c requires Apache version 2, skipping.
make: Nothing to be done for `all'.
/tmp/ap/bin/httpd -d /home/sctemme/asf/perl-framework/t -f
/home/sctemme/asf/perl-framework/t/conf/httpd.conf -D APACHE1 -D
PERL_USEITHREADS
using Apache/1.3.31
waiting 60 seconds for server to start: .....
waiting 60 seconds for server to start: ok (waited 3 secs)
server eartha:8529 started
t/apache/errordoc....1..14
# Running under perl version 5.008 for linux
# Current time local: Mon May 10 09:56:05 2004
# Current time GMT: Mon May 10 16:56:05 2004
# Using Test.pm version 1.23
Use of uninitialized value in concatenation (.) or string at
/home/sctemme/asf/perl-framework/Apache-Test/lib/Apache/TestRequest.pm
line 185.
dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 1-14
Failed 14/14 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
------------------------------------------------------------------------
-------
t/apache/errordoc.t 2 512 14 14 100.00% 1-14
Failed 1/1 test scripts, 0.00% okay. 14/14 subtests failed, 0.00% okay.
[warning] server eartha:8529 shutdown
[ error] error running tests (please examine t/logs/error_log)
Access log:
127.0.0.1 - - [10/May/2004:09:56:05 -0700] "GET /index.html HTTP/1.0"
200 26
(Huh, only one entry for fourteen tests?)
Error log:
[Mon May 10 09:56:04 2004] [info] created shared memory segment #524292
[Mon May 10 09:56:04 2004] [notice] Apache/1.3.31 (Unix) configured --
resuming normal operations
[Mon May 10 09:56:04 2004] [info] Server built: May 8 2004 07:49:35
[Mon May 10 09:56:04 2004] [notice] Accept mutex: sysvsem (Default:
sysvsem)
[Mon May 10 09:56:07 2004] [info] removed PID file
/home/sctemme/asf/perl-framework/t/logs/httpd.pid (pid=11234)
[Mon May 10 09:56:07 2004] [notice] caught SIGTERM, shutting down
(not exotic at all)
Rewrite log:
127.0.0.1 - - [10/May/2004:09:56:05 -0700]
[eartha/sid#8093d54][rid#80c3edc/initial] (2) init rewrite engine with
requested uri /index.html
127.0.0.1 - - [10/May/2004:09:56:05 -0700]
[eartha/sid#8093d54][rid#80c3edc/initial] (1) pass through /index.html
(that's that same request we saw in access_log)
The single request for /index.html is the framework's ping to see if
the server has started. It is not part of the errordoc tests, which
suggests that these don't get to the server at all.
>
>> t/modules/cgi.t 46 4 8.70% 5-6 13-14
>
> this just hangs for me, but there were some changes introduced
> recently that
> may account for this - without looking at the change log it something
> about
> STDERR IIRC.
Yes, it hangs for the longest time and then continues.
>> t/modules/expires.t 92 4 4.35% 13 21 33 45
>
> fails for me as well.
>
> it would be great to have the tests at 100% for current 1.3, 2.0, and
> 2.1.
> if we can get it to that point I volunteer to be the project watchdog
> who
> will pipe up if some commit causes the framework to suddenly fail (at
> least
> on the platform I run, currently fedora). but until we get to 100% the
> framework is kinda useless for RC testing as far as I'm concerned -
> "known
> failures" don't really mean much for this kind of thing.
It has long been one of my desires to do an automated nightly
build/test run on all three branches. As I get my lab set up here
(which should happen in the next couple of weeks), I may be able to
finally get that set up.
When I was testing a product based on httpd 2.0, I would keep a list of
known failures (we had some patches that the framework didn't deal
with) on our internal Wiki, so I would know that a test had been
failing and I wouldn't have to analyze every failure to death every
time. That was stuff like OpenSSL would put the email field name of a
certificate DN in uppercase, and RSA SSLC would put it in lowercase. Or
was it the other way around?
Anyway, it would be great to get something like that going on a daily
basis. Kinda like an httpd project interpretation of Gump, like,
Httpump.
S.
--
sander@temme.net http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Apache 1.3.31 RC Tarballs available
Posted by Sander Temme <sa...@temme.net>.
On May 9, 2004, at 4:18 PM, Geoffrey Young wrote:
>> t/apache/errordoc.t 2 512 14 14 100.00% 1-14
>
> I added that test recently and it passes for me on fedora. can you try
>
> $ t/TEST t/apache/errordoc.t -v
>
> and send that along (along with any relevant error_log messages).
> that all
> tests fail probably mean that it's not picking up on a required
> configuration thingy.
Same exact configuration I originally posted about, on same somewhat
updated RH 8 box.
tty says:
t/TEST -httpd /tmp/ap/bin/httpd -apxs /tmp/ap/bin/apxs -v
t/apache/errordoc.t
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl
/home/sctemme/asf/perl-framework/t/TEST -httpd '/tmp/ap/bin/httpd'
-apxs '/tmp/ap/bin/apxs' -v 't/apache/errordoc.t'
[ notice] mod_test_ssl.c requires Apache version 2, skipping.
[ notice] mod_test_pass_brigade.c requires Apache version 2, skipping.
[ notice] mod_test_apr_uri.c requires Apache version 2, skipping.
[ notice] mod_nntp_like.c requires Apache version 2, skipping.
[ notice] mod_input_body_filter.c requires Apache version 2, skipping.
[ notice] mod_client_add_filter.c requires Apache version 2, skipping.
make: Nothing to be done for `all'.
/tmp/ap/bin/httpd -d /home/sctemme/asf/perl-framework/t -f
/home/sctemme/asf/perl-framework/t/conf/httpd.conf -D APACHE1 -D
PERL_USEITHREADS
using Apache/1.3.31
waiting 60 seconds for server to start: .....
waiting 60 seconds for server to start: ok (waited 3 secs)
server eartha:8529 started
t/apache/errordoc....1..14
# Running under perl version 5.008 for linux
# Current time local: Mon May 10 09:56:05 2004
# Current time GMT: Mon May 10 16:56:05 2004
# Using Test.pm version 1.23
Use of uninitialized value in concatenation (.) or string at
/home/sctemme/asf/perl-framework/Apache-Test/lib/Apache/TestRequest.pm
line 185.
dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 1-14
Failed 14/14 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
------------------------------------------------------------------------
-------
t/apache/errordoc.t 2 512 14 14 100.00% 1-14
Failed 1/1 test scripts, 0.00% okay. 14/14 subtests failed, 0.00% okay.
[warning] server eartha:8529 shutdown
[ error] error running tests (please examine t/logs/error_log)
Access log:
127.0.0.1 - - [10/May/2004:09:56:05 -0700] "GET /index.html HTTP/1.0"
200 26
(Huh, only one entry for fourteen tests?)
Error log:
[Mon May 10 09:56:04 2004] [info] created shared memory segment #524292
[Mon May 10 09:56:04 2004] [notice] Apache/1.3.31 (Unix) configured --
resuming normal operations
[Mon May 10 09:56:04 2004] [info] Server built: May 8 2004 07:49:35
[Mon May 10 09:56:04 2004] [notice] Accept mutex: sysvsem (Default:
sysvsem)
[Mon May 10 09:56:07 2004] [info] removed PID file
/home/sctemme/asf/perl-framework/t/logs/httpd.pid (pid=11234)
[Mon May 10 09:56:07 2004] [notice] caught SIGTERM, shutting down
(not exotic at all)
Rewrite log:
127.0.0.1 - - [10/May/2004:09:56:05 -0700]
[eartha/sid#8093d54][rid#80c3edc/initial] (2) init rewrite engine with
requested uri /index.html
127.0.0.1 - - [10/May/2004:09:56:05 -0700]
[eartha/sid#8093d54][rid#80c3edc/initial] (1) pass through /index.html
(that's that same request we saw in access_log)
The single request for /index.html is the framework's ping to see if
the server has started. It is not part of the errordoc tests, which
suggests that these don't get to the server at all.
>
>> t/modules/cgi.t 46 4 8.70% 5-6 13-14
>
> this just hangs for me, but there were some changes introduced
> recently that
> may account for this - without looking at the change log it something
> about
> STDERR IIRC.
Yes, it hangs for the longest time and then continues.
>> t/modules/expires.t 92 4 4.35% 13 21 33 45
>
> fails for me as well.
>
> it would be great to have the tests at 100% for current 1.3, 2.0, and
> 2.1.
> if we can get it to that point I volunteer to be the project watchdog
> who
> will pipe up if some commit causes the framework to suddenly fail (at
> least
> on the platform I run, currently fedora). but until we get to 100% the
> framework is kinda useless for RC testing as far as I'm concerned -
> "known
> failures" don't really mean much for this kind of thing.
It has long been one of my desires to do an automated nightly
build/test run on all three branches. As I get my lab set up here
(which should happen in the next couple of weeks), I may be able to
finally get that set up.
When I was testing a product based on httpd 2.0, I would keep a list of
known failures (we had some patches that the framework didn't deal
with) on our internal Wiki, so I would know that a test had been
failing and I wouldn't have to analyze every failure to death every
time. That was stuff like OpenSSL would put the email field name of a
certificate DN in uppercase, and RSA SSLC would put it in lowercase. Or
was it the other way around?
Anyway, it would be great to get something like that going on a daily
basis. Kinda like an httpd project interpretation of Gump, like,
Httpump.
S.
--
sander@temme.net http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Apache 1.3.31 RC Tarballs available
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
cross-posting to test-dev@, which is probably where we ought to discuss the
gory details...
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ------------------------------------------------------------------------
at this point the test part of the perl-framework is largely unmaintained.
a few months ago I tried to stir up some interest in cleaning it up:
http://marc.theaimsgroup.com/?l=apache-test-dev&m=107091289914815&w=2
some of the issues there were fixed by myself and others, but a few remain
outstanding.
> t/apache/contentlength.t 20 7 35.00% 2 6 10 14 16 18 20
> t/modules/autoindex2.t 3 2 66.67% 1 3
these (or a subset thereof) have been failing at least since that email, but
I just haven't gotten around to looking at them yet.
> (1 subtest UNEXPECTEDLY SUCCEEDED)
IIRC this is from t/apache/include? I suspect this is due to some
backported changes that were never updated in the test suite by andre or
myself. I'll look at that this week unless andre beats me to it.
> t/apache/errordoc.t 2 512 14 14 100.00% 1-14
I added that test recently and it passes for me on fedora. can you try
$ t/TEST t/apache/errordoc.t -v
and send that along (along with any relevant error_log messages). that all
tests fail probably mean that it's not picking up on a required
configuration thingy.
> t/modules/cgi.t 46 4 8.70% 5-6 13-14
this just hangs for me, but there were some changes introduced recently that
may account for this - without looking at the change log it something about
STDERR IIRC.
> t/modules/expires.t 92 4 4.35% 13 21 33 45
fails for me as well.
it would be great to have the tests at 100% for current 1.3, 2.0, and 2.1.
if we can get it to that point I volunteer to be the project watchdog who
will pipe up if some commit causes the framework to suddenly fail (at least
on the platform I run, currently fedora). but until we get to 100% the
framework is kinda useless for RC testing as far as I'm concerned - "known
failures" don't really mean much for this kind of thing.
--Geoff
Re: Apache 1.3.31 RC Tarballs available
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
cross-posting to test-dev@, which is probably where we ought to discuss the
gory details...
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ------------------------------------------------------------------------
at this point the test part of the perl-framework is largely unmaintained.
a few months ago I tried to stir up some interest in cleaning it up:
http://marc.theaimsgroup.com/?l=apache-test-dev&m=107091289914815&w=2
some of the issues there were fixed by myself and others, but a few remain
outstanding.
> t/apache/contentlength.t 20 7 35.00% 2 6 10 14 16 18 20
> t/modules/autoindex2.t 3 2 66.67% 1 3
these (or a subset thereof) have been failing at least since that email, but
I just haven't gotten around to looking at them yet.
> (1 subtest UNEXPECTEDLY SUCCEEDED)
IIRC this is from t/apache/include? I suspect this is due to some
backported changes that were never updated in the test suite by andre or
myself. I'll look at that this week unless andre beats me to it.
> t/apache/errordoc.t 2 512 14 14 100.00% 1-14
I added that test recently and it passes for me on fedora. can you try
$ t/TEST t/apache/errordoc.t -v
and send that along (along with any relevant error_log messages). that all
tests fail probably mean that it's not picking up on a required
configuration thingy.
> t/modules/cgi.t 46 4 8.70% 5-6 13-14
this just hangs for me, but there were some changes introduced recently that
may account for this - without looking at the change log it something about
STDERR IIRC.
> t/modules/expires.t 92 4 4.35% 13 21 33 45
fails for me as well.
it would be great to have the tests at 100% for current 1.3, 2.0, and 2.1.
if we can get it to that point I volunteer to be the project watchdog who
will pipe up if some commit causes the framework to suddenly fail (at least
on the platform I run, currently fedora). but until we get to 100% the
framework is kinda useless for RC testing as far as I'm concerned - "known
failures" don't really mean much for this kind of thing.
--Geoff
Re: Apache 1.3.31 RC Tarballs available
Posted by Sander Temme <sa...@temme.net>.
I ran the perl-framework against the tarball on three platforms:
On Darwin MonaLisa 7.3.0 Darwin Kernel Version 7.3.0: Fri Mar 5
14:22:55 PST 2004; root:xnu/xnu-517.3.15.obj~4/RELEASE_PPC Power
Macintosh powerpc
Failed Test Stat Wstat Total Fail Failed List of Failed
------------------------------------------------------------------------
-------
t/apache/contentlength.t 20 7 35.00% 2 6 10 14 16 18
20
t/modules/autoindex2.t 3 2 66.67% 1 3
t/modules/expires.t 92 4 4.35% 13 21 33 45
(1 subtest UNEXPECTEDLY SUCCEEDED), 12 tests and 14 subtests skipped.
Failed 3/41 test scripts, 92.68% okay. 13/2175 subtests failed, 99.40%
okay.
On FreeBSD bagheera.shangrila.covalent.net 5.2.1-RELEASE FreeBSD
5.2.1-RELEASE #0: Mon Feb 23 20:45:55 GMT 2004
root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC i386
Failed Test Stat Wstat Total Fail Failed List of Failed
------------------------------------------------------------------------
-------
t/apache/contentlength.t 20 7 35.00% 2 6 10 14 16 18
20
t/modules/autoindex2.t 3 2 66.67% 1 3
t/modules/expires.t 92 4 4.35% 13 21 33 45
t/modules/include.t 77 1 1.30% 44
(1 subtest UNEXPECTEDLY SUCCEEDED), 12 tests and 14 subtests skipped.
On Linux eartha 2.4.20-28.8 #1 Thu Dec 18 12:53:39 EST 2003 i686 i686
i386 GNU/Linux
Failed Test Stat Wstat Total Fail Failed List of Failed
------------------------------------------------------------------------
-------
t/apache/contentlength.t 20 7 35.00% 2 6 10 14 16 18
20
t/apache/errordoc.t 2 512 14 14 100.00% 1-14
t/modules/autoindex2.t 3 2 66.67% 1 3
t/modules/cgi.t 46 4 8.70% 5-6 13-14
t/modules/expires.t 92 4 4.35% 13 21 33 45
t/modules/include.t 25 6400 77 77 100.00% 1-77
12 tests skipped.
Failed 6/41 test scripts, 85.37% okay. 108/2171 subtests failed, 95.03%
okay.
I don't know how many and which of these are known failures: I haven't
the time today to run regressions against .29.
S.
--
sander@temme.net http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Apache 1.3.31 RC Tarballs available
Posted by André Malo <nd...@perlig.de>.
* Joshua Slive <jo...@slive.ca> wrote:
> The URL has been posted on slashdot :-(
:-( I'd say, let's move it away. It's not released yet. period.
nd
--
print "Just Another Perl Hacker";
# André Malo, <http://pub.perlig.de/> #
Re: Apache 1.3.31 RC Tarballs available
Posted by Chip Cuccio <ch...@norlug.org>.
* Joshua Slive <jo...@slive.ca>
|__ Fri, May 07, 2004 at 03:14:08PM -0400:
> The URL has been posted on slashdot :-(
Oh no. It's not official yet. :-/
--
Chip Cuccio | <ch...@norlug.org>
NORLUG VP and Sysadmin | <http://norlug.org/~chipster/>
Northfield Linux Users' Group | Northfield, Minnesota USA
Re: Apache 1.3.31 RC Tarballs available
Posted by Joshua Slive <jo...@slive.ca>.
The URL has been posted on slashdot :-(
Joshua.
Re: Apache 1.3.31 RC Tarballs available
Posted by Chip Cuccio <ch...@norlug.org>.
Thumbs up on;
- Red Hat Linux 7.2, 7.3, 8.0, & 9.0
- Red Hat Enterprise Linux 2.1 & 3.0
- Fedora Core 1 Linux
- Slackware Linux 8.1, 9.0, 9.1, & -current
Thanks.
--
Chip Cuccio | <ch...@norlug.org>
NORLUG VP and Sysadmin | <http://norlug.org/~chipster/>
Northfield Linux Users' Group | Northfield, Minnesota USA
Re: Apache 1.3.31 RC Tarballs available
Posted by Kean Johnston <jk...@sco.com>.
> I'd like to announce and release the 11th.
Are we still on track for this? Reports seem to have been good ...
Kean
Re: Apache 1.3.31 RC Tarballs available
Posted by Sander Temme <sa...@temme.net>.
On May 7, 2004, at 8:15 AM, Jim Jagielski wrote:
> Via:
>
> http://httpd.apache.org/dev/dist/
>
>
> I'd like to announce and release the 11th.
Except Slashdot beat you to the punch: <http://apache.slashdot.org/>.
S.
--
sander@temme.net http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF