On Tue, 7 Dec 2004, Stas Bekman wrote:
> Randy, please try this patch:
[ ... ]
Works great, Stas! And the patched echo_bbs2 tests (with the
cleanup calls) all pass. Thanks.
--
best regards,
randy
-
To unsubscribe, e-mail: [EMAI
+ABSPERL => 'perlpath',
+ABSPERLRUN => 'perlpath',
That works fine - thanks!
Thanks. Committed.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http:/
On Tue, 7 Dec 2004, Stas Bekman wrote:
> Randy Kobes wrote:
>
> >>>In Apache::BuildConfig, there's some functions (eg, mv) that
> >>>are defined within the generated Makefile as
> >>>$(ABSPERLRUN) -MExtUtils::Command -e mv
> >>>(for those platforms for which a system 'mv' isn't
> >>>available)
Here's a patch to make sure we check for both the proxy and the
proxy_http modules.
Thanks Chris, committed.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://p
Christopher H. Laco wrote:
Stas Bekman wrote:
Christopher H. Laco wrote:
FWIW, I've all those modules linked in statically and I also have
this problem, though very randomly. I still didn't figure out how to
reproduce it deterministically.
WHen you have the proxy issues, is just a hang, or a fla
Christopher H. Laco wrote:
Christopher H. Laco wrote:
[snip]
Changing my httpd.conf fixes the failing test. Now, I assumed if was
just a matter of changing
plan tests => 1, need need_module('proxy'),
need_access;
to
plan tests => 1, need need_module(['proxy', 'proxy_http']),
need_access;
And here's the problem.a dump of $cfg->{modules} during need_module
shows this:
...
mod_deflate.c
mod_proxy.c
core.c
http_core.c
proxy_http.c<- Hey, that's not intuitive given the
LoadModule line. :-)
mpm_winnt.c
...
Of course, it will
Stas Bekman wrote:
Christopher H. Laco wrote:
FWIW, I've all those modules linked in statically and I also have
this problem, though very randomly. I still didn't figure out how to
reproduce it deterministically.
WHen you have the proxy issues, is just a hang, or a flat out error?
At least in my
Christopher H. Laco wrote:
FWIW, I've all those modules linked in statically and I also have this
problem, though very randomly. I still didn't figure out how to
reproduce it deterministically.
WHen you have the proxy issues, is just a hang, or a flat out error?
At least in my case I was getting
Stas Bekman wrote:
[snip]
add:
error $cfg->{modules}
to dump what's inside in need_module() sub in Apache/Test.pm?
It creates the list during t/TEST -conf. So you must not change
t/conf/httpd.conf, but your global httpd.conf from which it copies those
values. run t/TEST -conf -trace=debug to see
Christopher H. Laco wrote:
Ok, I've started looking into these. At least in my case this was the
root error of both of these failures:
[Tue Dec 07 19:14:34 2004] [debug] mod_proxy.c(416): Trying to run
scheme_handler
[Tue Dec 07 19:14:34 2004] [warn] proxy: No protocol handler was valid
for th
Christopher H. Laco wrote:
[snip]
Changing my httpd.conf fixes the failing test. Now, I assumed if was
just a matter of changing
plan tests => 1, need need_module('proxy'),
need_access;
to
plan tests => 1, need need_module(['proxy', 'proxy_http']),
need_access;
However, no encantation of
Ok, I've started looking into these. At least in my case this was the
root error of both of these failures:
[Tue Dec 07 19:14:34 2004] [debug] mod_proxy.c(416): Trying to run
scheme_handler
[Tue Dec 07 19:14:34 2004] [warn] proxy: No protocol handler was valid
for the URL /TestFilter__both_str
Stas Bekman wrote:
I'm not sure why this was done in first place, but in the test suite we
now have:
t/protocol/TestProtocol
t/preconnection/TestPreConnection
t/hooks/TestHooks
t/filter/TestFilter
that polute the already huge @INC. I suggest to move those to t/response
and get rid of the special
Jie Gao wrote:
Just tried to test-build from cvs and got the following:
Joe, cvs is dead. It's there just because we need to get diffs for some
old checkouts.
Please try again with this update info:
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
Thanks.
-
Philippe M. Chiasson wrote:
Index: Makefile.PL
-MODPERL_AP_INCLUDEDIR => $build->ap_includedir(),
+MODPERL_AP_INCLUDEDIR => $build->->install_headers_dir(),
doesn't look like you've tested it :) ->->
MODPERL_XS_H_FILES => join(" \\\n\t", @xs_h_files),
},
clean
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas just discovered that when building static, mod_perl's header
files ended up
being installed in httpd's build tree. That had 2 bad effects. First,
3rd party
modules wouldn't find the headers. Second,
Just tried to test-build from cvs and got the following:
Reading Makefile.PL args from @ARGV
MP_DEBUG = 1
MP_USE_DSO = 1
MP_APXS = /usr/local/apache_2.0.49/bin/apxs
MP_TRACE = 1
Configuring Apache/2.0.49 mod_perl/1.99_18-dev Perl/v5.8.3
[ info] generating script t/TEST
Writing Makefi
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas just discovered that when building static, mod_perl's header
files ended up
being installed in httpd's build tree. That had 2 bad effects. First,
3rd party
modules wouldn't find the headers. Second, thus polluted, the
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas just discovered that when building static, mod_perl's header files
ended up
being installed in httpd's build tree. That had 2 bad effects. First,
3rd party
modules wouldn't find the headers. Second, thus polluted, the httpd
source tree
wouldn't
Philippe M. Chiasson wrote:
Stas just discovered that when building static, mod_perl's header files
ended up
being installed in httpd's build tree. That had 2 bad effects. First,
3rd party
modules wouldn't find the headers. Second, thus polluted, the httpd
source tree
wouldn't build anymore, con
Stas just discovered that when building static, mod_perl's header files ended up
being installed in httpd's build tree. That had 2 bad effects. First, 3rd party
modules wouldn't find the headers. Second, thus polluted, the httpd source tree
wouldn't build anymore, confused by header files that shou
I'm not sure why this was done in first place, but in the test suite we
now have:
t/protocol/TestProtocol
t/preconnection/TestPreConnection
t/hooks/TestHooks
t/filter/TestFilter
that polute the already huge @INC. I suggest to move those to t/response
and get rid of the special cases. With svn it
Randy, please try this patch:
Index: xs/maps/apr_functions.map
===
--- xs/maps/apr_functions.map (revision 110129)
+++ xs/maps/apr_functions.map (working copy)
@@ -94,7 +94,8 @@
!apr_brigade_write
!apr_brigade_puts
-apr_brigade_
+ABSPERL= $(MODPERL_PERLPATH)
+ABSPERLRUN = $(MODPERL_PERLPATH)
Also do we need both, or just one is enough? I suppose it won't harm to
have both.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://s
Randy Kobes wrote:
In Apache::BuildConfig, there's some functions (eg, mv) that
are defined within the generated Makefile as
$(ABSPERLRUN) -MExtUtils::Command -e mv
(for those platforms for which a system 'mv' isn't
available). However, src/modules/perl/Makefile.PL doesn't
define $(ABSPERLRUN) (
for reload.t please post the verbose output from console and anything
interesting from error_log, and your build options (t/REPORT). Thanks.
Geoff, I get this one too, so please disregard this request. Thanks.
--
__
Stas Bekman
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
Hmm, the apr part does look wrong:
APU_DECLARE(apr_status_t) apr_brigade_cleanup(void *data)
{
apr_bucket_brigade *b = data;
apr_bucket *e;
shouldn't it be:
apr_bucket_brigade *b = (apr_bucket_brigade *)data;
In C, this
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> Hmm, the apr part does look wrong:
>
> APU_DECLARE(apr_status_t) apr_brigade_cleanup(void *data)
> {
> apr_bucket_brigade *b = data;
> apr_bucket *e;
>
> shouldn't it be:
>
> apr_bucket_brigade *b = (apr_bucket_brigade *)data;
In C,
Glenn Strauss wrote:
On Tue, Nov 30, 2004 at 05:07:12PM -0500, Stas Bekman wrote:
Philippe M. Chiasson wrote:
[...]
Anybody remembers how were we dealing with that before? I don't think
it has ever worked, besides when an explicit value of httpd was
passed to t/TEST.
I think so too. I've managed
Randy Kobes wrote:
[...]
However, I tried changing WrapXS/APR/Brigade/Brigade.xs
to read (in the declaration of apr_brigade_cleanup)
apr_status_t
apr_brigade_cleanup(data)
APR::Brigade data
With this, the above patched protocol/echo_bbs2 tests all
pass.
Excellent. Sounds very logical to me.
Gi
Geoffrey Young wrote:
that's prefork and worker, right?
sorry, just worker at the moment.
both 2.0.47 and 2.0.52 fail for me:
2.0.47:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/filter
Geoffrey Young wrote:
[snip]
2.0.52:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/filter/both_str_req_proxy.t11 100.00% 1
t/modules/proxy.t 255 65280
>
> that's prefork and worker, right?
sorry, just worker at the moment.
both 2.0.47 and 2.0.52 fail for me:
2.0.47:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/filter/both_str_req
34 matches
Mail list logo
