I hope this is the correct way to make a request for getting grpc in EPEL 8?
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
+1, needed for some PHP extensions
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
Updated GRPC (currently at 1.36.2) should be ready for Fedora 35 soon. Then I will investigate backporting it to EPEL8.
Time for a status update. ----- Currently, EPEL8 has protobuf 3.5.0, while grpc variously requires >=3.5.0.post1 or >=3.6.0. I suspect an update to 3.6.0 will not be possible under https://fedoraproject.org/wiki/EPEL_Updates_Policy. It may be that simply lowering the requirement to 3.5.0 yields a working or mostly-working grpc. I will need to get the other missing dependencies in place (either by getting them built in EPEL8, or by at least building them myself in a copr for testing purposes) before I can know whether that is true. ----- If I patch to lower the protobuf requirement to 3.5.0, I find that “python3dist(googleapis-common-protos) >= 1.5.5” still needs to be built for EPEL8. If I comment out that BR, I find that “cmake(c-ares)” does not work in EPEL8, but “pkgconfig(libcares)” does. However, the build system seems unhappy with the way it is finding both c-ares and openssl: > -- Could NOT find c-ares (missing: c-ares_DIR) > -- Found c-ares: /usr/include (found suitable version "1.13.0", minimum required is "1.13.0") > […] > -- Found OpenSSL: /usr/lib64/libcrypto.so (found version "1.1.1g") > […] > + /usr/lib/rpm/cmake-build . -j4 > […] > DEPENDENCY ERROR > > You are missing system dependencies that are essential to build grpc, > and the third_party directory doesn't have them: > > cares openssl > > Installing the development packages for your system will solve > this issue. Please consult INSTALL to get more information. > > If you need information about why these tests failed, run: > > make run_dep_checks More study of exactly what is going wrong will be needed.
It looks like the version of CMake in EPEL8 is using the Makefile whenever it exists, rather than respecting -GNinja. Removing the Makefile in %prep gets me to the point where I am actually compiling something. So the next step will be to get python-googleapis-common-protos built for EPEL8 and see if the tests can pass (at least, about as many as pass on Fedora).
> FAILED: CMakeFiles/grpc_cpp_plugin.dir/src/compiler/cpp_plugin.cc.o > /usr/bin/c++ -I. -Iinclude -Ithird_party/address_sorting/include -Isrc/core/ext/upb-generated -Isrc/core/ext/upbdefs-generated -Ithird_party/upb -Igens -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIE -std=c++1z -MD -MT CMakeFiles/grpc_cpp_plugin.dir/src/compiler/cpp_plugin.cc.o -MF CMakeFiles/grpc_cpp_plugin.dir/src/compiler/cpp_plugin.cc.o.d -o CMakeFiles/grpc_cpp_plugin.dir/src/compiler> /cpp_plugin.cc.o -c src/compiler/cpp_plugin.cc > In file included from ./src/compiler/python_generator_helpers.h:29, > from ./src/compiler/protobuf_plugin.h:24, > from ./src/compiler/cpp_plugin.h:29, > from src/compiler/cpp_plugin.cc:21: > ./src/compiler/python_generator.h:47:12: error: 'uint64_t grpc_python_generator::PythonGrpcGenerator::GetSupportedFeatures() const' marked 'override', but does not override > uint64_t GetSupportedFeatures() const override; > ^~~~~~~~~~~~~~~~~~~~ > In file included from src/compiler/cpp_plugin.cc:21: > ./src/compiler/cpp_plugin.h:37:12: error: 'uint64_t CppGrpcGenerator::GetSupportedFeatures() const' marked 'override', but does not override > uint64_t GetSupportedFeatures() const override { > ^~~~~~~~~~~~~~~~~~~~ > ./src/compiler/cpp_plugin.h: In member function 'uint64_t CppGrpcGenerator::GetSupportedFeatures() const': > ./src/compiler/cpp_plugin.h:38:12: error: 'FEATURE_PROTO3_OPTIONAL' was not declared in this scope > return FEATURE_PROTO3_OPTIONAL; > > ^~~~~~~~~~~~~~~~~~~~~~~ It’s looking like grpc in EPEL8 may not be possible given protobuf is at 3.5.0. Furthermore, protobuf is actually in the base OS (AppStream), not in EPEL, so there is no chance of an update even without considering https://fedoraproject.org/wiki/EPEL_Updates_Policy. Suggestions are welcome.
*** Bug 1978766 has been marked as a duplicate of this bug. ***
I’ve looked at this a bit further. I see a few options, only one of which I’m relatively comfortable with. ==== 1 ==== Build with a bundled protobuf, 3.6.0 or later. Discouraged by distribution policy. I’m not willing to guarantee that this wouldn’t cause problems for library users, especially considering they are quite likely to be linking both grpc and the system copy of protobuf. This option is probably feasible, but worries me. ==== 2 ==== Package the last version that supported protobuf 3.5.0, which is grpc 1.11.1, from mid-2018 (https://github.com/grpc/grpc/releases/tag/v1.11.1). This is probably feasible. (It’s possible there is still some other showstopper dependency issue I haven’t hit yet.) Obviously, this is an old release—even older than the initial release of RHEL8! Unfortunately, old libraries tend to be the mostly-unavoidable tradeoff for using a hyper-stable enterprise distribution. ==== 3 ==== Since the Python bindings required newer protobuf before the base library, package a more recent version of grpc, but without the the Python bindings. I don’t think this is a good idea. I think there will be users who rightfully expect the Python bindings filing issues, and I won’t be able to do anything about it. ----- I’m leaning toward attempting option 2, but I want to hear feedback from potential users on whether this version would be useful for them. Because of the EPEL incompatible updates policy, and the fact that grpc upstream breaks the C++ ABI on every minor release (even though they didn’t always bump the C++ SOVERSION in the past), if a version of grpc hits EPEL8 stable we’re pretty much locked into it forever.
Hi Ben, I've been using grpc 1.20 for the past two years on RHEL8 with protobuf-3.5.0. I'm pretty sure 1.26 built fine with 3.5.0 as well, but that release had a bug that (https://github.com/grpc/grpc/issues/21280) always occured for me. Otherwise the following could be used: https://cbs.centos.org/koji/buildinfo?buildID=28298 -- john
(In reply to John Obaterspok from comment #10) > Hi Ben, > > I've been using grpc 1.20 for the past two years on RHEL8 with > protobuf-3.5.0. I'm pretty sure 1.26 built fine with 3.5.0 as well, but that > release had a bug that (https://github.com/grpc/grpc/issues/21280) always > occured for me. Otherwise the following could be used: > https://cbs.centos.org/koji/buildinfo?buildID=28298 > > -- john I guess the approach demonstrated there is a fourth option. To get around the minimum protobuf version, package only python3-grpcio for Python. Do not package the python3-grpcio+protobuf extra, python3-grpcio-tools, python3-grpcio-admin, python3-grpcio-csds, python3-grpcio-channelz, python3-grpcio-health-checking, python3-grpcio-reflection, python3-grpcio-status, python3-grpcio-testing, or the Python documentation in grpc-doc. Even the latest version could probably work with that approach. Would that be better than having an old version with all of the Python packages actually packaged?
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
I didn't know there were that many python3-grpcio packages as I dont use any of those. I only have the following installed: grpc-plugins-1.20.1-3.el8.x86_64 grpc-1.20.1-3.el8.x86_64 grpc-cli-1.20.1-3.el8.x86_64 grpc-devel-1.20.1-3.el8.x86_64
Well, grpc 1.11.1 (which claims to support protobuf 3.5) predates Google versioning their shared libraries. I really don’t want to have to hack that in downstream. I’m also not comfortable supporting a package that provides a current or recent version of grpc, but omits subpackages like python3-grpcio-tools and grpc-plugins (the protobuf compiler plugins for grpc). I understand that there are extant spec files that “partially” package grpc in this way, and that they are useful for some people. I’m regretfully going to close this as WONTFIX, because there isn’t a solution that I am comfortable supporting. ----- That said, I will do my best to package grpc for EPEL9 when the time comes. Also, if a Fedora packager thinks they have a good plan for dealing with the lack of a recent-enough protobuf in EL8, and they are willing to deal with any bug reports on the resulting EPEL8 package, then I am happy to accept a co-maintainer (https://fedoraproject.org/wiki/EPEL_Package_Maintainers).