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: Bug#406557: RFP: python-wavelets -- python extension implementing of wavelet transformations
It seems that one.pl DNS servers are bad now... can't resolve even pox.one.pl now. Alternative location? ip? On Fri, 12 Jan 2007, Piotr Ozarowski wrote: > Thomas Viehmann wrote: > > I'd be very thankful if the following could be packaged. I'd be able to > > sponsor non-DDs if the packages are good. > http://debian.pox.one.pl/pywavelets_0.1.6-1.dsc > (I need a sponsor) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- 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 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
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]
