Re: python2.5 fails to import pygtk and gtk modules
On ti, 2007-01-16 at 09:53 +0200, Tshepang Lekhonkhobe wrote: Maybe there should be a big warning in the release notes (or elsewhere) that python2.5 supports NOT the loading of (certain?) external modules... Sure, something like Python 2.5 is included in etch, but is not fully supported by all extension modules. Python 2.5 is the default version of Python in etch.. Since you're the one feeling strongly about this, please feel free to file a wishlist bug against the release notes. :) -- Programming should be fun, otherwise you're doing something wrong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
On 1/2/07, Matthias Klose [EMAIL PROTECTED] wrote: Alexandre Fayolle writes: Am I the only one with a mixed feeling about this? I mean, we spent time last spring updating our packages to use the new Python policy, write nice loops in debian/rules to build for all versions specified by `pyversions -r -v`. Now we would need to tweak the Makefile again and clutter it with a hardcoded 2.5 in the list even though this version is requested debian/control (or in some other place if you chose the other way without XS-Python-Version). I have to admit that I am a bit disapointed by this, to say the least. Why are we shipping python2.5 in etch if we don't ship the python extension modules people expect to find (PIL, mx.DateTime, Numeric...) When etch/sid went into UVF after the 2.5 release, many depending packages and extensions were not yet usable/buildable for 2.5. Adding 2.5 was not considered an option after talking with the release team (Andreas Barth), because it would have introduced a lot of RC reports, which either needed to be fixed by new upstream versions or disabling 2.5 support for this extension. Explicitely adding support for 2.5 on a per package base doesn't introduce these extra RC failures during our release process at the cost of having the burden on the package maintainer, not the release team. Looking at mx and numeric, support for 2.5 can be added, but for example PIL explicitely states in the 1.1.6 release notes that this version adds complete support for 2.5. Maybe support for 2.5 for all extensions looks possible now, but at the time of the UVF it wasn't. You might want to create a python-etch repository and rebuild all extensions where possible to support 2.5, and add new upstream versions where necessary. Once done, propose the versions in this repository to the release team, but I doubt it will be allowed into etch. Mixed feeling yes, but IMO unavoidable with our release schedule for etch. Is there work done on this? If not may python2.5 be removed from Etch, or should I file a grave bug, if python2.5 doesn't load pygtk and gtk modules, then what use is it?. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
On ma, 2007-01-15 at 18:15 +0200, Tshepang Lekhonkhobe wrote: On 1/2/07, Matthias Klose [EMAIL PROTECTED] wrote: Alexandre Fayolle writes: Am I the only one with a mixed feeling about this? I mean, we spent time last spring updating our packages to use the new Python policy, write nice loops in debian/rules to build for all versions specified by `pyversions -r -v`. Now we would need to tweak the Makefile again and clutter it with a hardcoded 2.5 in the list even though this version is requested debian/control (or in some other place if you chose the other way without XS-Python-Version). I have to admit that I am a bit disapointed by this, to say the least. Why are we shipping python2.5 in etch if we don't ship the python extension modules people expect to find (PIL, mx.DateTime, Numeric...) When etch/sid went into UVF after the 2.5 release, many depending packages and extensions were not yet usable/buildable for 2.5. Adding 2.5 was not considered an option after talking with the release team (Andreas Barth), because it would have introduced a lot of RC reports, which either needed to be fixed by new upstream versions or disabling 2.5 support for this extension. Explicitely adding support for 2.5 on a per package base doesn't introduce these extra RC failures during our release process at the cost of having the burden on the package maintainer, not the release team. Looking at mx and numeric, support for 2.5 can be added, but for example PIL explicitely states in the 1.1.6 release notes that this version adds complete support for 2.5. Maybe support for 2.5 for all extensions looks possible now, but at the time of the UVF it wasn't. You might want to create a python-etch repository and rebuild all extensions where possible to support 2.5, and add new upstream versions where necessary. Once done, propose the versions in this repository to the release team, but I doubt it will be allowed into etch. Mixed feeling yes, but IMO unavoidable with our release schedule for etch. Is there work done on this? If not may python2.5 be removed from Etch, or should I file a grave bug, if python2.5 doesn't load pygtk and gtk modules, then what use is it?. Er, there's plenty of use for plain 2.5, without any extension -- Programming should be fun, otherwise you're doing something wrong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
Gah, I meant to press control-Backspace, not control-Enter. Sorry. On ma, 2007-01-15 at 16:28 +, Lars Wirzenius wrote: On ma, 2007-01-15 at 18:15 +0200, Tshepang Lekhonkhobe wrote: Is there work done on this? If not may python2.5 be removed from Etch, or should I file a grave bug, if python2.5 doesn't load pygtk and gtk modules, then what use is it?. Er, there's plenty of use for plain 2.5, without any extension I meant to say: there's plenty of use for plain 2.5, without any extension modules. For example, most of my code works with any version of Python from 2.1 onwards, and it's nice to be able to verify this, so having 2.5 packages is certainly useful to me. It will also make it easier to backport extension modules after etch is released. (I'm not opposed to removing 2.5 from etch, if the release managers deem it the best course of action, but doesn't work with pygtk isn't a reason, in my rather strong opinion.) -- RFC 1437 - yet another MIME specification Microsoft ignores -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
On 1/15/07, Lars Wirzenius [EMAIL PROTECTED] wrote: Gah, I meant to press control-Backspace, not control-Enter. Sorry. On ma, 2007-01-15 at 16:28 +, Lars Wirzenius wrote: On ma, 2007-01-15 at 18:15 +0200, Tshepang Lekhonkhobe wrote: Is there work done on this? If not may python2.5 be removed from Etch, or should I file a grave bug, if python2.5 doesn't load pygtk and gtk modules, then what use is it?. Er, there's plenty of use for plain 2.5, without any extension I meant to say: there's plenty of use for plain 2.5, without any extension modules. For example, most of my code works with any version of Python from 2.1 onwards, and it's nice to be able to verify this, so having 2.5 packages is certainly useful to me. It will also make it easier to backport extension modules after etch is released. (I'm not opposed to removing 2.5 from etch, if the release managers deem it the best course of action, but doesn't work with pygtk isn't a reason, in my rather strong opinion.) Maybe there should be a big warning in the release notes (or elsewhere) that python2.5 supports NOT the loading of (certain?) external modules... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
Hi, On Tue, Jan 02, 2007, Tshepang Lekhonkhobe wrote: I tried to do some development using Etch's python2.5, but it fails to import pygtk and gtk modules and this is a regression IIRC. v2.4 works fine. pyversions --supported only returns python2.4, so the source package does not build the 2.5 flavor. Either patch pygtk's debian/rules or patch pyversions and rebuild pygtk. Cheers, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
On Tue, Jan 02, 2007 at 03:20:10PM +0100, Loïc Minier wrote: Hi, On Tue, Jan 02, 2007, Tshepang Lekhonkhobe wrote: I tried to do some development using Etch's python2.5, but it fails to import pygtk and gtk modules and this is a regression IIRC. v2.4 works fine. pyversions --supported only returns python2.4, so the source package does not build the 2.5 flavor. Either patch pygtk's debian/rules or patch pyversions and rebuild pygtk. or do that the clean way: edit /usr/share/python/debian_defaults Not sure what has to be done though to force the byte compilation and links creation for the pure modules, and that won't compile binary extention either anyway (but maybe pygtk already forces it I don't know I shall say, I've not checked). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpN0Ut8wE6cv.pgp Description: PGP signature
Re: python2.5 fails to import pygtk and gtk modules
On Tue, Jan 02, 2007 at 03:20:10PM +0100, Loïc Minier wrote: Hi, On Tue, Jan 02, 2007, Tshepang Lekhonkhobe wrote: I tried to do some development using Etch's python2.5, but it fails to import pygtk and gtk modules and this is a regression IIRC. v2.4 works fine. pyversions --supported only returns python2.4, so the source package does not build the 2.5 flavor. Either patch pygtk's debian/rules or patch pyversions and rebuild pygtk. Happy new year everyone. Am I the only one with a mixed feeling about this? I mean, we spent time last spring updating our packages to use the new Python policy, write nice loops in debian/rules to build for all versions specified by `pyversions -r -v`. Now we would need to tweak the Makefile again and clutter it with a hardcoded 2.5 in the list even though this version is requested debian/control (or in some other place if you chose the other way without XS-Python-Version). I have to admit that I am a bit disapointed by this, to say the least. Why are we shipping python2.5 in etch if we don't ship the python extension modules people expect to find (PIL, mx.DateTime, Numeric...) sigh -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science Reprise et maintenance de sites CPS: http://www.migration-cms.com/ signature.asc Description: Digital signature
Re: python2.5 fails to import pygtk and gtk modules
On 1/2/07, Loïc Minier [EMAIL PROTECTED] wrote: Hi, On Tue, Jan 02, 2007, Tshepang Lekhonkhobe wrote: I tried to do some development using Etch's python2.5, but it fails to import pygtk and gtk modules and this is a regression IIRC. v2.4 works fine. pyversions --supported only returns python2.4, so the source package does not build the 2.5 flavor. Either patch pygtk's debian/rules or patch pyversions and rebuild pygtk. some mentoring needed: in the 2nd case, will I have to also have to build pyversions?
Re: python2.5 fails to import pygtk and gtk modules
On Tue, Jan 02, 2007, Pierre Habouzit wrote: or do that the clean way: edit /usr/share/python/debian_defaults This is slightly better indeed. My personal taste wouldn't allow me to edit a file under /usr, but I suppose a diversion would achieve a similar job. It would be nice to override this with /etc/python/debian_config. Not sure what has to be done though to force the byte compilation and links creation for the pure modules, and that won't compile binary extention either anyway (but maybe pygtk already forces it I don't know I shall say, I've not checked). The python postinst has it: for hook in /usr/share/python/runtime.d/*.rtupdate; do [ -x $hook ] || continue if ! $hook rtupdate python$oldv python2.4; then hb=$(basename $hook .rtupdate) echo 2 error running python rtupdate hook $hb errors=yes fi done (There are also pre- and post-rtupdate hooks, but these are mostly useful when the default runtime changes.) -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
On Tue, Jan 02, 2007, Alexandre Fayolle wrote: I have to admit that I am a bit disapointed by this, to say the least. Why are we shipping python2.5 in etch if we don't ship the python extension modules people expect to find (PIL, mx.DateTime, Numeric...) I suppose this could be solved by python-defaults upload to experimental to list python2.5 as supported as well? I agree python2.5 is not very useful in itself as is. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
Alexandre Fayolle writes: On Tue, Jan 02, 2007 at 03:20:10PM +0100, Loïc Minier wrote: Hi, On Tue, Jan 02, 2007, Tshepang Lekhonkhobe wrote: I tried to do some development using Etch's python2.5, but it fails to import pygtk and gtk modules and this is a regression IIRC. v2.4 works fine. pyversions --supported only returns python2.4, so the source package does not build the 2.5 flavor. Either patch pygtk's debian/rules or patch pyversions and rebuild pygtk. Happy new year everyone. Am I the only one with a mixed feeling about this? I mean, we spent time last spring updating our packages to use the new Python policy, write nice loops in debian/rules to build for all versions specified by `pyversions -r -v`. Now we would need to tweak the Makefile again and clutter it with a hardcoded 2.5 in the list even though this version is requested debian/control (or in some other place if you chose the other way without XS-Python-Version). I have to admit that I am a bit disapointed by this, to say the least. Why are we shipping python2.5 in etch if we don't ship the python extension modules people expect to find (PIL, mx.DateTime, Numeric...) When etch/sid went into UVF after the 2.5 release, many depending packages and extensions were not yet usable/buildable for 2.5. Adding 2.5 was not considered an option after talking with the release team (Andreas Barth), because it would have introduced a lot of RC reports, which either needed to be fixed by new upstream versions or disabling 2.5 support for this extension. Explicitely adding support for 2.5 on a per package base doesn't introduce these extra RC failures during our release process at the cost of having the burden on the package maintainer, not the release team. Looking at mx and numeric, support for 2.5 can be added, but for example PIL explicitely states in the 1.1.6 release notes that this version adds complete support for 2.5. Maybe support for 2.5 for all extensions looks possible now, but at the time of the UVF it wasn't. You might want to create a python-etch repository and rebuild all extensions where possible to support 2.5, and add new upstream versions where necessary. Once done, propose the versions in this repository to the release team, but I doubt it will be allowed into etch. Mixed feeling yes, but IMO unavoidable with our release schedule for etch. Matthias
Re: python2.5 fails to import pygtk and gtk modules
Loïc Minier writes: On Tue, Jan 02, 2007, Pierre Habouzit wrote: or do that the clean way: edit /usr/share/python/debian_defaults This is slightly better indeed. My personal taste wouldn't allow me to edit a file under /usr, but I suppose a diversion would achieve a similar job. It would be nice to override this with /etc/python/debian_config. no, this leads to build environments producing differing packages depending on the configuration.
