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.

@ynikitenko: so what you're saying is that this is in no way related to this package, but rather to wine-valve, and yet you commented here anyway?

Failed to install, because it required wine-valve, which did not compile (the end of the log is here: https://pastebin.com/y1Q61tQU).

@BrainDamage no it is not missing, it is yay being silly and not retaining its environment during building. I have adapted the PKGBUILD since.

python-pefile is missing from the build deps list, otherwise it'll fail to build with the error:

cd /home/cloud/temp/proton-native/src/build/dst-lsteamclient32/lib && find -type f -name '*.dll' -printf '/home/cloud/temp/proton-native/src/build/dist/dist/lib/%p\0' | xargs --verbose -0 -r -P1 -n1 /home/cloud/temp/proton-native/src/proton/make/pefixup.py
/home/cloud/temp/proton-native/src/proton/make/pefixup.py /home/cloud/temp/proton-native/src/build/dist/dist/lib/./wine/fakedlls/lsteamclient.dll
Traceback (most recent call last):
  File "/home/cloud/temp/proton-native/src/proton/make/pefixup.py", line 6, in <module>
  import pefile
ModuleNotFoundError: No module named 'pefile'
make[2]: *** [../proton/build/makefile_base.mak:600: /home/cloud/temp/proton-native/src/build/.lsteamclient-dist32] Error 123

oops... not sure how i didn't notice the edit. re: transition... not quite sure tbh. i guess the only thing that may be a problem is a possible conflict re: the proton executable? i have it somehow, no idea what's providing it. pacman says it's owned by an old version of proton-ge-custom which is a bit odd

edit: other than that it should be fine? given that proton-native is (i'm assuming) basically this (so a drop-in replacement) but with... actual proton

fwiw might want to look into replacing proton-git too?

I don't think it is needed. They push updates to their git only on releases. Maybe a package like proton-experimental tracking the experimental releases would be useful.

EDIT: if you are ok with it, how do you think we should handle the transition?

i just make sure it builds, so no complaints here. don't think my system can handle building the entire thing anyway. fwiw might want to look into replacing proton-git too?

The original plan was to package proton itself. But that never came about.

I tried to do that split package for proton myself but due to the need for extensive patching and that I wanted to provide something that was as close as possible to the upstream package I decided to just patch it to the point that it built without issues instead of splitting it.

If you package proton-native provides the proton binary, then IMO it should replace this package.

It works and function just like proton from valve for all intents and purposes, just built on Arch libraries and without the need for the Valve runtime. It is one big monolithic thing that includes everything the upstream package would.

I want to ask, why is this named proton since it doesn't provide the main proton executable and it can't be used through steam?

The original plan was to package proton itself. But that never came about.

I am asking because I maintain a complete proton package but the name proton-native that I am using already exists as a React framework and it might cause confusion or issues in the future.

If your package proton-native provides the proton binary, then IMO it should replace this package.