* [meta-arm][PATCH] meta-arm: Remove meta-python dependency @ 2020-05-29 15:14 Joshua Watt 2020-05-29 15:21 ` Bertrand Marquis 0 siblings, 1 reply; 17+ messages in thread From: Joshua Watt @ 2020-05-29 15:14 UTC (permalink / raw) To: meta-arm; +Cc: Joshua Watt Removes the dependency on meta-arm, now that the required python modules recipes are in oe-core. Ensure that a sufficiently new enough version of oe-core is present for the recipes to be provided. Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> --- meta-arm/conf/layer.conf | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf index d96e9f1..1c241d4 100644 --- a/meta-arm/conf/layer.conf +++ b/meta-arm/conf/layer.conf @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" LAYERDEPENDS_meta-arm = " \ core \ - meta-python \ " -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" -- 2.17.1 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-05-29 15:14 [meta-arm][PATCH] meta-arm: Remove meta-python dependency Joshua Watt @ 2020-05-29 15:21 ` Bertrand Marquis 2020-05-29 15:32 ` Joshua Watt 0 siblings, 1 reply; 17+ messages in thread From: Bertrand Marquis @ 2020-05-29 15:21 UTC (permalink / raw) To: Joshua Watt; +Cc: meta-arm, nd > On 29 May 2020, at 16:14, Joshua Watt via lists.yoctoproject.org <JPEWhacker=gmail.com@lists.yoctoproject.org> wrote: > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> > --- > meta-arm/conf/layer.conf | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf > index d96e9f1..1c241d4 100644 > --- a/meta-arm/conf/layer.conf > +++ b/meta-arm/conf/layer.conf > @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" > > LAYERDEPENDS_meta-arm = " \ > core \ > - meta-python \ > " > -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" > +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" Could you explain why you want to remove dunfell compatibility ? Bertrand > -- > 2.17.1 > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-05-29 15:21 ` Bertrand Marquis @ 2020-05-29 15:32 ` Joshua Watt 2020-05-29 15:37 ` Bertrand Marquis 0 siblings, 1 reply; 17+ messages in thread From: Joshua Watt @ 2020-05-29 15:32 UTC (permalink / raw) To: Bertrand Marquis; +Cc: meta-arm, nd On 5/29/20 10:21 AM, Bertrand Marquis wrote: > >> On 29 May 2020, at 16:14, Joshua Watt via lists.yoctoproject.org <JPEWhacker=gmail.com@lists.yoctoproject.org> wrote: >> >> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> >> --- >> meta-arm/conf/layer.conf | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf >> index d96e9f1..1c241d4 100644 >> --- a/meta-arm/conf/layer.conf >> +++ b/meta-arm/conf/layer.conf >> @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" >> >> LAYERDEPENDS_meta-arm = " \ >> core \ >> - meta-python \ >> " >> -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" >> +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" > Could you explain why you want to remove dunfell compatibility ? dunfell doesn't have the required python recipes in oe-core, so it isn't compatible with it anymore. > > Bertrand > >> -- >> 2.17.1 >> >> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-05-29 15:32 ` Joshua Watt @ 2020-05-29 15:37 ` Bertrand Marquis 2020-05-30 18:39 ` Joshua Watt 0 siblings, 1 reply; 17+ messages in thread From: Bertrand Marquis @ 2020-05-29 15:37 UTC (permalink / raw) To: Joshua Watt; +Cc: meta-arm, nd > On 29 May 2020, at 16:32, Joshua Watt <JPEWhacker@gmail.com> wrote: > > > On 5/29/20 10:21 AM, Bertrand Marquis wrote: >> >>> On 29 May 2020, at 16:14, Joshua Watt via lists.yoctoproject.org <JPEWhacker=gmail.com@lists.yoctoproject.org> wrote: >>> >>> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> >>> --- >>> meta-arm/conf/layer.conf | 3 +-- >>> 1 file changed, 1 insertion(+), 2 deletions(-) >>> >>> diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf >>> index d96e9f1..1c241d4 100644 >>> --- a/meta-arm/conf/layer.conf >>> +++ b/meta-arm/conf/layer.conf >>> @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" >>> >>> LAYERDEPENDS_meta-arm = " \ >>> core \ >>> - meta-python \ >>> " >>> -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" >>> +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" >> Could you explain why you want to remove dunfell compatibility ? > > dunfell doesn't have the required python recipes in oe-core, so it isn't compatible with it anymore. Nothing has been tested or is compatible with gatesgarth right now so this change will really have a breaking impact. Bertrand > > >> >> Bertrand >> >>> -- >>> 2.17.1 >>> >>> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-05-29 15:37 ` Bertrand Marquis @ 2020-05-30 18:39 ` Joshua Watt 2020-06-01 21:31 ` Jon Mason 0 siblings, 1 reply; 17+ messages in thread From: Joshua Watt @ 2020-05-30 18:39 UTC (permalink / raw) To: Bertrand Marquis; +Cc: meta-arm, nd [-- Attachment #1: Type: text/plain, Size: 2028 bytes --] On Fri, May 29, 2020, 10:37 AM Bertrand Marquis <Bertrand.Marquis@arm.com> wrote: > > > > On 29 May 2020, at 16:32, Joshua Watt <JPEWhacker@gmail.com> wrote: > > > > > > On 5/29/20 10:21 AM, Bertrand Marquis wrote: > >> > >>> On 29 May 2020, at 16:14, Joshua Watt via lists.yoctoproject.org > <JPEWhacker=gmail.com@lists.yoctoproject.org> wrote: > >>> > >>> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> > >>> --- > >>> meta-arm/conf/layer.conf | 3 +-- > >>> 1 file changed, 1 insertion(+), 2 deletions(-) > >>> > >>> diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf > >>> index d96e9f1..1c241d4 100644 > >>> --- a/meta-arm/conf/layer.conf > >>> +++ b/meta-arm/conf/layer.conf > >>> @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" > >>> > >>> LAYERDEPENDS_meta-arm = " \ > >>> core \ > >>> - meta-python \ > >>> " > >>> -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" > >>> +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" > >> Could you explain why you want to remove dunfell compatibility ? > > > > dunfell doesn't have the required python recipes in oe-core, so it isn't > compatible with it anymore. > > Nothing has been tested or is compatible with gatesgarth right now so this > change will really have a breaking impact. > Right, you certainly wouldn't want to backport it to the dunfell branch; this is just for master where the next release would be gatesgarth anyway. Also, with the qemu support I added, I think we have reasonable testing coverage on meta-arm, and in particular enough to have high confidence in this change. Finally, FWIW, upstream oe-core and meta-python have already made these changes on their master branches, so it seems like we wouldn't want a useless dependency on meta-python in meta-arm, *especially* if the idea is to get other bsp layers to depend on meta-arm to consolidate things like TF-A and optee. > Bertrand > > > > > > >> > >> Bertrand > >> > >>> -- > >>> 2.17.1 > >>> > >>> > > [-- Attachment #2: Type: text/html, Size: 3383 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-05-30 18:39 ` Joshua Watt @ 2020-06-01 21:31 ` Jon Mason 2020-06-01 21:55 ` Joshua Watt 0 siblings, 1 reply; 17+ messages in thread From: Jon Mason @ 2020-06-01 21:31 UTC (permalink / raw) To: Joshua Watt; +Cc: Bertrand Marquis, meta-arm On Sat, May 30, 2020 at 01:39:49PM -0500, Joshua Watt wrote: > On Fri, May 29, 2020, 10:37 AM Bertrand Marquis <Bertrand.Marquis@arm.com> > wrote: > > > > > > > > On 29 May 2020, at 16:32, Joshua Watt <JPEWhacker@gmail.com> wrote: > > > > > > > > > On 5/29/20 10:21 AM, Bertrand Marquis wrote: > > >> > > >>> On 29 May 2020, at 16:14, Joshua Watt via lists.yoctoproject.org > > <JPEWhacker=gmail.com@lists.yoctoproject.org> wrote: > > >>> > > >>> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> > > >>> --- > > >>> meta-arm/conf/layer.conf | 3 +-- > > >>> 1 file changed, 1 insertion(+), 2 deletions(-) > > >>> > > >>> diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf > > >>> index d96e9f1..1c241d4 100644 > > >>> --- a/meta-arm/conf/layer.conf > > >>> +++ b/meta-arm/conf/layer.conf > > >>> @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" > > >>> > > >>> LAYERDEPENDS_meta-arm = " \ > > >>> core \ > > >>> - meta-python \ > > >>> " > > >>> -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" > > >>> +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" > > >> Could you explain why you want to remove dunfell compatibility ? > > > > > > dunfell doesn't have the required python recipes in oe-core, so it isn't > > compatible with it anymore. > > > > Nothing has been tested or is compatible with gatesgarth right now so this > > change will really have a breaking impact. > > > > Right, you certainly wouldn't want to backport it to the dunfell branch; > this is just for master where the next release would be gatesgarth anyway. > > Also, with the qemu support I added, I think we have reasonable testing > coverage on meta-arm, and in particular enough to have high confidence in > this change. > > Finally, FWIW, upstream oe-core and meta-python have already made these > changes on their master branches, so it seems like we wouldn't want a > useless dependency on meta-python in meta-arm, *especially* if the idea is > to get other bsp layers to depend on meta-arm to consolidate things like > TF-A and optee. We currently have a requirement for dunfell compatability on the meta-arm master branch for Arm's BSP software releases (which will be YP based going forward). To make a stable release for our customers, we need to draw a line between stablity of our dependent layers and the latest code in the meta-arm layer. This especially relates to the BSPs Arm will be adding to meta-arm-bsp in this release. We do not have to keep dunfell support in master after the release of gatesgarth, but we will need it until then. So, please stash this patch until October (which will be here sooner than you think). Thanks, Jon > > > > Bertrand > > > > > > > > > > >> > > >> Bertrand > > >> > > >>> -- > > >>> 2.17.1 > > >>> > > >>> > > > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-06-01 21:31 ` Jon Mason @ 2020-06-01 21:55 ` Joshua Watt 2020-06-01 22:56 ` Jon Mason 2020-06-02 13:20 ` Joshua Watt 0 siblings, 2 replies; 17+ messages in thread From: Joshua Watt @ 2020-06-01 21:55 UTC (permalink / raw) To: Jon Mason; +Cc: Bertrand Marquis, meta-arm On 6/1/20 4:31 PM, Jon Mason wrote: > On Sat, May 30, 2020 at 01:39:49PM -0500, Joshua Watt wrote: >> On Fri, May 29, 2020, 10:37 AM Bertrand Marquis <Bertrand.Marquis@arm.com> >> wrote: >> >>> >>>> On 29 May 2020, at 16:32, Joshua Watt <JPEWhacker@gmail.com> wrote: >>>> >>>> >>>> On 5/29/20 10:21 AM, Bertrand Marquis wrote: >>>>>> On 29 May 2020, at 16:14, Joshua Watt via lists.yoctoproject.org >>> <JPEWhacker=gmail.com@lists.yoctoproject.org> wrote: >>>>>> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> >>>>>> --- >>>>>> meta-arm/conf/layer.conf | 3 +-- >>>>>> 1 file changed, 1 insertion(+), 2 deletions(-) >>>>>> >>>>>> diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf >>>>>> index d96e9f1..1c241d4 100644 >>>>>> --- a/meta-arm/conf/layer.conf >>>>>> +++ b/meta-arm/conf/layer.conf >>>>>> @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" >>>>>> >>>>>> LAYERDEPENDS_meta-arm = " \ >>>>>> core \ >>>>>> - meta-python \ >>>>>> " >>>>>> -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" >>>>>> +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" >>>>> Could you explain why you want to remove dunfell compatibility ? >>>> dunfell doesn't have the required python recipes in oe-core, so it isn't >>> compatible with it anymore. >>> >>> Nothing has been tested or is compatible with gatesgarth right now so this >>> change will really have a breaking impact. >>> >> Right, you certainly wouldn't want to backport it to the dunfell branch; >> this is just for master where the next release would be gatesgarth anyway. >> >> Also, with the qemu support I added, I think we have reasonable testing >> coverage on meta-arm, and in particular enough to have high confidence in >> this change. >> >> Finally, FWIW, upstream oe-core and meta-python have already made these >> changes on their master branches, so it seems like we wouldn't want a >> useless dependency on meta-python in meta-arm, *especially* if the idea is >> to get other bsp layers to depend on meta-arm to consolidate things like >> TF-A and optee. > We currently have a requirement for dunfell compatability on the > meta-arm master branch for Arm's BSP software releases (which will > be YP based going forward). To make a stable release for our > customers, we need to draw a line between stablity of our dependent > layers and the latest code in the meta-arm layer. This especially > relates to the BSPs Arm will be adding to meta-arm-bsp in this > release. > > We do not have to keep dunfell support in master after the release of > gatesgarth, but we will need it until then. So, please stash this > patch until October (which will be here sooner than you think). Hmm, that's really unfortunate. That makes me think this layer is not actually intended to be a centralized location for ARM related things, and I'm probably not going to try and consolidate things from other layers here anymore. Not having a master branch that can be used with the master branch of OE-core really eliminates the possibility for me to use a BSP layer like e.g. meta-rockchip for upstream development and testing if that BSP layer depends on meta-arm and meta-arm is perpetually stuck on the last release. > > Thanks, > Jon > > >> >>> Bertrand >>> >>>> >>>>> Bertrand >>>>> >>>>>> -- >>>>>> 2.17.1 >>>>>> >>>>>> >>> >> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-06-01 21:55 ` Joshua Watt @ 2020-06-01 22:56 ` Jon Mason 2020-06-02 6:10 ` Nicolas Dechesne ` (2 more replies) 2020-06-02 13:20 ` Joshua Watt 1 sibling, 3 replies; 17+ messages in thread From: Jon Mason @ 2020-06-01 22:56 UTC (permalink / raw) To: Joshua Watt; +Cc: Bertrand Marquis, meta-arm On Mon, Jun 01, 2020 at 04:55:24PM -0500, Joshua Watt wrote: > > On 6/1/20 4:31 PM, Jon Mason wrote: > > On Sat, May 30, 2020 at 01:39:49PM -0500, Joshua Watt wrote: > > > On Fri, May 29, 2020, 10:37 AM Bertrand Marquis <Bertrand.Marquis@arm.com> > > > wrote: > > > > > > > > > > > > On 29 May 2020, at 16:32, Joshua Watt <JPEWhacker@gmail.com> wrote: > > > > > > > > > > > > > > > On 5/29/20 10:21 AM, Bertrand Marquis wrote: > > > > > > > On 29 May 2020, at 16:14, Joshua Watt via lists.yoctoproject.org > > > > <JPEWhacker=gmail.com@lists.yoctoproject.org> wrote: > > > > > > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> > > > > > > > --- > > > > > > > meta-arm/conf/layer.conf | 3 +-- > > > > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > > > > > > > > > diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf > > > > > > > index d96e9f1..1c241d4 100644 > > > > > > > --- a/meta-arm/conf/layer.conf > > > > > > > +++ b/meta-arm/conf/layer.conf > > > > > > > @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" > > > > > > > > > > > > > > LAYERDEPENDS_meta-arm = " \ > > > > > > > core \ > > > > > > > - meta-python \ > > > > > > > " > > > > > > > -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" > > > > > > > +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" > > > > > > Could you explain why you want to remove dunfell compatibility ? > > > > > dunfell doesn't have the required python recipes in oe-core, so it isn't > > > > compatible with it anymore. > > > > > > > > Nothing has been tested or is compatible with gatesgarth right now so this > > > > change will really have a breaking impact. > > > > > > > Right, you certainly wouldn't want to backport it to the dunfell branch; > > > this is just for master where the next release would be gatesgarth anyway. > > > > > > Also, with the qemu support I added, I think we have reasonable testing > > > coverage on meta-arm, and in particular enough to have high confidence in > > > this change. > > > > > > Finally, FWIW, upstream oe-core and meta-python have already made these > > > changes on their master branches, so it seems like we wouldn't want a > > > useless dependency on meta-python in meta-arm, *especially* if the idea is > > > to get other bsp layers to depend on meta-arm to consolidate things like > > > TF-A and optee. > > We currently have a requirement for dunfell compatability on the > > meta-arm master branch for Arm's BSP software releases (which will > > be YP based going forward). To make a stable release for our > > customers, we need to draw a line between stablity of our dependent > > layers and the latest code in the meta-arm layer. This especially > > relates to the BSPs Arm will be adding to meta-arm-bsp in this > > release. > > > > We do not have to keep dunfell support in master after the release of > > gatesgarth, but we will need it until then. So, please stash this > > patch until October (which will be here sooner than you think). > > Hmm, that's really unfortunate. That makes me think this layer is not > actually intended to be a centralized location for ARM related things, and > I'm probably not going to try and consolidate things from other layers here > anymore. Not having a master branch that can be used with the master branch > of OE-core really eliminates the possibility for me to use a BSP layer like > e.g. meta-rockchip for upstream development and testing if that BSP layer > depends on meta-arm and meta-arm is perpetually stuck on the last release. I'm in no way saying that meta-arm master should not work with upstream master. I'm saying that we want to keep compatability with the previous release so that we can cut stable releases for customers. We have a requirement to release BSP SW based on YP. Just like I would expect other vendors/people who want to use meta-arm. So, there are a few ways we can approach this issue. 1. Merge patches onto dunfell branch 2. A development branch based on dunfell 3. Use master meta-arm-bsp and dunfell branches for meta-arm and meta-arm-toolchain 4. Keep master compatible with dunfell One is simple, we actually do our development on the dunfell branch. However, this breaks it from being a stable branch. So, this is a non-starter Two is still simple, we do all of our internal development on a second dunfell branch ("dunfell-dev") and make any releases we have off of that. The problem with this is the integration and testing. If there are multiple branches to test, can we expect developers to test every combination? Also, there might be a need for different versions of the patches depending on how much master and dunfell-dev diverge. Three is more complex. Since only meta-arm-bsp needs releases, we can simply let that one float and fix the others on the stable branches. The problem with this is that we are currently needing to add recipes for things into meta-arm that others might need (like SCP, EDK2, etc). So, this will work once we have more stability in meta-arm, but right now we are adding too much stuff to make it viable for the next release. Four is simple, we keep compatability with dunfell and make the releases off of that. The potential hazard with this is if something in YP master requires that compatability to be broken. I presonally would like #4, because it is simple. However, if this will prevent others from using meta-arm, then let's have a discussion on it. Perhaps I am not understanding something fundamental. Thanks, Jon > > > > > > Thanks, > > Jon > > > > > > > > > > > Bertrand > > > > > > > > > > > > > > > Bertrand > > > > > > > > > > > > > -- > > > > > > > 2.17.1 > > > > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-06-01 22:56 ` Jon Mason @ 2020-06-02 6:10 ` Nicolas Dechesne 2020-06-05 23:44 ` Denys Dmytriyenko 2020-06-02 12:51 ` Richard Purdie 2020-06-02 13:24 ` Ross Burton 2 siblings, 1 reply; 17+ messages in thread From: Nicolas Dechesne @ 2020-06-02 6:10 UTC (permalink / raw) To: Jon Mason; +Cc: Joshua Watt, Bertrand Marquis, meta-arm [-- Attachment #1: Type: text/plain, Size: 8221 bytes --] hey Jon, On Tue, Jun 2, 2020 at 12:56 AM Jon Mason <jdmason@kudzu.us> wrote: > On Mon, Jun 01, 2020 at 04:55:24PM -0500, Joshua Watt wrote: > > > > On 6/1/20 4:31 PM, Jon Mason wrote: > > > On Sat, May 30, 2020 at 01:39:49PM -0500, Joshua Watt wrote: > > > > On Fri, May 29, 2020, 10:37 AM Bertrand Marquis < > Bertrand.Marquis@arm.com> > > > > wrote: > > > > > > > > > > > > > > > On 29 May 2020, at 16:32, Joshua Watt <JPEWhacker@gmail.com> > wrote: > > > > > > > > > > > > > > > > > > On 5/29/20 10:21 AM, Bertrand Marquis wrote: > > > > > > > > On 29 May 2020, at 16:14, Joshua Watt via > lists.yoctoproject.org > > > > > <JPEWhacker=gmail.com@lists.yoctoproject.org> wrote: > > > > > > > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> > > > > > > > > --- > > > > > > > > meta-arm/conf/layer.conf | 3 +-- > > > > > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > > > > > > > > > > > diff --git a/meta-arm/conf/layer.conf > b/meta-arm/conf/layer.conf > > > > > > > > index d96e9f1..1c241d4 100644 > > > > > > > > --- a/meta-arm/conf/layer.conf > > > > > > > > +++ b/meta-arm/conf/layer.conf > > > > > > > > @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" > > > > > > > > > > > > > > > > LAYERDEPENDS_meta-arm = " \ > > > > > > > > core \ > > > > > > > > - meta-python \ > > > > > > > > " > > > > > > > > -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" > > > > > > > > +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" > > > > > > > Could you explain why you want to remove dunfell compatibility > ? > > > > > > dunfell doesn't have the required python recipes in oe-core, so > it isn't > > > > > compatible with it anymore. > > > > > > > > > > Nothing has been tested or is compatible with gatesgarth right now > so this > > > > > change will really have a breaking impact. > > > > > > > > > Right, you certainly wouldn't want to backport it to the dunfell > branch; > > > > this is just for master where the next release would be gatesgarth > anyway. > > > > > > > > Also, with the qemu support I added, I think we have reasonable > testing > > > > coverage on meta-arm, and in particular enough to have high > confidence in > > > > this change. > > > > > > > > Finally, FWIW, upstream oe-core and meta-python have already made > these > > > > changes on their master branches, so it seems like we wouldn't want a > > > > useless dependency on meta-python in meta-arm, *especially* if the > idea is > > > > to get other bsp layers to depend on meta-arm to consolidate things > like > > > > TF-A and optee. > > > We currently have a requirement for dunfell compatability on the > > > meta-arm master branch for Arm's BSP software releases (which will > > > be YP based going forward). To make a stable release for our > > > customers, we need to draw a line between stablity of our dependent > > > layers and the latest code in the meta-arm layer. This especially > > > relates to the BSPs Arm will be adding to meta-arm-bsp in this > > > release. > > > > > > We do not have to keep dunfell support in master after the release of > > > gatesgarth, but we will need it until then. So, please stash this > > > patch until October (which will be here sooner than you think). > > > > Hmm, that's really unfortunate. That makes me think this layer is not > > actually intended to be a centralized location for ARM related things, > and > > I'm probably not going to try and consolidate things from other layers > here > > anymore. Not having a master branch that can be used with the master > branch > > of OE-core really eliminates the possibility for me to use a BSP layer > like > > e.g. meta-rockchip for upstream development and testing if that BSP layer > > depends on meta-arm and meta-arm is perpetually stuck on the last > release. > > I'm in no way saying that meta-arm master should not work with > upstream master. I'm saying that we want to keep compatability with > the previous release so that we can cut stable releases for customers. > I have been very supportive about meta-arm as the central location for ARM pieces, and still believe it's the right thing to do. But like Joshua, I find this discussion a bit disappointing. A layer is a "social contract" between the community behind this layer, and the rest of the OE/YP community. Refusing proper and meaningful community patches in master because it doesn't some 'internal' needs doesn't feel right. > We have a requirement to release BSP SW based on YP. Just like I > would expect other vendors/people who want to use meta-arm. So, there > are a few ways we can approach this issue. > > 1. Merge patches onto dunfell branch > 2. A development branch based on dunfell > 3. Use master meta-arm-bsp and dunfell branches for meta-arm and > meta-arm-toolchain > 4. Keep master compatible with dunfell > I think the mistake we made (I am saying we, since I was involved in that discussion) is to have a single tree that includes both the 'community' content that the ARM ecosystem wants to depend on and the specific ARM "products" that are needed by very few specific people (e.g. your BSP product). I think #3 is the most sensible choice, e.g. you need to split meta-arm into 'community' pieces (I think that would correspond to meta-arm and meta-arm-toolchain layers) and your product pieces. When we build your product with OE, you would reply on the 'community' meta-arm, and if any hack or custom integration is needed, then you can do that in your product tree. You might even overlay things for some time there, it's fine for a product layer. Of course you will need to worry about doing the 'proper' fix into the community meta-arm at some point. But if you don't commit to maintaining a layer for the ARM community, the risk is that everyone will start forking meta-arm recipes, which is not what we want. > One is simple, we actually do our development on the dunfell branch. > However, this breaks it from being a stable branch. So, this is a > non-starter > Two is still simple, we do all of our internal development on a second > dunfell branch ("dunfell-dev") and make any releases we have off of > that. The problem with this is the integration and testing. If there > are multiple branches to test, can we expect developers to test every > combination? Also, there might be a need for different versions of > the patches depending on how much master and dunfell-dev diverge. > That is an alternate variant of splitting the trees.. doing your 'product' in a product branch, and keep the expected branches (dunfell, master, ...) as community branches. It really depends if meta-arm-bsp is really expected to be a community thing ever, or if it's your product only. In which case it might be more appropriate to split it apart. > > Three is more complex. Since only meta-arm-bsp needs releases, we can > simply let that one float and fix the others on the stable branches. > The problem with this is that we are currently needing to add recipes > for things into meta-arm that others might need (like SCP, EDK2, etc). > So, this will work once we have more stability in meta-arm, but right > now we are adding too much stuff to make it viable for the next > release. > > Four is simple, we keep compatability with dunfell and make the > releases off of that. The potential hazard with this is if something > in YP master requires that compatability to be broken. > I presonally would like #4, because it is simple. However, if this > will prevent others from using meta-arm, then let's have a discussion > on it. Perhaps I am not understanding something fundamental. > But the whole discussion started because you said you needed to keep master compatible with dunfell. Even though as you said, it might fail eventually. > Thanks, > Jon > > > > > > > > > > > Thanks, > > > Jon > > > > > > > > > > > > > > > Bertrand > > > > > > > > > > > > > > > > > > Bertrand > > > > > > > > > > > > > > > -- > > > > > > > > 2.17.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > [-- Attachment #2: Type: text/html, Size: 11250 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-06-02 6:10 ` Nicolas Dechesne @ 2020-06-05 23:44 ` Denys Dmytriyenko 2020-06-08 16:03 ` Jon Mason 0 siblings, 1 reply; 17+ messages in thread From: Denys Dmytriyenko @ 2020-06-05 23:44 UTC (permalink / raw) To: Nicolas Dechesne; +Cc: Jon Mason, Joshua Watt, Bertrand Marquis, meta-arm On Tue, Jun 02, 2020 at 08:10:04AM +0200, Nicolas Dechesne wrote: > hey Jon, > > > > Hmm, that's really unfortunate. That makes me think this layer is not > > > actually intended to be a centralized location for ARM related things, > > and > > > I'm probably not going to try and consolidate things from other layers > > here > > > anymore. Not having a master branch that can be used with the master > > branch > > > of OE-core really eliminates the possibility for me to use a BSP layer > > like > > > e.g. meta-rockchip for upstream development and testing if that BSP layer > > > depends on meta-arm and meta-arm is perpetually stuck on the last > > release. > > > > I'm in no way saying that meta-arm master should not work with > > upstream master. I'm saying that we want to keep compatability with > > the previous release so that we can cut stable releases for customers. > > > > I have been very supportive about meta-arm as the central location for ARM > pieces, and still believe it's the right thing to do. But like Joshua, I > find this discussion a bit disappointing. A layer is a "social contract" > between the community behind this layer, and the rest of the OE/YP > community. Refusing proper and meaningful community patches in master > because it doesn't some 'internal' needs doesn't feel right. > > > > We have a requirement to release BSP SW based on YP. Just like I > > would expect other vendors/people who want to use meta-arm. So, there > > are a few ways we can approach this issue. > > > > 1. Merge patches onto dunfell branch > > 2. A development branch based on dunfell > > 3. Use master meta-arm-bsp and dunfell branches for meta-arm and > > meta-arm-toolchain > > 4. Keep master compatible with dunfell > > > > I think the mistake we made (I am saying we, since I was involved in that > discussion) is to have a single tree that includes both the 'community' > content that the ARM ecosystem wants to depend on and the specific ARM > "products" that are needed by very few specific people (e.g. your BSP > product). > > I think #3 is the most sensible choice, e.g. you need to split meta-arm > into 'community' pieces (I think that would correspond to meta-arm and > meta-arm-toolchain layers) and your product pieces. When we build your > product with OE, you would reply on the 'community' meta-arm, and if any > hack or custom integration is needed, then you can do that in your product > tree. You might even overlay things for some time there, it's fine for a > product layer. Of course you will need to worry about doing the 'proper' > fix into the community meta-arm at some point. But if you don't commit to > maintaining a layer for the ARM community, the risk is that everyone will > start forking meta-arm recipes, which is not what we want. After giving it some thought for couple days, I tend to agree with Nico that it may be better off to split out meta-arm-bsp away from the rest of meta-arm repository to allow it to make releases against any YP versions and branches. > > One is simple, we actually do our development on the dunfell branch. > > However, this breaks it from being a stable branch. So, this is a > > non-starter > > > > Two is still simple, we do all of our internal development on a second > > dunfell branch ("dunfell-dev") and make any releases we have off of > > that. The problem with this is the integration and testing. If there > > are multiple branches to test, can we expect developers to test every > > combination? Also, there might be a need for different versions of > > the patches depending on how much master and dunfell-dev diverge. > > > > That is an alternate variant of splitting the trees.. doing your 'product' > in a product branch, and keep the expected branches (dunfell, master, ...) > as community branches. It really depends if meta-arm-bsp is really expected > to be a community thing ever, or if it's your product only. In which case > it might be more appropriate to split it apart. > > > > > > Three is more complex. Since only meta-arm-bsp needs releases, we can > > simply let that one float and fix the others on the stable branches. > > The problem with this is that we are currently needing to add recipes > > for things into meta-arm that others might need (like SCP, EDK2, etc). > > So, this will work once we have more stability in meta-arm, but right > > now we are adding too much stuff to make it viable for the next > > release. > > > > Four is simple, we keep compatability with dunfell and make the > > releases off of that. The potential hazard with this is if something > > in YP master requires that compatability to be broken. > > > > I presonally would like #4, because it is simple. However, if this > > will prevent others from using meta-arm, then let's have a discussion > > on it. Perhaps I am not understanding something fundamental. > > > > But the whole discussion started because you said you needed to keep master > compatible with dunfell. Even though as you said, it might fail eventually. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-06-05 23:44 ` Denys Dmytriyenko @ 2020-06-08 16:03 ` Jon Mason 0 siblings, 0 replies; 17+ messages in thread From: Jon Mason @ 2020-06-08 16:03 UTC (permalink / raw) To: Denys Dmytriyenko Cc: Nicolas Dechesne, Joshua Watt, Bertrand Marquis, meta-arm On Fri, Jun 05, 2020 at 07:44:54PM -0400, Denys Dmytriyenko wrote: > On Tue, Jun 02, 2020 at 08:10:04AM +0200, Nicolas Dechesne wrote: > > hey Jon, > > > > > > Hmm, that's really unfortunate. That makes me think this layer is not > > > > actually intended to be a centralized location for ARM related things, > > > and > > > > I'm probably not going to try and consolidate things from other layers > > > here > > > > anymore. Not having a master branch that can be used with the master > > > branch > > > > of OE-core really eliminates the possibility for me to use a BSP layer > > > like > > > > e.g. meta-rockchip for upstream development and testing if that BSP layer > > > > depends on meta-arm and meta-arm is perpetually stuck on the last > > > release. > > > > > > I'm in no way saying that meta-arm master should not work with > > > upstream master. I'm saying that we want to keep compatability with > > > the previous release so that we can cut stable releases for customers. > > > > > > > I have been very supportive about meta-arm as the central location for ARM > > pieces, and still believe it's the right thing to do. But like Joshua, I > > find this discussion a bit disappointing. A layer is a "social contract" > > between the community behind this layer, and the rest of the OE/YP > > community. Refusing proper and meaningful community patches in master > > because it doesn't some 'internal' needs doesn't feel right. > > > > > > > We have a requirement to release BSP SW based on YP. Just like I > > > would expect other vendors/people who want to use meta-arm. So, there > > > are a few ways we can approach this issue. > > > > > > 1. Merge patches onto dunfell branch > > > 2. A development branch based on dunfell > > > 3. Use master meta-arm-bsp and dunfell branches for meta-arm and > > > meta-arm-toolchain > > > 4. Keep master compatible with dunfell > > > > > > > I think the mistake we made (I am saying we, since I was involved in that > > discussion) is to have a single tree that includes both the 'community' > > content that the ARM ecosystem wants to depend on and the specific ARM > > "products" that are needed by very few specific people (e.g. your BSP > > product). > > > > I think #3 is the most sensible choice, e.g. you need to split meta-arm > > into 'community' pieces (I think that would correspond to meta-arm and > > meta-arm-toolchain layers) and your product pieces. When we build your > > product with OE, you would reply on the 'community' meta-arm, and if any > > hack or custom integration is needed, then you can do that in your product > > tree. You might even overlay things for some time there, it's fine for a > > product layer. Of course you will need to worry about doing the 'proper' > > fix into the community meta-arm at some point. But if you don't commit to > > maintaining a layer for the ARM community, the risk is that everyone will > > start forking meta-arm recipes, which is not what we want. > > After giving it some thought for couple days, I tend to agree with Nico that > it may be better off to split out meta-arm-bsp away from the rest of meta-arm > repository to allow it to make releases against any YP versions and branches. > > > > > One is simple, we actually do our development on the dunfell branch. > > > However, this breaks it from being a stable branch. So, this is a > > > non-starter > > > > > > > Two is still simple, we do all of our internal development on a second > > > dunfell branch ("dunfell-dev") and make any releases we have off of > > > that. The problem with this is the integration and testing. If there > > > are multiple branches to test, can we expect developers to test every > > > combination? Also, there might be a need for different versions of > > > the patches depending on how much master and dunfell-dev diverge. > > > > > > > That is an alternate variant of splitting the trees.. doing your 'product' > > in a product branch, and keep the expected branches (dunfell, master, ...) > > as community branches. It really depends if meta-arm-bsp is really expected > > to be a community thing ever, or if it's your product only. In which case > > it might be more appropriate to split it apart. > > > > > > > > > > Three is more complex. Since only meta-arm-bsp needs releases, we can > > > simply let that one float and fix the others on the stable branches. > > > The problem with this is that we are currently needing to add recipes > > > for things into meta-arm that others might need (like SCP, EDK2, etc). > > > So, this will work once we have more stability in meta-arm, but right > > > now we are adding too much stuff to make it viable for the next > > > release. > > > > > > Four is simple, we keep compatability with dunfell and make the > > > releases off of that. The potential hazard with this is if something > > > in YP master requires that compatability to be broken. > > > > > > > I presonally would like #4, because it is simple. However, if this > > > will prevent others from using meta-arm, then let's have a discussion > > > on it. Perhaps I am not understanding something fundamental. > > > > > > > But the whole discussion started because you said you needed to keep master > > compatible with dunfell. Even though as you said, it might fail eventually. I would appreciate it if everyone could take a look at the email I sent out on Friday, "Proposal for the branching policy of meta-arm". https://lists.yoctoproject.org/g/meta-arm/message/557 Creating and maintaining an active community around meta-arm is our #1 priority. We had extensive discussions internally, and came up with this proposal. I believe it addresses the issues everyone had, and should prevent this kind of thing from happening in the future. This is a proposal and not a dictate. So, please post comments and questions to that thread. Thanks, Jon ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-06-01 22:56 ` Jon Mason 2020-06-02 6:10 ` Nicolas Dechesne @ 2020-06-02 12:51 ` Richard Purdie 2020-06-02 13:24 ` Ross Burton 2 siblings, 0 replies; 17+ messages in thread From: Richard Purdie @ 2020-06-02 12:51 UTC (permalink / raw) To: Jon Mason, Joshua Watt; +Cc: Bertrand Marquis, meta-arm On Mon, 2020-06-01 at 18:56 -0400, Jon Mason wrote: > I'm in no way saying that meta-arm master should not work with > upstream master. I'm saying that we want to keep compatability with > the previous release so that we can cut stable releases for > customers. > > We have a requirement to release BSP SW based on YP. Just like I > would expect other vendors/people who want to use meta-arm. So, > there > are a few ways we can approach this issue. > > 1. Merge patches onto dunfell branch > 2. A development branch based on dunfell > 3. Use master meta-arm-bsp and dunfell branches for meta-arm and > meta-arm-toolchain > 4. Keep master compatible with dunfell > > One is simple, we actually do our development on the dunfell branch. > However, this breaks it from being a stable branch. So, this is a > non-starter > > Two is still simple, we do all of our internal development on a > second > dunfell branch ("dunfell-dev") and make any releases we have off of > that. The problem with this is the integration and testing. If > there > are multiple branches to test, can we expect developers to test every > combination? Also, there might be a need for different versions of > the patches depending on how much master and dunfell-dev diverge. > > Three is more complex. Since only meta-arm-bsp needs releases, we > can > simply let that one float and fix the others on the stable branches. > The problem with this is that we are currently needing to add recipes > for things into meta-arm that others might need (like SCP, EDK2, > etc). > So, this will work once we have more stability in meta-arm, but right > now we are adding too much stuff to make it viable for the next > release. > > Four is simple, we keep compatability with dunfell and make the > releases off of that. The potential hazard with this is if something > in YP master requires that compatability to be broken. > > I presonally would like #4, because it is simple. However, if this > will prevent others from using meta-arm, then let's have a discussion > on it. Perhaps I am not understanding something fundamental. I can see why you want to do this but it isn't how people expect to work with layers so it may need some further thought... Cheers, Richard ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-06-01 22:56 ` Jon Mason 2020-06-02 6:10 ` Nicolas Dechesne 2020-06-02 12:51 ` Richard Purdie @ 2020-06-02 13:24 ` Ross Burton 2 siblings, 0 replies; 17+ messages in thread From: Ross Burton @ 2020-06-02 13:24 UTC (permalink / raw) To: Jon Mason; +Cc: Joshua Watt, Bertrand Marquis, meta-arm On Mon, 1 Jun 2020 at 23:56, Jon Mason <jdmason@kudzu.us> wrote: > We have a requirement to release BSP SW based on YP. Just like I > would expect other vendors/people who want to use meta-arm. So, there > are a few ways we can approach this issue. > > 1. Merge patches onto dunfell branch > 2. A development branch based on dunfell > 3. Use master meta-arm-bsp and dunfell branches for meta-arm and > meta-arm-toolchain > 4. Keep master compatible with dunfell > > One is simple, we actually do our development on the dunfell branch. > However, this breaks it from being a stable branch. So, this is a > non-starter Especially as meta-arm is a new BSP that is rapidly growing, I don't think we should rule out #1. To expand: meta-arm master is compatible with oe-core master. meta-arm dunfell branch is compatible with dunfell. Because the BSP is in active development, and because we want to support the users as much as possible, new versions of some recipes can be backported from master into dunfell. Probably not every change, and the impact to testing isn't negligible, but in the greater scheme customers being able to track Dunfell but also get the latest software is probably the right balance. Prior art includes other BSPs such as meta-intel. The master branch is tested against master, but release branches also get selected upgrades such as new kernels or other components (media components, etc). Testing, now, that's another discussion entirely... Ross ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-06-01 21:55 ` Joshua Watt 2020-06-01 22:56 ` Jon Mason @ 2020-06-02 13:20 ` Joshua Watt 1 sibling, 0 replies; 17+ messages in thread From: Joshua Watt @ 2020-06-02 13:20 UTC (permalink / raw) To: Jon Mason; +Cc: Bertrand Marquis, meta-arm On 6/1/20 4:55 PM, Joshua Watt wrote: > > On 6/1/20 4:31 PM, Jon Mason wrote: >> On Sat, May 30, 2020 at 01:39:49PM -0500, Joshua Watt wrote: >>> On Fri, May 29, 2020, 10:37 AM Bertrand Marquis >>> <Bertrand.Marquis@arm.com> >>> wrote: >>> >>>> >>>>> On 29 May 2020, at 16:32, Joshua Watt <JPEWhacker@gmail.com> wrote: >>>>> >>>>> >>>>> On 5/29/20 10:21 AM, Bertrand Marquis wrote: >>>>>>> On 29 May 2020, at 16:14, Joshua Watt via lists.yoctoproject.org >>>> <JPEWhacker=gmail.com@lists.yoctoproject.org> wrote: >>>>>>> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> >>>>>>> --- >>>>>>> meta-arm/conf/layer.conf | 3 +-- >>>>>>> 1 file changed, 1 insertion(+), 2 deletions(-) >>>>>>> >>>>>>> diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf >>>>>>> index d96e9f1..1c241d4 100644 >>>>>>> --- a/meta-arm/conf/layer.conf >>>>>>> +++ b/meta-arm/conf/layer.conf >>>>>>> @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" >>>>>>> >>>>>>> LAYERDEPENDS_meta-arm = " \ >>>>>>> core \ >>>>>>> - meta-python \ >>>>>>> " >>>>>>> -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" >>>>>>> +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" >>>>>> Could you explain why you want to remove dunfell compatibility ? >>>>> dunfell doesn't have the required python recipes in oe-core, so it >>>>> isn't >>>> compatible with it anymore. >>>> >>>> Nothing has been tested or is compatible with gatesgarth right now >>>> so this >>>> change will really have a breaking impact. >>>> >>> Right, you certainly wouldn't want to backport it to the dunfell >>> branch; >>> this is just for master where the next release would be gatesgarth >>> anyway. >>> >>> Also, with the qemu support I added, I think we have reasonable testing >>> coverage on meta-arm, and in particular enough to have high >>> confidence in >>> this change. >>> >>> Finally, FWIW, upstream oe-core and meta-python have already made these >>> changes on their master branches, so it seems like we wouldn't want a >>> useless dependency on meta-python in meta-arm, *especially* if the >>> idea is >>> to get other bsp layers to depend on meta-arm to consolidate things >>> like >>> TF-A and optee. >> We currently have a requirement for dunfell compatability on the >> meta-arm master branch for Arm's BSP software releases (which will >> be YP based going forward). To make a stable release for our >> customers, we need to draw a line between stablity of our dependent >> layers and the latest code in the meta-arm layer. This especially >> relates to the BSPs Arm will be adding to meta-arm-bsp in this >> release. >> >> We do not have to keep dunfell support in master after the release of >> gatesgarth, but we will need it until then. So, please stash this >> patch until October (which will be here sooner than you think). > > Hmm, that's really unfortunate. That makes me think this layer is not > actually intended to be a centralized location for ARM related things, > and I'm probably not going to try and consolidate things from other > layers here anymore. Not having a master branch that can be used with > the master branch of OE-core really eliminates the possibility for me > to use a BSP layer like e.g. meta-rockchip for upstream development > and testing if that BSP layer depends on meta-arm and meta-arm is > perpetually stuck on the last release. Sorry for going a little overboard here, I was a bit upset because one of my main goals had been to remove the meta-python dependency and I overreacted. I do still plan on contributing to meta-arm :) One thing that might help is to define what the testing criteria for the community focused layers is. As an example: We have pretty good coverage with the recipes in meta-arm on qemu (we could even tie the op-tee tests into ptest). Is testing meta-arm changes on qemu sufficient to get them accepted to master? > > >> >> Thanks, >> Jon >> >> >>> >>>> Bertrand >>>> >>>>> >>>>>> Bertrand >>>>>> >>>>>>> -- >>>>>>> 2.17.1 >>>>>>> >>>>>>> >>>> >>> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [meta-arm][PATCH] meta-arm: Remove meta-python dependency @ 2020-05-29 15:18 Joshua Watt 2020-05-29 15:22 ` Bertrand Marquis 0 siblings, 1 reply; 17+ messages in thread From: Joshua Watt @ 2020-05-29 15:18 UTC (permalink / raw) To: meta-arm; +Cc: Joshua Watt Removes the dependency on meta-arm, now that the required python modules recipes are in oe-core. Ensure that a sufficiently new enough version of oe-core is present for the recipes to be provided. Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> --- meta-arm/conf/layer.conf | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf index d96e9f1..1c241d4 100644 --- a/meta-arm/conf/layer.conf +++ b/meta-arm/conf/layer.conf @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" LAYERDEPENDS_meta-arm = " \ core \ - meta-python \ " -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" -- 2.17.1 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-05-29 15:18 Joshua Watt @ 2020-05-29 15:22 ` Bertrand Marquis 2020-05-29 15:31 ` Joshua Watt 0 siblings, 1 reply; 17+ messages in thread From: Bertrand Marquis @ 2020-05-29 15:22 UTC (permalink / raw) To: Joshua Watt; +Cc: meta-arm, nd > On 29 May 2020, at 16:18, Joshua Watt via lists.yoctoproject.org <JPEWhacker=gmail.com@lists.yoctoproject.org> wrote: > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> > --- > meta-arm/conf/layer.conf | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf > index d96e9f1..1c241d4 100644 > --- a/meta-arm/conf/layer.conf > +++ b/meta-arm/conf/layer.conf > @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" > > LAYERDEPENDS_meta-arm = " \ > core \ > - meta-python \ > " > -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" > +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" Same here, why removing dunfell ? Bertrand > -- > 2.17.1 > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency 2020-05-29 15:22 ` Bertrand Marquis @ 2020-05-29 15:31 ` Joshua Watt 0 siblings, 0 replies; 17+ messages in thread From: Joshua Watt @ 2020-05-29 15:31 UTC (permalink / raw) To: Bertrand Marquis; +Cc: meta-arm, nd On 5/29/20 10:22 AM, Bertrand Marquis wrote: > >> On 29 May 2020, at 16:18, Joshua Watt via lists.yoctoproject.org <JPEWhacker=gmail.com@lists.yoctoproject.org> wrote: >> >> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> >> --- >> meta-arm/conf/layer.conf | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf >> index d96e9f1..1c241d4 100644 >> --- a/meta-arm/conf/layer.conf >> +++ b/meta-arm/conf/layer.conf >> @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6" >> >> LAYERDEPENDS_meta-arm = " \ >> core \ >> - meta-python \ >> " >> -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell" >> +LAYERSERIES_COMPAT_meta-arm = "gatesgarth" > Same here, why removing dunfell ? Sorry I accidentally sent the same patch twice. > > Bertrand > >> -- >> 2.17.1 >> >> ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2020-06-08 16:03 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-29 15:14 [meta-arm][PATCH] meta-arm: Remove meta-python dependency Joshua Watt 2020-05-29 15:21 ` Bertrand Marquis 2020-05-29 15:32 ` Joshua Watt 2020-05-29 15:37 ` Bertrand Marquis 2020-05-30 18:39 ` Joshua Watt 2020-06-01 21:31 ` Jon Mason 2020-06-01 21:55 ` Joshua Watt 2020-06-01 22:56 ` Jon Mason 2020-06-02 6:10 ` Nicolas Dechesne 2020-06-05 23:44 ` Denys Dmytriyenko 2020-06-08 16:03 ` Jon Mason 2020-06-02 12:51 ` Richard Purdie 2020-06-02 13:24 ` Ross Burton 2020-06-02 13:20 ` Joshua Watt 2020-05-29 15:18 Joshua Watt 2020-05-29 15:22 ` Bertrand Marquis 2020-05-29 15:31 ` Joshua Watt
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.