Meeting started at 2026-02-12 17:31:02 UTC

The Meeting name is 'fedora-ai-ml-sig'

!hi

Alexander Lent (xanderlent) - he / him / his

!hi

Tim Flink (tflink)

Alexander Lent: I pulled your agenda item from last meeting to this meeting. I assume it's still relevant

tflink: Thanks

!hi

Gordon Messmer (gordonmessmer)

ok, let's get this party started

!hi

None (mystro256)

at this point, this is an FYI and looking for comments and additions.

rocm 8 will likely break things like 7 did. i'd like not to go through that again, so more planning..

is the compatibility proposal a prerequisite of the 8.x feature?

it's is the big new thing i think will help the most and be a large chunk of the F45 work. i am also looking for other suggestions and help for other things.

i am not sure of the actual release of 8, so want to front load the compat things asap, starting now if possible.

in the past llvm-compat landed so late, it was hard to use.

we could also do some trials with the 7.1x releases in COPRs to see how well things are working

that compat devel work happened on 7.1.1, there is a copr listed in the hc/sig page.

atm problem is new, first package rocm-filesystem needs a --with compat flavor.

yeah, I imagine that the filesystem layout is going to be one of the biggest changes

I really need to read through all of those things, have been up to my eyeballs in ubuntu lately though

i believe /usr/lib64/rocm/rocm-<maj>.<min> is close to what AMD does with its releases to /opt/rocm/rocm-<maj>.<min>

no one has expressed any strong other opinions, so going with that.

the big question I haven't figured out, since i haven't read the proposal in detail, is how things like blender or pytorch might choose which version/stream to use

but I'll get to that outside the meeting

i will be moving python to the compat 7.2 when i do the update to 2.10

is there anything in particular that you wanted to cover today or more making folks aware of the feature and remind about the compat proposal?

just aware, comments and such can go into the change proposal discussion page.

ok, moving on to the next topic

Alexander Lent: this is yours, take it away

Sure, so upstream ggml.ai/ggml-org is now allowing distros to unbundle their flagship library, also called ggml or libggml.

fwiw, this is how the debian ecosystem handles libggml

and llama-cpp releaes will use it ? or their own copy ?

Yep, the Debian folks got the ball rolling upstream.

you can make the llama.cpp build use a system libggml

there's a cmake option for it, IIRC

So, with whisper.cpp, the releases seem mostly coordinated (with comparability between 0.9.x releases of GGML).

For llama.cpp, we may need to keep bundling since it is the source of most of the commits to the GGML library and bundles intermediate versions in releases.

sure, but is the library sync-ed to some llama-cpp release ? llama-cpp has a crazy release an hour thing going,

Yes, exactly the issue - I've been trying to determine if we can figure out which releases are synced in an automated way

ah i see question answered.

ah, not sure about that one. I haven't looked into it other than poking at the debian packages

That said, I don't intend to force any other packages to unbundle GGML by introducing it; for ollama it would be impractical given their custom fork.

i had been trying to sync llama-cpp to python-llama-cpp, but python- side went their own way.

I wanted to more make sure we had it available and figured we could work from there

oof, was not aware of this

ollama is loving its vendor-ed go things and I will not switch in the short term.

tflink: That's unfortunately not accurate; upstream is now extracting ggml from llama.cpp and allowing it to be used independently, but llama.cpp is the canonical source

!hi

Neal Gompa (ngompa) - he / him / his

ah, ok. thanks for the correction

!unduo

sorry too many meetings

!undo

!undo

Alexander Lent: is that more accurate?

Yes, thank you!

the big benefit to building the backends once is we can flip on features everywhere and allow users to install backends (ROCm, BLAS, CPU, Vulkan) on demand

we'll see how the new meetbot handles undo, I haven't used it much since it came out

it is not implemented

there is no undo command

oh, you might think that I would notice that there is no response from the bot

but apparently not

I ended up working on GGML since we were trying to flip on Vulkan in all the users of it; doing it once for GGML and getting the benefit in downstreams may make maintenance easier.

anyway, the review is in progress, please feel free to comment on it

someone can try to implement undo in https://github.com/GregSutcliffe/maubot-meetings

Alexander Lent: do you have a link to the review handy?

tflink: https://bugzilla.redhat.com/show_bug.cgi?id=2430570

thanks

anything else on this topic?

nope

ok, moving on

after it was just tom and I for the last meeting, I started wondering if this time still worked for people and I posted about it on discourse

https://discussion.fedoraproject.org/t/fedora-ai-ml-sig-meeting-schedule/180276

a half hour earlier would be good. i am on 2 meeting now

there hadn't been much feedback so far, I was inclined to not change anything

this used to be a 1/2 hr meeting, with an hour, it's a little weird.

For me, 16:00 UTC to 19:00 UTC lines up with lunch at $DAYJOB, so around the current time works well for me.

But I'm not committed to a specific time

I also had a very nice email conversation with Red Hat's CPT team in Brno, they are interested in AI/ML work, but the current meeting time is a little too late for them, IIUC.

CPT?

They build COPR, mock, rpkg, distro-gpg-keys, etc. Some of the core packaging stuff.

Their big initiative last year was LogDetective - training a model on rpmbuild outputs

ah, ok. I didn't know the team name

it sounds like there is some interest in changing the time, am I hearing correctly?

It also doesn't sound like there is anyone who has strong feelings about it :)

Hi, I have a conflict today, but will try to join in next time! I want to spend some more time following what this SIG is up to 👀

It also sounds like Tom would prefer a bit earlier.

Maybe we could try to reach out to the CPT folks about what their constraints might be? I can definitely email them back, though I can't speak for them at this time.

either way, I don't think we're going to get it figured out in meeting

If looking for app developers, the COPR folks and Packit folks might be good people to ask, but yeah, I think most/all of them are in Brno?

(I mean they are good to ask because I have seen them doing stuff with AI like Log Detective, etc.)

and it's 19:00 CET so yeah, a bit late for them

agreed

I'm temporarily in Europe right now, which is why this time is a tad late for me today 😄

/me will read back later 👋🏻

how about this: someone reach out to the potentially interested folks in brno and if there is enough interest, we can have the scheduling discussion offline in matrix and on discourse?

Would one of the folks from RH be able to do that outreach? I'll mention it by email but I'm not in the org.

I can follow up on that

thanks

if they're interested, getting an idea of how early it would need to be would be nice

unfortunately, there's not a ton of sane time overlap between CET and western NA

anything else on this? I think that's about all we can reasonably get to today

anything other topics for the meeting today?

one-line item: python-tokenizers is in F44 and rawhide now

that's all from me :)

thanks

anything else?

OK, thanks for coming, everyone