Hello @John-Gee, when did you test this? "Fixes bundled zenity binary" in the 2020-05-25 Steam client beta update should have helped with this.
Oh, that's interesting. I believe I tested this on the 26th, but I may have switched to the beta a couple hours later.
I just retested now and it was the same though.
Just in case, let me detail what I've just done:
[...]
Ok, I figured it out. When I removed both zenity and qarma, it worked. I wonder if it's using my system's zenity binary if it finds it, but maybe qarma is no good enough replacement and it just fails instead of using the bundled one.
Not sure if this is something you should worry about or not, so feel free to close this if you want.
One thing I have noticed is that on some systems, getcap and setcap both live in /usr/sbin/<get/setcap>
This, at the very least, is true for Debian.
Thus, getcap is not available without sudo. Is there a good way to fix that, or just symlink it somewhere else?
When I removed both zenity and qarma, it worked. I wonder if it's using my system's zenity binary if it finds it
It does:
# Prefer host zenity binary if available
export SYSTEM_ZENITY="$(which zenity 2>/dev/null)"
if [ -z ${SYSTEM_ZENITY} ]; then
export STEAM_ZENITY="zenity"
else
export STEAM_ZENITY="${SYSTEM_ZENITY}"
fi
Then what happens is, vrenv.sh adds steam-runtime directories to LD_LIBRARY_PATH. These include QT_DIR, which makes qarma not work, and dialog is not shown.
but maybe qarma is no good enough replacement and it just fails instead of using the bundled one.
Not sure if this is something you should worry about or not, so feel free to close this if you want.
qarma itself is good here. The problem is mismatch of the libraries: we have steam-runtime directories in PATH and LD_LIBRARY_PATH, but we're using system zenity instead of runtime one.
I think it would work if Steam would just call "zenity": it would get looked up in PATH, and with steam-runtime enabled, the runtime version would get picked up first. And, as a fallback, if runtime version is not found (e.g. runtime is disabled), it would go to system zenity next. But probably there was a reason to prefer system zenity over runtime one, so I don't know if it's possible to change it.
One thing I have noticed is that on some systems, getcap and setcap both live in /usr/sbin/<get/setcap>
This, at the very least, is true for Debian.
Thus, getcap is not available without sudo. Is there a good way to fix that, or just symlink it somewhere else?
I have it symlinked, but it didn't seem to require sudo to run. It'd be great if SteamVR would use whereis and then the actual path for stuff like that.
Nothing extracted yet.
Describe the bug
Hello,
this is a follow up on #342 .
In that bug I learned that I needed both polkit and zenity installed to have SteamVR get my root password and setup things as needed. Without zenity nothing happened (I had qarma which I thought was similar enough, I guess not), but there was no way for me to know I was missing something. A simple message about the missing dependencies would have been enough for me to know.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
3 should instead be: See a message about the missing dependency.
System Information (please complete the following information):
Thank you!