vkd3d 2.0 fails many of its build-time tests on riscv64, with 6 tests
segfaulting and one test failing gracefully:

https://buildd.debian.org/status/fetch.php?pkg=vkd3d&arch=riscv64&ver=2.0%2Bds-1&stamp=1784232926&raw=0

As with the similar armhf bug #1142206, these might well be problems
with Mesa llvmpipe/lavapipe, rather than genuinely being a bug in vkd3d.

This is probably not actually a regression in vkd3d. Version 1.2
compiled successfully on riscv64 buildds, but version 1.2 also didn't
actually run the majority of the tests on buildds: the buildd log claims
that all tests passed, but if you build locally in a buildd-like
environment and look at tests/*.log (which unfortunately are not
reflected into the buildd log), you'll see that most (all?) of the tests
were skipped because there was no working Vulkan driver. This is
because, before
https://salsa.debian.org/wine-team/vkd3d/-/commit/d2dcaf91440111271a285b119d2a05ba8409a8b6,
there was no build-dependency on mesa-vulkan-drivers.

Wine upstream seems unlikely to be actively supporting riscv64, and
nothing in Debian seems to depend on vkd3d (yet?), so I think it might
be most realistic to drop vkd3d from the riscv64 architecture and then
ask the ftp team to remove the old "cruft" binaries, unless a riscv64
porter is available to investigate this in detail.

Alternatively, if maintainers of vkd3d and/or riscv64 (and armhf)
porters are reasonably confident that it does work on systems with an
actual GPU, another possible workaround would be to skip the tests or
ignore their results on riscv64 (and armhf).

    smcv