Package Details: opensnitch-git 1.6.0rc5.r84.e1afd24-2

Git Clone URL: https://aur.archlinux.org/opensnitch-git.git (read-only, click to copy)
Package Base: opensnitch-git
Description: A GNU/Linux port of the Little Snitch application firewall
Upstream URL: https://github.com/evilsocket/opensnitch
Licenses: GPL3
Conflicts: opensnitch
Provides: opensnitch
Submitter: None
Maintainer: lsf
Last Packager: lsf
Votes: 40
Popularity: 0.002248
First Submitted: 2017-05-03 14:15 (UTC)
Last Updated: 2023-06-11 11:45 (UTC)

Latest Comments

« First ‹ Previous 1 .. 4 5 6 7 8 9 10 11 12 13 14 .. 18 Next › Last »

Zame commented on 2020-11-16 09:30 (UTC) (edited on 2020-11-16 09:33 (UTC) by Zame)

Gui doesn't work with last update: Status not running.

In terminal: ● opensnitchd.service - OpenSnitch is a GNU/Linux port of the Little Snitch application firewall. Loaded: loaded (/usr/lib/systemd/system/opensnitchd.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2020-11-16 13:03:59 +04; 22min ago Docs: https://github.com/gustavo-iniguez-goya/opensnitch/wiki Main PID: 673 (opensnitchd) Tasks: 17 (limit: 9414) Memory: 52.6M CGroup: /system.slice/opensnitchd.service └─673 /usr/bin/opensnitchd -rules-path /etc/opensnitchd/rules

system-fw.json from https://github.com/gustavo-iniguez-goya/opensnitch/blob/main/daemon/system-fw.json exists

OS: Manjaro Linux x86_64 Kernel: 5.9.3-1-MANJARO Plasma 5.20.2

yochananmarqos commented on 2020-11-14 19:24 (UTC)

@xtc0r: Thanks, done.

xtc0r commented on 2020-11-14 18:30 (UTC)

@Package Maintainer:

I got an error: Opensnitch.d fails with code=exited, status=2 using the latest opensnitch package

Ticket to issue here: https://github.com/gustavo-iniguez-goya/opensnitch/issues/88

root cause: AUR package did not distribute the file system-fw.json

Solution: Add https://github.com/gustavo-iniguez-goya/opensnitch/blob/main/daemon/system-fw.json to package and place it to /etc/opensnitchd/system-fw.json

tywyqu commented on 2020-10-12 10:02 (UTC)

Can you please load required modules for opensnitchd?

nfnetlink, nfnetlink_queue and x_tables

lambdaclan commented on 2020-08-17 08:06 (UTC)

@vyachkonovalov @lsf

Yeap, I also noticed that the installation page and the requirements.txt list different packages. Anyways, glad to see the issue has been resolved and with the blessings of the upstream developer.

Thank you both for the help.

lsf commented on 2020-08-16 08:32 (UTC)

That's interesting – way back then, when I took over the package here, I went by what the requirements.txt suggested.

This strongly points to python-slugify being fine, but we can probably wait and see what https://github.com/gustavo-iniguez-goya/opensnitch/issues/55 brings to light :)

crabvk commented on 2020-08-16 07:29 (UTC) (edited on 2020-08-16 07:38 (UTC) by crabvk)

Installation page suggests using python3-slugify which is from https://github.com/un33k/python-slugify.

lambdaclan commented on 2020-08-16 05:54 (UTC)

@lsf

Thank you for the reply. Yes indeed, that makes perfect sense. I will go ahead and raise an issue with the upstream developers but I am not confident that they will be willing to change the library.

I just realized that python-slugify and unicode_slugify are two different libraries that happen to use the same name for their module as you mention. I originally thought that it was the same library with added unicode support. Python packaging will never cease to amaze me.

After a quick look at the libraries they do seem to be working in a similar fashion but not sure if the developers will change a perfectly working setup.

The reason I requested the change in the first place is because any package that requires python-slugify will fail to install due to a conflict.

I will reach out to upstream but is there a way to maybe set the dependency to either python-slugify or python-unicode-slugify?

lsf commented on 2020-08-13 07:38 (UTC)

Should be possible (the way the module is called from the code is always just with a string as an argument and no other options, and the module is called slugify with both packages, so it seems to not matter very much), although I'd probably first raise this as an issue / question on https://github.com/gustavo-iniguez-goya/opensnitch/issues – might make sense to have someone with more python knowledge look into this and/or see if an "upstream" switch to the other package would make sense.

It's a bit of an annoying situation caused (probably) by the identical naming of the python module by different packages.