Issue 11715: building Python from source on multiarch Debian/Ubuntu
Ubuntu 11.04 added support for multiarch libraries: https://wiki.ubuntu.com/MultiarchSpec http://wiki.debian.org/ReleaseGoals/MultiArch At the moment, I don't care about issue 1294959 which I think addresses building multiarch flavors of Python: http://bugs.python.org/issue1294959 I have a much more short-term concern, which is being able to build Python from source *on* a multiarch Debian/Ubuntu: http://bugs.python.org/issue11715 The problem is that without this patch (or something like it), several of the extension modules do not build because setup.py does not search the directories in which the third party .so files live. The patch in the tracker is fairly straightforward and should be robust enough for platforms without dpkg-architecture(1). It's adapted from the patch in the Ubuntu source package. I would like to apply this patch (or its moral equivalent) to all active, affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3, as soon as possible. Without this, it will be very difficult for anyone on future Ubuntu or Debian releases to build Python. Since it's not a new feature, but just a minor fix to the build process, I think it should be okay to back port. Please comment here or in the tracker for issue 11715. Cheers, -Barry
I would like to apply this patch (or its moral equivalent) to all active, affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3, as soon as possible. Without this, it will be very difficult for anyone on future Ubuntu or Debian releases to build Python. Since it's not a new feature, but just a minor fix to the build process, I think it should be okay to back port.
If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable. Regards
On Fri, Apr 1, 2011 at 3:35 AM, Éric Araujo <merwok@netwok.org> wrote:
If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable.
Actual build fixes may be acceptable, if they're needed to allow people to build from a version control checkout or from source (since they need to be able to do that in order to apply security patches). However, the combination of "running on Ubuntu 11.04+" and "need to build security patched version of old Python" seems unlikely. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Apr 01, 2011, at 08:37 AM, Nick Coghlan wrote:
On Fri, Apr 1, 2011 at 3:35 AM, Éric Araujo <merwok@netwok.org> wrote:
If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable.
Actual build fixes may be acceptable, if they're needed to allow people to build from a version control checkout or from source (since they need to be able to do that in order to apply security patches).
However, the combination of "running on Ubuntu 11.04+" and "need to build security patched version of old Python" seems unlikely.
I'll just plead as RM for 2.6 that it's not as unlikely as it seems :). I'm happy to defer to MvL on its (non) applicability to 2.5. Cheers, -Barry
Am 31.03.2011 19:35, schrieb Éric Araujo:
I would like to apply this patch (or its moral equivalent) to all active, affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3, as soon as possible. Without this, it will be very difficult for anyone on future Ubuntu or Debian releases to build Python. Since it's not a new feature, but just a minor fix to the build process, I think it should be okay to back port.
If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable.
I wouldn't say doc fixes are not acceptable, but they are rather pointless since there won't be any more online docs or released docs for those versions. Georg
On Fri, 2011-04-01 at 08:37 +1000, Nick Coghlan wrote:
On Fri, Apr 1, 2011 at 3:35 AM, Éric Araujo <merwok@netwok.org> wrote:
If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable.
Actual build fixes may be acceptable, if they're needed to allow people to build from a version control checkout or from source (since they need to be able to do that in order to apply security patches).
However, the combination of "running on Ubuntu 11.04+" and "need to build security patched version of old Python" seems unlikely.
I disagree. FWIW - I maintain legacy code for python2.4, and 2.5 (mainly 2.5). I've reviewed upgrading this code to run on 2.7 - and it's too much work to do in the near future. I develop on Ubuntu (and will probably update to 11.04 in a few months) - so this will directly affect me. I'm fairly sure that others will be in the same situation. Even if their servers won't run ubuntu 11.04+ (or something with the same library paths), their development environments will. As a result, I'm very much +1 on integrating this patch to previous versions. Tim Wintle
On 01/04/2011 11:46, Georg Brandl wrote:
Am 31.03.2011 19:35, schrieb Éric Araujo:
I would like to apply this patch (or its moral equivalent) to all active, affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3, as soon as possible. Without this, it will be very difficult for anyone on future Ubuntu or Debian releases to build Python. Since it's not a new feature, but just a minor fix to the build process, I think it should be okay to back port. If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable. I wouldn't say doc fixes are not acceptable, but they are rather pointless since there won't be any more online docs or released docs for those versions. In the case that docs are wrong for unmaintained (but still used) versions of Python, is there any reason other than policy not to fix and update online docs?
All the best, Michael
Georg
_______________________________________________ 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/fuzzyman%40voidspace.org.u...
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On 4/1/2011 6:46 AM, Georg Brandl wrote:
Am 31.03.2011 19:35, schrieb Éric Araujo:
I would like to apply this patch (or its moral equivalent) to all active, affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3, as soon as possible. Without this, it will be very difficult for anyone on future Ubuntu or Debian releases to build Python. Since it's not a new feature, but just a minor fix to the build process, I think it should be okay to back port.
If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable.
I wouldn't say doc fixes are not acceptable, but they are rather pointless since there won't be any more online docs or released docs for those versions.
And I don't see a problem with build fixes. It's not like we're adding language features. If it makes someone's life easier, then what's the harm? Eric.
On Fri, 01 Apr 2011 07:57:53 -0400 Eric Smith <eric@trueblade.com> wrote:
On 4/1/2011 6:46 AM, Georg Brandl wrote:
Am 31.03.2011 19:35, schrieb Éric Araujo:
I would like to apply this patch (or its moral equivalent) to all active, affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3, as soon as possible. Without this, it will be very difficult for anyone on future Ubuntu or Debian releases to build Python. Since it's not a new feature, but just a minor fix to the build process, I think it should be okay to back port.
If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable.
I wouldn't say doc fixes are not acceptable, but they are rather pointless since there won't be any more online docs or released docs for those versions.
And I don't see a problem with build fixes. It's not like we're adding language features. If it makes someone's life easier, then what's the harm?
Well, how is this different from bug fixes? The policy is that we don't do bug fixes in security branches. We could change it of course, but introducing special cases through a weird interpretation of the rule sounds like a recipe for confusion, theirs and ours. (and, no, I don't think building an old Python on a new Debian/Ubuntu system is anymore important than other kinds of bug or build fixes; let's stop implying that Ubuntu is the dominant OS out there, because it's really not) Regards Antoine.
On 01/04/2011 13:07, Antoine Pitrou wrote:
On 4/1/2011 6:46 AM, Georg Brandl wrote:
Am 31.03.2011 19:35, schrieb Éric Araujo:
I would like to apply this patch (or its moral equivalent) to all active, affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3, as soon as possible. Without this, it will be very difficult for anyone on future Ubuntu or Debian releases to build Python. Since it's not a new feature, but just a minor fix to the build process, I think it should be okay to back port. If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable. I wouldn't say doc fixes are not acceptable, but they are rather pointless since there won't be any more online docs or released docs for those versions. And I don't see a problem with build fixes. It's not like we're adding language features. If it makes someone's life easier, then what's the harm? Well, how is this different from bug fixes? The policy is that we don't do bug fixes in security branches. We could change it of course, but introducing special cases through a weird interpretation of the rule sounds like a recipe for confusion,
On Fri, 01 Apr 2011 07:57:53 -0400 Eric Smith<eric@trueblade.com> wrote: theirs and ours. Possibly. But online docs fixes feels like a very particular special case that isn't hard to understand or likely to cause confusion.
All the best, Michael
(and, no, I don't think building an old Python on a new Debian/Ubuntu system is anymore important than other kinds of bug or build fixes; let's stop implying that Ubuntu is the dominant OS out there, because it's really not)
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/fuzzyman%40voidspace.org.u...
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
Am 01.04.2011 13:57, schrieb Michael Foord:
On 01/04/2011 11:46, Georg Brandl wrote:
Am 31.03.2011 19:35, schrieb Éric Araujo:
I would like to apply this patch (or its moral equivalent) to all active, affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3..3, as soon as possible. Without this, it will be very difficult for anyone on future Ubuntu or Debian releases to build Python. Since it's not a new feature, but just a minor fix to the build process, I think it should be okay to back port. If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable. I wouldn't say doc fixes are not acceptable, but they are rather pointless since there won't be any more online docs or released docs for those versions. In the case that docs are wrong for unmaintained (but still used) versions of Python, is there any reason other than policy not to fix and update online docs?
I think I was unclear: I'm not advocating doing doc fixes in security-only branches; I'm just explaining why it wouldn't even make sense to do these fixes. Let's not make life harder for the RMs of security-only branches... Georg
On 01/04/2011 13:32, Georg Brandl wrote:
Am 01.04.2011 13:57, schrieb Michael Foord:
On 01/04/2011 11:46, Georg Brandl wrote:
Am 31.03.2011 19:35, schrieb Éric Araujo:
I would like to apply this patch (or its moral equivalent) to all active, affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3..3, as soon as possible. Without this, it will be very difficult for anyone on future Ubuntu or Debian releases to build Python. Since it's not a new feature, but just a minor fix to the build process, I think it should be okay to back port. If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable. I wouldn't say doc fixes are not acceptable, but they are rather pointless since there won't be any more online docs or released docs for those versions. In the case that docs are wrong for unmaintained (but still used) versions of Python, is there any reason other than policy not to fix and update online docs? I think I was unclear: I'm not advocating doing doc fixes in security-only branches; I'm just explaining why it wouldn't even make sense to do these fixes.
I understood. I was suggesting we modify to allow doc changes that fix errors and push updated docs *online* (not do fresh releases) and asking why not do that (other than policy)? I don't see any advantage in leaving erroneous docs online even if we aren't going to do any new releases. Michael
Let's not make life harder for the RMs of security-only branches...
Georg
_______________________________________________ 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/fuzzyman%40voidspace.org.u...
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
I don't see any advantage in leaving erroneous docs online even if we aren't going to do any new releases.
See thread starting at http://mail.python.org/pipermail/python-dev/2010-August/103263.html Regards
On Fri, 01 Apr 2011 13:37:42 +0100 Michael Foord <fuzzyman@voidspace.org.uk> wrote:
I think I was unclear: I'm not advocating doing doc fixes in security-only branches; I'm just explaining why it wouldn't even make sense to do these fixes.
I understood. I was suggesting we modify to allow doc changes that fix errors and push updated docs *online* (not do fresh releases) and asking why not do that (other than policy)?
Well, I think the tradeoff is simply: do you want to do more work? (or, given the same amount of work, do you think allocating your workforce to backporting doc fixes is worthwhile?) I'm sure that if enough people want to do such backports, it can happen. Regards Antoine.
On 01/04/2011 13:42, Éric Araujo wrote:
I don't see any advantage in leaving erroneous docs online even if we aren't going to do any new releases. See thread starting at http://mail.python.org/pipermail/python-dev/2010-August/103263.html As far as I can tell there was no clear decision there either. :-) (Other than no *need* to bother, which doesn't answer the question of what if developers *want* to fix errors in the docs - and I'm in favour of *permitting* but not requiring it.)
All the best, Michael Foord
Regards
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
As far as I can tell there was no clear decision there either. :-) Not my understanding: http://mail.python.org/pipermail/python-dev/2010-August/103351.html
Regards
On 01/04/2011 14:49, Éric Araujo wrote:
As far as I can tell there was no clear decision there either. :-) Not my understanding: http://mail.python.org/pipermail/python-dev/2010-August/103351.html
That was about whether the release manager should backport doc fixes from 2.7 to the 2.6 branch and the conclusion was "not to bother", which is very different from saying that individual developers *can't* apply doc fixes if *they want*. Of course if the release manager says *do not* (which is different from *we won't be bothering*) then that is their decision and should be honoured. All the best, Michael
Regards
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On Apr 01, 2011, at 02:07 PM, Antoine Pitrou wrote:
(and, no, I don't think building an old Python on a new Debian/Ubuntu system is anymore important than other kinds of bug or build fixes; let's stop implying that Ubuntu is the dominant OS out there, because it's really not)
For the record, I wouldn't object to build fixes required to continue to build Python on say Windows 7 after some security patch broke the build. Or Gentoo, or OS X. I think there's no harm in build system or doc fixes that will have no effect on functionality. The difference is that even the simplest bug fix can change behavior, but a build system fix or doc fix will not. I agree with the position that back porting such fixes should not be required but also aren't prohibited. -Barry
On Apr 01, 2011, at 03:07 PM, Michael Foord wrote:
That was about whether the release manager should backport doc fixes from 2.7 to the 2.6 branch and the conclusion was "not to bother", which is very different from saying that individual developers *can't* apply doc fixes if *they want*.
Of course if the release manager says *do not* (which is different from *we won't be bothering*) then that is their decision and should be honoured.
Yeah, I know what I said before but I really am still on the fence about non-behavior changing fixes. Both sides have valid positions, IMO. :/ But as before, I'll abide by consensus, if such a thing can be determined. Not applying the patch to 2.6 will make things harder for me if I ever have to do another 2.6 release, but not impossible. However, because of the hg forward porting policy, I would like to decide asap on how far back to port the fix. As I see it, the patch is uncontroversial for 3.3, 3.2, and 2.7. And it definitely will not be applied to 3.0. That leaves 2.5, 2.6, and 3.1. If you really care one way or the other, please register your vote in the tracker. http://bugs.python.org/issue11715 (Hey, tracker voting would be a cool GSoC project perhaps) -Barry
Am 01.04.2011 14:49, schrieb Antoine Pitrou:
On Fri, 01 Apr 2011 13:37:42 +0100 Michael Foord <fuzzyman@voidspace.org.uk> wrote:
I think I was unclear: I'm not advocating doing doc fixes in security-only branches; I'm just explaining why it wouldn't even make sense to do these fixes.
I understood. I was suggesting we modify to allow doc changes that fix errors and push updated docs *online* (not do fresh releases) and asking why not do that (other than policy)?
Well, I think the tradeoff is simply: do you want to do more work? (or, given the same amount of work, do you think allocating your workforce to backporting doc fixes is worthwhile?)
Absolutely. I don't want to maintain that infrastructure. Georg
On 4/1/2011 9:45 AM, Michael Foord wrote:
See thread starting at http://mail.python.org/pipermail/python-dev/2010-August/103263.html As far as I can tell there was no clear decision there either. :-)
I read it as deciding no doc fixes.
(Other than no *need* to bother, which doesn't answer the question of what if developers *want* to fix errors in the docs - and I'm in favour of *permitting* but not requiring it.)
I see three reasons not to backport doc fixes: 1. we have too few people and too little time to do all we can/should with current releases. 2. anyone wanting up-to-date 2.6 docs should really consult 2.7 docs which include 2.6, with differences carefully noted. It was suggested in the thread that older docs, such as 2.6, say so. The point we should advertise is that the 'x.y' docs are really the cumulative Python x docs. We do extra work to make them be that. (If nothing else, restarting the docs fresh will eventually be a reason for a Python4 release.) 3. sporadic updates to 2.6 docs will not benefits windows users or anyone else with a local copy at all; they will only deceptively benefit site visitors, which will still miss out on everything not backported. -- Terry Jan Reedy
On Fri, 1 Apr 2011 11:17:27 -0400 Barry Warsaw <barry@python.org> wrote:
Yeah, I know what I said before but I really am still on the fence about non-behavior changing fixes. Both sides have valid positions, IMO. :/
Well, how can you be sure it's non-behaviour changing? A bugfix can always introduce a regression.
However, because of the hg forward porting policy, I would like to decide asap on how far back to port the fix. As I see it, the patch is uncontroversial for 3.3, 3.2, and 2.7. And it definitely will not be applied to 3.0. That leaves 2.5, 2.6, and 3.1.
I think it's Martin who ultimately decides what goes into 2.5. He seemed quite conservative about it. Regards Antoine.
On Fri, 01 Apr 2011 17:39:59 +0200 Georg Brandl <g.brandl@gmx.net> wrote:
Am 01.04.2011 14:49, schrieb Antoine Pitrou:
On Fri, 01 Apr 2011 13:37:42 +0100 Michael Foord <fuzzyman@voidspace.org.uk> wrote:
I think I was unclear: I'm not advocating doing doc fixes in security-only branches; I'm just explaining why it wouldn't even make sense to do these fixes.
I understood. I was suggesting we modify to allow doc changes that fix errors and push updated docs *online* (not do fresh releases) and asking why not do that (other than policy)?
Well, I think the tradeoff is simply: do you want to do more work? (or, given the same amount of work, do you think allocating your workforce to backporting doc fixes is worthwhile?)
Absolutely. I don't want to maintain that infrastructure.
But perhaps Michael would like to maintain it? He could be given an account on dinsdale if he wants to. Regards Antoine.
On Sat, Apr 2, 2011 at 2:31 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Fri, 01 Apr 2011 17:39:59 +0200 Georg Brandl <g.brandl@gmx.net> wrote:
Am 01.04.2011 14:49, schrieb Antoine Pitrou:
Well, I think the tradeoff is simply: do you want to do more work? (or, given the same amount of work, do you think allocating your workforce to backporting doc fixes is worthwhile?)
Absolutely. I don't want to maintain that infrastructure.
But perhaps Michael would like to maintain it? He could be given an account on dinsdale if he wants to.
As Terry pointed out, better to point people to the 2.7 docs, and remind them to keep an eye out for "new in 2.7" or "changed in 2.7" if they're using 2.6. Really, the older versions should only be referenced if you're looking at an offline version, or you want information on a deprecated feature that doesn't exist in the latest version. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
FWIW - I maintain legacy code for python2.4, and 2.5 (mainly 2.5). [...] As a result, I'm very much +1 on integrating this patch to previous versions.
Updating 2.4 is clearly out of question; and I veto changing 2.5 in that respect.
I develop on Ubuntu (and will probably update to 11.04 in a few months) - so this will directly affect me.
I think it is really Ubuntu's fault, not Python's, that it fails to build. They fail to provide backwards compatibility. It also STM that they fail to comply to the FHS with that change... In any case, it's not that you can't build Python 2.4 anymore on Ubuntu 11.04. You just have to edit Modules/Setup (which *is* a standard build procedure) to point it to the right library paths and names.
Even if their servers won't run ubuntu 11.04+ (or something with the same library paths), their development environments will.
They can also patch the Python releases themselves, or use Ubuntu packages that someone else made for them (they can probably just install the old 2.4 packages just fine). Regards, Martin
I wouldn't say doc fixes are not acceptable, but they are rather pointless since there won't be any more online docs or released docs for those versions.
That's the reason I don't want to see the in the tree, though - if people commit something, they expect to see it released at some point. So by refusing these changes, I hope to reduce the frustration for not getting them released. Regards, Martin
I understood. I was suggesting we modify to allow doc changes that fix errors and push updated docs *online* (not do fresh releases) and asking why not do that (other than policy)?
It's too much effort in the release process. I don't actually remember anymore how to do 2.5 documentation releases. Regards, Martin
And I don't see a problem with build fixes. It's not like we're adding language features. If it makes someone's life easier, then what's the harm?
It's extra work with no volunteer doing it. Regards, Martin
On 4/1/2011 3:52 PM, "Martin v. Löwis" wrote:
And I don't see a problem with build fixes. It's not like we're adding language features. If it makes someone's life easier, then what's the harm?
It's extra work with no volunteer doing it.
I understood Barry was volunteering. Certainly if no one is motivated to do the work, it won't get done. Eric.
Am 01.04.2011 17:03, schrieb Barry Warsaw:
I think there's no harm in build system or doc fixes that will have no effect on functionality.
I do believe that the build system changes can actually break things. The first version of your patch produced additional output on stderr, which may cause breakage on build infrastructures that filter the build output (and, say, suddenly start sending cron email messages, every fifteen minutes). Your current change creates the temp build directories if they aren't there. This may cause breakage on systems that create them themselves at some point, and then fail because the directories are already there. The change can also break build systems that patch setup.py, and now fail since the patch doesn't apply anymore. *Any* change to behavior can potentially break something. In a security-only release, the only acceptable tradeoff to this breakage is that a security concern is resolved in return for the breakage. Regards, Martin
Am 01.04.2011 21:54, schrieb Eric Smith:
On 4/1/2011 3:52 PM, "Martin v. Löwis" wrote:
And I don't see a problem with build fixes. It's not like we're adding language features. If it makes someone's life easier, then what's the harm?
It's extra work with no volunteer doing it.
I understood Barry was volunteering. Certainly if no one is motivated to do the work, it won't get done.
Ah, I somehow misread that you were talking about documentation changes (where Barry didn't volunteer to produce the documentation set for an upcoming 2.5 release - but for the change at hand, it wouldn't be necessary, either). Wrt. the build changes, I think they can actually break stuff, and therefore shouldn't be applied - see my other message. Regards, Martin
Am 01.04.2011 18:31, schrieb Antoine Pitrou:
On Fri, 01 Apr 2011 17:39:59 +0200 Georg Brandl <g.brandl@gmx.net> wrote:
Am 01.04.2011 14:49, schrieb Antoine Pitrou:
On Fri, 01 Apr 2011 13:37:42 +0100 Michael Foord <fuzzyman@voidspace.org.uk> wrote:
I think I was unclear: I'm not advocating doing doc fixes in security-only branches; I'm just explaining why it wouldn't even make sense to do these fixes.
I understood. I was suggesting we modify to allow doc changes that fix errors and push updated docs *online* (not do fresh releases) and asking why not do that (other than policy)?
Well, I think the tradeoff is simply: do you want to do more work? (or, given the same amount of work, do you think allocating your workforce to backporting doc fixes is worthwhile?)
Absolutely. I don't want to maintain that infrastructure.
But perhaps Michael would like to maintain it? He could be given an account on dinsdale if he wants to.
I seriously doubt that Michael would like to resurrect the old tex2html toolchain, and personally I also think that there are much better things he can do with his volunteer time... Georg
On Apr 01, 2011, at 09:47 PM, Martin v. Löwis wrote:
FWIW - I maintain legacy code for python2.4, and 2.5 (mainly 2.5). [...] As a result, I'm very much +1 on integrating this patch to previous versions.
Updating 2.4 is clearly out of question; and I veto changing 2.5 in that respect.
Fair enough. I respect your decision for 2.5.
I develop on Ubuntu (and will probably update to 11.04 in a few months) - so this will directly affect me.
I think it is really Ubuntu's fault, not Python's, that it fails to build. They fail to provide backwards compatibility. It also STM that they fail to comply to the FHS with that change...
When I saw this change happen, I did let out a little groan knowing what kind of resistance I'd likely encounter in python-dev. ;)
In any case, it's not that you can't build Python 2.4 anymore on Ubuntu 11.04. You just have to edit Modules/Setup (which *is* a standard build procedure) to point it to the right library paths and names.
Yes, but it's something I'd prefer not to do when cutting a release, because that's also error prone and could mask problems that users would have. But I do agree that we've ruled out any future full releases of Python 2.6, so the kind of testing I would normally go through before a release will not be necessary.
Even if their servers won't run ubuntu 11.04+ (or something with the same library paths), their development environments will.
They can also patch the Python releases themselves, or use Ubuntu packages that someone else made for them (they can probably just install the old 2.4 packages just fine).
The Python 2.6, 2.7, and 3.2 packages in Ubuntu 11.04 already have essentially the same patch that I posted, so folks using Python 2.6 from the operating system will not have a problem. Without this patch in our repository, folks building Python 2.6 from source will have to be aware of it. Since it's easy enough to back port the patch to 2.6 later should it be necessary, I leave it alone. I think we're still due one last bug fix release of Python 3.1, right? So that leaves applying this patch to 2.7, and 3.1 through 3.3. -Barry
Even if their servers won't run ubuntu 11.04+ (or something with the same library paths), their development environments will.
They can also patch the Python releases themselves, or use Ubuntu packages that someone else made for them (they can probably just install the old 2.4 packages just fine).
The Python 2.6, 2.7, and 3.2 packages in Ubuntu 11.04 already have essentially the same patch that I posted, so folks using Python 2.6 from the operating system will not have a problem. Without this patch in our repository, folks building Python 2.6 from source will have to be aware of it.
So let them use Python 2.6 from Ubuntu. Case closed! cheers Antoine.
Antoine Pitrou <solipsis@pitrou.net> wrote:
Even if their servers won't run ubuntu 11.04+ (or something with the same library paths), their development environments will.
They can also patch the Python releases themselves, or use Ubuntu packages that someone else made for them (they can probably just install the old 2.4 packages just fine).
The Python 2.6, 2.7, and 3.2 packages in Ubuntu 11.04 already have essentially the same patch that I posted, so folks using Python 2.6 from the operating system will not have a problem. Without this patch in our repository, folks building Python 2.6 from source will have to be aware of it.
So let them use Python 2.6 from Ubuntu. Case closed!
It isn't that simple. For example, I have automated scripts that test cdecimal against decimal.py for *every* release from r25 to r32. This is also the reason why I was unhappy that r25 did not build from Mercurial initially. There has been a lot of churn lately for module authors, starting with __pycache__, cpython-32m.so suffixes and ending in the mercurial transition. In this case, it's clearly Ubuntu who is going to break things. Still, the proposed patch could make life a lot easier for many people. Stefan Krah
On Apr 02, 2011, at 10:55 AM, Stefan Krah wrote:
In this case, it's clearly Ubuntu who is going to break things. Still, the proposed patch could make life a lot easier for many people.
I'd be more concerned about adding some Debian/Ubuntu special code to setup.py if it wasn't already a rats nest of specialization. $ grep darwin setup.py | wc -l 41 Not to mention the checks for osf1, unixware7, and openunix8 (!). It's a little ugly trying to run dpkg-architecture on every platform, but I'm not sure anything better can be done, and of course it only needs to run it once. I'm going to apply the patch to Python 2.7, 3.1, 3.2, and 3.3 tomorrow. Cheers, -Barry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/04/11 00:37, Nick Coghlan wrote:
However, the combination of "running on Ubuntu 11.04+" and "need to build security patched version of old Python" seems unlikely.
Well, I, for one, have Python 2.3, 2.4, 2.5, 2.6, 2.7, 3.1 and 3.2 installed in my machine (Ubuntu 10.04) because I need to support code spanning such a range of python versions. I remember that compiling 2.3 or 2.4 was a bit painful. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTbTqSJlgi5GaxT1NAQJdBwP/fVcqmac2gF/rPLYJvrwRKC7JqlmogRuQ h9Wp97Ihl430aeESjIuzLPCdfBxEWj14f6bP2GHOanncOXaNOLisA2Oktl5I92Dc Iw0lWPjWuEuDb1zkvALFB312Ecu0icBSCtScVRHHTeppC+ucpzuu/+eNXN+tCJ31 eWlNQcZR1qQ= =oQ1k -----END PGP SIGNATURE-----
participants (12)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Eric Smith -
Georg Brandl -
Jesus Cea -
Michael Foord -
Nick Coghlan -
Stefan Krah -
Terry Reedy -
Tim Wintle -
Éric Araujo