After consulting with upstream, it looks like the errors are misleading, so I disabled them in branch.
Please update to the latest to avoid test failure. I also cherrypicked a bugfix to devicelibs and a couple to compilersupport.
Side note, I've started a llvm 18 branch to prep for llvm 18 branch, but it's still rolling and experimental, I don't advise using it if Debian update to llvm 18:
Fedora will likely pick up LLVM 18 pretty quickly though.
Sorry about that, it looks like I overlooked this test suite.
I quickly tested and it doesn't work on Fedora, so I'll take a look and see if I can fix them.
Let me know if you see any other issues with this new upstream approach. It needs a lot more vetting, but I'm sure we can make it work. All of the comgr tests should work and OpenCL is fine, although we've been noticing some issues with HIP and blender, which may or may not be related to these failures.
On Mon, Dec 11, 2023, at 4:25 AM, Cordell Bloor wrote:
Hello,
I've prepared a rocm-device-libs-17 package [1] based on the
release/17.x branch that Jeremy Newton mentioned [2]. It is a separate
source package at the moment, but perhaps it should just be a new binary
package for rocm-device-libs? I don't know. The important thing is to
ensure that users can stay on rocm-device-libs for clang-15 until
rocm-compiler-support and rocm-hipamd have been updated to use clang-17,
otherwise all libraries written in the HIP language will FTBFS during
the transition. The creation of a new rocm-device-libs-17 package solves
that problem by enabling device libs for both clang-15 and clang-17 to
be installed during the transition, but perhaps there's a better way.
Unfortunately, I'm seeing some test failures. The logs are attached.
Fedora Rawhide apparently already packages this version of the
rocm-device-libs, so I'm curious to know if these failures are specific
to Debian.
Sincerely,
Cory Bloor
Attachments:
- rocm-device-libs-17.x-ctest-log.txt