Bojan has merged this to 1.5.x/1.4.x/0.9.x and it'll be included in
1.4.6.
Thanks,
Daniel
Daniel Shahaf wrote on Mon, Feb 06, 2012 at 21:35:34 +0200:
> Bojan Smojver wrote on Mon, Feb 06, 2012 at 09:25:59 +1100:
> > On Sun, 2012-02-05 at 22:44 +0200, Daniel Shahaf wrote:
> > > > > It looks like
Tarballs/zipballs are at http://apr.apache.org/dev/dist/.
Various fixes in there, including hash randomisation, so give it a good
bashing.
Please give your +1/-1:
[ ] Release apr 1.4.6 as GA
PS. Please don't shoot to RM. First timer here... :-)
--
Bojan
On Tue, Feb 7, 2012 at 5:03 PM, Bojan Smojver wrote:
> On Tue, 2012-02-07 at 17:00 -0500, Jeff Trawick wrote:
>> Using the slightly patched tool(s) from Fedora seems like a pain for
>> others to reproduce exactly, whereas anyone can install autotools of
>> arbitrary versions on arbitrary non-Windo
On Tue, 2012-02-07 at 17:00 -0500, Jeff Trawick wrote:
> Using the slightly patched tool(s) from Fedora seems like a pain for
> others to reproduce exactly, whereas anyone can install autotools of
> arbitrary versions on arbitrary non-Windows machines in just a few
> minutes
So, you want me to ke
On Tue, Feb 7, 2012 at 4:54 PM, Bojan Smojver wrote:
> On Wed, 2012-02-08 at 08:02 +1100, Bojan Smojver wrote:
>> Libtool is slightly ahead: 2.4 v 2.2.4, but this is not where the
>> warnings are coming from (mostly).
>
> Actually, that is not correct. If I use 2.2.4 instead of built-in 2.4, I
> d
On Wed, 2012-02-08 at 08:02 +1100, Bojan Smojver wrote:
> Libtool is slightly ahead: 2.4 v 2.2.4, but this is not where the
> warnings are coming from (mostly).
Actually, that is not correct. If I use 2.2.4 instead of built-in 2.4, I
do get warnings and they do come from the files contributed by
On Tue, 2012-02-07 at 22:09 +0100, Rainer Jung wrote:
> There is no analogous change for apr-util, but as far as I remember
> those warnings did not exist for apr-util. Bojan please correct me if
> your experience is different.
I haven't tried apr-util spin yet, to be honest. We'll cross that b
On 07.02.2012 15:42, Graham Leggett wrote:
On 07 Feb 2012, at 3:45 PM, Jeff Trawick wrote:
I agree 100%. And hopefully we also agree that the order should be
1. make the fixes to our code
2. start using autoconf v2.68
Also, that's not a showstopper for a release, so an RM should use the
kno
On Tue, 2012-02-07 at 07:18 -0500, Jeff Trawick wrote:
> Please use clean builds of the the autoconf and libtool versions that
> Graham used. I hate seeing the autotools versions jumping around as
> different people handle T&R.
Just for the record, autoconf in F-16 is the same version as vanilla
On Tue, 2012-02-07 at 16:42 +0200, Graham Leggett wrote:
> Has anyone gone through the warnings to determine if the warnings
> should cause concern?
AFAICT, they are all benign warnings like this
AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body:
http://www.flameeyes.eu/autotools-mythbus
On 07 Feb 2012, at 5:05 PM, grady player wrote:
> libapr-1.a is build 64 bit, libapr_util-1.a is build 32 bit… that alone
> should count as a bug
In my case, my apr-util is 64 bit, same as apr:
Non-fat file: /tmp/httpd-trunk/lib/libaprutil-1.0.4.2.dylib is architecture:
x86_64
Regards,
Graham
libapr-1.a is build 64 bit, libapr_util-1.a is build 32 bit… that alone should
count as a bug
Grady Player
gra...@mozy.com
gpla...@vmware.com
801 548 1371
On Feb 7, 2012, at 8:02 AM, Graham Leggett wrote:
> On 07 Feb 2012, at 4:16 PM, grady player wrote:
>
>> The reason is that having the
On 07 Feb 2012, at 4:16 PM, grady player wrote:
> The reason is that having the concept of a fat binary (Universal was used to
> denote PPC/i386 fat) doesn't mean that everything compiled on a modern mac
> will contain both 32bit and 64 bit code…
> in fact apr-util build from configure && make a
On 07 Feb 2012, at 3:45 PM, Jeff Trawick wrote:
> I agree 100%. And hopefully we also agree that the order should be
>
> 1. make the fixes to our code
> 2. start using autoconf v2.68
>
> Also, that's not a showstopper for a release, so an RM should use the
> known-compatible version of autocon
after a little digging, it looks like the configure script is always adding a
-m32 to the CFLAGS section of the rules.mk file (line 44)
this would seem to be a bug to me, but I haven't yet figured out where it is
pulling this value from…
apr-1.4.5 seems to work fine
Grady Player
gra...@mozy.c
The reason is that having the concept of a fat binary (Universal was used to
denote PPC/i386 fat) doesn't mean that everything compiled on a modern mac will
contain both 32bit and 64 bit code…
in fact apr-util build from configure && make all && make install seems to
always build 32 bit code….
On Tue, Feb 7, 2012 at 8:26 AM, Graham Leggett wrote:
> On 07 Feb 2012, at 3:02 PM, Jeff Trawick wrote:
>
>> Then the use of autoconf 2.68 was premature. Move back to autoconf
>> 2.64, which should be fine. When it works cleanly with 2.68 we can
>> move forward again.
>
> According to http://ftp
On 07 Feb 2012, at 3:02 PM, Jeff Trawick wrote:
> Then the use of autoconf 2.68 was premature. Move back to autoconf
> 2.64, which should be fine. When it works cleanly with 2.68 we can
> move forward again.
According to http://ftp.gnu.org/gnu/autoconf/, autoconf v2.68 was released in
Septembe
On Tue, Feb 7, 2012 at 7:48 AM, Bojan Smojver wrote:
> --- Original message ---
>>
>> From: Jeff Trawick
>
>
>> Please use clean builds of the the autoconf and libtool versions that
>> Graham used. I hate seeing the autotools versions jumping around as
>> different people handle T&R.
>
>
--- Original message ---
From: Jeff Trawick
Please use clean builds of the the autoconf and libtool versions that
Graham used. I hate seeing the autotools versions jumping around as
different people handle T&R.
These "clean" tools don't look so clean on my box, so I think I'll hold
On Mon, Feb 6, 2012 at 9:55 PM, Bojan Smojver wrote:
> On Tue, 2012-02-07 at 11:31 +1100, Bojan Smojver wrote:
>> This is what I get when I run the release.sh script against 1.4.5 tag
>
> Interestingly, if I rework release.sh to use branches instead of tags
> and give it 1.4.x as an argument, ever
21 matches
Mail list logo
