You can help prepare now for EPEL 10 and beyond

[Yaakov Selkowitz]

ELN Extras automatically creates EPEL-like builds of packages built on 
top of ELN, which allows for early build and dependency testing of 
packages which are candidates for the next versions of EPEL.  While RHEL 
10 has already branched from ELN, it still hasn't diverged all that much 
from rawhide, so testing now will also (and in fact already has) help 
detect potential issues building EPEL 10.  Results of ELN Extras are 
displayed in Content Resolver:

https://tiny.distro.builders/view--view-eln-extras.html

Here is an example of a workload-specific CR config:

https://github.com/minimization/content-resolver-input/blob/main/configs/eln...

And an example of a maintainer catch-all CR config:

https://github.com/minimization/content-resolver-input/blob/main/configs/eln...

You can add packages to ELN Extras by creating your own configs through 
a PR in the following repo:

https://github.com/minimization/content-resolver-input/

[Carl George]

On Thu, Aug 8, 2024 at 11:34 AM Yaakov Selkowitz  wrote:
> ELN Extras automatically creates EPEL-like builds of packages built on
> top of ELN, which allows for early build and dependency testing of
> packages which are candidates for the next versions of EPEL.  While RHEL
> 10 has already branched from ELN, it still hasn't diverged all that much
> from rawhide, so testing now will also (and in fact already has) help
> detect potential issues building EPEL 10.  Results of ELN Extras are
> displayed in Content Resolver:
>
> https://tiny.distro.builders/view--view-eln-extras.html
>
> Here is an example of a workload-specific CR config:
>
> https://github.com/minimization/content-resolver-input/blob/main/configs/eln...
>
> And an example of a maintainer catch-all CR config:
>
> https://github.com/minimization/content-resolver-input/blob/main/configs/eln...
>
> You can add packages to ELN Extras by creating your own configs through
> a PR in the following repo:
>
> https://github.com/minimization/content-resolver-input/
>
> --
> Yaakov Selkowitz
> Principal Software Engineer, Emerging RHEL
> Red Hat, Inc.
>
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Can you tell us more about the instances of ELN Extras helping
identify build problems for EPEL 10?  Examples of those could help
packagers avoid the same mistakes and demonstrate the value of taking
the time to set up their own workloads.

I have a high level understanding of ELN Extras and the benefits of
ensuring a spec file's conditionals stay compatible with the new
macros as they're introduced in ELN.  I would like to know more about
what a failure looks like for an ELN Extras workload.  I've configured
one workload myself, but I've never received an email or notification
about it failing.  Maybe I'm just lucky and the packages in that
workload had no issues, but if they did, how would that be presented
to me?

What is the ELN SIGs viewpoint on package permissions?  Can EPEL
maintainers add workloads that include packages they don't have
permission to commit to or request branches for?  This is a regular
issue for new EPEL major versions, where a maintainer doesn't have
access to request new EPEL branches for all their dependencies.