Re: python2.5 fails to import pygtk and gtk modules

2007-01-15 Thread Tshepang Lekhonkhobe

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

2007-01-15 Thread Lars Wirzenius
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

2007-01-15 Thread Lars Wirzenius
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: Bug#406557: RFP: python-wavelets -- python extension implementing of wavelet transformations

2007-01-15 Thread Yaroslav Halchenko
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

2007-01-15 Thread Tshepang Lekhonkhobe

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]