Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-17 Thread Matthias Klose
On 16.10.2012 17:58, David Malcolm wrote: > On Tue, 2012-10-16 at 10:59 +0200, Stefan Krah wrote: >> Charles-François Natali wrote: >>> Well, so I guess all committers will have to use the same >>> Linux/FreeBSD/whatever distribution then? >>> AFAICT there's no requirement regarding the mercurial

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Roumen Petrov
Trent Nelson wrote: [SNIP] diff -r 51ce9830d85a configure.ac --- a/configure.ac Sat Oct 13 11:58:23 2012 -0400 +++ b/configure.ac Tue Oct 16 09:12:56 2012 + @@ -9,6 +9,9 @@ AC_INIT(python, PYTHON_VERSION, http://bugs.python.org/) +BUILDDIR="`pwd`" ^ http://www.gnu.

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread David Malcolm
On Tue, 2012-10-16 at 10:59 +0200, Stefan Krah wrote: > Charles-François Natali wrote: > > Well, so I guess all committers will have to use the same > > Linux/FreeBSD/whatever distribution then? > > AFAICT there's no requirement regarding the mercurial version used by > > committers either. > > I

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Trent Nelson
On Tue, Oct 16, 2012 at 08:23:00AM -0700, Brett Cannon wrote: >On Tue, Oct 16, 2012 at 11:18 AM, Tres Seaver >wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > On 10/16/2012 09:47 AM, Barry Warsaw wrote: > > On Oct 16, 2012, at 05:32 AM, Trent Nelson wrote:

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Brett Cannon
On Tue, Oct 16, 2012 at 11:18 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/16/2012 09:47 AM, Barry Warsaw wrote: > > On Oct 16, 2012, at 05:32 AM, Trent Nelson wrote: > > > >> Anyway, back to the original question: does anyone know of reasons > >> we shouldn'

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/16/2012 09:47 AM, Barry Warsaw wrote: > On Oct 16, 2012, at 05:32 AM, Trent Nelson wrote: > >> Anyway, back to the original question: does anyone know of reasons >> we shouldn't bump to 2.69? Any known incompatibilities? > > There will be pro

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Toshio Kuratomi
On Tue, Oct 16, 2012 at 11:27:24AM +0200, Antoine Pitrou wrote: > On Tue, 16 Oct 2012 05:05:23 -0400 > Trent Nelson wrote: > > On Tue, Oct 16, 2012 at 01:43:37AM -0700, Charles-François Natali wrote: > > > > My understanding is that we use a specific version of autoconf. > > > > The reason is that

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Barry Warsaw
On Oct 16, 2012, at 05:32 AM, Trent Nelson wrote: > Anyway, back to the original question: does anyone know of reasons > we shouldn't bump to 2.69? Any known incompatibilities? There will be problems building with 2.69 on Ubuntus older than 12.10, and Debians older than wheezy. % rmadison autoc

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Petri Lehtinen
Trent Nelson wrote: > > build breaking is another matter, of course. If we are > > going to mandate a specific version again, that should be documented and > > checked for. > > My preference: bump to 2.69 and set AC_PREREQ(2.69). If 2.69 proves > unworkable, revert back to 2.68 and AC_PRE

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Trent Nelson
On Tue, Oct 16, 2012 at 02:17:35AM -0700, Charles-François Natali wrote: > > It should be sufficient to install autoconf-x.y into /home/user/bin or > > something similar. Installing autoconf from source really takes about > > 3 minutes. > > Well, maybe, maybe not. > autoconf depends on a least m4

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Antoine Pitrou
On Tue, 16 Oct 2012 05:05:23 -0400 Trent Nelson wrote: > On Tue, Oct 16, 2012 at 01:43:37AM -0700, Charles-François Natali wrote: > > > My understanding is that we use a specific version of autoconf. > > > The reason is that otherwise we end up with useless churn in the repo > > > as the generated

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Trent Nelson
On Tue, Oct 16, 2012 at 12:12:35AM -0700, R. David Murray wrote: > On Mon, 15 Oct 2012 23:18:04 -0700, Ned Deily wrote: > > In article <20121016043352.ga21...@snakebite.org>, > > Trent Nelson wrote: > > > Any objections to regenerating configure with autoconf 2.69? The > > > current ver

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Charles-François Natali
> It should be sufficient to install autoconf-x.y into /home/user/bin or > something similar. Installing autoconf from source really takes about > 3 minutes. Well, maybe, maybe not. autoconf depends on a least m4 and Perl, and you may very well have a compatibility issue here. That's why most dist

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Stefan Krah
Charles-François Natali wrote: > Well, so I guess all committers will have to use the same > Linux/FreeBSD/whatever distribution then? > AFAICT there's no requirement regarding the mercurial version used by > committers either. It should be sufficient to install autoconf-x.y into /home/user/bin o

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Trent Nelson
On Tue, Oct 16, 2012 at 01:43:37AM -0700, Charles-François Natali wrote: > > My understanding is that we use a specific version of autoconf. > > The reason is that otherwise we end up with useless churn in the repo > > as the generated file changes when different committers use different > > versio

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Trent Nelson
On Tue, Oct 16, 2012 at 01:04:46AM -0700, Ned Deily wrote: > In article <20121016071236.0792d250...@webabinitio.net>, > "R. David Murray" wrote: > > My understanding is that we use a specific version of autoconf. > > The reason is that otherwise we end up with useless churn in the repo > > as the

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Charles-François Natali
> My understanding is that we use a specific version of autoconf. > The reason is that otherwise we end up with useless churn in the repo > as the generated file changes when different committers use different > versions. In the past we have had issues with a new autoconf version > actually breaki

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Ned Deily
In article <20121016071236.0792d250...@webabinitio.net>, "R. David Murray" wrote: > My understanding is that we use a specific version of autoconf. > The reason is that otherwise we end up with useless churn in the repo > as the generated file changes when different committers use different > ver

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread Trent Nelson
On Tue, Oct 16, 2012 at 12:12:35AM -0700, R. David Murray wrote: > On Mon, 15 Oct 2012 23:18:04 -0700, Ned Deily wrote: > > In article <20121016043352.ga21...@snakebite.org>, > > Trent Nelson wrote: > > > Any objections to regenerating configure with autoconf 2.69? The > > > current ver

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-16 Thread R. David Murray
On Mon, 15 Oct 2012 23:18:04 -0700, Ned Deily wrote: > In article <20121016043352.ga21...@snakebite.org>, > Trent Nelson wrote: > > Any objections to regenerating configure with autoconf 2.69? The > > current version is based off 2.68, which was release on the 22nd > > of September

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-15 Thread Ned Deily
In article <20121016043352.ga21...@snakebite.org>, Trent Nelson wrote: > Any objections to regenerating configure with autoconf 2.69? The > current version is based off 2.68, which was release on the 22nd > of September 2010. 2.69 was released on the 24th of April, 2012. > > (T

[Python-Dev] Bumping autoconf from 2.68 to 2.69

2012-10-15 Thread Trent Nelson
Any objections to regenerating configure with autoconf 2.69? The current version is based off 2.68, which was release on the 22nd of September 2010. 2.69 was released on the 24th of April, 2012. (There are some fixes for the more esoteric UNIX platforms that Snakebite will b