[EPEL-devel] Re: Planning for EPEL9

[Michel Alexandre Salim]

On Thu, Jul 08, 2021 at 11:45:36AM +0200, Petr Pisar wrote:

> 
> DNF should acquire dependencies among repositories. I saw so many EPEL bug
> reports explained by missing powertools repository. The history will repeat.
> 
It... currently does, but only at the RPM level. So we can ensure the 
powertools repo
exists, but we can't easily override it to be enabled.

Long term I want to see dnf allowing overrides in a generic way, but this 
probably
won't be available in EL until at least EL10 or later. Short term... editing the
repo file, either by hand / with sed or with dnf config-manager, is the only 
way.

One problem is, once you touch the .repo file, you will no longer pick up any 
changes
introduced by later RPM updates (though that's rare) since they are marked
`%config(noreplace)`

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Andrew C Aitchison]

On Thu, 8 Jul 2021, Kevin Fenzi wrote:


On Wed, Jul 07, 2021 at 08:28:20PM -0400, Mohan Boddu wrote:

Hello all,

While we are already working on epel9-next enablement, there was a
discussion about how to handle epel9 when rhel9 goes GA. It is safe to
assume that a lot of the builds that are already in epel9-next at that
point of time should work on rhel9.


Yeah, a lot... but not all probibly.


There were couple of ideas thrown around from doing nothing to tagging
epel9-next builds to epel9, but I think the best way to solve this is,
mass branching the packages that have epel9-next branch and create
epel9 branch from it and then running a mass rebuild without any
changes to spec files. As epel9-next builds will already have a
.el9.next dist tag, we can simply rebuild whatever there is in epel9
branch (after branching epel9 branch from epel9-next branch).

Since the builds are done in alphanumerical order and does not
preserve build order, we might have to run this mass rebuild a few
times (thinking of 5 times) on the failed builds to get most of the
builds. This doesn't involve changing the spec files, just
resubmitting the failed tasks.


Well, it may be possible to just look at the failures after 2 passes and
see whats going on. I don't think we will have thousands of epel9-next
packages at that time, probibly hundreds? or even less.


Also, people who wish to opt out of this mass rebuild can add
'noautobuild' file to the epel9-next branch beforehand, this however
does not stop from creating the epel9 branch, just the package won't
be included in the rebuild. The idea here is, if the maintainer wishes
to support epel9-next, their final goal is to maintain the package for
epel9. So, we give them a branch, but will not rebuild their package
as they might have wanted to build their packages in the correct build
order (cough cough KDE :D).

This gives us a working epel9 with a bunch of working builds in a few
days after rhel9 GA and also we can create ftbfs bugs for those that
failed in the mass rebuild which will help maintainers to identify and
fix the issues.

Couple of questions that need to be answered here:
1. Is 5 times of rebuilds good enough or do we need more?


I think we should do 2 and then evaluate if more would help any.
Or I suppose we could go for 'steady state'. Ie, keep rebuilding only
the failures until the number of them is the same between runs. At that
point rebuilding them more won't help any.


Are we aiming for reproducibly built packages, like Debian
(I assume a completely reproducible *build* is still out of scope),
or is building every package on the new system sufficient ?

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Troy Dawson]

On Thu, Jul 8, 2021 at 7:51 AM Mohan Boddu  wrote:

> On Thu, Jul 8, 2021 at 9:58 AM Neal Gompa  wrote:
> >
> > On Thu, Jul 8, 2021 at 9:39 AM Kevin Fenzi  wrote:
> > >
> > > On Wed, Jul 07, 2021 at 08:32:27PM -0400, Neal Gompa wrote:
> > > >
> > > > This is very exciting!
> > > >
> > > > However, question here: At least for the bootstrap for RHEL 9 GA,
> > > > couldn't we use the EPEL9 next buildroot to rebuild everything once
> > > > instead of rebuilding 5 times? We can then remove the EPEL9 next
> > > > buildroot from the EPEL9 buildroot so that state doesn't persist
> after
> > > > everything is done. This also makes it so we can ignore the
> > > > "noautobuild" file the one time that all the content needs to be
> > > > properly seeded in EPEL9.
> > >
> > > But at the time of RHEL9.0 GA, cs9 may well have already moved on to
> > > 9.1... so that might result in stuff that doesn't work/install/depsolve
> > > with 9.0? Or am I missing something there...
> > >
> >
> > Based on what goes on now for EPEL8 and EPEL8 next, I think the
> > likelihood of that being a problem is fairly low. Ones where this is a
> > problem can be individually handled after the reset, and we'd waste
> > far less build resources in doing so.
>
> I still dont understand the advantages of it, we will be running the
> mass rebuild after RHEL 9.0 GA, so it wont be saving time (other than
> the time needed to setup the epel9 buildroot from rhel9 content). We
> will rebuild everything, so it wont be saving any builder/storage
> resources.
>
> I still prefer epel9 is built from rhel9 rather than CS after rhel
> goes GA as it always has been.
>

What about, instead of the epel9-next buildroot, we just use the epel9-next
repo.  Those packages that have already been built for epel9-next.
That way, we'd get all those dependencies that we built up in epel9-next,
without any CentOS Stream 9 packages that might have moved on.

Troy
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Mohan Boddu]

On Thu, Jul 8, 2021 at 9:58 AM Neal Gompa  wrote:
>
> On Thu, Jul 8, 2021 at 9:39 AM Kevin Fenzi  wrote:
> >
> > On Wed, Jul 07, 2021 at 08:32:27PM -0400, Neal Gompa wrote:
> > >
> > > This is very exciting!
> > >
> > > However, question here: At least for the bootstrap for RHEL 9 GA,
> > > couldn't we use the EPEL9 next buildroot to rebuild everything once
> > > instead of rebuilding 5 times? We can then remove the EPEL9 next
> > > buildroot from the EPEL9 buildroot so that state doesn't persist after
> > > everything is done. This also makes it so we can ignore the
> > > "noautobuild" file the one time that all the content needs to be
> > > properly seeded in EPEL9.
> >
> > But at the time of RHEL9.0 GA, cs9 may well have already moved on to
> > 9.1... so that might result in stuff that doesn't work/install/depsolve
> > with 9.0? Or am I missing something there...
> >
>
> Based on what goes on now for EPEL8 and EPEL8 next, I think the
> likelihood of that being a problem is fairly low. Ones where this is a
> problem can be individually handled after the reset, and we'd waste
> far less build resources in doing so.

I still dont understand the advantages of it, we will be running the
mass rebuild after RHEL 9.0 GA, so it wont be saving time (other than
the time needed to setup the epel9 buildroot from rhel9 content). We
will rebuild everything, so it wont be saving any builder/storage
resources.

I still prefer epel9 is built from rhel9 rather than CS after rhel
goes GA as it always has been.

>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> 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/epel-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Neal Gompa]

On Thu, Jul 8, 2021 at 9:39 AM Kevin Fenzi  wrote:
>
> On Wed, Jul 07, 2021 at 08:32:27PM -0400, Neal Gompa wrote:
> >
> > This is very exciting!
> >
> > However, question here: At least for the bootstrap for RHEL 9 GA,
> > couldn't we use the EPEL9 next buildroot to rebuild everything once
> > instead of rebuilding 5 times? We can then remove the EPEL9 next
> > buildroot from the EPEL9 buildroot so that state doesn't persist after
> > everything is done. This also makes it so we can ignore the
> > "noautobuild" file the one time that all the content needs to be
> > properly seeded in EPEL9.
>
> But at the time of RHEL9.0 GA, cs9 may well have already moved on to
> 9.1... so that might result in stuff that doesn't work/install/depsolve
> with 9.0? Or am I missing something there...
>

Based on what goes on now for EPEL8 and EPEL8 next, I think the
likelihood of that being a problem is fairly low. Ones where this is a
problem can be individually handled after the reset, and we'd waste
far less build resources in doing so.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Kevin Fenzi]

On Wed, Jul 07, 2021 at 08:32:27PM -0400, Neal Gompa wrote:
> 
> This is very exciting!
> 
> However, question here: At least for the bootstrap for RHEL 9 GA,
> couldn't we use the EPEL9 next buildroot to rebuild everything once
> instead of rebuilding 5 times? We can then remove the EPEL9 next
> buildroot from the EPEL9 buildroot so that state doesn't persist after
> everything is done. This also makes it so we can ignore the
> "noautobuild" file the one time that all the content needs to be
> properly seeded in EPEL9.

But at the time of RHEL9.0 GA, cs9 may well have already moved on to
9.1... so that might result in stuff that doesn't work/install/depsolve
with 9.0? Or am I missing something there... 

kevin


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Kevin Fenzi]

On Wed, Jul 07, 2021 at 08:28:20PM -0400, Mohan Boddu wrote:
> Hello all,
> 
> While we are already working on epel9-next enablement, there was a
> discussion about how to handle epel9 when rhel9 goes GA. It is safe to
> assume that a lot of the builds that are already in epel9-next at that
> point of time should work on rhel9.

Yeah, a lot... but not all probibly. 
 
> There were couple of ideas thrown around from doing nothing to tagging
> epel9-next builds to epel9, but I think the best way to solve this is,
> mass branching the packages that have epel9-next branch and create
> epel9 branch from it and then running a mass rebuild without any
> changes to spec files. As epel9-next builds will already have a
> .el9.next dist tag, we can simply rebuild whatever there is in epel9
> branch (after branching epel9 branch from epel9-next branch).
> 
> Since the builds are done in alphanumerical order and does not
> preserve build order, we might have to run this mass rebuild a few
> times (thinking of 5 times) on the failed builds to get most of the
> builds. This doesn't involve changing the spec files, just
> resubmitting the failed tasks.

Well, it may be possible to just look at the failures after 2 passes and
see whats going on. I don't think we will have thousands of epel9-next
packages at that time, probibly hundreds? or even less. 

> Also, people who wish to opt out of this mass rebuild can add
> 'noautobuild' file to the epel9-next branch beforehand, this however
> does not stop from creating the epel9 branch, just the package won't
> be included in the rebuild. The idea here is, if the maintainer wishes
> to support epel9-next, their final goal is to maintain the package for
> epel9. So, we give them a branch, but will not rebuild their package
> as they might have wanted to build their packages in the correct build
> order (cough cough KDE :D).
> 
> This gives us a working epel9 with a bunch of working builds in a few
> days after rhel9 GA and also we can create ftbfs bugs for those that
> failed in the mass rebuild which will help maintainers to identify and
> fix the issues.
> 
> Couple of questions that need to be answered here:
> 1. Is 5 times of rebuilds good enough or do we need more?

I think we should do 2 and then evaluate if more would help any. 
Or I suppose we could go for 'steady state'. Ie, keep rebuilding only
the failures until the number of them is the same between runs. At that
point rebuilding them more won't help any.

> 2. Do the mass rebuild builds have to go through bodhi or can we just
> directly tag them for stable compose?

In order to get a base of rhel9 packages out quickly, I would say just
make a stable compose with them. Then, all future ones use bodhi. 

kevin


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Petr Pisar]

V Thu, Jul 08, 2021 at 05:24:05AM -0400, Neal Gompa napsal(a):
> On Thu, Jul 8, 2021 at 5:19 AM Petr Pisar  wrote:
> >
> > V Thu, Jul 08, 2021 at 04:47:33AM -0400, Neal Gompa napsal(a):
> > > On Thu, Jul 8, 2021 at 4:41 AM Miro Hrončok  wrote:
> > > >
> > > > On 08. 07. 21 2:28, Mohan Boddu wrote:
> > > > > Also, people who wish to opt out of this mass rebuild can add
> > > > > 'noautobuild' file to the epel9-next branch beforehand, this however
> > > > > does not stop from creating the epel9 branch, just the package won't
> > > > > be included in the rebuild.
> > > >
> > > > I think there are 3 possible opt outs here:
> > > >
> > > > 1) The epel9-next packager does not intent to maintain the package in 
> > > > epel9,
> > > > only in epel9-next. While we might not like this goes, as long as there 
> > > > is no
> > > > policy against this approach, always creating the branch will create 
> > > > work for
> > > > the packager they have not signed for. I think there should be an opt 
> > > > out for
> > > > branching as well.
> > > >
> > >
> > > This is not a valid use-case.
> >
> > Why?
> >
> > If you were a CentOS user who moved to CentOS Stream, then you are going to
> > use epel9.next. You have no use of epel9.
> >
> 
> That is not the point of epel-next. It's only intended to be a overlay
> for resolving issues between RHEL minor releases (or in this case,
> bootstrapping before RHEL major releases are actually out).
> 
> EPEL-next is usually layered on top of EPEL, not the other way around.
> I'm proposing we layer EPEL on EPEL-next just long enough to do a mass
> rebuild cycle to populate EPEL9, then revert to the normal setup.
> 
I see. So if you are a CentOS Stream user, you need use both epel9 and
epel9-next.

In that case the EPEL 8 Next annoucement

was quite misleading. Especially without reading the linked Wiki page.

DNF should acquire dependencies among repositories. I saw so many EPEL bug
reports explained by missing powertools repository. The history will repeat.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Neal Gompa]

On Thu, Jul 8, 2021 at 5:19 AM Petr Pisar  wrote:
>
> V Thu, Jul 08, 2021 at 04:47:33AM -0400, Neal Gompa napsal(a):
> > On Thu, Jul 8, 2021 at 4:41 AM Miro Hrončok  wrote:
> > >
> > > On 08. 07. 21 2:28, Mohan Boddu wrote:
> > > > Also, people who wish to opt out of this mass rebuild can add
> > > > 'noautobuild' file to the epel9-next branch beforehand, this however
> > > > does not stop from creating the epel9 branch, just the package won't
> > > > be included in the rebuild.
> > >
> > > I think there are 3 possible opt outs here:
> > >
> > > 1) The epel9-next packager does not intent to maintain the package in 
> > > epel9,
> > > only in epel9-next. While we might not like this goes, as long as there 
> > > is no
> > > policy against this approach, always creating the branch will create work 
> > > for
> > > the packager they have not signed for. I think there should be an opt out 
> > > for
> > > branching as well.
> > >
> >
> > This is not a valid use-case.
>
> Why?
>
> If you were a CentOS user who moved to CentOS Stream, then you are going to
> use epel9.next. You have no use of epel9.
>

That is not the point of epel-next. It's only intended to be a overlay
for resolving issues between RHEL minor releases (or in this case,
bootstrapping before RHEL major releases are actually out).

EPEL-next is usually layered on top of EPEL, not the other way around.
I'm proposing we layer EPEL on EPEL-next just long enough to do a mass
rebuild cycle to populate EPEL9, then revert to the normal setup.





--
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Petr Pisar]

V Thu, Jul 08, 2021 at 04:47:33AM -0400, Neal Gompa napsal(a):
> On Thu, Jul 8, 2021 at 4:41 AM Miro Hrončok  wrote:
> >
> > On 08. 07. 21 2:28, Mohan Boddu wrote:
> > > Also, people who wish to opt out of this mass rebuild can add
> > > 'noautobuild' file to the epel9-next branch beforehand, this however
> > > does not stop from creating the epel9 branch, just the package won't
> > > be included in the rebuild.
> >
> > I think there are 3 possible opt outs here:
> >
> > 1) The epel9-next packager does not intent to maintain the package in epel9,
> > only in epel9-next. While we might not like this goes, as long as there is 
> > no
> > policy against this approach, always creating the branch will create work 
> > for
> > the packager they have not signed for. I think there should be an opt out 
> > for
> > branching as well.
> >
> 
> This is not a valid use-case.

Why?

If you were a CentOS user who moved to CentOS Stream, then you are going to
use epel9.next. You have no use of epel9.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Neal Gompa]

On Thu, Jul 8, 2021 at 4:41 AM Miro Hrončok  wrote:
>
> On 08. 07. 21 2:28, Mohan Boddu wrote:
> > Also, people who wish to opt out of this mass rebuild can add
> > 'noautobuild' file to the epel9-next branch beforehand, this however
> > does not stop from creating the epel9 branch, just the package won't
> > be included in the rebuild.
>
> I think there are 3 possible opt outs here:
>
> 1) The epel9-next packager does not intent to maintain the package in epel9,
> only in epel9-next. While we might not like this goes, as long as there is no
> policy against this approach, always creating the branch will create work for
> the packager they have not signed for. I think there should be an opt out for
> branching as well.
>

This is not a valid use-case. If we don't have this explicitly blocked
in policy yet, we need to make this explicit.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Miro Hrončok]

On 08. 07. 21 2:28, Mohan Boddu wrote:

Also, people who wish to opt out of this mass rebuild can add
'noautobuild' file to the epel9-next branch beforehand, this however
does not stop from creating the epel9 branch, just the package won't
be included in the rebuild.


I think there are 3 possible opt outs here:

1) The epel9-next packager does not intent to maintain the package in epel9, 
only in epel9-next. While we might not like this goes, as long as there is no 
policy against this approach, always creating the branch will create work for 
the packager they have not signed for. I think there should be an opt out for 
branching as well.


2) The epel9-next packager does intent to maintain the package in epel9, 
however the commits in the epel9-next branch already contain stuff that is 
necessary for c9s but doe snot work with RHEL 9.0. They want to branch for 
epel9, but from an earlier commit, so they don't need to revert and eventually 
unrevert later. (Yes, I know they could potentially build from an older commit, 
but that's not very transparent and many packagers don't do that.) I think 
there should be an opt out for branching with all the comits as well (i.e. opt 
in to create the epel9 branch empty).


3) The epel9-next packager does intent to maintain the package in epel9, all 
the commits are fine, but they intent to do manual bootstrapping themselves. I 
agree there should be an opt out for automatically rebuilding the package. 
However, I don't think the noautobuild file in git is ideal. At this point of 
EL 9 life cycle, many packagers are likely to at least attempt to maintain 
Fedora and EPEL 9 packages from identical branches. By requiring to add an EPEL 
9 specific file, we put them in a bad position. They would essentially be 
forced to pick the least bad solution:


 a) divert the branches like they did for the package.cfg file in epel8¹
 b) put the file to Fedora branches, essentially disabling mass rebuilds
 c) not opt out from building and deal with the rebuilds later by release bumps

And I think all three options either generate unnecessary work or have other 
consequences.


¹ IIRC this was a huge 🥙 for packagers trying to use a single branch for 
Fedora and EPEL 8.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Petr Pisar]

V Wed, Jul 07, 2021 at 08:32:27PM -0400, Neal Gompa napsal(a):
> On Wed, Jul 7, 2021 at 8:28 PM Mohan Boddu  wrote:
> > While we are already working on epel9-next enablement, there was a
> > discussion about how to handle epel9 when rhel9 goes GA. It is safe to
> > assume that a lot of the builds that are already in epel9-next at that
> > point of time should work on rhel9.
[...]
> > Couple of questions that need to be answered here:
> > 1. Is 5 times of rebuilds good enough or do we need more?
> > 2. Do the mass rebuild builds have to go through bodhi or can we just
> > directly tag them for stable compose?
> >
> > Any suggestions appreciated.
> >
> 
> This is very exciting!
> 
> However, question here: At least for the bootstrap for RHEL 9 GA,
> couldn't we use the EPEL9 next buildroot to rebuild everything once
> instead of rebuilding 5 times?

That would be indeed helpful when dealing with build cycles. Because whatever
times you attempt to rebuild them without changing their spec files (or spec
macros), you won't succeed.

On the other hand it arises a problem with disappearing (build-)required
packages whose maintainer requested noautobuild after uninheriting epel9-next
builds. (E.g. you would get epel9 packages that you cannot build again.)
But that should not be a big problem because mismatches between those two
requiring and required packages would appear even in the original approach.
Only later. And naturally, maintainers would have to cooperate and agree
wheter to keep or remove both of the packages.

Maybe one could do the mass rebuild twice. The second one without epel9.next
builds to verify that epel9 is self-contained. The scratch rebuilds would do
either.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Planning for EPEL9

[Neal Gompa]

On Wed, Jul 7, 2021 at 8:28 PM Mohan Boddu  wrote:
>
> Hello all,
>
> While we are already working on epel9-next enablement, there was a
> discussion about how to handle epel9 when rhel9 goes GA. It is safe to
> assume that a lot of the builds that are already in epel9-next at that
> point of time should work on rhel9.
>
> There were couple of ideas thrown around from doing nothing to tagging
> epel9-next builds to epel9, but I think the best way to solve this is,
> mass branching the packages that have epel9-next branch and create
> epel9 branch from it and then running a mass rebuild without any
> changes to spec files. As epel9-next builds will already have a
> .el9.next dist tag, we can simply rebuild whatever there is in epel9
> branch (after branching epel9 branch from epel9-next branch).
>
> Since the builds are done in alphanumerical order and does not
> preserve build order, we might have to run this mass rebuild a few
> times (thinking of 5 times) on the failed builds to get most of the
> builds. This doesn't involve changing the spec files, just
> resubmitting the failed tasks.
>
> Also, people who wish to opt out of this mass rebuild can add
> 'noautobuild' file to the epel9-next branch beforehand, this however
> does not stop from creating the epel9 branch, just the package won't
> be included in the rebuild. The idea here is, if the maintainer wishes
> to support epel9-next, their final goal is to maintain the package for
> epel9. So, we give them a branch, but will not rebuild their package
> as they might have wanted to build their packages in the correct build
> order (cough cough KDE :D).
>
> This gives us a working epel9 with a bunch of working builds in a few
> days after rhel9 GA and also we can create ftbfs bugs for those that
> failed in the mass rebuild which will help maintainers to identify and
> fix the issues.
>
> Couple of questions that need to be answered here:
> 1. Is 5 times of rebuilds good enough or do we need more?
> 2. Do the mass rebuild builds have to go through bodhi or can we just
> directly tag them for stable compose?
>
> Any suggestions appreciated.
>

This is very exciting!

However, question here: At least for the bootstrap for RHEL 9 GA,
couldn't we use the EPEL9 next buildroot to rebuild everything once
instead of rebuilding 5 times? We can then remove the EPEL9 next
buildroot from the EPEL9 buildroot so that state doesn't persist after
everything is done. This also makes it so we can ignore the
"noautobuild" file the one time that all the content needs to be
properly seeded in EPEL9.

I would also say that mass rebuild should just be directly tagged in.
Doing Bodhi stuff is going to make this incredibly slow and painful,
so I'd say don't bother.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure