Re: Time for 2.4.5
Am 24.06.2013 20:16, schrieb Jim Jagielski: > I propose a release somewhere around the 4th of July, > to celebrate our independence from proprietary s/w! > > I'll RM a snapshot for testers at http://httpd.apache.org/dev/dist/ would be fine, it would take me 5 minutes to rebuild our RPM from it and i guess other people too signature.asc Description: OpenPGP digital signature
Time for 2.4.5
I propose a release somewhere around the 4th of July, to celebrate our independence from proprietary s/w! I'll RM.
Re: Time for 2.4.5 ??
That is true actually, new test system - will need to look at why 2.4.4 stumbled over that, while 2.4.x did not. Many thanks for the feedback. On Fri, Jun 7, 2013 at 12:00 AM, Eric Covener wrote: > On Thu, Jun 6, 2013 at 5:56 PM, Michael Felt wrote: > > consider this a curiosity - but using the same configure command for > 2.4.4 > > and 2.4.x - with 2.4.x the filter mod_deflate.c gets included in libexec > in > > version 2.4.4, but not in 2.4.x > > > > Is this expected? the mod_deflate.so is no longer included (by > "default")? > > Maybe your current env doesn't find zlib/zlib headers? Check config.log. >
Re: Time for 2.4.5 ??
On Thu, Jun 6, 2013 at 5:56 PM, Michael Felt wrote: > consider this a curiosity - but using the same configure command for 2.4.4 > and 2.4.x - with 2.4.x the filter mod_deflate.c gets included in libexec in > version 2.4.4, but not in 2.4.x > > Is this expected? the mod_deflate.so is no longer included (by "default")? Maybe your current env doesn't find zlib/zlib headers? Check config.log.
Re: Time for 2.4.5 ??
consider this a curiosity - but using the same configure command for 2.4.4 and 2.4.x - with 2.4.x the filter mod_deflate.c gets included in libexec in version 2.4.4, but not in 2.4.x Is this expected? the mod_deflate.so is no longer included (by "default")? using: ./configure \ --enable-layout=$LAYOUT \ --with-apr=$apr_config \ --with-apr-util=$apu_config \ --enable-mpms-shared=all \ --enable-mods-shared=all \ --disable-lua is what I use to configure 2.4.X for AIX note: there are also some additions, but I am mainly curious about what does not get built, but the source still exists. On Mon, Jun 3, 2013 at 7:47 PM, Shahid khan wrote: > > On Jun 3, 2013 11:11 PM, "Michael Felt" wrote: > >> > >> I have meanwhile all the compiler warnings reduced down to one: > >> .\lua_request.c(574) : warning C4244: 'return' : conversion from > 'apr_off_t' to 'int', possible loss of data > >> > > Nice work! :) > > > > >
Re: Time for 2.4.5 ??
On Jun 3, 2013 11:11 PM, "Michael Felt" wrote: >> >> I have meanwhile all the compiler warnings reduced down to one: >> .\lua_request.c(574) : warning C4244: 'return' : conversion from 'apr_off_t' to 'int', possible loss of data >> > Nice work! :) > >
Re: Time for 2.4.5 ??
> > I have meanwhile all the compiler warnings reduced down to one: > .\lua_request.c(574) : warning C4244: 'return' : conversion from > 'apr_off_t' to 'int', possible loss of data > > Nice work! :)
Re: Time for 2.4.5 ??
On 25.05.2013 05:46, Guenter Knauf wrote: Found another small docu bug: r:unescape(string) -- Unescapes an URL-escaped string: local url = "http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5" local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 & 4 + 5' the function call should here be r:unescape(url) ... another one missing from the docs: r:construct_url(string) -- Constructs an URL from an URI local url = r:construct_url(r.uri) Gün.
Re: Time for 2.4.5 ??
Hi Daniel, On 25.05.2013 05:46, Guenter Knauf wrote: On 25.05.2013 02:06, Guenter Knauf wrote: On 24.05.2013 23:45, Daniel Gruno wrote: That's fine by me, I'm not married to 'sleep' (although I do like a good nap) hehe, ok; I look into it soon. done. Found another small docu bug: r:unescape(string) -- Unescapes an URL-escaped string: local url = "http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5" local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 & 4 + 5' the function call should here be r:unescape(url) ... I have meanwhile all the compiler warnings reduced down to one: .\lua_request.c(574) : warning C4244: 'return' : conversion from 'apr_off_t' to 'int', possible loss of data this is a somehwat tricky one, and I'm not sure whats the best way to fix it; clearly a cast wouldnt help here since r->remaining is apr_off_t, so a cast to int would indeed be a loss of data ... so the function needs to return the 64-bit apr_off_t: Index: lua_request.c === --- lua_request.c (revision 1486269) +++ lua_request.c (working copy) @@ -569,7 +569,7 @@ return r->useragent_ip; } -static int req_remaining_field(request_rec *r) +static apr_off_t req_remaining_field(request_rec *r) { return r->remaining; } but then the problem would be shifted to req_dispatch() where we only have APL_REQ_FUNTYPE_INT - should we add there a new type APL_REQ_FUNTYPE_INT64? Or do you have a better idea? Gün.
Re: Time for 2.4.5 ??
Can some of the proposed backports lacking a single vote get sum luv?
Re: Time for 2.4.5 ??
On Tue, May 28, 2013 at 04:14:55PM +0200, Graham Leggett wrote: >> Let me again ask for backports of r1368121, r1388447 and r1389339 >> from trunk; they are required to build mpm-itk without patching Apache. > Proposed. Thanks! /* Steinar */ -- Homepage: http://www.sesse.net/
Re: Time for 2.4.5 ??
On 28 May 2013, at 3:33 PM, "Steinar H. Gunderson" wrote: > Let me again ask for backports of r1368121, r1388447 and r1389339 > from trunk; they are required to build mpm-itk without patching Apache. Proposed. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Time for 2.4.5 ??
On Wed, May 22, 2013 at 02:20:03PM -0400, Jim Jagielski wrote: > I would be nice, imo, to start thinking about a 2.4.5 > release Real Soon Now. We have lots of stuff added and > fixed in 2.4.5-dev and even more fun stuff in STATUS. Let me again ask for backports of r1368121, r1388447 and r1389339 from trunk; they are required to build mpm-itk without patching Apache. Surely when it is acceptable to copy all of mod_ssl from trunk, it must be possible to add three small hooks? :-) /* Steinar */ -- Homepage: http://www.sesse.net/
Re: Time for 2.4.5 ??
Works for me. 2.4 branch was quite busy this holiday weekend, it probably needs a bit of time to stabilize. On Tue, May 28, 2013 at 6:26 AM, Jim Jagielski wrote: > > On May 24, 2013, at 4:22 PM, William A. Rowe Jr. > wrote: > > > On Wed, 22 May 2013 14:20:03 -0400 > > Jim Jagielski wrote: > > > >> I would be nice, imo, to start thinking about a 2.4.5 > >> release Real Soon Now. We have lots of stuff added and > >> fixed in 2.4.5-dev and even more fun stuff in STATUS. > >> > >> I'll RM. > > > > What is your thought on RSN? > > I was thinking a T&R sometime next week. > >
Re: Time for 2.4.5 ??
On May 24, 2013, at 4:22 PM, William A. Rowe Jr. wrote: > On Wed, 22 May 2013 14:20:03 -0400 > Jim Jagielski wrote: > >> I would be nice, imo, to start thinking about a 2.4.5 >> release Real Soon Now. We have lots of stuff added and >> fixed in 2.4.5-dev and even more fun stuff in STATUS. >> >> I'll RM. > > What is your thought on RSN? I was thinking a T&R sometime next week.
Re: Time for 2.4.5 ??
+ is not used in url-encoding. + is used in application/x-www-form-urlencoded encoding. So I assume this function has implemented unescaping application/x-www-form-urlencoded. For regular URL-encoding, space is encoded as %20. On Fri, May 24, 2013 at 11:46 PM, Guenter Knauf wrote: > Hi Daniel, > > On 25.05.2013 02:06, Guenter Knauf wrote: > >> On 24.05.2013 23:45, Daniel Gruno wrote: >> >>> That's fine by me, I'm not married to 'sleep' (although I do like a good >>> nap) >>> >> hehe, ok; I look into it soon. >> > done. > > Found another small docu bug: > > r:unescape(string) -- Unescapes an URL-escaped string: > > local url = "http%3a%2f%2ffoo.bar%2f1+2+3+**%26+4+%2b+5" > local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 & 4 + 5' > > the function call should here be r:unescape(url) ... > > Gün. > > >
Re: Time for 2.4.5 ??
On 5/24/2013 2:03 PM, Guenter Knauf wrote: ATM I think this is not needed - from what I tested during past weeks the current trunk code is at least as good / bad as what is already in 2.4.x branch - so copying over trunk to 2.4.x seems an improvement to me due to various bug fixes beside the added new stuff. I'm +1 to this approach.
Re: Time for 2.4.5 ??
Hi Daniel, On 25.05.2013 02:06, Guenter Knauf wrote: On 24.05.2013 23:45, Daniel Gruno wrote: That's fine by me, I'm not married to 'sleep' (although I do like a good nap) hehe, ok; I look into it soon. done. Found another small docu bug: r:unescape(string) -- Unescapes an URL-escaped string: local url = "http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5" local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 & 4 + 5' the function call should here be r:unescape(url) ... Gün.
Re: Time for 2.4.5 ??
Hi Daniel, On 24.05.2013 23:45, Daniel Gruno wrote: I can only say +1 from me, we need consistency here :) great! That's fine by me, I'm not married to 'sleep' (although I do like a good nap) hehe, ok; I look into it soon. Optional: I really would like to also have DBM support in addition to the DBD support, but unfortunately I had not the time yet to look into it ... I've not looked in APR, but I assume this is something supported in there? Perhaps if you could come up with a sketch/mock api, we could get started on this? yes, see the apr_dbm.h header; SDBM is the only database we allways have even without any driver or external libs; it can be used f.e. for password storage (htdbm.c), and I think mod_dav makes use of it for its lock database; as usage example might serve mod_authn_dbm.c ... Gün.
Re: Time for 2.4.5 ??
On 05/24/2013 09:02 PM, Guenter Knauf wrote: > On 24.05.2013 14:40, Jim Jagielski wrote: >> There are a few things I'd like to see in 2.4.5, which would >> be significant for the 2.4.x release: >> >>o The mod_lua stuff > ok, after spending a bunch of hours during last weeks with testing > mod_lua mainly on Windows I've finally removed my blocking vote from > STATUS just now; nevertheless I feel that I did only test half of all > the new stuff, and therefore my vote is +0.5 only ... > some things which I see as outstanding are: > - removal of the export declarations since they are unneeded (I will > take a look into this during this weekend if nobody beats me) > - removal of some doubled code ( ap_lua_check_request_rec() ) > - another docu fix for r:sleep() --> r.sleep(); meanwhile I have a > stronger oppinion about this: I believe we should chage all functions to > r:function() in order to separate them more clearly from vars like > r.filename; I can only say +1 from me, we need consistency here :) further more I believe r.sleep() would be better renamed to > r.usleep() taking microseconds instead of having a r.sleep() and then > dealing with fractions of seconds - this way also the code would be > cleaner and no calculation of the passed-in value needed anymore, just > the value would get passed to apr_sleep(). > That's fine by me, I'm not married to 'sleep' (although I do like a good nap) > Optional: I really would like to also have DBM support in addition to > the DBD support, but unfortunately I had not the time yet to look into > it ... > I've not looked in APR, but I assume this is something supported in there? Perhaps if you could come up with a sketch/mock api, we could get started on this? > So how do we further proceed with mod_lua? There are certainly some > remaining issues, but it just takes too long for only 2 persons to find > them all; also I see with current code that it works fine when I compile > it with MSVC6 while compiled MSVC9 it crashes when things go wrong - not > sure yet if this is an issue with MSVC9 itself, or with the converted > projects ...; I ran into some issues with MSVC10/11, but they appear to have been fixed (though not 100% sure) - but I'm not a big Windows expert anymore :| I think we should now copy over the complete trunk code to > 2.4.x branch, and keep the status 'experimental' so that users are > warned that directives, functions, etc. might change even with an > otherwise stable release branch; > hopefully then when more users play with mod_lua we will make faster > progress with finding any further issues ... > > also given that currently only Daniel and I (and Gregg with some > testing) care about mod_lua I would like that we make an exception for > this module so that we can backport any further modifications and fixes > directly to the 2.4.x branch until we declare the module as stable and > non-experimental. > > Gün. > > > With regards, Daniel.
Re: Time for 2.4.5 ??
On 24.05.2013 22:14, William A. Rowe Jr. wrote: There are several others of us, but large patch sets are difficult to incorporate in our day-to-day build trees. What about a sandbox of all of the proposed deltas, either just the modules/lua/ branch or the entire tree if that isn't realistic. It's preferable to just svn switch that branch to the sandbox for some more active eyeballs looking at the thing. ATM I think this is not needed - from what I tested during past weeks the current trunk code is at least as good / bad as what is already in 2.4.x branch - so copying over trunk to 2.4.x seems an improvement to me due to various bug fixes beside the added new stuff. Gün.
Re: Time for 2.4.5 ??
On 24 May 2013, at 2:40 PM, Jim Jagielski wrote: > There are a few things I'd like to see in 2.4.5, which would > be significant for the 2.4.x release: > > o The mod_lua stuff > o the Websocket Proxy module (wstunnel) > o Performance-related patches (Event & mod_ssl, cache, etc) Pretty much all of the cache and proxy related proposals are fixes for RFC violations, detected courtesy of the CoAdvisor test suite. It would be goodness to get these out there. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Time for 2.4.5 ??
On Wed, 22 May 2013 14:20:03 -0400 Jim Jagielski wrote: > I would be nice, imo, to start thinking about a 2.4.5 > release Real Soon Now. We have lots of stuff added and > fixed in 2.4.5-dev and even more fun stuff in STATUS. > > I'll RM. What is your thought on RSN? Sometime Thurs-Sat timeframe late next week? It could be good to have a goal and then slip the whole thing 1 week exactly if we can't reach it. My schedule is now very flexible, so you choose :) I like the late-week roll so that weekday coders and weekend warriors can both put their hands on the candidate.
Re: Time for 2.4.5 ??
On Fri, 24 May 2013 21:02:04 +0200 Guenter Knauf wrote: > > also given that currently only Daniel and I (and Gregg with some > testing) care about mod_lua I would like that we make an exception > for this module so that we can backport any further modifications and > fixes directly to the 2.4.x branch until we declare the module as > stable and non-experimental. There are several others of us, but large patch sets are difficult to incorporate in our day-to-day build trees. What about a sandbox of all of the proposed deltas, either just the modules/lua/ branch or the entire tree if that isn't realistic. It's preferable to just svn switch that branch to the sandbox for some more active eyeballs looking at the thing.
Re: Time for 2.4.5 ??
On 24.05.2013 14:40, Jim Jagielski wrote: There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff ok, after spending a bunch of hours during last weeks with testing mod_lua mainly on Windows I've finally removed my blocking vote from STATUS just now; nevertheless I feel that I did only test half of all the new stuff, and therefore my vote is +0.5 only ... some things which I see as outstanding are: - removal of the export declarations since they are unneeded (I will take a look into this during this weekend if nobody beats me) - removal of some doubled code ( ap_lua_check_request_rec() ) - another docu fix for r:sleep() --> r.sleep(); meanwhile I have a stronger oppinion about this: I believe we should chage all functions to r:function() in order to separate them more clearly from vars like r.filename; further more I believe r.sleep() would be better renamed to r.usleep() taking microseconds instead of having a r.sleep() and then dealing with fractions of seconds - this way also the code would be cleaner and no calculation of the passed-in value needed anymore, just the value would get passed to apr_sleep(). Optional: I really would like to also have DBM support in addition to the DBD support, but unfortunately I had not the time yet to look into it ... So how do we further proceed with mod_lua? There are certainly some remaining issues, but it just takes too long for only 2 persons to find them all; also I see with current code that it works fine when I compile it with MSVC6 while compiled MSVC9 it crashes when things go wrong - not sure yet if this is an issue with MSVC9 itself, or with the converted projects ...; I think we should now copy over the complete trunk code to 2.4.x branch, and keep the status 'experimental' so that users are warned that directives, functions, etc. might change even with an otherwise stable release branch; hopefully then when more users play with mod_lua we will make faster progress with finding any further issues ... also given that currently only Daniel and I (and Gregg with some testing) care about mod_lua I would like that we make an exception for this module so that we can backport any further modifications and fixes directly to the 2.4.x branch until we declare the module as stable and non-experimental. Gün.
Re: Time for 2.4.5 ??
On Fri, May 24, 2013 at 8:40 AM, Jim Jagielski wrote: > There are a few things I'd like to see in 2.4.5, which would > be significant for the 2.4.x release: > > o The mod_lua stuff > o the Websocket Proxy module (wstunnel) > Could you provide some notes for testing wstunnel in a real-world scenario? Thanks! > o Performance-related patches (Event & mod_ssl, cache, etc) > > > -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Time for 2.4.5 ??
There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff o the Websocket Proxy module (wstunnel) o Performance-related patches (Event & mod_ssl, cache, etc)
Re: Time for 2.4.5 ??
On Wed, 22 May 2013 14:20:03 -0400 Jim Jagielski wrote: > I would be nice, imo, to start thinking about a 2.4.5 > release Real Soon Now. We have lots of stuff added and > fixed in 2.4.5-dev and even more fun stuff in STATUS. > > I'll RM. +1 and once this head-cold is clear, I'm now seeing daylight ahead and have cycles to RM our 'final' 2.0.65 and a freshened 2.2.25 using their most recent respective toolchains. That should put 2.0 to bed and catch 2.2 up with the rewrite log escaping.
Time for 2.4.5 ??
I would be nice, imo, to start thinking about a 2.4.5 release Real Soon Now. We have lots of stuff added and fixed in 2.4.5-dev and even more fun stuff in STATUS. I'll RM.