Package Details: asf 3.4.0.7-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: 13
Popularity: 1.189836
First Submitted: 2016-04-02 13:31
Last Updated: 2018-11-09 14:40

Latest Comments

1 2 3 4 Next › Last »

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).

JustArchi commented on 2018-05-11 02:00

I'm not entirely sure what Arch follows in this regard since I'm not using it personally, but it might make more sense to delete deleteOldFileOnStartup from NLog.config, if there is another service (e.g. systemd) in charge of logs rotation. This way users could get access to old logs as well, there is no need to let ASF handle that part.

It'd probably also be a good idea to think of how to handle multiple-ASFs logging scenario, since they probably all will use the same log file now, and this is unwanted in multiple-processes scenario. You could distinguish them e.g. with ${currentdir} layout renderer, since every ASF will have its own config directory - https://github.com/nlog/nlog/wiki/Layout-Renderers

Up to you :).

Gilrain commented on 2018-04-29 13:54

/var/lib/asf/config or ~/.config/asf when using the services or wherever you want with /usr/bin/asf and the appropriate arguments.

giovannicimolin commented on 2018-04-29 12:52

Where do I put the configuration files? I have no idea of how to make it work on arch :/

bennyhillthebes commented on 2018-03-23 10:19

It is working now. Thank you very much Gilrain. For those who have problems with 2FA (caused by an incompability between DotNet and Ncurses 6.1) Archi recommends using XTerm to launch ASF, since it is unaffected.

Velfess commented on 2018-02-26 21:35

Got same problem as sylveon and bennyhillthebes.