Help needed to test Windows builds in Travis
Hi everybody, if you build httpd for Windows can you give us a list of commands and steps that you usually do? I am not familiar enough with the platform and [1] is still a bit cryptic to me :) The end goal is to add the build steps to our Travis config, to run them every time that a commit happens. Thanks in advance! Luca [1] https://httpd.apache.org/docs/2.4/platform/win_compiling.html
Re: AW: Integration tests running on Docker
Le 07/11/2019 à 11:31, Pluem, Ruediger, Vodafone Group a écrit :
C2 General
-Ursprüngliche Nachricht-
Von: Yann Ylavic
Gesendet: Donnerstag, 7. November 2019 11:19
An: httpd-dev
Betreff: Re: Integration tests running on Docker
On Wed, Nov 6, 2019 at 6:54 PM Joe Orton wrote:
Has anybody seen t/modules/deflate.t and t/modules/brotli.t fail on
Debian-ish distro? I don't remember seeing this before but maybe it's
something
trivial? t/TEST output -
It seems to originate from r1868312.
I don't really understand this new test in mod_deflate (the one which
fails):
ok $original_str eq $deflated_str_q0;
Why would we expect a plain string to be equal to a deflated one,
Christophe?
I don't see how the failure depends on debian vs any other system
either.
Running t/modules/deflate.t on my debian, with this debugging patch:
```
Index: t/modules/deflate.t
===
--- t/modules/deflate.t (revision 1869498)
+++ t/modules/deflate.t (working copy)
@@ -57,6 +57,10 @@ for my $server_deflate_uri (@server_deflate_uris)
ok $original_str eq $inflated_str;
ok $original_str eq $deflated_str_q0;
+if (not $original_str eq $deflated_str_q0) {
+print "original: '$original_str'\n";
+print "deflated: '$deflated_str_q0'\n";
+}
my $resp = POST($server_inflate_uri, @inflate_headers,
content => "foo123456789012346");
if (have_min_apache_version("2.5")) {
```
I get (e.g.):
```
not ok 42
original: '
Some dummy content. Some dummy content. Some dummy content. Some dummy
content.
EOF
'
deflated: '
I suspect that $deflated_str_q0 is the result of the request with
Accept-Encoding: gzip;q=0
where mod_deflate actually should not gzip the response because of q=0.
Yeap, that's it
Regards
Rüdiger
Re: Integration tests running on Docker
Il giorno gio 7 nov 2019 alle ore 16:49 Yann Ylavic ha scritto: > > On Thu, Nov 7, 2019 at 4:47 PM Eric Covener wrote: > > > > > @@ -125,6 +125,7 @@ > > > . non-Unix, single-platform code > > > . routine APLOGNO() backports > > > . .gdbinit > > > +. Travis integration: .travis.yml and test/travis*.sh > > > > +1 > > +1 +1 \o/
Re: Integration tests running on Docker
On Thu, Nov 7, 2019 at 4:47 PM Eric Covener wrote: > > > @@ -125,6 +125,7 @@ > > . non-Unix, single-platform code > > . routine APLOGNO() backports > > . .gdbinit > > +. Travis integration: .travis.yml and test/travis*.sh > > +1 +1
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
On Tue, Nov 5, 2019 at 9:19 AM Rüdiger Plüm wrote: > > On 10/28/2019 10:54 AM, Yann Ylavic wrote: > > > > Once/if backported, I plan to completely remove the base vhost from > > the game, in trunk (usual merging applies). > > So you want to revert r1868929 after the backport? Yes, exactly. > > As far as I can tell r1868929 keeps the inheritance behavior closer to the > previous 2.4.x and trunk behavior, but is different compared to the > inheritance behavior of already SNI respecting directives like e.g. > SSLCipherSuite. > Removing r1868929 would bring both (the directives respecting SNI so far > and the ones that NOW respect SNI) to the same inheritance level, correct? That's it, and consistent with all other RSRC_CONF directives merging. The difference between 2.4 (with r1868929) and trunk (without) would be only if no global SSLProtocol is configured. In this case any vhost with no SSLProtocol either would take the default value (the hard coded "ALL -SSLv3" currently), instead of first name based vhost's (which wouldn't be involved anymore for SSLProtocol). Sounds good? Thanks, Yann.
Re: Integration tests running on Docker
> @@ -125,6 +125,7 @@ > . non-Unix, single-platform code > . routine APLOGNO() backports > . .gdbinit > +. Travis integration: .travis.yml and test/travis*.sh +1
Re: Integration tests running on Docker
On Thu, Nov 07, 2019 at 10:37:50AM +, Pluem, Ruediger, Vodafone Group wrote: > r1868314 Ah, thank you! Obviously I tested this locally first too but hadn't updated my test/framework directory... duh. Should we use RTC or can I get an exception for 2.4.x travis integration? I have a few more things to merge to trunk then can backport: https://github.com/apache/httpd/compare/2.4.x...notroj:travisify-2.4.x Index: STATUS === --- STATUS (revision 1869499) +++ STATUS (working copy) @@ -125,6 +125,7 @@ . non-Unix, single-platform code . routine APLOGNO() backports . .gdbinit +. Travis integration: .travis.yml and test/travis*.sh RELEASE SHOWSTOPPERS:
AW: svn commit: r1869499 - /httpd/httpd/trunk/build/apr_common.m4
+1. This makes 3 +1 on list so we are now RTC and go for it :-). Regards Rüdiger C2 General > -Ursprüngliche Nachricht- > Von: Stefan Eissing > Gesendet: Donnerstag, 7. November 2019 13:14 > An: dev@httpd.apache.org > Betreff: Re: svn commit: r1869499 - > /httpd/httpd/trunk/build/apr_common.m4 > > +1 > > > Am 07.11.2019 um 13:12 schrieb Yann Ylavic : > > > > Should I backport this removal to 2.4.x? CTR? > > > > On Thu, Nov 7, 2019 at 1:10 PM Yann Ylavic > wrote: > >> > >> r1869500 > >> > >> On Thu, Nov 7, 2019 at 12:31 PM Pluem, Ruediger, Vodafone Group > >> wrote: > >>> > >>> +1 > >>> > >>> Regards > >>> > >>> Rüdiger > >>> > >>> > >>> C2 General > >>> > -Ursprüngliche Nachricht- > Von: Stefan Eissing > Gesendet: Donnerstag, 7. November 2019 12:13 > An: dev@httpd.apache.org > Betreff: Re: svn commit: r1869499 - > /httpd/httpd/trunk/build/apr_common.m4 > > +1 > > > Am 07.11.2019 um 12:04 schrieb Yann Ylavic : > > > > On Thu, Nov 7, 2019 at 12:01 PM wrote: > >> > >> Author: ylavic > >> Date: Thu Nov 7 11:01:48 2019 > >> New Revision: 1869499 > >> > >> URL: http://svn.apache.org/viewvc?rev=1869499=rev > >> Log: > >> Use latest/compatible apr_common.m4. > > > > Or should we remove this file from the repository since it's > generated > > by ./buildconf?
Re: svn commit: r1869499 - /httpd/httpd/trunk/build/apr_common.m4
+1 > Am 07.11.2019 um 13:12 schrieb Yann Ylavic : > > Should I backport this removal to 2.4.x? CTR? > > On Thu, Nov 7, 2019 at 1:10 PM Yann Ylavic wrote: >> >> r1869500 >> >> On Thu, Nov 7, 2019 at 12:31 PM Pluem, Ruediger, Vodafone Group >> wrote: >>> >>> +1 >>> >>> Regards >>> >>> Rüdiger >>> >>> >>> C2 General >>> -Ursprüngliche Nachricht- Von: Stefan Eissing Gesendet: Donnerstag, 7. November 2019 12:13 An: dev@httpd.apache.org Betreff: Re: svn commit: r1869499 - /httpd/httpd/trunk/build/apr_common.m4 +1 > Am 07.11.2019 um 12:04 schrieb Yann Ylavic : > > On Thu, Nov 7, 2019 at 12:01 PM wrote: >> >> Author: ylavic >> Date: Thu Nov 7 11:01:48 2019 >> New Revision: 1869499 >> >> URL: http://svn.apache.org/viewvc?rev=1869499=rev >> Log: >> Use latest/compatible apr_common.m4. > > Or should we remove this file from the repository since it's generated > by ./buildconf?
Re: svn commit: r1869499 - /httpd/httpd/trunk/build/apr_common.m4
Should I backport this removal to 2.4.x? CTR? On Thu, Nov 7, 2019 at 1:10 PM Yann Ylavic wrote: > > r1869500 > > On Thu, Nov 7, 2019 at 12:31 PM Pluem, Ruediger, Vodafone Group > wrote: > > > > +1 > > > > Regards > > > > Rüdiger > > > > > > C2 General > > > > > -Ursprüngliche Nachricht- > > > Von: Stefan Eissing > > > Gesendet: Donnerstag, 7. November 2019 12:13 > > > An: dev@httpd.apache.org > > > Betreff: Re: svn commit: r1869499 - > > > /httpd/httpd/trunk/build/apr_common.m4 > > > > > > +1 > > > > > > > Am 07.11.2019 um 12:04 schrieb Yann Ylavic : > > > > > > > > On Thu, Nov 7, 2019 at 12:01 PM wrote: > > > >> > > > >> Author: ylavic > > > >> Date: Thu Nov 7 11:01:48 2019 > > > >> New Revision: 1869499 > > > >> > > > >> URL: http://svn.apache.org/viewvc?rev=1869499=rev > > > >> Log: > > > >> Use latest/compatible apr_common.m4. > > > > > > > > Or should we remove this file from the repository since it's generated > > > > by ./buildconf?
Re: svn commit: r1869499 - /httpd/httpd/trunk/build/apr_common.m4
r1869500 On Thu, Nov 7, 2019 at 12:31 PM Pluem, Ruediger, Vodafone Group wrote: > > +1 > > Regards > > Rüdiger > > > C2 General > > > -Ursprüngliche Nachricht- > > Von: Stefan Eissing > > Gesendet: Donnerstag, 7. November 2019 12:13 > > An: dev@httpd.apache.org > > Betreff: Re: svn commit: r1869499 - > > /httpd/httpd/trunk/build/apr_common.m4 > > > > +1 > > > > > Am 07.11.2019 um 12:04 schrieb Yann Ylavic : > > > > > > On Thu, Nov 7, 2019 at 12:01 PM wrote: > > >> > > >> Author: ylavic > > >> Date: Thu Nov 7 11:01:48 2019 > > >> New Revision: 1869499 > > >> > > >> URL: http://svn.apache.org/viewvc?rev=1869499=rev > > >> Log: > > >> Use latest/compatible apr_common.m4. > > > > > > Or should we remove this file from the repository since it's generated > > > by ./buildconf?
AW: svn commit: r1869499 - /httpd/httpd/trunk/build/apr_common.m4
+1 Regards Rüdiger C2 General > -Ursprüngliche Nachricht- > Von: Stefan Eissing > Gesendet: Donnerstag, 7. November 2019 12:13 > An: dev@httpd.apache.org > Betreff: Re: svn commit: r1869499 - > /httpd/httpd/trunk/build/apr_common.m4 > > +1 > > > Am 07.11.2019 um 12:04 schrieb Yann Ylavic : > > > > On Thu, Nov 7, 2019 at 12:01 PM wrote: > >> > >> Author: ylavic > >> Date: Thu Nov 7 11:01:48 2019 > >> New Revision: 1869499 > >> > >> URL: http://svn.apache.org/viewvc?rev=1869499=rev > >> Log: > >> Use latest/compatible apr_common.m4. > > > > Or should we remove this file from the repository since it's generated > > by ./buildconf?
Re: svn commit: r1869499 - /httpd/httpd/trunk/build/apr_common.m4
+1 > Am 07.11.2019 um 12:04 schrieb Yann Ylavic : > > On Thu, Nov 7, 2019 at 12:01 PM wrote: >> >> Author: ylavic >> Date: Thu Nov 7 11:01:48 2019 >> New Revision: 1869499 >> >> URL: http://svn.apache.org/viewvc?rev=1869499=rev >> Log: >> Use latest/compatible apr_common.m4. > > Or should we remove this file from the repository since it's generated > by ./buildconf?
Re: svn commit: r1869499 - /httpd/httpd/trunk/build/apr_common.m4
On Thu, Nov 7, 2019 at 12:01 PM wrote: > > Author: ylavic > Date: Thu Nov 7 11:01:48 2019 > New Revision: 1869499 > > URL: http://svn.apache.org/viewvc?rev=1869499=rev > Log: > Use latest/compatible apr_common.m4. Or should we remove this file from the repository since it's generated by ./buildconf?
AW: Integration tests running on Docker
C2 General > -Ursprüngliche Nachricht- > Von: Yann Ylavic > Gesendet: Donnerstag, 7. November 2019 11:32 > An: httpd-dev > Betreff: Re: Integration tests running on Docker > > On Thu, Nov 7, 2019 at 11:19 AM Yann Ylavic > wrote: > > > > Am I missing something? > > A brain or something like that :) > > Nevermind, I was just confused by the name of $deflated_str_q0, this > string isn't actually deflated because of q=0. > > Since this test passes on trunk, a backport is missing possibly? r1868314 Regards Rüdiger
Re: Integration tests running on Docker
On Thu, Nov 7, 2019 at 11:31 AM Yann Ylavic wrote: > > Since this test passes on trunk, a backport is missing possibly? Yep, r1868313, proposed in STATUS already.
Re: Integration tests running on Docker
On Thu, Nov 7, 2019 at 11:31 AM Pluem, Ruediger, Vodafone Group wrote: > > I suspect that $deflated_str_q0 is the result of the request with > Accept-Encoding: gzip;q=0 > where mod_deflate actually should not gzip the response because of q=0. Yeah, brain fart :)
Re: Integration tests running on Docker
On Thu, Nov 7, 2019 at 11:19 AM Yann Ylavic wrote: > > Am I missing something? A brain or something like that :) Nevermind, I was just confused by the name of $deflated_str_q0, this string isn't actually deflated because of q=0. Since this test passes on trunk, a backport is missing possibly?
AW: Integration tests running on Docker
C2 General
> -Ursprüngliche Nachricht-
> Von: Yann Ylavic
> Gesendet: Donnerstag, 7. November 2019 11:19
> An: httpd-dev
> Betreff: Re: Integration tests running on Docker
>
> On Wed, Nov 6, 2019 at 6:54 PM Joe Orton wrote:
> >
> > Has anybody seen t/modules/deflate.t and t/modules/brotli.t fail on
> > Debian-ish distro? I don't remember seeing this before but maybe it's
> something
> > trivial? t/TEST output -
>
> It seems to originate from r1868312.
>
> I don't really understand this new test in mod_deflate (the one which
> fails):
> ok $original_str eq $deflated_str_q0;
>
> Why would we expect a plain string to be equal to a deflated one,
> Christophe?
> I don't see how the failure depends on debian vs any other system
> either.
>
> Running t/modules/deflate.t on my debian, with this debugging patch:
> ```
> Index: t/modules/deflate.t
> ===
> --- t/modules/deflate.t (revision 1869498)
> +++ t/modules/deflate.t (working copy)
> @@ -57,6 +57,10 @@ for my $server_deflate_uri (@server_deflate_uris)
>
> ok $original_str eq $inflated_str;
> ok $original_str eq $deflated_str_q0;
> +if (not $original_str eq $deflated_str_q0) {
> +print "original: '$original_str'\n";
> +print "deflated: '$deflated_str_q0'\n";
> +}
> my $resp = POST($server_inflate_uri, @inflate_headers,
> content => "foo123456789012346");
> if (have_min_apache_version("2.5")) {
> ```
>
> I get (e.g.):
> ```
> not ok 42
> original: '
> Some dummy content. Some dummy content. Some dummy content. Some dummy
> content.
> EOF
> '
> deflated: '
Re: Integration tests running on Docker
On Wed, Nov 6, 2019 at 6:54 PM Joe Orton wrote:
>
> Has anybody seen t/modules/deflate.t and t/modules/brotli.t fail on
> Debian-ish distro? I don't remember seeing this before but maybe it's
> something
> trivial? t/TEST output -
It seems to originate from r1868312.
I don't really understand this new test in mod_deflate (the one which fails):
ok $original_str eq $deflated_str_q0;
Why would we expect a plain string to be equal to a deflated one, Christophe?
I don't see how the failure depends on debian vs any other system either.
Running t/modules/deflate.t on my debian, with this debugging patch:
```
Index: t/modules/deflate.t
===
--- t/modules/deflate.t (revision 1869498)
+++ t/modules/deflate.t (working copy)
@@ -57,6 +57,10 @@ for my $server_deflate_uri (@server_deflate_uris)
ok $original_str eq $inflated_str;
ok $original_str eq $deflated_str_q0;
+if (not $original_str eq $deflated_str_q0) {
+print "original: '$original_str'\n";
+print "deflated: '$deflated_str_q0'\n";
+}
my $resp = POST($server_inflate_uri, @inflate_headers,
content => "foo123456789012346");
if (have_min_apache_version("2.5")) {
```
I get (e.g.):
```
not ok 42
original: '
Some dummy content. Some dummy content. Some dummy content. Some dummy content.
EOF
'
deflated: ''
# Failed test 42 in t/modules/deflate.t at line 59 fail #11
```
Am I missing something?
Regards,
Yann.
