Your message dated Wed, 13 Aug 2025 15:32:55 +0100 with message-id <aJyiF7OBoZUMteKA@descent> and subject line Re: Bug#1103350: libdxvk-native-dev: SDL3 WSI not enabled, despite libsdl3-dev build-dependency has caused the Debian Bug report #1103350, regarding libdxvk-native-dev: SDL3 WSI not enabled, despite libsdl3-dev build-dependency to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1103350: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103350 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: libdxvk-native-dev Version: 2.6.1-1 Severity: normal Tags: patch upstream fixed-upstream I added a libsdl3-dev build-dependency to src:dxvk in the hope that this would enable the SDL3 WSI, but my first attempt failed, as we can see in the buildd logs: > Get:329 https://deb.debian.org/debian sid/main arm64 libsdl3-0 arm64 > 3.2.10+ds-1 [835 kB] ... > Get:351 https://deb.debian.org/debian sid/main arm64 libsdl3-dev arm64 > 3.2.10+ds-1 [1473 kB] ... > Run-time dependency sdl3 found: NO (tried pkgconfig and cmake) > Run-time dependency sdl2 found: YES 2.32.54 > Run-time dependency glfw found: NO (tried pkgconfig and cmake) This is because upstream's dependency check for SDL3 was wrong, and only works (as a result of compensating errors) if cmake happens to be installed too. This led to my initial test-builds in the Steam Runtime succeeding, but silently disabling SDL3 because the dependency check for it was broken, resulting in some confusion while trying to test against a SDL3 game supplied by the FNA maintainer. Please consider applying my MR https://salsa.debian.org/aviau/dxvk/-/merge_requests/8 which incorporates an upstream-approved change to fix this. Also please consider the follow-up MR https://salsa.debian.org/aviau/dxvk/-/merge_requests/9 which incorporates and uses an upstream-approved change turning each of the three possible WSIs into a "feature" build option with three possible states (explicitly enabled, FTBFS if not found; explicitly disabled, do not enable; or automagic), to prevent the SDL2 and SDL3 WSIs accidentally getting disabled due to bugs, while also preventing the GLFW WSI from accidentally getting enabled. With those changes included in Steam Runtime 3's backport of DXVK 2.6.1 (which should be included in its next public beta, hopefully in the next few days), I was able to run both SDL2 and SDL3 code using DXVK. Thanks, smcv
--- End Message ---
--- Begin Message ---Version: 2.6.2-1 On Wed, 16 Apr 2025 at 17:17:22 +0100, Simon McVittie wrote: > I added a libsdl3-dev build-dependency to src:dxvk in the hope that this > would enable the SDL3 WSI, but my first attempt failed ... > This is because upstream's dependency check for SDL3 was wrong Subsequently fixed in experimental. Thanks, smcv
--- End Message ---
