Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]

[William A Rowe Jr]

On Tue, Oct 24, 2017 at 3:12 AM, Stefan Eissing
 wrote:
> FTR: I refuse any discussion where people, already in the initial
> statements, discuss each others merit and downfalls and whatnot.
>
> If you want to talk about technical stuff and/or propose a project plan,
> start a new thread without all that destructive crap I will not waste
> any more time than this mail about.

That's exactly what I did;

On Fri, Oct 13, 2017 at 8:19 AM, William A Rowe Jr  wrote:
> Is anyone seeing an issue of concern about stability on 2.4.x branch?
>
> Has anyone else looked at Jim's proposed fixes for xcode 9 building
> under maintainer mode? A couple-line quick fix to configure.in, that
> anyone on OS/X should be able to validate in minutes. The same fix
> is already present on APR's branches, which I will tag as well.
>
> I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment
> period, so that the many proposed enhancements can be examined
> by alpha testers and our quick adopters of 2.4.28 can be back on track
> by early next week. That should simplify getting some of the more
> complex patches backported as necessary, or move us forward
> in any case.

There was no animus or personality involved in this statement. Follow
the thread to find out where it "broke" and who broke it.

I will kill this thread; I should have limited it to responding that
our ruleset inhibits vetoes of tags and releases; then a second fresh
thread not to anyone's comment in particular explaining the basis of
2.5.0-alpha. My bad, I apologize for mixing the two, and will more
carefully avoid this in the future.

Re: Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?}today]

[Steffen]

wrong link where to clean up:

http://svn.apache.org/viewvc/httpd/httpd/branches/


On Tuesday 24/10/2017 at 10:26, Steffen  wrote:



Can someone clean up the not needed anymore  backports/branches at
http://svn.apache.org/viewvc/httpd/httpd/branches/?sortby=date




On Tuesday 24/10/2017 at 10:12, Stefan Eissing  wrote:

FTR: I refuse any discussion where people, already in the initial
statements, discuss each others merit and downfalls and whatnot.

If you want to talk about technical stuff and/or propose a project 
plan,

start a new thread without all that destructive crap I will not waste
any more time than this mail about.

Cheers,

Stefan



Am 24.10.2017 um 00:17 schrieb William A Rowe Jr 
:


Jim, you have very vocally and hostility reacted to *all* discussion
of improving the release process at the httpd project.

The project bylaws are clear, no individual PMC member may
block a release (the PMC chair may, owing to the fact that they
alone represent the board as the appointed VP, that's another
topic entirely.)

I have no evidence that you perceive a problem with the httpd
release status quo, and no evidence that you have reconsidered
your positions expressed during the past year, so I presume
none of these are changed, and further discussion is not
necessary at this step.

You've insisted we maintain the status quo with no changes,
and I'm proceeding based on our historical and documented
practices to move the project along. This is an obvious case
of agree-to-disagree, I accept your demand to hold to precedent,
and will proceed under that structure to ask wiling users to help
us determine the usability of the current code trunk/. In short,
you have engendered this solution.

This is only a starting point, not a result. Multiple -alphas will
usually occur, and I can't foresee any conclusions on a roadmap
before the end of the year, and a beta-worthy candidate before
the end of winter.

(Northern) winter tends to be a period of greater activity, summers
are very quiet in comparison. The approach to progress under our
existing model is incremental; code and release, code and release,
until the committee agrees that the code is ready to move from an
-alpha to a -beta, from a -beta to graduate to 2.6.0/3.0.0. This
approach avoids all personal conflicts by getting away from
people debating opinion or process, and going back to debating
the features and code.

I am reading your reply as adding additional process which does
not exist, and appears to be thrown-up roadblocks. I'll ignore such
attempts to introduce process until any proposed process has the
majority +1 support by the project. If others here at httpd want
to begin defining the structure of 2.6.0/3.0.0 (the next possible
GA release, because 2.5.x is not GA, by policy), I'm all for it.
It's not a prereq to begin.

http://httpd.apache.org/dev/release.html

By "vetoed tag" it does not mean you can veto a tag. That wording
means that there is no code at present which carries a veto. I'm
unaware of any code in trunk that is vetoed in the 2.5.x development
trunk branch.

Please inform within 72 hours of what you are vetoing from -alpha
examination, so that I can remove or route around it and avoid any
unnecessary tags.

The rules were designed from day 1 of the ASF as a foundation
that no one individual can block forward progress of the project,
any PMC member may branch, or tag. The majority decision of
the project decides whether that tag is adopted as a release
(even -alpha requires a majority, 3 +1's!)

As the saying goes "We won't know till we try"... let's see if we
have collectively treated trunk/ well, and whether adventurous
users on the bleeding edge like what they see.



On Mon, Oct 23, 2017 at 4:32 PM, Jim Jagielski  
wrote:


The issue obviously isn't in the *tagging*. It is the unknown
aspect of what is expected AFTER the tagging.

I see the tagging as simply a mechanism to force action
upon the PMC to go down a route which the PMC has not
decided, from what I can tell, to go down. Maybe I'm wrong.
But your reply tends to support that interpretation. The tag, per
se, is not the goal. The goal is to "push" 2.5.0 when, again
from what I can tell, the PMC has not decided that such
a push is warranted/needed/desired/whatever.

So if you want to tag, first generate a roadmap, that can be
shared and discussed with the PMC, and the dev community,
what that 1st step is intended to lead us to. But let's
not pretend that such tagging is simply noting a SVN revision.

You may complain that I "single handedly" do Foo and Bar
and other dictatorial and dangerous stuff, but AFAIK, I've
never done or proposed anything w/o bringing it up
to the list 1st (ala PROXY support, mod_wsgi, health
checks... etc...). Even w/ releases and tags I give
people more than 24hours notice. Unless, of course,
your tag was under Lazy Consensus, in which case my
"veto" was valid, if more "strong" than required. In
which 

Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?}today]

[Steffen]

Can someone clean up the not needed anymore  backports/branches at
http://svn.apache.org/viewvc/httpd/httpd/branches/?sortby=date




On Tuesday 24/10/2017 at 10:12, Stefan Eissing  wrote:

FTR: I refuse any discussion where people, already in the initial
statements, discuss each others merit and downfalls and whatnot.

If you want to talk about technical stuff and/or propose a project 
plan,

start a new thread without all that destructive crap I will not waste
any more time than this mail about.

Cheers,

Stefan



Am 24.10.2017 um 00:17 schrieb William A Rowe Jr 
:


Jim, you have very vocally and hostility reacted to *all* discussion
of improving the release process at the httpd project.

The project bylaws are clear, no individual PMC member may
block a release (the PMC chair may, owing to the fact that they
alone represent the board as the appointed VP, that's another
topic entirely.)

I have no evidence that you perceive a problem with the httpd
release status quo, and no evidence that you have reconsidered
your positions expressed during the past year, so I presume
none of these are changed, and further discussion is not
necessary at this step.

You've insisted we maintain the status quo with no changes,
and I'm proceeding based on our historical and documented
practices to move the project along. This is an obvious case
of agree-to-disagree, I accept your demand to hold to precedent,
and will proceed under that structure to ask wiling users to help
us determine the usability of the current code trunk/. In short,
you have engendered this solution.

This is only a starting point, not a result. Multiple -alphas will
usually occur, and I can't foresee any conclusions on a roadmap
before the end of the year, and a beta-worthy candidate before
the end of winter.

(Northern) winter tends to be a period of greater activity, summers
are very quiet in comparison. The approach to progress under our
existing model is incremental; code and release, code and release,
until the committee agrees that the code is ready to move from an
-alpha to a -beta, from a -beta to graduate to 2.6.0/3.0.0. This
approach avoids all personal conflicts by getting away from
people debating opinion or process, and going back to debating
the features and code.

I am reading your reply as adding additional process which does
not exist, and appears to be thrown-up roadblocks. I'll ignore such
attempts to introduce process until any proposed process has the
majority +1 support by the project. If others here at httpd want
to begin defining the structure of 2.6.0/3.0.0 (the next possible
GA release, because 2.5.x is not GA, by policy), I'm all for it.
It's not a prereq to begin.

http://httpd.apache.org/dev/release.html

By "vetoed tag" it does not mean you can veto a tag. That wording
means that there is no code at present which carries a veto. I'm
unaware of any code in trunk that is vetoed in the 2.5.x development
trunk branch.

Please inform within 72 hours of what you are vetoing from -alpha
examination, so that I can remove or route around it and avoid any
unnecessary tags.

The rules were designed from day 1 of the ASF as a foundation
that no one individual can block forward progress of the project,
any PMC member may branch, or tag. The majority decision of
the project decides whether that tag is adopted as a release
(even -alpha requires a majority, 3 +1's!)

As the saying goes "We won't know till we try"... let's see if we
have collectively treated trunk/ well, and whether adventurous
users on the bleeding edge like what they see.



On Mon, Oct 23, 2017 at 4:32 PM, Jim Jagielski  
wrote:


The issue obviously isn't in the *tagging*. It is the unknown
aspect of what is expected AFTER the tagging.

I see the tagging as simply a mechanism to force action
upon the PMC to go down a route which the PMC has not
decided, from what I can tell, to go down. Maybe I'm wrong.
But your reply tends to support that interpretation. The tag, per
se, is not the goal. The goal is to "push" 2.5.0 when, again
from what I can tell, the PMC has not decided that such
a push is warranted/needed/desired/whatever.

So if you want to tag, first generate a roadmap, that can be
shared and discussed with the PMC, and the dev community,
what that 1st step is intended to lead us to. But let's
not pretend that such tagging is simply noting a SVN revision.

You may complain that I "single handedly" do Foo and Bar
and other dictatorial and dangerous stuff, but AFAIK, I've
never done or proposed anything w/o bringing it up
to the list 1st (ala PROXY support, mod_wsgi, health
checks... etc...). Even w/ releases and tags I give
people more than 24hours notice. Unless, of course,
your tag was under Lazy Consensus, in which case my
"veto" was valid, if more "strong" than required. In
which case, I am sorry for that.

Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]

[Stefan Eissing]

FTR: I refuse any discussion where people, already in the initial 
statements, discuss each others merit and downfalls and whatnot.

If you want to talk about technical stuff and/or propose a project plan,
start a new thread without all that destructive crap I will not waste
any more time than this mail about.

Cheers,

Stefan

> Am 24.10.2017 um 00:17 schrieb William A Rowe Jr :
> 
> Jim, you have very vocally and hostility reacted to *all* discussion
> of improving the release process at the httpd project.
> 
> The project bylaws are clear, no individual PMC member may
> block a release (the PMC chair may, owing to the fact that they
> alone represent the board as the appointed VP, that's another
> topic entirely.)
> 
> I have no evidence that you perceive a problem with the httpd
> release status quo, and no evidence that you have reconsidered
> your positions expressed during the past year, so I presume
> none of these are changed, and further discussion is not
> necessary at this step.
> 
> You've insisted we maintain the status quo with no changes,
> and I'm proceeding based on our historical and documented
> practices to move the project along. This is an obvious case
> of agree-to-disagree, I accept your demand to hold to precedent,
> and will proceed under that structure to ask wiling users to help
> us determine the usability of the current code trunk/. In short,
> you have engendered this solution.
> 
> This is only a starting point, not a result. Multiple -alphas will
> usually occur, and I can't foresee any conclusions on a roadmap
> before the end of the year, and a beta-worthy candidate before
> the end of winter.
> 
> (Northern) winter tends to be a period of greater activity, summers
> are very quiet in comparison. The approach to progress under our
> existing model is incremental; code and release, code and release,
> until the committee agrees that the code is ready to move from an
> -alpha to a -beta, from a -beta to graduate to 2.6.0/3.0.0. This
> approach avoids all personal conflicts by getting away from
> people debating opinion or process, and going back to debating
> the features and code.
> 
> I am reading your reply as adding additional process which does
> not exist, and appears to be thrown-up roadblocks. I'll ignore such
> attempts to introduce process until any proposed process has the
> majority +1 support by the project. If others here at httpd want
> to begin defining the structure of 2.6.0/3.0.0 (the next possible
> GA release, because 2.5.x is not GA, by policy), I'm all for it.
> It's not a prereq to begin.
> 
> http://httpd.apache.org/dev/release.html
> 
> By "vetoed tag" it does not mean you can veto a tag. That wording
> means that there is no code at present which carries a veto. I'm
> unaware of any code in trunk that is vetoed in the 2.5.x development
> trunk branch.
> 
> Please inform within 72 hours of what you are vetoing from -alpha
> examination, so that I can remove or route around it and avoid any
> unnecessary tags.
> 
> The rules were designed from day 1 of the ASF as a foundation
> that no one individual can block forward progress of the project,
> any PMC member may branch, or tag. The majority decision of
> the project decides whether that tag is adopted as a release
> (even -alpha requires a majority, 3 +1's!)
> 
> As the saying goes "We won't know till we try"... let's see if we
> have collectively treated trunk/ well, and whether adventurous
> users on the bleeding edge like what they see.
> 
> 
> 
> On Mon, Oct 23, 2017 at 4:32 PM, Jim Jagielski  wrote:
>> The issue obviously isn't in the *tagging*. It is the unknown
>> aspect of what is expected AFTER the tagging.
>> 
>> I see the tagging as simply a mechanism to force action
>> upon the PMC to go down a route which the PMC has not
>> decided, from what I can tell, to go down. Maybe I'm wrong.
>> But your reply tends to support that interpretation. The tag, per
>> se, is not the goal. The goal is to "push" 2.5.0 when, again
>> from what I can tell, the PMC has not decided that such
>> a push is warranted/needed/desired/whatever.
>> 
>> So if you want to tag, first generate a roadmap, that can be
>> shared and discussed with the PMC, and the dev community,
>> what that 1st step is intended to lead us to. But let's
>> not pretend that such tagging is simply noting a SVN revision.
>> 
>> You may complain that I "single handedly" do Foo and Bar
>> and other dictatorial and dangerous stuff, but AFAIK, I've
>> never done or proposed anything w/o bringing it up
>> to the list 1st (ala PROXY support, mod_wsgi, health
>> checks... etc...). Even w/ releases and tags I give
>> people more than 24hours notice. Unless, of course,
>> your tag was under Lazy Consensus, in which case my
>> "veto" was valid, if more "strong" than required. In
>> which case, I am sorry for that.

Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]

[William A Rowe Jr]

Jim, you have very vocally and hostility reacted to *all* discussion
of improving the release process at the httpd project.

The project bylaws are clear, no individual PMC member may
block a release (the PMC chair may, owing to the fact that they
alone represent the board as the appointed VP, that's another
topic entirely.)

I have no evidence that you perceive a problem with the httpd
release status quo, and no evidence that you have reconsidered
your positions expressed during the past year, so I presume
none of these are changed, and further discussion is not
necessary at this step.

You've insisted we maintain the status quo with no changes,
and I'm proceeding based on our historical and documented
practices to move the project along. This is an obvious case
of agree-to-disagree, I accept your demand to hold to precedent,
and will proceed under that structure to ask wiling users to help
us determine the usability of the current code trunk/. In short,
you have engendered this solution.

This is only a starting point, not a result. Multiple -alphas will
usually occur, and I can't foresee any conclusions on a roadmap
before the end of the year, and a beta-worthy candidate before
the end of winter.

(Northern) winter tends to be a period of greater activity, summers
are very quiet in comparison. The approach to progress under our
existing model is incremental; code and release, code and release,
until the committee agrees that the code is ready to move from an
-alpha to a -beta, from a -beta to graduate to 2.6.0/3.0.0. This
approach avoids all personal conflicts by getting away from
people debating opinion or process, and going back to debating
the features and code.

I am reading your reply as adding additional process which does
not exist, and appears to be thrown-up roadblocks. I'll ignore such
attempts to introduce process until any proposed process has the
majority +1 support by the project. If others here at httpd want
to begin defining the structure of 2.6.0/3.0.0 (the next possible
GA release, because 2.5.x is not GA, by policy), I'm all for it.
It's not a prereq to begin.

http://httpd.apache.org/dev/release.html

By "vetoed tag" it does not mean you can veto a tag. That wording
means that there is no code at present which carries a veto. I'm
unaware of any code in trunk that is vetoed in the 2.5.x development
trunk branch.

Please inform within 72 hours of what you are vetoing from -alpha
examination, so that I can remove or route around it and avoid any
unnecessary tags.

The rules were designed from day 1 of the ASF as a foundation
that no one individual can block forward progress of the project,
any PMC member may branch, or tag. The majority decision of
the project decides whether that tag is adopted as a release
(even -alpha requires a majority, 3 +1's!)

As the saying goes "We won't know till we try"... let's see if we
have collectively treated trunk/ well, and whether adventurous
users on the bleeding edge like what they see.



On Mon, Oct 23, 2017 at 4:32 PM, Jim Jagielski  wrote:
> The issue obviously isn't in the *tagging*. It is the unknown
> aspect of what is expected AFTER the tagging.
>
> I see the tagging as simply a mechanism to force action
> upon the PMC to go down a route which the PMC has not
> decided, from what I can tell, to go down. Maybe I'm wrong.
> But your reply tends to support that interpretation. The tag, per
> se, is not the goal. The goal is to "push" 2.5.0 when, again
> from what I can tell, the PMC has not decided that such
> a push is warranted/needed/desired/whatever.
>
> So if you want to tag, first generate a roadmap, that can be
> shared and discussed with the PMC, and the dev community,
> what that 1st step is intended to lead us to. But let's
> not pretend that such tagging is simply noting a SVN revision.
>
> You may complain that I "single handedly" do Foo and Bar
> and other dictatorial and dangerous stuff, but AFAIK, I've
> never done or proposed anything w/o bringing it up
> to the list 1st (ala PROXY support, mod_wsgi, health
> checks... etc...). Even w/ releases and tags I give
> people more than 24hours notice. Unless, of course,
> your tag was under Lazy Consensus, in which case my
> "veto" was valid, if more "strong" than required. In
> which case, I am sorry for that.

Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]

[Jim Jagielski]

The issue obviously isn't in the *tagging*. It is the unknown
aspect of what is expected AFTER the tagging.

I see the tagging as simply a mechanism to force action
upon the PMC to go down a route which the PMC has not
decided, from what I can tell, to go down. Maybe I'm wrong.
But your reply tends to support that interpretation. The tag, per
se, is not the goal. The goal is to "push" 2.5.0 when, again
from what I can tell, the PMC has not decided that such
a push is warranted/needed/desired/whatever.

So if you want to tag, first generate a roadmap, that can be
shared and discussed with the PMC, and the dev community,
what that 1st step is intended to lead us to. But let's
not pretend that such tagging is simply noting a SVN revision.

You may complain that I "single handedly" do Foo and Bar
and other dictatorial and dangerous stuff, but AFAIK, I've
never done or proposed anything w/o bringing it up
to the list 1st (ala PROXY support, mod_wsgi, health
checks... etc...). Even w/ releases and tags I give
people more than 24hours notice. Unless, of course,
your tag was under Lazy Consensus, in which case my
"veto" was valid, if more "strong" than required. In
which case, I am sorry for that.

Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]

[William A Rowe Jr]

On Fri, Oct 13, 2017 at 8:25 AM, Jim Jagielski  wrote:
> Why lump 2.5.0 into all this?
>
> There is no rational reason to force connect 2.4.29 and 2.5.0
>
> Tag 2.4.29 and leave 2.5.0 alone until people discuss it. Until then
> I will veto any foolishness about 2.5.0-whatever.

Good work, you helped established a foundation with two simple
premises, that no code changes can happen without a group
consensus, while no individual can ever block a release, that vote
is not subject to veto; simple majority.

It's only taken you 18 years to single-handedly undo that? Surely
you know there is no such thing as "Your Esteemed" veto. That
was actually the basis for my -0 on 2.4.28, I determined it was an
unwise release (little did we know), but left it at that... any -1 was
going to have no effect whatsoever unless the RM agreed it was
an unwise tag.

2.5.0-[alpha|beta] serves a number of very useful purposes;

  * Is trunk buildable by most? Is it stable? Is it a broken playground
of cruft that is not releasable?

  * By my count, four rather twisted backports are proposed to 2.4.x
none of which have seen any testing whatsoever. Bold suggestion
that these should be pushed on users in the current "maintenance"
branch that users are relying on. An alpha/beta of these features
pushes them to the forefront and may win huge acceptance or
specific objections.

  * Several major Linux distributions are approaching a glide path
towards 2018 final decisions on httpd reversioning; Ubuntu LTS
and RHEL 9 are likely to be locked in by year end for the next
quarter decade. Our lack of momentum spells zero chance to
move toward fixes of longstanding deficiencies.

  * Big news splash on major ssl enhancements that are unreleased.
In theory, the suggestion to alpha the code would have collided
with a news release on the subject in a good way (not withstanding
the late review of your specific issue and appreciation that it was
a much broader issue with invalid C grammar AC tests.)

  * What needs to come next? What third party modules are already
broken? What changes are third party developers clamoring for?
Oh, and we don't ship snapshots, by definition. So, no alpha/beta
cycle results in a lose lose proposition for our consumers.

But with your dismissive attitude, we might as well presume, since
you are rewriting the project and foundation ruleset, that in your
esteemed wisdom, httpd will no longer evolve, so any suggestion
that httpd could be better than it is today is lost on this mailing list
under your esteemed supervision and new rulemaking.

Please reconsider my rational for submitting this suggestion, and
rethink your basis for opposing it.

Cheers,

Bill

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[Jim Jagielski]

I'd say we use STATUS to keep track

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

[Yann Ylavic]

On Mon, Oct 16, 2017 at 3:25 PM, Rainer Jung  wrote:
> Am 16.10.2017 um 12:31 schrieb Joe Orton:
>>
>> On Fri, Oct 13, 2017 at 11:51:54AM -0400, Jim Jagielski wrote:
>>>
>>> The long and short is that under maintainer mode, we cannot
>>> expect AC_CHECK_LIB to being correct any longer, because
>>> the combination of -Werror and -Wstrict-prototypes means
>>> that any and all functions looked for/checked for using
>>> AC_CHECK_LIB will NOT be found, due to warnings which are
>>> now fatal errors during configure time, even if those
>>> functions DO exist.
>>
>>
>> IMO the correct fix is to add all -W... flags to NOTEST_CFLAGS not
>> CFLAGS so they don't take effect during the configure run at all.  At
>> least I can't think of a good motivation for having compiler warnings
>> enabled when running autoconf tests in general.
>
>
> Good hint, never used that variable.

+1!

> So what about the following patch
> instead: just tried it on trunk and seemed to work fine there.

Slightly modified (see attached), it works for me too.

I just added a second arg to APACHE_ADD_GCC_CFLAG which allows me to:
+  APACHE_ADD_GCC_CFLAG([-Werror], [-Wno-strict-prototypes])

where $2 is also used for AC_LANG_PROGRAM's CFLAGS (before $1), but
will not be added to NOTEST_CFLAGS.
Without this change, -Werror is still not accepted by AC_LANG_PROGRAM for me...
Index: acinclude.m4
===
--- acinclude.m4	(revision 1812289)
+++ acinclude.m4	(working copy)
@@ -960,7 +960,7 @@ YES_IS_DEFINED
 dnl
 dnl APACHE_ADD_GCC_CFLAGS
 dnl
-dnl Check if compiler is gcc and supports flag. If yes, add to CFLAGS.
+dnl Check if compiler is gcc and supports flag. If yes, add to NOTEST_CFLAGS.
 dnl
 AC_DEFUN([APACHE_ADD_GCC_CFLAG], [
   define([ap_gcc_ckvar], [ac_cv_gcc_]translit($1, [-:.=], []))
@@ -967,13 +967,13 @@ AC_DEFUN([APACHE_ADD_GCC_CFLAG], [
   if test "$GCC" = "yes"; then
 AC_CACHE_CHECK([whether gcc accepts $1], ap_gcc_ckvar, [
   save_CFLAGS="$CFLAGS"
-  CFLAGS="$CFLAGS $1"
+  CFLAGS="$CFLAGS $2 $1"
   AC_COMPILE_IFELSE([AC_LANG_PROGRAM()],
 [ap_gcc_ckvar=yes], [ap_gcc_ckvar=no])
   CFLAGS="$save_CFLAGS"
 ])
 if test "$]ap_gcc_ckvar[" = "yes" ; then
-   APR_ADDTO(CFLAGS,[$1])
+   APR_ADDTO(NOTEST_CFLAGS,[$1])
 fi
   fi
   undefine([ap_gcc_ckvar])
Index: configure.in
===
--- configure.in	(revision 1812289)
+++ configure.in	(working copy)
@@ -627,21 +627,17 @@ AC_ARG_ENABLE(load-all-modules,APACHE_HELP_STRING(
 AC_ARG_ENABLE(maintainer-mode,APACHE_HELP_STRING(--enable-maintainer-mode,Turn on debugging and compile time warnings and load all compiled modules),
 [
   if test "$enableval" = "yes"; then
-APR_ADDTO(CPPFLAGS, -DAP_DEBUG)
+APR_ADDTO(NOTEST_CPPFLAGS, -DAP_DEBUG)
 if test "$GCC" = "yes"; then
-  APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith])
-  # Next flag needed, because -Wstrict-prototypes in combination with
-  # -Werror leads to compiler errors during configure checks (autoconf
-  # generates incomplete prototypes).
-  APACHE_ADD_GCC_CFLAG([-Wno-error=strict-prototypes])
+  APR_ADDTO(NOTEST_CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith])
   APACHE_ADD_GCC_CFLAG([-std=c89])
-  APACHE_ADD_GCC_CFLAG([-Werror])
+  APACHE_ADD_GCC_CFLAG([-Werror], [-Wno-strict-prototypes])
   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Wformat])
   APACHE_ADD_GCC_CFLAG([-Wformat-security])
   APACHE_ADD_GCC_CFLAG([-Wunused])
 elif test "$AIX_XLC" = "yes"; then
-  APR_ADDTO(CFLAGS,-qfullpath -qinitauto=FE -qcheck=all -qinfo=pro)
+  APR_ADDTO(NOTEST_CFLAGS,-qfullpath -qinitauto=FE -qcheck=all -qinfo=pro)
 fi
 if test "x$enable_load_all_modules" = "x"; then
   LOAD_ALL_MODULES=yes
@@ -657,9 +653,9 @@ AC_ARG_ENABLE(maintainer-mode,APACHE_HELP_STRING(-
 AC_ARG_ENABLE(debugger-mode,APACHE_HELP_STRING(--enable-debugger-mode,Turn on debugging and compile time warnings and turn off optimization),
 [
   if test "$enableval" = "yes"; then
-APR_ADDTO(CPPFLAGS, -DAP_DEBUG)
+APR_ADDTO(NOTEST_CPPFLAGS, -DAP_DEBUG)
 if test "$GCC" = "yes"; then
-  APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith -O0])
+  APR_ADDTO(NOTEST_CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith -O0])
   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Werror=declaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Wformat])
@@ -666,7 +662,7 @@ AC_ARG_ENABLE(debugger-mode,APACHE_HELP_STRING(--e
   APACHE_ADD_GCC_CFLAG([-Wformat-security])
   APACHE_ADD_GCC_CFLAG([-Werror=format-security])
 

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

[Rainer Jung]

Am 16.10.2017 um 12:31 schrieb Joe Orton:

On Fri, Oct 13, 2017 at 11:51:54AM -0400, Jim Jagielski wrote:

The long and short is that under maintainer mode, we cannot
expect AC_CHECK_LIB to being correct any longer, because
the combination of -Werror and -Wstrict-prototypes means
that any and all functions looked for/checked for using
AC_CHECK_LIB will NOT be found, due to warnings which are
now fatal errors during configure time, even if those
functions DO exist.


IMO the correct fix is to add all -W... flags to NOTEST_CFLAGS not
CFLAGS so they don't take effect during the configure run at all.  At
least I can't think of a good motivation for having compiler warnings
enabled when running autoconf tests in general.


Good hint, never used that variable. So what about the following patch 
instead: just tried it on trunk and seemed to work fine there. Ut 
changes APACHE_ADD_GCC_CFLAG to operate on NOTEST_CFLAGS instead of 
CFLAGS (the macro currently is only used in places where we IMHO 
actually want that change) and introduces NOTEST_CFLAGS use to configure 
where we handle maintainer mode and debugger mode.


Index: acinclude.m4
===
--- acinclude.m4(revision 1812263)
+++ acinclude.m4(working copy)
@@ -960,7 +960,7 @@
 dnl
 dnl APACHE_ADD_GCC_CFLAGS
 dnl
-dnl Check if compiler is gcc and supports flag. If yes, add to CFLAGS.
+dnl Check if compiler is gcc and supports flag. If yes, add to 
NOTEST_CFLAGS.

 dnl
 AC_DEFUN([APACHE_ADD_GCC_CFLAG], [
   define([ap_gcc_ckvar], [ac_cv_gcc_]translit($1, [-:.=], []))
@@ -973,7 +973,7 @@
   CFLAGS="$save_CFLAGS"
 ])
 if test "$]ap_gcc_ckvar[" = "yes" ; then
-   APR_ADDTO(CFLAGS,[$1])
+   APR_ADDTO(NOTEST_CFLAGS,[$1])
 fi
   fi
   undefine([ap_gcc_ckvar])
Index: configure.in
===
--- configure.in(revision 1812263)
+++ configure.in(working copy)
@@ -627,14 +627,10 @@

AC_ARG_ENABLE(maintainer-mode,APACHE_HELP_STRING(--enable-maintainer-mode,Turn 
on debugging and compile time warnings and load all compiled modules),

 [
   if test "$enableval" = "yes"; then
-APR_ADDTO(CPPFLAGS, -DAP_DEBUG)
+APR_ADDTO(NOTEST_CPPFLAGS, -DAP_DEBUG)
 if test "$GCC" = "yes"; then
-  APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes 
-Wmissing-declarations -Wpointer-arith])

-  # Next flag needed, because -Wstrict-prototypes in combination with
-  # -Werror leads to compiler errors during configure checks (autoconf
-  # generates incomplete prototypes).
-  APACHE_ADD_GCC_CFLAG([-Wno-error=strict-prototypes])
-  APACHE_ADD_GCC_CFLAG([-std=c89])
+  APR_ADDTO(NOTEST_CFLAGS,[-Wall -Wmissing-prototypes 
-Wstrict-prototypes -Wmissing-declarations -Wpointer-arith])

+  #APACHE_ADD_GCC_CFLAG([-std=c89])
   APACHE_ADD_GCC_CFLAG([-Werror])
   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Wformat])
@@ -641,7 +637,7 @@
   APACHE_ADD_GCC_CFLAG([-Wformat-security])
   APACHE_ADD_GCC_CFLAG([-Wunused])
 elif test "$AIX_XLC" = "yes"; then
-  APR_ADDTO(CFLAGS,-qfullpath -qinitauto=FE -qcheck=all -qinfo=pro)
+  APR_ADDTO(NOTEST_CFLAGS,-qfullpath -qinitauto=FE -qcheck=all 
-qinfo=pro)

 fi
 if test "x$enable_load_all_modules" = "x"; then
   LOAD_ALL_MODULES=yes
@@ -657,9 +653,9 @@

AC_ARG_ENABLE(debugger-mode,APACHE_HELP_STRING(--enable-debugger-mode,Turn 
on debugging and compile time warnings and turn off optimization),

 [
   if test "$enableval" = "yes"; then
-APR_ADDTO(CPPFLAGS, -DAP_DEBUG)
+APR_ADDTO(NOTEST_CPPFLAGS, -DAP_DEBUG)
 if test "$GCC" = "yes"; then
-  APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes 
-Wmissing-declarations -Wpointer-arith -O0])
+  APR_ADDTO(NOTEST_CFLAGS,[-Wall -Wmissing-prototypes 
-Wstrict-prototypes -Wmissing-declarations -Wpointer-arith -O0])

   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Werror=declaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Wformat])
@@ -666,7 +662,7 @@
   APACHE_ADD_GCC_CFLAG([-Wformat-security])
   APACHE_ADD_GCC_CFLAG([-Werror=format-security])
 elif test "$AIX_XLC" = "yes"; then
-  APR_ADDTO(CFLAGS,-qfullpath -qinitauto=FE -qcheck=all -qinfo=pro)
+  APR_ADDTO(NOTEST_CFLAGS,-qfullpath -qinitauto=FE -qcheck=all 
-qinfo=pro)

 fi
   fi
 ])dnl


Regards,

Rainer

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

[Joe Orton]

On Fri, Oct 13, 2017 at 11:51:54AM -0400, Jim Jagielski wrote:
> The long and short is that under maintainer mode, we cannot
> expect AC_CHECK_LIB to being correct any longer, because
> the combination of -Werror and -Wstrict-prototypes means
> that any and all functions looked for/checked for using
> AC_CHECK_LIB will NOT be found, due to warnings which are
> now fatal errors during configure time, even if those
> functions DO exist.

IMO the correct fix is to add all -W... flags to NOTEST_CFLAGS not 
CFLAGS so they don't take effect during the configure run at all.  At 
least I can't think of a good motivation for having compiler warnings 
enabled when running autoconf tests in general.

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

[Yann Ylavic]

On Mon, Oct 16, 2017 at 10:16 AM, Stefan Eissing
 wrote:
>
>> Am 15.10.2017 um 17:52 schrieb Rainer Jung :
>>
>> Nevertheless I would still say that adding "-Wno-error=strict-prototypes" 
>> for any clang and gcc version that supports it would be the correct option. 
>> Then -Werror should automatically get applied again.
>
> +1

+1

Thanks Rainer!

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

[Jim Jagielski]

I'd be +1 on setting -Wno-error=strict-prototypes unconditionally

> On Oct 15, 2017, at 11:52 AM, Rainer Jung  wrote:
> 
> Am 15.10.2017 um 16:25 schrieb Yann Ylavic:
>> On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung  wrote:
>>> 
>>> Why is this happening now? The "-Werror" was backported last December in
>>> r1772330, which was a backport of r1702948 from trunk (May 2015). Maybe
>>> people haven't used maintainer mode since then?
>> During the backport process of r1772330, Jacob noticed that -Werror
>> was not working as expected (see STATUS changes in this commit). He
>> also made a comment on dev@ here:
>> https://marc.info/?l=apache-cvs=147508169616462=2
>> Maybe -Werror is just ignored somehow, because I always compile in
>> maintainer mode with several gcc versions...
> 
> Thanks Yann, I actually only ran gcc with the respective flags. But indeed 
> configure checks for each flag whether it is "working" and the program which 
> gets compiled is:
> 
> int
> main ()
> {
> struct tm tm; tm.tm_gmtoff;
>  ;
>  return 0;
> }
> 
> So since we set -Wstrict-prototypes before, -Werror turns this into
> 
> conftest.c:45:1: error: function declaration isn't a prototype 
> [-Werror=strict-prototypes]
> main ()
> ^~~~
> 
> and -Werror does not get set at all.
> 
> Nevertheless I would still say that adding "-Wno-error=strict-prototypes" for 
> any clang and gcc version that supports it would be the correct option. Then 
> -Werror should automatically get applied again.
> 
> So something like the following (simple) patch should be an improvement for 
> gcc and clang and also fix Jim's problem. Of course since we then would have 
> -Werror enabled probably for the first time for gcc other new problems might 
> show (that will currently only be observable as warnings during maintainer 
> builds).
> 
> Index: configure.in
> ===
> --- configure.in(revision 1812218)
> +++ configure.in(working copy)
> @@ -597,6 +597,7 @@
> if test "$GCC" = "yes"; then
>   APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes 
> -Wmissing-declarations -Wpointer-arith])
>   APACHE_ADD_GCC_CFLAG([-std=c89])
> +  APACHE_ADD_GCC_CFLAG([-Wno-error=strict-prototypes])
>   APACHE_ADD_GCC_CFLAG([-Werror])
>   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
>   APACHE_ADD_GCC_CFLAG([-Wformat])
> 
> Regards,
> 
> Rainer

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

[Stefan Eissing]

> Am 15.10.2017 um 17:52 schrieb Rainer Jung :
> 
> Am 15.10.2017 um 16:25 schrieb Yann Ylavic:
>> On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung  wrote:
>>> 
>>> Why is this happening now? The "-Werror" was backported last December in
>>> r1772330, which was a backport of r1702948 from trunk (May 2015). Maybe
>>> people haven't used maintainer mode since then?
>> During the backport process of r1772330, Jacob noticed that -Werror
>> was not working as expected (see STATUS changes in this commit). He
>> also made a comment on dev@ here:
>> https://marc.info/?l=apache-cvs=147508169616462=2
>> Maybe -Werror is just ignored somehow, because I always compile in
>> maintainer mode with several gcc versions...
> 
> Thanks Yann, I actually only ran gcc with the respective flags. But indeed 
> configure checks for each flag whether it is "working" and the program which 
> gets compiled is:
> 
> int
> main ()
> {
> struct tm tm; tm.tm_gmtoff;
>  ;
>  return 0;
> }
> 
> So since we set -Wstrict-prototypes before, -Werror turns this into
> 
> conftest.c:45:1: error: function declaration isn't a prototype 
> [-Werror=strict-prototypes]
> main ()
> ^~~~
> 
> and -Werror does not get set at all.

Ha, nice catch! ;-)

> Nevertheless I would still say that adding "-Wno-error=strict-prototypes" for 
> any clang and gcc version that supports it would be the correct option. Then 
> -Werror should automatically get applied again.

+1

> So something like the following (simple) patch should be an improvement for 
> gcc and clang and also fix Jim's problem. Of course since we then would have 
> -Werror enabled probably for the first time for gcc other new problems might 
> show (that will currently only be observable as warnings during maintainer 
> builds).
> 
> Index: configure.in
> ===
> --- configure.in(revision 1812218)
> +++ configure.in(working copy)
> @@ -597,6 +597,7 @@
> if test "$GCC" = "yes"; then
>   APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes 
> -Wmissing-declarations -Wpointer-arith])
>   APACHE_ADD_GCC_CFLAG([-std=c89])
> +  APACHE_ADD_GCC_CFLAG([-Wno-error=strict-prototypes])
>   APACHE_ADD_GCC_CFLAG([-Werror])
>   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
>   APACHE_ADD_GCC_CFLAG([-Wformat])
> 
> Regards,
> 
> Rainer

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[William A Rowe Jr]

Your analysis matches mine, but we still have the open concern of your VS
import quirks around the expat library name. Ideas?



On Oct 15, 2017 03:20, "Steffen"  wrote:

> In Apache.dsw is now  project xml  removed, it is not building out of the
> box with current released apr-util.
>
> With coming apr-util 1.6.1 it should be fine.
>
> On Friday 13/10/2017 at 15:20, William A Rowe Jr wrote:
>
> Is anyone seeing an issue of concern about stability on 2.4.x branch?
>
> Has anyone else looked at Jim's proposed fixes for xcode 9 building
> under maintainer mode? A couple-line quick fix to configure.in, that
> anyone on OS/X should be able to validate in minutes. The same fix
> is already present on APR's branches, which I will tag as well.
>
> I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment
> period, so that the many proposed enhancements can be examined
> by alpha testers and our quick adopters of 2.4.28 can be back on track
> by early next week. That should simplify getting some of the more
> complex patches backported as necessary, or move us forward
> in any case.
>
>
>
>

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[William A Rowe Jr]

I've been watching the maintainer mode deliberations on dev@apr with great
interest. I'm also keenly aware of Steffen's concerns, especially since
dropping pcre didn't cause nearly this much trouble.

If we are all on the same page, I'll continue to work through the expat
headache on Monday and others hopefully are close to replacing your OS/X
solve with a more comprehensive solution, even if that means dropping the
I'll considered -Werror patch regression.

I think we all want a regression free and all-platform release finally. If
you want to be the RM, that's great!

Would anyone who is actively reviewing please chime in when you see your
concerns solved, whether these are related to maintainer mode or Win32?

TIA, Jim, and testers.



On Oct 14, 2017 08:41, "Jim Jagielski"  wrote:

> OtherBill, I see that 2.4.29 wasn't tagged. Are you still planning on
> doing so? I can T on Monday if you like.
>

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

[Rainer Jung]

Am 15.10.2017 um 16:25 schrieb Yann Ylavic:

On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung  wrote:


Why is this happening now? The "-Werror" was backported last December in
r1772330, which was a backport of r1702948 from trunk (May 2015). Maybe
people haven't used maintainer mode since then?


During the backport process of r1772330, Jacob noticed that -Werror
was not working as expected (see STATUS changes in this commit). He
also made a comment on dev@ here:
https://marc.info/?l=apache-cvs=147508169616462=2

Maybe -Werror is just ignored somehow, because I always compile in
maintainer mode with several gcc versions...


Thanks Yann, I actually only ran gcc with the respective flags. But 
indeed configure checks for each flag whether it is "working" and the 
program which gets compiled is:


int
main ()
{
struct tm tm; tm.tm_gmtoff;
  ;
  return 0;
}

So since we set -Wstrict-prototypes before, -Werror turns this into

conftest.c:45:1: error: function declaration isn't a prototype 
[-Werror=strict-prototypes]

 main ()
 ^~~~

and -Werror does not get set at all.

Nevertheless I would still say that adding 
"-Wno-error=strict-prototypes" for any clang and gcc version that 
supports it would be the correct option. Then -Werror should 
automatically get applied again.


So something like the following (simple) patch should be an improvement 
for gcc and clang and also fix Jim's problem. Of course since we then 
would have -Werror enabled probably for the first time for gcc other new 
problems might show (that will currently only be observable as warnings 
during maintainer builds).


Index: configure.in
===
--- configure.in(revision 1812218)
+++ configure.in(working copy)
@@ -597,6 +597,7 @@
 if test "$GCC" = "yes"; then
   APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes 
-Wmissing-declarations -Wpointer-arith])

   APACHE_ADD_GCC_CFLAG([-std=c89])
+  APACHE_ADD_GCC_CFLAG([-Wno-error=strict-prototypes])
   APACHE_ADD_GCC_CFLAG([-Werror])
   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Wformat])

Regards,

Rainer

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

[Yann Ylavic]

On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung  wrote:
>
> Why is this happening now? The "-Werror" was backported last December in
> r1772330, which was a backport of r1702948 from trunk (May 2015). Maybe
> people haven't used maintainer mode since then?

During the backport process of r1772330, Jacob noticed that -Werror
was not working as expected (see STATUS changes in this commit). He
also made a comment on dev@ here:
https://marc.info/?l=apache-cvs=147508169616462=2

Maybe -Werror is just ignored somehow, because I always compile in
maintainer mode with several gcc versions...

Regards,
Yann.

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

[Rainer Jung]

Hi Jim,

Am 13.10.2017 um 17:51 schrieb Jim Jagielski:

Let's recall what is really happening...

In maintainer mode, the build system sets -Werror and -Wstrict-prototypes.
This means that functions which lack strict prototypes will "fail".

Now note that AC_CHECK_LIB does not worry about generating
function calls w/ prototypes, so, for example, when checking
for luaL_newstate, it will fail *even if the function exists*!
In fact, this is how I 1st observed the issue: mod_lua was
no longer being included.

The long and short is that under maintainer mode, we cannot
expect AC_CHECK_LIB to being correct any longer, because
the combination of -Werror and -Wstrict-prototypes means
that any and all functions looked for/checked for using
AC_CHECK_LIB will NOT be found, due to warnings which are
now fatal errors during configure time, even if those
functions DO exist.

PS: CCing dev@apr since APR also uses AC_CHECK_LIB


I has a look at this. autoconf does generate a line they call a 
prototype, but it is not a strict prototype (there's no type information 
for the function arguments):


/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */
#ifdef __cplusplus
extern "C"
#endif
char luaL_newstate ();
int
main ()
{
return luaL_newstate ();
  ;
  return 0;
}

Directly before the "int main" there's the broken prototype line

char luaL_newstate ();

And in fact the compiler would also complain about

int
main ()

due to the missing "void" for the arguments.

Of all the flags we set in maintainer mode, the combination that lets 
the compiler fail is:


-Wstrict-prototypes
-Werror

It fails for me also when using GCC (from 4.1.2 to 7.1.0)! So I think a 
clang-specific solution is incomplete.


Why is this happening now? The "-Werror" was backported last December in 
r1772330, which was a backport of r1702948 from trunk (May 2015). Maybe 
people haven't used maintainer mode since then?


Regards,

Rainer

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[Steffen]

In Apache.dsw is now  project xml  removed, it is not building out of 
the box with current released apr-util.


With coming apr-util 1.6.1 it should be fine.


On Friday 13/10/2017 at 15:20, William A Rowe Jr  wrote:


Is anyone seeing an issue of concern about stability on 2.4.x branch?

Has anyone else looked at Jim's proposed fixes for xcode 9 building
under maintainer mode? A couple-line quick fix to configure.in, that
anyone on OS/X should be able to validate in minutes. The same fix
is already present on APR's branches, which I will tag as well.

I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment
period, so that the many proposed enhancements can be examined
by alpha testers and our quick adopters of 2.4.28 can be back on track
by early next week. That should simplify getting some of the more
complex patches backported as necessary, or move us forward
in any case.

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[Jim Jagielski]

OtherBill, I see that 2.4.29 wasn't tagged. Are you still planning on
doing so? I can T on Monday if you like.

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

[William A Rowe Jr]

Thank you for this summary!

On Oct 13, 2017 10:51, "Jim Jagielski"  wrote:

> Let's recall what is really happening...
>
> In maintainer mode, the build system sets -Werror and -Wstrict-prototypes.
> This means that functions which lack strict prototypes will "fail".
>
> Now note that AC_CHECK_LIB does not worry about generating
> function calls w/ prototypes, so, for example, when checking
> for luaL_newstate, it will fail *even if the function exists*!
> In fact, this is how I 1st observed the issue: mod_lua was
> no longer being included.
>
> The long and short is that under maintainer mode, we cannot
> expect AC_CHECK_LIB to being correct any longer, because
> the combination of -Werror and -Wstrict-prototypes means
> that any and all functions looked for/checked for using
> AC_CHECK_LIB will NOT be found, due to warnings which are
> now fatal errors during configure time, even if those
> functions DO exist.
>
> PS: CCing dev@apr since APR also uses AC_CHECK_LIB
>

AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

[Jim Jagielski]

Let's recall what is really happening...

In maintainer mode, the build system sets -Werror and -Wstrict-prototypes.
This means that functions which lack strict prototypes will "fail".

Now note that AC_CHECK_LIB does not worry about generating
function calls w/ prototypes, so, for example, when checking
for luaL_newstate, it will fail *even if the function exists*!
In fact, this is how I 1st observed the issue: mod_lua was
no longer being included.

The long and short is that under maintainer mode, we cannot
expect AC_CHECK_LIB to being correct any longer, because
the combination of -Werror and -Wstrict-prototypes means
that any and all functions looked for/checked for using
AC_CHECK_LIB will NOT be found, due to warnings which are
now fatal errors during configure time, even if those
functions DO exist.

PS: CCing dev@apr since APR also uses AC_CHECK_LIB

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[Reindl Harald]

Am 13.10.2017 um 17:05 schrieb William A Rowe Jr:
On Oct 13, 2017 08:41, "Stefan Eissing" > wrote:


 > Am 13.10.2017 um 15:19 schrieb William A Rowe Jr
>:
 >
 > Is anyone seeing an issue of concern about stability on 2.4.x branch?

Not any more than in previous releases, I think.

 > Has anyone else looked at Jim's proposed fixes for xcode 9 building
 > under maintainer mode? A couple-line quick fix to configure.in
, that
 > anyone on OS/X should be able to validate in minutes. The same fix
 > is already present on APR's branches, which I will tag as well.

I build in maintainer mode all the time and use Xcode9 since I
upgrade to macOS 10.13. Whatever weirdness I encountered and reported
earlier is gone - I rebuilt my local 2.4.x environment and all seems
well.

I suspect it works because you first configured APR in maintainer mode, 
and httpd inherits cpp flags?


and why does that happen at all for apr-util and httpd?

that means *you can not* build rpm packages for let say sandybridge on a 
machine which has installed apr/apr-util built with -mtune=native on a 
Skylake cluster until you first rebuild apr/apr-util which then means 
you can't build a httpd package optimized for Skylake until you rebuild 
the other both again - that is simply wrong and no other software acts 
that way


https://bz.apache.org/bugzilla/show_bug.cgi?id=61417
https://bz.apache.org/bugzilla/show_bug.cgi?id=61418

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[William A Rowe Jr]

On Oct 13, 2017 08:41, "Stefan Eissing" 
wrote:



> Am 13.10.2017 um 15:19 schrieb William A Rowe Jr :
>
> Is anyone seeing an issue of concern about stability on 2.4.x branch?

Not any more than in previous releases, I think.

> Has anyone else looked at Jim's proposed fixes for xcode 9 building
> under maintainer mode? A couple-line quick fix to configure.in, that
> anyone on OS/X should be able to validate in minutes. The same fix
> is already present on APR's branches, which I will tag as well.

I build in maintainer mode all the time and use Xcode9 since I
upgrade to macOS 10.13. Whatever weirdness I encountered and reported
earlier is gone - I rebuilt my local 2.4.x environment and all seems
well.


I suspect it works because you first configured APR in maintainer mode, and
httpd inherits cpp flags?

Jim's proposal fixes httpd configured in maintainer mode when a
conventional APR is present, IIUC.

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[Stefan Eissing]

> Am 13.10.2017 um 15:19 schrieb William A Rowe Jr :
> 
> Is anyone seeing an issue of concern about stability on 2.4.x branch?

Not any more than in previous releases, I think.

> Has anyone else looked at Jim's proposed fixes for xcode 9 building
> under maintainer mode? A couple-line quick fix to configure.in, that
> anyone on OS/X should be able to validate in minutes. The same fix
> is already present on APR's branches, which I will tag as well.

I build in maintainer mode all the time and use Xcode9 since I 
upgrade to macOS 10.13. Whatever weirdness I encountered and reported
earlier is gone - I rebuilt my local 2.4.x environment and all seems
well.


> I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment
> period, so that the many proposed enhancements can be examined
> by alpha testers and our quick adopters of 2.4.28 can be back on track
> by early next week. That should simplify getting some of the more
> complex patches backported as necessary, or move us forward
> in any case.

Must have missed any 2.5.0 discussion. Do we have any fixes in the pipe
that cannot be in the 2.4.x line? That'd be a shame.

-Stefan

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[Jim Jagielski]

Why lump 2.5.0 into all this?

There is no rational reason to force connect 2.4.29 and 2.5.0

Tag 2.4.29 and leave 2.5.0 alone until people discuss it. Until then
I will veto any foolishness about 2.5.0-whatever.

> On Oct 13, 2017, at 9:19 AM, William A Rowe Jr  wrote:
> 
> Is anyone seeing an issue of concern about stability on 2.4.x branch?
> 
> Has anyone else looked at Jim's proposed fixes for xcode 9 building
> under maintainer mode? A couple-line quick fix to configure.in 
> , that
> anyone on OS/X should be able to validate in minutes. The same fix
> is already present on APR's branches, which I will tag as well.
> 
> I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment
> period, so that the many proposed enhancements can be examined
> by alpha testers and our quick adopters of 2.4.28 can be back on track
> by early next week. That should simplify getting some of the more
> complex patches backported as necessary, or move us forward
> in any case.
> 
> 

Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[William A Rowe Jr]

Is anyone seeing an issue of concern about stability on 2.4.x branch?

Has anyone else looked at Jim's proposed fixes for xcode 9 building
under maintainer mode? A couple-line quick fix to configure.in, that
anyone on OS/X should be able to validate in minutes. The same fix
is already present on APR's branches, which I will tag as well.

I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment
period, so that the many proposed enhancements can be examined
by alpha testers and our quick adopters of 2.4.28 can be back on track
by early next week. That should simplify getting some of the more
complex patches backported as necessary, or move us forward
in any case.