[PATCH 0/3] SPDX: Add annotations to relationship

[PATCH 0/3] SPDX: Add annotations to relationship

[Saul Wold]

Add annotations to relationships and refactor code to add
create_annotation() function for code reuse.

Ensure that "cross" recipes are factored into isNative also.

v2: removed leftover and unused annotation per Joshua

Sau!

Saul Wold (3):
  spdx.py: Add annotation to relationship
  create-spdx: add create_annotation function
  create-spdx: cross recipes are native also

 classes/create-spdx.bbclass | 22 ++++++++++++++--------
 lib/oe/spdx.py              |  6 +++++-
 2 files changed, 19 insertions(+), 9 deletions(-)

-- 
2.31.1

[PATCH v2 1/3] spdx.py: Add annotation to relationship

[Saul Wold]

Having annotations on relationship can provide additional information
about the relationship such as how it was derived.

Signed-off-by: Saul Wold <saul.wold@windriver.com>
---
 lib/oe/spdx.py | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/oe/spdx.py b/lib/oe/spdx.py
index 4416194..9e7ced5 100644
--- a/lib/oe/spdx.py
+++ b/lib/oe/spdx.py
@@ -196,6 +196,7 @@ class SPDXRelationship(SPDXObject):
     relatedSpdxElement = _String()
     relationshipType = _String()
     comment = _String()
+    annotations = _ObjectList(SPDXAnnotation)
 
 
 class SPDXExternalReference(SPDXObject):
@@ -300,7 +301,7 @@ class SPDXDocument(SPDXObject):
     def from_json(cls, f):
         return cls(**json.load(f))
 
-    def add_relationship(self, _from, relationship, _to, *, comment=None):
+    def add_relationship(self, _from, relationship, _to, *, comment=None, annotation=None):
         if isinstance(_from, SPDXObject):
             from_spdxid = _from.SPDXID
         else:
@@ -320,6 +321,9 @@ class SPDXDocument(SPDXObject):
         if comment is not None:
             r.comment = comment
 
+        if annotation is not None:
+            r.annotations.append(annotation)
+
         self.relationships.append(r)
 
     def find_by_spdxid(self, spdxid):
-- 
2.31.1

[PATCH v2 2/3] create-spdx: add create_annotation function

[Saul Wold]

This allows code reuse and future usage with relationship annotations

Signed-off-by: Saul Wold <saul.wold@windriver.com>
---
 classes/create-spdx.bbclass | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/classes/create-spdx.bbclass b/classes/create-spdx.bbclass
index dd341db..72a9b55 100644
--- a/classes/create-spdx.bbclass
+++ b/classes/create-spdx.bbclass
@@ -35,6 +35,17 @@ def get_doc_namespace(d, doc):
     namespace_uuid = uuid.uuid5(uuid.NAMESPACE_DNS, d.getVar("SPDX_UUID_NAMESPACE"))
     return "%s/%s-%s" % (d.getVar("SPDX_NAMESPACE_PREFIX"), doc.name, str(uuid.uuid5(namespace_uuid, doc.name)))
 
+def create_annotation(d, comment):
+    from datetime import datetime, timezone
+
+    creation_time = datetime.now(tz=timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")
+    annotation = oe.spdx.SPDXAnnotation()
+    annotation.annotationDate = creation_time
+    annotation.annotationType = "OTHER"
+    annotation.annotator = "Tool: %s - %s" % (d.getVar("SPDX_TOOL_NAME"), d.getVar("SPDX_TOOL_VERSION"))
+    annotation.comment = comment
+    return annotation
+
 def recipe_spdx_is_native(d, recipe):
     return any(a.annotationType == "OTHER" and
       a.annotator == "Tool: %s - %s" % (d.getVar("SPDX_TOOL_NAME"), d.getVar("SPDX_TOOL_VERSION")) and
@@ -408,12 +419,7 @@ python do_create_spdx() {
     recipe.versionInfo = d.getVar("PV")
     recipe.SPDXID = oe.sbom.get_recipe_spdxid(d)
     if bb.data.inherits_class("native", d):
-        annotation = oe.spdx.SPDXAnnotation()
-        annotation.annotationDate = creation_time
-        annotation.annotationType = "OTHER"
-        annotation.annotator = "Tool: %s - %s" % (d.getVar("SPDX_TOOL_NAME"), d.getVar("SPDX_TOOL_VERSION"))
-        annotation.comment = "isNative"
-        recipe.annotations.append(annotation)
+        recipe.annotations.append(create_annotation(d, "isNative"))
 
     for s in d.getVar('SRC_URI').split():
         if not s.startswith("file://"):
-- 
2.31.1

[PATCH v2 3/3] create-spdx: cross recipes are native also

[Saul Wold]

Recipes that inherit cross should also be categorized as isNative

Signed-off-by: Saul Wold <saul.wold@windriver.com>
---
 classes/create-spdx.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/classes/create-spdx.bbclass b/classes/create-spdx.bbclass
index 72a9b55..e8f476f 100644
--- a/classes/create-spdx.bbclass
+++ b/classes/create-spdx.bbclass
@@ -418,7 +418,7 @@ python do_create_spdx() {
     recipe.name = d.getVar("PN")
     recipe.versionInfo = d.getVar("PV")
     recipe.SPDXID = oe.sbom.get_recipe_spdxid(d)
-    if bb.data.inherits_class("native", d):
+    if bb.data.inherits_class("native", d) or bb.data.inherits_class("cross", d):
         recipe.annotations.append(create_annotation(d, "isNative"))
 
     for s in d.getVar('SRC_URI').split():
@@ -610,7 +610,7 @@ python do_create_runtime_spdx() {
 
     deploy_dir_spdx = Path(d.getVar("DEPLOY_DIR_SPDX"))
     spdx_deploy = Path(d.getVar("SPDXRUNTIMEDEPLOY"))
-    is_native = bb.data.inherits_class("native", d)
+    is_native = bb.data.inherits_class("native", d) or bb.data.inherits_class("cross", d)
 
     creation_time = datetime.now(tz=timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")
 
-- 
2.31.1

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Jose Quaresma]

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

Hi all,

There are any plans or is it possible to backport the SBOM/SPDX to the
dunfell branch?
Doing a quick look on it I see that it is not too intrusive and the most
one is in
 classes/package: Add extended packaged data
 7ec54b174304e940ec66f21ac512f7b50fa637b3

Jose

Saul Wold <Saul.Wold@windriver.com> escreveu no dia quarta, 27/10/2021 à(s)
02:31:

> Add annotations to relationships and refactor code to add
> create_annotation() function for code reuse.
>
> Ensure that "cross" recipes are factored into isNative also.
>
> v2: removed leftover and unused annotation per Joshua
>
> Sau!
>
> Saul Wold (3):
>   spdx.py: Add annotation to relationship
>   create-spdx: add create_annotation function
>   create-spdx: cross recipes are native also
>
>  classes/create-spdx.bbclass | 22 ++++++++++++++--------
>  lib/oe/spdx.py              |  6 +++++-
>  2 files changed, 19 insertions(+), 9 deletions(-)
>
> --
> 2.31.1
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#157470):
> https://lists.openembedded.org/g/openembedded-core/message/157470
> Mute This Topic: https://lists.openembedded.org/mt/86616599/5052612
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> quaresma.jose@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
Best regards,

José Quaresma

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

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Steve Sakoman]

On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma <quaresma.jose@gmail.com> wrote:
>
> Hi all,
>
> There are any plans or is it possible to backport the SBOM/SPDX to the dunfell branch?

I'm going to yield to Saul as to whether he thinks this is
desirable/possible or not.

Steve

> Doing a quick look on it I see that it is not too intrusive and the most one is in
>  classes/package: Add extended packaged data
>  7ec54b174304e940ec66f21ac512f7b50fa637b3
>
> Jose
>
> Saul Wold <Saul.Wold@windriver.com> escreveu no dia quarta, 27/10/2021 à(s) 02:31:
>>
>> Add annotations to relationships and refactor code to add
>> create_annotation() function for code reuse.
>>
>> Ensure that "cross" recipes are factored into isNative also.
>>
>> v2: removed leftover and unused annotation per Joshua
>>
>> Sau!
>>
>> Saul Wold (3):
>>   spdx.py: Add annotation to relationship
>>   create-spdx: add create_annotation function
>>   create-spdx: cross recipes are native also
>>
>>  classes/create-spdx.bbclass | 22 ++++++++++++++--------
>>  lib/oe/spdx.py              |  6 +++++-
>>  2 files changed, 19 insertions(+), 9 deletions(-)
>>
>> --
>> 2.31.1
>>
>>
>>
>>
>
>
> --
> Best regards,
>
> José Quaresma
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#157476): https://lists.openembedded.org/g/openembedded-core/message/157476
> Mute This Topic: https://lists.openembedded.org/mt/86616599/3617601
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [sakoman@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Richard Purdie]

On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
> On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma <quaresma.jose@gmail.com> wrote:
> > 
> > Hi all,
> > 
> > There are any plans or is it possible to backport the SBOM/SPDX to the dunfell branch?
> 
> I'm going to yield to Saul as to whether he thinks this is
> desirable/possible or not.

The packagedata changes are pretty invasive unfortunately and likely not
something you're going to want in dunfell sadly.

Cheers,

Richard

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Jose Quaresma]

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

Richard Purdie <richard.purdie@linuxfoundation.org> escreveu no dia quinta,
28/10/2021 à(s) 21:58:

> On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
> > On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma <quaresma.jose@gmail.com>
> wrote:
> > >
> > > Hi all,
> > >
> > > There are any plans or is it possible to backport the SBOM/SPDX to the
> dunfell branch?
> >
> > I'm going to yield to Saul as to whether he thinks this is
> > desirable/possible or not.
>
> The packagedata changes are pretty invasive unfortunately and likely not
> something you're going to want in dunfell sadly.
>

Thanks for the clarification.


>
> Cheers,
>
> Richard
>
>

-- 
Best regards,

José Quaresma

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

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Richard Purdie]

On Thu, 2021-11-04 at 20:00 +0000, Jose Quaresma wrote:
> 
> 
> Richard Purdie <richard.purdie@linuxfoundation.org> escreveu no dia quinta,
> 28/10/2021 à(s) 21:58:
> > On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
> > > On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma <quaresma.jose@gmail.com>
> > wrote:
> > > > 
> > > > Hi all,
> > > > 
> > > > There are any plans or is it possible to backport the SBOM/SPDX to the
> > dunfell branch?
> > > 
> > > I'm going to yield to Saul as to whether he thinks this is
> > > desirable/possible or not.
> > 
> > The packagedata changes are pretty invasive unfortunately and likely not
> > something you're going to want in dunfell sadly.
> > 
> 
> 
> Thanks for the clarification.
> 

I have been thinking a bit more about this. I did wonder if we should consider a
mixin layer of some kind for it that could work with dunfell?

We could host it, it is just a question of writing the mixin layer and
maintaining it.

Cheers,

Richard

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Joshua Watt]

On 11/4/21 3:43 PM, Richard Purdie wrote:
> On Thu, 2021-11-04 at 20:00 +0000, Jose Quaresma wrote:
>>
>> Richard Purdie <richard.purdie@linuxfoundation.org> escreveu no dia quinta,
>> 28/10/2021 à(s) 21:58:
>>> On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
>>>> On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma <quaresma.jose@gmail.com>
>>> wrote:
>>>>> Hi all,
>>>>>
>>>>> There are any plans or is it possible to backport the SBOM/SPDX to the
>>> dunfell branch?
>>>> I'm going to yield to Saul as to whether he thinks this is
>>>> desirable/possible or not.
>>> The packagedata changes are pretty invasive unfortunately and likely not
>>> something you're going to want in dunfell sadly.
>>>
>>
>> Thanks for the clarification.
>>
> I have been thinking a bit more about this. I did wonder if we should consider a
> mixin layer of some kind for it that could work with dunfell?
>
> We could host it, it is just a question of writing the mixin layer and
> maintaining it.

I don't think it's going to be possible with a pure mixin layer, since 
it relies on the extended package data?


>
> Cheers,
>
> Richard
>

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Richard Purdie]

On Thu, 2021-11-04 at 15:45 -0500, Joshua Watt wrote:
> On 11/4/21 3:43 PM, Richard Purdie wrote:
> > On Thu, 2021-11-04 at 20:00 +0000, Jose Quaresma wrote:
> > > 
> > > Richard Purdie <richard.purdie@linuxfoundation.org> escreveu no dia quinta,
> > > 28/10/2021 à(s) 21:58:
> > > > On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
> > > > > On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma <quaresma.jose@gmail.com>
> > > > wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > There are any plans or is it possible to backport the SBOM/SPDX to the
> > > > dunfell branch?
> > > > > I'm going to yield to Saul as to whether he thinks this is
> > > > > desirable/possible or not.
> > > > The packagedata changes are pretty invasive unfortunately and likely not
> > > > something you're going to want in dunfell sadly.
> > > > 
> > > 
> > > Thanks for the clarification.
> > > 
> > I have been thinking a bit more about this. I did wonder if we should consider a
> > mixin layer of some kind for it that could work with dunfell?
> > 
> > We could host it, it is just a question of writing the mixin layer and
> > maintaining it.
> 
> I don't think it's going to be possible with a pure mixin layer, since 
> it relies on the extended package data?

I suspect that could perhaps be patched in through a layer though? You might
choose to drop the compression piece or do it differently for the backport?

Cheers,

Richard

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Joshua Watt]

On 11/4/21 3:50 PM, Richard Purdie wrote:
> On Thu, 2021-11-04 at 15:45 -0500, Joshua Watt wrote:
>> On 11/4/21 3:43 PM, Richard Purdie wrote:
>>> On Thu, 2021-11-04 at 20:00 +0000, Jose Quaresma wrote:
>>>> Richard Purdie <richard.purdie@linuxfoundation.org> escreveu no dia quinta,
>>>> 28/10/2021 à(s) 21:58:
>>>>> On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
>>>>>> On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma <quaresma.jose@gmail.com>
>>>>> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> There are any plans or is it possible to backport the SBOM/SPDX to the
>>>>> dunfell branch?
>>>>>> I'm going to yield to Saul as to whether he thinks this is
>>>>>> desirable/possible or not.
>>>>> The packagedata changes are pretty invasive unfortunately and likely not
>>>>> something you're going to want in dunfell sadly.
>>>>>
>>>> Thanks for the clarification.
>>>>
>>> I have been thinking a bit more about this. I did wonder if we should consider a
>>> mixin layer of some kind for it that could work with dunfell?
>>>
>>> We could host it, it is just a question of writing the mixin layer and
>>> maintaining it.
>> I don't think it's going to be possible with a pure mixin layer, since
>> it relies on the extended package data?
> I suspect that could perhaps be patched in through a layer though? You might
> choose to drop the compression piece or do it differently for the backport?


I'm not sure if a layer could hook in well enough to get the data 
needed...  maybe worth an experiment though


With a backport, I would probably either use GZip compression or no 
compression. The zstd compression was designed as a drop in replacement 
for Gzip if we wanted to go that route.

>
> Cheers,
>
> Richard
>

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Saul Wold]

On 11/4/21 2:20 PM, Joshua Watt wrote:
> 
> On 11/4/21 3:50 PM, Richard Purdie wrote:
>> On Thu, 2021-11-04 at 15:45 -0500, Joshua Watt wrote:
>>> On 11/4/21 3:43 PM, Richard Purdie wrote:
>>>> On Thu, 2021-11-04 at 20:00 +0000, Jose Quaresma wrote:
>>>>> Richard Purdie <richard.purdie@linuxfoundation.org> escreveu no dia 
>>>>> quinta,
>>>>> 28/10/2021 à(s) 21:58:
>>>>>> On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
>>>>>>> On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma 
>>>>>>> <quaresma.jose@gmail.com>
>>>>>> wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> There are any plans or is it possible to backport the SBOM/SPDX 
>>>>>>>> to the
>>>>>> dunfell branch?
>>>>>>> I'm going to yield to Saul as to whether he thinks this is
>>>>>>> desirable/possible or not.
>>>>>> The packagedata changes are pretty invasive unfortunately and 
>>>>>> likely not
>>>>>> something you're going to want in dunfell sadly.
>>>>>>
>>>>> Thanks for the clarification.
>>>>>
>>>> I have been thinking a bit more about this. I did wonder if we 
>>>> should consider a
>>>> mixin layer of some kind for it that could work with dunfell?
>>>>
>>>> We could host it, it is just a question of writing the mixin layer and
>>>> maintaining it.
>>> I don't think it's going to be possible with a pure mixin layer, since
>>> it relies on the extended package data?
>> I suspect that could perhaps be patched in through a layer though? You 
>> might
>> choose to drop the compression piece or do it differently for the 
>> backport?
> 
> 
> I'm not sure if a layer could hook in well enough to get the data 
> needed...  maybe worth an experiment though
> 
Yeah, I am not sure an mixin could track the changes for package.bbclass
> 
> With a backport, I would probably either use GZip compression or no 
> compression. The zstd compression was designed as a drop in replacement 
> for Gzip if we wanted to go that route.
> 
I will say that we did something similar with Hardknott for WRLinux, but 
did not propose it upstream as Hardknott was knot going to be supported 
longer term.

Having the spdx class standalone with the correctly backported changes 
seems to be working

Sau!
>>
>> Cheers,
>>
>> Richard
>>

-- 
Sau!

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Paul Eggleton]

On Tuesday, 9 November 2021 08:01:38 NZDT Saul Wold wrote:
> On 11/4/21 2:20 PM, Joshua Watt wrote:
> > On 11/4/21 3:50 PM, Richard Purdie wrote:
> >> On Thu, 2021-11-04 at 15:45 -0500, Joshua Watt wrote:
> >>> On 11/4/21 3:43 PM, Richard Purdie wrote:
> >>>> On Thu, 2021-11-04 at 20:00 +0000, Jose Quaresma wrote:
> >>>>> Richard Purdie <richard.purdie@linuxfoundation.org> escreveu no dia
> >>>>> quinta,
> >>>>> 
> >>>>> 28/10/2021 à(s) 21:58:
> >>>>>> On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
> >>>>>>> On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma
> >>>>>>> <quaresma.jose@gmail.com>
> >>>>>> 
> >>>>>> wrote:
> >>>>>>>> Hi all,
> >>>>>>>> 
> >>>>>>>> There are any plans or is it possible to backport the SBOM/SPDX
> >>>>>>>> to the
> >>>>>> 
> >>>>>> dunfell branch?
> >>>>>> 
> >>>>>>> I'm going to yield to Saul as to whether he thinks this is
> >>>>>>> desirable/possible or not.
> >>>>>> 
> >>>>>> The packagedata changes are pretty invasive unfortunately and
> >>>>>> likely not
> >>>>>> something you're going to want in dunfell sadly.
> >>>>> 
> >>>>> Thanks for the clarification.
> >>>> 
> >>>> I have been thinking a bit more about this. I did wonder if we
> >>>> should consider a
> >>>> mixin layer of some kind for it that could work with dunfell?
> >>>> 
> >>>> We could host it, it is just a question of writing the mixin layer and
> >>>> maintaining it.
> >>> 
> >>> I don't think it's going to be possible with a pure mixin layer, since
> >>> it relies on the extended package data?
> >> 
> >> I suspect that could perhaps be patched in through a layer though? You
> >> might
> >> choose to drop the compression piece or do it differently for the
> >> backport?
> > 
> > I'm not sure if a layer could hook in well enough to get the data
> > needed...  maybe worth an experiment though
> 
> Yeah, I am not sure an mixin could track the changes for package.bbclass
> 
> > With a backport, I would probably either use GZip compression or no
> > compression. The zstd compression was designed as a drop in replacement
> > for Gzip if we wanted to go that route.
> 
> I will say that we did something similar with Hardknott for WRLinux, but
> did not propose it upstream as Hardknott was knot going to be supported
> longer term.
> 
> Having the spdx class standalone with the correctly backported changes
> seems to be working

FYI Andres and I have done this backport to dunfell - should I post it? That 
said, I did just take the hit on some of the invasive parts (e.g. LICENSE 
value changes). I think given regulatory requirements this is important for 
lots of folks, so we probably need to do something here. Happy to be part of 
it.

Cheers
Paul

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Jose Quaresma]

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

Hi Paul,

Great to hear it.

I think the SPDX/SBOM will be useful for a bunch of users/companies that
currently use the yocto LTS dunfell.
It will be an awesome improvement if we have the SPDX/SBOM supported and
even more given that the dunfel
branch support has been extended for more than 2 years, until Apr. 2024.

I would be very happy if I could help in any way.

Jose

Paul Eggleton <bluelightning@bluelightning.org> escreveu no dia segunda,
15/11/2021 à(s) 22:44:

> On Tuesday, 9 November 2021 08:01:38 NZDT Saul Wold wrote:
> > On 11/4/21 2:20 PM, Joshua Watt wrote:
> > > On 11/4/21 3:50 PM, Richard Purdie wrote:
> > >> On Thu, 2021-11-04 at 15:45 -0500, Joshua Watt wrote:
> > >>> On 11/4/21 3:43 PM, Richard Purdie wrote:
> > >>>> On Thu, 2021-11-04 at 20:00 +0000, Jose Quaresma wrote:
> > >>>>> Richard Purdie <richard.purdie@linuxfoundation.org> escreveu no
> dia
> > >>>>> quinta,
> > >>>>>
> > >>>>> 28/10/2021 à(s) 21:58:
> > >>>>>> On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
> > >>>>>>> On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma
> > >>>>>>> <quaresma.jose@gmail.com>
> > >>>>>>
> > >>>>>> wrote:
> > >>>>>>>> Hi all,
> > >>>>>>>>
> > >>>>>>>> There are any plans or is it possible to backport the SBOM/SPDX
> > >>>>>>>> to the
> > >>>>>>
> > >>>>>> dunfell branch?
> > >>>>>>
> > >>>>>>> I'm going to yield to Saul as to whether he thinks this is
> > >>>>>>> desirable/possible or not.
> > >>>>>>
> > >>>>>> The packagedata changes are pretty invasive unfortunately and
> > >>>>>> likely not
> > >>>>>> something you're going to want in dunfell sadly.
> > >>>>>
> > >>>>> Thanks for the clarification.
> > >>>>
> > >>>> I have been thinking a bit more about this. I did wonder if we
> > >>>> should consider a
> > >>>> mixin layer of some kind for it that could work with dunfell?
> > >>>>
> > >>>> We could host it, it is just a question of writing the mixin layer
> and
> > >>>> maintaining it.
> > >>>
> > >>> I don't think it's going to be possible with a pure mixin layer,
> since
> > >>> it relies on the extended package data?
> > >>
> > >> I suspect that could perhaps be patched in through a layer though? You
> > >> might
> > >> choose to drop the compression piece or do it differently for the
> > >> backport?
> > >
> > > I'm not sure if a layer could hook in well enough to get the data
> > > needed...  maybe worth an experiment though
> >
> > Yeah, I am not sure an mixin could track the changes for package.bbclass
> >
> > > With a backport, I would probably either use GZip compression or no
> > > compression. The zstd compression was designed as a drop in replacement
> > > for Gzip if we wanted to go that route.
> >
> > I will say that we did something similar with Hardknott for WRLinux, but
> > did not propose it upstream as Hardknott was knot going to be supported
> > longer term.
> >
> > Having the spdx class standalone with the correctly backported changes
> > seems to be working
>
> FYI Andres and I have done this backport to dunfell - should I post it?
> That
> said, I did just take the hit on some of the invasive parts (e.g. LICENSE
> value changes). I think given regulatory requirements this is important
> for
> lots of folks, so we probably need to do something here. Happy to be part
> of
> it.
>
> Cheers
> Paul
>
>
>
>
>

-- 
Best regards,

José Quaresma

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

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Saul Wold]

On 11/15/21 2:44 PM, Paul Eggleton wrote:
> On Tuesday, 9 November 2021 08:01:38 NZDT Saul Wold wrote:
>> On 11/4/21 2:20 PM, Joshua Watt wrote:
>>> On 11/4/21 3:50 PM, Richard Purdie wrote:
>>>> On Thu, 2021-11-04 at 15:45 -0500, Joshua Watt wrote:
>>>>> On 11/4/21 3:43 PM, Richard Purdie wrote:
>>>>>> On Thu, 2021-11-04 at 20:00 +0000, Jose Quaresma wrote:
>>>>>>> Richard Purdie <richard.purdie@linuxfoundation.org> escreveu no dia
>>>>>>> quinta,
>>>>>>>
>>>>>>> 28/10/2021 à(s) 21:58:
>>>>>>>> On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
>>>>>>>>> On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma
>>>>>>>>> <quaresma.jose@gmail.com>
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> There are any plans or is it possible to backport the SBOM/SPDX
>>>>>>>>>> to the
>>>>>>>>
>>>>>>>> dunfell branch?
>>>>>>>>
>>>>>>>>> I'm going to yield to Saul as to whether he thinks this is
>>>>>>>>> desirable/possible or not.
>>>>>>>>
>>>>>>>> The packagedata changes are pretty invasive unfortunately and
>>>>>>>> likely not
>>>>>>>> something you're going to want in dunfell sadly.
>>>>>>>
>>>>>>> Thanks for the clarification.
>>>>>>
>>>>>> I have been thinking a bit more about this. I did wonder if we
>>>>>> should consider a
>>>>>> mixin layer of some kind for it that could work with dunfell?
>>>>>>
>>>>>> We could host it, it is just a question of writing the mixin layer and
>>>>>> maintaining it.
>>>>>
>>>>> I don't think it's going to be possible with a pure mixin layer, since
>>>>> it relies on the extended package data?
>>>>
>>>> I suspect that could perhaps be patched in through a layer though? You
>>>> might
>>>> choose to drop the compression piece or do it differently for the
>>>> backport?
>>>
>>> I'm not sure if a layer could hook in well enough to get the data
>>> needed...  maybe worth an experiment though
>>
>> Yeah, I am not sure an mixin could track the changes for package.bbclass
>>
>>> With a backport, I would probably either use GZip compression or no
>>> compression. The zstd compression was designed as a drop in replacement
>>> for Gzip if we wanted to go that route.
>>
>> I will say that we did something similar with Hardknott for WRLinux, but
>> did not propose it upstream as Hardknott was knot going to be supported
>> longer term.
>>
>> Having the spdx class standalone with the correctly backported changes
>> seems to be working
> 
> FYI Andres and I have done this backport to dunfell - should I post it? That
> said, I did just take the hit on some of the invasive parts (e.g. LICENSE
> value changes). I think given regulatory requirements this is important for
> lots of folks, so we probably need to do something here. Happy to be part of
> it.
> 
Hi Paul, Andres:

We talked about this during the Tech Call this morning and the consensus 
was that this work should be done in a mix-in style layer so that it 
could be used by multiple releases.

The LICENSE value changes could be handled by a single file with 
LICENSE_<package> style overrides in the mix-in layer, or by a set of 
bbappends in the mix-in layer.

Did you include the compression changes or convert that back to basic XZ 
compression?

We realize that this make for more work, but it's the problem of 
backporting a feature to the release vs having the feature in a separate 
mix-in.

Hope this is clear.

Sau!

> Cheers
> Paul
> 
> 
> 
> 

-- 
Sau!

Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

[Saul Wold]

On 11/16/21 8:39 AM, Saul Wold wrote:
> 
> 
> On 11/15/21 2:44 PM, Paul Eggleton wrote:
>> On Tuesday, 9 November 2021 08:01:38 NZDT Saul Wold wrote:
>>> On 11/4/21 2:20 PM, Joshua Watt wrote:
>>>> On 11/4/21 3:50 PM, Richard Purdie wrote:
>>>>> On Thu, 2021-11-04 at 15:45 -0500, Joshua Watt wrote:
>>>>>> On 11/4/21 3:43 PM, Richard Purdie wrote:
>>>>>>> On Thu, 2021-11-04 at 20:00 +0000, Jose Quaresma wrote:
>>>>>>>> Richard Purdie <richard.purdie@linuxfoundation.org> escreveu no dia
>>>>>>>> quinta,
>>>>>>>>
>>>>>>>> 28/10/2021 à(s) 21:58:
>>>>>>>>> On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
>>>>>>>>>> On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma
>>>>>>>>>> <quaresma.jose@gmail.com>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> There are any plans or is it possible to backport the SBOM/SPDX
>>>>>>>>>>> to the
>>>>>>>>>
>>>>>>>>> dunfell branch?
>>>>>>>>>
>>>>>>>>>> I'm going to yield to Saul as to whether he thinks this is
>>>>>>>>>> desirable/possible or not.
>>>>>>>>>
>>>>>>>>> The packagedata changes are pretty invasive unfortunately and
>>>>>>>>> likely not
>>>>>>>>> something you're going to want in dunfell sadly.
>>>>>>>>
>>>>>>>> Thanks for the clarification.
>>>>>>>
>>>>>>> I have been thinking a bit more about this. I did wonder if we
>>>>>>> should consider a
>>>>>>> mixin layer of some kind for it that could work with dunfell?
>>>>>>>
>>>>>>> We could host it, it is just a question of writing the mixin 
>>>>>>> layer and
>>>>>>> maintaining it.
>>>>>>
>>>>>> I don't think it's going to be possible with a pure mixin layer, 
>>>>>> since
>>>>>> it relies on the extended package data?
>>>>>
>>>>> I suspect that could perhaps be patched in through a layer though? You
>>>>> might
>>>>> choose to drop the compression piece or do it differently for the
>>>>> backport?
>>>>
>>>> I'm not sure if a layer could hook in well enough to get the data
>>>> needed...  maybe worth an experiment though
>>>
>>> Yeah, I am not sure an mixin could track the changes for package.bbclass
>>>
>>>> With a backport, I would probably either use GZip compression or no
>>>> compression. The zstd compression was designed as a drop in replacement
>>>> for Gzip if we wanted to go that route.
>>>
>>> I will say that we did something similar with Hardknott for WRLinux, but
>>> did not propose it upstream as Hardknott was knot going to be supported
>>> longer term.
>>>
>>> Having the spdx class standalone with the correctly backported changes
>>> seems to be working
>>
>> FYI Andres and I have done this backport to dunfell - should I post 
>> it? That
>> said, I did just take the hit on some of the invasive parts (e.g. LICENSE
>> value changes). I think given regulatory requirements this is 
>> important for
>> lots of folks, so we probably need to do something here. Happy to be 
>> part of
>> it.
>>
> Hi Paul, Andres:
> 
> We talked about this during the Tech Call this morning and the consensus 
> was that this work should be done in a mix-in style layer so that it 
> could be used by multiple releases.
> 
> The LICENSE value changes could be handled by a single file with 
> LICENSE_<package> style overrides in the mix-in layer, or by a set of 
> bbappends in the mix-in layer.
> 
minor correct: LIENCE_pn-<package_name>


> Did you include the compression changes or convert that back to basic XZ 
> compression?
> 
> We realize that this make for more work, but it's the problem of 
> backporting a feature to the release vs having the feature in a separate 
> mix-in.
> 
> Hope this is clear.
> 
> Sau!
> 
>> Cheers
>> Paul
>>
>>
>>
>>
> 

-- 
Sau!