Quack,
On 2025-03-24 21:06, Simon McVittie wrote:
I think that's all we can really do at the moment. Given the trixie
release
timeline, having DXVK Native in experimental for now would seem
reasonable,
and perhaps it can go to testing/unstable in the forky cycle?
Sounds like a plan.
I asked a FNA maintainer on
<https://github.com/ValveSoftware/steam-runtime/issues/687> and he's
made
a SDL3 beta branch available for
<https://store.steampowered.com/app/1800730/I_MAED_A_GAM3_W1TH_Z0MB1ES_1N_IT1/>
(which is a Steam game, but free-as-in-free-beer, and probably doesn't
have any particular DRM beyond being most conveniently installed via
Steam,
because there isn't much point in putting intrusive DRM in a free
game).
Trying that out is on my to-do list: when I update to 2.6 I'll probably
use that as one of my smoke-tests.
Nice, I'll feel more confident if we can test real games.
At the dh_auto_configure stage, I used override_ because we need hooks
both before and after dh_auto_configure. At the dh_auto_clean,
dh_auto_build and dh_auto_install stages, I used execute_after_ because
the debhelper defaults are fine for DXVK Native, and your Wine-specific
second build pass can be done semi-independently.
Sorry, it was obvious, I should have read it more carefully.
I personally prefer having the vendored stuff in git directly so I can
review what changed in it without needing to use diffoscope (for larger
vendored modules by using multiple orig.tar like I do in src:yquake2,
or for smaller vendored modules by having it unpacked in debian/ like I
did with debian/vendor/mingw-directx-headers here) but I realise
opinions
can differ on this topic.
I never felt the need to look into multiple orig.tar (probably because I
did without when it did not exist) but looking at the documentation it
would both be out of debian/ and unpacked and under git control. Looks
like gbp has a --component option and that should work with --uscan so
why not try it in experimental?
Regards.
\_o<
--
Marc Dequènes
