[Bug 59079] New: Debian Trixie: wine-devel package lacks ntsync support with linux-image-amd64/trixie-backports
http://bugs.winehq.org/show_bug.cgi?id=59079
Bug ID: 59079 Summary: Debian Trixie: wine-devel package lacks ntsync support with linux-image-amd64/trixie-backports Product: Packaging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-packages Assignee: wine-bugs@list.winehq.org Reporter: actium@gmx.net CC: dimesio@earthlink.net Distribution: ---
The WineHQ packaged wine-devel 10.20 for Debian 13 "Trixie" lacks ntsync support, because Trixie's LTS kernel 6.12 predates the ntsync merge and thus ntsync.h is missing. However, trixie-backports currently ships Linux 6.17 with ntsync [1]. Alternatively, the ntsync kernel module is trivial to build with DKMS [2].
While retrofitting kernel-side ntsync is easy on Trixie, adding it to wine itself requires building from source. Wine users would benefit from ntsync-ready WineHQ binary packages, as they would facilitate ntsync access. This would only require including ntsync.h when building the WineHQ packages for Trixie.
[1] https://packages.debian.org/trixie-backports/linux-image-amd64 [2] https://github.com/ActiumDev/debian-ntsync-dkms/
http://bugs.winehq.org/show_bug.cgi?id=59079
actium@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |actium@gmx.net Distribution|--- |Debian
http://bugs.winehq.org/show_bug.cgi?id=59079
Chiitoo chiitoo@gentoo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chiitoo@gentoo.org
http://bugs.winehq.org/show_bug.cgi?id=59079
--- Comment #1 from actium@gmx.net --- This is related to, but not a duplicate of https://bugs.winehq.org/show_bug.cgi?id=58751 (thanks to Chiitoo for pointing this out). I've read the discussion and would like to add the following argument:
AFAICT, adding ntsync.h to the Trixie packages will not break anything for non-backport Trixie installs. Wine with ntsync support will silently default to the wineserver-based sync mechanism if /dev/ntsync is missing. Thus, it would help out backport users without affecting non-backport installs.
http://bugs.winehq.org/show_bug.cgi?id=59079
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
--- Comment #2 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to actium from comment #1)
This is related to, but not a duplicate of https://bugs.winehq.org/show_bug.cgi?id=58751 (thanks to Chiitoo for pointing this out). I've read the discussion and would like to add the following argument:
AFAICT, adding ntsync.h to the Trixie packages will not break anything for non-backport Trixie installs. Wine with ntsync support will silently default to the wineserver-based sync mechanism if /dev/ntsync is missing. Thus, it would help out backport users without affecting non-backport installs.
ntsync.h is already included in our trixie builds, but it is the original version, which is not new enough. Using the newer version would require building against the backports repository on the OBS, and that would cause our trixie packages to depend on newer versions of every dependency that had a newer version in backports.
http://bugs.winehq.org/show_bug.cgi?id=59079
--- Comment #3 from actium@gmx.net --- I agree that depending on backports is a hard no. However, I was thinking of cherry picking *only* the newer version of ntsync.h into the package source files to substitute Trixie's "old" version. While somewhat unclean, it would not pull in any backports dependencies. Dunno whether that's even possible with OBS. I have no packaging experience.
I understand this may be a too unconventional suggestion. Doing this merely in an effort to solve this upstream before I pursue a workaround.
http://bugs.winehq.org/show_bug.cgi?id=59079
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #4 from Rosanne DiMesio dimesio@earthlink.net --- Users who really want ntsync support can always upgrade to forky.
http://bugs.winehq.org/show_bug.cgi?id=59079
--- Comment #5 from actium@gmx.net --- Not an option for dedicated server use, where OS security support is a hard requirement, which Forky currently lacks.
If anyone is looking for a solution, see this Debian wiki page that suggests a 3rd party OBS build (buyers beware): https://wiki.debian.org/Wine/NtsyncHowto (Thanks to tomman on IRC for pointing this out!)
http://bugs.winehq.org/show_bug.cgi?id=59079
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #6 from Zeb Figura z.figura12@gmail.com --- (In reply to actium from comment #5)
Not an option for dedicated server use, where OS security support is a hard requirement, which Forky currently lacks.
If anyone is looking for a solution, see this Debian wiki page that suggests a 3rd party OBS build (buyers beware): https://wiki.debian.org/Wine/NtsyncHowto (Thanks to tomman on IRC for pointing this out!)
Isn't "dedicated server use, where OS security support is a hard requirement" kind of inherently at odds with a very new feature like ntsync?
http://bugs.winehq.org/show_bug.cgi?id=59079
--- Comment #7 from actium@gmx.net --- (In reply to Zeb Figura from comment #6)
Isn't "dedicated server use, where OS security support is a hard requirement" kind of inherently at odds with a very new feature like ntsync?
I do (naively) presume that ntsync doesn't increase the overall system attack surface, particularly facing the internet. Regardless, it is an upstream kernel feature and thus covered by the Linux kernel security team and distribution security teams. In combination with unattended-upgrades and automatic reboots, that should deliver decent, low-overhead security on Debian Stable. Forky/Testing does not enjoy the same level of security incident response. This relates to the whole system including all internet-facing services and not just ntsync and Wine.
With regards to wine, I'm more worried about the attack surface of the windows binaries. But that is best left to sandboxing and prayer ...
-
WineHQ Bugzilla