Check fedpkg clone waiverdb. The dependency is installed for the package provided in epel7 repo.

Correct me if I'm wrong, but Fedora servers have different means of authentication. So this dependency could be still optional. This is just something to consider - I'm still OK with merging this.

BTW, Jenkins probably complains because the dependency name in that build environment is python3-requests-gssapi (I'm guessing).

I am not a pro of this, but I guess besides BuildRequires it should also be included in Requires?

Check fedpkg clone waiverdb. The dependency is installed for the package provided in epel7 repo.
Correct me if I'm wrong, but Fedora servers have different means of authentication. So this dependency could be still optional. This is just something to consider - I'm still OK with merging this.

Not sure I understood correctly what you mean. The issue is present when from a Fedora machine you try to connect with Kerberos to any kind of waiverdb.

Rebased with the suggestions... I hope it will be fine now.

I thinks it should be also python3-requests-gssapi.

Looks like the other dependencies here are also incorrect, e.g. there are both python3-flask and python-flask.

Not sure I understood correctly what you mean. The issue is present when from a Fedora machine you try to connect with Kerberos to any kind of waiverdb.

I meant that Fedora waiverdb servers are using different authentication method (https://waiverdb.fedoraproject.org/api/v1.0/about).

Not sure I understood correctly what you mean. The issue is present when from a Fedora machine you try to connect with Kerberos to any kind of waiverdb.

I meant that Fedora waiverdb servers are using different authentication method (https://waiverdb.fedoraproject.org/api/v1.0/about).

Yeah, ok. But what if you want to use the internal waiverdb with your Fedora machine? :)
That's exactly the issue...

I thinks it should be also python3-requests-gssapi.
Looks like the other dependencies here are also incorrect, e.g. there are both python3-flask and python-flask.

do you mean s/python-requests-gssapi/python3-requests-gssapi/g ?
I tried like that and it's not working...

do you mean s/python-requests-gssapi/python3-requests-gssapi/g ?
I tried like that and it's not working...

Then the dependency should be always python-requests-gssapi, right?

Yeah, ok. But what if you want to use the internal waiverdb with your Fedora machine? :)
That's exactly the issue...

Then the dependency could be optional. I.e. if I work only with the Fedora waiverdb servers I don't need to install the python-requests-gssapi package.

But I'm still OK with merging this if there is no better solution.

+1 if this is a mandatory dependency or no better options.

I would merge this but Jenkins is not rebuilding this PR and last build is in failed state.

@lholecek Sometimes after a PR is rebased, Pagure doesn't update the commit behind refs/pull/<PR_NO>/head. I think that is also a problem of Pagure.

About the Jenkins build failure: The added build dependency is not present in the Jenkins slave image (docker-registry.engineering.redhat.com/factory2/waiverdb-jenkins-slave:latest). That image was built from waiverdb/openshift/containers/jenkins-slave/Dockerfile, which installs the build dependencies in waiverdb.spec from the master branch. This reminds me that this process should be improved. I am planning to add sudo package then use sudo to install build dependencies from waiverdb.spec at runtime.

If this is urgent, I think it is safe to merge this PR without waiting a successful Jenkins build.

Commit f360ceed fixes this pull-request

OK, I shouldn't have merged it. The dependency is not available on f27 at all and the name is different on f28.

Maybe we can use spec file from pkgs.fedoraproject.org/rpms/waiverdb?

Is this issue fixed?

@mvadkert yes, but we didn't release the new package yet... I'll try to do it today.