hi guys,
We have a few nodes that can be used, public facing, for builds - and we have Howards's bootstrap image in place. With that in mind, can we as a group help with the wider armv7 effort at this point ?
One option might be to see if we can get this image loaded onto the nodes we have from online.net ? and then get a plague builder thread on each node. We can host the plague server on a different machine, as long as network latency isnt too high we should be fine.
This would then allow people to setup and submit jobs without needing the entire setup at their own place.
Plague, since koji isnt suiteable here, yet. Plus we have some plague expertise already ( we still use it for CentOS-5 builds ).
Regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 14/04/15 18:23, Karanbir Singh wrote:
hi guys,
We have a few nodes that can be used, public facing, for builds - and we have Howards's bootstrap image in place. With that in mind, can we as a group help with the wider armv7 effort at this point ?
One option might be to see if we can get this image loaded onto the nodes we have from online.net ? and then get a plague builder thread on each node. We can host the plague server on a different machine, as long as network latency isnt too high we should be fine.
Hmm, online.net images aren't standard ones, so not sure if we can upload ours and get those running there. At the moment, those nodes have fedora-21-based images, but modified to suit the architecture : different kernel, also using nbd devices accross the network (nothing "local") OTOH, I guess we can just use those ones, as plague-{server,client} nodes there. (keep in mind that only one node has a public IP, while the remaining ones have 10.x.x.x, but reachable from node1)
This would then allow people to setup and submit jobs without needing the entire setup at their own place.
Plague, since koji isnt suiteable here, yet. Plus we have some plague expertise already ( we still use it for CentOS-5 builds ).
Sound like a plan
Regards,
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On 04/15/2015 09:28 AM, Fabian Arrotin wrote:
Hmm, online.net images aren't standard ones, so not sure if we can upload ours and get those running there. At the moment, those nodes have fedora-21-based images, but modified to suit the architecture : different kernel, also using nbd devices accross the network (nothing "local") OTOH, I guess we can just use those ones, as plague-{server,client} nodes there. (keep in mind that only one node has a public IP, while the remaining ones have 10.x.x.x, but reachable from node1)
I tried to email the online.net guys to see if they can come join this list, but havent had a response - do you want to try and reach out see if they might consider using the image we have here from Howard ? if not, do we want to try and just hammer on with the f21 image in place there now?
On 2015-04-17 10:35, Karanbir Singh wrote:
On 04/15/2015 09:28 AM, Fabian Arrotin wrote:
Hmm, online.net images aren't standard ones, so not sure if we can upload ours and get those running there. At the moment, those nodes have fedora-21-based images, but modified to suit the architecture : different kernel, also using nbd devices accross the network (nothing "local") OTOH, I guess we can just use those ones, as plague-{server,client} nodes there. (keep in mind that only one node has a public IP, while the remaining ones have 10.x.x.x, but reachable from node1)
I tried to email the online.net guys to see if they can come join this list, but havent had a response - do you want to try and reach out see if they might consider using the image we have here from Howard ? if not, do we want to try and just hammer on with the f21 image in place there now?
Does it really matter what the host OS is if all the building is done in mock?
On Apr 17, 2015, at 11:35 AM, Karanbir Singh mail-lists@karan.org wrote:
On 04/15/2015 09:28 AM, Fabian Arrotin wrote:
Hmm, online.net images aren't standard ones, so not sure if we can upload ours and get those running there. At the moment, those nodes have fedora-21-based images, but modified to suit the architecture : different kernel, also using nbd devices accross the network (nothing "local") OTOH, I guess we can just use those ones, as plague-{server,client} nodes there. (keep in mind that only one node has a public IP, while the remaining ones have 10.x.x.x, but reachable from node1)
I tried to email the online.net guys to see if they can come join this list, but havent had a response - do you want to try and reach out see if they might consider using the image we have here from Howard ? if not, do we want to try and just hammer on with the f21 image in place there now?
Hi there,
I’m from Online/Scaleway. It's possible to use your image on our platform. You can build an image from scratch by bootstrapping a secondary volume on a running server. Once the secondary volume is bootstrapped, just snapshot the volume and create an image from it. We have a documentation explaining how to bootstrap an image from scratch (https://www.scaleway.com/docs/create_an_image_from_scratch) The documentation is for debian system but the same process applies for any distribution.
Fabian is you have not enough nodes or enough Public IP for the first builds, let us know, we will increase your quota.
Please reach out to moul on our IRC #scaleway - irc.online.net if you need help with building the first CentOS image.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 17/04/15 11:35, Karanbir Singh wrote:
On 04/15/2015 09:28 AM, Fabian Arrotin wrote:
Hmm, online.net images aren't standard ones, so not sure if we can upload ours and get those running there. At the moment, those nodes have fedora-21-based images, but modified to suit the architecture : different kernel, also using nbd devices accross the network (nothing "local") OTOH, I guess we can just use those ones, as plague-{server,client} nodes there. (keep in mind that only one node has a public IP, while the remaining ones have 10.x.x.x, but reachable from node1)
I tried to email the online.net guys to see if they can come join this list, but havent had a response - do you want to try and reach out see if they might consider using the image we have here from Howard ? if not, do we want to try and just hammer on with the f21 image in place there now?
I'll try to ping them, but as already said, they have a specific image, and different kernel, that uses nbd devices as root device. So, except if Howard modifies his image for online.net/scaleway, I guess that those will not even boot. Let's try to discuss that with scaleway people.
I also guess that my initial proposal is still something we can do : use those f21 images and just use mock inside (with some plague-clients). Testing the produced rpms/images will have to happen on other physical/traditional nodes. Then, if scaleway people are interested in a centos image, we can work with them too
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On 2015-04-17 11:19, Fabian Arrotin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 17/04/15 11:35, Karanbir Singh wrote:
On 04/15/2015 09:28 AM, Fabian Arrotin wrote:
Hmm, online.net images aren't standard ones, so not sure if we can upload ours and get those running there. At the moment, those nodes have fedora-21-based images, but modified to suit the architecture : different kernel, also using nbd devices accross the network (nothing "local") OTOH, I guess we can just use those ones, as plague-{server,client} nodes there. (keep in mind that only one node has a public IP, while the remaining ones have 10.x.x.x, but reachable from node1)
I tried to email the online.net guys to see if they can come join this list, but havent had a response - do you want to try and reach out see if they might consider using the image we have here from Howard ? if not, do we want to try and just hammer on with the f21 image in place there now?
I'll try to ping them, but as already said, they have a specific image, and different kernel, that uses nbd devices as root device.
I have to say using NDB seems... unusual. I haven't seen NDB used in a serious setup in quite a while. Are there performance (or any other) benefits from doing so, and are they documented anywhere?
Gordan
On Apr 17, 2015, at 12:22 PM, Gordan Bobic gordan@redsleeve.org wrote:
On 2015-04-17 11:19, Fabian Arrotin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/04/15 11:35, Karanbir Singh wrote:
On 04/15/2015 09:28 AM, Fabian Arrotin wrote:
Hmm, online.net images aren't standard ones, so not sure if we can upload ours and get those running there. At the moment, those nodes have fedora-21-based images, but modified to suit the architecture : different kernel, also using nbd devices accross the network (nothing "local") OTOH, I guess we can just use those ones, as plague-{server,client} nodes there. (keep in mind that only one node has a public IP, while the remaining ones have 10.x.x.x, but reachable from node1)
I tried to email the online.net guys to see if they can come join this list, but havent had a response - do you want to try and reach out see if they might consider using the image we have here from Howard ? if not, do we want to try and just hammer on with the f21 image in place there now?
I'll try to ping them, but as already said, they have a specific image, and different kernel, that uses nbd devices as root device.
I have to say using NDB seems... unusual. I haven't seen NDB used in a serious setup in quite a while. Are there performance (or any other) benefits from doing so, and are they documented anywhere?
Gordan
Hi there,
I’m from Online/Scaleway. It's possible to use your image on our platform. You can build an image from scratch by bootstrapping a secondary volume on a running server. Once the secondary volume is bootstrapped, just snapshot the volume and create an image from it. We have a documentation explaining how to bootstrap an image from scratch (https://www.scaleway.com/docs/create_an_image_from_scratch) The documentation is for debian system but the same process applies for any distribution.
If you have not enough nodes or enough Public IP for the first builds, let us know, we will increase your quota.
Please reach out to moul on our IRC #scaleway - irc.online.net if you need help with building the first CentOS image.
Please reach out to moul on our IRC #scaleway - irc.online.net if you need help with building the first CentOS image.
I can work with Online/Scaleway to build the first CentOS image for their systems.
Slightly off topic but just before reading these emails, I had already posted a comment on my GSoC proposal about the same thing.
I can work with Online/Scaleway to build the first CentOS image for their systems.
I would like to join the CentOS ARM effort officially.
I have tested MerlinTHP's CentOS-7-armv7hl-sda-03.raw image in QEMU. It works fine. It needs development tools like rpmbuild, mock etc. which MerlinTHP has already built. We can use those.
As suggested by kbsingh, we use this image to bootstrap CentOS for ARMv7.
Can I get acccess to the Online/Scaleway nodes once they are up and running? If they need any help with setting up the image I would be glad to be involved.
On 17/04/15 14:38, Mandar Joshi wrote:
I can work with Online/Scaleway to build the first CentOS image for their systems.
I would like to join the CentOS ARM effort officially.
nothing official here :) people doing the work are in, people hanging around talking and hand waving are not.
I have tested MerlinTHP's CentOS-7-armv7hl-sda-03.raw image in QEMU. It works fine. It needs development tools like rpmbuild, mock etc. which MerlinTHP has already built. We can use those.
As suggested by kbsingh, we use this image to bootstrap CentOS for ARMv7.
Can I get acccess to the Online/Scaleway nodes once they are up and running? If they need any help with setting up the image I would be glad to be involved.
the way this is likely going to work is that noone will get direct access to those machines, we will use them to run a build service that people can get access to in order to send requests and effect builds etc.
On Fri, Apr 17, 2015 at 11:07 AM, Karanbir Singh mail-lists@karan.org wrote:
On 17/04/15 14:38, Mandar Joshi wrote:
I can work with Online/Scaleway to build the first CentOS image for their systems.
I would like to join the CentOS ARM effort officially.
nothing official here :) people doing the work are in, people hanging around talking and hand waving are not.
This doesn't make any sense. So, if people want to join the CentOS arm effort, they cannot, unless they are already part of the CentOS arm effort? How can people change from "hand waving" to actually doing work?
On 04/23/2015 02:38 PM, Troy Dawson wrote:
On Fri, Apr 17, 2015 at 11:07 AM, Karanbir Singh <mail-lists@karan.org mailto:mail-lists@karan.org> wrote:
On 17/04/15 14:38, Mandar Joshi wrote: >> I can work with Online/Scaleway to build the first CentOS image for >> their systems. > I would like to join the CentOS ARM effort officially. nothing official here :) people doing the work are in, people hanging around talking and hand waving are not.This doesn't make any sense. So, if people want to join the CentOS arm effort, they cannot, unless they are already part of the CentOS arm effort? How can people change from "hand waving" to actually doing work?
as you can see, there is no real 'CentOS Arm Effort' - whatever is happening is being done by people on their own, on their own hardware using the centos sources from git.centos.org or srpms.
hoping to fix that with a plague setup, across some nodes, that people can ask for access to and then pool in the work being done.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 23/04/15 17:08, Karanbir Singh wrote:
On 04/23/2015 02:38 PM, Troy Dawson wrote:
On Fri, Apr 17, 2015 at 11:07 AM, Karanbir Singh <mail-lists@karan.org mailto:mail-lists@karan.org> wrote:
On 17/04/15 14:38, Mandar Joshi wrote:
I can work with Online/Scaleway to build the first CentOS image for their systems.
I would like to join the CentOS ARM effort officially.
nothing official here :) people doing the work are in, people hanging around talking and hand waving are not.
This doesn't make any sense. So, if people want to join the CentOS arm effort, they cannot, unless they are already part of the CentOS arm effort? How can people change from "hand waving" to actually doing work?
as you can see, there is no real 'CentOS Arm Effort' - whatever is happening is being done by people on their own, on their own hardware using the centos sources from git.centos.org or srpms.
hoping to fix that with a plague setup, across some nodes, that people can ask for access to and then pool in the work being done.
The plague farm is exactly what I'm now working on. Once that will be in place (plague and plague-builders), we'll announce here how one can (ab)use those nodes to try a arm port of CentOS
Cheers, - --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 23/04/15 17:22, Fabian Arrotin wrote:
On 23/04/15 17:08, Karanbir Singh wrote:
On 04/23/2015 02:38 PM, Troy Dawson wrote:
On Fri, Apr 17, 2015 at 11:07 AM, Karanbir Singh <mail-lists@karan.org mailto:mail-lists@karan.org> wrote:
On 17/04/15 14:38, Mandar Joshi wrote:
I can work with Online/Scaleway to build the first CentOS image for their systems.
I would like to join the CentOS ARM effort officially.
nothing official here :) people doing the work are in, people hanging around talking and hand waving are not.
This doesn't make any sense. So, if people want to join the CentOS arm effort, they cannot, unless they are already part of the CentOS arm effort? How can people change from "hand waving" to actually doing work?
as you can see, there is no real 'CentOS Arm Effort' - whatever is happening is being done by people on their own, on their own hardware using the centos sources from git.centos.org or srpms.
hoping to fix that with a plague setup, across some nodes, that people can ask for access to and then pool in the work being done.
The plague farm is exactly what I'm now working on. Once that will be in place (plague and plague-builders), we'll announce here how one can (ab)use those nodes to try a arm port of CentOS
Cheers,
Just a quick status update for that plague farm :
* The five armv7 nodes are running F21 * fist one is actually plague-server * the 4 remaining ones are plague-builder nodes (connected now to plague-server)
The reason why it takes more time than expected is that I had multiple issues within centos infra, so not only focusing on that build farm. It's cfgmgmt driven, so everything is done through something that can be reproduced easily (if we need to extend/move)
Howard had to patch the plague packages to support armv7hl as supported arches I had to inspect and patch the plague-certhelper tool generating the initial keys/certs, as it was defaulting to md5 as signature algorithm, which doesn't verify on newer platform. We'll send our patches "upstream" (if there is still an "upstream" for plague :-p )
As Howard has more or less an initial armv7 tree for centos 7, we decided it would be good to wait some extra days , and use his initial tree/repo to build against, and not bootstrapping (again from scratch) from f19/f20.
Once that is done, and that builders can build rpms, we'll open up to people with instructions on how to use it (but basically that will mean using the plague-client tool)
We also have to see how to import custom mock config files (and so also targets, from a plague builder/server PoV) if those are needed for specific packages
Cheers,
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On 04/29/2015 11:14 AM, Fabian Arrotin wrote:
Just a quick status update for that plague farm :
- The five armv7 nodes are running F21
- fist one is actually plague-server
- the 4 remaining ones are plague-builder nodes (connected now to
plague-server)
The reason why it takes more time than expected is that I had multiple issues within centos infra, so not only focusing on that build farm. It's cfgmgmt driven, so everything is done through something that can be reproduced easily (if we need to extend/move)
Howard had to patch the plague packages to support armv7hl as supported arches I had to inspect and patch the plague-certhelper tool generating the initial keys/certs, as it was defaulting to md5 as signature algorithm, which doesn't verify on newer platform. We'll send our patches "upstream" (if there is still an "upstream" for plague :-p )
As Howard has more or less an initial armv7 tree for centos 7, we decided it would be good to wait some extra days , and use his initial tree/repo to build against, and not bootstrapping (again from scratch) from f19/f20.
Once that is done, and that builders can build rpms, we'll open up to people with instructions on how to use it (but basically that will mean using the plague-client tool)
We also have to see how to import custom mock config files (and so also targets, from a plague builder/server PoV) if those are needed for specific packages
Please clear up one thing for me...
What uboot and kernel will be used for this? One message seemed to imply that the building would be F19 based.
From my work with F19 on my cubies and f21 and F22, I really want the current uboot and kernel, as multiple board support really works now, compared to how it was with F19.
On 04/29/2015 10:29 AM, Robert Moskowitz wrote:
Please clear up one thing for me...
What uboot and kernel will be used for this? One message seemed to imply that the building would be F19 based.
From my work with F19 on my cubies and f21 and F22, I really want the current uboot and kernel, as multiple board support really works now, compared to how it was with F19.
I'm fine with moving forward. Initially Howard and I had talked about using a 3.18 or 3.19 base for long term support, but as ARMv8 matures it might be better to use a newer kernel. Currently I'm building against kernel-4.0.0-1.fc23.src.rpm as a base.
Would that be acceptable for everyone?
On 04/29/15 19:06, Jim Perrin wrote:
On 04/29/2015 10:29 AM, Robert Moskowitz wrote:
Please clear up one thing for me...
What uboot and kernel will be used for this? One message seemed to imply that the building would be F19 based.
From my work with F19 on my cubies and f21 and F22, I really want the current uboot and kernel, as multiple board support really works now, compared to how it was with F19.
I'm fine with moving forward. Initially Howard and I had talked about using a 3.18 or 3.19 base for long term support, but as ARMv8 matures it might be better to use a newer kernel. Currently I'm building against kernel-4.0.0-1.fc23.src.rpm as a base.
Would that be acceptable for everyone?
just my 2ct: For RedSleeve7 I patched the stock CentOS/RH kernel until it builded. All packages have been build against this kernel-headers. For running the system I use the stock kernels delivered by the various HW vendors.
Jacco
On 04/29/2015 12:46 PM, Jacco Ligthart wrote:
just my 2ct: For RedSleeve7 I patched the stock CentOS/RH kernel until it builded. All packages have been build against this kernel-headers. For running the system I use the stock kernels delivered by the various HW vendors.
For everything except ARMv8 that's fine. ARMv8 needs a newer kernel to function properly. Mostly, I have to have a newer kernel, and if the other arm effort can benefit from a common version, why not share for consistency.
On 04/29/2015 06:46 PM, Jacco Ligthart wrote:
For RedSleeve7 I patched the stock CentOS/RH kernel until it builded. All packages have been build against this kernel-headers.
but if you have patched it out - and assume that the kernel only gets management / support / maintainence, is there any use in doing that ? isnt it safer overall to communicate clearly that a newer, self managed kernel was used ? What you have there certainly does not seem in a state where you could asset its the distro kernel. Or is it ?
On 2015-05-01 09:42, Karanbir Singh wrote:
On 04/29/2015 06:46 PM, Jacco Ligthart wrote:
For RedSleeve7 I patched the stock CentOS/RH kernel until it builded. All packages have been build against this kernel-headers.
but if you have patched it out - and assume that the kernel only gets management / support / maintainence, is there any use in doing that ? isnt it safer overall to communicate clearly that a newer, self managed kernel was used ? What you have there certainly does not seem in a state where you could asset its the distro kernel. Or is it ?
I think we need to make a clear separation here between the kernel and userspace, because Linus' policy is to never break userspace with kernel ABI changes.
This is purely to give userspace programs the kernel headers they expect to build against, and more importantly, to give mock a usable binary rpm to install to satisfy the dependencies the userspace package source rpm requires.
What kernel you end up using to run the system is irrelevant. Unfortunately, in the ARM world you often have to use whatever kernel has patches, or even just binaries available that work on the machine. If you can stick with SoC/board combinations that have upstream mainline support, that's awesome, but that is still very much not always the case. But that doesn't really make any difference to the userspace (e.g. in RS6 the recommendation is to use whatever kernel your device ships with and use that with the EL6 userspace, for purely pragmatic reasons.
Gordan
On 05/01/2015 01:25 PM, Gordan Bobic wrote:
On 2015-05-01 09:42, Karanbir Singh wrote:
On 04/29/2015 06:46 PM, Jacco Ligthart wrote:
For RedSleeve7 I patched the stock CentOS/RH kernel until it builded. All packages have been build against this kernel-headers.
but if you have patched it out - and assume that the kernel only gets management / support / maintainence, is there any use in doing that ? isnt it safer overall to communicate clearly that a newer, self managed kernel was used ? What you have there certainly does not seem in a state where you could asset its the distro kernel. Or is it ?
I think we need to make a clear separation here between the kernel and userspace, because Linus' policy is to never break userspace with kernel ABI changes.
This is purely to give userspace programs the kernel headers they expect to build against, and more importantly, to give mock a usable binary rpm to install to satisfy the dependencies the userspace package source rpm requires.
What kernel you end up using to run the system is irrelevant. Unfortunately, in the ARM world you often have to use whatever kernel has patches, or even just binaries available that work on the machine. If you can stick with SoC/board combinations that have upstream mainline support, that's awesome, but that is still very much not always the case. But that doesn't really make any difference to the userspace (e.g. in RS6 the recommendation is to use whatever kernel your device ships with and use that with the EL6 userspace, for purely pragmatic reasons.
Like Gordan says, it's mostly for pragmatic reasons. One of the issues I found was that I was not able to build the raspberry pi kernel (3.18.something) with the CentOS 7.0 gcc. The kernel complained that that gcc version was known to break kernel builds. (the 7.1 gcc version is just that much newer that it now works)
Similarly, I expect some other packages to FTBFS if presented with newer kernel-headers.
Anyhow, I was not trying to convince you that this is the way you should do it. It's just what I've done. And, at the same time, if you also want to go down this route, that I have patches available, to kick-start such an endeavor.
Jacco
On 04/29/2015 01:06 PM, Jim Perrin wrote:
On 04/29/2015 10:29 AM, Robert Moskowitz wrote:
Please clear up one thing for me...
What uboot and kernel will be used for this? One message seemed to imply that the building would be F19 based.
From my work with F19 on my cubies and f21 and F22, I really want the current uboot and kernel, as multiple board support really works now, compared to how it was with F19.
I'm fine with moving forward. Initially Howard and I had talked about using a 3.18 or 3.19 base for long term support, but as ARMv8 matures it might be better to use a newer kernel. Currently I'm building against kernel-4.0.0-1.fc23.src.rpm as a base.
Would that be acceptable for everyone?
I am assuming that is close enough to 4.0.0-1.f22 for me to say yes.
But what uboot? 2015.02 is the current in f22, with looking like 2015.04 will be what ships.
My votes kernel: 4.0.0.-*.f22 (The current fedora f22 4.0.0 kernel) uboot: 2015.04
Why? uboot 2015.4 had some major improvements over 2015.02 (I'm really hoping it makes it into f22 final) kernel - well, I actually want 4.1.0 because it will have support for my pcDuino3 Nano ... but 4.0.0 is currently close enough.
I feel more strongly about uboot 2015.04 than I do about the kernel.
Troy
On Wed, Apr 29, 2015 at 3:17 PM, Robert Moskowitz rgm@htt-consult.com wrote:
On 04/29/2015 01:06 PM, Jim Perrin wrote:
On 04/29/2015 10:29 AM, Robert Moskowitz wrote:
Please clear up one thing for me...
What uboot and kernel will be used for this? One message seemed to imply that the building would be F19 based.
From my work with F19 on my cubies and f21 and F22, I really want the current uboot and kernel, as multiple board support really works now, compared to how it was with F19.
I'm fine with moving forward. Initially Howard and I had talked about using a 3.18 or 3.19 base for long term support, but as ARMv8 matures it might be better to use a newer kernel. Currently I'm building against kernel-4.0.0-1.fc23.src.rpm as a base.
Would that be acceptable for everyone?
I am assuming that is close enough to 4.0.0-1.f22 for me to say yes.
But what uboot? 2015.02 is the current in f22, with looking like 2015.04 will be what ships.
Arm-dev mailing list Arm-dev@centos.org http://lists.centos.org/mailman/listinfo/arm-dev
On 04/30/2015 09:59 AM, Troy Dawson wrote:
My votes kernel: 4.0.0.-*.f22 (The current fedora f22 4.0.0 kernel) uboot: 2015.04
Why? uboot 2015.4 had some major improvements over 2015.02 (I'm really hoping it makes it into f22 final) kernel - well, I actually want 4.1.0 because it will have support for my pcDuino3 Nano ... but 4.0.0 is currently close enough.
There are some patches in 4.1.0 rc that I'd like, but I don't think we want to live *quite* on that bleeding edge. I could be convinced either way.
I feel more strongly about uboot 2015.04 than I do about the kernel.
uboot I hadn't worried about and have no strong feelings for as it's not needed on the armv8 gear I have. I'm fine with whatever works for you guys so long as someone maintains it.
On 04/30/2015 11:28 AM, Jim Perrin wrote:
On 04/30/2015 09:59 AM, Troy Dawson wrote:
My votes kernel: 4.0.0.-*.f22 (The current fedora f22 4.0.0 kernel) uboot: 2015.04
Why? uboot 2015.4 had some major improvements over 2015.02 (I'm really hoping it makes it into f22 final) kernel - well, I actually want 4.1.0 because it will have support for my pcDuino3 Nano ... but 4.0.0 is currently close enough.
There are some patches in 4.1.0 rc that I'd like, but I don't think we want to live *quite* on that bleeding edge. I could be convinced either way.
I don't know enough, could ask Hans, where the patches for some of the board items he has been working on.
I feel more strongly about uboot 2015.04 than I do about the kernel.
uboot I hadn't worried about and have no strong feelings for as it's not needed on the armv8 gear I have. I'm fine with whatever works for you guys so long as someone maintains it.
I MIGHT think that once 2015.04 comes out in Fedora, you just lift it and live with it? I am just going by what I see on the Fedora list. Yes there are patches all the time on the uboot list, but that is for the active tree.
On 04/30/2015 04:46 PM, Robert Moskowitz wrote:
On 04/30/2015 11:28 AM, Jim Perrin wrote:
On 04/30/2015 09:59 AM, Troy Dawson wrote:
My votes kernel: 4.0.0.-*.f22 (The current fedora f22 4.0.0 kernel) uboot: 2015.04
Why? uboot 2015.4 had some major improvements over 2015.02 (I'm really hoping it makes it into f22 final) kernel - well, I actually want 4.1.0 because it will have support for my pcDuino3 Nano ... but 4.0.0 is currently close enough.
There are some patches in 4.1.0 rc that I'd like, but I don't think we want to live *quite* on that bleeding edge. I could be convinced either way.
I don't know enough, could ask Hans, where the patches for some of the board items he has been working on..
keep in mind that Jim is bootstrapping Aarch64, and not ARMv7 content.
On 04/30/2015 03:59 PM, Troy Dawson wrote:
My votes kernel: 4.0.0.-*.f22 (The current fedora f22 4.0.0 kernel) uboot: 2015.04
Why? uboot 2015.4 had some major improvements over 2015.02 (I'm really hoping it makes it into f22 final) kernel - well, I actually want 4.1.0 because it will have support for my pcDuino3 Nano ... but 4.0.0 is currently close enough.
I feel more strongly about uboot 2015.04 than I do about the kernel.
+1 on this from my side, if we can unify around a single kernel and not need to worry about the vendor supplied ( therefore unmaintained and in many cases, will never be maintained ) kernels. We might not be able to do this for all boards, but even if the number > 1 we are winning.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/04/15 17:14, Fabian Arrotin wrote: <big snip>
Just a status update on that plague farm. I identified today some glitches in the setup we had on those nodes and reflected those changes in the cfgmgmt.
I then found that mock 1.2.7 has a strange build issue when used with plague-builder, but working fine directly on the f21 node. I had no time to investigate why, but tested a "yum downgrade mock" and plague-builder is now happy with mock-1.1.41-3.fc21.noarch
So, while waiting for Howard's initial tree, I decided to test if the plague setup is now robust, and I just put the 2400+ CentOS 7.0.1406 SRPMS in the build queue (through plague-client). Let's see what can come out of it :-)
If everything works fine, we'll have to discuss about multiple things, like :
* who would like to get build access (through plague-client) * what to do with modified SRPM (like a specific patch, as plague doesn't support building from git) * what to do with custom mock config files for specific packages (and how to distribute that )
PS : we have actually some "issue" regarding public reporting : Scaleway blocks by default outgoing tcp/25, so all plague attempts to send mail reports are failing. The plague webui (who does remember that ?) was written for mod_python, which is now deprecated and unavailable. And it seems that those .psp files can't work through mod_wsgi
Cheers, - --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On 30 aprilie 2015 23:58:37 EEST, Fabian Arrotin arrfab@centos.org wrote:
PS : we have actually some "issue" regarding public reporting : Scaleway blocks by default outgoing tcp/25, so all plague attempts to send mail reports are failing.
Maybe you can use port 587 or a reverse SSH runnel on port 25 ?
Manuel
On 04/30/2015 07:07 PM, Manuel Wolfshant wrote:
On 30 aprilie 2015 23:58:37 EEST, Fabian Arrotin arrfab@centos.org wrote:
PS : we have actually some "issue" regarding public reporting : Scaleway blocks by default outgoing tcp/25, so all plague attempts to send mail reports are failing.
Maybe you can use port 587 or a reverse SSH runnel on port 25 ?
587 is the 'standard' for this. Or do it over the TLS port.
On 04/30/2015 09:58 PM, Fabian Arrotin wrote:
So, while waiting for Howard's initial tree, I decided to test if the plague setup is now robust, and I just put the 2400+ CentOS 7.0.1406 SRPMS in the build queue (through plague-client). Let's see what can come out of it :-)
what are you building these against ? ( ie. whats in the build roots ) F19 ?
Also, can you export the /repodir and /rpmbuild from the plague-server and put that behind a http server ?
regards and thanks for your help on this so far,
- KB
On Apr 30, 2015, at 10:58 PM, Fabian Arrotin arrfab@centos.org wrote:
Signed PGP part On 29/04/15 17:14, Fabian Arrotin wrote:
<big snip>
PS : we have actually some "issue" regarding public reporting : Scaleway blocks by default outgoing tcp/25, so all plague attempts to send mail reports are failing. The plague webui (who does remember that ?) was written for mod_python, which is now deprecated and unavailable. And it seems that those .psp files can't work through mod_wsgi
Cheers,
Hi Fabian,
By default the mail ports are closed, but you can open the mail ports in the “Security” section of the console. If you have an issue with this, please contact the support team. ;)
— Yann
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/05/15 12:17, Yann Leger wrote:
On Apr 30, 2015, at 10:58 PM, Fabian Arrotin arrfab@centos.org wrote:
Signed PGP part On 29/04/15 17:14, Fabian Arrotin wrote: <big snip>
PS : we have actually some "issue" regarding public reporting : Scaleway blocks by default outgoing tcp/25, so all plague attempts to send mail reports are failing. The plague webui (who does remember that ?) was written for mod_python, which is now deprecated and unavailable. And it seems that those .psp files can't work through mod_wsgi
Cheers,
Hi Fabian,
By default the mail ports are closed, but you can open the mail ports in the “Security” section of the console. If you have an issue with this, please contact the support team. ;)
— Yann
Hi Yann,
Yeah, been there, done that .. but it's not immediate so I have to restart all those nodes (what I've been said), and they are busy with the 7.0.1406 SRPMS rebuild (job id is now 2299, out of 2635 in that initial queue for plague builders)
I'll restart the nodes after that, to be able to send the plague reports by mail.
Cheers,
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On 05/04/2015 06:44 AM, Fabian Arrotin wrote:
On 04/05/15 12:17, Yann Leger wrote:
On Apr 30, 2015, at 10:58 PM, Fabian Arrotin arrfab@centos.org wrote:
Signed PGP part On 29/04/15 17:14, Fabian Arrotin wrote: <big snip>
PS : we have actually some "issue" regarding public reporting : Scaleway blocks by default outgoing tcp/25, so all plague attempts to send mail reports are failing. The plague webui (who does remember that ?) was written for mod_python, which is now deprecated and unavailable. And it seems that those .psp files can't work through mod_wsgi
Cheers,
Hi Fabian,
By default the mail ports are closed, but you can open the mail ports in the “Security” section of the console. If you have an issue with this, please contact the support team. ;)
— Yann
Hi Yann,
Yeah, been there, done that .. but it's not immediate so I have to restart all those nodes (what I've been said), and they are busy with the 7.0.1406 SRPMS rebuild (job id is now 2299, out of 2635 in that initial queue for plague builders)
I'll restart the nodes after that, to be able to send the plague reports by mail.
Fabian,
Have these initial SRPM rebuilds managed to complete? Are we in a position to start looking at expanded access to the farm?
We have a GSoC project spinning up around C7 32 bit ARM and I'm keen to get our student access to this, if it's likely to happen soon.
-Ian
Cheers,
Arm-dev mailing list Arm-dev@centos.org http://lists.centos.org/mailman/listinfo/arm-dev
On 2015-04-23 16:08, Karanbir Singh wrote:
On 04/23/2015 02:38 PM, Troy Dawson wrote:
On Fri, Apr 17, 2015 at 11:07 AM, Karanbir Singh <mail-lists@karan.org mailto:mail-lists@karan.org> wrote:
On 17/04/15 14:38, Mandar Joshi wrote: >> I can work with Online/Scaleway to build the first CentOS imagefor >> their systems. > I would like to join the CentOS ARM effort officially.
nothing official here :) people doing the work are in, peoplehanging around talking and hand waving are not.
This doesn't make any sense. So, if people want to join the CentOS arm effort, they cannot, unless they are already part of the CentOS arm effort? How can people change from "hand waving" to actually doing work?
as you can see, there is no real 'CentOS Arm Effort' - whatever is happening is being done by people on their own, on their own hardware using the centos sources from git.centos.org or srpms.
hoping to fix that with a plague setup, across some nodes, that people can ask for access to and then pool in the work being done.
Having been doing exactly this kind of thing for the past 3-4 years with the RedSleeve project, IMO the most important part of this kind of an effort, if it is to be a community effort that scales, is coordination.
Ultimately, anyone can take a F19 image and packages and write a 20 line bash script to rebuild the EL7 src.rpms using mock, then do it again based on the packages that fell out of the first stage, and then doing it again based on the package that fall out of the second stage just to make sure. That just takes CPU time, and situation today is massively less bad than it was about 4 years ago when I first started working on it. For example, back the RedSleeve builders were all Sheeva/Guru/Dream Plus, with 512MB of RAM and running on an NFS rootfs.
Today you can get a single 8-core ARM board with 4GB of RAM, which will outright outperform my entire old build farm on it's own, and avoid the complications of running on NFS by having a SATA port (running NFS root on the build directory caused some package self tests to fail, at least back on EL6).
The part that is human time consuming is fixing all the packages that refuse/fail to build. On EL6 there was over a hundred. On EL7, I'm told it's less bad, but I'm not so sure - having tried to build an i686 EL7 build, there seems to be a lot of spurious build breakages so it isn't a plain, simple, out of the box "just works" process. Having some way to distribute that effort is the difficult part to coordinate. Raising tickets is cumbersome, and some issues often disappear on a subsequent rebuild (and some things fail in stage 2 even though they build in stage 1 based off Fedora packages).
If anyone has a sensible method to automate such a process, I would love to hear about it. Otherwise it takes somebody to take charge and effectively perform such coordination as almost a full time job until the initial complete release build is rolled out (after that the effort reduces dramatically).
Gordan
On Thu, Apr 23, 2015 at 10:26 AM, Gordan Bobic gordan@redsleeve.org wrote:
On 2015-04-23 16:08, Karanbir Singh wrote:
On 04/23/2015 02:38 PM, Troy Dawson wrote:
On Fri, Apr 17, 2015 at 11:07 AM, Karanbir Singh <mail-lists@karan.org mailto:mail-lists@karan.org> wrote:
On 17/04/15 14:38, Mandar Joshi wrote: >> I can work with Online/Scaleway to build the first CentOS imagefor >> their systems. > I would like to join the CentOS ARM effort officially.
nothing official here :) people doing the work are in, people hanging around talking and hand waving are not.This doesn't make any sense. So, if people want to join the CentOS arm effort, they cannot, unless they are already part of the CentOS arm effort? How can people change from "hand waving" to actually doing work?
as you can see, there is no real 'CentOS Arm Effort' - whatever is happening is being done by people on their own, on their own hardware using the centos sources from git.centos.org or srpms.
hoping to fix that with a plague setup, across some nodes, that people can ask for access to and then pool in the work being done.
Having been doing exactly this kind of thing for the past 3-4 years with the RedSleeve project, IMO the most important part of this kind of an effort, if it is to be a community effort that scales, is coordination.
Ultimately, anyone can take a F19 image and packages and write a 20 line bash script to rebuild the EL7 src.rpms using mock, then do it again based on the packages that fell out of the first stage, and then doing it again based on the package that fall out of the second stage just to make sure. That just takes CPU time, and situation today is massively less bad than it was about 4 years ago when I first started working on it. For example, back the RedSleeve builders were all Sheeva/Guru/Dream Plus, with 512MB of RAM and running on an NFS rootfs.
Today you can get a single 8-core ARM board with 4GB of RAM, which will outright outperform my entire old build farm on it's own, and avoid the complications of running on NFS by having a SATA port (running NFS root on the build directory caused some package self tests to fail, at least back on EL6).
The part that is human time consuming is fixing all the packages that refuse/fail to build. On EL6 there was over a hundred. On EL7, I'm told it's less bad, but I'm not so sure - having tried to build an i686 EL7 build, there seems to be a lot of spurious build breakages so it isn't a plain, simple, out of the box "just works" process. Having some way to distribute that effort is the difficult part to coordinate. Raising tickets is cumbersome, and some issues often disappear on a subsequent rebuild (and some things fail in stage 2 even though they build in stage 1 based off Fedora packages).
If anyone has a sensible method to automate such a process, I would love to hear about it. Otherwise it takes somebody to take charge and effectively perform such coordination as almost a full time job until the initial complete release build is rolled out (after that the effort reduces dramatically).
I wish I could say I had a nice way. It seems to be 90% of the work on 10% of the packages. For the most part, doing the build loop like you said works for alot of the packages. The majority of the packages that needed tweaking are the ones that RHEL7 has marked as x86_64 only. I will give this tip. Don't start on Fedora 20 for your build repo, or even use it partway through. I did that on my arm build and was delighted that so many package built. Then after a month I started checking dependencies on them. Hardly anything would install because of the crazy dependencies. I think libpng was the biggest issue. It wanted the version of libpng in Fedora 20, which was newer than the version in RHEL7. Had to rebuild the whole thing again.
Troy
On 04/24/2015 06:06 PM, Troy Dawson wrote:
I wish I could say I had a nice way. It seems to be 90% of the work on 10% of the packages. For the most part, doing the build loop like you said works for alot of the packages. The majority of the packages that needed tweaking are the ones that RHEL7 has marked as x86_64 only. I will give this tip. Don't start on Fedora 20 for your build repo, or even use it partway through. I did that on my arm build and was delighted that so many package built. Then after a month I started checking dependencies on them. Hardly anything would install because of the crazy dependencies. I think libpng was the biggest issue. It wanted the version of libpng in Fedora 20, which was newer than the version in RHEL7. Had to rebuild the whole thing again.
Similarly, don't start with fedora18. Here the biggest issues are libffi and libtasn1 (iirc). For RedSleeve 7.1 I did not build many of the x86_64 only stuff. Only corosync and golang. All the rest is not really needed or rightfully x86_64 only.
For reference this is the overview of the issues encountered when building for armv5tel: http://www.mirrorservice.org/sites/ftp.redsleeve.org/pub/el7/7.1/RS7.1_issue...
If relevant, the patches I made should also be there, but the syncing has not completed yet. (the older patches for Redsleeve 7.0 are here: http://www.mirrorservice.org/sites/ftp.redsleeve.org/pub/el7/alpha/patches/ and here: http://www.mirrorservice.org/sites/ftp.redsleeve.org/pub/el7/alpha-updates/p... )
Jacco
On 2015-04-24 17:18, Jacco Ligthart wrote:
On 04/24/2015 06:06 PM, Troy Dawson wrote:
I wish I could say I had a nice way. It seems to be 90% of the work on 10% of the packages. For the most part, doing the build loop like you said works for alot of the packages. The majority of the packages that needed tweaking are the ones that RHEL7 has marked as x86_64 only. I will give this tip. Don't start on Fedora 20 for your build repo, or even use it partway through. I did that on my arm build and was delighted that so many package built. Then after a month I started checking dependencies on them. Hardly anything would install because of the crazy dependencies. I think libpng was the biggest issue. It wanted the version of libpng in Fedora 20, which was newer than the version in RHEL7. Had to rebuild the whole thing again.
Similarly, don't start with fedora18. Here the biggest issues are libffi and libtasn1 (iirc). For RedSleeve 7.1 I did not build many of the x86_64 only stuff. Only corosync and golang. All the rest is not really needed or rightfully x86_64 only.
For reference this is the overview of the issues encountered when building for armv5tel: http://www.mirrorservice.org/sites/ftp.redsleeve.org/pub/el7/7.1/RS7.1_issue...
If relevant, the patches I made should also be there, but the syncing has not completed yet. (the older patches for Redsleeve 7.0 are here: http://www.mirrorservice.org/sites/ftp.redsleeve.org/pub/el7/alpha/patches/ and here: http://www.mirrorservice.org/sites/ftp.redsleeve.org/pub/el7/alpha-updates/p... )
There, from The Man, himself - thanks for joining the thread. :)
Gordan
On 2015-04-24 17:06, Troy Dawson wrote:
On Thu, Apr 23, 2015 at 10:26 AM, Gordan Bobic gordan@redsleeve.org wrote:
On 2015-04-23 16:08, Karanbir Singh wrote: On 04/23/2015 02:38 PM, Troy Dawson wrote:
On Fri, Apr 17, 2015 at 11:07 AM, Karanbir Singh <mail-lists@karan.org mailto:mail-lists@karan.org> wrote:
On 17/04/15 14:38, Mandar Joshi wrote:
I can work with Online/Scaleway to build the first CentOS
image for
their systems.
I would like to join the CentOS ARM effort officially.
nothing official here :) people doing the work are in, people hanging around talking and hand waving are not.
This doesn't make any sense. So, if people want to join the CentOS arm effort, they cannot, unless they are already part of the CentOS arm effort? How can people change from "hand waving" to actually doing work?
as you can see, there is no real 'CentOS Arm Effort' - whatever is happening is being done by people on their own, on their own hardware using the centos sources from git.centos.org [1] or srpms.
hoping to fix that with a plague setup, across some nodes, that people can ask for access to and then pool in the work being done.
Having been doing exactly this kind of thing for the past 3-4 years with the RedSleeve project, IMO the most important part of this kind of an effort, if it is to be a community effort that scales, is coordination.
Ultimately, anyone can take a F19 image and packages and write a 20 line bash script to rebuild the EL7 src.rpms using mock, then do it again based on the packages that fell out of the first stage, and then doing it again based on the package that fall out of the second stage just to make sure. That just takes CPU time, and situation today is massively less bad than it was about 4 years ago when I first started working on it. For example, back the RedSleeve builders were all Sheeva/Guru/Dream Plus, with 512MB of RAM and running on an NFS rootfs.
Today you can get a single 8-core ARM board with 4GB of RAM, which will outright outperform my entire old build farm on it's own, and avoid the complications of running on NFS by having a SATA port (running NFS root on the build directory caused some package self tests to fail, at least back on EL6).
The part that is human time consuming is fixing all the packages that refuse/fail to build. On EL6 there was over a hundred. On EL7, I'm told it's less bad, but I'm not so sure - having tried to build an i686 EL7 build, there seems to be a lot of spurious build breakages so it isn't a plain, simple, out of the box "just works" process. Having some way to distribute that effort is the difficult part to coordinate. Raising tickets is cumbersome, and some issues often disappear on a subsequent rebuild (and some things fail in stage 2 even though they build in stage 1 based off Fedora packages).
If anyone has a sensible method to automate such a process, I would love to hear about it. Otherwise it takes somebody to take charge and effectively perform such coordination as almost a full time job until the initial complete release build is rolled out (after that the effort reduces dramatically).
I wish I could say I had a nice way. It seems to be 90% of the work on 10% of the packages.
Yes, that's about right.
For the most part, doing the build loop like you said works for alot of the packages. The majority of the packages that needed tweaking are the ones that RHEL7 has marked as x86_64 only.
Since RHEL src rpms are no longer available, CentOS is about as upstream as it gets for the rest of us. And in CentOS, IIRC from the other day, there are a total of 2 packages that are marked as x86-64 only (as in not including i686). I don't know how many are marked as x86* only.
I will give this tip. Don't start on Fedora 20 for your build repo, or even use it partway through. I did that on my arm build and was delighted that so many package built. Then after a month I started checking dependencies on them. Hardly anything would install because of the crazy dependencies. I think libpng was the biggest issue. It wanted the version of libpng in Fedora 20, which was newer than the version in RHEL7. Had to rebuild the whole thing again.
I seem to recall that Jacco bootstrapped stage 1 with F18, because that is the last Fedora with a soft-float image available and we are targetting RedSleeve at armv5tel. That seems to have worked out quite well.
I am a few days' testing and some de-branding away from announcing RS 7 alpha release for public consumption, but if you want to take it for a spin right now you can find everything you need on the RS mirrors.
AFAIK there is no intention for CentOS to support armv5tel, only armv7hl.
My biggest current frustration is that there seems to be no official effort of any kind to actually get an ARM build released and made available. There were noises about it back in EL6 days, and nothing happened (RedSleeve came about because I needed it and I felt that those claiming it would be too difficult needed putting in their place and those making noise but not producing anything publicly available needed some motivating competition.
Sadly, here we are with EL7 and while the nay-sayers have piped down, there is nothing at all visible and available in terms of a wider concerted effort. In other words, very little has changed.
Gordan
-
Fabian Arrotin -
Gordan Bobic -
Ian McLeod -
Jacco Ligthart -
Jim Perrin -
Karanbir Singh -
Mandar Joshi -
Manuel Wolfshant -
Robert Moskowitz -
Troy Dawson -
Yann Leger