On Feb 5, 2012, at 20:25 , Benjamin Peterson wrote:

2012/2/5 Ned Deily :

...

In article , georg.brandl wrote:

...

+Bugfix Releases +=============== + +- 3.2.1: released July 10, 2011 +- 3.2.2: released September 4, 2011 + +- 3.2.3: planned February 10-17, 2012

I would like to propose that we plan for 3.2.3 and 2.7.3 immediately after PyCon, so approximately March 17, if that works for all involved. My primary rationale is to allow time to address all of the OS X Xcode 4 issues for 10.6 and 10.7. They need to be fixed in 2.7.x, 3.2.x, and 3.3: right now it is not possible to build C extension modules in some sets of configurations. As I mentioned the other day, it is going to take a few more weeks to finish testing and generate all the fixes.

The reason 3.2.3 is so soon is the need to patch the hash collision attack.

I understand that but, to me, it makes no sense to send out truly broken releases. Besides, the hash collision attack is not exactly new either. Another few weeks can't make that much of a difference. -- Ned Deily nad@acm.org -- []

In article <20120205204551.Horde.NCdeYVNNcXdPLtxvnkzi1lA@webmail.df.eu>, martin@v.loewis.de wrote:

...

I understand that but, to me, it makes no sense to send out truly broken releases. Besides, the hash collision attack is not exactly new either. Another few weeks can't make that much of a difference.

Why would the release be truly broken? It surely can't be worse than the current releases (which apparently aren't truly broken, else there would have been no point in releasing them back then).

They were broken by the release of OS X 10.7 and Xcode 4.2 which were subsequent to the previous releases. None of the currently available python.org installers provide a fully working system on OS X 10.7, or on OS X 10.6 if the user has installed Xcode 4.2 for 10.6. -- Ned Deily, nad@acm.org

In article <4F32DF1E.40205@v.loewis.de>, "Martin v. Lowis" wrote:

Am 05.02.2012 21:34, schrieb Ned Deily:

...

In article <20120205204551.Horde.NCdeYVNNcXdPLtxvnkzi1lA@webmail.df.eu>, martin@v.loewis.de wrote:

...

...

I understand that but, to me, it makes no sense to send out truly broken releases. Besides, the hash collision attack is not exactly new either. Another few weeks can't make that much of a difference.

Why would the release be truly broken? It surely can't be worse than the current releases (which apparently aren't truly broken, else there would have been no point in releasing them back then).

They were broken by the release of OS X 10.7 and Xcode 4.2 which were subsequent to the previous releases. None of the currently available python.org installers provide a fully working system on OS X 10.7, or on OS X 10.6 if the user has installed Xcode 4.2 for 10.6.

In what way are the current releases not fully working? Are you referring to issues with building extension modules?

Yes

If it's that, I wouldn't call that "truly broken". Plus, the releases continue to work fine on older OS X releases.

If not "truly", then how about "seriously broken"? And it's not quite the case that the releases work fine on older OS X releases. The installers in question, the 64-/32-bit installer variants, work only on OS X 10.6 and above. If the user installed the optional Xcode 4.2 for 10.6, then they have the same problem with building extension modules as 10.7 users do.

So when you build a bug fix release, just build it with the same tool chain as the previous bug fix release, and all is fine.

I am not proposing changing the build tool chain for 3.2.x and 2.7.x bug fix releases. But, users not being able to build extension modules out of the box with the default vendor-supplied build tools as they have in the past is not a case of of all is fine, IMO. However, this may all be a moot point now as I've subsequently proposed a patch to Distutils to smooth over the problem by checking for the case of gcc-4.2 being required but not available and, if so, automatically substituting clang instead. (http://bugs.python.org/issue13590) This trades off a certain risk of using clang for extension modules against the 100% certainty of users being unable to build extension modules. -- Ned Deily, nad@acm.org

In article <4F32DF1E.40205@v.loewis.de>, "Martin v. Lowis" wrote:

Am 05.02.2012 21:34, schrieb Ned Deily:

...

In article <20120205204551.Horde.NCdeYVNNcXdPLtxvnkzi1lA@webmail.df.eu>, martin@v.loewis.de wrote:

...

...

I understand that but, to me, it makes no sense to send out truly broken releases. Besides, the hash collision attack is not exactly new either. Another few weeks can't make that much of a difference.

Why would the release be truly broken? It surely can't be worse than the current releases (which apparently aren't truly broken, else there would have been no point in releasing them back then).

They were broken by the release of OS X 10.7 and Xcode 4.2 which were subsequent to the previous releases. None of the currently available python.org installers provide a fully working system on OS X 10.7, or on OS X 10.6 if the user has installed Xcode 4.2 for 10.6.

In what way are the current releases not fully working? Are you referring to issues with building extension modules?

One problem I've run into is that the 64-bit Mac python 2.7 does not work properly with ActiveState Tcl/Tk. One symptom is to build matplotlib. The results fail -- both versions of Tcl/Tk somehow get linked in. We have had similar problems with the 32-bit python.org python in the past, but recent builds have been fine. I believe the solution that worked for the 32-bit versions was to install ActiveState Tcl/Tk before making the distribution build. The results would work fine with Apple's Tcl/Tk or with ActiveState Tcl/Tk. I don't know if the same solution would work for 64-bit python. I don't know of any issues with the 32-bit build of Python 2.7. I've not tried the Python 3 builds. -- Russell

In article , Ned Deily wrote:

In article , "Russell E. Owen" wrote:

...

One problem I've run into is that the 64-bit Mac python 2.7 does not work properly with ActiveState Tcl/Tk. One symptom is to build matplotlib. The results fail -- both versions of Tcl/Tk somehow get linked in.

The 64-bit OS X installer is built on and tested on systems with A/S Tcl/Tk 8.5.x and we explicitly recommend its use when possible.

http://www.python.org/download/mac/tcltk/

Please open a python bug for this and any other issues you know of regarding the use with current A/S Tcl/Tk 8.5.x with current 2.7.x or 3.2.x installers on OS X 10.6 or 10.7.

Yes. I apologize. See the discussion in the Mac python mailing list (I replied to your email there). I was trying to build a matplotlib binary installer and ran into problems. I don't know where the problem comes from, and it may well not have anything to do with the python build. -- Russell

In article , Nick Coghlan wrote:

Because Apple wasn't publishing versions of gcc-llvm that miscompile Python when those releases were made.

More importantly, Apple removed gcc-4.2 with the current versions of Xcode 4 and the Pythons installed by our current installers require gcc-4.2 to build extension modules. That will be changed but the situation is much more complex than when the previous set of releases went out.

(However, that's just a clarification of what changed to break the Mac OS X builds, I don't think it's a reason to hold up the hash security fix, even if it means spinning 3.2.4 not long after PyCon to sort out the XCode build problems).

I don't think it is a service to any of our users to hurry out two releases with minimal testing and with the knowledge that a major platform is crippled and with the expectation that another set of releases will be issued within 4 to 6 weeks, all just because of a fairly obscure problem that has been around for years (even if not publicized). Releases add a lot of work and risk for everyone in the Python chain, especially distributors of Python and end-users. That's just my take on it, of course. I can live with either option. -- Ned Deily, nad@acm.org

Am 06.02.2012 00:01, schrieb Barry Warsaw:

On Feb 05, 2012, at 02:25 PM, Benjamin Peterson wrote:

...

The reason 3.2.3 is so soon is the need to patch the hash collision attack.

Also remember that we are coordinating releases between several versions of Python for this issue, some of which are in security-only mode. The RMs of the active stable branches agree it's best to get these coordinated security releases out as soon as possible.

Well, one way to do it would be to release a rc now-ish, giving the community time to test it, and to already use it productively in critical cases, and release the final with the OSX fixes after/at PyCon. Georg