On 31 Jan 2026, at 14:49, Koen Kooi via lists.openembedded.org <[email protected]> wrote: >>>> On Fri, 2026-01-30 at 13:20 +0800, hongxu via lists.openembedded.org wrote: >>>> Would you please approve to add this layer to >>>> https://git.yoctoproject.org/, I will maintain >>>> meta-ollama for recipe uprev and bug fix >>> Thanks for sharing this, it looks really interesting and I like the >>> idea of it a lot. > > Great timing as well :) I’m currently at FOSDEM asking around how people > would feel about a meta-ai layer that would have various bits in it: tflite, > onnx-runtime, llama.cpp and other things that need compilation. > > At the OE BoF this morning I was pointed at this thread, so I’ll hook into > that to ask: > > How would people feel about a layer that combines at least the runtimes and > has active maintainers? > > The amount of ai/ml recipes I touch daily has grown too large to stuff in in > the qcom-distro layer, but are also to spread out in other (vendor) layers to > include by default.
I agree with other comments that a hyper-focused meta-ollama isn’t ideal, considering that there are many pieces and they’ll often get mixed-and-matched by different people. Of course, the alternative of “meta-oe but for AI” isn’t ideal either, as whilst meta-oe is very accepting of new recipes it is arguably _too_ accepting: there’s a lot of unmaintained and unbuildable software in there (I acknowledge that recent changes to build meta-oe in the AB has managed to clear out a lot of the utterly broken recipes). I’m wondering if Hongxu and Koen would be open to co-maintaining a meta-ai (better name ideas welcome, maybe meta-llm?) layer with strict policies. For example: - Full automated build testing before patches are merged, to ensure that nothing breaks - Support for multiple architectures, so that BSP vendors can use the recipes and extend them easily as needed - Every recipe has an active maintainer - Removal of obsolete recipes from master This would mean we can consolidate common recipes, without the risk of turning into a collection of obsolete unmaintained software that BSP vendors forked from the year before. Does this sound like a direction that would be acceptable? Cheers, Ross
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2239): https://lists.openembedded.org/g/openembedded-architecture/message/2239 Mute This Topic: https://lists.openembedded.org/mt/117540395/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
