Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, I just packaged DXVK 2.0 which brings lots of improvements. It is the first time since I took over that the requirements were bumped and the bar is high: Wine 7.1 and Mesa3d 22.0 (minimum version, not recommended): https://github.com/doitsujin/dxvk/wiki/Driver-support With the current lag of the Wine packaging it is not sufficient to use wine-stable at the moment. I'm not closing this bug but I really think that if someone really wants DXVK with stable then a dxvk-stable package would be needed. As stated before I'm not interested in maintaining such package but if someone would step up then we could sync our packages and collaborate. Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, On 2022-03-11 21:52, Adrian Bunk wrote: dxvk should have an RC bug documenting why it is not in testing, and this bug in dxvkshould be fixed by using the non-development version of wine. I agree documenting is nice but this is not my decision. It is unlikely that wine maintainers would change their mind and push -devel in a stable release but if that were to happen then this package would needlessly be blocked by this bug now. The fact that it does not work with wine-stable is another matter entirely. As for the use of wine-stable as stated previously I have no idea what are the consequences of building with an old version and using it with the -devel one. Creating a dxvk-stable would be safer but since I never use wine-stable I would not wish to maintain it. I do not have any knowledge of the DXVK or wine code and did not have time to look into it or ask upstream about it, but if you do then I'll be happy to hear about it (you seem to be sure that's the obvious solution so I guess you do). For testing migration of dxvk this does not make a difference, but it highlights that there is a bug in dxvk that needs fixing. This is a new feature of the package, thus "wishlist" severity. And I'm not going to skip over this BR just because the severity is not RC. Anyway, that does not change much but I find it very annoying when people play with severity without explaining why. I think mixing the not-in-stable and does-not-work-with_wine-stable questions is confusing. Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
On Wed, Mar 09, 2022 at 12:56:39PM +0900, Marc Dequènes (duck) wrote: > Quack, > > Btw, Adrian could you clarify with you bumped the severity? > wine-development was already blocked from entering Bullseye and that blocked > dxvk as well, so no need to add a RC bug just for that. dxvk should have an RC bug documenting why it is not in testing, and this bug in dxvkshould be fixed by using the non-development version of wine. For testing migration of dxvk this does not make a difference, but it highlights that there is a bug in dxvk that needs fixing. > Regards. > \_o< cu Adrian
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, Btw, Adrian could you clarify with you bumped the severity? wine-development was already blocked from entering Bullseye and that blocked dxvk as well, so no need to add a RC bug just for that. Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, Could you please test the changes in branch 'br982159' on Salsa and tell me if it works for you? Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, Sorry for the late reply. You're right DXVK can now handle wine-stable version (5.0.3). I have not tested it but upstream claims 3.10 as the minimum version needed. That still won't let this package into testing though as it is built against libwine-development-dev that will never reach testing. Without making two separate packages I don't think that would work. Also, with the important gap between stable and devel versions I'm wondering how DXVK is going to perform. Again without another package built with libwine I don't see how we can be sure that's not gonna break. I personally stopped using the Debian packaged wine-development because they are unable to keep up with the release frequency (and also did not seem willing to accept me in their team to contribute) and I've been using the packages provided on winehq and that never broke so far. That is to say I may have overestimated the risk. I'm not really interested in creating another package for stable knowing I would never use it myself and thus would not be able to test it, but I'm ok to remove the restrictions on dxvk-setup. I'll schedule that for the next upload. Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Package: dxvk Version: 1.7.3+ds1-1 Severity: normal dxvk currently depends on wine-development being available, or its patches can not be applied on the target WINE prefix. In my experience, a WINE prefix patched in this way can then be used with a stable build of WINE ≥ 5.0. I suspect the dependency on the development build of WINE was justified when the packaged stable version of WINE was 4.x, but is no longer useful starting with Bullseye, that is coming with WINE 5.0.3 stable build. Since this dependency on wine-development is actually preventing dxvk to enter testing, I suggest studying the possibility to have it rely on wine (stable) instead. This is probably a bit late for Bullseye, but might help for an easier comeback with Bookworm, as well as for Bullseye backports. From what I see from the code, it might be as simple as editing the argument parsing snippet in debian/dxvk-setup/dxvk-setup [1] to drop the error message and the forced exit. If this is indeed the case, I can run some tests to ensure it has no side-effect as long as WINE ≥ 5.0 is available, and submit a patch through salsa. [1]: https://salsa.debian.org/aviau/dxvk/-/blob/87cda5190382e29bf6bfa2bcc8a487d232b2d073/debian/dxvk-setup/dxvk-setup#L261 -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dxvk depends on: ii dxvk-wine32-development 1.7.3+ds1-1 ii dxvk-wine64-development 1.7.3+ds1-1 Versions of packages dxvk recommends: ii dxvk-wine32-development 1.7.3+ds1-1 ii dxvk-wine64-development 1.7.3+ds1-1 dxvk suggests no packages. -- no debconf information
