Re: [dunfell][PATCH 00/14] Backport mandatory dtschema handling for device trees built through the kernel.

Re: [dunfell][PATCH 00/14] Backport mandatory dtschema handling for device trees built through the kernel.

[Bruce Ashfield]

On Wed, Dec 1, 2021 at 3:34 PM Bhupesh Sharma <bhupesh.sharma@linaro.org> wrote:
>
> This is a backport request for dunfell, while picking up only the
> skeletal support for allowing mandatory dtschema handling for
> device trees built through the kernel, introduced from kernel
> version 5.16 onwards.

The problem with adding this support to dunfell, is obvious in the
number of patches involved.  We've also said/known that at some point
that we won't be able to support all new kernel versions with the LTS
release. This may be the start of drawing that line.

Also, we've had to do some license tweaks in master just today for one
of the added packages (idna), so that would be needed as well.

The validation isn't absolutely critical, I'd suggest that just the
wrappers and pkg-config fixes would be a smaller footprint to allow
the kernel to build, without the new package/feature additions to the
dunfell release. The new packages (and full validation) could still
possibly be done through a secondary or mixin layer.

I'm not sure which way to go on this, but I thought I'd offer those
points for discussion.

Bruce

>
> Without this backport compiling 5.16 kernel leads to the following
> error in the dunfell stable branch:
>
> scripts/dtc/Makefile:23: *** dtc needs libyaml for DT schema
>  validation support. Install the necessary libyaml development package..  Stop.
>
> Bruce Ashfield (14):
>   kernel: export native PKGCONFIG variables
>   python: introduce python3-dtschema
>   python: import jsonpointer from meta-python
>   python3-jsonpointer: Update 2.1 to 2.2
>   python: import jsonschema from meta-python
>   python: import idna from meta-python
>   python: import rfc3339-validator from meta-python
>   python: import rfc3986-validator from meta-python
>   python: import webcolors from meta-python
>   python: import ruamel-yaml from meta-python
>   python: import pyrsistent from meta-python
>   python: import rfc3987 from meta-pyton
>   python: import strict-rfc3339 from meta-python
>   python: import vcversioner from meta-python
>
>  meta/classes/kernel.bbclass                   |  7 +++
>  ...e-pytest-runner-to-test_requirements.patch | 32 +++++++++++++
>  .../python/python3-dtschema_2021.10.bb        | 16 +++++++
>  .../python/python3-idna_3.3.bb                | 19 ++++++++
>  .../python/python3-jsonpointer/run-ptest      |  3 ++
>  .../python/python3-jsonpointer_2.2.bb         | 26 ++++++++++
>  .../python/python3-jsonschema_3.2.0.bb        | 48 +++++++++++++++++++
>  .../python/python3-pyrsistent_0.18.0.bb       | 14 ++++++
>  .../python/python3-rfc3339-validator_0.1.4.bb | 20 ++++++++
>  .../python/python3-rfc3986-validator_0.1.1.bb | 23 +++++++++
>  .../python/python3-rfc3987_1.3.8.bb           | 10 ++++
>  .../python/python3-ruamel-yaml_0.17.16.bb     | 23 +++++++++
>  .../python/python3-strict-rfc3339_0.7.bb      | 10 ++++
>  .../python/python3-vcversioner_2.16.0.0.bb    | 12 +++++
>  .../python/python3-webcolors/run-ptest        |  3 ++
>  .../python/python3-webcolors_1.11.1.bb        | 27 +++++++++++
>  16 files changed, 293 insertions(+)
>  create mode 100644 meta/recipes-devtools/python/python-rfc3986-validator/0001-setup.py-move-pytest-runner-to-test_requirements.patch
>  create mode 100644 meta/recipes-devtools/python/python3-dtschema_2021.10.bb
>  create mode 100644 meta/recipes-devtools/python/python3-idna_3.3.bb
>  create mode 100644 meta/recipes-devtools/python/python3-jsonpointer/run-ptest
>  create mode 100644 meta/recipes-devtools/python/python3-jsonpointer_2.2.bb
>  create mode 100644 meta/recipes-devtools/python/python3-jsonschema_3.2.0.bb
>  create mode 100644 meta/recipes-devtools/python/python3-pyrsistent_0.18.0.bb
>  create mode 100644 meta/recipes-devtools/python/python3-rfc3339-validator_0.1.4.bb
>  create mode 100644 meta/recipes-devtools/python/python3-rfc3986-validator_0.1.1.bb
>  create mode 100644 meta/recipes-devtools/python/python3-rfc3987_1.3.8.bb
>  create mode 100644 meta/recipes-devtools/python/python3-ruamel-yaml_0.17.16.bb
>  create mode 100644 meta/recipes-devtools/python/python3-strict-rfc3339_0.7.bb
>  create mode 100644 meta/recipes-devtools/python/python3-vcversioner_2.16.0.0.bb
>  create mode 100644 meta/recipes-devtools/python/python3-webcolors/run-ptest
>  create mode 100644 meta/recipes-devtools/python/python3-webcolors_1.11.1.bb
>
> --
> 2.31.1
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [OE-core] [dunfell][PATCH 00/14] Backport mandatory dtschema handling for device trees built through the kernel.

[Richard Purdie]

On Wed, 2021-12-01 at 16:33 -0500, Bruce Ashfield wrote:
> On Wed, Dec 1, 2021 at 3:34 PM Bhupesh Sharma <bhupesh.sharma@linaro.org> wrote:
> > 
> > This is a backport request for dunfell, while picking up only the
> > skeletal support for allowing mandatory dtschema handling for
> > device trees built through the kernel, introduced from kernel
> > version 5.16 onwards.
> 
> The problem with adding this support to dunfell, is obvious in the
> number of patches involved.  We've also said/known that at some point
> that we won't be able to support all new kernel versions with the LTS
> release. This may be the start of drawing that line.
> 
> Also, we've had to do some license tweaks in master just today for one
> of the added packages (idna), so that would be needed as well.
> 
> The validation isn't absolutely critical, I'd suggest that just the
> wrappers and pkg-config fixes would be a smaller footprint to allow
> the kernel to build, without the new package/feature additions to the
> dunfell release. The new packages (and full validation) could still
> possibly be done through a secondary or mixin layer.
> 
> I'm not sure which way to go on this, but I thought I'd offer those
> points for discussion.

I think this needs to be done in a mixin layer for dunfell.

Cheers,

Richard

Re: [OE-core] [dunfell][PATCH 00/14] Backport mandatory dtschema handling for device trees built through the kernel.

[Nicolas Dechesne]

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

On Wed, Dec 1, 2021 at 10:39 PM Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Wed, 2021-12-01 at 16:33 -0500, Bruce Ashfield wrote:
> > On Wed, Dec 1, 2021 at 3:34 PM Bhupesh Sharma <bhupesh.sharma@linaro.org>
> wrote:
> > >
> > > This is a backport request for dunfell, while picking up only the
> > > skeletal support for allowing mandatory dtschema handling for
> > > device trees built through the kernel, introduced from kernel
> > > version 5.16 onwards.
> >
> > The problem with adding this support to dunfell, is obvious in the
> > number of patches involved.  We've also said/known that at some point
> > that we won't be able to support all new kernel versions with the LTS
> > release. This may be the start of drawing that line.
> >
> > Also, we've had to do some license tweaks in master just today for one
> > of the added packages (idna), so that would be needed as well.
> >
> > The validation isn't absolutely critical, I'd suggest that just the
> > wrappers and pkg-config fixes would be a smaller footprint to allow
> > the kernel to build, without the new package/feature additions to the
> > dunfell release. The new packages (and full validation) could still
> > possibly be done through a secondary or mixin layer.
> >
> > I'm not sure which way to go on this, but I thought I'd offer those
> > points for discussion.
>
> I think this needs to be done in a mixin layer for dunfell.
>

ok.. what about honister? would you consider a backport of these patches
for this more recent release?


>
> Cheers,
>
> Richard
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#159062):
> https://lists.openembedded.org/g/openembedded-core/message/159062
> Mute This Topic: https://lists.openembedded.org/mt/87439224/1279857
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> nicolas.dechesne@linaro.org]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

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

Re: [OE-core] [dunfell][PATCH 00/14] Backport mandatory dtschema handling for device trees built through the kernel.

[Richard Purdie]

On Tue, 2021-12-07 at 10:49 +0100, Nicolas Dechesne wrote:
> 
> 
> On Wed, Dec 1, 2021 at 10:39 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Wed, 2021-12-01 at 16:33 -0500, Bruce Ashfield wrote:
> > > On Wed, Dec 1, 2021 at 3:34 PM Bhupesh Sharma <bhupesh.sharma@linaro.org>
> > wrote:
> > > > 
> > > > This is a backport request for dunfell, while picking up only the
> > > > skeletal support for allowing mandatory dtschema handling for
> > > > device trees built through the kernel, introduced from kernel
> > > > version 5.16 onwards.
> > > 
> > > The problem with adding this support to dunfell, is obvious in the
> > > number of patches involved.  We've also said/known that at some point
> > > that we won't be able to support all new kernel versions with the LTS
> > > release. This may be the start of drawing that line.
> > > 
> > > Also, we've had to do some license tweaks in master just today for one
> > > of the added packages (idna), so that would be needed as well.
> > > 
> > > The validation isn't absolutely critical, I'd suggest that just the
> > > wrappers and pkg-config fixes would be a smaller footprint to allow
> > > the kernel to build, without the new package/feature additions to the
> > > dunfell release. The new packages (and full validation) could still
> > > possibly be done through a secondary or mixin layer.
> > > 
> > > I'm not sure which way to go on this, but I thought I'd offer those
> > > points for discussion.
> > 
> > I think this needs to be done in a mixin layer for dunfell.
> > 
> 
> 
> ok.. what about honister? would you consider a backport of these patches for
> this more recent release?

To be honest, with such a large set of changes, no, I'd much prefer a mixin
layer there too.

It is rather sad the kernel is suddenly "growing" it's dependency list in such a
large way but it doesn't change our policy on feature backports. Whilst we've
worked to allow newer kernels on older releases where it is practical, this case
isn't even close to being similar in scope :(.

Cheers,

Richard

Re: [dunfell][PATCH 00/14] Backport mandatory dtschema handling for device trees built through the kernel.

[Paul Barker]

On 01/12/2021 21:33, Bruce Ashfield wrote:
> On Wed, Dec 1, 2021 at 3:34 PM Bhupesh Sharma <bhupesh.sharma@linaro.org> wrote:
>>
>> This is a backport request for dunfell, while picking up only the
>> skeletal support for allowing mandatory dtschema handling for
>> device trees built through the kernel, introduced from kernel
>> version 5.16 onwards.
> 
> The problem with adding this support to dunfell, is obvious in the
> number of patches involved.  We've also said/known that at some point
> that we won't be able to support all new kernel versions with the LTS
> release. This may be the start of drawing that line.
> 
> Also, we've had to do some license tweaks in master just today for one
> of the added packages (idna), so that would be needed as well.
> 
> The validation isn't absolutely critical, I'd suggest that just the
> wrappers and pkg-config fixes would be a smaller footprint to allow
> the kernel to build, without the new package/feature additions to the
> dunfell release. The new packages (and full validation) could still
> possibly be done through a secondary or mixin layer.
> 
> I'm not sure which way to go on this, but I thought I'd offer those
> points for discussion.

I've been thinking about this for meta-linux-mainline. Backporting 
python3-dtschema-wrapper seems like the way to go, either into a very 
small mixin layer or into oe-core.

Thanks,

-- 
Paul Barker

e: paul@pbarker.dev
w: https://pbarker.dev/