Re: [Python-Dev] Impaired Usability of the Mercurial Source Viewer
On Fri, Apr 1, 2011 at 02:30, Antoine Pitrou wrote: > This is something you need to discuss with the Mercurial project. > See http://mercurial.selenic.com/bts/ and > http://mercurial.selenic.com/wiki/ContributingChanges There's a lot you can change by just starting a new set of templates (with Mercurial's templating language). I even wrote an extension that'll let you use Jinja for the templating, so it shouldn't be hard to make changes here -- changes like Raymond proposes most certainly don't require code changes inside Mercurial. Cheers, Dirkjan ___ 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] Impaired Usability of the Mercurial Source Viewer
Am 01.04.2011 03:44, schrieb Benjamin Peterson: > 2011/3/31 Raymond Hettinger : >> >> On Mar 31, 2011, at 6:28 PM, Victor Stinner wrote: >> >> Le 01/04/2011 01:15, Raymond Hettinger a écrit : >> >> The Hg source viewer needs to be tweaked to improve its usability. >> >> What we've got now is a step backwards from the previous svn viewer. >> >> Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for >> example, >> >> there are two issues. 1) the code cannot be cut-and-pasted because the >> >> line numbers are commingled with the source text. 2) the code is hard >> >> to read because of the alternating white and gray bars. >> >> You can use mirrors like: >> https://bitbucket.org/mirror/cpython/ >> >> On Bitbucket, line numbers are displayed, but you can copy/paste code >> without the line number. And the background is just white. For example: >> https://bitbucket.org/mirror/cpython/src/3558eecd84f0/Modules/faulthandler.c >> >> >> That's *way* better: >> https://bitbucket.org/mirror/cpython/src/3558eecd84f0/Lib/linecache.py >> Why can't we have that for our primary source viewer. > > Because it's closed source. There are of course other Mercurial-web frontends that are free. hgweb is just the first choice because it's included. (Just like Tkinter.) For example, I was recently pointed to RhodeCode (http://pypi.python.org/pypi/RhodeCode/), but I haven't had a closer look yet. 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/archive%40mail-archive.com
Re: [Python-Dev] Please revert autofolding of tracker edit form
Am 01.04.2011 06:02, schrieb Terry Reedy: > On 3/31/2011 8:26 PM, Antoine Pitrou wrote: >> On Thu, 31 Mar 2011 12:52:23 -0400 >> Terry Reedy wrote: >>> >>> Here is my proposal for a redesign based on an analysis of my usage ;-). >>> I have a 1600x1050 (or thereabouts), 20" (measured) diagonal, 17" across >>> screen. >>> >>> The left column has a 7/8" margin, 2 3/8" text area, and 1" gutter. >>> These could be shrunk to say, 1/4, 2, 1/4, saving 1 3/8". >>> The comment box is 8 1/2", message boxes are wider, but the extra width >>> is not used if one uses hard returns in the comment box. In any case, >>> the message boxes could be narrowed by 1 1/8". >>> This would allow a right column of 1/4+2+1/4". >> >> Let's say that by using non-metric units you have already lost me, > > My bad. Im science context I have always used S.I units, and wish U.S. > would switch. Just forgot here. Multiply everything by 2.4 for cm. Or by 2.54, if you're using SI cm :) 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/archive%40mail-archive.com
Re: [Python-Dev] devguide: Add a table of contents to the FAQ.
Am 01.04.2011 01:12, schrieb R. David Murray: > On Fri, 01 Apr 2011 08:29:29 +1000, Nick Coghlan wrote: >> On Fri, Apr 1, 2011 at 2:34 AM, R. David Murray wro= >> te: >> > I agree with this point. =A0The sidebar list of questions is effectively >> > useless. >> >> Indeed. If it's simple, I'd actually be inclined to reduce the depth >> of the sidebar in this case to only show the categories and not the >> individual questions. > > I believe that requires editing the sphinx page template and adding > a special case of some sort. Use :tocdepth: x at the top of the rst file. 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/archive%40mail-archive.com
Re: [Python-Dev] Issue 11715: building Python from source on multiarch Debian/Ubuntu
On Fri, 2011-04-01 at 08:37 +1000, Nick Coghlan wrote: > On Fri, Apr 1, 2011 at 3:35 AM, Éric Araujo 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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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.uk -- 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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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. ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
On Fri, 01 Apr 2011 07:57:53 -0400 Eric Smith 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. ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
On 01/04/2011 13:07, Antoine Pitrou wrote: On Fri, 01 Apr 2011 07:57:53 -0400 Eric Smith 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. 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.uk -- 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 ___ 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] [Python-checkins] cpython (3.2): Add links to make the math docs more usable.
>> There's a space missing here, and the link doesn't work. > It does for me. This may depend on the mail reader and whether it parses > the url out in spite of the missing space. Victor was talking about the rendered HTML, not his email client. :) Cheers ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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.uk -- 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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
> 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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
On Fri, 01 Apr 2011 13:37:42 +0100 Michael Foord 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. ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
> 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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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 signature.asc 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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 signature.asc 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
Am 01.04.2011 14:49, schrieb Antoine Pitrou: > On Fri, 01 Apr 2011 13:37:42 +0100 > Michael Foord 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 ___ 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] Impaired Usability of the Mercurial Source Viewer
On Fri, Apr 1, 2011 at 8:42 PM, Georg Brandl wrote: > There are of course other Mercurial-web frontends that are free. hgweb is > just > the first choice because it's included. (Just like Tkinter.) > > For example, I was recently pointed to RhodeCode > (http://pypi.python.org/pypi/RhodeCode/), but I haven't had a closer look yet. If you find one that will stay on the symbolic tip of a branch while browsing, instead of hard linking to the *current* tip the way hgweb does, that would be really nice :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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 ___ 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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-03-25 - 2011-04-01) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2733 ( -2) closed 20787 (+69) total 23520 (+67) Open issues with patches: 1167 Issues opened (49) == #11557: Increase coverage in logging module http://bugs.python.org/issue11557 reopened by r.david.murray #11674: list(obj), tuple(obj) swallow TypeError (in _PyObject_LengthHi http://bugs.python.org/issue11674 opened by Elvis.Pranskevichus #11676: imp.load_module and submodules - doc issue, or bug? http://bugs.python.org/issue11676 opened by Dave Peck #11677: make test has horrendous performance on an ecryptfs http://bugs.python.org/issue11677 opened by barry #11678: Add support for Arch Linux to platform.linux_distributions() http://bugs.python.org/issue11678 opened by anikom15 #11679: readline interferes with characters beginning with byte \xe9 http://bugs.python.org/issue11679 opened by takluyver #11681: -b option undocumented http://bugs.python.org/issue11681 opened by eric.araujo #11682: PEP 380 reference implementation for 3.3 http://bugs.python.org/issue11682 opened by ncoghlan #11683: unittest discover should recurse into packages which are alrea http://bugs.python.org/issue11683 opened by Calvin.Spealman #11684: (Maybe) Add email.parser.BytesHeaderParser http://bugs.python.org/issue11684 opened by sdaoden #11685: possible SQL injection into db APIs via table names... sqlite3 http://bugs.python.org/issue11685 opened by illume #11686: Update of some email/ __all__ lists http://bugs.python.org/issue11686 opened by sdaoden #11688: SQLite trace callback http://bugs.python.org/issue11688 opened by torsten #11689: sqlite: Incorrect unit test fails to detect failure http://bugs.python.org/issue11689 opened by torsten #11690: Devguide: Add "communication" FAQ http://bugs.python.org/issue11690 opened by ncoghlan #11691: sqlite3 Cursor.description doesn't set type_code http://bugs.python.org/issue11691 opened by wesclemens #11693: memory leak in email.generator.Generator().flatten() method http://bugs.python.org/issue11693 opened by Kaushik.Kannan #11694: xdrlib raises ConversionError in inconsistent way http://bugs.python.org/issue11694 opened by gruszczy #11695: Improve argparse usage/help customization http://bugs.python.org/issue11695 opened by bethard #11697: Unsigned type in mmap_move_method http://bugs.python.org/issue11697 opened by rmib #11698: Improve repr for structseq objects to show named, but unindexe http://bugs.python.org/issue11698 opened by rhettinger #11699: Documentation for get_option_group is wrong http://bugs.python.org/issue11699 opened by weeble #11700: mailbox.py proxy updates http://bugs.python.org/issue11700 opened by sdaoden #11701: email.parser.BytesParser() uses TextIOWrapper http://bugs.python.org/issue11701 opened by sdaoden #11702: dir on return value of msilib.OpenDatabase() crashes python http://bugs.python.org/issue11702 opened by markm #11703: Bug in python >= 2.7 with urllib2 fragment http://bugs.python.org/issue11703 opened by Ivan.Ivanenko #11704: functools.partial doesn't create bound methods http://bugs.python.org/issue11704 opened by alex #11705: sys.excepthook doesn't work in imported modules http://bugs.python.org/issue11705 opened by mikez302 #11707: Create C version of functools.cmp_to_key() http://bugs.python.org/issue11707 opened by rhettinger #11708: argparse: suggestion for formatting optional positional args http://bugs.python.org/issue11708 opened by pwil3058 #11709: help-method crashes if sys.stdin is None http://bugs.python.org/issue11709 opened by palm.kevin #11710: Landing pages in docs for standard library packages http://bugs.python.org/issue11710 opened by ncoghlan #11714: threading.Semaphore does not use try...finally http://bugs.python.org/issue11714 opened by glglgl #11715: Building Python on multiarch Debian and Ubuntu http://bugs.python.org/issue11715 opened by barry #11717: conflicting definition of ssize_t in pyconfig.h http://bugs.python.org/issue11717 opened by wrohdewald #11718: Teach IDLE's open-module command to find packages http://bugs.python.org/issue11718 opened by rhettinger #11719: test_msilib skip unexpected on non-Windows platforms http://bugs.python.org/issue11719 opened by nvawda #11722: mingw64 does not link when building extensions http://bugs.python.org/issue11722 opened by moog #11723: No proper support for mingw64 - patch to add http://bugs.python.org/issue11723 opened by moog #11726: linecache becomes specific to Python scripts in Python 3 http://bugs.python.org/issue11726 opened by haypo #11728: mbox parser incorrect behaviour http://bugs.python.org/issue11728 opened by wally1980 #11729: libffi assembler relocation check is not robust, fails with cl http://bugs.python.org/issue11
Re: [Python-Dev] Please revert autofolding of tracker edit form
On 4/1/2011 6:44 AM, Georg Brandl wrote: Am 01.04.2011 06:02, schrieb Terry Reedy: would switch. Just forgot here. Multiply everything by 2.4 for cm. Or by 2.54, if you're using SI cm :) Then its a good thing I did the conversions with a dual scale ruler ;-). So the number were accurate. I envy all of you who only have to learn and use one relatively sensible unit system. -- Terry Jan Reedy ___ 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] devguide: Add a table of contents to the FAQ.
On Fri, 01 Apr 2011 12:47:12 +0200, Georg Brandl wrote: > Am 01.04.2011 01:12, schrieb R. David Murray: > > On Fri, 01 Apr 2011 08:29:29 +1000, Nick Coghlan wrote: > >> On Fri, Apr 1, 2011 at 2:34 AM, R. David Murray > >> wro= > >> te: > >> > I agree with this point. =A0The sidebar list of questions is effectively > >> > useless. > >> > >> Indeed. If it's simple, I'd actually be inclined to reduce the depth > >> of the sidebar in this case to only show the categories and not the > >> individual questions. > > > > I believe that requires editing the sphinx page template and adding > > a special case of some sort. > > Use > > :tocdepth: x > > at the top of the rst file. Ah, nice. -- R. David Murray http://www.bitdance.com ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
On Fri, 1 Apr 2011 11:17:27 -0400 Barry Warsaw 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. ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
On Fri, 01 Apr 2011 17:39:59 +0200 Georg Brandl wrote: > Am 01.04.2011 14:49, schrieb Antoine Pitrou: > > On Fri, 01 Apr 2011 13:37:42 +0100 > > Michael Foord 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. ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
On Sat, Apr 2, 2011 at 2:31 AM, Antoine Pitrou wrote: > On Fri, 01 Apr 2011 17:39:59 +0200 > Georg Brandl 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 | ncogh...@gmail.com | Brisbane, Australia ___ 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] faulthandler is now part of Python 3.3
Victor Stinner wrote: I pushed my faulthandler module into the default branch (Python 3.3). Since one week, I fixed a lot of bugs (platform issues), improved the tests and Antoine wrote a new implementation of dump_backtraces_later() using a thread (instead of SIGALRM+alarm()). It should now work on all platforms (but register() is not available on Windows). I apologize -- I'm not going to have time to test this myself, and I'm really curious to know if it works: Issue11603 describes a problem where Python either hangs or crashes depending on Python version/OS version... does the faulthandler work for this problem? Remodeling-at-home-and-swamped-at-work-ly yours, ~Ethan~ ___ 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] Impaired Usability of the Mercurial Source Viewer
> That's *way* better: > > https://bitbucket.org/mirror/cpython/src/3558eecd84f0/Lib/linecache.py > > Why can't we have that for our primary source viewer. Would you like to install this, or something else, or change the templates? If so, please let me know so I can give you access to dinsdale. Regards, Martin ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
> 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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
> 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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
> 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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
> 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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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. ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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 ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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 ___ 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] Please revert autofolding of tracker edit form
On 4/1/2011 9:08 AM, Terry Reedy wrote: I envy all of you who only have to learn and use one relatively sensible unit system. Me too. But anyone that calls themselves a programmer should be able to realize that the numbers are proportional and Google happily finds online conversion calculators. ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
Am 01.04.2011 18:31, schrieb Antoine Pitrou: > On Fri, 01 Apr 2011 17:39:59 +0200 > Georg Brandl wrote: >> Am 01.04.2011 14:49, schrieb Antoine Pitrou: >> > On Fri, 01 Apr 2011 13:37:42 +0100 >> > Michael Foord 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 ___ 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] Impaired Usability of the Mercurial Source Viewer
On Apr 1, 2011, at 12:40 PM, Martin v. Löwis wrote: >> That's *way* better: >> >> https://bitbucket.org/mirror/cpython/src/3558eecd84f0/Lib/linecache.py >> >> Why can't we have that for our primary source viewer. > > Would you like to install this, or something else, or change the > templates? If so, please let me know so I can give you access to > dinsdale. Yes please. Raymond ___ 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] warn_unused_result warnings
2011-04-01 03:23:10 Victor Stinner napisał(a): > Le 01/04/2011 01:11, Benjamin Peterson a écrit : > > I'm rather sick of seeing this warnings on all compiles, so I propose > > we enable the -Wno-unused-results option. I judge that most of the > > cases where this occurs are error reporting functions, where not much > > with return code can be done. > Can't we try to fix the warnings instead of turning them off? Or is it > possible to only turn off these warnings on a specific function? http://gcc.gnu.org/gcc-4.6/changes.html "Support for selectively enabling and disabling warnings via #pragma GCC diagnostic has been added." -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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] Use regrtest.py --timeout on buildbots
Le jeudi 31 mars 2011 à 18:35 +0200, Victor Stinner a écrit : > Hi, > > I just added a --timeout option to Lib/test/regrtest.py: if a test (one > function, not a whole file) takes more than TIMEOUT seconds, the > traceback is dumped and it exits. I tested it on 3 buildbots with a > timeout of 5 minutes and it worked as expected: see #11727 for > examples. > > It would be nice to have this feature enabled on all buildbots. I enabled this timeout with a timeout of 15 minutes. Thanks to this timeout, I have know a traceback for the strange test_threadsignals hang: http://bugs.python.org/issue11738 But I got also 3 buildbots (2 FreeBSD, 1 Solaris) failing on: test_io, test_subprocess, test_signal. I changed the default timeout to 30 minutes. The timeout was too long to catch a test_ssl failure on Windows 7 (which uses a timeout of 20 minutes), but also long enough to avoid false positive on Solaris. The 2 FreeBSD buildbots still fails (test_io, test_socket). I am not sure yet that the failures with timeouts of 15 or 30 minutes are just false positive. For example, test_interrupted_write_buffered() in test_io was interrupted after 30 minutes on "x86 FreeBSD 3.x" whereas this test takes less then 5 seconds on my Linux box (and on my FreeBSD VM). Anyway, I am happy to have a working tool to get more information on buildbot hang. At least, it is possible to enable it temporary to try to learn more on a failure. The timeout protects also the buildbot against bugs (hang or infinite loop) in Python or in the test suite: bugs are detected earlier. Victor ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
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 signature.asc 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
> >> 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. ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
On 4/1/2011 7:52 PM, Barry Warsaw wrote: necessary, I leave it alone. I think we're still due one last bug fix release of Python 3.1, right? Yes, hopefully soon. -- Terry Jan Reedy ___ 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
