Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <473E0F4C.5010003@apache.org>
Date: Fri, 16 Nov 2007 22:44:44 +0100
From: Ruediger Pluem <rpluem@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.9) Gecko/20071030 SeaMonkey/1.1.6
MIME-Version: 1.0
To: APR Developer List <dev@apr.apache.org>
Subject: Re: [Votes] Apr candidates in /dev/dist/
References: <473CB97E.5060805@rowe-clan.net>
In-Reply-To: <473CB97E.5060805@rowe-clan.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


On 11/15/2007 10:26 PM, William A. Rowe, Jr. wrote:
> Please provide your input to release.
> 
>   [+1] APR-0.9.17
>   [  ] APR-1.2.12
>   [-1] APR-util-1.2.11
>   [  ] APR-iconv-1.2.1
> 
> 
> 
> I've already noticed I should have scuttled testreslist current
> implementation,
> but that's 20/20 hindsight and it sure isn't a showstopper.
> 

These are my results so far (more tests to follow):

Signatures: All OK.
md5 sums: All OK.

APR 1.2.12 / APR-UTIL 1.2.11 tested with httpd testframework and httpd-2.2.6 on Linux:
NO regressions.

Test results (make check):

APR 0.9.17:

Solaris 8 - 10, OpenSuSE 10.2: All OK.

So +1 from on APR 0.9.17.

APR 1.2.12:

Solaris 8 / 9: All OK except:

testshm             : -Line 254: Error destroying shared memory block (22): Invalid argument

FAILED 1 of 6
Failed Tests            Total   Fail    Failed %
===================================================
testshm                     6      1     16.67%

But as I have learned from previous posts this is expected and no regression.


Solaris 10: All OK except:

testpoll            : /Line 314: expected <5>, but saw <4>
FAILED 1 of 13
testshm             : -Line 254: Error destroying shared memory block (22): Invalid argument

FAILED 1 of 6
Failed Tests            Total   Fail    Failed %
===================================================
testpoll                   13      1      7.69%
testshm                     6      1     16.67%

Is the first one in testpoll expected? To be honest I did not do a regression check
with APR 1.2.11 so far. So not vote from me on APR 1.2.12 currently as I also need
to do Linux test.


APR-UTIL 1.2.11:

The testreslist test freezes because of a bug in apr_reslist_invalidate. The following patch should
fix this, by activating the threads waiting for a resource:

--- apr_reslist.c.orig  2007-11-01 15:07:19.000000000 +0100
+++ apr_reslist.c       2007-11-16 14:52:35.789677000 +0100
@@ -370,6 +370,7 @@
     apr_thread_mutex_lock(reslist->listlock);
     ret = reslist->destructor(resource, reslist->params, reslist->pool);
     reslist->ntotal--;
+    apr_thread_cond_signal(reslist->avail);
     apr_thread_mutex_unlock(reslist->listlock);
     return ret;
 }

Comments? Otherwise I will commit tomorrow to trunk and 1.2.x

And testdate fails with

testdate            : |Line 188: expected <Mon, 27 Feb 1995 20:49:44 GMT>, but saw <Tue, 28 Feb 1995 04:49:44 GMT>
FAILED 1 of 2
Failed Tests            Total   Fail    Failed %
===================================================
testdate                    2      1     50.00%

IMHO one of these failures seems to be caused by a wrong testcase:

--- apr-util-1.2.11/test/testdate.c     2007-10-30 19:12:15.000000000 +0100
+++ apr-util-1.2.11.new/test/testdate.c 2007-11-16 17:30:48.593086000 +0100
@@ -32,7 +32,7 @@
   { "Monday, 27-Feb-95 20:49:44 -0800", "Tue, 28 Feb 1995 04:49:44 GMT" },
   { "Tue, 4 Mar 1997 12:43:52 +0200",   "Tue, 04 Mar 1997 10:43:52 GMT" },
   { "Mon, 27 Feb 95 20:49:44 -0800",    "Tue, 28 Feb 1995 04:49:44 GMT" },
-  { "Tue,  4 Mar 97 12:43:52 +0200",    "Tue, 04 Mar 1997 10:43:52 GMT" },
+  { "Tue, 4 Mar 97 12:43:52 +0200",    "Tue, 04 Mar 1997 10:43:52 GMT" },
   { "Tue, 4 Mar 97 12:43:52 +0200",     "Tue, 04 Mar 1997 10:43:52 GMT" },
   { "Mon, 27 Feb 95 20:49 GMT",         "Mon, 27 Feb 1995 20:49:00 GMT" },
   { "Tue, 4 Mar 97 12:43 GMT",          "Tue, 04 Mar 1997 12:43:00 GMT" },

and oddly enough the other testdate failures seem to be caused by bugs in apr_date_parse_rfc
(which I cannot really believe for such a well tested function, so some remote eyes please, or
some comments if the testcases are wrong and why. All failures are caused by not respecting
the timezone string at the end of the test date). The following patch would fix this:

--- apr-util-1.2.11/misc/apr_date.c     2007-11-01 15:07:19.000000000 +0100
+++ apr-util-1.2.11.new/misc/apr_date.c 2007-11-16 17:31:11.606303000 +0100
@@ -375,7 +375,7 @@

         monstr = date + 3;
         timstr = date + 10;
-        gmtstr = date + 19;
+        gmtstr = date + 18;

         TIMEPARSE_STD(ds, timstr);
     }
@@ -412,7 +412,7 @@

         monstr = date + 2;
         timstr = date + 11;
-        gmtstr = date + 20;
+        gmtstr = date + 19;

         TIMEPARSE_STD(ds, timstr);
     }
@@ -428,7 +428,7 @@

         monstr = date + 3;
         timstr = date + 10;
-        gmtstr = date + 19;
+        gmtstr = date + 18;

         TIMEPARSE_STD(ds, timstr);
     }
@@ -444,7 +444,7 @@

         monstr = date + 2;
         timstr = date + 9;
-        gmtstr = date + 18;
+        gmtstr = date + 17;

         TIMEPARSE_STD(ds, timstr);
     }

So -1 from me on APR-UTIL.

Regards

Rüdiger