| Message ID | 20230412184242.29743-5-afd@ti.com |
|---|---|
| State | Superseded |
| Delegated to: | Ryan Eatmon |
| Headers | show |
| Series | [meta-ti,master/kirkstone,v2,1/6] ti-sgx-ddk-um: Remove RDEPENDS on libdrm-omap | expand |
On Wed, Apr 12, 2023 at 01:42:41PM -0500, Andrew Davis via lists.yoctoproject.org wrote: > Neither of recipes nor their ABI is all that stable. OpenGL might be > slightly more stable, but that is not what these provide anymore. > Remove these. This is not what you think it is... :) Actually, Rogue recipes should be added to the list. This is specific to signatures/shared state. The ABI in this case is libgles and libegl (which are stable) and tells bitbake to avoid rebuilding generic apps depending on these packages between platfoms in the same architecture. > Signed-off-by: Andrew Davis <afd@ti.com> > --- > meta-ti-bsp/conf/layer.conf | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/meta-ti-bsp/conf/layer.conf b/meta-ti-bsp/conf/layer.conf > index 39e7f9eb..31eb9db8 100644 > --- a/meta-ti-bsp/conf/layer.conf > +++ b/meta-ti-bsp/conf/layer.conf > @@ -18,9 +18,4 @@ LAYERDEPENDS_meta-ti-bsp = " \ > meta-arm \ > " > > -SIGGEN_EXCLUDERECIPES_ABISAFE += " \ > - ti-sgx-ddk-km \ > - ti-sgx-ddk-um \ > -" > - > HOSTTOOLS_NONFATAL += "truncate xxd comm" > -- > 2.39.2
On 4/12/23 3:43 PM, Denys Dmytriyenko wrote: > On Wed, Apr 12, 2023 at 01:42:41PM -0500, Andrew Davis via lists.yoctoproject.org wrote: >> Neither of recipes nor their ABI is all that stable. OpenGL might be >> slightly more stable, but that is not what these provide anymore. >> Remove these. > > This is not what you think it is... :) Actually, Rogue recipes should be added > to the list. > > This is specific to signatures/shared state. The ABI in this case is libgles > and libegl (which are stable) and tells bitbake to avoid rebuilding generic > apps depending on these packages between platfoms in the same architecture. > These do not provide those API anymore, Mesa does. And nothing should depend on the KM package other than the UM libs. Andrew > >> Signed-off-by: Andrew Davis <afd@ti.com> >> --- >> meta-ti-bsp/conf/layer.conf | 5 ----- >> 1 file changed, 5 deletions(-) >> >> diff --git a/meta-ti-bsp/conf/layer.conf b/meta-ti-bsp/conf/layer.conf >> index 39e7f9eb..31eb9db8 100644 >> --- a/meta-ti-bsp/conf/layer.conf >> +++ b/meta-ti-bsp/conf/layer.conf >> @@ -18,9 +18,4 @@ LAYERDEPENDS_meta-ti-bsp = " \ >> meta-arm \ >> " >> >> -SIGGEN_EXCLUDERECIPES_ABISAFE += " \ >> - ti-sgx-ddk-km \ >> - ti-sgx-ddk-um \ >> -" >> - >> HOSTTOOLS_NONFATAL += "truncate xxd comm" >> -- >> 2.39.2
On Wed, Apr 12, 2023 at 04:08:50PM -0500, Andrew Davis wrote: > On 4/12/23 3:43 PM, Denys Dmytriyenko wrote: > >On Wed, Apr 12, 2023 at 01:42:41PM -0500, Andrew Davis via lists.yoctoproject.org wrote: > >>Neither of recipes nor their ABI is all that stable. OpenGL might be > >>slightly more stable, but that is not what these provide anymore. > >>Remove these. > > > >This is not what you think it is... :) Actually, Rogue recipes should be added > >to the list. > > > >This is specific to signatures/shared state. The ABI in this case is libgles > >and libegl (which are stable) and tells bitbake to avoid rebuilding generic > >apps depending on these packages between platfoms in the same architecture. > > > > These do not provide those API anymore, Mesa does. And nothing should depend > on the KM package other than the UM libs. Still doesn't matter - if you have Mesa depend on these, you still need them listed in here to avoid rebuilding Mesa from one platform to another. And everything else downstream. > >>Signed-off-by: Andrew Davis <afd@ti.com> > >>--- > >> meta-ti-bsp/conf/layer.conf | 5 ----- > >> 1 file changed, 5 deletions(-) > >> > >>diff --git a/meta-ti-bsp/conf/layer.conf b/meta-ti-bsp/conf/layer.conf > >>index 39e7f9eb..31eb9db8 100644 > >>--- a/meta-ti-bsp/conf/layer.conf > >>+++ b/meta-ti-bsp/conf/layer.conf > >>@@ -18,9 +18,4 @@ LAYERDEPENDS_meta-ti-bsp = " \ > >> meta-arm \ > >> " > >>-SIGGEN_EXCLUDERECIPES_ABISAFE += " \ > >>- ti-sgx-ddk-km \ > >>- ti-sgx-ddk-um \ > >>-" > >>- > >> HOSTTOOLS_NONFATAL += "truncate xxd comm" > >>-- > >>2.39.2
On 4/12/23 4:25 PM, Denys Dmytriyenko wrote: > On Wed, Apr 12, 2023 at 04:08:50PM -0500, Andrew Davis wrote: >> On 4/12/23 3:43 PM, Denys Dmytriyenko wrote: >>> On Wed, Apr 12, 2023 at 01:42:41PM -0500, Andrew Davis via lists.yoctoproject.org wrote: >>>> Neither of recipes nor their ABI is all that stable. OpenGL might be >>>> slightly more stable, but that is not what these provide anymore. >>>> Remove these. >>> >>> This is not what you think it is... :) Actually, Rogue recipes should be added >>> to the list. >>> >>> This is specific to signatures/shared state. The ABI in this case is libgles >>> and libegl (which are stable) and tells bitbake to avoid rebuilding generic >>> apps depending on these packages between platfoms in the same architecture. >>> >> >> These do not provide those API anymore, Mesa does. And nothing should depend >> on the KM package other than the UM libs. > > Still doesn't matter - if you have Mesa depend on these, you still need them > listed in here to avoid rebuilding Mesa from one platform to another. And > everything else downstream. > We *want* Mesa to be rebuilt if these change, these do not provide a stable ABI anymore, it can and does change, sometimes between platforms (SGX KM -> UM is based on plat). Andrew > >>>> Signed-off-by: Andrew Davis <afd@ti.com> >>>> --- >>>> meta-ti-bsp/conf/layer.conf | 5 ----- >>>> 1 file changed, 5 deletions(-) >>>> >>>> diff --git a/meta-ti-bsp/conf/layer.conf b/meta-ti-bsp/conf/layer.conf >>>> index 39e7f9eb..31eb9db8 100644 >>>> --- a/meta-ti-bsp/conf/layer.conf >>>> +++ b/meta-ti-bsp/conf/layer.conf >>>> @@ -18,9 +18,4 @@ LAYERDEPENDS_meta-ti-bsp = " \ >>>> meta-arm \ >>>> " >>>> -SIGGEN_EXCLUDERECIPES_ABISAFE += " \ >>>> - ti-sgx-ddk-km \ >>>> - ti-sgx-ddk-um \ >>>> -" >>>> - >>>> HOSTTOOLS_NONFATAL += "truncate xxd comm" >>>> -- >>>> 2.39.2
On Wed, Apr 12, 2023 at 04:28:45PM -0500, Andrew Davis wrote: > On 4/12/23 4:25 PM, Denys Dmytriyenko wrote: > >On Wed, Apr 12, 2023 at 04:08:50PM -0500, Andrew Davis wrote: > >>On 4/12/23 3:43 PM, Denys Dmytriyenko wrote: > >>>On Wed, Apr 12, 2023 at 01:42:41PM -0500, Andrew Davis via lists.yoctoproject.org wrote: > >>>>Neither of recipes nor their ABI is all that stable. OpenGL might be > >>>>slightly more stable, but that is not what these provide anymore. > >>>>Remove these. > >>> > >>>This is not what you think it is... :) Actually, Rogue recipes should be added > >>>to the list. > >>> > >>>This is specific to signatures/shared state. The ABI in this case is libgles > >>>and libegl (which are stable) and tells bitbake to avoid rebuilding generic > >>>apps depending on these packages between platfoms in the same architecture. > >>> > >> > >>These do not provide those API anymore, Mesa does. And nothing should depend > >>on the KM package other than the UM libs. > > > >Still doesn't matter - if you have Mesa depend on these, you still need them > >listed in here to avoid rebuilding Mesa from one platform to another. And > >everything else downstream. > > > > We *want* Mesa to be rebuilt if these change, these do not provide a stable ABI > anymore, it can and does change, sometimes between platforms (SGX KM -> UM is > based on plat). The name of the variable may be confusing. It's not about rebuilding Mesa once you make changes to the KM/UM pieces - that will happen automatically if the dependencies are tracked properly. This variable is about re-use of the dependant generic packages. The issue it is trying to solve is when you have machine-specific packages early in the dependecy tree, everything down the dependency tree that depends on these packages will be treated as machine-specific, even if they are generic. Since bitbake will try to play safe here, you have to tell it otherwise. Again, this is not about rebuilds of a dependent component between changes. This is about rebuilds of a dependent component between different machines (platforms) w/o making any changes. For example, Wayland, Weston and all Qt5 modules are generic and should be re-used from shared state across all our Aarch64 platforms, but that's not the case and they are being rebuilt for each and every platform again and again. I've done some experiments locally - back when SGX/Rogue UM libs provided libgles, libegl, libgbm (which API/ABI are supposed to be stable!), you certainly wanted to have them listed in this SIGGEN_EXCLUDERECIPES_ABISAFE list. Now, those ABIs have shifted to Mesa and we do mark that package as machine-specific (I had to add PACKAGE_ARCH = "${MACHINE_ARCH}" when redoing Reese's patches - see v8 changes section at [1]). With that in mind, this variable now has to list Mesa instead of individual UM packages - the patch is coming. [1] https://patchwork.yoctoproject.org/project/ti/patch/20230224101219.4130589-3-denis@denix.org/
On 4/14/23 3:54 PM, Denys Dmytriyenko wrote: > On Wed, Apr 12, 2023 at 04:28:45PM -0500, Andrew Davis wrote: >> On 4/12/23 4:25 PM, Denys Dmytriyenko wrote: >>> On Wed, Apr 12, 2023 at 04:08:50PM -0500, Andrew Davis wrote: >>>> On 4/12/23 3:43 PM, Denys Dmytriyenko wrote: >>>>> On Wed, Apr 12, 2023 at 01:42:41PM -0500, Andrew Davis via lists.yoctoproject.org wrote: >>>>>> Neither of recipes nor their ABI is all that stable. OpenGL might be >>>>>> slightly more stable, but that is not what these provide anymore. >>>>>> Remove these. >>>>> >>>>> This is not what you think it is... :) Actually, Rogue recipes should be added >>>>> to the list. >>>>> >>>>> This is specific to signatures/shared state. The ABI in this case is libgles >>>>> and libegl (which are stable) and tells bitbake to avoid rebuilding generic >>>>> apps depending on these packages between platfoms in the same architecture. >>>>> >>>> >>>> These do not provide those API anymore, Mesa does. And nothing should depend >>>> on the KM package other than the UM libs. >>> >>> Still doesn't matter - if you have Mesa depend on these, you still need them >>> listed in here to avoid rebuilding Mesa from one platform to another. And >>> everything else downstream. >>> >> >> We *want* Mesa to be rebuilt if these change, these do not provide a stable ABI >> anymore, it can and does change, sometimes between platforms (SGX KM -> UM is >> based on plat). > > The name of the variable may be confusing. It's not about rebuilding Mesa once > you make changes to the KM/UM pieces - that will happen automatically if the > dependencies are tracked properly. > > This variable is about re-use of the dependant generic packages. The issue it > is trying to solve is when you have machine-specific packages early in the > dependecy tree, everything down the dependency tree that depends on these > packages will be treated as machine-specific, even if they are generic. Since > bitbake will try to play safe here, you have to tell it otherwise. > > Again, this is not about rebuilds of a dependent component between changes. > This is about rebuilds of a dependent component between different machines > (platforms) w/o making any changes. > > For example, Wayland, Weston and all Qt5 modules are generic and should be > re-used from shared state across all our Aarch64 platforms, but that's not the > case and they are being rebuilt for each and every platform again and again. > > I've done some experiments locally - back when SGX/Rogue UM libs provided > libgles, libegl, libgbm (which API/ABI are supposed to be stable!), you > certainly wanted to have them listed in this SIGGEN_EXCLUDERECIPES_ABISAFE > list. Now, those ABIs have shifted to Mesa and we do mark that package as > machine-specific (I had to add PACKAGE_ARCH = "${MACHINE_ARCH}" when redoing > Reese's patches - see v8 changes section at [1]). With that in mind, this > variable now has to list Mesa instead of individual UM packages - the patch > is coming. > So then we are saying the same thing, the UM libs should not be listed here. This patch should go in then, and another one that adds Mesa to the list can go in after. If that is fine, then the first 5 patches in this series should be good to go. Andrew
On 4/14/2023 16:43, Andrew Davis wrote: > On 4/14/23 3:54 PM, Denys Dmytriyenko wrote: >> On Wed, Apr 12, 2023 at 04:28:45PM -0500, Andrew Davis wrote: >>> On 4/12/23 4:25 PM, Denys Dmytriyenko wrote: >>>> On Wed, Apr 12, 2023 at 04:08:50PM -0500, Andrew Davis wrote: >>>>> On 4/12/23 3:43 PM, Denys Dmytriyenko wrote: >>>>>> On Wed, Apr 12, 2023 at 01:42:41PM -0500, Andrew Davis via >>>>>> lists.yoctoproject.org wrote: >>>>>>> Neither of recipes nor their ABI is all that stable. OpenGL might be >>>>>>> slightly more stable, but that is not what these provide anymore. >>>>>>> Remove these. >>>>>> >>>>>> This is not what you think it is... :) Actually, Rogue recipes >>>>>> should be added >>>>>> to the list. >>>>>> >>>>>> This is specific to signatures/shared state. The ABI in this case >>>>>> is libgles >>>>>> and libegl (which are stable) and tells bitbake to avoid >>>>>> rebuilding generic >>>>>> apps depending on these packages between platfoms in the same >>>>>> architecture. >>>>>> >>>>> >>>>> These do not provide those API anymore, Mesa does. And nothing >>>>> should depend >>>>> on the KM package other than the UM libs. >>>> >>>> Still doesn't matter - if you have Mesa depend on these, you still >>>> need them >>>> listed in here to avoid rebuilding Mesa from one platform to >>>> another. And >>>> everything else downstream. >>>> >>> >>> We *want* Mesa to be rebuilt if these change, these do not provide a >>> stable ABI >>> anymore, it can and does change, sometimes between platforms (SGX KM >>> -> UM is >>> based on plat). >> >> The name of the variable may be confusing. It's not about rebuilding >> Mesa once >> you make changes to the KM/UM pieces - that will happen automatically >> if the >> dependencies are tracked properly. >> >> This variable is about re-use of the dependant generic packages. The >> issue it >> is trying to solve is when you have machine-specific packages early in >> the >> dependecy tree, everything down the dependency tree that depends on these >> packages will be treated as machine-specific, even if they are >> generic. Since >> bitbake will try to play safe here, you have to tell it otherwise. >> >> Again, this is not about rebuilds of a dependent component between >> changes. >> This is about rebuilds of a dependent component between different >> machines >> (platforms) w/o making any changes. >> >> For example, Wayland, Weston and all Qt5 modules are generic and >> should be >> re-used from shared state across all our Aarch64 platforms, but that's >> not the >> case and they are being rebuilt for each and every platform again and >> again. >> >> I've done some experiments locally - back when SGX/Rogue UM libs provided >> libgles, libegl, libgbm (which API/ABI are supposed to be stable!), you >> certainly wanted to have them listed in this >> SIGGEN_EXCLUDERECIPES_ABISAFE >> list. Now, those ABIs have shifted to Mesa and we do mark that package as >> machine-specific (I had to add PACKAGE_ARCH = "${MACHINE_ARCH}" when >> redoing >> Reese's patches - see v8 changes section at [1]). With that in mind, this >> variable now has to list Mesa instead of individual UM packages - the >> patch >> is coming. >> > > So then we are saying the same thing, the UM libs should not be listed > here. > This patch should go in then, and another one that adds Mesa to the list > can go in after. > > If that is fine, then the first 5 patches in this series should be good > to go. Denys, is there a follow on patch to this one that will correct your comments? Should I hold off on applying this patch until your patch is ready, or go ahead and apply it so that you have a basis for your patch? > Andrew
On Tue, Apr 18, 2023 at 09:09:04AM -0500, Ryan Eatmon wrote: > > > On 4/14/2023 16:43, Andrew Davis wrote: > >On 4/14/23 3:54 PM, Denys Dmytriyenko wrote: > >>On Wed, Apr 12, 2023 at 04:28:45PM -0500, Andrew Davis wrote: > >>>On 4/12/23 4:25 PM, Denys Dmytriyenko wrote: > >>>>On Wed, Apr 12, 2023 at 04:08:50PM -0500, Andrew Davis wrote: > >>>>>On 4/12/23 3:43 PM, Denys Dmytriyenko wrote: > >>>>>>On Wed, Apr 12, 2023 at 01:42:41PM -0500, Andrew Davis > >>>>>>via lists.yoctoproject.org wrote: > >>>>>>>Neither of recipes nor their ABI is all that stable. OpenGL might be > >>>>>>>slightly more stable, but that is not what these provide anymore. > >>>>>>>Remove these. > >>>>>> > >>>>>>This is not what you think it is... :) Actually, Rogue > >>>>>>recipes should be added > >>>>>>to the list. > >>>>>> > >>>>>>This is specific to signatures/shared state. The ABI in > >>>>>>this case is libgles > >>>>>>and libegl (which are stable) and tells bitbake to avoid > >>>>>>rebuilding generic > >>>>>>apps depending on these packages between platfoms in the > >>>>>>same architecture. > >>>>>> > >>>>> > >>>>>These do not provide those API anymore, Mesa does. And > >>>>>nothing should depend > >>>>>on the KM package other than the UM libs. > >>>> > >>>>Still doesn't matter - if you have Mesa depend on these, you > >>>>still need them > >>>>listed in here to avoid rebuilding Mesa from one platform to > >>>>another. And > >>>>everything else downstream. > >>>> > >>> > >>>We *want* Mesa to be rebuilt if these change, these do not > >>>provide a stable ABI > >>>anymore, it can and does change, sometimes between platforms > >>>(SGX KM -> UM is > >>>based on plat). > >> > >>The name of the variable may be confusing. It's not about > >>rebuilding Mesa once > >>you make changes to the KM/UM pieces - that will happen > >>automatically if the > >>dependencies are tracked properly. > >> > >>This variable is about re-use of the dependant generic packages. > >>The issue it > >>is trying to solve is when you have machine-specific packages > >>early in the > >>dependecy tree, everything down the dependency tree that depends on these > >>packages will be treated as machine-specific, even if they are > >>generic. Since > >>bitbake will try to play safe here, you have to tell it otherwise. > >> > >>Again, this is not about rebuilds of a dependent component > >>between changes. > >>This is about rebuilds of a dependent component between > >>different machines > >>(platforms) w/o making any changes. > >> > >>For example, Wayland, Weston and all Qt5 modules are generic and > >>should be > >>re-used from shared state across all our Aarch64 platforms, but > >>that's not the > >>case and they are being rebuilt for each and every platform > >>again and again. > >> > >>I've done some experiments locally - back when SGX/Rogue UM libs provided > >>libgles, libegl, libgbm (which API/ABI are supposed to be stable!), you > >>certainly wanted to have them listed in this > >>SIGGEN_EXCLUDERECIPES_ABISAFE > >>list. Now, those ABIs have shifted to Mesa and we do mark that package as > >>machine-specific (I had to add PACKAGE_ARCH = "${MACHINE_ARCH}" > >>when redoing > >>Reese's patches - see v8 changes section at [1]). With that in mind, this > >>variable now has to list Mesa instead of individual UM packages > >>- the patch > >>is coming. > >> > > > >So then we are saying the same thing, the UM libs should not be > >listed here. > >This patch should go in then, and another one that adds Mesa to the list > >can go in after. > > > >If that is fine, then the first 5 patches in this series should be > >good to go. > > Denys, is there a follow on patch to this one that will correct your > comments? Should I hold off on applying this patch until your patch > is ready, or go ahead and apply it so that you have a basis for your > patch? I can re-spin Andrew's patch with slight update in the commit message along with a new one to add Mesa.
On Tue, Apr 18, 2023 at 03:20:57PM -0400, Denys Dmytriyenko wrote: > On Tue, Apr 18, 2023 at 09:09:04AM -0500, Ryan Eatmon wrote: > > > > > > On 4/14/2023 16:43, Andrew Davis wrote: > > >On 4/14/23 3:54 PM, Denys Dmytriyenko wrote: > > >>On Wed, Apr 12, 2023 at 04:28:45PM -0500, Andrew Davis wrote: > > >>>On 4/12/23 4:25 PM, Denys Dmytriyenko wrote: > > >>>>On Wed, Apr 12, 2023 at 04:08:50PM -0500, Andrew Davis wrote: > > >>>>>On 4/12/23 3:43 PM, Denys Dmytriyenko wrote: > > >>>>>>On Wed, Apr 12, 2023 at 01:42:41PM -0500, Andrew Davis > > >>>>>>via lists.yoctoproject.org wrote: > > >>>>>>>Neither of recipes nor their ABI is all that stable. OpenGL might be > > >>>>>>>slightly more stable, but that is not what these provide anymore. > > >>>>>>>Remove these. > > >>>>>> > > >>>>>>This is not what you think it is... :) Actually, Rogue > > >>>>>>recipes should be added > > >>>>>>to the list. > > >>>>>> > > >>>>>>This is specific to signatures/shared state. The ABI in > > >>>>>>this case is libgles > > >>>>>>and libegl (which are stable) and tells bitbake to avoid > > >>>>>>rebuilding generic > > >>>>>>apps depending on these packages between platfoms in the > > >>>>>>same architecture. > > >>>>>> > > >>>>> > > >>>>>These do not provide those API anymore, Mesa does. And > > >>>>>nothing should depend > > >>>>>on the KM package other than the UM libs. > > >>>> > > >>>>Still doesn't matter - if you have Mesa depend on these, you > > >>>>still need them > > >>>>listed in here to avoid rebuilding Mesa from one platform to > > >>>>another. And > > >>>>everything else downstream. > > >>>> > > >>> > > >>>We *want* Mesa to be rebuilt if these change, these do not > > >>>provide a stable ABI > > >>>anymore, it can and does change, sometimes between platforms > > >>>(SGX KM -> UM is > > >>>based on plat). > > >> > > >>The name of the variable may be confusing. It's not about > > >>rebuilding Mesa once > > >>you make changes to the KM/UM pieces - that will happen > > >>automatically if the > > >>dependencies are tracked properly. > > >> > > >>This variable is about re-use of the dependant generic packages. > > >>The issue it > > >>is trying to solve is when you have machine-specific packages > > >>early in the > > >>dependecy tree, everything down the dependency tree that depends on these > > >>packages will be treated as machine-specific, even if they are > > >>generic. Since > > >>bitbake will try to play safe here, you have to tell it otherwise. > > >> > > >>Again, this is not about rebuilds of a dependent component > > >>between changes. > > >>This is about rebuilds of a dependent component between > > >>different machines > > >>(platforms) w/o making any changes. > > >> > > >>For example, Wayland, Weston and all Qt5 modules are generic and > > >>should be > > >>re-used from shared state across all our Aarch64 platforms, but > > >>that's not the > > >>case and they are being rebuilt for each and every platform > > >>again and again. > > >> > > >>I've done some experiments locally - back when SGX/Rogue UM libs provided > > >>libgles, libegl, libgbm (which API/ABI are supposed to be stable!), you > > >>certainly wanted to have them listed in this > > >>SIGGEN_EXCLUDERECIPES_ABISAFE > > >>list. Now, those ABIs have shifted to Mesa and we do mark that package as > > >>machine-specific (I had to add PACKAGE_ARCH = "${MACHINE_ARCH}" > > >>when redoing > > >>Reese's patches - see v8 changes section at [1]). With that in mind, this > > >>variable now has to list Mesa instead of individual UM packages > > >>- the patch > > >>is coming. > > >> > > > > > >So then we are saying the same thing, the UM libs should not be > > >listed here. > > >This patch should go in then, and another one that adds Mesa to the list > > >can go in after. > > > > > >If that is fine, then the first 5 patches in this series should be > > >good to go. > > > > Denys, is there a follow on patch to this one that will correct your > > comments? Should I hold off on applying this patch until your patch > > is ready, or go ahead and apply it so that you have a basis for your > > patch? > > I can re-spin Andrew's patch with slight update in the commit message along > with a new one to add Mesa. Ok, v3 of this patch and a follow up patch have been submitted.
diff --git a/meta-ti-bsp/conf/layer.conf b/meta-ti-bsp/conf/layer.conf index 39e7f9eb..31eb9db8 100644 --- a/meta-ti-bsp/conf/layer.conf +++ b/meta-ti-bsp/conf/layer.conf @@ -18,9 +18,4 @@ LAYERDEPENDS_meta-ti-bsp = " \ meta-arm \ " -SIGGEN_EXCLUDERECIPES_ABISAFE += " \ - ti-sgx-ddk-km \ - ti-sgx-ddk-um \ -" - HOSTTOOLS_NONFATAL += "truncate xxd comm"
Neither of recipes nor their ABI is all that stable. OpenGL might be slightly more stable, but that is not what these provide anymore. Remove these. Signed-off-by: Andrew Davis <afd@ti.com> --- meta-ti-bsp/conf/layer.conf | 5 ----- 1 file changed, 5 deletions(-)