On Sun, Jun 28, 2020 at 05:15:03PM +0200, Graham Leggett wrote:
> On 28 Jun 2020, at 15:47, Travis CI wrote:
>
> > apache / httpd
> > trunk
> > Build #896 is still failing9 mins and 44 secs
>
> Travis mavens, I’ve been looking for the test/perl-framework directory
> as referred to in --with-tes
On Tue, Jun 23, 2020 at 12:14:01PM +0200, Yann Ylavic wrote:
> Argh, fixed in r1879110 (hopefully).
Thanks a lot, looking green! If we didn't find some actual bugs I would
feel like burning thousands of hours of CPU time in CI was a wasted
effort ;)
On Tue, Jun 23, 2020 at 10:53:13AM +0100, Joe Orton wrote:
> On Fri, Jun 19, 2020 at 02:21:48PM +0100, Joe Orton wrote:
> > so if Apache-Test is trying to connect to ::1 but httpd is only
> > listening on AF_INET port 80, it will look like the server is not
> > running, even
On Fri, Jun 19, 2020 at 02:21:48PM +0100, Joe Orton wrote:
> so if Apache-Test is trying to connect to ::1 but httpd is only
> listening on AF_INET port 80, it will look like the server is not
> running, even if it is.
After r1879103 they are now at least starting up, but failing in t
On Fri, Jun 19, 2020 at 02:08:18PM +0200, Ruediger Pluem wrote:
> Anyone an idea why the Travis builds on s390x, ppc64le and arm64 always fail
> (e.g. https://travis-ci.org/github/apache/httpd/builds/700041805)? It looks
> like the server fails to start in time when running
> the test suite.
My g
On Tue, Jun 16, 2020 at 12:08:41PM +0200, Ruediger Pluem wrote:
>
>
> On 6/16/20 9:29 AM, Stefan Eissing wrote:
> >> Am 15.06.2020 um 21:46 schrieb Ruediger Pluem :
> >>
> >> I would like to unblock the test failure on trunk soon. Any comments on
> >> the below?
> >
> > I am not really familiar
On Thu, May 07, 2020 at 09:50:26AM -0400, Eric Covener wrote:
> On Thu, May 7, 2020 at 9:39 AM Joe Orton wrote:
> > Better question... or stupider question? For "modern" OpenLDAP where
> > ldap_set_rebind_proc takes a void *, this linked list cache is
> > completel
Apologies, I didn't realize that forks would spam the list as well. :(
There will be a few more errors before the commit which turns off
e-mails gets through and/or I get lucky and the thing passes.
Looks like we can use a conditional to disable notifications by default
for forks, I'll try adj
On Sat, May 16, 2020 at 11:19:58AM +0200, Steffen wrote:
> Current trunk 1877795 Win
>
> Change with current 2.4.43 :
>
> MDStoreDire defaults to ServerRoot/logs and not relative to ServerRoot
>
>
> Updating 2.4.43 to Trunk : issue my mailserver cannot find certificates.
As I said in my prev
On Fri, May 15, 2020 at 11:20:51PM +0200, Yann Ylavic wrote:
> On Fri, May 15, 2020 at 8:59 PM Ruediger Pluem wrote:
> >
> > On 5/15/20 6:50 PM, Yann Ylavic wrote:
> > >
> > > Somehow this change (bisected) broke many framework tests for me:
> > > t/ssl/* and t/security/CVE-*, the ones using mod_s
On Thu, May 07, 2020 at 08:06:00AM -0400, Eric Covener wrote:
> On Thu, May 7, 2020 at 2:04 AM Ruediger Pluem wrote:
> > Not looked at the problem further, but there is now a PR for this:
> >
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=64414
> >
> > Maybe this revives the discussion :-)
>
On Thu, May 07, 2020 at 12:55:03PM +0200, Steffen wrote:
> Tried to build trunk again after 2 years :)
>
> server\core.c(5618,58): error C2065: 'DEFAULT_REL_STATEDIR': undeclared
> identifier
That was added in r1842929 (October 2018) and nobody has noticed Windows
was broken before now? "Discon
On Wed, May 06, 2020 at 11:44:37AM +0100, Joe Orton wrote:
> On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote:
> > On 5/4/20 3:49 PM, Joe Orton wrote:
> > > d) SSLRandomSeed. This might have made sense in 1998 but at least with
> > > OpenSSL 1.1.1 whi
On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote:
> On 5/4/20 3:49 PM, Joe Orton wrote:
> > d) SSLRandomSeed. This might have made sense in 1998 but at least with
> > OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd
> > should not be do
On Tue, May 05, 2020 at 03:23:18PM +0200, Ruediger Pluem wrote:
> On 5/5/20 2:40 PM, jor...@apache.org wrote:
> > Author: jorton
> > Date: Tue May 5 12:40:38 2020
> > New Revision: 1877397
> >
> > URL: http://svn.apache.org/viewvc?rev=1877397&view=rev
> > Log:
> > mod_ssl: Switch to using SSL_OP_
On Mon, May 04, 2020 at 09:59:24AM -0400, Eric Covener wrote:
> On Mon, May 4, 2020 at 9:49 AM Joe Orton wrote:
> > c) Client-initiated renegotiation prevention mechanism. This was
> > introduced mostly as a temporary workaround for CVE-2009-3555, and as
> > the saying goes
I'd like to gauge consensus on removing the following mod_ssl features
for 2.5. I am +1 (more or less strongly) on removing all the following:
a) SSLInsecureRengotiation. If you haven't patched your clients for
CVE-2009-3555 there is no hope. This should definitely be removed.
b) SSLRequire
On Wed, Apr 29, 2020 at 11:47:33AM -0500, Daniel Gruno wrote:
> And done, plus we have GH notifications going there now :)
Nice, thanks a lot Daniel.
worse. So as well as changing this the indexed linked list should
really be a hash table?
Regards, Joe
--
Joe Orton // Red Hat Core Services
In uldap_connection_unbind, apr_ldap_rebind_remove() is always passed
NULL since ldc->ldap is either NULL on entry or is set to NULL. This
looks safe, but seems like an expensive noop since
apr_ldap_rebind_remove() acquires a mutex and iterates a linked list
trying to find a rebind reference m
On Tue, Apr 28, 2020 at 05:19:09PM +0200, Ruediger Pluem wrote:
> +1 g...@httpd.apache.org (I declare the naming discussion for the list name
> opened :-)).
> This offers an easy opt-in for those who are interested in these updates.
+1 from me, does anybody know if it's actually technically possi
On Mon, Apr 27, 2020 at 04:27:56PM +0200, Yann Ylavic wrote:
> On Mon, Apr 27, 2020 at 4:11 PM Joe Orton wrote:
> >
> > +1 from me for using the term "opaque buckets" as a synonym for
> > "e->length == (apr_size_t)-1" aka "buckets with inde
On Mon, Apr 27, 2020 at 03:57:37PM +0200, Yann Ylavic wrote:
> On Mon, Apr 27, 2020 at 3:43 PM Yann Ylavic wrote:
> >
> > On Mon, Apr 27, 2020 at 2:09 PM Yann Ylavic wrote:
> > >
> > > https://github.com/apache/httpd/pull/117
> >
> > I closed it, how about the second patch there though?
> >
> > h
tor hook. It calls
> ap_get_sload() and then a static utility function calc_mon_data() to
> calculate the new averages.
>
> - Minor mmn change not yet part of the patch.
>
> It compiles fine (maintainer mode) on RHEL 7 x86_64 and on Solaris 10 Sparc
> and I did some tests with m
On Mon, Apr 27, 2020 at 02:29:55PM +0200, Yann Ylavic wrote:
> The call chain is:
> apr_bucket_setaside(bucket, newpool)
> => file_bucket_setaside(bucket, newpool)
> => apr_file_setaside(&newfd, bucket->data->fd, newpool)
> => copy bucket->data->fd to newfd, move cleanup to newpool
On Sun, Apr 26, 2020 at 05:26:02PM +0200, Yann Ylavic wrote:
> For FILE buckets, the behaviour of apr_bucket_setaside() is to take
> *full* ownership of the underlying apr_file, that is: allocate/move
> the file/cleanup to the new pool AND set the old file's fd to -1 (see
> apr_file_setaside, [1]).
On Fri, Apr 24, 2020 at 12:17:19PM +0200, Rainer Jung wrote:
> Thinking further: I think it would make sense to have a module or core
> implement the monitor hook to generate that derived data (requests/sec,
> bytes/sec, durationMs/request, avgConcurrency) in the last monitor interval
> and to prov
In the past two weeks we've had three true negative build failures from
Travis on trunk - i.e. bugs were introduced and CI caught them - and one
false negative (where the gcc 9 build broke because of some change in
the Ubuntu repo). So I think we're reaching the point where signal is
dominatin
On Thu, Apr 23, 2020 at 08:56:23AM -, rj...@apache.org wrote:
> URL: http://svn.apache.org/viewvc?rev=1876870&view=rev
> Log:
> systemd dependencies are only needed by mod_systemd.
> They should currently not be needed by httpd directly
> or any other binary. So no need to add them to
> HTTPD_L
Another one I'd like to check consensus on, before disappearing too far
down the rabbit-hole.
The ap_set_*_slot directive function initializers throw away type safety
completely since you can pass anything to APR_OFFSETOF(x,y) and it's
cast to void * regardless. I've seen one bug because of th
On Wed, Apr 22, 2020 at 12:50:36PM +0200, Yann Ylavic wrote:
> On Wed, Apr 22, 2020 at 12:10 PM Yann Ylavic wrote:
> >
> > > ':'
> >
> > This one looks special already in ap_resolve_env(), though it's
> > forbidden in Define so that may be it.
>
> I'm afraid ':' will collide with mod_rewrite's
>
On Tue, Apr 21, 2020 at 03:13:47PM +0100, Joe Orton wrote:
> On Tue, Apr 21, 2020 at 03:37:04PM +0200, Ruediger Pluem wrote:
> > Shouldn't that be argc < 2?
>
> It is < 3 to make the second arg truly optional, so a proto default is
No, you were right the logic was bo
On Tue, Apr 21, 2020 at 03:37:04PM +0200, Ruediger Pluem wrote:
> Looks good in general apart from the comment below.
>
> On 4/21/20 2:53 PM, Joe Orton wrote:
> > @@ -1058,7 +1104,24 @@ AP_DECLARE_NONSTD(const char *)
> > ap_set_listener(cmd_parms *cmd, void *dummy,
>
A previous conversation [1] about optionally enabling socket options for
Listen seemed to gain consensus around adding an optional argument,
rather than multiple alternative Listen-like directives.
I've attached a patch based on work by both Jan Kaluza and Lubos
Uhliarik which implements this,
On Fri, Apr 17, 2020 at 07:22:00PM +0200, Yann Ylavic wrote:
> On Thu, Apr 16, 2020 at 7:55 PM wrote:
> >
> > Author: jorton
> > Date: Thu Apr 16 17:55:48 2020
> > New Revision: 1876619
> >
> > URL: http://svn.apache.org/viewvc?rev=1876619&view=rev
> > Log:
> > * modules/core/mod_watchdog.c (wd_wo
On Wed, Apr 15, 2020 at 09:50:01AM -0400, Jim Jagielski wrote:
> very, very elegant.
Thank you Jim!
I wonder if the new state variable is redundant with the other state
variables in the watchdog structure? I don't understand the watchdog
model well enough to be confident here.
struct ap_watc
On Thu, Apr 02, 2020 at 10:58:21AM +0200, Yann Ylavic wrote:
> On Thu, Apr 2, 2020 at 6:39 AM Ruediger Pluem wrote:
> >
> > > +#define AP_BUCKET_IS_MORPHING(e)((e)->length == (apr_size_t)-1)
> >
> > Nitpick: After having a second thought on the whole thing, I think the
> > above name is misle
On Thu, Apr 02, 2020 at 10:37:01AM +0200, Ruediger Pluem wrote:
> Sounds reasonable. Thanks for explaining. Do you fix <= vs < and > vs >= or
> should I?
http://svn.apache.org/viewvc?view=revision&revision=1876037
I hope I have tweaked this to death now, but more review definitely
welcome since
On Thu, Apr 02, 2020 at 07:30:50AM +0200, Ruediger Pluem wrote:
> On 4/1/20 11:44 PM, Mike Rumph wrote:
> > I'm not very familiar with this code, so my questions might not make sense.
> >
> > But take a look at the following two code segments in
> > ssl_io_filter_coalesce():
> >
> > for (e =
On Wed, Apr 01, 2020 at 02:04:21PM +0200, Ruediger Pluem wrote:
> On 3/30/20 3:18 PM, jor...@apache.org wrote:
> >
> > -rv = apr_bucket_split(e, COALESCE_BYTES - (buffered + bytes));
> > +/* If the read above made the bucket morph, it may now fit
> > + * entirely within th
On Wed, Apr 01, 2020 at 10:06:20AM +0200, Ruediger Pluem wrote:
>
>
> On 4/1/20 9:53 AM, Joe Orton wrote:
> > On Wed, Apr 01, 2020 at 09:24:27AM +0200, Ruediger Pluem wrote:
> >> I have checked socket, pipe and cgi buckets and none of them seem to
> >> retu
On Wed, Apr 01, 2020 at 09:24:27AM +0200, Ruediger Pluem wrote:
> I have checked socket, pipe and cgi buckets and none of them seem to return
> EOF. In case they hit EOF they replace themselves with
> an immortal bucket of length 0. So above seems just an additional safety if a
> (future) morphin
On Tue, Mar 31, 2020 at 01:19:08AM +0200, Yann Ylavic wrote:
> FWIW, attached is v2 with simpler "batching" in
> ap_filter_setaside_brigade(), no spurious hunk, bb cleaned up at the
> end, and APR_ENOTIMPL when called from a filter < AP_FTYPE_CONNECTION.
FWIW this makes more sense to me than what'
On Mon, Mar 30, 2020 at 12:31:05AM +0200, Rainer Jung wrote:
> I can now see the same problem on Linux (eg. RHEL 7, SLES 12 and SLES 15)
> when doing testing for 2.4.43. I think it is not a regression and for me it
> is not a showstopper, but something that would be nice to fix. Symptom is
>
> [Sa
On Thu, Mar 26, 2020 at 09:50:12AM -0500, Daniel Ruggeri wrote:
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.43:
> [X]
On Thu, Mar 26, 2020 at 01:11:10AM +0200, Graham Leggett wrote:
> The question you’re asking is “why is is an async path being taken
> when AP_MPMQ_IS_ASYNC is false”. The setasides and reinstates should
> be noops in this situation.
The "noop" path in ap_filter_setaside_brigade is when it is pa
On Wed, Mar 25, 2020 at 11:20:32AM +0100, Rainer Jung wrote:
> And now I notice that's of course not appropriate (everone needing to change
> the call to the Makefile. So I will add local defaults in the spirit of your
> below suggestion into Makefile.PL.
Thanks a lot, looks good now with r1875640
On Tue, Mar 24, 2020 at 11:35:38PM +0100, Rainer Jung wrote:
> Excellent. That gave me the right idea where to look at.
>
> I found a way to pass additionals args inside Makefile.PL into
> Apache::TestMM::Argv which get automatically added to $vars in
> Apache::TestConfig. It seems to work well. C
On Tue, Mar 24, 2020 at 12:35:45AM +0200, Graham Leggett wrote:
> The most likely reason is because:
>
> a) http://httpd.apache.org/docs/trunk/mod/core.html#asyncfilter defaults to
> request, meaning request filters are expected to support async filters; and
>
> b) the worker MPM doesn't call th
On Sat, Feb 08, 2020 at 12:01:29PM +0100, Luca Toscano wrote:
> Hi everybody,
>
> Travis is able to read commit messages and skip the CI workflow if the
> "[skip ci]" magic sequence is added somewhere. I keep forgetting about
> it too, but it would be nice if we could start using it to avoid using
On Fri, Mar 06, 2020 at 09:30:41AM +0100, Ruediger Pluem wrote:
> On 3/4/20 9:23 AM, jor...@apache.org wrote:
> > Author: jorton
> > Date: Wed Mar 4 08:23:55 2020
> > New Revision: 1874775
> >
> > URL: http://svn.apache.org/viewvc?rev=1874775&view=rev
> > Log:
> > Update docs. The expr_string.t f
On Fri, Mar 20, 2020 at 12:28:31PM +, Travis CI wrote:
> Build Update for apache/httpd
> -
>
> Build: #500
> Status: Still Failing
This is now only failing because of the apxs bug so I'll give Eric the
pleasure of making it pass by merging the fix.
On Thu, Mar 19, 2020 at 04:27:06PM +, Joe Orton wrote:
> On Thu, Mar 19, 2020 at 08:32:25AM -0700, Mike Rumph wrote:
> > Build #484 fails on test #484.13, Linux Ubuntu, Regenerate ap_expr
> > +./buildconf --with-apr=/usr/bin/apr-1-config --with-regen-expr
> > unknown opti
On Thu, Mar 19, 2020 at 08:32:25AM -0700, Mike Rumph wrote:
> Build #484 fails on test #484.13, Linux Ubuntu, Regenerate ap_expr
> +./buildconf --with-apr=/usr/bin/apr-1-config --with-regen-expr
> unknown option --with-regen-expr
> The command "./test/travis run_${TRAVIS_OS_NAME}.sh" exited with 1
On Thu, Feb 27, 2020 at 11:30:58AM +, Joe Orton wrote:
> and weirdly the tests failing everywhere in the same places:
Obviously worked it out just after writing this, duh. It's because the
svn2git process drops empty directories, which we need preserved. Will
see if infra can fix
On Thu, Feb 20, 2020 at 09:04:21AM +, Joe Orton wrote:
> On Wed, Feb 19, 2020 at 08:20:20AM -0500, Eric Covener wrote:
> > On Wed, Feb 19, 2020 at 8:17 AM Joe Orton wrote:
> > > OK so I will ask for httpd/test/framework to be mirrored to github, but
> > > first the
On Wed, Feb 19, 2020 at 08:20:20AM -0500, Eric Covener wrote:
> On Wed, Feb 19, 2020 at 8:17 AM Joe Orton wrote:
> > OK so I will ask for httpd/test/framework to be mirrored to github, but
> > first the really hard question - what to name it? Assuming we can pick
> > an a
On Mon, Feb 17, 2020 at 05:32:48PM -0500, Eric Covener wrote:
> > >> There is also the complicating factor of the svn:external for
> > >> https://svn.apache.org/repos/asf/perl/Apache-Test/trunk
> > >>
> > >
> > > Good point. Not sure how to map svn:external in the git world.
> >
> > https://help.gi
On Mon, Feb 17, 2020 at 10:52:10AM -0500, Eric Covener wrote:
> On Mon, Feb 17, 2020 at 10:44 AM Joe Orton wrote:
> >
> > On Mon, Feb 17, 2020 at 04:30:40PM +0100, Stefan Eissing wrote:
> > > Does this look like a Travis problem? Just red on some "Linux Ubuntu"
On Mon, Feb 17, 2020 at 04:30:40PM +0100, Stefan Eissing wrote:
> Does this look like a Travis problem? Just red on some "Linux Ubuntu"
> combinations, but I do not really see the cause.
Yep, it's a timeout doing the "svn checkout" because the test suite was
updated, you can ignore.
On Mon, Feb 17, 2020 at 10:01:17AM +0100, Ruediger Pluem wrote:
> On 02/17/2020 09:20 AM, jor...@apache.org wrote:
> > Author: jorton
> > Date: Mon Feb 17 08:20:52 2020
> > New Revision: 1874102
> >
> > URL: http://svn.apache.org/viewvc?rev=1874102&view=rev
> > Log:
> > * modules/http/http_filters
On Fri, Feb 14, 2020 at 11:33:50AM +0100, Ruediger Pluem wrote:
> On 02/14/2020 10:08 AM, Joe Orton wrote:
> > I've been playing with UBSan[1] which catches undefined behaviour, found a
> > couple of interesting things so far.
> >
> > One is with event, I mess
I've been playing with UBSan[1] which catches undefined behaviour, found a
couple of interesting things so far.
One is with event, I messed with the line numbers but the error is:
event.c:3620:13: runtime error: null pointer passed as argument 2, which is
declared to never be null
from the mem
On Mon, Feb 10, 2020 at 07:22:45AM -0500, Eric Covener wrote:
> Is there anything possible in SVN like a pre-commit hook that can see
> what changed and append [skip ci] unless some other incantantation is
> present?
Seems like a neat idea, I think that could work *if* infra actually
allows us to
On Thu, Feb 06, 2020 at 07:52:18AM -0600, Daniel Ruggeri wrote:
> Hey there, Joe; No idea how I didn't detect this much sooner. I have
>access to hardware security modules with PKCS11 interfaces for key
>operations and would be happy to put this through it's paces. The
>2.5 docs are
On Fri, Jan 31, 2020 at 08:30:06AM +0100, Ruediger Pluem wrote:
> On 01/31/2020 04:14 AM, Luca Toscano wrote:
> > Hi everybody,
> >
> > I tested a bit the mod_systemd backport proposal (thanks Joe for
> > working on it!) and I have some doubts, that might be due to my
> > limited understanding of
I'd like to catch empty APLOGNO() use in CI, I think this should be an
error and IIRC it's tripped us up in 2.4 releases in the past. Two ways
to do this are:
1. For #ifdef AP_DEBUG, or for some other special-case, catch and fail
at compile-time for empty APLOGNO(). I think this should be poss
On Mon, Jan 13, 2020 at 08:46:54AM +0300, Benson Muite wrote:
>
> Hi,
>
> There was an earlier message on this list [0] about systemd support in 2.4 -
> r1625531 which am looking to find. Will this likely happen? As many
> distributions now use systemd, there is interest from distributions other
On Fri, Jan 10, 2020 at 09:55:24AM -0800, Mike Rumph wrote:
> I'm interested in taking a look at this t/apache/expr_string.t
> testcase failure. For example, is it the testcase that is in error or
> is it the code that it's testing? Maybe this can be discussed in a
> separate thread since it is
On Thu, Jan 09, 2020 at 03:01:42PM +0100, Luca Toscano wrote:
> Il giorno gio 9 gen 2020 alle ore 14:19 Joe Orton
> ha scritto:
> >
> > The caching does work on arm64 so the build & test only takes 11 minutes
> > which is reasonable.
> >
> > https://t
The caching does work on arm64 so the build & test only takes 11 minutes
which is reasonable.
https://travis-ci.org/apache/httpd/jobs/634661216
Looks like this one is the next unreliable test to attack -
2425# Failed test 17 in t/apache/expr_string.t at line 87
2426# Failed test 20 in t/apach
On Thu, Jan 09, 2020 at 09:10:31AM +, Pluem, Ruediger, Vodafone Group wrote:
> Would
>
> lscpu -p | grep -c -E ^[0-9]
>
> work on Ubuntu to deliver the number of cores?
>
> So
>
> make -j `lscpu -p | grep -c -E ^[0-9]`
I've got no idea if this DTRT for the mix of VMs & containers that
tra
On Wed, Jan 08, 2020 at 02:50:17PM -0800, Mike Rumph wrote:
> Okay the first Travis run with arm64 (#201) passed.
> The arm64 job (#201.4) took 33 minutes, 5 seconds.
> Compared tp ppc64le at 4 minutes, 30 seconds.
> This is possibly due to need for extra caching on the first run.
> Otherwise, the
On Tue, Jan 07, 2020 at 07:31:42PM +0100, Yann Ylavic wrote:
> Could you please try the attached patch?
> The goal is to make ap_request_core_filter() a connection filter, so
> that it remains in c->output_filters until the EOR is handled.
> The patch has subtleties, but ap_request_core_filter() is
On Tue, Jan 07, 2020 at 01:27:33PM -0800, Mike Rumph wrote:
> I would like to add support for arm64 to httpd/trunk/.travis.yml.
> I would then devote some time to getting this support to work.
> Are there some steps I should take before adding this commit?
That'd be great! If you are familiar wit
This is a classic heisenbug since it is timing related, when you add
more debugging it slows the server down enough that the client can keep
up, write never returns EAGAIN, and the bug disappears, I think...
I see from 2016 people have reported similar failures before ("Subject:
Some test failu
On Mon, Jan 06, 2020 at 06:38:29PM +, Travis CI wrote:
> Build Update for apache/httpd
> -
>
> Build: #190
> Status: Still Failing
>
> Duration: 7 mins and 11 secs
> Commit: 894b6a1 (trunk)
> Author: Luca Toscano
> Message: travis: add verbose config to per
On Sun, Dec 01, 2019 at 12:05:15PM +0100, Luca Toscano wrote:
> Hi everybody,
>
> Travis seems not able to deliver emails to dev@, I opened a jira to
> Infra: https://issues.apache.org/jira/browse/INFRA-19508
Thanks!
> +svn export -q -r
> https://svn.apache.org/repos/asf/apr/apr/branches/1.7.x
>
On Fri, Nov 22, 2019 at 09:35:01AM +0100, Ruediger Pluem wrote:
> On 11/21/2019 10:30 AM, jor...@apache.org wrote:
> > Author: jorton
> > Date: Thu Nov 21 09:30:34 2019
> > New Revision: 1870077
...
> > +function install_apx() {
> > +local name=$1
> > +local version=$2
> > +local root=h
On Fri, Nov 15, 2019 at 08:10:28PM +0100, Ruediger Pluem wrote:
> > --- httpd/httpd/trunk/test/travis_run_linux.sh (original)
> > +++ httpd/httpd/trunk/test/travis_run_linux.sh Tue Nov 12 12:45:57 2019
> > @@ -1,7 +1,7 @@
> > #!/bin/bash -ex
> > ### Installed apr/apr-util don't include the *.m4 f
On Tue, Nov 12, 2019 at 02:39:58PM +0100, Luca Toscano wrote:
> Il giorno mar 12 nov 2019 alle ore 12:40 Joe Orton
> ha scritto:
> >
> > Thanks to everyone who gave feedback, I made the change to require APR
> > 1.6 in r1869684. While I kept the Travis builds passing,
Thanks to everyone who gave feedback, I made the change to require APR
1.6 in r1869684. While I kept the Travis builds passing, buildbot broke
since it's doing a trunk build against the system APR. Does anybody
know if there is a buildbot slave running Bionic?
Regards, Joe
On Fri, Nov 08, 2019 at 11:04:32AM +0100, Ruediger Pluem wrote:
> On 11/06/2019 12:45 PM, jor...@apache.org wrote:
> > ==
> > --- httpd/httpd/trunk/test/travis_before_linux.sh (added)
> > +++ httpd/httpd/trunk/test/travis_b
On trunk the configure script requires APR 1.4 but mod_proxy_balancer
fails to build with APR < 1.5 since it uses apr_escape.h unconditionally
[1]. Thinking of 2.5/2.6 it might make sense to bump up the APR version
requirement to something newer, any opinions? RHEL 8 and Bionic
(18.04LTS) bot
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 mo
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 -
https://travis-ci.org/notroj/httpd/jobs/608306769#L3244
(I'm trying to get Travis working in 2.4.x as well.)
Regards, Jo
On Wed, Nov 06, 2019 at 10:54:56AM +0100, Luca Toscano wrote:
> I just noticed
> https://docs.travis-ci.com/user/installing-dependencies/#installing-dependencies-on-multiple-operating-systems,
> so the 'addons' will be used by travis only if the os can use them (I
> was afraid of having windows an
On Tue, Nov 05, 2019 at 10:06:23AM +0100, Luca Toscano wrote:
> Basically what Joe did, but following what the Apache Arrow Project
> did. There is a little bit of repetition, but in theory with this
> config people are free to add tests for other OSes (osx, windows) and
> I will probably be able t
On Mon, Nov 04, 2019 at 09:35:09PM +0100, Ruediger Pluem wrote:
> On 10/25/2019 12:52 PM, Yann Ylavic wrote:
> > My feeling is that it's easier to start from trunk, no strong feeling
> > (an intuitive one).
> >
> > So how about:
> > 0. github workflow? meanwhile...
> > 1. compare trunk/2.4.x (in
Here is a proof of concept -
https://github.com/notroj/httpd/blob/a73adfc8f1c01fbb6a3d493582f9c49c7c942756/.travis.yml
This runs using the full test suite using a few different configurations
and also does builds with -Werror and maintainer-mode -
https://travis-ci.org/notroj/httpd/builds/60721
On Sun, Oct 27, 2019 at 06:42:58PM +0100, Luca Toscano wrote:
> Some updates:
>
> - We have support for httpd in travis - https://travis-ci.org/apache/httpd
Nice, thanks Luca & infra!
> - In order to configure automatic builds, a travis.yaml file is needed
> in the base path of the repository, i
On Mon, Oct 14, 2019 at 04:51:56PM +0200, Stefan Sperling wrote:
> On Mon, Oct 14, 2019 at 03:27:31PM +0100, Joe Orton wrote:
> > At the moment I think we have a quality control problem for 2.4.x, yet I
> > find it hard to justify spending much time on writing test cases because
On Tue, Oct 08, 2019 at 02:17:12PM +0200, Luca Toscano wrote:
> Il giorno mar 8 ott 2019 alle ore 11:04 Greg Stein
> ha scritto:
> >
> > Travis CI is possible *today* ... since the svn commits are
> > replicated over to github, Travis can pick them up and run tests.
> > Just file an INFRA ticket
On Sat, Oct 05, 2019 at 04:09:34PM -0400, Jim Jagielski wrote:
> Various PMCs have made their default/de-facto SCM git and have seen an
> increase in contributions and contributors...
>
> Is this something the httpd project should consider? Especially w/ the
> foundation officially supporting Gi
On Mon, Sep 02, 2019 at 08:12:38AM +0200, Ruediger Pluem wrote:
> I vaguely remember that backports of changes to .gdbinit are CTR but I cannot
> find it any longer.
> So if we would agree on it I would add it to the "Current exceptions for RTC
> for this branch:" in the STATUS file.
> Comments /
On Wed, Aug 28, 2019 at 02:24:40PM +0200, Ruediger Pluem wrote:
> On 08/06/2019 05:41 PM, jor...@apache.org wrote:
> > Author: jorton
> > Date: Tue Aug 6 15:41:22 2019
> > New Revision: 1864526
...
> > +ret = apr_brigade_length(ctx->bb, 1, &got);
> > +if (ret || got > want)
On Tue, Aug 13, 2019 at 02:50:17PM -0700, Brad Warren wrote:
> * httpd 2.4.18 (from Ubuntu 16.04)
> * httpd 2.4.25 (from Debian 9)
> * httpd 2.4.39 (from Amazon Linux 2)
>
> They were presumably using the version of OpenSSL available in those
> distributions as well although I haven’t been able t
On Fri, Aug 09, 2019 at 08:40:38AM -0500, Daniel Ruggeri wrote:
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this candidate
> tarball as 2.4.41:
> [
On Sat, Aug 10, 2019 at 11:58:44AM +0200, Marion & Christophe JAILLET wrote:
> Hi all,
>
> I would appreciate some other eyes on the patch below.
> I guess that that the fix is correct, but I don't know the possible
> implication of the fix.
>
> As said in the commit description, -1 seems to be a
On Thu, Aug 08, 2019 at 09:09:57AM -0400, Eric Covener wrote:
> CC dev@ I assumed this was safe to just assert.
>
> On Thu, Aug 8, 2019 at 9:08 AM wrote:
> >
> > Author: covener
> > Date: Thu Aug 8 13:08:33 2019
> > New Revision: 1864701
> >
> > URL: http://svn.apache.org/viewvc?rev=1864701&view
201 - 300 of 1564 matches
Mail list logo
