One thing that bothers me at the moment is how long we spend in do_configure. I have some new build hardware but sadly whilst having quite a large parallel capacity, it spends a lot of time at idle an

I think the areas where there are disagreements are comparatively small, really just on shell whitespace. Where they do exist, they are problematic, not least as some layers effectively ignored an agr

At the time we fixed python functions to use four space indentation and no tabs. This matches python recommendations and avoided issues with some version of python which became stricter about whitespa

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 case

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

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 to wan

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 people

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 theory. Cheers

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 lo

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 ext4

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 testing. Cheer

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 bet

Times change and xz is becoming the defacto compression format and utility. It has better compression ratios than gz and similar compression/decompression times. Its better than bzip2 decompression in

Right now, if you have some python code like: X = "a" def somefunction(d): d.setVar("X", "b") d.setVar("Y", "${X}") then any sane person would expect that Y = "b" at the end of the function. This is n

At some point in the future, getVarFlag should expand by default. To get there from the current position, we need a period of time where the expand parameter is mandatory. This patch starts that proce

At some point in the future, getVar should expand by default. To get there from the current position, we need a period of time where the expand parameter is mandatory. This patch starts that process.

Most users expect the data to be expanded by default. Most call sites also use getVar(xxx, True), its uncommon to see expand=False, outside the core of bitbake. So the ultimate advantage is a more sen

Less ugly syntax, in 99.9% of usages, you would want expand=True and getVar("X") is neater than getVar("X", True). Cheers, Richard

If we go through the full transition, its possible something might silently break, if they skip the release where we require a value. We haven't reached that point yet and I'm honestly not sure how lo

I'm just thinking out loud here, I think the above is worth seriously considering. One big advantage "getVar" has is that its pretty unique and the python parsing code therefore doesn't get a lot of f