You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by DR...@primary.net on 2018/02/19 14:54:35 UTC
[VOTE] Release httpd-2.4.30
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.30:
[ ] +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.
--
Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.30
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Feb 19, 2018, at 10:47 AM, Graham Leggett <mi...@sharp.fm> wrote:
>
> On 19 Feb 2018, at 5:45 PM, Jim Jagielski <jim@jaguNET.com <ma...@jaguNET.com>> wrote:
>
>> Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
>> in ap_release.h is set to 0
>>
>> How does your release process work? What we've always
>> done is make the req changes to the branch and then copy
>> from that branch to the tag. So the tag itself must refer to
>> a specific SVN number on the http-2.4 branch but I'm
>> not seeing where that is done.
>
> What I've done in the past is follow the commits for previous releases, using them as a template for the steps to take.
>
+1
Re: [VOTE] Release httpd-2.4.30
Posted by Graham Leggett <mi...@sharp.fm>.
On 19 Feb 2018, at 5:45 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
> in ap_release.h is set to 0
>
> How does your release process work? What we've always
> done is make the req changes to the branch and then copy
> from that branch to the tag. So the tag itself must refer to
> a specific SVN number on the http-2.4 branch but I'm
> not seeing where that is done.
What I've done in the past is follow the commits for previous releases, using them as a template for the steps to take.
Regards,
Graham
—
Re: [VOTE] Release httpd-2.4.30
Posted by Jim Jagielski <ji...@jaguNET.com>.
If we could see the tooling it might be easier to vet it.
> On Feb 20, 2018, at 8:39 AM, DRuggeri@primary.net wrote:
>
>> -----Original Message-----
>> From: Jim Jagielski [mailto:jim@jaguNET.com]
>> Sent: Tuesday, February 20, 2018 6:10 AM
>> To: dev@httpd.apache.org
>> Subject: Re: [VOTE] Release httpd-2.4.30
>>
>> Another thing that helps is providing some heads-up
>> that a T&R will actually be happening... Yeah, you
>> had noted the you were going to T&R on Monday
>> (in the "T&R of 2.4.30 Proposal" thread) but sending
>> out a quick "I plan on doing this in X hours" notice
>> allows for some possible last-minute items to pop
>> up.
>>
>> Just a suggestion.
>
> Sure, I can do that.
>
>
>>
>>> On Feb 19, 2018, at 9:44 PM, Jim Jagielski <jim@jaguNET.com <ma...@jaguNET.com>> wrote:
>>>
>>> I would suggest using the scripts from
>>>
>>> https://svn.apache.org/repos/asf/httpd/site/trunk/tools <https://svn.apache.org/repos/asf/httpd/site/trunk/tools>
>>>
>>> for as much of the work as possible since they have been used
>>> and vetted for several years.
>
> Indeed, I did for everything except the tagging (which is why I created a script to do it). I also created one to push to dev/release dist repos for convenience. As mentioned, the goal is to automate the process as much as possible so with the gap in existing tooling, I went ahead and filled it. I guess I just misinterpreted the instructions and didn’t think to review SVN history of the previous releases as Joe mentioned.
>
> Aside from this omission, are we otherwise in good shape?
>
>
>>>
>>>> On Feb 19, 2018, at 7:28 PM, DRuggeri@primary.net wrote:
>>>>
>>>> Ah, I see. I created a script that does the tagging based on the directions
>> here.
>>>> http://httpd.apache.org/dev/release.html
>>>>
>>>> It was unclear in those instructions that one should commit the change to
>> AP_SERVER_DEVBUILD_BOOLEAN.
>>>>
>>>> Instead I did the following:
>>>> ...
>>>> # Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
>>>> perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g'
>> include/ap_release.h
>>>>
>>>> # Create an official X.Y.Z tag based on the candidate tree.
>>>> svn copy "$src_dir" "$tags_dir/$version"
>>>>
>>>> # Revert the change to include/ap_release.h setting
>> AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump
>> AP_SERVER_PATCHLEVEL_NUMBER
>>>> perl -pi -e '
>>>> s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;
>>>>
>>>> if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
>>>> $new = $2 + 1;
>>>> $_ = "${1}${new}\n";
>>>> }
>>>> ' include/ap_release.h
>>>> ...
>>>>
>>>> This begets a tarball that has the Boolean set to 0, but no
>> commit/revert/bump (instead just an apparent bump):
>>>>
>> http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.
>> h?view=markup#l47
>>>>
>>>> It makes sense that the tag comes from a specific commit where the
>> variable was flipped... Should I adjust the script and retry?
>>>>
>>>> --
>>>> Daniel Ruggeri
>>>>
>>>> From: Jim Jagielski [mailto:jim@jaguNET.com]
>>>> Sent: Monday, February 19, 2018 9:46 AM
>>>> To: dev@httpd.apache.org
>>>> Subject: Re: [VOTE] Release httpd-2.4.30
>>>>
>>>> Hmmm... I'm not seeing the patch where
>> AP_SERVER_DEVBUILD_BOOLEAN
>>>> in ap_release.h is set to 0
>>>>
>>>> How does your release process work? What we've always
>>>> done is make the req changes to the branch and then copy
>>>> from that branch to the tag. So the tag itself must refer to
>>>> a specific SVN number on the http-2.4 branch but I'm
>>>> not seeing where that is done.
>>>>
>>>>
>>>> On Feb 19, 2018, at 9:54 AM, mailto:DRuggeri@primary.net 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.30:
>>>>
>>>> [ ] +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.
>>>> --
>>>> Daniel Ruggeri
>>>>
>>>>
>
> --
> Daniel Ruggeri
RE: [VOTE] Release httpd-2.4.30
Posted by DR...@primary.net.
> -----Original Message-----
> From: Jim Jagielski [mailto:jim@jaguNET.com]
> Sent: Tuesday, February 20, 2018 6:10 AM
> To: dev@httpd.apache.org
> Subject: Re: [VOTE] Release httpd-2.4.30
>
> Another thing that helps is providing some heads-up
> that a T&R will actually be happening... Yeah, you
> had noted the you were going to T&R on Monday
> (in the "T&R of 2.4.30 Proposal" thread) but sending
> out a quick "I plan on doing this in X hours" notice
> allows for some possible last-minute items to pop
> up.
>
> Just a suggestion.
Sure, I can do that.
>
> > On Feb 19, 2018, at 9:44 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> >
> > I would suggest using the scripts from
> >
> > https://svn.apache.org/repos/asf/httpd/site/trunk/tools
> >
> > for as much of the work as possible since they have been used
> > and vetted for several years.
Indeed, I did for everything except the tagging (which is why I created a script to do it). I also created one to push to dev/release dist repos for convenience. As mentioned, the goal is to automate the process as much as possible so with the gap in existing tooling, I went ahead and filled it. I guess I just misinterpreted the instructions and didn’t think to review SVN history of the previous releases as Joe mentioned.
Aside from this omission, are we otherwise in good shape?
> >
> >> On Feb 19, 2018, at 7:28 PM, DRuggeri@primary.net wrote:
> >>
> >> Ah, I see. I created a script that does the tagging based on the directions
> here.
> >> http://httpd.apache.org/dev/release.html
> >>
> >> It was unclear in those instructions that one should commit the change to
> AP_SERVER_DEVBUILD_BOOLEAN.
> >>
> >> Instead I did the following:
> >> ...
> >> # Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
> >> perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g'
> include/ap_release.h
> >>
> >> # Create an official X.Y.Z tag based on the candidate tree.
> >> svn copy "$src_dir" "$tags_dir/$version"
> >>
> >> # Revert the change to include/ap_release.h setting
> AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump
> AP_SERVER_PATCHLEVEL_NUMBER
> >> perl -pi -e '
> >> s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;
> >>
> >> if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
> >> $new = $2 + 1;
> >> $_ = "${1}${new}\n";
> >> }
> >> ' include/ap_release.h
> >> ...
> >>
> >> This begets a tarball that has the Boolean set to 0, but no
> commit/revert/bump (instead just an apparent bump):
> >>
> http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.
> h?view=markup#l47
> >>
> >> It makes sense that the tag comes from a specific commit where the
> variable was flipped... Should I adjust the script and retry?
> >>
> >> --
> >> Daniel Ruggeri
> >>
> >> From: Jim Jagielski [mailto:jim@jaguNET.com]
> >> Sent: Monday, February 19, 2018 9:46 AM
> >> To: dev@httpd.apache.org
> >> Subject: Re: [VOTE] Release httpd-2.4.30
> >>
> >> Hmmm... I'm not seeing the patch where
> AP_SERVER_DEVBUILD_BOOLEAN
> >> in ap_release.h is set to 0
> >>
> >> How does your release process work? What we've always
> >> done is make the req changes to the branch and then copy
> >> from that branch to the tag. So the tag itself must refer to
> >> a specific SVN number on the http-2.4 branch but I'm
> >> not seeing where that is done.
> >>
> >>
> >> On Feb 19, 2018, at 9:54 AM, mailto:DRuggeri@primary.net 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.30:
> >>
> >> [ ] +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.
> >> --
> >> Daniel Ruggeri
> >>
> >>
--
Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.30
Posted by Jim Jagielski <ji...@jaguNET.com>.
Another thing that helps is providing some heads-up
that a T&R will actually be happening... Yeah, you
had noted the you were going to T&R on Monday
(in the "T&R of 2.4.30 Proposal" thread) but sending
out a quick "I plan on doing this in X hours" notice
allows for some possible last-minute items to pop
up.
Just a suggestion.
> On Feb 19, 2018, at 9:44 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> I would suggest using the scripts from
>
> https://svn.apache.org/repos/asf/httpd/site/trunk/tools
>
> for as much of the work as possible since they have been used
> and vetted for several years.
>
>> On Feb 19, 2018, at 7:28 PM, DRuggeri@primary.net wrote:
>>
>> Ah, I see. I created a script that does the tagging based on the directions here.
>> http://httpd.apache.org/dev/release.html
>>
>> It was unclear in those instructions that one should commit the change to AP_SERVER_DEVBUILD_BOOLEAN.
>>
>> Instead I did the following:
>> ...
>> # Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
>> perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g' include/ap_release.h
>>
>> # Create an official X.Y.Z tag based on the candidate tree.
>> svn copy "$src_dir" "$tags_dir/$version"
>>
>> # Revert the change to include/ap_release.h setting AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump AP_SERVER_PATCHLEVEL_NUMBER
>> perl -pi -e '
>> s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;
>>
>> if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
>> $new = $2 + 1;
>> $_ = "${1}${new}\n";
>> }
>> ' include/ap_release.h
>> ...
>>
>> This begets a tarball that has the Boolean set to 0, but no commit/revert/bump (instead just an apparent bump):
>> http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.h?view=markup#l47
>>
>> It makes sense that the tag comes from a specific commit where the variable was flipped... Should I adjust the script and retry?
>>
>> --
>> Daniel Ruggeri
>>
>> From: Jim Jagielski [mailto:jim@jaguNET.com]
>> Sent: Monday, February 19, 2018 9:46 AM
>> To: dev@httpd.apache.org
>> Subject: Re: [VOTE] Release httpd-2.4.30
>>
>> Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
>> in ap_release.h is set to 0
>>
>> How does your release process work? What we've always
>> done is make the req changes to the branch and then copy
>> from that branch to the tag. So the tag itself must refer to
>> a specific SVN number on the http-2.4 branch but I'm
>> not seeing where that is done.
>>
>>
>> On Feb 19, 2018, at 9:54 AM, mailto:DRuggeri@primary.net 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.30:
>>
>> [ ] +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.
>> --
>> Daniel Ruggeri
>>
>>
>
Re: [VOTE] Release httpd-2.4.30
Posted by Jim Jagielski <ji...@jaguNET.com>.
I would suggest using the scripts from
https://svn.apache.org/repos/asf/httpd/site/trunk/tools <https://svn.apache.org/repos/asf/httpd/site/trunk/tools>
for as much of the work as possible since they have been used
and vetted for several years.
> On Feb 19, 2018, at 7:28 PM, DRuggeri@primary.net wrote:
>
> Ah, I see. I created a script that does the tagging based on the directions here.
> http://httpd.apache.org/dev/release.html
>
> It was unclear in those instructions that one should commit the change to AP_SERVER_DEVBUILD_BOOLEAN.
>
> Instead I did the following:
> ...
> # Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
> perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g' include/ap_release.h
>
> # Create an official X.Y.Z tag based on the candidate tree.
> svn copy "$src_dir" "$tags_dir/$version"
>
> # Revert the change to include/ap_release.h setting AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump AP_SERVER_PATCHLEVEL_NUMBER
> perl -pi -e '
> s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;
>
> if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
> $new = $2 + 1;
> $_ = "${1}${new}\n";
> }
> ' include/ap_release.h
> ...
>
> This begets a tarball that has the Boolean set to 0, but no commit/revert/bump (instead just an apparent bump):
> http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.h?view=markup#l47
>
> It makes sense that the tag comes from a specific commit where the variable was flipped... Should I adjust the script and retry?
>
> --
> Daniel Ruggeri
>
> From: Jim Jagielski [mailto:jim@jaguNET.com]
> Sent: Monday, February 19, 2018 9:46 AM
> To: dev@httpd.apache.org
> Subject: Re: [VOTE] Release httpd-2.4.30
>
> Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
> in ap_release.h is set to 0
>
> How does your release process work? What we've always
> done is make the req changes to the branch and then copy
> from that branch to the tag. So the tag itself must refer to
> a specific SVN number on the http-2.4 branch but I'm
> not seeing where that is done.
>
>
> On Feb 19, 2018, at 9:54 AM, mailto:DRuggeri@primary.net 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.30:
>
> [ ] +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.
> --
> Daniel Ruggeri
>
>
RE: [VOTE] Release httpd-2.4.30
Posted by DR...@primary.net.
Ah, I see. I created a script that does the tagging based on the directions here.
http://httpd.apache.org/dev/release.html
It was unclear in those instructions that one should commit the change to AP_SERVER_DEVBUILD_BOOLEAN.
Instead I did the following:
...
# Set AP_SERVER_DEVBUILD_BOOLEAN to 0 in include/ap_release.h.
perl -pi -e 's/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}0/g' include/ap_release.h
# Create an official X.Y.Z tag based on the candidate tree.
svn copy "$src_dir" "$tags_dir/$version"
# Revert the change to include/ap_release.h setting AP_SERVER_DEVBUILD_BOOLEAN back to 1, and bump AP_SERVER_PATCHLEVEL_NUMBER
perl -pi -e '
s/(#define\s+AP_SERVER_DEVBUILD_BOOLEAN\s+)\d/${1}1/g;
if(/(#define\s+AP_SERVER_PATCHLEVEL_NUMBER\s+)(\d+)$/){
$new = $2 + 1;
$_ = "${1}${new}\n";
}
' include/ap_release.h
...
This begets a tarball that has the Boolean set to 0, but no commit/revert/bump (instead just an apparent bump):
http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.30/include/ap_release.h?view=markup#l47
It makes sense that the tag comes from a specific commit where the variable was flipped... Should I adjust the script and retry?
--
Daniel Ruggeri
From: Jim Jagielski [mailto:jim@jaguNET.com]
Sent: Monday, February 19, 2018 9:46 AM
To: dev@httpd.apache.org
Subject: Re: [VOTE] Release httpd-2.4.30
Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
in ap_release.h is set to 0
How does your release process work? What we've always
done is make the req changes to the branch and then copy
from that branch to the tag. So the tag itself must refer to
a specific SVN number on the http-2.4 branch but I'm
not seeing where that is done.
On Feb 19, 2018, at 9:54 AM, mailto:DRuggeri@primary.net 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.30:
[ ] +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.
--
Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.30
Posted by Jim Jagielski <ji...@jaguNET.com>.
Hmmm... I'm not seeing the patch where AP_SERVER_DEVBUILD_BOOLEAN
in ap_release.h is set to 0
How does your release process work? What we've always
done is make the req changes to the branch and then copy
from that branch to the tag. So the tag itself must refer to
a specific SVN number on the http-2.4 branch but I'm
not seeing where that is done.
> On Feb 19, 2018, at 9:54 AM, DRuggeri@primary.net wrote:
>
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/ <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.30:
>
> [ ] +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.
> --
> Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.30
Posted by Jim Jagielski <ji...@jaguNET.com>.
It likely makes sense to CLOSE this vote with the
result that 2.4.30 is not being released...
> On Feb 19, 2018, at 9:54 AM, DRuggeri@primary.net wrote:
>
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/ <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.30:
>
> [ ] +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.
> --
> Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.30
Posted by Stefan Eissing <st...@greenbytes.de>.
Wow! Nice work!
> Am 21.02.2018 um 21:34 schrieb Rainer Jung <ra...@kippdata.de>:
>
> Am 19.02.2018 um 15:54 schrieb DRuggeri@primary.net:
>> 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.30:
>> [ ] +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.
>
> -1 to release due to the flaws found by others. But we should be good with 2.4.31. Please update APR/APU in the deps tarball.
>
> Detailed report:
>
> - Sigs and hashes OK
> - contents of tarballs identical
> - contents of tag and tarballs identical
> except for expected deltas
> - deps convenience tarball does not contain latest APR/APU 1.6.3/1.6.1
> -> please update
>
> Built on
>
> - Solaris 10 Sparc as 32 Bit Binaries
> - SLES 11+12 (64 Bits)
> - RHEL 6+7 (64 Bits)
>
> For all platforms built
>
> - with default (shared) and static modules
> - with module set reallyall
> - using --enable-load-all-modules
> - against "included" APR/APU from deps tarball,
> plus external APR/APU 1.6.3/1.6.1 and 1.5.2/1.5.4
>
> - using external libraries
> - expat 2.2.5
> - pcre 8.41
> - openssl 1.0.2n plus patches
> - lua 5.3.4 (compiled with LUA_COMPAT_MODULE)
> - distcache 1.5.1
> - libxml2 2.9.7
> - libnghttp2 1.30.0
> - brotli 1.0.2
> - curl 7.58.0
> - jansson 2.10
>
> - Tool chain:
> - platform gcc except on Solaris
> (gcc 7.3.0 Solaris 10, only older APR/APU 1.5.x compiled with older gcc 4.9.2)
> - CFLAGS: -O2 -g -Wall -fno-strict-aliasing
> - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
> -D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
> and -D_XPG6
>
> All 40 builds succeeded.
>
> - compiler warnings:
>
> - modules/core/mod_watchdog.c:436: warning: 'rv' may be used
> uninitialized in this function
> -> warning is correct but not critical (debug log);
> not a regression
>
> on RHEL 6 and SLES 11 due to older GCC versions:
>
> - modules/md/md_json.c:31: warning: expected [error|warning|ignored] after '#pragma GCC diagnostic'
>
> - modules/md/md_json.c:45: warning: expected [error|warning|ignored] after '#pragma GCC diagnostic'
>
> due to strange jansson dependency library header files:
>
> include/jansson.h:117:6: warning: 'json_decrefp' defined but not used [-Wunused-function]
> include/jansson.h:187:5: warning: 'json_object_set_nocheck' defined but not used [-Wunused-function]
> include/jansson.h:193:5: warning: 'json_object_iter_set' defined but not used [-Wunused-function]
> include/jansson.h:208:5: warning: 'json_array_set' defined but not used [-Wunused-function]
> include/jansson.h:220:5: warning: 'json_array_insert' defined but not used [-Wunused-function]
>
> and only on Solaris (gcc 7.3.0)
>
> - modules/ldap/util_ldap_cache_mgr.c:728:32: warning: format '%ld' expects argument of type 'long int', but argument 6 has type 'long long int' [-Wformat=]
>
> - modules/ldap/util_ldap_cache.c:111:20: warning: format '%ld' expects argument of type 'long int', but argument 8 has type 'long long int' [-Wformat=]
>
> - srclib/apr-util/xlate/xlate.c:120:38: warning: passing argument 2 of
> 'iconv' from incompatible pointer type
> [-Wincompatible-pointer-types]
>
> - srclib/apr-util/xlate/xlate.c:343:42: warning: passing argument 2 of
> 'iconv' from incompatible pointer type
> [-Wincompatible-pointer-types]
>
>
> Tested for
>
> - Solaris 10, SLES 11+12, RHEL 6+7
> - MPMs prefork, worker, event
> - default and static modules
> - log levels info, debug and trace8
> - module set reallyall (127 modules plus MPMs)
>
> The following test failures were seen:
>
> a Lots of tests in t/module/session.t fail always for static builds.
> Not a regression.
> For 2.4.28 the analysis was:
> The whole setup for the /sessiontest uri is missing in the generated
> t/conf/httpd.conf. This is due to it missing from the also generated
> filet/conf/apache_test_config.pm. I do not know yet, why it is missing
> there, but this seems to be a test framework problem.
>
> b Test 59 of t/modules/include.t only and always on
> Solaris.
> Not a regression
> Old analysis was:
> This is due to a bug in the test, which uses strftime()
> with a "%s" pattern that is not supported on Solaris.
> Until recently the server and the test client both returned
> verbatim "%s" and the test succeeded. After updating some
> Perl modules for the http2 tests, the perl client even
> on Solaris now supports "%s" in strftime and the test starts
> to fail. It seems we have to fix the test.
>
> c Various tests in t/apache/expr_string.t
> Not a regression.
> Test numbers : 6, 11, 14, 17, 20, 23, 26, 29
> Happens for 9 out of about 225 runs (8 times on RHEL6, once
> on Solaris).
> The failure is almost always on line 87, where the error_log contents
> are checked.
>
> d One single test run (RHEL 7) failed test 163 of t/ssl/proxy.t
> (line 131 of Apache-Test/lib/Apache/TestCommonPost.pm)
>
> e Only on Solaris and only with prefork proxy tests sometimes
> seem to hang until timeout.
> Not a regression
> Some test runs complete without
> Not observed for static builds. Only builds based on APR/APU 1.6.x
> seem to have the problem. First observed when testing 2.4.26.
> It seems processes die due to Solaris mutex deadlock detection
> for the accept mutex (false positive). Such processes get not
> replaced until we end up with only one prefork child, which of
> course can't serve proxy requests.
>
> All in all I don't see a critical problem during my tests.
>
> Regards,
>
> Rainer
Re: [VOTE] Release httpd-2.4.30
Posted by Rainer Jung <ra...@kippdata.de>.
Am 19.02.2018 um 15:54 schrieb DRuggeri@primary.net:
> 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.30:
>
> [ ] +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.
-1 to release due to the flaws found by others. But we should be good
with 2.4.31. Please update APR/APU in the deps tarball.
Detailed report:
- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
except for expected deltas
- deps convenience tarball does not contain latest APR/APU 1.6.3/1.6.1
-> please update
Built on
- Solaris 10 Sparc as 32 Bit Binaries
- SLES 11+12 (64 Bits)
- RHEL 6+7 (64 Bits)
For all platforms built
- with default (shared) and static modules
- with module set reallyall
- using --enable-load-all-modules
- against "included" APR/APU from deps tarball,
plus external APR/APU 1.6.3/1.6.1 and 1.5.2/1.5.4
- using external libraries
- expat 2.2.5
- pcre 8.41
- openssl 1.0.2n plus patches
- lua 5.3.4 (compiled with LUA_COMPAT_MODULE)
- distcache 1.5.1
- libxml2 2.9.7
- libnghttp2 1.30.0
- brotli 1.0.2
- curl 7.58.0
- jansson 2.10
- Tool chain:
- platform gcc except on Solaris
(gcc 7.3.0 Solaris 10, only older APR/APU 1.5.x compiled with
older gcc 4.9.2)
- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
- on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
and -D_XPG6
All 40 builds succeeded.
- compiler warnings:
- modules/core/mod_watchdog.c:436: warning: 'rv' may be used
uninitialized in this function
-> warning is correct but not critical (debug log);
not a regression
on RHEL 6 and SLES 11 due to older GCC versions:
- modules/md/md_json.c:31: warning: expected [error|warning|ignored]
after '#pragma GCC diagnostic'
- modules/md/md_json.c:45: warning: expected [error|warning|ignored]
after '#pragma GCC diagnostic'
due to strange jansson dependency library header files:
include/jansson.h:117:6: warning: 'json_decrefp' defined but not used
[-Wunused-function]
include/jansson.h:187:5: warning: 'json_object_set_nocheck' defined but
not used [-Wunused-function]
include/jansson.h:193:5: warning: 'json_object_iter_set' defined but not
used [-Wunused-function]
include/jansson.h:208:5: warning: 'json_array_set' defined but not used
[-Wunused-function]
include/jansson.h:220:5: warning: 'json_array_insert' defined but not
used [-Wunused-function]
and only on Solaris (gcc 7.3.0)
- modules/ldap/util_ldap_cache_mgr.c:728:32: warning: format '%ld'
expects argument of type 'long int', but argument 6 has type 'long long
int' [-Wformat=]
- modules/ldap/util_ldap_cache.c:111:20: warning: format '%ld'
expects argument of type 'long int', but argument 8 has type 'long long
int' [-Wformat=]
- srclib/apr-util/xlate/xlate.c:120:38: warning: passing argument 2 of
'iconv' from incompatible pointer type
[-Wincompatible-pointer-types]
- srclib/apr-util/xlate/xlate.c:343:42: warning: passing argument 2 of
'iconv' from incompatible pointer type
[-Wincompatible-pointer-types]
Tested for
- Solaris 10, SLES 11+12, RHEL 6+7
- MPMs prefork, worker, event
- default and static modules
- log levels info, debug and trace8
- module set reallyall (127 modules plus MPMs)
The following test failures were seen:
a Lots of tests in t/module/session.t fail always for static builds.
Not a regression.
For 2.4.28 the analysis was:
The whole setup for the /sessiontest uri is missing in the generated
t/conf/httpd.conf. This is due to it missing from the also generated
filet/conf/apache_test_config.pm. I do not know yet, why it is missing
there, but this seems to be a test framework problem.
b Test 59 of t/modules/include.t only and always on
Solaris.
Not a regression
Old analysis was:
This is due to a bug in the test, which uses strftime()
with a "%s" pattern that is not supported on Solaris.
Until recently the server and the test client both returned
verbatim "%s" and the test succeeded. After updating some
Perl modules for the http2 tests, the perl client even
on Solaris now supports "%s" in strftime and the test starts
to fail. It seems we have to fix the test.
c Various tests in t/apache/expr_string.t
Not a regression.
Test numbers : 6, 11, 14, 17, 20, 23, 26, 29
Happens for 9 out of about 225 runs (8 times on RHEL6, once
on Solaris).
The failure is almost always on line 87, where the error_log contents
are checked.
d One single test run (RHEL 7) failed test 163 of t/ssl/proxy.t
(line 131 of Apache-Test/lib/Apache/TestCommonPost.pm)
e Only on Solaris and only with prefork proxy tests sometimes
seem to hang until timeout.
Not a regression
Some test runs complete without
Not observed for static builds. Only builds based on APR/APU 1.6.x
seem to have the problem. First observed when testing 2.4.26.
It seems processes die due to Solaris mutex deadlock detection
for the accept mutex (false positive). Such processes get not
replaced until we end up with only one prefork child, which of
course can't serve proxy requests.
All in all I don't see a critical problem during my tests.
Regards,
Rainer
Re: [VOTE] Release httpd-2.4.30
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Feb 20, 2018 at 6:06 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> -1: I think with the release process hiccups and the Win issues
> noted in the "Current branche 2.4.30-dev issues" thread,
> we will need a 2.4.31. Additionally, there are some
> backports in STATUS that could also be folded in.
Very sensible.
I think our odds of a successful 2.4.31 increase dramatically if the
community will please continue their 2.4.30 review as if it would
become the release. Hold off any re-spin for a couple days to allow
that to happen as it usually would.
If 2.4.31 remains relatively static vs. 2.4.30, it minimizes the number
of additional regressions, e.g. hold 2.4.x branch to showstoppers
or regression fixes of 2.4.29/2.4.30 only for a few days.
Reviewing a lightly modified 2.4.31 candidate becomes much
simpler if 2.4.30 candidate has been beaten on, sufficiently.
Re: [VOTE] Release httpd-2.4.30
Posted by Jim Jagielski <ji...@jaguNET.com>.
-1: I think with the release process hiccups and the Win issues
noted in the "Current branche 2.4.30-dev issues" thread,
we will need a 2.4.31. Additionally, there are some
backports in STATUS that could also be folded in.
> On Feb 19, 2018, at 9:54 AM, DRuggeri@primary.net 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.30:
>
> [ ] +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.
> --
> Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.30
Posted by Daniel Ruggeri <dr...@apache.org>.
All;
With the release issues identified during validation, we will call this vote CLOSED with the statement that 2.4.30 is not suitable for public release. I apologise for the clerical error in not noting this sooner.
On 2018/02/19 14:54:35, <DR...@primary.net> 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.30:
>
>
>
> [ ] +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.
>
> --
>
> Daniel Ruggeri
>
>
>
>
Re: [VOTE] Release httpd-2.4.30
Posted by Rainer Jung <ra...@kippdata.de>.
Am 19.02.2018 um 15:54 schrieb DRuggeri@primary.net:
> 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.30:
>
> [ ] +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.
My testing is still ongoing but one thing I noticed: the dependency
tarball which we provide for convenience still contains APR/APU
1.6.2/1.6.0, but recent versions would be 1.6.3/1.6.1.
Regards,
Rainer
Re: [VOTE] Release httpd-2.4.30
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 19.02.2018 um 15:54 schrieb <DR...@primary.net> <DR...@primary.net>:
>
> 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.30:
>
> [ ] +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.
> --
> Daniel Ruggeri
+1
Tested: 17.4.0 Darwin (High Sierra 10.13.3), event+worker, http2 und md
Thanks for RMing, Daniel!