PEP 466 approved bring the core Python 2 network security infrastructure
up to speed with the modern internet.
Alex Gaynor has provided a draft patch of the most complex part of that
PEP, backporting the bulk of the Python 3.4 SSL module to Python 2.7:
This is also the part of the PEP most likely to break things, so
figuring out a way to test it in Fedora before it makes it into an
upstream CPython release would be a good idea...
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect
Hi everybody, I'd like to introduce a new project of Slavek Kabrda and mine:
Copr repository with nightly builds of development version of Python 3.
How does it work?
Each night, at 00:01 CET/CEST, dgroc  is run and checks out if any of
the following upstream projects has some new commits in master/default
If so, it creates SRPM with code from that specific new commit and
builds it in the copr repository. Is is being built as a software
collection, not to break system python3 package (that being in critpath
once Python 3 will be the default).
This will let us know immediately when our patches of Python 3 package
are broken. We can react when that happens a we know exactly what commit
(or at lest what day) broke it. This will avoid a big "fix all the
patches" spree once Python 3.5 is stable and hits Fedora. The builds
also run the test suite, so we can see regressions when they happen and
we can communicate with Python upstream fast and flexible (again,
instead of a mass failure once Python 3.5 hits Fedora). It also let us
and you to test if your packages build and run with Python 3.5, so we
can avoid more confusion once Python 3.5... you see what I mean.
Other than the packaging reasons: Fedora might attract Python
enthusiasts and developers as it is most likely the only Linux distro
that has development version of Python packaged nightly. Developers and
powerusers can play with new features committed yesterday just by doing
How to use it
Ad the repository (with dnf copr plugin, or manually), and install
python35 package. That installs the software collection and you can use
it as any other software collection:
$ scl enable python35 python
$ scl enable python35 bash
You can also install packages from PyPI:
# scl enable python35 bash
# pip install ipython
How to (test)build my package against Python 3.5
If you want to build your package against Python 3.5, you can do it in
the following way:
1. Update the spec by adding SCL related macros, see 
2. In mock or Copr, add the repository and add the following packages
to the chroot: scl-utils-build python35-build 
3. Build and profit
Dne 4.7.2014 02:06, Zbigniew Jędrzejewski-Szmek napsal(a):
> looks like something I might use for development of Python software.
> But for this to be truly useful, I'd need a bunch of stuff on top,
> at least numpy/scipy, but also pytables, matplotlib. Without that it
> would be even hard to test building of packages, since they often
> depend on those modules (and others of course). Is there any chance
> you could add cascaded builds of the most popular extensions?
Thanks for your feedback. Unfortunately we do not plan to build "most
popular extensions" in this repository. We would have to select those
and that would lead to either 1) unhappy people (without necessary
packages) or 2) rebuilding almost the whole Python stack in Copr as SCL
(not enough man power, not worth the work).
You can either use pip to install dependencies or build your
dependencies as RPMs in your own Copr/mock. Feel free to ping me on IRC
if you need help.