Re: The drive for 2.4.26

2017-04-29 Thread Stefan Eissing
Is this a Windows issue? I built with 1.1.0e on MacOS and apr 1.5 and saw no 
problems.

> Am 28.04.2017 um 22:26 schrieb Steffen :
> 
> I doubt now. It was based on a note in cvtdsp.pl. 
> 
> Maybe it is only a .dsp and xml change, which I can apply to 1.5. 
> 
> Maybe Gregg can shed some light on this ?
> 
> 
>> Op 28 apr. 2017 om 22:16 heeft William A Rowe Jr  het 
>> volgende geschreven:
>> 
>> Now that these are independent of one another, I think we can release before 
>> 1.6.x are released. We should just call out "New: OpenSSL 1.1.0 support! 
>> (Upcoming APR 1.6.x is required for this support.)
>> 
>> 
>> 
>>> On Apr 28, 2017 2:56 PM, "Steffen"  wrote:
>>> When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 1.1 
>>> not supported.
>>> 
>>> For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g  
>>> apr_crypto_openssl for mod_session crypto)
>>> 
>>> 
>>> > Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het 
>>> > volgende geschreven:
>>> >
>>> > It would be cool to have 2.4.26 released by ApacheCon, or even
>>> > by OSCON. There are, last I checked, 2 showstoppers on list for
>>> > 2.4.26... Anyway we could address them and shoot for a T maybe
>>> > next Weds?
>>> 


Re: The drive for 2.4.26

2017-04-29 Thread Steffen
Also no issue with apr_crypto_openssl and mod_session crypto ?

 Begin Message  
Group: gmane.comp.apache.devel 
MsgID:  

Is this a Windows issue? I built with 1.1.0e on MacOS and apr 1.5 and saw no 
problems.

>Am 28.04.2017 um 22:26 schrieb Steffen :
>
>I doubt now. It was based on a note in cvtdsp.pl. 
>
>Maybe it is only a .dsp and xml change, which I can apply to 1.5. 
>
>Maybe Gregg can shed some light on this ?
>
>
>>Op 28 apr. 2017 om 22:16 heeft William A Rowe Jr  het 
>>volgende geschreven:
>>
>>Now that these are independent of one another, I think we can release before 
>>1.6.x are released. We should just call out "New: OpenSSL 1.1.0 support! 
>>(Upcoming APR 1.6.x is required for this support.)
>>
>>
>>
>>>On Apr 28, 2017 2:56 PM, "Steffen"  wrote:
>>>When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 1.1 
>>>not supported.
>>>
>>>For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g  apr_crypto_openssl 
>>>for mod_session crypto)
>>>
>>>
Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het 
volgende geschreven:

It would be cool to have 2.4.26 released by ApacheCon, or even
by OSCON. There are, last I checked, 2 showstoppers on list for
2.4.26... Anyway we could address them and shoot for a T maybe
next Weds?
>>>



- End Message - 



Re: The drive for 2.4.26

2017-04-29 Thread William A Rowe Jr
On Apr 29, 2017 12:16 PM, "Gregg Smith"  wrote:


Once APR 1.6 is released my plan is to make the change permanent next 2.4.x
then making the need for that conversion unneeded.

Openssl 1.0.2 is good till sometime in 2019, even 1.1.0 eol's before it
does so we're stuck w/ cvtdsp.pl modifying the dsp files one way or another.


I prefer that cvtdsp.pl do exactly the same thing moving forwards so
someone who just built 3 mos ago can repeat the exercise, and only someone
building OpenSSL 1.1.0 needs to cvtdsp.pl because the are seeking the new
support.

So no action on that needed now, but I'd like to discourage us from
inverting this all in the later patch you suggest during 2.4.x lifecycle.


Re: svn commit: r1792912 - in /httpd/httpd/branches/2.4.x/modules/filters: mod_brotli.dsp mod_brotli.mak

2017-04-29 Thread Gregg Smith

No, libs/exe still land in the source root.


On 4/28/2017 8:35 AM, William A Rowe Jr wrote:

Wouldn't there be a corresponding change to LIBPATH?



On Thu, Apr 27, 2017 at 10:17 AM,   wrote:

Author: gsmith
Date: Thu Apr 27 15:17:57 2017
New Revision: 1792912

URL: http://svn.apache.org/viewvc?rev=1792912=rev
Log:
Per brotli-master include will move in 1.0.0
Prepare now, remove old location once 1.0.0 is released

Modified:
httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.dsp
httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.mak

Modified: httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.dsp
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.dsp?rev=1792912=1792911=1792912=diff
==
--- httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.dsp (original)
+++ httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.dsp Thu Apr 27 
15:17:57 2017
@@ -43,7 +43,7 @@ RSC=rc.exe
 # PROP Ignore_Export_Lib 0
 # PROP Target_Dir ""
 # ADD BASE CPP /nologo /MD /W3 /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D 
"HAVE_ZUTIL_H" /FD /c
-# ADD CPP /nologo /MD /W3 /O2 /Oy- /Zi /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /Fd"Release\mod_brotli_src" /FD /c
+# ADD CPP /nologo /MD /W3 /O2 /Oy- /Zi /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /I "../../srclib/brotli/c/include" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" 
/Fd"Release\mod_brotli_src" /FD /c
 # ADD BASE MTL /nologo /D "NDEBUG" /win32
 # ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32
 # ADD BASE RSC /l 0x409 /d "NDEBUG"
@@ -75,7 +75,7 @@ PostBuild_Cmds=if exist $(TargetPath).ma
 # PROP Ignore_Export_Lib 0
 # PROP Target_Dir ""
 # ADD BASE CPP /nologo /MDd /W3 /EHsc /Zi /Od /D "WIN32" /D "_DEBUG" /D 
"_WINDOWS" /FD /c
-# ADD CPP /nologo /MDd /W3 /EHsc /Zi /Od /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "HAVE_ZUTIL_H" 
/Fd"Debug\mod_brotli_src" /FD /c
+# ADD CPP /nologo /MDd /W3 /EHsc /Zi /Od /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /I "../../srclib/brotli/c/include" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "HAVE_ZUTIL_H" 
/Fd"Debug\mod_brotli_src" /FD /c
 # ADD BASE MTL /nologo /D "_DEBUG" /win32
 # ADD MTL /nologo /D "_DEBUG" /mktyplib203 /win32
 # ADD BASE RSC /l 0x409 /d "_DEBUG"

Modified: httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.mak
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.mak?rev=1792912=1792911=1792912=diff
==
--- httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.mak (original)
+++ httpd/httpd/branches/2.4.x/modules/filters/mod_brotli.mak Thu Apr 27 
15:17:57 2017
@@ -62,7 +62,7 @@ CLEAN :
 if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"

 CPP=cl.exe
-CPP_PROJ=/nologo /MD /W3 /Zi /O2 /Oy- /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /Fo"$(INTDIR)\\" 
/Fd"$(INTDIR)\mod_brotli_src" /FD /c
+CPP_PROJ=/nologo /MD /W3 /Zi /O2 /Oy- /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /I "../../srclib/brotli/c/include" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /Fo"$(INTDIR)\\" 
/Fd"$(INTDIR)\mod_brotli_src" /FD /c

 .c{$(INTDIR)}.obj::
$(CPP) @<<
@@ -166,7 +166,7 @@ CLEAN :
 if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"

 CPP=cl.exe
-CPP_PROJ=/nologo /MDd /W3 /Zi /Od /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "HAVE_ZUTIL_H" /Fo"$(INTDIR)\\" 
/Fd"$(INTDIR)\mod_brotli_src" /FD /EHsc /c
+CPP_PROJ=/nologo /MDd /W3 /Zi /Od /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I 
"../../srclib/brotli/include" /I "../../srclib/brotli/c/include" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "HAVE_ZUTIL_H" 
/Fo"$(INTDIR)\\" /Fd"$(INTDIR)\mod_brotli_src" /FD /EHsc /c

 .c{$(INTDIR)}.obj::
$(CPP) @<<




Re: The drive for 2.4.26

2017-04-29 Thread Gregg Smith

APR 1.6 is needed for apr_crypto_openssl, obviously.

ABS: Not sure. When I originally tried building w/ APR 1.5 it didn't 
work, but it didn't work with OpenSSL 1.1 and APR 1.6 either. That has 
now been fixed by Rainer. Have not tried 1.5/1.1.0 w/ abs yet so I 
simply don't know. Feel free to try it. I have no time today to do it.


cvtdsp.pl assumes 1.6 is needed due to those first attempts and may be 
inaccurate. It's easy to just remove the xml.mak regex for 1.6 that's 
part of cvtdsp.pl -ossl11 (), there is a separate -apr16 option 
for just the one change in APR (xml.mak's location). Maybe I should 
remove the part concerning APR 1.6 from the -ossl11 option.


Once APR 1.6 is released my plan is to make the change permanent next 
2.4.x then making the need for that conversion unneeded.


Openssl 1.0.2 is good till sometime in 2019, even 1.1.0 eol's before it 
does so we're stuck w/ cvtdsp.pl modifying the dsp files one way or 
another.


Anyone with commit access for apr can remove the part to modify for 1.6 
that is included in cvtdsp.pl -ossl110 (sub toossl1) if 1.6 really isn't 
needed for ABS.


Have a family member in the hospital who had surgery yesterday so this 
is my first time to even check mail since Wednesday morning. I have to 
go back to the hospital shortly.




On 4/28/2017 1:26 PM, Steffen wrote:

I doubt now. It was based on a note in cvtdsp.pl.

Maybe it is only a .dsp and xml change, which I can apply to 1.5.

Maybe Gregg can shed some light on this ?



Op 28 apr. 2017 om 22:16 heeft William A Rowe Jr  het 
volgende geschreven:

Now that these are independent of one another, I think we can release before 1.6.x 
are released. We should just call out "New: OpenSSL 1.1.0 support! (Upcoming 
APR 1.6.x is required for this support.)




On Apr 28, 2017 2:56 PM, "Steffen"  wrote:
When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 1.1 not 
supported.

For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g  apr_crypto_openssl 
for mod_session crypto)



Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het volgende 
geschreven:

It would be cool to have 2.4.26 released by ApacheCon, or even
by OSCON. There are, last I checked, 2 showstoppers on list for
2.4.26... Anyway we could address them and shoot for a T maybe
next Weds?






Re: mod_brotli in 2.4.x is missing a few Makefile changes

2017-04-29 Thread Gregg Smith



On 4/28/2017 9:35 AM, Jan Ehrhardt wrote:

William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03
-0500):

You might have missed my thought here... suggesting that the CMake
not-so-experimental build become recommended for users who want to
build all the modules in one go including the new mod_brotli.


People like Steffen, Gregg and me disagree with you on making CMake the
only way for building Apache and all the modules in one go.


Maybe we have an English->Dutch translation error?

I have no problem with "recommending" folks use cmake, none at all. I 
find it to be a pain in the backside but that's just me. Others may 
share this but I will not stand in the way of simply "recommending" it. 
I'm actually for it so there are less folks new to building httpd having 
problems because of all the quirks the different VC versions have.


I do however have a problem with any thought or discussion of removing 
or shorting modules in the legacy build up until such time as it really 
is impossible to build with it or simply goes stale because of lack of 
will to keep it up to date which as of now has not yet happened.


Bill, viewing the complete thread your reasoning here should have 
precluded this discussion years ago when pcre went to cmake, so at or 
before 2.4.0. After all, it's the only way to build pcre which is a hard 
requirement, not soft like brotli.





It sounds like you attempted to export mod_brotli.dsp to a vcproj all
on it's own which has never been possible.


It is perfectly possible. That is how I added mod_fcgid and now
mod_brotli to my existing Apache 2.4.25 sln. Convert to vcproj (VC9) or
vcxproj (VC11/VC14), add the x64 configuration, add the vc(x)proj as an
existing project to Apache.sln. I am doing the same thing when mod_http2
changes the headers or sources.

For 2.4.next I will convert Apache.dsw once again and add mod_fcgid
afterwards.



Re: The drive for 2.4.26

2017-04-29 Thread Gregg Smith
Yes, and only with the legacy build and then only with the IDE. Those 
files are static. If you build at the command line it should "just work."


When I built with apr 1.5 however apr_crypto_openssl would not build 
with openssl 1.1.0. I cannot see how that has changed..


On 4/29/2017 1:42 AM, Stefan Eissing wrote:

Is this a Windows issue? I built with 1.1.0e on MacOS and apr 1.5 and saw no 
problems.


Am 28.04.2017 um 22:26 schrieb Steffen :

I doubt now. It was based on a note in cvtdsp.pl.

Maybe it is only a .dsp and xml change, which I can apply to 1.5.

Maybe Gregg can shed some light on this ?



Op 28 apr. 2017 om 22:16 heeft William A Rowe Jr  het 
volgende geschreven:

Now that these are independent of one another, I think we can release before 1.6.x 
are released. We should just call out "New: OpenSSL 1.1.0 support! (Upcoming 
APR 1.6.x is required for this support.)




On Apr 28, 2017 2:56 PM, "Steffen"  wrote:
When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 1.1 not 
supported.

For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g  apr_crypto_openssl 
for mod_session crypto)



Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het volgende 
geschreven:

It would be cool to have 2.4.26 released by ApacheCon, or even
by OSCON. There are, last I checked, 2 showstoppers on list for
2.4.26... Anyway we could address them and shoot for a T maybe
next Weds?






Re: mod_brotli in 2.4.x is missing a few Makefile changes

2017-04-29 Thread Gregg Smith



On 4/29/2017 5:19 PM, Gregg Smith wrote:


Bill, viewing the complete thread your reasoning here should have
precluded this discussion years ago when pcre went to cmake, so at or
before 2.4.0. After all, it's the only way to build pcre which is a hard
requirement, not soft like brotli.



I guess I didn't see it all. I see now where your reasoning is as far as 
doing it now and not before.


I see no majority as 3 do, 3 do not (if I include expat). This is 
assuming nghttp2 fixed the cmake problem I had on windows. I would think 
so as a long time and many versions have come since then.


I'm still against removal/shorting legacy yet not against recommending 
cmake.