You request branches through pkg-db

https://admin.fedoraproject.org/pkgdb/package/qpid-qmf/

see "request branch" button in the left side bar

and once you have the branch you just do a "git pull" or "fedpkg pull" to get the branch locally and then do builds and bodhi updates as per standard procedure.

I did,
And got this message:

There is already a package named qpid-qmf in RHEL-6. If you really wish to have an EPEL branch for it open a ticket on the rel-eng trac

Yes, I am really asking to for el6 branch...

And for qpid-cpp and python-qpid, we need to un-retire el6 branch.

Please note: qpid packages were "retired" in RHEL 6.4, RHEL PMs agreed to to adding these packages to epel 6.

Attempted to unretire qpid-cpp/el6:
Admins have been asked to un-retire branch: el6

Attempted to unretire python-qpid/el6, got this message:
Admins have been asked to un-retire branch: el6
Could not save the request for branch: el6, has it already been requested?

Attempted to add el6 branch to qpid-qmf:
There is already a package named qpid-qmf in RHEL-6. If you really wish to have an EPEL branch for it open a ticket on the rel-eng trac

Attempted to add el6 branch to qpid-tests:
Branch el6 requested for user irina

Attempted to add el6 branch to qpid-tools:
Branch el6 requested for user irina

Attempted to add el6 branch to rubygem-qpid_messaging:
Branch el6 requested for user irina

Got this notifications:

(1) limb changed irina's branch request for qpid-tools in el6 from Awaiting Review to Denied with message: Present in RHEL6

(2) limb changed irina's branch request for qpid-tests in el6 from Awaiting Review to Denied with message: Present in EPEL

As I already pointed out, these packages were deprecated in RHEL 6.4 and should be eligible for EPEL 6 now. We have applications depending on qpid packages (python-qpid, qpid-cpp, qpid-qmf, qpid-tests, qpid-tools and rubygem-qpid_messaging)

So, I looked into this this morning.

Please realize that people have lots to do and try and be patient with requests.

The problem is our repo2json process isn't up to date, so it's still got old data that makes it think those packages are still in rhel. We need to fix that, then you can just request the branches as normal.

Can you provide a list of the packages you still need?
Or have any of them been processed yet?

Hum.

Looking more closely, it's not wrong. I see all of these except rubygem-qpid_messaging as still being active in rhel6.

A sub-set of these packages was distributed by RHEL 6, and was deprecated in 6.4. Please
see this bz: https://bugzilla.redhat.com/show_bug.cgi?id=860872

All these packages are now distributed by product MRG. EPEL 6 packages will be different
from MRG packages (very limited patches, no product level testing), and to eliminate any confusion,
I will add "epel" to the NVR. We already have all these packages in EPEL 7, and we are distributing
MRG/RHEL 7 packages as well. I am not sure what you mean by "active" in RHEL 6, did you mean MRG packages
or something else?

Regards, Irina.

Replying to [comment:9 irina]:

A sub-set of these packages was distributed by RHEL 6, and was deprecated in 6.4. Please
see this bz: https://bugzilla.redhat.com/show_bug.cgi?id=860872

Access to the bug is restricted, therefore it is not a useful reference.

I will add "epel" to the NVR. We already have all these packages in EPEL 7, and we are distributing

adding epel to the NVR is not covered by the EPEL guidelines afaik.

I made bz public. I think adding "epel" is good, but I can omit it.

Thank you.

Here is another source about its retirement:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.6_Technical_Notes/deprecated_functionality.html

However, the packages are still in the Fedora infra RHEL mirror - not sure if this means that they are still shipped by RHEL but only not updated. This would confuse our tools as well.

btw. CentOS still ships at least qpid-tests, I will file a ticket about this

Here is the CentOS ticket: https://bugs.centos.org/view.php?id=9747

Sorry, I posted my comment to the wrong ticket. ;(

Yes, I see where thats mentioned, but it doesn't seem to actually be the
case? Unless we are syncing rhel6 incorrectly somehow the packages are
still there.

The rhn web interface seems to agree:

{{{
Red Hat Enterprise Linux 6 Server (RPMs)
python-qpid Python client library for AMQP Download Latest
qpid-cpp-client Libraries for Qpid C++ client applications Download
Latest
qpid-cpp-client-ssl SSL support for Qpid clients Download Latest
qpid-cpp-server An AMQP message broker daemon Download Latest
qpid-cpp-server-ssl SSL support for the Qpid daemon Download Latest
qpid-qmf The Qpid Management Framework Download Latest
qpid-tests Conformance tests for Apache Qpid Download Latest
qpid-tools Management and diagnostic tools for Apache Qpid Download
Latest
}}}

Perhaps they didn't get blocked right in the main server rpms channels?

I am guessing that we never remove packages from RHN, we just stop updating & supporting them.

I've checked the internal rel-eng server and the above mentioned qpid rpms are there. But I think it is correct, the documentation from the RHEL bug says "The following packages in RHEL have been deprecated and subject to removal in a future release of RHEL. These packages will not be updated in the RHEL repositories and customers who do not use the MRG-Messaging product are advised to uninstall them from their system." which is what we can see.

Can I please get an update on my request, is there an agreement to complete it or not? It is somewhat urgent for consumers of this request...

So, I have asked some other releng folks to look and comment, they just haven't had time to do so.

This is not something we have ever done before and IMHO sets a bad precident. We have always waited until RHEL removed the packages before adding them to EPEL.

Perhaps they could be removed in the next point release and then added to EPEL then?

Additionally, is there some urgency here we are unaware of? These packages have been depreciated and sitting there for years... is there some more urgent issue related to them now?

I have no problems waiting few more days, and yes, there is an urgency to get this resolved.

Pulp and Katello team have been attempting to provide an alternative to distributing qpid packages via http://koji.katello.org/koji/search?match=glob&type=package&terms=*qpid* system, as an alternative to epel 6 builds. However they are not able to keep up with (a) changes in EPEL 6 and (2) changes in qpid upstream and asked Messaging team to build them in Fedora instead. Recently I updated qpid-proton in F22, and this requires rebuild of other qpid packages, and because of (1) and (2), Pulp and Katello epel 6 repos are broken.

I hope you understand that providing yet another epel 6 distribution as part of "katello" build system is not a good idea, and we can move forward with my request.

updating a package in F22 has nothing to do with updating a package in epel6. I am having a hard time following what is actually broken and what you are trying to fix, the bug you referenced has zero details. I suspect it has a bunch of private comments I can not read. at this point I am inclined to say you need to wait until the packages have been removed from RHEL. we will gladly add them to EPEL then.

If you feel we really need to do something please clearly explain what exactly is broken, pointing to examples, bug reports or mailing list archives, if need be. Please note that we can not act on anything that is not general public knowledge.

There is an agreement that EPEL will not replace RHEL packages, while this has been deprecated in RHEL it is still in RHEL.

On the whole I am seeing a lot of noise and not a lot of substance of what issues we are actually trying to resolve by adding the packages that are in RHEL to EPEL.

I am sorry, I meant epel 6, not f22.
We are solving a problem for katello and pulp users who (1) use qpid packages and (2) are forced to maintain epel 6 version (newer that RHEL 6) of qpid packages, but do not have the resources/skills to be able to accomplish this task.

Also, when you say "remove" from RHEL 6, where they should be removed from? They cannot be removed from RHN/CDN because RHEL has long term customer's obligations, but if they are removed from the next update ISO, is this going to be enough?

Because it seems like there's a lot of back and forth here I asked for some background from some folks that I had nearby.

The urgency here is because the current releases of Pulp cannot be installed on EL6. That is because on Oct 1, the qpid team pushed new packages to epel6 through a rebase they did. Pulp has tagged in a build that was done ~16 months ago (qpid 0.26) --> https://repos.fedorapeople.org/repos/pulp/pulp/stable/2.6/6Server/x86_64/. So the qpid that comes with Pulp and is the defualt for Pulp is not usable on EL6 because of the epel6 deps change in a related but different package (qpid-proton-c). Several users a week contact the Pulp team about this, and the only option available that they use rabbitMQ - so the upstream pulp community for EL6 is forced to switch brokers. Pulp has also been making a lot of bug fixes to their qpid that they cannot share externally.

It sounds like we have the option of either having the packages removed from RHEL 6 in the next minor update (which would mean further delay for Pulp users and still requires a response to Irina's questions about whether or not we've defined exactly what that means) or making an exception to the current policy (which doesn't sound appealing). Is the recommended approach to work with RHEL on this or is there room to discuss the request? Is there more info that would make that decision point clear?

I Spoke with the pulp guys at the end of teh week and found out what the issue actually is. I put a spec file together for a qipd-proton-compat package that will allow them to fix the broken deps. I also outlined to both the pulp and qpid teams what will be needed to be done to make versions of teh packages that are installable side by side of the qpid stack. we will not be allowing the branching of packages shipped in RHEL unless it is to enable architectures that RHEL does not ship the package on. For future reference in order for us to add a package to epel that is part of rhel the package has to be removed entirely, including from RHN and the CDN.

The messaging team disagrees with the decision to close this ticket as "invalid". We understand that we are asking for an exception to the existing policy to prohibit EPEL packages already distributed by RHEL, but in this case allowing them should be permitted for a number of reasons:

(1) This should be a Product Management decision, and RHEL PM agrees to this, see this ticket:
https://engineering.redhat.com/rt/Ticket/Display.html?id=380292

(2) Original qpid packages in RHEL 6 were only there to support matahari project, and both matahari and qpid packages were deprecated in 6.4

(3) Original qpid packages in RHEL 6 were a subset of qpid packages and were not expected to be used by users directly

(4) Original qpid packages in RHEL 6 are now very old (0.14 version), offering epel 6 packages would be significant improvement (version 0.32 or better)

(5) Both compat package and packages with a different name (as proposed above) will be conflicting with the original qpid packages (and cannot be installed at the same time)

(6) This is forcing us to create another qpid distribution thus creating additional obstacles for using them in RHEL 6 and creating opportunities for competing solutions.

Replying to [comment:27 irina]:

(1) This should be a Product Management decision, and RHEL PM agrees to this, see this ticket:
https://engineering.redhat.com/rt/Ticket/Display.html?id=380292

Just to point out that this is not public, it therefore doesn't exist for everyone.

Replying to [comment:27 irina]:

(1) This should be a Product Management decision, and RHEL PM agrees to this, see this ticket:
https://engineering.redhat.com/rt/Ticket/Display.html?id=380292

FYI: I cannot read this.

(2) Original qpid packages in RHEL 6 were only there to support matahari project, and both matahari and qpid packages were deprecated in 6.4

(3) Original qpid packages in RHEL 6 were a subset of qpid packages and were not expected to be used by users directly

All in all I do not understand why the packages are not simply removed from RHEL to make all this obvious to everybody and removing the conflict with the existing policy.

Commit 901080b fixes this issue