Source: vkd3d Version: 2.0+ds-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: [email protected], [email protected] User: [email protected] Usertags: riscv64
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 >Segmentation fault >FAIL tests/d3d12 (exit status: 139) >Segmentation fault >FAIL tests/hlsl_d3d12 (exit status: 139) >Segmentation fault >FAIL tests/hlsl/compute.shader_test (exit status: 139) >shader_runner.c:1964: non-const-indexing.shader_test:398: Model 2.0: Test >failed: Got {5.00000000e+00, 6.00000000e+00, 7.00000000e+00, 8.00000000e+00}, >expected {1.00000000e+00, 2.00000000e+00, 3.00000000e+00, 4.00000000e+00} at >(0, 0). >FAIL tests/hlsl/non-const-indexing.shader_test (exit status: 1) >Segmentation fault >FAIL tests/hlsl/rasteriser-ordered-views.shader_test (exit status: 139) >Segmentation fault >FAIL tests/hlsl/tgsm.shader_test (exit status: 139) >Segmentation fault >FAIL tests/hlsl/uav-rwbuffer.shader_test (exit status: 139) 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
