Package Details: proton 2:9.0.3.5-1

Git Clone URL: https://aur.archlinux.org/proton.git (read-only, click to copy)
Package Base: proton
Description: Compatibility tool for Steam Play based on Wine and additional components
Upstream URL: https://github.com/ValveSoftware/Proton
Keywords: dxvk proton steam valve vkd3d wine
Licenses: custom
Submitter: Forty-Bot
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 112
Popularity: 1.55
First Submitted: 2018-08-22 01:23 (UTC)
Last Updated: 2024-11-16 17:23 (UTC)

Dependencies (115)

Required by (4)

Sources (10)

Pinned Comments

loathingkernel commented on 2020-10-22 08:43 (UTC) (edited on 2022-06-15 14:11 (UTC) by loathingkernel)

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.

Latest Comments

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 13 .. 24 Next › Last »

pvizc commented on 2022-05-07 13:51 (UTC)

@mihalycsaba I got the same problem building the package. I could fix it by disabling the threaded compilation. Eg: MAKEFLAGS=-j1

loathingkernel commented on 2022-05-06 14:21 (UTC)

@mihalycsaba I don't know then. I just re-built the package in a clean chroot to test and it built correctly. This is probably on your end.

mihalycsaba commented on 2022-05-06 14:17 (UTC)

@loathingkernel I don't use the testing repo, but the binutils got updated too on may 4, so it's now in the community repo. I don't know how to fix this.

loathingkernel commented on 2022-05-06 13:52 (UTC) (edited on 2022-05-06 13:54 (UTC) by loathingkernel)

@mihalycsaba To me it looks like the tool failing is part of mingw-w64-binutils

/usr/bin/i686-w64-mingw32-dlltool is owned by mingw-w64-binutils 2.38-2

Someone reported a similar issue with wine-ge-custom which was due to using mingw-w64-binutils from community-testing repository.

mihalycsaba commented on 2022-05-06 10:54 (UTC) (edited on 2022-05-06 10:56 (UTC) by mihalycsaba)

There was a mingw-w64-tools update a few days ago and the build fails now. Tried reinstalling the mingw-w64-tools.

  /home/csaba/.cache/yay/proton/src/build/src-wine/dlls/kernelbase/kernelbase.spec
Assembler messages:
Error: can't open rpcrt4_dll_t.s for reading: No such file or directory
/usr/bin/i686-w64-mingw32-dlltool: /usr/bin/i686-w64-mingw32-as exited with status 1
/usr/bin/i686-w64-mingw32-dlltool: failed to open temporary tail file: rpcrt4_dll_t.o: No such file or directory
winebuild: /usr/bin/i686-w64-mingw32-dlltool failed with status 1
make[3]: *** [Makefile:341657: dlls/rpcrt4/librpcrt4.delay.a] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/home/csaba/.cache/yay/proton/src/build/obj-wine32'
make[2]: *** [../proton/Makefile.in:717: /home/csaba/.cache/yay/proton/src/build/.wine-build32] Error 2
make[2]: Leaving directory '/home/csaba/.cache/yay/proton/src/build'
make[1]: *** [../proton/Makefile.in:121: container-build] Error 2
make[1]: Leaving directory '/home/csaba/.cache/yay/proton/src/build'
make: *** [../proton/Makefile.in:32: nested_make] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: proton

loathingkernel commented on 2022-03-30 22:25 (UTC) (edited on 2022-03-30 22:25 (UTC) by loathingkernel)

@Nu4425 Yes, the mingw-w64-crt package doesn't contain the following two tools which are required for the package to build.

mingw-w64-tools /usr/bin/i686-w64-mingw32-widl
mingw-w64-tools /usr/bin/x86_64-w64-mingw32-widl

The mingw-w64-tools package doesn't get updates regularly (it doesn't need them) so installing it manually through makepkg itself once is a workable alternative.

Nu4425 commented on 2022-03-30 22:09 (UTC) (edited on 2022-03-30 22:59 (UTC) by Nu4425)

@loathingkernel thanks. Also, is there any specific reason why mingw-w64-tools was chosen as a make dependency rather Arch's mingw-w64-crt when both packages pull from the same source?

I'm having integrity check problems with mingw-w64-tools when using paru, which is causing the build to fail

Edit: The integrity check problem seemed to be temporary. After re-trying sometime later, it was able to pass for some reason

loathingkernel commented on 2022-03-23 18:43 (UTC)

@Nu4425 No,it doesn't use any sandboxing, and basically that is the reason it exists as a package. The sandboxing in Proton from Valve and Proton-GE is in reality a side-effect of the runtime. It is used to make the process prioritize shared libraries existing in the runtime over those in the system.

This package doesn't need it, as it is built linking to the system libraries. Pressure vessel is avoided on purpose, and running this version in it would most likely break it.

I have not tried running it in a sandbox, and it is not something that I see the benefit of, but feel free to try it. It should be an interesting experiment.

Nu4425 commented on 2022-03-23 01:33 (UTC) (edited on 2022-03-23 02:02 (UTC) by Nu4425)

@loathingkernel do you happen to know if this proton build uses sandboxing?

When observing the process tree with this proton, games run through Steam are directly under a process called "reaper". While for another build, like proton-ge, games are nested under the "pv-bwrap" and a pressure-vessel process which are bubblewrap related.

If this is the case, that the sandboxing mechanism is absent, then is it advised that users apply their own sandboxing solution?

loathingkernel commented on 2022-02-28 12:26 (UTC)

@kopfik.petr No, they do not use this PKGBUILD and I don't think they will. They want a common base for everything in steam that won't break randomly due to Arch updates and I would also assume that they might want to be able move distributions at any point. They have done an excellent job at providing the stable base they needed with steam-runtime.

Possibly Steam Deck could use this package but it's better to leave it to the initiated for experimentation. I cannot test it nor I can endorse it.

If you want readily made packages, you can either use one for the repositories that provide them, or my own from here

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 13 .. 24 Next › Last »