You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Ruediger Pluem <rp...@apache.org> on 2008/08/07 22:02:51 UTC
Time for 1.3.3
What obstacles are left between us and an 1.3.3 release of APR / APR-UTIL?
Regards
Rüdiger
Re: Time for 1.3.3
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Stefan Fritsch wrote:
> On Thursday 07 August 2008, William A. Rowe, Jr. wrote:
>> Stefan, my goal is to have a working 2.62 ready package, so I'll
>> take a closer look, but if other folks would take a peek at this
>> flaw, we'd really appreciate it. It just can't be that hard to fix
>> (if I had cycles I would have already investigated). Some flags
>> are missing somehow for the testrand target.
>
> The problem is that AC_C_BIGENDIAN is broken in autoconf 2.62. This
> will result in APR_IS_BIGENDIAN in apr.h getting the wrong value,
> which might break other software and not just the test. In the case
> of testrand, the problematic code is in random/unix/sha2.c and not in
> testrand.c.
>
> Is there really something in 2.62 you need, or could you simply use
> 2.61 to generate the configure in the tarball? Alternatively, you
> could grab the patch reverting AC_C_BIGENDIAN to the 2.61 behaviour
> from some linux distro and use the patched autoconf.
Given a choice between a broken AC_C_BIGENDIAN test from 2.62, and the
known-good test existing in 2.61, I'm going with 2.61.
http://www.mail-archive.com/autoconf@gnu.org/msg17413.html
indicates that they are ready to address this and recognize what they had
done (still no indication they violated the project's first principal w.r.t.
not emitting stupid warnings for subpackages, a bug we have worked around),
but given that Early August is past, I'm not waiting for 2.63.
So this package is going to be back to 2.61, and at a future date we'll be
ready to adopt 2.63. Maybe a release.sh patch to refuse 2.62 would be
appropriate at this point :)
Re: autoconf/libtool for apr and for httpd, Was: Re: Time for 1.3.3
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
>>
>> What will be used, once httpd 2.2.10 with bundled apr/apr-util gets
>> prepared? Last time (2.2.9), httpd configure plus those inside
>> srclib/apr(-util) got generated with autoconf 2.62.
>>
>
> I've downgraded on my release machine to 2.61
http://lists.gnu.org/archive/html/autoconf/2008-09/msg00065.html
It seems a very long list of regressions are addressed. I suggest
we run with it, and I'll T&R apr sometime later next week. We might
let the release vote run a few extra days to get the best evaluation
of a 2.63 bump. But from that list, it fixes at least three classes
of issues I've seen in bugzilla.
Re: autoconf/libtool for apr and for httpd, Was: Re: Time for 1.3.3
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 17, 2008, at 4:06 PM, Rainer Jung wrote:
> Bojan Smojver schrieb:
>> On Thu, 2008-08-07 at 17:55 -0500, William A. Rowe, Jr. wrote:
>>
>>> Thanks Peter, it begs the question from my last note, should we
>>> refuse
>>> any 2.62 for packaging via our scripts, or just let it slide?
>>>
>>> My gutcheck says simply refuse 2.62.
>>
>> I would generate our configure with 2.61 (for which we know is
>> good) and
>> let others choose their own. In many cases, distributions are
>> shipping
>> their own patches to 2.62 that are addressing the problem, so no
>> need to
>> ban 2.62 outright.
>
> What will be used, once httpd 2.2.10 with bundled apr/apr-util gets
> prepared? Last time (2.2.9), httpd configure plus those inside
> srclib/apr(-util) got generated with autoconf 2.62.
>
I've downgraded on my release machine to 2.61
Re: autoconf/libtool for apr and for httpd, Was: Re: Time for 1.3.3
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Rainer Jung wrote:
> Bojan Smojver schrieb:
>> On Thu, 2008-08-07 at 17:55 -0500, William A. Rowe, Jr. wrote:
>>
>>> Thanks Peter, it begs the question from my last note, should we refuse
>>> any 2.62 for packaging via our scripts, or just let it slide?
>>>
>>> My gutcheck says simply refuse 2.62.
>> I would generate our configure with 2.61 (for which we know is good) and
>> let others choose their own. In many cases, distributions are shipping
>> their own patches to 2.62 that are addressing the problem, so no need to
>> ban 2.62 outright.
>
> What will be used, once httpd 2.2.10 with bundled apr/apr-util gets
> prepared? Last time (2.2.9), httpd configure plus those inside
> srclib/apr(-util) got generated with autoconf 2.62.
Either autoconf 2.61 or autoconf 2.63 given the endian-ness issues.
Although I count on fedora 8 and 9 for most of my needs, I don't use
it for my build toolchain. Peeking in on the status of 2.63 now.
> I noticed, that more generally, httpd-bundled apr(-util) do not
> necessarily use the same autoconf and libtool versions as the standalone
> ones, even when they are released shortly after each other. Would it
> make sense to keep changes small in general to avoid surprises when
> switching from bundled apr(-util) to standalone, even when using the
> same version?
Well, that issue is that we have two different RM's. We could obviously
change the release.sh script to insist on one specific version, but we
again have to keep apr and httpd release.sh scripts in sync with each
other.
Let's hope that in httpd-2.4, "bundled apr" can be done away with? At
least by httpd-3.0.
> Of course the release managers environment is not automatically the
> same. The other possibility would be to really include the released
> apr(-util) inside httpd without regenerating configure and libtool.
>
> Don't know, if I should send this to httpd-dev, but I assume most
> relevant people read both lists.
We do :)
autoconf/libtool for apr and for httpd, Was: Re: Time for 1.3.3
Posted by Rainer Jung <ra...@kippdata.de>.
Bojan Smojver schrieb:
> On Thu, 2008-08-07 at 17:55 -0500, William A. Rowe, Jr. wrote:
>
>> Thanks Peter, it begs the question from my last note, should we refuse
>> any 2.62 for packaging via our scripts, or just let it slide?
>>
>> My gutcheck says simply refuse 2.62.
>
> I would generate our configure with 2.61 (for which we know is good) and
> let others choose their own. In many cases, distributions are shipping
> their own patches to 2.62 that are addressing the problem, so no need to
> ban 2.62 outright.
What will be used, once httpd 2.2.10 with bundled apr/apr-util gets
prepared? Last time (2.2.9), httpd configure plus those inside
srclib/apr(-util) got generated with autoconf 2.62.
I noticed, that more generally, httpd-bundled apr(-util) do not
necessarily use the same autoconf and libtool versions as the standalone
ones, even when they are released shortly after each other. Would it
make sense to keep changes small in general to avoid surprises when
switching from bundled apr(-util) to standalone, even when using the
same version?
Of course the release managers environment is not automatically the
same. The other possibility would be to really include the released
apr(-util) inside httpd without regenerating configure and libtool.
Don't know, if I should send this to httpd-dev, but I assume most
relevant people read both lists.
Regards,
Rainer
Re: Time for 1.3.3
Posted by Bojan Smojver <bo...@rexursive.com>.
On Thu, 2008-08-07 at 17:55 -0500, William A. Rowe, Jr. wrote:
> Thanks Peter, it begs the question from my last note, should we refuse
> any 2.62 for packaging via our scripts, or just let it slide?
>
> My gutcheck says simply refuse 2.62.
I would generate our configure with 2.61 (for which we know is good) and
let others choose their own. In many cases, distributions are shipping
their own patches to 2.62 that are addressing the problem, so no need to
ban 2.62 outright.
PS. I just checked Fedora's Rawhide and autoconf 2.62 there has a patch
that appears to be addressing the same issue. Obviously, openSuSE have
one etc.
--
Bojan
Re: Time for 1.3.3
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Peter Poeml wrote:
> Here is the patch that we added at openSUSE to revert the breakage.
Thanks Peter, it begs the question from my last note, should we refuse
any 2.62 for packaging via our scripts, or just let it slide?
My gutcheck says simply refuse 2.62.
Bill
Re: Time for 1.3.3
Posted by Peter Poeml <po...@suse.de>.
On Fri, Aug 08, 2008 at 12:24:22 +0200, Stefan Fritsch wrote:
> On Thursday 07 August 2008, William A. Rowe, Jr. wrote:
> > Stefan, my goal is to have a working 2.62 ready package, so I'll
> > take a closer look, but if other folks would take a peek at this
> > flaw, we'd really appreciate it. It just can't be that hard to fix
> > (if I had cycles I would have already investigated). Some flags
> > are missing somehow for the testrand target.
>
> The problem is that AC_C_BIGENDIAN is broken in autoconf 2.62. This
> will result in APR_IS_BIGENDIAN in apr.h getting the wrong value,
> which might break other software and not just the test. In the case
> of testrand, the problematic code is in random/unix/sha2.c and not in
> testrand.c.
>
> Is there really something in 2.62 you need, or could you simply use
> 2.61 to generate the configure in the tarball? Alternatively, you
> could grab the patch reverting AC_C_BIGENDIAN to the 2.61 behaviour
> from some linux distro and use the patched autoconf.
>
> Stefan
Here is the patch that we added at openSUSE to revert the breakage.
Peter
--
"WARNING: This bug is visible to non-employees. Please be respectful!"
SUSE LINUX Products GmbH
Research & Development
Re: Time for 1.3.3
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Thursday 07 August 2008, William A. Rowe, Jr. wrote:
> Stefan, my goal is to have a working 2.62 ready package, so I'll
> take a closer look, but if other folks would take a peek at this
> flaw, we'd really appreciate it. It just can't be that hard to fix
> (if I had cycles I would have already investigated). Some flags
> are missing somehow for the testrand target.
The problem is that AC_C_BIGENDIAN is broken in autoconf 2.62. This
will result in APR_IS_BIGENDIAN in apr.h getting the wrong value,
which might break other software and not just the test. In the case
of testrand, the problematic code is in random/unix/sha2.c and not in
testrand.c.
Is there really something in 2.62 you need, or could you simply use
2.61 to generate the configure in the tarball? Alternatively, you
could grab the patch reverting AC_C_BIGENDIAN to the 2.61 behaviour
from some linux distro and use the patched autoconf.
Stefan
Re: Time for 1.3.3
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Stefan Fritsch wrote:
> On Thursday 07 August 2008, Ruediger Pluem wrote:
>> What obstacles are left between us and an 1.3.3 release of APR /
>> APR-UTIL?
>
> No obstacle, but please don't use autoconf 2.62. See
> https://issues.apache.org/bugzilla/show_bug.cgi?id=45389
Stefan, my goal is to have a working 2.62 ready package, so I'll take
a closer look, but if other folks would take a peek at this flaw, we'd
really appreciate it. It just can't be that hard to fix (if I had
cycles I would have already investigated). Some flags are missing
somehow for the testrand target.
Re: Time for 1.3.3
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Thursday 07 August 2008, Ruediger Pluem wrote:
> What obstacles are left between us and an 1.3.3 release of APR /
> APR-UTIL?
No obstacle, but please don't use autoconf 2.62. See
https://issues.apache.org/bugzilla/show_bug.cgi?id=45389
Cheers,
Stefan
Re: Time for 1.3.3
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bob Rossi wrote:
> On Thu, Aug 07, 2008 at 10:02:51PM +0200, Ruediger Pluem wrote:
>> What obstacles are left between us and an 1.3.3 release of APR / APR-UTIL?
>
> Getting apr/apr-util to port cleanly to mingw? I can help with testing.
Nope.
I mean, yes, please help! We do want it ported cleanly :) Even to the
point that I have a fresh 2008 box sitting here awaiting the MSYS/MINGW
toolchains along with most modern visual studios.
But No, it's not a /showstopper/, all we are looking for in 1.3.3 are no
regressions :)
There's nothing stopping us from releasing 1.3.4 a week afterwards.
Re: Time for 1.3.3
Posted by Bob Rossi <bo...@cox.net>.
On Thu, Aug 07, 2008 at 10:02:51PM +0200, Ruediger Pluem wrote:
> What obstacles are left between us and an 1.3.3 release of APR / APR-UTIL?
Getting apr/apr-util to port cleanly to mingw? I can help with testing.
Bob Rossi
Re: Time for 1.3.3
Posted by Ruediger Pluem <rp...@apache.org>.
On 08/07/2008 10:08 PM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>> What obstacles are left between us and an 1.3.3 release of APR /
>> APR-UTIL?
>
> Here's an offer, I'll tag and roll 24 hours from now unless someone
> tells me
> that the API remains broken w.r.t. reslist etc. Unless we hear it is now
> broken, we'll presume that 1.3.3 is entirely backwards compatible to
> 1.2.12.
Sounds good.
Regards
Rüdiger
Re: Time for 1.3.3
Posted by Bojan Smojver <bo...@rexursive.com>.
On Thu, 2008-08-07 at 16:46 -0500, William A. Rowe, Jr. wrote:
> Then make it so, and buy me a beverage at ApacheCon when you lose :)
Aye, aye, cap'n!
> Oh, if your patch isn't committed within 22 hrs it will miss the bus,
> so please do move on that.
On the bus :-)
--
Bojan
Re: Time for 1.3.3
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bojan Smojver wrote:
>
> I'll put $5 on that ;-)
>
> Seriously, there is one backport for reslist we need to do
> (r683517/683520) and that should be it regarding reslist.
Then make it so, and buy me a beverage at ApacheCon when you lose :)
Oh, if your patch isn't committed within 22 hrs it will miss the bus,
so please do move on that.
Re: Time for 1.3.3
Posted by Bojan Smojver <bo...@rexursive.com>.
On Thu, 2008-08-07 at 15:08 -0500, William A. Rowe, Jr. wrote:
> Here's an offer, I'll tag and roll 24 hours from now unless someone tells me
> that the API remains broken w.r.t. reslist etc.
Not broken. In fact, the trunk changes have been addressed in an
entirely backward compatible way.
> Unless we hear it is now
> broken, we'll presume that 1.3.3 is entirely backwards compatible to 1.2.12.
I'll put $5 on that ;-)
Seriously, there is one backport for reslist we need to do
(r683517/683520) and that should be it regarding reslist.
--
Bojan
Re: Time for 1.3.3
Posted by Peter Poeml <po...@suse.de>.
On Fri, Aug 08, 2008 at 12:42:25AM +0200, Peter Poeml wrote:
> On Thu, Aug 07, 2008 at 03:08:14 -0500, William A. Rowe, Jr. wrote:
> > Here's an offer, I'll tag and roll 24 hours from now unless someone tells me
> > that the API remains broken w.r.t. reslist etc. Unless we hear it is now
> > broken, we'll presume that 1.3.3 is entirely backwards compatible to 1.2.12.
> >
> > Bill
>
> I am a heavy user of both mod_dbd and apr_memcache, and I'm
> investigating an apr_memcache related memleak right now that I started
> getting with 1.3.0, so I will give this a good testing in the next few
> hours.
Looks good to me -
Running fine since a few hours on two SLE10SP2 servers, busy with
database and memcache queries.
Thanks,
Peter
--
"WARNING: This bug is visible to non-employees. Please be respectful!"
SUSE LINUX Products GmbH
Research & Development
Re: Time for 1.3.3
Posted by Bojan Smojver <bo...@rexursive.com>.
On Fri, 2008-08-08 at 08:58 +1000, Bojan Smojver wrote:
> Latest patch for memcache leak is attached.
That's for 1.3.x. The trunk should be OK, because it relies on
pre_cleanup.
PS. If the list thinks that it is better to have
apr_reslist_cleanup_order_set() in 1.3.x as non-public API, then
obviously the same can be fixed with that + pre_cleanup.
--
Bojan
Re: Time for 1.3.3
Posted by Bojan Smojver <bo...@rexursive.com>.
On Fri, 2008-08-08 at 00:42 +0200, Peter Poeml wrote:
> I am a heavy user of both mod_dbd and apr_memcache, and I'm
> investigating an apr_memcache related memleak right now that I started
> getting with 1.3.0, so I will give this a good testing in the next few
> hours.
Latest patch for memcache leak is attached.
--
Bojan
Re: Time for 1.3.3
Posted by Peter Poeml <po...@suse.de>.
On Thu, Aug 07, 2008 at 03:08:14 -0500, William A. Rowe, Jr. wrote:
> Here's an offer, I'll tag and roll 24 hours from now unless someone tells me
> that the API remains broken w.r.t. reslist etc. Unless we hear it is now
> broken, we'll presume that 1.3.3 is entirely backwards compatible to 1.2.12.
>
> Bill
I am a heavy user of both mod_dbd and apr_memcache, and I'm
investigating an apr_memcache related memleak right now that I started
getting with 1.3.0, so I will give this a good testing in the next few
hours.
Peter
--
"WARNING: This bug is visible to non-employees. Please be respectful!"
SUSE LINUX Products GmbH
Research & Development
Re: Time for 1.3.3
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
> What obstacles are left between us and an 1.3.3 release of APR / APR-UTIL?
Here's an offer, I'll tag and roll 24 hours from now unless someone tells me
that the API remains broken w.r.t. reslist etc. Unless we hear it is now
broken, we'll presume that 1.3.3 is entirely backwards compatible to 1.2.12.
Bill