katello-nightly-rpm-pipeline 836 failed

[jenkins]

Katello nightly pipeline failed:

https://ci.theforeman.org/job/katello-nightly-rpm-pipeline/836/

[ehelms]

To support EL8, we built and added to the Katello repositories the qpid-cpp and qpid-proton packages. On EL7, we are relying on the packages in EPEL. However, we are encountering a divergence where EPEL has qpid-proton 0.33.0 but the rubygem that is currently released is only 0.32.0 at the time of writing this (qpid_proton | RubyGems.org | your community gem host). This leads to the current repoclosure failure and will lead to yum failures down the road, e.g.:

 Error: Package: tfm-rubygem-qpid_proton-0.32.0-1.el7.x86_64 (katello-koji)
               Requires: qpid-proton-cpp = 0.32.0
               Removing: qpid-proton-cpp-0.32.0-2.el7.x86_64 (@/qpid-proton-cpp-0.32.0-2.el7.x86_64C_Y6rr)
                   qpid-proton-cpp = 0.32.0-2.el7
               Updated By: qpid-proton-cpp-0.33.0-1.el7.x86_64 (epel)
                   qpid-proton-cpp = 0.33.0-1.el7
               Available: qpid-proton-cpp-0.14.0-2.el7.x86_64 (extras)
                   qpid-proton-cpp = 0.14.0-2.el7

We could opt to carry the qpid-proton 0.32.0 package ourselves and align EL7 and EL8 within Katello repositories to the one we build. However, as you can see above we will run into issues with yum update.

Some options I could think of:

1. we update to the qpid-proton 0.33.0 version, which means we need to find or get published the 0.33.0 rubygem
2. we build qpid-proton into the Katello repositories for EL7 as well, and update qpid-proton spec to generate the rubygem it produces within the TFM SCL on EL7. On EL8, since we build qpid-proton, it has a rubygem-qpid_proton subpackage that gets generated already.

@Jonathon_Turel @evgeni @pcreech @Justin_Sherrill

[evgeni]

I think I’d prefer getting 0.33, under the expectation that this is also the that will be used by others as it’s in EPEL etc.