the Python (3) bindings are missing on RHEL/CentOS/EPEL 8 for the protobuf package (https://src.fedoraproject.org/rpms/protobuf).
A bug request has been created on Bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1765844), but as no status has been given, I was wondering whether someone could shed some light on the context.
Since protobuf is a RedHat core package (maintained by RedHat and therefore not managed by Fedora/EPEL), it appears as a kind of black box from Fedora perspective. On Fedora (Rawhide, 31), the Python (3) bindings are generated/packaged (see for instance https://bodhi.fedoraproject.org/updates/FEDORA-2019-e3a662fe8b and https://koji.fedoraproject.org/koji/rpminfo?rpmID=19440119), but for some reason, those Python bindings are not generated by RedHat for RHEL/CentOS 8.
1. Would anyone from RedHat be able to provide some heads up on why those Python 3 bindings are missing for Protobuf, and/or an approximate timeline for when it would be generated?
2. Would RedHat need help with packaging protobuf on RHEL/CentOS/EPEL 8?
3. Would you recommend another way for Fedora packagers/users to get their hands on the python3-protobuf/protobuf-python3 package? For instance, through COPR, or some module we may have missed.
Hello fellow Python packagers. This is an announcement about a new set of RPM
macros you can use to build PEP 517/518 enabled packages, that is Python
packages that have the pyproject.toml file.
The set of macros is designed for modern packaging with dynamic buildrequires in
The macros are in the pyproject-rpm-macros package and you can use them like this:
See the full documentation of the macros:
See example spec files:
(These use setuptools (setup.py), flit and poetry for build backends, but you
cannot tell that from the specfiles - BuildRequires are generated dynamically
from upstream metadata.)
The macros are **provisional**, i.e. their API may be changed upon feedback
received from you.
We are not (yet) interested in a general "update all the Python packages" hunt,
but rather in early adopters.
If you have questions, ask here. We'll gladly extend the docs if something is
If you find bugs, report them in bugzilla or here. Likewise for RFEs.
I'd like to inform you that [PEP 602] "Annual Release Cycle for Python" has been
approved and [PEP 596] "Python 3.9 Release Schedule" is pending approval:
tl;dr New Python 3.X versions will be released annually, with RC period adjusted
to make it possible to update Python in odd-numbered Fedora releases. We plan to
submit the Python 3.9 change proposal for Fedora 33 after the first Python 3.9
alpha (expected in ~2 weeks).
The Python 3.8 update was postponed from Fedora 31 to Fedora 32 because the
schedule was too tight. With 3.9 and the recent adjustments, we expect that
Fedora 33 is a reasonable target release, but we are prepared to reevaluate that
Like with 3.8, we plan to rebuild Fedora packages with Python 3.9 pre-releases,
file bugs, and coordinate fixes both to Python and the software that uses it. We
hope to make that process smoother, but even more effective at finding and
resolving incompatibilities. With the shorter cycle, we anticipate less
Quotes from PEP 602:
(Rationale and Goals)
"This change provides the following advantages: ... allows for synchronizing the
schedule of Python release management with external distributors like Fedora
who've been historically very helpful in finding regressions early not only in
core Python but also in third-party libraries, helping moving the community
forward to support the latest version of Python from Day 1"
"While [keeping 4 betas over 4 months and a final month for the release
candidate] would make the release calendar a bit cleaner, it would make it very
hard for external distributors like Fedora to release the newest version of
Python as soon as possible. We are adjusting Python's calendar here in the hope
that this will enable Fedora to integrate the newest version of Python with the
newest version of Fedora as both are being developed which makes both projects
Quotes from the [python-dev] mailing list:
"...in order to give the community enough time to provide feedback in the betas
while having enough time to thoroughly test the RC and to prep for the final
release so the delay from Python's final release to any new project releases is
minimal. It should also fit into the release schedule of Linux distributions
like Fedora better than previously proposed so the distributions can test the RC
when they start preparing for their own October releases."
-- Brett Cannon, Python Steering Council member
"[2 months for RCs instead of 1] allows for synchronizing the schedule of Python
release management with Fedora. They've been historically very helpful in early
finding regressions not only in core Python but also in third-party libraries,
helping moving the community forward. It seems like a bargain to make a slight
adjustment of our schedule to help Fedora help us make 3.9 and beyond better
-- Łukasz Langa, Python 3.8 and 3.9 Release Manager
[PEP 596] https://www.python.org/dev/peps/pep-0596/
[PEP 602] https://www.python.org/dev/peps/pep-0602/
we've been recently approached by a colleague from Red Hat working on
According to their testing, Fedora Python performance could be improved by ~15%
by building /usr/bin/python* statically with libpython*.a. That sounds like a
worthy thing to do.
Since Python 3.8 Python extension modules are no longer linked to libpython.so
and we can do the following:
* build /usr/bin/python3(.8) statically with libpython*.a
* build and ship libpython3.8.so.1.0 for packages that "embed" Python
The change in the python3 package is trivial:
However it can have serious impact on Python extension modules that are linked
to libpython3.8.so.1.0 by various "nonstandard" build mechanisms or by compiling
code for Python extension module and code that embeds Python into one file.
We will likely propose a Fedora 32 Change for this, however I'm opening this
topic for discussion before we do so.
Testing the proposed Pull Request with your code is also helpful. Let me know
how can we make that easier (e.g. if you want a Copr or a Fedora 30/31 python38
package with this change).