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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
