Re: python3.3 status
On Friday, June 21, 2013 01:30:00 AM Scott Kitterman wrote:
> On Wednesday, June 19, 2013 12:53:40 AM Scott Kitterman wrote:
> > Here's a further update on packages pertaining to the 3.3 transition:
> >
> libguestfs - No longer FTBFS on amd64, but does on i386, #710545, now
> builds for all python3 versions
> nuitka FTBFS unrepoducible
> pyepr builds successfully, but puts dbg extensions into wrong package:
> #708011 - bug marked as pending
python-scipy - Updated version uploaded, no reason the latest upload shouldn't
make it to testing.
> pytango - FTBFS on s390 -> #711761
> morse-simulator - NMUed for #712014 - will need binNMU after python3.3 is
> default
pyopencl - Fixed.
> boost1.53 - builds, but doesn't generate python related depends right
> (not related to the transition)
> file - No effect on the transition #709269
liblouis - Shouldn't be part of the transition, build-dep is wrong #712076 -
fixed, dropped off the tracker.
> libsigrokdecode - #709406 marked pending since May 28, can ignore
packagekit - Not affected by the transition
> postgresql-9.1 - Only depends on libpython3.2. Will need binNMU after 3.3
> is default. I think this should have an interpreter dependency as well, but
> didn't file a bug as I'm not sure. I would appreciate it if someone would
> have a look.
> pycxx - Will need sourceful update after python3.3 is default
> pymongo - If it was packaged properly, it would need a binNMU, but it's
> not, so it's not an issue for the transition, #712112.
> sqlalchemy - Builds fine, no action needed for transition, ideally would
> build- dep on python3-all
> subunit - No action needed for transition, but multiple bugs need dealing
> with, #708077, #709540, and #712203
> yafaray - FTBFS fixed. Only supports default python3, so it will need
> binNMU after python3.3 is default.
> shiboken - done
> znc
> magics++ - No python3 content in the binaries, no effect on transition
> pygrib - Doesn't actually build python3 packages yet, no effect on
> transition.
> uwsgi - uwsgi-plugin-python3 only depends on libpython3.2 (and also 3.3
> when rebuilt). Like postgresql-9.1, I think this should probably have a
> python3 dependency. It'd be nice if someone could have a look.
> python-astropy Builds fine, but doesn't actually put the python3 build in
> a binary, no impact on the transition
Looking at where we are now, the open issues are down to #711761 and #711761.
I don't think they are enough of a reason to hold back switching to python3.3
as default.
My proposal is that once scipy reaches Testing, we switch to python3.3 as
default python3 and then very shortly after, once all the rebuilds/uploads
that can't be done until after 3.3 is the default are complete and python3-
defaults with the default set to python3.3 is in Testing, we drop python3.2
from supported and start working on it's removal.
If people are generally OK with that, I'll run it past the release team and
unless they object, we'll do it. There's 10 days before we can do this in any
case.
Scott K
Reply to: