As noted, I already spent time creating a VM of CentOS5 with the required toolchain, so I'm good to go.
On Aug 21, 2014, at 1:26 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote: > On Thu, 21 Aug 2014 13:59:52 +0200 > Ruediger Pluem <rpl...@apache.org> wrote: > >> >> >> Jim Jagielski wrote: >>> I offered to RM but OtherBill said he'd do it; plus, last >>> time I did, I used more up-to-date versions of autoconf, et.al. >>> and OtherBill complained that for the 2.2 built, we should >>> continue to use the much older versions... >>> >>> FWIW, I still can't recall which old version numbers we >>> should be using for 2.2... :/ >> >> Digging through the archives reveals: >> >> On Tue, 12 Nov 2013 16:00:52 -0500 >> Jim Jagielski <j...@jagunet.com> wrote: >> >>> So what versions of autoconf and libtool should we >>> be baselining for 2.2.x? >> >> On Tue, 12 Nov 2013 11:56:39 -0600 >> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote: >> >>> Libtool 1.5.26 and autoconf 2.67 were used for 2.2.25 release; any >>> later 1.5 libtool or 2.6x series autoconf aught to work but you >>> would want to pre- buildconf and review any newer versions before >>> tagging. > > That about sums it up. Sorry, I am still drowning in my late father's > affairs for another 3-4 weeks, but will make time to do this in 2 hours > from now, sum up votes and move files Sun a.m. for a Mon a.m. release. > That saves anyone else from creating an older toolchain (even I never > use this one on the development branches). > > I see three patches to apply, if nobody beats me to it I'll merge them, > but dibs goes to the proposer. About Eric's comment, given the delay > we should pick up that patch, it can simply encourage us to get 2.4.11 > out in the reasonably near future. > > I'd love to see us pick up newer autoconf/libtool, preferably not on a > security release... perhaps we can come up with a bugfix release that > lets us let new conf scripts out into the wild for wider review? > > I was not waiting on the utf-8 services patch, but am looking forward to > some of our international windows users giving that patch a spin and > sounding in on the fix for international service names.
