[PATCH] cooker: Only warn on potentially incompatible layer

[PATCH] cooker: Only warn on potentially incompatible layer

[Damian Wrobel]

It frequently happens that the 3rd party layer is, in practise,
fully compatible with the older version of yocto. So, instead of
false positively reporting an error, it seems to be more
appropriately to just emit the warning.

Signed-off-by: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
---
 lib/bb/cookerdata.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/bb/cookerdata.py b/lib/bb/cookerdata.py
index 1c1e008c..ed678616 100644
--- a/lib/bb/cookerdata.py
+++ b/lib/bb/cookerdata.py
@@ -397,7 +397,7 @@ class CookerDataBuilder(object):
                     bb.fatal("Found duplicated BBFILE_COLLECTIONS '%s', check bblayers.conf or layer.conf to fix it." % c)
                 compat = set((data.getVar("LAYERSERIES_COMPAT_%s" % c) or "").split())
                 if compat and not (compat & layerseries):
-                    bb.fatal("Layer %s is not compatible with the core layer which only supports these series: %s (layer is compatible with %s)"
+                    bb.warn("Layer %s is not compatible with the core layer which only supports these series: %s (layer is compatible with %s)"
                               % (c, " ".join(layerseries), " ".join(compat)))
                 elif not compat and not data.getVar("BB_WORKERCONTEXT"):
                     bb.warn("Layer %s should set LAYERSERIES_COMPAT_%s in its conf/layer.conf file to list the core layer names it is compatible with." % (c, c))
-- 
2.31.1

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Richard Purdie]

On Fri, 2021-09-03 at 16:28 +0200, Damian Wrobel wrote:
> It frequently happens that the 3rd party layer is, in practise,
> fully compatible with the older version of yocto. So, instead of
> false positively reporting an error, it seems to be more
> appropriately to just emit the warning.
> 
> Signed-off-by: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
> ---
>  lib/bb/cookerdata.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/bb/cookerdata.py b/lib/bb/cookerdata.py
> index 1c1e008c..ed678616 100644
> --- a/lib/bb/cookerdata.py
> +++ b/lib/bb/cookerdata.py
> @@ -397,7 +397,7 @@ class CookerDataBuilder(object):
>                      bb.fatal("Found duplicated BBFILE_COLLECTIONS '%s', check bblayers.conf or layer.conf to fix it." % c)
>                  compat = set((data.getVar("LAYERSERIES_COMPAT_%s" % c) or "").split())
>                  if compat and not (compat & layerseries):
> -                    bb.fatal("Layer %s is not compatible with the core layer which only supports these series: %s (layer is compatible with %s)"
> +                    bb.warn("Layer %s is not compatible with the core layer which only supports these series: %s (layer is compatible with %s)"
>                                % (c, " ".join(layerseries), " ".join(compat)))
>                  elif not compat and not data.getVar("BB_WORKERCONTEXT"):
>                      bb.warn("Layer %s should set LAYERSERIES_COMPAT_%s in its conf/layer.conf file to list the core layer names it is compatible with." % (c, c))

This isn't something we should change.

If two things are not marked as being compatible with each other, we don't allow
them together and you have to make some effort to bypass it. It is possible, it
isn't easy and that is reasonable.

Cheers,

Richard

Re: [PATCH] cooker: Only warn on potentially incompatible layer

[Damian Wrobel]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

On Fri, Sep 3, 2021 at 07:07 PM, Richard Purdie wrote:

> 
> LAYERSERIES_COMPAT

The problem is that there is inconsistency for treating layers with and without LAYERSERIES_COMPAT.

If the layer without LAYERSERIES_COMPAT works perfectly - only a warning is emitted. Then
symmetrically the same should happen for a layer with LAYERSERIES_COMPAT - especially that
this check is not able to detect any real problems in this layer - it only blindly rejects a valid layer.

Additionally, this bb.fatal generates compatibility problem as we're able to consume 3rd party
layers which have LAYERSERIES_COMPAT in yocto morty (which doesn't use this compatibility check),
but the same layers are false positively rejected by yocto dunfell.

Having this merged would allow to limit maintenance burden on 3rd party layers.

--
Regards,
Damian

[-- Attachment #2: Type: text/html, Size: 929 bytes --]

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Richard Purdie]

On Fri, 2021-09-03 at 10:53 -0700, Damian Wrobel wrote:
> On Fri, Sep 3, 2021 at 07:07 PM, Richard Purdie wrote:
> > LAYERSERIES_COMPAT
> The problem is that there is inconsistency for treating layers with and
> without
> LAYERSERIES_COMPAT.
> 
> If the layer without LAYERSERIES_COMPAT works perfectly - only a warning is
> emitted.

This was from the time when we introduced the variable and we had to allow a
transition period. If you really want symmetry, we should perhaps make that one
an error now?

>  Then symmetrically the same should happen for a layer with LAYERSERIES_COMPAT
> - especially that this check is not able to detect any real problems in this
> layer - it only blindly rejects a valid layer.

We (as a TSC and a project) realised we had a lot of problems due to layers not
declaring which versions they are compatible with. We decided to make that a
requirement as it causes users a problem. I don't see that anything has changed
in this regard, if we drop this to a warning, people will just not declare the
layer compatibility and we're back to square one.

> Additionally, this bb.fatal generates compatibility problem as we're able to
> consume 3rd party layers which have LAYERSERIES_COMPAT in yocto morty (which
> doesn't use this compatibility check), but the same layers are false
> positively rejected by yocto dunfell.

As I say above, we have a period where we had to introduce this feature. We've
done that so perhaps now is the time to require it, not the other way around and
drop the check.

> Having this merged would allow to limit maintenance burden on 3rd party
> layers.

Adding a single keyword every six months to show the layer is active and meant
to work with a new release is not in my view a huge maintenance burden compared
to showing that the layer is actively maintained and clearly showing which
combinations are meant to work.

Cheers,

Richard

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Peter Kjellerstedt]

> -----Original Message-----
> From: bitbake-devel@lists.openembedded.org <bitbake-
> devel@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 4 september 2021 09:54
> To: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>; bitbake-
> devel@lists.openembedded.org
> Subject: Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially
> incompatible layer
> 
> On Fri, 2021-09-03 at 10:53 -0700, Damian Wrobel wrote:
> > On Fri, Sep 3, 2021 at 07:07 PM, Richard Purdie wrote:
> > > LAYERSERIES_COMPAT
> > The problem is that there is inconsistency for treating layers with and
> > without
> > LAYERSERIES_COMPAT.
> >
> > If the layer without LAYERSERIES_COMPAT works perfectly - only a warning
> is
> > emitted.
> 
> This was from the time when we introduced the variable and we had to allow
> a
> transition period. If you really want symmetry, we should perhaps make
> that one
> an error now?
> 
> >  Then symmetrically the same should happen for a layer with
> LAYERSERIES_COMPAT
> > - especially that this check is not able to detect any real problems in
> this
> > layer - it only blindly rejects a valid layer.
> 
> We (as a TSC and a project) realised we had a lot of problems due to
> layers not
> declaring which versions they are compatible with. We decided to make that
> a
> requirement as it causes users a problem. I don't see that anything has
> changed
> in this regard, if we drop this to a warning, people will just not declare
> the
> layer compatibility and we're back to square one.
> 
> > Additionally, this bb.fatal generates compatibility problem as we're
> able to
> > consume 3rd party layers which have LAYERSERIES_COMPAT in yocto morty
> (which
> > doesn't use this compatibility check), but the same layers are false
> > positively rejected by yocto dunfell.
> 
> As I say above, we have a period where we had to introduce this feature.
> We've
> done that so perhaps now is the time to require it, not the other way
> around and
> drop the check.
> 
> > Having this merged would allow to limit maintenance burden on 3rd party
> > layers.
> 
> Adding a single keyword every six months to show the layer is active and
> meant
> to work with a new release is not in my view a huge maintenance burden
> compared
> to showing that the layer is actively maintained and clearly showing which
> combinations are meant to work.
> 
> Cheers,
> 
> Richard

In addition to this, with the upcoming Honister release it will be nearly 
impossible to have a layer that is compatible with anything older than 
Dunfell due to the syntax changes for the variable overrides. So you may 
as well get used to not being able to have one version of a layer that is 
compatible with everything.

//Peter

Re: [PATCH] cooker: Only warn on potentially incompatible layer

[Damian Wrobel]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On Sat, Sep 4, 2021 at 09:54 AM, Richard Purdie wrote:

> 
> Adding a single keyword every six months to show the layer is active and
> meant
> to work with a new release is not in my view a huge maintenance burden
> compared
> to showing that the layer is actively maintained and clearly showing which
> 
> combinations are meant to work.

It's not feasible because if the layer required some extra bbclasses cherry-picked to be support it in the older yocto,
then no one can simply add this keyword to mark it's supported with older yocto. This in practise means that despite
the layer itself didn't require any changes to be supported in older yocto it will be unconditionally rejected by bitbake.

So, in reality it mean that such a layer has to be forked and modified to be accepted by bitbake.

I hope this clearly shows why this kind of checking in bitbake is inappropriate.

--
Regards,
Damian

[-- Attachment #2: Type: text/html, Size: 981 bytes --]

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Richard Purdie]

On Tue, 2021-09-07 at 01:54 -0700, Damian Wrobel wrote:
> On Sat, Sep 4, 2021 at 09:54 AM, Richard Purdie wrote:
> > Adding a single keyword every six months to show the layer is active and
> > meant
> > to work with a new release is not in my view a huge maintenance burden
> > compared
> > to showing that the layer is actively maintained and clearly showing which
> > combinations are meant to work.
>
> It's not feasible because if the layer required some extra bbclasses cherry-
> picked to be support it in the older yocto, then no one can simply add this
> keyword to mark it's supported with older yocto.

I don't understand your example here. If you can cherry-pick changes into a
layer, you can also add a patch to mark the layer as supported using the
standard variables?

> This in practise means that despite the layer itself didn't require any
> changes to be supported in older yocto it will be unconditionally rejected by
> bitbake.

Your previous sentence says "the layer required some extra bbclasses" so it did
need changes?

> So, in reality it mean that such a layer has to be forked and modified to be
> accepted by bitbake.
> 
> I hope this clearly shows why this kind of checking in bitbake is
> inappropriate.

I'm afraid I don't understand your example.

Cheers,

Richard

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Damian Wrobel]

 ---- On Tue, 07 Sep 2021 13:40:07 +0200 Richard Purdie <richard.purdie@linuxfoundation.org> wrote ----
 > On Tue, 2021-09-07 at 01:54 -0700, Damian Wrobel wrote:
 > > On Sat, Sep 4, 2021 at 09:54 AM, Richard Purdie wrote:
 > > > Adding a single keyword every six months to show the layer is active and
 > > > meant
 > > > to work with a new release is not in my view a huge maintenance burden
 > > > compared
 > > > to showing that the layer is actively maintained and clearly showing which
 > > > combinations are meant to work.
 > >
 > > It's not feasible because if the layer required some extra bbclasses cherry-
 > > picked to be support it in the older yocto, then no one can simply add this
 > > keyword to mark it's supported with older yocto.
 > 
 > I don't understand your example here. If you can cherry-pick changes into a
 > layer, you can also add a patch to mark the layer as supported using the
 > standard variables?

Let's consider the following example:

a) meta-layer-which-we-want-to-consume (contains: LAYERSERIES_COMPAT_clang-layer = "gatesgarth hardknott")
b) openembedded-core
c) bitbake
d) meta-our-layer

By saying that layer (a) required some extra bbclasses to be cherry-picked I meant that
in order to use layer (a) we had to cherry-pick some extra bbclasses or other changes
into (d) to get (a) working with (b) and (c).

This worked for us when (b), (c) and (d) were on yocto morty, but stopped to work when
we switched to dunfell because dunfell started to utilize LAYERSERIES_COMPAT.

This is very common situation that nothing needs to be modified in (a) to get it working with different versions
of (b) and (c).

So the question is why we have to modify also (a) to make (c) happy?

--
Regards,
Damian

 > 
 > > This in practise means that despite the layer itself didn't require any
 > > changes to be supported in older yocto it will be unconditionally rejected by
 > > bitbake.
 > 
 > Your previous sentence says "the layer required some extra bbclasses" so it did
 > need changes?
 > 
 > > So, in reality it mean that such a layer has to be forked and modified to be
 > > accepted by bitbake.
 > > 
 > > I hope this clearly shows why this kind of checking in bitbake is
 > > inappropriate.
 > 
 > I'm afraid I don't understand your example.
 > 
 > Cheers,
 > 
 > Richard
 > 
 > 

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2980 bytes --]

You can modify LAYERSERIES_COMPAT_clang-layer to whatever you need after
you provide whatever is needed for layer (a) to be compatible with the rest
of your stack of layers.

See meta-qt5-compat as an example
https://github.com/webosose/meta-webosose/tree/2db6a1bc8e1a6f82db5b8f345d5aaa29e74fede5/meta-qt5-compat

Regards,

On Tue, Sep 7, 2021 at 3:50 PM Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
wrote:

>
>
>
>  ---- On Tue, 07 Sep 2021 13:40:07 +0200 Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote ----
>  > On Tue, 2021-09-07 at 01:54 -0700, Damian Wrobel wrote:
>  > > On Sat, Sep 4, 2021 at 09:54 AM, Richard Purdie wrote:
>  > > > Adding a single keyword every six months to show the layer is
> active and
>  > > > meant
>  > > > to work with a new release is not in my view a huge maintenance
> burden
>  > > > compared
>  > > > to showing that the layer is actively maintained and clearly
> showing which
>  > > > combinations are meant to work.
>  > >
>  > > It's not feasible because if the layer required some extra bbclasses
> cherry-
>  > > picked to be support it in the older yocto, then no one can simply
> add this
>  > > keyword to mark it's supported with older yocto.
>  >
>  > I don't understand your example here. If you can cherry-pick changes
> into a
>  > layer, you can also add a patch to mark the layer as supported using the
>  > standard variables?
>
> Let's consider the following example:
>
> a) meta-layer-which-we-want-to-consume (contains:
> LAYERSERIES_COMPAT_clang-layer = "gatesgarth hardknott")
> b) openembedded-core
> c) bitbake
> d) meta-our-layer
>
> By saying that layer (a) required some extra bbclasses to be cherry-picked
> I meant that
> in order to use layer (a) we had to cherry-pick some extra bbclasses or
> other changes
> into (d) to get (a) working with (b) and (c).
>
> This worked for us when (b), (c) and (d) were on yocto morty, but stopped
> to work when
> we switched to dunfell because dunfell started to utilize
> LAYERSERIES_COMPAT.
>
> This is very common situation that nothing needs to be modified in (a) to
> get it working with different versions
> of (b) and (c).
>
> So the question is why we have to modify also (a) to make (c) happy?
>
> --
> Regards,
> Damian
>
>  >
>  > > This in practise means that despite the layer itself didn't require
> any
>  > > changes to be supported in older yocto it will be unconditionally
> rejected by
>  > > bitbake.
>  >
>  > Your previous sentence says "the layer required some extra bbclasses"
> so it did
>  > need changes?
>  >
>  > > So, in reality it mean that such a layer has to be forked and
> modified to be
>  > > accepted by bitbake.
>  > >
>  > > I hope this clearly shows why this kind of checking in bitbake is
>  > > inappropriate.
>  >
>  > I'm afraid I don't understand your example.
>  >
>  > Cheers,
>  >
>  > Richard
>  >
>  >
>
> 
>
>

[-- Attachment #2: Type: text/html, Size: 3875 bytes --]

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On Tue, 7 Sept 2021 at 15:50, Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
wrote:

> Let's consider the following example:
>
> a) meta-layer-which-we-want-to-consume (contains:
> LAYERSERIES_COMPAT_clang-layer = "gatesgarth hardknott")
> b) openembedded-core
> c) bitbake
> d) meta-our-layer
>
> By saying that layer (a) required some extra bbclasses to be cherry-picked
> I meant that
> in order to use layer (a) we had to cherry-pick some extra bbclasses or
> other changes
> into (d) to get (a) working with (b) and (c).
>
> This worked for us when (b), (c) and (d) were on yocto morty, but stopped
> to work when
> we switched to dunfell because dunfell started to utilize
> LAYERSERIES_COMPAT.
>
> This is very common situation that nothing needs to be modified in (a) to
> get it working with different versions
> of (b) and (c).
>
> So the question is why we have to modify also (a) to make (c) happy?
>

I still do not understand what the problem is. meta-clang does have a
dunfell branch, that sets LAYERSERIES_COMPAT accordingly, why are you not
using that?

Alex

[-- Attachment #2: Type: text/html, Size: 1465 bytes --]

Re: [PATCH] cooker: Only warn on potentially incompatible layer

[Damian Wrobel]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

>>So the question is why we have to modify also (a) to make (c) happy?

>I still do not understand what the problem is. meta-clang does have a dunfell branch, that sets LAYERSERIES_COMPAT accordingly, why are you not using that?

Please assume that we can't, if this would make it possible to finally answer my aforementioned question.

--
Regards,
Damian

[-- Attachment #2: Type: text/html, Size: 406 bytes --]

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Tue, 7 Sept 2021 at 17:35, Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
wrote:

> >>So the question is why we have to modify also (a) to make (c) happy?
>
> >I still do not understand what the problem is. meta-clang does have a
> dunfell branch, that sets LAYERSERIES_COMPAT accordingly, why are you not
> using that?
>
> Please assume that we can't, if this would make it possible to finally
> answer my aforementioned question.
>

Sorry, not possible. If dunfell branch doesn't do what you need it to, the
correct solution is to send patches for the branch, or backport the needed
changes into your internal copy of that layer. But certainly not to start
mixing layer revisions from different releases and demand that this must be
supported and easy.

Alex

[-- Attachment #2: Type: text/html, Size: 1196 bytes --]

Re: [PATCH] cooker: Only warn on potentially incompatible layer

[Damian Wrobel]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

On Tue, Sep 7, 2021 at 05:49 PM, Alexander Kanavin wrote:

>Sorry, not possible. If dunfell branch doesn't do what you need it to, the correct solution is to send patches for the branch, or backport the needed changes into your internal copy of that layer. But certainly not to start mixing layer revisions from different releases and demand that this must be supported and easy.

Thank you for the hints but they do not scale well in reality and the restrictions LAYERSERIES_COMPAT imposes on the rest of the components simply resembles me the "rule of diversity"[0] from the Art of Unix programming.

[0] https://www.linuxtopia.org/online_books/programming_books/art_of_unix_programming/ch01s06_15.html ( https://www.linuxtopia.org/online_books/programming_books/art_of_unix_programming/ch01s06_15.html )

--
Regards,
Damian

[-- Attachment #2: Type: text/html, Size: 978 bytes --]

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Richard Purdie]

On Tue, 2021-09-07 at 09:38 -0700, Damian Wrobel wrote:
> On Tue, Sep 7, 2021 at 05:49 PM, Alexander Kanavin wrote:
> 
> > Sorry, not possible. If dunfell branch doesn't do what you need it to, the
> > correct solution is to send patches for the branch, or backport the needed
> > changes into your internal copy of that layer. But certainly not to start
> > mixing layer revisions from different releases and demand that this must be
> > supported and easy.
> 
> Thank you for the hints but they do not scale well in reality and the
> restrictions LAYERSERIES_COMPAT imposes on the rest of the components simply
> resembles me the "rule of diversity"[0] from the Art of Unix programming.
> 
> [0]
> https://www.linuxtopia.org/online_books/programming_books/art_of_unix_programmin
> g/ch01s06_15.html

So you're saying we're showing an "unhealthy form of arrogance". Thanks.

I did mention you can bypass and do creative things with the checks. I don't
particularly want to spell it out as I don't want to encourage it or see it in
widespread use but someone else has also mentioned more directly how it can be
done.

The answer is still no, we're not changing that default as it does help end
users a lot. You can avoid the check if you know what you're doing.

Cheers,

Richard

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Tue, 7 Sept 2021 at 21:17, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> So you're saying we're showing an "unhealthy form of arrogance". Thanks.
>
> I did mention you can bypass and do creative things with the checks. I
> don't
> particularly want to spell it out as I don't want to encourage it or see
> it in
> widespread use but someone else has also mentioned more directly how it
> can be
> done.
>

By the way, in my previous job I've seen a certain well-known mobile
silicon vendor get even more creative and declare a wildcard yocto release
compatibility for all of their BSP layers, so they would never have to
spell out specific yocto releases. That was literally the first thing I
told them to remove, and no, I am not saying how they did it. One can
bypass all rules if one is determined to.

Alex

[-- Attachment #2: Type: text/html, Size: 1217 bytes --]

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Enrico Scholz]

"Damian Wrobel" <dwrobel@ertelnet.rybnik.pl> writes:

> It frequently happens that the 3rd party layer is, in practise,
> fully compatible with the older version of yocto. So, instead of
> false positively reporting an error, it seems to be more
> appropriately to just emit the warning.

You can achieve this already now (when you are really sure that it works
for your bsp).  Just set

| LAYERSERIES_COMPAT:<foreign-layer>:append = " frodo"

in your bblayers.conf.



Enrico

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Peter Kjellerstedt]

> -----Original Message-----
> From: bitbake-devel@lists.openembedded.org <bitbake-
> devel@lists.openembedded.org> On Behalf Of Enrico Scholz via
> lists.openembedded.org
> Sent: den 8 september 2021 11:56
> To: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
> Cc: bitbake-devel@lists.openembedded.org
> Subject: Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially
> incompatible layer
> 
> "Damian Wrobel" <dwrobel@ertelnet.rybnik.pl> writes:
> 
> > It frequently happens that the 3rd party layer is, in practise,
> > fully compatible with the older version of yocto. So, instead of
> > false positively reporting an error, it seems to be more
> > appropriately to just emit the warning.
> 
> You can achieve this already now (when you are really sure that it works
> for your bsp).  Just set
> 
> | LAYERSERIES_COMPAT:<foreign-layer>:append = " frodo"
> 
> in your bblayers.conf.

Minor detail: LAYERSERIES_COMPAT is among the variables that have 
not been changed to use the new override format, so the above should 
be:

LAYERSERIES_COMPAT_<foreign-layer>:append = " frodo"

> Enrico

//Peter

Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

[Damian Wrobel]

 ---- On Wed, 08 Sep 2021 11:56:28 +0200 Enrico Scholz <enrico.scholz@sigma-chemnitz.de> wrote ----
 > "Damian Wrobel" <dwrobel@ertelnet.rybnik.pl> writes:
 > 
 > > It frequently happens that the 3rd party layer is, in practise,
 > > fully compatible with the older version of yocto. So, instead of
 > > false positively reporting an error, it seems to be more
 > > appropriately to just emit the warning.
 > 
 > You can achieve this already now (when you are really sure that it works
 > for your bsp).  Just set

I'm aware of this thread [2] where it was already discussed, but I was hoping to fix it for good in the root of the problem.

[2] https://lists.yoctoproject.org/g/yocto/topic/74454321

Regards,
Damian

 > 
 > | LAYERSERIES_COMPAT:<foreign-layer>:append = " frodo"
 > 
 > in your bblayers.conf.
 > 
 > 
 > 
 > Enrico
 >