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

Hi Richard, <snip> I didn't mean to bring up old discussions :-) All I was trying to say is that one day I had the idea that it would be nice if we had something similar to the kernel's checkpatch.pl

This all sounds like an improvement and is therefore a step in the right direction :-) A while back I had the idea of "porting" the kernel's "checkpatch.pl" to The Yocto Project (it was around the sam

Hi, Now that registration is open for ELC, it would be a good time to find out if there are any plans for any post-ELC activities? Best regards, Trevor

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

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

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 s

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.

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

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 performance,

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

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 C

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

Hi We cache size of off_t in site files and the value is 4 in most cases meta/site/arm-linux:ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=4} meta/site/ix86-common:ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=4}

Hi, We emulate G4/mac99 when using qemuppc target and kernel is in sync with this as well where we enable 6xx features + altivec However the toolchain defaults are assuming e500 core. COLLECT_GCC_OPTI

Hi This is FYI, as I have sent a RFT for glibc 2.24, there might be another change coming which is under discussion on glibc mailing lists which is on supported minimum kernel version bump to 3.2 sinc

Thanks, its like 10month ahead of time warning so no one then forces to keep us using 2.6.32 you have been informed

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

Indeed, it's a very welcome change from my point of view! +1 -- olofjn

I absolutely support this. It should reduce confusion with no loss of functionality. Acked-by: Christopher Larson <kergoth@...> -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEm