<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><span></span></div><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"><span></span></div><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"><span></span></div><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"><span></span></div><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"></div><div dir="ltr">On Feb 22, 2019, at 02:35, Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>> wrote:</div><div dir="ltr"><br></div><blockquote type="cite"><div dir="ltr"><span>On Thu, 2019-02-21 at 20:09 -0500, Rich Persaud wrote:</span><br><blockquote type="cite"><blockquote type="cite"><span>On Feb 21, 2019, at 18:51, Richard Purdie <</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Multiconfig is meant to support this workflow. Unfortunately there</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>are</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>open bugs and people haven't the time to work on it so its stalled.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>That said, the key pieces are already there.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>A picture is worth a thousand words. I thought a demo might</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>interest</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>people and "prove" this can work.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Thank you for the patches and PoC. We will test and are motivated to</span><br></blockquote><blockquote type="cite"><span>see this work.</span><br></blockquote><span></span><br><span>I've been thinking about what Alejandro and I discussed and I think the</span><br><span>correct fix for the multiconfig code is to filter the BB_TASKDEPDATA at</span><br><span>source in bitbake to remove the multiconfig entries for other</span><br><span>multiconfigs. I'll try and work up a patch for that in the next day or</span><br><span>two as the hacks on my branch that do this are fragile right now.</span><br></div></blockquote><div><br></div><div>Looks like the patches are in bitbake 1.40. </div><div><br></div><div>Is it possible to avoid duplicate builds of packages which are used in multiple VM images? Could multiconfig replace a dozen serial instances of bitbake with a single parsing instance, or would it use a dozen parallel instances? If the latter, is this a constraint in bitbake architecture, recipe DSL, or time/resources?</div><div><br></div><blockquote type="cite"><div dir="ltr"><span></span><blockquote type="cite"><span>I will also be experimenting with the generation of "immutable</span><br></blockquote><blockquote type="cite"><span>infrastructure" from source code, to learn whether a single <a href="http://Packer.io">Packer.io</a></span><br></blockquote><blockquote type="cite"><span>template can be used to both:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>(a) modify binary images, in the traditional Packer model, e.g. start</span><br></blockquote><blockquote type="cite"><span>a bitbake-generated image in a VM or container, make runtime</span><br></blockquote><blockquote type="cite"><span>configuration changes, then repack the machine image</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>(b) perform automated customization of _inputs_ to bitbake recipes</span><br></blockquote><blockquote type="cite"><span>and package source code, such that a machine image built by bitbake +</span><br></blockquote><blockquote type="cite"><span>Packer template is equivalent to the image generated by Packer at</span><br></blockquote><blockquote type="cite"><span>runtime</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>If feasible, this would combine the agility of image customizations</span><br></blockquote><blockquote type="cite"><span>with the security of bitbake's reproducible builds and supply chain</span><br></blockquote><blockquote type="cite"><span>integrity.</span><br></blockquote><span></span><br><span>(a) definitely sounds easier than (b). I've not used <a href="http://packer.io">packer.io</a> but I'd</span><br><span>be curious to see how that works out. People do find our image</span><br><span>customisation hard to get to grips with :(</span><br></div></blockquote><br><div>Siemens 'kas' provides a declarative front-end for bitbake configuration, a small step in the direction of (b):</div><div><br></div><div><a href="https://kas.readthedocs.io/en/0.19.0/userguide.html#use-cases">https://kas.readthedocs.io/en/0.19.0/userguide.html#use-cases</a></div><div><a href="https://github.com/siemens/kas">https://github.com/siemens/kas</a></div><div><a href="https://groups.google.com/forum/#!forum/kas-devel">https://groups.google.com/forum/#!forum/kas-devel</a></div><div><br></div><div>Rich</div></div></div></div></div></body></html>