Re: python3.3 status
On Saturday, July 06, 2013 10:22:22 PM Scott Kitterman wrote:
> On Wednesday, July 03, 2013 01:55:07 PM Scott Kitterman wrote:
> > 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
> > pytango - FTBFS on s390 -> #711761, patch sent upstream, waiting for
> feedback.
> > > morse-simulator - NMUed for #712014 - will need binNMU after python3.3
> > > is default
> > > boost1.53 - builds, but doesn't generate python related depends right
> > > (not related to the transition)
> > > file - No effect on the transition #709269
> > > 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 - Will need binNMU after 3.3 is default.
>
> > 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
> > #710545. 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.
>
> No one objected, so I'll run this by the release team.
No one objected here and the release team said go ahead, so I've just uploaded
python3-defaults to unstable that makes python3.3 default. After the next
dinstall, we should be able to start on the "once 3.3 is default" actions.
Hopefully, this python3-defaults upload gets to testing in 10 days and then we
can start working on getting rid of 3.2.
Congratulations to everyone that helped out.
Scott K
Reply to: