You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2007/11/15 22:26:22 UTC
[Votes] Apr candidates in /dev/dist/
Please provide your input to release.
[ ] APR-0.9.17
[ ] APR-1.2.12
[ ] 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.
Re: [Votes] Apr candidates in /dev/dist/
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
>
> On 11/20/2007 11:30 PM, William A. Rowe, Jr. wrote:
>> William A. Rowe, Jr. wrote:
>>> Please provide your input to release.
>>>
>>> [+1] APR-iconv-1.2.1
>>
>> Please note I didn't see much feedback yet one way or another on
>> APR-iconv-1.2.1 nor
>
> What can be done with APR-iconv, except
>
> - checking md5 / signature
> - compiling
> - installing
yes, to all of the above. Also, the delta between 1.2.0 and 1.2.1 releases
is useful for inspection. Finally --with-iconv=/path/to/installed-apr-iconv
to apr-util should bind to this rather than to system iconv. Of course any
release vote is subject to your own metrics, with the general concensus that
non-regressions aren't showstoppers.
> I see no test suite. Would the above results be enough for a qualified
> vote. If yes, I can try to provide this (at least for some OS).
Once bound to apr-util, there is a simple apr-xlate validation test already,
in fact I'd rather we invested energy in validating apr_xlate than very
specific apr-iconv testing. (It's a win for apr-iconv, which might go away
sometime if citrus libs or icu become good solutions, and it remains a win
for checking against system iconv).
That test reveals one issue, not a regression, with a missing shift-out
of utf-7 encoding after a series of shifted bytes from the utf-8 source.
> BTW: zip files would have been helpful for tests on windows as I missed
> to install any of the usual suspect zip tools on the XP box I have
> at hand :-(.
See /dev/dist now, however I didn't install testall, etc. I can see a good
rational for some install-tests target though, just to validate a binary
against a wider range of boxes.
Lucian's vote (not binding) and mine leave me looking for 2 more +1's to
wrap up this whole shooting match. Hard for me to shift apr-all-* binaries
without approval of apr-iconv-1.2.1 along with apr, apr-util 1.2.12.
Bill
Re: [Votes] Apr candidates in /dev/dist/
Posted by Ruediger Pluem <rp...@apache.org>.
On 11/20/2007 11:30 PM, William A. Rowe, Jr. wrote:
> William A. Rowe, Jr. wrote:
>> Please provide your input to release.
>>
>> [+1] APR-0.9.17
>> [+1] APR-1.2.12
>> [XX] APR-util-1.2.11
>> [+1] APR-iconv-1.2.1
>
> Please note I've withdrawn apr-util-1.2.11 from consideration, and a
> 1.2.12 package
> test will be announced once I've copied up and synced.
>
> I'll leave this vote open through Friday and start a vote on 1.2.12 in a
> new thread,
> just so we have one place to record it all. But I plan on Friday
> evening to announce
> the results of all of these.
>
> Please note I didn't see much feedback yet one way or another on
> APR-iconv-1.2.1 nor
What can be done with APR-iconv, except
- checking md5 / signature
- compiling
- installing
I see no test suite. Would the above results be enough for a qualified
vote. If yes, I can try to provide this (at least for some OS).
BTW: zip files would have been helpful for tests on windows as I missed
to install any of the usual suspect zip tools on the XP box I have
at hand :-(.
Regards
Rüdiger
Re: [Votes] Apr candidates in /dev/dist/
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Please provide your input to release.
>
> [+1] APR-0.9.17
> [+1] APR-1.2.12
> [XX] APR-util-1.2.11
> [+1] APR-iconv-1.2.1
Please note I've withdrawn apr-util-1.2.11 from consideration, and a 1.2.12 package
test will be announced once I've copied up and synced.
I'll leave this vote open through Friday and start a vote on 1.2.12 in a new thread,
just so we have one place to record it all. But I plan on Friday evening to announce
the results of all of these.
Please note I didn't see much feedback yet one way or another on APR-iconv-1.2.1 nor
really a whole lot for apr 0.9.17, so please keep those votes coming. In the case of
APR-iconv-1.2.1 I observed the bug of not shift-stating out of utf-7 back to utf-8 on
close, but it seems apr_xlate may be relying on a shift-out behavior that this
implementation (and therefore, probably others) doesn't support. Not a regression so
better to release and just move forward.
Bill
Re: [Votes] Apr candidates in /dev/dist/
Posted by Ruediger Pluem <rp...@apache.org>.
On 11/16/2007 10:44 PM, Ruediger Pluem wrote:
>
> 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.
Ok. This seems to be PR 43000 (http://issues.apache.org/bugzilla/show_bug.cgi?id=43000),
but not a regression. There seems to be fix in http://issues.apache.org/bugzilla/show_bug.cgi?id=43000#c8.
Regards
Rüdiger
Re: [Votes] Apr candidates in /dev/dist/
Posted by Ruediger Pluem <rp...@apache.org>.
On 11/16/2007 10:44 PM, Ruediger Pluem wrote:
>
> On 11/15/2007 10:26 PM, William A. Rowe, Jr. wrote:
>> Please provide your input to release.
>>
>> [+1] APR-0.9.17
>> [+1] 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.
>>
Now my latest results which let me vote +1 on APR-1.2.12:
APR 1.2.12:
Solaris 8 / 9, OpenSuSE 10.2 32 bit, OpenSuSE 10.1 64 bit: 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%
The testpoll failure seems to be no regression though but related to
PR 43000 (http://issues.apache.org/bugzilla/show_bug.cgi?id=43000).
Regards
Rüdiger
Re: [Votes] Apr candidates in /dev/dist/
Posted by Ruediger Pluem <rp...@apache.org>.
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
Re: [Votes] Apr candidates in /dev/dist/
Posted by Jeff Trawick <tr...@gmail.com>.
On Nov 15, 2007 4:26 PM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Please provide your input to release.
>
> [ ] APR-0.9.17
> [+1] APR-1.2.12
> [+1] APR-util-1.2.11
> [ ] APR-iconv-1.2.1
Solaris 10/x86_64
Sun Studio 11
apr 1.2.11 vs. apr 1.2.12
tested in 32-bit and 64-bit
checked test suite and compile warnings
only apparent regression was the testcase testshm
(no apparent library regressions)
apr-util 1.2.10 vs. apr-util 1.2.11
tested 64-bit only
dbd not enabled
checked test suite and compile warnings
new test suite failures:
testdate
this is apparently testcase goodness and not a regression
testreslist
this is apparently not a regression; testcase goodness? it
triggered a fix
Re: [Votes] Apr candidates in /dev/dist/
Posted by Jeff Trawick <tr...@gmail.com>.
On Nov 15, 2007 6:19 PM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Lucian Adrian Grijincu wrote:
> > On Nov 15, 2007 11:26 PM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> >> Please provide your input to release.
> > Ubuntu 7.10 kernel 2.6.22-14, x86
> > testsock : //bin/bash: line 1: 23623 Segmentation fault
> > (core dumped) ./$prog
>
> Yuck - have a backtrace of the core? This is usually indicative of strange
> configurations of the IP stack, win32 used to be notorious for such things.
FWLIW, I didn't encounter this on same distro/kernel
Re: [Votes] Apr candidates in /dev/dist/
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On Nov 16, 2007 1:19 AM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Lucian Adrian Grijincu wrote:
> > On Nov 15, 2007 11:26 PM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> >> Please provide your input to release.
> > Ubuntu 7.10 kernel 2.6.22-14, x86
> >
> > Details:
> >
> >> [-1] APR-1.2.12
> > on the first run:
> > testshm : FAILED 1 of 6
>
> Correct; this is not a regression, not a showstopper, but a new illustration
> of an existing bug. We may remove the shm backing store, and destroy the shm
> object (or let it clean up) but it will attempt to re-remove itself. It's
> illustrating the bug, no patch was forthcoming, I'm considering it closed until
> the next go-around with release 1.2.13.
>
the test goes like this
rv = apr_shm_remove(SHARED_FILENAME, p);
|
---> apr_file_remove(filename);
[...]
rv = apr_shm_destroy(shm);
|
---> return apr_file_remove(filename);
APR_ASSERT_SUCCESS(tc, "Error destroying shared memory block", rv);
To me it's obvious that the testcase should check for APR_ENOENT AND
APR_SUCCESS. (some platforms just return APR_ENOTIMPL for
apr_shm_remove and afterwards apr_shm_destroy will return APR_SUCCESS
in that case. This is not a bug in APR it's a bug in the testcase.)
Attached a patch for the testcases.
> > testsock : //bin/bash: line 1: 23623 Segmentation fault
> > (core dumped) ./$prog
>
> Yuck - have a backtrace of the core? This is usually indicative of strange
> configurations of the IP stack, win32 used to be notorious for such things.
>
Unfortunately no, I forgot to "ulimit -c unlimited" before running the
tests and there's no core dump.
I'll script it to run for some time, maybe I'll get lucky.
> > afterwards only the first error ON EVERY RUN; testsock seemed fine, I
> > can only hope it core dumped because of the test that failed before.
>
> Not for the shm test; but it sounds like we failed to check the rc of some
> specific test.
>
> >> [+1] APR-0.9.17
> > Not a showstopper from my POV:
> > starting consumer.....
> > Name-based shared memory test FAILED: [2] No such file or directory
> > starting producer.....
> > Name-based shared memory test FAILED: [2] No such file or directory
>
> No - those are fine, no regression.
>
> >> [-1] APR-util-1.2.11
> >
> > gringo@lethe:~/aprtest/apr-util-1.2.11$ ./test/testall -v
> > 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
>
> I /believe/ this is a failure in the test.
They are failing because the comparisons can't be right: this is from the tests.
static struct datetest {
const char *input;
const char *output;
} tests[] = {
{ "Mon, 27 Feb 1995 20:49:44 -0800", "Tue, 28 Feb 1995 04:49:44 GMT" },
....
}
...
date = apr_date_parse_rfc(tests[i].input);
apr_rfc822_date(str_date, date);
ABTS_STR_EQUAL(tc, str_date, tests[i].output);
I see no pattern in the strings defined at the start of the testfile,
but it's definitely a test bug.
>
> > testxml : |Line 68: expected <2>, but saw <0>
> > FAILED 1 of 1
>
> Ick - which expat?
>
> > testxlate : SUCCESS
> > testrmm : SUCCESS
> > testdbm : |Line 175: expected <2>, but saw <0>
> > FAILED 1 of 1
>
> Ick, which db?
#define APU_HAVE_SDBM 1
#define APU_HAVE_GDBM 0
#define APU_HAVE_NDBM 0
#define APU_HAVE_DB 0
Havent' been able to reproduce it, I hate this kinds of bugs.
The reason might be that I had CTRL+C-ed a previous run of ./testall
because of a dead testreslist and stuff may have not been cleaned up.
>
> > testqueue : SUCCESS
> > testreslist : \-|/-|\-|/-|\-|/-|\-|/-|\/ [[ and
> > deadlocks here forever (>3 min == infinity) ]]
>
> Reslist is broke, I did mention this in my post. I'd possibly consider
> rerolling tomorrow afternoon if someone wants to fix this test (not it's
> original implementation on 1.2 either - that was equally horrid).
>
> I'd also entertain rerolling after removing testreslist from the list of
> tests, altogether.
Without reslist only the badly written testdate still fails:
teststrmatch : SUCCESS
testuri : SUCCESS
testuuid : SUCCESS
testbuckets : SUCCESS
testpass : SUCCESS
testmd4 : SUCCESS
testmd5 : SUCCESS
testdbd : SUCCESS
testdate : FAILED 1 of 2
testxml : SUCCESS
testxlate : SUCCESS
testrmm : SUCCESS
testdbm : SUCCESS
testqueue : SUCCESS
Failed Tests Total Fail Failed %
===================================================
testdate 2 1 50.00%
--
Lucian
Re: [Votes] Apr candidates in /dev/dist/
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Lucian Adrian Grijincu wrote:
> On Nov 15, 2007 11:26 PM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> Please provide your input to release.
> Ubuntu 7.10 kernel 2.6.22-14, x86
>
> Details:
>
>> [-1] APR-1.2.12
> on the first run:
> testshm : FAILED 1 of 6
Correct; this is not a regression, not a showstopper, but a new illustration
of an existing bug. We may remove the shm backing store, and destroy the shm
object (or let it clean up) but it will attempt to re-remove itself. It's
illustrating the bug, no patch was forthcoming, I'm considering it closed until
the next go-around with release 1.2.13.
> testsock : //bin/bash: line 1: 23623 Segmentation fault
> (core dumped) ./$prog
Yuck - have a backtrace of the core? This is usually indicative of strange
configurations of the IP stack, win32 used to be notorious for such things.
> afterwards only the first error ON EVERY RUN; testsock seemed fine, I
> can only hope it core dumped because of the test that failed before.
Not for the shm test; but it sounds like we failed to check the rc of some
specific test.
>> [+1] APR-0.9.17
> Not a showstopper from my POV:
> starting consumer.....
> Name-based shared memory test FAILED: [2] No such file or directory
> starting producer.....
> Name-based shared memory test FAILED: [2] No such file or directory
No - those are fine, no regression.
>> [-1] APR-util-1.2.11
>
> gringo@lethe:~/aprtest/apr-util-1.2.11$ ./test/testall -v
> 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
I /believe/ this is a failure in the test.
> testxml : |Line 68: expected <2>, but saw <0>
> FAILED 1 of 1
Ick - which expat?
> testxlate : SUCCESS
> testrmm : SUCCESS
> testdbm : |Line 175: expected <2>, but saw <0>
> FAILED 1 of 1
Ick, which db?
> testqueue : SUCCESS
> testreslist : \-|/-|\-|/-|\-|/-|\-|/-|\/ [[ and
> deadlocks here forever (>3 min == infinity) ]]
Reslist is broke, I did mention this in my post. I'd possibly consider
rerolling tomorrow afternoon if someone wants to fix this test (not it's
original implementation on 1.2 either - that was equally horrid).
I'd also entertain rerolling after removing testreslist from the list of
tests, altogether.
> Creating configure ...
As far as these are concerned, I have no desire to fix. I think that's
a good thing to focus on trunk for the next minor bump.
Bill
Re: [Votes] Apr candidates in /dev/dist/
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On Nov 15, 2007 11:26 PM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Please provide your input to release.
Ubuntu 7.10 kernel 2.6.22-14, x86
>
> [+1] APR-0.9.17
> [-1] APR-1.2.12
> [-1] APR-util-1.2.11
> [+1] APR-iconv-1.2.1 -- I only built it! aren't there any tests for this?
>
>
Details:
> [-1] APR-1.2.12
on the first run:
testshm : FAILED 1 of 6
testsock : //bin/bash: line 1: 23623 Segmentation fault
(core dumped) ./$prog
afterwards only the first error ON EVERY RUN; testsock seemed fine, I
can only hope it core dumped because of the test that failed before.
gringo@lethe:~/aprtest/apr-1.2.12/test$ ./testall testshm -v
testshm : -Line 254: Error destroying shared memory block
(2): No such file or directory
FAILED 1 of 6
Failed Tests Total Fail Failed %
===================================================
testshm 6 1 16.67%
gringo@lethe:~/aprtest/apr-1.2.12/test$ cd ..
gringo@lethe:~/aprtest/apr-1.2.12$ ./test/testall testshm -v
testshm : -Line 254: Error destroying shared memory block
(2): No such file or directory
FAILED 1 of 6
Failed Tests Total Fail Failed %
===================================================
testshm 6 1 16.67%
I'll look into this later tonight.
> [+1] APR-0.9.17
Not a showstopper from my POV:
starting consumer.....
Name-based shared memory test FAILED: [2] No such file or directory
starting producer.....
Name-based shared memory test FAILED: [2] No such file or directory
> [-1] APR-util-1.2.11
gringo@lethe:~/aprtest/apr-util-1.2.11$ ./test/testall -v
teststrmatch : SUCCESS
testuri : SUCCESS
testuuid : SUCCESS
testbuckets : SUCCESS
testpass : SUCCESS
testmd4 : SUCCESS
testmd5 : SUCCESS
testdbd : SUCCESS
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
testxml : |Line 68: expected <2>, but saw <0>
FAILED 1 of 1
testxlate : SUCCESS
testrmm : SUCCESS
testdbm : |Line 175: expected <2>, but saw <0>
FAILED 1 of 1
testqueue : SUCCESS
testreslist : \-|/-|\-|/-|\-|/-|\-|/-|\/ [[ and
deadlocks here forever (>3 min == infinity) ]]
Some warnings:
gringo@lethe:~/aprtest/apr-0.9.17$ ./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.61 (ok)
buildconf: libtool version 1.5.24 (ok)
Copying libtool helper files ...
buildconf: Using libtool.m4 at /usr/share/aclocal/libtool.m4.
Creating include/arch/unix/apr_private.h.in ...
autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for `config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows one to define a
template without
autoheader: WARNING: `acconfig.h':
autoheader:
autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be produced, see the
autoheader: WARNING: documentation.
Creating configure ...
rebuilding rpm spec file
gringo@lethe:~/aprtest/apr-util-1.2.11$ ./buildconf --with-apr=../apr-1.2.12
Looking for apr source in /home/gringo/aprtest/apr-1.2.12
Creating include/private/apu_config.h ...
Creating configure ...
Generating 'make' outputs ...
Invoking xml/expat/buildconf.sh ...
Copying libtool helper files ...
Incorporating /usr/share/aclocal/libtool.m4 into aclocal.m4 ...
Creating config.h.in ...
autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for `config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows one to define a
template without
autoheader: WARNING: `acconfig.h':
autoheader:
autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be produced, see the
autoheader: WARNING: documentation.
Creating configure ...
rebuilding rpm spec file
--
Lucian
Re: [Votes] Apr candidates in /dev/dist/
Posted by Ruediger Pluem <rp...@apache.org>.
On 11/26/2007 02:12 AM, Jeff Trawick wrote:
> On Nov 15, 2007 4:26 PM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> Please provide your input to release.
>
>> [ ] APR-iconv-1.2.1
>
> diffs from prior release look reasonable (punted on reviewing Windows
> build changes just as I normally punt on testing them)
>
> I had to manually define API_USE_BUILTIN_ALIASES on Linux to get
> testxlate to run far enough to encounter the "missing shift-out of
> utf-7 encoding" problem; by default it provides no aliases and
> testxlate fails (not a regression AFAICT)
I needed to do the same for Linux and Solaris. Test results:
Signatures: OK
md5sum: tar.gz OK, zip file NOT OK
I assume the following error is the expected error mentioned above:
testxlate : /Line 52: expected <Edelwei+AN8>, but saw <Edelwei+AN8->
FAILED 1 of 1
Failed Tests Total Fail Failed %
===================================================
testxlate 1 1 100.00%
Otherwise compiles and installs fine.
Done on
Solaris (SPARC) 8
Solaris (SPARC) 9
Solaris (SPARC) 10
Red Hat AS 4 (x86) 64 Bit
OpenSuSE 10.2 (x86) 32 Bit
So +1 from me on apr-iconv-1.2.1.
If I have counted correctly we have now three +1's: Other Bill, Jeff and me.
Regards
Rüdiger
Re: [Votes] Apr candidates in /dev/dist/
Posted by Jeff Trawick <tr...@gmail.com>.
On Nov 15, 2007 4:26 PM, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Please provide your input to release.
> [ +1] APR-iconv-1.2.1
diffs from prior release look reasonable (punted on reviewing Windows
build changes just as I normally punt on testing them)
I had to manually define API_USE_BUILTIN_ALIASES on Linux to get
testxlate to run far enough to encounter the "missing shift-out of
utf-7 encoding" problem; by default it provides no aliases and
testxlate fails (not a regression AFAICT)
Re: [Votes] Apr candidates in /dev/dist/
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
>
> On 11/19/2007 12:38 AM, Bojan Smojver wrote:
>>
>> Both apr-0.9.17 and apr-1.2.12 fail SHM tests:
>>
>> 0.9.17:
>> -------------------------
>> starting consumer.....
>> starting producer.....
>> Name-based shared memory test FAILED: [2] No such file or directory
>> Name-based shared memory test FAILED: [2] No such file or directory
>
> That's a bug in the test. Just ensure that the test subdirectory is in your PATH
> such that testshmconsumer and testshmcontributor can be executed.
Yes; see the recent changes in Makefile.win to see where we set up PATH= to the
corresponding binary subdirectories. Of course if you cross compile, these
simply can't work.
>> Given that Ruediger already committed patches for both of these, it
>> would probably be best to roll again.
apr-util 1.2.12 is on it's way. I have one build failure as I had jumped to an
older nmake+older cmd.exe, my path-hack to work out the users' APR_PREFIX etc on
win32 doesn't behave as it did on server 2003+modern nmake, failing to then run
the test/ Makefile.win build properly. Grumpf. Should be an hour or few to get
that right (started it back in Atlanta), thanks for the loan of the wireless usb
dongle, Issac).
> I haven't commited for testdate so far. I just wanted to hear some other opinions
> especially on the patches to apr_date_parse_rfc as I couldn't believe that these
> bugs have not been found in a function that has not been touched for such a long time.
> So please comment and I commit or adjust.
Amazing how long a bug can live unnoticed, eh?
Re: [Votes] Apr candidates in /dev/dist/
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2007-11-19 at 21:47 +0100, Ruediger Pluem wrote:
> I haven't commited for testdate so far.
Yeah, sorry. I confused a patch sent to the list with a commit. I'll
blame it on caffeine deficiency, although old age is more likely ;-)
--
Bojan
Re: [Votes] Apr candidates in /dev/dist/
Posted by Ruediger Pluem <rp...@apache.org>.
On 11/19/2007 10:04 PM, Jeff Trawick wrote:
> Did you have a look at diffs between 1.2.x and trunk for apr_date.c?
>
> The 1.2.x branch is missing
>
> http://svn.apache.org/viewvc?view=rev&revision=233425 (combo of bug
> fixes and support for a new date format and new testcases)
> http://svn.apache.org/viewvc?view=rev&revision=405896 (comment tweak)
Thanks for the pointers Jeff. That's it. The patch is even better. So I have
backported it (r596464).
Regards
Rüdiger
Re: [Votes] Apr candidates in /dev/dist/
Posted by Jeff Trawick <tr...@gmail.com>.
On Nov 19, 2007 3:47 PM, Ruediger Pluem <rp...@apache.org> wrote:
>
>
> On 11/19/2007 12:38 AM, Bojan Smojver wrote:
> > On Thu, 2007-11-15 at 16:26 -0500, William A. Rowe, Jr. wrote:
> >> Please provide your input to release.
> >>
> >> [+1] APR-0.9.17
> >> [+1] APR-1.2.12
> >> [-1] APR-util-1.2.11
> >> [ ] APR-iconv-1.2.1
> >
> > Fedora 8, i686 and x86_64.
> >
> > Both apr-0.9.17 and apr-1.2.12 fail SHM tests:
> >
> > 0.9.17:
> > -------------------------
> > starting consumer.....
> > starting producer.....
> > Name-based shared memory test FAILED: [2] No such file or directory
> > Name-based shared memory test FAILED: [2] No such file or directory
>
> That's a bug in the test. Just ensure that the test subdirectory is in your PATH
> such that testshmconsumer and testshmcontributor can be executed.
>
> > Waiting for producer to exit.
> > Waiting for consumer to exit.
> > Destroying shared memory segment...OK
> > Named shared memory test passed!
> > -------------------------
> >
> > 1.2.12:
> > -------------------------
> > testshm : FAILED 1 of 6
> > -------------------------
> >
> > However, there have been comments that this is supposed to be expected
> > and that there is no fix available at present. So, I guess +1 in that
> > case.
> >
> > apr-util-1.2.11 fails with:
> > -------------------------
> > testdate : FAILED 1 of 2
> > -------------------------
> >
> > Also, testreslist hangs, just like for some other people.
> >
> > Given that Ruediger already committed patches for both of these, it
> > would probably be best to roll again.
>
> I haven't commited for testdate so far. I just wanted to hear some other opinions
> especially on the patches to apr_date_parse_rfc as I couldn't believe that these
> bugs have not been found in a function that has not been touched for such a long time.
> So please comment and I commit or adjust.
Did you have a look at diffs between 1.2.x and trunk for apr_date.c?
The 1.2.x branch is missing
http://svn.apache.org/viewvc?view=rev&revision=233425 (combo of bug
fixes and support for a new date format and new testcases)
http://svn.apache.org/viewvc?view=rev&revision=405896 (comment tweak)
Re: [Votes] Apr candidates in /dev/dist/
Posted by Ruediger Pluem <rp...@apache.org>.
On 11/19/2007 12:38 AM, Bojan Smojver wrote:
> On Thu, 2007-11-15 at 16:26 -0500, William A. Rowe, Jr. wrote:
>> Please provide your input to release.
>>
>> [+1] APR-0.9.17
>> [+1] APR-1.2.12
>> [-1] APR-util-1.2.11
>> [ ] APR-iconv-1.2.1
>
> Fedora 8, i686 and x86_64.
>
> Both apr-0.9.17 and apr-1.2.12 fail SHM tests:
>
> 0.9.17:
> -------------------------
> starting consumer.....
> starting producer.....
> Name-based shared memory test FAILED: [2] No such file or directory
> Name-based shared memory test FAILED: [2] No such file or directory
That's a bug in the test. Just ensure that the test subdirectory is in your PATH
such that testshmconsumer and testshmcontributor can be executed.
> Waiting for producer to exit.
> Waiting for consumer to exit.
> Destroying shared memory segment...OK
> Named shared memory test passed!
> -------------------------
>
> 1.2.12:
> -------------------------
> testshm : FAILED 1 of 6
> -------------------------
>
> However, there have been comments that this is supposed to be expected
> and that there is no fix available at present. So, I guess +1 in that
> case.
>
> apr-util-1.2.11 fails with:
> -------------------------
> testdate : FAILED 1 of 2
> -------------------------
>
> Also, testreslist hangs, just like for some other people.
>
> Given that Ruediger already committed patches for both of these, it
> would probably be best to roll again.
I haven't commited for testdate so far. I just wanted to hear some other opinions
especially on the patches to apr_date_parse_rfc as I couldn't believe that these
bugs have not been found in a function that has not been touched for such a long time.
So please comment and I commit or adjust.
Regards
Rüdiger
Re: [Votes] Apr candidates in /dev/dist/
Posted by Bojan Smojver <bo...@rexursive.com>.
On Thu, 2007-11-15 at 16:26 -0500, William A. Rowe, Jr. wrote:
> Please provide your input to release.
>
> [+1] APR-0.9.17
> [+1] APR-1.2.12
> [-1] APR-util-1.2.11
> [ ] APR-iconv-1.2.1
Fedora 8, i686 and x86_64.
Both apr-0.9.17 and apr-1.2.12 fail SHM tests:
0.9.17:
-------------------------
starting consumer.....
starting producer.....
Name-based shared memory test FAILED: [2] No such file or directory
Name-based shared memory test FAILED: [2] No such file or directory
Waiting for producer to exit.
Waiting for consumer to exit.
Destroying shared memory segment...OK
Named shared memory test passed!
-------------------------
1.2.12:
-------------------------
testshm : FAILED 1 of 6
-------------------------
However, there have been comments that this is supposed to be expected
and that there is no fix available at present. So, I guess +1 in that
case.
apr-util-1.2.11 fails with:
-------------------------
testdate : FAILED 1 of 2
-------------------------
Also, testreslist hangs, just like for some other people.
Given that Ruediger already committed patches for both of these, it
would probably be best to roll again.
--
Bojan