You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2016/06/22 10:48:36 UTC
2.4.23
My plan is to tag T&R once we get the configure stuff sorted out.
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by Jim Jagielski <ji...@jaguNET.com>.
Things are still too loosey-goosey... I am going to wait
until the start of next week to (likely) T&R and give some
time for the churn to stabilize.
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jun 23, 2016 at 7:32 AM, William A Rowe Jr <wr...@rowe-clan.net>
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: T&R 2.4.23 tomorrow (Thurs) ??
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 <ji...@jagunet.com> 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.Schleusener@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).
> >>
> >> Sooooo... anyone opposed to a T&R 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&R 2.4.23 tomorrow (Thurs) ??
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <Je...@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).
>>
>> Sooooo... anyone opposed to a T&R 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&R 2.4.23 tomorrow (Thurs) ??
Posted by Jens Schleusener <Je...@t-online.de>.
On Mon, 27 Jun 2016, William A Rowe Jr wrote:
> On Mon, Jun 27, 2016 at 6:00 AM, Jens Schleusener <Je...@t-online.de> wrote:
> On Fri, 24 Jun 2016, William A Rowe Jr wrote:
>
> On Thu, Jun 23, 2016 at 10:38 AM, Jens Schleusener <Je...@t-online.de>
> wrote:
>
> 1) Just a pure ./configure (probably equivalent to using the option --enable-mods-shared=most) let
> produce the "make" (compared to the last release 2.4.20) 86 modules instead 85 modules with the
> additional modules
>
> modules/core/.libs/mod_watchdog.so
> modules/proxy/.libs/mod_proxy_hcheck.so
>
>
> Yes, proposed (and accepted) that we change the watchdog default to enable
> at enable "most", as proxy_hcheck requires it.
>
> and the omitted module
>
> modules/session/.libs/mod_session_crypto.so
>
> That may be expected.
>
>
> Need to look at mod_session_crypto, I hadn't proposed mod_session
> changes, modules/session/config.m4 hasn't changed since 2.4.21 was
> tagged. acinclude.m4 changes may have had side effects, but unlikely.
> Once the whole "--enable-proxy" decision is made, others that followed
> this broken pattern need to be reevaluated, but that isn't a change for
> a 2.4.23 tag, since there should be no regression here.
>
> There is a simpler explanation, did you change the detected apr-util
> to one without apr_crypto (based on openssl) enabled? Ensure your
> apr-util build enabled openssl and is current (1.5).
Oops, my fault, well combined, you are completely right: For 2.4.20 I
used (since I have originally not downloaded httpd-2.4.20-deps.tar.bz2)
my "separate" self-compiled apr-1.5.2 and apr-util-1.5.4
installatations (using the configure options --with-crypto
--with-openssl=/usr).
> By the way the option --enable-mods-shared=all produces 103 modules and
> --enable-mods-shared=reallyall 120 ones.
>
> 2) But for me surprising the option--enable-mods-shared=none seems to have the same configuration
> effect as the option--enable-mods-shared=most (producing 86 modules) respectively the option is
> ignored and the default "most" is used.
>
> Similar for e.g. --enable-mods-shared='headers rewrite dav' (an example from the documentation
> page http://httpd.apache.org/docs/2.4/programs/configure.html) seems to produce the same behaviour
> like --enable-mods-shared=most while I would expect that only the three specified modules would be
> buillt.
>
> Odd, also arbitray module names like --enable-mods-shared=nonsense seems equivalent to
> --enable-mods-shared=most.
>
> But that is an error it seems not a regression since 2.4.20 shows the same behaviour.
>
>
> It is, you found it, and the error was already a side effect within acinclude.m4
> which trusted the value 'no' (which is why I continued to trust the value 'no').
>
> In order for --enable-mods-shared=nonsense to behave as expected, I think
> the patch is pretty simple...
>
> --- acinclude.m4 (revision 1749925)
> +++ acinclude.m4 (working copy)
> @@ -375,6 +375,8 @@
> "$force_$1" != "no" ; then
> enable_$1=$module_default
> _apmod_extra_msg=" ($module_selection)"
> + else
> + enable_$1=no
> fi
> if test "$enable_$1" != "no"; then
> dnl If we plan to enable it, allow the module to run some autoconf magic
Just for completeness (since another fix seems on the way): At some first
quick tests this fix seems not to work for me. For httpd-2.4.x I saw no
difference in the number of built modules using either
--enable-mods-shared=nonsense or --enable-mods-shared=none and for
httpd-2.4.21 (patched with your proxy-rollup-2.4.21.patch patch) it let
only omit the modules
modules/proxy/balancers/.libs/mod_lbmethod_bybusyness.so
modules/proxy/balancers/.libs/mod_lbmethod_byrequests.so
modules/proxy/balancers/.libs/mod_lbmethod_bytraffic.so
modules/proxy/balancers/.libs/mod_lbmethod_heartbeat.so
Regards
Jens
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Jun 27, 2016 at 6:00 AM, Jens Schleusener <
Jens.Schleusener@t-online.de> wrote:
> On Fri, 24 Jun 2016, William A Rowe Jr wrote:
>
> On Thu, Jun 23, 2016 at 10:38 AM, Jens Schleusener <
>> Jens.Schleusener@t-online.de> wrote:
>>
>> 1) Just a pure ./configure (probably equivalent to using the option
> --enable-mods-shared=most) let produce the "make" (compared to the last
> release 2.4.20) 86 modules instead 85 modules with the additional modules
>
> modules/core/.libs/mod_watchdog.so
> modules/proxy/.libs/mod_proxy_hcheck.so
>
Yes, proposed (and accepted) that we change the watchdog default to enable
at enable "most", as proxy_hcheck requires it.
> and the omitted module
>
> modules/session/.libs/mod_session_crypto.so
>
> That may be expected.
>
Need to look at mod_session_crypto, I hadn't proposed mod_session
changes, modules/session/config.m4 hasn't changed since 2.4.21 was
tagged. acinclude.m4 changes may have had side effects, but unlikely.
Once the whole "--enable-proxy" decision is made, others that followed
this broken pattern need to be reevaluated, but that isn't a change for
a 2.4.23 tag, since there should be no regression here.
There is a simpler explanation, did you change the detected apr-util
to one without apr_crypto (based on openssl) enabled? Ensure your
apr-util build enabled openssl and is current (1.5).
By the way the option --enable-mods-shared=all produces 103 modules and
> --enable-mods-shared=reallyall 120 ones.
>
> 2) But for me surprising the option--enable-mods-shared=none seems to have
> the same configuration effect as the option--enable-mods-shared=most
> (producing 86 modules) respectively the option is ignored and the default
> "most" is used.
>
> Similar for e.g. --enable-mods-shared='headers rewrite dav' (an example
> from the documentation page
> http://httpd.apache.org/docs/2.4/programs/configure.html) seems to
> produce the same behaviour like --enable-mods-shared=most while I would
> expect that only the three specified modules would be buillt.
>
> Odd, also arbitray module names like --enable-mods-shared=nonsense seems
> equivalent to --enable-mods-shared=most.
>
> But that is an error it seems not a regression since 2.4.20 shows the same
> behaviour.
>
It is, you found it, and the error was already a side effect within
acinclude.m4
which trusted the value 'no' (which is why I continued to trust the value
'no').
In order for --enable-mods-shared=nonsense to behave as expected, I think
the patch is pretty simple...
--- acinclude.m4 (revision 1749925)
+++ acinclude.m4 (working copy)
@@ -375,6 +375,8 @@
"$force_$1" != "no" ; then
enable_$1=$module_default
_apmod_extra_msg=" ($module_selection)"
+ else
+ enable_$1=no
fi
if test "$enable_$1" != "no"; then
dnl If we plan to enable it, allow the module to run some autoconf
magic
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by Jens Schleusener <Je...@t-online.de>.
On Fri, 24 Jun 2016, William A Rowe Jr wrote:
> On Thu, Jun 23, 2016 at 10:38 AM, Jens Schleusener <Je...@t-online.de> wrote:
>
> ... 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.
>
>
> The entire solution is now presented in STATUS, but for reviewers
> I've rolled up all of the diffs into a single delta that can be applied
> to either 2.4.21 or 2.4.22 release candidates for easier testing;
>
> https://raw.githubusercontent.com/wrowe/patches/master/proxy-rollup-2.4.21.patch
>
> This will hopefully address every edge case with the proxy and
> proxy sub-modules logic in ./configure (just be sure to re-run
> ./buildconf after applying this patch!)
Ok, I applied the patch to both release candidates and a
./configure --enable-mods-shared=few
ends without errors (using openSUSE Leap 42.1; autoconf-2.69-11.4.noarch;
libtool-2.4.2-16.6.x86_64).
But a subsequent "make" produces to the expected 21 modules
additionally the 4 modules
modules/proxy/balancers/.libs/mod_lbmethod_bybusyness.so
modules/proxy/balancers/.libs/mod_lbmethod_byrequests.so
modules/proxy/balancers/.libs/mod_lbmethod_bytraffic.so
modules/proxy/balancers/.libs/mod_lbmethod_heartbeat.so
As since yesterday httpd-2.4.x seems now accordingly patched I tried that
branch and it also works with the above configure command and a subsequent
"make" produces just the expected 21 modules.
So for the original reported error regarding the configure option
--enable-mods-shared=few the fixes seems ok now.
But some observations (from an outsider):
1) Just a pure ./configure (probably equivalent to using the option
--enable-mods-shared=most) let produce the "make" (compared to the last
release 2.4.20) 86 modules instead 85 modules with the additional modules
modules/core/.libs/mod_watchdog.so
modules/proxy/.libs/mod_proxy_hcheck.so
and the omitted module
modules/session/.libs/mod_session_crypto.so
That may be expected.
By the way the option --enable-mods-shared=all produces 103 modules and
--enable-mods-shared=reallyall 120 ones.
2) But for me surprising the option--enable-mods-shared=none seems to have
the same configuration effect as the option--enable-mods-shared=most
(producing 86 modules) respectively the option is ignored and the default
"most" is used.
Similar for e.g. --enable-mods-shared='headers rewrite dav' (an example
from the documentation page
http://httpd.apache.org/docs/2.4/programs/configure.html) seems to produce
the same behaviour like --enable-mods-shared=most while I would expect
that only the three specified modules would be buillt.
Odd, also arbitray module names like --enable-mods-shared=nonsense seems
equivalent to --enable-mods-shared=most.
But that is an error it seems not a regression since 2.4.20 shows the same
behaviour.
Regards
Jens
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jun 23, 2016 at 10:38 AM, Jens Schleusener <
Jens.Schleusener@t-online.de> wrote:
>
> ... 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.
>
The entire solution is now presented in STATUS, but for reviewers
I've rolled up all of the diffs into a single delta that can be applied
to either 2.4.21 or 2.4.22 release candidates for easier testing;
https://raw.githubusercontent.com/wrowe/patches/master/proxy-rollup-2.4.21.patch
This will hopefully address every edge case with the proxy and
proxy sub-modules logic in ./configure (just be sure to re-run
./buildconf after applying this patch!)
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by Jens Schleusener <Je...@t-online.de>.
On Thu, 23 Jun 2016, William A Rowe Jr wrote:
> On Thu, Jun 23, 2016 at 6:13 AM, Jens Schleusener <Je...@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...
... 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&paste 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
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jun 23, 2016 at 6:13 AM, Jens Schleusener <
Jens.Schleusener@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&R 2.4.23 tomorrow (Thurs) ??
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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" <wr...@rowe-clan.net> wrote:
> On Jun 23, 2016 6:13 AM, "Jens Schleusener" <Je...@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).
> >>
> >> Sooooo... anyone opposed to a T&R 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&R 2.4.23 tomorrow (Thurs) ??
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Jun 23, 2016 6:13 AM, "Jens Schleusener" <Je...@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).
>>
>> Sooooo... anyone opposed to a T&R 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&R 2.4.23 tomorrow (Thurs) ??
Posted by Jens Schleusener <Je...@t-online.de>.
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).
>
> Sooooo... anyone opposed to a T&R 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&R 2.4.23 tomorrow (Thurs) ??
Posted by Marion & Christophe JAILLET <ch...@wanadoo.fr>.
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&R 2.4.23 tomorrow (Thurs) ??
Posted by Stefan Eissing <st...@greenbytes.de>.
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 <ch...@wanadoo.fr>:
>
> 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 <ch...@wanadoo.fr>:
>>>
>>>
>>>
>>> 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).
>>>>
>>>> Sooooo... anyone opposed to a T&R 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&R 2.4.23 tomorrow (Thurs) ??
Posted by Marion & Christophe JAILLET <ch...@wanadoo.fr>.
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 <ch...@wanadoo.fr>:
>>
>>
>>
>> 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).
>>>
>>> Sooooo... anyone opposed to a T&R 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&R 2.4.23 tomorrow (Thurs) ??
Posted by Stefan Eissing <st...@greenbytes.de>.
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 <ch...@wanadoo.fr>:
>
>
>
> 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).
>>
>> Sooooo... anyone opposed to a T&R 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&R 2.4.23 tomorrow (Thurs) ??
Posted by Marion & Christophe JAILLET <ch...@wanadoo.fr>.
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).
>
> Sooooo... anyone opposed to a T&R 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&R 2.4.23 tomorrow (Thurs) ??
Posted by Stefan Eissing <st...@greenbytes.de>.
+1
(Unless the mod_proxy connection cleanup improvements slip in there, then I'd like to test this more).
> Am 28.06.2016 um 13:41 schrieb Jim Jagielski <ji...@jaguNET.com>:
>
> I am thinking of a T&R today... Anyone see or know of any
> reasons for not doing so? Or anyone wish to make uninformed
> or incorrect assumptions (with veiled threats) against a
> T&R for no valid reason other than it's an opportunity to
> do so?
>
>> On Jun 22, 2016, at 4:05 PM, Jim Jagielski <ji...@jaguNET.com> 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).
>>
>> Sooooo... anyone opposed to a T&R tomorrow in the hopes
>> of getting this out to people by the start of next week??
>
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Jun 28, 2016 at 6:41 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> I am thinking of a T&R today... Anyone see or know of any
> reasons for not doing so?
As far as Jens and I have been able to determine, there are no remaining
edge
cases once the critical patch in STATUS is applied to undo the erasure of
the
--enable-proxy-balancer=shared status, and to inherit that parent module's
status as the default for the lbmethods. Still had an open question of
whether
there is any consumer of lbmethods such that they should still be built
even
when mod_proxy_balancer is not enabled?
The other is nice-to-have but not so critical. The regression appears to be
resolved once that backport is applied.
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/28/2016 04:15 PM, William A Rowe Jr wrote:
> On Tue, Jun 28, 2016 at 8:46 AM, William A Rowe Jr <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
>
>
> I suppose this would have been the more accurate toggle, in the first place?
> Any reason we would build lbmethods without balancer?
>
> enable_lbmethod_byrequests=$enable_proxy_balancer
> enable_lbmethod_bytraffic=$enable_proxy_balancer
> enable_lbmethod_bybusyness=$enable_proxy_balancer
> enable_lbmethod_heartbeat=$enable_proxy_balancer
>
> Patch committed to trunk, r1750507, to depend-on proxy_balancer
> and to use it's build flag as our default (static/shared or 'yes')
>
>
> Also, in one case...
>
> APACHE_MODULE(lbmethod_heartbeat, Apache proxy Load balancing from Heartbeats, , , $enable_proxy_balancer, , proxy_balancer)
>
> Wouldn't this depend on both [proxy_balancer,heartmonitor] (using the
> new multiple-dependency syntax)?
>
>
Sounds sensible.
Regards
R�diger
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Jun 28, 2016 at 10:20 AM, Yann Ylavic <yl...@gmail.com> wrote:
> On Tue, Jun 28, 2016 at 5:12 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> > On Tue, Jun 28, 2016 at 10:10 AM, Yann Ylavic <yl...@gmail.com>
> wrote:
> >>
> >> On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic <yl...@gmail.com>
> wrote:
> >> > On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic <yl...@gmail.com>
> >> > wrote:
> >> >>
> >> >> I don't see where lbmethod_heartbeat depends on mod_heartmonitor in
> >> >> the code, but it seems to require mod_slotmem_shm though.
> >> >
> >> > My bad, mod_heartmonitor is required too.
> >>
> >> Actually lbmethod_heartbeat seems to fall back to using the filesystem
> >> when mod_heartmonitor is missing, so it's not really a (configure)
> >> requirement IMHO.
> >
> >
> > Thanks for the validation. Some updates to the lbmethod_heartbeat module
> > docs might be helpful.
>
> Regarding dependency on mod_slotmem(_shm), is it a requirement of
> mod_proxy_balancer already (it should)?
>
While I agree, taking the enable_proxy_balancer (yes|shared|static) value as
the default will cause the APACHE_MODULE macro to evaluate building every
lbmethod dependency as required (and fail if not available), as if they were
explicitly enabled. I'd like to avoid repeating the logic we used in
config.m4
from mod_proxy, but adding another dependency could cause configure to
bomb when a module is disabled.
I think we can add more dependencies this after 2.4.23 is tagged.
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Jun 28, 2016 at 5:12 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Tue, Jun 28, 2016 at 10:10 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>
>> On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic <yl...@gmail.com> wrote:
>> > On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic <yl...@gmail.com>
>> > wrote:
>> >>
>> >> I don't see where lbmethod_heartbeat depends on mod_heartmonitor in
>> >> the code, but it seems to require mod_slotmem_shm though.
>> >
>> > My bad, mod_heartmonitor is required too.
>>
>> Actually lbmethod_heartbeat seems to fall back to using the filesystem
>> when mod_heartmonitor is missing, so it's not really a (configure)
>> requirement IMHO.
>
>
> Thanks for the validation. Some updates to the lbmethod_heartbeat module
> docs might be helpful.
Regarding dependency on mod_slotmem(_shm), is it a requirement of
mod_proxy_balancer already (it should)?
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Jun 28, 2016 at 10:10 AM, Yann Ylavic <yl...@gmail.com> wrote:
> On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic <yl...@gmail.com> wrote:
> > On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic <yl...@gmail.com>
> wrote:
> >>
> >> I don't see where lbmethod_heartbeat depends on mod_heartmonitor in
> >> the code, but it seems to require mod_slotmem_shm though.
> >
> > My bad, mod_heartmonitor is required too.
>
> Actually lbmethod_heartbeat seems to fall back to using the filesystem
> when mod_heartmonitor is missing, so it's not really a (configure)
> requirement IMHO.
>
Thanks for the validation. Some updates to the lbmethod_heartbeat module
docs might be helpful.
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>
>> I don't see where lbmethod_heartbeat depends on mod_heartmonitor in
>> the code, but it seems to require mod_slotmem_shm though.
>
> My bad, mod_heartmonitor is required too.
Actually lbmethod_heartbeat seems to fall back to using the filesystem
when mod_heartmonitor is missing, so it's not really a (configure)
requirement IMHO.
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> I don't see where lbmethod_heartbeat depends on mod_heartmonitor in
> the code, but it seems to require mod_slotmem_shm though.
My bad, mod_heartmonitor is required too.
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Jun 28, 2016 at 4:15 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Tue, Jun 28, 2016 at 8:46 AM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>>
>>
>> I suppose this would have been the more accurate toggle, in the first
>> place?
>> Any reason we would build lbmethods without balancer?
>>
>> enable_lbmethod_byrequests=$enable_proxy_balancer
>> enable_lbmethod_bytraffic=$enable_proxy_balancer
>> enable_lbmethod_bybusyness=$enable_proxy_balancer
>> enable_lbmethod_heartbeat=$enable_proxy_balancer
>>
>> Patch committed to trunk, r1750507, to depend-on proxy_balancer
>> and to use it's build flag as our default (static/shared or 'yes')
>
>
> Also, in one case...
>
> APACHE_MODULE(lbmethod_heartbeat, Apache proxy Load balancing from
> Heartbeats, , , $enable_proxy_balancer, , proxy_balancer)
>
> Wouldn't this depend on both [proxy_balancer,heartmonitor] (using the
> new multiple-dependency syntax)?
I don't see where lbmethod_heartbeat depends on mod_heartmonitor in
the code, but it seems to require mod_slotmem_shm though.
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Jun 28, 2016 at 8:46 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
>
> I suppose this would have been the more accurate toggle, in the first
> place?
> Any reason we would build lbmethods without balancer?
>
> enable_lbmethod_byrequests=$enable_proxy_balancer
> enable_lbmethod_bytraffic=$enable_proxy_balancer
> enable_lbmethod_bybusyness=$enable_proxy_balancer
> enable_lbmethod_heartbeat=$enable_proxy_balancer
>
> Patch committed to trunk, r1750507, to depend-on proxy_balancer
> and to use it's build flag as our default (static/shared or 'yes')
>
Also, in one case...
APACHE_MODULE(lbmethod_heartbeat, Apache proxy Load balancing from
Heartbeats, , , $enable_proxy_balancer, , proxy_balancer)
Wouldn't this depend on both [proxy_balancer,heartmonitor] (using the
new multiple-dependency syntax)?
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Jun 28, 2016 at 6:41 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> I am thinking of a T&R today... Anyone see or know of any
> reasons for not doing so?
>
Of the changes we just backported, there is one side effect, Jens wasn't
imagining things. From this query...
grep -E "^[ \t]*enable_.*=" configure | grep -v -E
"(yes|no|shared|static|module_default)"
I was looking for non-standard things, found some additional expected
cases, e.g.
enable_dumpio=most
enable_echo=maybe-all
... so these are valid (did not see 'all', or 'few', fwiw).
Discovered these explicit overrides, only one group concerns me...
enable_dtrace=$enableval
enable_so=$ac_cv_define_APR_HAS_DSO
enable_so=$enable_so
enable_session_cookie=$session_mods_enable
enable_session_crypto=$session_mods_enable_crypto
enable_session_dbd=$session_mods_enable
enable_lbmethod_byrequests=$proxy_mods_enable
enable_lbmethod_bytraffic=$proxy_mods_enable
enable_lbmethod_bybusyness=$proxy_mods_enable
enable_lbmethod_heartbeat=$proxy_mods_enable
enable_unixd=$unixd_mods_enable
enable_dav=$dav_enable
enable_dav_fs=$dav_fs_enable
but we've knocked out proxy_mods_enable as a switch (it only exists
now in co
I suppose this would have been the more accurate toggle, in the first place?
Any reason we would build lbmethods without balancer?
enable_lbmethod_byrequests=$enable_proxy_balancer
enable_lbmethod_bytraffic=$enable_proxy_balancer
enable_lbmethod_bybusyness=$enable_proxy_balancer
enable_lbmethod_heartbeat=$enable_proxy_balancer
Patch committed to trunk, r1750507, to depend-on proxy_balancer
and to use it's build flag as our default (static/shared or 'yes')
Re: T&R 2.4.23 tomorrow (Thurs) ??
Posted by Jim Jagielski <ji...@jaguNET.com>.
I am thinking of a T&R today... Anyone see or know of any
reasons for not doing so? Or anyone wish to make uninformed
or incorrect assumptions (with veiled threats) against a
T&R for no valid reason other than it's an opportunity to
do so?
> On Jun 22, 2016, at 4:05 PM, Jim Jagielski <ji...@jaguNET.com> 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).
>
> Sooooo... anyone opposed to a T&R tomorrow in the hopes
> of getting this out to people by the start of next week??
T&R 2.4.23 tomorrow (Thurs) ??
Posted by Jim Jagielski <ji...@jaguNET.com>.
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).
Sooooo... anyone opposed to a T&R tomorrow in the hopes
of getting this out to people by the start of next week??