Re: Is llvm-toolchain-17 something that could be backported?
Hi Cory,
On 2024-07-08 19:47, Cordell Bloor wrote:
> On 2024-07-08 02:40, Christian Kastner wrote:
>> Just an update for the list: while backporting would usually be quite
>> straightforward, There are two changes between the releases that make
>> this somewhat more difficult: the 64-bit time_t transition, and the move
>> to /usr/bin.
>>
>> I did not look into this yet, and will probably not have the time to do
>> in the very near future.
>
> This is also beyond my skills for the moment. If someone else wants to
> backport llvm-toolchain-17 and then backport one library maintained by
> the Debian ROCm Team, then I will backport the rest. I just need an
> example to work from.
A backport is a source package taken from testing, and rebuilt in a
stable chroot. For bookworm, in the simplest case, all it takes to
create one is a new changelog entry with s/unstable/bookworm-backports/,
like we do for experimental. Really trivial stuff.
In Salsa, this package would then be maintained in the
bookworm-backports branch.
However, sometimes the source package requires modification to be
buildable in stable, for example adjusting dependencies, or dropping
feature flags.
With llvm-toolchain-17, the t64 dependencies require adjusting, and I
didn't check what (if any) the impact of the /usr/bin move is. But these
changes are significant enough that I would want to invest more time
into this than I currently can. My major concerns are (1) possibly
breaking things for users and (2) somehow breaking upgrade path from
bookworm-backports to trixie.
One thing we could trivially do is open up a bookworm-backports branch
in our own APT repo, and upload it there for testing. Once we are
satisfied, we can look into an official backports upload.
> With that said, we do not necessarily need llvm-toolchain-17 to backport
> many of the ROCm math libraries. It would be quite straightforward to
> backport most of the math libraries based on llvm-toolchain-15 (e.g.,
> rocblas, rocsolver, etc.). The biggest drawback would be the lack of
> support for RDNA 3 GPUs.
Purely from my gut, I think backporting llvm-toolchain-17 would be less
work, as our own libraries's backports would remain trivial, and there
is less of a mental delta as well.
> There was mention previously that Blender requires at least ROCm 5.3,
> but I think we could backport rocm-hipamd 5.3.3 (or 5.4.3) based on
> llvm-15 as well. Although, porting rocm-hipamd 5.7.1 would be the easier
> option if llvm-17 is available.
We must strictly adhere to the version in testing, as far as I'm aware.
And I suspect that new newer our versions, the better anyway.
Best,
Christian
Reply to: