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.

steam deck is using Arch linux, am I right? do somebody know, whether they are using this AUR package for the proton? i wonder if gamers would need to compile the package each time there is an update or if steam distributes it precompiled? i have no problem compiling it on my 5800X in tmpfs, yes sure it takes like 15 minutes maybe?, but my mini PC with celeron j4125 has only 8GB and the cpu has a 1/10 of the 5800X horse power... it takes like... a half day to compile.

@Nu4425 The intention is the overwrite them, yes. The current default Arch FLAGS will make a number of things fail and this was the easier way to provide both easily mutable FLAGS and retain the original FLAGS at the same time. The lines you refer to were left in as documentation/notice of sorts.

On another note, the proton repo moved the submodules point to the github mirrors and I might update them too at some point if the issues continue.

@loathingkernel thank you. Also, sorry if I am missing something, but are lines 295-306 in the PKGBUILD supposed to be commented? Presumably, redeclaration of CFLAGS, CXXFLAGS, and LDFLAGS will overwrite the previous states.

I just want to make sure that the intention wasn't to update than to overwrite.

@Nu4425 I am aware of the issue but thanks for finding the related issue in the bug tracker.

I could move it to the github mirrors but that would have the subtle side-effect of causing issues with the SRCDEST shared sources directory supported by pacman (which incidentally I use).

As a workaround, the other repositories can be updated manually and build it with the --holdver makepkg option to not update sources while building.

@loathingkernel for this build to be successful it requires the hosts for the upstream gstreamer repositories to be online and reliable. Currently, there are connectivity issues in gstreamers gitlab servers that is causing this package's build process to hang when retrieving sources via git-clone.

See https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/407 for details.

Any suggested workarounds for this?

@arvin Given that the package works through submodules I doubt that manually downloading the source will build the exact same package that upstream intents. It can be done it should be rather tedious.

The gstreamer repo fails to clone and the package building halts at that point. This happens with makepkg -si and aura AUR helper. I even disabled sslvarify on .gitconfig but it didn't work still. Is there a way to download the repo or change PKGBUILD?

@Ninjoh Thank you for looking into it and providing an answer, I am not particularly knowledgeable about how Rust tooling works and I wouldn't be able to figure it out on my own.

For now I have pinned your comment, pending looking into if the toolchain should be pinned to stable at all. It just seemed like the sanest of choices at the time.

@loathingkernel After taking a detailed look at the PKGBUILD, I noticed that it explicitly, unconditionally, selects the stable Rust toolchain. I'm usually working with the nightly toolchain so that toolchain is set as my default. This means that when I run rustup target add i686-unknown-linux-gnu, it will add it to the nightly toolchain. But, the PKGBUILD selects the stable toolchain and I hadn't ran rustup target add i686-unknown-linux-gnu against that one, so the target was not available on the stable toolchain.

Setting the default toolchain to stable with rustup default stable, and then running rustup target add i686-unknown-linux-gnu solved the issue, and now it compiles just fine.

Perhaps it is of use to add to your notes comment that rustup users should ensure that the i686-unknown-linux-gnu target is installed on the stable toolchain.