Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

> On Feb 7, 2018, at 12:04 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Wed, Feb 7, 2018 at 9:07 AM, Jim Jagielski <j...@jagunet.com > <mailto:j...@jagunet.com>> wrote: >> Personally, I still think that updating these fields for 2.4.x >>

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

> On Feb 7, 2018, at 10:24 AM, Graham Leggett wrote: > > On 07 Feb 2018, at 5:18 PM, Graham Leggett > wrote: > >> Looking back through the archives, looks like that backport was already >> accepted: >> >>

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

PS: Want to propose it for back port, or should I? ;) > On Feb 7, 2018, at 10:16 AM, Jim Jagielski <j...@jagunet.com> wrote: > > > >> On Feb 7, 2018, at 10:07 AM, Graham Leggett <minf...@sharp.fm> wrote: >> >> >> In theory, the “accept

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

> On Feb 7, 2018, at 10:07 AM, Graham Leggett wrote: > > > In theory, the “accept a truncated value” will work around the problem and be > backport-able, is that true? +1 (assuming the truncated value is unique)

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

Personally, I still think that updating these fields for 2.4.x makes sense and can be justified... but am in no mood for a battle *grin* > On Feb 7, 2018, at 10:04 AM, Jim Jagielski <j...@jagunet.com> wrote: > > I believe the issue are the various defines in &g

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

I believe the issue are the various defines in mod_proxy.h (eg: PROXY_WORKER_MAX_NAME_SIZE. These have been bumped up in trunk but have not been backported to 2.4 due to perceived API/ABI issues. > On Feb 7, 2018, at 9:52 AM, Graham Leggett wrote: > > Hi all, > > Just hit

Re: Which server id for mod_proxy_lb? (was: New ServerUID directive)

At this point, I no longer have a horse in this race... From a philosophical point of view, adding 10kgs of fluff to fix 1kg of error seems over-engineering to me, but that is just me. +1 for whatever you think is best... and thx for your work on this.

Re: Which server id for mod_proxy_lb? (was: New ServerUID directive)

Just for fun, what is the functional difference, if any, between this very large patch, that adds lots of code, and this extremely simple diff which, from what I can tell, handles the exact defined "problem" with the original code??? Just curious if our current policy is to use a sledgehammer now

Re: Which server id for mod_proxy_lb? (was: New ServerUID directive)

ll the vhost's balancers states... > > On Tue, Feb 6, 2018 at 2:29 PM, Jim Jagielski <j...@jagunet.com> wrote: >> IMO, unless there are issues/problems with what we do *now*, >> we shouldn't be changing things... >> >>> On Feb 6, 2018, at 2:24 AM, Yann Ylavic <

Re: Which server id for mod_proxy_lb? (was: New ServerUID directive)

IMO, unless there are issues/problems with what we do *now*, we shouldn't be changing things... > On Feb 6, 2018, at 2:24 AM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Mon, Feb 5, 2018 at 8:09 PM, Jim Jagielski <j...@jagunet.com> wrote: >> >> On Feb 5,

Re: New ServerUID directive

But we already HAVE an "automatic" ID... that's what the Vhost's server_rec is. The issue is that there is no "one-size-fits-all" definition of what such an automatic ID means or how it should be defined. Is it just Vhost name + Port? That might be good for some modules, but NOT good for others.

Re: New ServerUID directive

> On Feb 5, 2018, at 7:38 AM, Stefan Eissing > wrote: > > > 2. Does httpd core expose a VirtualHost Identifier in its API and > what would the semantic properties of such an identifier be? > Yes, it does. It's the server_rec. That contains all the info

Re: The Case for Managed Domains

+1 > On Feb 4, 2018, at 7:35 AM, Steffen wrote: > > There is already Basic Management eXtensions for Apache : mod_bmx is handling > vhosts. > > https://github.com/hyperic/mod_bmx/ > > Using it on windows with mrtg and mod_watch to

Re: New ServerUID directive

> On Feb 2, 2018, at 8:05 PM, Yann Ylavic wrote: > > That's a new directive too, very specialized (though it's your point). > Wouldn't it end up being declined to other modules one day or the other? > But mainly, rather than ignoring config changes, I think mod_proxy_lb >

Re: New ServerUID directive

> On Feb 4, 2018, at 5:49 AM, Stefan Eissing > wrote: > > > Initially, ServerUID sounded like a tweak, but now we are talking > about the identity of a server_rec across reloads and how that > can be useful. > But does it need to be a user Directive? I still

Re: New ServerUID directive

On Fri, Feb 2, 2018 at 3:44 PM, Stefan Eissing >> <stefan.eiss...@greenbytes.de> wrote: >>> >>> >>>> Am 02.02.2018 um 15:42 schrieb Yann Ylavic <ylavic@gmail.com>: >>>> >>>> On Fri, Feb 2, 2018 at 3:25 PM, Plüm, Rüdiger, Vodafone Group &

Re: New ServerUID directive

> On Feb 2, 2018, at 9:42 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > >> Am 02.02.2018 um 15:25 schrieb Plüm, Rüdiger, Vodafone Group >> <ruediger.pl...@vodafone.com>: >> >> >> >>> -Ursprüngliche Na

Re: [Bug 62044] shared memory segments are not found in global list, but appear to exist in kernel.

To be honest, I don't think we ever envisioned an actual environ where the config files change every hour and the server gracefully restarted... I think our working assumptions have been that actual config file changes are "rare", hence the number of modules that allow for "on-the-fly"

Re: New ServerUID directive

Why? If it is designed to not change between restarts then there are much easier ways to be unique, which it kinda already is, considering the actual structs being used. Also, this seems like unnecessary admin overhead for the webmaster... if there is a need for such an ID, httpd should provide

Re: [Bug 62044] shared memory segments are not found in global list, but appear to exist in kernel.

FWIW, the id is supposed to be somewhat unique if the config DOES change, hence the use of the line number as part of the hash... In other words, if the config file itself is changed, we want to create a new id because we have no idea how to match up the "old" config in shm and the "new" config

Re: svn commit: r1822806 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c

:) > On Jan 31, 2018, at 9:25 AM, yla...@apache.org wrote: > > Author: ylavic > Date: Wed Jan 31 14:25:53 2018 > New Revision: 1822806 > > URL: http://svn.apache.org/viewvc?rev=1822806=rev > Log: > Revert r1822800 and r1822804. > > All was already there, I just misread name vs sname :/ > > >

Re: svn commit: r1822341 - in /httpd/httpd/trunk: CHANGES modules/slotmem/mod_slotmem_shm.c

OK, I'll hold off on any patching since it looks like you are working on this. > On Jan 28, 2018, at 6:49 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Sun, Jan 28, 2018 at 8:23 PM, Jim Jagielski <j...@jagunet.com> wrote: >> >> >>> On Jan

Re: svn commit: r1822341 - in /httpd/httpd/trunk: CHANGES modules/slotmem/mod_slotmem_shm.c

> On Jan 27, 2018, at 9:14 AM, Yann Ylavic wrote: > But this change (r1822341) means that SHMs are not reused on graceful > restart, unless persisted. If that's the case, then that's a non-starter. Are you sure?

Re: shared memory segment issue in 2.4.29

Hmmm... It looks like SLOTMEM_UNLINK_SEMANTIC might do exactly what we want. > On Jan 26, 2018, at 9:25 AM, Jim Jagielski <j...@jagunet.com> wrote: > > I think Eric is on the right track there... > >> On Jan 25, 2018, at 6:04 PM, Mark Blackman <m...@exonetric.com>

Re: shared memory segment issue in 2.4.29

I think Eric is on the right track there... > On Jan 25, 2018, at 6:04 PM, Mark Blackman wrote: > > Hi, > > Any chance I could persuade anyone on the list to look over > https://bz.apache.org/bugzilla/show_bug.cgi?id=62044 >

PROXY and mod_proxy_uwsgi

It would be super wonderful if these were in the next, upcoming release. Anyone have the time and interest to test and cast votes??

Re: can we haz backports?

oing up. For >> this to happen, two backports need 1(!) more vote: >> >> 1. core/mod_ssl: Add new flag int to module struct. >> existing votes: icing, ylavic >> 2. mod_md: backport of ACME (Let's Encrypt) support. >> existing votes: icing, jim >>

Re: Align worker's worker's fdqueue with event's?

> On Jan 12, 2018, at 7:32 AM, Eric Covener wrote: > > On Fri, Jan 12, 2018 at 6:51 AM, Yann Ylavic > wrote: >> A bit orthogonal, I'd also like to sync 2.4.x "event" with trunk's >> w.r.t. cosmetic changes before (and to

Re: listener thread not exiting cleanly on OSX on trunk

Let me take a look... I haven't built trunk for 1-2 weeks What version of OSX and Xcode are you using? > On Jan 10, 2018, at 2:13 PM, Eric Covener wrote: > > I'm new to OSX. For my httpd sandbox, I notice "apachectl stop" has to > forcibly kill children. When I caught one

Time for 2.4.30? (Was: Re: 2.4.x STATUS needs you!)

As we get settled into the new year, it seems a good time to think about a 2.4.30 release in the coming week or so. Lots of good stuff currently in 2.4.30-dev and even more good stuff in STATUS awaiting a single vote! Let's see if we can clean-up STATUS, get 2.4.30-dev into fantastic shape, and

Re: Mistaken attributions?

> On Dec 15, 2017, at 11:26 AM, William A Rowe Jr wrote: > > Actually remoteip isn't a showstopper... I find it demotivating and against > the spirit of httpd development, but am NOT vetoing it, and was showing an > example of proper form when attribution is desired. > >

Re: mod_proxy_uwsgi build errors

> On Dec 15, 2017, at 7:06 AM, Jim Jagielski <j...@jagunet.com> wrote: > > >> On Dec 13, 2017, at 2:49 PM, Ruediger Pluem <rpl...@apache.org> wrote: >> >> >> >> On 12/13/2017 04:27 PM, Steffen wrote: >>> I know, for example:

Re: mod_proxy_uwsgi build errors

> On Dec 13, 2017, at 2:49 PM, Ruediger Pluem wrote: > > > > On 12/13/2017 04:27 PM, Steffen wrote: >> I know, for example: >> >> util_expr_scan.c > > At least this one includes inttypes.h which seems according to the comments > is only available on C99. > Should we

Re: mod_proxy_uwsgi build errors

Who is using C99?? > On Dec 13, 2017, at 2:07 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > C99 is promiscuous. > > I thought we were holding to C89 on the 2.4 branch? > > On Dec 13, 2017 09:23, "Jim Jagielski" <j...@jagunet.com > <mai

Re: 2.4.x STATUS needs you!

> On Dec 14, 2017, at 11:31 AM, William A Rowe Jr wrote: > > It is good to see you share my concern about unreleased code for > a change. I share it all the time... That's why I work on getting back ports into 2.4.x as diligently as I do.

Re: 2.4.x STATUS needs you!

My own 2c is that I don't really care that much *where* the functionality exists, just that we actually ship it. It's been almost a year since I reached out to the orig author and asked about moving/donating the code to the ASF, and they readily agreed. To have it just sit around, un-released, for

Re: mod_proxy_uwsgi build errors

We use uint8_t numerous places elsewhere. > On Dec 13, 2017, at 9:44 AM, Steffen <i...@apachelounge.com> wrote: > > > @jim > > You adjusted uint16_t > > Still errors: > > > mod_proxy_uwsgi.c(186): warning C4267: '=': conversion from 'size_t' to

Re: 2.4.x STATUS needs you!

tml/b79ff329bb6163bb63d1284696360385313a402a6a70604459604e48@%3Cdev.httpd.apache.org%3E> Apologies on the mistake. > On Dec 13, 2017, at 7:53 AM, Jim Jagielski <j...@jagunet.com> wrote: > > Hmmm > > > > > https://lists.apache.org/list.html?c...@httpd.apache.org:lte=24M:proxyprotocol >

Re: 2.4.x STATUS needs you!

> On Wed, Dec 13, 2017 at 6:17 AM, Jim Jagielski <j...@jagunet.com> wrote: >> >> On Dec 13, 2017, at 1:02 AM, Jordan Gigov <colad...@gmail.com> wrote: >> >> On 12 December 2017 at 11:32, Stefan Eissing <stefan.eiss...@greenbytes.de> >> wrot

Re: 2.4.x STATUS needs you!

> On Dec 13, 2017, at 12:45 AM, William A Rowe Jr wrote: > > On Tue, Dec 12, 2017 at 3:32 AM, Stefan Eissing > wrote: >> Fellow Apache developers: if we want to make an X-mas 2.4 release for the >> people on this planet, the backports in

Re: 2.4.x STATUS needs you!

> On Dec 13, 2017, at 1:02 AM, Jordan Gigov wrote: > > On 12 December 2017 at 11:32, Stefan Eissing > wrote: > Fellow Apache developers: if we want to make an X-mas 2.4 release for the > people on this

Re: mod_md and ManagedDomain

ty has tested/participated from the beginning. I do not > know how much is tested on other platforms by users. > > From now on I prefer to discuss issues/requests here at this list. And I like > to see test reports from non-windows platforms. > > @Jim In status I see you

Re: mod_md and ManagedDomain

I am a SUPER +1 on the design, architecture, etc... As far as the naming, it seems like a bikeshed to me... JFDI ;) > On Dec 11, 2017, at 5:08 AM, Stefan Eissing > wrote: > > >> Am 08.12.2017 um 19:35 schrieb William A Rowe Jr : >> >> On

Re: mod_md and ManagedDomain

+1! > On Dec 4, 2017, at 8:16 AM, Stefan Eissing > wrote: > > Not much input regarding this naming change. Personally, I like to keep > ' > I propose the following changes: > > 1. The simple, single line 'ManagedDomain' will be renamed

Re: mod_md backports and happy turkey day

FWIW, I'd like to see us maybe do a nice solid 2.4.30 around the end of the year which includes mod_md and some other useful backports.

Re: PHP test cases

We still have tests for imagemaps so I'm not sure I see the rush in removing support for tests of "relatively" older version of PHP ;) I'm sure some of our users are stuck w/ older versions. > On Nov 28, 2017, at 6:32 PM, Rich Bowen wrote: > > > > On Tue, Nov 21, 2017,

Re: Let's Encrypt Feature Release

+1 from me!! > On Nov 15, 2017, at 4:59 AM, Stefan Eissing > wrote: > > Now that Gregg has landed Windows build support in trunk (yay!), I would > really like us to include the Let's Encrypt Support in the next 2.4 release > as an experimental mod_md plus the

Re: We have soon 5 SVN repo's

Thx for the clarification. > On Nov 6, 2017, at 2:34 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Mon, Nov 6, 2017 at 12:44 PM, Jim Jagielski <j...@jagunet.com > <mailto:j...@jagunet.com>> wrote: >> >>> On Nov 6, 2017, at 12:18 PM,

Re: We have soon 5 SVN repo's

> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr wrote: > > Reiterating again, that we disagree about who our preferred > approaches are serving and they are disingenuous toward. > Again, a value judgement. > Assuming we go ahead and tag 2.5.0, what is your intention

Re: We have soon 5 SVN repo's

> On Nov 5, 2017, at 9:39 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Nov 5, 2017 12:21, "Jim Jagielski" <j...@jagunet.com > <mailto:j...@jagunet.com>> wrote: > > Sorry Bill, but that's not right. trunk is not a "branch"

Re: We have soon 5 SVN repo's

> On Nov 4, 2017, at 11:44 PM, William A Rowe Jr wrote: > > It is safer. It is incredibly time consuming to effectively perform > a full audit of the state of trunk vs current. If we were to take this > approach, it seems necessary to revert all of the unaccepted > changes

Re: We have soon 5 SVN repo's

> On Nov 4, 2017, at 11:44 PM, William A Rowe Jr wrote: > >> > > It is safer. It is incredibly time consuming to effectively perform > a full audit of the state of trunk vs current. If we were to take this > approach, it seems necessary to revert all of the unaccepted >

Re: We have soon 5 SVN repo's

> On Nov 4, 2017, at 6:43 PM, Helmut K. C. Tessarek > wrote: > > On 2017-11-04 18:25, Graham Leggett wrote: >> If you aren’t willing to do the four things you’ve mentioned above, >> your code has pretty much disqualified itself from consideration, and >> what you want is

Re: We have soon 5 SVN repo's

> On Nov 4, 2017, at 6:03 AM, Steffen wrote: > > Soon we have: > > branches 2.4.x > trunk > 2.5.0-alpha > patches/2.4.x > patches/trunk > > Please a procedure: where and when do we apply patches/fixes. IMO, the ones w/ the LEAST clarity are the ones related to

mod_proxy_uwsgi.c

My plan is to work on a backport proposal for mod_proxy_uwsgi.c and an updated one for PROXY support...

Re: Pruning working branches (Was: Re: Why?)

Are there anything of "value" in any of those branches? If not, prune away! > On Oct 24, 2017, at 9:11 AM, William A Rowe Jr wrote: > > On Tue, Oct 24, 2017 at 3:28 AM, Steffen wrote: >> >> On Tuesday 24/10/2017 at 10:26, Steffen wrote: >> >> Can

Re: Thoughts on 2.5.0

> On Oct 24, 2017, at 10:20 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 10/24/2017 11:45 AM, William A Rowe Jr wrote: >> On Tue, Oct 24, 2017 at 12:35 PM, Jim Jagielski <j...@jagunet.com> wrote: >>> That is way when we backport we transition to RTC

Re: [Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines

> On Oct 25, 2017, at 7:48 AM, Eric Covener wrote: > >> The guidelines are fine with me and seem to make sense to get to an API >> stable next GA. It is good to have a list of 'To Do's' that needs to be done >> before next GA. That helps people looking for interesting and

Re: svn commit: r1813167 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.c

The only reasons we keep those factors as ints rather than floats are: 1. We can't change the struct fields in 2.4.x 2. The rationale that int based operations will "always" be faster than floating point 2.5.0 doesn't suffer from #1. We can break API/ABI if there's a good reason. And #2

Re: svn commit: r1813167 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.c

> On Oct 24, 2017, at 4:16 PM, Yann Ylavic wrote: > > > Meaning that we now have a granularity of 10KB (instead of previous > 100B, max) before a balancer member can take over the previous one (I > wondered why several successive small requests were always reaching > the

Re: svn commit: r1813167 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.c

is what we wanted. > On Oct 24, 2017, at 4:16 PM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Tue, Oct 24, 2017 at 3:28 PM, Jim Jagielski <j...@jagunet.com> wrote: >> I don't understand this patch. It looks like we are no lingering externally >> representin

Re: Thoughts on 2.5.0

> > I am not doing it for 2.4.x, and will continue not to do it for 2.4.x, > because I won't contribute to further destabilizing 2.4.x current > releases. So you refuse to help stabilize the 2.4.x tree, but then complain that the 2.4.x tree is unstable. OK. That's fine. Your cycles are yours to

Re: Thoughts on 2.5.0

> That's what commit-then-review means. If you failed to > review it, you now have a six year knowledge gap and review to > conduct. That's not sustainable, nobody at the project has that kind > of time. "Review" does not have a time limit. Anyone can, and should, review whenever they wish.

Thoughts on 2.5.0

I would like to start a discussion on 2.5.0 and give some insights on my thoughts related to it. First and foremost: there is cool stuff in 2.5.0 that I really, REALLY wish were in a releasable, usable artifact. Up to now, we've been doing these as backports to the 2.4.x tree with, imo at least,

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

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

[ANNOUNCE] Apache HTTP Server 2.4.29 Released

Apache HTTP Server 2.4.29 Released October 23, 2017 The Apache Software Foundation and the Apache HTTP Server Project are pleased to announce the release of version 2.4.29 of the Apache HTTP Server ("Apache"). This version of Apache is our latest GA release of the new generation

[CLOSED] Re: [VOTE] Release Apache httpd 2.4.29 as GA

Will more than the required 3 +1 (binding) votes and some other unbinding +1 votes, and no -1s, I call this vote not only CLOSED but also PASSED. Thx to all!

[VOTE] Release Apache httpd 2.4.29 as GA

The pre-release test tarballs for Apache httpd version 2.4.29 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.29 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the

Re: expr changes and 2.4.29-dev

OK, this does not look like a regression, but instead a test not expected to PASS under 2.4 (yet). So I am thinking that a T of 2.4.29 is now a Go. I will likely T later on today, say ~3pm eastern.

Re: expr changes and 2.4.29-dev

verbose: # writing file: /Users/jim/src/asf/code/stable/httpd-test/framework/t/htdocs/apache/expr/.htaccess Error log should not have 'Internal evaluation error' or 'flex scanner jammed' entries, found 1: flex scanner jammed not ok 27 Expected return code 200, got 500 for '%{tolower:"

expr changes and 2.4.29-dev

HEAD of 2.4 now has errors with the test framework: t/apache/expr_string.t .. 1/32 # Failed test 27 in t/apache/expr_string.t at line 73 fail #10 # Failed test 28 in t/apache/expr_string.t at line 83 fail #9 # Failed test 29 in t/apache/expr_string.t at line 87 t/apache/expr_string.t

Re: svn commit: r1812303 - /httpd/httpd/branches/2.4.x/STATUS

Let's keep :) > On Oct 16, 2017, at 11:54 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > Seems Jim is +0 to back out and I'm +0 to keep. First > strong opinion wins so we can get to tagging :) > > Absolute consensus on informing our apr, and httpd > builders

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

I'd say we use STATUS to keep track

Re: svn commit: r1812303 - /httpd/httpd/branches/2.4.x/STATUS

The APR fix just handles macOS w/ Xcode9 or clang 5.0.0. -Werror can be set "externally" and whether or not we should actually die is debatable. But considering that AC_CHECK_LIB will never use function prototypes, the long term solution may be to simply never use that. I'm +0 on removing the

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

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

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

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.

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

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

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

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

Re: [CLOSED] [VOTE] Release Apache httpd 2.4.28 as GA

Hrm... looks like it was already announced? At least the website sez it was, and it looks like an Email was sent to announce@a.o but I'm not seeing anything on the httpd lists.

Re: [CLOSED] [VOTE] Release Apache httpd 2.4.28 as GA

FYI: I'll be announcing tomorrow

Re: [CLOSED] [VOTE] Release Apache httpd 2.4.28 as GA

Sure. Anyone who wants to announce, please do so!! :) > On Oct 3, 2017, at 11:47 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Tue, Oct 3, 2017 at 6:46 AM, Jim Jagielski <j...@jagunet.com> wrote: >> With more than the required 3 +1 (binding) votes, and no

[CLOSED] Re: [VOTE] Release Apache httpd 2.4.28 as GA

With more than the required 3 +1 (binding) votes, and no vetos, I call this vote CLOSED with the result that the vote passes. I will start moving the artifacts for mirror sync and let's plan on announcing on Friday. > On Sep 25, 2017, at 8:13 AM, Jim Jagielski <j...@jagunet.com&

Re: [VOTE] Release Apache httpd 2.4.28 as GA

Leaving it open for another ~24 hours... I don't want to go thru the process of "releasing" it if someone is going to gripe after the fact. FWIW: I'll be at Grace Hopper the rest of the week so my online time will be sporadic. > On Sep 30, 2017, at 4:23 PM, Jim Jagielski <j...@ja

Issue with Xcode/clang-900 and --enable-maintainer-mode

I just upgraded to Xcode 9, which installs clang-900[1]. I noticed that this now breaks several aspects of our configure system when using --enable-maintainer-mode due to issues with AC_CHECK_LIB. In particular, -Werror,-Wstrict-prototypes Note for example, this error: configure:22140:

Re: [VOTE] Release Apache httpd 2.4.28 as GA

Can we discuss this on a sep thread. The question now is really whether 2.4.28 is DOA or not. I'm not seeing any -1s... nor have I seen any more info related to the assert bug (but I admit I may have missed that)

Re: [VOTE] Release Apache httpd 2.4.28 as GA

modules/foo into > the /I path includes list so this can't happen again during 2.4, and > hopefully not until 20 year old build logic is discarded. One less thing to > worry about or pre-review when RM's loudly announce an upcoming tag. > > > > > On Sep 25, 2017 07:13,

Re: [VOTE] Release Apache httpd 2.4.28 as GA

fdqueue.c, line 390, assertion "!((queue)->nelts == (queue)->bounds)" failed > On Sep 27, 2017, at 11:04 AM, Luca Toscano wrote: > > Hi Stefan, > > 2017-09-27 17:32 GMT+02:00 Stefan Eissing : > On my h2 load tests, the server sometimes

Re: [VOTE] Release Apache httpd 2.4.28 as GA

> On Sep 25, 2017, at 7:13 AM, Jim Jagielski <j...@jagunet.com> wrote: > > The pre-release test tarballs for Apache httpd > version 2.4.28 can be found at the usual place: > > http://httpd.apache.org/dev/dist/ > > I'm calling a VOTE on releasing t

[VOTE] Release Apache httpd 2.4.28 as GA

The pre-release test tarballs for Apache httpd version 2.4.28 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.28 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the

Re: Time for 2.4.28 ?

I'll do a T on Monday then... This give as the weekend, just in case. > On Sep 23, 2017, at 7:39 AM, Yann Ylavic <ylavic@gmail.com> wrote: > > On Fri, Sep 22, 2017 at 7:52 PM, Eric Covener <cove...@gmail.com> wrote: >> On Fri, Sep 22, 2017 at 1:25 PM, Jim Jagiels

Re: Time for 2.4.28 ?

We can wait. No reason to rush if we can hold off for a bit and ensure that 2.4.28 is as ready to go as possible. > On Sep 22, 2017, at 1:23 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Fri, Sep 22, 2017 at 7:06 AM, Jim Jagielski <j...@jagunet.com> wrote:

Re: Time for 2.4.28 ?

STATUS looks clean. Hoping to do a T this afternoon, eastern, unless I hear any objections or concerns re: timing. Cheers!

Re: Time for 2.4.28 ?

Looks like we need 1 more vote on it for it to be folded in on time for 2.4.28. > On Sep 19, 2017, at 1:48 PM, Jim Jagielski <j...@jagunet.com> wrote: > > There have been no issues w/ that on trunk... will > fold into 2.4 and do some stress testing over the next > 2 days.

Re: Time for 2.4.28 ?

There have been no issues w/ that on trunk... will fold into 2.4 and do some stress testing over the next 2 days. > On Sep 19, 2017, at 12:58 PM, Yann Ylavic wrote: > > On Tue, Sep 19, 2017 at 6:41 PM, Stefan Priebe - Profihost AG > wrote: >> >> Do

Time for 2.4.28 ?

Seems like a good time to push for a 2.4.28 T by end-of-week. Review STATUS! Test and Vote on backports! Comments?

Re: Interest in a uwsgi mod_proxy module?

They have relicensed the module to ALv2! I am requesting explicit OK from them for us to snag the module :) https://github.com/unbit/uwsgi/issues/1636

Re: Interest in a uwsgi mod_proxy module?

Some great news! They are willing to relicense and donate their existing module to the ASF! Is this someone we would like to accept? For completeness, please review: https://incubator.apache.org/ip-clearance/ Cheers!

Re: Interest in a uwsgi mod_proxy module?

I see that their module is under copyleft, so I want to be careful in that I am as "clean room" as possible ;) But +1 on reaching out. > On Sep 12, 2017, at 9:00 AM, Luca Toscano <toscano.l...@gmail.com> wrote: > > Hi Jim, > > 2017-09-11 17:12 GMT+02:00 Jim Jagie

Interest in a uwsgi mod_proxy module?

I am thinking about putting together a mod_proxy_uwsgi to complement our current roster of (sub)modules... I don't want to spend the cycles unless there is some interest in having such a beast in our core distro. Is there?

Re: A little nit

Sounds good to me :) > On Aug 4, 2017, at 9:02 PM, Jim Riggs <apache-li...@riggs.me> wrote: > >> On 3 Aug 2017, at 08:30, Jim Jagielski <j...@jagunet.com> wrote: >> >> It's just GUI magic... Basically, it will internally take '1.1' and >> convert

<    1   2   3   4   5   6   7   8   9   10   >