RE: Needing branches for releases ?
[AMD Official Use Only - AMD Internal Distribution Only]
In fedora, to deal with the updating patches, the changes are a mix of at build time sed commands and much fewer patches. In looking through at least the some of the packages I could not find a pattern on how something like sed would be done.
Here is an example
https://src.fedoraproject.org/rpms/rocblas/blob/rawhide/f/rocblas.spec#_285
Is there a sed-ing pattern in Debian we could leverage?
And it should be possible to share the patches between Debian and Fedora once we get synced up.
Updating the compiler and runtime is always a challenge requiring some test and debug cycle. An additional challenge on Debian is the non x86-64 archs. Who does the test and debug on the non x86-64 ?
What Tim presented last meeting for the compiler, was a repacking of Fedora's ROCm compiler which is also used on RHEL, OpenSUSE and SUSE. Updating and supporting a repackaged fork should be easier than what is currently being done. Many times the new features of a release depends on the compiler with the infra for those features being in the non llvm-project/amd parts of the full rocm-llvm and not yet in what should be the upstream llvm-project. The last one I had to deal with was the offload compress feature that is critical for reducing the size of the libraries, I spend a couple of weeks hacking together a workaround I was never comfortable with. The next big feature for generic targets I would expect to have the same problem.
Here is an example what changes you could expect for using the full rocm-llvm
https://salsa.debian.org/trix/rocm-hipamd/-/commit/1d80279c7635aacd3d71a931548a40044907d33f
In d/control
clang-17 -> clang-rocm and similar
https://salsa.debian.org/trix/rocm-hipamd/-/commit/1d80279c7635aacd3d71a931548a40044907d33f#58ef006ab62b83b4bec5d81fe5b32c3b4c2d1cc2_22_20
In some d/rules
Define location of bin,cmake for rocm-llvm
https://salsa.debian.org/trix/rocm-hipamd/-/commit/1d80279c7635aacd3d71a931548a40044907d33f#8756c63497c8dc39f7773438edf53b220c773f67_5_5
Tom
-----Original Message-----
From: Christian Kastner <ckk@debian.org>
Sent: Wednesday, July 9, 2025 1:05 AM
To: debian-ai@lists.debian.org
Subject: Re: Needing branches for releases ?
On 2025-07-07 22:35, Rix, Tom wrote:
> I am interested in expanding my POC to cover more of the stack and have some branching to try out some release and/or ci workflows.
The Debian Janitor [1, 2] is a tool that can automate away a lot of packaging tasks, especially the lintian-related ones. It is used extensively by some other teams.
One of its features is the ability to auto-update a package from git, using routine-update [4]. This works fine for some of the easier packages, eg: Python modules. Though I haven't tried it, I would expect this to just work at least for patch releases.
> It is very challenging to have a very fast upstream and a lot of packages. Patch releases happen about every 4-6 weeks. This takes us in fedora about 2 weeks but this leans on a lot of fedora processes that I am not sure have a Debian equivalent. If there is a some better/different way folks aways wanted to try out, I would be willing to give those a try otherwise I'll do the best I can to reduce the manual overhead per package.
I guess it depends on how much overhead is involved. For a patch release, I would expect it to be very low. In a minor release, I would expect some patches to be dropped (those applied upstream), and possibly some larger tooling changes (changing the docs build process). No idea what triggers a major update.
Looking back at the libraries I updated to 6.4, the biggest pain points were
(1) Updating our custom downstream patches, eg: for changing file
locations
(2) Discovering/dealing with new features
(3) SOVER bumps, though this is mostly just a chore
(4) The change to the documentation build, though once I had this
figured out, it was also just a 5-min chore
I think that if we had tracked upstream more closely rather than letting the versions drift so far back, all of this would have been much simpler. This applies to rocblas especially, the 5.5 -> 6.4 update is substantial and I'm glad that Christian Bayle had already done much of the needed work for 6.1.
Having said that, even with all of the above and the substantial version delta, the library updates so far didn't really take that much time, and I might finish the other libraries during DebConf (though all I myself needed has now been updated, so no promises there).
The bigger problem, I think, are keeping hipcc and other core components updated. I don't have a feel for that yet.
Best,
Christian
[1]: https://janitor.debian.net/, down at the moment
[2]: https://wiki.debian.org/Janitor
[3]: https://packages.debian.org/sid/routine-update
[4]: https://packages.debian.org/sid/routine-update
Reply to: