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 2009/05/29 10:08:41 UTC

[vote] release apr 1.3.4, apr-util 1.3.5

Candidates in the usual location, may take up to an hour to sync.
Letting this vote run through midnight Monday morning, my time,
so depending on my weekend I'll either stage-to-mirrors late that
night, or first thing Monday a.m. for announcement about 12 hrs
later after some mirrors have caught up.  Windows .zip's will show
up sometime tomorrow when I have the humor :)

 +/-1
 [  ]  Release apr 1.3.4 as GA
 [  ]  Release apr-util 1.3.5 as GA

Folks, your opinions please.

Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Ruediger Pluem <rp...@apache.org>.

On 05/31/2009 11:07 AM, Stefan Fritsch wrote:
> On Saturday 30 May 2009, William A. Rowe, Jr. wrote:
>> Stefan Fritsch wrote:
>>> On Friday 29 May 2009, William A. Rowe, Jr. wrote:
>>>>  [  ]  Release apr-util 1.3.5 as GA
>>> apr-util's "make check" fails in testdbm because test/Makefile.in
>>> misses ../dbm/.libs when setting LD_LIBRARY_PATH.
>> Patches hugely appreciated.
> 
> Attached. I guess it only happens if you do "make check" before "make 
> install", or if you did "make install DESTDIR=..." like package build 
> scripts do.

Committed to trunk as r780411. Thanks for the patch.

Regards

Rüdiger



Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Saturday 30 May 2009, William A. Rowe, Jr. wrote:
> Stefan Fritsch wrote:
> > On Friday 29 May 2009, William A. Rowe, Jr. wrote:
> >>  [  ]  Release apr-util 1.3.5 as GA
> >
> > apr-util's "make check" fails in testdbm because test/Makefile.in
> > misses ../dbm/.libs when setting LD_LIBRARY_PATH.
>
> Patches hugely appreciated.

Attached. I guess it only happens if you do "make check" before "make 
install", or if you did "make install DESTDIR=..." like package build 
scripts do.


Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Stefan Fritsch wrote:
> On Friday 29 May 2009, William A. Rowe, Jr. wrote:
>>  [  ]  Release apr-util 1.3.5 as GA
> 
> apr-util's "make check" fails in testdbm because test/Makefile.in 
> misses ../dbm/.libs when setting LD_LIBRARY_PATH.

Patches hugely appreciated.

Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Friday 29 May 2009, William A. Rowe, Jr. wrote:
>  [  ]  Release apr-util 1.3.5 as GA

apr-util's "make check" fails in testdbm because test/Makefile.in 
misses ../dbm/.libs when setting LD_LIBRARY_PATH.




Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
> 
> Minor glitch on all Solaris variants for apr-util: If not dbd driver was
> complied make check fails because the Solaris flavour of bash is picky regarding
> an for loop with an empty list (for i in ; do). The ones on RHEL don't seem to
> care. But IMHO nothing that prevents from releasing.

Patches hugely appreciated; usual convention; add x to the list and test
to dodge the value x.

Bill

Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Ruediger Pluem <rp...@apache.org>.
On 29.05.2009 10:08, William A. Rowe, Jr. wrote:
> Candidates in the usual location, may take up to an hour to sync.
> Letting this vote run through midnight Monday morning, my time,
> so depending on my weekend I'll either stage-to-mirrors late that
> night, or first thing Monday a.m. for announcement about 12 hrs
> later after some mirrors have caught up.  Windows .zip's will show
> up sometime tomorrow when I have the humor :)
> 
>  +/-1
>  [ +1 ]  Release apr 1.3.4 as GA
>  [ +1 ]  Release apr-util 1.3.5 as GA
> 

Tested on

RHEL 4 32 bit
RHEL 4 64 bit
RHEL 5 32 bit
RHEL 5 64 bit
SuSE 10.2 32 bit
Solaris 8 SPARC
Solaris 9 SPARC
Solaris 10 SPARC

Minor glitch on all Solaris variants for apr-util: If not dbd driver was
complied make check fails because the Solaris flavour of bash is picky regarding
an for loop with an empty list (for i in ; do). The ones on RHEL don't seem to
care. But IMHO nothing that prevents from releasing.

Regards

Rüdiger




Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Rainer Jung wrote:
> 
> Also seeing Ruediger's observation concerning the empty shell loop in
> test Makefile for apr-util on Solaris; r780412 fixes it.

Yup, that's going to be picked up.  Very nice.

> On Windows testpass fails, because there's no crypt but the test still
> tries to validate the Unix crypted hashes against the password. So the
> test is broken.

Not exactly.  In the test suite;

#ifdef WIN32

or similar is absolutely verboten.  It indicates an APR design flaw, because
only APR_HAVE_... or APR_HAS_... or a result code of APR_ENOTIMPL can be
used to determine if APR on a given architecture supports something.

There's no test for "we have crypt" so the failure is valid.



Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Rainer Jung <ra...@kippdata.de>.
On 29.05.2009 10:08, William A. Rowe, Jr. wrote:
>  +/-1
>  [  ]  Release apr 1.3.4 as GA
>  [  ]  Release apr-util 1.3.5 as GA
> 
> Folks, your opinions please.

+1 (non-binding) on Solaris 8 and Windows XP for both

Also seeing Ruediger's observation concerning the empty shell loop in
test Makefile for apr-util on Solaris; r780412 fixes it.

On Windows testpass fails, because there's no crypt but the test still
tries to validate the Unix crypted hashes against the password. So the
test is broken.

Regards,

Rainer

Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Guenter Knauf wrote:
> William A. Rowe, Jr. schrieb:
>>  +/-1
>>  [  ]  Release apr 1.3.4 as GA
>>  [  ]  Release apr-util 1.3.5 as GA
>>
>> Folks, your opinions please.
> MingW32 / MSYS configure build is still broken ...

As Mladen broke this versions ago, I see no point in holding up any
release for this issue.  If you want him to fix it, ask him (nicely).


Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Guenter Knauf <fu...@apache.org>.
William A. Rowe, Jr. schrieb:
>  +/-1
>  [  ]  Release apr 1.3.4 as GA
>  [  ]  Release apr-util 1.3.5 as GA
> 
> Folks, your opinions please.
MingW32 / MSYS configure build is still broken ...

Günter.







Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 31, 2009, at 10:09 AM, Bojan Smojver wrote:

> On Fri, 2009-05-29 at 03:08 -0500, William A. Rowe, Jr. wrote:
>> [+1]  Release apr 1.3.4 as GA
>> [-1]  Release apr-util 1.3.5 as GA
>
> ----------------------
> $ ./testall -v testdbm
> testdbm             : |Line 175: expected <0>, but saw <20019>
> FAILED 1 of 2
> Failed Tests   		Total	Fail	Failed %
> ===================================================
> testdbm        		    2	   1	 50.00%
> ----------------------
>
> We should redo APU with already committed patches, I think.
>

+1


Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Bojan Smojver <bo...@rexursive.com>.
On Fri, 2009-05-29 at 03:08 -0500, William A. Rowe, Jr. wrote:
>  [+1]  Release apr 1.3.4 as GA
>  [-1]  Release apr-util 1.3.5 as GA

----------------------
$ ./testall -v testdbm
testdbm             : |Line 175: expected <0>, but saw <20019>
FAILED 1 of 2
Failed Tests   		Total	Fail	Failed %
===================================================
testdbm        		    2	   1	 50.00%
----------------------

We should redo APU with already committed patches, I think.

-- 
Bojan


Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
> 
> On 05/31/2009 01:15 AM, William A. Rowe, Jr. wrote:
>> FYI - As soon as I see one more committer ack the 1.3 release, I will
>> move ahead with tagging an 0.9; I just figured it wasn't worth doing
>> if things were out of sorts.
>>
>> If anyone wants to address any 'make check' flaw there, first, that
>> would be terrific.  I doubt we'll see another 0.9 release after this.
> 
> The 'make check' errors do not occur with 0.9 as we have neither dbd
> nor dbm drivers in 0.9.

Then we simply need to validate that the poll issues also do not occur
(I doubt they do) and apr[-util]-0.9 looks ready to rock n roll.

Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Ruediger Pluem <rp...@apache.org>.

On 05/31/2009 01:15 AM, William A. Rowe, Jr. wrote:
> FYI - As soon as I see one more committer ack the 1.3 release, I will
> move ahead with tagging an 0.9; I just figured it wasn't worth doing
> if things were out of sorts.
> 
> If anyone wants to address any 'make check' flaw there, first, that
> would be terrific.  I doubt we'll see another 0.9 release after this.

The 'make check' errors do not occur with 0.9 as we have neither dbd
nor dbm drivers in 0.9.

Regards

Rüdiger



Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
FYI - As soon as I see one more committer ack the 1.3 release, I will
move ahead with tagging an 0.9; I just figured it wasn't worth doing
if things were out of sorts.

If anyone wants to address any 'make check' flaw there, first, that
would be terrific.  I doubt we'll see another 0.9 release after this.

Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Bojan Smojver <bo...@rexursive.com>.
On Sun, 2009-05-31 at 09:15 -0700, Sander Temme wrote:
> Looks like descs has not been filled in:
> 
> (gdb) p descs
> $8 = (const apr_pollfd_t *) 0x0
> 
> Should that be NULL after the poll?

Maybe you need to step into apr_pollset_poll() on line 384, to see what
happens to descs there. Looks like success is being returned, but descs
is still NULL, where it should not be:
---------------------
        if (descriptors) {
            *descriptors = pollset->result_set;
        }
---------------------

We know that descriptors is not NULL there, because it is &descs. So, I
guess pollset->result_set must be NULL then, which it cannot be because
it was supposed to be initialised in apr_pollset_create().

Maybe something is stomping over the apr_pollset_t structure and making
result_set NULL. Really weird...

-- 
Bojan


Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Ryan Phillips <ry...@trolocsis.com>.
Sander Temme <sa...@temme.net> said:
>
> On May 31, 2009, at 3:31 AM, Bojan Smojver wrote:
>
>> On Sat, 2009-05-30 at 23:55 -0700, Sander Temme wrote:
>>> #0  0x000103a7 in send0_pollset (tc=0xbffff508, data=0x0) at
>>> testpoll.c:389
>>
>> If you stop there and have a look at the vars, anything that GDB  
>> doesn't
>> like? Wrong alignment and such?
>
>
> I built a new copy with -O0.  Make check gives me:
>
> testpoll            : |/bin/sh: line 1: 54775 Bus error                
> (core dumped) ./$prog
> Programs failed: testall
> make[1]: *** [check] Error 138
> make: *** [check] Error 2
>
> #0  0x0001213e in send0_pollset (tc=0xbffff564, data=0x0) at  
> testpoll.c:389
> #1  0x000024b4 in abts_run_test (ts=0x1001f0, f=0x12071 <send0_pollset>, 
> value=0x0) at abts.c:168
> #2  0x00013303 in testpoll (suite=0x1001f0) at testpoll.c:685
> #3  0x00002e4d in main (argc=1, argv=0xbffff5e8) at abts.c:424

What is the expected behavior of timeout == 0 of the APR poll APIs
(apr_poll, apr_pollset_poll, etc)? Since poll() returns immediately when
the timeout is zero, could this cause unexpected behavior within the
testpoll application?

Regards,
Ryan


Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Sander Temme <sa...@temme.net>.
On May 31, 2009, at 3:31 AM, Bojan Smojver wrote:

> On Sat, 2009-05-30 at 23:55 -0700, Sander Temme wrote:
>> #0  0x000103a7 in send0_pollset (tc=0xbffff508, data=0x0) at
>> testpoll.c:389
>
> If you stop there and have a look at the vars, anything that GDB  
> doesn't
> like? Wrong alignment and such?


I built a new copy with -O0.  Make check gives me:

testpoll            : |/bin/sh: line 1: 54775 Bus error                
(core dumped) ./$prog
Programs failed: testall
make[1]: *** [check] Error 138
make: *** [check] Error 2

#0  0x0001213e in send0_pollset (tc=0xbffff564, data=0x0) at  
testpoll.c:389
#1  0x000024b4 in abts_run_test (ts=0x1001f0, f=0x12071  
<send0_pollset>, value=0x0) at abts.c:168
#2  0x00013303 in testpoll (suite=0x1001f0) at testpoll.c:685
#3  0x00002e4d in main (argc=1, argv=0xbffff5e8) at abts.c:424

That is actually

     ABTS_PTR_EQUAL(tc, s[0], descs[0].desc.s);

Nothing weird in tc:

(gdb) p tc
$1 = (abts_case *) 0xbffff564
(gdb) p *tc
$2 = {
   failed = 1,
   suite = 0x100880
}
(gdb) p *tc->suite
$3 = {
   name = 0x1008a0 "testpoll",
   num_test = 6,
   failed = 0,
   not_run = 0,
   not_impl = 0,
   next = 0x0
}

Socket looks OK:

(gdb) p *s[0]
$7 = {
   pool = 0x804018,
   socketdes = 3,
   type = 2,
   protocol = 0,
   local_addr = 0x8216d0,
   remote_addr = 0x821868,
   timeout = -1,
   local_port_unknown = 0,
   local_interface_unknown = 0,
   remote_addr_unknown = 1,
   options = 0,
   inherit = 0,
   userdata = 0x0
}

Looks like descs has not been filled in:

(gdb) p descs
$8 = (const apr_pollfd_t *) 0x0

Should that be NULL after the poll?

S.

-- 
sander@temme.net              http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF


Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Bojan Smojver <bo...@rexursive.com>.
On Sat, 2009-05-30 at 23:55 -0700, Sander Temme wrote:
> #0  0x000103a7 in send0_pollset (tc=0xbffff508, data=0x0) at  
> testpoll.c:389

If you stop there and have a look at the vars, anything that GDB doesn't
like? Wrong alignment and such?

-- 
Bojan


Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Sander Temme <sa...@temme.net>.
On May 30, 2009, at 10:20 PM, Bojan Smojver wrote:

> On Sat, 2009-05-30 at 21:39 -0700, Sander Temme wrote:
>> testpoll            : |/bin/sh: line 1:  1831 Bus
>> error               ./$prog
>> Programs failed: testall
>> make[1]: *** [check] Error 138
>> make: *** [check] Error 2
>
> What does gdb tell you?


#0  0x000103a7 in send0_pollset (tc=0xbffff508, data=0x0) at  
testpoll.c:389
#1  0x00001ba5 in abts_run_test (ts=0x1001f0, f=0x102f0  
<send0_pollset>, value=0x0) at abts.c:168
#2  0x000113fb in testpoll (suite=0x1001f0) at testpoll.c:685
#3  0x00002385 in main (argc=1, argv=0xbffff5e8) at abts.c:424

S.

-- 
sander@temme.net              http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF


Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Bojan Smojver <bo...@rexursive.com>.
On Sat, 2009-05-30 at 21:39 -0700, Sander Temme wrote:
> testpoll            : |/bin/sh: line 1:  1831 Bus  
> error               ./$prog
> Programs failed: testall
> make[1]: *** [check] Error 138
> make: *** [check] Error 2

What does gdb tell you?

-- 
Bojan


Re: Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by tr...@gmail.com.
On May 31, 2009 5:11pm, Bojan Smojver <bo...@rexursive.com> wrote:
> On Sun, 2009-05-31 at 05:21 -0700, Jeff Trawick wrote:

> > FWIW, "make check" has been causing a system panic for me on at least

> > 10.5.5-10.5.7. As Paul mentioned earlier (somewhere), this is

> > triggered by our kqueue() use (which has no issues AFAICT on FreeBSD).

> > I don't recall other people reporting system panics.



> Surely, that must be a kernel bug. No?

A panic triggered by user space? Of course ;)

If more than a couple of people are having to remember not to run "make  
check," then APR shouldn't use kqueue() until the kernel problem is  
resolved.

Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Bojan Smojver <bo...@rexursive.com>.
On Sun, 2009-05-31 at 05:21 -0700, Jeff Trawick wrote:
> FWIW, "make check" has been causing a system panic for me on at least
> 10.5.5-10.5.7.  As Paul mentioned earlier (somewhere), this is
> triggered by our kqueue() use (which has no issues AFAICT on FreeBSD).
> I don't recall other people reporting system panics.

Surely, that must be a kernel bug. No?

-- 
Bojan


Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, May 30, 2009 at 9:39 PM, Sander Temme <sa...@temme.net> wrote:

>
> On May 29, 2009, at 1:08 AM, William A. Rowe, Jr. wrote:
>
>  Candidates in the usual location, may take up to an hour to sync.
>> Letting this vote run through midnight Monday morning, my time,
>> so depending on my weekend I'll either stage-to-mirrors late that
>> night, or first thing Monday a.m. for announcement about 12 hrs
>> later after some mirrors have caught up.  Windows .zip's will show
>> up sometime tomorrow when I have the humor :)
>>
>> +/-1
>> [-0]  Release apr 1.3.4 as GA
>> [+1]  Release apr-util 1.3.5 as GA
>>
>> Folks, your opinions please.
>>
>
>

> -1 on APR for Darwin -- see below.
>


>
> ----------
> Darwin Legadema.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31
> 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386
>
> apr-1.3.4:
>
> testpoll            : |/bin/sh: line 1:  1831 Bus error
> ./$prog
> Programs failed: testall
> make[1]: *** [check] Error 138
> make: *** [check] Error 2
>
> apr-1.3.3: All tests passed.
>
> That's a regression.  Don't know what it means.


FWIW, "make check" has been causing a system panic for me on at least
10.5.5-10.5.7.  As Paul mentioned earlier (somewhere), this is triggered by
our kqueue() use (which has no issues AFAICT on FreeBSD).  I don't recall
other people reporting system panics.

After disabling kqueue(), I get different crashes in testpoll.

#0  0x000d5eea in impl_pollcb_remove (pollcb=0x208d00,
descriptor=0xbffff7d8) at poll/unix/poll.c:352
352        if (descriptor->desc.s == pollcb->copyset[i]->desc.s) {
(gdb) where
#0  0x000d5eea in impl_pollcb_remove (pollcb=0x208d00,
descriptor=0xbffff7d8) at poll/unix/poll.c:352
#1  0x000d6365 in apr_pollcb_remove (pollcb=0x208d00, descriptor=0xbffff7d8)
at poll/unix/pollcb.c:152
#2  0x00012b9a in trigger_pollcb (tc=0xbffff814, data=0x0) at testpoll.c:614
#3  0x00001eec in abts_run_test (ts=0x200470, f=0x12a14 <trigger_pollcb>,
value=0x0) at abts.c:168
#4  0x0001303f in testpoll (suite=0x200470) at testpoll.c:698
#5  0x00002885 in main (argc=3, argv=0xbffff898) at abts.c:424

Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Sander Temme <sa...@temme.net>.
On May 29, 2009, at 1:08 AM, William A. Rowe, Jr. wrote:

> Candidates in the usual location, may take up to an hour to sync.
> Letting this vote run through midnight Monday morning, my time,
> so depending on my weekend I'll either stage-to-mirrors late that
> night, or first thing Monday a.m. for announcement about 12 hrs
> later after some mirrors have caught up.  Windows .zip's will show
> up sometime tomorrow when I have the humor :)
>
> +/-1
> [-0]  Release apr 1.3.4 as GA
> [+1]  Release apr-util 1.3.5 as GA
>
> Folks, your opinions please.

FreeBSD 6.4-STABLE i386
Ubuntu 9.04 x86_64
Darwin i386

+1 on APR-Util.

+1 on APR for Ubuntu and FreeBSD
-1 on APR for Darwin -- see below.

--------------------

Good hashes, though unconventionally formatted:

[sctemme@Legadema] apr-test $ for f in *.tar.{bz2,gz} ; do echo $f ;  
md5 $f ; cat $f.md5 ; done
apr-1.3.4.tar.bz2
MD5 (apr-1.3.4.tar.bz2) = 0d5f7bb11e9a3214d234cac4d84ff228
apr-1.3.4.tar.bz2: 0D 5F 7B B1 1E 9A 32 14  D2 34 CA C4 D8 4F F2 28
apr-util-1.3.5.tar.bz2
MD5 (apr-util-1.3.5.tar.bz2) = 9a0b6d2705ffdb0dad97ffe941dfcc41
apr-util-1.3.5.tar.bz2: 9A 0B 6D 27 05 FF DB 0D  AD 97 FF E9 41 DF CC 41
apr-1.3.4.tar.gz
MD5 (apr-1.3.4.tar.gz) = 5aa20df99551190f1f7390297db99487
apr-1.3.4.tar.gz: 5A A2 0D F9 95 51 19 0F  1F 73 90 29 7D B9 94 87
apr-util-1.3.5.tar.gz
MD5 (apr-util-1.3.5.tar.gz) = 2de826301b7dcf69a971a1e12e0a8bd9
apr-util-1.3.5.tar.gz: 2D E8 26 30 1B 7D CF 69  A9 71 A1 E1 2E 0A 8B D9

Good signatures:

[sctemme@Legadema] apr-test $ for f in *.asc ; do gpg --verify $f ; done
gpg: Signature made Fri May 29 00:59:31 2009 PDT using RSA key ID  
CB9B9EC5
gpg: Good signature from "William A. Rowe, Jr. <wr...@rowe-clan.net>"
gpg:                 aka "William A. Rowe, Jr. <wr...@apache.org>"
gpg:                 aka "William A. Rowe, Jr. <william.rowe@springsource.com 
 >"
gpg: Signature made Fri May 29 00:59:28 2009 PDT using RSA key ID  
CB9B9EC5
gpg: Good signature from "William A. Rowe, Jr. <wr...@rowe-clan.net>"
gpg:                 aka "William A. Rowe, Jr. <wr...@apache.org>"
gpg:                 aka "William A. Rowe, Jr. <william.rowe@springsource.com 
 >"
gpg: Signature made Fri May 29 01:03:18 2009 PDT using RSA key ID  
CB9B9EC5
gpg: Good signature from "William A. Rowe, Jr. <wr...@rowe-clan.net>"
gpg:                 aka "William A. Rowe, Jr. <wr...@apache.org>"
gpg:                 aka "William A. Rowe, Jr. <william.rowe@springsource.com 
 >"
gpg: Signature made Fri May 29 01:03:14 2009 PDT using RSA key ID  
CB9B9EC5
gpg: Good signature from "William A. Rowe, Jr. <wr...@rowe-clan.net>"
gpg:                 aka "William A. Rowe, Jr. <wr...@apache.org>"
gpg:                 aka "William A. Rowe, Jr. <william.rowe@springsource.com 
 >"

-----------------------

./configure --prefix=`pwd`/../../inst && make -j4 && make install &&  
make test
./configure --prefix=`pwd`/../../inst --with-apr=`pwd`/../../inst/ &&  
make -j4 && make install && make test

----------
Darwin Legadema.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31  
22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386

apr-1.3.4:

testpoll            : |/bin/sh: line 1:  1831 Bus  
error               ./$prog
Programs failed: testall
make[1]: *** [check] Error 138
make: *** [check] Error 2

apr-1.3.3: All tests passed.

That's a regression.  Don't know what it means.

apr-util-1.3.5: Looks like everything passed.

------------
Linux surtur 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC  
2009 x86_64 GNU/Linux

apr-1.3.4: All tests passed.

apr-util-1.3.5: Looks like everything passed.

------------
FreeBSD bagheera.sandla.org. 6.4-STABLE FreeBSD 6.4-STABLE #11: Tue  
May  5 19:08:06 PDT 2009     root@bagheera.sandla.org.:/usr/obj/usr/ 
src/sys/BAGHEERA  i386

apr-1.3.4: All tests passed.
apr-util-1.3.5: All tests passed.
Loaded pgsql driver OK.
Failed to open pgsql[]
(I don't have a Postgres server to test against)

-- 
sander@temme.net              http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF


Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Guenter Knauf <fu...@apache.org>.
William A. Rowe, Jr. schrieb:
>  [+1]  Release apr 1.3.4 as GA
>  [+1]  Release apr-util 1.3.5 as GA
builds for, and works with NetWare.

Günter.






Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Guenter Knauf <fu...@apache.org>.
Hi,
Guenter Knauf schrieb:
> I'm neither a configure guru; but when we do cross-builds of libcurl we
> use --with-random=notused to pass this check, so I guess we have there a
> hack in the configure script ...
wrong track - I had in mind it was /dev/random, but its /dev/zero which
breaks ...

so ignore this post :)

Günter.



Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Guenter Knauf <fu...@apache.org>.
Hi Günther,
Makulik schrieb:
> Guenter Knauf-2 wrote:
>> Unfortunately cross-mingw32 on Linux is broken either for another
>> reason: configure wants to check somewhere for /dev/zero:
>>
> 
> I came over the same issue when I tried to cross compile APR for
> a powerpc system. The real problem is, that despite configure allows
> to override ac_cv_file__dev_zero=yes if you have it on your target
> system, there's a non overridable run time check if mmap works with
> /dev/zero that will simply reset ac_cv_file__dev_zero=no when
> cross-compiling is detected. I had to hack the configure script to
> skip this test, introducing another variable 
> ac_cv_mmap_dev_zero_works that allows that explicitely.
> IMHO this should be corrected in the autoconf sources for
> configure, but I have no experience with autoconf.
> Can anyone tell how to bring this to the config script, resp. to the
> source of it?
I'm neither a configure guru; but when we do cross-builds of libcurl we
use --with-random=notused to pass this check, so I guess we have there a
hack in the configure script ...

Günter.









Re: [vote] release apr 1.3.4, apr-util 1.3.5

Posted by Makulik <gu...@kathrein.de>.

Guenter Knauf-2 wrote:
> 
> Unfortunately cross-mingw32 on Linux is broken either for another
> reason: configure wants to check somewhere for /dev/zero:
> 

I came over the same issue when I tried to cross compile APR for
a powerpc system. The real problem is, that despite configure allows
to override ac_cv_file__dev_zero=yes if you have it on your target
system, there's a non overridable run time check if mmap works with
/dev/zero that will simply reset ac_cv_file__dev_zero=no when
cross-compiling is detected. I had to hack the configure script to
skip this test, introducing another variable 
ac_cv_mmap_dev_zero_works that allows that explicitely.
IMHO this should be corrected in the autoconf sources for
configure, but I have no experience with autoconf.
Can anyone tell how to bring this to the config script, resp. to the
source of it?

Günther
-- 
View this message in context: http://www.nabble.com/-vote--release-apr-1.3.4%2C-apr-util-1.3.5-tp23775995p24162578.html
Sent from the APR Dev (Apache Portable Runtime) mailing list archive at Nabble.com.