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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20160728/5ad87e19/attachment-0006.sig>