AUR builds with unusual build requirements (e.g. CUDA) broken

krakoi commented 17 hours ago

pikaur -Vq
Pikaur v1.30.2
Pacman v7.0.0 - libalpm v15.0.0 - pyalpm v0.10.6

Prerequisites:

CUDA, or other unusual build environment needing custom PATH and envrionment variables.

Description:

The privilege escalation mechanism of pikaur breaks some AUR packages that require an unusual build environment, such as CUDA. Running makepkg as pikaur does (e.g., sudo --user=#1000 -- makepkg --force) does not properly use the user's PATH and environment variables by default (see /etc/profile.d/cuda.sh). This issue can be worked around in two ways:

By setting PrivilegeEscalationTarget to pacman, which essentially disables the convenience of not having to type passwords multiple times.
By modifying the PreserveEnv configuration of pikaur and adding CUDA to the secure_path in /etc/sudoers. However, I'm not entirely sure if this approach is secure. It’s also quite complex and inconvenient, especially given the lack of documentation and the need for manual updates whenever the CUDA environment changes.

The issue with pikaur's current default settings is significant enough that there are numerous error reports in AUR packages likely related to this problem. For example, see this comment in the cuda_memtest package (a simple package to reproduce the issue locally).

I'm not sure what the proper solution would be, but the current default settings of pikaur are clearly problematic. Most users encountering these issues are unaware that they stem from how pikaur executes the makepkg command.

Attached log:

pikaur -S cuda_memtest

==> Starting prepare()...
==> Starting pkgver()...
==> Updated version: cuda_memtest r97.7affd32-1
==> Starting build()...
-- The CXX compiler identification is GNU 14.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at /usr/share/cmake/Modules/Internal/CMakeCUDAFindToolkit.cmake:104 (message):
  Failed to find nvcc.

  Compiler requires the CUDA toolkit.  Please set the CUDAToolkit_ROOT
  variable.
Call Stack (most recent call first):
  /usr/share/cmake/Modules/CMakeDetermineCUDACompiler.cmake:85 (cmake_cuda_find_toolkit)
  CMakeLists.txt:44 (enable_language)

-- Configuring incomplete, errors occurred!
==> ERROR: A failure occurred in build().
    Aborting...

Command 'sudo --user=#1000 -- makepkg --force' failed to execute.

actionless commented 17 hours ago

i think that's a problem on the build side (it needs to source that file explicitly inside the build), i'll describe the potential scenario why it's so:

1) you have a clean build system with only base and base-devel being installed 2) you starting to build this package 3) cuda package, which provides this cuda.sh profile extension config is being installed 4) the build continues and fails because just installed cuda.sh file wasn't sourced yet

actionless commented 17 hours ago

By modifying the PreserveEnv configuration of pikaur

that's recommended workaround approach, although as mentioned in the message above, this must be fixed on the package side.

and adding CUDA to the secure_path in /etc/sudoers. However, I'm not entirely sure if this approach is secure.

i dunno why you'd want to do that at first place

It’s also quite complex and inconvenient, especially given the lack of documentation

if you'd try opening the documentation you'd find it

and the need for manual updates whenever the CUDA environment changes.

that's not true, it needs updating only if cuda would decide to change the names of their env vars

krakoi commented 15 hours ago

@actionless

i think that's a problem on the build side (it needs to source that file explicitly inside the build)

You're right, but it doesn't work (anymore?). I mean, you can't simply source /etc/profile.d files because they rely on helper functions defined in /etc/profile. For example, if I add source /etc/profile.d/cuda.sh to the PKGBUILD of the previously mentioned cuda_memtest package, I get this error:

==> Starting build()...
/etc/profile.d/cuda.sh: line 2: append_path: command not found
==> ERROR: A failure occurred in build().
    Aborting...

Command 'sudo --user=#1000 -- makepkg --force' failed to execute.

It's quite possible that I'm missing something (I'm obviously not an expert with Arch PKGBUILD files), but it seems the average AUR packager is missing it too, as they typically don't source /etc/profile.d/cuda.sh in cuda-built packages (at least in the few examples I've checked). In fact, I've seen examples where it was sourced once but was later intentionally removed. See:

https://aur.archlinux.org/cgit/aur.git/commit/?h=vapoursynth-plugin-bm3dcuda-git&id=a82cf87e6f7d861236dc74334be9a5030f358a9d

actionless commented 13 hours ago

the fact that many packages have that same problem doesn't turn a problem into non-problem

krakoi commented 13 hours ago

the fact that many packages have that same problem doesn't turn a problem into non-problem

Okay, can you recommend a proper solution? I can accept that this issue should be fixed in the package PKGBUILD files, but how? As I mentioned in my last comment, you can't simply source /etc/profile.d/cuda.sh.

I'd be eager to recommend a fix for the AUR packages that break on my system due to this issue, but I'm not aware of a proper solution.

actionless commented 13 hours ago

i think the easiest way to work it around for you now would be to source the whole profile - it's still much better then letting package build process to use user's current env vars

actionless commented 12 hours ago

but on the package side i think just those env vars need to be set explicitly

krakoi commented 12 hours ago

i think the easiest way to work it around for you now would be to source the whole profile - it's still much better then letting package build process to use user's current env vars

Couldn't pikaur do that automatically somehow? If not by default, then at least after setting a config var or using a flag (like --preserve-env).

but on the package side i think just those env vars need to be set explicitly

The main issue with that is that the whole problem is specific to running makepkg with sudo, like how pikaur does. If you do the compilation manually—so you fetch the repository using git and run makepkg as your user (like it's explained on the Arch Wiki, without sudo)—then there's no issue, because /etc/profile has already set the necessary environment for your user.

What you recommend is that for each CUDA-built package the maintainer should set up the proper CUDA environment from scratch just for the sake of some tools like pikaur...

actionless commented 12 hours ago

If you do the compilation manually—so you fetch the repository using git and run makepkg as your user (like it's explained on the Arch Wiki, without sudo)—then there's no issue, because /etc/profile has already set the necessary environment for your user.

no, that's not true, again read the https://github.com/actionless/pikaur/issues/850#issuecomment-2514108072

actionless / pikaur