Bug 2053646

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.