On Sat, Nov 21, 2020 at 7:48 AM Robert P. J. Day <rpjday@...> wrote: %< SNIP %< pedantically speaking, since you're using "+=", you don't need those leading spaces. Indeed you are correct.

On Sat, Nov 21, 2020 at 12:21 AM Chuck Wolber <chuckwolber@...> wrote: %< SNIP %< And finally, I have adjusted to using the following pattern, and found that it has improved maintainability a gr

Both will work, although you do run the risk of accidentally globbing files that you do not mean to include, but perhaps you know your recipes well enough that that is not a factor. Personally, I find

I have bumbled into a few recipes like that as well. It caused some concern because bitbake is supposed to avoid contamination like that. You can use the ERROR_QA variable to do compile-host-path and

Apologies for the marginally related reply, but the provided example triggered a reminder of a best practice we started doing that had some significant maintainability benefits. Instead of this patter

I do not know if this precisely answers your question, but creating bbclass functionality to create a different type of image may be the way to go. What you are suggesting sounds similar to this: http

Hi all, I have a need to unpack an ISO image during do_unpack. This does not appear to be one of the extensions that is handled by default, so I am working out a way to use xorriso to do this for me.

In that case, your best bet is to probably write a do_*_append() function into the bbappend recipe so you can jump in after one of the build steps and apply your patch during the appropriate stage. Re

Are you patching an existing upstream recipe? Or your own recipe? In the former case, you would use a .bbappend recipe. In either case, it all depends on how the service file is generated. If it is pa

Enthusiastic second to this. If you separate things too much, newbies get no sense of the depth of the project, and experienced people get less of a sense of the "newcomer pain points". Granted, this

Thanks! It sounds like I am not stepping into an historical tarpit then. There are so many references to patchutils in the Yocto ecosystem that I figured there just had to be some reason for the non-e

Hi, I checked the layer index (and google) and I find no references to a bitbake recipe for patchutils. Was there a conscious decision to not maintain a recipe for patchutils? Or is this something tha

Thanks for replying! That is effectively what we have to do with the VM clone of the build machine. We spin up the VM, do the build, see what is new in the downloads directory, do our due diligence, a

Hi All, Our build environment is stuck behind a firewall with no access to the Internet. When a Yocto build requires a new package, we normally extract the URL from the failed build log and "wget" the

It depends on a lot of factors. But for actually building yocto images... I find that 1.5 gigs of RAM per CPU seems to be about right on the virtual machines we use to build images. ..Ch:W..

Have you done any wireshark analysis on the traffic? My guess is that the round trip with network latency is bumping your build time by a factor of at least 100x. The state-cache is hammered on contin

Normally the source archive is unpacked first, which contains the license file. Is there something different with the source packaging for your recipe? ..Ch:W..

You have to refactor xslt-config out of the autotools macros and use pkg-config instead. This recipe is an example: meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.pat

I have run across this a few times, particularly with man pages, when including upstream packages into my images. I have to use a bbappend recipe in my meta layer to remove the lower priority version.

You have to refactor the Icecast bitbake recipe to use pkg-config instead of xslt-config. This patch might give you some ideas: meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-d