[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-10 Thread Stephen John Smoogen 
On Wed, 10 Feb 2021 at 14:48, Miro Hrončok  wrote:

> On 10. 02. 21 20:24, Stephen John Smoogen wrote:
> >
> >
> > On Wed, 10 Feb 2021 at 14:19, Miro Hrončok  > > wrote:
> >
> > On 10. 02. 21 19:53, Stephen John Smoogen wrote:
> >  > fedpkg-minimal
> >  > epel-release
> >  > epel-rpm-macros
> >
> >
> > Those make perfect sense to me.
> >
> >  > fedpkg
> >  > koji
> >  > bodhi
> >
> > But I don't understand why those are required. What am I missing?
> >
> >
> > A lot of EPEL developers do their development on an EL system and use
> the base
> > tools to do so. That needs fedpkg to be on that system to talk to
> koji/bodhi and
> > a host of other items. In order to get fedpkg to do that you end up
> needing
> > parts of koji and bodhi because of library needs. That requires the yak
> train.
>
> Oh, so this is only needed to make EPEL "self hosting" in a sense. So
> packagers
> can contribute to EPEL 9 from an EL 9 system.
>
> I agree that this is a valuable goal, but should this be an essential part
> of
> the initial "bootstrap"?
>
>
Well it depends on what bootstrap means. Is it 'what is needed to have a
package set to call it EPEL' or 'what are the minimal set of packages
needed for an EPEL packager to be able to work'

In the past it was enough to get enough of the package set together that
others can build and add packages to the distro. Since a LOT of packages
use fedpkg local etc for their testing/porting.. having fedpkg fully
functional was a requirement.  However that does mean extra work for things
like this which no one is working on and no one is paying anyone to work
on. So maybe the group should say it is a requirement that development is
done in Fedora instead.



> I'm asking because I know that yak train has a lot of packages, including
> some
> deprecated that I maintain in Fedora. So I'd rather see a real maintainer
> deciding to package e.g. python-nose or python-mock for EPEL 9, than a SIG
> member who is more likely to import/build it once and move on.
>
> --
> 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
>


-- 
Stephen J Smoogen.
___
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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-10 Thread Miro Hrončok 

On 10. 02. 21 20:24, Stephen John Smoogen wrote:



On Wed, 10 Feb 2021 at 14:19, Miro Hrončok > wrote:


On 10. 02. 21 19:53, Stephen John Smoogen wrote:
 > fedpkg-minimal
 > epel-release
 > epel-rpm-macros


Those make perfect sense to me.

 > fedpkg
 > koji
 > bodhi

But I don't understand why those are required. What am I missing?


A lot of EPEL developers do their development on an EL system and use the base 
tools to do so. That needs fedpkg to be on that system to talk to koji/bodhi and 
a host of other items. In order to get fedpkg to do that you end up needing 
parts of koji and bodhi because of library needs. That requires the yak train.


Oh, so this is only needed to make EPEL "self hosting" in a sense. So packagers 
can contribute to EPEL 9 from an EL 9 system.


I agree that this is a valuable goal, but should this be an essential part of 
the initial "bootstrap"?


I'm asking because I know that yak train has a lot of packages, including some 
deprecated that I maintain in Fedora. So I'd rather see a real maintainer 
deciding to package e.g. python-nose or python-mock for EPEL 9, than a SIG 
member who is more likely to import/build it once and move on.


--
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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-10 Thread Stephen John Smoogen 
On Wed, 10 Feb 2021 at 14:24, Stephen John Smoogen  wrote:

>
>
> On Wed, 10 Feb 2021 at 14:19, Miro Hrončok  wrote:
>
>> On 10. 02. 21 19:53, Stephen John Smoogen wrote:
>> > fedpkg-minimal
>> > epel-release
>> > epel-rpm-macros
>>
>>
>> Those make perfect sense to me.
>>
>> > fedpkg
>> > koji
>> > bodhi
>>
>> But I don't understand why those are required. What am I missing?
>>
>>
> A lot of EPEL developers do their development on an EL system and use the
> base tools to do so. That needs fedpkg to be on that system to talk to
> koji/bodhi and a host of other items. In order to get fedpkg to do that you
> end up needing parts of koji and bodhi because of library needs. That
> requires the yak train.
>
>

All fedpkg-minimal is

#!/bin/bash

baseurl=http://pkgs.fedoraproject.org/repo/pkgs
pkgname=$(pwd| sed -e 's|^/.*/||g')
cat sources | while read line; do
tarball=$(echo  $line| sed -e 's|.* ||g')
md5sum=$(echo $line| sed -e 's| .*||g')
wget $baseurl/$pkgname/$tarball/$md5sum/$tarball
done

it does not do builds, it does not have any of the 'local' tools developers
expect and so the full fedpkg is what is expected for a person to have.





> --
>> 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
>>
>
>
> --
> Stephen J Smoogen.
>
>

-- 
Stephen J Smoogen.
___
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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-10 Thread Stephen John Smoogen 
On Wed, 10 Feb 2021 at 14:19, Miro Hrončok  wrote:

> On 10. 02. 21 19:53, Stephen John Smoogen wrote:
> > fedpkg-minimal
> > epel-release
> > epel-rpm-macros
>
>
> Those make perfect sense to me.
>
> > fedpkg
> > koji
> > bodhi
>
> But I don't understand why those are required. What am I missing?
>
>
A lot of EPEL developers do their development on an EL system and use the
base tools to do so. That needs fedpkg to be on that system to talk to
koji/bodhi and a host of other items. In order to get fedpkg to do that you
end up needing parts of koji and bodhi because of library needs. That
requires the yak train.


> --
> 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
>


-- 
Stephen J Smoogen.
___
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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-10 Thread Miro Hrončok 

On 10. 02. 21 19:53, Stephen John Smoogen wrote:

fedpkg-minimal
epel-release
epel-rpm-macros



Those make perfect sense to me.


fedpkg
koji
bodhi


But I don't understand why those are required. What am I missing?

--
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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-10 Thread Stephen John Smoogen 
On Mon, 8 Feb 2021 at 17:36, Troy Dawson  wrote:

> On Mon, Feb 8, 2021 at 11:50 AM Kevin Fenzi  wrote:
> >
> > On Mon, Feb 08, 2021 at 08:19:24AM -0500, Stephen John Smoogen wrote:
> > > There is a little nuance here. In order to get the repository going,
> we had
> > > to 'mass-branch' about 40 or so packages. fedpkg and some other items
> > > require quite a few packages which all have to be done at once. Without
> > > those you can't build anything else to put into EPEL... so I would say
> that
> > > EPEL is the specific set of packages in order to get a minimal
> repository
> > > working in the Fedora Build System. Everything else is just extras
> people
> > > add to it.
> >
> > That is an excellent point. Perhaps we should try and identify those
> > packages and see if we can just add epel-packagers sig to all of them?
> > Do we have any record of those?
> >
> If they were the packages that I built they were
> fedpkg
> koji
> bodhi
>
> And then all the packages needed to build them, that weren't in RHEL.
> But there might have been others that Smooge did.
>
>
For EL8 it was a larger pile of yaks than what tdawson had originally.  I
found all the src.rpms from that timeframe (and others have been updated
since then so would need to be included also). Looking at the initial EPEL
build dates of 2019-07, there are still about 124 packages which were in
that grouping because some things had dropped out of beta and other things
needed a long line of bootstrapping

That said I can try to replicate on a weekend.

fedpkg-minimal
fedpkg
koji
bodhi
epel-release
epel-rpm-macros


I can re

-- 
Stephen J Smoogen.
___
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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-08 Thread Troy Dawson 
On Mon, Feb 8, 2021 at 11:50 AM Kevin Fenzi  wrote:
>
> On Mon, Feb 08, 2021 at 08:19:24AM -0500, Stephen John Smoogen wrote:
> > There is a little nuance here. In order to get the repository going, we had
> > to 'mass-branch' about 40 or so packages. fedpkg and some other items
> > require quite a few packages which all have to be done at once. Without
> > those you can't build anything else to put into EPEL... so I would say that
> > EPEL is the specific set of packages in order to get a minimal repository
> > working in the Fedora Build System. Everything else is just extras people
> > add to it.
>
> That is an excellent point. Perhaps we should try and identify those
> packages and see if we can just add epel-packagers sig to all of them?
> Do we have any record of those?
>
If they were the packages that I built they were
fedpkg
koji
bodhi

And then all the packages needed to build them, that weren't in RHEL.
But there might have been others that Smooge did.

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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-08 Thread Miro Hrončok 

On 08. 02. 21 14:19, Stephen John Smoogen wrote:
There is a little nuance here. In order to get the repository going, we had to 
'mass-branch' about 40 or so packages. fedpkg and some other items require quite 
a few packages which all have to be done at once. Without those you can't build 
anything else to put into EPEL... so I would say that EPEL is the specific set 
of packages in order to get a minimal repository working in the Fedora Build 
System. Everything else is just extras people add to it.


Is this needed to allow building EPEL 9 packages from RHEL 9 system? Should that 
indeed be the minimal requirement?


Because AFAIK we don't need fedpkg in EPEL 9 to build packages in mock/koji, 
just fedpkg-minimal, epel-release and epel-rpm-macros (+ eventually other epel 
packages required by that one, but I imagine that to be zero at the start).


--
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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-08 Thread Kevin Fenzi 
On Mon, Feb 08, 2021 at 08:19:24AM -0500, Stephen John Smoogen wrote:
> There is a little nuance here. In order to get the repository going, we had
> to 'mass-branch' about 40 or so packages. fedpkg and some other items
> require quite a few packages which all have to be done at once. Without
> those you can't build anything else to put into EPEL... so I would say that
> EPEL is the specific set of packages in order to get a minimal repository
> working in the Fedora Build System. Everything else is just extras people
> add to it.

That is an excellent point. Perhaps we should try and identify those
packages and see if we can just add epel-packagers sig to all of them?
Do we have any record of those?

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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-08 Thread Stephen John Smoogen 
On Sun, 7 Feb 2021 at 18:26, Kevin Fenzi  wrote:

> Overall this seems fine to me, a few nitpicks inline...
>
> On Fri, Feb 05, 2021 at 01:51:15PM -0800, Troy Dawson wrote:
> > This is a proposal.  It's mainly writing down what I think most of us
> > agreed on at last weeks EPEL Steering Committee meeting.  Feel free to
> > continue to discuss and/or have ideas.
> > I've been asked by a couple places what the plans were, so I'm writing
> it here.
> >
> > Overall Plan:
> > - epel-next is an epel branch that is built against CentOS Stream.
> epel-next
> > only has the packages that would be incompatible with released RHEL
> > builds, or if an EPEL maintainer is updating a package that will only
> > be released to regular EPEL at the next RHEL release.
> > - We plan on creating epel9-next when CentOS 9 Stream has a public
> > repository.  We plan on using the EPEL Packaging SIG to populate it
> > early with common packages, although any EPEL package maintainers can
> > add their packages whenever they want.
>
> This part I am unsure of. What are 'common packages' ?
> We should make sure and ask maintainers to branch and maintain packages
> they want for this, but I think it would be odd to just do it without
> them being in the loop. We never never 'mass branched' things in the
> past. EPEL isn't a specific set of packages, it's packages maintainers
> want to maintain. That said, if there's packages of interest where the
> maintainers are not interested in epel, the epel sig should definitely
> branch and maintain those.
>
>
There is a little nuance here. In order to get the repository going, we had
to 'mass-branch' about 40 or so packages. fedpkg and some other items
require quite a few packages which all have to be done at once. Without
those you can't build anything else to put into EPEL... so I would say that
EPEL is the specific set of packages in order to get a minimal repository
working in the Fedora Build System. Everything else is just extras people
add to it.



> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>


-- 
Stephen J Smoogen.
___
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

[EPEL-devel] Re: Proposal: EPEL9 timeline

2021-02-07 Thread Kevin Fenzi 
Overall this seems fine to me, a few nitpicks inline...

On Fri, Feb 05, 2021 at 01:51:15PM -0800, Troy Dawson wrote:
> This is a proposal.  It's mainly writing down what I think most of us
> agreed on at last weeks EPEL Steering Committee meeting.  Feel free to
> continue to discuss and/or have ideas.
> I've been asked by a couple places what the plans were, so I'm writing it 
> here.
> 
> Overall Plan:
> - epel-next is an epel branch that is built against CentOS Stream.  epel-next
> only has the packages that would be incompatible with released RHEL
> builds, or if an EPEL maintainer is updating a package that will only
> be released to regular EPEL at the next RHEL release.
> - We plan on creating epel9-next when CentOS 9 Stream has a public
> repository.  We plan on using the EPEL Packaging SIG to populate it
> early with common packages, although any EPEL package maintainers can
> add their packages whenever they want.

This part I am unsure of. What are 'common packages' ? 
We should make sure and ask maintainers to branch and maintain packages
they want for this, but I think it would be odd to just do it without
them being in the loop. We never never 'mass branched' things in the
past. EPEL isn't a specific set of packages, it's packages maintainers
want to maintain. That said, if there's packages of interest where the
maintainers are not interested in epel, the epel sig should definitely
branch and maintain those. 

> - We plan on creating normal EPEL9 after the RHEL 9.0 GA release, just
> like normal.  No sooner.  All epel9-next packages will be rebuilt on
> EPEL9.  They will not be "tagged over".  This rebuild should be by whoever
> built it in epel9-next.

This I am also not a fan of. What if you make a epel9-next branch for
something, but you don't (for whatever reason) want to put it in epel9?
I think we should just open new epel9 branches at epel9 time and
maintaienrs can branch and build them (again, if people don't care the
epel packagers sig can do all the ones they manage right up front).
> 
> Approximate Timelines:
> - All of these timelines depend on (A) CentOS 9 Stream / RHEL9 actual dates
> and (B) availability of EPEL volunteers.  Please note, EPEL is
> completely volunteers, and sometimes "day jobs" make EPEL timelines slip.
> - epel9-next - July 2021
> -- CentOS 9 Stream should have a public repository in April 2021
> -- Should take about 3 months to setup
> - epel9 - October 2022
> -- RHEL 9.0 should be released around May 2022
> -- Should take about 5 months to setup
> -- Note: It takes longer because it has to deal with getting packages
> from an internal RHEL repo and all the complications of doing that.
> 
> EPEL Packaging SIG
> - We hope to utilize the EPEL Packaging SIG as much as possible.
> - This might be as simple as having them rebuild a epel9-next package
> on epel9, or possibly maintaining a package when the Fedora packager
> does not want to do EPEL.

I think simple is better here. 

> - More details will be coming, but we hope the SIG will help get alot
> of the most used EPEL packages into EPEL9 as soon as possible.

Thanks for writing all this up!

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