Re: Python 2.1/2.2 removal; Python 2.4 as default
On Wed, 2006-04-12 at 22:58 +0200, Jeroen van Wolffelaar wrote: zope2.9 is simply still sitting in NEW, and is not rejected. I see there was a clarification requested over the weekend about the big number of zope versions in the archive (2.9 would be the 4th), and Fabio replied. This was two days ago, nothing happened since as far as I can see, so I'd advice to just wait a bit. Fwiw, I don't see a zope2.7 removal request yet, but maybe I'm looking wrongly? We are working on this, but before filing a zope2.7 request we need to check what packages are incompatible with zope = 2.8 and *then* ask for the removal of zope2.7. In the end, in a few days I'll file the removal request of zope2.7 and (I hope) ftp-masters will accept zope2.9 package. -- Fabio Tranchitella [EMAIL PROTECTED].''`. Proud Debian GNU/Linux developer, admin and user.: :' : `. `'` http://people.debian.org/~kobold/ `- _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: This is a digitally signed message part
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Wed, 12 Apr 2006, Matthias Klose wrote: ok, I did run out of time last weekend, however python2.5, python2.3-doc, python2.4-doc are in NEW. According your logic about vacation times, the change of the default version probably should not be done before Easter. Easter is 4 days or a full week for some: nothing problematic. Please go ahead with the python 2.4 change ASAP. Unfortunately FTP masters did reject the Zope2.x upload, which uses python2.4. Any reasons for that? Zope2.7 already was scheduled for removal. I'm not ftpmaster so I can't comment, but usually they give a reason in the rejection notice... what did it say ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Wed, Apr 12, 2006 at 04:33:35PM +0200, Matthias Klose wrote: Jeroen van Wolffelaar writes: On Wed, Apr 12, 2006 at 12:41:13AM +0200, Jeroen van Wolffelaar wrote: So, because there were no objections to the python 2.1/2.2 removal, I'll be proceeding with that. Done now, I'd like to announce this, together with some warning about default python version changes, if they're going to happen soon (best to not to have multiple separate announcements if they can be joined). It'll be a bit (about 24h) before a dropped python2.1 python2.2 will reach the mirrors, and impact should be reasonably limited, so otoh, it isn't totally required. So, any opinion on the -defaults change, esp. from Matthias of course, is very welcomed. ok, I did run out of time last weekend, however python2.5, python2.3-doc, python2.4-doc are in NEW. Cool According your logic about vacation times, the change of the default version probably should not be done before Easter. I don't know, while some people (including, at least, myself) will be unavailable during Easter to do any Debian work, others might rather have lots of time because of it being a holiday and no daytime job being in the way. Having this change done before easter will leverage both groups of people. But I don't care about the exact timing, but I do think we should really do this sooner rather than later, to get things going. Therefore, I'd like to urge you to simply do the move, and have anyone interested help out fixing up all the packages that get broken by it and need an update. Unfortunately FTP masters did reject the Zope2.x upload, which uses python2.4. Any reasons for that? Zope2.7 already was scheduled for removal. Can you please be more specific? And/or reply to the REJECT mail, as it states at the bottom of every reject? That way, all the info is at hand for us ftp-people to look into it. I can't find any NEW reject for zope2.anything during the whole of 2006. At least listing the exact filename of the .changes is already very useful to find the upload you're talking about. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
Jeroen van Wolffelaar writes: Unfortunately FTP masters did reject the Zope2.x upload, which uses python2.4. Any reasons for that? Zope2.7 already was scheduled for removal. Can you please be more specific? And/or reply to the REJECT mail, as it states at the bottom of every reject? That way, all the info is at hand for us ftp-people to look into it. I can't find any NEW reject for zope2.anything during the whole of 2006. At least listing the exact filename of the .changes is already very useful to find the upload you're talking about. CC'ing Fabio, AFAIK that was a zope2.9 upload. Maybe it would be better, if FTP masters send the reject mail to the Maintainer address, not the uploader address? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Wed, Apr 12, 2006 at 10:32:28PM +0200, Matthias Klose wrote: Jeroen van Wolffelaar writes: Unfortunately FTP masters did reject the Zope2.x upload, which uses python2.4. Any reasons for that? Zope2.7 already was scheduled for removal. Can you please be more specific? And/or reply to the REJECT mail, as it states at the bottom of every reject? That way, all the info is at hand for us ftp-people to look into it. I can't find any NEW reject for zope2.anything during the whole of 2006. At least listing the exact filename of the .changes is already very useful to find the upload you're talking about. CC'ing Fabio, AFAIK that was a zope2.9 upload. Maybe it would be better, if FTP masters send the reject mail to the Maintainer address, not the uploader address? zope2.9 is simply still sitting in NEW, and is not rejected. I see there was a clarification requested over the weekend about the big number of zope versions in the archive (2.9 would be the 4th), and Fabio replied. This was two days ago, nothing happened since as far as I can see, so I'd advice to just wait a bit. Fwiw, I don't see a zope2.7 removal request yet, but maybe I'm looking wrongly? About who to inform, typically there isn't a maintainer yet for packages in NEW, so it's a bit tricky. The actual maintainer is only available after a package is installed, because it's not in the .changes. In most cases it doesn't matter (uploader maintainer same person), so while I agree better notification might be worthwhile, it's also not terribly high on my list of things to look into. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
Matthias Klose wrote: Jeroen van Wolffelaar writes: The first freezes are already closing in fast, did I miss something? There's no update since http://lists.debian.org/debian-devel-announce/2005/10/msg4.html Yes. At least the January, 3rd one (http://lists.debian.org/debian-devel-announce/2006/01/msg1.html) --- snip --- [...] Our time line still is: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] The good news is that we are on track to reach this goal. [...] --- snip --- Regards, Rene signature.asc Description: Digital signature
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, Apr 07, 2006 at 01:49:52PM +0200, Matthias Klose wrote: Jeroen van Wolffelaar writes: The first freezes are already closing in fast, did I miss something? There's no update since http://lists.debian.org/debian-devel-announce/2005/10/msg4.html We're roughly 16 weeks from the python freeze, including the debconf period and the summer holiday period (for the northern hemisphere, that is). During these mere 16 weeks, python 2.1 2.2 needs to be dropped, the default moved to 2.4, and the plan is to overhaul the python policy/infrastructure. We can use all of those weeks to get settled over each of those issues, and many more that are important for the release. Having 4 (or maybe even 5) python versions would be a release blocker, and the two oldest ones can be removed without any serious direct consequences, and simply would provide a better urge for people to fix up their packages. Several people already asked for removal, sponsoring, and I noticed some more packages simply getting fixed over the weekend. So, because there were no objections to the python 2.1/2.2 removal, I'll be proceeding with that. Regarding 2.4, I'd really like to get started with it asap, and having the policy stuff happening in parallel. Are there any objections/reasons to *not* do so in like a week from now, starting with a simple upload of python-defaults? --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Wed, Apr 12, 2006 at 12:41:13AM +0200, Jeroen van Wolffelaar wrote: So, because there were no objections to the python 2.1/2.2 removal, I'll be proceeding with that. Done now, I'd like to announce this, together with some warning about default python version changes, if they're going to happen soon (best to not to have multiple separate announcements if they can be joined). It'll be a bit (about 24h) before a dropped python2.1 python2.2 will reach the mirrors, and impact should be reasonably limited, so otoh, it isn't totally required. So, any opinion on the -defaults change, esp. from Matthias of course, is very welcomed. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
decompyle2.2 has an unsatisfied build-dependency: python2.2-dev This is a legacy package, and it requires python 2.2 (it will not work with 2.3 or newer). I have just filed an ftp.d.o bug asking for it to be removed. Users should have no problem switching to the newer decompyle package instead. jython has an unsatisfied build-dependency: python2.1 I orphaned this a couple of months ago. It requires python2.1 at runtime because it is actually an implementation of python2.1. The simplest fix is probably to copy across the pure python modules from cpython2.1 and add them to the jython2.1 package in /usr/share/jython/Lib/, at which point the python2.1 dependency should be able to be removed. However, the jython packages are not ageing gracefully. Unless someone has time to spend actively looking after this (see my WNPP bug for what is required), I'd (regretfully) suggest its removal also. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, Apr 07, 2006 at 12:33:11PM +0200, Jeroen van Wolffelaar wrote: python-pylibacl has an unsatisfied build-dependency: python2.2-dev python-pyxattr has an unsatisfied build-dependency: python2.2-dev I've already re-built these two packages, removing 2.1 and 2.2 support and adding 2.4. However, I've been unable to find a sponsor. Regards, Iustin Pop signature.asc Description: Digital signature
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, Apr 07, 2006 at 01:38:43PM +0200, Iustin Pop wrote: On Fri, Apr 07, 2006 at 12:33:11PM +0200, Jeroen van Wolffelaar wrote: python-pylibacl has an unsatisfied build-dependency: python2.2-dev python-pyxattr has an unsatisfied build-dependency: python2.2-dev I've already re-built these two packages, removing 2.1 and 2.2 support and adding 2.4. However, I've been unable to find a sponsor. If nobody else beats me to it, I'll sponsor you on monday. Ensure that the URL to your package is in the bug report filed on it regarding this transition, so that I, or whoever wants to look into this bug/package, can find it. This advice is valid for everyone, if you are a non-DD maintaining such package, make sure people can sponsor you instead of NMUing, without the need to ask first for URLs etc, by providing all necessary information in a bug. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, 07 Apr 2006, Iustin Pop wrote: On Fri, Apr 07, 2006 at 12:33:11PM +0200, Jeroen van Wolffelaar wrote: python-pylibacl has an unsatisfied build-dependency: python2.2-dev python-pyxattr has an unsatisfied build-dependency: python2.2-dev I've already re-built these two packages, removing 2.1 and 2.2 support and adding 2.4. However, I've been unable to find a sponsor. Please don't hesitate to ask for sponsorship of python related modules here. Where can we find your packages ? BTW, there's no response in the BTS to these bug reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351149 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351150 Submitting in the BTS any relevant information, like availability of fixed packages, and the need for sponsor is always a good idea so that anyone else stumbling upon it could offer you his help. Maybe Matthias himself could have sponsored your upload since he reported the bug ... :-) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
Jeroen van Wolffelaar writes: The first freezes are already closing in fast, did I miss something? There's no update since http://lists.debian.org/debian-devel-announce/2005/10/msg4.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, Apr 07, 2006 at 01:38:43PM +0200, Iustin Pop wrote: I've already re-built these two packages, removing 2.1 and 2.2 support and adding 2.4. However, I've been unable to find a sponsor. Thanks everyone for the suggestions. Will update the bug reports later today with the relevant information. Thanks, Iustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's think about removing Python 2.1 and 2.2
On 7/12/05, Kenneth Pronovici [EMAIL PROTECTED] wrote: I think you misunderstood my suggestion, and probably the suggestion of the OP. I did not suggest that we continue to maintain packages depending on these old Python versions. I just suggested that we continue to support the interpreters themselves, so that users can invoke them directly if desired. Agreed. Note also that other implementations of the Python JVM (Jython and Stackless) lag developments in CPython, and interested hackers benefit greatly from having a stable binary release of CPython against which to regression test. Could be done in a sarge chroot, of course, or better yet in a Xen guest; but at least that's an argument that might carry some weight with those who don't care much about commercial users. This in and of itself should not be a large burden on the security team and should not result in very many extra packages in the archive (at least not hundreds extra). I can't speak for the burden on the python maintainers themselves, which is why I was hoping (in the part of my message you trimmed) that they might speak up and tell us how much of a burden this might be. If you have the python-fu needed to hack on pychecker, I would guess that they would welcome your participation. That's just a guess, though, as I don't know them. Matthias Klose's comment that Zope is the only reason to keep 2.3.x in the archives is a bit discouraging; I dislike version churn for its own sake and it's a lot more painful to migrate an app off of Windows if you have to eat upgrades to Python, WxWidgets, etc., etc. at the same time. The penalty for success in language design is that you accumulate an ecosystem that's hard to drag further forward. Witness C. Square this for weakly typed languages. Witness Perl. Square it again for languages with multiple implementations that are way different under the hood. Witness Scheme. Add OO snake oil (with polymorphic operators and multiple inheritance), multithreading, and a habit of pushing extensions down into native code for performance, and you get a really fun and powerful language that you don't upgrade for upgrading's sake unless you like pain or hate the poor sods in QA. Cheers, - Michael
Re: Let's think about removing Python 2.1 and 2.2
On Mon, Jun 13, 2005 at 11:54:10AM -0700, Donovan Baarda wrote: On Sun, 2005-06-12 at 13:40, Martin Michlmayr wrote: I once had a discussion with Matthias Klose about reducing the number of Python versions in Debian and he said he'd like to get rid of 2.1 and 2.2 after sarge is out. If I remember correctly, a problem is that 2.1 is needed by Jython and 2.1 by Zope. Can someone please work on a plan to move these packages to a newer version of Python and to get rid of 2.1 and 2.2 (and maybe 2.3) in time for etch? I think there is a subtle but significant difference between removing and no-longer supporting. Sure, don't waste time and effort on supporting old Python's, but let's hold off on removing them for a while... until the rest of the world has well and truely moved on to Python2.4, there will be plenty of people who appreciate being able to develop and test against all the 2.1+ versions of Python on one platform. If these are removed from Debian, then we will need an unofficial repository where they can be put for developers who want/need them... and personaly I hate unofficial repositories. (Sorry I'm late in replying to this). I second this position. I did some hacking on pychecker earlier this year, and it was really nice to have 2.1, 2.2, 2.3 and 2.4 all available on the same Debian system. I would be disappointed if Debian dropped these interpreters completely for etch. Hopefully, it wouldn't be too difficult to continue supporting these interpreters until upstream declares them dead. I don't think it would take too much effort (since they don't seem to change too often), but perhaps Gregor Hoffleit or Matthias Klose will speak up and let me know differently. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpzEOiwab6C7.pgp Description: PGP signature
Re: Let's think about removing Python 2.1 and 2.2
Le mardi 12 juillet 2005 à 14:35 -0500, Kenneth Pronovici a écrit : I did some hacking on pychecker earlier this year, and it was really nice to have 2.1, 2.2, 2.3 and 2.4 all available on the same Debian system. I would be disappointed if Debian dropped these interpreters completely for etch. Hopefully, it wouldn't be too difficult to continue supporting these interpreters until upstream declares them dead. I strongly disagree. Not only does supporting too many versions of the interpreter is more difficult - not speaking of the added burden to the security team - but this is cluttering the archive, complicating the maintainers' work and the major version transitions, wasting time that could be spent to more useful tasks. Having only one python version (at least for most packages) would save hundreds of packages in the distribution, and it's that less work for maintainers. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: Let's think about removing Python 2.1 and 2.2
On Tue, Jul 12, 2005 at 10:26:09PM +0200, Josselin Mouette wrote: Le mardi 12 juillet 2005 à 14:35 -0500, Kenneth Pronovici a écrit : I did some hacking on pychecker earlier this year, and it was really nice to have 2.1, 2.2, 2.3 and 2.4 all available on the same Debian system. I would be disappointed if Debian dropped these interpreters completely for etch. Hopefully, it wouldn't be too difficult to continue supporting these interpreters until upstream declares them dead. I strongly disagree. Not only does supporting too many versions of the interpreter is more difficult - not speaking of the added burden to the security team - but this is cluttering the archive, complicating the maintainers' work and the major version transitions, wasting time that could be spent to more useful tasks. Having only one python version (at least for most packages) would save hundreds of packages in the distribution, and it's that less work for maintainers. I think you misunderstood my suggestion, and probably the suggestion of the OP. I did not suggest that we continue to maintain packages depending on these old Python versions. I just suggested that we continue to support the interpreters themselves, so that users can invoke them directly if desired. This in and of itself should not be a large burden on the security team and should not result in very many extra packages in the archive (at least not hundreds extra). I can't speak for the burden on the python maintainers themselves, which is why I was hoping (in the part of my message you trimmed) that they might speak up and tell us how much of a burden this might be. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpqLbWFGfQVV.pgp Description: PGP signature
Re: Let's think about removing Python 2.1 and 2.2
However we should keep jython in the archives, upstream shows some activity for python2.3/2.4 compatibility. For reference, it seems upstream is currently looking at a final (non-beta) release around August [1]. Though they've missed deadlines before, so please don't take this as definitive. b. 1. http://www.jython.org/cgi-bin/wiki/RoadMap -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's think about removing Python 2.1 and 2.2
On Sun, 2005-06-12 at 13:40, Martin Michlmayr wrote: I once had a discussion with Matthias Klose about reducing the number of Python versions in Debian and he said he'd like to get rid of 2.1 and 2.2 after sarge is out. If I remember correctly, a problem is that 2.1 is needed by Jython and 2.1 by Zope. Can someone please work on a plan to move these packages to a newer version of Python and to get rid of 2.1 and 2.2 (and maybe 2.3) in time for etch? I think there is a subtle but significant difference between removing and no-longer supporting. Sure, don't waste time and effort on supporting old Python's, but let's hold off on removing them for a while... until the rest of the world has well and truely moved on to Python2.4, there will be plenty of people who appreciate being able to develop and test against all the 2.1+ versions of Python on one platform. If these are removed from Debian, then we will need an unofficial repository where they can be put for developers who want/need them... and personaly I hate unofficial repositories. -- Donovan Baarda [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's think about removing Python 2.1 and 2.2
On 12/06/2005 Matthias Klose wrote: Martin Michlmayr writes: I once had a discussion with Matthias Klose about reducing the number of Python versions in Debian and he said he'd like to get rid of 2.1 and 2.2 after sarge is out. If I remember correctly, a problem is that 2.1 is needed by Jython and 2.1 by Zope. Can someone please work on a plan to move these packages to a newer version of Python and to get rid of 2.1 and 2.2 (and maybe 2.3) in time for etch? Yes, there is a plan, hopefully be presented at Debconf5. However we should keep jython in the archives, upstream shows some activity for python2.3/2.4 compatibility. 2.3 is still needed for zope 2.7 and zope 2.8, these zope version do run with 2.4, but upstream claims, there was not yet any security audit done for zope 2.x on python2.4. AFAIK besides zope there are no other reasons to keep 2.3 in the archives. according to upstream, zope 2.6 (default zope version in debian) should best be run with python 2.1. python 2.2 is already depreciated. as zope (2.6.4-1.8) already runs with python 2.2, at least this version has to be kept in unstable as long as zope 2.6 is supported in debian. i asked about this recently on the pkg-zope-developers list. someone claimed that providing a smooth upgrade from zope 2.6 to 2.7 would be good, and maybe that implies that zope 2.6 will stay in the archive for some more time. bye jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-zope-developers] Re: Let's think about removing Python 2.1 and 2.2
also sprach Jonas Meurer [EMAIL PROTECTED] [2005.06.12.2326 +0200]: i asked about this recently on the pkg-zope-developers list. someone claimed that providing a smooth upgrade from zope 2.6 to 2.7 would be good, and maybe that implies that zope 2.6 will stay in the archive for some more time. I don't think this will happen (the upgrade path). To me, it sounds best just to remove zope2.6 from etch. There is little point to keep maintaining it as it's really just outdated now. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! alles sollte so einfach, wie möglich gemacht sein, aber nicht einfacher. -- albert einstein signature.asc Description: Digital signature
Re: RC wxwindows reports preventing python 2.1 - 2.2 transition
Howdy, On Sat, Apr 05, 2003 at 11:54:42AM +0200, Matthias Klose wrote: For wxwindows2.2 and 2.4 I see two RC reports. Any chance to fix these soon? Well the bts issues relating to the package itself should now all be fixed in the 2.4.0.8 upload, however it appears its still going to be kept out of testing by toolchain failures on hppa and ppc, and (newly) also on m68k. I'm not sure what else to do now except be patient until they are fixed. I don't think there is anything I can do in wx to fix these problems. Ron
Re: RC wxwindows reports preventing python 2.1 - 2.2 transition
Howdy, On Sat, Apr 05, 2003 at 11:54:42AM +0200, Matthias Klose wrote: For wxwindows2.2 and 2.4 I see two RC reports. Any chance to fix these soon? The biggest issue with them IMO is the png mess, and the right fix to avoid thrashing on all sides is probably to transition them to gtk2 sooner now rather than later. I'll bump it all further up my stack again though, thanks. What about removing wxwindows2.3 from unstable. AFAICR this was a development release anyway. Same for 2.2, no other packages seem to depend on this version anymore. Yes, they are certainly candidates for removal asap. When I looked yesterday poedit still showed up in the 2.3 deps, but I don't see that now. (apt-cache showpkg reports some terribly weird things for me from time to time...) If they really have no further deps I'd be glad to see 2.2 and 2.3 gone. I'll file a request at ftp-admin if no-one listening pings me that they've already removed them :-) cheers, Ron
Re: Python-2.1 becoming Debian's default Python version
Neil Schemenauer [EMAIL PROTECTED] writes: It's probably better to check if you're unsure rather than speculate or guess. From the 2.1.1 LICENCE file: Python 1.6.1 is essentially the same as Python 1.6, with a few minor bug fixes, and with a different license that enables later versions to be GPL-compatible. The license claims to be GPL compatible, but according to the FSF, it isn't, because of the choice-of-law clause.
Re: Python-2.1 becoming Debian's default Python version
* Florian Weimer [EMAIL PROTECTED] [011107 15:04]: Neil Schemenauer [EMAIL PROTECTED] writes: It's probably better to check if you're unsure rather than speculate or guess. From the 2.1.1 LICENCE file: Python 1.6.1 is essentially the same as Python 1.6, with a few minor bug fixes, and with a different license that enables later versions to be GPL-compatible. The license claims to be GPL compatible, but according to the FSF, it isn't, because of the choice-of-law clause. ^^^ Can you provide any proof for this claim ? From http://www.gnu.org/licenses/license-list.html: The License of Python 1.6a2 and earlier versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that newer versions of Python are under other licenses (see below). The License of Python 2.0.1, 2.1.1, and newer versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that intermediate versions of Python (1.6b1, through 2.0 and 2.1) are under a different license (see below). Gregor
Re: Python-2.1 becoming Debian's default Python version
On Wed, Nov 07, 2001 at 03:10:31PM +0100, Gregor Hoffleit wrote: | * Florian Weimer [EMAIL PROTECTED] [011107 15:04]: | Neil Schemenauer [EMAIL PROTECTED] writes: | | It's probably better to check if you're unsure rather than speculate or | guess. From the 2.1.1 LICENCE file: | | Python 1.6.1 is essentially the same as Python 1.6, with a few minor | bug fixes, and with a different license that enables later versions | to be GPL-compatible. | | The license claims to be GPL compatible, but according to the FSF, it | isn't, because of the choice-of-law clause. | ^^^ | | Can you provide any proof for this claim ? | | From http://www.gnu.org/licenses/license-list.html: | | The License of Python 1.6a2 and earlier versions. | This is a free software license and is compatible with the GNU | GPL. Please note, however, that newer versions of Python are | under other licenses (see below). | | The License of Python 2.0.1, 2.1.1, and newer versions. | This is a free software license and is compatible with the GNU | GPL. Please note, however, that intermediate versions of Python | (1.6b1, through 2.0 and 2.1) are under a different license (see ^^ | below). This is what I thought (note the micro version differences!, also note that python doesn't put a .0 micro version, but rather an empty string micro version for the first release) -D
Re: Python-2.1 becoming Debian's default Python version
Gregor Hoffleit [EMAIL PROTECTED] writes: Python 1.6.1 is essentially the same as Python 1.6, with a few minor bug fixes, and with a different license that enables later versions to be GPL-compatible. The license claims to be GPL compatible, but according to the FSF, it isn't, because of the choice-of-law clause. ^^^ Can you provide any proof for this claim ? From http://www.gnu.org/licenses/license-list.html: The License of Python 1.6a2 and earlier versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that newer versions of Python are under other licenses (see below). The License of Python 2.0.1, 2.1.1, and newer versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that intermediate versions of Python (1.6b1, through 2.0 and 2.1) are under a different license (see below). You have to follow the see below link on this page.
Re: Python-2.1 becoming Debian's default Python version
* Florian Weimer [EMAIL PROTECTED] [011107 16:08]: Gregor Hoffleit [EMAIL PROTECTED] writes: Python 1.6.1 is essentially the same as Python 1.6, with a few minor bug fixes, and with a different license that enables later versions to be GPL-compatible. The license claims to be GPL compatible, but according to the FSF, it isn't, because of the choice-of-law clause. ^^^ Can you provide any proof for this claim ? From http://www.gnu.org/licenses/license-list.html: The License of Python 1.6a2 and earlier versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that newer versions of Python are under other licenses (see below). The License of Python 2.0.1, 2.1.1, and newer versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that intermediate versions of Python (1.6b1, through 2.0 and 2.1) are under a different license (see below). You have to follow the see below link on this page. Sorry, I guess I was misinterpreting you. I think we do agree that the License of Python 2.1.1, according to the FSF, is compatible with the GPL ? (That was my point, and I think I was prejudicating you ;-) Now for Python 1.6.1. The 'see below' in the second paragraph links to this (refering to 'intermediate versions of Python (1.6b1, through 2.0 and 2.1)': The License of Python 1.6b1 and later versions, through 2.0 and 2.1. This is a free software license but is incompatible with the GNU GPL. The primary incompatibility is that this Python license is governed by the laws of the State of Virginia, in the USA, and the GPL does not permit this. This section is incorrect, in that Python 1.6.1 has yet another different license. It should read something like The License of Python 1.6b1 and later versions, through 2.0 and 2.1, but excluding 1.6.1 and derivatives thereof. Then, there should be another section The License of Python 1.6.1 and derivatives thereof since this license is different from the license license of 1.6. In fact the modification between 1.6 and 1.6.1 (which was made possible by CNRI) was the major step in making the release of 2.0.1 and 2.1.1 possible. OTOH, I wonder if B. Kuhn would be glad to list *four* different Python licenses on that page ? ;-) Gregor
Re: Python-2.1 becoming Debian's default Python version
Matthias Klose [EMAIL PROTECTED] immo vero scripsit Please Cc: me, because I am not on the list. python-ecasound I have been looking at python 2.1, and python2.1 debian/copyright file tells me that it is not GPL compatible. Is it still so? regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: Python-2.1 becoming Debian's default Python version
On Tue, Nov 06, 2001 at 11:05:29PM +0900, Junichi Uekawa wrote: | Matthias Klose [EMAIL PROTECTED] immo vero scripsit | | Please Cc: me, because I am not on the list. | |python-ecasound | | I have been looking at python 2.1, and python2.1 debian/copyright file tells | me that it is not GPL compatible. | | Is it still so? As I understand/recall the history, python 2.0 and 2.1 are not GPL compatible. However, 2.0.1 and 2.1.1 (note the micro version increase) are GPL Compatible. So, strictly speaking, you are right to say that 2.1 is not GPL compatible, however the 2.1 packages really package 2.1.1 which is GPL compatible. -D
Re: Python-2.1 becoming Debian's default Python version
Matthias Klose [EMAIL PROTECTED] writes:
You get this mail, because you are the maintainer of packages probably
affected by the change of the Python version. Followups and replies,
which could be of interest for all Python packagers, should be sent to
[EMAIL PROTECTED] Your packages are:
syslog-summary, fsh, python-xmlrpc
These are now in incoming. Do yell if I screwed up, its late.
Cc: me in replies, not actively reading the list.
--
[EMAIL PROTECTED],havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
double a,b=4,c;main(){for(;++a2e6;c-=(b=-b)/a++);printf(%f\n,c);}
Python 2.1 crypto
I notice that python2.1-base depends on libssl0.9.6. I haven't been following the developments in Debian's crypto policy, but doesn't this mean that python2.1-base should have been uploaded to non-US? -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Ha ha! Puny receptacle!
Re: Intent for NMU of python-2.1 packages
Matthias Klose [EMAIL PROTECTED] writes: ... in June (2.1) and July (2.1.1). Gregor (the python-1.5 and python-2.0 maintainer) has put experimental packages at http://people.debian.org/~flight/python and was asking for help regarding the packaging (20010801). Jérôme Marant answered (20010803), but since this date nothing happened. I intend to do a NMU of python2.1 based on Gregor's experimental packages that can coexist ... Do you know what happened to Gregor since 20010801? I periodicaly had a look to his page at debian.org but nothing happened since then. Did you contact him? Do you have his agreement for the NMU? What do you plan to do about the idle package? Thanks. Cheers, -- Jérôme Marant [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Intent for NMU of python-2.1 packages
Gregor Hoffleit [EMAIL PROTECTED] writes: I'm still alive, I'm not lost ;-) You're not dead, which is the most important ;-) And that's the problem where I was stuck. The dependencies of the current experimental python1.5 packages aren't good enough to allow an easy upgrade from potato or earlier. AFAICS, I would have to include empty transitional packages for almost all python-* packages built from the python source. That's butt ugly IMHO. That is what happened for the Perl transition. I don't think you can avoid this. What you have to do: . provide transitional packages. These packages will guaranty that nothing will break during the transition. . ask people to change their dependencies. You will regularly list packages that have not been updated and warn their maintainers to do so. Furthermore, it's my current impression that we have to orphan all python-* packages in order to get a clean upgrade path! Huh?! There are many packages with broken dependencies in potato (i.e. packages that install stuff in /usr/lib/python1.5, but don't have a versioned dependency on Python 1.5). Therefore, any future python-base package either has to be compatible with stuff in /usr/lib/python1.5, or has to list all those broken packages as conflicts. Either is ugly. Do we have a list of them? Therefore I think we have to get rid of all the problem-ridden package names, i.e. at least python-base and python-tk, perhaps even python-dev. I don't see any other solution. Sorry, I did not understand this. ... Python package maintainers should then change their packages to build python1.5-* and python2.1-* packages (python2.0 if needed), and make them depend on python1.5-base etc. That would remove the need for versioned dependencies. Right. At a later point, we could implement a kind of registry like the emacsen have, so that third-party packages could build only one python-* package, that registers itself with all existing pythons. We have dealt with this a long time ago and we have always said that it was too late because we were approaching the freeze. But we are still not frozen (optional packages) and I think it's time to implement this, whenever is the freeze (it will be usefull whether it is integrated in woody or not). Cheers, -- Jérôme Marant [EMAIL PROTECTED] [EMAIL PROTECTED]
Intent for NMU of python-2.1 packages
As David Maslen pointed out in http://lists.debian.org/debian-python/2001/debian-python-200109/msg0.html Debian doesn't have yet python-2.1 in it's distro, although released in June (2.1) and July (2.1.1). Gregor (the python-1.5 and python-2.0 maintainer) has put experimental packages at http://people.debian.org/~flight/python and was asking for help regarding the packaging (20010801). Jérôme Marant answered (20010803), but since this date nothing happened. I intend to do a NMU of python2.1 based on Gregor's experimental packages that can coexist with python1.5 and python2.0. I hope that these packages will find its way to the woody dist and allow the upload of python-2.1 dependent packages to woody. I will do this upload next weekend. Matthias
Python 2.1
I've read through archives on this in the past, feel free to suggest other URL's if this is a discussed to death topic, but; Python 2.1 in now GPL compatable right? I saw some 2.1 packages in one of the debian developers home directories. They aren't release though, and that can be a little annoying if you want to compile modules etc, and there are dependacy issues. What's the story for python2 in Debian? Also has it been decided that we will need python 1.5 for the foreseable future? I just like to hack with python, but I like to feel I'm using the latest software. Debian has traditionally been very good for that, because apt-get made it so. However in relation to python, it doesn't seem to be a safe assumption.
Python policy (was Re: Experimental Python 2.1 packages, release plans)
On Thu, May 24, 2001 at 04:34:35PM +0200, Gregor Hoffleit wrote: Anyway, while I'm away, perhaps someone could start to audit the packages that depend on Python, and file bugs for all packages that don't have a correct, explicit versioned dependency on python-base like Depends: python-base (= 1.5), python-base ( 1.6) or Depends: python2-base (= 2.0), python2-base ( 2.1) Hmmm is the implication of this that every package will still need to be customised to know which /usr/lib/python-XXX to use? Is this the approach that maintainers are taking? If so, would it not perhaps make more sense to have python packages detect the version of /usr/bin/python at build time, and adjust themselves accordingly? The only problem would be the need for a shlibdeps equivalent or whatever -- Peter Eckersley http://www.cs.mu.oz.au/~pde ([EMAIL PROTECTED]) TLI: http://www.computerbank.org.au .sig temporarily conservative pending divine intervention GPG fingerprint: 30BF 6A78 2013 DCFA 5985 E255 9D31 4A9A 7574 65BC pgpdVBAhMiq22.pgp Description: PGP signature
Re: python-2.1 for unstable?
On Sun, Jun 03, 2001 at 07:06:09PM +0200, Florian Weimer wrote: Gregor Hoffleit [EMAIL PROTECTED] writes: This is probably correct, but it is completely irrelevant in our case. Some parts of Python 2.1 are still covered by the GPL-incompatible CNRI license, so Python 2.1 as a whole is not GPL compatible. I'm glad to correct you, but according to Guido and Eben, that's not the case. The only remaining problem with the CNRI license was the choice-of-law clause. Apparently Eben said to Guido that for GPL compatibility only the choice-of-law in the topmost license on the stack matters, and that's the PSF license. I'm no lawyer, so don't ask me why. This means that you can incorporate GPLed code whose copyright is owned by the FSF into Python, but other copyright owners might still ask you not to do this. This reminds me of the ipfilter license blowup (cf. http://lwn.net/2001/0524/#ipfilter), where the ipfilter author appearently claimed that a standard BSD license doesn't permit modification of the code. Certainly it's not unthinkable that people use the GPL for their own code, but don't agree with the FSF that this new Python license is compatible with the GPL. I would tend to think, though, that the vast majority of authors of GPL code will agree with the interpretation of Moglen and RMS. Therefore I can't see your point here. Gregor
Re: python-2.1 for unstable?
Florian Weimer writes: This is probably correct, but it is completely irrelevant in our case. Some parts of Python 2.1 are still covered by the GPL-incompatible CNRI license, so Python 2.1 as a whole is not GPL compatible. which parts exactly?
Re: python-2.1 for unstable?
Matthias Klose [EMAIL PROTECTED] writes: Florian Weimer writes: This is probably correct, but it is completely irrelevant in our case. Some parts of Python 2.1 are still covered by the GPL-incompatible CNRI license, so Python 2.1 as a whole is not GPL compatible. which parts exactly? I think you have to ask the Python developers. Answering this question requires a huge amount of work (digging through CVS logs, diffs, mailing list archives, personal mail folders, etc.).
Re: python-2.1 for unstable?
On Thu, May 24, 2001 at 01:02:29PM +0200, Florian Weimer wrote: Gregor Hoffleit [EMAIL PROTECTED] writes: I talked to RMS, Eben Moglen and GvR. The bad news: According to RMS+Moglen, the license used in Python 2.1 still is not yet compatible with the GPL. The good news: The PSF decided to drop the choice of law clause. A modified license is in CVS, and, according to Guido, will be used for the maintenance releases 2.0.1 and 2.1.1. The bright news: Moglen himself told me that the license text in CVS is compatible with the GPL. This is probably correct, but it is completely irrelevant in our case. Some parts of Python 2.1 are still covered by the GPL-incompatible CNRI license, so Python 2.1 as a whole is not GPL compatible. I'm glad to correct you, but according to Guido and Eben, that's not the case. The only remaining problem with the CNRI license was the choice-of-law clause. Apparently Eben said to Guido that for GPL compatibility only the choice-of-law in the topmost license on the stack matters, and that's the PSF license. I'm no lawyer, so don't ask me why. I have sent the file python/dist/src/LICENSE from CVS to Eben Moglen (which contains the complete stack of licenses), and he replied: Yes, you can say that I have advised you that if this is the license for Python 2.1.1 it would be a GPL-compatible release. Eben Moglen is the legal advisor of the FSF, so I think we could take his word for granted: If Python 2.1.1 will be released under the license currently in CVS, then it will be compatible with the GPL, according to the judgement of the FSF. Gregor
Experimental Python 2.1 packages, release plans
I have uploaded experimental Python 2.1 packages. Grab them at http://people.debian.org/~flight/python2/ The packages are completely untested. I had to re-implement the building of the shared library (just finished), the remainder of the packages is mostly unchanged. In a few hours, I will leave to Illinois for two weeks. Thomas Wouters currently is preparing the Python 2.1.1 maintenance release, which will be the first GPL compliant release of Python 2.x (provided nothing desastrous happens). At the same time, Moshe Zadka is working on a 2.0.1 release, which will also be GPL compatible. Quoting Thomas: Another couple of weeks at least, before a release candidate. It also depends on Moshe; if he actually releases 2.0.1 anytime soon, I'll hold off on 2.1.1 a bit longer. A few days ago, I quoted from ajt's release schedule. Now if either Python 2.0.1 or 2.1.1 would be out before July 1, I would like to try and make a hard migration: Python 1.5.2 would be re-packaged as python1.5, and the then-GPL-compliant would be packaged under the name python. As a consequence, nearly all Python packages would have to be re-packaged. The goal should be to provide a smooth migration from potato to woody. This would involve a quite work-intensive period for the maintainers, but IMHO for the user it would be the best solution. I wouldn't like to start this migration, though, before Python 2.x is really GPL compliant. I don't like to release python-* packages with woody which are encumbered by license problems. I.e. I don't want to release woody with 2.0 or 2.1 as python-*, and I would prefer to release woody with python 2.0.1 and python1.5 1.5.2 over releasing woody with python2 2.1 and python 1.5.2. Now the problems start if neither 2.0.1 nor 2.1.1 would be ready in time. If it's obious early that the won't be ready in time, we could start to migrate the python2 packages to Python 2.1. Anyway, while I'm away, perhaps someone could start to audit the packages that depend on Python, and file bugs for all packages that don't have a correct, explicit versioned dependency on python-base like Depends: python-base (= 1.5), python-base ( 1.6) or Depends: python2-base (= 2.0), python2-base ( 2.1) Gregor
Experimental Python 2.1 packages, release plans
Gregor Hoffleit writes: I have uploaded experimental Python 2.1 packages. Grab them at http://people.debian.org/~flight/python2/ thanks! Now the problems start if neither 2.0.1 nor 2.1.1 would be ready in time. If it's obious early that the won't be ready in time, we could start to migrate the python2 packages to Python 2.1. IMO there would be no problem in uploading the current CVS version of the 2.1 branch. The maintainance release isn't supposed to break anything and if upstream could be convinced to check in the LICENSE from the HEAD branch to the release21-maint branch before the freeze ... Python 1.5.2 would be re-packaged as python1.5, and the then-GPL-compliant would be packaged under the name python. As a consequence, nearly all Python packages would have to be re-packaged. The goal should be to provide a smooth migration from potato to woody. Anyway, while I'm away, perhaps someone could start to audit the packages that depend on Python, and file bugs for all packages that don't have a correct, explicit versioned dependency on python-base like Depends: python-base (= 1.5), python-base ( 1.6) Thats double work if you want to replace python-foo with python1.5-foo anyway.
Re: python-2.1 for unstable?
Matthias Klose wrote: - new packages names python2.1-foobar - same package names, but add versioned dependencies: python-foobar (= 2.1) The latter will cause some incompatibilities until all python2 dependent packages are uploaded for 2.1. I strongly prefer the latter. If people want multiple versions of Python installed they can easily download the source and install them into /usr/local/bin. Neil
Re: python-2.1 for unstable?
On Mon, May 21, 2001 at 12:14:07PM -0700, Neil Schemenauer wrote:
Matthias Klose wrote:
- new packages names python2.1-foobar
- same package names, but add versioned dependencies: python-foobar (= 2.1)
The latter will cause some incompatibilities until all python2
dependent packages are uploaded for 2.1.
I strongly prefer the latter. If people want multiple versions
of Python installed they can easily download the source and
install them into /usr/local/bin.
I'd just like to comment on this. I installed python2.1 some time ago in
/usr/local. However this leads to problems. You have to modify some of
the code (eg PYTHONPATH IIRC) due to using prefix=/usr/local.
If you do not modify the code, all of your installed python
modules/packages (in prefix=/usr) will not be found by
/usr/local/bin/python.
I don't think I ever got it quite right, perhaps a simple
export PYTHONPATH=/usr/local/lib/python{2,2.1}:/usr/lib/python1.5
inside $HOME/.bashrc would be a better solution?
--
Gordon Sadler
Re: python-2.1 for unstable?
Gordon Sadler wrote:
I'd just like to comment on this. I installed python2.1 some time ago in
/usr/local. However this leads to problems. You have to modify some of
the code (eg PYTHONPATH IIRC) due to using prefix=/usr/local.
Which code is the code? The code distributed with Python works
fine when installed in /usr/local.
If you do not modify the code, all of your installed python
modules/packages (in prefix=/usr) will not be found by
/usr/local/bin/python.
Which modules are you talking about? If you have pure Python
modules you can make them available to Python 2.1 by copying the
source files to /usr/local/lib/python2.1/site-packages and
running compileall.py on them. Extension modules have to be
recomplied for 2.1. Its easy if the extensions use distutils:
$ python2.1 setup.py build
$ su
$ python2.1 setup.py install
I don't think I ever got it quite right, perhaps a simple
export PYTHONPATH=/usr/local/lib/python{2,2.1}:/usr/lib/python1.5
Bad idea. The stuff in /usr/lib/python1.5 is for Python 1.5. It
might by chance work with 2.0 or 2.1 but don't count on it.
Neil
Re: python-2.1 for unstable?
On 21 May 2001 20:57:34 +0200, Matthias Klose wrote: I really would like to see 2.1 in the next Debian release. I'd like to ask Gregor (the maintainer) for an upload schedule, so that other maintainers can rely on this to get their packages ready for the next release as well. Are there still license issues which will be resolved in upcoming releases? Should we skip 2.1 and hope that 2.2 gets I don't think 2.1 is much better than 2.0 when it comes to GPL compatibility. But the roumurs say that there will be a 2.1.1 release that is fixes this and a few other bugs. I think the new (2.1.1) license was blessed by rms... Sorry, I don't remember where I read this. released upstream before the woody freeze? Thanks, Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Tom Cato Amundsen [EMAIL PROTECTED] GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/
Re: python-2.1 for unstable?
On Mon, May 21, 2001 at 01:12:57PM -0700, Neil Schemenauer wrote:
Gordon Sadler wrote:
I'd just like to comment on this. I installed python2.1 some time ago in
/usr/local. However this leads to problems. You have to modify some of
the code (eg PYTHONPATH IIRC) due to using prefix=/usr/local.
Which code is the code? The code distributed with Python works
fine when installed in /usr/local.
I was doing something awful here. You are correct, now that you've
pointed out (don't move /usr/lib/python1.x to /usr/local/lib/python2.x)
If you do not modify the code, all of your installed python
modules/packages (in prefix=/usr) will not be found by
/usr/local/bin/python.
Which modules are you talking about? If you have pure Python
modules you can make them available to Python 2.1 by copying the
source files to /usr/local/lib/python2.1/site-packages and
running compileall.py on them. Extension modules have to be
recomplied for 2.1. Its easy if the extensions use distutils:
Actually I just did:
cd /usr/lib/site-python
cp *py /usr/local/lib/site-python
then ran compileall.py on /usr/local/lib/site-python.
I was completely missing the version independent items before. For some
reason I was trying to move /usr/lib/python1.5/site-packages/* to my
/usr/local python2 -(. Thanks for setting this straight.
$ python2.1 setup.py build
$ su
$ python2.1 setup.py install
I don't think I ever got it quite right, perhaps a simple
export PYTHONPATH=/usr/local/lib/python{2,2.1}:/usr/lib/python1.5
Bad idea. The stuff in /usr/lib/python1.5 is for Python 1.5. It
might by chance work with 2.0 or 2.1 but don't count on it.
You are correct here as well. When I did some of this it was rather late
at night, bad habit of staying up late and trying to twiddle stuff on my
system. Thanks again.
--
Gordon Sadler
Re: python-2.1 for unstable?
Sorry guys for the silence. I had to go through upgrading my hardware, upgrading my line setup to a new provider with a flat fee, and finally, some real world work kept me busy. On Mon, May 21, 2001 at 10:35:15PM +0200, Tom Cato Amundsen wrote: On 21 May 2001 20:57:34 +0200, Matthias Klose wrote: I really would like to see 2.1 in the next Debian release. I'd like to ask Gregor (the maintainer) for an upload schedule, so that other maintainers can rely on this to get their packages ready for the next release as well. Are there still license issues which will be resolved in upcoming releases? Should we skip 2.1 and hope that 2.2 gets I don't think 2.1 is much better than 2.0 when it comes to GPL compatibility. But the roumurs say that there will be a 2.1.1 release that is fixes this and a few other bugs. I think the new (2.1.1) license was blessed by rms... Sorry, I don't remember where I read this. Here's a quick update: I talked to RMS, Eben Moglen and GvR. The bad news: According to RMS+Moglen, the license used in Python 2.1 still is not yet compatible with the GPL. The good news: The PSF decided to drop the choice of law clause. A modified license is in CVS, and, according to Guido, will be used for the maintenance releases 2.0.1 and 2.1.1. The bright news: Moglen himself told me that the license text in CVS is compatible with the GPL. Guido asked for our release plan. He'd like to inform the release managers of 2.0.1 and 2.1.1, and seemed to be quite interested to make sure that the next release of Debian will contain a fixed version: On Tue, May 08, 2001 at 04:32:13PM +0200, Gregor Hoffleit wrote: On Tue, May 08, 2001 at 09:48:38AM -0500, Guido van Rossum wrote: That would be great! When should 2.1.1 be out in order for it to be the default version? If I have a specific date I can put some pressure on the folks responsible for assembling the release! The earlier, the better, is all I can say ;-) According to our release manager, Anthony Towns [EMAIL PROTECTED], the critical dates for the next release or like this: * Policy goes into debugging mode on 1st June, and no further changes may be made after about 20th June. * Base packages must have all release-critical bugs fixed by 1st July, and no further changes may be made after about 20th Jul$ * Boot-floppies, standard packages, task packages, and packages included in tasks or in boot-floppies need all their release-critical bugs fixed by 1st August, and no further release-critical bugs fixed by 1st August, and no further changes may be made to them after about 20th August. * The remaining packages (optional, extra) need their release-critical bugs fixed by 1st September, and no further changes may be made to them after about 20th September. * We release early to mid October. Again this is still fairly optimistic, and not necessarily going to happen. (Hi Slashdot.) Looks like plenty of time, but due to the big tree of dependencies, the timeframes are still quite tight. python is now a 'standard' package in Debian. Therefore I should not make any critical changes on the default Python packages after August 1. Currently, the 'default' Python packages are built from Python 1.5.2. A problem is that it would take some time of preparation after the release of Python 2.1.1 to change the default Python to 2.1.1 (coordinating uploads of packages with new dependencies, testing of the dependencies, etc. pp.). Given that the above dates all hold true: If Python 2.1.1 is out by July 1, it should be possible to include it as default Python version in the next release. (And, it would be ready in time for the European Python Meeting in Bordeaux ;-). If it's out by mid-September, it still could be included, but only as second choice. Python 1.5.2 would then be default. Still, I would very much appreciate if it was released earlier, since that would allow for a much smoother transition and for a better testing.
Re: Python 2.1 out
Sean 'Shaleh' Perry [EMAIL PROTECTED] writes: last I checked it only helped derivatives of python, not python itself. AIUI, the point is that Python 2.1 is a derivative of CNRI Python 1.6.1. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
Re: Python 2.1 out
D-Man [EMAIL PROTECTED] writes: On Wed, Apr 18, 2001 at 10:25:52PM +0200, Florian Weimer wrote: | Steve Purcell [EMAIL PROTECTED] writes: | | Licenses aside, there are the same technical issues with Python 2.1 | as with Python 2.0. | | Python 2.1 seems to print some diagnostic messages during run-time; | this might affect scripts which are invoked in cron jobs. Are you sure they aren't warnings regarding code that will not work as expected in future versions? Yes, I think so. But that doesn't make them less annoying. ;-)
Re: Python 2.1 out
On Thu, Apr 19, 2001 at 10:04:24AM +0200, Florian Weimer wrote: D-Man [EMAIL PROTECTED] writes: On Wed, Apr 18, 2001 at 10:25:52PM +0200, Florian Weimer wrote: | Steve Purcell [EMAIL PROTECTED] writes: | | Licenses aside, there are the same technical issues with Python 2.1 | as with Python 2.0. | | Python 2.1 seems to print some diagnostic messages during run-time; | this might affect scripts which are invoked in cron jobs. Are you sure they aren't warnings regarding code that will not work as expected in future versions? Yes, I think so. But that doesn't make them less annoying. ;-) Could you mail an example of such a message ? Gregor
Re: Python 2.1 out
Gregor Hoffleit [EMAIL PROTECTED] writes: [Python warning messages] Could you mail an example of such a message ? y = None def fun(): y = None def bar(): y bar() fun() results in: file:2: SyntaxWarning: local name 'y' in 'fun' shadows use of 'y' as global in nested scope 'bar' def fun(): There are probably other kinds of warnings; PyErr_Warn is called in a number of places. Python 2.1 provides a mechanism to switch off warnings (the 'warnings' module, don't ask me about details :-/), but by default, they are printed to stderr.
Re: Python 2.1 out
On Thu, Apr 19, 2001 at 12:17:40PM +0200, Florian Weimer wrote: | Gregor Hoffleit [EMAIL PROTECTED] writes: | | [Python warning messages] | | Could you mail an example of such a message ? | | y = None | def fun(): | y = None | def bar(): | y | bar() | | fun() | | results in: | | file:2: SyntaxWarning: local name 'y' in 'fun' shadows use of 'y' as global in nested scope 'bar' | def fun(): Yeah, that code will almost certainly break in 2.2 when nested scopes become mandatory. It may have been intended, but assignment to a local variable overshadowing a global is rarely the intended effect. Anyways, if you want to get rid of those message now, without changing the code use the -W option to the interpreter. Example : $ python -W ignore Scope.py (I created a file called Scope.py with that code in it) See the last paragraph at http://www.python.org/doc/current/lib/warning-filter.html -D
Re: Python 2.1 out
Vasko Miroslav wrote: as Python 2.1 is out, there is no need to keep Python2 and Python152 in Debian, I think. [snip] and code-breakage features like nested scopes are disabled by default. Licenses aside, there are the same technical issues with Python 2.1 as with Python 2.0. The byte code files are incompatible, and so are binaries of extension modules written in C. There could not be a full migration of Debian to Python 2.1 until all extensions have been rebuilt and tested successfully with 2.1. It could also take some time before developers of python-based packages (Zope etc) declare them to be compatible with Python 2.1. I expect this means that Python 1.5.2 will be around for a while yet. -Steve -- Steve Purcell, Pythangelist Get testing at http://pyunit.sourceforge.net/ Any opinions expressed herein are my own and not necessarily those of Yahoo
Re: Python 2.1 out
On Wed, Apr 18, 2001 at 10:25:52PM +0200, Florian Weimer wrote: | Steve Purcell [EMAIL PROTECTED] writes: | | Licenses aside, there are the same technical issues with Python 2.1 | as with Python 2.0. | | Python 2.1 seems to print some diagnostic messages during run-time; | this might affect scripts which are invoked in cron jobs. Are you sure they aren't warnings regarding code that will not work as expected in future versions? -D
Python 2.1 packages?
Hello, With the release of Python 2.1 and legal changes, will we soon be seeing officially packaged Python 2.1 packages in unstable? And if so, how will they relate to the existing Python packages? Will they replace the Python 2.0 packages? Will they be compiled with readline and gdbm support? Which version of IDLE will be included with all Python variants, 0.8? Or does that version depend of Python 2.x features? And related, will wxPython packages be made available for Python 2.1 as well? I would be happy to remove Python 1.5 and keep only Python 2.1, provided that everything that now works with 1.5 will work with 2.1 :-) With greetings, --Tim
