For future enhancements, I would want to keep some kind of record inside build/conf of where the original template was taken from. I agree that build init scripts should not use it at all, but

I'm starting a new thread/discussion on this with a new perspective. I did a little research myself on how these files are being used. My conclusion is that templateconf.cfg isn't really used by much

Bug filed: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14916 Not sure if I put it in the right category, so feel free to move it around if needed

Someone needs to do the work involved and I guess that hasn't happened. It isn't entirely simple as this does still exist in the other releases. Could you open a bug please so we don't forget

Hi all, I thought the agreement was to stop promoting meta-gplv2? Still I find it listed here - it somehow implies that this is still officially support, which everyone agreed it isn't Can this be

I need to read into the details but that looks like a great start and I'm happy to see the process being documented! Thanks for the link, I'll try and have a read. That makes sense, it is a tricky

Il 2022-09-16 17:49 Mark Hatle wrote: IMHO it's a matter of different ways of framing Yocto recipes into SPDX format. Upstream sources are all SPDX packages. Yocto layers are SPDX packages, too,

I certainly love the goal. I presume you're going to share your review criteria somehow? There must be some further set of steps, documentation and results beyond what we're discussing here? I think

On 9/16/22 10:18 AM, Alberto Pianon wrote: ... trimmed ... >> I also can see the issue with multiple sources in SRC_URI, although you >> should be able to map those back if you assume subtrees are

Hi Richard, thank you for your reply, you gave me very interesting cues to think about. I'll reply in reverse/importance order Il 2022-09-15 14:16 Richard Purdie wrote: We didn't paint the overall

I had a look at this and was a bit puzzled by some of it. I can see the issues you'd have if you want to separate the unpatched source from the patches and know which files had patches applied

When I last looked at this, it was critical that the analysis be: binary -> patched & configured source (dbg package) -> how the sources were constructed. As Joshua said above. I believe all of the

This is true, but I think that's more of a problem with the inability to express multiple download locations in the SPDX, not that we don't have all the source when we generate the SPDX, correct? I

Hi Joshua, nice to meet you! I'm new to this list, and I've always approached Yocto just from the "IP compliance side", so I may miss important pieces of information. That is why Marta encouraged me

I believe we map the binaries to the source code from the -dbg packages; is the premise that this is insufficient? Can you elaborate more on why that is, I don't quite understand. The debug sources

Dear all, (cross-posting to oe-core and *-architecture) In the last months, we have worked in Oniro on using the create-spdx class for both IP compliance and security. During this work, Alberto

I was asked about getting official support for the TOOLCHAIN variable in core. This is obviously late in the release cycle and after a bit of thought, the answer is no. I wanted to document why since

Hi, I took a deeper dive and made the python based patchtest work (c.f. https://github.com/HerrMuellerluedenscheid/patchtest and https://github.com/HerrMuellerluedenscheid/patchtest-oe). TBH: it

Hi Marius, Understandable, congratulations! :) This doesn't seem like a good direction to me. I have nothing against rust, I've spent the past couple of months trying to sort out rust support in

There’s definitely still interest in patchtest, but my personal opinion is that considering 99% of our code is Python keeping patchtest in python means that there are more people who can work on