IMO what is needed is the definitive decision from the project maintainers on what the "correct" way of producing the EPEL package builds is. Putting all the EPEL7 packages through mock is fairly trivial and wouldn't take more than a matter of days to churn through on an 8-core ARMv8 with tons of RAM. The part that would be human-intensive is resolving the FTBFS issues for the (relatively small) number of packages that hit those. On 2016-07-28 13:31, Ed Brand wrote: > There are willing users on this thread. Just need access to the build > systems. Is there a fedora group/SIG/sponsorship needed? > > On 07/28/2016 08:23 AM, Karanbir Singh wrote: >> On 28/07/16 13:18, Johnny Hughes wrote: >>> On 07/28/2016 07:09 AM, Johnny Hughes wrote: >>>> On 07/28/2016 06:57 AM, Karanbir Singh wrote: >>>>> On 28/07/16 01:26, Stephen John Smoogen wrote: >>>>>> I believe it is still going through pass-2 or so. There are a >>>>>> couple >>>>>> of problems in that a couple of things which could be >>>>>> 'jump-started' >>>>>> from x86_64 fedora 18 -> epel x86_64 do not exist because Fedora >>>>>> arm32 >>>>>> was not as available then. This means having to go to newer >>>>>> versions >>>>>> than what is in EPEL so the two chains do not meet. I have finally >>>>>> finished my move across the country and am able to start trying to >>>>>> get >>>>>> these together for a build tree. I will be happy to help people in >>>>>> the >>>>>> community if they step up. >>>>>> >>>>> thanks Stephen, >>>>> >>>>> Would it help if we were to get some arm32 builders online behind >>>>> cbs.centos.org / koji ? >>>>> >>>> IMHO, we need to decide one way to try to build EPEL for alternative >>>> arches. If we want to use CBS, then we can do that. >>>> >>>> Currently for both arm32 and aarch64 we are using the distro build >>>> and >>>> not koji for EPEL build. >>>> >>>> I don't really have a preference but we need to define the process >>>> and >>>> stick to it and not keep hopping around. >>>> >>>> We do need koji arm32 builders for SIG content regardless of how we >>>> do EPEL. >>>> >>>> But shifting systems mid stream (ie, we are building EPEL now) is >>>> not >>>> the best idea. >>> To discuss this in a bit more detail: >>> >>> 1. If we are going to actually try to do what EPEL does on alt >>> arches >>> (That is, recruit individual maintainers for individual packages for >>> different arches) .. then we need to do this on CBS >>> >>> (hopefully that will not be necessary, hopefully EPEL will do this so >>> that CentOS does not have to do a completely different program that >>> is >>> the same thing as EPEL). >>> >>> 2. If, in the interim (before EPEL does build these arches), we want >>> to >>> try to produce the things that build with little or no modification >>> on a >>> best effort type build .. well then, we would want to use the distro >>> build system for the flexibility it gives. (You can build each arch >>> independently, one arch does not impact the others, you can have >>> modified packages between arches, etc. much more easily not using >>> koji). >>> >>> So, it really depends on what we are trying to accomplish. >> the key here is to build the user story. at the moment there is none, >> all the above is the provider side which is easily replaced / >> discarded >> / rehashed as needed. >> >> > > _______________________________________________ > Arm-dev mailing list > Arm-dev at centos.org > https://lists.centos.org/mailman/listinfo/arm-dev