Re: [PATCH] make test TEST_VERBOSE=1
On Wed, 18 Sep 2002, Geoffrey Young wrote: I think the attached patch behaves as suggested. perfectly, thanks.
Re: [PATCH] make test TEST_VERBOSE=1
On Wed, 18 Sep 2002, Doug MacEachern wrote: On Wed, 18 Sep 2002, Geoffrey Young wrote: I think the attached patch behaves as suggested. perfectly, thanks. with 5.8.0 that is. with 5.6.1, dies with: Error in option spec: verbose:1
Re: newbie question on perl-framework...
On Tue, 17 Sep 2002, David Hill wrote: Tried that (twice) and it did not help. Thanks for the pointer to the config blocks, missed that in my RTFM-ing. If I hand hack a conf file based on your pointer, things run much better, but what a pain t/TEST -clean t/TEST -trace=debug will give you some more info. I am beginning to think that the problem is related to the path to the libraries created by apxs. The DSO is created as ./c-modules/foo/.libs/libmod_foo.so I am trying to understand the perl code but have not found anything that deals with this stuff. that path is expected. if the .so isn't found, then it shouldn't be added to httpd.conf and tests skipped that depend on that module. you might want to look at the generated file: t/conf/apache_test_config.pm contains most of the collected info, including a list of cmodules from the c-modules directory.
Re: POST with no data
i think lwp does the right thing, but TestRequest.pm does not.
patch below should fix (untested).
--- Apache-Test/lib/Apache/TestRequest.pm 4 Apr 2002 00:54:26 - 1.71
+++ Apache-Test/lib/Apache/TestRequest.pm 17 Sep 2002 20:22:38 -
@@ -251,7 +251,7 @@
$credentials{$keep-{realm} || '__ALL__'} =
[$keep-{username}, $keep-{password}];
}
-if (my $content = $keep-{content}) {
+if (defined(my $content = $keep-{content})) {
if ($content eq '-') {
$content = join '', STDIN;
}
Re: minor change needed in mod_test_apr_uri.c
On Mon, 16 Sep 2002, Dave Hill wrote: Hi, Just starting to use the test framework on Tru64. Bumped into a compiler issue... Our compiler does not like multiline implicite strings. You can do muliline strings, you just need to end them with '\n\'. Attached is a diff -c of my change. I belive that the the change should work with other compilers. thanks, applied to cvs. p.s. if possible, diff -u is the prefered format for patches.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
this change is wrong. please revert and explain what you need so we can find the right solution. On 3 Jun 2002 [EMAIL PROTECTED] wrote: jerenkrantz2002/06/03 11:03:42 Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm Log: Only start one server instance until we need the other one for the proxy tests. Revision ChangesPath 1.137 +1 -1 httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm Index: TestConfig.pm === RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v retrieving revision 1.136 retrieving revision 1.137 diff -u -r1.136 -r1.137 --- TestConfig.pm 20 May 2002 22:25:34 - 1.136 +++ TestConfig.pm 3 Jun 2002 18:03:42 - 1.137 @@ -1553,7 +1553,7 @@ /IfModule IfModule prefork.c -StartServers @MaxClients@ +StartServers 1 MaxClients @MaxClients@ MaxRequestsPerChild 0 /IfModule
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, 3 Jun 2002, Aaron Bannert wrote: Cliff is always mentioning something like t/TEST -d gdb or something like that. Won't that run in -X mode automatically? yes.
Re: cvs commit: httpd-test/perl-framework README
On 3 Jun 2002 [EMAIL PROTECTED] wrote: aaron 2002/06/03 11:31:00 Modified:perl-framework README Log: Add a note about envoking gdb. note that this and heaps of other stuff is in httpd-test/perl-framework/Apache-Test/README which is where it belongs, since Apache-Test is the self-contained part that is used to build other test suites, such as modperl-2.0
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, 3 Jun 2002, Justin Erenkrantz wrote: The reason I don't like that is because if I need to restart the server I have to quit my gdb. I want my gdb to last longer than the process (so my breakpoints et al remain the same). you can use the -maxclients option or edit httpd.conf by hand before you start to debug. I'm confused why this commit is an issue. None of the other MPMs start multiple processes - why should prefork? it breaks any sort of proxy tests, various modperl test, etc. your change is just plain wrong, back it out. And, it's not like it won't start multiple processes when it needs to. -- justin umm, not with MaxClients 1 it won't
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, 3 Jun 2002, Justin Erenkrantz wrote: Um, as I pointed out, none of the other MPMs are configured like this. Only prefork would start multiple servers. The others always run under a single process. -- justin yeah, cos threaded mpms can handle concurrent requests with one process, prefork cannot.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, 3 Jun 2002, Doug MacEachern wrote: umm, not with MaxClients 1 it won't oh wait, you changed StartServers not MaxClients, maybe that isn't a problem.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, 3 Jun 2002, Justin Erenkrantz wrote: Um, I think you misread my commit. All I changed was StartServers. totally, i only read - @MaxClients@ + 1, never even saw StartServers. disregard my comments, they were meant for MaxClients, your change is fine with me.
rewritemap breakage
seems that the test suite now requires httpd-2.0-cvs from HEAD? server does not start with 1.3.x or 2.0.36: Syntax error on line 139 of .../t/conf/extra.conf RewriteMap: map file or program not found:/.../t/htdocs/modules/rewrite/append.pl foo
Re: cvs commit: httpd-test/perl-framework/Apache-Test README
On 19 May 2002 [EMAIL PROTECTED] wrote:
stas02/05/19 00:56:32
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
perl-framework/Apache-Test README
Log:
make the APACHE_TEST_COLOR env setting work when running from script
if running as batch, simply make sure that it's not set
updating the docs
...
-use constant COLOR = ($ENV{APACHE_TEST_COLOR} -t STDOUT) ? 1 : 0;
+use constant COLOR = $ENV{APACHE_TEST_COLOR} ? 1 : 0;
...
+When running in the batch mode and redirecting STDOUT to a file, make
+sure that the environment variable CAPACHE_TEST_COLOR is set to 0 or
+not set at all.
why this change? from perlfunc.pod:
-t Filehandle is opened to a tty.
color should always be turned off if that is not true.
i have APACHE_TEST_COLOR turned on in my shell rc file, but now i have to
unset it by hand when i do: t/TEST -v test.log
with the -t test, that hassle does not exist.
Re: cvs commit: httpd-test/perl-framework/Apache-Test README
On Mon, 20 May 2002, Stas Bekman wrote: Because the color setting doesn't have any effect if you build using the script. e.g. before my change this script won't work with colors: #!/bin/sh make clean APACHE_TEST_COLOR=1; export APACHE_TEST_COLOR /home/stas/perl/ithread/bin/perl Makefile.PL ... ... make make test that works fine (colorized as expected) for me with the old code, tested modperl-2.0 with: #!/bin/sh make clean APACHE_TEST_COLOR=1; export APACHE_TEST_COLOR $HOME/perl/farm/bin/perl-current-debug-ithreads Makefile.PL \ MP_AP_PREFIX=$HOME/apache/farm/install/worker-debug-shared-all-exp make make test -t is the right check. what do you see with the test script below? % sh test.sh STDOUT is a tty % sh test.sh test.log % cat test.log STDOUT is not a tty #!/bin/sh cat EOF make.test all: @perl -e 'printf STDOUT is%s a tty\n, -t STDOUT ? : not' EOF make -f make.test rm make.test
Re: inherit_documentroot breakage
On Tue, 14 May 2002, Cliff Woolley wrote: Thanks. I had noticed that commit, but thought maybe there would be some way to fix it by just adjusting extra.conf.in rather than reverting. Oh well, whatever works. :) it broke other stuff too. i have the functionality i was after now with the new should_load_module stuff, which is much more generic/useful than the original change that broke stuff.
Re: inherit_documentroot breakage
On Tue, 14 May 2002, Cliff Woolley wrote: Anybody know why this just started happening within the last few days? i just backed out the change from yesterday that caused it, should be ok now.
Re: perl-framework: make test recompiles everything all the time
On Tue, 16 Apr 2002, Stas Bekman wrote: one last question. Should the ssl certificates be recreated on t/TEST -clean (or 'make test')? yup. if you don't want them to be, there are several ways to keep t/conf/ssl/ca from being deleted/regenerated. careful though, since new ssl tests come along from time-to-time that require ssl/ca to be regenerated.
Re: perl-framework: make test recompiles everything all the time
On Fri, 12 Apr 2002, Stas Bekman wrote: Any idea why 'make test' in perl-framework is recompiling everything on each invocation without sources getting changed? Including rebuilding ssl certs. because 'make test' always does a t/TEST -clean after itself.
Re: perl-framework: make test recompiles everything all the time
On Sat, 13 Apr 2002, Stas Bekman wrote: but why 't/TEST -clean' removes the compiled modules? Shouldn't this be the job of 'make clean' and its variants? i don't really care. i never use 'make test' or even 'make' here. i have several checkouts of httpd-test/perl-framework that point to different servers, i only ever run Makefile.PL and t/TEST i think i did it that way, for one because 'make test' is only supposed to be run once, and t/TEST -conf/-clean is part of the 'test' really. if this is an issue for you, just run t/TEST instead of 'make test'.
Re: perl-framework: make test recompiles everything all the time
yup, t/TEST -conf will 'make' the c-modules, you can also just do 'make cmodules' if you only want to compile the changed c-modules.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestServer.pm
it is a nice feature when it works, so i've re-enabled for linux only. for the other platforms in the current state, its better to wait 60 seconds if the server fails to start than to throw and error and die when it has successfully started.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Fri, 5 Apr 2002, Cliff Woolley wrote: Doug. DOOD. You're working too hard. GO PARTY! ;) well, i am drinking a beer at least. wasn't expecting this GA push today, so i'm scrambling to get a modperl release together. then i will party like never before!
Re: cvs commit: httpd-test/perl-framework/t/ssl http.t
On Tue, 2 Apr 2002, Cliff Woolley wrote: The old version for me was giving a res-code of 200, not 500, because it was sending the http request to port 8529, not 8530. Maybe it's related to the version of LWP I'm using? strange. i don't think it is lwp related. probably not worth spending time on, the new version is fine.
Re: cvs commit: httpd-test/perl-framework/t/ssl http.t
On 2 Apr 2002 [EMAIL PROTECTED] wrote: jwoolley02/04/01 23:20:34 Modified:perl-framework/t/ssl http.t Log: Okay, well the test works now, but it still fails at the moment because mod_ssl really is broken. :) this patch does not change anything that i can see, both the old version and new do this: #lwp request: #GET http://localhost:8530/index.html HTTP/1.0 #User-Agent: libwww-perl/5.64 # #server response: #500 (Internal Server Error) unexpected EOF before status line seen please explain?
Re: perl-framework: Lower-grade ciphers and mod_ssl port broken
On Fri, 18 Jan 2002, Justin Erenkrantz wrote: Failed Test Status Wstat Total Fail Failed List of Failed ssl/varlookup.t 723 4.17% 34, 36-37 34, 36, and 37 are related to the ciphers in use. It seems my ciphers are different than expected. # testing : SSL_CIPHER # expected: 'EDH-RSA-DES-CBC3-SHA' # received: 'IDEA-CBC-SHA' not ok 34 # testing : SSL_CIPHER_ALGKEYSIZE # expected: '168' # received: '128' not ok 36 # testing : SSL_CIPHER_USEKEYSIZE # expected: '168' # received: '128' not ok 37 i can fix those. Also, port configuration of mod_ssl vhost is broken. I had to hack the config files (ssl/ssl.conf.in and apache_test_config.pm) to configure the mod_ssl server and get perl-framework to recognize it. -- justin working fine here. did you get errors or was it just ignored? is mod_ssl built static or shared? if shared, what file does the LoadModule ssl_module live in?
Re: What makes the server die with 255?
On Wed, 16 Jan 2002, Sander Temme wrote: Hi all, Built and ran HEAD on Darwin 5.2, and ran the httpd-test perl-framework. This dies with the following protest: server has died with status 255 (please examine t/logs/error_log) Terminated The log says: [batmobile:perl-framework] sctemme$cat t/logs/error_log [Wed Jan 16 15:44:04 2002] [notice] Digest: generating secret for digest authentication ... [Wed Jan 16 15:44:04 2002] [notice] Digest: done sounds like mod_auth_digest is broken. trying building httpd with --disable-auth_digest and see if things are happier.
Re: cvs commit: httpd-test/perl-framework/t/apache etags.t
On Thu, 10 Jan 2002, Rodent of Unusual Size wrote: Um, but it's going to work with 2.0. Please revert your patch because it's broken. The test for a 500 return allows the test to skip on versions of Apache that don't have the directive (like 1.3.22). Your change will cause the skip to be a failure instead. well, i said it was incomplete, MMN need to be checked too. and once its supported in 2.0 the condition can be updated to reflect that. skipping a test based on a 500 response code is bogus if you ask me. but isn't worth fussing over, so i just backed it out. The real issue is: why doesn't an invalid .htaccess file cause a 500 on 2.0? *That's* what needs to be solved. maybe because there is no .htaccess file that applies to /etags/test.txt
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestServer.pm
On Sun, 6 Jan 2002, Stas Bekman wrote:
I've done with this:
-eval 'END {
+eval 'my $parent_pid = $$;
+ END {
+ return unless $$ == $parent_pid; # because of fork
ok. i thought is_parent() could be useful elsewhere, but i guess we could
worry about that later if needed.
Digest::MD5 in TestSmoke?
perl-framework does not work with 5.6.1 due to Digest::MD5 requirement. i don't see any reason why this: my $digest = Digest::MD5::md5_hex(join '', @$ra_tests); cannot just be this: my $digest = join '', @$ra_tests; ??
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestServer.pm
On Mon, 7 Jan 2002, Stas Bekman wrote:
I needed it TestRun, whereas the fork was happening in TestServer. So it
was definitely easier to do it locally.
are you saying the following patch would not work?
Index: Apache-Test/lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.82
diff -u -r1.82 TestRun.pm
--- Apache-Test/lib/Apache/TestRun.pm 6 Jan 2002 07:08:05 - 1.82
+++ Apache-Test/lib/Apache/TestRun.pm 6 Jan 2002 18:45:46 -
@@ -248,6 +248,9 @@
$opts-{'run-tests'} ||= @$tests;
}
+my $parent_pid = $$;
+sub is_parent { $$ == $parent_pid }
+
my $caught_sig_int = 0;
sub install_sighandlers {
@@ -276,9 +279,8 @@
#must eval to install this END block, otherwise it will
#always run, a subclass might not want that
-eval 'my $parent_pid = $$;
- END {
- return unless $$ == $parent_pid; # because of fork
+eval 'END {
+ return unless is_parent(); # because of fork
local $?; # preserve the exit status
eval {
Apache::TestRun-new(test_config =
Re: Digest::MD5 in TestSmoke?
On Mon, 7 Jan 2002, Stas Bekman wrote: Sorry, can we put it into the Bundle? that's fine, but we cannot 'use Digest::MD5' the way it was before. else 'perl Makefile.PL' doesn't work without it. Because there can be hundreds of tests in @$ra_tests; Remember that the first run by default does 10 * #tests. In case of httpd-test it's 910 strings, at the average of 10 char/string it's about 10K chars, now add many iterations and the memory demands are growing fast. Not talking about lookups of the 10k keys in the hash. ok, that makes sense. Any alternatives under 5.6.1? dunno. if you want to require Digest::MD5 just for running t/SMOKE that's ok, but not for t/TEST.
Re: More basics on the perl-framework stuff..
On Sun, 23 Dec 2001, Stas Bekman wrote: That means two different ways to add configuration. yup. because we're doing different things. and for the record: there are already more than 2 ways to add configuration. tho only one to run the CONFIGURE routine. Why cannot we make the .pm scanner more generic? because it was designed to be specific to modperl and it will stay that way. in fact, it might become even more specific to modperl in the future. The magic is not mod_perl specific. most of configure_pm_tests is mod_perl specific. The __DATA__ section can work for non-modperl, so does APACHE_TEST_CONFIGURE. right, which is why i pointed out that we should just run add_module_config() and run_apache_test_config() on these other files, which are generic routines.
Re: [patch] don't complain about old core files
On Mon, 24 Dec 2001, Stas Bekman wrote: this patch: - s/scan/scan_core/ for consistency with warn_core - don't complain aload when an old core from some old run is found (i'm tired of remembering to remove old core files) nice, +1
Re: cvs commit: httpd-test/perl-framework/t/apache getfile.t
On Fri, 21 Dec 2001, Stas Bekman wrote: OK, here it is: I've finally called it skip_all() as it's a standalone function now. cool, +1. but would rather it still be called skip_unless()
Re: [patch] autogeneration of TEST/SMOKE/REPORT
On Fri, 21 Dec 2001, Stas Bekman wrote:
This patch removes the need for t/TEST.PL, t/SMOKE.PL, build/bugreport.pl
and implements in each set of the classes used by these scripts a
generate_script() method, which generates these scripts.
nice.
Issues:
- should it generate t/REPORT or just as before build/bug_report.pl?
t/REPORT
- If you look at ModPerl-Registry/t/TEST.PL, it cannot reuse
autogeneration, since it adds some more stuff
that's ok.
- If you try to generate t/SMOKE for ModPerl-Registry it'll need a
different 'use lib' adjustments.
you could pass a [EMAIL PROTECTED] arg to the generate methods that are added
to the
'use lib ...'
So it's not than much re-usable after all. Are you sure that we really
want this to be done in the way this patch does and not just to stick with
.PL scripts? I really prefer a the .PL scripts because of their easy
customizability.
i mainly wanted to see the bugreport stuff be re-usable in a module,
rather than having to copy a .pl script around to each project. having
the methods to generate t/{TEST,SMOKE,REPORT} are just a bonus. if a
project needs to customize more, then they just don't use the generation
methods.
Re: More basics on the perl-framework stuff..
On Fri, 21 Dec 2001, Stas Bekman wrote: I was thinking some more about this issue and came to a conclusion that there is nothing we should add, since we have already a working solution: close, but the current .pm scanner a bit too specific to mod_perl in terms of location (where the .pm's have to live) and magic performed. how about scanning for *.t.conf (or whatever extension), that just does the $self-add_module_config and $self-run_apache_test_config parts? then we could have: t/modules/access.t t/modules/access.t.conf
Re: More basics on the perl-framework stuff..
On Thu, 13 Dec 2001, Stas Bekman wrote:
agreed, but the other suggestion to check the first line of .t is too
restrictive.
how so? the first line thing is just to say 'scan this file'. if the
magic isn't on the first line, the file isn't scanned.
Also when you want to get to the CONFIGURE section you have to require()
the file, which means it'll run the code in it, which is not good.
(compare with .pm, where everything is made of functions).
right. so we do it different from .pm's and just eval the 'sub CONFIGURE
{...}' part. and for good luck, as part of the eval we can toss in:
use Apache::Test;
use Apache::TestUtil;
etc.
if the CONFIGURE sub needs anything else, it can 'require' it. no more
painful to the user than having it another file.
Also notice that Ken's request is different from what CONFIGURE does.
CONFIGURE doesn't add stuff to .conf, the __DATA__ section does.
i know that. i brought CONFIGURE into the conversation because if we're
going to scan .t's for __DATA__ we might as well look for CONFIGURE too
while we're there.
Re: [perl-framework] SSL certs/keys for non-mod_ssl
On Thu, 13 Dec 2001, Rodent of Unusual Size wrote:
You know what's popping my corn right now? Trying to
find out where the flippin' .conf files get a lot of their
contents. For instance, t/conf/extra.conf contains:
it is generated from this config in extra.conf.in:
IfModule mod_echo.c
VirtualHost mod_echo
ProtocolEcho On
/VirtualHost
IfModule @ssl_module@
VirtualHost mod_echo_ssl
ProtocolEcho On
SSLEngine On
/VirtualHost
/IfModule
/IfModule
whenever there is a VirtualHost mod_foo and mod_foo is available, it
is expanded into:
Listen $port_counter
VirtualHost _default_:$port_counter
ServerName $servername:$port_counter
where $port_counter starts at the default 8529 and is incremented for each
VirtualHost. VirtualHost mod_foo_ssl is expanded the same way, but only
if $ssl_module (normally mod_ssl.c) is also available.
the port number can then be looked up on the client side
using the module name. t/protocol/echo.t for example:
my @modules = qw(mod_echo);
if (Apache::Test::have_ssl()) {
$tests *= 2;
unshift @modules, 'mod_echo_ssl';
}
for my $module (@modules) {
my $sock = Apache::TestRequest::vhost_socket($module);
first time through, $sock is a socket connected to the port mod_echo is
listening on, second time is mod_echo with SSL enabled.
the routine that does the parsing/expansion for vhosts is
Apache::TestConfig::parse_vhost.
Re: [perl-framework] SSL certs/keys for non-mod_ssl
i just added a t/conf/ssl/README with descriptions. i would hope that the ibm ssl module can understand the same certificates and keys, as they are standard formats. the same if verisign or other well known ca were to issue them. what does ibm use for a crypto library? rsa? openssl? or does ibm have its own implementation?
Re: a new utility: failure tests sequence finder
concept sounds great, +1 haven't looked at the code, but i should probably be in a module, like Apache::TestSmoke. that can either be run with -M or a tiny generated t/SMOKE (like t/TEST) or from t/TEST. else each project that wants to use it needs a copy of util/smokerandom.pl the idea has always been for a project that wants a t/TEST only needs the Apache-Test directory. then they create custom t/conf/foo.conf.in, t/foo/*.t and everything else is setup for you.
Re: modules/dav on Win32
On Fri, 7 Dec 2001, Rodent of Unusual Size wrote:
@#*(^(#(@# windows.. }-(
After a lot of travail I've gotten to the point at which all
the prerequisites for modules/dav on Windows can be run.
(Only the Expat bundled with Apache seems to suffice for
XML::Parser, btw; the Win32 download from expat.sf.net
fails tests because of a missing XML_GetAttributeCount).
still hoping to see dav.t rewritten to use HTTP::Webdav
And now.. and now.. modules/dav is running, but crapping out
with
modules\dav.The getpwnam function is unimplemented at modules\dav.t
line 37.
dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 1-14
Is this missing getpwnam a deficiency of my Perl on Windows?
yes. i think the patch below will suffice.
Index: t/modules/dav.t
===
RCS file: /home/cvs/httpd-test/perl-framework/t/modules/dav.t,v
retrieving revision 1.4
diff -u -r1.4 dav.t
--- t/modules/dav.t 2001/11/12 07:18:47 1.4
+++ t/modules/dav.t 2001/12/07 19:06:01
@@ -34,8 +34,12 @@
## make sure its clean before we begin ##
unlink htdocs$uri if -e htdocs$uri;
mkdir htdocs/$dir, oct('755') unless -e htdocs/$dir;
-my ($login,$pass,$uid,$gid) = getpwnam($vars-{user});
-chown $uid, $gid, htdocs/$dir;
+
+eval {
+#not all platforms support getpwnam
+my($uid, $gid) = (getpwnam($vars-{user}))[2,3];
+chown $uid, $gid, htdocs/$dir;
+};
## set up resource and lock it ##
my $resource = $dav-new_resource( -uri = http://$server$uri;);
Re: New perl-framework failures
On Thu, 6 Dec 2001, Rodent of Unusual Size wrote:
Client-Response-Num: 3
...
my $request_num = $res-header('Client-Request-Num');
...
Was that supposed to be 'Client-Response-Num' instead of 'Request'?
no, that's correct for lwp 5.60. i just made a change so both versions
are supported.
Re: New perl-framework failures
On Thu, 6 Dec 2001, Rodent of Unusual Size wrote: Eh. So why am I not seeing Client-Request-Num in the LWP output? Rrrr... because your are using lwp 5.62? the change was actually made in 5.61, from Changes: - Client-Request-Num renamed to Client-Response-Num
Re: perl-framework: mod_dav but not mod_dav?
On Tue, 4 Dec 2001, Stas Bekman wrote: Actually, we don't have to run -t to test for failure, since the normal execution fails as well and for all cases (not only syntax errors). The problem is that we run: system command ; we can run $cmd -t| before that and check if the output contains Syntax OK or not.
Re: [patch] more robust startup + counting
On Wed, 5 Dec 2001, Stas Bekman wrote: I suggest having an APACHE_TEST_CRON_MODE env var which will also replace APACHE_TEST_NO_COLOR. Sounds OK? i'd just rather have a different name. this'll be useful for more than cron. in fact i'd be happy to stick with APACHE_TEST_NO_COLOR.
Re: cvs commit: httpd-test/perl-framework/t/apache getfile.t
On Wed, 5 Dec 2001, Stas Bekman wrote: I didn't get you? do you prefer to make this change and disengage skip stuff from plan: skip_unless(...); plan tests = $tests; i'd like it if the current shorthand continues to work: plan tests = $tests, ['lwp', 'cgi']; i would not like it if the only option to plan was the return value of skip_unless. so if the skip_unless extensions do not fit into the overloaded plan, then just detach it like you have above. we only call it in one .t at the moment (byterange), and i guess one more would call it if the extension is made (getfile).
Re: perl-framework: mod_dav but not mod_dav?
On Wed, 5 Dec 2001, Stas Bekman wrote: ok, but that catches only syntax errors. if we can catch the return status from system() we can catch all errors, causing the failure. that would be great.
Re: Testing remote server
On Tue, 4 Dec 2001, Rodent of Unusual Size wrote: Was 'foo' supposed to be a vhost on the current system, or was it supposed to be able to be a remote system? The latter is my goal (testing things like DAV on Win32 bites the Harry Houdini..). the latter.
Re: ssl/varlookup.t
On Sat, 1 Dec 2001, Cliff Woolley wrote:
Is this really a bug in httpd, or is it a bug in the test? I think it's a
bug in the test that only shows up days 1-9 of the month, but I just
thought I'd check before I went and 'fixed' the test.
bug in the test, fixed. there was another that would have showed up next
month :)
it is the expected result, ssl_var_lookup does:
else if (strcEQ(var, TIME_MON)) {
MKTIMESTR(%02d, tm_mon+1)
}
else if (strcEQ(var, TIME_DAY)) {
MKTIMESTR(%02d, tm_mday)
}
Re: [patch] more robust startup + counting
this broke something. i keep getting: % t/TEST ... waiting for server to start: ok (waited 0 secs) ... still waiting for server to warm up: ok (waited 1 secs) failed to start server! (please examine t/logs/error_log) and yet the server is running.
Re: [patch] user defined debug script
On Thu, 29 Nov 2001, Stas Bekman wrote: How does it live with t/.gdb-test-start, or do you start it manually (I mean without t/TEST -d)? it just works. try it: % cat .gdbinit define sr printf %s\n, ap_server_root end % t/TEST -d ctrl-c (gdb) sr /home/dougm/ap/httpd-test/perl-framework/t i intentionally chose a name other than .gdbinit (.gdb-test-start) for this reason. but that requires typing on every debug session :( I want to automate things to a maximum to make debugging less irritating and erroneous. no typing required with .gdbinit since you mentioned your custom files, can you please share the new .gdbinit ala .gdbinit in modperl 1.x sources? I guess you are talking about .gdbinit there's nothing useful in there to share. my point is that we do not need a new feature which re-invents functionality that already exists in gdb.
Re: [patch] user defined debug script
On Thu, 29 Nov 2001, Stas Bekman wrote: that's not what I meant. Look at the script I've posted: then add this to your ./.gdbinit: define myrun handle SIGPIPE pass handle SIGPIPE nostop set auto-solib-add 0 b ap_run_pre_config run -DONE_PROCESS -d `pwd`/t -f `pwd`/t/conf/httpd.conf \ -DAPACHE2 -DPERL_USEITHREADS sharedlibrary modperl b modperl_hook_init # start: modperl_hook_init continue end % gdb ~/apache-2.0/bin/httpd (gdb) myrun
Re: [patch] user defined debug script
On Thu, 22 Nov 2001, Stas Bekman wrote: this patch allows us to provide a manually crafted debug script, which cannot be automatically created. % t/TEST -d -commands=.my_gdb_script much easier to just create ./.gdbinit or ~/.gdbinit and gdb will find it for you. and of course, there's always the gdb 'source' command to pull it in from elsewhere. no need for this support to be in Apache-Test.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestCommon.pm
On Thu, 22 Nov 2001, Stas Bekman wrote: isn't it common only for httpd-test, but not really common for other projects using Apache-Test, e.g. mod_perl comes to mind. nope. Apache::TestCommon::run_write_test could also be used against mod_perl, php, java, python, ssi, cgi, or anything that can generate dynamic content. The reason I ask is that gozer has suggested to have a similar thing for mod_perl stuff. For example he saw that many methods that are based on apr_table_t have identical tests, so he suggested to write a common test and remove duplication from tests. But than you have already taken TestCommon here. I think these should live outside Apache-Test, somewhere under t/ specific to each project. For example t/lib/common.pm. that would be fine for common things specific to modperl.
Re: 2.0.28 results, need interpretation
On Tue, 13 Nov 2001, Aaron Bannert wrote: The limits failure has to with LimitRequestBody, and looks to be a known issue (see modules/http/http_protocol.c:1314, /* XXX shouldn't we enforce this for chunked encoding too? */). But you probably already knew this. :) ken told me he wasn't surprised that test is failing with 2.0, but didn't say why. As for the cgi error, is this the error that Cliff reported earlier? It looks like it's a simple error with how @CGI_MODULE@ is being replaced in t/conf/extra.conf.in on about line 175. In my setup, no matter what I do it gets replaced with mod_cgi.c, which means those directives are never included with worker's mod_cgid.c. Can someone with more experience with perl voodoo check this out and let me know what I'm doing wrong here? this is fixed now.
Re: New module for perl-framework
(resend, this never showed up on the list) From [EMAIL PROTECTED] Tue Nov 6 13:10:06 2001 -0800 Status: X-Status: X-Keywords: Date: Tue, 6 Nov 2001 13:10:05 -0800 (PST) From: Doug MacEachern [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: New module for perl-framework In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Nov 2001, Rodent of Unusual Size wrote: Um, it doesn't build the Makefile, and hence doesn't build it. It finds it, though. working fine here: % t/TEST -clean % mkdir c-modules/foo % cal c-modules/foo/mod_foo.c % t/TEST -conf ... mod_foo.c:1: parse error before `2001' ... % ls -l c-modules/foo/Makefile -rw-r--r--1 dougmdougm 249 Nov 6 13:08 c-modules/foo/Makefile
Re: Perl tests and server start
On Fri, 2 Nov 2001, Rodent of Unusual Size wrote: Well, if there's only one server running, never mind. But the messages look as though three are being started. the startup message says 'started' only once for the default 8529 port and 'listening' for all the vhosts.
Re: Perl tests and server start
On Mon, 22 Oct 2001, Rodent of Unusual Size wrote: I noticed yesterday that three servers are started even if the tests requested don't need 'em. That is, a server is started for mod_headers and mod_vhost_alias even if I ask for only a single test sequence that doesn't include those. those are just vhosts. what is the problem?
Re: mod_random_chunk
On Mon, 22 Oct 2001, Gary Benson wrote:
Hi,
If you remove the #define HTTPD_TEST_REQUIRE_APACHE 2 from
mod_random_chunk.c then it compiles and runs successfully but does not
pass the tests. It seems that it is not sending any headers: should it
be?
it would need to call ap_send_http_header(r); #ifdef APACHE1
and also notice this, not sure if it matters at all...
else if (len == 0) {
/* 1.x version used to do this; but chunk_filter does now */
#if 0
ap_bsetflag(r-connection-client, B_CHUNK, 0);
ap_bsetflag(r-connection-client, B_CHUNK, 1);
#endif
}
Re: Winnow?
On Sat, 20 Oct 2001, William A. Rowe, Jr. wrote: Could be cool if -winnow or some other arg would run only failed tests, for developers to quickly repeat the problem. there are already two ways to run selected tests: - tell t/TEST to only run certain tests: t/TEST t/modules/cgi t/modules/rewrite - create a t/SKIP file with passing tests setenvif.t access.t etc.t
Re: Apache-Test breakage
On Thu, 18 Oct 2001, Stas Bekman wrote: is there anything else we need to do with opts parsing at this stage? now that we know all args and which are meant as test files, anything else should throw an error. for example what ken saw: % t/TEST t/notexist currently ignores t/notexist and runs all tests instead. I think the break in the middle of config is important to fix, right? yes. the problem right now is if die() is thrown, files have been generated but the Apache::TestConfig object is not committed to t/conf/apache_test_config.pm. so t/TEST -clean does not know about those generated files. either a DESTROY or __DIE__ handler could probably be used to solve the problem.
Re: [patch] hint why the test was skipped
On Thu, 18 Oct 2001, Stas Bekman wrote: [Please let's decide where we discuss Apache-Test and send patches, the docs say dev@perl.apache.org, but in fact it's spread across the two lists. It seems that test-dev will eventually take over, since that's where people report problems.] here is fine i think. People already start complaining because they don't know why this or that test gets skipped, but they are techy enough to look at the code to figure out. Once we release Apache-Test, many people won't know to figure out why some tests are skipped. Therefore I've tried to solve this, so if I require have_module Chatbot::Eliza1 I get: i like the idea of hinting why a test is skipped. only thing is Missing foo might not be very informative, for example the tests that run against c-modules. none of the c-modules will be missing, but they might not be built because: - apxs is not available - the module requires 2.0 - etc missing mod_echo_post won't be very helpful in that case. then there are tests that are skipped unless 'have_apache 2.0', 'have_perl ithreads', etc. maybe just extend your patch so a .t can define: $Apache::Test::SkipReason = 'requires apxs and apache-2.0'; and the skip code does this: my $real_reason = $Apache::Test::SkipReason || $reason; print 1..0 # skipped: $real_reason \n; since each .t has its own process, there won't be a clash using the $Apache::TestSkip::Reason variable.
Re: Apache-Test breakage
On Thu, 18 Oct 2001, Stas Bekman wrote:
this patch does that:
nice, +1
but, indentation is messed up:
my $argv = $self-{argv};
+my @leftovers = ();
}
+push @leftovers, $_;
$self-{tests} = [EMAIL PROTECTED];
+$self-{argv} = [EMAIL PROTECTED];
$self-split_test_args;
+$self-die_on_invalid_args;
Re: Apache/2.0.27-dev and perl-framework and Darwin 1.4
On Wed, 17 Oct 2001, Sander Temme wrote: #0 0x0001e1a0 in load_module aside from the -d suggestion, if darwin has an strace equiv, might help to see what module is being loaded here.
Re: [patch] Re: Apache-Test breakage
On Thu, 18 Oct 2001, Stas Bekman wrote:
So it works when you run ./t/TEST, but when you run 'make test', for
some reason Makefile doesn't abort on exit from test_clean target, no
matter if I put exit -1, 0 or 1, and proceeds with run_tests target.
Does that have anything to do with the installed __DIE__ sighandler?
probably, since __DIE__ will stop the server. where did you put the
exit(1) call? i think it should work in the __DIE__ handler.
I suggest to review the code and get rid of the __DIE__ sighandler all
together and instead wrap the relevant pieces of code in eval block. Are
there any exception handling modules bundled in the core?
if you can switch to eval {} that would be fine.
In any case I think this patch can be committed without relation to the
__DIE__ issue.
looks good, +1
Re: Outch(es) on Win32 perl-framework
On Tue, 16 Oct 2001, William A. Rowe, Jr. wrote: [Tue Oct 16 19:07:41 2001] [error] (33501)No such host is known. : Cannot resolve host name _default_:mod_proxy --- ignoring! when config files are generated from .conf.in to .conf these are supposed to be replaced with a port number, see Apache::TestConfig::replace_vhost_modules(). Paths, across the board, are incorrect. We are using perl's understanding of '\' seperators in File::Find, etc, and need to keep Apache's conf in '/' syntax. This could explain some of the problems, above. ha, and here we were thinking that using File::Spec functions would make things portable. The list of skipped tests implies that we know nothing of the modules.c list from Win32. Can we change the logic to rely instead upon httpd -l ??? it does use httpd -l. see get_httpd_static_modules() in TestConfigParse.pm I would start debugging, but I rather expect there are all sorts of unix assumptions by the testbench and modules, WRT line endings and the like. Any suggestions on what to hack first? Alternate approaches to invoking t/TEST that could rule out/rule in suspects? See any patterns in the failure list? i would concentrate on getting the following to work: t/TEST -start and try a few simple urls: t/TEST -get / t/TEST -get /server-info i have an unused machine at home i've been thinking about install NT and msdev studio on, i could probably be more help that way.
Re: Outch(es) on Win32 perl-framework
bill, try the patch below. it should force File::Spec functions and
anything that uses them (Apache::Test*, File::Find, etc.) to use unix
/path/file.ext conventions.
Index: Apache-Test/lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.58
diff -u -r1.58 TestRun.pm
--- Apache-Test/lib/Apache/TestRun.pm 2001/10/17 01:30:40 1.58
+++ Apache-Test/lib/Apache/TestRun.pm 2001/10/17 01:47:55
@@ -3,6 +3,12 @@
use strict;
use warnings FATAL = 'all';
+BEGIN {
+$INC{'File/Spec.pm'} = __FILE__;
+require File::Spec::Unix;
+@File::Spec::ISA = qw(File::Spec::Unix);
+}
+
use Apache::TestConfig ();
use Apache::TestConfigC ();
use Apache::TestRequest ();
Re: Outch(es) on Win32 perl-framework
On Tue, 16 Oct 2001, William A. Rowe, Jr. wrote: join ':', $$resolve, $self-port($module); that's weird because there are checks to make sure both $$resolve and $module are initialized. seems to be what is killing all of the tests. wonder if this double check helps at all? --- Apache-Test/lib/Apache/TestConfig.pm2001/10/17 01:30:40 1.74 +++ Apache-Test/lib/Apache/TestConfig.pm2001/10/17 02:41:38 @@ -509,7 +509,7 @@ } } -join ':', $$resolve, $self-port($module); +join ':', $$resolve || 'localhost', $self-port($module || ''); } #look for mod_foo.so
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Tue, 16 Oct 2001, William A. Rowe, Jr. wrote: httpd is now 'undef'... not pretty... watching for the next commit. hmm, you might need to: t/TEST -clean (and double check that any *.conf in t/conf and t/conf/apache_test_config.pm are gone after that) and backing out that change means you'll need to use: perl Makefile.PL httpd .../Apache.exe rather than -httpd .../Apache.exe I believe the other patch you suggested for win32 paths solves our problem on that platform. ok great. As far as file 'comparisons' to the pod files, I believe we've probably opened those files in the wrong 'mode'... and we need to binmode them into binary (thus, all our mismatches :) Where would I find that comparison code? oh right, i'll need to dig to find it anyhow, i'll just go ahead and add the binmode() calls.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Tue, 16 Oct 2001, William A. Rowe, Jr. wrote: As far as file 'comparisons' to the pod files, I believe we've probably opened those files in the wrong 'mode'... and we need to binmode them into binary (thus, all our mismatches :) Where would I find that comparison code? hmm, server side the default-handler is sending the files, client side libwww-perl is reading the data over a socket, i don't think binmode() can be applied there, can it? and the comparision to the file on disk is done with -s $file; can you run that test with t/TEST -v t/apache/getfile so we can see what it reports for download and file bytes?
Re: cvs commit: httpd-test/perl-framework/t TEST.PL
On Wed, 17 Oct 2001, William A. Rowe, Jr. wrote:
It's ok, that patch broke win32 as well... we end up with paths like
wha? the 5.005 compat patch did not change behavior at all. the commit
message says:
backport to 5.005:
- open my $fh, ... = my $fh = Symbol::gensym(); open $fh, ...
- our @foo = use vars qw(@foo)
- create a stub warnings.pm
- complain if File::Spec::Functions does not exist
the latter two don't happen if $] = 5.006, and there's no way the other
two would change how paths are looked at.
C:/httpd-test/perl-framework/C:/httpd-test/perl-framework/t/conf
since it doesn't look to Unix like C:/ starts a path.
I'd suggest we revert, and find a better solution for Win32.
you must be talking about the patch that added this to Apache/TestRun.pm,
right??
BEGIN {
#Apache likes everything to be in /unix/path/file.ext format
$INC{'File/Spec.pm'} = __FILE__;
require File::Spec::Unix;
@File::Spec::ISA = qw(File::Spec::Unix);
}
Re: testing cookies under Apache-Test
On Wed, 17 Oct 2001, clayton cottingham wrote: = from cookie.t my %cookies = Apache::Cookie-fetch; #ive tried parse too Apache::Cookie only works inside Apache. it will not work in a .t file run by Test::Harness. see lwp docs on how to deal with cookies client side. modperl-1.xx also has a t/modules/cookie.t test.
Re: Why 5.6, and t/TEST not working as described
On Tue, 16 Oct 2001, Rodent of Unusual Size wrote: Since most of my Linux machines run RH 6.2, the requirement for Perl 5.6 is a bit onerous (RH hasn't built an RPM for 6.2). Why is 5.6 required? Apache-Test started out in the modperl-2.0 tree which requires 5.6. it could probably be made to work with older Perls, but nobody has asked until now. Running the full suite with t/TEST works fine, but when I tell it I want a specific set of tests run, or just to start the test server, it runs the whole suite as though I didn't specify any options at all. E.g., t/TEST -httpd /path/to/httpd -start starts the server, and then runs all the tests. looks like recent breakage, args picked up by GetOptions in Apache::PerlRun::getopts are being force to come before other options. stas can you please fix this. in the meantime ken, this will work: t/TEST -start -httpd /path/to/httpd
Re: httpd-test results with Apache 1.3.22
probably flaws in the test suite. i just tried with a fresh apache-1.3: Failed Test Stat Wstat Total Fail Failed List of Failed --- modules/alias.t 62 32 51.61% 3-12 19-38 61-62 php/strings3.t324 12.50% 29-32
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigPerl.pm
i don't feel strongly enough either way to debate further. i'll leave the decision to you stas.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigPerl.pm
On Sun, 16 Sep 2001, Stas wrote:
Hmm, we don't want to pass the package name to the package itself
why not?
this fixes it, so we can write:
sub APACHE_TEST_CONFIG {
my $self = shift;
this seems fine to me:
my($class, $config) = @_;
-eval { $module-APACHE_TEST_CONFIGURE($self); };
+no strict 'refs';
+eval { ${module}::APACHE_TEST_CONFIGURE-($self) };
this way passes use strict:
my $cv = \{${module}::APACHE_TEST_CONFIGURE};
eval { $cv-($self) };
but i think the current way in cvs is correct.
Re: What is test.o?
On Wed, 12 Sep 2001, Gary Benson wrote: rm -f blib/arch/auto/httpd-test/test.so LD_RUN_PATH= gcc -shared test.o -o blib/arch/auto/httpd-test/test.so gcc: test.o: No such file or directory gcc: No input files make: *** [blib/arch/auto/httpd-test/test.so] Error 1 not seeing that here. do you have a test.c or test.xs file in that directory by chance? actually, why is there any httpd-test directory relative to perl-framework at all?
Re: What is test.o?
On Wed, 12 Sep 2001, Gary Benson wrote: The makefile itself makes the directory, and puts a .exists file in it, but I don't know what it is trying to to do it or why. I've attached my makefile if you want to compare, or if you send me yours then I'll compare it instead... looks like there's a mod_random_chunk.c in your perl-framework/ directory?
Re: [patch] a cleaner make clean
On Mon, 10 Sep 2001, Stas Bekman wrote: Index: perl-framework/Makefile.PL looks good, +1
Re: new helper module Apache::TestUtil
On Thu, 6 Sep 2001, Stas Bekman wrote: I'd like to start properly document the packages, especially something like TestUtil. Should I do a pod section at the bottom of the package, or do inline pods? I know you prefer the former. i do. which do you prefer? anybody else?
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Gary Benson wrote:
+# untaint
+$ENV{PATH} = '/bin:/usr/bin';
this should be 'local $ENV{PATH} = ...;', does that help at all?
Re: Bundle::ApacheTest
On Thu, 6 Sep 2001, Stas Bekman wrote: The problem is that it's not on CPAN. So you cannot use CPAN::Grab to grab this bundle. doesn't need to be on cpan, just needs to be in your @INC or ~/.cpan/Bundle
Re: forcing cleanup
On Fri, 31 Aug 2001, Stas Bekman wrote: When you cvs update, make sure to run './t/TEST -clean'. I've noticed that one of the subtests in alias.t was failing. It was because extra.conf.in has been changed, but the stale autogenerated extra.conf was used. what about using MD5 checksums, to decide whether to rebuild .in files or not, to cause less errors and questions? just comparing mtimes would be good enough.
Re: How to make the c-modules run?
On Tue, 28 Aug 2001, Gary Benson wrote: BTW, is anyone on this list trying to use httpd-test on 1.3, or am I on my own here? the goal is for the tests to pass with 1.3, but i think most of us are developing with 2.0 right now. so keep the patches coming :-)
perl Makefile.PL
if you cvs up, be sure to rerun 'perl Makefile.PL apxs ...' since the *.pl scripts are now generated from *.pl.PL
Re: make test in modperl 2.0 is broken
On Sat, 11 Aug 2001, Stas Bekman wrote:
The recent addition of C modules stuff broke mod_perl's 'make test'.
Wherever $self-{cmodules_dir} is used it's undef, and hence fatal
warning.
fixed now.
Re: Problems with the test suite.
On Thu, 9 Aug 2001, Paul Edgar wrote: modules/expires.Undefined subroutine HTTP::Request::Common::HEAD btw, this should work without lwp installed, i will look into that.
Re: License status
On Wed, 8 Aug 2001, Gary Benson wrote: What license are these tests released under? I'm presuming they are under the ASL... yes, i've added a copy of the LICENSE to the top-level directory.
