Re: failing httpd-test tests
Agreed. I'll try to reproduce it and resolve it. Sorry for the breakage. no problem, that's part of the process. Oh, yeah, I got it right away when trying to build mp2. Looking at it. I think I've a good workaround for now. Please try again with the current cvs. Still having a problem? nope, looks good. --Geoff
Re: failing httpd-test tests
Joe Orton wrote: On Tue, Aug 10, 2004 at 09:56:12AM -0700, Stas Bekman wrote: Aha! Excellent, Geoff! Does it solve the problem by moving those default_module calls after getting httpd config? Moving the calls one line further on fixed it for me. OK to check in? (BTW your patch had whitespace issues and only applied with patch -l) Index: Apache-Test/lib/Apache/TestConfig.pm === RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v retrieving revision 1.235 diff -u -r1.235 TestConfig.pm --- Apache-Test/lib/Apache/TestConfig.pm 9 Aug 2004 06:19:15 - 1.235 +++ Apache-Test/lib/Apache/TestConfig.pm 10 Aug 2004 21:12:59 - @@ -313,13 +313,6 @@ $vars-{proxyssl_url} ||= ''; $vars-{defines} ||= ''; -$self-default_module(cgi= [qw(mod_cgi mod_cgid)]); -$self-default_module(thread = [qw(worker threaded)]); -$self-default_module(ssl= [qw(mod_ssl)]); -$self-default_module(access = [qw(mod_access mod_authz_host)]); -$self-default_module(auth = [qw(mod_auth mod_auth_basic)]); -$self-default_module(php= [qw(mod_php4 mod_php5)]); - $self-{hostport} = $self-hostport; $self-{server} = $self-new_test_server; @@ -359,6 +352,14 @@ } $self-inherit_config; #see TestConfigParse.pm + +$self-default_module(cgi= [qw(mod_cgi mod_cgid)]); +$self-default_module(thread = [qw(worker threaded)]); +$self-default_module(ssl= [qw(mod_ssl)]); +$self-default_module(access = [qw(mod_access mod_authz_host)]); +$self-default_module(auth = [qw(mod_auth mod_auth_basic)]); +$self-default_module(php= [qw(mod_php4 mod_php5)]); + $self-configure_httpd_eapi; #must come after inherit_config $self-{server}-post_config; I'd rather see it moved two statements (it still works, doesn't it?) so the eapi comes right after inherit_config. Otherwise, yes, please commit it. so are we all clean now? Any other problems? As a result of my changes, now the API has two wrappers Apache::Test::config (full config as before), and Apache::Test::basic_config, which is the same sans httpd information. For example to autogenerate t/TEST and other files you don't need to know anything about httpd, and therefore you shouldn't require users to supply that info before it's really needed. Until now things were silently failing (to find httpd stuff), making it really hard to trace some problems. Now things fail when something goes wrong, so this separation was important. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
On Wed, Aug 11, 2004 at 01:17:04AM -0700, Stas Bekman wrote: I'd rather see it moved two statements (it still works, doesn't it?) so the eapi comes right after inherit_config. Otherwise, yes, please commit it. Yes, great, done. so are we all clean now? Any other problems? No failures with HEAD again now - thanks a lot. joe
Re: forcing full config in Makefile.PL (was Re: failing httpd-test tests)
Geoffrey Young wrote: As a result of my changes, now the API has two wrappers Apache::Test::config (full config as before), and Apache::Test::basic_config, which is the same sans httpd information. For example to autogenerate t/TEST and other files you don't need to know anything about httpd, and therefore you shouldn't require users to supply that info before it's really needed. one of the things I've tried to do but was never able to get working was call have_apache within Makefile.PL. being able to do this would be a nice way to add a PREREQ_PM-type precondition for building modules that rely on, say, httpd 2.1. as a user it doesn't quite make sense why this wouldn't work - Makefile.PL is getting passed -apxs or -httpd, so you would think that after the call to filter_args the httpd version would be known. being able to support something like this, whether automatically or on command would be really great. that is, forcing a full configuration before calling WriteMakefile so that all the standard Apache::Test functions are available. Sure, just call Apache::Test::config and voila you have the full config in Makefile.PL. Don't forget that at the moment 99.9% of users will not have that provision of httpd/apxs during Makefile.PL, so you will want to check whether it's provided (and that's not bogus). Otherwise asking for a full config with no httpd/apxs provision will trigger interactive config at the Makefile.PL level, which doesn't sound good at all for the general case. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Joe Orton wrote: On Wed, Aug 11, 2004 at 01:17:04AM -0700, Stas Bekman wrote: I'd rather see it moved two statements (it still works, doesn't it?) so the eapi comes right after inherit_config. Otherwise, yes, please commit it. Yes, great, done. so are we all clean now? Any other problems? No failures with HEAD again now - thanks a lot. Excellent. Thanks Joe! -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Geoffrey Young wrote: But things are getting more and more fragile and dependant on each other indeed. right now a fresh checkout will not even run for me because I don't have an ssl-enabled apache to run against. this is not a minor issue, as I suspect I'm in the majority for normal users. Agreed. I'll try to reproduce it and resolve it. Sorry for the breakage. making the code less and less maintainable. exactly - I'm kind of at a loss for what exactly to do here to fix it. you made a few suggestions, but I really don't know what's best - between the sticky configuration stuff (that I still don't care for) and the new configuration breakdown I'm pretty much lost at the moment. We need to rethink how the things are configured in A-T, I think it all used to be just fine. well, maybe not fine but maintainable to a certain degree. then we started adding magic things like sticky preferences and the ability to move the test directory around and things got considerably more complex. Well, those things aren't magical, they were just solutions to the existing (some pretty bad) problems. I've a way too many other things to do, to just go and break Apache-Test for fun. write some sort of test suite to cover what's working, then completely rewrite the configuration process from scratch, making sure that things are still working. ideally, sure. I just can't think of how to do that. Do what? The test suite? I think this is the first step. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Stas Bekman wrote: Geoffrey Young wrote: But things are getting more and more fragile and dependant on each other indeed. right now a fresh checkout will not even run for me because I don't have an ssl-enabled apache to run against. this is not a minor issue, as I suspect I'm in the majority for normal users. Agreed. I'll try to reproduce it and resolve it. Sorry for the breakage. Oh, yeah, I got it right away when trying to build mp2. Looking at it. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
On Mon, Aug 09, 2004 at 02:33:34PM -0700, Stas Bekman wrote: I have tested with a checkout from Aug 1 and t/modules/access fails just the same, so it's definitely unrelated to my changes over the weekend. I I can't confirm that - the break occurs from the change between 18:00 and 19:00 UTC on 6th August + cvs -Q co -D '2004-08-06 18:00 +' -d pf-2004-08-06-18:00 httpd-test/perl-framework + pushd pf-2004-08-06-18:00 /tmp/regressoE4Aym/pf-2004-08-06-18:00 /tmp/regressoE4Aym + perl Makefile.PL -apxs /tmp/regressoE4Aym/2.1-root/bin/apxs + ./t/TEST -conf + grep auth_module t/conf/apache_test_config.pm 'auth_module_name' = 'mod_auth_basic', 'auth_module' = 'mod_auth_basic.c', + popd /tmp/regressoE4Aym + dir=pf-2004-08-06-19:00 + rm -rf pf-2004-08-06-19:00 + cvs -Q co -D '2004-08-06 19:00 +' -d pf-2004-08-06-19:00 httpd-test/perl-framework + pushd pf-2004-08-06-19:00 /tmp/regressoE4Aym/pf-2004-08-06-19:00 /tmp/regressoE4Aym + perl Makefile.PL -apxs /tmp/regressoE4Aym/2.1-root/bin/apxs + ./t/TEST -conf + grep auth_module t/conf/apache_test_config.pm 'auth_module_name' = 'mod_auth', 'auth_module' = 'mod_auth.c',
Re: failing httpd-test tests
On Fri, Aug 06, 2004 at 07:26:31PM -0700, Stas Bekman wrote: Do you also get these tests failing with the current httpd-2.0? Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/limits.t 102 20.00% 7 9 t/ssl/basicauth.t32 66.67% 2-3 t/ssl/env.t 28 14 50.00% 15-28 t/ssl/proxy.t 169 116 68.64% 1-58 112-169 t/ssl/require.t 52 40.00% 2 5 t/ssl/varlookup.t 72 72 100.00% 1-72 t/ssl/verify.t 31 33.33% 2 I get just the ssl/basicauth.t failures and a whole bunch in modules/access.t too using HEAD of httpd and httpd-test. The tests were all passing on July 25th before I went on holiday so it is a relatively recent regression, but I turned off my nightly builds in the meantime so I'll try and track it down manually...
Re: failing httpd-test tests
There is something funky in the default_module detection; it's picking up mod_auth.c and mod_access.c as the {auth,access}_module settings rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0. $ grep access_ conf/apache_test_config.pm 'access_module_name' = 'mod_access', 'access_module' = 'mod_access.c that the failures I'm seeing here. ./TEST -debug seems to have stopper working sometime too $ ./TEST -debug [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /tmp/regressPPKikg/pf/t/TEST -debug [warning] server localhost.localdomain:8529 shutdown Use of uninitialized value in concatenation (.) or string at Apache-Test/lib/Apache/TestServer.pm line 130. any ideas? joe
Re: failing httpd-test tests
On Mon, Aug 09, 2004 at 10:48:39AM -0400, Geoffrey Young wrote: Joe Orton wrote: There is something funky in the default_module detection; it's picking up mod_auth.c and mod_access.c as the {auth,access}_module settings rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0. ... I'm not sure if that's something stas touched or not. helpful information at this point would be some of the verbose output from the module selection reports using 'export APACHE_TEST_TRACE_LEVEL=debug' when running t/TEST -conf. just to reduce things a bit, starting from a fresh checkout might be useful too - I'm still seeing random failures in some tests when I switch from 2.0 to 2.1 in the same working directory, even after running 'make realclean' and t/TEST -clean, but I haven't been able to put my finger on it. OK, attached ./t/TEST -conf output after fresh checkout. joe [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /var/tmp/pf-4/t/TEST -conf [ debug] no custom config data was loaded [ debug] configuring httpd [ debug] no custom config data was loaded [ debug] Writing custom config /var/tmp/pf-4/lib/Apache/TestConfigData.pm Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens [EMAIL PROTECTED] Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens [EMAIL PROTECTED] [ debug] isolated httpd_info VERSION = Apache/2.1.0-dev [ debug] isolated httpd_info BUILT = Aug 9 2004 09:08:40 [ debug] isolated httpd_info MODULE_MAGIC_NUMBER = 20040425:1 [ debug] isolated httpd_info SERVER_MPM = Prefork [ debug] isolated httpd_defines APACHE_MPM_DIR = server/mpm/prefork [ debug] isolated httpd_defines APR_HAS_SENDFILE = 1 [ debug] isolated httpd_defines APR_HAS_MMAP = 1 [ debug] isolated httpd_defines APR_HAVE_IPV6 (IPv4-mapped addresses enabled) = 1 [ debug] isolated httpd_defines APR_USE_SYSVSEM_SERIALIZE = 1 [ debug] isolated httpd_defines APR_USE_PTHREAD_SERIALIZE = 1 [ debug] isolated httpd_defines SINGLE_LISTEN_UNSERIALIZED_ACCEPT = 1 [ debug] isolated httpd_defines APR_HAS_OTHER_CHILD = 1 [ debug] isolated httpd_defines AP_HAVE_RELIABLE_PIPED_LOGS = 1 [ debug] isolated httpd_defines HTTPD_ROOT = /tmp/regressPPKikg/2.1-root [ debug] isolated httpd_defines SUEXEC_BIN = /tmp/regressPPKikg/2.1-root/bin/suexec [ debug] isolated httpd_defines DEFAULT_PIDLOG = logs/httpd.pid [ debug] isolated httpd_defines DEFAULT_SCOREBOARD = logs/apache_runtime_status [ debug] isolated httpd_defines DEFAULT_LOCKFILE = logs/accept.lock [ debug] isolated httpd_defines DEFAULT_ERRORLOG = logs/error_log [ debug] isolated httpd_defines AP_TYPES_CONFIG_FILE = conf/mime.types [ debug] isolated httpd_defines SERVER_CONFIG_FILE = conf/httpd.conf [ debug] inheriting config file: /tmp/regressPPKikg/2.1-root/conf/httpd.conf [ debug] using httpd.conf inherited ServerRoot to resolve conf/ssl.conf [ debug] conf/ssl.conf successfully resolved to existing file /tmp/regressPPKikg/2.1-root/conf/ssl.conf [ debug] inheriting config file: /tmp/regressPPKikg/2.1-root/conf/ssl.conf [ debug] using httpd.conf inherited ServerRoot to resolve modules/mod_echo.so [ debug] modules/mod_echo.so successfully resolved to existing file /tmp/regressPPKikg/2.1-root/modules/mod_echo.so [ debug] Found: echo_module = mod_echo.c [ debug] LoadModule echo_module mod_echo.c [ debug] using httpd.conf inherited ServerRoot to resolve modules/mod_case_filter.so [ debug] modules/mod_case_filter.so successfully resolved to existing file /tmp/regressPPKikg/2.1-root/modules/mod_case_filter.so [ debug] Found: case_filter_module = mod_case_filter.c [ debug] LoadModule case_filter_module mod_case_filter.c [ debug] using httpd.conf inherited ServerRoot to resolve modules/mod_case_filter_in.so [ debug] modules/mod_case_filter_in.so successfully resolved to existing file /tmp/regressPPKikg/2.1-root/modules/mod_case_filter_in.so [ debug] Found: case_filter_in_module = mod_case_filter_in.c [ debug] LoadModule case_filter_in_module mod_case_filter_in.c [ debug] using httpd.conf inherited ServerRoot to resolve modules/mod_deflate.so [ debug] modules/mod_deflate.so successfully resolved to existing file /tmp/regressPPKikg/2.1-root/modules/mod_deflate.so [ debug] Found: deflate_module = mod_deflate.c [ debug] LoadModule deflate_module mod_deflate.c [ debug] using httpd.conf inherited ServerRoot to resolve modules/mod_expires.so [ debug] modules/mod_expires.so successfully resolved to existing file /tmp/regressPPKikg/2.1-root/modules/mod_expires.so [ debug] Found: expires_module = mod_expires.c [ debug] LoadModule expires_module mod_expires.c [ debug] using httpd.conf inherited ServerRoot to resolve modules/mod_headers.so [ debug] modules/mod_headers.so successfully resolved to existing file /tmp/regressPPKikg/2.1-root/modules/mod_headers.so [ debug] Found: headers_module = mod_headers.c [ debug] LoadModule headers_module mod_headers.c [ debug] using httpd.conf inherited
Re: failing httpd-test tests
Yes, sorry I'm talking about 2.1 here of course. I debugged this as far as finding that $self-{modules} appears to be empty at the time that the -default_module calls are made. Attached: 1) patch to add debugging to default_module 2) ./TEST -conf output with patch applied 3) resultant apache_test_config.pm Index: Apache-Test/lib/Apache/TestConfig.pm === RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v retrieving revision 1.235 diff -u -r1.235 TestConfig.pm --- Apache-Test/lib/Apache/TestConfig.pm9 Aug 2004 06:19:15 - 1.235 +++ Apache-Test/lib/Apache/TestConfig.pm9 Aug 2004 15:37:38 - @@ -371,13 +371,27 @@ my $mname = $name . '_module_name'; +debug dm: looking for $mname; + +if ($self-{vars}-{$mname}) { +debug dm: already got $self-{vars}-{$mname}; +} + unless ($self-{vars}-{$mname}) { ($self-{vars}-{$mname}) = grep { $self-{modules}-{$_.c}; } @$choices; +if ($self-{vars}-{$mname}) { +debug dm: found $self-{vars}-{$mname} from choices; +} else { +debug dm: falling back on default $choices-[0]; +} + $self-{vars}-{$mname} ||= $choices-[0]; } + +debug dm: found $self-{vars}-{$mname}; $self-{vars}-{$name . '_module'} = $self-{vars}-{$mname} . '.c' [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /var/tmp/pf-4/t/TEST -conf [ debug] no custom config data was loaded [ debug] dm: looking for cgi_module_name [ debug] dm: falling back on default mod_cgi [ debug] dm: found mod_cgi [ debug] dm: looking for thread_module_name [ debug] dm: falling back on default worker [ debug] dm: found worker [ debug] dm: looking for ssl_module_name [ debug] dm: falling back on default mod_ssl [ debug] dm: found mod_ssl [ debug] dm: looking for access_module_name [ debug] dm: falling back on default mod_access [ debug] dm: found mod_access [ debug] dm: looking for auth_module_name [ debug] dm: falling back on default mod_auth [ debug] dm: found mod_auth [ debug] dm: looking for php_module_name [ debug] dm: falling back on default mod_php4 [ debug] dm: found mod_php4 [ debug] configuring httpd [ debug] no custom config data was loaded [ debug] Writing custom config /var/tmp/pf-4/lib/Apache/TestConfigData.pm Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens [EMAIL PROTECTED] Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens [EMAIL PROTECTED] [ debug] isolated httpd_info VERSION = Apache/2.1.0-dev [ debug] isolated httpd_info BUILT = Aug 9 2004 09:08:40 [ debug] isolated httpd_info MODULE_MAGIC_NUMBER = 20040425:1 [ debug] isolated httpd_info SERVER_MPM = Prefork [ debug] isolated httpd_defines APACHE_MPM_DIR = server/mpm/prefork [ debug] isolated httpd_defines APR_HAS_SENDFILE = 1 [ debug] isolated httpd_defines APR_HAS_MMAP = 1 [ debug] isolated httpd_defines APR_HAVE_IPV6 (IPv4-mapped addresses enabled) = 1 [ debug] isolated httpd_defines APR_USE_SYSVSEM_SERIALIZE = 1 [ debug] isolated httpd_defines APR_USE_PTHREAD_SERIALIZE = 1 [ debug] isolated httpd_defines SINGLE_LISTEN_UNSERIALIZED_ACCEPT = 1 [ debug] isolated httpd_defines APR_HAS_OTHER_CHILD = 1 [ debug] isolated httpd_defines AP_HAVE_RELIABLE_PIPED_LOGS = 1 [ debug] isolated httpd_defines HTTPD_ROOT = /tmp/regressPPKikg/2.1-root [ debug] isolated httpd_defines SUEXEC_BIN = /tmp/regressPPKikg/2.1-root/bin/suexec [ debug] isolated httpd_defines DEFAULT_PIDLOG = logs/httpd.pid [ debug] isolated httpd_defines DEFAULT_SCOREBOARD = logs/apache_runtime_status [ debug] isolated httpd_defines DEFAULT_LOCKFILE = logs/accept.lock [ debug] isolated httpd_defines DEFAULT_ERRORLOG = logs/error_log [ debug] isolated httpd_defines AP_TYPES_CONFIG_FILE = conf/mime.types [ debug] isolated httpd_defines SERVER_CONFIG_FILE = conf/httpd.conf [ debug] inheriting config file: /tmp/regressPPKikg/2.1-root/conf/httpd.conf [ debug] using httpd.conf inherited ServerRoot to resolve conf/ssl.conf [ debug] conf/ssl.conf successfully resolved to existing file /tmp/regressPPKikg/2.1-root/conf/ssl.conf [ debug] inheriting config file: /tmp/regressPPKikg/2.1-root/conf/ssl.conf [ debug] using httpd.conf inherited ServerRoot to resolve modules/mod_echo.so [ debug] modules/mod_echo.so successfully resolved to existing file /tmp/regressPPKikg/2.1-root/modules/mod_echo.so [ debug] Found: echo_module = mod_echo.c [ debug] LoadModule echo_module mod_echo.c [ debug] using httpd.conf inherited ServerRoot to resolve modules/mod_case_filter.so [ debug] modules/mod_case_filter.so successfully resolved to existing file /tmp/regressPPKikg/2.1-root/modules/mod_case_filter.so [ debug] Found: case_filter_module = mod_case_filter.c [ debug] LoadModule case_filter_module mod_case_filter.c [ debug] using httpd.conf inherited ServerRoot
Re: failing httpd-test tests
On Mon, Aug 09, 2004 at 11:55:57AM -0400, Geoffrey Young wrote: Joe Orton wrote: Yes, sorry I'm talking about 2.1 here of course. I debugged this as far as finding that $self-{modules} appears to be empty at the time that the -default_module calls are made. yes, I see that there is no aaa stuff in your resulting conf, which I assume is because you don't have any aaa LoadModule statements in your main httpd.conf. this should be fine under normal circumstances. the only thing I can think of that might trip this up is if you have those modules compiled statically, but I'm not entirely sure. Yes, indeed. $ ./bin/httpd -l | grep mod_auth mod_authn_file.c mod_authn_default.c mod_authz_host.c mod_authz_groupfile.c mod_authz_user.c mod_authz_default.c mod_auth_basic.c anyway, if t/modules/access.t is failing for you, please run $ t/TEST t/modules/access.t -v and post the resulting output - the call to need_access should be sufficient to keep that test from running at all if it can't find an appropriate aaa module. All tests which expect access do pass, all those expecting access denial fail, i.e. failing exactly as if no access control is applied. # Order mutual-failure # Allow from 127.0.0.1/16 # Deny from 66.6.6.6 # expecting access. ok 374 # --- ... # Order mutual-failure # Allow from 66.6.6.6 # Deny from 66.6.6.6 # expecting access denial. # Failed test 408 in t/modules/access.t at line 185 fail #8 not ok 408 does that help? joe
Re: failing httpd-test tests
Geoffrey Young wrote: Joe Orton wrote: There is something funky in the default_module detection; it's picking up mod_auth.c and mod_access.c as the {auth,access}_module settings rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0. $ grep access_ conf/apache_test_config.pm 'access_module_name' = 'mod_access', 'access_module' = 'mod_access.c that the failures I'm seeing here. any ideas? I'm not sure if that's something stas touched or not. I think not, but I'm not 100% sure. All I did is split the A-T configuration process in 2 parts, postponing the httpd-specific information finding to a later stage. helpful information at this point would be some of the verbose output from the module selection reports using 'export APACHE_TEST_TRACE_LEVEL=debug' when running t/TEST -conf. it's simpler with: t/TEST -conf -trace=debug :) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Joe Orton wrote: There is something funky in the default_module detection; it's picking up mod_auth.c and mod_access.c as the {auth,access}_module settings rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0. $ grep access_ conf/apache_test_config.pm 'access_module_name' = 'mod_access', 'access_module' = 'mod_access.c that the failures I'm seeing here. ./TEST -debug seems to have stopper working sometime too $ ./TEST -debug [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /tmp/regressPPKikg/pf/t/TEST -debug [warning] server localhost.localdomain:8529 shutdown Use of uninitialized value in concatenation (.) or string at Apache-Test/lib/Apache/TestServer.pm line 130. any ideas? Indeed. I've committed the fix. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
failing httpd-test tests
Do you also get these tests failing with the current httpd-2.0? Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/limits.t 102 20.00% 7 9 t/ssl/basicauth.t32 66.67% 2-3 t/ssl/env.t 28 14 50.00% 15-28 t/ssl/proxy.t 169 116 68.64% 1-58 112-169 t/ssl/require.t 52 40.00% 2 5 t/ssl/varlookup.t 72 72 100.00% 1-72 t/ssl/verify.t 31 33.33% 2 It's hard to know whether my recent changes in Apache-Test didn't break things, when so many tests fail (they were failing before my changes). -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Stas Bekman wrote: Do you also get these tests failing with the current httpd-2.0? Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/limits.t 102 20.00% 7 9 I only get this one on a clean checkout (before your changes - no time to test now :) --Geoff