Arch Linux User Repository

At that point it should pretty much just pull go dependencies, which always seems to hang for a moment without any output at that point, depending on your internet connection speed. Maybe changing dep ensure to dep ensure -v might get you more output on where it's stuck?

I just did a clean build of it and its AUR-dependencies in a clean chroot and everything seemed to build properly.

If you're using an AUR helper, you might want to give it a try without one or with another one (yay should work)?

Hi, I have a problem trying to install opensnitch-git... When it reaches the "Starting prepare()" message in the build process, it stays there forever and nothing happens. I know pretty much nothing about building from sources, but I know is not doing anything. No CPU usage, nothing:

==> Extracting sources...
  -> Creating working copy of opensnitch git repo...
Cloning into 'opensnitch'...
done.
==> Starting prepare()...

Hi, still having issues with daemon start : write /sys/kernel/debug/tracing/kprobe_events: no such file or directory

For those having a working opensnitch : which kernel do you use ?

@lsf: Please see VCS, Go and Python package guidelines.

Proper working PKGBUILD.

Hi,my daemon doesn't start. In daemons logs I get this weird error.

[2019-08-08 11:51:14] !!! Error while enabling probe descriptor for opensnitch_exec_probe: write /sys/kernel/debug/tracing/kprobe_events: no such file or directory

Some issues in upstream projects seem to state I'm not alone ... did anyone face this ? I'm running 4.19 LTS kernel. In /proc/config.gz I can see : CONFIG_KPROBE_EVENTS=y

debugfs is correctly mounted, files do exist. (-rw-r--r-- 1 root root 0 8 août 13:51 /sys/kernel/debug/tracing/kprobe_events)

That shouldn't be necessary. python-unicode-slugify-git uses provides=(python-unicode-slugify). Your AUR helper should understand this (yay does).

python-unicode-slugify is unavailable, it should be replaced with python-unicode-slugify-git in the pkgbuild

No. Or rather: only under very specific circumstances. I don't know how much you know about gnupg/pgp, so I'll just keep it short: What you did is import a key of some person who signs packages with it. Now you can additionally verify the integrity of packages/files signed with this key (in addition to the basic checksums). In some cases, the keys used are provided by the maintainer of the software that is packaged, in other cases it's by the person packaging it for the AUR, providing different amounts of extra "trust". This would only be an issue if you'd now blindly trust everything signed with this key, installed AUR packages without inspecting them and the key owner intentionally created a "bad" package (or someone got hold of his key and created one). So basically: no, everything's fine, as long as you follow basic "AUR hygiene", as stated in: https://wiki.archlinux.org/index.php/Arch_User_Repository#Build_and_install_the_package => "Warning: Carefully check the PKGBUILD, any .install files, and any other files in the package's git repository for malicious or dangerous commands. If in doubt, do not build the package, and seek advice on the forums or mailing list. Malicious code has been found in packages before."

@lsf Thank's a lot! By the way, could this compromise the security of the system somehow?

You need to import the public key in your personal gpg keyring (there are ways around cluttering your regular keyring, but let's just stick with using it for simplicity). See: https://wiki.archlinux.org/index.php/Makepkg#ERROR:_One_or_more_PGP_signatures_could_not_be_verified!

It boils down to gpg --recv-keys 8C004C2F93481F6B, but optimally you would also verify the fingerprint of the key as provided "upstream", to ensure it's the actual and correct key you've imported via the aforementioned command.