Re: Problems using Apache::Test on Debian (and Ubuntu)

Are you suggesting that people who want to run tests that use Apache::Test should know that they have to source /etc/apache2/envvars first? Or that I should patch Apache::Test to source that file instead of guessing which vars to set? That file unsets HOME on Ubuntu and changes LANG to C, so if

Re: Problems using Apache::Test on Debian (and Ubuntu)

That seems like a reasonable solution. Do you think we should switch to using apachectl everywhere, or try to detect whether it's necessary? Sam On Mon, Mar 6, 2017 at 12:46 PM, Eric Covener wrote: > On Mon, Mar 6, 2017 at 3:23 PM, Stefan Fritsch wrote:

Re: Problems using Apache::Test on Debian (and Ubuntu)

On Mon, Mar 6, 2017 at 3:23 PM, Stefan Fritsch wrote: > These are set in /etc/apache2/envvars. You should simply source that file > before running the test suite. Also, you can pass another config file name to > the test suite. Maybe this helps: I can't remember/find the parm,

Re: Problems using Apache::Test on Debian (and Ubuntu)

On Friday, 3 March 2017 22:59:10 CET Sam Tregar wrote: > Hello all. I've been working on getting Apache::Test running on Debian and > it's not going well. One problem seems to be that Debian's system Apache > conf is not named what Apache::Test thinks it should be named (apache2.conf > vs

Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4

On 03/06/2017 09:41 AM, Jacob Champion wrote: On 03/06/2017 04:36 AM, Jim Jagielski wrote: So config.m4 should look for that API then, right? Yup. I don't think it's *quite* as easy as just looking for the _openlib call, since that's an implementation detail (the compatibility APIs are macros

Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4

On 03/06/2017 09:12 AM, William A Rowe Jr wrote: The fix seems simple. Autoconf test for a usable luaL_openlib. If that fails, keep rolling on to the next candidate. See my response to Jim -- not quite that simple, but it should be close, I think. I'll try a patch. Wondering why we are

Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4

On 03/06/2017 04:36 AM, Jim Jagielski wrote: On Mar 3, 2017, at 2:03 PM, Jacob Champion wrote: To try to clear up what's going on: Ubuntu's (and as I understand it, Debian's) version of liblua5.3 has not been compiled with some of the optional 5.1/2 compatibility APIs.

Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4

The fix seems simple. Autoconf test for a usable luaL_openlib. If that fails, keep rolling on to the next candidate. Wondering why we are making all this up still, when pkgconfig will give us all the correct [c|cpp|ld]flags, per each distro's quirks. On Fri, Mar 3, 2017 at 1:03 PM, Jacob

Re: Read scattered to gather send (was [too long]: httpd 2.4.25, mpm_event, ssl: segfaults)

This really belongs in dev@apr... Adding it now. If we are *really* drastically changing this core aspect of pool allocation, we should reconsider my thoughts related to more granular mutex related to anytime we alloc from a pool to allow for, if required/desired, full thread safety not just when

Re: Read scattered to gather send (was [too long]: httpd 2.4.25, mpm_event, ssl: segfaults)

Hello Yann, Just one question at this time: It appears that your changes to httpd will depend on new functions in APR-util which would require a new release of APR-util (and APR as well?). What is your plan for handling this dependency? Thanks, Mike Rumph On 3/3/2017 11:38 AM, Yann Ylavic

Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4

> On Mar 3, 2017, at 2:03 PM, Jacob Champion wrote: > > On 03/03/2017 10:27 AM, Jim Jagielski wrote: >> But what if you use the full path? > > That would work if I'd compiled Lua myself and installed into a separate > prefix, but on my machine all the lua versions are

Re: svn commit: r1785116 - in /httpd/httpd/branches/2.4.x: ./ modules/lua/config.m4

> On Mar 3, 2017, at 2:03 PM, Jacob Champion wrote: > > > To try to clear up what's going on: Ubuntu's (and as I understand it, > Debian's) version of liblua5.3 has not been compiled with some of the > optional 5.1/2 compatibility APIs. mod_lua relies on them, and it