Scope configuration error when launching pre-release 1.0.0b
Upon launching YARC 1.0.0b, I'm presented with a white screen with an error about a configured scope.
Checking the logs, It's just a repeated output of this:
[2024-08-25][16:54:52][DEBUG][reqwest::connect] starting new connection: https://releases.yarg.in/ [2024-08-25][16:54:52][ERROR][webview] "path not allowed on the configured scope: /home/AmpliFreQuency/.config/in.yarg.launcher/"
I am running Bazzite 40 (Fedora) on a Steam Deck
I have tried launching in both gaming and desktop mode, with and without the WEBKIT_DISABLE_COMPOSITING_MODE launch option, to no avail.
Versions prior to 1.0.0.b work fine.
Thanks for the report! So, it's likely because Tauri isn't letting the settings file to be created because this is the scope that is defined:
According to the docs, this is what that resolves to:
${bundleIdentifier} is in.yarg.launcher, and ${configDir} resolves to:
So my question is, does $HOME correctly point to /home/AmpliFreQuency/, and does $XDG_CONFIG_HOME correctly point to /home/AmpliFreQuency/.config/? If so, this is likely a bug from Tauri's side that I'll have to look into.
Sorry for the inconvenience!
Not a problem at all!
I can confirm that $HOME and @XDG_CONFIG_HOME points to /home/AmpliFreQuency and /home/AmpliFreQuency/.config respectively.
Is that colon supposed to be on the end of $XDG_CONFIG_HOME? (I don't use linux so idk lol)
Good eye! That is definitely not supposed to be there. I've created an override in my ~/.bashrc to fix that:
if ! [[ "$XDG_CONFIG_HOME" =~ "$HOME/.config" ]]; then XDG_CONFIG_HOME="$HOME/.config" fi export XDG_CONFIG_HOME
And for good measure, I tried using the direct path of /home/AmpliFreQuency/.config
if ! [[ "$XDG_CONFIG_HOME" =~ "/home/AmpliFreQuency/.config" ]]; then XDG_CONFIG_HOME="/home/AmpliFreQuency/.config" fi export XDG_CONFIG_HOME
Unfortunately, I still get the scope error with YARC. The in.yarg.launcher gets created in the .config folder of my home directory, along with a logs subdirectory in it and a YARC Launcher.log, but nothing else in that in.yarg.launcher folder is created.
Now (again, my lack of Linux knowledge is gonna be apparent here), does it also update that value for the launcher, or is it only in the console?
The change seems to only affect console and not the launcher at all :/
Likely not super helpful but i did manage to get it to work here under the same distro (bazzite-deck)
By extracting the appimage and running the Apprun.sh in a distrobox (just a standard fedora one) it works without and issue
Having the same symptoms and same issue with latest version of the launcher on Fedora Silverblue 40.
Console/log output is:
[2025-01-20][20:53:23][DEBUG][reqwest::connect] starting new connection: https://releases.yarg.in/
[2025-01-20][20:53:24][ERROR][webview] "path not allowed on the configured scope: /home/aed/.config/in.yarg.launcher/"
Something seems to be broken that is causing it to not work on immutable linux distros (like Bazzite & Fedora Silverblue). I believe they handle permissions differently from regular linux distros. I will probably go back to regular Fedora Workstation to see if the issue persists there.
All of my files are on separate drives from my OS drive, so I re-installed Silverblue (41) just for kicks to see if it was an issue with my install of Silverblue prior.
Everything works flawlessly with YARC launcher. Launches, I can use mouse input , etc.
I re-based at one point in time to Bazzite and a bunch of other ublue flavors, so I wonder if rebasing irrevocably messed something up with my system. All good for me now.
Having same issue, and unable to apply the workaround through distrobox
Same issue on bazzite as @giwty and YARG in distrobox crashes when trying to add songs. I'd love a native solution here!
Played with it today and got it to work. Created https://github.com/YARC-Official/YARC-Launcher/pull/60
this issue happened to me when i symlinked my home directory to a different, non-root hard drive. i can confirm that the fix in #60 does work for me as well.
this issue should is fixed now as PR #68 was merged in