On Oct 28, 2019, at 09:46, Joshua Watt <jpewhac...@gmail.com> wrote: > >> On 10/28/19 5:55 AM, Rich Persaud wrote: >>> On Oct 28, 2019, at 6:23 AM, Adrian Bunk <b...@stusta.de> wrote: >>> Hi Rich, >>> >>> most of what you are writing is unfortunately quite far from the actual >>> problems regarding Yocto LTS. >>> >>> Yocto LTS might not happen at all due to a lack of resource commitments. >>> >>> Discussing what additional work could be done for Yocto LTS is >>> therefore not productive, unless you are the one doing this work. >>> >>> If you manage to convince your employer or a customer to make >>> a resource commitment for Yocto LTS, everyone would be extremely >>> grateful since this would help solving the biggest problem. >> As stated at the beginning of the thread, few companies can alone resource >> the work needed for LTS support, given the complexity of the software supply >> chain. As stated in the previous email, Linux Foundation, Google, Microsoft >> and RedHat today announced their pooled investment of resources into a test >> project (Kernel CI) with historical resource challenges. >> >> If long-term support for OpenEmbedded is not receiving sufficient resource >> investment, one question is: which similar projects *are* receiving >> investment? Two examples were provided, one based on OE/Yocto. Has Yocto >> asked Microsoft to contribute resources to Yocto LTS? Another question that >> can be posed to potential contributors: what changes to Yocto LTS scope >> (phase 1 or 2) would enable contribution of pooled resources? >> >> OpenXT uses OpenEmbedded to develop systems with hardware-assisted security >> properties. If Yocto LTS can reduce our existing test burden on real >> hardware, there is potential for collaboration. Currently-scoped Yocto LTS >> would not be a good fit for testing security properties, especially if the >> virtual test hardware is based on Ubuntu instead of OpenEmbedded >> meta-virtualization + bitbake guarantees for software supply chain integrity. > > I understand why this is desirable for a secure supply chain, but on the > other hand I wonder how this is different from the reference hardware > platforms that Yocto project already builds? The reference hardware platforms > certainly don't cover all the hardware that the project can run on, but you > can easily extended the project to run on whatever hardware you desire. > Similarly, just because the LTS release is only tested on Ubuntu LTS for > resource reason (which I personally think is a good idea), doesn't mean that > you can't also extended the LTS release in your own layer to do an OE-on-OE > build. > > Also, out of curiosity, how close is the build-appliance [1] image to what > you are looking for? If that's sufficient for your use cases (perhaps with > some minor tweaks), that is an image that the project already supports (and > tests) for the OE-on-OE build use case. If that is something that is useful, > allocating some resources to maintain that image in OE-core would be helpful > to the project overall. > > > [1] > https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/images/build-appliance-image_15.0.0.bb
Thanks. Since this is designed for VMware and VirtualBox, we can look into support for OE meta-virtualization. Rich _______________________________________________ Openembedded-architecture mailing list Openembedded-architecture@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
