I am preparing to update grpc in Fedora Rawhide (35) to version 1.37.1. This
includes the following subpackages:
• grpc
• grpc-data
• grpc-doc
• grpc-cpp
• grpc-plugins
• grpc-cli
• grpc-devel
• python3-grpcio
• python3-grpcio-tools
• python3-grpcio-channelz
• python3-grpcio-health-checking
• python3-grpcio-reflection
• python3-grpcio-status
• python3-grpcio-testing
The C API/ABI so-version will be bumped to “15”, and the C++ API/ABI so-version
to “1”. Additionally, for compatibility with the system copy of abseil-cpp, the
C++ libraries are now built with C++17, which may affect their ABI.
I have built the new version into the side tag “f35-build-side-41105”.
Testing and contributions are welcome. I’ve improved the quality of this
package quite a bit over the last few months since I started maintaining it,
but it is still far from perfect (and will likely remain so, given the nature
of its upstream). Particularly, there are still a significant number of
unexplained test failures, many of which are architecture-specific, that I have
to skip. Any contributions to understanding these well enough to fix them or
usefully report them upstream (understanding that upstream runs the tests very
differently, with a dedicated test build using docker) are very welcome.
I have identified the following packages that will need to be rebuilt because
they depend on the C or C++ libraries. Each package has received a PR, or
a new Bugzilla issue in preparation for a PR.
• bear
• frr
• perl-grpc-xs
The following packages use the Python bindings. Testing with the new version
would be a good idea, but a rebuild should not be required. For the first two,
I performed a successful scratch-build using the side tag to check for any
issues. The last two are FTBFS for unrelated reasons
(
https://bugzilla.redhat.com/show_bug.cgi?id=1959534,
https://bugzilla.redhat.com/show_bug.cgi?id=1959540).
• buildstream
• python-google-api-core
• python-opencensus
• python-opentelemetry
Any contributions are welcome, from testing to auditing the spec file (PRs
welcome) to co-maintainers. The missing language bindings (Ruby, PHP, C#,
Objective-C) are much more likely to be packaged if I have input from someone
with experience packaging for those languages. I’m not a user of this package,
and now that I’ve brought it back to usable and current condition, I’d welcome
those interested in taking co-maintainer responsibility for any of the following:
• the whole package (I would be happy for someone else to be the primary
maintainer in the long term)
• EPEL 8 (
https://bugzilla.redhat.com/show_bug.cgi?id=1757147); currently
this means getting a significant number of dependencies into EPEL 8 and
perhaps offering to co-maintain them there
• particular language bindings (C++, Python, or the as-yet unpackaged Ruby,
PHP, C#, or Objective-C)
• running down test failures and other warts and figuring out patches and/or
reporting them upstream usefully
Drive-by contributions are appreciated too, of course.