| Message ID | 20250905171154.182825-1-kamel.bouhara@bootlin.com |
|---|---|
| Headers | show |
| Series | backport: SPDX 3.0 support to Scarthgap | expand |
On Fri, Sep 05, 2025 at 07:11:48PM +0200, Kamel Bouhara wrote: > Hello, > Please note this entire patch series is for Scarthgap. Sorry for the missing [scarthgap] tag in the subject line. Cc: Steve Sakoman <steve@sakoman.com> > This series backports SPDX 3.0 support from the upstream Walnascar > branch to Scarthgap, along with a few additional local fixes to ensure > correct integration. > > The primary motivation for this series is to bring full SPDX 3.0 support > to the latest Yocto Project LTS release, Scarthgap, which will continue > to receive maintenance updates until 2028. > > This ensures that long-term supported releases can benefit from the > latest SPDX standard for license and compliance tracking. > > These changes are also in line with discussions at the Yocto Project > Summit in Amsterdam, where the need for up-to-date SPDX support in LTS > releases was highlighted. > > The backport introduces SPDX 3.0 document support, SDK and image > integration, and related helpers. It also brings over tasks, classes, > and library code from upstream. > > Feedback is particularly welcome on: > - The correctness and completeness of the backport > - Whether the local fixes should be adjusted or further refined > > Greetings. > > Kamel > > Joshua Watt (4): > classes-global/license: Move functions to library code > lib/license: Move package license skip to library > lib: oe: license: Add missing import > classes-recipe/image: Add image file manifest > > Kamel Bouhara (Schneider Electric) (2): > backport: SPDX 3.0 fixes and tasks from upstream version Walnascar > spdx30_tasks: fix FetchData attribute in add_download_files > > meta/classes-global/base.bbclass | 41 +- > meta/classes-global/license.bbclass | 165 - > .../create-spdx-image-3.0.bbclass | 85 + > .../create-spdx-sdk-3.0.bbclass | 74 + > meta/classes-recipe/image.bbclass | 58 + > meta/classes-recipe/license_image.bbclass | 14 +- > meta/classes-recipe/nospdx.bbclass | 13 + > meta/classes/create-spdx-3.0.bbclass | 200 + > meta/classes/spdx-common.bbclass | 99 + > meta/lib/oe/__init__.py | 2 +- > meta/lib/oe/license.py | 203 + > meta/lib/oe/sbom30.py | 1096 ++++ > meta/lib/oe/spdx30.py | 5593 +++++++++++++++++ > meta/lib/oe/spdx30_tasks.py | 1348 ++++ > meta/lib/oe/spdx_common.py | 244 + > 15 files changed, 9028 insertions(+), 207 deletions(-) > create mode 100644 meta/classes-recipe/create-spdx-image-3.0.bbclass > create mode 100644 meta/classes-recipe/create-spdx-sdk-3.0.bbclass > create mode 100644 meta/classes-recipe/nospdx.bbclass > create mode 100644 meta/classes/create-spdx-3.0.bbclass > create mode 100644 meta/classes/spdx-common.bbclass > create mode 100644 meta/lib/oe/sbom30.py > create mode 100644 meta/lib/oe/spdx30.py > create mode 100644 meta/lib/oe/spdx30_tasks.py > create mode 100644 meta/lib/oe/spdx_common.py > > -- > 2.43.0 > -- Kamel Bouhara, Bootlin Embedded Linux and kernel engineering https://bootlin.com
On Fri, Sep 5, 2025 at 11:11 AM Kamel Bouhara <kamel.bouhara@bootlin.com> wrote: > Hello, > > This series backports SPDX 3.0 support from the upstream Walnascar > branch to Scarthgap, along with a few additional local fixes to ensure > correct integration. > > The primary motivation for this series is to bring full SPDX 3.0 support > to the latest Yocto Project LTS release, Scarthgap, which will continue > to receive maintenance updates until 2028. > > This ensures that long-term supported releases can benefit from the > latest SPDX standard for license and compliance tracking. > > These changes are also in line with discussions at the Yocto Project > Summit in Amsterdam, where the need for up-to-date SPDX support in LTS > releases was highlighted. > > The backport introduces SPDX 3.0 document support, SDK and image > integration, and related helpers. It also brings over tasks, classes, > and library code from upstream. > > Feedback is particularly welcome on: > - The correctness and completeness of the backport > - Whether the local fixes should be adjusted or further refined > Interesting. This backport isn't as bad as I initially thought it might be, thanks for putting it together! I'll look it over more closely to make sure it seems alright We had originally stated that we wouldn't backport this in OE core, and would prefer to use a mix in layer.... that said, it is probably the number one request I've gotten any time I talk about SPDX, a lot of people are pretty interested in having this, and there are a lot of advantages to doing it in OE core, so perhaps we can discuss that more. The one thing I can tell right away that you are missing is the test code; if this does go into OE core, backport of the test cases will be required also. > > Greetings. > > Kamel > > Joshua Watt (4): > classes-global/license: Move functions to library code > lib/license: Move package license skip to library > lib: oe: license: Add missing import > classes-recipe/image: Add image file manifest > > Kamel Bouhara (Schneider Electric) (2): > backport: SPDX 3.0 fixes and tasks from upstream version Walnascar > spdx30_tasks: fix FetchData attribute in add_download_files > > meta/classes-global/base.bbclass | 41 +- > meta/classes-global/license.bbclass | 165 - > .../create-spdx-image-3.0.bbclass | 85 + > .../create-spdx-sdk-3.0.bbclass | 74 + > meta/classes-recipe/image.bbclass | 58 + > meta/classes-recipe/license_image.bbclass | 14 +- > meta/classes-recipe/nospdx.bbclass | 13 + > meta/classes/create-spdx-3.0.bbclass | 200 + > meta/classes/spdx-common.bbclass | 99 + > meta/lib/oe/__init__.py | 2 +- > meta/lib/oe/license.py | 203 + > meta/lib/oe/sbom30.py | 1096 ++++ > meta/lib/oe/spdx30.py | 5593 +++++++++++++++++ > meta/lib/oe/spdx30_tasks.py | 1348 ++++ > meta/lib/oe/spdx_common.py | 244 + > 15 files changed, 9028 insertions(+), 207 deletions(-) > create mode 100644 meta/classes-recipe/create-spdx-image-3.0.bbclass > create mode 100644 meta/classes-recipe/create-spdx-sdk-3.0.bbclass > create mode 100644 meta/classes-recipe/nospdx.bbclass > create mode 100644 meta/classes/create-spdx-3.0.bbclass > create mode 100644 meta/classes/spdx-common.bbclass > create mode 100644 meta/lib/oe/sbom30.py > create mode 100644 meta/lib/oe/spdx30.py > create mode 100644 meta/lib/oe/spdx30_tasks.py > create mode 100644 meta/lib/oe/spdx_common.py > > -- > 2.43.0 > >
On Sat, Sep 06, 2025 at 11:02:26AM -0600, Joshua Watt wrote: > On Fri, Sep 5, 2025 at 11:11 AM Kamel Bouhara <kamel.bouhara@bootlin.com> > wrote: > > > Hello, > > Hi Joshua, > > This series backports SPDX 3.0 support from the upstream Walnascar > > branch to Scarthgap, along with a few additional local fixes to ensure > > correct integration. > > > > The primary motivation for this series is to bring full SPDX 3.0 support > > to the latest Yocto Project LTS release, Scarthgap, which will continue > > to receive maintenance updates until 2028. > > > > This ensures that long-term supported releases can benefit from the > > latest SPDX standard for license and compliance tracking. > > > > These changes are also in line with discussions at the Yocto Project > > Summit in Amsterdam, where the need for up-to-date SPDX support in LTS > > releases was highlighted. > > > > The backport introduces SPDX 3.0 document support, SDK and image > > integration, and related helpers. It also brings over tasks, classes, > > and library code from upstream. > > > > Feedback is particularly welcome on: > > - The correctness and completeness of the backport > > - Whether the local fixes should be adjusted or further refined > > > > Interesting. This backport isn't as bad as I initially thought it might be, > thanks for putting it together! I'll look it over more closely to make sure > it seems alright Thanks for the quick review and the feedback! I hesitated to do cherry-picking and finally chose to backport every SPDX3 related class and library in one patch to have a clean and coherent backport. For related functionality (like the license refactoring and image manifest), I used cherry-picks. > > We had originally stated that we wouldn't backport this in OE core, and > would prefer to use a mix in layer.... that said, it is probably the number > one request I've gotten any time I talk about SPDX, a lot of people are > pretty interested in having this, and there are a lot of advantages to > doing it in OE core, so perhaps we can discuss that more. I also think that this belongs in OE core, LTS releases are used in production for many years, and SPDX3 adds significant value for compliance and SBOM requirements. Regarding the suggestion of using a mixin layer: I’m not entirely clear on how meta-lts-mixins would apply here. According to the documentation, mixin layers are thin and specific-purpose, maintained by the community, and not tested by the Yocto Project. SPDX3, on the other hand, is a fundamental part of license compliance infrastructure, and its maintenance should remain unchanged and part of OE-Core to ensure stability and testing across all LTS users. > > The one thing I can tell right away that you are missing is the test code; > if this does go into OE core, backport of the test cases will be required > also. I did a quick check, and my plan is to cherry-pick the following commits from upstream to bring in the SPDX3 test coverage: 838d64c096 spdx 3.0: Rework how SPDX aliases are linked 14f534f15f lib: oeqa: spdx: Add tests for extra options ccd6dde301 oeqa/selftest: Add SPDX 3.0 include source case for work-share b1d2309b3a selftest: spdx: Add SPDX 3.0 test cases This should provide equivalent test coverage to Walnascar. Does that approach work for you? Thanks ! Kamel -- Kamel Bouhara, Bootlin Embedded Linux and kernel engineering https://bootlin.com
On Mon, Sep 8, 2025 at 3:01 AM Kamel Bouhara <kamel.bouhara@bootlin.com> wrote: > > On Sat, Sep 06, 2025 at 11:02:26AM -0600, Joshua Watt wrote: > > On Fri, Sep 5, 2025 at 11:11 AM Kamel Bouhara <kamel.bouhara@bootlin.com> > > wrote: > > > > > Hello, > > > > > Hi Joshua, > > > > This series backports SPDX 3.0 support from the upstream Walnascar > > > branch to Scarthgap, along with a few additional local fixes to ensure > > > correct integration. > > > > > > The primary motivation for this series is to bring full SPDX 3.0 support > > > to the latest Yocto Project LTS release, Scarthgap, which will continue > > > to receive maintenance updates until 2028. > > > > > > This ensures that long-term supported releases can benefit from the > > > latest SPDX standard for license and compliance tracking. > > > > > > These changes are also in line with discussions at the Yocto Project > > > Summit in Amsterdam, where the need for up-to-date SPDX support in LTS > > > releases was highlighted. > > > > > > The backport introduces SPDX 3.0 document support, SDK and image > > > integration, and related helpers. It also brings over tasks, classes, > > > and library code from upstream. > > > > > > Feedback is particularly welcome on: > > > - The correctness and completeness of the backport > > > - Whether the local fixes should be adjusted or further refined > > > > > > > Interesting. This backport isn't as bad as I initially thought it might be, > > thanks for putting it together! I'll look it over more closely to make sure > > it seems alright > > Thanks for the quick review and the feedback! > > I hesitated to do cherry-picking and finally chose to backport every > SPDX3 related class and library in one patch to have a clean and coherent > backport. For related functionality (like the license refactoring and > image manifest), I used cherry-picks. > > > > > We had originally stated that we wouldn't backport this in OE core, and > > would prefer to use a mix in layer.... that said, it is probably the number > > one request I've gotten any time I talk about SPDX, a lot of people are > > pretty interested in having this, and there are a lot of advantages to > > doing it in OE core, so perhaps we can discuss that more. > > I also think that this belongs in OE core, LTS releases are used in > production for many years, and SPDX3 adds significant value for > compliance and SBOM requirements. > > Regarding the suggestion of using a mixin layer: I’m not entirely clear > on how meta-lts-mixins would apply here. According to the documentation, > mixin layers are thin and specific-purpose, maintained by the community, > and not tested by the Yocto Project. SPDX3, on the other hand, is a > fundamental part of license compliance infrastructure, and its > maintenance should remain unchanged and part of OE-Core to ensure > stability and testing across all LTS users. > > > > > The one thing I can tell right away that you are missing is the test code; > > if this does go into OE core, backport of the test cases will be required > > also. > > I did a quick check, and my plan is to cherry-pick the following commits > from upstream to bring in the SPDX3 test coverage: > > 838d64c096 spdx 3.0: Rework how SPDX aliases are linked > 14f534f15f lib: oeqa: spdx: Add tests for extra options > ccd6dde301 oeqa/selftest: Add SPDX 3.0 include source case for work-share > b1d2309b3a selftest: spdx: Add SPDX 3.0 test cases > > This should provide equivalent test coverage to Walnascar. Does that > approach work for you? Yes, that sounds like a good plan > > Thanks ! > Kamel > > -- > Kamel Bouhara, Bootlin > Embedded Linux and kernel engineering > https://bootlin.com