Package Details: asf 4.0.1.0-1

Git Clone URL: https://aur.archlinux.org/asf.git (read-only)
Package Base: asf
Description: Steam cards farmer.
Upstream URL: https://github.com/JustArchiNET/ArchiSteamFarm
Licenses: Apache
Submitter: Gilrain
Maintainer: Gilrain
Last Packager: Gilrain
Votes: 14
Popularity: 0.257705
First Submitted: 2016-04-02 13:31
Last Updated: 2019-03-07 09:47

Latest Comments

1 2 3 4 Next › Last »

Lucki commented on 2019-02-19 16:11

Fixed with 4.0.0.8.

Gilrain commented on 2019-02-10 17:00

Great, another hard-coded path…

Lucki commented on 2019-02-10 13:43

Only place it gets picked up is in /usr/lib/asf/plugins.

Gilrain commented on 2019-02-09 21:54

I would guess the plugin folder needs to be in /var/lib/asf/config/plugins, but I haven't tested that functionality yet.

Lucki commented on 2019-02-09 19:55

Where am I supposed to place the new plugins? There's the folder in /usr/lib/asf/plugins but the service file sets /var/lib/asf as the operating path. But I also noticed you've set a symlink for the config path.

I've tried to place the plugins folder right next to the current config folder in /var/lib/asf/plugins but the plugins don't get picked up by asf.

Gilrain commented on 2018-05-17 19:21

It's planned. The last time I tried compiling from source I had a never ending stream of errors and gave up after fixing a couple of them. Maybe now that dotnet is on its 7th iteration it will be different…

doskoi commented on 2018-05-17 19:11

Can you rename this package to asf-bin then? This would allow to have a package named asf built from source and using dotnet-runtime.

Gilrain commented on 2018-05-17 06:59

It's simple. So as not to install 420Mb worth of dependencies when your special builds only require ~6Mb. And also, it works now. There's no longer a weird error about Arch not being a proper GNU-Linux.

JustArchi commented on 2018-05-17 03:04

I'm wondering why you decided to go after OS-specific builds after all, is there a reason? When including ASF in package manager it'd be much better to include only as little as possible (generic variant) and share remaining dependencies with the rest of the OS. This is a good idea mainly because people might already utilize dotnet-runtime for other apps, and there is no direct need to bundle ASF together with the runtime, unless wanted by the end-user.

Of course it's your decision as a package maintainer and both variants will work good enough, but I think bundling generic package and putting a dependency on dotnet-runtime would be better after all, as ASF doesn't require any specific runtime build dedicated to it, only a runtime version that is recent enough (right now 2.0+, quite soon 2.1+).

Up to you of course.

Gilrain commented on 2018-05-12 08:07

Thank you for the advice.

As you said, it would be best to assume a systemd environment and forgo the use of a log file. That way, novice users (or as novice as a AUR user ought to be) can run ASF as a service while advanced users can read the thorough documentations to cater to their own needs (I'll make sure custom NLog.config files aren't overwritten by the package).