Re: Apache 1.3.31 RC Tarballs available
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-devm=107091289914815w=2 some of the issues there were fixed by myself and others, but a few remain outstanding. t/apache/contentlength.t 207 35.00% 2 6 10 14 16 18 20 t/modules/autoindex2.t 32 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 51214 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.t464 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.t924 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
On May 9, 2004, at 4:18 PM, Geoffrey Young wrote: t/apache/errordoc.t 2 51214 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/errordoc1..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.t2 51214 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.t464 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.t924 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
Re: Apache 1.3.31 RC Tarballs available
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
