vkd3d has a new upstream release available, v1.7. It would be great to have that version in experimental, or in unstable after bookworm is released. I need .deb packages of this version for a work project, so I've been looking at updating the packaging used for Debian as a starting point for that, and I'll send a merge request when I have it working. One thing to watch out for is that there is an ABI regression: https://bugs.winehq.org/show_bug.cgi?id=54761 so packaging a new version will require the patch from that bug. Thanks, smcv
Control: tags -1 + patch https://salsa.debian.org/smcv-guest/vkd3d wip/1.7 I used `uscan --download` to get the orig.tar.* I used for test-builds. Errata: I'm getting test failures when I run the build-time tests on my development laptop (Debian unstable, Intel UHD Graphics 620, Mesa 22.3.6), although those failing tests are skipped when I do the build in a chroot or a podman container. I wonder whether it would be more honest to disable the build-time tests completely, since they're clearly not providing much coverage in practice: the majority of them are skipped when using Debian's production infrastruction (sbuild). For the moment, I've left the build-time tests enabled in my branch, and continued with the maintainers' approach of disabling tests in situations where they're clearly not going to work. Thanks, smcv
Control: retitle -1 vkd3d: new upstream release 1.11 Since then there have been several more upstream releases and it is currently at v1.11. Updated version at: https://salsa.debian.org/smcv-guest/vkd3d wip/1.11 Once again I used `uscan --download` to get the orig.tar.* I used for test-builds. debian/patches/fixes/byte-comparison.patch no longer applies; I dropped it for now (and the package builds successfully in my environment), but if it's still necessary for other build environments, it will need some adjustment. It would be ideal if this issue could be reported upstream and fixed there. smcv
Hi, I'm a vkd3d upstream developer. Unfortunately I haven't had a lot of time for Debian for a few years, but I'm happy to help here if needed. Il 28/05/24 19:36, Simon McVittie ha scritto: And now v1.12, just yesterday. compare_uint() and compare_color() are now in tests/utils.h. I don't really understand in which cases that patch is supposed to help, but it's true that vkd3d assumes every now and then that the architecture is one of i386, amd64, arm or arm64 (i.e., the architectures meaningful for Windows). So it's totally possible that a little endian assumption has trickled in somewhere, though it's not immediately clear to me how endianness should break something here. For the failing tests, as you might already have noticed, most vkd3d developers use AMD GPUs. I'm slowly trying to clean up the tests on llvmpipe, Intel and NVIDIA GPUs (and also more exotic Vulkan implementations, like MoltenVK and mobile GPUs), but that tends to be relatively low priority. Gio.
Despite what the name kind of implies it's not a LE assumption. Unless I'm misreading it, It's rather letting comparisons wrap (e.g. treating 0x00 as "close" to 0xff), presumably in an attempt to fix failing tests, but those failures are probably legitimate.
Control: retitle -1 vkd3d: new upstream release 1.12 Updated branch at: https://salsa.debian.org/smcv-guest/vkd3d wip/1.12 Again, I used `uscan --download` to get the orig.tar.* I used for test-builds. If the Wine team don't have time to review that packaging update right now, it could be useful if a team member could prepare an "official" repacked orig.tar.* for 1.12 and make it available somehow (perhaps pristine-tar or pristine-lfs) so that forks of this packaging outside Debian can agree on a shared "single source of truth" orig tarball, rather than having the orig tarballs inside and outside Debian diverge. It's looking likely that I will need to upload this to the Steam Runtime (a specialized Debian derivative) at some point, and if possible I'd prefer not to have to re-import the upstream source versioned as 1.12~steamrt or similar to avoid that divergence. Or, if this version isn't felt to be ready for unstable, an upload to experimental would be a good way to find out whether there are test regressions on the autobuilders, particularly for non-x86. Right, that's why I didn't update the patch or forward a bug report upstream - sorry, but it wasn't clear to me what the steps to reproduce for the bug would be. It was added in 1.2-7, for which the changelog says "Skip failing tests when using llvmpipe from mesa 21" (but that seems to be debian/patches/fixes/llvmpipe.patch) and "Skip failing tests when using nvidia devices" (but that seems to be debian/patches/fixes/nvidia.patch which was subsequently removed). In the update to 1.12 I also dropped d/p/fixes/llvmpipe.patch, which doesn't seem to be necessary with current llvmpipe as of Debian 12 (either that, or I'm not testing it in the same scenario where the skipped tests would have failed - it's hard to tell which). I believe having the tests pass with llvmpipe would be sufficient for the official Debian autobuilders, which don't have access to a real GPU device node in /dev even if the underlying machine has one. smcv
Updated branch at: https://salsa.debian.org/smcv-guest/vkd3d wip/1.13 Again, I used `uscan --download` to get the orig.tar.* I used for test-builds. vkd3d 1.12 is now included in the "Steam Linux Runtime 3.0 (sniper)" container environment (since August), and I'll probably be asked to upgrade that to 1.13 at some point. For the moment I'm using a forked "upstream" version number (now 1.12~steamrt1, likely to become 1.13~steamrt1) to avoid colliding with the Wine team's "official" orig tarballs, but I'd like to be able to stop doing this. smcv
Updated branch at: https://salsa.debian.org/smcv-guest/vkd3d.git wip/1.15 https://salsa.debian.org/smcv-guest/vkd3d/-/tree/wip/1.15?ref_type=heads Again, I used `uscan --download` to get the orig.tar.* I used for test-builds. It builds and passes smoke-tests (vkd3d-demos). This would (still) be helpful. The Steam Linux Runtime is now shipping vkd3d 1.14, and will probably be updated to 1.15 in its next beta. smcv
Updated branch at: https://salsa.debian.org/smcv-guest/vkd3d.git wip/1.16 https://salsa.debian.org/smcv-guest/vkd3d/-/tree/wip/1.16?ref_type=heads It would be great if someone from the Wine Party could look at upgrading this library in forky. smcv
Another new version: https://salsa.debian.org/smcv-guest/vkd3d.git wip/smcv/new-upstream https://salsa.debian.org/smcv-guest/vkd3d/-/tree/wip/smcv/new-upstream?ref_type=heads This builds and passes smoke-tests (vkd3d-demos, and when built for the Steam Runtime, a sample FNA game https://steamdb.info/app/1800730/ `sdl3` beta branch with command-line argument `/gldevice:D3D11`). Also new in this updated version is that it has a Build-Depends on mesa-vulkan-drivers, which allows a lot of the test suite to be run at build-time. I did have to skip one test, which fails when using llvmpipe/lavapipe in current Mesa: https://salsa.debian.org/smcv-guest/vkd3d/-/blob/wip/smcv/new-upstream/debian/patches/tests-Don-t-run-rasteriser-ordered-views.shader_test-for-.patch?ref_type=heads but that still seems to be better coverage than this package has had so far. I hope this is useful, smcv
An updated version (same branch address) cherry-picks a patch from upstream git, intended to be released in 1.20, to make the test workaround more selective: https://salsa.debian.org/smcv-guest/vkd3d/-/commit/3b399858b83e8a4345c2c0afac8d74f5e7c23aff and another patch from upstream git, also intended to be in 1.20, to resolve a FTBFS when built in a non-minimal container that has libegl-dev installed and tested against older Mesa: https://salsa.debian.org/smcv-guest/vkd3d/-/commit/b7ae87011c198704e2ca71b55cd1df065f394c79 smcv
Control: retitle -1 vkd3d: new upstream release 2.0 Dear Maintainers, upstream has released vkd3d version 2.0 https://gitlab.winehq.org/wine/vkd3d/-/releases/vkd3d-2.0 Is there interest in updating the Debian packages? This will help Debian derivatives a lot by reducing the backporting efforts. Simon has spent a lot of time time revamping the packaging for new versions in https://salsa.debian.org/smcv-guest/vkd3d and we will propose an update for vkd3d-2.0 too, but it would be great to get a signal from the maintainers about their intentions to upload such updates. Thanks a lot, Antonio