<@tflink:fedora.im>
16:30:08
!startmeeting fedora-ai-ml-sig
<@meetbot:fedora.im>
16:30:09
Meeting started at 2025-03-27 16:30:08 UTC
<@meetbot:fedora.im>
16:30:09
The Meeting name is 'fedora-ai-ml-sig'
<@tflink:fedora.im>
16:30:15
!hi
<@zodbot:fedora.im>
16:30:16
Tim Flink (tflink)
<@dherrera:fedora.im>
16:30:32
!hi
<@zodbot:fedora.im>
16:30:33
Diego Herrera (dherrera) - he / him / his
<@mystro256:fedora.im>
16:31:51
!hi
<@zodbot:fedora.im>
16:31:52
None (mystro256)
<@xanderlent:fedora.im>
16:32:41
!hi
<@zodbot:fedora.im>
16:32:42
Alexander Lent (xanderlent)
<@tflink:fedora.im>
16:33:24
ok, let's get started
<@tflink:fedora.im>
16:33:48
!topic ROCm 6.4 Release
<@tflink:fedora.im>
16:33:56
@trix I think this is you?
<@trix:fedora.im>
16:34:35
yes. this is more informational, that 6.4 is coming and while it is happening rawhide rocm bits will be in flux.
<@tflink:fedora.im>
16:35:28
!info ROCm 6.4 will be released soon. While the Fedora packages are being updated, there may be some instability until those updates are complete
<@mystro256:fedora.im>
16:35:36
Yeah I'll be doing most of the work, Tom helping if need be
<@trix:fedora.im>
16:35:44
yup
<@mystro256:fedora.im>
16:35:49
upstream says release is "soon"
<@mystro256:fedora.im>
16:36:02
so I'll keep my eye on it
<@tflink:fedora.im>
16:36:27
cool, sounds good
<@tflink:fedora.im>
16:36:56
ok, moving on to the next (I think) quick one
<@tflink:fedora.im>
16:37:04
!topic Intel/AMD NPU Drivers
<@tflink:fedora.im>
16:37:16
Alexander Lent: I think this is yours?
<@xanderlent:fedora.im>
16:37:44
Yep, not much has changed. Biggest win is we have firmware for both in Fedora proper.
<@xanderlent:fedora.im>
16:38:08
Update your system and the kernel drivers will Just Work™.
<@tflink:fedora.im>
16:38:11
!info Firmware for both Intel and AMD NPUs is shipping for all Fedora branches
<@tflink:fedora.im>
16:38:46
it sounds like there is still work to be done for both the NPUs, though?
<@xanderlent:fedora.im>
16:38:56
Correct. I'm still working on both user-space drivers otherwise, relatively little progress since last meeting.
<@xanderlent:fedora.im>
16:39:19
On the AMD side they are seeking patches upstream so I'm going to get involved with their roadmap.
<@tflink:fedora.im>
16:39:19
!info work is still needed for the user-space drivers for both NPU stacks
<@xanderlent:fedora.im>
16:39:59
On the Intel side I need to sit down and think it out a bit.
<@xanderlent:fedora.im>
16:40:22
That's is everything for the NPU.
<@xanderlent:fedora.im>
16:40:38
That's everything for the NPU.
<@tflink:fedora.im>
16:40:42
cool, thanks for the update
<@tflink:fedora.im>
16:41:00
!topic Huggingface AI Libraries
<@tflink:fedora.im>
16:41:08
Alexander Lent: I think this is also yours
<@xanderlent:fedora.im>
16:41:33
Yep. First thing was a status update.
<@tflink:fedora.im>
16:41:59
not sure I understand what you mean by needing another review round
<@tflink:fedora.im>
16:42:22
does that mean that you've fixed some things and you want it to be reviewed again?
<@xanderlent:fedora.im>
16:42:45
Yes, I will work with @trix who is the reviewer on that.
<@tflink:fedora.im>
16:42:50
ah, ok
<@tflink:fedora.im>
16:43:10
!info python-safetensors has been updated and is ready for review again
<@trix:fedora.im>
16:43:27
ok, sorry i need get on that stat!
<@xanderlent:fedora.im>
16:43:54
No problem; we've both been busy recently. 🙂
<@tflink:fedora.im>
16:44:07
!info python-accelerate packaging will start soon
<@xanderlent:fedora.im>
16:44:28
<@xanderlent:fedora.im>
16:44:28
That's the whole bullet point.
<@xanderlent:fedora.im>
16:44:28
My plan is to submit python-accerlerate next, which is a pure-python package for automatically using accelerator hardware in PyTorch.
<@tflink:fedora.im>
16:45:20
Any thoughts on whether we want to push for a self-contained change about HF packages for F43?
<@xanderlent:fedora.im>
16:45:24
The final thing was that I've been thinking about listing the remaining Huggingface packages - there are about four or five main ones still TODO.
<@trix:fedora.im>
16:45:38
python-accelerate has a lot of dependencies, i do not think are met.
<@tflink:fedora.im>
16:45:54
Alexander Lent: do you think that they'll be done for F43, it sounds like there is quite a bit of work left
<@xanderlent:fedora.im>
16:46:32
<@xanderlent:fedora.im>
16:46:32
I think a formal change might help with marketing and/or coordinating all the work.
<@xanderlent:fedora.im>
16:46:32
I am not certain I'll have time for F43 given the amount of work. Perhaps I can write a draft and we can do it in the F44 cycle?
<@tflink:fedora.im>
16:47:06
sure, that can work. I think it's up to you whether you want to start drafting the change now or once the work is done
<@tflink:fedora.im>
16:47:10
I don't have a strong opinion on it
<@xanderlent:fedora.im>
16:47:58
OK, I wasn't sure what the process was. Since it's something we're doing incrementally, I think writing it up afterwards makes sense.
<@tflink:fedora.im>
16:48:33
there's not really a formal process that I know of until you get to the point of proposing the feature
<@xanderlent:fedora.im>
16:48:48
I think a lot of the dependencies are from extras that would not be packaged in Fedora, but I'll have to look into it. Thanks for the heads-up.
<@xanderlent:fedora.im>
16:49:30
Ok. I think that's all I have for today's meeting.
<@tflink:fedora.im>
16:49:51
ok, thanks for participating on top of all the work you're doing
<@tflink:fedora.im>
16:50:02
moving on to the last topic on the agenda for today
<@tflink:fedora.im>
16:50:13
!topic onnx-runtime backend
<@tflink:fedora.im>
16:50:21
Tom Rix: I think this is yours
<@trix:fedora.im>
16:51:32
so i have a PR that enable rocm backend and delivers as a seperate subpackage. does this seem like a good way to go for general adding backends to onnx-runtime ? and others more generally ?
<@tflink:fedora.im>
16:52:19
I don't pretend to know much about onnx but it makes sense to me
<@dherrera:fedora.im>
16:52:41
I'm a comaintainer of that package, I merged that PR today btw :)
<@trix:fedora.im>
16:52:57
oh.. question #1 answered.
<@tflink:fedora.im>
16:52:59
pulling in chunks of the rocm stack for folks who aren't interested in those accelerators seems like it would annoy people
<@trix:fedora.im>
16:53:14
yes, it does.
<@dherrera:fedora.im>
16:53:35
I had some ideas on alternatives on how to deliver that, but after researching they ended being inconvenient and had problems in their implementation, so I just went to merge yours :)
<@trix:fedora.im>
16:54:24
so next step is for me to see how connecting it to sourceextractor++ works.
<@dherrera:fedora.im>
16:55:08
honestly, idk how that would work either, and i'm interested since I also have a couple of packages that depend on that in COPR :)
<@trix:fedora.im>
16:55:08
goal would be something like a sourceextratorc++-rocm that installs to the default location
<@trix:fedora.im>
16:55:36
and doesn't step on anyone else.
<@tflink:fedora.im>
16:56:00
would alternatives be an option?
<@trix:fedora.im>
16:56:10
yes.
<@man2dev:fedora.im>
16:56:15
Rpm has too many ways to make spec work with mutiple code bases and not enough examples i think the only people that know rpm well enough about such deails are rpm devs
<@trix:fedora.im>
16:56:34
😂
<@trix:fedora.im>
16:56:46
true.
<@man2dev:fedora.im>
16:57:01
I trired and faild at mutiple times to find way to add backends to specs thats scales
<@trix:fedora.im>
16:57:26
it's not an easy problem.
<@tflink:fedora.im>
16:58:30
!info PR to add rocm backend for onnx has been merged, will start showing up in the Fedora onnx packages
<@dherrera:fedora.im>
16:59:14
I was researching to do this trick on onnxruntime https://www.pixelbeat.org/docs/conflicting-rpms.html but in the end I stumbled with some optimizations that made it infeasible to use on libraries
<@dherrera:fedora.im>
16:59:14
This trick is used on coreutils though, so it should work for packages like sourceextratorc++-rocm
<@trix:fedora.im>
17:00:48
this seemed similar to alternatives, but don't know alternatives that well, just i have _heard_ of alternatives and not this approach.
<@tflink:fedora.im>
17:02:14
it sounds like different approaches to the same problem - one using RPM and the other using symlinks+config
<@dherrera:fedora.im>
17:02:40
tbh, whatever works is fine for me ^^
<@dherrera:fedora.im>
17:03:00
tbh, whatever that works is fine for me ^^
<@tflink:fedora.im>
17:03:20
I don't have anything insightful to add, either. just wondering if alternatives might be better to look at first since that's a more general solution
<@tflink:fedora.im>
17:03:37
but I also think that'll be up to whoever is doing the work :)
<@tflink:fedora.im>
17:04:07
is there anything else to cover on this topic?
<@trix:fedora.im>
17:04:27
i guess i try some stuff out and report back on list and in the next meeting.
<@dherrera:fedora.im>
17:04:34
https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
<@dherrera:fedora.im>
17:04:34
btw, alternatives you mean this, right?
<@tflink:fedora.im>
17:05:39
yeah, that looks right. I thought it was a general method and that doc makes it sound fedora-specific
<@tflink:fedora.im>
17:07:16
!info more investigation is needed before this conversation goes father, will resume the discussion at a later date once that investigation is done
<@tflink:fedora.im>
17:07:37
anything else here or any suggested changes to my summary attempts?
<@trix:fedora.im>
17:07:48
sounds good.
<@tflink:fedora.im>
17:08:02
ok, that's the last topic on today's agenda
<@tflink:fedora.im>
17:08:06
moving on to
<@tflink:fedora.im>
17:08:09
!topic open floor
<@tflink:fedora.im>
17:08:15
any other topic that folks want to bring up?
<@tflink:fedora.im>
17:12:44
ok, thanks for coming everyone
<@tflink:fedora.im>
17:12:52
!endmeeting