Re: Python 2.{6,7} backports for lenny
* 2010-10-13 10:19, Fabio Tranchitella wrote: > Maybe I'm completely wrong, but... isn't lenny-backports-sloppy for these > type of packages? IIRC, python2.7 could go to lenny-backports-sloppy as > soon as it hits unstable. Uhm, testing... so you are right, it won't happen anytime soon. :) Fabio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101013082338.gc21...@mail.tranchitella.eu
Re: Python 2.{6,7} backports for lenny
* 2010-10-13 10:18, Sandro Tosi wrote: > 2.7 is not meant for squeeze (unless a surprise from the maintainer) so > it won't be in testing anytime soon. Maybe I'm completely wrong, but... isn't lenny-backports-sloppy for these type of packages? IIRC, python2.7 could go to lenny-backports-sloppy as soon as it hits unstable. Fabio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101013081933.gb21...@mail.tranchitella.eu
Python 2.{6,7} backports for lenny
Hello, I recently backported both python 2.6 and 2.7 (actually, 2.6.6-6 and 2.7-8) to lenny for internal use; the packages (only available for amd64, sorry) can be installed adding the following line to your sources.list: deb http://packages.tranchitella.eu/public lenny main Note: these backports cannot be (yet) uploaded to backports.debian.org because the backported packages are not available in testing. I plan to upload these packages to lenny-backports when these versions (or new ones, if any) will migrate to testing. In the meantime, testing, bug reports and/or suggestions are welcome. Best regards. -- Fabio Tranchitella .''`. 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: Digital signature
Re: binary packages with explicit python2.5 build dependency
Hello Matthias, * 2010-09-26 22:52, Matthias Klose wrote: > At least one of the binary packages built by these source packages ends > up with a dependency, recommendation or suggestion on python2.5 without > having an explicit build dependency on python2.5 or python2.5-dev. These packages provide scripts in /usr/bin, one for each supported version of python, eg: /usr/bin/bobo2.5 /usr/bin/bobo2.6 This is the reason why we have the python2.5 dependency; should I upload the package dropping support for python2.5? AFAICK, python2.5 is still supported in Lenny, isn't it? Thanks, Fabio signature.asc Description: Digital signature
Re: psycopg2 2.2.1
* 2010-06-30 18:20, Johan Euphrosine wrote: > I made a tentative package for psycopg2 2.2.1, (I just copied 2.0.14-1 > debian directory) and ran it throught pbuilder. Uploaded, thanks! Fabio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100702133031.gc6...@mail.tranchitella.eu
Re: python 2.6 deb for lenny ?
* 2010-06-25 19:20, Toni Mueller wrote: > The only thing I had to change was to set the libdb-dev dependency from > 4.8 to 4.7, but then, I only compiled on my workstation, which might be > infected with other backports already. > > If you want to make it more official, please step in and tell me what > your changes are. ;) I did the same change on my build (although, I did it with an older version of python2.6). Best regards, Fabio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100628084336.gd17...@mail.tranchitella.eu
Re: [Half-OT] Plone and: Re: python 2.6 deb for lenny ?
* 2010-06-23 21:17, Toni Mueller wrote: > Short story: I want to abandon the UI as soon as possible. Me too, TBH. But.. sorry, there is either plan buildout, or UI (which produces a buildout-ready environment). Everything else (eg. debian packages) has been labeled "messy", "unstable", "old" from the developers themselves. IMHO, the real mess is Plone itself: it can be a great platform, but it is a nightmare to deploy and maintain. Best regards, Fabio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100624045830.gg30...@mail.tranchitella.eu
Re: [Half-OT] Plone and: Re: python 2.6 deb for lenny ?
* 2010-06-23 19:34, Toni Mueller wrote: > Some of you recommended using the Unified Installer, which I have quite > mixed results with. I recently talked to a number of Zope and Plone > experts, who uninanimously recommended to stay clear of the UI. So I'm > back to square one, but I'd still like to use a "system" Python instead > of a fully-local Python under eg. /usr/local. I personally use the unified installer with the system-wide python, using --with-python; if you have system-wide python packages you don't want to expose to the UI, you can use virtenv. Best regards, Fabio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100623174904.gf30...@mail.tranchitella.eu
Re: Python2.4 has been removed, now what for Zopistas and Plonistas? [ADDENDUM]
* 2010-04-27 18:33, Toni Mueller wrote: > I forgot to ask what'd be the best way to go forward for Plonistas? > I really think that there should be some time for Plonistas to upgrade, > which the current scheme does not allow for. I personally use the unified installer, and it works fine; I liked more the debian packages, but it is quite complex to support them so I switched to what is considered by upstream the "only" way to install plone nowadays. Best regards, Fabio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100427181109.gi26...@mail.tranchitella.eu
Re: Python2.4 has been removed, now what for Zopistas and Plonistas?
* 2010-04-27 15:16, Luca Falavigna wrote: > When dealing with python2.4 removal, we asked Fabio about state of the > art of Zope 2.14 and Plone 4. He replied he hadn't way to look at them at > that time, and he would have looked upgrading the whole stack in > April/May. CCing him, to see if things evolved. The current stable release of Plone requires python2.4 and Zope2.10, which we cannot support in squeeze. I see no way to really support them, so I'd prefer to have the packages removed. > If those packages are beyond any repair, maybe filing RM bugs against > them is the way to go. Fabio, thoughts? I agree, feel free to file RM bugs for all the zope-related packages in the archive which depend on python2.4. Best regards, Fabio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100427134245.gh26...@mail.tranchitella.eu
Re: python 2.6 deb for lenny ?
* 2010-04-21 01:17, Bernd Zeimetz wrote: > I think Fabio (kob...@d.o) also wanted to / is working on a backport, > might make sense to co-maintain that with him. CCed him :) I'm definitely interested in co-maintaining the backport (and using my own backport in production already). I'll have a look at the packages from Toni, and see the difference with my own backport. Best regards. Fabio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100421044627.gf2...@mail.tranchitella.eu
Bug#555048: RFA: sqlobject
Package: wnpp Severity: normal I'm going to orphan SQLObject because I don't use it anymore in my projects; the package is already maintained within the debian-python-modules team. Thanks, Fabio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The future of Zope{2,3} and Plone in Debian and Ubuntu
Hello, * 2009-07-05 16:33, Jonas Meurer wrote: > in fact i already prepared and uploaded zope2.11 and also did the last > uploads of zope2.10 and zope-common. and i intend to keep on doing the > work. so yes, i somehow do feel responsible for zope2 in debian :-) > still i would be really glad to have you as backup maintainer, especially > as you have much more zope/python skills than I do. Feel free to keep me in the uploaders field: I'm willing to help as a co-maintainer, but I don't have time to work as the only maintainer of zope2.X. I think we should remove zope2.10 from Debian now, though. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [kob...@debian.org: The future of Zope{2, 3} and Plone in Debian and Ubuntu]
Hello, * 2009-07-02 14:05, Jonas Meurer wrote: > why not wait for zope2.12 with python2.5/2.6 support, upload that one to > debian/unstable and afterwards file a request for removal for > zope2.10/zope2.11/python2.4? I believe that a zope2.12 release candidate > will be published within the next month, given that a beta2 has already > been published on 27. of may. That way we would have a zope2 release > available in debian/unstable all the time would. Zope2.12 is a different source/binary package: why can't we just drop it now, and when the 2.12 release will be out upload it to testing/unstable? I don't see the point of keeping zope2.10 around just because zope2.12 is not ready: I really want to avoid releasing a new stable release of Debian or Ubuntu with zope2.10. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The future of Zope{2,3} and Plone in Debian and Ubuntu
Hello,
* 2009-07-02 14:04, Jonas Meurer wrote:
> I do think that the debian zope managment tools (dzhandle,
> zope-debhelper) do a great job, and I really would be sad to see them
> go.
>
> I already did some housekeeping maintenance work for zope2.{10,11} and
> zope-common in the past, and I intend to continue that work in the
> future.
zope-common is really usable on for Zope2: nobody uses "instances" for the
zope3 stack anymore. Maybe we should make a new upload to zope-common do
remove support for the zope3 stack (which will be removed from unstable
very soon, as a monolithic package).
> Maybe we could just remove zope2.10 from the archive now, wait until a
> zope2.12 release candidate is published, then upload that one, and
> finally remove zope2.11 and python2.4 as well?
I don't see any problem in uploading zope2.12 as soon as it is fine, but
I'm not going to maintain it alone, that's sure. :)
> With that roadmap we at least would have one zope2 version in
> debian/unstable all the time.
It is possible, are you going to commit yourself to maintain it? That would
be great: I'm not a zope2 consumer anymore, so it is quite pointless for me
to maintain it.
Thanks.
--
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http://www.tranchitella.it
_
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Zope-dev] The future of Zope{2, 3} and Plone in Debian and Ubuntu
Hello Andreas, * 2009-06-24 13:29, Andreas Tille wrote: > ... in Debian stable. What about experimental? This is possible, indeed, and I like your idea of orphaning the packages bug keeping them around. Thanks for your suggestion! -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Zope-dev] The future of Zope{2, 3} and Plone in Debian and Ubuntu
Hello, * 2009-06-24 11:20, Sebastien Douche wrote: > Is it possible to keep Python 2.4 with a warning like "we don't provide > support on this version" ? No, it is not possible. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The future of Zope{2,3} and Plone in Debian and Ubuntu
Hello, * 2009-06-24 07:30, Balazs Ree wrote: > What's the reason for the removal of python2.4? Is there a technological > reason, or is this a policy decision? Don't forget that Plone users, who > are also the biggest consumer group of Zope / ZTK, still will be users of > 2.4 for a while. The unified installer is not the only installation > method used for Plone, in fact many users and the majority of deployments > use python + buildout. These users will need to read documentation and do > installation to be able to bootstrap their buildout, which is not exactly > a reason for them to choose Debian / Ubuntu in this case. We already have python2.5 and python2.6; after the release of stable (either Debian or Ubuntu), we have to provide security support for all the packages, and supporting three different versions of python is too much work. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [kob...@debian.org: The future of Zope{2, 3} and Plone in Debian and Ubuntu]
(filtering out some of the interested mailing lists) * 2009-06-23 20:19, Erik Rose wrote: > I'm sad to see Plone support go, as I have a lot of reservations about > how Plone is distributed these days. FWIW, I'm sad too and I share your same reservations about how Plone is distributed. > Actually not; it works in 2.5 and 2.6. 2.4 is unsupported by 2.12, > though it "should work". > http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html#support-for-newer-python-versions My fault, I wanted to write 2.11 (which is the current stable release, as today). Sorry for the wrong number. > Were you aware that we've renumbered the releases and inserted a less > ambitious Plone 4, which should be in beta by the end of the year? It > will run on (and require) Zope 2.12. Plone is finally joining the modern > Python world. :-) I don't exclude to support Zope 2.x again in Debian and Ubuntu, but I really think that in this moment dropping the packages is the best solution: we will finally be able to drop python2.4. For Plone, after 5 years of maintenance in Debian, I'm sure that *not* having an official package (eg. included in Debian stable) is the best option for our users. -- Fabio Tranchitella .''`. 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: Digital signature
The future of Zope{2,3} and Plone in Debian and Ubuntu
Hello all! In the last couple of weeks Brian Sutherland, Matthias Klose and I worked together to improve the Zope packaging for Debian and Ubuntu. This e-mail summarizes the problems we faced, the decisions that have been taken and the changes that we will upload to experimental and unstable in the next weeks. Short summary = We switch from a monolithic Zope 3 package to individual packages for the libraries that are part of the ZTK (Zope Toolkit). Zope instance management tools are not supported anymore, as we suggest the use of WSGI. We also drop support for Zope 2 and Plone in Debian and Ubuntu, asking for the removal of the packages from the distribution. Background == It is a known fact that the Zope community, as well as the Plone one, prefers to use other means of installation for their software and usually dislikes the integration of Zope and Plone with the Debian and Ubuntu distributions. The suggested upstream way to install plone, for example, is the unified installer. ZTK developers suggest the use of zc.buildout. These tools create an isolated environment where it is possible to develop and run your software with a very limited interactions with the rest of the system. I think it is better to split the two worlds, Zope2 and ZTK, to better understand their specific needs. ZTK === Right now zope3 is a monolithic source and binary package which provides all the python libraries released inside the old-style monolithic tarball called Zope 3. Upstream stopped distributing Zope 3 as a monolithic tarball, transforming the concept of a monolithic "Zope 3" framework into a collection of independent python libraries (the ZTK, Zope Toolkit). The eggification of Zope 3 is a great path towards interoperability between different python frameworks, and we decided to modify our packaging methods in this direction: each library will be packaged as an independent source/binary package. Considering that WSGI is the actual standard for python web frameworks the instance management tools, previously part of the zope3 package, won't be packaged anymore: the most important WSGI servers and tools are already packaged and available in the archive. It is worth mentioning that the last monolithic release only supports python2.5, but some of the libraries that are part of the Zope Toolkit already support python2.6. It's also important to note that a lot of software in the monolithic tarball will not be present in the ZTK packages because it is deprecated/unmaintained at source and has large/complex dependency trees. For these reasons we decided to focus on relatively stable packages which have sane dependency graphs. Other packages may be maintained, but outside the official repositories. We will only maintain what members of the Debian/Ubuntu Zope team use, focusing on automatic testing to provide the high quality standards. As of today, these are the packages supported by the team: - transaction - zc.lockfile - ZConfig - zdaemon - ZODB3 - zope.authentication - zope.browser - zope.cachedescriptors - zope.component - zope.configuration - zope.dottedname - zope.event - zope.exceptions - zope.hookable - zope.i18nmessageid - zope.interface - zope.location - zope.proxy - zope.publisher - zope.schema - zope.security - zope.testbrowser - zope.testing - zope.traversing The aforementioned policy is also available from the team web page: http://pkg-zope.alioth.debian.org. Comments and suggestions are welcome! Zope 2 and Plone Zope 2 and Plone are obviously related, so the future of one of the two influences the other one. The main problem for Zope2 is that the current stable upstream branch (2.12) still requires pthon2.4. This is not acceptable in Debian and Ubuntu, and Zope 2 is right now the only stopper for the removal of python2.4 from both Debian and Ubuntu. Even worse, the current stable Plone releases requires Zope 2.10, which we suppose will never support anything but python2.4 in the foreseeable future. The new major upstream branch (Plone 4) is still far from being released, which means that the only way to support Plone and Zope 2.x in Debian and Ubuntu is to keep python2.4 in the distribution. For this reason, together with the upstream suggestions to use the unified installer and zc.buildout as primary tools for deploying Zope 2 and Plone, the Debian/Ubuntu Zope Team decided to drop support for Zope 2, Plone and all the other Zope 2 products. We will file requests of removal for all the Zope and Plone packages from the archive. Thanks for reading this! Fabio Tranchitella on behalf of the Debian/Ubuntu Zope Team -- Fabio Tranchitella .''`. Proud Debian GNU/Linux developer, admin and user.: :' : `. `&#x
The future of Zope{2,3} and Plone in Debian and Ubuntu
Hello all! In the last couple of weeks Brian Sutherland, Matthias Klose and I worked together to improve the Zope packaging for Debian and Ubuntu. This e-mail summarizes the problems we faced, the decisions that have been taken and the changes that we will upload to experimental and unstable in the next weeks. Short summary = We switch from a monolithic Zope 3 package to individual packages for the libraries that are part of the ZTK (Zope Toolkit). Zope instance management tools are not supported anymore, as we suggest the use of WSGI. We also drop support for Zope 2 and Plone in Debian and Ubuntu, asking for the removal of the packages from the distribution. Background == It is a known fact that the Zope community, as well as the Plone one, prefers to use other means of installation for their software and usually dislikes the integration of Zope and Plone with the Debian and Ubuntu distributions. The suggested upstream way to install plone, for example, is the unified installer. ZTK developers suggest the use of zc.buildout. These tools create an isolated environment where it is possible to develop and run your software with a very limited interactions with the rest of the system. I think it is better to split the two worlds, Zope2 and ZTK, to better understand their specific needs. ZTK === Right now zope3 is a monolithic source and binary package which provides all the python libraries released inside the old-style monolithic tarball called Zope 3. Upstream stopped distributing Zope 3 as a monolithic tarball, transforming the concept of a monolithic "Zope 3" framework into a collection of independent python libraries (the ZTK, Zope Toolkit). The eggification of Zope 3 is a great path towards interoperability between different python frameworks, and we decided to modify our packaging methods in this direction: each library will be packaged as an independent source/binary package. Considering that WSGI is the actual standard for python web frameworks the instance management tools, previously part of the zope3 package, won't be packaged anymore: the most important WSGI servers and tools are already packaged and available in the archive. It is worth mentioning that the last monolithic release only supports python2.5, but some of the libraries that are part of the Zope Toolkit already support python2.6. It's also important to note that a lot of software in the monolithic tarball will not be present in the ZTK packages because it is deprecated/unmaintained at source and has large/complex dependency trees. For these reasons we decided to focus on relatively stable packages which have sane dependency graphs. Other packages may be maintained, but outside the official repositories. We will only maintain what members of the Debian/Ubuntu Zope team use, focusing on automatic testing to provide the high quality standards. As of today, these are the packages supported by the team: - transaction - zc.lockfile - ZConfig - zdaemon - ZODB3 - zope.authentication - zope.browser - zope.cachedescriptors - zope.component - zope.configuration - zope.dottedname - zope.event - zope.exceptions - zope.hookable - zope.i18nmessageid - zope.interface - zope.location - zope.proxy - zope.publisher - zope.schema - zope.security - zope.testbrowser - zope.testing - zope.traversing The aforementioned policy is also available from the team web page: http://pkg-zope.alioth.debian.org. Comments and suggestions are welcome! Zope 2 and Plone Zope 2 and Plone are obviously related, so the future of one of the two influences the other one. The main problem for Zope2 is that the current stable upstream branch (2.12) still requires pthon2.4. This is not acceptable in Debian and Ubuntu, and Zope 2 is right now the only stopper for the removal of python2.4 from both Debian and Ubuntu. Even worse, the current stable Plone releases requires Zope 2.10, which we suppose will never support anything but python2.4 in the foreseeable future. The new major upstream branch (Plone 4) is still far from being released, which means that the only way to support Plone and Zope 2.x in Debian and Ubuntu is to keep python2.4 in the distribution. For this reason, together with the upstream suggestions to use the unified installer and zc.buildout as primary tools for deploying Zope 2 and Plone, the Debian/Ubuntu Zope Team decided to drop support for Zope 2, Plone and all the other Zope 2 products. We will file requests of removal for all the Zope and Plone packages from the archive. Thanks for reading this! Fabio Tranchitella on behalf of the Debian/Ubuntu Zope Team -- Fabio Tranchitella .''`. Proud Debian GNU/Linux developer, admin and user.: :' : `. `&#x
Re: is psycopg2 broken in etch?
Hello Emil, * 2008-07-17 17:18, Emil Pedersen wrote: > I have (very simple) python program that makes use of psycopg2 to access > a postgresql database (still very simple). Can you post here your script? It would help to debug the situation. > Since I'm on Debian/Etch amd64, I wonder if the "natural" version of > psycopg2 (2.0.5.1-6) have had any fixes backported from never versions? I think 2.0.5.1 already contains the fix (2.0.5.1 != 2.0.5). > On a side note I tried to bring back the version from Sid (using apt-get > source ...) but there were too many dependencys for me to feel comfort > about. Is there some easy way to "strip it" from stuff I know I wont be > using (e.i. debug and zope packages)? You have to rebuild the package in etch, because it contains a binary library which is depending on a newer libc6 and so on. Best regards, -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: test upgrade, Re: Bug#411657: Transition from sarge-etch for zope packages
* 2007-02-23 11:15, wrote: > hi, Hi! > In the next 4 hours I repeatedly tried to use the migration tool of Plone > to update my Plone site. It turned out that the new version of > exUserFolder 0.50 is completely different , so I removed from the > instance and manually put my old (patched) 0.20 into it ; and it turns > out that I18NLayer is incompatible with Plone 2.5 (so I deleted all my > I18NLayer files from the instance - of course, this is unacceptable for a > "real" upgrade, but at a certain point I was also curious to see if I > could ever get to a working instance!). These are all problems related to upstream upgrade paths and there is nothing which we (as Debian Zope Team) could do. From my experience, upgrade paths in Plone 2.0 -> 2.5 are quite painful as a lot of background code changed. > --- my failed "semi upgrade" > > I created another instance w/o Etch products > # dzhandle -z 2.9 make-instance -m manual dida_oldplone > I copied all my data and personal products ; and I also > copied all Plone 2.0 products from Sarge into > /var/var/lib/zope2.9/instance/dida_oldplone/Products > So my goal was to just upgrade zope2.7 -> zope2.9 , > and be able to run my portal in Etch (and leave > the Plone update to a later moment). > It failed in a worse way: when I try to access any > folder in management mode , I get > 2007-02-23T09:50:50 ERROR Zope.SiteErrorLog > http://localhost:9673/Control_Panel/Products/manage_main > Traceback (innermost last): > Module ZPublisher.Publish, line 115, in publish > Module ZPublisher.mapply, line 88, in mapply > Module ZPublisher.Publish, line 41, in call_object > Module Shared.DC.Scripts.Bindings, line 311, in __call__ > Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec > Module App.special_dtml, line 176, in _exec > Module DocumentTemplate.DT_Let, line 76, in render > Module DocumentTemplate.DT_Util, line 196, in eval >- __traceback_info__: REQUEST > Module , line 0, in ? > NameError: name 'getDefaultSorting' is not defined Same as before, with a note that this is a known problem: try to remove ExternalEditor from your products folder, it should fix the portal. Cheers, -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Digital signature
Re: Bug#411657: Transition from sarge-etch for zope packages
Hi Steve, first of all, thanks for your reply. * 2007-02-21 21:10, Steve Langasek wrote: > > I think that changing the dependency on zope-common to something like: > > Depends: python (>= 2.4) | python2.4, ... > > would do the trick, > > No, this would definitely be wrong. The package either uses > /usr/bin/python2.4 as an interpreter or it uses /usr/bin/python -- whichever > one it uses is the package it should be depending on. In this case, I would switch back to python2.4 instead of python (>= 2.4) to provide a smooth upgrade path. > Using /usr/bin/python and depending on python (>= 2.4) has the advantage > that the package will be automatically compatible with future versions of > python, introducing the possibility of a smoother upgrade for etch->lenny. > This shouldn't be considered to outweigh having a smooth upgrade for > sarge->etch though; OTOH, I also don't see why it's important to avoid > removal of zope2.7 on upgrade, it /is/ an obsolete package from the etch > perspective. FWIW, I have customers still running zope (= 2.6) in production. Having both an old version of zope and the new one allows smooth migration, and it is a must-have for a solid distribution like Debian is. At this point, I just would like to know what Matthias think about it before reverting his change. Cheers, -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Digital signature
Re: Bug#411657: Transition from sarge-etch for zope packages
* 2007-02-21 17:33, Jonas Meurer wrote: > If i understand it correctly, zope-common should depend on python2.4, > but not on python (>= 2.4), and use python2.4 directly. > > This would avoid an upgrade of the default python package and just > introduce the new python2.4 package. This way, the old python (<= 2.3), > python2.3 and zope2.7 could stay on the upgraded system. Sure, and it used to be so, but Matthias Klose (python maintainer) uploaded a new release of zope-common which depends on python (>= 2.4) two weeks ago. This is why I'm asking here. Cheers, -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Digital signature
Re: Bug#411657: Transition from sarge-etch for zope packages
* 2007-02-21 15:17, A Mennucc wrote: > > > > Depends: python (>= 2.4) | python2.4, ... > > > > would do the trick, leaving the old python package around without removing > > python2.3, but I'm not even sure and to say the truth I do not understand > > why the dependency on python2.4 has been replaced with python (>= 2.4). > > quite on the opposite, I fail to see why this would help. > May you explain better? Because zope-common requires python (>= 2.4), which conflicts with the sarge version of python2.3. So far, so good. If the user managed to install zope-common, he already has installed python2.4 in his system (because zope-common only works with python2.4) from sarge-backports, testing or unstable. In this scenario, the dependency block "python (>= 2.4) | python2.4" is satisfied because python2.4 is already installed and apt does not have to install the new python package, which would lead to the python2.3 removal. Urgh, my english is terrible.. Is it more clear now? I do not know if this would actually work, and all I need now is a god fix for #411657. Thanks! -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Transition from sarge-etch for zope packages
Hello all, I need some help to find a fix for #411657. The problem is that sarge included the zope2.7 package which requires python2.3, but python2.3 will not be shipped with etch and the current python package conflicts with it. Matthias uploaded zope-common 0.5.31 with the following change: * debian/control: Depend on the unversioned python package. Which means that zope-common now depends on python (>= 2.4) instead of python2.4. After this change, upgrading from sarge to etch means that the sarge version of python2.3 will be uninstalled as well as zope2.7, which I would like to avoid. It will be common for our users to upgrade from sarge to etch with sites running zope2.7, and it would be a good thing to let them run both in order to manually upgrade their instances. See here: $ apt-cache show python | grep Conflicts Conflicts: python2.3 (<< 2.3.5-14), python2.1 (<= 2.1.2), python-xmlbase, python-csv, python-bz2, python-base, python-central (<< 0.5.5) I think that changing the dependency on zope-common to something like: Depends: python (>= 2.4) | python2.4, ... would do the trick, leaving the old python package around without removing python2.3, but I'm not even sure and to say the truth I do not understand why the dependency on python2.4 has been replaced with python (>= 2.4). Any idea? Thanks in advance, -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Digital signature
Re: Bug#404355: python-psycopg: Python 2.5 support missing
* 2006-12-26 21:53, Piotr Ozarowski wrote: > > * 2006-12-23 23:12, Christian Joergensen wrote: > > > It seems as if there is no support for python 2.5 in this package: > > $ pyversions --supported > python2.4 Thanks Piotr, I'll keep the bug report open for lenny then. Thanks again, -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#404355: python-psycopg: Python 2.5 support missing
Hi Christian, * 2006-12-23 23:12, Christian Joergensen wrote: > Package: python-psycopg > Version: 1.1.21-13 > Severity: wishlist > > Hello > > It seems as if there is no support for python 2.5 in this package: Uhm, you are right: python-psycopg misses the 2.5 support, but I do not understand if this should be fixed in etch or just in etch+1. Running pyversions does not provide python2.5 with any of the command line switches. Cc'ing [EMAIL PROTECTED], so somebody with a better knowledge of the python policy could help me to understand if I need to fix something in my package in order to provide a python2.5-compatible package. Thanks, -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Digital signature
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 Fri, 2006-04-07 at 12:33 +0200, Jeroen van Wolffelaar wrote: > zopeinterface has an unsatisfied build-dependency: python2.2-dev This package can be removed, pythonX-zopeinterface are now built from zope3 source 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: New python maintenance team
On Thu, 2006-04-06 at 19:11 +0200, Matthias Klose wrote: > I'm sure one or more teams could be useful, packagers should be able > to decide on their own if they want to join a team. There are lot of > packages, where people did ask for maintainance (i.e. python-xml), but > got no response. On the other teams like deb-scipy seem to just work. Just a quick note: I'm adopting python-xml as Zope team and I'll upload the package with the new maintainer soon (zope packages depends on it). -- 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-sqlobject v0.7 package?
Il giorno ven, 20/01/2006 alle 18.10 +0100, Ramon Bastiaans ha scritto: > Hi all, > > I was wondering on the status of a version 0.7 package for python-sqlobject. > It's current package is still at version 0.6, while version 0.7 has been > released in October 2005. > > It seems the package maintainer has been notified of the new version in > November 2005 through the bug report system, though there is still no > new package available or reply from the maintainer for that matter. > > I would like to use some functionality from the new version and would > love an update or status on it. > > Kind regards, > - Ramon. I'm working on this, and I'll adopt the package. Expect an upload of 0.7-1 in a few days. -- 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: [Pkg-zope-developers] Re: [Zope] A few questions...
Il giorno mer, 26-01-2005 alle 12:09 +0100, A Mennucc ha scritto: > well only important news pass through :-) Ok, so the list is not dead but is has very low traffic. :) > actually, there was a discussion some time ago , which I try to summarize: > there should exist a 'zope-common' package, containing: the zope-policy, > zope-admin-guide, AND all the scripts and debconf templates to > restart zope and/or zope2.7 when a new zope package is installed. > > Unfortunately the main mantainer of zope 2.6, namely Luca, is mostly MIA > So the above problem was never fully addressed I'd like to take over his idea. Is there someone which is working on this or I have to start from the scratch? Is there someone interested in helping me to design this solution? -- Fabio Tranchitella http://www.kobold.it Studio Tranchitella Assoc. Professionale http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: [Zope] A few questions...
Il giorno mar, 25-01-2005 alle 15:33 -0700, Joel Aelwyn ha scritto: > [ Mail-Followup-To set; please *do* Cc me, as I do not currently ] > [ subscribe to the -python list, though it appears to be the proper place ] > [ for Zope discussions, at least from what I can find in the archives.] > [ Please redirect me if somewhere else is more appropriate. ] > > So I have relatively recently taken over a Zope package, and while it is > now in (basically) good shape, there are a couple of technical points I > want to clear up to make sure I'm doing it right, since what I can find on > the mailing list archives isn't entirely conclusive. I think the right place for your email is the mailing list of zope debian packages developers [1], but the list seems to be almost dead. > 1) Is it proper (assuming that the package works under both Zope 2.6 and >Zope 2.7) to Depend on 'zope | zope2.7'? It seems like it should be, but >I wanted to double-check. IMHO the dependency should be "zope2.7 | zope", so the newer version will be automatically installed if needed. > 2) Usage of debconf templates. The debconf manual (and the maintainer) >seem to think that every package which uses the shared Zope restart >template needs to provide an identical copy. My opinion on this issue is that for zope packages you do not use the shared template, just read its value in debian/postinst. For this reason, you haven't (and you shouldn't) provide the template: you'll never ask the user for that question so providing the template have really no sense, this just create additional work for the translators. Here an example from one of my packages: $ cat zope-cmfphoto-0.5.0/debian/postinst | grep "shared/zope" db_get "shared/zope/restart" || true If db_get fails (the package zope isn't installed, or the template hasn't been initialized, or something else) the "or true" prevents the maintainer script to return a bad exit code. So, why for the hell you provide the template in your package? :) After this, I maintain a lot of zope packages. Packaging this type of software is quite easy, and often it is a repetitive job. For this reason I'd like to see a dh_zope debhelper script, so the packages (at least the easy ones) could get rid of their templates and their maintainer scripts. I know that Luca De Vitis started working on it, and I tried to mail him but I haven't received any answer so far. His last upload to zope package is on 2004, February. Does anyone know if he is still around? Fabio [1] [EMAIL PROTECTED] -- Fabio Tranchitella http://www.kobold.it Studio Tranchitella Assoc. Professionale http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: Python modules for every supported version
Il gio, 2004-06-17 alle 03:26, Donovan Baarda ha scritto: > >From looking at it, the main thing we'd loose by dropping python2.1 is > jython. Anyone using it? Looking at http://popcon.debian.org/by_inst seems there is enough people that use it... I've looked also on http://www.jython.org, they say: "We expect then a new release for the summer, with 2.2 and some 2.3 features. Leading up to the release this site will be revamped." (Apr 2004) Mmm... I'd like to drop python2.1 before the release of sarge, leaving only python2.2 and python2.3 in the prospective stable. What can we do? Is there someone who disagree with Donovan and me and wants to leave python2.1 in sarge? Thanks, -- Fabio Tranchitella kobold.it, Turin, Italy - Free is better! --- <http://www.kobold.it>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> --- GPG Key fingerprint: 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: Python modules for every supported version
Il mer, 2004-06-16 alle 04:03, Donovan Baarda ha scritto: > There are various reasons why you might need a non-current Python > package. Typically it is for a legacy Python application that has not > yet been "upgraded". Now I understand your point of view... So we have to try to complete the python 2.1->2.2 transition before talking about 2.2->2.3 and so on.. IMHO Actually in sarge there are too many versions of python (python2.1, python2.2 and python2.3).. :) > In the days when the Python policy was being put together, Python > transitions were non-trivial, and even though the 2.2 -> 2.3 transition > was relatively painless, there is no reason to assume that future > transitions will be as minor. Even now, there are still several > applications, including Zope, still running on python2.2, when the > default is python2.3 and has been for some time. Policy? What I missed? I tried to find a Debian Python policy, but I didn't have enough luck. It is not listed on http://www.debian.org/devel/ like the perl policy or the java policy... So exists (or will exist, if actually doesn't) an official debian python policy? > If we were to revert to a "only one version of Python" policy, we would > be faced with the choice of delaying Python upgrades until _everything_ > has been upgraded, or regularly breaking many important Python packages > until they "catch up" with the latest Python. For applications like > Zope, you would never have a working package, because it seems to be > perpetually dependant on the "latest-1" version of Python. I agree with Donovan. IMHO an approch like the perl one can only confuse the users and create a lot of problems during the transitions. But as I wrote before I understand a transition between two versions, but not between three (2.1, 2.2 and 2.3). What about source and binary packages? For example python-psycopg source package generates four pythonX.Y-related binary packages (yes, also some others zope-related, I know ...) and a dummy package python-psycopg which depends on python2.3 and python2.3-psycopg. Is this approch correct? Donovan suggests (as I understood) to build different source packages for the different python versions (and/or for the dummy package). Why shouldn't I use only one source package to build python2.3-foo, python2.4-foo and python-foo (which switch the default during the transition)? > I agree, where unnecessary is defined as; there are no packages that > depend on this package that do not have a python2.2 version, and the > maintainer wants to have it removed. > > Package dependencies can be used to check that removing it doesn't break > something, but maintainers of individual packages have the best idea of > how important legacy packages are for that particular package. Here in attachment there is a statistical report on which version of python depends every python-related package. It was build with testing main/non-free/contrib Packages files, so it is closely related to sarge. Near the name of the package, there is a flag (automatically generated so I'm not sure about it) which say if the package is compatible with python2.3 (Y) or not (N). IMHO even if we can't drop python2.2 because zope (and other packages) depends on it, we have to try to drop python2.1 and python2.1-* from sarge. Having a quick look through the report, I think it isn't too hard to drop them. Talk to you later, and have a good day. -- Fabio Tranchitella kobold.it, Turin, Italy - Free is better! --- <http://www.kobold.it>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> --- GPG Key fingerprint: 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 Packages which depends on, recommends or suggests python1.5: - [Y] libzorp2-dev Depends on : python-dev (>= 1.5.2) - [Y] mftrace Depends on : python2.3 | python2.2 | python2.1 | python1.5 - [Y] sgmltools-lite Depends on : python (>= 1.5) - [Y] xmltv-util Depends on : python (>= 1.5) - [Y] yodl Recommends : python (>= 1.5.2-4) Packages which depends on, recommends or suggests python2.1: - [Y] doc-central Depends on : python (>= 2.1) - [Y] enemies-of-carlotta Depends on : python (>= 2.1) - [Y] fetchmailconf Depends on : python (>= 2.1), python-tk - [N] idle-python2.1 Depends on : python2.1, python2.1-tk (>= 2.1.3-23) - [Y] jaxml Depends on : python2.3 | python2.1 | python2.2 - [N] jython Depends on : python2.1 Suggests : python2.1-doc - [N] jython-doc Suggests : python2.1-doc - [N] libapache-mod-python2.1
Re: Python modules for every supported version
Il mar, 2004-06-15 alle 17:13, Cory Dodt ha scritto: > There is an implicit assumption here that python modules will actually work > for all versions of Python. This is clearly not the case; some will use > features only available in (some newer version X.y). Furthermore, at least a > few (distutils and difflib are notable) are available only for the versions in > which they would not normally be available anyway. (They were added to the > stdlib later, iirc.) It would be undesirable to package them for later > versions and do extra work pulling those parts out of the stdlib, and probably > impossible to package them for earlier versions since they would not work
Python modules for every supported version
Hi! I'm not (yet) an official dd, but I started my applicant process some weeks ago so I hope I'll be a DD soon. I'm interested in adopting python-gd (my package is available on http://www.kobold.it/python-gd). Actually there is only a whishlist bug for this package (#223580) which ask for a versioned packaging for the module. Actually it is available only for python2.3, but there are no problems to compile and package it for other version (python2.1 and python2.2) so I did. I also did a statistical report for the python modules availables in stable, testing, unstable and experimental, I attached it to this e-mail. My conclusion is that there are a lot of modules which are not versioned and are available only for particular versions of python without motivation. IMHO, can be very useful if every maintaner have to package versioned python modules. I know people who use python2.1 or python2.2 and I think Debian should think also about them. What about the policy? Is there something which suggests to do this? What do you thing about my proposal? Thanks in advance, Fabio T. -- Fabio Tranchitella kobold.it, Turin, Italy - Free is better! --- <http://www.kobold.it>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> --- GPG Key fingerprint: 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 epydoc => python, python2.3, python2.2, python2.1 eyed3 => python distutils => python1.5 weblib-doc => python xlib=> python, python2.3, python2.2, python2.1 oss => python, python2.3, python2.2, python2.1 pcgi=> python gnome2-dev => python psyco => python, python2.3, python2.2, python2.1 netcdf => python gdbm=> python, python2.3, python2.2, python2.1, python1.5 omniorb2=> python, python2.3, python2.2, python2.1 osd => python, python2.3, python2.2, python2.1 extclass=> python, python2.3, python2.2, python2.1 xml => python, python2.3, python2.2, python2.1 tables => python, python2.3, python2.2 samba => python2.3 vte => python cdb => python gdchart => python vtk => python gtk => python subversion => python2.3 kjbuckets => python, python2.3, python2.2, python2.1 cjkcodecs => python2.3, python2.2, python2.1 twisted-conch => python, python2.3, python2.2 sip-dev => python2.3, python2.2, python2.1 scgi=> python2.3 egenix-mxtools => python, python2.3, python2.2, python2.1, python1.5 scientific => python pygame => python, python2.3, python2.2 hip => python pyx-doc => python bsddb3 => python, python2.3, python2.2 editobj => python, python2.3 numarray-doc=> python textwrap=> python2.2, python2.1 gtk2=> python, python2.3, python2.2 mpi => python simpletal => python, python2.3, python2.2 gtk-1.2 => python dictclient => python2.3 mpz => python, python2.3, python2.2, python2.1, python1.5 pygresql=> python, python2.3, python2.2 gnuradio=> python qt3-gl => python, python2.3 gdk-imlib => python syck=> python, python2.3 xdg => python pylibacl=> python, python2.3, python2.2 crypto => python, python2.3, python2.2, python2.1 soappy => python xlib-doc=> python comedilib => python japanese-codecs => python, python2.3, python2.2 mode=> python egenix-mxstack => python, python2.3, python2.2, python2.1, python1.5 geoip => python davlib => python dbus=> python2.3 fixedpoint => python, python2.3, python2.2 rpy-doc => python pyao=> python pyx => python, python2.3, python2.2 parted => python pmw => python pymad => python rrd => python, python2.3, python2.2 elisp => python, python2.2, python2.1 numeric => python, python2.3, python2.2, python2.1 xmms=> python, python2.3, python2.2, python2.1 yappy => python, python2.3, python2.2 mysqldb => python, python2.3, python2.2, python2.1 gnome2 => python, python2.3, python2.2 examples
