It's getting close to the Fedora 18 deadline, but Python 3.3 is in feature freeze upstream, so I think we ought to try to get it into Fedora 18
I've created this feature page for the bump of "python3" from 3.2 to 3.3: https://fedoraproject.org/wiki/Features/Python_3.3
I've started work on packaging it. My plan is to create "python3.3" branches of all relevant packages within dist-git, and to test the builds to try to sort out the bulk of the issues (scratch build of the core python3 src.rpm, and then local builds on a rawhide vm). Once that's done and (hopefully) all the issues are resolved, we can apply the changes to "master" and rebuild for real into Koji. Any help would be greatly appreciated!
Thoughts?
Dave
On 07/21/2012 07:53 AM, David Malcolm wrote:
It's getting close to the Fedora 18 deadline, but Python 3.3 is in feature freeze upstream, so I think we ought to try to get it into Fedora 18
I've created this feature page for the bump of "python3" from 3.2 to 3.3: https://fedoraproject.org/wiki/Features/Python_3.3
I've started work on packaging it. My plan is to create "python3.3" branches of all relevant packages within dist-git, and to test the builds to try to sort out the bulk of the issues (scratch build of the core python3 src.rpm, and then local builds on a rawhide vm). Once that's done and (hopefully) all the issues are resolved, we can apply the changes to "master" and rebuild for real into Koji. Any help would be greatly appreciated!
Thoughts?
If you could do this with either trunk or beta 2 (due any day now) that would be *wonderful* from an upstream point of view. While Brett did great work with the importlib test suite, feedback on the first beta highlighted some interesting holes in our test coverage that have been addressed for beta 2 (mostly relating to the fact that our original approach of postponing the migration of pkgutil, runpy and inspect to importlib to 3.4 turned out to be a terrible idea). I still see the update to a PEP 302 compliant import implementation as the riskiest part of this release (given the many undefined quirks of the legacy import implementation), and a successful rebuild of Fedora's Python 3 stack would go a long way to alleviating that concern. It also means that any problems you do find can be fixed before the final release.
Cheers, Nick.
----- Original Message -----
It's getting close to the Fedora 18 deadline, but Python 3.3 is in feature freeze upstream, so I think we ought to try to get it into Fedora 18
I've created this feature page for the bump of "python3" from 3.2 to 3.3: https://fedoraproject.org/wiki/Features/Python_3.3
I've started work on packaging it. My plan is to create "python3.3" branches of all relevant packages within dist-git, and to test the builds to try to sort out the bulk of the issues (scratch build of the core python3 src.rpm, and then local builds on a rawhide vm). Once that's done and (hopefully) all the issues are resolved, we can apply the changes to "master" and rebuild for real into Koji. Any help would be greatly appreciated!
Thoughts?
Dave
Maybe it would be better to try to get a separate Koji tags + target - that way, if everything works ok, we can then just merge our new builds in. If not, we can throw them away.
On Mon, 2012-07-23 at 01:41 -0400, Bohuslav Kabrda wrote:
----- Original Message -----
It's getting close to the Fedora 18 deadline, but Python 3.3 is in feature freeze upstream, so I think we ought to try to get it into Fedora 18
I've created this feature page for the bump of "python3" from 3.2 to 3.3: https://fedoraproject.org/wiki/Features/Python_3.3
I've started work on packaging it. My plan is to create "python3.3" branches of all relevant packages within dist-git, and to test the builds to try to sort out the bulk of the issues (scratch build of the core python3 src.rpm, and then local builds on a rawhide vm). Once that's done and (hopefully) all the issues are resolved, we can apply the changes to "master" and rebuild for real into Koji. Any help would be greatly appreciated!
Maybe it would be better to try to get a separate Koji tags + target - that way, if everything works ok, we can then just merge our new builds in. If not, we can throw them away.
FWIW I asked about this last week on #fedora-releng, and the thought was that it's not enough packages to be worth it yet:
<dmalcolm> is there a (very) rough ETA on when the mass rebuild is likely to be done? I'm may want a custom build target for getting Python 3.3 into F18: https://fedoraproject.org/wiki/Features/Python_3.3 <dgilmore> dmalcolm: when its done <dmalcolm> :) <dgilmore> dmalcolm: probably by the end of the weekend <dmalcolm> ah; thanks! <nirik> well, lets see... 3 days and we have done what... 5k or so? <nirik> well, 2 days I guess. <nirik> so yeah, end of weekend seems possible <dmalcolm> so is a custom build target for python 3.3 sometime next week a sane thing to ask for? * dmalcolm is hoping to have a contingency plan <dgilmore> dmalcolm: that should be fine. how many packages are we talking about? <dgilmore> and how long should it take? <dmalcolm> about 30 iirc <dmalcolm> depends if we run into difficulties <dmalcolm> am trying it out locally on my laptop <dgilmore> dmalcolm: for that few it really shouldnt need its own tag <dmalcolm> dgilmore: thanks. My concern is: what happens if I run into some snag 20 packages in that isn't easily resolvable? Do I manually back everything out? <dgilmore> dmalcolm: we could untag it as long as its not gone out * dmalcolm isn't sure what that means <dmalcolm> dgilmore: does that basically mean untag the say 20 packages, so that rawhide goes back to earlier NVRs? <dgilmore> dmalcolm: yes <dmalcolm> tnx <dgilmore> dmalcolm: we cant do that though if its gone out in a nightly rawhide <dmalcolm> hmmm * dmalcolm hopes that that gives a wide enough window, and gets back to rehearsing the builds on his laptop <dmalcolm> thanks
On Mon, Jul 23, 2012 at 03:30:13PM -0400, David Malcolm wrote:
<dgilmore> dmalcolm: that should be fine. how many packages are we talking about? <dgilmore> and how long should it take? <dmalcolm> about 30 iirc
Just an FYI: 100 packages is a better estimate. $ lftp mirrors.tummy.com:/pub/fedora.redhat.com/fedora/linux/development/rawhide/i386/os/Packages/p
cd ok, cwd=/pub/fedora.redhat.com/fedora/linux/development/rawhide/i386/os/Packages/p lftp mirrors.tummy.com:/pub/fedora.redhat.com/fedora/linux/development/rawhide/i386/os/Packages/p> ls python3*|wc -l
108
-Toshio
On Mon, 2012-07-23 at 12:45 -0700, Toshio Kuratomi wrote:
On Mon, Jul 23, 2012 at 03:30:13PM -0400, David Malcolm wrote:
<dgilmore> dmalcolm: that should be fine. how many packages are we talking about? <dgilmore> and how long should it take? <dmalcolm> about 30 iirc
Just an FYI: 100 packages is a better estimate. $ lftp mirrors.tummy.com:/pub/fedora.redhat.com/fedora/linux/development/rawhide/i386/os/Packages/p
cd ok, cwd=/pub/fedora.redhat.com/fedora/linux/development/rawhide/i386/os/Packages/p lftp mirrors.tummy.com:/pub/fedora.redhat.com/fedora/linux/development/rawhide/i386/os/Packages/p> ls python3*|wc -l
108
Thanks.
The https://fedoraproject.org/wiki/Python3 wiki page is always going to be out-of-date, but I think it's still useful as a quick reference (and something to point people at), so I wrote a script to help update it [1], and it's now much more up-to-date; the "Python 3 already in Fedora" section is pleasingly long.
I'm now experimenting with skvidal's "mockchain" script [2] to try to automate the chain of experimental rebuilds via mock.
Dave
[1] see http://fedorapeople.org/gitweb?p=dmalcolm/public_git/fedora-wiki-python3-pag...
[2] http://fedorapeople.org/gitweb?p=skvidal/public_git/scripts.git;f=mock/mockc...
On Wed, 2012-07-25 at 14:35 -0400, David Malcolm wrote:
I'm now experimenting with skvidal's "mockchain" script [2] to try to automate the chain of experimental rebuilds via mock.
"mockchain" works well; I've updated the status of the feature page: https://fedoraproject.org/wiki/Features/Python_3.3 and there are detailed notes in the "Discussion" page: https://fedoraproject.org/wiki/Talk:Features/Python_3.3
Right now, I'm most concerned about numpy; it uses unicode internals that changed in 3.3 and doesn't compile against 3.3 yet AFAIK.
Plus I haven't actually run any of the code beyond what's being run in the various test suites; some shakedown will be needed of course.
On 07/27/2012 05:29 AM, David Malcolm wrote:
Right now, I'm most concerned about numpy; it uses unicode internals that changed in 3.3 and doesn't compile against 3.3 yet AFAIK.
http://projects.scipy.org/numpy/ticket/1471
Looks like this is also one of the reasons NumPy doesn't play nicely with PyPy's cpyext.
Cheers, Nick.
python-devel@lists.fedoraproject.org
-
Bohuslav Kabrda -
David Malcolm -
Nick Coghlan -
Toshio Kuratomi