Arch Linux User Repository

Notes about this package

• If you encounter issues while using this package, please contact me here first before reporting an issue to the upstream repository. Don't post logs, link to them. If you are using Manjaro, another derivative or an AUR helper, please mention it, I DO NOT TEST AGAINST THEM AND I CANNOT KNOW WHAT MIGHT BE WRONG WITH THE DISTRO/HELPER OF YOUR CHOICE.

• It takes a LOT of time and space to build. Building with multiple jobs helps but might cause builds to fail in rare cases. Be sure to have at least 16GB of RAM if you are building on tmpfs

• It is NOT built against Steam Linux Runtime (Sniper, Soldier, etc) and as such it doesn't require it. Still, is detected by Steam and works properly (preferable through steam-native).

• This PKGBUILD uses CFLAGS, CXXFLAGS and LDFLAGS hardcoded in the PKGBUILD itself. By default it uses the same C[XX]FLAGS as upstream, namely -march=nocona and -mtune=core-avx2. To change them you will have to edit the PKGBUILD itself. Due to the nature of this package some flags can cause it to fail to build or not function properly. I try to filter them out but it is based on testing. If you have a feeling that compile-time options are involved in the issues you are having please include them in your comment. Currently the filtered options are -fstack-protector-{,-strong,-all}(dxvk and vkd3d only), -fno-plt, -z,relro, -z,now. Also the use of AVX instructions is disabled through -mno-avx.

• There have been reports with afdko failing to find its dependencies during building. I can't do anything about that as I don't maintain that package. It is NOT an issue with this package and I haven't found a way to not depend on it. Please don't report fails due to afdko (or any of its python- dependencies, they are pulled in due to afdko and only used by that), it has been discussed enough. There are possible workarounds in the comments.

• It contains a patch to store game prefixes in the main Steam Library under $HOME/.local/share/Steam/steamapps/compatdata. It helps with isolation of game prefixes between users and works around issues with shared libraries on NTFS partitions due to drive symlinks. To enable it, set the PROTON_USER_COMPAT_DATA env variable to 1.

• This package requires a Rust 32 bit target, please run rustup target install i686-unknown-linux-gnu BEFORE posting any issues if you're using rustup.

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.

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

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

The patches aren't working with v4.11.11:

patching file build/makefile_base.mak
Hunk #6 succeeded at 267 (offset -4 lines).
Hunk #7 succeeded at 383 (offset -5 lines).
Hunk #8 succeeded at 422 (offset -5 lines).
Hunk #9 succeeded at 434 (offset -5 lines).
Hunk #10 FAILED at 475.
Hunk #11 succeeded at 533 (offset -5 lines).
Hunk #12 succeeded at 567 (offset -5 lines).
Hunk #13 succeeded at 622 (offset -5 lines).
Hunk #14 succeeded at 658 (offset -5 lines).
Hunk #15 succeeded at 863 (offset -5 lines).
Hunk #16 succeeded at 1061 (offset -5 lines).
Hunk #17 succeeded at 1114 (offset -5 lines).
Hunk #18 succeeded at 1195 (offset -5 lines).
Hunk #19 succeeded at 1216 (offset -5 lines).
Hunk #20 FAILED at 1279.
Hunk #21 succeeded at 1276 with fuzz 2 (offset -53 lines).
Hunk #22 succeeded at 1286 (offset -53 lines).
Hunk #23 succeeded at 1311 (offset -53 lines).
Hunk #24 succeeded at 1336 (offset -53 lines).
Hunk #25 succeeded at 1362 (offset -53 lines).
Hunk #26 succeeded at 1404 (offset -53 lines).
2 out of 26 hunks FAILED -- saving rejects to file build/makefile_base.mak.rej

need modify PKGBUILD in prepare()

comment > #git clone --recurse-submodules https://github.com/ValveSoftware/Proton.git . uncoment > sed -i 's,wined3d-interop.h,wine/wined3d-interop.h,g' vrclient_x64/vrclient_x64/*

Same issue as @Agafron and @jakbyte.

Same issue as Agafron.

in build proccess have an error ==> Starting prepare()... fatal: destination path '.' already exists and is not an empty directory.

?

It happens too me too, but not every time consistently. It is not going to forget it every time, but if it forgets it once, then it won't remember it at the next start.

My workaround has been to have a valve proton distribution selected in the global options and then select proton-native on a per game basis.

I don't know why it might be happening, it could be because it doesn't find the dist.lock file? But even if it was there, it should be user-writable, which defeats the whole system-wide installation.

If this happens for a title that has a native port, it will trigger a redownload, which in my case at least, is going to fail eventually to merge the newly downloaded files with the existing installation. In that case, the workaround I use, is to stop the download, select a Valve proton and restart a client.

This has happened to me no matter the way I have used to make steam aware of proton-native, either by placing it in /usr/share/steam/compatibilitytools.d or by the older way I used, by providing a compatibilitytools.vdf with a path to the install location (it used to be in /opt/proton-native)

If I choose to run other titles with proton-native and restart Steam, the Enable Steam Play for all other titles checkbox is unchecked. Checking it and restarting results in it being unchecked again.