Report on the situation of python2.5 in Debian

Hi,

I have conducted a thorough analysis of all packages
preventing us from
migrating to python 2.5.

I cannot say that the situation looks good. Since the last
transition,
many new packages have been introduced, and a large part of
them don't
support the current policy. Another bad news is that it
isn't possible
to rely on the packages' metadata, as many maintainers don't
understand
what the X?-Python-Version fields mean.


Let's start with the good news. The following packages are
included in
python2.5, and will disappear or become legacy.
        celementtree
        ctypes
        python-pysqlite2
        python-wsgiref


The following packages need a round of binNMUs as soon as
possible, to
build extensions for python2.5, after which they shouldn't
bother us.
Can anyone schedule the binNMUs please?
        bitpim
        cx-bsdiff
        duplicity
        elementtidy
        eunuchs
        gamin
        mmpython
        pyalsaaudio
        pyao
        pychm
        pymad
        pyme
        pyopenssl
        pypoker-eval
        pystatgrab
        python-adns
        python-biggles
        python-cddb
        python-crack
        python-daap
        python-extclass
        python-fam
        python-gd
        python-geoip
        python-omniorb2
        python-osd
        python-pgsql
        python-pqueue
        python-pylibacl
        python-scientific
        python-smbpasswd
        python-tcpwrap
        python-utmp
        python-xattr
        python-yenc
        pyvorbis
        pyx
        pyxmpp
        qm
        quixote1
        reportlab-accel
        zodb
        zope-textindexng2

The following packages should also work with python2.5 after
a round of
binNMUs, as some dependencies were relaxed in python-support
0.7.4:
        dia
        exaile
        k3d


Now, for the bad news. The following packages have various
kinds of
issues that prevent them from working with python2.5. Some
of them are
trivial, some are much more tricky. In all cases, we need to
focus on
these bugs if we want to see those packages in lenny:
        buxon #445247
        decompyle #445248
        gajim #445275
        gaphas #445397
        gaphor #445277
        gpodder #445278
        hamlib #445382
        hk-classes #445372
        imgsizer #445280
        jppy #445379
        kde-guidance #445281
        lcms #436541
        ldaptor #445285
        libsvm #445386
        bondlaw #445288
        maxdb-7.5.00 #445289
        moosic #445400
        musiclibrarian #445399
        newt #445392
        opensync #445394
        postr #445403
        pykdeextensions #445292
        pyroman #445408
        python-gammu #445370
        pyvtk #445396
        quantlib-swig #445416
        quixote #445405
        revelation #445415
        scanerrlog #406729
        swaml #445422
        urlscan #445424
        xmms2 #445409
I request a zero-day NMU policy for these bugs.

The following packages are also buggy, but they are
nevertheless too
buggy for other reasons; let's ignore them.
        diacanvas2
        pyspi
        schooltool


The following packages do not support multiple versions of
python at
once. This is where we have the most serious regression
compared to the
situation of the python2.4 transition. It is understandable
not to
rebuild the gimp or OpenOffice.org packages for several
python versions,
but many of these packages are using distutils and are
therefore
*trivial* to get to work with several versions.

Please note that they can all be binNMUed after python2.5
has become the
default, but all of them will have to migrate to testing at
once. We
must make this list shorter unless we want this transition
to recall bad
memories to the release team. 

Here is the list:
        adesklets
        aubio
        audit
        beagle
        brltty
        capisuite
        comedilib
        cwiid
        dballe
        dds
        deskbar-applet
        eikazo
        empathy
        galago-python
        galago-python-gtk
        gimmie
        gimp
        gnome-orca
        gnuradio
        hocr
        hplip
        imgseek
        jppy
        kdebindings
        libapache2-mod-python
        libbtctl
        libhdate
        libhid
        libipod
        libmetakit2.4.9.3
        libphidgets
        memaid-pyqt
        mirage
        mod-wsgi
        music-applet
        ninix-aya
        notify-python
        nufw
        ocempgui
        ocfs2-tools
        omniidl4
        opencv
        openoffice.org
        pida
        player
        pyclutter
        pyg
        pygoocanvas
        pykaraoke
        pymol
        pynjb
        pypanel
        pyqonsole
        pyrite-publisher
        pyslide
        python-fuse
        python-libpcap
        pytone
        pyxine
        rdiff-backup
        renpy
        sabayon
        skencil
        smart
        snappea
        solfege
        sonata
        sqlrelay
        streamtuner
        subterfugue
        subversion
        synopsis
        vtk
        wxwidgets2.6
        xmldiff
        xulrunner
        zeroc-ice-python
I also request a zero-day NMU policy for these issues, at
least for
packages using distutils.


Finally, for the following packages, I'm waiting for the
situation to
clarify in libboost. It is being discussed in bug #445381.
        democracyplayer #445249
        libavg
        miro
        python-visual
        pythonmagick #445395


A status of all opened bugs can be found here:
http://bugs.debian.org/cgi-bin/pkgreport.cg
i?tag=python2.5;users=jossdebian.org

Thanks for reading.
-- 
 .''`.           Josselin Mouette        /./
: :' :           josselin.mouetteens-lyon.org
`. `'                        jossdebian.org
  `-  Debian GNU/Linux -- The power of freedom

Hi,

> Now, for the bad news. The following packages have
various kinds of
> issues that prevent them from working with python2.5.
Some of them are
> trivial, some are much more tricky. In all cases, we
need to focus on
> these bugs if we want to see those packages in lenny:

You have missed Zope.
It is not possible to run Zope 2.X with Python 2.5 yet, same
for Zope 3.
The problems in there are nothing a maintainer could fix,
except
somebody is willing to pay several days (weeks!?) of work.
Changing the default python version also means to go trough
all Zope
packages and replace /usr/bin/python by /usr/bin/python2.4.

> The following packages do not support multiple versions
of python at
> once. This is where we have the most serious regression
compared to the
> situation of the python2.4 transition. It is
understandable not to
> rebuild the gimp or OpenOffice.org packages for several
python versions,
> but many of these packages are using distutils and are
therefore
> *trivial* to get to work with several versions.

Does the list include those packages which are not conform
to the new
Python policy? There're still several of them out there. A
zero-day NMU
policy would be good to have here, too.
http://bugs.debian.org/from:madcoder-python-transition
debian.org;pend-exc=done;exclude=fixed


> Please note that they can all be binNMUed after
python2.5 has become the
> default, but all of them will have to migrate to
testing at once. We
> must make this list shorter unless we want this
transition to recall bad
> memories to the release team. 

>         mod-wsgi

It's not possible to use more than one python version with
mod-wsgi,
therefore it will only work and be build against the default
python
version. A binNMU after changing the version should work
well.


Cheers,

Bernd

-- 
Bernd Zeimetz
<berndbzed.de>                         <http://bzed.de/>


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

ON FRI, OCT 05, 2007 AT 06:42:46PM +0000, BERND ZEIMETZ
WROTE:
> HI,
> 
> > NOW, FOR THE BAD NEWS. THE FOLLOWING PACKAGES HAVE
VARIOUS KINDS OF
> > ISSUES THAT PREVENT THEM FROM WORKING WITH
PYTHON2.5. SOME OF THEM ARE
> > TRIVIAL, SOME ARE MUCH MORE TRICKY. IN ALL CASES,
WE NEED TO FOCUS ON
> > THESE BUGS IF WE WANT TO SEE THOSE PACKAGES IN
LENNY:
> 
> YOU HAVE MISSED ZOPE.

  ZOPE IS KIND OF OUTSIDE THE PYTHON POLICY BECAUSE IT
ALWAYS LAGS
BEHIND, AND IS DEALT WITH IN ITS OWN ROUND, I PRESUME THAT'S
WHY JOSS
DIDN'T TALKED ABOUT IT.

> DOES THE LIST INCLUDE THOSE PACKAGES WHICH ARE NOT
CONFORM TO THE NEW
> PYTHON POLICY? THERE'RE STILL SEVERAL OF THEM OUT
THERE. A ZERO-DAY NMU
> POLICY WOULD BE GOOD TO HAVE HERE, TOO.
>
HTTP://BUGS.DEBIAN.ORG/FROM:MADCODER-PYTHON-TRANSITIONDEBIAN.ORG;PEND-EXC=DONE;EXCLUDE=FIXED

  LAST TIME I CHECKED, MOST OF THEM WEREN'T IN TESTING FOR
AGES. BUT
THIS WASN'T THOROUGH.

> > PLEASE NOTE THAT THEY CAN ALL BE BINNMUED AFTER
PYTHON2.5 HAS BECOME THE
> > DEFAULT, BUT ALL OF THEM WILL HAVE TO MIGRATE TO
TESTING AT ONCE. WE
> > MUST MAKE THIS LIST SHORTER UNLESS WE WANT THIS
TRANSITION TO RECALL BAD
> > MEMORIES TO THE RELEASE TEAM. 
> 
> >         MOD-WSGI
> 
> IT'S NOT POSSIBLE TO USE MORE THAN ONE PYTHON VERSION
WITH MOD-WSGI,
> THEREFORE IT WILL ONLY WORK AND BE BUILD AGAINST THE
DEFAULT PYTHON
> VERSION. A BINNMU AFTER CHANGING THE VERSION SHOULD
WORK WELL.

  YES, FOR SOME PACKAGES IT MAKES SENSE, JOSS DIDN'T ASKED
FOR AN EMPTY
LIST, MERELY A SHORTER ONE, AND I AGREE WITH HIM.

-- 
·O·  PIERRE HABOUZIT
··O                                               
MADCODERDEBIAN.ORG
OOO                                               
HTTP://WWW.MADISM.ORG

>>> Please note that they can all be binNMUed after
python2.5 has become the
>>> default, but all of them will have to migrate
to testing at once. We
>>> must make this list shorter unless we want this
transition to recall bad
>>> memories to the release team. 
>>>         mod-wsgi
>> It's not possible to use more than one python
version with mod-wsgi,
>> therefore it will only work and be build against
the default python
>> version. A binNMU after changing the version should
work well.
> 
>   yes, for some packages it makes sense, Joss didn't
asked for an empty
> list, merely a shorter one, and I agree with him.

I agree with him, too - just wanted to make sure nobody
tries to "fix"
mod-wsgi.

-- 
Bernd Zeimetz
<berndbzed.de>                         <http://bzed.de/>


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

ON FRI, OCT 05, 2007 AT 06:04:27PM +0000, JOSSELIN MOUETTE
WROTE:
> HI,
> 
> I HAVE CONDUCTED A THOROUGH ANALYSIS OF ALL PACKAGES
PREVENTING US FROM
> MIGRATING TO PYTHON 2.5.

  THANKS A LOT FOR THE WORK !


> NOW, FOR THE BAD NEWS. THE FOLLOWING PACKAGES HAVE
VARIOUS KINDS OF
> ISSUES THAT PREVENT THEM FROM WORKING WITH PYTHON2.5.
SOME OF THEM ARE
> TRIVIAL, SOME ARE MUCH MORE TRICKY. IN ALL CASES, WE
NEED TO FOCUS ON
> THESE BUGS IF WE WANT TO SEE THOSE PACKAGES IN LENNY:
[...]
> I REQUEST A ZERO-DAY NMU POLICY FOR THESE BUGS.

  I SECOND THIS.

> THE FOLLOWING PACKAGES DO NOT SUPPORT MULTIPLE VERSIONS
OF PYTHON AT
> ONCE. THIS IS WHERE WE HAVE THE MOST SERIOUS REGRESSION
COMPARED TO THE
> SITUATION OF THE PYTHON2.4 TRANSITION. IT IS
UNDERSTANDABLE NOT TO
> REBUILD THE GIMP OR OPENOFFICE.ORG PACKAGES FOR SEVERAL
PYTHON VERSIONS,
> BUT MANY OF THESE PACKAGES ARE USING DISTUTILS AND ARE
THEREFORE
> *TRIVIAL* TO GET TO WORK WITH SEVERAL VERSIONS.
> 
> PLEASE NOTE THAT THEY CAN ALL BE BINNMUED AFTER
PYTHON2.5 HAS BECOME THE
> DEFAULT, BUT ALL OF THEM WILL HAVE TO MIGRATE TO
TESTING AT ONCE. WE
> MUST MAKE THIS LIST SHORTER UNLESS WE WANT THIS
TRANSITION TO RECALL BAD
> MEMORIES TO THE RELEASE TEAM. 
> 
> HERE IS THE LIST:
[...]
> I ALSO REQUEST A ZERO-DAY NMU POLICY FOR THESE ISSUES,
AT LEAST FOR
> PACKAGES USING DISTUTILS.

  THIS IS A TAD AGGRESSIVE AS FOR SOME OF THE PACKAGES (SEE
WCGI) IT
MAKE SENSE TO STAY LIKE THAT, AND AN NMUER THAT DOES 10 OF
THOSE IN A
ROUND MAY MISS THE REASONS. I'D RATHER SEE A MASS BUG
FILLING ON THOSE
PACKAGES, AND SEE THE MAINTAINERS THAT FEEL THEIR PACKAGE
SHOULD BE
BUILT FOR ONE VERSION ONLY SAY IT LOUD FIRST.

  THEN MAYBE WE WILL CONSIDER MAKING IT RC.

-- 
·O·  PIERRE HABOUZIT
··O                                               
MADCODERDEBIAN.ORG
OOO                                               
HTTP://WWW.MADISM.ORG

Le vendredi 05 octobre 2007 à 20:42 +0200, Bernd Zeimetz a
écrit :
> You have missed Zope.
> It is not possible to run Zope 2.X with Python 2.5 yet,
same for Zope 3.
> The problems in there are nothing a maintainer could
fix, except
> somebody is willing to pay several days (weeks!?) of
work.
> Changing the default python version also means to go
trough all Zope
> packages and replace /usr/bin/python by
/usr/bin/python2.4.

My guess is that must have already been done, because all
zope packages
(except those I have listed) already depend on python2.4.

> Does the list include those packages which are not
conform to the new
> Python policy? There're still several of them out
there. A zero-day NMU
> policy would be good to have here, too.
> http://bugs.debian.org/from:madcoder-python-transition
debian.org;pend-exc=done;exclude=fixed

AFAICT the remaining packages shouldn't prevent python2.5 to
migrate to
testing. Still, these bugs also deserve a 0-day NMU policy
indeed.

> >         mod-wsgi
> 
> It's not possible to use more than one python version
with mod-wsgi,
> therefore it will only work and be build against the
default python
> version. A binNMU after changing the version should
work well.

I think it should be possible, by building several versions
and using a
rtupdate hook to change a symbolic link pointing to one of
them. Still,
that makes the package much harder to change than those
using distutils,
for which there is no excuse.

A 0-day NMU policy is indeed a bit too much for such
packages; it would
be nice to have them fixed, but it should be done in
agreement with the
maintainer.

-- 
 .''`.           Josselin Mouette        /./
: :' :           josselin.mouetteens-lyon.org
`. `'                        jossdebian.org
  `-  Debian GNU/Linux -- The power of freedom

On Fri, Oct 05, 2007 at 08:04:27PM +0200, Josselin Mouette
wrote:
> Please note that they can all be binNMUed after
python2.5 has become the
> default, but all of them will have to migrate to
testing at once. We
> must make this list shorter unless we want this
transition to recall bad
> memories to the release team. 

Well, then, that's not going to happen before the toolchain
gets fixed
on mips, because of

> Here is the list:
(...)
>         xulrunner

Mike


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

Josselin Mouette wrote:
> Le vendredi 05 octobre 2007 à 20:42 +0200, Bernd
Zeimetz a écrit :
>> You have missed Zope.
>> It is not possible to run Zope 2.X with Python 2.5
yet, same for Zope 3.
>> The problems in there are nothing a maintainer
could fix, except
>> somebody is willing to pay several days (weeks!?)
of work.
>> Changing the default python version also means to
go trough all Zope
>> packages and replace /usr/bin/python by
/usr/bin/python2.4.
> 
> My guess is that must have already been done, because
all zope packages
> (except those I have listed) already depend on
python2.4.

They depend on python2.4, but I'm pretty sure a lot of them
use
#!/usr/bin/python, unfortunately. I'm forwading the mail to
the Zope
lsit therefore.



>> Does the list include those packages which are not
conform to the new
>> Python policy? There're still several of them out
there. A zero-day NMU
>> policy would be good to have here, too.
>> http://bugs.debian.org/from:madcoder-python-transition
debian.org;pend-exc=done;exclude=fixed
> 
> AFAICT the remaining packages shouldn't prevent
python2.5 to migrate to
> testing. Still, these bugs also deserve a 0-day NMU
policy indeed.

As far as I remember several of them were supposed to be
orphaned
anyway, removing instead of fixing would be the way for
them.


>>>         mod-wsgi
>> It's not possible to use more than one python
version with mod-wsgi,
>> therefore it will only work and be build against
the default python
>> version. A binNMU after changing the version should
work well.
> 
> I think it should be possible, by building several
versions and using a
> rtupdate hook to change a symbolic link pointing to one
of them.

Probably I'll implement that, and provide a module for every
python
version. That's something I have to talk trough with
upstream first, though.



-- 
Bernd Zeimetz
<berndbzed.de>                         <http://bzed.de/>


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

Le vendredi 05 octobre 2007 à 21:21 +0200, Mike Hommey a
écrit :
> Well, then, that's not going to happen before the
toolchain gets fixed
> on mips, because of
> 
> > Here is the list:
> (...)
> >         xulrunner

Well, I don't think this transition will be done in a day.
If, by the
time that is required to come to switch python 2.5, the
toolchain still
isn't fixed, that will say much about the state of the mips
port.

-- 
 .''`.           Josselin Mouette        /./
: :' :           josselin.mouetteens-lyon.org
`. `'                        jossdebian.org
  `-  Debian GNU/Linux -- The power of freedom

Le vendredi 05 octobre 2007 à 20:04 +0200, Josselin Mouette
a écrit :
> The following packages should also work with python2.5
after a round of
> binNMUs, as some dependencies were relaxed in
python-support 0.7.4:
>         dia
>         exaile
>         k3d

You can add:
	mod-wsgi
which in fact enters in this category.

-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender
your code.
`. `'       We will add your hardware and software
distinctiveness to
  `-        our own. Resistance is futile.