Package Details: asf-plugin-itemsmatcher 6.0.8.7-1

Git Clone URL: https://aur.archlinux.org/asf.git (read-only, click to copy)
Package Base: asf
Description: ItemsMatcher plugin for ArchiSteamFarm.
Upstream URL: https://github.com/JustArchiNET/ArchiSteamFarm
Licenses: Apache-2.0
Submitter: Gilrain
Maintainer: Gilrain
Last Packager: Gilrain
Votes: 24
Popularity: 0.76
First Submitted: 2016-04-02 13:31 (UTC)
Last Updated: 2024-11-01 09:59 (UTC)

Pinned Comments

Gilrain commented on 2022-11-03 08:45 (UTC)

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

Gilrain commented on 2021-10-02 14:02 (UTC)

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.

Latest Comments

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

Gilrain commented on 2019-02-10 17:00 (UTC)

Great, another hard-coded path…

Lucki commented on 2019-02-10 13:43 (UTC)

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

Gilrain commented on 2019-02-09 21:54 (UTC) (edited on 2019-02-09 21:55 (UTC) by Gilrain)

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 (UTC)

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 (UTC)

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…

abouvier commented on 2018-05-17 19:11 (UTC)

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 (UTC)

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 (UTC) (edited on 2018-05-17 03:04 (UTC) by JustArchi)

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 (UTC)

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 (UTC)

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

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