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.pur...@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.j...@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!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#158367):
https://lists.openembedded.org/g/openembedded-core/message/158367
Mute This Topic: https://lists.openembedded.org/mt/86616599/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
