Re: T 2.4.23 tomorrow (Thurs) ??

[William A Rowe Jr]

On Tue, Jun 28, 2016 at 6:41 AM, Jim Jagielski  wrote:

> I am thinking of a T 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 2.4.23 tomorrow (Thurs) ??

[William A Rowe Jr]

On Tue, Jun 28, 2016 at 10:20 AM, Yann Ylavic  wrote:

> On Tue, Jun 28, 2016 at 5:12 PM, William A Rowe Jr 
> wrote:
> > On Tue, Jun 28, 2016 at 10:10 AM, Yann Ylavic 
> wrote:
> >>
> >> On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic 
> wrote:
> >> > On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic 
> >> > 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 2.4.23 tomorrow (Thurs) ??

[Yann Ylavic]

On Tue, Jun 28, 2016 at 5:12 PM, William A Rowe Jr  wrote:
> On Tue, Jun 28, 2016 at 10:10 AM, Yann Ylavic  wrote:
>>
>> On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic  wrote:
>> > On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic 
>> > 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 2.4.23 tomorrow (Thurs) ??

[William A Rowe Jr]

On Tue, Jun 28, 2016 at 10:10 AM, Yann Ylavic  wrote:

> On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic  wrote:
> > On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic 
> 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 2.4.23 tomorrow (Thurs) ??

[Yann Ylavic]

On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic  wrote:
> On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic  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 2.4.23 tomorrow (Thurs) ??

[Yann Ylavic]

On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic  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 2.4.23 tomorrow (Thurs) ??

[Yann Ylavic]

On Tue, Jun 28, 2016 at 4:15 PM, William A Rowe Jr  wrote:
> On Tue, Jun 28, 2016 at 8:46 AM, William A Rowe Jr 
> 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 2.4.23 tomorrow (Thurs) ??

[Ruediger Pluem]

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  > 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 2.4.23 tomorrow (Thurs) ??

[William A Rowe Jr]

On Tue, Jun 28, 2016 at 8:46 AM, William A Rowe Jr 
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 2.4.23 tomorrow (Thurs) ??

[William A Rowe Jr]

On Tue, Jun 28, 2016 at 6:41 AM, Jim Jagielski  wrote:

> I am thinking of a T 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 2.4.23 tomorrow (Thurs) ??

[Stefan Eissing]

+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 :
> 
> I am thinking of a T 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 for no valid reason other than it's an opportunity to
> do so?
> 
>> On Jun 22, 2016, at 4:05 PM, 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??
> 

Re: T 2.4.23 tomorrow (Thurs) ??

[Jim Jagielski]

I am thinking of a T 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 for no valid reason other than it's an opportunity to
do so?

> On Jun 22, 2016, at 4:05 PM, 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??

Re: T 2.4.23 tomorrow (Thurs) ??

[Jens Schleusener]

On Mon, 27 Jun 2016, William A Rowe Jr wrote:


On Mon, Jun 27, 2016 at 6:00 AM, Jens Schleusener 
 wrote:
  On Fri, 24 Jun 2016, William A Rowe Jr wrote:

On Thu, Jun 23, 2016 at 10:38 AM, Jens Schleusener 

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 2.4.23 tomorrow (Thurs) ??

[William A Rowe Jr]

On Mon, Jun 27, 2016 at 6:00 AM, Jens Schleusener <
jens.schleuse...@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.schleuse...@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 2.4.23 tomorrow (Thurs) ??

[Jens Schleusener]

On Fri, 24 Jun 2016, William A Rowe Jr wrote:


On Thu, Jun 23, 2016 at 10:38 AM, Jens Schleusener 
 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 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: 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

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: 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

T 2.4.23 tomorrow (Thurs) ??

[Jim Jagielski]

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??