Re: [yocto] [OE-core] Carrier Grade layer proposal
Bruce that is actually the best solution, but I personally did not know it is possible and permitted by the Yocto project git maintainers. That is a really good news. Alex -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Friday, August 01, 2014 7:26 AM To: akuster; Alexandru Vaduva; Joe MacDonald Cc: yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal On 2014-07-31, 9:30 PM, akuster wrote: Bruce, So how / where do I start on the kernel part? How's this for a bad start of an answer .. it depends. Let me point out an example to follow, since that's probably the easiest way to get started. If you look at the linux-yocto-rt recipe, that shows how to use the linux-yocto repo, and build a particular branch (or set of branches) with a configuration that is specific to those branches. i.e. it is a kernel type (we have standard, preempt-rt and tiny at the moment). To test your changes, and configuration fragments, linux-yocto works like any other recipe. You can specify an existing branch like standard/base (see how linux-yocto-tiny does just that), and then add patches and .cfg files to the SRC_URI. The kernel will be patched, and the configuration applied to the build. Once you are happy with the content, the changes can be merged to a dedicated branch (i.e. standard/cgl) and the meta data put into the meta branch of the repo. From that point on, the recipe only needs to specify that branch and you no longer need to patch, or explicitly reference the meta data. You are then in sync with the LTSI/linux-yocto version, and the branch will get stable updates, bug fixes, BSP support, etc. Bruce - Armin On 07/22/2014 08:58 AM, Bruce Ashfield wrote: On 14-07-22 11:54 AM, akuster wrote: Alexandru, Regarding a few packages in category CD. I have latest samhain building as well as grsecurity (pax patches applied against 3.14.12) in a branch in my meta-security tree. I have a bit more testing to do before I was going to post them. And on this note, we should consider the kernel parts and see if getting them into a common location is a good idea. We already have the linux-yocto tree, and it tracks LTSI, has CVE and -stable tracking, and is maintained to support the set of reference boards. Creating yet more reference kernel trees doesn't help our goal of fewer trees and a discrete set of kernel versions. Just something to consider. Cheers, Bruce grsecurity and samhain aren't CGL specific and they maybe belong in a more generalize layer? just a thought. regards, Armin On 07/22/2014 03:52 AM, Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular
Re: [yocto] [OE-core] Carrier Grade layer proposal
On 14-08-01 03:30 AM, Alexandru Vaduva wrote: Bruce that is actually the best solution, but I personally did not know it is possible and permitted by the Yocto project git maintainers. That is a really good news. Definitely something we can do. There are other yocto ecosystem layers that also have configuration and branches that they use in the kernel tree, so we'll be following a model that is established and works pretty well. I'm going to be out of the office for a bit over the next couple of weeks, but I'll monitor the list and help where possible. Cheers, Bruce Alex -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Friday, August 01, 2014 7:26 AM To: akuster; Alexandru Vaduva; Joe MacDonald Cc: yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal On 2014-07-31, 9:30 PM, akuster wrote: Bruce, So how / where do I start on the kernel part? How's this for a bad start of an answer .. it depends. Let me point out an example to follow, since that's probably the easiest way to get started. If you look at the linux-yocto-rt recipe, that shows how to use the linux-yocto repo, and build a particular branch (or set of branches) with a configuration that is specific to those branches. i.e. it is a kernel type (we have standard, preempt-rt and tiny at the moment). To test your changes, and configuration fragments, linux-yocto works like any other recipe. You can specify an existing branch like standard/base (see how linux-yocto-tiny does just that), and then add patches and .cfg files to the SRC_URI. The kernel will be patched, and the configuration applied to the build. Once you are happy with the content, the changes can be merged to a dedicated branch (i.e. standard/cgl) and the meta data put into the meta branch of the repo. From that point on, the recipe only needs to specify that branch and you no longer need to patch, or explicitly reference the meta data. You are then in sync with the LTSI/linux-yocto version, and the branch will get stable updates, bug fixes, BSP support, etc. Bruce - Armin On 07/22/2014 08:58 AM, Bruce Ashfield wrote: On 14-07-22 11:54 AM, akuster wrote: Alexandru, Regarding a few packages in category CD. I have latest samhain building as well as grsecurity (pax patches applied against 3.14.12) in a branch in my meta-security tree. I have a bit more testing to do before I was going to post them. And on this note, we should consider the kernel parts and see if getting them into a common location is a good idea. We already have the linux-yocto tree, and it tracks LTSI, has CVE and -stable tracking, and is maintained to support the set of reference boards. Creating yet more reference kernel trees doesn't help our goal of fewer trees and a discrete set of kernel versions. Just something to consider. Cheers, Bruce grsecurity and samhain aren't CGL specific and they maybe belong in a more generalize layer? just a thought. regards, Armin On 07/22/2014 03:52 AM, Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new
Re: [yocto] [OE-core] Carrier Grade layer proposal
Bruce, So how / where do I start on the kernel part? - Armin On 07/22/2014 08:58 AM, Bruce Ashfield wrote: On 14-07-22 11:54 AM, akuster wrote: Alexandru, Regarding a few packages in category CD. I have latest samhain building as well as grsecurity (pax patches applied against 3.14.12) in a branch in my meta-security tree. I have a bit more testing to do before I was going to post them. And on this note, we should consider the kernel parts and see if getting them into a common location is a good idea. We already have the linux-yocto tree, and it tracks LTSI, has CVE and -stable tracking, and is maintained to support the set of reference boards. Creating yet more reference kernel trees doesn't help our goal of fewer trees and a discrete set of kernel versions. Just something to consider. Cheers, Bruce grsecurity and samhain aren't CGL specific and they maybe belong in a more generalize layer? just a thought. regards, Armin On 07/22/2014 03:52 AM, Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list we can sign up for? I see you have guidance for sending submissions to meta-cgl, but is that a list that's open to the community, or is it an internal alias / distribution list for Enea? Thanks, -J. On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The errors are package related. Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB from poky). I already started fixing a number, of the already existing errors and the patches will be added upstream after proper testing. I will continue the bug fixing and package integration (into the core-image-cgl image) process and after that is finished I will continue with the Category B packages. I will also try to keep you guys informed about the latest updates, mainly on the YPTM, but for those who cannot wait that much, there is the Git repository with which they can interact: http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary Have a good day, Alex -Original Message- From: jefro@gmail.com [mailto:jefro@gmail.com] On Behalf Of Jeff Osier-Mixon Sent: Monday, July 07, 2014 9:22 PM To: Alexandru Vaduva Subject: Re: [OE-core] Carrier Grade layer proposal Thanks
Re: [yocto] [OE-core] Carrier Grade layer proposal
On 2014-07-31, 9:30 PM, akuster wrote: Bruce, So how / where do I start on the kernel part? How's this for a bad start of an answer .. it depends. Let me point out an example to follow, since that's probably the easiest way to get started. If you look at the linux-yocto-rt recipe, that shows how to use the linux-yocto repo, and build a particular branch (or set of branches) with a configuration that is specific to those branches. i.e. it is a kernel type (we have standard, preempt-rt and tiny at the moment). To test your changes, and configuration fragments, linux-yocto works like any other recipe. You can specify an existing branch like standard/base (see how linux-yocto-tiny does just that), and then add patches and .cfg files to the SRC_URI. The kernel will be patched, and the configuration applied to the build. Once you are happy with the content, the changes can be merged to a dedicated branch (i.e. standard/cgl) and the meta data put into the meta branch of the repo. From that point on, the recipe only needs to specify that branch and you no longer need to patch, or explicitly reference the meta data. You are then in sync with the LTSI/linux-yocto version, and the branch will get stable updates, bug fixes, BSP support, etc. Bruce - Armin On 07/22/2014 08:58 AM, Bruce Ashfield wrote: On 14-07-22 11:54 AM, akuster wrote: Alexandru, Regarding a few packages in category CD. I have latest samhain building as well as grsecurity (pax patches applied against 3.14.12) in a branch in my meta-security tree. I have a bit more testing to do before I was going to post them. And on this note, we should consider the kernel parts and see if getting them into a common location is a good idea. We already have the linux-yocto tree, and it tracks LTSI, has CVE and -stable tracking, and is maintained to support the set of reference boards. Creating yet more reference kernel trees doesn't help our goal of fewer trees and a discrete set of kernel versions. Just something to consider. Cheers, Bruce grsecurity and samhain aren't CGL specific and they maybe belong in a more generalize layer? just a thought. regards, Armin On 07/22/2014 03:52 AM, Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list
Re: [yocto] [OE-core] Carrier Grade layer proposal
Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list we can sign up for? I see you have guidance for sending submissions to meta-cgl, but is that a list that's open to the community, or is it an internal alias / distribution list for Enea? Thanks, -J. On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The errors are package related. Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB from poky). I already started fixing a number, of the already existing errors and the patches will be added upstream after proper testing. I will continue the bug fixing and package integration (into the core-image-cgl image) process and after that is finished I will continue with the Category B packages. I will also try to keep you guys informed about the latest updates, mainly on the YPTM, but for those who cannot wait that much, there is the Git repository with which they can interact: http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary Have a good day, Alex -Original Message- From: jefro@gmail.com [mailto:jefro@gmail.com] On Behalf Of Jeff Osier-Mixon Sent: Monday, July 07, 2014 9:22 PM To: Alexandru Vaduva Subject: Re: [OE-core] Carrier Grade layer proposal Thanks, Alex. Others on the mailing lists, if you have any comments on the contents of this new layer, please mention them on this thread. Re compilation errors, were they specific to a BSP or were they general errors in the packages? thanks On Mon, Jun 30, 2014 at 8:01 AM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The available layer is a work in progress. For the moment we have done an internal mapping of the packages needed inside meta-cgl layer. The mapping is done as following: A. Requirement that map against package/packages with recipes that already exists in Yocto A1. Requirement that map against package/packages with recipes already existing in meta-enea A2. Requirement that map against package/packages with recipes that exists in Yocto
Re: [yocto] [OE-core] Carrier Grade layer proposal
Hi Alex [RE: [yocto] [OE-core] Carrier Grade layer proposal] On 14.07.22 (Tue 10:52) Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, that is really helpful, actually. So a couple of other things, though. I think I remember that early on you were intending to take your yocto-based system with meta-cgl (and, I imagine based on the contents of the README, the additional dependent layers) through a CGL registration. Really, that's great if you still are, but it sounds like maybe now you're planning a staged approach and are only targeting a subset of the CGL P1s for the end of the year / start of next year. Is that accurate, or are you looking at full P1 compliance by that date? I ask mostly because I know doing a CGL distribution is a big effort (I've been down this road before) and it may be that you don't need to have the system complete before you can move it to the openembedded.org location and get into the system so to speak. Your team is pretty active, though, so I'm sure you'll also notice if things are going into other layers that can save you some time (e.g. the submission of a numactl recipe to meta-oe last week). That, and if I've got an idea of where you're going, I'll be happy to take an early look at what you've got in terms of it's CGL-ness and hopefully make the eventual registration (if you go that route) move along quickly. -J. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list we can sign up for? I see you have guidance for sending submissions to meta-cgl, but is that a list that's open to the community, or is it an internal alias / distribution list for Enea? Thanks, -J. On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The errors are package related. Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB from poky). I already started fixing a number, of the already existing errors and the patches will be added upstream after proper testing. I will continue the bug fixing and package integration (into the core-image-cgl image
Re: [yocto] [OE-core] Carrier Grade layer proposal
Hello again, The P1 compliance until in November is a best effort approach. Regarding the move to the openembedded.org location, we intend to do that as soon as possible after the web page will be put on place, as to make it simple for the community to interact with the layer and have all the needed information available in one place. Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Tuesday, July 22, 2014 4:53 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hi Alex [RE: [yocto] [OE-core] Carrier Grade layer proposal] On 14.07.22 (Tue 10:52) Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, that is really helpful, actually. So a couple of other things, though. I think I remember that early on you were intending to take your yocto-based system with meta-cgl (and, I imagine based on the contents of the README, the additional dependent layers) through a CGL registration. Really, that's great if you still are, but it sounds like maybe now you're planning a staged approach and are only targeting a subset of the CGL P1s for the end of the year / start of next year. Is that accurate, or are you looking at full P1 compliance by that date? I ask mostly because I know doing a CGL distribution is a big effort (I've been down this road before) and it may be that you don't need to have the system complete before you can move it to the openembedded.org location and get into the system so to speak. Your team is pretty active, though, so I'm sure you'll also notice if things are going into other layers that can save you some time (e.g. the submission of a numactl recipe to meta-oe last week). That, and if I've got an idea of where you're going, I'll be happy to take an early look at what you've got in terms of it's CGL-ness and hopefully make the eventual registration (if you go that route) move along quickly. -J. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list we can sign up for? I see you have guidance for sending submissions
Re: [yocto] [OE-core] Carrier Grade layer proposal
A quick follow up to the previous e-mail: I only mention that P1 compliance is until November is a best effort approach. This is very much influenced by the community, the available recipes, bugs etc. The CGL compliance is tested against the qemuppc machine, being the fact that a real target is a bit hard to use by everyone. There is also an idea about a CGL calculator that could offer information about the number of cgl requirements that are met and offer a compliance percentage (similar to LSB), but as I said this is just at the idea level. I believe more info about the milestones and the activities that we commit on doing until those milestones will be available on the web page. Please let me know if any information would be needed in the case I may have overlooked some useful parts of information. In that way I can also make sure this information will be also available when the web page will be up. Alex -Original Message- From: Alexandru Vaduva Sent: Tuesday, July 22, 2014 5:21 PM To: 'Joe MacDonald' Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: RE: [yocto] [OE-core] Carrier Grade layer proposal Hello again, The P1 compliance until in November is a best effort approach. Regarding the move to the openembedded.org location, we intend to do that as soon as possible after the web page will be put on place, as to make it simple for the community to interact with the layer and have all the needed information available in one place. Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Tuesday, July 22, 2014 4:53 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hi Alex [RE: [yocto] [OE-core] Carrier Grade layer proposal] On 14.07.22 (Tue 10:52) Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, that is really helpful, actually. So a couple of other things, though. I think I remember that early on you were intending to take your yocto-based system with meta-cgl (and, I imagine based on the contents of the README, the additional dependent layers) through a CGL registration. Really, that's great if you still are, but it sounds like maybe now you're planning a staged approach and are only targeting a subset of the CGL P1s for the end of the year / start of next year. Is that accurate, or are you looking at full P1 compliance by that date? I ask mostly because I know doing a CGL distribution is a big effort (I've been down this road before) and it may be that you don't need to have the system complete before you can move it to the openembedded.org location and get into the system so to speak. Your team is pretty active, though, so I'm sure you'll also notice if things are going into other layers that can save you some time (e.g. the submission of a numactl recipe to meta-oe last week). That, and if I've got an idea of where you're going, I'll be happy to take an early look at what you've got in terms of it's CGL-ness and hopefully make the eventual registration (if you go that route) move along quickly. -J. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting
Re: [yocto] [OE-core] Carrier Grade layer proposal
Alexandru, Regarding a few packages in category CD. I have latest samhain building as well as grsecurity (pax patches applied against 3.14.12) in a branch in my meta-security tree. I have a bit more testing to do before I was going to post them. grsecurity and samhain aren't CGL specific and they maybe belong in a more generalize layer? just a thought. regards, Armin On 07/22/2014 03:52 AM, Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list we can sign up for? I see you have guidance for sending submissions to meta-cgl, but is that a list that's open to the community, or is it an internal alias / distribution list for Enea? Thanks, -J. On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The errors are package related. Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB from poky). I already started fixing a number, of the already existing errors and the patches will be added upstream after proper testing. I will continue the bug fixing and package integration (into the core-image-cgl image) process and after that is finished I will continue with the Category B packages. I will also try to keep you guys informed about the latest updates, mainly on the YPTM, but for those who cannot wait that much, there is the Git repository with which they can interact: http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary Have a good day, Alex -Original Message- From: jefro@gmail.com [mailto:jefro@gmail.com] On Behalf Of Jeff Osier-Mixon Sent: Monday, July 07, 2014 9:22 PM To: Alexandru Vaduva Subject: Re: [OE-core] Carrier Grade layer proposal Thanks, Alex. Others on the mailing lists, if you have any comments on the contents of this new layer, please mention them on this thread. Re compilation errors, were they specific to a BSP or were they general errors in the packages? thanks On Mon, Jun 30, 2014 at 8:01 AM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The available layer is a work in progress. For the moment we have done
Re: [yocto] [OE-core] Carrier Grade layer proposal
On 14-07-22 11:54 AM, akuster wrote: Alexandru, Regarding a few packages in category CD. I have latest samhain building as well as grsecurity (pax patches applied against 3.14.12) in a branch in my meta-security tree. I have a bit more testing to do before I was going to post them. And on this note, we should consider the kernel parts and see if getting them into a common location is a good idea. We already have the linux-yocto tree, and it tracks LTSI, has CVE and -stable tracking, and is maintained to support the set of reference boards. Creating yet more reference kernel trees doesn't help our goal of fewer trees and a discrete set of kernel versions. Just something to consider. Cheers, Bruce grsecurity and samhain aren't CGL specific and they maybe belong in a more generalize layer? just a thought. regards, Armin On 07/22/2014 03:52 AM, Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list we can sign up for? I see you have guidance for sending submissions to meta-cgl, but is that a list that's open to the community, or is it an internal alias / distribution list for Enea? Thanks, -J. On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The errors are package related. Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB from poky). I already started fixing a number, of the already existing errors and the patches will be added upstream after proper testing. I will continue the bug fixing and package integration (into the core-image-cgl image) process and after that is finished I will continue with the Category B packages. I will also try to keep you guys informed about the latest updates, mainly on the YPTM, but for those who cannot wait that much, there is the Git repository with which they can interact: http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary Have a good day, Alex -Original Message- From: jefro@gmail.com [mailto:jefro@gmail.com] On Behalf Of Jeff Osier-Mixon Sent: Monday, July 07, 2014 9:22 PM To: Alexandru Vaduva Subject: Re: [OE-core] Carrier Grade layer proposal Thanks, Alex. Others on the mailing lists, if you have any comments on the contents of this new layer, please
Re: [yocto] [OE-core] Carrier Grade layer proposal
On 14-07-22 12:02 PM, akuster wrote: On 07/22/2014 08:58 AM, Bruce Ashfield wrote: On 14-07-22 11:54 AM, akuster wrote: Alexandru, Regarding a few packages in category CD. I have latest samhain building as well as grsecurity (pax patches applied against 3.14.12) in a branch in my meta-security tree. I have a bit more testing to do before I was going to post them. And on this note, we should consider the kernel parts and see if getting them into a common location is a good idea. yep. We already have the linux-yocto tree, and it tracks LTSI, has CVE and -stable tracking, and is maintained to support the set of reference boards. Creating yet more reference kernel trees doesn't help our goal of fewer trees and a discrete set of kernel versions. Agreed. Great, glad to hear. I wasn't trying to divert the discussion, just seeing if there was anywhere I could help. I know for certain that Joe has a LOT of experience with grsec, and I've been helping maintain its 'tentacles' for a long time, so I'm sure we can come up with something workable when the time is right. Cheers, Bruce thanks, Armin Just something to consider. Cheers, Bruce grsecurity and samhain aren't CGL specific and they maybe belong in a more generalize layer? just a thought. regards, Armin On 07/22/2014 03:52 AM, Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list we can sign up for? I see you have guidance for sending submissions to meta-cgl, but is that a list that's open to the community, or is it an internal alias / distribution list for Enea? Thanks, -J. On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The errors are package related. Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB from poky). I already started fixing a number, of the already existing errors and the patches will be added upstream after proper testing. I will continue the bug fixing and package integration (into the core-image-cgl image) process and after that is finished I will continue with the Category B packages. I will also try to keep you guys informed about the latest updates, mainly on the YPTM, but for those who cannot wait that much, there is the Git
Re: [yocto] [OE-core] Carrier Grade layer proposal
On 07/22/2014 08:58 AM, Bruce Ashfield wrote: On 14-07-22 11:54 AM, akuster wrote: Alexandru, Regarding a few packages in category CD. I have latest samhain building as well as grsecurity (pax patches applied against 3.14.12) in a branch in my meta-security tree. I have a bit more testing to do before I was going to post them. And on this note, we should consider the kernel parts and see if getting them into a common location is a good idea. yep. We already have the linux-yocto tree, and it tracks LTSI, has CVE and -stable tracking, and is maintained to support the set of reference boards. Creating yet more reference kernel trees doesn't help our goal of fewer trees and a discrete set of kernel versions. Agreed. thanks, Armin Just something to consider. Cheers, Bruce grsecurity and samhain aren't CGL specific and they maybe belong in a more generalize layer? just a thought. regards, Armin On 07/22/2014 03:52 AM, Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list we can sign up for? I see you have guidance for sending submissions to meta-cgl, but is that a list that's open to the community, or is it an internal alias / distribution list for Enea? Thanks, -J. On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The errors are package related. Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB from poky). I already started fixing a number, of the already existing errors and the patches will be added upstream after proper testing. I will continue the bug fixing and package integration (into the core-image-cgl image) process and after that is finished I will continue with the Category B packages. I will also try to keep you guys informed about the latest updates, mainly on the YPTM, but for those who cannot wait that much, there is the Git repository with which they can interact: http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary Have a good day, Alex -Original Message- From: jefro@gmail.com [mailto:jefro@gmail.com] On Behalf Of Jeff Osier-Mixon Sent: Monday, July 07, 2014 9:22 PM To: Alexandru Vaduva Subject: Re: [OE-core] Carrier Grade layer proposal Thanks, Alex. Others on the mailing
Re: [yocto] [OE-core] Carrier Grade layer proposal
OK, thanks for the information and your contribution. I am not opposing to your suggestion but in the same time I believe that this recipe should appear in a properly maintained layer, in the case your layer disappears tomorrow. As you mentioned this information should appear in the mainline meta-security layer. In that case I will use the recipe without adding it into meta-cgl because we do not plan to have duplicate recipes available in meta-cgl layer if this is not applicable. Alex On Tuesday, July 22, 2014 6:54 PM, akuster akus...@mvista.com wrote: Alexandru, Regarding a few packages in category CD. I have latest samhain building as well as grsecurity (pax patches applied against 3.14.12) in a branch in my meta-security tree. I have a bit more testing to do before I was going to post them. grsecurity and samhain aren't CGL specific and they maybe belong in a more generalize layer? just a thought. regards, Armin On 07/22/2014 03:52 AM, Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list we can sign up for? I see you have guidance for sending submissions to meta-cgl, but is that a list that's open to the community, or is it an internal alias / distribution list for Enea? Thanks, -J. On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The errors are package related. Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB from poky). I already started fixing a number, of the already existing errors and the patches will be added upstream after proper testing. I will continue the bug fixing and package integration (into the core-image-cgl image) process and after that is finished I will continue with the Category B packages. I will also try to keep you guys informed about the latest updates, mainly on the YPTM, but for those who cannot wait that much, there is the Git repository with which they can interact: http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary Have a good day, Alex -Original Message- From: jefro@gmail.com [mailto:jefro@gmail.com] On Behalf Of Jeff Osier-Mixon Sent
Re: [yocto] [OE-core] Carrier Grade layer proposal
Glad to hear that Bruce. On Tuesday, July 22, 2014 7:09 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 14-07-22 12:02 PM, akuster wrote: On 07/22/2014 08:58 AM, Bruce Ashfield wrote: On 14-07-22 11:54 AM, akuster wrote: Alexandru, Regarding a few packages in category CD. I have latest samhain building as well as grsecurity (pax patches applied against 3.14.12) in a branch in my meta-security tree. I have a bit more testing to do before I was going to post them. And on this note, we should consider the kernel parts and see if getting them into a common location is a good idea. yep. We already have the linux-yocto tree, and it tracks LTSI, has CVE and -stable tracking, and is maintained to support the set of reference boards. Creating yet more reference kernel trees doesn't help our goal of fewer trees and a discrete set of kernel versions. Agreed. Great, glad to hear. I wasn't trying to divert the discussion, just seeing if there was anywhere I could help. I know for certain that Joe has a LOT of experience with grsec, and I've been helping maintain its 'tentacles' for a long time, so I'm sure we can come up with something workable when the time is right. Cheers, Bruce thanks, Armin Just something to consider. Cheers, Bruce grsecurity and samhain aren't CGL specific and they maybe belong in a more generalize layer? just a thought. regards, Armin On 07/22/2014 03:52 AM, Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list we can sign up for? I see you have guidance for sending submissions to meta-cgl, but is that a list that's open to the community, or is it an internal alias / distribution list for Enea? Thanks, -J. On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The errors are package related. Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB from poky). I already started fixing a number, of the already existing errors and the patches will be added upstream after proper testing. I will continue the bug fixing and package integration (into the core-image-cgl image) process and after
Re: [yocto] [OE-core] Carrier Grade layer proposal
Hello Bruce, What I understand from your mail you suggest using the already available linux-yocto tree. As an answer to this let me assure that as much as possible the meta-cgl layer will try to do that. If that will not be the case I will let the community know that. One such case could be grsecurity(which as Joe mentioned changes the kernel quite much) I also expect more such examples exist. Do you consider this subject needs a new email opened for it? I will think more about this and in the same time gather more information on it. I will try to come back with an answer. Alex -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, July 22, 2014 6:59 PM To: akuster; Alexandru Vaduva; Joe MacDonald Cc: yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal On 14-07-22 11:54 AM, akuster wrote: Alexandru, Regarding a few packages in category CD. I have latest samhain building as well as grsecurity (pax patches applied against 3.14.12) in a branch in my meta-security tree. I have a bit more testing to do before I was going to post them. And on this note, we should consider the kernel parts and see if getting them into a common location is a good idea. We already have the linux-yocto tree, and it tracks LTSI, has CVE and -stable tracking, and is maintained to support the set of reference boards. Creating yet more reference kernel trees doesn't help our goal of fewer trees and a discrete set of kernel versions. Just something to consider. Cheers, Bruce grsecurity and samhain aren't CGL specific and they maybe belong in a more generalize layer? just a thought. regards, Armin On 07/22/2014 03:52 AM, Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list we can sign up for? I see you have guidance for sending submissions to meta-cgl, but is that a list that's open to the community, or is it an internal alias / distribution list for Enea? Thanks, -J. On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The errors are package related. Meta-cgl can be seen as a non BSP
Re: [yocto] [OE-core] Carrier Grade layer proposal
On 14-07-22 01:21 PM, Alexandru Vaduva wrote: Hello Bruce, What I understand from your mail you suggest using the already available linux-yocto tree. As an answer to this let me assure that as much as possible the meta-cgl layer will try to do that. If that will not be the case I will let the community know that. Sounds good. I'm attempting to push everything I do in the yocto eco system into that same kernel tree. That's why meta-cloud-services and meta-virtualization don't carry custom kernels, even though they have some very specific requirements. One such case could be grsecurity(which as Joe mentioned changes the kernel quite much) I also expect more such examples exist. grsec is a well known kernel maintenance cost, but it is something that we can easily deal with (if we want) in the common yocto kernel. Just look at how preempt-rt is managed. We wouldn't want that for all boards and builds, yet it is carried and maintained along with the other features. One someone gets deeper into development, they may find that they want to consume the patch series differently, and that's fine, but getting it along with the other reference kernel versions and features is a good kickstart for development. That means it always patches, and gets CVEs, -stable updates, etc. If grsec is maintained out of a tree (that may or may not be the plan), you'll find that even korg -stable updates will break the application and you'll be in constant refresh mode. Not to mention, repeating the same standard/boring maintenance tasks across multiple trees, when we could be developing new features and fixing bugs. Just more food for thought and options to consider. Do you consider this subject needs a new email opened for it? We could, but I just went and blathered on about it above. So we'll see if an initial direction isn't too far away. Cheers, Bruce I will think more about this and in the same time gather more information on it. I will try to come back with an answer. Alex -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, July 22, 2014 6:59 PM To: akuster; Alexandru Vaduva; Joe MacDonald Cc: yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal On 14-07-22 11:54 AM, akuster wrote: Alexandru, Regarding a few packages in category CD. I have latest samhain building as well as grsecurity (pax patches applied against 3.14.12) in a branch in my meta-security tree. I have a bit more testing to do before I was going to post them. And on this note, we should consider the kernel parts and see if getting them into a common location is a good idea. We already have the linux-yocto tree, and it tracks LTSI, has CVE and -stable tracking, and is maintained to support the set of reference boards. Creating yet more reference kernel trees doesn't help our goal of fewer trees and a discrete set of kernel versions. Just something to consider. Cheers, Bruce grsecurity and samhain aren't CGL specific and they maybe belong in a more generalize layer? just a thought. regards, Armin On 07/22/2014 03:52 AM, Alexandru Vaduva wrote: Hello Joe, Here at Enea we are preparing the steps needed for publishing the layer on the open embedded meta layers initiative: http://layers.openembedded.org/layerindex/branch/master/layers/ For this we started working at a web page that should contain all the relevant information regarding meta-cgl. It will be available in a couple of weeks. Until then the layer will be available internally and the patches should be submitted as the README states: on the eneali...@lists.enea.com mailing list. We will try to make the switch to Open Embedded mailing list as quick as possible. Regarding the other B, C and D packages that we will try to add into the meta-cgl layer, I will post this information below, but keep in mind that this information will also be available on the web page. Category B packages: - ifenslave - evlog - crash - mipv6-daemon-umip - openl2tp Category CD packages: - drbd - grsecurity - logcheck - makedumpfile - numactl - ocfs2-tools - pam_passwdqc - samhain - ltt-usertrace - ftrace The above lists correspond with only the P1 requirements that we try to fulfill for the moment. If there are any questions and/or suggestions regarding this CGL initialtive please address them to me and I will try to offer a response in the shortest time possible. Thanks, Alex -Original Message- From: Joe MacDonald [mailto:j...@deserted.net] Sent: Monday, July 21, 2014 10:58 PM To: Alexandru Vaduva Cc: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] [OE-core] Carrier Grade layer proposal Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail
Re: [yocto] [OE-core] Carrier Grade layer proposal
Hey Alex, I've been away from this for a bit but now I'm getting time to look at it again and I was wondering if you had any deeper level of detail you could share about the work going on in meta-cgl. Obviously since this is a new registration and one that will look rather different from all of the other CGL registrations currently, those of us in the CGL workgroup were quite interested to see this happen. Personally I'm also interested in this since it's the kind of thing I've been doing for a long time now and if I can, I'd like to help out. In particular, if you've got a list of, say, the category B+ items, that might be something I can do that will be independent of your work on the more active cat-A stuff. OTOH, cat-A is easy to work on since those are the items I saw when I was working with meta-cgl a month or so back. I know you guys are focused on your part of it, but if you had sort of a here's how to help us guide, that'd be awesome. Also, I probably missed it, but is the intent to use either the yocto list or the oe list for all meta-cgl discussions, or do you have a dedicated list we can sign up for? I see you have guidance for sending submissions to meta-cgl, but is that a list that's open to the community, or is it an internal alias / distribution list for Enea? Thanks, -J. On Mon, Jul 7, 2014 at 2:43 PM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The errors are package related. Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB from poky). I already started fixing a number, of the already existing errors and the patches will be added upstream after proper testing. I will continue the bug fixing and package integration (into the core-image-cgl image) process and after that is finished I will continue with the Category B packages. I will also try to keep you guys informed about the latest updates, mainly on the YPTM, but for those who cannot wait that much, there is the Git repository with which they can interact: http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary Have a good day, Alex -Original Message- From: jefro@gmail.com [mailto:jefro@gmail.com] On Behalf Of Jeff Osier-Mixon Sent: Monday, July 07, 2014 9:22 PM To: Alexandru Vaduva Subject: Re: [OE-core] Carrier Grade layer proposal Thanks, Alex. Others on the mailing lists, if you have any comments on the contents of this new layer, please mention them on this thread. Re compilation errors, were they specific to a BSP or were they general errors in the packages? thanks On Mon, Jun 30, 2014 at 8:01 AM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The available layer is a work in progress. For the moment we have done an internal mapping of the packages needed inside meta-cgl layer. The mapping is done as following: A. Requirement that map against package/packages with recipes that already exists in Yocto A1. Requirement that map against package/packages with recipes already existing in meta-enea A2. Requirement that map against package/packages with recipes that exists in Yocto (but not in meta-enea) B. Requirement that map against package/packages without any recipe C. Requirement does not directly map against package/packages and needs some investigation. D. Requirement that no solution have been found after a more detailed investigation. When the release was made available on the public repository, the packages from the A1 and A2 were integrated, a bunch of them with compilation errors: - lksctp-tools - openais - pacemaker - openhpi - open-iscsi-user - open-iscsi-kernel - libcap-ng - cluster-glue - cluster-resource-agents The activity on the meta-cgl was resumed today and those build and integration errors will be dealt next. On the longer run we will try to create recipes and/or fulfill all the other requirements from the class B, C, and D. Please do not hesitate to contact me if you have further questions. Alex From: Jon Aldama Sent: Friday, June 27, 2014 1:07 PM To: Alexandru Vaduva; Cosmin Moldoveanu; Jenny Andersson; David Nyström Cc: Daniel Bornaz; Adrian Dudau Subject: RE: Carrier Grade layer proposal Roger that! Thanks Alexandru! From: Alexandru Vaduva Sent: den 27 juni 2014 11:43 To: Jon Aldama; Cosmin Moldoveanu; Jenny Andersson; David Nyström Cc: Daniel Bornaz; Adrian Dudau Subject: RE: Carrier Grade layer proposal Hello Jon, We will first have an internal meeting on Monday and after that I will offer an answer to Jeff. Alex From: Jon Aldama Sent: Friday, June 27, 2014 12:32 PM To: Cosmin Moldoveanu; Jenny Andersson; David Nyström Cc: Alexandru Vaduva; Daniel Bornaz; Adrian Dudau Subject: RE: Carrier Grade layer proposal Thank you Cosmin, Alexandru, could you please respond Jeff at the
Re: [yocto] [OE-core] Carrier Grade layer proposal
Hello Jeff, The errors are package related. Meta-cgl can be seen as a non BSP specific layer (it can be viewed as the LSB from poky). I already started fixing a number, of the already existing errors and the patches will be added upstream after proper testing. I will continue the bug fixing and package integration (into the core-image-cgl image) process and after that is finished I will continue with the Category B packages. I will also try to keep you guys informed about the latest updates, mainly on the YPTM, but for those who cannot wait that much, there is the Git repository with which they can interact: http://git.enea.com/git/?p=linux/meta-cgl.git;a=summary Have a good day, Alex -Original Message- From: jefro@gmail.com [mailto:jefro@gmail.com] On Behalf Of Jeff Osier-Mixon Sent: Monday, July 07, 2014 9:22 PM To: Alexandru Vaduva Subject: Re: [OE-core] Carrier Grade layer proposal Thanks, Alex. Others on the mailing lists, if you have any comments on the contents of this new layer, please mention them on this thread. Re compilation errors, were they specific to a BSP or were they general errors in the packages? thanks On Mon, Jun 30, 2014 at 8:01 AM, Alexandru Vaduva alexandru.vad...@enea.com wrote: Hello Jeff, The available layer is a work in progress. For the moment we have done an internal mapping of the packages needed inside meta-cgl layer. The mapping is done as following: A. Requirement that map against package/packages with recipes that already exists in Yocto A1. Requirement that map against package/packages with recipes already existing in meta-enea A2. Requirement that map against package/packages with recipes that exists in Yocto (but not in meta-enea) B. Requirement that map against package/packages without any recipe C. Requirement does not directly map against package/packages and needs some investigation. D. Requirement that no solution have been found after a more detailed investigation. When the release was made available on the public repository, the packages from the A1 and A2 were integrated, a bunch of them with compilation errors: - lksctp-tools - openais - pacemaker - openhpi - open-iscsi-user - open-iscsi-kernel - libcap-ng - cluster-glue - cluster-resource-agents The activity on the meta-cgl was resumed today and those build and integration errors will be dealt next. On the longer run we will try to create recipes and/or fulfill all the other requirements from the class B, C, and D. Please do not hesitate to contact me if you have further questions. Alex From: Jon Aldama Sent: Friday, June 27, 2014 1:07 PM To: Alexandru Vaduva; Cosmin Moldoveanu; Jenny Andersson; David Nyström Cc: Daniel Bornaz; Adrian Dudau Subject: RE: Carrier Grade layer proposal Roger that! Thanks Alexandru! From: Alexandru Vaduva Sent: den 27 juni 2014 11:43 To: Jon Aldama; Cosmin Moldoveanu; Jenny Andersson; David Nyström Cc: Daniel Bornaz; Adrian Dudau Subject: RE: Carrier Grade layer proposal Hello Jon, We will first have an internal meeting on Monday and after that I will offer an answer to Jeff. Alex From: Jon Aldama Sent: Friday, June 27, 2014 12:32 PM To: Cosmin Moldoveanu; Jenny Andersson; David Nyström Cc: Alexandru Vaduva; Daniel Bornaz; Adrian Dudau Subject: RE: Carrier Grade layer proposal Thank you Cosmin, Alexandru, could you please respond Jeff at the mailing list? (see down below) Cheers Jon From: Cosmin Moldoveanu Sent: den 27 juni 2014 10:59 To: Jenny Andersson; Jon Aldama; David Nyström Cc: Alexandru Vaduva; Daniel Bornaz; Adrian Dudau Subject: RE: Carrier Grade layer proposal Hi, Alexandru Vaduva will be main responsible for interfacing with community on meta-cgl topic. He will also attend Yocto Technical Meetings whenever necessary from now on. BR, /Cosmin From: Jenny Andersson Sent: Friday, June 27, 2014 10:32 AM To: Jon Aldama; David Nyström; Cosmin Moldoveanu Cc: Valentin Cobelea Subject: RE: Carrier Grade layer proposal Hi Cosmin, How took over after Valentin left Enea? Could someone in your team respond. Thanks, Jenny From: Jon Aldama Sent: den 27 juni 2014 09:28 To: David Nyström; Jenny Andersson Cc: Valentin Cobelea Subject: FW: Carrier Grade layer proposal David, Jenny, Will any of you answer this? BTW, have you managed to file the Yocto compatibility application? Regards Jon From: Osier-mixon, Jeffrey [mailto:jeffrey.osier-mi...@intel.com] Sent: den 26 juni 2014 20:36 To: David Nyström; davide.ri...@windriver.com; challi...@gmail.com; teodor.boborn...@windriver.com; Valentin Cobelea; chase.mau...@ti.com; Jon Aldama; philip.balis...@gmail.com; kevin_mcco...@mentor.com; akus...@mvista.com; jason.wes...@windriver.com;
