Good question. We need to get these things scheduled soon. Philip

I don't think I'm alone in being a bit frustrated with the effort needed to get FILES_${PN}-dbg correct. I've just posted a patch to oe -core which automates this and means we can drop 99% of the

and the architecture list, this is something that should apply to more than OE-Core ideally. Cheers, Richard

I thought the exact same thing seconds after hitting send. I'll let the security and architecture people decide which list is best for discussion. What I do want to see is fewer discussions cross

Agreed, right now I just want people to get thinking about the right place for some of these discussions to happen too though. I suspect the right place is architecture since we're likely going

There is an initiative to track vulnerable software being built (see bugs 8119 and 7515). The idea is to have a testing tool that would check the recipe versions against CVEs. In order to accomplish

I just started the thread onto the architecture list, lets move move the discussion there. Here is the

FWIW I like the proposal as above adding a tag to the patches. If nobody objects to that we need to update the patch submission guidelines so that everyone is aware of this and then we can ask

My initial thought was "tag in filename" for convenience but the inability for a single patch to fix multiple CVEs is quite a downside, so agreed. Whilst we're updating the guidelines can we change

I'll just say hell yes :) Been hoping one of the implementations of this would get merged, glad to see it happening. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded,

I support the CVE proposal and also this :) We might also want to discuss the Pending upstream status. There seems to be a great deal of confusion among folks who think this means it's pending

It's too bad there wasn't an "INCOMPATIBLE_MACHINE" for when one machine/architecture stops being supported by a recipe. It would be easier than trying to list every other machine that is compatible.

COMPATIBLE_MACHINE is a regexp so you could use something like negative lookahead? COMPATIBLE_MACHINE = "^(?!.*somemachine).*$" I've not tested it but something like this should work in

Yep, I've been using it for years even back in Classic OE: http://arago-project.org/git/?p=arago.git;a=blob;f=recipes/meta/board-set.bb;hb=HEAD Basically, it's "(?!machinename)", but Richard's

I've heard complaints from people trying to create more interesting image types about how hard it is to understand the rootfs/image generation code and that its a pain to develop/test/debug. Having

To put this in a different why which people might be able to relate to, this changes: do_rootfs into: do_rootfs do_image do_image_ext4 do_image_tar do_image_complete (for IMAGE_FSTYPES = "tar.bz2

Hi Richard, I like this a lot. I'd idly considered this model before (as I'm sure others had) as it simplifies a lot of the multi-format image construction handling, improves incremental

Thanks for the feedback. Just as a heads up for people, I posted an updated patch set to the OE-Core list. This one has various issues fixed (including the todos) and is ready for wider

Agreed, that alone probably makes this change worthwhile in some ways. That is the intent, someone should be able to much more easily tap into and do other things with the generated data. It works

The conclusion of identify the CVE patches was to add a new tag in the metadata patch. Based on this I have updated the wiki to reflect the new policy. Hence all the new submitted patches that solve