Bug 263196 - emulators/wine-proton: update to 7.0
Summary: emulators/wine-proton: update to 7.0
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Rainer Hurling
URL:
Keywords:
Depends on:
Blocks: 267803
  Show dependency treegraph
 
Reported: 2022-04-10 16:15 UTC by Aleksander Slomka
Modified: 2022-11-26 11:19 UTC (History)
6 users (show)

See Also:
iwtcex: maintainer-feedback+


Attachments
7.0 update patch (402.90 KB, patch)
2022-04-10 16:15 UTC, Aleksander Slomka
no flags Details | Diff
7.0 update patch - new (402.88 KB, patch)
2022-04-10 20:24 UTC, Aleksander Slomka
no flags Details | Diff
7.0 update patch v2 (301.36 KB, patch)
2022-04-11 20:59 UTC, Aleksander Slomka
no flags Details | Diff
7.0 update patch v3 (300.98 KB, patch)
2022-04-13 20:33 UTC, Aleksander Slomka
no flags Details | Diff
6.3.2_5_to_7.0.patch (298.40 KB, patch)
2022-05-29 16:34 UTC, Bartek Jasicki
no flags Details | Diff
6.3.2_5_to_7.0.2.patch (298.45 KB, patch)
2022-06-05 17:07 UTC, Bartek Jasicki
no flags Details | Diff
6.3.2_5_to_7.0.3.patch (298.50 KB, patch)
2022-06-19 17:01 UTC, Bartek Jasicki
no flags Details | Diff
update to 7.0.4 (206.12 KB, patch)
2022-11-10 03:56 UTC, Alex S
no flags Details | Diff
update to 7.0.4 v2 (207.49 KB, patch)
2022-11-12 22:46 UTC, Alex S
no flags Details | Diff
update to 7.0.4 v3 (207.59 KB, patch)
2022-11-16 06:18 UTC, Alex S
iwtcex: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Aleksander Slomka 2022-04-10 16:15:07 UTC
Created attachment 233122 [details]
7.0 update patch

This updates wine-proton to version 7.0
Comment 1 Aleksander Slomka 2022-04-10 20:24:19 UTC
Created attachment 233136 [details]
7.0 update patch - new
Comment 2 Alex S 2022-04-11 01:59:38 UTC
This is mostly reasonable with a few misses:

1. BUILD_DEPENDS should contain `llvm${_LLVM_VERSION}>=0:devel/llvm${_LLVM_VERSION}`;
2. faudio, jpeg-turbo, libjxr, lcms2, png, libxml2 should be removed from LIB_DEPENDS (all these libs are bundled with Wine now);
3. USES still has `jpeg`;
4. CONFIGURE_ARGS still has `--without-mingw`; we should also borrow `--with-pcap`, `--with-pthread`, `--without-coreaudio`, `--without-gssapi`, `--without-netapi` from the wine-devel port.
5. I don't think we actually need `WINELIBDIR=	${PREFIX}/lib`;
6. we _definitely_ don't want to touch USE_LDCONFIG — nothing in this port should be present in any kind of default search paths;
7. trap codes were only fixed in wine-7.1, so patch-dlls_ntdll_unix_signal_x86_64.c is still necessary;
8. I don't quite remember what `export PATH="${TARGET%/*}:${PATH}"` line was doing in wine-wow64.sh, but I'd rather keep it in place for now;
9. also keep `export GST_PLUGIN_SYSTEM_PATH_1_0="${TARGET%/*/*/*}/lib/gstreamer-1.0"`.

Would you like to update the patch or should I make these adjustments for you?
Comment 3 Aleksander Slomka 2022-04-11 20:59:18 UTC
Created attachment 233154 [details]
7.0 update patch v2

Thanks for the feedback, I updated the patch according to your comment. Please let me know if anything else is needed.
Also, I noticed than enabling mingw introduced some issues when I tried the new build with steam, but that's probably because I accidentally patched linuxulator-steam-utils to work with Proton 7.0 with mingw disabled(which worked flawlessly).
Comment 4 Alex S 2022-04-12 11:06:21 UTC
(In reply to Aleksander Slomka from comment #3)

1. I've noticed there is a version of libpcap in base. Do we need net/libpcap specifically?
2. dlls/winevulkan/make_vulkan requires python3, so you should rather add `python:build` to USES and invoke it as `${PYTHON_CMD} dlls/winevulkan/make_vulkan` (BINARY_ALIAS for python3 didn't work for me for some reason).
3. Don't change `$PREFIX/bin/pkg32.sh` to `$PREFIX/share/wine/pkg32.sh`.

> Also, I noticed than enabling mingw introduced some issues when I tried the new build with steam, but that's probably because I accidentally patched linuxulator-steam-utils to work with Proton 7.0 with mingw disabled(which worked flawlessly).

What issues?
Comment 5 Aleksander Slomka 2022-04-13 20:33:06 UTC
Created attachment 233204 [details]
7.0 update patch v3

Looks like libpcap from base also works fine, so I removed the dependency. The other things you mentioned should also be resolved now.

> What issues?
I couldn't launch any games, but it turned out that my wine prefix was out of date (I generated it with the version without mingw enabled). After I made a new prefix everything started working as it should. 
When I workout the details I will make a PR to linuxulator-steam-utils.
Comment 6 Alex S 2022-05-01 05:59:52 UTC
I updated steam-utils' git repo (but not the port yet). Issues found with this Proton update so far:

1. There is a "err:winediag:gnutls_process_attach Compiled without DH support." warning we probably want to eliminate.
2. A few games got stuck at DX setup in my testing, this will take some time to troubleshoot.
Comment 7 Bartek Jasicki 2022-05-29 16:34:01 UTC
Created attachment 234314 [details]
6.3.2_5_to_7.0.patch

Thank you for your work, unfortunately, in the meantime, the version of wine-proton in the ports updated. This made the patch is no longer valid. I have a new one, it contains two changes in Makefile:

1. Updated version to 6.3.2_5
2. Added gstreamer to USES, as far I know, that was reason for a new version of the package.

I also have a question: there is available the new version of wine-proton: 7.0_2. Maybe update the port to this version? It needs a bit more patching. I have one, but it isn't fully tested. If someone wants, I can attach it here or create a new report.
Comment 8 Aleksander Slomka 2022-06-04 19:29:35 UTC
(In reply to Bartek Jasicki from comment #7)
> I also have a question: there is available the new version of wine-proton: 7.0_2. Maybe update the port to this version? It needs a bit more patching. I have one, but it isn't fully tested. If someone wants, I can attach it here or create a new report.

Sure, you can post it here and I try to fix the remaining issue. Right now, I have more free time at my disposal so I will try to make this upgrade be finally ready to be merged.
Comment 9 Bartek Jasicki 2022-06-05 17:07:12 UTC
Created attachment 234467 [details]
6.3.2_5_to_7.0.2.patch

Ok, so, here it is, the patch from 6.3.2_5 to 7.0_2. Changes:

In Makefile:

1. Same as in my previous patch, updated version to 6.3.2_5.
2. Added gstreamer to USES.
3. New version updated to 7.0_2.

The main change is the patch for `fsync.c`. Looks like this file has rewritten between versions and the old diff not working anymore. I updated it to the new version of the file with one not fully tested change: I use *return 0;* instead of *assert(0);* in code which shouldn't trigger. As far I see, it is the common way how that kind of code has written in the file and generally in the project's code. If there will be problems, I will switch patch again to use *assert(0);*.
Comment 10 Bartek Jasicki 2022-06-19 17:01:31 UTC
Created attachment 234789 [details]
6.3.2_5_to_7.0.3.patch

A few days ago, wine-proton upgraded to the new version 7.0_3. Here is the new patch for it.

In Makefile:

1. Same as in my previous patches, updated version to 6.3.2_5.
2. Added gstreamer to USES.
3. New version updated to 7.0_3.
4. Fixed generating winevulkan library from native Vulkan libraries. This issue exists probably in all versions of wine (stable, development, older versions of this one). By default, wine distributed with an outdated version of auto-generated winevulkan code. Earlier it wasn't a big problem, but with 7.0_3 Valve removed those files. The command `make_vulkan` has to be executed before the configuration stage or the wine-proton will not compile due to lack of proper header files. Additionally, I'm not sure did the previous version work correctly, it could not generate a new version of winevulkan code and compile the outdated one.

Fsync.h: updated the patch to the new version of the file. Again. ;)

That's probably all, I didn't notice any regression on my side, only the old ones difficulties observed in the previous versions (6.0 and older).
Comment 11 Thibault Payet 2022-08-17 15:27:47 UTC
Just out of curiosity, does this version of proton will support vulkan child window rendering ?

026c:fixme:vulkan:X11DRV_vkCreateWin32SurfaceKHR Application requires child window rendering, which is not implemented yet!
Comment 12 Bartek Jasicki 2022-08-17 17:01:17 UTC
(In reply to Thibault Payet from comment #11)

As far I know, not. This patch is available only in custom builds of Wine (like GE-TGK) not available in vanilla Wine or wine-proton.

And question to the maintainer, any progress in accepting it? By 2 months, no one reported any problems with the patch, so it could be ready to deploy. It also blocks a few other patches.
Comment 13 Alex S 2022-08-17 17:10:18 UTC
(In reply to Bartek Jasicki from comment #12)

> And question to the maintainer, any progress in accepting it?
> By 2 months, no one reported any problems with the patch,
> so it could be ready to deploy.

See comment #6.

> It also blocks a few other patches.

What would that be?
Comment 14 Bartek Jasicki 2022-08-18 05:18:31 UTC
(In reply to Alex S from comment #13)

1. It isn't a wine error. Wine informs you that your gnutls package was compiled without support for Diffie-Hellman algorithm. It may cause problems, especially with some communication protocols.

2. Hard to guess without minimal amount of information which allows reproducing the issue. If it has to be fixed, please give more information:
 a) The names of the games which don't work
 b) The architecture used by the games (64/32 bit)
 c) The manufacturer of your graphic card (Nvidia, AMD, Intel)
 d) The version of the graphic card driver.
At this moment, I can only guess: if the games are 32-bit, you have an Nvidia card, and you use nvidia-driver package, you are victim of the bug #263475.

> What would that be?

For example, the childwindow patch, or I could try to fix the bug mentioned above or bug with lack of sound, https://bugs.winehq.org/show_bug.cgi?id=50214
Comment 15 Alex S 2022-08-18 10:06:16 UTC
(In reply to Bartek Jasicki from comment #14)

> 1. It isn't a wine error. Wine informs you that your gnutls package was compiled without support for Diffie-Hellman algorithm. It may cause problems, especially with some communication protocols.

Well, you asked for blocking issues with the update, this is one of them.

> 2. Hard to guess without minimal amount of information which allows reproducing the issue.

I've got a feeling you aren't actually using this port in combination with linux-steam-utils.

> the bug mentioned above or bug with lack of sound, https://bugs.winehq.org/show_bug.cgi?id=50214

See bug 157050.
Comment 16 Bartek Jasicki 2022-08-18 11:18:41 UTC
(In reply to Alex S from comment #15)

> Well, you asked for blocking issues with the update, this is one of them.

So, the blocking issue is the maintainer? :) Jokes aside, please read my answer again. The problem is that *your* gnutls version was, for some reasons, compiled without Diffie-Hellman algorithm support. SAA#1 ;) I can't reproduce the error.

> I've got a feeling you aren't actually using this port in combination with linux-steam-utils.

And I got a feeling you aren't actually read my answer. :) Please answer on my questions. I can't help you, if you refuse to cooperate. As mentioned above, I don't have issues that you wrote, so I need information to reproduce them. At least the names of the games.

> See bug 157050.

Yes, I'm aware about it, thank you. :) It can also be implemented on an application level, that's why I want to do it on a separated bug report. It requires some “intensive” tests, mostly related to the possible performance concerns.
Comment 17 Alex S 2022-08-18 12:16:14 UTC
(In reply to Bartek Jasicki from comment #16)

> So, the blocking issue is the maintainer?

That's actually very common.

> The problem is that *your* gnutls version was, for some reasons, compiled without Diffie-Hellman algorithm support.

It's not. In fact, as you might infer from the HAVE_GMP_H ifdef in the code, that issue has nothing to do with gnutls at all. And, for the record, I already know what the actual issue is (configure.ac and configure being out of sync), it's the total radio silence (and now a knee jerk dismissal) part that annoys me.

> At least the names of the games.

It's the Proton's prefix setup procedure itself. It usually tries to install a few dependencies here and there (typically directx and msvc runtime) and that part _way too often_ hangs for me:

steam 56900   70,4  0,0    1108640    30732  -  R    15:11       0:17,94 Z:\\usr\\home\\steam\\.steam\\steam\\steamapps\\common\\Steamworks Shared\\_CommonRedist\\DirectX\\Jun2010\\DXSETUP.exe (wine.bin)
steam 56749   24,4  0,0      27924    15864  -  Rs   15:11       0:06,69 /usr/local/wine-proton/bin/wineserver
steam 56753    0,0  0,0    1750916    17760  -  Is   15:11       0:00,04 C:\\windows\\system32\\services.exe (wine64.bin)
steam 56759    0,0  0,0    1729096    19520  -  I    15:11       0:00,02 C:\\windows\\system32\\plugplay.exe (wine64.bin)
steam 56765    0,0  0,0    1721596    12496  -  I    15:11       0:00,01 C:\\windows\\system32\\svchost.exe (wine64.bin)
steam 56771    0,0  0,0    1738512    17076  -  I    15:11       0:00,01 C:\\windows\\system32\\rpcss.exe (wine64.bin)
steam 56845    0,0  0,0    1727740    25752  -  Is   15:11       0:00,06 C:\\windows\\system32\\tabtip.exe (wine64.bin)
steam 56855    0,0  0,0    1105732    27032  -  Is   15:11       0:00,05 legacycompat\\SteamService.exe (wine.bin)
steam 56857    0,0  0,0    1725288    22944  -  Is   15:11       0:00,05 C:\\windows\\system32\\conhost.exe (wine64.bin)
steam 56746    0,0  0,0    1723484    24284  4  I+   15:11       0:00,03 c:\\windows\\system32\\steam.exe (wine64.bin)
steam 56835    0,0  0,0    1719352    16484  4  I+   15:11       0:00,02 C:\\windows\\system32\\conhost.exe (wine64.bin)
steam 56837    0,0  0,0    1733604    27688  4  S+   15:11       0:00,08 C:\\windows\\system32\\explorer.exe (wine64.bin)
steam 56847    0,0  0,0    1098900    20592  4  S+   15:11       0:00,07 Z:\\home\\steam\\.steam\\steam\\legacycompat\\iscriptevaluator.exe (wine.bin)

I don't really have the inclination to debug that issue and there is no feedback of any kind, so I'm going to assume that's a showstopper.
Comment 18 Bartek Jasicki 2022-08-18 16:56:44 UTC
(In reply to Alex S from comment #17)

> That's actually very common.

:]

*snip* 
> (configure.ac and configure being out of sync) 
*snip*

Don't look at the configure file. It is one of “fake code” in Wine source. It is replaced by a new one during configuration. Wine has a lot of that code, which is just for fun. It isn't used because its newer version is generated before configuration phase. Especially the code related to Vulcan. Valve from time to time remove that outdated code… which usually ends in more problems. :) The whole process of build Wine is a bit long:

1. Some part of the code is (re)generated, created etc.
2. Autoconf generates configuration files. When it isn't generated for you, it is a bug.
3. The source code, old and generated, is configured.
4. Finally, start compilation.

It could be the second part is failing and can't for some reason detect needed libraries. Or it is the missing dependency for the package. Or it doesn't generate a new configuration file.

> It's the Proton's prefix setup procedure itself. It usually tries to install a few dependencies here and there (typically directx and msvc runtime) and that part _way too often_ hangs for me
*snip*

Ok, thank you for the explanation, now I understand. And I still think that could be something with configuration of the package. Question about this random hangs: They happen during downloading or executing?

I will try to look at it, just this will take some time. As far I see, Valve released the new version of wine-proton 7.0_4 which has some bugs fixed again.
Comment 19 Alex S 2022-08-18 17:42:06 UTC
(In reply to Bartek Jasicki from comment #18)

> Don't look at the configure file. It is one of “fake code” in Wine source. It is replaced by a new one during configuration. Wine has a lot of that code, which is just for fun.

I'm reasonably familiar with autotools. The point is that this configure script won't be regenerated unless we explicitly run autoconf, thus we need to add USES=autoreconf (see /usr/ports/Mk/Uses/autoreconf.mk) to the port's Makefile.

> It isn't used because its newer version is generated before configuration phase.

Nope.
Comment 20 Bartek Jasicki 2022-08-18 18:18:54 UTC
(In reply to Alex S from comment #19)

> I'm reasonably familiar with autotools. The point is that this configure script won't be regenerated unless we explicitly run autoconf, thus we need to add USES=autoreconf (see /usr/ports/Mk/Uses/autoreconf.mk) to the port's Makefile.

Then we probably have a bug here. It should be regenerated. The original configure file is for Linux, not FreeBSD. I think, USES=autoreconf should be in Makefile. I will test it, but feel free to do some tests either. ;)
Comment 21 Alex S 2022-11-10 03:56:38 UTC
Created attachment 237995 [details]
update to 7.0.4
Comment 22 Alex S 2022-11-12 22:46:15 UTC
Created attachment 238045 [details]
update to 7.0.4 v2
Comment 23 Alex S 2022-11-16 06:18:46 UTC
Created attachment 238111 [details]
update to 7.0.4 v3
Comment 24 Alex S 2022-11-16 06:23:28 UTC
(In reply to Alex S from comment #6)

For the record, the second issue vanished after https://github.com/shkhln/linuxulator-steam-utils/commit/4114ebcd82d97fe8ef0115b8eb25ac8f1ff9dd83.
Comment 25 Nuno Teixeira freebsd_committer freebsd_triage 2022-11-16 16:56:51 UTC
1.
USE_GCC=yes and BUILD_DEPENDS+=llvm${_LLVM_VERSION}>=0:devel/llvm${_LLVM_VERSION}?

2.
There are 2 llvm defaults: Mk/bsd.default-versions.mk:
---
.  if ${ARCH} == powerpc
LLVM_DEFAULT?=          10
.  else
LLVM_DEFAULT?=          90
---
why using:
---
if (${LLVM_DEFAULT} == 90 || ${LLVM_DEFAULT} == 10 || ${LLVM_DEFAULT} == 11)
_LLVM_VERSION=	12
.else
_LLVM_VERSION=	${LLVM_DEFAULT}
.endif
---
?
Can't be desired/needed llvm version be in BUILD_DEPENDS directly?

3.
Mk/bsd.options.desc.mk:PULSEAUDIO_DESC?= PulseAudio sound server support
Why changing it's default description to "Build winepulse.drv"?
Comment 26 Alex S 2022-11-16 18:03:49 UTC
(In reply to Nuno Teixeira from comment #25)

> USE_GCC=yes and BUILD_DEPENDS+=llvm${_LLVM_VERSION}>=0:devel/llvm${_LLVM_VERSION}?

We had stability issues in the past with pure Clang Wine build. We don't however have the ability to build Windows PE executables with GCC. (Wine uses both ELF and PE components.)

> There are 2 llvm defaults: Mk/bsd.default-versions.mk

We don't support PowerPC.

> Can't be desired/needed llvm version be in BUILD_DEPENDS directly?

I obviously expect LLVM_DEFAULT to be occasionally changed (not to mention people building their own packages). We don't have a preferred version, it's just that it should be >= 12.

> Mk/bsd.options.desc.mk:PULSEAUDIO_DESC?= PulseAudio sound server support
Why changing it's default description to "Build winepulse.drv"?

I didn't notice there is a default description. I specifically patched the port to not automatically enable PulseAudio in preference of OSS, though. Might be worth mentioning somewhere.
Comment 27 Nuno Teixeira freebsd_committer freebsd_triage 2022-11-16 20:39:28 UTC
(In reply to Alex S from comment #26)

Can't handle this port. Mix of gcc and llvm is new to me.

I'm cc'ed to this PR so I will follow it.

Thanks
Comment 28 Rainer Hurling freebsd_committer freebsd_triage 2022-11-20 20:37:26 UTC
I just tried to build Proton 7.0.4 patch v3 on FreeBSD 14.0-CURRENT amd64 (main-n259351-d0f168e680ff) and got the following breakage:


===>  Building for wine-proton-7.0.4
cd /poudriere/ports/default/emulators/wine-proton/work/wine-fb6e6af8928a29660e8cf797d43e028ea5bf8d23 && gmake depend
gmake[2]: Entering directory '/poudriere/ports/default/emulators/wine-proton/work/wine-fb6e6af8928a29660e8cf797d43e028ea5bf8d23'
tools/makedep
gmake[2]: Leaving directory '/poudriere/ports/default/emulators/wine-proton/work/wine-fb6e6af8928a29660e8cf797d43e028ea5bf8d23'
cd /poudriere/ports/default/emulators/wine-proton/work/wine-fb6e6af8928a29660e8cf797d43e028ea5bf8d23 && tools/make_requests
gmake[2]: Entering directory '/poudriere/ports/default/emulators/wine-proton/work/wine-fb6e6af8928a29660e8cf797d43e028ea5bf8d23'
clang -c -o dlls/acledit/main.cross.o dlls/acledit/main.c -Idlls/acledit -Iinclude -Iinclude/msvcrt -D__WINESRC__ \
  -DWINE_NO_LONG_TYPES -D_UCRT -D__WINE_PE_BUILD -Wall -target x86_64-windows -fno-strict-aliasing \
  -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Winit-self -Wno-pragma-pack \
  -Wstrict-prototypes -Wtype-limits -Wvla -Wwrite-strings -Wpointer-arith -Wabsolute-value \
  -Wno-format -Wnonnull -mcx16 -isystem /usr/local/include -isystem /poudriere/ports/default/emulators/wine-proton/files/clang
dlls/acledit/main.c:21:10: fatal error: 'stdarg.h' file not found
#include <stdarg.h>
         ^~~~~~~~~~
1 error generated.
gmake[2]: *** [Makefile:1997: dlls/acledit/main.cross.o] Error 1
gmake[2]: Leaving directory '/poudriere/ports/default/emulators/wine-proton/work/wine-fb6e6af8928a29660e8cf797d43e028ea5bf8d23'
*** Error code 1


Am I the only one?
Comment 29 Nuno Teixeira freebsd_committer freebsd_triage 2022-11-20 21:36:50 UTC
(In reply to Rainer Hurling from comment #28)

Testport ok on 13.1-RELEASE-p3 and 14.0-CURRENT 1400073
https://people.freebsd.org/~eduardo/logs/wine-proton/

Also tested on local current 8526120ad41c and builds fine.
Comment 30 Rainer Hurling freebsd_committer freebsd_triage 2022-11-22 17:53:23 UTC
(In reply to Nuno Teixeira from comment #29)

After trying again in Poudriere with 14.0-CURRENT and 13.1-STABLE and in an unclean environment of 14.0-CURRENT, my problem persisted: 'stdarg.h' file not found.

With further trial and error, I found that I had accidentally patched without -p1. After patching with -p1 everything is fine now, the update builds and installs without problems. 

Thanks for the retesting and the quick reply. And sorry for the noise.
Comment 31 Alex S 2022-11-23 00:17:58 UTC
So, would anybody actually commit this?
Comment 32 Rainer Hurling freebsd_committer freebsd_triage 2022-11-23 17:26:35 UTC
(In reply to Alex S from comment #31)

It seems that there is another dependent port in the tree: games/suyimazu.

And this port wants to use Proton-6.3. At least this version is referenced, as in docs/working-games.md. In the repo of Suyimazu the latest commits[1][2] against two scripts are hardcoded to Proton 6.3.

Has anyone tested games/suyimazu with Proton 7.0.4?


[1] https://codeberg.org/Alexander88207/Suyimazu/src/commit/6a6b05bf295a8a745f9926bedb7e327b98ecefab/Library/Scripts/Steam-wine-proton6.3-Final
[2] https://codeberg.org/Alexander88207/Suyimazu/src/branch/main/Library/Scripts/Steam-wine-proton6.3-Setup
Comment 33 Alexander Vereeken 2022-11-23 17:42:09 UTC
(In reply to Rainer Hurling from comment #32)

My thing (games/suyimazu) dont need not be considered. I've already prepared stuff for the 7th version and i'm also waiting for this here to be comitted.

My running games list serves as a possible orientation should something not run in the future.

Steam has now been copied to Steam-wine-proton-6.3. since version 7 has changed a few things and this allows to use steam with 6.3 if users need it.

If the new versions lands (the 7th version) things will be moved to the main library from testing.
Comment 34 commit-hook freebsd_committer freebsd_triage 2022-11-23 20:19:19 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=bbad8ab905cd0a9f76e5a50dc62b04541352f06f

commit bbad8ab905cd0a9f76e5a50dc62b04541352f06f
Author:     Aleksander Slomka <alex@alexslomka.xyz>
AuthorDate: 2022-11-23 19:45:37 +0000
Commit:     Rainer Hurling <rhurlin@FreeBSD.org>
CommitDate: 2022-11-23 20:17:37 +0000

    emulators/wine-proton: Update to 7.0.4

    Co-authored-by: Bartek Jasicki <thindil@laeran.pl>
    Co-authored-by: Alex S <iwtcex@gmail.com>

    Changelog: https://github.com/ValveSoftware/wine/blob/proton_7.0/ANNOUNCE

    PR:             263196

 emulators/wine-proton/Makefile                     |   67 +-
 emulators/wine-proton/distinfo                     |    6 +-
 emulators/wine-proton/files/clang/stdarg.h (new)   |   35 +
 .../patch-dlls__wineoss.drv__mmdevdrv.c (new)      |   18 +
 .../patch-dlls__winepulse.drv__mmdevdrv.c (new)    |   11 +
 .../files/patch-dlls_ntdll_unix_fsync.c (gone)     |   32 -
 .../files/patch-dlls_winebus.sys_bus_sdl.c (gone)  |   15 -
 .../wine-proton/files/patch-server_fsync.c (gone)  |   31 -
 emulators/wine-proton/files/patch-sysinfo (gone)   |   72 -
 emulators/wine-proton/files/wine-wow64.sh          |   14 +-
 emulators/wine-proton/files/wine.sh                |   11 +-
 emulators/wine-proton/pkg-plist                    | 3733 ++++++++------------
 12 files changed, 1646 insertions(+), 2399 deletions(-)
Comment 35 Rainer Hurling freebsd_committer freebsd_triage 2022-11-23 20:21:56 UTC
I just committed patch 7.0.4 v3 and hope, all is fine with it. Please test again, thanks.
Comment 36 Alex S 2022-11-26 11:19:28 UTC
Looks like the port no longer compiles on FreeBSD 12 due F_ADD_SEALS usage. Should we mark 12 as unsupported?