Re: Upgrading to ROCm 6.1
Hi Jeremy,
On 2024-06-12 21:41, Jeremy Newton wrote:
> Since I need to do the compiler bits first do you have any preferences
> on the source package change? As I said before, I just consolidated all
> the fedora packages under rocm-compilersupport source package.
> Alternatively you could introduce a new source package called
> "rocm-llvm-project", or I can just manually clone and copy the source
> from the upstream tree into the three source packages: rocm-device-libs,
> rocm-compilersupport (libamd-comgr), and rocm-hipamd (hipcc).
I'd aim to keep the deltas as small as possible, so definitely one
source package rather than tree.
It's tempting to use rocm-compilersupport for consistency with Fedora.
However, we already have that package. With the new package being
substantially different, it would seem cleaner to go for a rocm-llvm,
and more pragmatic to stick with rocm-compilersupport.
I'll let others chime in, too.
> Do you try to maintain the upstream git history? Or just do a merge
> squashed commit every update? I briefly skimmed it, but wasn't sure at a
> glance if upstream changes should be included in the salsa git history.
We don't use upstream git at all.
uscan (which uses debian/watch) downloads upstream tarballs (optionally
filtering and repacking ). git-buildpackage takes such tarball, commits
it to the pristine-tar branch, commits its contents to the upstream
branch in one single commit, and merges the upstream branch into the
master branch.
I think the upstream branch is you had in mind with "merge squashed
commit every update", right?
> Regarding "Fedora's Salsa" it's https://src.fedoraproject.org/
> <https://src.fedoraproject.org/>. It has a similar interface to gitlab.
> The easiest way to access the ROCm packages is through the SIG (special
> interest group): https://src.fedoraproject.org/group/rocm-packagers-sig
> <https://src.fedoraproject.org/group/rocm-packagers-sig>>
> I think the packages are largely the same of what Debian has, but with
> name differences (e.g. rocm-comgr vs libamd-comgr2), and sources are
> handled differently than Debian (Fedora always prefers extracting and
> building clean upstream tarballs). Also the math libs also are split up
> by HW generation (e.g. gfx8, gfx9, etc).
Yeah, interesting. Could you expand on the rationale? Possibly a package
size/disk space thing?
Best,
Christian
PS: I'm taking a few personal days, replies might take me til Monday.
Reply to: