Bug 684899 - mrepo broken for RHEL 6
mrepo broken for RHEL 6
Status: NEW
Product: Fedora EPEL
Classification: Fedora
Component: mrepo (Show other bugs)
el6
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: James Findley
Fedora Extras Quality Assurance
:
Depends On: 731050
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-14 14:27 EDT by Brian Long
Modified: 2013-02-26 13:18 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Applies cleanly to the 0.8.7-4 source rpm, fixes RHEL 6 breakage (36.19 KB, patch)
2013-02-26 12:34 EST, Andrew Wyatt
no flags Details | Diff

  None (edit)
Description Brian Long 2011-03-14 14:27:35 EDT
Description of problem:
There are patches which need to be applied to mrepo, gensystemid and two helper libraries in order to get mrepo working on a RHEL 6 host.

Version-Release number of selected component (if applicable):
0.8.7-2

How reproducible:
Always

Steps to Reproduce:
1. Install RHEL 6 and mrepo
2. Configure mrepo to download RHEL 6 channels from RHN
  
Actual results:
rhpl.translate missing
md5 deprecated; need to use hashlib

Additional info:
RHEL 6 Beta included the old rhpl package which has been phased out, but mrepo still requires it.  Not sure if the pieces required by mrepo have been migrated to another package which is part of RHEL 6; otherwise, rhpl might need to be added into EPEL 6 since Red Hat pulled it out of the RHEL 6 GA release.

One of the mrepo patches is available here:
http://lists.rpmforge.net/pipermail/tools/2010-November/001800.html
The latest gensystemid has added RHEL 6 releases:
http://svn.rpmforge.net/svn/trunk/tools/mrepo/gensystemid
Comment 1 James Findley 2011-03-24 06:33:37 EDT
Sorry for the slow response to this, I'll try to have a fixed package in -testing by tonight.
Comment 2 dburklan 2011-04-27 15:10:53 EDT
Is there an updated package I can download? I am experiencing the same issues on my RHEL 6 test machine where the latest EPEL mrepo package is installed.

Thanks,

Dan
Comment 3 Jessica Jones 2011-08-16 11:40:50 EDT
I have fixed this, but am waiting for a package re-review.  In the meantime the package for EL6 can be downloaded from:

http://people.fedoraproject.org/~zaniyah/mrepo/mrepo-0.8.7-4.el6.noarch.rpm
http://people.fedoraproject.org/~zaniyah/mrepo/md5sum

Jess
Comment 4 Dean Hamstead 2011-08-24 21:09:27 EDT
just fyi, there is a new upstream version 0.8.8

see https://github.com/dagwieers/mrepo
Comment 5 Dean Hamstead 2011-08-24 21:15:13 EDT
also, in this url http://people.fedoraproject.org/~zaniyah/mrepo/ there is a utf-8 patch - which isnt included in the .spec file and consequently the resultant rpms
Comment 6 Yury V. Zaytsev 2011-08-25 14:34:33 EDT
(In reply to comment #4)
> just fyi, there is a new upstream version 0.8.8
> 
> see https://github.com/dagwieers/mrepo

This is the upcoming version yet to be released.

(In reply to comment #5)
> also, in this url http://people.fedoraproject.org/~zaniyah/mrepo/ there is a
> utf-8 patch - which isnt included in the .spec file and consequently the
> resultant rpms

Would be nice to have the patches upstreamed to us with a sensible description (the github URL above is now the official repository and bug tracking system for mrepo).

I think some of those are still relevant for the git version, although probably should be reworked.

(In reply to comment #3)
> I have fixed this, but am waiting for a package re-review.  In the meantime the
> package for EL6 can be downloaded from:

FYI, I have recently merged a branch to support hosting mrepo mirrors on RHEL6 into the above mentioned git repository.

Did you backport the patches from git or you applied some fixes that you came up with yourself?

Thanks,
Z.
Comment 7 Dean Hamstead 2011-08-25 18:48:16 EDT
hi.

i have compiled the 0.8.8 (there is an src rpm at http://www.openfusion.com.au/labs/srpms/) - however it doesnt work for me on rhel6

the 0.8.7-2 version does work for me, although i have to add the rhpl package from rhel6 beta in order to make it work.

the utf-8 patch was merely an observation, i dont know its purpose.

also, i believe its an omission that the mrepo package needs rhpl to run - but the rpm doesnt have it as a dependency.

anyway - github makes it crazy easy to submit patches. i suspect that if you fork 0.8.8, merge the patches from 0.8.7-2 then send a pull request to the maintainer, he will almost certainly accept them and create a new version

i would be a happy customer :)
Comment 8 Yury V. Zaytsev 2011-08-26 03:32:55 EDT
(In reply to comment #7)
> hi.
> 
> i have compiled the 0.8.8 (there is an src rpm at

As I stated above, 0.8.8 does *not* exist yet.

> http://www.openfusion.com.au/labs/srpms/) - however it doesnt work for me on
> rhel6

Try my latest packaging instead:

https://github.com/repoforge/rpms/tree/master/specs/mrepo

it is not officially pushed out yet, but it works for me in production.

> anyway - github makes it crazy easy to submit patches. i suspect that if you
> fork 0.8.8, merge the patches from 0.8.7-2 then send a pull request to the
> maintainer, he will almost certainly accept them and create a new version

I like to receive patches as github pull requests, but I am not a pull request zealot. If one just attaches them to the issues with reasonable comments, so that we can make sense out of it, it's perfectly fine with me as well.
Comment 9 Dean Hamstead 2011-08-26 03:38:53 EDT
this one (http://people.fedoraproject.org/~zaniyah/mrepo/) is working fine for me now. im not encountering any issues that require me to seek additional patches, 

ill happily update the package i use when all the patches come together and another release emerges.

im now trying to get apt-rpm to compile in rhel6 so can completely upgrade our repo servers :) ...
Comment 10 Jessica Jones 2011-08-26 05:33:13 EDT
(In reply to comment #5)
> also, in this url http://people.fedoraproject.org/~zaniyah/mrepo/ there is a
> utf-8 patch - which isnt included in the .spec file and consequently the
> resultant rpms

It's there because it was submitted to the mailing list, but I'm not convinced it was accepted or is actually relevant, so I didn't include it in the spec.  The other patches are all from the mailing list and have been accepted by upstream, but I had to recreate them for the current stable version as they and had been in most cases made without knowledge of each other's changes.
Comment 11 Jessica Jones 2011-08-26 05:36:38 EDT
(In reply to comment #7)
> hi.
> 
> i have compiled the 0.8.8 (there is an src rpm at
> http://www.openfusion.com.au/labs/srpms/) - however it doesnt work for me on
> rhel6

I'll upgrade to that when it is officially released.

> the 0.8.7-2 version does work for me, although i have to add the rhpl package
> from rhel6 beta in order to make it work.

That's not a dependency I'm aware of, so I'll have to do more testing to work that one out.  It builds fine in mock and runs when I use it, and none of my machines are subscribed to RHEL6 beta.  If it's in the official RHEL6 then it is possible that I have it installed already as a dependency of something else.

> the utf-8 patch was merely an observation, i dont know its purpose.

Neither do I, which is partly why it's not included.

> also, i believe its an omission that the mrepo package needs rhpl to run - but
> the rpm doesnt have it as a dependency.

Possibly - I'd have to do more testing in order to establish this.

> anyway - github makes it crazy easy to submit patches. i suspect that if you
> fork 0.8.8, merge the patches from 0.8.7-2 then send a pull request to the
> maintainer, he will almost certainly accept them and create a new version

He's stipulated in the past that he'd rather they were submitted to the mailing list, and in this case they've already been accepted anyway, but yes, git does make life much easier.
Comment 12 Yury V. Zaytsev 2011-08-26 07:31:18 EDT
(In reply to comment #10)
> (In reply to comment #5)
> > also, in this url http://people.fedoraproject.org/~zaniyah/mrepo/ there is a
> > utf-8 patch - which isnt included in the .spec file and consequently the
> > resultant rpms
> 
> It's there because it was submitted to the mailing list, but I'm not convinced
> it was accepted or is actually relevant, so I didn't include it in the spec.

It could be easily so that it was just forgotten or lost in the process. Trust me, it's *very* easy to miss something when you are digging through half a year worth of mailing list archives :-/

(In reply to comment #11)
> 
> That's not a dependency I'm aware of, so I'll have to do more testing to work
> that one out. 

AFAIK, it is needed for rhnget to work. Dag is planning to rewrite this piece of code to get rid of the rhpl dependency, but for now, there is no other way around if you want to use mrepo to mirror RHN channels.

> If it's in the official RHEL6 then it is possible that I have
> it installed already as a dependency of something else.

No, it's not. It was still there in RHEL 6 Beta 2 and then they dropped it right before the release. Which is why for RHEL 6 we are shipping rhpl which is rebuild from beta SRPM as is.

> He's stipulated in the past that he'd rather they were submitted to the mailing
> list, and in this case they've already been accepted anyway, but yes, git does
> make life much easier.

In the past, there was no separate version control repository, bug tracking system or anything at all for mrepo, so, of course, using the mailing list was way better than tracking patches in the personal e-mail.

Since then we migrated mrepo to github and now the preferred way to contribute is to file github issues and submit pull requests.

Z.
Comment 13 Jessica Jones 2011-08-31 04:35:44 EDT
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #5)
> > > also, in this url http://people.fedoraproject.org/~zaniyah/mrepo/ there is a
> > > utf-8 patch - which isnt included in the .spec file and consequently the
> > > resultant rpms
> > 
> > It's there because it was submitted to the mailing list, but I'm not convinced
> > it was accepted or is actually relevant, so I didn't include it in the spec.
> 
> It could be easily so that it was just forgotten or lost in the process. Trust
> me, it's *very* easy to miss something when you are digging through half a year
> worth of mailing list archives :-/

Ah I see - I hadn't realised you were having to do that.

> (In reply to comment #11)
> > 
> > That's not a dependency I'm aware of, so I'll have to do more testing to work
> > that one out. 
> 
> AFAIK, it is needed for rhnget to work. Dag is planning to rewrite this piece
> of code to get rid of the rhpl dependency, but for now, there is no other way
> around if you want to use mrepo to mirror RHN channels.

Hmm, that might be tricky as I can see people complaining about that one if they don't want to use RHN.  Also it isn't available for Fedora as far as I can see, so will require a bit more thought.

> > If it's in the official RHEL6 then it is possible that I have
> > it installed already as a dependency of something else.
> 
> No, it's not. It was still there in RHEL 6 Beta 2 and then they dropped it
> right before the release. Which is why for RHEL 6 we are shipping rhpl which is
> rebuild from beta SRPM as is.

In that case I'm not sure how we can add it as a dependency of the Fedora package.  Presumably only a few routines are used?  I thought most of them were moved out into other packages.

> > He's stipulated in the past that he'd rather they were submitted to the mailing
> > list, and in this case they've already been accepted anyway, but yes, git does
> > make life much easier.
> 
> In the past, there was no separate version control repository, bug tracking
> system or anything at all for mrepo, so, of course, using the mailing list was
> way better than tracking patches in the personal e-mail.
> 
> Since then we migrated mrepo to github and now the preferred way to contribute
> is to file github issues and submit pull requests.

Okay, in that case I will have a look at doing that, although it may take me a little while.
Comment 14 Yury V. Zaytsev 2011-08-31 16:08:56 EDT
(In reply to comment #13)
> 
> Hmm, that might be tricky as I can see people complaining about that one if
> they don't want to use RHN.  Also it isn't available for Fedora as far as I can
> see, so will require a bit more thought.

For Fedora at the moment I don't see any other option, but to drop this dep and make a note that rhnget won't work :-(

Trying to bundle rhpl is probably more complicated than re-writing the offending piece of code.

> In that case I'm not sure how we can add it as a dependency of the Fedora
> package.  Presumably only a few routines are used?  I thought most of them were
> moved out into other packages.

I have to admit that I am not very familiar with this particular piece of code. As far as I understand rhpl classes are used to send XMLRPC requests to RHN. Obviously, this code can be either ported to whatever new packages RH is using, or re-written to perform said requests using raw Python facilities.

For us it's not a big deal, because we only target RHEL and can easily provide rhpl at the moment, but I can understand that it presents a problem for Fedora.

Unfortunately, I can't really help you on this one. All I can tell is that last time I talked to Dag, he said that he is aware of it and is planning to solve this problem, but so far it didn't happen.

I am subscribing him to this bug so that he can chime in if he feels that I'm misleading you here.

> Okay, in that case I will have a look at doing that, although it may take me a
> little while.

No worries, we're all busy people...
Comment 15 Yury V. Zaytsev 2011-09-01 17:09:37 EDT
FYI, a patch to get rid from the RHPL dependency was just merged in the git master: https://github.com/dagwieers/mrepo/issues/4 .
Comment 16 Dag Wieers 2011-09-01 18:37:51 EDT
Thanks Yury. The bigger plan was to replace the older RHEL4 up2date code we ship with mrepo (for rhnget) with either the yum-plugin-rhn RHEL6 code, or with our own xmlrpc library.

That hasn't happened yet, but in the meantime we have been patching the older RHEL4 up2date code to basically do what we want, including the removal of the dependency on rhpl (thanks to patches from David Cantrell).

I guess it's perfectly acceptable to patch the older RHEL4 code (during 0.8.x) until we have a newer replacement (0.9).
Comment 17 Jessica Jones 2011-10-11 09:10:09 EDT
Added a dependency on the review request for this package.

For those from upstream watching this bug, I'm not sure what is going on with the mailing list as I can't seem to get through on it right now (is it down for maintenance?), so I'm pasting in the most relevant part of the related package review here so that no one has to go and read all the way through it:

"Additionally:
Most libraries in:
/usr/share/mrepo/up2date_client/
are copied from package rhn-client-tools
and libraries in:
/usr/share/mrepo/rhn
are copied from package rhnlib
Both are for some time in Fedora.
I encouradge you talk to upstream to not bundle this libraries to mrepo, but
use those libraries directly from rhnlib and rhn-client-tools."

Presumably these are things that can be dropped?  rhnlib and rhn-client-tools look like they should be available through EPEL if needed on RHEL-based systems.
Comment 18 Yury V. Zaytsev 2011-10-11 09:30:11 EDT
(In reply to comment #17)
> 
> For those from upstream watching this bug, I'm not sure what is going on with
> the mailing list as I can't seem to get through on it right now (is it down for
> maintenance?)

The lists migrated to:

http://lists.repoforge.org/mailman/listinfo

The old address seems to be redirecting properly. Not sure what could be the problem that you are facing.

> Presumably these are things that can be dropped?  rhnlib and rhn-client-tools
> look like they should be available through EPEL if needed on RHEL-based
> systems.

I can't really comment on that, but I guess that the original intention was to be independent of EPEL. Might be that these dependencies can be dropped altogether if the corresponding code is rewritten...
Comment 19 Dag Wieers 2011-10-11 09:34:33 EDT
Unfortunately, these cannot be dropped. The libraries that were copied came from RHEL4 and have since been modified (only slightly, though still important) for the purpose of accessing RHN without the up2date relevant bits causing issues.

We bundled them with mrepo initially to make mrepo work on RHEL3 and RHEL5 (which both ship different versions of these libraries). We would like to get rid of them too at some point, but it has not happened yet. They have recently been modified to work also on RHEL6's python.

See the Github issue tracker for relevant details:

    http://github.com/dagwieers/mrepo

PS The mailinglists should be working fine, but be careful to either use 'lists.rpmforge.net' or 'lists.repoforge.org'. The latter is preferred, the former an artifact from the past.
Comment 20 Andrew Wyatt 2013-02-26 12:34:31 EST
Created attachment 703048 [details]
Applies cleanly to the 0.8.7-4 source rpm, fixes RHEL 6 breakage

Original patch was pulled from here: https://github.com/dagwieers/mrepo/issues/4

It was updated to apply cleanly to the source rpm found here:

http://people.fedoraproject.org/~zaniyah/mrepo/

The only other change needed for full RHEL 6 functionality was:

# echo "up2date default" >/etc/sysconfig/rhn/sources

Note You need to log in before you can comment on or make changes to this bug.