Package Details: proton-native 4.11.12-4

Git Clone URL: (read-only, click to copy)
Package Base: proton-native
Description: Compatibility tool for Steam Play based on Wine and additional components. Monolithic distribution
Upstream URL:
Licenses: custom
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 3
Popularity: 0.79
First Submitted: 2019-11-12 13:24
Last Updated: 2020-01-16 23:09

Dependencies (161)

Required by (0)

Sources (13)

Latest Comments

1 2 Next › Last »

loathingkernel commented on 2020-01-16 13:46

Yeah, I should stop pushing changes in the late night. I messed up the CFLAGS filter. Will fix.

That explains some of the issues I have been having with the latest version myself. In my case it is that dxvk (and wine for that matter) really dislikes being build with AVX. In your specific case though it was the -fstack-protector[-whatever] flag.

Anyways the relevant sections in the PKGBUILD should be

dxvk_cflags="${dxvk_cflags// -O+([0-3s]|fast)/}"

dxvk_cflags="${dxvk_cflags/ -fno-plt/}"

Will push the fix when I test it again.

yochananmarqos commented on 2020-01-15 22:49

meson is required to build:

/bin/bash: line 1: meson: command not found
make[1]: *** [../proton/build/makefile_base.mak:1239: obj-dxvk32/] Error 127
make[1]: Leaving directory '/home/yochanan/Documents/pkgbuilds/proton-native/src/build'
make: *** [../proton/build/makefile_base.mak:17: nested_make] Error 2

EDIT: Probably glslang as well since it's required to build dxvk-mingw.

EDIT: ...and it failed to build again, not sure why this time. Here's the relevant part of the build log:

loathingkernel commented on 2020-01-14 22:01

As far as wine-valve-git is concerned, I am against it because it would require extensive patching to proton to use it from the system-wide installation path, and it would require replacing the official wine or wine-staging packages. Personally I use wine-staging from the repos to run games outside steam. Also, wine-valve-git is installed to the regular paths /usr/lib32 and /usr/lib where wine built to be used with proton uses usr/lib and usr/lib64 respectively. There are a few other subtle differences here and there and that is why I used this route (patching the makefile) to build proton locally. Also, I like having control over how wine is built to avoid inconsistencies.

I have considered adding vkd3d-valve-git and lib32-vkd3d-valve-git in the previous release that it wouldn't build without vkd3d from valve. I don't like that they are git packages and don't point to specific fragments and that they require spirv-headers-git. If they were in sync with the commit of the submodule in proton I would reconsider it. Also I am not sure where I stand in requiring to replace them system-wide. I don't want to force any specific version of another package if I don't need to onto anyone using proton-native. On the other hand, they add about 5Mb to the installation, IIRC, so space-wise it is negligible.

Also, what the fuck is dxvk_config? Fucking hell, it's gonna have to build dxvk now too...

@yochananmarqos: I would also like your input on using a python virtualenv and installing afdko through pip install during the build process to use that to build the fonts. Usually whenever I try to build proton-native there is a version mismatch in one of the python libraries required by afdko. I know, doing that it is fugly and I hate it myself, but have you experienced it yourself? Do you have any better solutions or suggestions?

yochananmarqos commented on 2020-01-14 21:30

What do you think about adding the wine-valve-git, vkd3d-valve-git & lib32-vkd3d-valve-gitpackages as dependencies instead of directly pulling git repos? That would make things a bit more concise with sorting what dependencies are actually for what instead of having all the wine dependencies.

yochananmarqos commented on 2019-12-25 15:56

wine_gecko is now wine-gecko, FYI.

loathingkernel commented on 2019-12-19 23:57

I just tested it with dxvk-bin. makepkg detected it and started building correctly. I assumed that the issue was that dxvk-bin was using a split-package workflow while building only one package, but that is not the case. I have no idea why this is happening either.

yochananmarqos commented on 2019-12-19 23:40

It does it with both makepkg and yay. It doesn't make any sense because everything looks right.

loathingkernel commented on 2019-12-19 23:31

The maintainer of dxvk-bin said something similar. Does it happen with makepkg or an AUR helper? makepkg finds it correctly here, but I have dxvk-mingw installed, although it has the same exact provides array.

yochananmarqos commented on 2019-12-19 23:22

Thanks, it built fine. Too late now, but you forgot to reset the pkgrel back to 1.

For some reason it won't detect dxvk-bin 1.5-3 as dxvk>=1.5

loathingkernel commented on 2019-12-19 22:21

Yeah, they need rebasing with almost every version. I just updated, please test as I can't build it right now.