When possible, please branch and build python-oauth2client in EPEL9. While the project is archived/deprecated upstream, it is still a dependency for grpc. Missing dependencies are python-fasteners[1] and python-mock. The latter must be removed before branching[2]; I can offer a PR. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2032532 [2] https://fedoraproject.org/wiki/Changes/DeprecatePythonMock
PR to remove python-mock dependency: https://src.fedoraproject.org/rpms/python-oauth2client/pull-request/4
*** Bug 2086884 has been marked as a duplicate of this bug. ***
*** Bug 2082172 has been marked as a duplicate of this bug. ***
I have built python-fasteners for EPEL9 and ensured that the buildroot override[1] is active until it reaches stable. Kaleb Keithley has offered[2] for the epel-packagers-sig to maintain the EPEL9 branch if needed. The current Rawhide spec file builds for EPEL9 without modifications[3]. Can you please comment on whether you would like to branch and build python-oauth2client for EPEL9, or whether you would like to accept a co-maintainer to do so? Thanks! [1] https://bodhi.fedoraproject.org/overrides/python-fasteners-0.17.3-2.el9 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2086884 [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=87140309
Hi Ben, if somebody could co-maintain, that would be grand. I am really strapped with time (and will be so for the next few months), so I'd appreciate any help on the cs9 front I added 'epel-packages-sig' as committer, let me know if anything else is needed. Thanks!
(In reply to Michele Baldessari from comment #5) > Hi Ben, > > if somebody could co-maintain, that would be grand. I am really strapped > with time (and will be so for the next few months), so I'd appreciate any > help on the cs9 front > I added 'epel-packages-sig' as committer, let me know if anything else is > needed. > I have submitted a request for the epel9 branch. (https://pagure.io/releng/fedora-scm-requests/issue/44470) Someone (probably me, but could also be someone else in the epel-packagers-sig group) will do the epel9 builds. Thanks https://pagure.io/releng/fedora-scm-requests/issue/44470
Thanks for taking care of it, Kaleb. When you do the intial build, can you please create a buildroot override active for one week? I’ll keep an eye out for it and check if we’re ready to do a bootstrap build of grpc in EPEL9 or not.
(In reply to Ben Beasley from comment #7) > Thanks for taking care of it, Kaleb. > > When you do the intial build, can you please create a buildroot override > active for one week? I’ll keep an eye out for it and check if we’re ready to > do a bootstrap build of grpc in EPEL9 or not. sure. (Although I believe there are several other dependencies that are required and need to be built in epel9 before grpc can be built.) Also my request-branch was erroneously rejected because "I'm not a maintainer." I am a member of the epel-packagers-sig and commit has been granted to epel-packagers-sig. So now we wait.
(In reply to Kaleb KEITHLEY from comment #8) > (In reply to Ben Beasley from comment #7) > > Thanks for taking care of it, Kaleb. > > > > When you do the intial build, can you please create a buildroot override > > active for one week? I’ll keep an eye out for it and check if we’re ready to > > do a bootstrap build of grpc in EPEL9 or not. > > sure. (Although I believe there are several other dependencies that are > required and need to be built in epel9 before grpc can be built.) > > Also my request-branch was erroneously rejected because "I'm not a > maintainer." I am a member of the epel-packagers-sig and commit has been > granted to epel-packagers-sig. So now we wait. Michele, you might need to change the "commit" to "collaborator" and access to the "epel9" branch
(In reply to Kaleb KEITHLEY from comment #9) > (In reply to Kaleb KEITHLEY from comment #8) > > (In reply to Ben Beasley from comment #7) > > > Thanks for taking care of it, Kaleb. > > > > > > When you do the intial build, can you please create a buildroot override > > > active for one week? I’ll keep an eye out for it and check if we’re ready to > > > do a bootstrap build of grpc in EPEL9 or not. > > > > sure. (Although I believe there are several other dependencies that are > > required and need to be built in epel9 before grpc can be built.) > > > > Also my request-branch was erroneously rejected because "I'm not a > > maintainer." I am a member of the epel-packagers-sig and commit has been > > granted to epel-packagers-sig. So now we wait. > > Michele, you might need to change the "commit" to "collaborator" and access > to the "epel9" branch Or maybe you could add me (kkeithle) as a "collaborator" with access to "epel9" branch. Thanks
branch has been created. Commencing to build.
An odd problem! I’m pretty sure packager group commit privileges has been enough for me to request a branch in the past. https://pagure.io/releng/issue/10797 I’m glad you got it sorted out, anyway.
FEDORA-EPEL-2022-adfe49c49a has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-adfe49c49a
(In reply to Kaleb KEITHLEY from comment #8) > sure. (Although I believe there are several other dependencies that are > required and need to be built in epel9 before grpc can be built.) For the full build, yes, although several of them are simply in a circular dependency relationship with certain grpc subpackages, so they just have to wait for a bootstrapped build of grpc. With the boostrap build conditional enabled, though, I was able to get far enough along For a bootstrapped build, I was able to satisfy all the dependencies and get far enough along to hit a compiler error in grpc: ../test/cpp/end2end/rls_server.cc: In function 'grpc::lookup::v1::RouteLookupResponse grpc::testing::BuildRlsResponse(std::vector<std::__cxx11::basic_string<char> >, const char*)': ../test/cpp/end2end/rls_server.cc:97:34: error: no matching function for call to 'google::protobuf::RepeatedPtrField<std::__cxx11::basic_string<char> >::Add(std::vector<std::__cxx11::basic_string<char> >::iterator, std::vector<std::__cxx11::basic_string<char> >::iterator)' 97 | response.mutable_targets()->Add(targets.begin(), targets.end()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/google/protobuf/implicit_weak_message.h:39, from /usr/include/google/protobuf/parse_context.h:42, from /usr/include/google/protobuf/map_type_handler.h:34, from /usr/include/google/protobuf/map.h:56, from /usr/include/google/protobuf/generated_message_table_driven.h:34, from gens/src/proto/grpc/lookup/v1/rls.pb.h:26, from gens/src/proto/grpc/lookup/v1/rls.grpc.pb.h:22, from ../test/cpp/end2end/rls_server.h:20, from ../test/cpp/end2end/rls_server.cc:17: /usr/include/google/protobuf/repeated_field.h:941:12: note: candidate: 'Element* google::protobuf::RepeatedPtrField<T>::Add() [with Element = std::__cxx11::basic_string<char>]' 941 | Element* Add(); | ^~~ /usr/include/google/protobuf/repeated_field.h:941:12: note: candidate expects 0 arguments, 2 provided /usr/include/google/protobuf/repeated_field.h:942:8: note: candidate: 'void google::protobuf::RepeatedPtrField<T>::Add(Element&&) [with Element = std::__cxx11::basic_string<char>]' 942 | void Add(Element&& value); | ^~~ /usr/include/google/protobuf/repeated_field.h:942:8: note: candidate expects 1 argument, 2 provided So I still have some work to do as grpc package maintainer, but that’s a huge step in the right direction! Note also that grpc 1.46.1 (and shortly 1.46.2) is now in Rawhide.
FEDORA-EPEL-2022-adfe49c49a has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-adfe49c49a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-adfe49c49a has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.