Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread Steffen Land

HTTPd 2.4.45

Warning C4267   modules\http\http_filters.c 284 '+=': conversion from 
'size_t' to 'apr_int32_t', possible loss of data
Warning C4267   modules\http\http_filters.c 473 '=': conversion from 
'size_t' to 'int', possible loss of data
Warning C4267   modules\http\http_filters.c 980 'initializing': 
conversion from 'size_t' to 'int', possible loss of data
Warning C4267   modules\http\http_filters.c 1850'return': conversion 
from 'size_t' to 'long', possible loss of data
Warning C4267   modules\http\http_protocol.c942 'initializing': 
conversion from 'size_t' to 'int', possible loss of data
Warning C4267   modules\http\http_protocol.c1468'initializing': 
conversion from 'size_t' to 'int', possible loss of data
Warning C4312   os\win32\util_win32.c   100 'type cast': conversion from 
'int' to 'char *' of greater size
Warning C4267   server\config.c 608 'initializing': conversion from 
'size_t' to 'int', possible loss of data
Warning C4267   server\config.c 609 'initializing': conversion from 
'size_t' to 'int', possible loss of data
Warning C4311   server\config.c 1474'type cast': pointer truncation from 
'void *' to 'long'
Warning C4311   server\config.c 1487'type cast': pointer truncation from 
'void *' to 'long'
Warning C4311   server\config.c 1505'type cast': pointer truncation from 
'void *' to 'long'
Warning C4311   server\config.c 1516'type cast': pointer truncation from 
'void *' to 'long'
Warning C4311   server\config.c 1527'type cast': pointer truncation from 
'void *' to 'long'
Warning C4311   server\config.c 1544'type cast': pointer truncation from 
'void *' to 'long'
Warning C4018   server\config.c 1745'>=': signed/unsigned mismatch
Warning C4311   server\core.c   2999'type cast': pointer truncation from 
'void *' to 'long'
Warning C4244   server\core.c   4043'return': conversion from '__int64' to 
'int', possible loss of data
Warning C4244   server\core.c   5277'=': conversion from 'unsigned long' to 
'apr_uint16_t', possible loss of data
Warning C4018   server\core_filters.c   264 '<': signed/unsigned mismatch
Warning C4018   server\core_filters.c   270 '<': signed/unsigned mismatch
Warning C4018   server\core_filters.c   295 '<': signed/unsigned mismatch
Warning C4267   server\core_filters.c   821 'function': conversion from 
'size_t' to 'apr_int32_t', possible loss of data
Warning C4244   server\log.c590 'return': conversion from '__int64' to 
'int', possible loss of data
Warning C4267   server\log.c781 '+=': conversion from 'size_t' to 
'int', possible loss of data
Warning C4267   server\log.c1019'+=': conversion from 'size_t' to 
'int', possible loss of data
Warning C4267   server\log.c1069'+=': conversion from 'size_t' to 
'int', possible loss of data
Warning C4267   server\log.c1551'+=': conversion from 'size_t' to 
'int', possible loss of data
Warning C4311   server\mpm\winnt\child.c791 'type cast': pointer 
truncation from 'void *' to 'int'
Warning C4312   server\mpm\winnt\child.c1006'type cast': conversion 
from 'int' to 'void *' of greater size
Warning C4090   server\mpm\winnt\mpm_winnt.c364 'function': different 
'volatile' qualifiers
Warning C4090   server\mpm\winnt\mpm_winnt.c1089'function': different 
'volatile' qualifiers
Warning C4244   server\protocol.c   643 'return': conversion from 
'__int64' to 'int', possible loss of data
Warning C4244   server\protocol.c   2078'initializing': conversion from 
'__int64' to 'int', possible loss of data
Warning C4267   server\protocol.c   2135'return': conversion from 
'size_t' to 'int', possible loss of data
Warning C4267   server\request.c1468'=': conversion from 'size_t' 
to 'int', possible loss of data
Warning C4267   server\scoreboard.c 147 'return': conversion from 
'size_t' to 'int', possible loss of data
Warning C4267   server\util.c   401 'function': conversion from 'size_t' to 
'int', possible loss of data
Warning C4244   server\util.c   507 '=': conversion from '__int64' to 
'int', possible loss of data
Warning C4244   server\util.c   654 '=': conversion from '__int64' to 
'int', possible loss of data
Warning C4244   server\util.c   686 '=': conversion from '__int64' to 
'int', possible loss of data
Warning C4244   server\util.c   714 '=': conversion from '__int64' to 
'int', possible loss of data
Warning C4244   server\util.c   811 'function': conversion from '__int64' 
to 'int', possible loss of data
Warning C4244   server\util.c   821 'function': conversion from '__int64' 
to 'int', possible loss of data
Warning C4244   server\util.c   865 'function': conversion from '__int64' 
to 'int', possible loss of data
Warning C4244   server\util.c   875 'function': conversion from '__int64' 
to 'int', possible loss of data
Warning C4267   server\util.c   

Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread Christophe JAILLET



Le 29/07/2020 à 17:26, Daniel Ruggeri a écrit :

Hi, all;
    Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this
candidate tarball as 2.4.45:
[ ] +1: It's not just good, it's good enough!
[X] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha1: 98d470cee244a41ac933f44428ebf10149639a8c *httpd-2.4.45.tar.gz
sha256: 653b4f24eca6852e1b6248f6dc9a6674b647fdc4d1d4583f46bd8a6c8ee049ae
*httpd-2.4.45.tar.gz
sha512:
8b1e9c22371c75efd2466c69ed48782ddcecfe0a3ff143ca3f9cb720ea2aee56f5c323a9e3ae80cd5c44f1601b5894879af03b6b3729a8ca0555bb5193a1296a
*httpd-2.4.45.tar.gz

The SVN tag is '2.4.45' at r1880411.


+0 (before additional testing, likely this afternoon)


I've not tested yet, but looking at Steffen Land compilation error logs 
on Windows, I've been surprised by:


   Warning    C4003    modules\proxy\mod_proxy_fcgi.c    180 not enough 
arguments for function-like macro invocation 'APLOGNO'


In fact, in r1879525, r1877830 seems to be missing in what has been 
committed in 2.4.x.


I wouldn't say it is a show stopper, but I thought that we had a travis 
job for that.
Apparently, it is on trunk only (see r1879370 which is not backported, 
maybe on purpose)


CJ



Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread Graham Leggett
On 30 Jul 2020, at 11:16, Steffen Land  wrote:

> +1 on Windows.
> 
> I am in doubt for a -0 :
> 
> Still quite some (more) warnings, now 432, attached Win64 warnings with the 
> ones from APR-UTIL.
> 
> I think a goal is (must be) that we get warning free on all platforms, now it 
> looks bad on Windows.
> 
> I reported here a few times. APR is warning free, thanks to Yann.

Apr-util is a library from the APR project, not httpd, and so warnings from APR 
wouldn’t be relevant for an httpd release, or for the httpd project.

That said there is definite need for more Windows testing over at APR, if you 
or members of the Apachelounge community are in the position to contribute 
patches this will be very much appreciated.

Regards,
Graham
—



Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread jean-frederic clere

On 29/07/2020 17:26, Daniel Ruggeri wrote:

[X] +1: It's not just good, it's good enough!


Tested on fedora32 x86_64.

--
Cheers

Jean-Frederic


Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread Joe Orton
On Thu, Jul 30, 2020 at 11:55:09AM +0200, Christophe JAILLET wrote:
> I've not tested yet, but looking at Steffen Land compilation error logs on
> Windows, I've been surprised by:
> 
>    Warning    C4003    modules\proxy\mod_proxy_fcgi.c    180 not enough
> arguments for function-like macro invocation 'APLOGNO'
> 
> In fact, in r1879525, r1877830 seems to be missing in what has been
> committed in 2.4.x.
> 
> I wouldn't say it is a show stopper, but I thought that we had a travis job
> for that.

Good catch!  

Unfortunately the APLOGNO() check only runs for trunk because it uses 
docs/log-message-tags/* stuff which doesn't exist outside trunk.  That 
is itself deliberate, the data is only supposed to be maintained in one 
place.

I've updated the travis test in r1880453 to check for the missing 
argument case for non-trunk, will backport if that passes.

Regards, Joe



Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread Jim Jagielski



> On Jul 30, 2020, at 5:55 AM, Christophe JAILLET 
>  wrote:
> 
> I wouldn't say it is a show stopper, but I thought that we had a travis job 
> for that.
> Apparently, it is on trunk only (see r1879370 which is not backported, maybe 
> on purpose)
> 

I agree that it's not a show-stopper but it is something that seems easy to fix 
and, considering that (1) we want to release the best possible version as we 
can and (2) there is quite a bit of time between releases, I wouldn't be 
opposed if the RM decided to skip 2.4.45 and go w/ 2.4.46.



Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread Steffen
Thanks for you reply Graham,

Indeed  apt-util warnings not relevant here.

You said below :  ... more Windows testing over at APR .  For HTTPD enough 
?   We test HTTPD and APR  quite intensive with a few members, even on 
production level on different configurations.  The code is quite good, so we 
find not that much. 

I hope you have also concerns about Windows warnings.  There is a reason that 
ms gives code a warning, a sign that code can be better. 

We had some Windows coders in the community, sadly they left. I shall look 
around again. 

Ps.  We test also Trunk, issues found I let it know (like in May) and post  
warnings here.  After some commits we test. It is not automated like Travis. 


> Op 30 jul. 2020 om 11:56 heeft Graham Leggett  het volgende 
> geschreven:
> 
> On 30 Jul 2020, at 11:16, Steffen Land  wrote:
> 
>> +1 on Windows.
>> 
>> I am in doubt for a -0 :
>> 
>> Still quite some (more) warnings, now 432, attached Win64 warnings with the 
>> ones from APR-UTIL.
>> 
>> I think a goal is (must be) that we get warning free on all platforms, now 
>> it looks bad on Windows.
>> 
>> I reported here a few times. APR is warning free, thanks to Yann.
> 
> Apr-util is a library from the APR project, not httpd, and so warnings from 
> APR wouldn’t be relevant for an httpd release, or for the httpd project.
> 
> That said there is definite need for more Windows testing over at APR, if you 
> or members of the Apachelounge community are in the position to contribute 
> patches this will be very much appreciated.
> 
> Regards,
> Graham
> —
> 


Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread Steffen Land



aplogno warnings on 2.4.40 was a reason to skip.

www.apachelounge.com/viewtopic.php?t=8329&highlight=aplogno



On Thursday 30/07/2020 at 17:10, Jim Jagielski  wrote:





On Jul 30, 2020, at 5:55 AM, Christophe JAILLET 
 wrote:


I wouldn't say it is a show stopper, but I thought that we had a 
travis job for that.
Apparently, it is on trunk only (see r1879370 which is not backported, 
maybe on purpose)




I agree that it's not a show-stopper but it is something that seems 
easy to fix and, considering that (1) we want to release the best 
possible version as we can and (2) there is quite a bit of time 
between releases, I wouldn't be opposed if the RM decided to skip 
2.4.45 and go w/ 2.4.46.






Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread Eric Covener
On Wed, Jul 29, 2020 at 11:26 AM Daniel Ruggeri  wrote:
>
> Hi, all;
>Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.45:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: 98d470cee244a41ac933f44428ebf10149639a8c *httpd-2.4.45.tar.gz
> sha256: 653b4f24eca6852e1b6248f6dc9a6674b647fdc4d1d4583f46bd8a6c8ee049ae
> *httpd-2.4.45.tar.gz
> sha512:
> 8b1e9c22371c75efd2466c69ed48782ddcecfe0a3ff143ca3f9cb720ea2aee56f5c323a9e3ae80cd5c44f1601b5894879af03b6b3729a8ca0555bb5193a1296a
> *httpd-2.4.45.tar.gz
>
> The SVN tag is '2.4.45' at r1880411.
>
> --

+1 based on 2.4.44 testing on AIX/PPC64


Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread William A Rowe Jr
On Thu, Jul 30, 2020 at 10:10 AM Jim Jagielski  wrote:

>
> > On Jul 30, 2020, at 5:55 AM, Christophe JAILLET <
> christophe.jail...@wanadoo.fr> wrote:
> >
> > I wouldn't say it is a show stopper, but I thought that we had a travis
> job for that.
> > Apparently, it is on trunk only (see r1879370 which is not backported,
> maybe on purpose)
>
> I agree that it's not a show-stopper but it is something that seems easy
> to fix and, considering that (1) we want to release the best possible
> version as we can and (2) there is quite a bit of time between releases, I
> wouldn't be opposed if the RM decided to skip 2.4.45 and go w/ 2.4.46.
>

Agreed. And Steffen points out there is precedence.


Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread Daniel Ruggeri

On 7/30/2020 2:41 PM, William A Rowe Jr wrote:
> On Thu, Jul 30, 2020 at 10:10 AM Jim Jagielski  > wrote:
>
>
> > On Jul 30, 2020, at 5:55 AM, Christophe JAILLET
>  > wrote:
> >
> > I wouldn't say it is a show stopper, but I thought that we had a
> travis job for that.
> > Apparently, it is on trunk only (see r1879370 which is not
> backported, maybe on purpose) 
>
> I agree that it's not a show-stopper but it is something that
> seems easy to fix and, considering that (1) we want to release the
> best possible version as we can and (2) there is quite a bit of
> time between releases, I wouldn't be opposed if the RM decided to
> skip 2.4.45 and go w/ 2.4.46.
>
>  
> Agreed. And Steffen points out there is precedence.
>

Aye - and I'd hate to appear inconsistent :-)

Version numbers are cheap - I'll re-roll when we have confirmation all
is good in the 2.4 branch.

-- 
Daniel Ruggeri



[RESULT] [VOTE] Release httpd-2.4.45

2020-07-30 Thread Daniel Ruggeri
Hi, all;
   I thank everyone for their testing and quick feedback. While we had
enough votes and positive feedback, we have some easily fixable warnings
which have precedence for holding up a release.

   To that end, I will close this vote and declare 2.4.45 dead on the vine.

   I will roll 2.4.46 when we are all buttoned up with the warnings.

-- 
Daniel Ruggeri

On 7/29/2020 10:26 AM, Daniel Ruggeri wrote:
> Hi, all;
>    Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.45:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: 98d470cee244a41ac933f44428ebf10149639a8c *httpd-2.4.45.tar.gz
> sha256: 653b4f24eca6852e1b6248f6dc9a6674b647fdc4d1d4583f46bd8a6c8ee049ae
> *httpd-2.4.45.tar.gz
> sha512:
> 8b1e9c22371c75efd2466c69ed48782ddcecfe0a3ff143ca3f9cb720ea2aee56f5c323a9e3ae80cd5c44f1601b5894879af03b6b3729a8ca0555bb5193a1296a
> *httpd-2.4.45.tar.gz
>
> The SVN tag is '2.4.45' at r1880411.
>



Re: [VOTE] Release httpd-2.4.45

2020-07-30 Thread William A Rowe Jr
On Thu, Jul 30, 2020 at 3:19 PM Daniel Ruggeri  wrote:

>
> On 7/30/2020 2:41 PM, William A Rowe Jr wrote:
>
> On Thu, Jul 30, 2020 at 10:10 AM Jim Jagielski  wrote:
>
>>
>> > On Jul 30, 2020, at 5:55 AM, Christophe JAILLET <
>> christophe.jail...@wanadoo.fr> wrote:
>> >
>> > I wouldn't say it is a show stopper, but I thought that we had a travis
>> job for that.
>> > Apparently, it is on trunk only (see r1879370 which is not backported,
>> maybe on purpose)
>>
>> I agree that it's not a show-stopper but it is something that seems easy
>> to fix and, considering that (1) we want to release the best possible
>> version as we can and (2) there is quite a bit of time between releases, I
>> wouldn't be opposed if the RM decided to skip 2.4.45 and go w/ 2.4.46.
>>
>
> Agreed. And Steffen points out there is precedence.
>
> Aye - and I'd hate to appear inconsistent :-)
>
> Version numbers are cheap - I'll re-roll when we have confirmation all is
> good in the 2.4 branch.
>

Released on Jun 29th, we do not compile against lua 5.4.0. A possible fix
is described here;

https://github.com/apache/httpd/pull/133

If there is anyone very savvy with lua coding, it would be good to identify
the best approach for compatibility. (It may not be realistic to solve this
in 2.4.46.)