Ian Holsman wrote:
The IdentityCheck directive seems to have moved to mod_ident.c in apache
2.1
One of the access tests explitly uses this directive
Options None
Options Indexes FollowSymLinks
AuthName modperl
AuthType none
IdentityCheck On
SetHandler modperl
PerlResp
Markus Wichitill wrote:
Stas Bekman wrote:
t\filter\in_bbs_inject_header.t always succeeds when run as part of
the whole "nmake new" run, and only sometimes crashes Apache when run
alone, which was only uncovered by last night's SMOKE run.
So can you run:
t/TEST -trace=debug -start
now run:
t/TE
Markus Wichitill wrote:
Stas Bekman wrote:
If I check out a fresh copy of modperl-2.0 now, "Apache-Test" and
"docs" are included, but "cvs up -d" on my previous working copies
doesn't produce those directories. What mechanism is responsible for
that?
Why did you remove those in first place? "Ap
The IdentityCheck directive seems to have moved to mod_ident.c in apache 2.1
One of the access tests explitly uses this directive
Options None
Options Indexes FollowSymLinks
AuthName modperl
AuthType none
IdentityCheck On
SetHandler modperl
PerlResponseHandler TestAPI::
Stas Bekman wrote:
t\filter\in_bbs_inject_header.t always succeeds when run as part of
the whole "nmake new" run, and only sometimes crashes Apache when run
alone, which was only uncovered by last night's SMOKE run.
So can you run:
t/TEST -trace=debug -start
now run:
t/TEST -v -run t/filter/in_bb
Stas Bekman wrote:
If I check out a fresh copy of modperl-2.0 now, "Apache-Test" and
"docs" are included, but "cvs up -d" on my previous working copies
doesn't produce those directories. What mechanism is responsible for
that?
Why did you remove those in first place? "Apache-Test" and "docs" are
Markus Wichitill wrote:
Markus Wichitill wrote:
Ah, I just noticed that there's no "Apache-Test" directory in
modperl-2.0 pulled from CVS.
If I check out a fresh copy of modperl-2.0 now, "Apache-Test" and "docs"
are included, but "cvs up -d" on my previous working copies doesn't
produce those d
Markus Wichitill wrote:
Ah, I just noticed that there's no "Apache-Test" directory in
modperl-2.0 pulled from CVS.
If I check out a fresh copy of modperl-2.0 now, "Apache-Test" and "docs" are
included, but "cvs up -d" on my previous working copies doesn't produce
those directories. What mechanis
Markus Wichitill wrote:
Stas Bekman wrote:
Do you remember the last time you run it w/o a problem? e.g. try
checking out earlier dates and try to find when the problem was
introduced.
The weird startup errors were caused by the wrong Apache::Test version
(as far as I can tell), that problem is
Stas Bekman wrote:
Ah, I just noticed that there's no "Apache-Test" directory in
modperl-2.0 pulled from CVS. So for my regular Apache/Perl
installations Apache::Test 1.13 from the Perl lib was used (probably
got there via an earlier snapshot?), while for the debug Apache/Perl
installation Apac
Stas Bekman wrote:
Markus Wichitill wrote:
Ah, I just noticed that there's no "Apache-Test" directory in
modperl-2.0 pulled from CVS. So for my regular Apache/Perl
installations Apache::Test 1.13 from the Perl lib was used (probably
got there via an earlier snapshot?), while for the debug Apach
Markus Wichitill wrote:
Randy Kobes wrote:
C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
-clean
C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
-bugreport -verbose=0
"my" variable $script masks earlier declaration in same scope at
C:\Dev\src\modperl-2.
Randy Kobes wrote:
C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -clean
C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
-bugreport -verbose=0
"my" variable $script masks earlier declaration in same scope at
C:\Dev\src\modperl-2.0\t\response\TestApache\s
Markus Wichitill wrote:
Stas Bekman wrote:
Markus Wichitill wrote:
While running t\SMOKE last night for the ithreads scalar leak issue
didn't help with the leak issue itself, it made
t\filter\in_bbs_inject_header.t crash Apache 2.0.50/Win32 when the
test is run by itself, which I can reproduce m
Stas Bekman wrote:
Markus Wichitill wrote:
While running t\SMOKE last night for the ithreads scalar leak issue
didn't help with the leak issue itself, it made
t\filter\in_bbs_inject_header.t crash Apache 2.0.50/Win32 when the
test is run by itself, which I can reproduce manually. As part of the
Randy Kobes wrote:
On Sun, 15 Aug 2004, Stas Bekman wrote:
[ .. ]
No. Normally those happen after the handler has been run
already. How come do you get them on the client side? Is
the client leaking those? (doesn't make sense). Or is it
something specific to win32, where server logs end up on
the c
Joe Schaefer wrote:
Geoffrey Young <[EMAIL PROTECTED]> writes:
At the moment one can build Perl APR only by building mod_perl, so I
suppose apxs is fine for now.
ok. so it looks like the way to handle this is via the new APR_VERSION and
APU_VERSION queries. this is in apxs:
my $apr_version = ge
On Sun, 15 Aug 2004, Markus Wichitill wrote:
> So I finally decided to set up my own debug builds of Perl
> and Apache in addition to my normally used AS and ASF
> binaries. Compiling and installing Perl and Apache worked
> fine, however when I run "nmake test" of mod_perl CVS, the
> Apache startu
Geoffrey Young <[EMAIL PROTECTED]> writes:
> > At the moment one can build Perl APR only by building mod_perl, so I
> > suppose apxs is fine for now.
>
> ok. so it looks like the way to handle this is via the new APR_VERSION and
> APU_VERSION queries. this is in apxs:
>
> my $apr_version = g
On Sun, 15 Aug 2004, Stas Bekman wrote:
[ .. ]
> No. Normally those happen after the handler has been run
> already. How come do you get them on the client side? Is
> the client leaking those? (doesn't make sense). Or is it
> something specific to win32, where server logs end up on
> the client sid
Markus Wichitill wrote:
While running t\SMOKE last night for the ithreads scalar leak issue
didn't help with the leak issue itself, it made
t\filter\in_bbs_inject_header.t crash Apache 2.0.50/Win32 when the test
is run by itself, which I can reproduce manually. As part of the whole
sequence, th
Markus Wichitill wrote:
Stas Bekman wrote:
It seemed completely consistent to me. "nmake test" with mod_include
always leaks, "nmake test" without mod_include and partial tests
don't leak. Of course the long runtime of full tests has limited the
number of tests I could run.
But does the test fa
While running t\SMOKE last night for the ithreads scalar leak issue didn't
help with the leak issue itself, it made t\filter\in_bbs_inject_header.t
crash Apache 2.0.50/Win32 when the test is run by itself, which I can
reproduce manually. As part of the whole sequence, the test succeeds.
So I fi
Stas Bekman wrote:
It seemed completely consistent to me. "nmake test" with mod_include
always leaks, "nmake test" without mod_include and partial tests don't
leak. Of course the long runtime of full tests has limited the number
of tests I could run.
But does the test fail or not? If it doesn't
I've compared the latest accessors api with Geoff and Philippe comments on
Fred's patch and added the following entry to todo/api_status:
* the following accessors might be turned into read/write (they are
readonly at the moment). if you think that should be the case,
please document the chan
Stas Bekman wrote:
Philippe M. Chiasson wrote:
As stas pointed out in todo/release, since glue_pods is kinda broken
right now,
why not simply use ExtUtils::MakeMaker to manify and install all pods
in docs/api ?
There are several reasons:
1) perldoc won't find the docs. I think that's the case ev
26 matches
Mail list logo
