Package Details: apparmor-vim 2.11.1-1

Git Clone URL: (read-only)
Package Base: apparmor
Description: AppArmor VIM support
Upstream URL:
Keywords: hardening linux LSM MAC security
Licenses: GPL
Submitter: Harvie
Maintainer: edh
Last Packager: edh
Votes: 98
Popularity: 1.977898
First Submitted: 2010-10-28 14:55
Last Updated: 2017-10-26 18:08

Latest Comments

edh commented on 2017-10-26 18:10

I am very sorry that it took me some time to bump the version. I forgot to create one of my usual alerts which would have notified me of a new release :|

michaelkempff commented on 2017-10-18 09:23

It's very clear now, thanks a lot!

edh commented on 2017-10-17 20:54

No problem.

This is quite a common misconception, which is really easy to get to since you install the package using pacman. However the download, build and packaging is done as a normal user (root is not supported in order to strengthen security). Hence the key has to be present in the user's keyring.
I hope this clarifies the cause of the error message and helped you to understand the underlying problem.

Kind Regards

michaelkempff commented on 2017-10-17 19:15

Thanks Edh,

Sorry i added the key to my pacman keyring :p

edh commented on 2017-10-17 14:20

This is the expected behaviour. Please do a little bit more research [1] prior to using the AUR and especially before posting comments!
The error is about not being able to verify the author of the signature of the downloaded file. In accordance with the web of trust it therefore aborts building the package. In order to 'fix' this error you have to import the key into your gpg-keyring, see the link [1] for more details.


michaelkempff commented on 2017-10-16 21:33

Hi Edh,

I'm getting the following error when trying to install the apparmor metapackage:

==> Verifying source file signatures with gpg...
apparmor-2.11.0.tar.gz ... FAILED (unknown public key 6689E64E3D3664BB)
==> ERROR: One or more PGP signatures could not be verified!

Any ideas?
Thanks in advance!

edh commented on 2017-10-02 14:58

The distribution of the dependencies into the different arrays is intentional. Package specific dependencies (those e.g. defined by apparmor-profiles) behave differently than than their pkgbase counterpart. The latter one is always present when building while the first one not necessarily.

Concerning your '/usr/lib/perl5/vendor_perl' and perl-rpc-xml problem: The command you specified would yield nothing since the path has been deprecated in favor of '/usr/lib/perl5/PERL_VENDORARCH/vendor_perl'.

IrvineHimself commented on 2017-09-30 15:05

Glad to see a new maintainer volunteering and outstanding issues being fixed so quickly.

With regard to "apparmor-utils": Noting that perl itself is a "make dependency", should this also be the case for "perl-rpc-xml". In particular, should I be concerned that running "pacman -Qqo '/usr/lib/perl5/vendor_perl'" lists "perl-rpc-xml" as not being used by the updated perl interpreter.

Best wishes

Just noticed that is listed twice in the dependency tree, once as a "make depends" and once as a "depends"??

edh commented on 2017-09-30 14:01

Done. Thanks for the reminder.

egrupled commented on 2017-09-30 13:19

@edh Can you add patch which I mentioned before? Unless I'm missing something it affects everyone who actually use those tools.

some apparmor utils are currently broken with python 3.6, see

I recommend adding patch which fixes issue:

All comments