Package Details: asf

Git Clone URL: (read-only, click to copy)
Package Base: asf
Description: Steam cards farmer.
Upstream URL:
Licenses: Apache
Submitter: Gilrain
Maintainer: Gilrain
Last Packager: Gilrain
Votes: 15
Popularity: 0.007993
First Submitted: 2016-04-02 13:31
Last Updated: 2020-01-16 08:59

Dependencies (6)

Required by (1)

Sources (6)

Pinned Comments

Gilrain commented on 2020-01-15 15:42

Compiling asf (or anything really) using community dotnet is broken right now (

Gilrain commented on 2019-12-16 10:50

This package is now compiling the source code.

For now, you'll see these namcap warnings: W: ELF file ('usr/lib/asf/ArchiSteamFarm') lacks FULL RELRO, check LDFLAGS. W: ELF file ('usr/lib/asf/ArchiSteamFarm') lacks PIE.

I'll investigate further when community is updated to v3.x, since the benefits of those options would be lost while using dotnet AUR binaries.

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

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

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 -

Up to you :).