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.
---
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.
So what do you think? Any other suggestions?
Regards, H.
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.
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.
So what do you think? Any other suggestions?
Regards, H. _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Cheers! -- Brian
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.
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@gmail.com mengxiandong@gmail.com
On Mon, Oct 17, 2016 at 10:45 PM, Thomas Oulevey thomas.oulevey@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@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 21/10/16 13:41, Xiandong Meng wrote:
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?
if we can consolidate the altarch cloud sig content, that would be quite good!
would you also be able to use the same tag's for ppc8le as aarch64 ? or would this involve a complete new set of tags, and therefore a completely new way to run the merge ?
I guess a question for Thomas - how would a 3 way merge like this work anyway ? how would we track the srpms for content that changes per arch, unless we force all altarch to consume the same content, and ifarch the arch specific changes ?
regards
On Oct 21, 2016, at 8:17 AM, Karanbir Singh mail-lists@karan.org wrote:
On 21/10/16 13:41, Xiandong Meng wrote:
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?
if we can consolidate the altarch cloud sig content, that would be quite good!
would you also be able to use the same tag's for ppc8le as aarch64 ? or would this involve a complete new set of tags, and therefore a completely new way to run the merge ?
I guess a question for Thomas - how would a 3 way merge like this work anyway ? how would we track the srpms for content that changes per arch, unless we force all altarch to consume the same content, and ifarch the arch specific changes ?
regards
I would be happy to step in and help with ppc64le RDO bootstrap too. I would hope the same altarch tags and targets would work for aarch64, ppc64le like qemu-kvm-ev in virt7-kvm-common-el7-build http://cbs.centos.org/koji/buildinfo?buildID=12087
-
Brian Stinson -
Haïkel -
James O'Connor -
Karanbir Singh -
Thomas Oulevey -
Xiandong Meng