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?
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=rev
> > Log:
> > mod_ssl: Switch to using
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 g
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.
ell 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
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
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?
> >
> >
tatic 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 mod_status and mod_systemd.
>
> Regards,
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(, 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,
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
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
On Thu, Apr 23, 2020 at 08:56:23AM -, rj...@apache.org wrote:
> URL: http://svn.apache.org/viewvc?rev=1876870=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_LIBS.
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
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 borked.
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=rev
> > Log:
> > * modules/core/mod_watchdog.c
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
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
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=1876037
I hope I have tweaked this to death now, but more review definitely
welcome since I found
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
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
> >>
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)
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
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
>
>
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:
>
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
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
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.
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
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
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=rev
> > Log:
> > Update docs. The expr_string.t
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
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
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.
> >
> >
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=rev
> > Log:
> > * modules/http/http_filters.c
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 m
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
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
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
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
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
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()
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
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
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
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
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
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)
> > +++
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)
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
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,
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
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
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
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 -
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,
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
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
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, );
> > +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
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
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=rev
On Tue, Aug 06, 2019 at 09:57:50AM +0200, Rainer Jung wrote:
> Thank you. It's funny, that the warning happens directly before the new
> pragma use to influence -Wcomment ...
No worries, quite a funny one indeed ;)
On Sun, Aug 04, 2019 at 04:51:45PM -0400, Dennis Clarke wrote:
> Quick reply here to let you know that the build fails instantly
> within server/config.c at func process_resource_config_cb() with
> a strange error uttered by Oracle Studio 12.6 thus :
...
> "config.c", line 1907: error: undefined
On Mon, Jul 22, 2019 at 09:08:48PM +0200, Rüdiger Plüm wrote:
> On 07/17/2019 09:51 AM, jor...@apache.org wrote:
> > Copied: httpd/httpd/trunk/modules/generators/cgi_common.h (from r1863117,
> > httpd/httpd/trunk/modules/generators/mod_cgi.c)
> > URL:
> >
If anybody is interested to test this out I have a 2.4.x backport here:
http://people.apache.org/~jorton/httpd-2.4.x-cgid-fdpassing.patch
which ignores the configure test and hard-codes to enabling the new code
(unlike code in trunk).
I think we're now at parity between mod_cgi and mod_cgid in
On Wed, Jul 10, 2019 at 01:40:10PM +0200, Stefan Eissing wrote:
> Added descriptions for this.
>
> Updated the backport patch. Updated the mod_md version in trunk, 2.4.x
> and github master and github maintenance branch. At this time, each
> change is about half a day's work.
Thanks, all
On Tue, Jul 09, 2019 at 11:57:00AM +0200, Stefan Eissing wrote:
> mod_md v2.0.x has landed in 2.4.x. This offers the ACMEv2 (RFC 8555) support
> and offers various monitoring possibilities for admins to see what is going
> on. But...it really needs votes for a mod_ssl related backport:
>
>
On Fri, Jul 05, 2019 at 01:39:21PM +0200, Ruediger Pluem wrote:
> How much portable is this and do we have / should have something in
> APR that does that portability? We probably should guard this with a
> check for
>
> #ifndef CMSG_DATA
> #error This module only works on unix platforms with
PR 54211 and 60692 track a design problem in mod_cgid: the stderr of
spawned CGI scripts is a copy of the main server's stderr. This is a
significant regression from mod_cgi (you lose logging prefixes,
per-vhost config, non-file/pipe-logging provider support e.g. syslog)
I can think of two
On Wed, Jul 03, 2019 at 08:45:36AM +0100, Steve Hay wrote:
> Please download, test, and report back on this Apache-Test 1.41
> release candidate.
>
> https://dist.apache.org/repos/dist/dev/perl/Apache-Test-1.41-rc1.tar.gz
>
> MD5 = 7933d3a6a762f087bf7883a1ac2086eb
> SHA1 =
On Tue, Jun 18, 2019 at 07:29:51PM +0200, Christophe JAILLET wrote:
> Hi,
>
> Just for the records, this is apparently already pat of r1809037 on trunk.
Stefan are you planning to merge the changes here to 2.4.x any time
soon? If not can I get a few +1s on the attached so 2.4.x can be
201 - 300 of 1530 matches
Mail list logo
