Hiyas,
is there a bugtracker for EPEL and its infrastructure? I did not find one, therefore I post my RFEs for EPEL here:
1) Currently EPEL only provides a buildsys-build rpm package at: http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/
It would be nice to have also a buildsys-build comps group in the EPEL comps file, so one can easier build epel rpms with a gpg check enabled setup.
2) Add the rpm macros from http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/buildsys- macros-5-4.el5.noarch.rpm
to the epel-release package. In Fedora the dist macro is also in fedora- release. The reason for this is the same as for 1).
Regards Till
On May 26, 2009, at 5:08 AM, Till Maas wrote:
- Currently EPEL only provides a buildsys-build rpm package at:
http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/
It would be nice to have also a buildsys-build comps group in the EPEL comps file, so one can easier build epel rpms with a gpg check enabled setup.
The EPEL comps file? We have one of those? Or would this be a separate yumgroups.xml type file specifically used by createrepo? Anyway, I think this sounds like a good idea.
- Add the rpm macros from
http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/buildsys- macros-5-4.el5.noarch.rpm
to the epel-release package. In Fedora the dist macro is also in fedora- release. The reason for this is the same as for 1).
I don't see any reason not to do this.
-Jeff
On Monday 01 June 2009 15:49:20 Jeff Sheltren wrote:
On May 26, 2009, at 5:08 AM, Till Maas wrote:
- Currently EPEL only provides a buildsys-build rpm package at:
http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/
It would be nice to have also a buildsys-build comps group in the EPEL comps file, so one can easier build epel rpms with a gpg check enabled setup.
The EPEL comps file? We have one of those? Or would this be a separate yumgroups.xml type file specifically used by createrepo? Anyway, I think this sounds like a good idea.
There is one: http://cvs.fedoraproject.org/viewvc/comps/comps-el5.xml.in?view=log I just created the buildsys-build group from the contents of the buildsys- build package I have. Btw. who maintains the package list for EPEL? I noticed it differs from the F11 one.
- Add the rpm macros from
http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/buildsys- macros-5-4.el5.noarch.rpm
to the epel-release package. In Fedora the dist macro is also in fedora- release. The reason for this is the same as for 1).
I don't see any reason not to do this.
Will you or someone else do this I should/can I do this, too?
Regards Till
On Tuesday 02 June 2009 02:38:53 pm Till Maas wrote:
On Monday 01 June 2009 15:49:20 Jeff Sheltren wrote:
On May 26, 2009, at 5:08 AM, Till Maas wrote:
- Currently EPEL only provides a buildsys-build rpm package at:
epel does not provide this. fedora project does.
It would be nice to have also a buildsys-build comps group in the EPEL comps file, so one can easier build epel rpms with a gpg check enabled setup.
It cant hurt at all
The EPEL comps file? We have one of those? Or would this be a separate yumgroups.xml type file specifically used by createrepo? Anyway, I think this sounds like a good idea.
There is one: http://cvs.fedoraproject.org/viewvc/comps/comps-el5.xml.in?view=log I just created the buildsys-build group from the contents of the buildsys- build package I have. Btw. who maintains the package list for EPEL? I noticed it differs from the F11 one.
It is maintainer managed the same as fedora. if no one updates it that it doesnt get updated. if you want you packages listed its up to you to add them.
- Add the rpm macros from
http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/buildsys- macros-5-4.el5.noarch.rpm
im honestly not sure if we should add the macros to epel-release it would mean then that you must have epel enabled in your mock config to build for EL-4 and EL-5. it would also mean that we need to have mock updated for all active releases with new epel configs since the existing configs would be broken. which would need to be tightly controlled. since epel-testing or epel building would be broken during the stages of transition. mock could be useful for people building things for rhel but not epel. if Red Hat decides to add them to redhat-release or centos adds them to centos-release we will end up with conflicts (im not aware of any plans to add them but im not really in the know) however it is really the right place for them. though we could possibly get away with making the comps group require epel-release and not buildsys-macros.
to the epel-release package. In Fedora the dist macro is also in fedora- release. The reason for this is the same as for 1).
I don't see any reason not to do this.
Will you or someone else do this I should/can I do this, too?
Regards Till
On Wed June 3 2009, Dennis Gilmore wrote:
On Tuesday 02 June 2009 02:38:53 pm Till Maas wrote:
On Monday 01 June 2009 15:49:20 Jeff Sheltren wrote:
On May 26, 2009, at 5:08 AM, Till Maas wrote:
There is one: http://cvs.fedoraproject.org/viewvc/comps/comps-el5.xml.in?view=log I just created the buildsys-build group from the contents of the buildsys- build package I have. Btw. who maintains the package list for EPEL? I noticed it differs from the F11 one.
It is maintainer managed the same as fedora. if no one updates it that it doesnt get updated. if you want you packages listed its up to you to add them.
I meant the package list of the minimum build root. For the Fedora Collection afaik rel-eng maintains it. Somebody is probably doing the same for EPEL.
- Add the rpm macros from
http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/buildsys- macros-5-4.el5.noarch.rpm
im honestly not sure if we should add the macros to epel-release it would mean then that you must have epel enabled in your mock config to build for EL-4 and EL-5. it would also mean that we need to have mock updated for all active releases with new epel configs since the existing configs would be broken. which would need to be tightly controlled. since epel-testing or epel building would be broken during the stages of transition. mock could be useful for people building things for rhel but not epel. if Red Hat decides to add them to redhat-release or centos adds them to centos-release we will end up with conflicts (im not aware of any plans to add them but im not really in the know) however it is really the right place for them. though we could possibly get away with making the comps group require epel-release and not buildsys-macros.
I already made the comps group require epel-release and not buildsys-macros. Also there is no need to remove the groups repo at the specified URL, therefore nothing should break during the transisiton and also old configs will still work. We can first update epel-release and once it is in stable update the mock config files. The problem with conflicts between EPEL and future releases of RHEL exists with every package in EPEL, therefore it is not a big problem.
Regards Till
On Thu, Jun 04, 2009 at 09:53:55AM +0200, Till Maas wrote:
On Wed June 3 2009, Dennis Gilmore wrote:
On Tuesday 02 June 2009 02:38:53 pm Till Maas wrote:
On Monday 01 June 2009 15:49:20 Jeff Sheltren wrote:
On May 26, 2009, at 5:08 AM, Till Maas wrote:
There is one: http://cvs.fedoraproject.org/viewvc/comps/comps-el5.xml.in?view=log I just created the buildsys-build group from the contents of the buildsys- build package I have. Btw. who maintains the package list for EPEL? I noticed it differs from the F11 one.
It is maintainer managed the same as fedora. if no one updates it that it doesnt get updated. if you want you packages listed its up to you to add them.
I meant the package list of the minimum build root. For the Fedora Collection afaik rel-eng maintains it. Somebody is probably doing the same for EPEL.
- Add the rpm macros from
http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/buildsys- macros-5-4.el5.noarch.rpm
im honestly not sure if we should add the macros to epel-release it would mean then that you must have epel enabled in your mock config to build for EL-4 and EL-5. it would also mean that we need to have mock updated for all active releases with new epel configs since the existing configs would be broken. which would need to be tightly controlled. since epel-testing or epel building would be broken during the stages of transition. mock could be useful for people building things for rhel but not epel. if Red Hat decides to add them to redhat-release or centos adds them to centos-release we will end up with conflicts (im not aware of any plans to add them but im not really in the know) however it is really the right place for them. though we could possibly get away with making the comps group require epel-release and not buildsys-macros.
I already made the comps group require epel-release and not buildsys-macros. Also there is no need to remove the groups repo at the specified URL, therefore nothing should break during the transisiton and also old configs will still work. We can first update epel-release and once it is in stable update the mock config files. The problem with conflicts between EPEL and future releases of RHEL exists with every package in EPEL, therefore it is not a big problem.
I just verified that at least the buildsys-build group is not synced to mirrors. Can we somehow move forward on this? If adding the rpm macros to epel-release is really a problem, can we move the package to a proper EPEL repository instead? When I proposed this long a ago for the Fedora packages, it was not done, because they went away eventually. So if nobody complains, I will just create a new package to get this done. But it would be really nice if this could be managed by the people maintaining these packages, to keep them in sync.
Regards Till
On Sun, 17 Jan 2010 09:39:59 +0100 Till Maas opensource@till.name wrote:
On Sun, Jan 17, 2010 at 09:23:03AM +0100, Till Maas wrote:
I just verified that at least the buildsys-build group is not synced to
Sorry for the confusion, the buildsys-build group is synced, but still progress needs to be made.
So, what is left here? Adding macros to epel-release?
Whats the advantage of doing things that way again?
kevin
On Mon, Jan 18, 2010 at 10:32:07AM -0700, Kevin Fenzi wrote:
On Sun, 17 Jan 2010 09:39:59 +0100 Till Maas opensource@till.name wrote:
On Sun, Jan 17, 2010 at 09:23:03AM +0100, Till Maas wrote:
I just verified that at least the buildsys-build group is not synced to
Sorry for the confusion, the buildsys-build group is synced, but still progress needs to be made.
So, what is left here? Adding macros to epel-release?
Yes, or some other package in EPEL.
Whats the advantage of doing things that way again?
The mock config can be changed to not use this repo that only provides unsigned RPMs: http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/
Then one can a lot easier enable gpgcheck in the mock config. Currently it involves downloading and auditing the rpms in above repo and mirror it locally.
Regards Till
On Mon, 18 Jan 2010 19:59:20 +0100 Till Maas opensource@till.name wrote:
The mock config can be changed to not use this repo that only provides unsigned RPMs: http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/
Then one can a lot easier enable gpgcheck in the mock config. Currently it involves downloading and auditing the rpms in above repo and mirror it locally.
Perhaps we could just sign those packages? (Possibly with a different key)?
kevin
On Mon, Jan 18, 2010 at 12:35:43PM -0700, Kevin Fenzi wrote:
On Mon, 18 Jan 2010 19:59:20 +0100 Till Maas opensource@till.name wrote:
The mock config can be changed to not use this repo that only provides unsigned RPMs: http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/
Then one can a lot easier enable gpgcheck in the mock config. Currently it involves downloading and auditing the rpms in above repo and mirror it locally.
Perhaps we could just sign those packages? (Possibly with a different key)?
I don't think that it would be easier, but if it is done, then please with the same key to kind of ensure that it is stored carefully. Here is btw the discussion from 2007 about the same issue but for Fedora:
http://lists.fedoraproject.org/pipermail/devel/2007-June/104640.html
Regards Till
On Mon, Jan 18, 2010 at 09:05:49PM +0100, Till Maas wrote:
On Mon, Jan 18, 2010 at 12:35:43PM -0700, Kevin Fenzi wrote:
On Mon, 18 Jan 2010 19:59:20 +0100 Till Maas opensource@till.name wrote:
The mock config can be changed to not use this repo that only provides unsigned RPMs: http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/
Then one can a lot easier enable gpgcheck in the mock config. Currently it involves downloading and auditing the rpms in above repo and mirror it locally.
Perhaps we could just sign those packages? (Possibly with a different key)?
I don't think that it would be easier, but if it is done, then please with the same key to kind of ensure that it is stored carefully. Here is btw the discussion from 2007 about the same issue but for Fedora:
http://lists.fedoraproject.org/pipermail/devel/2007-June/104640.html
Another three weeks have passed without any progress, so I will create a review request for buildsys-macros.
Regards Till
On Tue, 09 Feb 2010 13:40:40 +0100 Till Maas opensource@till.name wrote:
Another three weeks have passed without any progress, so I will create a review request for buildsys-macros.
Can you not simply pull buildsys-macros into a local repo and sign it there?
I'm not opposed to signing it, but Dennis is. You will need to convince him before it happens I'm afraid.
kevin
On Thu, Feb 11, 2010 at 01:38:27PM -0700, Kevin Fenzi wrote:
On Tue, 09 Feb 2010 13:40:40 +0100 Till Maas opensource@till.name wrote:
Another three weeks have passed without any progress, so I will create a review request for buildsys-macros.
Can you not simply pull buildsys-macros into a local repo and sign it there?
I could also just maintain all my packages only in a local repo, but this is not what a FOSS community is about.
I'm not opposed to signing it, but Dennis is. You will need to convince him before it happens I'm afraid.
This seems to be impossible, as he seems to ignore me, e.g. he did not answer any of my mails here except the first one, even though I addressed his concerns and his only reaction on IRC that I am aware of, is that he will close my review request without any further explanatory statement. But on the other hand, he did not even close it after I pointed him to it.
Nevertheless, I am now trying to directly persuade the assignee of the redhat-release component to give me a statement of whether this will ever changed or not in RHEL, or maybe it will even be changed, which I somehow doubt, as it was not even changed for a stable Fedora release.
Regards Till
On Fri, Feb 12, 2010 at 12:08:59AM +0100, Till Maas wrote:
Nevertheless, I am now trying to directly persuade the assignee of the redhat-release component to give me a statement of whether this will ever changed or not in RHEL, or maybe it will even be changed, which I somehow doubt, as it was not even changed for a stable Fedora release.
So I got confirmation that RHEL won't provide these macros: https://bugzilla.redhat.com/show_bug.cgi?id=481023 https://bugzilla.redhat.com/show_bug.cgi?id=564188
Therefore just adding a buildsys-macros to EPEL seems to be the best option to fix this. People who do not want to use EPEL can then still use the groups repository instead of EPEL, because both can happily co-exist.
Regards Till
epel-devel@lists.fedoraproject.org
-
Dennis Gilmore -
Jeff Sheltren -
Kevin Fenzi -
Till Maas -
Till Maas