I've created a python3 Fedora 29 update 3 weeks ago:
I don't want to push it without a single user giving feedback, however it is a
security update, so I don't want to keep it in testing forever.
Anyone still running F29 who could update to this python3 version and run the
system for couple days?
when RHEL 7.7 will be released, the following new components/packages will be
provided (assuming from 7.7 beta):
python3 - the Python 3.6 package
This new RHEL7 component builds several subpackages, all obsoleting the
subpackages of epel7 python36 package.
We will simply retire python36 from epel7.
This new RHEL7 component is a drop-in replacement of python-rpm-macros from
epel7, we will simply retire the package. python-epel-rpm-macros already provide
the necessary macros for python34 in epel7.
This new RHEL7 component produces the python3-setuptools package that obsoletes
the python36-setuptools package (built from the python3-setuptools epel7 component).
We cannot simply retire python3-setuptools from epel7, as it also builds
python34-setuptools in epel7 and there is no replacement for that in RHEL7.
Easiest thing would be to stop building python36-setuptools and only keep
python34-setuptools in epel7, however IIRC we cannot have the same component
name as in RHEL. If that is indeed the case, python3-setuptools needs to be
retired and a new python34-setuptools component needs to be created in epel7. Is
my assumption correct?
This new RHEL7 component produces the python3-pip package that obsoletes the
python36-pip package (built from the python-pip epel7 component).
The python-pip epel7 component also produces python34-pip and python2-pip
(neither available in RHEL 7.7).
If my previous assumption about components with RHEL names is correct, we need 1
or 2 new components for python34-pip and python2-pip - either we have each in a
separate component or we create a new component that builds both (called
This new RHEL7 component produces the python3-wheel package.
The python-wheel epel7 component produced python-wheel package (Python 2).
The epel7 package was adapted to produce python2-wheel and python36-wheel,
however there was no successful build of this in epel7.
If my previous assumption about components with RHEL names is correct,
we need to add a new python2-wheel component to epel7.
Are my assumptions correct?
If we indeed need new packages/components, I can help to create them, but I do
not intent to maintain them. Any takers?
The first beta for Python 3.7 is out. It will hopefully get into Fedora
soon as python37.
After it comes out of beta, we'll upgrade python3 to it.
The What's New list is at: https://docs.python.org/3.7/whatsnew/3.7.html
One thing that's interesting for packagers is PEP 552: Deterministic
Let me summarize in my own words.
A new opt-in mode for byte-compilation makes .pyc (bytecode cache) files
depend only on the contents of the corresponding source file.
If we use this, it will slow down imports, because the whole source file
would need to be read and hashed in order to verify if a .pyc file is
valid. (Currently, metadata like the modification time and file size is
To speed things up, there's an option, UNCHECKED_HASH, which skips cache
validation entirely. Using this would mean that if you modify a .py
source file installed by RPM, the changes wouldn't take effect (the .py
contents would only be shown in tracebacks).
Modifying installed files in production is extremely bad practice, of
course, but it's quite useful for debugging on throw-away systems. If we
adopt UNCHECKED_HASH, anyone doing it will have to remember to remove
the corresponding .pyc file.
Honestly, I'm not sure we want to use this in Fedora. Is anyone here
into reproducible builds, to make a better argument for this?
Hello Python package maintainers.
You might know that we are trying to rebuild the Python packages with Python 3.8.
More info at https://fedoraproject.org/wiki/Changes/Python3.8
As is usual with such Python upgrades, packages that parse the AST are imacted
by the changes the most and they need a while to adapt. As a result, pylint is
not yet ready for Python 3.8. Similar situation happened during the upgrade to
I'd like to kindly ask you to stop buildrequiring and running pylint in Fedora
RPM's %check (or similar), unless your package has a runtime dependency on it.
Pylint is an excellent tool and I appreciate that you care for code quality,
however I don't think this is the purpose of %check.
Let me know if you'd like my help with depylinting your %checks.
The following packages BR python3-pylint (I've removed pocketlint and
setuptools-lint where I suspect more complicated dependency reasons):
Maintainers by package:
copr-cli clime dturecek frostyx msuchy praiskup
gnome-abrt ekulik jfilak mhabrnal mkutlak msuchy rluzynski
mock jcwillia mebrown msuchy
python-copr clime dturecek frostyx msuchy
python-ryu abregman apevec
rpmconf mjakubicek msuchy
Packages by maintainer (all Bcc'ed):
clime copr-cli python-copr
dturecek copr-cli python-copr
frostyx copr-cli python-copr
msuchy copr-cli gnome-abrt mock python-copr python-hwdata rpmconf
With Python 2 slated to be removed, I'm going to retire these packages
where upstream has either stopped development (Obnam's dependencies) or
is moving too slow to get a stable Python 3-based release out
(gnumed-server). Also, I've been helping out with gnumed (the client)
but never officially maintained it, and that package is already retired
in Rawhide due to being orphaned - so there's no reason to keep the
List of packages as follows, I'll hold off until Friday before retiring
them if someone wants to take over these packages and get them built. If
you take over gnumed-server you should take over gnumed and unretire it too.
Michel Alexandre Salim
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
When I filed the Python 3.8 [change] for Fedora 31, we knew that the schedule
would be tight.
For that very reason, we have not yet started to build for Python 3.8 in a f31
side tag, but instead we've only been doing it in [copr] so far.
The mass rebuild happens on 2019-07-24, according to the Fedora 31 [schedule].
That gives us about 1 month + 1 week to be able to merge the side tag back in
case we decide to start building it now.
There are several challenges:
- there are ~200 build failures that block this, tracked on [bugzilla]
- further there are about ~300 packages that are blocked by the above,
- some of the packages are quite crucial to make this happen (tornado, pygobject3)
- the 3.8.0 [releases] have been delayed so far, so continuing the trend, we
could very well end up with the first RC just one day before the F31 Final
Freeze or even after that (risking 3.8 beta in Fedora 31 GA)
I've met with Petr Viktorin and Tomáš Orsava today and we are prepared to deffer
this change to Fedora 32, unless there is a large push-back against that.
However we don't want this to be an internal decision behind closed doors, so we
are sharing it with you and we are happy to reconsider, in case there is
something that we haven't anticipated.
What would that mean:
- we would continue to build the packages in [copr] as new Python 3.8 beta
versions are released
- we would continue to report build failures and to provide pointers to
- right after the F32 branching (2019-08-13 according to the [schedule]), we
would start with the side tag builds
- the Koji builds would start ~2 months later
- we would not be stressed by the immediate mass rebuild deadline
- we would not need to care about ABI incompatibilities between beta releases,
because the last beta should be out when we start
- the users would get 3.8 as the main python3 about 6 months later, but they
already have Python 3.8 interpreter in Fedora to develop on
We could of course just start building now and than decide not to merge the side
tag, but we are worried that it would leave a big mess in git repos and RPM
If you think this is not a wise decision and would prefer to have Python 3.8 in
Fedora 31 (as the main python3), please discuss quickly. The F31 mass rebuild is
approaching fast and there's a lot to be done, so every day counts now; in other
words, the later you present your argument, the stronger it must be ;)
on behalf of the Fedora's Python SIG
and Red Hat's Python Maintenance team