Arch Linux User Repository

Potential breaking change: the service file security has been tightened. If you altered it any way on your machine, you might not be able to start ASF.

You can debug the problem introduced with SystemCallFilter, by following https://unix.stackexchange.com/a/681075

Starting with 5.1.4.0-1, the custom service files provided with this package have been replaced with the one upstream.

It uses a EnvironmentFile in /etc/asf to point to the right dir (remember, you want n-1 from asf config folder).

It also serves to populate the user and home folder for the daemon.

@JustArchi thank you for taking the time to answer here. I was the one who asked about the path setting in Github by the way. I was going to post a few extra suggestions in Github regarding this, maybe having the default behaviour to be compliant with XDG specification[1], I don't really know if this should be implemented at package level or the application level. Probably for the package level the application should have a few parameters to allow for it (maybe with --path is enough). I do think that running the application (if it is installed at system level) should check for the ~/.config/asf/config folder of the user running it, if its not found, fallback to the $INSTALLED_DIR/config, which might or might not work. The --path flag should be specified at runlevel when you want an exception (for ex. to run a profile found in another folder than the default in your home). Please tell me if this makes sense. Example with user bob. bob@archlinux ]$ asf Should search for the config files in: /home/bob/.config/asf/config @Gilrain I rather run it as my own user, I don't like having services running in the background unless needed, and as I'm not a "24/7 farmer", I didn't think of making a systemd unit. I understand the reason to do it though. Thanks for the heads up. Anyway, I didn't like the service saving user data to /opt/asf/config (particularly if you are in a multi user environment), that's why I asked about the config path. It would be great if you continue the issue to allow for the changes needed for the application to be package-friendly. Thanks to both of you for the attention to the issue. ps. forgot links: [1] https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html [2] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html [3] https://wiki.archlinux.org/index.php/XDG_user_directories

@sud_crow Your workaround is valid, though not recommended. I would advise "sudo -u asf -g asf -H /usr/bin/asf" for interactive operations. For now the package default mode of operation is to execute asf as a --server through a systemd service. Since farming takes hours, I thought it was sensible to set it and forget its existence. Any other way requires some expertise on the part of the end user (which should not blindly install AUR packages anyway). @JustArchi Thank you for the explanation. I missed that issue during my cursory look at the repo.

@Gilrain It was retroactively changed to not raise false-positive for Windows users due to including ASF-Service.exe in the zip that uses different repacking method to stay compatible with being run via service. For some reason Windows Defender doesn't like ILRepack that is being used, hence I had to remove the service from default zip. See: https://github.com/JustArchi/ArchiSteamFarm/issues/127#issuecomment-234313478 @sud_crow Starting with ASF 2.1.3.0 there will be special --path argument supported by ASF that will tell it where to look for config directory. This will allow package maintainer (Gilrain) to use it by executing ASF.exe with --path=/home/current_user/.asf, --path=$HOME/.asf (if $HOME is supported) or similar. That part is up to package maintainer though and how he wants to use ASF in AUR, I can only implement extra features to make it easier for you.

Also there is an issue with the permissions. Unless I'm doing something wrong due to lack of documentation, it seems the config folder is in the /opt/asf folder, as this folder only has (write) permissions for the "asf" user and (read) for the "asf" group, when you run the asf command from your user, it will complain about not being able to write the "*.db" and "*.bin" (where * is the name of your created "profile.json") as well as the "ASF.db" file. I don't know if you can give asf the parameters to look/create this files in the ~/.asf/config of the user running asf. As a workaround, I added my user to asf group and gave the group write permissions over /opt/asf/config. If there is a way to specify where to store the json/db/bin for the bot profile, it would be a good idea to give this information in the post_install script.

The archive has been updated to exclude ASF-Service.exe retroactively, without warning, hence the hash change. This is not good…

ps. The problem with the original PKGBUILD was with the sha256 of the 2.1.2.5 release, the download: https://github.com/JustArchi/ArchiSteamFarm/releases/download/2.1.2.5/ASF.zip has this sha256sum: 560bee3a662214f9cbabd7bd7faaaac2a5b1ccc785d57711d5a4a662967d7aad

Sorry, flagged and sent comment with pre-release. Didn't notice before. The default PKGBUILD wasn't working for me, so I did a quick check, and upgraded to 2.1.2.9 without noticing it was a pre-release.

This package is only for stable releases. Please do not flag it as out of date whenever a pre-release is published. If you want access to the bleeding edge, unstable, beta releases: feel free to create your own package.

I believe, auto joining to steam group without user's permission (or notification, at the minimum) is not expected application's behaviour. So, I think, it is not bad to change defaults for the benefit of end-user.

Thank you for bringing those up. I will disable UpdateChannel since we have package managers for that and it's a close relative of AutoUpdates anyway. But I don't feel it's up to the packagers to make privacy choices for the end-users, so Statistics will remain as it is.