Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
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 neolo...@free.fr 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 or something similar. Installing autoconf from source really takes about 3 minutes. FWIW this was also documented in the devguide, as of: http://hg.python.org/devguide/rev/5432be4d4e1a though that description was then removed in: http://hg.python.org/devguide/rev/27be97280cf so maybe this could be restored. the python configure.ac doesn't use that internal and specific autoconf features, so it might be ok to live with the diffs. I didn't see any issues using the system supplied autoconf with any python version on not that recent distro releases. However the effort to use a specific autoconf version for each branch should be minimal (other projects do require this). Matthias ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
In article 20121016043352.ga21...@snakebite.org, Trent Nelson tr...@snakebite.org 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. (There are some fixes for the more esoteric UNIX platforms that Snakebite will benefit from. Also, I struggled to find a box with 2.68 even installed when I needed to regenerate configure this weekend; it seems all package management/ports have bumped to 2.69.) If there are no objections, can it be applied across the board? 2.7, 3.2, 3.3 and 3.x? I believe it is the case that we don't currently require a specific version of autoconf. autoconf is only run when making a committer makes a change to configure.ac et al and then it is run on the committer's machine. So whatever is checked in for those files reflects the version of autoconf that the committer used. -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Mon, 15 Oct 2012 23:18:04 -0700, Ned Deily n...@acm.org wrote: In article 20121016043352.ga21...@snakebite.org, Trent Nelson tr...@snakebite.org 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. (There are some fixes for the more esoteric UNIX platforms that Snakebite will benefit from. Also, I struggled to find a box with 2.68 even installed when I needed to regenerate configure this weekend; it seems all package management/ports have bumped to 2.69.) If there are no objections, can it be applied across the board? 2.7, 3.2, 3.3 and 3.x? I believe it is the case that we don't currently require a specific version of autoconf. autoconf is only run when making a committer makes a change to configure.ac et al and then it is run on the committer's machine. So whatever is checked in for those files reflects the version of autoconf that the committer used. 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 breaking the Python build, so we also need to test a new version before switching to it. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
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 n...@acm.org wrote: In article 20121016043352.ga21...@snakebite.org, Trent Nelson tr...@snakebite.org 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. (There are some fixes for the more esoteric UNIX platforms that Snakebite will benefit from. Also, I struggled to find a box with 2.68 even installed when I needed to regenerate configure this weekend; it seems all package management/ports have bumped to 2.69.) If there are no objections, can it be applied across the board? 2.7, 3.2, 3.3 and 3.x? I believe it is the case that we don't currently require a specific version of autoconf. autoconf is only run when making a committer makes a change to configure.ac et al and then it is run on the committer's machine. So whatever is checked in for those files reflects the version of autoconf that the committer used. 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. Indeed; the 2.68-2.69 bump results in a 746 line diff for configure. In the past we have had issues with a new autoconf version actually breaking the Python build, so we also need to test a new version before switching to it. If there are no objections in principle to the bump (i.e. nobody is aware of any existing 2.69 incompatibilities), my plan is to bump, then make sure all the build slaves and Snakebite machines work with the new version. If 2.69 introduces insurmountable build issues, I'll simply revert back to 2.68 (with some notes at the top of configure.ac mentioning the issues with 2.69). Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
In article 20121016071236.0792d250...@webabinitio.net, R. David Murray rdmur...@bitdance.com 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 versions. In the past we have had issues with a new autoconf version actually breaking the Python build, so we also need to test a new version before switching to it. Well, there was a test in the past for a specific version of autoconf but I believe that was removed. I see that the default branch configure.ac contains AC_PREREQ(2.65) but the most recently checked-in version of configure was generated with 2.68. I understand about the desirability of avoiding a lot of churn although it seems to me to not be a huge thing; build breaking is another matter, of course. If we are going to mandate a specific version again, that should be documented and checked for. -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
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 breaking the Python build, so we also need to test a new version before switching to it. 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. Charles ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, Oct 16, 2012 at 01:04:46AM -0700, Ned Deily wrote: In article 20121016071236.0792d250...@webabinitio.net, R. David Murray rdmur...@bitdance.com 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 versions. In the past we have had issues with a new autoconf version actually breaking the Python build, so we also need to test a new version before switching to it. Well, there was a test in the past for a specific version of autoconf but I believe that was removed. I see that the default branch configure.ac contains AC_PREREQ(2.65) but the most recently checked-in version of configure was generated with 2.68. That's a good point regarding AC_PREREQ. I think there's been a general unspoken rule to try and minimize 'configure' churn, which means using the same version of autoconf that the previous person used. I understand about the desirability of avoiding a lot of churn although it seems to me to not be a huge thing; I don't know, the churn is usually offensive enough to warrant using the same autoconf version. It's impossible to vet a configure.ac change if you're regenerating configure with a different version of autoconf. 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_PREREQ(2.68). I definitely like the idea of explicitly setting the version being used via AC_PREREQ, as this will prevent accidental version churn being checked in by a committer inadvertently. -- Ned Deily, n...@acm.org Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
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 versions. In the past we have had issues with a new autoconf version actually breaking the Python build, so we also need to test a new version before switching to it. 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. Autoconf is a special case though. Different versions of autoconf produce wildly different outputs for 'configure', making it impossible to vet configure.ac changes by reviewing the configure diff. It doesn't matter which OS or Mercurial version a developer uses as they don't implicitly affect any versioned resources; autoconf does. Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
Charles-François Natali neolo...@free.fr 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 or something similar. Installing autoconf from source really takes about 3 minutes. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
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 distributions have package managers, and in 2012 we're past the './configure make make install. It doesn't matter which OS or Mercurial version a developer uses as they don't implicitly affect any versioned resources; autoconf does. If you're worried about the noise in diff, it's never been a problem at least to me (just don't post a configure diff for review, the configure.ac is enough). If you're worried about runtime compatibility, then autoconf is not your only worry. Proper build also depends on the target shell, target toolchain (gcc, libc, etc). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
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 n...@acm.org wrote: In article 20121016043352.ga21...@snakebite.org, Trent Nelson tr...@snakebite.org 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. (There are some fixes for the more esoteric UNIX platforms that Snakebite will benefit from. Also, I struggled to find a box with 2.68 even installed when I needed to regenerate configure this weekend; it seems all package management/ports have bumped to 2.69.) If there are no objections, can it be applied across the board? 2.7, 3.2, 3.3 and 3.x? I believe it is the case that we don't currently require a specific version of autoconf. autoconf is only run when making a committer makes a change to configure.ac et al and then it is run on the committer's machine. So whatever is checked in for those files reflects the version of autoconf that the committer used. 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 breaking the Python build, so we also need to test a new version before switching to it. Just to put this in perspective, here's a change I made to configure.ac over the weekend as part of #15819: % hg diff configure.ac 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` +AC_SUBST(BUILDDIR) + AC_SUBST(HGVERSION) AC_SUBST(HGTAG) AC_SUBST(HGBRANCH) With the correct version of autoconf (2.68), this generates the following diff to configure: % hg diff configure diff -r 51ce9830d85a configure --- a/configure Sat Oct 13 11:58:23 2012 -0400 +++ b/configure Tue Oct 16 09:15:04 2012 + @@ -714,6 +714,7 @@ HGBRANCH HGTAG HGVERSION +BUILDDIR target_alias host_alias build_alias @@ -2719,6 +2720,9 @@ +BUILDDIR=`pwd` + + However, the 2.69 version of autoconf generates this monster of a configure diff: http://hydrogen.snakebite.net/~cpython/configure.diff As you can see, it's impossible to figure out what my configure.ac change was from that diff. Which is why I'm proposing we leverage AC_PREREQ to prevent inadvertent autoconf version churn. Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, 16 Oct 2012 05:05:23 -0400 Trent Nelson tr...@snakebite.org 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 file changes when different committers use different versions. In the past we have had issues with a new autoconf version actually breaking the Python build, so we also need to test a new version before switching to it. 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. Autoconf is a special case though. Different versions of autoconf produce wildly different outputs for 'configure', making it impossible to vet configure.ac changes by reviewing the configure diff. Isn't it enough to review the configure.ac diff? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
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 and Perl, and you may very well have a compatibility issue here. That's why most distributions have package managers, and in 2012 we're past the './configure make make install. If you're unable to get 2.69 (or whatever) installed for whatever reason, you can always just commit configure.ac and ask another committer to regenerate configure with the correct version. (In my case, I couldn't find a single Snakebite box that had 2.68 installed; out of 20-something hosts, everything had 2.69, which is partly why I'd like to bump to 2.69.) It doesn't matter which OS or Mercurial version a developer uses as they don't implicitly affect any versioned resources; autoconf does. If you're worried about the noise in diff, it's never been a problem at least to me (just don't post a configure diff for review, the configure.ac is enough). If you're worried about runtime compatibility, then autoconf is not your only worry. Proper build also depends on the target shell, target toolchain (gcc, libc, etc). Ignoring diff noise, what I'm suggesting is that we formalize the version used to build configure, as opposed to just accepting that configure was built with whatever arbitrary version of autoconf the last developer that modified configure.ac had installed. If you look at configure's history, we pretty much already follow this informally. Anyway, back to the original question: does anyone know of reasons we shouldn't bump to 2.69? Any known incompatibilities? Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
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_PREREQ(2.68). I definitely like the idea of explicitly setting the version being used via AC_PREREQ, as this will prevent accidental version churn being checked in by a committer inadvertently. Bear in mind that AC_PREREQ sets the minimum required version. It cannot be used to prevent from running newer autoconf in the future. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
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 autoconf autoconf | 2.61-4 | hardy | source, all autoconf | 2.65-3ubuntu1 | lucid | source, all autoconf | 2.67-2ubuntu1 | natty | source, all autoconf | 2.68-1ubuntu1 | oneiric | source, all autoconf | 2.68-1ubuntu2 | precise | source, all autoconf | 2.69-1ubuntu1 | quantal | source, all % rmadison -u debian autoconf autoconf | 2.67-2 | squeeze | source, all autoconf | 2.69-1 | wheezy | source, all autoconf | 2.69-1 | sid | source, all FWIW, precise is Ubuntu 12.04 LTS, so it carries Python 2.7 and 3.2. I think it would be fine to update the default branch (i.e. 3.4), but I'm not sure what benefit you gain from making this change to stable branches, and you could potentially cause build problems, which you may not find out about for a while, e.g. when 2.7.4 is released and all the distros go to update. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, Oct 16, 2012 at 11:27:24AM +0200, Antoine Pitrou wrote: On Tue, 16 Oct 2012 05:05:23 -0400 Trent Nelson tr...@snakebite.org 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 file changes when different committers use different versions. In the past we have had issues with a new autoconf version actually breaking the Python build, so we also need to test a new version before switching to it. 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. Autoconf is a special case though. Different versions of autoconf produce wildly different outputs for 'configure', making it impossible to vet configure.ac changes by reviewing the configure diff. Isn't it enough to review the configure.ac diff? That's the ideal but it's been wrong in the past and may possibly be wrong in the future as well. Anecdotally, in the Linux distribution I package for we have a conversation about whether we should apply patches to configure.ac and then run autoreconf (or equivalent) or include the patches to ocnfigure about once a year. Although the latter has been pretty stable for several autoconf version updates enough people have bad memories of those times when bumping autoconf revisions that there's always a vocal contingent who advocate shipping patches to the actual configure scripts (they're under the impression the package maintainer will actually audit the configure patch that autoconf generated to see if there's breakage that way). -Toshio pgpKtINQd1o1B.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
-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 problems building with 2.69 on Ubuntus older than 12.10, and Debians older than wheezy. % rmadison autoconf autoconf | 2.61-4 | hardy | source, all autoconf | 2.65-3ubuntu1 | lucid | source, all autoconf | 2.67-2ubuntu1 | natty | source, all autoconf | 2.68-1ubuntu1 | oneiric | source, all autoconf | 2.68-1ubuntu2 | precise | source, all autoconf | 2.69-1ubuntu1 | quantal | source, all % rmadison -u debian autoconf autoconf | 2.67-2 | squeeze | source, all autoconf | 2.69-1 | wheezy | source, all autoconf | 2.69-1 | sid | source, all FWIW, precise is Ubuntu 12.04 LTS, so it carries Python 2.7 and 3.2. I think it would be fine to update the default branch (i.e. 3.4), but I'm not sure what benefit you gain from making this change to stable branches, and you could potentially cause build problems, which you may not find out about for a while, e.g. when 2.7.4 is released and all the distros go to update. Agreed: this is really the same issue as bumping the VisualStudio version (or any other build tooling) inside a release line: too much potential for breakage for little gain. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB9eq8ACgkQ+gerLs4ltQ5gWQCcDDjMRWcUDagb6dhZCK+5pSVs dVIAoLH+S205plmi22RS0aBaF5GxnTmn =PrEy -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, Oct 16, 2012 at 11:18 AM, Tres Seaver tsea...@palladion.com 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'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 autoconf autoconf | 2.61-4 | hardy | source, all autoconf | 2.65-3ubuntu1 | lucid | source, all autoconf | 2.67-2ubuntu1 | natty | source, all autoconf | 2.68-1ubuntu1 | oneiric | source, all autoconf | 2.68-1ubuntu2 | precise | source, all autoconf | 2.69-1ubuntu1 | quantal | source, all % rmadison -u debian autoconf autoconf | 2.67-2 | squeeze | source, all autoconf | 2.69-1 | wheezy | source, all autoconf | 2.69-1 | sid | source, all FWIW, precise is Ubuntu 12.04 LTS, so it carries Python 2.7 and 3.2. I think it would be fine to update the default branch (i.e. 3.4), but I'm not sure what benefit you gain from making this change to stable branches, and you could potentially cause build problems, which you may not find out about for a while, e.g. when 2.7.4 is released and all the distros go to update. Agreed: this is really the same issue as bumping the VisualStudio version (or any other build tooling) inside a release line: too much potential for breakage for little gain. I think Barry's suggestion of updating default and leaving stable versions alone is a good one. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, Oct 16, 2012 at 08:23:00AM -0700, Brett Cannon wrote: On Tue, Oct 16, 2012 at 11:18 AM, Tres Seaver tsea...@palladion.com 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't bump to 2.69? A Any known incompatibilities? There will be problems building with 2.69 on Ubuntus older than 12.10, and Debians older than wheezy. % rmadison autoconf autoconf | A A 2.61-4 | A A A A hardy | source, all autoconf | 2.65-3ubuntu1 | A A A A lucid | source, all autoconf | 2.67-2ubuntu1 | A A A A natty | source, all autoconf | 2.68-1ubuntu1 | oneiric | source, all autoconf | 2.68-1ubuntu2 | A A A precise | source, all autoconf | 2.69-1ubuntu1 | A A A quantal | source, all % rmadison -u debian autoconf autoconf | 2.67-2 | squeeze | source, all autoconf | 2.69-1 | wheezy A | source, all autoconf | 2.69-1 | sid | source, all FWIW, precise is Ubuntu 12.04 LTS, so it carries Python 2.7 and 3.2. I think it would be fine to update the default branch (i.e. 3.4), but I'm not sure what benefit you gain from making this change to stable branches, and you could potentially cause build problems, which you may not find out about for a while, e.g. when 2.7.4 is released and all the distros go to update. Agreed: A this is really the same issue as bumping the VisualStudio version (or any other build tooling) inside a release line: A too much potential for breakage for little gain. I think Barry's suggestion of updating default and leaving stable versions alone is a good one.A Bumped 3.4 to 2.69 in 79763:74b95194ba86! Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, 2012-10-16 at 10:59 +0200, Stefan Krah wrote: Charles-François Natali neolo...@free.fr 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 or something similar. Installing autoconf from source really takes about 3 minutes. FWIW this was also documented in the devguide, as of: http://hg.python.org/devguide/rev/5432be4d4e1a though that description was then removed in: http://hg.python.org/devguide/rev/27be97280cff ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
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.org/software/autoconf/manual/autoconf-2.67/html_node/Preset-Output-Variables.html [SNIP] However, the 2.69 version of autoconf generates this monster of a configure diff: It is python project rule to keep generated files into repository. Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
