> Op 5 feb 2026, om 16:12 heeft Ross Burton <[email protected]> het volgende
> geschreven:
>
> 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 completely agree with that, after talking to a lot of people at FOSDEM, the
OE workshop and coworkers, I've been working on a proposal which has this:
"The goal of this layer is to host AI/ML related recipes that need compilation
as well as the absolute minimum of binary-only items to make testing possible,
ideally only the mobilenet model."
That is my attempt at keeping it broad enough as well as narrow enough to make
the most people happy (don't mention Goldilocks!)
> 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.
Sure, the more people involved, the better!
> 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?
I already had this written down:
"Vendor specific changes need careful consideration, backports should be fine,
but changes under upstream review or unsubmitted changes should live in their
vendor layer as bbappends."
As for maintenance, I'd really like to be able to use git{hub,lab} like pull
requests to have proper 2 way communication, but I suspect a separate
mailinglist with patchwork+b4 would get us most of the way there.
regards,
Koen
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2246):
https://lists.openembedded.org/g/openembedded-architecture/message/2246
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]]
-=-=-=-=-=-=-=-=-=-=-=-
