Sorry for the slow response to this, I'll try to have a fixed package in -testing by tonight.

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

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

just fyi, there is a new upstream version 0.8.8

see https://github.com/dagwieers/mrepo

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

(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.

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 :)

(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.

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 :) ...

(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.

(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.

(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.

(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.

(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...

FYI, a patch to get rid from the RHPL dependency was just merged in the git master: https://github.com/dagwieers/mrepo/issues/4 .

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).

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.

(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...

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.

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

This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged  change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.

EPEL el6 changed to end-of-life (EOL) status on 2020-11-30. EPEL el6 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
EPEL please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.