Re: Issues with --enable_mod[ules|s-shared|s-static] 'few', 'none' and proxy

[Ruediger Pluem]

On 06/23/2016 08:03 PM, Ruediger Pluem wrote:
> 
> 
> On 06/23/2016 05:49 PM, William A Rowe Jr wrote:
>> On Thu, Jun 23, 2016 at 10:24 AM, William A Rowe Jr > > wrote:
>>
>> So digging deeper, this just seemed odd until I found...
>>

>>
>>
>> Well, a +1 from trawick, anyways...
>>
>> http://svn.apache.org/viewvc?view=revision=1396440
> 
> So I guess lets backport the acinclude.m4 part of 1396440.

Out of order mail read :-). Already in STATUS.
Voted in r1749957.

Regards

Rüdiger

Re: Issues with --enable_mod[ules|s-shared|s-static] 'few', 'none' and proxy

[Ruediger Pluem]

On 06/23/2016 05:49 PM, William A Rowe Jr wrote:
> On Thu, Jun 23, 2016 at 10:24 AM, William A Rowe Jr  > wrote:
> 
> So digging deeper, this just seemed odd until I found...
> 
> On Thu, Jun 23, 2016 at 10:05 AM, William A Rowe Jr  > wrote:
> 
> On Thu, Jun 23, 2016 at 6:13 AM, Jens Schleusener 
>  > wrote:
> 
> Just for curiosity I copied the soure code via
> 
>  svn checkout 
> http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
> 
>  src/httpd-2.4.x> ./buildconf
> 
>  src/httpd-2.4.x> ./configure --enable-mods-shared=few
> 
>  configure: loading site script 
> /usr/share/site/x86_64-unknown-linux-gnu
>  checking for chosen layout... Apache
>  [... many lines deleted ...]
>  checking whether to enable mod_proxy_express... no (few)
>  checking whether to enable mod_proxy_hcheck... checking 
> dependencies
>  configure: WARNING: "mod_proxy is disabled but required for 
> mod_proxy_hcheck"
>  checking whether to enable mod_proxy_hcheck... configure: error:
>  mod_proxy_hcheck has been requested but can not be built due to 
> prerequisite failures
> 
> So it appears not the identical but a similar failure compared to 
> that one I reported some days ago ("Small
> problem in "configure" script with 2.4.21"): Now "mod_watchdog" 
> is replaced by "mod_proxy".
> 
> And again: Since the option "--enable-mods-shared=few" doesn't 
> include any "proxy"-related modules I also
> don't expect to build the "reverse-proxy health-check module".
> 
> I am not sure if there is still a problem or if my "configure" 
> building and testing is incorrect.
> 
> 
> There is still a problem, and it relates to a special case handling 
> of the underlying 'few' token. Found it, more updates shortly...
> 
> 
>   case "$enable_proxy_hcheck" in
> yes|static|shared)
>   _apmod_required="yes"
>   ;;
> *)
>   case "$module_selection" in
>   reallyall|all|most)
> _apmod_required="no"
> ;;
>   *)
> _apmod_required="yes"
> ;;
>   esac
>   esac
>  
> What is going on here is that choosing few|none actually causes
> every module dependency mismatch to become fatal, even if the 
> specific modules are not requested.
> 
> I believe this should be reduced in every module's test to simply;
> 
>   case "$enable_proxy_hcheck" in
> yes|static|shared)
>   _apmod_required="yes"
>   ;;
> *)
>   _apmod_required="no"
>   esac
> 
> Comments?
> 
> 
> Well, a +1 from trawick, anyways...
> 
> http://svn.apache.org/viewvc?view=revision=1396440

So I guess lets backport the acinclude.m4 part of 1396440.

Regards

Rüdiger

Re: T 2.4.23 tomorrow (Thurs) ??

[Jim Jagielski]

Things are still too loosey-goosey... I am going to wait
until the start of next week to (likely) T and give some
time for the churn to stabilize.

Re: Issues with --enable_mod[ules|s-shared|s-static] 'few', 'none' and proxy

[William A Rowe Jr]

On Thu, Jun 23, 2016 at 10:24 AM, William A Rowe Jr 
wrote:

> So digging deeper, this just seemed odd until I found...
>
> On Thu, Jun 23, 2016 at 10:05 AM, William A Rowe Jr 
> wrote:
>
>> On Thu, Jun 23, 2016 at 6:13 AM, Jens Schleusener <
>> jens.schleuse...@t-online.de> wrote:
>>
>>> Just for curiosity I copied the soure code via
>>>
>>>  svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
>>>
>>>  src/httpd-2.4.x> ./buildconf
>>>
>>>  src/httpd-2.4.x> ./configure --enable-mods-shared=few
>>>
>>>  configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
>>>  checking for chosen layout... Apache
>>>  [... many lines deleted ...]
>>>  checking whether to enable mod_proxy_express... no (few)
>>>  checking whether to enable mod_proxy_hcheck... checking dependencies
>>>  configure: WARNING: "mod_proxy is disabled but required for
>>> mod_proxy_hcheck"
>>>  checking whether to enable mod_proxy_hcheck... configure: error:
>>>  mod_proxy_hcheck has been requested but can not be built due to
>>> prerequisite failures
>>>
>>> So it appears not the identical but a similar failure compared to that
>>> one I reported some days ago ("Small problem in "configure" script with
>>> 2.4.21"): Now "mod_watchdog" is replaced by "mod_proxy".
>>>
>>> And again: Since the option "--enable-mods-shared=few" doesn't include
>>> any "proxy"-related modules I also don't expect to build the "reverse-proxy
>>> health-check module".
>>>
>>> I am not sure if there is still a problem or if my "configure" building
>>> and testing is incorrect.
>>>
>>
>> There is still a problem, and it relates to a special case handling
>> of the underlying 'few' token. Found it, more updates shortly...
>>
>
>   case "$enable_proxy_hcheck" in
> yes|static|shared)
>   _apmod_required="yes"
>   ;;
> *)
>   case "$module_selection" in
>   reallyall|all|most)
> _apmod_required="no"
> ;;
>   *)
> _apmod_required="yes"
> ;;
>   esac
>   esac
>
> What is going on here is that choosing few|none actually causes
> every module dependency mismatch to become fatal, even if the
> specific modules are not requested.
>
> I believe this should be reduced in every module's test to simply;
>
>   case "$enable_proxy_hcheck" in
> yes|static|shared)
>   _apmod_required="yes"
>   ;;
> *)
>   _apmod_required="no"
>   esac
>
> Comments?
>

Well, a +1 from trawick, anyways...

http://svn.apache.org/viewvc?view=revision=1396440

Thus, Jim, you couldn't see this issue pop on trunk, because it was fixed
almost 4 years ago.

Re: T 2.4.23 tomorrow (Thurs) ??

[Jens Schleusener]

On Thu, 23 Jun 2016, William A Rowe Jr wrote:


On Thu, Jun 23, 2016 at 6:13 AM, Jens Schleusener 
 wrote:
  Just for curiosity I copied the soure code via

 svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x

 src/httpd-2.4.x> ./buildconf

 src/httpd-2.4.x> ./configure --enable-mods-shared=few

 configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
 checking for chosen layout... Apache
 [... many lines deleted ...]
 checking whether to enable mod_proxy_express... no (few)
 checking whether to enable mod_proxy_hcheck... checking dependencies
 configure: WARNING: "mod_proxy is disabled but required for mod_proxy_hcheck"
 checking whether to enable mod_proxy_hcheck... configure: error:
 mod_proxy_hcheck has been requested but can not be built due to prerequisite 
failures

So it appears not the identical but a similar failure compared to that one I 
reported some days ago
("Small problem in "configure" script with 2.4.21"): Now "mod_watchdog" is replaced by 
"mod_proxy".

And again: Since the option "--enable-mods-shared=few" doesn't include any 
"proxy"-related modules I
also don't expect to build the "reverse-proxy health-check module".

I am not sure if there is still a problem or if my "configure" building and 
testing is incorrect.


There is still a problem, and it relates to a special case handling 
of the underlying 'few' token. Found it, more updates shortly...


... good news.

So now nearly superfluous info but just for completeness: Your first patch 
for modules/proxy/config.m4 sent at "Thu, 23 Jun 2016 07:32:02 -0500" 
solved at least the superficial problem and let the configure run end 
without an error.


But caused by some cut unicode errors and since your diff has within 
the 3 trailing unified lines the line


 enable_proxy_hcheck="no";

where the original file modules/proxy/config.m4 has at line number 67

 enable_proxy_hcheck="";

I had to apply the patch manually.

Jens

Issues with --enable_mod[ules|s-shared|s-static] 'few', 'none' and proxy

[William A Rowe Jr]

So digging deeper, this just seemed odd until I found...

On Thu, Jun 23, 2016 at 10:05 AM, William A Rowe Jr 
wrote:

> On Thu, Jun 23, 2016 at 6:13 AM, Jens Schleusener <
> jens.schleuse...@t-online.de> wrote:
>
>> Just for curiosity I copied the soure code via
>>
>>  svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
>>
>>  src/httpd-2.4.x> ./buildconf
>>
>>  src/httpd-2.4.x> ./configure --enable-mods-shared=few
>>
>>  configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
>>  checking for chosen layout... Apache
>>  [... many lines deleted ...]
>>  checking whether to enable mod_proxy_express... no (few)
>>  checking whether to enable mod_proxy_hcheck... checking dependencies
>>  configure: WARNING: "mod_proxy is disabled but required for
>> mod_proxy_hcheck"
>>  checking whether to enable mod_proxy_hcheck... configure: error:
>>  mod_proxy_hcheck has been requested but can not be built due to
>> prerequisite failures
>>
>> So it appears not the identical but a similar failure compared to that
>> one I reported some days ago ("Small problem in "configure" script with
>> 2.4.21"): Now "mod_watchdog" is replaced by "mod_proxy".
>>
>> And again: Since the option "--enable-mods-shared=few" doesn't include
>> any "proxy"-related modules I also don't expect to build the "reverse-proxy
>> health-check module".
>>
>> I am not sure if there is still a problem or if my "configure" building
>> and testing is incorrect.
>>
>
> There is still a problem, and it relates to a special case handling
> of the underlying 'few' token. Found it, more updates shortly...
>

  case "$enable_proxy_hcheck" in
yes|static|shared)
  _apmod_required="yes"
  ;;
*)
  case "$module_selection" in
  reallyall|all|most)
_apmod_required="no"
;;
  *)
_apmod_required="yes"
;;
  esac
  esac

What is going on here is that choosing few|none actually causes
every module dependency mismatch to become fatal, even if the
specific modules are not requested.

I believe this should be reduced in every module's test to simply;

  case "$enable_proxy_hcheck" in
yes|static|shared)
  _apmod_required="yes"
  ;;
*)
  _apmod_required="no"
  esac

Comments?

Re: T 2.4.23 tomorrow (Thurs) ??

[William A Rowe Jr]

On Thu, Jun 23, 2016 at 6:13 AM, Jens Schleusener <
jens.schleuse...@t-online.de> wrote:

> Just for curiosity I copied the soure code via
>
>  svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
>
>  src/httpd-2.4.x> ./buildconf
>
>  src/httpd-2.4.x> ./configure --enable-mods-shared=few
>
>  configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
>  checking for chosen layout... Apache
>  [... many lines deleted ...]
>  checking whether to enable mod_proxy_express... no (few)
>  checking whether to enable mod_proxy_hcheck... checking dependencies
>  configure: WARNING: "mod_proxy is disabled but required for
> mod_proxy_hcheck"
>  checking whether to enable mod_proxy_hcheck... configure: error:
>  mod_proxy_hcheck has been requested but can not be built due to
> prerequisite failures
>
> So it appears not the identical but a similar failure compared to that one
> I reported some days ago ("Small problem in "configure" script with
> 2.4.21"): Now "mod_watchdog" is replaced by "mod_proxy".
>
> And again: Since the option "--enable-mods-shared=few" doesn't include any
> "proxy"-related modules I also don't expect to build the "reverse-proxy
> health-check module".
>
> I am not sure if there is still a problem or if my "configure" building
> and testing is incorrect.
>

There is still a problem, and it relates to a special case handling
of the underlying 'few' token. Found it, more updates shortly...

Re: T 2.4.23 tomorrow (Thurs) ??

[William A Rowe Jr]

On Thu, Jun 23, 2016 at 7:32 AM, William A Rowe Jr 
wrote:

> The patch appears to be as simple as;
> ...
>

Close, not quite. The defect is actually in...

if test "$enable_proxy" = "shared"; then
  proxy_mods_enable=shared
elif test "$enable_proxy" = "yes"; then
  proxy_mods_enable=yes
else
  proxy_mods_enable=most
fi

We should have never been "forcing" every proxy module within the
--enable-proxy=[yes|shared] toggle to build.  That is defective.

If --enable-proxy is combined with --enable-mods-shared=few why
would we build 'all' proxy components? Some --enable-all-proxy
flag could have been appropriate, but in a few/none scenario we
should never trigger a cluster of modules for electing to build just one.

I don't know that such a fix is 'in-scope' of 2.4, the idea is to reduce
surprises, so I expect we can't (except on trunk). But we can at least
change that behavior to build by-default at the current level
(few/most/all/reallyall) with...

if test "$enable_proxy" = "yes"; then
  proxy_mods_enable=$module_selection

should produce the desired result, reset all of the proxy_mods to
build at the current level (e.g. --enable-mods-shared=few so that
all of the proxy modules are attempted but not fatal at level 'few')...
however that doesn't cover the 'shared' election.

The shared election can be handled if we can agree that an
enabled module with a 'shared' dependency is simply promoted
to being a shared module should solve that whole headache.

In trunk, the combination of 'most' as a fixed option for almost
all of the proxy sub-modules (except rarely used methods), with
the proxy dependency driving the train, should solve the whole
issue. But I won't commit that until we fix the defect in 2.4 so
that these don't drift out of sync yet.

So I'm still debugging...

Re: MinSpareThreads lower bound calculation and docs

[Stefan Eissing]

I am lurking with interest, but am no expert to answer your question. 

> Am 23.06.2016 um 14:55 schrieb Luca Toscano :
> 
> 
> 
> 2016-06-18 11:53 GMT+02:00 Luca Toscano :
> Hi Apache devs! 
> 
> I have a question for you about the following users@ email thread:
> 
> - 
> https://lists.apache.org/thread.html/ba26440a53773426e29296569bec17692c77a4a3bd07e8b5331474c4@1464703063@%3Cusers.httpd.apache.org%3E
> 
> This one is about Yann's fix for the MinSpareThreads lower bound calculation 
> for worker/event: http://svn.apache.org/viewvc?view=revision=1737447
> 
> I was able to explain how it works in case of bucket = 1, but I have doubts 
> when buckets > 1. I've read event/worker code and IIUC:
> 
> 1) min_spare_threads = threads_per_child * (num_buckets - 1) + num_buckets
> 2) max_spare_threads = min_spare_threads + threads_per_child * num_buckets
> 3) idle_spawn_rate controls the amount of new children created in each 
> perform_idle_server_maintenance run.
> 4) perform_idle_server_maintenance is called per bucket and calculates 
> max|min_spare_threads accordingly.
> 
> Rick's question in the email thread is about what happens when, with two 
> buckets and two processes for example, httpd reaches 50% of idle threads. I 
> made some calculations and an extra process should be indeed created, but 
> then killed because of the max_spare_threads limit. Is it going to keep 
> creating/destroying child processes or does idle_spawn_rate prevents it? 
> 
> Final goal would be to add notes in (Min|Max)SpareThreads documentation to 
> warn users about the (good) side effects of setting ListenCoresBucketRatio 
> (there is a reference in the trunk doc but very generic, it would be great to 
> have more details IMHO).
> 
> 
> Anyone? :)
> 
> Thanks!
> 
> Luca 

Re: MinSpareThreads lower bound calculation and docs

[Luca Toscano]

2016-06-18 11:53 GMT+02:00 Luca Toscano :

> Hi Apache devs!
>
> I have a question for you about the following users@ email thread:
>
> -
> https://lists.apache.org/thread.html/ba26440a53773426e29296569bec17692c77a4a3bd07e8b5331474c4@1464703063@%3Cusers.httpd.apache.org%3E
>
> This one is about Yann's fix for the MinSpareThreads lower bound
> calculation for worker/event:
> http://svn.apache.org/viewvc?view=revision=1737447
>
> I was able to explain how it works in case of bucket = 1, but I have
> doubts when buckets > 1. I've read event/worker code and IIUC:
>
> 1) min_spare_threads = threads_per_child * (num_buckets - 1) + num_buckets
> 2) max_spare_threads = min_spare_threads + threads_per_child * num_buckets
> 3) idle_spawn_rate controls the amount of new children created in
> each perform_idle_server_maintenance run.
> 4) perform_idle_server_maintenance is called per bucket and calculates
> max|min_spare_threads accordingly.
>
> Rick's question in the email thread is about what happens when, with two
> buckets and two processes for example, httpd reaches 50% of idle threads. I
> made some calculations and an extra process should be indeed created, but
> then killed because of the max_spare_threads limit. Is it going to keep
> creating/destroying child processes or does idle_spawn_rate prevents it?
>
> Final goal would be to add notes in (Min|Max)SpareThreads documentation to
> warn users about the (good) side effects of setting ListenCoresBucketRatio
> (there is a reference in the trunk doc but very generic, it would be great
> to have more details IMHO).
>
>
Anyone? :)

Thanks!

Luca

Re: T 2.4.23 tomorrow (Thurs) ??

[William A Rowe Jr]

The patch appears to be as simple as;

Index: modules/proxy/config.m4
===
--- modules/proxy/config.m4 (revision 1749791)
+++ modules/proxy/config.m4 (working copy)
@@ -59,14 +59,13 @@
 APACHE_MODULE(proxy_balancer, Apache proxy BALANCER module.  Requires and
is enabled by --enable-proxy., $proxy_balancer_objs, , $proxy_mods_enable,,
proxy)

 APACHE_MODULE(proxy_express, mass reverse-proxy module. Requires
--enable-proxy., , , $proxy_mods_enable,, proxy)
-APACHE_MODULE(proxy_hcheck, [reverse-proxy health-check module. Requires
--enable-proxy and --enable-watchdog.], , ,[
-  $proxy_mods_enable
-  dnl Verify that both proxy_mods_enable above and watchdog below are
enabled
+APACHE_MODULE(proxy_hcheck, [reverse-proxy health-check module. Requires
--enable-proxy and --enable-watchdog.], , , $proxy_mods_enable, [
+  dnl Verify that both proxy_mods_enable above and watchdog below are
honored
   dnl when --enable-proxy-hcheck isn't explicitly elected
   if test "$enable_watchdog" = "no"; then
 enable_proxy_hcheck="no";
   fi
-], , [proxy,watchdog])
+], [proxy,watchdog])

 APR_ADDTO(INCLUDES, [-I\$(top_srcdir)/$modpath_current])

... or perhaps enable_proxy_hcheck="" - and let prerequisites
kill the enablement. Still reviewing.

On Thu, Jun 23, 2016 at 7:21 AM, Jim Jagielski  wrote:

> Ugg... Thanks for the test and the feedback. Will hold off
> and look into it.
>
> > On Jun 23, 2016, at 7:13 AM, Jens Schleusener <
> jens.schleuse...@t-online.de> wrote:
> >
> > On Wed, 22 Jun 2016, Jim Jagielski wrote:
> >
> >> Subj sez it all... afaict, there are no showstoppers and
> >> no outstanding issues (none seen in STATUS, or noted as
> >> such on any Email threads).
> >>
> >> So... anyone opposed to a T tomorrow in the hopes
> >> of getting this out to people by the start of next week??
> >
> > Just for curiosity I copied the soure code via
> >
> > svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
> >
> > and did for building the "configure" script a
> >
> > src/httpd-2.4.x> ./buildconf
> >
> > found apr source: srclib/apr
> > rebuilding srclib/apr/configure
> > buildconf: checking installation...
> > buildconf: python version 2.7.9 (ok)
> > buildconf: autoconf version 2.69 (ok)
> > buildconf: libtool version 2.4.2 (ok)
> > buildconf: copying libtool helper files using /usr/bin/libtoolize
> > buildconf: creating include/arch/unix/apr_private.h.in ...
> > buildconf: creating configure ...
> > buildconf: generating 'make' outputs ...
> > buildconf: rebuilding rpm spec file
> > copying build files
> > rebuilding include/ap_config_auto.h.in
> > rebuilding configure
> > rebuilding rpm spec file
> > fixing timestamps for ap_expr sources
> >
> > and then issued
> >
> > src/httpd-2.4.x> ./configure --enable-mods-shared=few
> >
> > configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
> > checking for chosen layout... Apache
> > [... many lines deleted ...]
> > checking whether to enable mod_proxy_express... no (few)
> > checking whether to enable mod_proxy_hcheck... checking dependencies
> > configure: WARNING: "mod_proxy is disabled but required for
> mod_proxy_hcheck"
> > checking whether to enable mod_proxy_hcheck... configure: error:
> > mod_proxy_hcheck has been requested but can not be built due to
> prerequisite failures
> >
> > So it appears not the identical but a similar failure compared to that
> one I reported some days ago ("Small problem in "configure" script with
> 2.4.21"): Now "mod_watchdog" is replaced by "mod_proxy".
> >
> > And again: Since the option "--enable-mods-shared=few" doesn't include
> any "proxy"-related modules I also don't expect to build the "reverse-proxy
> health-check module".
> >
> > I am not sure if there is still a problem or if my "configure" building
> and testing is incorrect.
> >
> > Regards
> >
> > Jens
> >
>
>

Re: T 2.4.23 tomorrow (Thurs) ??

[William A Rowe Jr]

There is still a reproducible edge case here, thanks for the report
(focused on the later half of your email).  Nothing unusual about your
./buildconf environment.

Also --enable-modules=few exhibits the same behavior.  Will have an update
in the next 30 minutes.
On Jun 23, 2016 7:10 AM, "William A Rowe Jr"  wrote:

> On Jun 23, 2016 6:13 AM, "Jens Schleusener" 
> wrote:
> >
> > On Wed, 22 Jun 2016, Jim Jagielski wrote:
> >
> >> Subj sez it all... afaict, there are no showstoppers and
> >> no outstanding issues (none seen in STATUS, or noted as
> >> such on any Email threads).
> >>
> >> So... anyone opposed to a T tomorrow in the hopes
> >> of getting this out to people by the start of next week??
> >
> >
> > Just for curiosity I copied the soure code via
> >
> >  svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
> >
> > and did for building the "configure" script a
> >
> >  src/httpd-2.4.x> ./buildconf
> >
> >  found apr source: srclib/apr
> >  rebuilding srclib/apr/configure
> >  buildconf: checking installation...
> >  buildconf: python version 2.7.9 (ok)
> >  buildconf: autoconf version 2.69 (ok)
> >  buildconf: libtool version 2.4.2 (ok)
> >  buildconf: copying libtool helper files using /usr/bin/libtoolize
> >  buildconf: creating include/arch/unix/apr_private.h.in ...
> >  buildconf: creating configure ...
> >  buildconf: generating 'make' outputs ...
> >  buildconf: rebuilding rpm spec file
> >  copying build files
> >  rebuilding include/ap_config_auto.h.in
> >  rebuilding configure
> >  rebuilding rpm spec file
> >  fixing timestamps for ap_expr sources
> >
> > and then issued
> >
> >  src/httpd-2.4.x> ./configure --enable-mods-shared=few
> >
> >  configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
> >  checking for chosen layout... Apache
> >  [... many lines deleted ...]
> >  checking whether to enable mod_proxy_express... no (few)
> >  checking whether to enable mod_proxy_hcheck... checking dependencies
> >  configure: WARNING: "mod_proxy is disabled but required for
> mod_proxy_hcheck"
> >  checking whether to enable mod_proxy_hcheck... configure: error:
> >  mod_proxy_hcheck has been requested but can not be built due to
> prerequisite failures
> >
> > So it appears not the identical but a similar failure compared to that
> one I reported some days ago ("Small problem in "configure" script with
> 2.4.21"): Now "mod_watchdog" is replaced by "mod_proxy".
> >
> > And again: Since the option "--enable-mods-shared=few" doesn't include
> any "proxy"-related modules I also don't expect to build the "reverse-proxy
> health-check module".
> >
> > I am not sure if there is still a problem or if my "configure" building
> and testing is incorrect.
>
> Reviewing.  For fun, please post the output of ./buildconf
> And uname -a
>

Re: T 2.4.23 tomorrow (Thurs) ??

[Jim Jagielski]

Ugg... Thanks for the test and the feedback. Will hold off
and look into it.

> On Jun 23, 2016, at 7:13 AM, Jens Schleusener  
> wrote:
> 
> On Wed, 22 Jun 2016, Jim Jagielski wrote:
> 
>> Subj sez it all... afaict, there are no showstoppers and
>> no outstanding issues (none seen in STATUS, or noted as
>> such on any Email threads).
>> 
>> So... anyone opposed to a T tomorrow in the hopes
>> of getting this out to people by the start of next week??
> 
> Just for curiosity I copied the soure code via
> 
> svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
> 
> and did for building the "configure" script a
> 
> src/httpd-2.4.x> ./buildconf
> 
> found apr source: srclib/apr
> rebuilding srclib/apr/configure
> buildconf: checking installation...
> buildconf: python version 2.7.9 (ok)
> buildconf: autoconf version 2.69 (ok)
> buildconf: libtool version 2.4.2 (ok)
> buildconf: copying libtool helper files using /usr/bin/libtoolize
> buildconf: creating include/arch/unix/apr_private.h.in ...
> buildconf: creating configure ...
> buildconf: generating 'make' outputs ...
> buildconf: rebuilding rpm spec file
> copying build files
> rebuilding include/ap_config_auto.h.in
> rebuilding configure
> rebuilding rpm spec file
> fixing timestamps for ap_expr sources
> 
> and then issued
> 
> src/httpd-2.4.x> ./configure --enable-mods-shared=few
> 
> configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
> checking for chosen layout... Apache
> [... many lines deleted ...]
> checking whether to enable mod_proxy_express... no (few)
> checking whether to enable mod_proxy_hcheck... checking dependencies
> configure: WARNING: "mod_proxy is disabled but required for mod_proxy_hcheck"
> checking whether to enable mod_proxy_hcheck... configure: error:
> mod_proxy_hcheck has been requested but can not be built due to prerequisite 
> failures
> 
> So it appears not the identical but a similar failure compared to that one I 
> reported some days ago ("Small problem in "configure" script with 2.4.21"): 
> Now "mod_watchdog" is replaced by "mod_proxy".
> 
> And again: Since the option "--enable-mods-shared=few" doesn't include any 
> "proxy"-related modules I also don't expect to build the "reverse-proxy 
> health-check module".
> 
> I am not sure if there is still a problem or if my "configure" building and 
> testing is incorrect.
> 
> Regards
> 
> Jens
> 

Re: T 2.4.23 tomorrow (Thurs) ??

[William A Rowe Jr]

On Jun 23, 2016 6:13 AM, "Jens Schleusener" 
wrote:
>
> On Wed, 22 Jun 2016, Jim Jagielski wrote:
>
>> Subj sez it all... afaict, there are no showstoppers and
>> no outstanding issues (none seen in STATUS, or noted as
>> such on any Email threads).
>>
>> So... anyone opposed to a T tomorrow in the hopes
>> of getting this out to people by the start of next week??
>
>
> Just for curiosity I copied the soure code via
>
>  svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x
>
> and did for building the "configure" script a
>
>  src/httpd-2.4.x> ./buildconf
>
>  found apr source: srclib/apr
>  rebuilding srclib/apr/configure
>  buildconf: checking installation...
>  buildconf: python version 2.7.9 (ok)
>  buildconf: autoconf version 2.69 (ok)
>  buildconf: libtool version 2.4.2 (ok)
>  buildconf: copying libtool helper files using /usr/bin/libtoolize
>  buildconf: creating include/arch/unix/apr_private.h.in ...
>  buildconf: creating configure ...
>  buildconf: generating 'make' outputs ...
>  buildconf: rebuilding rpm spec file
>  copying build files
>  rebuilding include/ap_config_auto.h.in
>  rebuilding configure
>  rebuilding rpm spec file
>  fixing timestamps for ap_expr sources
>
> and then issued
>
>  src/httpd-2.4.x> ./configure --enable-mods-shared=few
>
>  configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
>  checking for chosen layout... Apache
>  [... many lines deleted ...]
>  checking whether to enable mod_proxy_express... no (few)
>  checking whether to enable mod_proxy_hcheck... checking dependencies
>  configure: WARNING: "mod_proxy is disabled but required for
mod_proxy_hcheck"
>  checking whether to enable mod_proxy_hcheck... configure: error:
>  mod_proxy_hcheck has been requested but can not be built due to
prerequisite failures
>
> So it appears not the identical but a similar failure compared to that
one I reported some days ago ("Small problem in "configure" script with
2.4.21"): Now "mod_watchdog" is replaced by "mod_proxy".
>
> And again: Since the option "--enable-mods-shared=few" doesn't include
any "proxy"-related modules I also don't expect to build the "reverse-proxy
health-check module".
>
> I am not sure if there is still a problem or if my "configure" building
and testing is incorrect.

Reviewing.  For fun, please post the output of ./buildconf
And uname -a

Re: T 2.4.23 tomorrow (Thurs) ??

[Jens Schleusener]

On Wed, 22 Jun 2016, Jim Jagielski wrote:


Subj sez it all... afaict, there are no showstoppers and
no outstanding issues (none seen in STATUS, or noted as
such on any Email threads).

So... anyone opposed to a T tomorrow in the hopes
of getting this out to people by the start of next week??


Just for curiosity I copied the soure code via

 svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x

and did for building the "configure" script a

 src/httpd-2.4.x> ./buildconf

 found apr source: srclib/apr
 rebuilding srclib/apr/configure
 buildconf: checking installation...
 buildconf: python version 2.7.9 (ok)
 buildconf: autoconf version 2.69 (ok)
 buildconf: libtool version 2.4.2 (ok)
 buildconf: copying libtool helper files using /usr/bin/libtoolize
 buildconf: creating include/arch/unix/apr_private.h.in ...
 buildconf: creating configure ...
 buildconf: generating 'make' outputs ...
 buildconf: rebuilding rpm spec file
 copying build files
 rebuilding include/ap_config_auto.h.in
 rebuilding configure
 rebuilding rpm spec file
 fixing timestamps for ap_expr sources

and then issued

 src/httpd-2.4.x> ./configure --enable-mods-shared=few

 configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
 checking for chosen layout... Apache
 [... many lines deleted ...]
 checking whether to enable mod_proxy_express... no (few)
 checking whether to enable mod_proxy_hcheck... checking dependencies
 configure: WARNING: "mod_proxy is disabled but required for mod_proxy_hcheck"
 checking whether to enable mod_proxy_hcheck... configure: error:
 mod_proxy_hcheck has been requested but can not be built due to prerequisite 
failures

So it appears not the identical but a similar failure compared to that one 
I reported some days ago ("Small problem in "configure" script with 
2.4.21"): Now "mod_watchdog" is replaced by "mod_proxy".


And again: Since the option "--enable-mods-shared=few" doesn't include any 
"proxy"-related modules I also don't expect to build the "reverse-proxy 
health-check module".


I am not sure if there is still a problem or if my "configure" building 
and testing is incorrect.


Regards

Jens

Re: T 2.4.23 tomorrow (Thurs) ??

[Marion & Christophe JAILLET]

Well, perl seems to be at the expected place but perlsub.pod seems to be 
nowhere.


Must be an issue on my test environment or a file not included in my 
distro or a change between perl 5.18 and 5.22


Thx for your time and explanation.

CJ


Le 23/06/2016 à 10:55, Stefan Eissing a écrit :

As you can see: in your installation, the /getfiles-perl-pod/perlsub.pod cannot 
be found.
In t/conf/httpd.conf:Alias /getfiles-binary-perl /usr/bin/perl

So, maybe you do have perl in a different location?

Re: T 2.4.23 tomorrow (Thurs) ??

[Stefan Eissing]

Did not have mod_cgi loaded. Now:

t/filter/case.t .. [Thu Jun 23 10:50:33.548696 2016] [so:warn] [pid 57617:tid 
140735287451648] AH01574: module cgid_module is already loaded, skipping

1..4
# Running under perl version 5.018002 for darwin
# Current time local: Thu Jun 23 10:50:33 2016
# Current time GMT:   Thu Jun 23 08:50:33 2016
# Using Test.pm version 1.26
# Using Apache/Test.pm version 1.40
ok 1
# testing mod_alias with /getfiles-perl-pod/perlsub.pod
# expected 200
# received 200
ok 2
# testing mod_cgi with /modules/cgi/perl.pl
# expected 200
# received 200
ok 3
# testing mod_test_rwrite with /test_rwrite
# expected 200
# received 200
ok 4
ok
All tests successful.
Files=1, Tests=4,  0 wallclock secs ( 0.02 usr  0.01 sys +  0.35 cusr  0.16 
csys =  0.54 CPU)
Result: PASS

As you can see: in your installation, the /getfiles-perl-pod/perlsub.pod cannot 
be found.
In t/conf/httpd.conf:Alias /getfiles-binary-perl /usr/bin/perl

So, maybe you do have perl in a different location?

> Am 23.06.2016 um 10:40 schrieb Marion & Christophe JAILLET 
> :
> 
> Current 2.4.x, Ubuntu 16.04:
> 
> The output with -verbose is:
> 
> t/filter/case.t ..
> 1..4
> # Running under perl version 5.022001 for linux
> # Current time local: Thu Jun 23 10:39:03 2016
> # Current time GMT:   Thu Jun 23 08:39:03 2016
> # Using Test.pm version 1.26
> # Using Apache/Test.pm version 1.40
> ok 1
> # testing mod_alias with /getfiles-perl-pod/perlsub.pod
> # expected 200
> # received 404
> not ok 2
> # Failed test 2 in t/filter/case.t at line 39 fail #2
> # testing mod_cgi with /modules/cgi/perl.pl
> # expected 200
> # received 200
> ok 3
> # testing mod_test_rwrite with /test_rwrite
> # expected 200
> # received 200
> ok 4
> Failed 1/4 subtests
> 
> Test Summary Report
> ---
> t/filter/case.t (Wstat: 0 Tests: 4 Failed: 1)
>  Failed test:  2
> Files=1, Tests=4,  0 wallclock secs ( 0.01 usr  0.01 sys +  0.29 cusr  0.06 
> csys =  0.37 CPU)
> Result: FAIL
> Failed 1/1 test programs. 1/4 subtests failed.
> 
> 
> I have 4 tests, you have 3.
> Could you re-run with -verbose to see which one is not run on your system?
> 
> CJ
> 
> 
> 
> Le 23/06/2016 à 10:22, Stefan Eissing a écrit :
>> Current 2.4.x, OS X:
>> 
>> t/filter/case.t .. ok
>> All tests successful.
>> Files=1, Tests=3,  1 wallclock secs ( 0.01 usr  0.00 sys +  0.36 cusr  0.18 
>> csys =  0.55 CPU)
>> Result: PASS
>> 
>>> Am 23.06.2016 um 10:08 schrieb Marion & Christophe JAILLET 
>>> :
>>> 
>>> 
>>> 
>>> Le 22/06/2016 à 22:05, Jim Jagielski a écrit :
 Subj sez it all... afaict, there are no showstoppers and
 no outstanding issues (none seen in STATUS, or noted as
 such on any Email threads).
 
 So... anyone opposed to a T tomorrow in the hopes
 of getting this out to people by the start of next week??
 
>>> Hi,
>>> 
>>> while testing, I have:
>>> 
>>> t/filter/case.t ..
>>> 1..4
>>> # Running under perl version 5.022001 for linux
>>> # Current time local: Thu Jun 23 09:45:04 2016
>>> # Current time GMT:   Thu Jun 23 07:45:04 2016
>>> # Using Test.pm version 1.26
>>> # Using Apache/Test.pm version 1.40
>>> ok 1
>>> # testing mod_alias with /getfiles-perl-pod/perlsub.pod
>>> # expected 200
>>> # received 404
>>> not ok 2
>>> 
>>> 
>>> I don't know how to diagnose it.
>>> 
>>> CJ
>> 
> 

Re: T 2.4.23 tomorrow (Thurs) ??

[Marion & Christophe JAILLET]

Current 2.4.x, Ubuntu 16.04:

The output with -verbose is:

t/filter/case.t ..
1..4
# Running under perl version 5.022001 for linux
# Current time local: Thu Jun 23 10:39:03 2016
# Current time GMT:   Thu Jun 23 08:39:03 2016
# Using Test.pm version 1.26
# Using Apache/Test.pm version 1.40
ok 1
# testing mod_alias with /getfiles-perl-pod/perlsub.pod
# expected 200
# received 404
not ok 2
# Failed test 2 in t/filter/case.t at line 39 fail #2
# testing mod_cgi with /modules/cgi/perl.pl
# expected 200
# received 200
ok 3
# testing mod_test_rwrite with /test_rwrite
# expected 200
# received 200
ok 4
Failed 1/4 subtests

Test Summary Report
---
t/filter/case.t (Wstat: 0 Tests: 4 Failed: 1)
  Failed test:  2
Files=1, Tests=4,  0 wallclock secs ( 0.01 usr  0.01 sys +  0.29 cusr  
0.06 csys =  0.37 CPU)

Result: FAIL
Failed 1/1 test programs. 1/4 subtests failed.


I have 4 tests, you have 3.
Could you re-run with -verbose to see which one is not run on your system?

CJ



Le 23/06/2016 à 10:22, Stefan Eissing a écrit :

Current 2.4.x, OS X:

t/filter/case.t .. ok
All tests successful.
Files=1, Tests=3,  1 wallclock secs ( 0.01 usr  0.00 sys +  0.36 cusr  0.18 
csys =  0.55 CPU)
Result: PASS


Am 23.06.2016 um 10:08 schrieb Marion & Christophe JAILLET 
:



Le 22/06/2016 à 22:05, Jim Jagielski a écrit :

Subj sez it all... afaict, there are no showstoppers and
no outstanding issues (none seen in STATUS, or noted as
such on any Email threads).

So... anyone opposed to a T tomorrow in the hopes
of getting this out to people by the start of next week??


Hi,

while testing, I have:

t/filter/case.t ..
1..4
# Running under perl version 5.022001 for linux
# Current time local: Thu Jun 23 09:45:04 2016
# Current time GMT:   Thu Jun 23 07:45:04 2016
# Using Test.pm version 1.26
# Using Apache/Test.pm version 1.40
ok 1
# testing mod_alias with /getfiles-perl-pod/perlsub.pod
# expected 200
# received 404
not ok 2


I don't know how to diagnose it.

CJ

Re: T 2.4.23 tomorrow (Thurs) ??

[Stefan Eissing]

Current 2.4.x, OS X:

t/filter/case.t .. ok   
All tests successful.
Files=1, Tests=3,  1 wallclock secs ( 0.01 usr  0.00 sys +  0.36 cusr  0.18 
csys =  0.55 CPU)
Result: PASS

> Am 23.06.2016 um 10:08 schrieb Marion & Christophe JAILLET 
> :
> 
> 
> 
> Le 22/06/2016 à 22:05, Jim Jagielski a écrit :
>> Subj sez it all... afaict, there are no showstoppers and
>> no outstanding issues (none seen in STATUS, or noted as
>> such on any Email threads).
>> 
>> So... anyone opposed to a T tomorrow in the hopes
>> of getting this out to people by the start of next week??
>> 
> 
> Hi,
> 
> while testing, I have:
> 
> t/filter/case.t ..
> 1..4
> # Running under perl version 5.022001 for linux
> # Current time local: Thu Jun 23 09:45:04 2016
> # Current time GMT:   Thu Jun 23 07:45:04 2016
> # Using Test.pm version 1.26
> # Using Apache/Test.pm version 1.40
> ok 1
> # testing mod_alias with /getfiles-perl-pod/perlsub.pod
> # expected 200
> # received 404
> not ok 2
> 
> 
> I don't know how to diagnose it.
> 
> CJ

Re: T 2.4.23 tomorrow (Thurs) ??

[Marion & Christophe JAILLET]

Le 22/06/2016 à 22:05, Jim Jagielski a écrit :

Subj sez it all... afaict, there are no showstoppers and
no outstanding issues (none seen in STATUS, or noted as
such on any Email threads).

So... anyone opposed to a T tomorrow in the hopes
of getting this out to people by the start of next week??



Hi,

while testing, I have:

t/filter/case.t ..
1..4
# Running under perl version 5.022001 for linux
# Current time local: Thu Jun 23 09:45:04 2016
# Current time GMT:   Thu Jun 23 07:45:04 2016
# Using Test.pm version 1.26
# Using Apache/Test.pm version 1.40
ok 1
# testing mod_alias with /getfiles-perl-pod/perlsub.pod
# expected 200
# received 404
not ok 2


I don't know how to diagnose it.

CJ