[Fwd: cvs commit: ports/archivers/gtar Makefile distinfo ports/archivers/gtar/files extra-patch-tests_gzip.at patch-configure patch-tests_gzip.at patch-tests_pipe.at patch-tests_shortr

2008-12-30 Thread Philip M. Gollucci

gtar in freebsd ports now has this support as of today :)

since its in gtar, that means that any linux should have it once they 
update to a new enough version of gtar.




Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354
Consultant - P6M7G8 Inc.  http://p6m7g8.net
Senior System Admin - RideCharge, Inc.  http://ridecharge.com
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.
--- Begin Message ---
naddy   2008-12-30 17:41:11 UTC

  FreeBSD ports repository

  Modified files:
archivers/gtar   Makefile distinfo 
archivers/gtar/files patch-configure 
  Added files:
archivers/gtar/files patch-tests_gzip.at patch-tests_pipe.at 
 patch-tests_shortrec.at 
 patch-tests_testsuite.at 
  Removed files:
archivers/gtar/files extra-patch-tests_gzip.at 
  Log:
  * Update to 1.21.  Notable changes:
- Some new flags, e.g. -J for lzma compression and --lzop.
- transformation scope flags
Testsuite fixes from upstream CVS.
  
  * Drop workarounds for no longer supported FreeBSD releases.
  
  Revision  ChangesPath
  1.63  +4 -18 ports/archivers/gtar/Makefile
  1.20  +3 -3  ports/archivers/gtar/distinfo
  1.2   +0 -15 ports/archivers/gtar/files/extra-patch-tests_gzip.at 
(dead)
http://cvsweb.FreeBSD.org/ports/archivers/gtar/files/extra-patch-tests_gzip.at?rev=1.1&content-type=text/x-cvsweb-markup
  1.7   +9 -9  ports/archivers/gtar/files/patch-configure
  1.1   +15 -0 ports/archivers/gtar/files/patch-tests_gzip.at (new)
http://cvsweb.FreeBSD.org/ports/archivers/gtar/files/patch-tests_gzip.at?rev=1.1&content-type=text/x-cvsweb-markup
  1.1   +24 -0 ports/archivers/gtar/files/patch-tests_pipe.at (new)
http://cvsweb.FreeBSD.org/ports/archivers/gtar/files/patch-tests_pipe.at?rev=1.1&content-type=text/x-cvsweb-markup
  1.1   +33 -0 ports/archivers/gtar/files/patch-tests_shortrec.at (new)
http://cvsweb.FreeBSD.org/ports/archivers/gtar/files/patch-tests_shortrec.at?rev=1.1&content-type=text/x-cvsweb-markup
  1.1   +35 -0 ports/archivers/gtar/files/patch-tests_testsuite.at (new)
http://cvsweb.FreeBSD.org/ports/archivers/gtar/files/patch-tests_testsuite.at?rev=1.1&content-type=text/x-cvsweb-markup

http://cvsweb.FreeBSD.org/ports/archivers/gtar/Makefile.diff?r1=1.62&r2=1.63&f=h
| --- ports/archivers/gtar/Makefile 2008/08/20 00:56:24 1.62
| +++ ports/archivers/gtar/Makefile 2008/12/30 17:40:52 1.63
| @@ -2,12 +2,11 @@
|  # Date created:  Sa   6 Jun 1998 10:24:51 CEST
|  # Whom:  Andreas Klemm 
|  #
| -# $FreeBSD: /usr/local/www/cvsroot/FreeBSD/ports/archivers/gtar/Makefile,v 
1.62 2008/08/20 00:56:24 ade Exp $
| +# $FreeBSD: /usr/local/www/cvsroot/FreeBSD/ports/archivers/gtar/Makefile,v 
1.63 2008/12/30 17:40:52 naddy Exp $
|  #
|  
|  PORTNAME=tar
| -PORTVERSION= 1.20
| -PORTREVISION=1
| +PORTVERSION= 1.21
|  CATEGORIES=  archivers sysutils
|  MASTER_SITES=${MASTER_SITE_GNU}
|  MASTER_SITE_SUBDIR=  ${PORTNAME}
| @@ -18,9 +17,11 @@ COMMENT=   GNU version of the traditional 
|  
|  # Actually we need lzma(1), but not the one in archivers/lzma.
|  RUN_DEPENDS= ${LOCALBASE}/bin/lzcat:${PORTSDIR}/archivers/lzmautils
| +RUN_DEPENDS+=lzop:${PORTSDIR}/archivers/lzop
|  
|  INFO=tar
|  
| +USE_AUTOTOOLS=   autoconf:262:env# autom4te
|  USE_BZIP2=   yes
|  USE_ICONV=   yes
|  GNU_CONFIGURE=   yes
| @@ -44,22 +45,7 @@ CONFIGURE_ARGS+=--disable-nls
|  PLIST_SUB+=  NLS="@comment "
|  .endif
|  
| -.include 
| -
| -# after the GNU gzip implementation was replaced with a BSD licensed version
| -.if (${OSVERSION} >= 602105) && \
| -(${OSVERSION} < 70 || ${OSVERSION} >= 700029)
| -USE_AUTOTOOLS=   autoconf:262:env# autom4te
| -EXTRA_PATCHES=   ${PATCHDIR}/extra-patch-tests_gzip.at
| -.endif
| -
| -# avoid triggering auto framework rebuilds
| -# FreeBSD 5.5 makeinfo can't rebuild tar.info
| -post-patch:
| - @${TOUCH} -r ${WRKSRC}/configure.orig ${WRKSRC}/configure
| - @${TOUCH} ${WRKSRC}/doc/tar.info* ${WRKSRC}/stamp-vti
| -
|  regression-test: build
|   @cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${MAKE} check
|  
| -.include 
| +.include 
http://cvsweb.FreeBSD.org/ports/archivers/gtar/distinfo.diff?r1=1.19&r2=1.20&f=h
| --- ports/archivers/gtar/distinfo 2008/04/21 16:03:49 1.19
| +++ ports/archivers/gtar/distinfo 2008/12/30 17:41:02 1.20
| @@ -1,3 +1,3 @@
| -MD5 (tar-1.20.tar.bz2) = 1a7e17f27abf583b3b0bc059a827e68b
| -SHA256 (tar-1.20.tar.bz2) = 
be8bf33afb5adc2377e45d94693ffd46b75f267f9b808df0c7006e51211f9deb
| -SIZE (tar-1.20.tar.bz2) = 1912591
| +MD5 (tar-1.21.tar.bz2) = 4f9028d231c3e7d7bdd658e14e74c2d1
| +SHA256 (tar-1.21.tar.bz2) = 
dc6c70d2071ca4

Re: svn commit: r730181 - in /httpd/httpd/trunk/modules/mem: mod_slotmem.h providers/mod_plainmem.c providers/mod_sharedmem.c

2008-12-30 Thread Ruediger Pluem


On 12/30/2008 06:08 PM, j...@apache.org wrote:
> Author: jim
> Date: Tue Dec 30 09:08:24 2008
> New Revision: 730181
> 
> URL: http://svn.apache.org/viewvc?rev=730181&view=rev
> Log:
> And complete the API changes...
> 
> Modified:
> httpd/httpd/trunk/modules/mem/mod_slotmem.h
> httpd/httpd/trunk/modules/mem/providers/mod_plainmem.c
> httpd/httpd/trunk/modules/mem/providers/mod_sharedmem.c
> 
> Modified: httpd/httpd/trunk/modules/mem/mod_slotmem.h
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mem/mod_slotmem.h?rev=730181&r1=730180&r2=730181&view=diff
> ==

> Modified: httpd/httpd/trunk/modules/mem/providers/mod_plainmem.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mem/providers/mod_plainmem.c?rev=730181&r1=730180&r2=730181&view=diff
> ==
> --- httpd/httpd/trunk/modules/mem/providers/mod_plainmem.c (original)
> +++ httpd/httpd/trunk/modules/mem/providers/mod_plainmem.c Tue Dec 30 
> 09:08:24 2008

> @@ -167,6 +159,7 @@
>  
>  static void ap_plainmem_register_hook(apr_pool_t *p)
>  {
> +static const char * const prePos[] = { "mod_slotmem.c", NULL };

Why is prePos not used later on? And don't we need to do the same thing
regarding hook ordering for mod_sharedmem.c?

>  ap_register_provider(p, SLOTMEM_STORAGE, "plain", "0", &storage);
>  ap_hook_pre_config(pre_config, NULL, NULL, APR_HOOK_MIDDLE);
>  }
> 


Re: svn commit: r730180 - in /httpd/httpd/trunk/modules/mem: config5.m4 mod_plainmem.c mod_sharedmem.c mod_slotmem.c mod_slotmem.h providers/ providers/Makefile.in providers/config6.m4 providers/mod_p

2008-12-30 Thread Ruediger Pluem


On 12/30/2008 06:07 PM, j...@apache.org wrote:
> Author: jim
> Date: Tue Dec 30 09:07:25 2008
> New Revision: 730180
> 
> URL: http://svn.apache.org/viewvc?rev=730180&view=rev
> Log:
> Start of further refactoring
> 
> Added:
> httpd/httpd/trunk/modules/mem/mod_slotmem.c   (with props)
> httpd/httpd/trunk/modules/mem/mod_slotmem.h   (props changed)
>   - copied unchanged from r730179, httpd/httpd/trunk/modules/mem/slotmem.h
> httpd/httpd/trunk/modules/mem/providers/
> httpd/httpd/trunk/modules/mem/providers/Makefile.in   (with props)
> httpd/httpd/trunk/modules/mem/providers/config6.m4   (with props)
> httpd/httpd/trunk/modules/mem/providers/mod_plainmem.c   (props changed)
>   - copied unchanged from r730179, 
> httpd/httpd/trunk/modules/mem/mod_plainmem.c
> httpd/httpd/trunk/modules/mem/providers/mod_sharedmem.c   (props changed)
>   - copied unchanged from r730179, 
> httpd/httpd/trunk/modules/mem/mod_sharedmem.c
> Removed:
> httpd/httpd/trunk/modules/mem/mod_plainmem.c
> httpd/httpd/trunk/modules/mem/mod_sharedmem.c
> httpd/httpd/trunk/modules/mem/slotmem.h
> Modified:
> httpd/httpd/trunk/modules/mem/config5.m4
> 

> Added: httpd/httpd/trunk/modules/mem/providers/config6.m4
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mem/providers/config6.m4?rev=730180&view=auto
> ==
> --- httpd/httpd/trunk/modules/mem/providers/config6.m4 (added)
> +++ httpd/httpd/trunk/modules/mem/providers/config6.m4 Tue Dec 30 09:07:25 
> 2008
> @@ -0,0 +1,14 @@
> +dnl modules enabled in this directory by default
> +
> +dnl APACHE_MODULE(name, helptext[, objects[, structname[, default[, 
> config)
> +
> +APACHE_MODPATH_INIT(mem/providers)
> +
> +sharedmem_objs="mod_sharedmem.lo"
> +APACHE_MODULE(sharedmem, memslot provider that uses shared memory, 
> $sharedmem_objs, , $slotmem_mods_enable)
> +APACHE_MODULE(plainmem, memslot provider that uses plain memory, , , no)
> +
> +# Ensure that other modules can pick up slotmem.h
> +APR_ADDTO(INCLUDES, [-I\$(top_srcdir)/$modpath_current])

Why do we add this? slotmem.h should be in one directory above and should be 
already added
by the local config.m4 file.

Regards

Rüdiger


Re: svn commit: r730180 - in /httpd/httpd/trunk/modules/mem: config5.m4 mod_plainmem.c mod_sharedmem.c mod_slotmem.c mod_slotmem.h providers/ providers/Makefile.in providers/config6.m4 providers/mod_p

2008-12-30 Thread Jim Jagielski


On Dec 30, 2008, at 3:17 PM, Ruediger Pluem wrote:

+# Ensure that other modules can pick up slotmem.h
+APR_ADDTO(INCLUDES, [-I\$(top_srcdir)/$modpath_current])


Why do we add this? slotmem.h should be in one directory above and  
should be already added

by the local config.m4 file.



cut/paste error :)



Re: Why is r->handler a garbled string?

2008-12-30 Thread Arturo 'Buanzo' Busleiman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

John David Duncan wrote:
>if(strcmp(r->handler,my_name)) return DECLINED;

why aren't you using strncmp?!

Sorry, couldn't help it. I've seen (and exploited) way too many vulns like this.

- --
Arturo "Buanzo" Busleiman
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJWofWAlpOsGhXcE0RCusdAJ4rGSTzod8vgjrwuwBOiCGcfZTg6wCfWDUY
gcsvk8AaZeWEj7S/AyVrW4A=
=GSRX
-END PGP SIGNATURE-


Re: svn commit: r729641 - /httpd/mod_mbox/trunk/scripts/site-sitemap.py

2008-12-30 Thread Justin Erenkrantz
On Sat, Dec 27, 2008 at 8:51 AM,   wrote:
> Author: pquerna
> Date: Sat Dec 27 08:51:31 2008
> New Revision: 729641
>
> URL: http://svn.apache.org/viewvc?rev=729641&view=rev
> Log:
> Change the sitemap index generator to split the sitemap indexes every 500 
> entries, as the great GOOG doesn't like big sitemap indexes.

FYI, you should be able to support 1,000 entries as long as you don't
hit the size limitations first.  -- justin


Re: mod_fcgid license questions

2008-12-30 Thread Chris Darroch

pqf wrote:


version 1.10 ( Jul 3rd 2006 )
1. Use poll() instead of select() in UNIX. It becomes problematic on
   apache2 with large number of logfiles. Apache2 calls poll()
   (when OS supports it), and in that case it doesn't need to be recompiled
   with larger FD_SETSIZE. select() is still limited to FD_SETSIZE."
   (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
2. Bug fix: "Some requests fail with HTTP 500 and no errorlog entry is
   generated" (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)


  Ryan has been in touch with Piotr Gackiewicz independently and Piotr
asks if we can confirm that a CLA and SGA are necessary, as he considers
his contribution to have been just "simple repairs" (his term).

  From looking over the CVS repository at
http://mod-fcgid.cvs.sourceforge.net/viewvc/mod-fcgid/mod_fcgid/
it would appear to me that these patches amount to the following.

  Foes anyone have a sense of whether these would indeed require
a CLA and SGA?

Chris.

=
--- fcgid_bridge.c2006/01/22 14:16:231.25
+++ fcgid_bridge.c2006/05/13 23:45:441.26
@@ -256,8 +256,11 @@
}

bucket_ctx = apr_pcalloc(request_pool, sizeof(*bucket_ctx));
-if (!bucket_ctx)
+if (!bucket_ctx) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r->server,
+ "mod_fcgid: apr_calloc of %d bytes failed in handle_request 
function", sizeof(*bucket_ctx));
return HTTP_INTERNAL_SERVER_ERROR;
+}
bucket_ctx->ipc.connect_timeout = g_connect_timeout;
bucket_ctx->ipc.communation_timeout = g_comm_timeout;
bucket_ctx->ipc.request = r;
@@ -315,7 +318,7 @@

/* Now I get a connected ipc handle */
if (!bucket_ctx->procnode) {
-ap_log_error(APLOG_MARK, APLOG_INFO, 0, r->server,
+ap_log_error(APLOG_MARK, APLOG_WARNING, 0, r->server,
 "mod_fcgid: can't apply process slot for %s", argv0);
return HTTP_SERVICE_UNAVAILABLE;
}
@@ -326,7 +329,7 @@
if ((rv =
 proc_write_ipc(main_server, &bucket_ctx->ipc,
output_brigade)) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_INFO, rv, r->server,
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r->server,
 "mod_fcgid: write data to fastcgi server error");
bucket_ctx->has_error = 1;
return HTTP_INTERNAL_SERVER_ERROR;
@@ -335,8 +338,11 @@
/* Create brigade */
brigade_stdout =
apr_brigade_create(request_pool, r->connection->bucket_alloc);
-if (!brigade_stdout)
+if (!brigade_stdout) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r->server,
+ "mod_fcgid: apr_brigade_create failed in handle_request 
function");
return HTTP_INTERNAL_SERVER_ERROR;
+}
APR_BRIGADE_INSERT_TAIL(brigade_stdout,
ap_bucket_fcgid_header_create(r->connection->
  bucket_alloc,
@@ -346,7 +352,11 @@
/* Check the script header first. If got error, return immediately */
if ((cond_status = ap_scan_script_header_err_core
 (r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout)) >= 400)
+{
+ap_log_error(APLOG_MARK, APLOG_INFO, rv, r->server,
+"mod_fcgid: ap_scan_script_header_err_core failed in 
handle_request function: %d", cond_status);
return cond_status;
+}

/* Check redirect */
location = apr_table_get(r->headers_out, "Location");
@@ -377,6 +387,9 @@
if ((rv =
 ap_pass_brigade(r->output_filters,
 brigade_stdout)) != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r->server,
+ "mod_fcgid: ap_pass_brigade failed in handle_request 
function");
+
return HTTP_INTERNAL_SERVER_ERROR;
}

@@ -437,7 +450,7 @@
AP_MODE_READBYTES,
APR_BLOCK_READ,
HUGE_STRING_LEN)) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_INFO, rv,
+ap_log_error(APLOG_MARK, APLOG_WARNING, rv,
 main_server,
 "mod_fcgid: can't get data from http client");
apr_brigade_destroy(output_brigade);
--- arch/unix/fcgid_proc_unix.c2006/01/22 14:16:231.27
+++ arch/unix/fcgid_proc_unix.c2006/05/13 23:45:441.28
@@ -2,6 +2,7 @@
#include 
#include 
#include /* For TCP_NODELAY */
+#include 
#define CORE_PRIVATE
#include "httpd.h"
#include "apr_thread_proc.h"
@@ -525,10 +526,9 @@
   fcgid_ipc * ipc_handle, const char *buffer,
   apr_size_t * size)
{
-fd_set rset;
-struct timeval tv;
int retcode, unix_socket;
fcgid_namedpipe_handle *handle_info;
+struct pollfd pollfds[1];

handle_info = (fcgid_namedpipe_handle *) ipc_handle->ipc_handle_info;

Re: svn commit: r726113 - /httpd/httpd/trunk/server/mpm/worker/fdqueue.c

2008-12-30 Thread Chris Darroch

Hi --

  I wrote:


   What we had before was:

if (apr_atomic_casptr((volatile void**)&(queue_info->recycled_pools),
  new_recycle, next) == next) {
but also:

if (apr_atomic_cas32(&(queue_info->idlers), prev_idlers + 1,
 prev_idlers) == prev_idlers) {

   I see no reason why a pointer to an integer doesn't need a
volatile cast, while a pointer to a pointer does.  I'm also not
aware of any problems reported caused by the lack of a cast on these
other apr_atomic_*() calls.

   Consider too that all the apr_atomic_*() functions explicitly cast
their arguments as pointers to volatile data, so the compiler should
perform no optimization on data accesses within the function
(which is presumably where it counts).  Putting a volatile cast on
the argument in the call could only mean something, it seems to me,
if the APR functions didn't explicitly do this already.

   Further, the (volatile void**) casts for the recycled_pools pointer
were only added in the first place, according to the commit log, to
avoid compiler warnings (see r101236) -- which they no longer do for
gcc anyway, even if they ever did for some platform and compiler in
the past.


  That all said, I did some additional reading on void** casts
and the meaning of the type-punning warning gcc generates, and
it would seem that the underlying reason for the warning here has to
do exclusively with casting a pointer to data (struct recycled_pool*)
to a void*.  See http://c-faq.com/ptrs/genericpp.html
for what seems like a pretty decent explanation.

  Based on that, it would appear to me that the issue with casting
the arguments passed to apr_atomic_casptr() is that should httpd
be compiled on some unusual platform where a void* is, say, larger
than a struct recycled_pool*, things might go awry.

  Now, there are a number of APR functions which take void**
arguments, and I haven't thought about any of these except for the
two apr_atomic_*() ones.

  Does anyone know if we should be concerned about any modern
platforms where void* is a different size than some other pointers?
(E.g., pointers to data and pointers to functions might be different
sizes, and void* the larger of the two?)  In such a case, we might
need to refactor some code, including these apr_atomic_casptr()
calls.  If not, then casting to void* to silence the warnings ought
to be tolerable, I think.

Chris.

--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B



Re: mod_fcgid license questions

2008-12-30 Thread Roy T. Fielding

On Dec 31, 2008, at 6:31 PM, Chris Darroch wrote:


pqf wrote:


version 1.10 ( Jul 3rd 2006 )
1. Use poll() instead of select() in UNIX. It becomes problematic on
   apache2 with large number of logfiles. Apache2 calls poll()
   (when OS supports it), and in that case it doesn't need to be  
recompiled

   with larger FD_SETSIZE. select() is still limited to FD_SETSIZE."
   (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
2. Bug fix: "Some requests fail with HTTP 500 and no errorlog  
entry is
   generated" (Thank Piotr Gackiewicz gacek at intertele.pl for  
the patch.)


  Ryan has been in touch with Piotr Gackiewicz independently and Piotr
asks if we can confirm that a CLA and SGA are necessary, as he  
considers

his contribution to have been just "simple repairs" (his term).

  From looking over the CVS repository at
http://mod-fcgid.cvs.sourceforge.net/viewvc/mod-fcgid/mod_fcgid/
it would appear to me that these patches amount to the following.

  Foes anyone have a sense of whether these would indeed require
a CLA and SGA?


They look like simple repairs to me.  More importantly, if he thinks
they are simple repairs and he is happy to see them Apache Licensed,
then there is no need for a CLA or software grant.

Roy


Re: mod_fcgid license questions

2008-12-30 Thread pqf
Hi, guys
Thanks Chris first :)
Please take a look at the attachments, I got it from my mail archive. The 
errorlog patch is a minor patch. the poll patch change not much lines of code, 
but it did come with original idea.If Piotr Gackiewicz think his job is 
"simple repairs", I think these patchs can be put to "minor patch" group too. 

Thanks

- Original Message - 
From: "Chris Darroch" 
To: 
Sent: Wednesday, December 31, 2008 1:31 PM
Subject: Re: mod_fcgid license questions


> pqf wrote:
> 
>> version 1.10 ( Jul 3rd 2006 )
>> 1. Use poll() instead of select() in UNIX. It becomes problematic on
>>apache2 with large number of logfiles. Apache2 calls poll()
>>(when OS supports it), and in that case it doesn't need to be recompiled
>>with larger FD_SETSIZE. select() is still limited to FD_SETSIZE."
>>(Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
>> 2. Bug fix: "Some requests fail with HTTP 500 and no errorlog entry is
>>generated" (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.)
> 
>   Ryan has been in touch with Piotr Gackiewicz independently and Piotr
> asks if we can confirm that a CLA and SGA are necessary, as he considers
> his contribution to have been just "simple repairs" (his term).
> 
>   From looking over the CVS repository at
> http://mod-fcgid.cvs.sourceforge.net/viewvc/mod-fcgid/mod_fcgid/
> it would appear to me that these patches amount to the following.
> 
>   Foes anyone have a sense of whether these would indeed require
> a CLA and SGA?
> 
> Chris.
> 
> =
> --- fcgid_bridge.c2006/01/22 14:16:231.25
> +++ fcgid_bridge.c2006/05/13 23:45:441.26
> @@ -256,8 +256,11 @@
> }
> 
> bucket_ctx = apr_pcalloc(request_pool, sizeof(*bucket_ctx));
> -if (!bucket_ctx)
> +if (!bucket_ctx) {
> +ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r->server,
> + "mod_fcgid: apr_calloc of %d bytes failed in 
> handle_request function", sizeof(*bucket_ctx));
> return HTTP_INTERNAL_SERVER_ERROR;
> +}
> bucket_ctx->ipc.connect_timeout = g_connect_timeout;
> bucket_ctx->ipc.communation_timeout = g_comm_timeout;
> bucket_ctx->ipc.request = r;
> @@ -315,7 +318,7 @@
> 
> /* Now I get a connected ipc handle */
> if (!bucket_ctx->procnode) {
> -ap_log_error(APLOG_MARK, APLOG_INFO, 0, r->server,
> +ap_log_error(APLOG_MARK, APLOG_WARNING, 0, r->server,
>  "mod_fcgid: can't apply process slot for %s", argv0);
> return HTTP_SERVICE_UNAVAILABLE;
> }
> @@ -326,7 +329,7 @@
> if ((rv =
>  proc_write_ipc(main_server, &bucket_ctx->ipc,
> output_brigade)) != APR_SUCCESS) {
> -ap_log_error(APLOG_MARK, APLOG_INFO, rv, r->server,
> +ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r->server,
>  "mod_fcgid: write data to fastcgi server error");
> bucket_ctx->has_error = 1;
> return HTTP_INTERNAL_SERVER_ERROR;
> @@ -335,8 +338,11 @@
> /* Create brigade */
> brigade_stdout =
> apr_brigade_create(request_pool, r->connection->bucket_alloc);
> -if (!brigade_stdout)
> +if (!brigade_stdout) {
> +ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r->server,
> + "mod_fcgid: apr_brigade_create failed in handle_request 
> function");
> return HTTP_INTERNAL_SERVER_ERROR;
> +}
> APR_BRIGADE_INSERT_TAIL(brigade_stdout,
> ap_bucket_fcgid_header_create(r->connection->
>   bucket_alloc,
> @@ -346,7 +352,11 @@
> /* Check the script header first. If got error, return immediately */
> if ((cond_status = ap_scan_script_header_err_core
>  (r, sbuf, getsfunc_fcgid_BRIGADE, brigade_stdout)) >= 400)
> +{
> +ap_log_error(APLOG_MARK, APLOG_INFO, rv, r->server,
> +"mod_fcgid: ap_scan_script_header_err_core failed in 
> handle_request function: %d", cond_status);
> return cond_status;
> +}
> 
> /* Check redirect */
> location = apr_table_get(r->headers_out, "Location");
> @@ -377,6 +387,9 @@
> if ((rv =
>  ap_pass_brigade(r->output_filters,
>  brigade_stdout)) != APR_SUCCESS) {
> +ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r->server,
> + "mod_fcgid: ap_pass_brigade failed in handle_request 
> function");
> +
> return HTTP_INTERNAL_SERVER_ERROR;
> }
> 
> @@ -437,7 +450,7 @@
> AP_MODE_READBYTES,
> APR_BLOCK_READ,
> HUGE_STRING_LEN)) != APR_SUCCESS) {
> -ap_log_error(APLOG_MARK, APLOG_INFO, rv,
> +ap_log_error(APLOG_MARK, APLOG_WARNING, rv,
>  main_server,
>  "mod_fcgid: can't