[STATUS] (httpd-test: perl-framework) Wed Dec 21 23:54:19 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Dec 14 23:53:05 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Dec 7 23:56:03 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Nov 30 23:54:11 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Nov 23 23:54:27 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Nov 16 23:54:30 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Nov 9 23:53:55 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Nov 2 23:54:34 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Oct 26 23:53:40 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Oct 12 23:55:05 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Sep 21 23:48:26 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Sep 14 23:47:09 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Jul 6 23:46:08 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Jun 22 23:47:04 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Jun 15 23:46:15 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Jun 1 23:46:54 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed May 18 23:46:18 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed May 4 23:46:12 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Apr 27 23:46:17 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Apr 20 23:46:11 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Apr 13 23:48:10 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Apr 6 23:46:09 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Mar 30 23:46:06 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Mar 23 23:45:58 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Mar 16 23:47:23 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Mar 9 23:46:19 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Feb 23 23:46:13 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Wed Feb 16 23:46:33 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Thu Feb 10 06:05:10 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Thu 27 Jan 2005 12:22:26 AM EST

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Thu 06 Jan 2005 11:29:45 AM EST

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

Re: [STATUS] (httpd-test: perl-framework) Wed Jan 5 23:45:15 2005

[Rodent of Unusual Size]

-BEGIN PGP SIGNED MESSAGE-

Rodent of Unusual Size wrote:
> httpd-test/perl-framework STATUS: -*-text-*-
> Last modified at [$Date: 2002/03/09 05:22:48 $]

Well, bugger.  This moved to subversion and I didn't notice; these
have been coming from the old CVS.  Fixed momentarily and new ones
sent out..
- --
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist  http://Apache-Server.Com/

"Millennium hand and shrimp!"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBQd1lBZrNPMCpn3XdAQETswP/ak2MOk2lNdhsvcV8qjPbmrJcon87w4Eu
+Vi6OLCd4hKedyVGh36eUC8RP3Yhn4cueo64B1jbQjQdIbzCDm6rvslXv3S3YuQK
3dmXLp2TLmQEZfVmmk0tFbU5wWf/MXk0Zrc+VAk9FsDM5ALbjod9sjDWPUyqbtss
7H+dOBASmkA=
=w+yA
-END PGP SIGNATURE-

[STATUS] (httpd-test: perl-framework) Wed Jan 5 23:45:15 2005

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2002/03/09 05:22:48 $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Fri 31 Dec 2004 02:15:07 PM EST

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2002/03/09 05:22:48 $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

[STATUS] (httpd-test: perl-framework) Thu 23 Dec 2004 07:26:29 AM EST

[Rodent of Unusual Size]

httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2002/03/09 05:22:48 $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: <[EMAIL PROTECTED]>
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:

Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php

[William A. Rowe, Jr.]

At 03:27 PM 11/23/2004, Joe Orton wrote:

>> Second, whenever we fail any CAN-2004-.t we must direct the
>> user to some patch where they can remedy the situation.  I'm sort
>> of laughing that I spent 4 hours yesterday researching two vulns
>> that many other engineers had spent 4 hours researching.  The
>> laughable thing - show me on www.php.net where they call out any
>> patches for 4.3.x to these two incidents?
>
>They don't, it was fixed silently, I mailed them about that but they
>didn't seem inclined to do anything about it.  If you want to follow up
>on that some more, great, but ranting about it here won't make much 
>difference.

Sure it will.  *We* simply put in a policy of not testing 
for garbage, with no solution, that is not our own doing 
or all together tangential to our projects.

I'll contemplate how to inject useful references in the
test results summary.

The rest was a rant which I don't expect us to do anything about :)

Bill

Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php

[Joe Orton]

On Tue, Nov 23, 2004 at 12:55:16PM -0600, William Rowe wrote:
> What I questioned was why we were doing the security validation 
> of PHP when it's outside the scope of httpd, or isn't due to some
> interaction with httpd.

This is true for most of the functional tests of PHP in t/php/ which
Covalent donated.  I don't necessarily disagree, but I do I find it
useful.  Possibly these tests could go in the PHP test suite as well,
I'm not sure.  If that's your itch...

> I also questioned shoving scary security/CAN-2004-.t failures
> at our users.  FIRST this should never have been in security/ -
> it should have been a php/ test.  Again, this is not our security
> incident within httpd.

I don't really care either way, smells like a freshly painted bikeshed
to me ;)

> Second, whenever we fail any CAN-2004-.t we must direct the
> user to some patch where they can remedy the situation.  I'm sort
> of laughing that I spent 4 hours yesterday researching two vulns
> that many other engineers had spent 4 hours researching.  The
> laughable thing - show me on www.php.net where they call out any
> patches for 4.3.x to these two incidents?

They don't, it was fixed silently, I mailed them about that but they
didn't seem inclined to do anything about it.  If you want to follow up
on that some more, great, but ranting about it here won't make much 
difference.

joe

Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php

[William A. Rowe, Jr.]

At 12:25 PM 11/23/2004, Cliff Woolley wrote:
>On Tue, 23 Nov 2004, Joe Orton wrote:
>
>> Discussion of whether or not it's useful to have PHP tests in httpd-test
>> can take place on test-dev@, please send your comments there and I'll
>> follow up.
>
>I actually think it's useful to have php tests in our suite, because
>having a large number of tests for a module as big as php helps to flush
>out bugs in httpd (and maybe apr).  That would be even more the case if
>php's sapi module for httpd 2.x that worked as a filter were in a
>reasonable state...

I totally agree that regression testing is terrific.  We gain alot
knowing when our patches might break php.

What I questioned was why we were doing the security validation 
of PHP when it's outside the scope of httpd, or isn't due to some
interaction with httpd.

I also questioned shoving scary security/CAN-2004-.t failures
at our users.  FIRST this should never have been in security/ -
it should have been a php/ test.  Again, this is not our security
incident within httpd.

Second, whenever we fail any CAN-2004-.t we must direct the
user to some patch where they can remedy the situation.  I'm sort
of laughing that I spent 4 hours yesterday researching two vulns
that many other engineers had spent 4 hours researching.  The
laughable thing - show me on www.php.net where they call out any
patches for 4.3.x to these two incidents?

It's akin to screaming FIRE in a crowded theater, when the doors
are locked.  Open up the doors first, then scream.

Oh, just an aside, answering "upgrade n-1.x to the latest n.0
release" is no answer to a security incident.  Didn't we just
listen to a preso in Vegas decrying how 5.0 isn't 4.3?

Bill

Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php

[Geoffrey Young]

Cliff Woolley wrote:
> On Tue, 23 Nov 2004, Joe Orton wrote:
> 
> 
>>Discussion of whether or not it's useful to have PHP tests in httpd-test
>>can take place on test-dev@, please send your comments there and I'll
>>follow up.
> 
> 
> I actually think it's useful to have php tests in our suite, because
> having a large number of tests for a module as big as php helps to flush
> out bugs in httpd (and maybe apr).  That would be even more the case if
> php's sapi module for httpd 2.x that worked as a filter were in a
> reasonable state...

now that TestRunPHP and TestConfigPHP are complete, I was considering moving
 the existing php tests over to this new framework.  the advantage is that
each individual test would get an ok marker at a granular level, rather than
a simple ok that represented, say, 5 tests together in a lump.

how does this sound to everyone?  I'd probably get to it sometime over the
next two weeks, and I'd post a major diff before going forward.

--Geoff

Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php

[Cliff Woolley]

On Tue, 23 Nov 2004, Joe Orton wrote:

> Discussion of whether or not it's useful to have PHP tests in httpd-test
> can take place on test-dev@, please send your comments there and I'll
> follow up.

I actually think it's useful to have php tests in our suite, because
having a large number of tests for a module as big as php helps to flush
out bugs in httpd (and maybe apr).  That would be even more the case if
php's sapi module for httpd 2.x that worked as a filter were in a
reasonable state...

--Cliff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm

[Stas Bekman]

Geoffrey Young wrote:
  return $preamble . <<'EOF' . $cover;
 -TEST_VERBOSE ?= 0
 +TEST_VERBOSE = 0

why not if (WIN32) {} then?

do win32 environments add some magic WIN32 environment variable I can check
in the Makefile?  if they do and we can work around them that's cool with me.
My suggestion was a simpler one: condition that in Perl and generate the 
right Makefile.

--
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm

[Geoffrey Young]

>>a little digging on my own at the time made it seem like solaris make is
>>really gmake
> 
> 
> Well, the way you have it installed perhaps.  But attempting this
> against /usr/ccs/bin/make it most definately blows up.

ok.  I actually don't have a solaris box to try on - I just went to sun's
support site and saw that the manpage for make was gmake (at least the one
that google first pointed me toward :)

> 
> 
>>, so between linux, solaris, and bsd a decent case was being
>>made that most unix make variants to support the syntax.  of course, 
>>that list of 3 was hardly exhaustive :)
> 
> 
> Hardly.  The man page for hpux 11 make makes no mention of ?=
> nor does AIX 5.1.  you are 2 for 5.

yeah, not good.

> 
> Explicitly fails on native make(s) on AIX 5.1, HPUX 11, Solaris 2.6.
> Please find another solution.

well, the solution at the moment is to not have a solution - cvs has been
reverted, so unless a real solution can be found it will remain a minor nit.

> p.s. simple test I used...
>
> TERM ?= uberterm
> all:
> echo $(TERM)

the gmake manual suggests that ?= is equivalent to

ifeq ($(origin TEST_VERBOSE), undefined)
  TEST_VERBOSE = 0
endif

so that might make for a good test - the gmake manual didn't speficially say
that origin was explicit to it, but then again it didn't mention ?= either :)

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm

[Garrett Rooney]

Geoffrey Young wrote:
a little digging on my own at the time made it seem like solaris make is
really gmake, so between linux, solaris, and bsd a decent case was being
made that most unix make variants to support the syntax.  of course, that
list of 3 was hardly exhaustive :)
Umm, on all the solaris systems I've used make is in fact not gmake, 
there are a number of solaris specific differences.  This is at least 
true on solaris 2.6 through solaris 8.  I'm not sure about 9 or 10.

-garrett

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm

[William A. Rowe, Jr.]

At 11:23 AM 11/4/2004, Geoffrey Young wrote:

>> 
>> If I had to guess, this borks anything but gmake.  Test for that.
>
>I had asked on #asf about this and somebody (I forget who) said that the
>make manpage on minortaur (some bsd variant) supports ?= as well.  from
>looking at that it seems to be the manpage for pmake, which I guess is some
>other make variant. so limiting it to gmake at least would seem to wipe out
>bsd folks.

Ok, looks good for pmake, yes... however...

>a little digging on my own at the time made it seem like solaris make is
>really gmake

Well, the way you have it installed perhaps.  But attempting this
against /usr/ccs/bin/make it most definately blows up.

>, so between linux, solaris, and bsd a decent case was being
>made that most unix make variants to support the syntax.  of course, 
>that list of 3 was hardly exhaustive :)

Hardly.  The man page for hpux 11 make makes no mention of ?=
nor does AIX 5.1.  you are 2 for 5.

Explicitly fails on native make(s) on AIX 5.1, HPUX 11, Solaris 2.6.
Please find another solution.

Bill

p.s. simple test I used...

TERM ?= uberterm
all:
echo $(TERM)
  

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm

[Geoffrey Young]

> 
> If I had to guess, this borks anything but gmake.  Test for that.

I had asked on #asf about this and somebody (I forget who) said that the
make manpage on minortaur (some bsd variant) supports ?= as well.  from
looking at that it seems to be the manpage for pmake, which I guess is some
other make variant. so limiting it to gmake at least would seem to wipe out
bsd folks.

a little digging on my own at the time made it seem like solaris make is
really gmake, so between linux, solaris, and bsd a decent case was being
made that most unix make variants to support the syntax.  of course, that
list of 3 was hardly exhaustive :)

anyway, this just isn't my area, so I'm happy to defer to others that grok
all this SA-type stuff.  but if most unix-variants support ?=, or if there
is another more universal way to work around the issue, I would hate to see
the correct behavior only for unix people using gmake.

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm

[William A. Rowe, Jr.]

At 10:35 AM 11/4/2004, Geoffrey Young wrote:

>>>   -TEST_VERBOSE ?= 0
>>>   +TEST_VERBOSE = 0
>> 
>> why not if (WIN32) {} then?
>
>do win32 environments add some magic WIN32 environment variable I can check
>in the Makefile?  if they do and we can work around them that's cool with me.

If I had to guess, this borks anything but gmake.  Test for that.

Bill

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm

[Geoffrey Young]

Stas Bekman wrote:
> [EMAIL PROTECTED] wrote:
> 
>> geoff   2004/11/03 12:37:22
>>
>>   Modified:perl-framework/Apache-Test/lib/Apache TestMM.pm
>>   Log:
>>   reverting to 1.41 - apparently the conditional assignment borks win32
> 
> 
>>return $preamble . <<'EOF' . $cover;
>>   -TEST_VERBOSE ?= 0
>>   +TEST_VERBOSE = 0
> 
> 
> why not if (WIN32) {} then?

do win32 environments add some magic WIN32 environment variable I can check
in the Makefile?  if they do and we can work around them that's cool with me.

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm

[Stas Bekman]

[EMAIL PROTECTED] wrote:
geoff   2004/11/03 12:37:22
  Modified:perl-framework/Apache-Test/lib/Apache TestMM.pm
  Log:
  reverting to 1.41 - apparently the conditional assignment borks win32

   return $preamble . <<'EOF' . $cover;
  -TEST_VERBOSE ?= 0
  +TEST_VERBOSE = 0
why not if (WIN32) {} then?
--
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm

[Philippe M. Chiasson]

Seems it's not Win32 friendly, see this complaint:
http://marc.theaimsgroup.com/?t=10994804082&r=1&w=2
[EMAIL PROTECTED] wrote:
geoff   2004/10/25 18:42:14
  Modified:perl-framework/Apache-Test/lib/Apache TestMM.pm
  Log:
  make sure TEST_VERBOSE respects the environment, not just the current
  shell command.
  
  somebody shout if ?= isn't portable, but a few accounts indicate that it is
  
  Revision  ChangesPath
  1.42  +1 -1      httpd-test/perl-framework/Apache-Test/lib/Apache/TestMM.pm
  

--

Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5


signature.asc
Description: OpenPGP digital signature

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm

[Stas Bekman]

Geoffrey Young wrote:
[EMAIL PROTECTED] wrote:
geoff   2004/10/28 07:33:56
 Modified:perl-framework/Apache-Test Changes
  perl-framework/Apache-Test/lib/Apache TestConfig.pm
 Log:
 revert last change to keep things compiling

sorry stas if you would have gotten to this quickly, but I thought it was a
good idea to keep things in cvs compiling and gozer said you would be
offline for a few days due to a crazy landlord or something :)
That's exactly right. you did the right thing. I'm still relying on a 
anonymous friendly neighbour somewhere on the same block to get my oxygen. 
One day we will be able to get online in a matter of seconds...

--
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm

[Stas Bekman]

Geoffrey Young wrote:
@
  if (my $custom_config_path = custom_config_path()) {
  debug "loading custom config data from: '$custom_config_path'";
  $custom_config_loaded++;
 +($candidate) = $candidate=~/^(.*)/; # launder for -T
  require $custom_config_path;

huh?
something is definitely wrong here - there is no $candidate in the scope of
the current function, so this actually fails with errors.
$ perl Makefile.PL -apxs /apache/2.0/prefork/perl-5.8.5/bin/apxs
Global symbol "$candidate" requires explicit package name at
lib/Apache/TestConfig.pm line 2080.
sorry, rushed to commit while i had the connection on :( should be ok now
--
__
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: cvs commit: httpd-test/perl-framework/t/security CAN-2004-0940.t

[Cliff Woolley]

On Thu, 28 Oct 2004, Geoffrey Young wrote:

> I get the following failures on 1.3.32 but not on 1.3.33.
>
> t/modules/rewrite.t  222   9.09%  18 20
> t/security/CAN-2004-0940.t11 100.00%  1
> t/security/CAN-2004-0958.t92  22.22%  1 3
>
> I think these are all recent additions from you.  should each of these
> failures be skipped unless something like
>
>   ( have_apache(1) && have_min_apache_version(1.3.33) ) ||
>   ( have_apache(2) && have_min_apache_version(2.0.XX) )

I don't think so -- it's detecting an actual legitimate failure.  It's not
that the test requires a new version to work right, it's that that
particular version was broken.  No sense obfuscating that fact.

--Cliff

Re: cvs commit: httpd-test/perl-framework/t/security CAN-2004-0940.t

[Geoffrey Young]

> Did you change PHP version too? That's a PHP test, the result shouldn't
> change unless you change PHP version too with 1.3.33?

ah, I had php installed for 1.3.32 but not 1.3.33 :)

btw, the php stuff we've been doing is coming along quite well.  you might
be interested in the tarball chris and I are working on for apachecon

  http://www.modperlcookbook.org/~geoff/slides/nyphp/perl-php-test.tar.gz

note you'll need to have current A-T cvs installed, as I didn't take any
protection against missing versions, etc.

> Welll... we started having this debate a while back :)

indeed :)

> 
> Here's my take: I think it's correct to:
> 
> 1) only test for new features in versions on which they are known to be 
> present

I think we agreed on that (eventually :)

> 
> 2) test for bugs in all versions unconditionally in all affected
> versions
> 
> I think it's the desired outcome that if you test 1.3.32 for
> CAN-2004-0940, it should fail: 1.3.32 is after all vulnerable to
> CAN-2004-0940.  Why hide that by skipping the test?  Likewise, if you're
> running 1.3.32 you *should* be told that there is a nasty mod_rewrite
> regression in that version.
> 
> Maybe I'm hawking my corporate agenda here a little too, because it
> makes httpd-test slightly more useful to me since I can test for 1.3.x +
> backported patch, whereas if the test was skipped for <1.3.33 it won't
> demonstrate that the code is patched.
> 
> Does that make sense?

sure.

what it really feels like is that we (as a community) need a new function of
sorts.  that is, skip just glosses over a failure, and todo is only forward
looking (throwing unexpectedly succeeded warnings) - we need some kind of
'known issue' marker that understands an issue can never be fixed (unlike
todo which assumes that it can be fixed in the future).

but I guess that's another topic altogether :)

so I guess I'm inclined to agree with your logic then - it's better to have
regressions fail loudly and pique some interest than to just gloss over
them, especially for security-type things.

thanks for being patient with me while I caught up, then :)

--Geoff

Re: cvs commit: httpd-test/perl-framework/t/security CAN-2004-0940.t

[Joe Orton]

On Thu, Oct 28, 2004 at 03:19:32PM -0400, Geoffrey Young wrote:
> 
> 
> [EMAIL PROTECTED] wrote:
> > jorton  2004/10/25 06:04:14
> > 
> >   Modified:perl-framework/t/conf extra.conf.in
> >   Added:   perl-framework/t/htdocs/security CAN-2004-0940.shtml
> >perl-framework/t/security CAN-2004-0940.t
> >   Log:
> >   Regression test for CAN-2004-0940, 1.3 mod_include overflow.
> 
> hi joe :)
> 
> I get the following failures on 1.3.32 but not on 1.3.33.
> 
> t/modules/rewrite.t  222   9.09%  18 20
> t/security/CAN-2004-0940.t11 100.00%  1

Those bugs are present in 1.3.32, so that's expected.

> t/security/CAN-2004-0958.t92  22.22%  1 3

Did you change PHP version too? That's a PHP test, the result shouldn't
change unless you change PHP version too with 1.3.33?
 
> I think these are all recent additions from you.  should each of these
> failures be skipped unless something like
> 
>   ( have_apache(1) && have_min_apache_version(1.3.33) ) ||
>   ( have_apache(2) && have_min_apache_version(2.0.XX) )

Welll... we started having this debate a while back :)

Here's my take: I think it's correct to:

1) only test for new features in versions on which they are known to be 
present

2) test for bugs in all versions unconditionally in all affected
versions

I think it's the desired outcome that if you test 1.3.32 for
CAN-2004-0940, it should fail: 1.3.32 is after all vulnerable to
CAN-2004-0940.  Why hide that by skipping the test?  Likewise, if you're
running 1.3.32 you *should* be told that there is a nasty mod_rewrite
regression in that version.

Maybe I'm hawking my corporate agenda here a little too, because it
makes httpd-test slightly more useful to me since I can test for 1.3.x +
backported patch, whereas if the test was skipped for <1.3.33 it won't
demonstrate that the code is patched.

Does that make sense?

joe

Re: cvs commit: httpd-test/perl-framework/t/security CAN-2004-0940.t

[Geoffrey Young]

[EMAIL PROTECTED] wrote:
> jorton  2004/10/25 06:04:14
> 
>   Modified:perl-framework/t/conf extra.conf.in
>   Added:   perl-framework/t/htdocs/security CAN-2004-0940.shtml
>perl-framework/t/security CAN-2004-0940.t
>   Log:
>   Regression test for CAN-2004-0940, 1.3 mod_include overflow.

hi joe :)

I get the following failures on 1.3.32 but not on 1.3.33.

t/modules/rewrite.t  222   9.09%  18 20
t/security/CAN-2004-0940.t11 100.00%  1
t/security/CAN-2004-0958.t92  22.22%  1 3

I think these are all recent additions from you.  should each of these
failures be skipped unless something like

  ( have_apache(1) && have_min_apache_version(1.3.33) ) ||
  ( have_apache(2) && have_min_apache_version(2.0.XX) )

?

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm

[Geoffrey Young]

[EMAIL PROTECTED] wrote:
> geoff   2004/10/28 07:33:56
> 
>   Modified:perl-framework/Apache-Test Changes
>perl-framework/Apache-Test/lib/Apache TestConfig.pm
>   Log:
>   revert last change to keep things compiling

sorry stas if you would have gotten to this quickly, but I thought it was a
good idea to keep things in cvs compiling and gozer said you would be
offline for a few days due to a crazy landlord or something :)

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm

[Geoffrey Young]

@
>if (my $custom_config_path = custom_config_path()) {
>debug "loading custom config data from: '$custom_config_path'";
>$custom_config_loaded++;
>   +($candidate) = $candidate=~/^(.*)/; # launder for -T
>require $custom_config_path;

huh?

something is definitely wrong here - there is no $candidate in the scope of
the current function, so this actually fails with errors.

$ perl Makefile.PL -apxs /apache/2.0/prefork/perl-5.8.5/bin/apxs
Global symbol "$candidate" requires explicit package name at
lib/Apache/TestConfig.pm line 2080.

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm

[David Wheeler]

On Oct 26, 2004, at 10:00 AM, Geoffrey Young wrote:
that's not so bad, but it will affect users somewhat - I know that I 
have
used it in at least one of my tests...
Bleh. Bad Geoff!
maybe keeping $RedirectOK but moving the perl-framework (and mod_perl) 
over
to the new API would be a nice compromise (along with a deprecated 
warning
in Changes).
I decided not to do it this way. I realized that I could just use a 
lexical for when the module sets up the redirection and let users 
continue to use the (undocumented) package variable. This is handy for 
folks who want to use C, which is a cute hack.

I'm still tempted to replace it with a class method, just to enforce 
good practice. If I do so, I'll probably tie $RedirectOK so that it 
will indirectly use the class method, and thus remain backward 
compatible (and can issue a warning for a while, too). Thoughts?

But not today.
Regards,
David

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm

[Joe Orton]

On Mon, Oct 25, 2004 at 06:47:12PM -0700, David Wheeler wrote:
> No, just hacking. Let's see...oh, I get it. I changed it so that it 
> ignored $RedirectOK if LWP was installed.

Thanks David.  No comments here on what's right, only what works ;)

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm

[Geoffrey Young]

> You know, I'm inclined to remove that stupid $RedirectOK global
> variable, because you can't tell whether it was set by the user of
> Apache::TestRequest. This makes it difficult to decide whether or not to
> let LWP handle the call to redirect_ok(). What say you all to my
> changing this to a class method, say RedirectOK()? Then it can be
> smarter about who is doing what to whom. 

that sounds fine.  well, fine enough for us to chew on some posted code
anyway :)

> It would require I change the
> tests that rely on it, but they don't appear to be too many:
> 
> % grep -r RedirectOK t
> t/modules/alias.t:local $Apache::TestRequest::RedirectOK = 0;
> t/modules/alias.t:local $Apache::TestRequest::RedirectOK = 0;
> t/ssl/proxy.t:local $Apache::TestRequest::RedirectOK = 0;

that's not so bad, but it will affect users somewhat - I know that I have
used it in at least one of my tests...

maybe keeping $RedirectOK but moving the perl-framework (and mod_perl) over
to the new API would be a nice compromise (along with a deprecated warning
in Changes).

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm

[David Wheeler]

On Oct 25, 2004, at 4:33 PM, Geoffrey Young wrote:
let's give david a chance to investigate - either to fix or, if a 
quick fix
isn't obvious, revert the behavior.

if david doesn't respond by, say, wednesday, we (you or I) should feel 
free
to just revert the change.  maybe david is on vacation or something, 
or just
temporarily behind in his emails.
No, just hacking. Let's see...oh, I get it. I changed it so that it 
ignored $RedirectOK if LWP was installed. That's not necessarily a good 
idea, given the goofy way in which this module is written. I've applied 
a fix to only let LWP handle the call to redirect_ok() if a an array 
reference was passed to user_agent( requests_redirectable => []). Ugh, 
that is so ugly!

But this doesn't seem to help t/ssl/basicauth.t. But even if I roll 
back the changes that test still fails, so I'm inclined to think that 
it's failing for some other reason.

You know, I'm inclined to remove that stupid $RedirectOK global 
variable, because you can't tell whether it was set by the user of 
Apache::TestRequest. This makes it difficult to decide whether or not 
to let LWP handle the call to redirect_ok(). What say you all to my 
changing this to a class method, say RedirectOK()? Then it can be 
smarter about who is doing what to whom. It would require I change the 
tests that rely on it, but they don't appear to be too many:

% grep -r RedirectOK t
t/modules/alias.t:local $Apache::TestRequest::RedirectOK = 0;
t/modules/alias.t:local $Apache::TestRequest::RedirectOK = 0;
t/ssl/proxy.t:local $Apache::TestRequest::RedirectOK = 0;
Thoughts?
Regards,
David

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm

[Geoffrey Young]

Joe Orton wrote:
> On Sun, Oct 24, 2004 at 11:37:11AM +0100, Joe Orton wrote:
> 
>>On Fri, Oct 22, 2004 at 10:09:54PM -, [EMAIL PROTECTED] wrote:
>>
>>>theory  2004/10/22 15:09:54
>>>
>>>  Modified:perl-framework/Apache-Test Changes
>>>   perl-framework/Apache-Test/lib/Apache TestRequest.pm
>>>  Log:
>>>  Redirect from POST fixes (or prevention, depending on how you lok at it).
>>
>>It looks like this change broke the t/modules/alias.t test in
>>httpd-test? Also mod_perl's t/apache/scanhdrs2.t started failing and I
>>can't see anything else that changed, sorry, no time to look any further
>>into it at the mo...
> 
> 
> Any chance this could be fixed or reverted?  It's hindering regression
> testing... unexpected failures in httpd-test are currently:
> 
> t/modules/alias.t 62   15  24.19%  14-18 49-58
> t/ssl/proxy.t1723   1.74%  8 62 121
>

let's give david a chance to investigate - either to fix or, if a quick fix
isn't obvious, revert the behavior.

if david doesn't respond by, say, wednesday, we (you or I) should feel free
to just revert the change.  maybe david is on vacation or something, or just
temporarily behind in his emails.

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm

[Joe Orton]

On Sun, Oct 24, 2004 at 11:37:11AM +0100, Joe Orton wrote:
> On Fri, Oct 22, 2004 at 10:09:54PM -, [EMAIL PROTECTED] wrote:
> > theory  2004/10/22 15:09:54
> > 
> >   Modified:perl-framework/Apache-Test Changes
> >perl-framework/Apache-Test/lib/Apache TestRequest.pm
> >   Log:
> >   Redirect from POST fixes (or prevention, depending on how you lok at it).
> 
> It looks like this change broke the t/modules/alias.t test in
> httpd-test? Also mod_perl's t/apache/scanhdrs2.t started failing and I
> can't see anything else that changed, sorry, no time to look any further
> into it at the mo...

Any chance this could be fixed or reverted?  It's hindering regression
testing... unexpected failures in httpd-test are currently:

t/modules/alias.t 62   15  24.19%  14-18 49-58
t/ssl/proxy.t1723   1.74%  8 62 121

joe

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm

[Joe Orton]

On Fri, Oct 22, 2004 at 10:09:54PM -, [EMAIL PROTECTED] wrote:
> theory  2004/10/22 15:09:54
> 
>   Modified:perl-framework/Apache-Test Changes
>perl-framework/Apache-Test/lib/Apache TestRequest.pm
>   Log:
>   Redirect from POST fixes (or prevention, depending on how you lok at it).

It looks like this change broke the t/modules/alias.t test in
httpd-test? Also mod_perl's t/apache/scanhdrs2.t started failing and I
can't see anything else that changed, sorry, no time to look any further
into it at the mo...

joe

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache Test.pm

[Stas Bekman]

Joe Orton wrote:
On Wed, Oct 20, 2004 at 11:37:45PM -0400, Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
jorton  2004/10/20 06:42:07
Modified:perl-framework/Apache-Test/lib/Apache Test.pm
Log:
Add the need_php4 export.
It's of little value if it's not documented, especially when the rest is. 
Joe, please see the pod at the end of that file (search for need_php).

I documented it in the commit before :)
Opps, my apologies, I've missed it. 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache Test.pm

[Joe Orton]

On Wed, Oct 20, 2004 at 11:37:45PM -0400, Stas Bekman wrote:
> [EMAIL PROTECTED] wrote:
> >jorton  2004/10/20 06:42:07
> >
> >  Modified:perl-framework/Apache-Test/lib/Apache Test.pm
> >  Log:
> >  Add the need_php4 export.
> 
> It's of little value if it's not documented, especially when the rest is. 
> Joe, please see the pod at the end of that file (search for need_php).

I documented it in the commit before :)

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache Test.pm

[Stas Bekman]

[EMAIL PROTECTED] wrote:
jorton  2004/10/20 06:42:07
  Modified:perl-framework/Apache-Test/lib/Apache Test.pm
  Log:
  Add the need_php4 export.
It's of little value if it's not documented, especially when the rest is. 
Joe, please see the pod at the end of that file (search for need_php).

  Revision  ChangesPath
  1.106 +1 -1  httpd-test/perl-framework/Apache-Test/lib/Apache/Test.pm
  
  Index: Test.pm
  ===
  RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/Test.pm,v
  retrieving revision 1.105
  retrieving revision 1.106
  diff -d -w -u -r1.105 -r1.106
  --- Test.pm	20 Oct 2004 13:38:15 -	1.105
  +++ Test.pm	20 Oct 2004 13:42:07 -	1.106
  @@ -27,7 +27,7 @@
 need_module need_apache need_min_apache_version
 need_apache_version need_perl need_min_perl_version
 need_min_module_version need_threads need_apache_mpm
  -  need_php need_ssl);
  +  need_php need_php4 need_ssl);
   
   my @have = map { (my $need = $_) =~ s/need/have/; $need } @need;
   
  
  
  

--
__
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: cvs commit: httpd-test/perl-framework/Apache-Test Changes

[Geoffrey Young]

David Wheeler wrote:
> On Oct 18, 2004, at 5:06 PM, [EMAIL PROTECTED] wrote:
> 
>>   add new test_config make target, equivalent to t/TEST -conf,
>>   and make it a prerequisite for the cmodules make target.  now
>>   you can 'make cmodules' to build the things in c-modules/
>>   without running t/TEST -conf first.
> 
> 
> Uh, what? Can you tell me what this does, Geoff, so I can figure out
> whether it needs to be implemented for TestMB, too?

sure :)

there was already a cmodules target (as well as a cmodules_clean target).
they used to look like this:

cmodules:
cd c-modules && $(MAKE) all


cmodules_clean:
cd c-modules && $(MAKE) clean

if you didn't already know, you can place apache C modules in
c-modules/name/mod_name.c and A-T will automatically compile them via apxs
and add a LoadModule to httpd.conf for you.  for a few examples, see
perl-framework/c-modules/.

anyway, those two targets did not work as specified, since the Makefiles
under c-modules/ do not exist until you run t/TEST -conf (which is done
automatically when you run t/TEST) - simply running 'make cmodules' would bomb.

so, I added a test_config target as a prerequisite to the cmodules and
cmodules_clean targets so that you can now 'make cmodules' and it actually
works.

does that help?

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test Changes

[David Wheeler]

On Oct 18, 2004, at 5:06 PM, [EMAIL PROTECTED] wrote:
  add new test_config make target, equivalent to t/TEST -conf,
  and make it a prerequisite for the cmodules make target.  now
  you can 'make cmodules' to build the things in c-modules/
  without running t/TEST -conf first.
Uh, what? Can you tell me what this does, Geoff, so I can figure out 
whether it needs to be implemented for TestMB, too?

Thanks,
David

Re: cvs commit: httpd-test/perl-framework/Apache-Test/t/more

[Geoffrey Young]

[EMAIL PROTECTED] wrote:
> geoff   2004/10/14 21:11:39
> 
>   Modified:perl-framework/Apache-Test Changes
>perl-framework/Apache-Test/lib/Apache Test.pm
>perl-framework/Apache-Test/t/conf extra.conf.in
>   Added:   perl-framework/Apache-Test/t/more 01testpm.t 02testmore.t
> 03testpm.t 04testmore.t all.t
>   Log:
>   add -withtestmore import action, which allows Test::More >= 0.49
>   to replace Test.pm as the engine for server-side tests

Test::Simple 0.49 was just announced this evening, so I committed the work
that I've had sitting around just waiting for the announcement.

I know that the tests probably need some work, but the underlying
Apache/Test.pm functionality is pretty solid - we've been using it
internally for the past few months now and haven't seen any issues.

--Geoff

Re: cvs commit: httpd-test/perl-framework/t/conf extra.conf.in

[André Malo]

* Geoffrey Young <[EMAIL PROTECTED]> wrote:

> joe++
> :)

!

;-)

nd
-- 
"Solides und umfangreiches Buch"
  -- aus einer Rezension

Re: cvs commit: httpd-test/perl-framework/t/conf extra.conf.in

[Geoffrey Young]

[EMAIL PROTECTED] wrote:
> jorton  2004/10/12 06:53:41
> 
>   Modified:perl-framework/t/modules rewrite.t
>perl-framework/t/conf extra.conf.in
>   Log:
>   Add test for RewriteRule [P] flag which is broken in HEAD
>   due to mod_proxy changes.

joe++

:)

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMB.pm

[Geoffrey Young]

[EMAIL PROTECTED] wrote:
> theory  2004/10/05 12:45:08
> 
>   Modified:perl-framework/Apache-Test/lib/Apache TestMB.pm
>   Log:
>   Added testcover action.

entry in Changes?

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMB.pm

[Philippe M. Chiasson]

[EMAIL PROTECTED] wrote:
theory  2004/10/05 12:45:08
  Modified:perl-framework/Apache-Test/lib/Apache TestMB.pm
  Log:
  Added testcover action.
  
  Revision  ChangesPath
  1.8   +28 -1 httpd-test/perl-framework/Apache-Test/lib/Apache/TestMB.pm
  
  Index: TestMB.pm
  ===
  RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestMB.pm,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- TestMB.pm	5 Sep 2004 00:11:30 -	1.7
  +++ TestMB.pm	5 Oct 2004 19:45:08 -	1.8
  @@ -60,6 +60,27 @@
'-bugreport', '-verbose=' . ($self->verbose || 0));
   }
   
  +sub ACTION_testcover {
  +my $self = shift;
  +
  +unless ($self->find_module_by_name('Devel::Cover', [EMAIL PROTECTED])) {
  +warn("Cannot run testcover action unless Devel::Cover "
  + . "is installed.\n");
  +return;
  +}
  +
  +$self->add_to_cleanup('coverage', 'cover_db');
  +
  +my $atdir = $self->localize_file_path("$ENV{HOME}/.apache-test");
  +local $Test::Harness::switches=
  +local $Test::Harness::Switches=
  +local $ENV{HARNESS_PERL_SWITCHES} = "-MDevel::Cover=+inc,'$atdir'";
  +local $ENV{APACHE_TEST_EXTRA_ARGS} = "-one-process";
  +
  +$self->depends_on('test');
  +$self->do_system('cover');
  +}
  +
   sub _bliblib {
   my $self = shift;
   return (
  @@ -69,7 +90,7 @@
   }
   
   sub ACTION_test {
  -my $self = shift;
  +my $self = shift
Feels like a typo to me ^^^
   $self->depends_on('code');
   $self->depends_on('run_tests');
   $self->depends_on('test_clean');
  @@ -233,6 +254,12 @@
   This action actually the tests by executing the test script,
   F. It is executed by the C action, so most of the time
   it won't be executed directly.
  +
  +=item testcover
  +
  +C overrides this action from C in order to
  +prevent the C preference files from being included in the test
  +coverage.
   
   =back
   
  
  
  

--

Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

Re: cvs commit: httpd-test/perl-framework/t/ssl basicauth.t http.t proxy.t

[Justin Erenkrantz]

--On Thursday, September 30, 2004 2:54 PM + [EMAIL PROTECTED] wrote:
geoff   2004/09/30 07:54:40
  Modified:perl-framework/t/apache acceptpathinfo.t chunkinput.t
errordoc.t getfile.t limits.t options.t
   perl-framework/t/filter input_body.t
   perl-framework/t/http11 chunked.t
   perl-framework/t/modules alias.t asis.t autoindex2.t cgi.t
negotiation.t vhost_alias.t
   perl-framework/t/php arg.t func5.t getenv.t getlastmod.t
ifmodsince.t umask.t var1.t var2.t var3.t
   perl-framework/t/protocol echo.t
   perl-framework/t/ssl basicauth.t http.t proxy.t
  Log:
  swap t_cmp() arguments where they appeared to not match the current
  function order.
/me adds Geoff to beer list at AC'04.  ;-)
Yay.  Thank you!  -- justin

Re: cvs commit: httpd-test/perl-framework/t/protocol nntp-like.t

[Geoffrey Young]

> so yeah, it sucks, continues to suck, and I'm sorry.

ok, I went through and changed all of the ones I saw that needed changing.
all tests are fine for me except the ones for modules I don't have installed
(namely ssl and php).  sorry if I broke any of those...

--Geoff

Re: cvs commit: httpd-test/perl-framework/t/protocol nntp-like.t

[Geoffrey Young]

Justin Erenkrantz wrote:
> --On Wednesday, September 29, 2004 10:26 AM +0100 Joe Orton
> <[EMAIL PROTECTED]> wrote:
> 
>> Yup, the t_cmp arguments were flipped a while back.
> 
> 
> FWIW, I think whomever flipped the t_cmp arguments but didn't flip the
> included test cases at the same time needs a stern talking to.  I spent
> over an hour and a half figuring out why the heck httpd was returning a
> 200 in that case where a 413 was clearly (or at least more) correct:
> only to find out that the debug output was swapped.  Incredibly,
> incredibly lame.

yeah, well, that was me.  it's difficult to find the time to do everything
that needs doing.  in this case, the order was swapped to be consistent with
 other (more popular) Perl testing libraries, but there just weren't enough
tuits lying around to make all the changes throughout the perl-framework.
the argument at the time was that this was OK(tm) because the only thing
affected was the debugging output, not the actual comparison.  I'll take the
blame for that brain fart too, but again a severe lack of free time got in
the way of doing things a bit better.

however, those of us that are reasonably active here were aware of this, uh,
issue and were changing test files as we touched them for other reasons.

so yeah, it sucks, continues to suck, and I'm sorry.  I'll buy you a beer or
two at apachecon to make up for it :)

--Geoff

Re: cvs commit: httpd-test/perl-framework/t/protocol nntp-like.t

[Justin Erenkrantz]

--On Wednesday, September 29, 2004 10:26 AM +0100 Joe Orton 
<[EMAIL PROTECTED]> wrote:

Yup, the t_cmp arguments were flipped a while back.
FWIW, I think whomever flipped the t_cmp arguments but didn't flip the 
included test cases at the same time needs a stern talking to.  I spent 
over an hour and a half figuring out why the heck httpd was returning a 200 
in that case where a 413 was clearly (or at least more) correct: only to 
find out that the debug output was swapped.  Incredibly, incredibly lame.

All I wanted to do last night was add some caching tests: instead I had to 
fix our tests to pass at all.  *sigh*  -- justin

Re: cvs commit: httpd-test/perl-framework/t/protocol nntp-like.t

[Justin Erenkrantz]

--On Wednesday, September 29, 2004 3:39 PM +0100 Joe Orton 
<[EMAIL PROTECTED]> wrote:

OK, the difference is in the handling of an empty Content-Length header.
The glibc strtoll does not return an error for an empty string, as C99
requires, and so ap_http_filter treats it exactly as "Content-Length:
0".
I guess the strto* on your platform does return an error for this case:
I'd say a 400 is a better error than a 413 for "Content-Length:\r\n" but
413 is clearly better than 200, so I've fixed ap_http_filter in HEAD.
FWIW, I had failures with Darwin and FreeBSD (might have ran it on Solaris 
too, but can't recall).  Yah, expecting 200 was just plainly wrong in this 
case.  I do think 413 is a bit arbitrary, but is clearly more correct than 
200.  -- justin

Re: cvs commit: httpd-test/perl-framework/c-modules/test_pass_brigade mod_test_pass_brigade.c

[Joe Orton]

On Wed, Sep 29, 2004 at 01:19:24PM -0400, Cliff Woolley wrote:
> On Wed, 29 Sep 2004 [EMAIL PROTECTED] wrote:
> 
> > jorton  2004/09/29 08:03:59
> >
> >   Modified:perl-framework/c-modules/test_pass_brigade
> > mod_test_pass_brigade.c
> >   Log:
> >   Prevent death by memory consumption in an --enable-pool-debug/-lefence
> >   build: allocate and {ab,re}use a single brigade structure rather than
> >   allocating one out of r->pool for each block sent (see also "why are
> >   brigades allocated out of pools this is insane" threads).
> 
> Um, I actually never saw any such threads.  Where were they?

OK, I paraphrased somewhat, but:

recent: http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=108732600304014&w=2
historic: http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=104039770718467&w=2

> Anyway, there actually was a brief period of time about two years ago when
> they were not allocated out of pools.  I was under the mistaken impression
> that that was still the case, but apparently brianp reverted his own
> commit about a week afterward for some reason I can no longer recall
> (presumably it broke something and it was easier at the time to revert
> than fix because a new release of httpd was pending).

The fact is that now, we can't fix it in 2.0 because there are output
filters which presume they can apr_brigade_destroy() the brigade passed
in, and there are other filters which presume they can reuse a brigade
which they passed down.

Many of the filters in httpd will allocate new brigades when you pass a
FLUSH bucket up (e.g. PR23567, a slow-running CGI), which leads to
memory usage proportional to number of FLUSH buckets sent etc etc...

joe

Re: cvs commit: httpd-test/perl-framework/c-modules/test_pass_brigade mod_test_pass_brigade.c

[Cliff Woolley]

On Wed, 29 Sep 2004 [EMAIL PROTECTED] wrote:

> jorton  2004/09/29 08:03:59
>
>   Modified:perl-framework/c-modules/test_pass_brigade
> mod_test_pass_brigade.c
>   Log:
>   Prevent death by memory consumption in an --enable-pool-debug/-lefence
>   build: allocate and {ab,re}use a single brigade structure rather than
>   allocating one out of r->pool for each block sent (see also "why are
>   brigades allocated out of pools this is insane" threads).

Um, I actually never saw any such threads.  Where were they?

Anyway, there actually was a brief period of time about two years ago when
they were not allocated out of pools.  I was under the mistaken impression
that that was still the case, but apparently brianp reverted his own
commit about a week afterward for some reason I can no longer recall
(presumably it broke something and it was easier at the time to revert
than fix because a new release of httpd was pending).

Brian, do you remember what the deal was there?

--Cliff

Re: cvs commit: httpd-test/perl-framework/t/protocol nntp-like.t

[Joe Orton]

On Wed, Sep 29, 2004 at 10:26:05AM +0100, Joe Orton wrote:
> On Wed, Sep 29, 2004 at 06:53:42AM -, [EMAIL PROTECTED] wrote:
> > jerenkrantz2004/09/28 23:53:42
> > 
> >   Modified:perl-framework/c-modules/nntp_like mod_nntp_like.c
> >perl-framework/t/apache contentlength.t
> >perl-framework/t/protocol nntp-like.t
> >   Log:
> >   Fix up nntp-like and content-length tests to pass.
> 
> To pass against what httpd on what platform? They were passing on Linux
> against 2.0 and HEAD.  But now they're not :) Against HEAD I now get:

OK, the difference is in the handling of an empty Content-Length header. 
The glibc strtoll does not return an error for an empty string, as C99
requires, and so ap_http_filter treats it exactly as "Content-Length:
0".

I guess the strto* on your platform does return an error for this case:
I'd say a 400 is a better error than a 413 for "Content-Length:\r\n" but
413 is clearly better than 200, so I've fixed ap_http_filter in HEAD.

joe

Re: cvs commit: httpd-test/perl-framework/t/protocol nntp-like.t

[Joe Orton]

On Wed, Sep 29, 2004 at 06:53:42AM -, [EMAIL PROTECTED] wrote:
> jerenkrantz2004/09/28 23:53:42
> 
>   Modified:perl-framework/c-modules/nntp_like mod_nntp_like.c
>perl-framework/t/apache contentlength.t
>perl-framework/t/protocol nntp-like.t
>   Log:
>   Fix up nntp-like and content-length tests to pass.

To pass against what httpd on what platform? They were passing on Linux
against 2.0 and HEAD.  But now they're not :) Against HEAD I now get:

t/apache/contentlength..# Failed test 2 in t/apache/contentlength.t at line 
54
# Failed test 4 in t/apache/contentlength.t at line 54 fail #2
FAILED tests 2, 4
Failed 2/20 tests, 90.00% okay

Yup, the t_cmp arguments were flipped a while back.

Re: cvs commit: httpd-test/perl-framework/Apache-Test Makefile.PL Changes

[Stas Bekman]

Geoffrey Young wrote:
 +sub clean_files {
 +return [
 +qw(lib/Apache/TestConfigData.pm
 +   .mypacklist
 +   t/TEST
 +  ),
 +   ];
 +}

[EMAIL PROTECTED] mod_perl-2.0]$ perl Makefile.PL
MP_APXS=/usr/local/apache2/bin/apxs
Reading Makefile.PL args from @ARGV
   MP_APXS = /usr/local/apache2/bin/apxs
Configuring Apache/2.0.49 mod_perl/1.99_17-dev Perl/v5.8.3
Subroutine clean_files redefined at ./Makefile.PL line 56.
Thanks for the spot, Geoff, should be fixed now.
--
__
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: cvs commit: httpd-test/perl-framework/Apache-Test Makefile.PL Changes

[Geoffrey Young]

>   +sub clean_files {
>   +return [
>   +qw(lib/Apache/TestConfigData.pm
>   +   .mypacklist
>   +   t/TEST
>   +  ),
>   +   ];
>   +}

[EMAIL PROTECTED] mod_perl-2.0]$ perl Makefile.PL
MP_APXS=/usr/local/apache2/bin/apxs
Reading Makefile.PL args from @ARGV
   MP_APXS = /usr/local/apache2/bin/apxs
Configuring Apache/2.0.49 mod_perl/1.99_17-dev Perl/v5.8.3
Subroutine clean_files redefined at ./Makefile.PL line 56.


--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm

[Stas Bekman]

[EMAIL PROTECTED] wrote:
gozer   2004/09/16 14:36:13
  Modified:perl-framework/Apache-Test Changes
   perl-framework/Apache-Test/lib/Apache TestConfig.pm
  Log:
  Added an apxs query cache for improved test performance
It doesn't seem to make any difference for me. I'm not sure why it made 
such a significant difference on your machine. Perhaps your apxs util is 
for some reason is too slow.

% time perl -le 'qx[~/httpd/prefork/bin/apxs -q CFLAGS] for 1..30'
3.411u 1.786s 0:05.35 97.0% 0+0k 0+0io 0pf+0w
--
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm

[Geoffrey Young]

[EMAIL PROTECTED] wrote:
> geoff   2004/09/15 16:55:31
> 
>   Modified:perl-framework/Apache-Test Changes
>perl-framework/Apache-Test/lib/Apache TestMM.pm
>   Log:
>   run_tests make target no longer invokes t/TEST -clean, making it
>   possible to save a few development cycles when a full cleanup is
>   not required between runs.

TestMB.pm probably should be updated to be consistent as well.

David, I think the attached patch is right but I'll leave TestMB entirely up
to you.

--Geoff
? mb.patch
? quick.patch
Index: lib/Apache/TestMB.pm
=======
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestMB.pm,v
retrieving revision 1.7
diff -u -r1.7 TestMB.pm
--- lib/Apache/TestMB.pm	5 Sep 2004 00:11:30 -	1.7
+++ lib/Apache/TestMB.pm	15 Sep 2004 23:56:48 -
@@ -53,7 +53,6 @@
 
 sub ACTION_run_tests {
 my $self = shift;
-$self->depends_on('test_clean');
 # XXX I'd love to do this without t/TEST.
 $self->do_system($self->perl, $self->_bliblib,
  $self->localize_file_path($self->apache_test_script),
@@ -71,8 +70,8 @@
 sub ACTION_test {
 my $self = shift;
 $self->depends_on('code');
-$self->depends_on('run_tests');
 $self->depends_on('test_clean');
+$self->depends_on('run_tests');
 }
 
 sub _cmodules {

Re: cvs commit: httpd-test/perl-framework/Apache-Test Changes

[Stas Bekman]

Geoffrey Young wrote:
[EMAIL PROTECTED] wrote:
stas2004/08/26 17:51:55
 Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
  perl-framework/Apache-Test Changes
 Log:
 Make sure that when Apache-Test is a part of modperl-2.0 checkout, the
 interactive configuration is properly run (it must not be run when
 mod_perl 2.0 is tested since it should have all the info needed to run
 the tests).

  
 -use constant IS_MOD_PERL_2_BUILD => IS_MOD_PERL_2 &&
 -require Apache::Build && Apache::Build::IS_MOD_PERL_BUILD();
 -
  use constant IS_APACHE_TEST_BUILD =>
  grep { -e "$_/lib/Apache/TestConfig.pm" } qw(Apache-Test . ..);
  
 +use constant IS_MOD_PERL_2_BUILD =>
 +IS_MOD_PERL_2 && !IS_APACHE_TEST_BUILD &&
 +require Apache::Build && Apache::Build::IS_MOD_PERL_BUILD();
 +

this borked the mod_perl build.  IS_APACHE_TEST_BUILD now reports back true
for a mod_perl checkout, which makes IS_MOD_PERL_2_BUILD false.  the result
is that Apache2.pm is added to t/TEST but lib/ is not, so t/TEST can't run
on a fresh checkout (where there are no mod_perl files in site_lib).
I think the attached patch makes more sense, but I'm not sure if it collides
with the problem you were trying to solve.
--Geoff

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.243
diff -u -r1.243 TestConfig.pm
--- Apache-Test/lib/Apache/TestConfig.pm	27 Aug 2004 01:03:55 -	1.243
+++ Apache-Test/lib/Apache/TestConfig.pm	3 Sep 2004 14:23:24 -
@@ -31,7 +31,7 @@
 eval { require mod_perl && $mod_perl::VERSION >= 1.99 } || 0;
 
 use constant IS_APACHE_TEST_BUILD =>
-grep { -e "$_/lib/Apache/TestConfig.pm" } qw(Apache-Test . ..);
+grep { -e "$_/lib/Apache/TestConfig.pm" } qw(. ..);
 
 use constant IS_MOD_PERL_2_BUILD =>
 IS_MOD_PERL_2 && !IS_APACHE_TEST_BUILD &&
thanks Geoff for the heads up, I think I've found a more suitable solution 
for this. One shouldn't run 'perl Makefile.PL' from within Apache-Test/ 
when that is a checkout inside modperl-2.0. I have been bitten by that 
quite a few times, as there are many bad sideeffects when 
Apache-Test/t/conf is populated (it gets picked up by modperl tests then 
causing all kind breakages).

--
__
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: cvs commit: httpd-test/perl-framework/Apache-Test Changes

[Geoffrey Young]

[EMAIL PROTECTED] wrote:
> stas2004/08/26 17:51:55
> 
>   Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
>perl-framework/Apache-Test Changes
>   Log:
>   Make sure that when Apache-Test is a part of modperl-2.0 checkout, the
>   interactive configuration is properly run (it must not be run when
>   mod_perl 2.0 is tested since it should have all the info needed to run
>   the tests).

>
>   -use constant IS_MOD_PERL_2_BUILD => IS_MOD_PERL_2 &&
>   -require Apache::Build && Apache::Build::IS_MOD_PERL_BUILD();
>   -
>use constant IS_APACHE_TEST_BUILD =>
>grep { -e "$_/lib/Apache/TestConfig.pm" } qw(Apache-Test . ..);
>
>   +use constant IS_MOD_PERL_2_BUILD =>
>   +IS_MOD_PERL_2 && !IS_APACHE_TEST_BUILD &&
>   +require Apache::Build && Apache::Build::IS_MOD_PERL_BUILD();
>   +

this borked the mod_perl build.  IS_APACHE_TEST_BUILD now reports back true
for a mod_perl checkout, which makes IS_MOD_PERL_2_BUILD false.  the result
is that Apache2.pm is added to t/TEST but lib/ is not, so t/TEST can't run
on a fresh checkout (where there are no mod_perl files in site_lib).

I think the attached patch makes more sense, but I'm not sure if it collides
with the problem you were trying to solve.

--Geoff
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.243
diff -u -r1.243 TestConfig.pm
--- Apache-Test/lib/Apache/TestConfig.pm	27 Aug 2004 01:03:55 -	1.243
+++ Apache-Test/lib/Apache/TestConfig.pm	3 Sep 2004 14:23:24 -
@@ -31,7 +31,7 @@
 eval { require mod_perl && $mod_perl::VERSION >= 1.99 } || 0;
 
 use constant IS_APACHE_TEST_BUILD =>
-grep { -e "$_/lib/Apache/TestConfig.pm" } qw(Apache-Test . ..);
+grep { -e "$_/lib/Apache/TestConfig.pm" } qw(. ..);
 
 use constant IS_MOD_PERL_2_BUILD =>
 IS_MOD_PERL_2 && !IS_APACHE_TEST_BUILD &&

Re: cvs commit: httpd-test/perl-framework/t/htdocs/modules/cgi nph-foldhdr.pl.PL .cvsignore

[Joe Orton]

On Tue, Aug 17, 2004 at 01:15:57PM -0400, Geoffrey Young wrote:
> 
> >   +sok {
> >   +t_cmp(200, 
> >   +  GET('/modules/cgi/nph-foldhdr.pl')->code,
> >   +  "CGI script with folded headers");
> 
> I swapped the arguments passed to t_cmp() here and elsewhere in the file so
> that they match the new order (received results first).  as I don't have ssl
> installed at the moment, if you could run through it again to make sure I
> didn't break anything that would be great :)

Thanks, yes, it still works.  I'll try to remember to switch the 
arguments around whenever I touch other files too...

joe

Re: cvs commit: httpd-test/perl-framework/t/htdocs/modules/cgi nph-foldhdr.pl.PL .cvsignore

[Geoffrey Young]

>   +sok {
>   +t_cmp(200, 
>   +  GET('/modules/cgi/nph-foldhdr.pl')->code,
>   +  "CGI script with folded headers");

I swapped the arguments passed to t_cmp() here and elsewhere in the file so
that they match the new order (received results first).  as I don't have ssl
installed at the moment, if you could run through it again to make sure I
didn't break anything that would be great :)

since nobody really has the time to go through and change every file, I
guess it's just something that we can try to remember to do when we make a
modification.

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache Test.pm TestConfig.pm TestRun.pm

[Geoffrey Young]

Stas Bekman wrote:
> [EMAIL PROTECTED] wrote:
> 
>> stas2004/08/08 23:19:16
>>
>>   Modified:perl-framework/Apache-Test/lib/Apache Test.pm
>> TestConfig.pm
>> TestRun.pm
>>   Log:
>>   another round of fixes of fixes
> 
> 
> We are definitely not ready for the planned release. My recent attempts
> to fix a fatal configuration bug affecting end users, have unstabilized
> things, as I have shuffled some of the execution sequences, and w/o
> tests I couldn't do through testing. So I discover problem as I deply
> A-T in various context. I hope it'll be back to stable soonish.

yeah, we discussed this semi-privately - we're bagging the proposed release
of A-T 1.13 and will re-roll a 1.13 candidate in a bit when we're all done
tinkering.  funny how activity seems to come in flurries :)

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache Test.pm TestConfig.pm TestRun.pm

[Stas Bekman]

[EMAIL PROTECTED] wrote:
stas2004/08/08 23:19:16
  Modified:perl-framework/Apache-Test/lib/Apache Test.pm TestConfig.pm
TestRun.pm
  Log:
  another round of fixes of fixes
We are definitely not ready for the planned release. My recent attempts 
to fix a fatal configuration bug affecting end users, have unstabilized 
things, as I have shuffled some of the execution sequences, and w/o 
tests I couldn't do through testing. So I discover problem as I deply 
A-T in various context. I hope it'll be back to stable soonish.

--
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigPerl.pm TestRun.pm TestServer.pm

[Stas Bekman]

Geoffrey Young wrote:
(I wish there was a test suite for Apache-Test itself, not the internal
tests, but the configuration tests)

yeah, I've thought about ways to do this but wasn't able to come up with
anything decent.  it's one thing to test that t_cmp() works, quite another
to test whether the proper httpd is picked up from an end-user environment.
Probably we can do that we some sequence of configure+run of various 
setups. Unfortunatly since each one of us has a different naming/layout 
of httpd/mod_perl, it can't be re-used. Unless we come up with a common 
approach and then we can re-use each other's stuff.

--
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigPerl.pm TestRun.pm TestServer.pm

[Geoffrey Young]

> (I wish there was a test suite for Apache-Test itself, not the internal
> tests, but the configuration tests)

yeah, I've thought about ways to do this but wasn't able to come up with
anything decent.  it's one thing to test that t_cmp() works, quite another
to test whether the proper httpd is picked up from an end-user environment.

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigPerl.pm TestRun.pm TestServer.pm

[Stas Bekman]

[EMAIL PROTECTED] wrote:
stas2004/08/06 11:20:42
  Modified:perl-framework/Apache-Test Changes Makefile.PL
   perl-framework/Apache-Test/lib/Apache TestConfig.pm
TestConfigPerl.pm TestRun.pm TestServer.pm
  Log:
  move the custom config code into Apache::TestConfig, split the config
  object creation in 2 parts - first not requiring the knowledge of
  httpd location, the second requiring one, refactor the custom config
  interactive prompting into the second phase, if failed to find
  httpd. Reshuffle the code to run first bits not requiring the
  knowledge of httpd location.
I had to do some re-shuffling to change the timing of the httpd 
detection, as a few things were broken. I hope I didn't break anything. 
Please do extensive testing. Thanks.

(I wish there was a test suite for Apache-Test itself, not the internal 
tests, but the configuration tests)

--
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm

[Geoffrey Young]

David Wheeler wrote:
> On Jul 31, 2004, at 5:04 PM, Stas Bekman wrote:
> 
>>> I guess losing the skip message by making need_ functions that
>>> replace the existing have_ functions is okay. It's most important
>>> that tests continue to pass...
>>
>>
>> They will.
> 
> 
> Then I say we go with need.

I kind of favor this as well - it's really no big deal that have functions
will all of a sudden stop printing a skip message, and in doing so it will
encourage users that care to upgrade to the new function.

--Geoff

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm

[David Wheeler]

On Jul 31, 2004, at 5:04 PM, Stas Bekman wrote:
I guess losing the skip message by making need_ functions that 
replace the existing have_ functions is okay. It's most important 
that tests continue to pass...
They will.
Then I say we go with need.
Regards,
David


smime.p7s
Description: S/MIME cryptographic signature

Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm

[Stas Bekman]

David Wheeler wrote:
On Jul 31, 2004, at 9:46 AM, Stas Bekman wrote:
to me, got and have are exactly the same thing. How are you going to 
remember which one to use when?

Yes, I will. :-)
Authors of the existing tests don't have to change anything, have_foo 
will work just the same, but won't add the skip reason anymore. This 
won't make affect the existing tests in any way, rather than not 
printing the reason for a tests being skipped.

Isn't that rather significant?
Significant, yes, but not critical. Most users aren't going to bother to 
figure out why tests were skipped and install optional modules required 
for the tests.

But, yes, the transition could be made 100% perfect, by keeping have_ 
as it is, and adding a new interface which doesn't add the skip 
reason. But we need to find an unambiguous name for it. skip_foo will 
be good, but we have a general function have(), which can't be 
replaced with skip(). So may be want_foo() is a better choice. Or may 
be you have a better name...

I thought I did. Hrm...
Sorry, I was asking others to suggest too :)
or may be add must_have_*, so have_* is for checking, and must_have_* 
is checking and requiring. may be it's too long to type, but I like it.

That's similar to have in the same way got is. Are you going to remember 
which is which?
Yes, because one suggests a requirement and the other tells you what you 
have. While essentially the two are the same, the context is different. 
It's almost like 'require Foo' vs. 'eval { require Foo }'.

I guess losing the skip message by making need_ functions that replace 
the existing have_ functions is okay. It's most important that tests 
continue to pass...
They will.
--
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm

[David Wheeler]

On Jul 31, 2004, at 9:46 AM, Stas Bekman wrote:
to me, got and have are exactly the same thing. How are you going to 
remember which one to use when?
Yes, I will. :-)
Authors of the existing tests don't have to change anything, have_foo 
will work just the same, but won't add the skip reason anymore. This 
won't make affect the existing tests in any way, rather than not 
printing the reason for a tests being skipped.
Isn't that rather significant?
But, yes, the transition could be made 100% perfect, by keeping have_ 
as it is, and adding a new interface which doesn't add the skip 
reason. But we need to find an unambiguous name for it. skip_foo will 
be good, but we have a general function have(), which can't be 
replaced with skip(). So may be want_foo() is a better choice. Or may 
be you have a better name...
I thought I did. Hrm...
or may be add must_have_*, so have_* is for checking, and must_have_* 
is checking and requiring. may be it's too long to type, but I like 
it.
That's similar to have in the same way got is. Are you going to 
remember which is which?

I guess losing the skip message by making need_ functions that replace 
the existing have_ functions is okay. It's most important that tests 
continue to pass...

Regards,
David


smime.p7s
Description: S/MIME cryptographic signature