Package Details: opensnitch-git 1.0.1.r3.544ce11-1

Git Clone URL: (read-only, click to copy)
Package Base: opensnitch-git
Description: A GNU/Linux application firewall
Upstream URL:
Licenses: GPL3
Conflicts: opensnitch
Provides: opensnitch
Submitter: None
Maintainer: lsf (yochananmarqos)
Last Packager: yochananmarqos
Votes: 26
Popularity: 2.06
First Submitted: 2017-05-03 14:15
Last Updated: 2020-08-16 14:52

Latest Comments

1 2 3 4 5 6 ... Next › Last »

tywyqu commented on 2020-10-12 10:02

Can you please load required modules for opensnitchd?

nfnetlink, nfnetlink_queue and x_tables

monoid commented on 2020-08-17 08:06

@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

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 brings to light :)

vyachkonovalov commented on 2020-08-16 07:29

Installation page suggests using python3-slugify which is from

monoid commented on 2020-08-16 05:54


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

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

monoid commented on 2020-08-13 06:32

Is it possible to replace the python-unicode-slugify dependency with the version in community? According to the description "A Python slugify application that handles unicode" so I am assuming there will be no issues.

I have removed the AUR one and replaced it with the community version and opensnitch still seems to work.

tuqueque commented on 2020-07-28 00:40

@yochananmarqos oh, you're absolutely right!... I actually didn't know that keeping stuff like these in cache in could bring these type of problems. Good thing I'm learning today. Double thanks!

yochananmarqos commented on 2020-07-27 21:45

@tuqueque: You have an old cached version of the PKGBUILD from whatever AUR helper you're using. Remove the cache and try again or use makepkg.

tuqueque commented on 2020-07-27 16:20

Hello, I see that somebody reported a dependency problem and you said you fixed it, but today I tried to install OpenSnitch and I get this error:

==> Making package: opensnitch-git 1.0.0.rc5.r16.db22e83-1 (lun 27 jul 2020 12:04:43)
==> Checking runtime dependencies...
==> Missing dependencies:
  -> python-libconfigparser
==> Checking buildtime dependencies...
==> ERROR: Could not resolve all dependencies.
error making: opensnitch-git

I tried manually installing python-configparser-5.0.0-1, but still won't compile. (I'm using Manjaro)