Fwd: Getting Ready for FOSDEM 2017

[Rich Bowen]

FYI, if you're going to be at FOSDEM in February, it would be awesome to
see you there, and we can use some help promoting the ASF at the booth.


 Forwarded Message 
Subject: Getting Ready for FOSDEM 2017
Date: Thu, 05 Jan 2017 13:30:49 -
From: Sharan Foga 
Reply-To: d...@community.apache.org
To: d...@community.apache.org

Hi Everyone

FOSDEM is less than a month away. For those of you who don't know about
FOSDEM then please take a look at the link below:

https://fosdem.org/2017/

The main thing that people highlight is that it is free so please
promote going to FOSDEM to your communities.
FOSDEM Wiki Page
---
I've updated the FOSDEM wiki page to include the key details from the
conference.

https://cwiki.apache.org/confluence/display/COMDEV/FOSDEM+2017

Please take a look. We are looking for volunteers to help out on the
booth over the 2 days of the conference, so if you are going to be there
and are willing to help then please add your name to the volunteer list.

ASF Booth

This year the ASF will again be running a booth at FOSDEM. Unfortunately
we will only have one (last year we had a separate one for AOO too). As
usual we will be talking to people about the ASF and giving away some
ASF swag.

Promoting Your Project at FOSDEM
-
FOSDEM has up to 4-5000 attendees so is a great place to spread the word
about your project.

If you would like to spend time on the ASF booth promoting your project
then please sign up on the FOSDEM wiki page.  Initially we would like to
split this into slots of 3-4 hours but this will depend on the number of
projects that are represented.

Project Stickers
--
If you are going to be at FOSDEM and do not have any project stickers to
give away then we may, budget permitting be able to help you get some
printed. Please contact me with your requirements.
Community Devroom
---
This year FOSDEM will specifically include a Community Devroom covering
a range of community related topics. See below for schedule

https://fosdem.org/2017/schedule/track/community/
Social Event
--
People have asked about organising a ASF social event / meetup during
the conference. This is possible but we will need know how many people
are interested and what date works best for everyone. The wiki page
contains a section for you to let us know when you will be in Brussels
so please add your details if you would like to participate.

I hope this helps people see what a great event FOSDEM is and I'm
looking forward to seeing lots of people from our ASF communities there.

Thanks
Sharan

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org




signature.asc
Description: OpenPGP digital signature

Re: [proposed] 2.4 Maintenance SIG

[Jacob Champion]

On 01/04/2017 11:55 AM, Graham Leggett wrote:

On 04 Jan 2017, at 8:37 PM, Jacob Champion  wrote:

So, there's 3k of the 20k. And remember, my point was that we can
fix what I call "dead code" with good old fashioned legwork. I
don't advocate trashing trunk, and I don't think having "dead code"
is a disaster or a stain on anyone here. I just don't think it's
appropriate to spin up an RC from trunk as-is.


Look for the discussion that occurred around November 2011 when v2.4
was released:

http://smtp.grokbase.com/t/apache/dev/11bb6wswq2/branched-httpd-2-4-x

 We came to the same conclusion then.


I started a longer reply to what you wrote earlier in the email, but I 
think I need to clear up any misunderstandings I have with this part first.


From offlist discussions I've had with other committers (and Bill's 
recent reply to this thread), my understanding was that an alpha/beta 
branch would be forked from the current tip of trunk, followed by 
testing and additional feature work, until a .0 release is voted on.


The conversation you linked to appears to modify that somewhat: we 
started tagging trunk directly with alpha/beta, and at some point 
decided to fork a 2.4.x from a mostly current trunk. It also adds the 
information that 2.4.x was still CTR, up to the .0 release. But in both 
cases, the statement "we plan to fork 2.6.x from a current-ish trunk 
commit" seems to hold up pretty well.


Is that correct?

--Jacob

Re: svn commit: r1777460 - /httpd/httpd/trunk/modules/http/http_filters.c

[Yann Ylavic]

On Thu, Jan 5, 2017 at 11:42 PM, Yann Ylavic  wrote:
> On Thu, Jan 5, 2017 at 11:08 PM, William A Rowe Jr  
> wrote:
>> On Thu, Jan 5, 2017 at 4:05 PM, Eric Covener  wrote:
>>> Do we want this for the 2.2 release?
>>
>> I don't feel strongly about this.
>>
>> It is such an unusual edge case (I believe Yann pointed out it was a custom
>> module he was working around) that it should rarely be seen in the wild.
>>
>> I'd be fine if we want to accelerate this into 2.2.32, or get 2.2.32
>> out and then
>> backport to have the patch available for the very few who are impacted.
>
> Agreed, I wouldn't push it, and can live with a my own patching.
> Possibly another module/cgi uses that CRLF to LWS trick though, but
> not that I'm aware of so..

But if any of you fears a possible regression for older 2.2.x apps (I
see now that Eric included a test, I personnaly tested it this
afternoon with a custom integration suite too), I'm happy to propose
and vote it.

Re: svn commit: r1777460 - /httpd/httpd/trunk/modules/http/http_filters.c

[Yann Ylavic]

On Thu, Jan 5, 2017 at 11:08 PM, William A Rowe Jr  wrote:
> On Thu, Jan 5, 2017 at 4:05 PM, Eric Covener  wrote:
>> Do we want this for the 2.2 release?
>
> I don't feel strongly about this.
>
> It is such an unusual edge case (I believe Yann pointed out it was a custom
> module he was working around) that it should rarely be seen in the wild.
>
> I'd be fine if we want to accelerate this into 2.2.32, or get 2.2.32
> out and then
> backport to have the patch available for the very few who are impacted.

Agreed, I wouldn't push it, and can live with a my own patching.
Possibly another module/cgi uses that CRLF to LWS trick though, but
not that I'm aware of so..

Re: 2.2 needs a reviewer for http strict backport ...

[William A Rowe Jr]

On Thu, Jan 5, 2017 at 3:03 AM, Yann Ylavic  wrote:
> On Thu, Jan 5, 2017 at 3:02 AM, Eric Covener  wrote:
>>
>> 2.2 running clean under test suite for me on Linux.
>
> Same here, thanks Eric for backporting.
>
> PS: I had to apply the OPENSSL_NO_SSL3 patch for my debian
> (libssl-1.0.2) to compile.
> One more vote please ;)
> PPS: The other (annoying) gcc warnings fix patches are welcome too :)

So I'm currently running regressions against all of the proposed backports,
including proxy / ssl bug fixes, given that SNI is very widely deployed now,
and SSL3 is now super-discouraged. Good set of proposals, Yann - thanks.

A few proxy bug fixes still need one more reviewer to be accepted.
I'll backport all which are accepted, and unless anyone raises an issue,
will move ahead with a tag tomorrow (Friday) to kick off a 2.2.32 release
vote.

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

On Thu, Jan 5, 2017 at 12:50 PM, Jacob Champion  wrote:
> On 01/04/2017 11:55 AM, Graham Leggett wrote:
>>
>> On 04 Jan 2017, at 8:37 PM, Jacob Champion  wrote:
>>>
>>> So, there's 3k of the 20k. And remember, my point was that we can
>>> fix what I call "dead code" with good old fashioned legwork. I
>>> don't advocate trashing trunk, and I don't think having "dead code"
>>> is a disaster or a stain on anyone here. I just don't think it's
>>> appropriate to spin up an RC from trunk as-is.
>>
>>
>> Look for the discussion that occurred around November 2011 when v2.4
>> was released:
>>
>> http://smtp.grokbase.com/t/apache/dev/11bb6wswq2/branched-httpd-2-4-x
>>
>>  We came to the same conclusion then.
>
>
> I started a longer reply to what you wrote earlier in the email, but I think
> I need to clear up any misunderstandings I have with this part first.
>
> From offlist discussions I've had with other committers (and Bill's recent
> reply to this thread), my understanding was that an alpha/beta branch would
> be forked from the current tip of trunk, followed by testing and additional
> feature work, until a .0 release is voted on.
>
> The conversation you linked to appears to modify that somewhat: we started
> tagging trunk directly with alpha/beta, and at some point decided to fork a
> 2.4.x from a mostly current trunk. It also adds the information that 2.4.x
> was still CTR, up to the .0 release. But in both cases, the statement "we
> plan to fork 2.6.x from a current-ish trunk commit" seems to hold up pretty
> well.
>
> Is that correct?

Following past practices, and a desire to reduce the amount of effort by
committers, I'd strongly object to a fork before 3.0 (or 2.6) is finalized.
It's a procedural-process sort of question, so it's a straightforward PMC
majority vote.

I'm also against forking at 3.0 or 2.6 until someone wants to introduce
an API breaking change, unless we solidify some new process for having
more predictable and frequent bug fix releases and split these from our
constant churn of feature changes. In that case, feature changes do map
well to trunk until there is a breaking ABI change, while we would need to
collect such bug fixes on a new branch.

Re: svn commit: r1777460 - /httpd/httpd/trunk/modules/http/http_filters.c

[Eric Covener]

Do we want this for the 2.2 release?

On Thu, Jan 5, 2017 at 7:31 AM,   wrote:
> Author: ylavic
> Date: Thu Jan  5 12:31:48 2017
> New Revision: 1777460
>
> URL: http://svn.apache.org/viewvc?rev=1777460=rev
> Log:
> http: allow folding in check_headers(), still compliant with RFC 7230 (3.2.4).
>
> Modified:
> httpd/httpd/trunk/modules/http/http_filters.c
>
> Modified: httpd/httpd/trunk/modules/http/http_filters.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?rev=1777460=1777459=1777460=diff
> ==
> --- httpd/httpd/trunk/modules/http/http_filters.c (original)
> +++ httpd/httpd/trunk/modules/http/http_filters.c Thu Jan  5 12:31:48 2017
> @@ -631,14 +631,16 @@ apr_status_t ap_http_filter(ap_filter_t
>
>  struct check_header_ctx {
>  request_rec *r;
> -int strict;
> +unsigned int strict:1,
> + unfold:1;
>  };
>
>  /* check a single header, to be used with apr_table_do() */
> -static int check_header(void *arg, const char *name, const char *val)
> +static int check_header(struct check_header_ctx *ctx,
> +const char *name, const char **val)
>  {
> -struct check_header_ctx *ctx = arg;
> -const char *test;
> +const char *pos, *end;
> +char *dst = NULL;
>
>  if (name[0] == '\0') {
>  ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, ctx->r, APLOGNO(02428)
> @@ -647,12 +649,12 @@ static int check_header(void *arg, const
>  }
>
>  if (ctx->strict) {
> -test = ap_scan_http_token(name);
> +end = ap_scan_http_token(name);
>  }
>  else {
> -test = ap_scan_vchar_obstext(name);
> +end = ap_scan_vchar_obstext(name);
>  }
> -if (*test) {
> +if (*end) {
>  ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, ctx->r, APLOGNO(02429)
>"Response header name '%s' contains invalid "
>"characters, aborting request",
> @@ -660,13 +662,54 @@ static int check_header(void *arg, const
>  return 0;
>  }
>
> -test = ap_scan_http_field_content(val);
> -if (*test) {
> -ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, ctx->r, APLOGNO(02430)
> -  "Response header '%s' value of '%s' contains invalid "
> -  "characters, aborting request",
> -  name, val);
> -return 0;
> +for (pos = *val; *pos; pos = end) {
> +end = ap_scan_http_field_content(pos);
> +if (*end) {
> +if (end[0] != CR || end[1] != LF || (end[2] != ' ' &&
> + end[2] != '\t')) {
> +ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, ctx->r, 
> APLOGNO(02430)
> +  "Response header '%s' value of '%s' contains "
> +  "invalid characters, aborting request",
> +  name, pos);
> +return 0;
> +}
> +if (!ctx->unfold) {
> +end += 3;
> +}
> +else if (!dst) {
> +*val = dst = apr_palloc(ctx->r->pool, strlen(*val) + 1);
> +}
> +}
> +if (dst) {
> +memcpy(dst, pos, end - pos);
> +dst += end - pos;
> +if (*end) {
> +/* skip folding and replace with a single space */
> +end += 3 + strspn(end + 3, "\t ");
> +*dst++ = ' ';
> +}
> +}
> +}
> +if (dst) {
> +*dst = '\0';
> +}
> +return 1;
> +}
> +
> +static int check_headers_table(apr_table_t *t, struct check_header_ctx *ctx)
> +{
> +const apr_array_header_t *headers = apr_table_elts(t);
> +apr_table_entry_t *header;
> +int i;
> +
> +for (i = 0; i < headers->nelts; ++i) {
> +header = _ARRAY_IDX(headers, i, apr_table_entry_t);
> +if (!header->key) {
> +continue;
> +}
> +if (!check_header(ctx, header->key, (const char **)>val)) {
> +return 0;
> +}
>  }
>  return 1;
>  }
> @@ -683,8 +726,10 @@ static APR_INLINE int check_headers(requ
>
>  ctx.r = r;
>  ctx.strict = (conf->http_conformance != AP_HTTP_CONFORMANCE_UNSAFE);
> -return apr_table_do(check_header, , r->headers_out, NULL) &&
> -   apr_table_do(check_header, , r->err_headers_out, NULL);
> +ctx.unfold = (!r->content_type || strncmp(r->content_type,
> +  "message/http", 12));
> +return check_headers_table(r->headers_out, ) &&
> +   check_headers_table(r->err_headers_out, );
>  }
>
>  static int check_headers_recursion(request_rec *r)
>
>



-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r1777460 - /httpd/httpd/trunk/modules/http/http_filters.c

[William A Rowe Jr]

On Thu, Jan 5, 2017 at 4:05 PM, Eric Covener  wrote:
> Do we want this for the 2.2 release?

I don't feel strongly about this.

It is such an unusual edge case (I believe Yann pointed out it was a custom
module he was working around) that it should rarely be seen in the wild.

I'd be fine if we want to accelerate this into 2.2.32, or get 2.2.32
out and then
backport to have the patch available for the very few who are impacted.

Re: Fixing module-specific, public include/*.h file inclusion on trunk

[William A Rowe Jr]

On Fri, Dec 16, 2016 at 1:22 PM, William A Rowe Jr  wrote:
> On Fri, Dec 16, 2016 at 12:57 PM, William A Rowe Jr 
> wrote:
>>
>> So today's primary bogus result is courtesy of is due to leaving
>> public headers hiding in modules/class/*.h paths for our builds.
>>
>> I'd suggest one of two approaches, pick a favorite solution?
>>
>>  [  ] Have the top level build copy all modules/*/mod_*.h
>>   definitions to the build tree include/ path (conditionally,
>>   based on datestamp)?
>>
>>  [  ] Make individual modules/*/Makefile[*] responsible for
>>   moving their headers into the build tree include/ path
>>   (conditionally, based on datestamp)?
>
>
> The challenge with option 2 is that we run the makefiles in
> sequence by directory name. It introduces the need to reorder
> the subdirectories by function, so that each makefile runs based
> on its dependencies (and reciprocal dependencies require the
> current /I "../foomodules/" hack.)

Decided that POLS applies here... we add all of these ../modules/foo/
paths to the unix compile command, we should do the same throughout
each and every make component in Windows (and Netware) so this
is less likely to bite us again before we entirely transition to CMake.

Re: svn commit: r1777460 - /httpd/httpd/trunk/modules/http/http_filters.c

[William A Rowe Jr]

On Thu, Jan 5, 2017 at 5:14 PM, Yann Ylavic  wrote:
> On Thu, Jan 5, 2017 at 11:49 PM, Yann Ylavic  wrote:
>>
>> But if any of you fears a possible regression for older 2.2.x apps (I
>> see now that Eric included a test, I personnaly tested it this
>> afternoon with a custom integration suite too), I'm happy to propose
>> and vote it.
>
> FWIW, proposed in STATUS for both to 2.2 and 2.4.

Excellent.

Since all other changes had lived on trunk and been accepted by several
more committers towards 2.4 backport, I'm more comfortable working in
the 2.4-stable changes onto 2.2 at this moment than adding new work,
but that's just my 2c. I'll vet and approve the patch after we wrap up 2.2.32
but if others jump on board to review it, I'm not about to object.

Re: 2.2 needs a reviewer for http strict backport ...

[Yann Ylavic]

On Thu, Jan 5, 2017 at 3:02 AM, Eric Covener  wrote:
>
> 2.2 running clean under test suite for me on Linux.

Same here, thanks Eric for backporting.

PS: I had to apply the OPENSSL_NO_SSL3 patch for my debian
(libssl-1.0.2) to compile.
One more vote please ;)
PPS: The other (annoying) gcc warnings fix patches are welcome too :)

Re: 2.2.x release on the horizon

[Steffen]

Exported revision 1777442.

No go:

Error13error C2143: syntax error : missing ';' before 'type'   
E:\VC10\Win32\httpd-2.2.32\modules\proxy\mod_proxy.c1093
Error14error C2065: 'post_status' : undeclared identifier
E:\VC10\Win32\httpd-2.2.32\modules\proxy\mod_proxy.c1101
Error15error C2065: 'post_status' : undeclared identifier
E:\VC10\Win32\httpd-2.2.32\modules\proxy\mod_proxy.c1102



btw.

Do we need the fix for the proxy crash as in 2.4.25 ?

https://www.apachelounge.com/viewtopic.php?t=7470

http://svn.apache.org/viewvc?view=revision=1775775



On Thursday 05/01/2017 at 03:10, Eric Covener  wrote:

Hi Steffen, we're about to kick off a 2.2.x release. Can you give
Windows a sniff-test?

Thanks,

--
Eric Covener
cove...@gmail.com

Re: 2.2.x release on the horizon

[Yann Ylavic]

Thanks Steffen for testing.

On Thu, Jan 5, 2017 at 11:02 AM, Steffen  wrote:
> Exported revision 1777442.
>
> No go:
>
> Error 13 error C2143: syntax error : missing ';' before 'type'
> E:\VC10\Win32\httpd-2.2.32\modules\proxy\mod_proxy.c 1093
> Error 14 error C2065: 'post_status' : undeclared identifier
> E:\VC10\Win32\httpd-2.2.32\modules\proxy\mod_proxy.c 1101
> Error 15 error C2065: 'post_status' : undeclared identifier
> E:\VC10\Win32\httpd-2.2.32\modules\proxy\mod_proxy.c 1102

Does it work with:
http://home.apache.org/~ylavic/patches/httpd-2.2.x-r1753592.patch ?
(Proposed for backported already).

>
> Do we need the fix for the proxy crash as in 2.4.25 ?
>
> https://www.apachelounge.com/viewtopic.php?t=7470
>
> http://svn.apache.org/viewvc?view=revision=1775775

No, this was a 2.4.x change/regression only.


Regards,
Yann.

Re: svn commit: r1777390 - /httpd/httpd/branches/2.2.x/STATUS

[Yann Ylavic]

On Thu, Jan 5, 2017 at 2:37 AM, Eric Covener  wrote:
>> + wrowe asks: covener, would you apply? I'd like to have at least a 
>> second
>> + pair of hands and eyes on merging this to branches/2.2.x 
>> and
>> + am happy to compare/verify against my working copy.
>> +
>
> getting a start on it now

Looks good to me, thanks Eric.

Re: 2.2.x release on the horizon

[Steffen]

It builds now on VC10 with the patch.

I cannot test is extensive, I have no test site for 2.2.

Btw. I already stopped distributing 2.2 for some time.


Regards,

Steffen AL


On Thursday 05/01/2017 at 11:40, Yann Ylavic  wrote:

Thanks Steffen for testing.

On Thu, Jan 5, 2017 at 11:02 AM, Steffen  
wrote:


Exported revision 1777442.

No go:

Error 13 error C2143: syntax error : missing ';' before 'type'
E:\VC10\Win32\httpd-2.2.32\modules\proxy\mod_proxy.c 1093
Error 14 error C2065: 'post_status' : undeclared identifier
E:\VC10\Win32\httpd-2.2.32\modules\proxy\mod_proxy.c 1101
Error 15 error C2065: 'post_status' : undeclared identifier
E:\VC10\Win32\httpd-2.2.32\modules\proxy\mod_proxy.c 1102


Does it work with:
http://home.apache.org/~ylavic/patches/httpd-2.2.x-r1753592.patch ?
(Proposed for backported already).




Do we need the fix for the proxy crash as in 2.4.25 ?

https://www.apachelounge.com/viewtopic.php?t=7470

http://svn.apache.org/viewvc?view=revision=1775775


No, this was a 2.4.x change/regression only.


Regards,
Yann.

Re: 2.2.x release on the horizon

[Yann Ylavic]

On Thu, Jan 5, 2017 at 12:12 PM, Steffen  wrote:
> It builds now on VC10 with the patch.

Good, so I'll "promote" it as showstopper.

>
> I cannot test is extensive, I have no test site for 2.2.
>
> Btw. I already stopped distributing 2.2 for some time.

Oh well, good to know, maybe we should stop asking you to test 2.2
then (it shouldn't happen so often now, though)..

Thanks again Steffen.

Re: 2.2.x release on the horizon

[Eric Covener]

On Thu, Jan 5, 2017 at 6:12 AM, Steffen  wrote:
> It builds now on VC10 with the patch.
>
> I cannot test is extensive, I have no test site for 2.2.

Thanks for jumping on the request so quickly.
> Btw. I already stopped distributing 2.2 for some time.

Double-thanks in light of this!


-- 
Eric Covener
cove...@gmail.com