Re: Current status of mod_h2 test suite?

ung : >>> >>> Hi Stefan, >>> >>> Am 05.04.2022 um 13:49 schrieb Stefan Eissing: >>>> Which test suite, the one in trunk or the one from github? Both work best >>>> against the respective source. >>> >>> the test suite in

Re: Current status of mod_h2 test suite?

Thaks, will switch to that one. Should have reembered it ... Am 05.04.2022 um 14:04 schrieb Stefan Eissing: Am 05.04.2022 um 14:01 schrieb Rainer Jung : Hi Stefan, Am 05.04.2022 um 13:49 schrieb Stefan Eissing: Which test suite, the one in trunk or the one from github? Both work best

Re: Current status of mod_h2 test suite?

> Am 05.04.2022 um 14:01 schrieb Rainer Jung : > > Hi Stefan, > > Am 05.04.2022 um 13:49 schrieb Stefan Eissing: >> Which test suite, the one in trunk or the one from github? Both work best >> against the respective source. > > the test suite in > >

Re: Current status of mod_h2 test suite?

Hi Stefan, Am 05.04.2022 um 13:49 schrieb Stefan Eissing: Which test suite, the one in trunk or the one from github? Both work best against the respective source. the test suite in https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk Which one would you recommend to test http2 in a 2.4

Re: Current status of mod_h2 test suite?

Which test suite, the one in trunk or the one from github? Both work best against the respective source. > Am 05.04.2022 um 13:47 schrieb Rainer Jung : > > I try to make the mod_h2 test suite run for me. Some difficulties are > expected due to my non-standard setup, but th

Current status of mod_h2 test suite?

I try to make the mod_h2 test suite run for me. Some difficulties are expected due to my non-standard setup, but the first test that seems to fail in a way I am not directly blaming myself is fuzz header * on http://test.example.org:12345: super-long...--- gen/expect_431 2022-04-05 13:25

Re: Python test suite - failures on Fedora Rawhide / MacOS

7.80.0/config.log > ---> Building curl > ---> Staging curl into destroot > ---> Installing curl @7.80.0_0+http2+ssl > ---> Deactivating curl @7.80.0_0+ssl > ---> Cleaning curl > ---> Activating curl @7.80.0_0+http2

Re: Python test suite - failures on Fedora Rawhide / MacOS

broken files found. ---> No broken ports found. I suspect we need tests at the very beginning of the test suite to fail if the required tools are missing / incomplete. Regards, Graham —

Re: Python test suite - failures on Fedora Rawhide / MacOS

> Am 07.02.2022 um 11:42 schrieb Stefan Eissing : > > > >> Am 07.02.2022 um 11:26 schrieb Graham Leggett : >> >> On 07 Feb 2022, at 12:23, Stefan Eissing wrote: >> >>> could you attach a complete failed output of your pytest run? I use it on >>> MacOS all the time and >>> it seems most

Re: Python test suite - failures on Fedora Rawhide / MacOS

> Am 07.02.2022 um 11:26 schrieb Graham Leggett : > > On 07 Feb 2022, at 12:23, Stefan Eissing wrote: > >> could you attach a complete failed output of your pytest run? I use it on >> MacOS all the time and >> it seems most likely that some prerequisites have not been documented well >>

Re: Python test suite - failures on Fedora Rawhide / MacOS

On 07 Feb 2022, at 12:23, Stefan Eissing wrote: > could you attach a complete failed output of your pytest run? I use it on > MacOS all the time and > it seems most likely that some prerequisites have not been documented well > enough or checks must > add more information in output. I reduced

Re: Python test suite - failures on Fedora Rawhide / MacOS

ieb Graham Leggett : > > Hi all, > > I am not having any luck getting the python test suite to run on either MacOS > or Rawhide. > > In the case of MacOS I see this: > > == 50 failed, 214 passed, 239 skipped, 195

Python test suite - failures on Fedora Rawhide / MacOS

Hi all, I am not having any luck getting the python test suite to run on either MacOS or Rawhide. In the case of MacOS I see this: == 50 failed, 214 passed, 239 skipped, 195 errors in 282.97s (0:04:42) === A selection of errors

Re: [VOTE] Re: http2 test suite

On Wed, Sep 01, 2021 at 10:56:15AM +0100, Joe Orton wrote: > On Mon, Aug 30, 2021 at 08:39:17AM +0200, Ruediger Pluem wrote: > > On 8/28/21 4:00 PM, Yann Ylavic wrote: > > > On Fri, Aug 27, 2021 at 10:07 AM ste...@eissing.org > > > wrote: > > >> Related to that, do we exempt "./test" from RTC in

Re: [VOTE] Re: http2 test suite

On 9/1/21 11:56 AM, Joe Orton wrote: > On Mon, Aug 30, 2021 at 08:39:17AM +0200, Ruediger Pluem wrote: >> On 8/28/21 4:00 PM, Yann Ylavic wrote: >>> On Fri, Aug 27, 2021 at 10:07 AM ste...@eissing.org >>> wrote: Related to that, do we exempt "./test" from RTC in 2.4.x/STATUS? >>> >>> +1

Re: [VOTE] http2 test suite

> Am 01.09.2021 um 11:56 schrieb Joe Orton : > > On Mon, Aug 30, 2021 at 08:39:17AM +0200, Ruediger Pluem wrote: >> On 8/28/21 4:00 PM, Yann Ylavic wrote: >>> On Fri, Aug 27, 2021 at 10:07 AM ste...@eissing.org >>> wrote: Related to that, do we exempt "./test" from RTC in 2.4.x/STATUS?

[VOTE] Re: http2 test suite

On Mon, Aug 30, 2021 at 08:39:17AM +0200, Ruediger Pluem wrote: > On 8/28/21 4:00 PM, Yann Ylavic wrote: > > On Fri, Aug 27, 2021 at 10:07 AM ste...@eissing.org > > wrote: > >> Related to that, do we exempt "./test" from RTC in 2.4.x/STATUS? > > > > +1 for CTR, that's how the tests framework

Re: http2 test suite

On 8/28/21 4:00 PM, Yann Ylavic wrote: > On Fri, Aug 27, 2021 at 10:07 AM ste...@eissing.org > wrote: >> >> With the http2 test suite now running in CI (thanks Joe for >> all the CI work!), we should also put that into 2.4.x. It >> should run there without a

Re: http2 test suite

On Fri, Aug 27, 2021 at 10:07 AM ste...@eissing.org wrote: > > With the http2 test suite now running in CI (thanks Joe for > all the CI work!), we should also put that into 2.4.x. It > should run there without any changes, as I use it myself > that way. Thanks to both of yo

http2 test suite

With the http2 test suite now running in CI (thanks Joe for all the CI work!), we should also put that into 2.4.x. It should run there without any changes, as I use it myself that way. Related to that, do we exempt "./test" from RTC in 2.4.x/STATUS? - Stefan

Re: http2 test suite

t;>> >>>> Cheers, Stefan >>>> >>>>> Am 20.08.2021 um 18:08 schrieb ste...@eissing.org: >>>>> >>>>> Done in r1892476. Looking forward on how this works on your machines. >>>>> >>>>> - Stefan &g

Re: http2 test suite

in r1892476. Looking forward on how this works on your machines. > >>> > >>> - Stefan > >>> > >>>> Am 20.08.2021 um 13:50 schrieb ste...@eissing.org: > >>>> > >>>> > >>>> > >>>>> Am

Re: http2 test suite

gt; - Stefan >>> >>>> Am 20.08.2021 um 13:50 schrieb ste...@eissing.org: >>>> >>>> >>>> >>>>> Am 20.08.2021 um 13:46 schrieb Joe Orton : >>>>> >>>>> On Fri, Aug 20, 2021 at 11:35:45AM

Re: http2 test suite

hrieb ste...@eissing.org: > >> > >> > >> > >>> Am 20.08.2021 um 13:46 schrieb Joe Orton : > >>> > >>> On Fri, Aug 20, 2021 at 11:35:45AM +0200, Stefan Eissing wrote: > >>>> https://github.com/apache/httpd/pull/260 >

Re: http2 test suite

i, Aug 20, 2021 at 11:35:45AM +0200, Stefan Eissing wrote: >>>> https://github.com/apache/httpd/pull/260 >>>> a PR with the http2 test suite in trunk/test/modules/http2 >>>> >>>> How to use: >>>> >>>> • run configure again after

Re: http2 test suite

gt;> https://github.com/apache/httpd/pull/260 >>> a PR with the http2 test suite in trunk/test/modules/http2 >>> >>> How to use: >>> >>> • run configure again after you checked this out >>> • the following components need to be instal

Re: http2 test suite

> Am 20.08.2021 um 13:46 schrieb Joe Orton : > > On Fri, Aug 20, 2021 at 11:35:45AM +0200, Stefan Eissing wrote: >> https://github.com/apache/httpd/pull/260 >> a PR with the http2 test suite in trunk/test/modules/http2 >> >> How to use: >> >> • r

Re: http2 test suite

On Fri, Aug 20, 2021 at 11:35:45AM +0200, Stefan Eissing wrote: > https://github.com/apache/httpd/pull/260 > a PR with the http2 test suite in trunk/test/modules/http2 > > How to use: > > • run configure again after you checked this out > • the following components

http2 test suite

https://github.com/apache/httpd/pull/260 a PR with the http2 test suite in trunk/test/modules/http2 How to use: • run configure again after you checked this out • the following components need to be installed on your system: • python3, pytest • curl, nghttp, h2load run the tests

Test suite using OpenSSL 0.9.8 client against OpenSSL 3.0.0 server

FYI: the problems I observed when running the httpd test suite using an OpenSSL 0.9.8zh based client against a server build using OpenSSL 3.0.0 originated in the fact, that OpenSSL 3.0.0 by default no longer allows RSA SHA1 and DSA SHA1 as signature algorithms. But 0.9.8 only support TLS 1.0

Re: Test suite and OpenSSL 1.1.1

With this change (and all the others checked out with test suite), everything works for me. (Actually I had to s/1.86_06/1.86/g at several places in p5-net-ssleay to avoid 'Argument "1.86_06" isn't numeric in numeric lt (<) at /usr/local/share/perl/5.26.2/IO/Socket/SSL.pm line 94' from test suite). Thanks Rainer! Regards, Yann.

Re: Test suite and OpenSSL 1.1.1

20.10.2018 um 06:28 schrieb Rainer Jung: Am 19.10.2018 um 23:31 schrieb Yann Ylavic: Could not make the test suite framework work with 1.1.1 (cpan -u didn't help). Although the ssl tests report SUCCESS, httpd actually timeouts on SSL_peek() (as already reported). Indeed I checked my test suite logs

Re: Test suite and OpenSSL 1.1.1

19.10.2018 um 23:31 schrieb Yann Ylavic: Could not make the test suite framework work with 1.1.1 (cpan -u didn't help). Although the ssl tests report SUCCESS, httpd actually timeouts on SSL_peek() (as already reported). Indeed I checked my test suite logs and until now all tests only used TLS

Re: Test suite and OpenSSL 1.1.1

not make the test suite framework work with 1.1.1 (cpan -u didn't help). Although the ssl tests report SUCCESS, httpd actually timeouts on SSL_peek() (as already reported). Indeed I checked my test suite logs and until now all tests only used TLS 1.2. But what works for me now with TLS 1.3

Re: Test suite and OpenSSL 1.1.1

Am 20.10.2018 um 10:27 schrieb Christophe JAILLET: Le 20/10/2018 à 09:56, Rainer Jung a écrit : Am 20.10.2018 um 09:39 schrieb Christophe JAILLET: Le 20/10/2018 à 06:28, Rainer Jung a écrit : Am 19.10.2018 um 23:31 schrieb Yann Ylavic: Could not make the test suite framework work with 1.1.1

Re: Test suite and OpenSSL 1.1.1

Le 20/10/2018 à 09:56, Rainer Jung a écrit : Hi, Am 20.10.2018 um 09:39 schrieb Christophe JAILLET: Le 20/10/2018 à 06:28, Rainer Jung a écrit : Am 19.10.2018 um 23:31 schrieb Yann Ylavic: Could not make the test suite framework work with 1.1.1 (cpan -u didn't help). Although the ssl tests

Re: Test suite and OpenSSL 1.1.1

tests work I added r1844393. Both, r1844389 and r1844393 are part of the /perl/Apache-Test/trunk/ external which gets pulled into our test framework. Am 20.10.2018 um 06:28 schrieb Rainer Jung: Am 19.10.2018 um 23:31 schrieb Yann Ylavic: Could not make the test suite framework work with 1.1.1 (cpan

Re: Test suite and OpenSSL 1.1.1

Hi, Am 20.10.2018 um 09:39 schrieb Christophe JAILLET: Le 20/10/2018 à 06:28, Rainer Jung a écrit : Am 19.10.2018 um 23:31 schrieb Yann Ylavic: Could not make the test suite framework work with 1.1.1 (cpan -u didn't help). Although the ssl tests report SUCCESS, httpd actually timeouts

Re: Test suite and OpenSSL 1.1.1

Le 20/10/2018 à 06:28, Rainer Jung a écrit : Am 19.10.2018 um 23:31 schrieb Yann Ylavic: Could not make the test suite framework work with 1.1.1 (cpan -u didn't help). Although the ssl tests report SUCCESS, httpd actually timeouts on SSL_peek() (as already reported). Indeed I checked my test

Re: Test suite and OpenSSL 1.1.1

not make the test suite framework work with 1.1.1 (cpan -u didn't help). Although the ssl tests report SUCCESS, httpd actually timeouts on SSL_peek() (as already reported). Indeed I checked my test suite logs and until now all tests only used TLS 1.2. But what works for me now with TLS 1.3

Test suite and OpenSSL 1.1.1

Am 19.10.2018 um 23:31 schrieb Yann Ylavic: Could not make the test suite framework work with 1.1.1 (cpan -u didn't help). Although the ssl tests report SUCCESS, httpd actually timeouts on SSL_peek() (as already reported). Indeed I checked my test suite logs and until now all tests only used

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018 at 8:11 PM, William A Rowe Jr wrote: > > On Thu, May 24, 2018, 06:34 Eric Covener wrote: >> >> Despite the directory structure, this was not part of a "module" in >> the httpd/LoadModule sense. I think it's reasonable to pull it "up" >> which is simpler then trying to push

Re: Experimental C unit test suite available for hacking

On Thu, May 31, 2018 at 10:07 AM, Yann Ylavic wrote: > On Thu, May 24, 2018 at 8:11 PM, William A Rowe Jr > wrote: > > > > On Thu, May 24, 2018, 06:34 Eric Covener wrote: > >> > >> Despite the directory structure, this was not part of a "module" in > >> the httpd/LoadModule sense. I think

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018 at 8:11 PM, William A Rowe Jr wrote: > > On Thu, May 24, 2018, 06:34 Eric Covener wrote: >> >> Despite the directory structure, this was not part of a "module" in >> the httpd/LoadModule sense. I think it's reasonable to pull it "up" >> which is simpler then trying to push

Re: Experimental C unit test suite available for hacking

I couldn't make it out to ApacheCon. As a result there is now a C-language unit test suite available in branches/httpdunit (based on trunk). I've tested it with a Windows+CMake toolchain as well as an Ubuntu+autoconf toolchain. The suite itself is based on Check, which is a testing library I've

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018, 06:34 Eric Covener wrote: > On Thu, May 24, 2018 at 7:23 AM, Micha Lenk wrote: > > Hi Yann, > > > > On 05/24/2018 12:31 PM, Yann Ylavic wrote: > >>> > >>> Well, first things first. Let's first fix trunk to be buildable again > on > >>>

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018 at 7:23 AM, Micha Lenk wrote: > Hi Yann, > > On 05/24/2018 12:31 PM, Yann Ylavic wrote: >>> >>> Well, first things first. Let's first fix trunk to be buildable again on >>> build systems that really only link the needed symbols and thus rely on >>> the >>>

Re: Experimental C unit test suite available for hacking

Hi Yann, On 05/24/2018 12:31 PM, Yann Ylavic wrote: Well, first things first. Let's first fix trunk to be buildable again on build systems that really only link the needed symbols and thus rely on the correct library order during linking. I think this is*the* dependency issue, the order in

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018 at 12:11 PM, Micha Lenk wrote: > > On 05/24/2018 12:00 PM, Yann Ylavic wrote: > >> I think "core" shouldn't depend on a module (even builtin), for >> instance ap_set_{last_modified,accept_range,content_length,...} also >> used by the core are defined in

Re: Experimental C unit test suite available for hacking

Hi Yann, FWIW I've found a very good explanation of what's going on during linking and why the library order in static linking is so important. https://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking On 05/24/2018 12:00 PM, Yann Ylavic wrote: Looks like the right order to

Re: Experimental C unit test suite available for hacking

Hi Yann, On 05/24/2018 10:41 AM, Yann Ylavic wrote: --- Makefile.in (revision 1832123) +++ Makefile.in (working copy) @@ -7,9 +7,9 @@ PROGRAM_SOURCES = modules.c PROGRAM_LDADD= buildmark.o $(HTTPD_LDFLAGS) $(PROGRAM_DEPENDENCIES) $(HTTPD_LIBS) $(EXTRA_LIBS) $(AP_LIBS) $(LIBS)

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018 at 11:28 AM, Yann Ylavic wrote: > On Thu, May 24, 2018 at 11:23 AM, Yann Ylavic wrote: >> On Thu, May 24, 2018 at 11:06 AM, Micha Lenk wrote: >>> >>> On 05/24/2018 10:41 AM, Yann Ylavic wrote: >>> Btw, as

Re: Experimental C unit test suite available for hacking

Hi Yann, On 05/24/2018 11:23 AM, Yann Ylavic wrote: Yes, for me too, except that the linker problem with undefined symbols now seems to shift to the modules. I had to disable a few modules (--enable-mods-static=most --disable-apreq --disable-proxy-fcgi --disable-session-cookie

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018 at 11:23 AM, Yann Ylavic wrote: > On Thu, May 24, 2018 at 11:06 AM, Micha Lenk wrote: >> >> On 05/24/2018 10:41 AM, Yann Ylavic wrote: >> >>> Btw, as Jacob noted, the attached patch seems to work for me (even >>> without the above

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018 at 11:06 AM, Micha Lenk wrote: > > On 05/24/2018 10:41 AM, Yann Ylavic wrote: > >> Btw, as Jacob noted, the attached patch seems to work for me (even >> without the above option). > > Yes, for me too, except that the linker problem with undefined symbols now

Re: Experimental C unit test suite available for hacking

Hi Yann, On 05/24/2018 10:41 AM, Yann Ylavic wrote: ./configure --prefix=/home/mlenk/Upstream/Apache/target --with-apr=/home/mlenk/Upstream/Apache/target --with-apr-util=/home/mlenk/Upstream/Apache/target --with-mpm=worker --with-mpms-shared=all --enable-mods-static=most

Re: Experimental C unit test suite available for hacking

Hi Micha, On Thu, May 24, 2018 at 10:29 AM, Micha Lenk wrote: > > I tried several combinations of --with-mpm=worker and > --with-mpms-shared=all, but none of them worked (all attempts with "make > clean"). The most recent attempt used the following ./configure command > line: >

Re: Experimental C unit test suite available for hacking

On 05/23/2018 10:21 PM, Christophe Jaillet wrote: I can reproduce the issue if I don't pass any --enable-mpms-shared paramater to ./configure. Having --with-mpm=xx only also triggers the building issue. What is your ./configure command line? The initial ./configure command line was:

Re: Experimental C unit test suite available for hacking

On 05/23/2018 10:32 AM, Marion et Christophe JAILLET wrote: > '--with-test-suite=...' is for the Perl test framework, not for the > 'test/httpdunit'. Ah, yes! Thanks for the reminder; --with-test-suite only enables the `make check` functionality. Sorry, it's been too long. On 05/23/2018

Re: Experimental C unit test suite available for hacking

Le 23/05/2018 à 20:52, Micha Lenk a écrit : Am 23.05.2018 um 20:18 schrieb Marion et Christophe JAILLET: Could you please try to 'make clean' and 'make' to see if you still have the build issue? No change. :( Regards, Micha I can reproduce the issue if I don't pass any --enable-mpms-shared

Re: Experimental C unit test suite available for hacking

Am 23.05.2018 um 20:18 schrieb Marion et Christophe JAILLET: > Could you please try to 'make clean' and 'make' to see if you still have > the build issue? No change. :( Regards, Micha

Re: Experimental C unit test suite available for hacking

Le 23/05/2018 à 14:48, Micha Lenk a écrit : On 05/25/2017 11:44 PM, Jacob Champion wrote (almost a year ago): Last week I had a personal hackathon since I couldn't make it out to ApacheCon. As a result there is now a C-language unit test suite available in branches/httpdunit (based on trunk

Re: Experimental C unit test suite available for hacking

Le 23/05/2018 à 16:14, Micha Lenk a écrit : Hi Eric, On 05/23/2018 02:59 PM, Eric Covener wrote: I guess the CI setup needs to be updated to at least build the unit tests? I did not configure the build explicitly to run the unit tests, so it is just the plain "make" that causes this

Re: Experimental C unit test suite available for hacking

tests, so it is just the plain "make" that causes this target to get build. I would expect the CI setup to implicitly build it as well. Yes, no?! Does the target 'test/httpdunit' not get build in your local builds? It should only get built if you configure --with-test-suite=... and specif

Re: Experimental C unit test suite available for hacking

On Wed, May 23, 2018, 7:35 AM Micha Lenk <mi...@lenk.info> wrote: > > It should only get built if you configure --with-test-suite=... and > > specify the path to a perl-framework wc. It builds for me in trunk. > > Hmm, no difference. It seems to get built independent fr

Re: Experimental C unit test suite available for hacking

the unit tests, so it is just the plain "make" that causes this target to get build. I would expect the CI setup to implicitly build it as well. Yes, no?! Does the target 'test/httpdunit' not get build in your local builds? It should only get built if you configure --with-test-suite=... a

Re: Experimental C unit test suite available for hacking

t is > just the plain "make" that causes this target to get build. I would expect > the CI setup to implicitly build it as well. Yes, no?! > > Does the target 'test/httpdunit' not get build in your local builds? It should only get built if you configure --with-test-suite=... a

Re: Experimental C unit test suite available for hacking

Hi Eric, On 05/23/2018 02:59 PM, Eric Covener wrote: I guess the CI setup needs to be updated to at least build the unit tests? I did not configure the build explicitly to run the unit tests, so it is just the plain "make" that causes this target to get build. I would expect the CI setup to

Re: Experimental C unit test suite available for hacking

On Wed, May 23, 2018 at 8:48 AM, Micha Lenk <mi...@lenk.info> wrote: > On 05/25/2017 11:44 PM, Jacob Champion wrote (almost a year ago): >> >> Last week I had a personal hackathon since I couldn't make it out to >> ApacheCon. As a result there is now a C-languag

Re: Experimental C unit test suite available for hacking

On 25 May 2017, at 11:44 PM, Jacob Champion <champio...@gmail.com> wrote: > Last week I had a personal hackathon since I couldn't make it out to > ApacheCon. As a result there is now a C-language unit test suite available in > branches/httpdunit (based on trunk). I've tested it

Experimental C unit test suite available for hacking

Hi all, Last week I had a personal hackathon since I couldn't make it out to ApacheCon. As a result there is now a C-language unit test suite available in branches/httpdunit (based on trunk). I've tested it with a Windows+CMake toolchain as well as an Ubuntu+autoconf toolchain. The suite

Re: httpd test suite breakage

On Tue, Nov 29, 2016 at 7:25 AM, Petr Gajdos wrote: > On Tue, Nov 29, 2016 at 01:09:25PM +, Joe Orton wrote: > > On Mon, Nov 28, 2016 at 05:16:12PM -0600, William A Rowe Jr wrote: > > > httpd: Syntax error on line 295 of > > >

Re: httpd test suite breakage

On Tue, Nov 29, 2016 at 01:09:25PM +, Joe Orton wrote: > On Mon, Nov 28, 2016 at 05:16:12PM -0600, William A Rowe Jr wrote: > > httpd: Syntax error on line 295 of > > /home/wrowe/dev/test/test24-apr16-ossl102/t/conf/httpd.conf: Cannot load > >

Re: httpd test suite breakage

On Mon, Nov 28, 2016 at 05:16:12PM -0600, William A Rowe Jr wrote: > httpd: Syntax error on line 295 of > /home/wrowe/dev/test/test24-apr16-ossl102/t/conf/httpd.conf: Cannot load > /home/wrowe/dev/test/test24-apr16-ossl102/c-modules/test_session/.libs/mod_test_session.so > into server: >

Re: httpd test suite breakage

My bad.. this is not against HEAD, this is Fedora 25. /sbin/httpd -v Server version: Apache/2.4.23 (Fedora) Server built: Jul 18 2016 15:38:14 Not so urgent for me now, but worth addressing I'd guess. On Mon, Nov 28, 2016 at 5:16 PM, William A Rowe Jr wrote: > Against

httpd test suite breakage

Against 2.4 HEAD... In file included from mod_test_session.c:61:0: mod_test_session.c: In function ‘test_session_register_hooks’: /home/wrowe/dev/test/test24-apr16-ossl102/c-modules/apache_httpd_test.h:128:36: warning: the comparison will always evaluate as ‘true’ for the address of

out-of-thread response to running the test suite on Windows

(sorry, no time now to keep trying to trick the mail gatekeeper into accepting my in-thread response) Here are my notes from 6-7 months ago... They don't seem complete??? Maybe apxs_win32 from svn has fixes to avoid needing the editing to ap*.bat/.pl suggested below. I also remember posting

Re: Running the test suite on Windows

I think the first point of confusion stemmed from those bash CGI scripts you mentioned. I could have sworn I saw more shebangs with paths in /usr/bin/, but that might have come from my semi-odd setup. I'm ssh-ing into cygwin then running the test suite with Strawberry perl through a couple

RE: Running the test suite on Windows

- Original Message - Subject: Running the test suite on Windows From: Edward Lu chaos...@gmail.com Date: 1/21/15 10:05 am To: dev@httpd.apache.org It appears that the test framework has a bunch of dependencies on unix, e.g. it runs scripts with #!/usr/bin/ Running it under

Running the test suite on Windows

It appears that the test framework has a bunch of dependencies on unix, e.g. it runs scripts with #!/usr/bin/ Running it under cygwin would fix some of those issues, but unfortunately, running under cygwin perl generates unix-like paths in the conf files which a windows-built httpd can't deal

any clues about viability of httpd test suite on Windows?

-- Born in Roswell... married an alien... http://emptyhammock.com/

Re: test suite help

On 2/15/2011 10:28 PM, Guenter Knauf wrote: Am 16.02.2011 00:22, schrieb Igor Galić: httpd-x.x/test isn't anything (and perhaps we should remove it entirely). [snip] I coined that a couple of months ago, big +1 from my side. maybe a test/README[.txt] which points to the framework would make

Re: test suite help

On 16/02/2011 16:43, William A. Rowe Jr. wrote: On 2/15/2011 10:28 PM, Guenter Knauf wrote: Am 16.02.2011 00:22, schrieb Igor Galić: httpd-x.x/test isn't anything (and perhaps we should remove it entirely). [snip] I coined that a couple of months ago, big +1 from my side. maybe a

test suite help

Dear httpd developers, I want to do some code coverage statistics of httpd based on its pre-release testing. The test directory along with each release version seems incomplete. Usually, aside from testing conducted by the subscribers of the list, do you have some test suite that must be performed

Re: test suite help

have some test suite that must be performed to verify the basic functionality even before posting a [vote] thread? Is it from apache-test? Thanks very much, httpd-x.x/test isn't anything (and perhaps we should remove it entirely). You need to refer to the test-framework. http://svn.apache.org

Re: test suite help

seems incomplete. Usually, aside from testing conducted by the subscribers of the list, do you have some test suite that must be performed to verify the basic functionality even before posting a [vote] thread? Is it from apache-test? Thanks very much, -- Ryan

Re: test suite help

directory along with each release version seems incomplete. Usually, aside from testing conducted by the subscribers of the list, do you have some test suite that must be performed to verify the basic functionality even before posting a [vote] thread? Is it from apache-test? Thanks very much

Re: test suite help

you have some test suite that must be performed to verify the basic functionality even before posting a [vote] thread? Is it from apache-test? Thanks very much, httpd-x.x/test isn't anything (and perhaps we should remove it entirely). You need to refer to the test-framework. http

Re: test suite help

[snip] The test directory along with each release version seems incomplete. [snip] httpd-x.x/test isn't anything (and perhaps we should remove it entirely). [snip] I coined that a couple of months ago, big +1 from my side. i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail:

Re: test suite help

Am 16.02.2011 00:22, schrieb Igor Galić: httpd-x.x/test isn't anything (and perhaps we should remove it entirely). [snip] I coined that a couple of months ago, big +1 from my side. maybe a test/README[.txt] which points to the framework would make sense? Gün.

Test suite for trunks looks good again

Hi, after yesterdays various small fixes the test suite for trunk again runs flawlessly for me, no failures, no cores. Tested on Solaris 8+10 Sparc, RedHat 5 64 Bits and SuSE Linux Enterprise 10 32 Bits using r1060283. I checked against apr trunk (r1060249) and apr 1.4.2/apu 1.3.10, using

Test suite crash for trunk in mod_setenvif using trace8

It looks like a confusion between array and table: Program terminated with signal 11, Segmentation fault. #0 0xff032198 in strlen () from /lib/libc.so.1 (gdb) bt full #0 0xff032198 in strlen () from /lib/libc.so.1 No symbol table info available. #1 0xff3301ec in apr_array_pstrcat (p=0x5f0730,

Re: Test suite crash for trunk in mod_setenvif using trace8

On Mon, 17 Jan 2011, Rainer Jung wrote: It looks like a confusion between array and table: Program terminated with signal 11, Segmentation fault. #0 0xff032198 in strlen () from /lib/libc.so.1 (gdb) bt full Thanks for the pointer. Fixed in r1060072

Re: Apache test suite problems

-framework/t/conf/httpd.conf, the test can work. IfModule !mod_version.c   LoadModule version_module /usr/lib/apache2-prefork/mod_version.so /IfModule Right, the test suite requires mod_version for testing httpd 2.0 or above. But there still a lot of mod missed. So lots of test skipped

Re: Apache test suite problems

. IfModule !mod_version.c    LoadModule version_module /usr/lib/apache2-prefork/mod_version.so /IfModule Right, the test suite requires mod_version for testing httpd 2.0 or above. But there still a lot of mod missed. So lots of test skipped or failed. Can you show us the output? Generally a missing

Re: Failures in SSL tests in test suite

On 12.12.2009 18:26, Jeff Trawick wrote: On Thu, Dec 10, 2009 at 3:28 PM, Ruediger Pluem rpl...@apache.org wrote: Apparently because of the fix in openssl for the TLS renegotiation issue the following failed tests now pop up in our test suite (trunk and 2.2.x the same): Failed Test

Re: Failures in SSL tests in test suite

On Sat, Dec 12, 2009 at 12:26 PM, Jeff Trawick traw...@gmail.com wrote: On Thu, Dec 10, 2009 at 3:28 PM, Ruediger Pluem rpl...@apache.org wrote: Apparently because of the fix in openssl for the TLS renegotiation issue the following failed tests now pop up in our test suite (trunk and 2.2.x

Re: Failures in SSL tests in test suite

Jeff Trawick wrote: On Sat, Dec 12, 2009 at 12:26 PM, Jeff Trawick traw...@gmail.com wrote: On Thu, Dec 10, 2009 at 3:28 PM, Ruediger Pluem rpl...@apache.org wrote: Apparently because of the fix in openssl for the TLS renegotiation issue the following failed tests now pop up in our test

Re: Failures in SSL tests in test suite

On Thu, Dec 10, 2009 at 3:28 PM, Ruediger Pluem rpl...@apache.org wrote: Apparently because of the fix in openssl for the TLS renegotiation issue the following failed tests now pop up in our test suite (trunk and 2.2.x the same): Failed Test       Stat Wstat Total Fail  List of Failed

Failures in SSL tests in test suite

Apparently because of the fix in openssl for the TLS renegotiation issue the following failed tests now pop up in our test suite (trunk and 2.2.x the same): Failed Test Stat Wstat Total Fail List of Failed --- t

  1   2   >