[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Reply to: