In trying to get resources allocated, I have been working on the project plans for 8. The original one was at https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8
As of today an updated one is at
https://smooge.fedorapeople.org/EPEL-8/
which I will translate to wiki for better editing this weekend. However the core items I am currently working on
1. https://smooge.fedorapeople.org/EPEL-8/EPEL-8-known-package-list.txt contains a list of packages I know we can't rebuild (because they will be in CentOS/RHEL-8 and a list of packages I know will build with our first attempt at EPEL-8
2. I am currently working on patches for https://github.com/puiterwijk/grobisplitter so that I can get it to work with how Red Hat publishes its packages. I am also working on it just breaking out default modules.
3. I have discovered that modules which have no default channel should not be used to build non-modular packages against. There are 6 modules set up this way ( 389-ds, libselinux-python, mod_auth_openidc, parfait, pki-core, pki-deps ) and so the packages in them will not be available to build against. Even after we have some ursa-* solution in place, packages requiring them must be part of a module.
NOTICE: I have been informed that various parts of the document have major errors. I will be updating and fixing today. Problems include the mentioning various javapackages which were shipped and not spelling out that one of the differences between internal and external is usra-major
On Wed, 15 May 2019 at 18:06, Stephen John Smoogen smooge@gmail.com wrote:
In trying to get resources allocated, I have been working on the project plans for 8. The original one was at https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8
As of today an updated one is at
https://smooge.fedorapeople.org/EPEL-8/
which I will translate to wiki for better editing this weekend. However the core items I am currently working on
a list of packages I know we can't rebuild (because they will be in CentOS/RHEL-8 and a list of packages I know will build with our first attempt at EPEL-8
- I am currently working on patches for
https://github.com/puiterwijk/grobisplitter so that I can get it to work with how Red Hat publishes its packages. I am also working on it just breaking out default modules.
- I have discovered that modules which have no default channel should not
be used to build non-modular packages against. There are 6 modules set up this way ( 389-ds, libselinux-python, mod_auth_openidc, parfait, pki-core, pki-deps ) and so the packages in them will not be available to build against. Even after we have some ursa-* solution in place, packages requiring them must be part of a module.
-- Stephen J Smoogen.
On Wed, 15 May 2019 18:06:21 -0400 Stephen John Smoogen smooge@gmail.com wrote:
In trying to get resources allocated, I have been working on the project plans for 8. The original one was at https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8
As of today an updated one is at
is there a plan to start EPEL-8 with all arches supported by RHEL-8? So s390x will be also included? We never bootstrapped EPEL-7 for s390x, but it wasn't a blocker because there is a rebuild available from the ClefOS people (they do a CentOS rebuild for s390x). We are registering questions about availability of EPEL for s390x quite regularly.
Thanks
Dan
On Thu, 16 May 2019 at 09:48, Dan Horák dan@danny.cz wrote:
On Wed, 15 May 2019 18:06:21 -0400 Stephen John Smoogen smooge@gmail.com wrote:
In trying to get resources allocated, I have been working on the project plans for 8. The original one was at https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8
As of today an updated one is at
is there a plan to start EPEL-8 with all arches supported by RHEL-8? So s390x will be also included? We never bootstrapped EPEL-7 for s390x, but it wasn't a blocker because there is a rebuild available from the ClefOS people (they do a CentOS rebuild for s390x). We are registering questions about availability of EPEL for s390x quite regularly.
It will depend on the resources available for s390x. Currently all s390x builds are done on a system shared with other builds which is severely overloaded. Adding more build targets needs to be weighed with 'can we do it without breaking our house of cards anymore'. If more resources are available or other changes, it will be seriously looked at. [I have downloaded RHEL-8 s390x just in case.]
Thanks Dan
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
On Thu, 16 May 2019 10:31:48 -0400 Stephen John Smoogen smooge@gmail.com wrote:
On Thu, 16 May 2019 at 09:48, Dan Horák dan@danny.cz wrote:
On Wed, 15 May 2019 18:06:21 -0400 Stephen John Smoogen smooge@gmail.com wrote:
In trying to get resources allocated, I have been working on the project plans for 8. The original one was at https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8
As of today an updated one is at
is there a plan to start EPEL-8 with all arches supported by RHEL-8? So s390x will be also included? We never bootstrapped EPEL-7 for s390x, but it wasn't a blocker because there is a rebuild available from the ClefOS people (they do a CentOS rebuild for s390x). We are registering questions about availability of EPEL for s390x quite regularly.
It will depend on the resources available for s390x. Currently all s390x builds are done on a system shared with other builds which is severely overloaded. Adding more build targets needs to be weighed with 'can we do it without breaking our house of cards anymore'. If more resources are available or other changes, it will be seriously looked at. [I have downloaded RHEL-8 s390x just in case.]
BTW do we know how much load does EPEL generate in koji? 1% or 10 % or 30%? It should be just regular builds and composes for updates, but no images or appliances, no modules.
Dan
On Fri, 17 May 2019 at 09:23, Dan Horák dan@danny.cz wrote:
On Thu, 16 May 2019 10:31:48 -0400 Stephen John Smoogen smooge@gmail.com wrote:
On Thu, 16 May 2019 at 09:48, Dan Horák dan@danny.cz wrote:
On Wed, 15 May 2019 18:06:21 -0400 Stephen John Smoogen smooge@gmail.com wrote:
In trying to get resources allocated, I have been working on the project plans for 8. The original one was at https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8
As of today an updated one is at
is there a plan to start EPEL-8 with all arches supported by RHEL-8? So s390x will be also included? We never bootstrapped EPEL-7 for s390x, but it wasn't a blocker because there is a rebuild available from the ClefOS people (they do a CentOS rebuild for s390x). We are registering questions about availability of EPEL for s390x quite regularly.
It will depend on the resources available for s390x. Currently all s390x builds are done on a system shared with other builds which is severely overloaded. Adding more build targets needs to be weighed with 'can we do it without breaking our house of cards anymore'. If more resources are available or other changes, it will be seriously looked at. [I have downloaded RHEL-8 s390x just in case.]
BTW do we know how much load does EPEL generate in koji? 1% or 10 % or 30%? It should be just regular builds and composes for updates, but no images or appliances, no modules.
Probably lower in comparison to Fedora builds.. but currently we are seeing nearly daily complaints about builds hanging/crashing on the s390x.
I would like to add s390x to EL7 and EL8. I just want to make it a super-stretch goal for 8.0, a stretch goal for 8.1, and a goal for 8.2. We might get to it much sooner, but I would prefer not to add to the bailing wire, superglue, and long hours of fruitless debugging we have due to the complicated way we are building it.
So, I don't have a handle on the whole modularity thing... still trying to understand what's what with that. But this caught my eye in your "Open Questions":
- Some normally leaf packages like screen are inside of the Red Hat hidden buildroot package set. Having them built in EPEL is likely to cause conflicts on user systems and divergence with RHEL. EPEL maintains agreed upon policies for these cases so using the repo doesn’t cause pain for RHEL customers or users.
What does that actually mean? I'm a consumer of CentOS rather than RHEL these days, so I haven't really dug into version 8 yet. I do use screen a lot, so what does "inside of the Red Hat hidden buildroot package set" mean for me?
On Thu, 16 May 2019 at 09:59, Chris Adams linux@cmadams.net wrote:
So, I don't have a handle on the whole modularity thing... still trying to understand what's what with that. But this caught my eye in your "Open Questions":
- Some normally leaf packages like screen are inside of the Red Hat hidden buildroot package set. Having them built in EPEL is likely to cause conflicts on user systems and divergence with RHEL. EPEL maintains agreed upon policies for these cases so using the repo doesn’t cause pain for RHEL customers or users.
What does that actually mean? I'm a consumer of CentOS rather than RHEL these days, so I haven't really dug into version 8 yet. I do use screen a lot, so what does "inside of the Red Hat hidden buildroot package set" mean for me?
RHEL-8 was built with various packages which are not shipped in BaseOS/AppStream/CRB. Some like screen are in the buildroot for the packages which depend on them but were decided not to be shipped. Thus they are hidden buildroot set. They were however branched to CentOS git repository. While building a newer version of screen and putting it in EPEL might not break anything, other packages might cause problems which we don't have the resources to track down and debug. So I would like to not have EPEL rebuild any package which was branched to CentOS EL-8.
I will clarify the document.
-- Chris Adams linux@cmadams.net _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
Once upon a time, Stephen John Smoogen smooge@gmail.com said:
RHEL-8 was built with various packages which are not shipped in BaseOS/AppStream/CRB. Some like screen are in the buildroot for the packages which depend on them but were decided not to be shipped.
Huh, that's... weird. As someone that's been using screen for, hmm, longer than Red Hat's been in business I think... that's annoying.
I guess the CentOS side would be the more appropriate place to ask, but would it be practical to gather up these packages and make a CentOS "module" of them? Sorry if that doesn't make sense (like I said, still trying to get my head around modularity).
On Thu, May 16, 2019 at 6:50 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Stephen John Smoogen smooge@gmail.com said:
RHEL-8 was built with various packages which are not shipped in BaseOS/AppStream/CRB. Some like screen are in the buildroot for the packages which depend on them but were decided not to be shipped.
Huh, that's... weird. As someone that's been using screen for, hmm, longer than Red Hat's been in business I think... that's annoying.
Internally, during the discussions, it was expected that screen would be in EPEL8.
<my opinion> short answer: screen should be in EPEL8 as a normal package.
Long answer: I think that any package that a non-redhatter cannot tell is part of RHEL8, such as screen, is fair game for EPEL8. I believe this is just those packages like Stephen said, that are part of buildroot, but weren't shipped. I don't think they need to be in a module (unless it makes sense), but can be their own package. </my opinion>
epel-devel@lists.fedoraproject.org
-
Chris Adams -
Dan Horák -
Stephen John Smoogen -
Troy Dawson