Preferred versions of libtool and autoconf for TR
What are our preferred versions of autoconf and libtool for TR on the weekend? As far as I remember autoconf 2.61 had some problems. Regards Rüdiger
Re: Preferred versions of libtool and autoconf for TR
Plüm, Rüdiger, VF-Group wrote: What are our preferred versions of autoconf and libtool for TR on the weekend? As far as I remember autoconf 2.61 had some problems. I'm not actually sure now days what specific version should be used, I haven't done RM in a while :-/ Just make sure you use a local copy, hand compiled version, not something an operating packaging system installs, and possibly patches to their liking. -Paul
Re: Preferred versions of libtool and autoconf for TR
-Ursprüngliche Nachricht- Von: Paul Querna Gesendet: Freitag, 28. November 2008 17:55 An: dev@httpd.apache.org Betreff: Re: Preferred versions of libtool and autoconf for TR Plüm, Rüdiger, VF-Group wrote: What are our preferred versions of autoconf and libtool for TR on the weekend? As far as I remember autoconf 2.61 had some problems. I'm not actually sure now days what specific version should be used, I haven't done RM in a while :-/ Just make sure you use a local copy, hand compiled version, not That was my plan. Jim what versions did you use last time? something an operating packaging system installs, and possibly patches to their liking. Regards Rüdiger
Intent to Roll 2.3.0-alpha
Hi dev@,
FYI, I intend to roll 2.3.0-alpha, our first release from trunk in about
3 years, on Saturday December 6th.
As in the previous 2.${odd} release cycles, this is not a stable
release, do not guarantee a stable ABI, and would not be recommended for
production usage:
https://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING
I think we need to start stabilizing trunk, and getting on the path of
doing 2.4.x 'soon'.
In other words, if you wanted some big ass feature in 2.4, start coding
now, your time is short :D
Thanks,
Paul
Re: Preferred versions of libtool and autoconf for TR
Plüm, Rüdiger, VF-Group schrieb: -Ursprüngliche Nachricht- Von: Paul Querna Gesendet: Freitag, 28. November 2008 17:55 An: dev@httpd.apache.org Betreff: Re: Preferred versions of libtool and autoconf for TR Plüm, Rüdiger, VF-Group wrote: What are our preferred versions of autoconf and libtool for TR on the weekend? As far as I remember autoconf 2.61 had some problems. I'm not actually sure now days what specific version should be used, I haven't done RM in a while :-/ Just make sure you use a local copy, hand compiled version, not That was my plan. Jim what versions did you use last time? The generated files in the httpd distribution and also in the bundled apr/apr-util tell us it was autoconf 2.61 and libtool 1.5.26. There was a short discussion about autoconf versions and apr and httpd releasing before 2.2.10: http://marc.info/?t=12216820601r=1w=2 The technical reasons for nit chosing 2.62 are contained in the discussion starting with your mail http://marc.info/?l=apr-devm=121814441110258w=2 Regards, Rainer
Re: Intent to Roll 2.3.0-alpha
On Nov 28, 2008, at 9:04 AM, Paul Querna wrote: FYI, I intend to roll 2.3.0-alpha, our first release from trunk in about 3 years, on Saturday December 6th. +1, let's get that code out there. As part of this process, I would like us (the group) to identify *early* which third party modules are popular with our userbase, and pro-actively approach their vendors so that they know what we're doing. Then they can make their plans to release without being blindsided. Off the top of my head I'm thinking: * PHP * Oracle (WebLogic) * Breach (ModSecurity) Let's throw this on the user list once the Alpha is out and see what's important to them. S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: Intent to Roll 2.3.0-alpha
Sander Temme wrote: On Nov 28, 2008, at 9:04 AM, Paul Querna wrote: FYI, I intend to roll 2.3.0-alpha, our first release from trunk in about 3 years, on Saturday December 6th. +1, let's get that code out there. As part of this process, I would like us (the group) to identify *early* which third party modules are popular with our userbase, and pro-actively approach their vendors so that they know what we're doing. Then they can make their plans to release without being blindsided. Off the top of my head I'm thinking: * PHP * Oracle (WebLogic) * Breach (ModSecurity) FastCGI support for Rails, Django, etc. mod_fcgid seems to be the most popular now days. Would be nice if someone had time to polish mod_proxy_fcgi -Paul
Re: Preferred versions of libtool and autoconf for TR
On 11/28/2008 06:35 PM, Rainer Jung wrote: Plüm, Rüdiger, VF-Group schrieb: -Ursprüngliche Nachricht- Von: Paul Querna Gesendet: Freitag, 28. November 2008 17:55 An: dev@httpd.apache.org Betreff: Re: Preferred versions of libtool and autoconf for TR Plüm, Rüdiger, VF-Group wrote: What are our preferred versions of autoconf and libtool for TR on the weekend? As far as I remember autoconf 2.61 had some problems. I'm not actually sure now days what specific version should be used, I haven't done RM in a while :-/ Just make sure you use a local copy, hand compiled version, not That was my plan. Jim what versions did you use last time? The generated files in the httpd distribution and also in the bundled apr/apr-util tell us it was autoconf 2.61 and libtool 1.5.26. There was a short discussion about autoconf versions and apr and httpd releasing before 2.2.10: http://marc.info/?t=12216820601r=1w=2 The technical reasons for nit chosing 2.62 are contained in the discussion starting with your mail http://marc.info/?l=apr-devm=121814441110258w=2 Thanks for the pointers. Any objections going with autoconf 2.63 and libtool 1.5.26? If autoconf 2.63 is seen as too risky I would go back to autoconf 2.61. Regards Rüdiger
Re: Intent to Roll 2.3.0-alpha
On 11/28/2008 06:58 PM, Sander Temme wrote: On Nov 28, 2008, at 9:04 AM, Paul Querna wrote: FYI, I intend to roll 2.3.0-alpha, our first release from trunk in about 3 years, on Saturday December 6th. +1, let's get that code out there. As part of this process, I would like us (the group) to identify *early* which third party modules are popular with our userbase, and pro-actively approach their vendors so that they know what we're doing. Then they can make their plans to release without being blindsided. Off the top of my head I'm thinking: * PHP * Oracle (WebLogic) * Breach (ModSecurity) Let's throw this on the user list once the Alpha is out and see what's important to them. +1 to this approach. Regards Rüdiger
Re: Intent to Roll 2.3.0-alpha
mod_perl comes to mind too. To a lesser extend mod_security and mod_macro. ~Jorge On Fri, Nov 28, 2008 at 10:06 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: On 11/28/2008 06:58 PM, Sander Temme wrote: On Nov 28, 2008, at 9:04 AM, Paul Querna wrote: FYI, I intend to roll 2.3.0-alpha, our first release from trunk in about 3 years, on Saturday December 6th. +1, let's get that code out there. As part of this process, I would like us (the group) to identify *early* which third party modules are popular with our userbase, and pro-actively approach their vendors so that they know what we're doing. Then they can make their plans to release without being blindsided. Off the top of my head I'm thinking: * PHP * Oracle (WebLogic) * Breach (ModSecurity) Let's throw this on the user list once the Alpha is out and see what's important to them. +1 to this approach. Regards Rüdiger
Re: Preferred versions of libtool and autoconf for TR
Ruediger Pluem wrote: Any objections going with autoconf 2.63 and libtool 1.5.26? If autoconf 2.63 is seen as too risky I would go back to autoconf 2.61. I see no remaining issues for 2.63... solid choice. The endianess issues of 2.62 should all be addressed.
error code overlap -- AP_FILTER_ERROR vs. SUSPENDED
There are a couple of places, in trunk only, where the macro SUSPENDED
is checked against a handlers return code.
1 45 include/util_filter.h GLOBAL
#define AP_FILTER_ERROR -3
1460 include/httpd.h GLOBAL
#define SUSPENDED -3
Note that AP_FILTER_ERROR can be returned by a handler that calls
ap_discard_request_body(), in the same contexts that checking against
SUSPENDED is intersting
I was looking to add an additional clause to the IGNORE_HTTP_RANGE
checking in ap_invoke_handler, but found in trunk it wasn't necessary
because of the overlap:
Index: server/config.c
===
--- server/config.c (revision 713453)
+++ server/config.c (working copy)
@@ -382,6 +382,7 @@
handler \%s\ not found for: %s, r-handler, r-filename);
}
if ((result != OK) (result != DONE) (result != DECLINED)
(result != SUSPENDED)
+ (result != AP_FILTER_ERROR) /* no-op on trunk due to SUSPENDED */
!ap_is_HTTP_VALID_RESPONSE(result)) {
/* If a module is deliberately returning something else
* (request_rec in non-HTTP or proprietary extension?)
(ap_die ignores AP_FILTER_ERROR, but not when it's been transformed
from -3 to 500 by the code above -- LimitRequestBody with a custom
ErrorDocument is busted on 2.2.x due to this)
--
Eric Covener
[EMAIL PROTECTED]
Re: error code overlap -- AP_FILTER_ERROR vs. SUSPENDED
Eric Covener wrote:
There are a couple of places, in trunk only, where the macro SUSPENDED
is checked against a handlers return code.
1 45 include/util_filter.h GLOBAL
#define AP_FILTER_ERROR -3
1460 include/httpd.h GLOBAL
#define SUSPENDED -3
Uhm, Util filter also defines:
/** Returned by the bottom-most filter if no data was written.
* @see ap_pass_brigade(). */
#define AP_NOBODY_WROTE -1
/** Returned by the bottom-most filter if no data was read.
* @see ap_get_brigade(). */
#define AP_NOBODY_READ -2
/** Returned when?? @bug find out when! */
#define AP_FILTER_ERROR -3
To be honest, I don't think these are used as they should be, and this
is also a pain since DECLINED is -1, so there was already an overlap.
If anything, change the ones in util_filter.h to different numbers, but
better yet, remove them all, and have _one_ place for return values from
a handler and the filters you pass to directly to be defined.
-Paul
Note that AP_FILTER_ERROR can be returned by a handler that calls
ap_discard_request_body(), in the same contexts that checking against
SUSPENDED is intersting
I was looking to add an additional clause to the IGNORE_HTTP_RANGE
checking in ap_invoke_handler, but found in trunk it wasn't necessary
because of the overlap:
Index: server/config.c
===
--- server/config.c (revision 713453)
+++ server/config.c (working copy)
@@ -382,6 +382,7 @@
handler \%s\ not found for: %s, r-handler, r-filename);
}
if ((result != OK) (result != DONE) (result != DECLINED)
(result != SUSPENDED)
+ (result != AP_FILTER_ERROR) /* no-op on trunk due to SUSPENDED */
!ap_is_HTTP_VALID_RESPONSE(result)) {
/* If a module is deliberately returning something else
* (request_rec in non-HTTP or proprietary extension?)
(ap_die ignores AP_FILTER_ERROR, but not when it's been transformed
from -3 to 500 by the code above -- LimitRequestBody with a custom
ErrorDocument is busted on 2.2.x due to this)
Re: Intent to Roll 2.3.0-alpha
Jorge Schrauwen wrote: mod_perl comes to mind too. yeah really *cough* mod perl committer -- Philip M. Gollucci ([EMAIL PROTECTED]) c:703.336.9354 Consultant - P6M7G8 Inc. - http://p6m7g8.net 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: svn commit: r721020 - in /httpd/httpd/trunk: configure.in srclib/pcre/
[EMAIL PROTECTED] wrote: Author: pquerna Date: Wed Nov 26 14:53:34 2008 New Revision: 721020 URL: http://svn.apache.org/viewvc?rev=721020view=rev Log: Stop bundling PCRE in trunk. Definitely needs an entry in CHANGES IMHO. -- Philip M. Gollucci ([EMAIL PROTECTED]) c:703.336.9354 Consultant - P6M7G8 Inc. - http://p6m7g8.net 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
