I have no idea if there is any interest in this or not. I managed to get the
EPEL7 python34 package to build on EL6 with a few modifications. Is there any
interest in supporting this?
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
$ cat /usr/lib/python3.5/site-packages/Flask.egg-link
I think we should exclude all egg-links from distribution.. Also
question comes what we should do from RPM generator.
Neal proposed for now to just skip it..
I'm currently rebasing Python to version 3.5.2 for Fedora 25.
As many of the existing patches are no longer necessary I needed to
delete or disable them. I looked through the git history of python and
python3 packages, and there isn't a clear consensus on which method is
preferred. While python3 package so far only has patches deleted, python
package had many patches that were just disabled/commented out, but not
I decided deleting no longer useful patches is the better option, not
only because it was a more prevalent method in the past, but also
because it keeps the spec file clean for the years to come. No data is
actually lost as it remains in git history.
Hello, I would like to ask if it is possible to update python-django
for EPEL7 to, for example, 1.8 version.
I am actually going to fill a Review Request for
python-django-netjsongraph, and among its requirements, there is
python-django-rest-framework that cannot actually be packaged for
EPEL7 due python-django actual version
I'm happy to inform you that I've rebased Python 3 in Fedora rawhide to
a new version 3.5.2 up from 3.5.1.
The official build has just finished , and should show up in rawhide
repos in the upcoming days.
I invite everyone to try it out, if all goes well I'll push the update
to Fedora 25 as well.
Good day to all,
A Change proposal has been created for Fedora 26 in order to rebase Python 3 stack to 3.6.
You can view the change here . Reviews, questions etc are welcome.
For people who want to do some early testing you can install it by enabling my copr repo: dnf copr enable cstratak/python-3.6
Please be aware that this is an alpha version and the copr builds so far are experimental (some patches need reviewing, some package changes are not documented etc), so builds might disappear, updated, downgraded etc.
As an added note, Python-SIG wiki page is (slowly) being updated . Feel free to add your own knowledge, notes and so on.
Associate Software Engineer
Python Maintenance Team, Red Hat
As of now, http://fedora.portingdb.xyz shows that we are 50% done
porting Fedora packages to Python 3. This is a big magic milestone; if
you're looking for a reason to celebrate, this is it! :)
Meanwhile, let me talk about what the number means and what the next
50% packages are "done" in Rawhide. "Done" is defined as either
"Released"/"green" (packages that are either py3-only, or have py3 and
py2 variants packaged), or "Dropped"/"gray" (package won't be ported,
but there's a py3-compatible alternative packaged in Fedora -- for
example: "python" is dropped because "python3" is available;
"python-numeric" is dropped in favor of "numpy" even though the API s
The classification of "green" packages is mostly automatic, and it's not
perfect -- for example, python-twisted is green even though not all of
the submodules are ported yet, and nothing checks if the packaged py3
versions actually works. For cases when there's a problem with the
automatic process, manual overrides or notes can be put in
Portingdb tracks Rawhide; Fedora 25 is currently missing about 4
packages to get to 50%. It might very well get to 50% before the release.
Now, what's next?
I can't speak for everyone involved, but at Red Hat's python-maint team,
we'll tone down the focus on getting as many packages ported as
possible. This led to us picking the low-hanging fruit, which is better
left to people that are just getting started. We'll be around to answer
questions, provide hints, and otherwise help others get the badges
instead of stealing them for ourselves :)
Instead, we should shift our focus from porting specfiles to upstream
projects. At this point, if some software is easy to port it was
probably ported already; what we're left with are either tough nuts to
crack or projects with few people relative to the codebase size. Some
projects that come to mind that could use attention are GTK, Mercurial,
Samba, wxPython, PySide, Koji & Fedora infra, Ansible.
I don't know yet what our priorities should be here, but that's the
But even if it won't be *our* focus, RPM porting is still open – you can
[contribute] toward the remaining 50%! Badges are waiting :)