I'd like to offer to help maintain some packages in the EPEL repo. Right now I'm building RPMs for CentOS 5 and 6...here's a list of packages / versions I have built
The following I have currently for both CentOS 5 and 6 --------------------- facter-1.6.0 puppet-2.6.9 puppet-2.7.1 puppet-server-2.6.9 puppet-server-2.7.1 (but buggy, at least I had problems) ossec-hids-2.6.0 ossec-hids-client-2.6.0 ossec-hids-server-2.6.0 (untested server portion) zabbix-agent-1.8.5 (can work on getting server portion completed)
These I have only for CentOS 6, but easy enough to convert to 5 ------------------ byobu-4.22 virt-manager-0.8.7 python-virtinst-0.500.6 nut-2.6.1 nut-cgi-2.6.1 (untested) nut-client-2.6.1 nut-devel-2.6.1 (untested) nut-hal-2.6.1 (untested) nut-xml-2.6.1 (untested)
Let me know how I can help.
Thanks - Trey
Hi Trey,
Trey Dockendorf wrote:
I'd like to offer to help maintain some packages in the EPEL repo. Right now I'm building RPMs for CentOS 5 and 6...here's a list of packages / versions I have built
The following I have currently for both CentOS 5 and 6
facter-1.6.0
I'll be pushing facter-1.6.0 to testing today or tomorrow. I've had them in my fedorapeople.org repo for a couple weeks and have not heard any reports of trouble yet. I wanted to ensure that the change from 1.5.x to 1.6.x didn't introduce any obvious incompatibility. I confirmed with upstream that none is intended.
puppet-2.6.9 puppet-2.7.1 puppet-server-2.6.9 puppet-server-2.7.1 (but buggy, at least I had problems)
Puppet 2.6.x is in epel-testing. It has been there for nearly 2 months now. There is one outstanding issue there (selinux policy needs updated on EL-6¹. That's got the attention of a few RHEL folks whom I'm waiting to hear from about when the selinux policy update might get pushed.
Puppet 2.7.x is another major version which includes incompatible changes, making it a bit trickier to update in EPEL without causing grief to users. It's also still very new, and has bugs that need fixed upstream, as you note. I don't see that being a suitable update for EPEL at this time (despite some folks clamoring for the latest and greatest ;).
Any feedback on the packages in testing would be most appreciated (even if you find bugs in the packaging or upstream code that warrant holding off on pushing them to stable).
Thanks!
¹ https://bugzilla.redhat.com/show_bug.cgi?id=718390
On Wed, 2011-07-27 at 07:23 -0500, Trey Dockendorf wrote:
I'd like to offer to help maintain some packages in the EPEL repo. Right now I'm building RPMs for CentOS 5 and 6...here's a list of packages / versions I have built
The following I have currently for both CentOS 5 and 6
facter-1.6.0
facter is part of the MRG Grid add-on and if I remember correctly (http://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_w...) overriding packages from add-ons is not allowed. So if you do push this version, please make sure it won't override the version supplied by Red Hat.
These I have only for CentOS 6, but easy enough to convert to 5
virt-manager-0.8.7 python-virtinst-0.500.6
These are already in RHEL6, so again, please make sure you don't override the default versions.
David Juran wrote:
facter is part of the MRG Grid add-on and if I remember correctly (http://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_w...) overriding packages from add-ons is not allowed. So if you do push this version, please make sure it won't override the version supplied by Red Hat.
Facter has been in EPEL for ages and I never paid any attention to what version may be available in MRG. I already pushed facter-1.6.0 to epel-testing.
I believe puppet is also in MRG, at something like 0.24.6, last time I got a mistaken bug report about it via the Fedora EPEL product in bugzilla.
Are we really not supposed to override packages from places like MRG? Is MRG available to CentOS and Scientific Linux users like other parts of RHEL?
If this is the policy, has it changed recently or have facter and puppet been violating it for nearly as long as they've been in EPEL?
As a maintainer, how can I check what versions are provided by MRG?
On Thu, 2011-07-28 at 09:58 -0400, Todd Zullinger wrote:
David Juran wrote:
facter is part of the MRG Grid add-on and if I remember correctly (http://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_w...) overriding packages from add-ons is not allowed. So if you do push this version, please make sure it won't override the version supplied by Red Hat.
Are we really not supposed to override packages from places like MRG? Is MRG available to CentOS and Scientific Linux users like other parts of RHEL?
To be honest, I'm not sure. I know it's been discussed on this list back and forth a few times but I can't recall the outcome so I just pulled the above FAQ out from google... Can anyone else on the list recall?
As a maintainer, how can I check what versions are provided by MRG?
I wish there was an easy way of doing this, but you'll find the SRPM:s of MRG in http://ftp.redhat.com/redhat/linux/enterprise/5Server/en/RHEMRG/SRPMS/
David Juran wrote:
To be honest, I'm not sure. I know it's been discussed on this list back and forth a few times but I can't recall the outcome so I just pulled the above FAQ out from google... Can anyone else on the list recall?
Heh, I have similarly vague recollections. Glad to not be the only one. :)
I wish there was an easy way of doing this, but you'll find the SRPM:s of MRG in http://ftp.redhat.com/redhat/linux/enterprise/5Server/en/RHEMRG/SRPMS/
Thanks for the link. (I did stumble onto that myself after asking). So it looks like MRG is shipping facter-1.5.2-2 and puppet-0.24.6-3. Neither package is newer than January 2009, so they are not getting much love in MRG it would seem. (The upstream release dates are September 2008 for facter-1.5.2 and October 2008 for puppet-0.24.6, for what it's worth.)
I certainly don't want to make any RHEL folks lives (or jobs) more difficult, but I can't see the value in holding all EPEL user on such ancient and unmaintained versions of facter and puppet.
When David Lutterkort was maintaining facter/puppet in EPEL, they were updated much more frequently. This was before puppet had reached as many users as it has now, to be fair. We've slowed down a bit on pushing updates, even as upstream continues to forge ahead with new versions. But still, more users clamor for updates than for not, it seems to me. Hardly a few days go by that I don't get mail in my inbox asking "where's puppet 2.6 in EPEL?" (Or 2.7 now.) If we stuck on 0.24.6, I doubt many puppet users would bother using EPEL at all.
On 07/28/2011 05:54 PM, Todd Zullinger wrote:
David Juran wrote:
To be honest, I'm not sure. I know it's been discussed on this list back and forth a few times but I can't recall the outcome so I just pulled the above FAQ out from google... Can anyone else on the list recall?
Heh, I have similarly vague recollections. Glad to not be the only one. :)
I wish there was an easy way of doing this, but you'll find the SRPM:s of MRG in http://ftp.redhat.com/redhat/linux/enterprise/5Server/en/RHEMRG/SRPMS/
Thanks for the link. (I did stumble onto that myself after asking). So it looks like MRG is shipping facter-1.5.2-2 and puppet-0.24.6-3. Neither package is newer than January 2009, so they are not getting much love in MRG it would seem. (The upstream release dates are September 2008 for facter-1.5.2 and October 2008 for puppet-0.24.6, for what it's worth.)
I certainly don't want to make any RHEL folks lives (or jobs) more difficult, but I can't see the value in holding all EPEL user on such ancient and unmaintained versions of facter and puppet.
When David Lutterkort was maintaining facter/puppet in EPEL, they were updated much more frequently. This was before puppet had reached as many users as it has now, to be fair. We've slowed down a bit on pushing updates, even as upstream continues to forge ahead with new versions. But still, more users clamor for updates than for not, it seems to me. Hardly a few days go by that I don't get mail in my inbox asking "where's puppet 2.6 in EPEL?" (Or 2.7 now.) If we stuck on 0.24.6, I doubt many puppet users would bother using EPEL at all.
But is MRG still active? I have not seen any activity in ages
On Thu, 2011-07-28 at 18:04 +0300, Manuel Wolfshant wrote:
But is MRG still active? I have not seen any activity in ages
Live and kicking, the RHEL-6-based MRG 2.0 has recently been released https://access.redhat.com/knowledge/docs/Red_Hat_Enterprise_MRG/ (-:
David Juran wrote :
On Thu, 2011-07-28 at 18:04 +0300, Manuel Wolfshant wrote:
But is MRG still active? I have not seen any activity in ages
Live and kicking, the RHEL-6-based MRG 2.0 has recently been released https://access.redhat.com/knowledge/docs/Red_Hat_Enterprise_MRG/ (-:
Call me stupid, but nowhere in that page, searching the knowledge base or skimming through the MRG Release Notes was I able to find the meaning of the MRG acronym.
Google's first link was http://www.redhat.com/mrg/ where I was able to read "Red Hat Enterprise MRG is a next-generation IT infrastructure incorporating Messaging, Realtime, and Grid functionality." at last.
...just in case others might be wondering too :-)
Matthias
I wrote:
David Juran wrote:
To be honest, I'm not sure. I know it's been discussed on this list back and forth a few times but I can't recall the outcome so I just pulled the above FAQ out from google... Can anyone else on the list recall?
Heh, I have similarly vague recollections. Glad to not be the only one. :)
This might be the thread we were thinking about:
https://www.redhat.com/archives/epel-devel-list/2010-December/msg00102.html
That means that facter and puppet are violating this. :(
They have been doing so for years. I strongly suspect that they were in EPEL before they got added to MRG and no one noticed at the time. I started helping with the packages in Fedora/EPEL around the 0.24.6 timeframe, but they entered EPEL in July of 2006, it appears.
I wrote:
This might be the thread we were thinking about:
https://www.redhat.com/archives/epel-devel-list/2010-December/msg00102.html
That means that facter and puppet are violating this. :(
They have been doing so for years. I strongly suspect that they were in EPEL before they got added to MRG and no one noticed at the time. I started helping with the packages in Fedora/EPEL around the 0.24.6 timeframe, but they entered EPEL in July of 2006, it appears.
After talking a little in #epel, Kevin pointed out that EPEL has primarily agreed to not conflict with packages in RHEL AS, but not in various other add-on channels.
http://meetbot.fedoraproject.org/teams/epel/epel.2010-01-15-21.00.log.html#l...
The caveat to this is that we'll consider requests from RHEL folks to no ship things. Obviously, no one wants to cause problems.
David, do you know if the MRG folks have issues with facter and puppet in EPEL? As I said, those packages have been in EPEL for years, so I'm not sure there's anything to be gained by trying to block them at this point. We're already way past MRG in terms of NVR's. But if there are ways we can help alleviate issues for MRG users, I'm game to try.
Todd Zullinger wrote :
David, do you know if the MRG folks have issues with facter and puppet in EPEL? As I said, those packages have been in EPEL for years, so I'm not sure there's anything to be gained by trying to block them at this point. We're already way past MRG in terms of NVR's. But if there are ways we can help alleviate issues for MRG users, I'm game to try.
I seriously hope MRG will be ignored here : No one using puppet today will be interested in the old packages it ships, and as you mentioned in another post, upstream is *very* active and many people are tracking the releases very closely (me included).
Matthias
On Fri, 2011-07-29 at 10:04 +0200, Matthias Saou wrote:
Todd Zullinger wrote :
David, do you know if the MRG folks have issues with facter and puppet in EPEL? As I said, those packages have been in EPEL for years, so I'm not sure there's anything to be gained by trying to block them at this point. We're already way past MRG in terms of NVR's. But if there are ways we can help alleviate issues for MRG users, I'm game to try.
I seriously hope MRG will be ignored here : No one using puppet today will be interested in the old packages it ships, and as you mentioned in another post, upstream is *very* active and many people are tracking the releases very closely (me included).
Well, there's always is the possibility of doing various packaging magic that would allow parallel install or at least cause a package conflict which would prevent accidental upgrade. But as I mentioned in my previous email, not sure if there is much point in doing this for this particular case any more.
On Thu, 2011-07-28 at 12:28 -0400, Todd Zullinger wrote:
I wrote:
This might be the thread we were thinking about:
https://www.redhat.com/archives/epel-devel-list/2010-December/msg00102.html
That means that facter and puppet are violating this. :(
They have been doing so for years. I strongly suspect that they were in EPEL before they got added to MRG and no one noticed at the time. I started helping with the packages in Fedora/EPEL around the 0.24.6 timeframe, but they entered EPEL in July of 2006, it appears.
After talking a little in #epel, Kevin pointed out that EPEL has primarily agreed to not conflict with packages in RHEL AS, but not in various other add-on channels.
http://meetbot.fedoraproject.org/teams/epel/epel.2010-01-15-21.00.log.html#l...
The caveat to this is that we'll consider requests from RHEL folks to no ship things. Obviously, no one wants to cause problems.
David, do you know if the MRG folks have issues with facter and puppet in EPEL?
Not speaking for the MRG team, I can still imagine a scenario where e.g. facter gets updated "by accident" from EPEL on a Grid scheduler and that this potentially could cause problems. All of this is of course slightly hypothetical, I don't even know if an updated facter is a problem or not but just the fact that it hasn't been tested tend to make people nervous when production systems are concerned. And if we (EPEL, Fedora project) want to tout EPEL as "safe to use" on all RHEL systems regardless of add-ons, then this is a problem. On the other hand, if the ambition for EPEL to only be "safe" for RHEL users without add-ons, then this should be made more clear on the EPEL landing page. Maybe even with some conflicts added to the epel-release package to prevent someone from activating it by mistake.
As I said, those packages have been in EPEL for years, so I'm not sure there's anything to be gained by trying to block them at this point. We're already way past MRG in terms of NVR's.
Agreed, not sure if there is any point in beating on a dead horse in this particular case. Both puppet and facter only relate to RHEL5-based MRG-Grid-1 and don't seem to be present in RHEL6-based MRG-grid-2. So if there ever was any damage done, one can always hope that it's done by now...
But if there are ways we can help alleviate issues for MRG users, I'm game to try.
What I think we need is a solution to the general problem, that it's not trivial for an EPEL maintainer to know whether his package stomps on a RHEL package or not. Is anyone from Red Hat (Release Engineering?) reading this list? Any thoughts on whether it would be possible to have an automatically updated list of _all_ RPM NVR:s published? That would certainly be a starting point...
On Fri, Jul 29, 2011 at 02:42, David Juran djuran@redhat.com wrote:
On Thu, 2011-07-28 at 12:28 -0400, Todd Zullinger wrote:
I wrote:
This might be the thread we were thinking about:
https://www.redhat.com/archives/epel-devel-list/2010-December/msg00102.html
That means that facter and puppet are violating this. :(
They have been doing so for years. I strongly suspect that they were in EPEL before they got added to MRG and no one noticed at the time. I started helping with the packages in Fedora/EPEL around the 0.24.6 timeframe, but they entered EPEL in July of 2006, it appears.
After talking a little in #epel, Kevin pointed out that EPEL has primarily agreed to not conflict with packages in RHEL AS, but not in various other add-on channels.
http://meetbot.fedoraproject.org/teams/epel/epel.2010-01-15-21.00.log.html#l...
The caveat to this is that we'll consider requests from RHEL folks to no ship things. Obviously, no one wants to cause problems.
David, do you know if the MRG folks have issues with facter and puppet in EPEL?
Not speaking for the MRG team, I can still imagine a scenario where e.g. facter gets updated "by accident" from EPEL on a Grid scheduler and that this potentially could cause problems. All of this is of course slightly
A system administrator who uses MRG on a Grid and then pulls in EPEL willy-nilly gets what is coming to him, mainly walked out the door.
hypothetical, I don't even know if an updated facter is a problem or not but just the fact that it hasn't been tested tend to make people nervous when production systems are concerned. And if we (EPEL, Fedora project) want to tout EPEL as "safe to use" on all RHEL systems regardless of add-ons, then this is a problem. On the other hand, if the ambition for EPEL to only be "safe" for RHEL users without add-ons, then this should be made more clear on the EPEL landing page. Maybe even with some conflicts added to the epel-release package to prevent someone from activating it by mistake.
EPEL like any other add-on can not be guaranteed safe in any environment any more than blindly updating from 5.n to 5.n+1 is guaranteed to be safe (and if it is.. I need some rather large checks from RH for overtime over the last 10 years :)). A system administrator MUST take responsibility for the fact that software is complicated and interactions between things are not always going to be "safe". A system administrator MUST have a plan on how to locally update, test, deploy en-mass, and back track.
[I am not saying this because I think you disagree, just stating some facts that no software is safe, and there are no guarantees with EPEL. We will do our best to make it work, but we can't stop stupid.]
As I said, those packages have been in EPEL for years, so I'm not sure there's anything to be gained by trying to block them at this point. We're already way past MRG in terms of NVR's.
Agreed, not sure if there is any point in beating on a dead horse in this particular case. Both puppet and facter only relate to RHEL5-based MRG-Grid-1 and don't seem to be present in RHEL6-based MRG-grid-2. So if there ever was any damage done, one can always hope that it's done by now...
But if there are ways we can help alleviate issues for MRG users, I'm game to try.
What I think we need is a solution to the general problem, that it's not trivial for an EPEL maintainer to know whether his package stomps on a RHEL package or not. Is anyone from Red Hat (Release Engineering?) reading this list? Any thoughts on whether it would be possible to have an automatically updated list of _all_ RPM NVR:s published? That would certainly be a starting point...
-- David Juran Sr. Consultant Red Hat +358-504-146348
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Wed, 27 Jul 2011 07:23:17 -0500 Trey Dockendorf treydock@gmail.com wrote:
I'd like to offer to help maintain some packages in the EPEL repo. Right now I'm building RPMs for CentOS 5 and 6...here's a list of packages / versions I have built
I can't find you in the packagers' database. To work with packages in EPEL, you'd need to become a Fedora packager first.
http://fedoraproject.org/wiki/PackageMaintainers/Join
On Thu, Jul 28, 2011 at 8:45 AM, Jussi Lehtola < jussilehtola@fedoraproject.org> wrote:
On Wed, 27 Jul 2011 07:23:17 -0500 Trey Dockendorf treydock@gmail.com wrote:
I'd like to offer to help maintain some packages in the EPEL repo. Right now I'm building RPMs for CentOS 5 and 6...here's a list of packages / versions I have built
I can't find you in the packagers' database. To work with packages in EPEL, you'd need to become a Fedora packager first.
http://fedoraproject.org/wiki/PackageMaintainers/Join
Jussi Lehtola Fedora Project Contributor jussilehtola@fedoraproject.org
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
I'll be sure to sign up for that group, I have a Fedora account but the group's page didn't have a link to apply for the fedora packagers.
While I work on that I'm also looking at building packages using Mock, but am having a lot of trouble getting it to work. I've found a few docs on mock on the Fedora wiki, but not much else. Right now I'm trying to test packages I've made on CentOS 6, but am getting this...maybe if someone could point me in the direction of additional information on Mock or where to get support that would be great.
ERROR: Exception(ossec-hids-2.6.0-1.el6.src.rpm) Config(epel-6-x86_64) 0 minutes 1 seconds INFO: Results and/or logs in: /var/lib/mock/epel-6-x86_64/result ERROR: Command failed: # ['/usr/bin/yum', '--installroot', '/var/lib/mock/epel-6-x86_64/root/', 'groupinstall', 'buildsys-build'] Error: Package: epel-release-6-5.noarch (epel) Requires: /bin/sh Error: Package: epel-release-6-5.noarch (epel) Requires: redhat-release >= 6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
Thanks - Trey
On 07/28/2011 07:05 PM, Trey Dockendorf wrote:
While I work on that I'm also looking at building packages using Mock, but am having a lot of trouble getting it to work. I've found a few docs on mock on the Fedora wiki, but not much else. Right now I'm trying to test packages I've made on CentOS 6, but am getting this...maybe if someone could point me in the direction of additional information on Mock or where to get support that would be great.
ERROR: Exception(ossec-hids-2.6.0-1.el6.src.rpm) Config(epel-6-x86_64) 0 minutes 1 seconds INFO: Results and/or logs in: /var/lib/mock/epel-6-x86_64/result ERROR: Command failed: # ['/usr/bin/yum', '--installroot', '/var/lib/mock/epel-6-x86_64/root/', 'groupinstall', 'buildsys-build'] Error: Package: epel-release-6-5.noarch (epel) Requires: /bin/sh Error: Package: epel-release-6-5.noarch (epel) Requires: redhat-release >= 6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
You need to tweak the epel 6 mock config, the one shipped with the mock package are currently not working out of the box but i think a fixed version is on its way. In /etc/mock/epel-6-x86_64.cfg, disable the 'beta' and 'beta-optional' repos and enable the 'base' and 'updates' repos.
Regards, Xavier
epel-devel@lists.fedoraproject.org
-
David Juran -
Manuel Wolfshant -
Matthias Saou -
Stephen John Smoogen -
Susi Lehtola -
Todd Zullinger -
Trey Dockendorf -
Xavier Bachelot