You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Paul Querna <ch...@force-elite.com> on 2005/03/16 01:27:43 UTC
[VOTE] 1.1.1 Release
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lots of little bug fixes got backported. Please check it out and vote.
Download:
http://www.apache.org/~pquerna/dev/apr-1.1.1/
APR Changes:
~ *) Disable sendfile support for S/390 only in kernel versions < 2.4.0.
~ [Joe Orton]
~ *) Fix posix rwlock detection on Darwin. [Aaron Bannert]
~ *) Build fix for Multicast support on HP-UX 11.00 and Tru64 [Joe Orton]
~ *) Fix libapr.rc for Win32 builds [William Rowe]
~ *) Rewrite apr_file_writev_full using apr_file_write_full.
~ [Paul Querna]
~ *) Use APR_RING_CONCAT for moving dead list in KQueue, sys_epoll, and
~ Event Ports. [Paul Querna]
~ *) find_apr.m4: Try installed APR before bundled copy if --with-apr not
~ passed to configure. [Justin Erenkrantz]
APR-Util Changes:
~ *) Fix memory leak in buckets when using APR_POOL_DEBUG mode.
~ [Joe Schaefer]
~ *) find_apu.m4: Try installed APR-util before bundled copy if
~ --with-apr-util not passed to configure. [Justin Erenkrantz]
MD5 Sums:
1b3089a03a52b1c9103d42dd13c5e897 apr-1.1.1.tar.Z
8ef474ee579b9f9343f145cc7b973607 apr-1.1.1.tar.bz2
e153fda2df2338250548448c7a6e3d59 apr-1.1.1.tar.gz
db9e745b3935ca6f42e24ba23d1d5f34 apr-util-1.1.1.tar.Z
365dee4792e0f6ee543c68c8decec7ef apr-util-1.1.1.tar.bz2
04c2c13d075e3d7ff76ea5140476835e apr-util-1.1.1.tar.gz
- -Paul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCN31/94h19kJyHwARAm2sAJ40hFlUZvVJt+FprqgUWH7WUJDkswCgkzC2
axBJGD0+okoY9KBpx6CjOSw=
=dbuY
-----END PGP SIGNATURE-----
Re: [VOTE] 1.1.1 Release
Posted by Graham Leggett <mi...@sharp.fm>.
Paul Querna wrote:
> http://www.apache.org/~pquerna/dev/apr-1.1.1/
+1 (RHEL RPMs)
Regards,
Graham
--
Re: [VOTE] 1.1.1 Release
Posted by Sander Striker <st...@apache.org>.
Paul Querna wrote:
> Paul Querna wrote:
>
>> Lots of little bug fixes got backported. Please check it out and vote.
>>
>> Download:
>> http://www.apache.org/~pquerna/dev/apr-1.1.1/
>>
>
> APR-Util did not have the correct win32 build fixes in 1.1.1. These
> have been fixed in APR-Util 1.1.2. APR-Iconv also needed fixes for
> win32. Thanks to Justin for picking this up.
>
> Updated Downloads:
> http://www.apache.org/~pquerna/dev/apu-1.1.2/
> http://www.apache.org/~pquerna/dev/api-1.0.2/
+1 for apr 1.1.1 and apr-util 1.1.2
Tested on:
Linux (Ubuntu - Warty Warthog)
Win32 (XP SP2) with Visual Studio .NET 2002
Sander
Re: [VOTE] 1.1.1 Release
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Mar 15, 2005 at 09:59:55PM -0800, Paul Querna wrote:
> Paul Querna wrote:
> >Lots of little bug fixes got backported. Please check it out and vote.
> >
> >Download:
> >http://www.apache.org/~pquerna/dev/apr-1.1.1/
> >
>
> APR-Util did not have the correct win32 build fixes in 1.1.1. These
> have been fixed in APR-Util 1.1.2. APR-Iconv also needed fixes for
> win32. Thanks to Justin for picking this up.
>
> Updated Downloads:
> http://www.apache.org/~pquerna/dev/apu-1.1.2/
> http://www.apache.org/~pquerna/dev/api-1.0.2/
+1 for APR 1.1.1, APR-util 1.1.2, and APR-iconv 1.0.2.
Tested on:
Win32 with Visual Studio .NET 2003
Darwin (Mac OS X 10.3.8)
Thanks! -- justin
Re: [VOTE] 1.1.1 Release
Posted by Paul Querna <ch...@force-elite.com>.
Paul Querna wrote:
> Lots of little bug fixes got backported. Please check it out and vote.
>
> Download:
> http://www.apache.org/~pquerna/dev/apr-1.1.1/
>
APR-Util did not have the correct win32 build fixes in 1.1.1. These
have been fixed in APR-Util 1.1.2. APR-Iconv also needed fixes for
win32. Thanks to Justin for picking this up.
Updated Downloads:
http://www.apache.org/~pquerna/dev/apu-1.1.2/
http://www.apache.org/~pquerna/dev/api-1.0.2/
> APR Changes:
>
> ~ *) Disable sendfile support for S/390 only in kernel versions < 2.4.0.
> ~ [Joe Orton]
>
> ~ *) Fix posix rwlock detection on Darwin. [Aaron Bannert]
>
> ~ *) Build fix for Multicast support on HP-UX 11.00 and Tru64 [Joe Orton]
>
> ~ *) Fix libapr.rc for Win32 builds [William Rowe]
>
> ~ *) Rewrite apr_file_writev_full using apr_file_write_full.
> ~ [Paul Querna]
>
> ~ *) Use APR_RING_CONCAT for moving dead list in KQueue, sys_epoll, and
> ~ Event Ports. [Paul Querna]
>
> ~ *) find_apr.m4: Try installed APR before bundled copy if --with-apr not
> ~ passed to configure. [Justin Erenkrantz]
>
> APR-Util Changes:
>
> ~ *) Fix memory leak in buckets when using APR_POOL_DEBUG mode.
> ~ [Joe Schaefer]
>
> ~ *) find_apu.m4: Try installed APR-util before bundled copy if
> ~ --with-apr-util not passed to configure. [Justin Erenkrantz]
>
> MD5 Sums:
> 1b3089a03a52b1c9103d42dd13c5e897 apr-1.1.1.tar.Z
> 8ef474ee579b9f9343f145cc7b973607 apr-1.1.1.tar.bz2
> e153fda2df2338250548448c7a6e3d59 apr-1.1.1.tar.gz
> db9e745b3935ca6f42e24ba23d1d5f34 apr-util-1.1.1.tar.Z
> 365dee4792e0f6ee543c68c8decec7ef apr-util-1.1.1.tar.bz2
> 04c2c13d075e3d7ff76ea5140476835e apr-util-1.1.1.tar.gz
>
> -Paul
Re: [VOTE] 1.1.1 Release
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> At 05:08 PM 3/16/2005, Paul Querna wrote:
>
>>William A. Rowe, Jr. wrote:
>>
>>>-1 for apr-util / apr-iconv.
>>>Curt has identified a very significant issue; I will comment
>>>to that thread. Since the 'fix' should be fairly trivial,
>>>I think we should next release a version that deals with
>>>iconv/*.so's.
>>
>>I do not believe this is a valid reason to hold up these releases. This is not a regression from any previous versions. This release fixes many other issues. Once this issue is fixed, we can do another release.
>
>
> Heaven forbid folks examine issues as they queue in :)
>
> +1 on release of 1.1.1 apr release, you are quite right.
Vote Tally:
+1: Justin Erenkrantz, Sander Striker, Brad Nicholes, Jim Jagielski,
Graham Leggett, William A. Rowe.
With that, I have moved the releases to dist/apr to be sync on the
mirrors and I will send out the announcement email later tonight.
Thanks for voting.
-Paul
Re: [VOTE] 1.1.1 Release
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> At 08:29 PM 3/16/2005, Paul Querna wrote:
>
>
>>>For that matter, how do we disambiguate include/ from include/?
>>>Most modern libraries have an include/foopkg/*.h structure.
>>
>>1.0.0
>
>
> Not when, how?
include/apr-0
include/apr-1
Re: [VOTE] 1.1.1 Release
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 08:29 PM 3/16/2005, Paul Querna wrote:
>>For that matter, how do we disambiguate include/ from include/?
>>Most modern libraries have an include/foopkg/*.h structure.
>
>1.0.0
Not when, how?
Re: [VOTE] 1.1.1 Release
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> At 06:57 PM 3/16/2005, Justin Erenkrantz wrote:
>
>>--On Wednesday, March 16, 2005 6:43 PM -0600 "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>>
>>
>>>0.9 and 1.1 yes.
>>>
>>>0.9 and 1.0?
>>
>>Yes. -- justin
>
>
> Which version did we disambiguate apr-config from apr-config-1?
>
1.0.0
> For that matter, how do we disambiguate include/ from include/?
> Most modern libraries have an include/foopkg/*.h structure.
1.0.0
Re: [VOTE] 1.1.1 Release
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 06:57 PM 3/16/2005, Justin Erenkrantz wrote:
>--On Wednesday, March 16, 2005 6:43 PM -0600 "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
>>0.9 and 1.1 yes.
>>
>>0.9 and 1.0?
>
>Yes. -- justin
Which version did we disambiguate apr-config from apr-config-1?
For that matter, how do we disambiguate include/ from include/?
Most modern libraries have an include/foopkg/*.h structure.
Re: [VOTE] 1.1.1 Release
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, March 16, 2005 6:43 PM -0600 "William A. Rowe, Jr."
<wr...@rowe-clan.net> wrote:
> 0.9 and 1.1 yes.
>
> 0.9 and 1.0?
Yes. -- justin
Re: [VOTE] 1.1.1 Release
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 06:19 PM 3/16/2005, Justin Erenkrantz wrote:
>--On Wednesday, March 16, 2005 6:05 PM -0600 "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
>>In answer to the bigger Q - I would discourage anyone from
>>adopting apr 1.0 and hope few have. apr 1.0 wasn't ready for
>>prime time, to coexist on machines which had our original
>>apr 0.9 installed. Now apr 1.1.1 is getting close to getting
>>it right. If I voice that we should take things a bit more
>>slowly and thoroughly, it's because I expect the same attention
>>to detail from apr that folks expect from clib. After all, we
>>are asking our users to give that much trust to our library.
>
>APR 0.9.x and 1.x co-exist just fine on Unix systems. -- justin
0.9 and 1.1 yes.
0.9 and 1.0?
Re: [VOTE] 1.1.1 Release
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, March 16, 2005 6:05 PM -0600 "William A. Rowe, Jr."
<wr...@rowe-clan.net> wrote:
> In answer to the bigger Q - I would discourage anyone from
> adopting apr 1.0 and hope few have. apr 1.0 wasn't ready for
> prime time, to coexist on machines which had our original
> apr 0.9 installed. Now apr 1.1.1 is getting close to getting
> it right. If I voice that we should take things a bit more
> slowly and thoroughly, it's because I expect the same attention
> to detail from apr that folks expect from clib. After all, we
> are asking our users to give that much trust to our library.
APR 0.9.x and 1.x co-exist just fine on Unix systems. -- justin
Re: [VOTE] 1.1.1 Release
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:08 PM 3/16/2005, Paul Querna wrote:
>William A. Rowe, Jr. wrote:
>>-1 for apr-util / apr-iconv.
>>Curt has identified a very significant issue; I will comment
>>to that thread. Since the 'fix' should be fairly trivial,
>>I think we should next release a version that deals with
>>iconv/*.so's.
>
>I do not believe this is a valid reason to hold up these releases. This is not a regression from any previous versions. This release fixes many other issues. Once this issue is fixed, we can do another release.
Heaven forbid folks examine issues as they queue in :)
+1 on release of 1.1.1 apr release, you are quite right.
I will be voting +1 on httpd 2.1 alpha with this version.
I will be voting -1 on taking httpd 2.1 to beta based on
this version, and this specific conflict. Dev's don't mind
having messed up and conflicting libraries (if you wonder
where I've been, there ya go) messing up their systems.
But end users are sure affected, and the point to a beta
is pushing out code at our users/testers, as opposed to
our devs/testers.
I'm glad that Curt was as diligent as he was in following
up the specific conflicts. My svn, httpd, all my packages
are fragmented into their own trees.
I don't expect either is true of the casual users/testers
and any product that rolls these out in the same location or
tries to use the envvar will end up jammed. We have jk2
(well, though it's deprectated), svn, apache, log4cxx, etc
all who've come to trust apr - and we need to do all we can
to continue to keep that trust.
So +1 that 1.1.1 is better than 1.1.0 was.
I am amused that some expect fast reaction to backport these
fixes from trunk - the fixes that are ignored on list for months.
I brought up the .rc/version issues 11/20, no feedback. David
Barrett observed the problem 12/21, I committed the fix 2/7 and
immediately got a flood of (productive) dialog, and immediately
tweaked accordingly. If you aren't happy with my response time
and attitude twords the "httpd 2.1 beta today!" scroll back to
all the unanswered posts from many end users and fellow devs.
In answer to the bigger Q - I would discourage anyone from
adopting apr 1.0 and hope few have. apr 1.0 wasn't ready for
prime time, to coexist on machines which had our original
apr 0.9 installed. Now apr 1.1.1 is getting close to getting
it right. If I voice that we should take things a bit more
slowly and thoroughly, it's because I expect the same attention
to detail from apr that folks expect from clib. After all, we
are asking our users to give that much trust to our library.
Bill
Re: [VOTE] 1.1.1 Release
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> -1 for apr-util / apr-iconv.
>
> Curt has identified a very significant issue; I will comment
> to that thread. Since the 'fix' should be fairly trivial,
> I think we should next release a version that deals with
> iconv/*.so's.
>
I do not believe this is a valid reason to hold up these releases. This
is not a regression from any previous versions. This release fixes many
other issues. Once this issue is fixed, we can do another release.
-Paul