Re: Re: Upgrading to ROCm 6.1
Apparently the subscription request isn't going through... I tried a few times.
I tried making a gitlab account for Salsa, but looks like I'm also not getting confirmation emails from there either... I swear I checked my spam folder.
> If you're unfamiliar with Debian packaging
So the packaging itself I'm familiar with, it's more of the practices and policies that are a bit opaque to me. E.g. how legal review works, what is best practices for naming and source handling, etc.
I gave the list of packages that I'm most familiar with, so I hope to help out there with updates and hopefully that would take some load off of you guys to focus on the other stuff.
> correctly assess the notable changes
Fortunately because I work on Fedora packages, I do this already, so I feel like I can help out there. Someone would need to check over my work though to make sure it's kosher, but I can do the heavy lifting.
For reference, Tom Rix (of Redhat) and I are currently the main maintainers in Fedora, and I tend to focus on the lower end, while he handles the higher math libraries.
> There's also an ABI breakage [6] to deal with ...
So prior to 6.1, ROCm just targeted their own fork of LLVM, which was always misaligned with upstream LLVM API/ABI.
Starting 6.1, they are choosing an LLVM branch during development to align their LLVM with, so in theory breakage should be minimal if we match that LLVM branch.
ROCm 6.1 targeted LLVM 17, 6.2 should target 18, while my best guess is that 19 should be around 6.4 or similar timing, depending how many releases they do this year.
The "amd-mainline-open" branch is a preview of the next ROCm release, and it appears to use LLVM 18 [9], hence why I suspect 6.2. We can get a good idea when the switch to LLVM 19 happens when this branch changes. They have a staging branch as well that they use as staging new llvm changes before merging into their mainline [10]
As I meantioned, ROCm 6.1.2 broke due to API, but this is a bug, I've documented it [11]
> That depends on how deep you want to get into Debian packaging.
My gut says that if I can send a merge request on Salsa for upgrades for the packages I'm familiar with, I think that's my best way to contribute. We can figure out the detail during review, as I learn quicker on the job. I assume this is ok, right?
> Just one example: regarding MIOpen
Yeah I'm not 100% sure how to handle miopen, I've been too preoccupied with maintaining the lower bits that I've been out of the loop. I can sync up with Tom Rix about how fedora is handling it.
Reply to: