Thanks for the review, Christian!
On 2024-01-05 11:53, Cordell Bloor wrote:I've updated rocm-device-libs to build using clang-17. The LLVM IR is only guaranteed to be stable within an LLVM major version, so changing the compiler is a breaking change. I've renamed the binary package from rocm-device-libs to rocm-device-libs-17 to reflect that the new binary package is intended exclusively for use with LLVM 17. That was true of rocm-device-libs and LLVM 15 previously, but it was not reflected in the name. This will require a trip through NEW, but I think it's the right thing to do.bin:rocm-device-libs has one reverse dependency, bin:hipcc. So I guess the plan is that we eventually upgrade that to depend on bin:rocm-device-libs-17, right?
Yes, that's my expectation.
In discussing this change previously, I'd proposed splitting out a new source package, but after further consideration I deemed it simpler to just drop the old rocm-device-libs binary package. We don't have the manpower to maintain more than one toolchain anyway.I concur. Even with a single package, I *think* we should be fine without a formal transition. Unless I'm greviously misremembering, bin:rocm-device-libs will stay around until bin:hipcc no longer depends on it, even if src:rocm-device-libs is updated.
Great!
The upstream license file states that the copyright is "2014-2016, Advanced Micro Devices, Inc." but the library has clearly been updated in every year from 2017 to 2023. Every maintainer for this package seems to have gone by the stated copyright date in the repo's license file, so that's how I left it. In any case, I'll raise the issue upstream, because AMD should update the date regardless.To be honest, I was never entirely sure about this myself, but I think the lesser of two evils is simply quoting upstream's copyright assertion verbatim.
I'll update the copyright date upstream and the question will be moot.
rocm-device-libs (5.7~git20231212.5a852ed-1~exp1) experimental; urgency=medium^^^ A ~git suffix is somewhat unusual as ~ sorts before: $ dpkg --compare-versions 5.7~git20231212.5a852ed '<<' 5.7; echo $? 0 With git, usually, it's +git to indicate that this is based on the 5.7 tag, plus some git commits added on top of that, for example to track bleeding edge. Was the ~git intentional? I admit to not having checked upstream too deeply on this, so apologies if this is noise on my end. (You mention in a commit that we are tracking the release/17.x branch now because that's the one basing on stable LLVM releases; that part was clear.)
I just used the default for uscan [1] and changed 0.0 to 5.7.
- pretty=rule
- Set the upstream version string to an arbitrary format as an optional opts argument when the matching-pattern is HEAD or heads/branch for git mode. For the exact syntax, see the get-log manpage under tformat. The default is pretty=0.0~git%cd.%h. No uversionmangle rules is applicable for this case.
It's not easy to correlate the branch with a particular version,
since the branch seems to diverge from the tagged releases a very
long ways back and is maintained with cherry-picks, but it appears
to include everything from ROCm 6.0 and beyond. Based on your
reasoning, it should be 6.0+git<...>. I will update the
package to reflect that.
Sincerely,
Cory Bloor
[1]: https://manpages.debian.org/buster/devscripts/uscan.1