Looks like RHEL 8.2 will have python 3.8 in addition to python 3.6. From
the 8.2 beta:
Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs)
Name Stream Profiles Summary
python27 2.7 [d][e] common [d] Python programming
language, version 2.7
python36 3.6 [d][e] build, common [d] Python programming
language, version 3.6
python38 3.8 [d][e] build, common [d] Python programming
language, version 3.8
Currently, %python_pkgversion is set to 3 in
/usr/lib/rpm/macros.d/macros.python-srpm from python-srpm-macros.
python3-devel is still provided only by python36-devel, so presumably all
EPEL8 python packages will continue to be built against python 3.6. But I
imagine that people will soon be asking for python 3.8 versions of EPEL
packages. How can we provide those? Does this have to be done in some
modular fashion - which seems to come back to the discussion of whether or not
every package has to become its own module or whether to group them together
somehow. Or since both python modules are "default" modules and we can
install both python36-devel and python38-devel at the same time, perhaps we
can define the python3_other* macros again for python38 and just go that way?
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
Now that RHEL 8.2 is out, those of you who are KDE users might notice
that you cannot update certain things due to the change in qt5.
Mainly that qt5 changed from qt5-5.11 to qt5-5.12.
This is actually a good thing. qt5-5.12 is an LTS release and has
The downside is that certain key packages need to be updated and rebuilt.
This was known about beforehand, but due to the nature of EPEL,
nothing could be rebuilt on EPEL8 until RHEL 8.2 was publicly
Rebuild all of the current KDE Plasma Desktop that is in EPEL8.
Updating all packages that are possible to update. There are a few
that cannot be updated, but I believe that is about 5 out of 300.
I expect this to take a week and a half, and should be done by May 13.
At this point, these rebuilt packages will go into epel-testing.
The majority of packages will be at these versions. Except for qt5,
the vast majority of the packages will match those of Fedora 32.
kf5* 5.68 / 19.12
apps 5.18 / 19.12
Thank you for your patience.
If you wish to open bugzilla's for certain packages, that is fine.
Feel free to do that, and assign them to me.
python-mimeparse fails to build in Koji for the epel8-playground target:
from build.log (as an aside, Koji often prompts to look at root.log even
when that's not where the error lies, weird):
error: line 48: Unknown tag: %python_provide: ERROR:
python3-mimeparse not recognized.
but builds fine with the same spec for epel8:
Interestingly, building in mock with the epelplayground-8-x86_64
mock -r epelplayground-8-x86_64 ./python-mimeparse-1.6.0-13.el8.src.rpm
In Mock, the macro expansion works fine:
<mock-chroot> sh-4.4# rpm -E '%python_provide python3-mimeparse'
<mock-chroot> sh-4.4# rpm -q python-rpm-macros
Is the epel8-playground builder somehow using an different version of
python-rpm-macros? Happy to file a bug if I know where this should go.
Michel Alexandre Salim
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
You are kindly invited to the meeting:
EPEL Steering Committee on 2020-05-01 from 21:00:00 to 22:00:00 UTC
The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.
A general agenda is the following:
#topic Old Business