I am looking for building RDO for ppc64le in centos as well. Based on my experience, there are a few source rpm changes needed to make them work with ppc64le. I would assume this will apply to aarch64 as well. One case in example is MongoDB. MongoDB 2.6.x depends on V8, but V8 cannot be built out of box on Power. But MongoDB 3.2.x has a dependency on a higher version of Boost than the CentOS 7.2 default. So shall we work together on a common source repository across multiple architectures or shall we maintain a side repo for aarch64/ppc64le? Regards, Alex Meng <mengxiandong at gmail.com> mengxiandong at gmail.com On Mon, Oct 17, 2016 at 10:45 PM, Thomas Oulevey <thomas.oulevey at cern.ch> wrote: > On 10/17/2016 04:21 PM, Brian Stinson wrote: > >> On Oct 13 17:52, Haïkel wrote: >> >>> Hi, >>> >>> There was various discussions about enabling aarch64 architecture for >>> Cloud SIG OpenStack repositories. >>> And likely others are coming, so I'd like to confirm with a wider >>> audience about the proper course of action. >>> So we can document it and share that experience with other SIGs. >>> >>> Arrfab suggested the following: >>> * scratch builds with archoverride of existing arch-dependent builds >>> * ask CBS admin to merge the task with existing builds using >>> mergeScratch. >>> >>> I find this process simple and efficient, but I'm worried about how it >>> scales. >>> In my case, I have about 250 binary packages (including the Erlang >>> stack etc.) with many interdependencies, so >>> it can rapidly get bothersome for CBS admins. >>> >>> If we can find a way to automate the mergeScratch operations or >>> temporarily grant that permission to >>> SIGs during bootstrapping phase, I have pretty much no objections for >>> that course. >>> >> >> I think if you let us know your schedule, one of us can be around to >> help with the bootstrap. The mergeScratch operation requires permissions >> that we can't give out to non-admins. >> >> > +1 > > I am available to help this week and the following. > > >>> As for daily operations, if you can't block on alternate arch build >>> failures, I was recommended to just use %excludearch >>> and move forward. Which gives us the flexibility to move forward and >>> give more time to fix things at our pace. >>> >> >> +1 here, there might be a little NVR churn with this but I think that's >> the best way to handle this. >> >> > koji build --arch-override="" is better as there is no need to modify the > spec. And that could be added to all build in the RDO process if we need to > move forward with x86_64 only. > > > -- > Thomas. > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20161021/ae3a4c6c/attachment-0008.html>