[1/2] smack: new package.

SMACK stands for Simplified Mandatory Access Control Kernel. It is a Linux
Security Module which provides a Mandatory Access Control mechanism,
like SELinux, but aiming towards simplicity.

This package provides the tools to load/unload the policy from the
kernel as well as a library allowing applications to interact with
SMACK. The proper kernel options are also set.

Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
---
 linux/linux.mk          |  4 ++++
 package/Config.in       |  1 +
 package/smack/Config.in | 28 ++++++++++++++++++++++++++++
 package/smack/smack.mk  | 14 ++++++++++++++
 4 files changed, 47 insertions(+)
 create mode 100644 package/smack/Config.in
 create mode 100644 package/smack/smack.mk

Dear Eric Le Bihan,

On Sun, 20 Apr 2014 20:54:03 +0200, Eric Le Bihan wrote:

> diff --git a/package/smack/Config.in b/package/smack/Config.in
> new file mode 100644
> index 0000000..971b79a
> --- /dev/null
> +++ b/package/smack/Config.in
> @@ -0,0 +1,28 @@
> +config BR2_PACKAGE_SMACK
> +	bool "smack"

Dependency on !BR2_PREFER_STATIC_LIB was missing, due to <dlfcn.h>
usage. Remember to build test your packages with
http://autobuild.buildroot.org/toolchains/configs/free-electrons/bfin-linux-uclibc.config
(to test !MMU) and
http://autobuild.buildroot.org/toolchains/configs/free-electrons/bfin-uclinux.config
(to test !MMU and BR2_PREFER_STATIC_LIB).


> +SMACK_VERSION = 1.0.4
> +SMACK_SITE = $(call github,smack-team,smack,v$(SMACK_VERSION))
> +SMACK_LICENSE = LGPLv2.1+

License is actually LGPLv2.1, according to comment headers in the
source code.

> +SMACK_LICENSE_FILES = COPYING
> +SMACK_INSTALL_STAGING = YES
> +SMACK_AUTORECONF = YES

Dependency on host-pkgconf was missing, the configure.ac script uses
PKG_CHECK_MODULES.

Applied with those changes,

Thomas

Dear Eric Le Bihan,

On Mon, 21 Apr 2014 13:56:07 +0200, Eric Le Bihan wrote:

> Thanks for the polishing! Wouldn't it be useful to add a stanza in the
> docs/manual/contribute.txt about performing some compliancy tests using these
> two configurations before submitting new packages? Are there any other
> criteria that could fit compliancy tests/checklist?

While reviewing these packages, I was indeed thinking of writing a
"package addition check list" for the manual. But I'm wondering if this
wouldn't replicate quite a lot of informations already in the manual,
though it's true the idea of testing with some specific toolchain
configurations isn't written anywhere.

Thomas

Hi!

On Mon, Apr 21, 2014 at 12:19:01PM +0200, Thomas Petazzoni wrote:
> Dear Eric Le Bihan,
>
> On Sun, 20 Apr 2014 20:54:03 +0200, Eric Le Bihan wrote:
>
> > diff --git a/package/smack/Config.in b/package/smack/Config.in
> > new file mode 100644
> > index 0000000..971b79a
> > --- /dev/null
> > +++ b/package/smack/Config.in
> > @@ -0,0 +1,28 @@
> > +config BR2_PACKAGE_SMACK
> > +	bool "smack"
>
> Dependency on !BR2_PREFER_STATIC_LIB was missing, due to <dlfcn.h>
> usage. Remember to build test your packages with
> http://autobuild.buildroot.org/toolchains/configs/free-electrons/bfin-linux-uclibc.config
> (to test !MMU) and
> http://autobuild.buildroot.org/toolchains/configs/free-electrons/bfin-uclinux.config
> (to test !MMU and BR2_PREFER_STATIC_LIB).
Thanks for the polishing! Wouldn't it be useful to add a stanza in the
docs/manual/contribute.txt about performing some compliancy tests using these
two configurations before submitting new packages? Are there any other
criteria that could fit compliancy tests/checklist?

Best regards,
ELB

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> schreef:
>Dear Eric Le Bihan,
>
>On Mon, 21 Apr 2014 13:56:07 +0200, Eric Le Bihan wrote:
>
>> Thanks for the polishing! Wouldn't it be useful to add a stanza in the
>> docs/manual/contribute.txt about performing some compliancy tests using these
>> two configurations before submitting new packages? Are there any other
>> criteria that could fit compliancy tests/checklist?
>
>While reviewing these packages, I was indeed thinking of writing a
>"package addition check list" for the manual. But I'm wondering if this
>wouldn't replicate quite a lot of informations already in the manual,
>though it's true the idea of testing with some specific toolchain
>configurations isn't written anywhere.

I certainly think a checklist would be a good addition to the manual. The checklist would not contain details, but only references to other parts of the manual.

Adding a list of toolchain configurations to test packages with is also on my todo list but I haven't gotten around these improvements yet...

Best regards,
Thomas

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

Hi,

 >> While reviewing these packages, I was indeed thinking of writing a
 >> "package addition check list" for the manual. But I'm wondering if this
 >> wouldn't replicate quite a lot of informations already in the manual,
 >> though it's true the idea of testing with some specific toolchain
 >> configurations isn't written anywhere.

 > I certainly think a checklist would be a good addition to the
 > manual. The checklist would not contain details, but only references
 > to other parts of the manual.

 > Adding a list of toolchain configurations to test packages with is
 > also on my todo list but I haven't gotten around these improvements
 > yet...

Perhaps we need something like checkpatch.pl to test a package with the
various toolchain combinations?

Dear Peter Korsgaard,

On Thu, 24 Apr 2014 22:14:34 +0200, Peter Korsgaard wrote:

>  >> While reviewing these packages, I was indeed thinking of writing a
>  >> "package addition check list" for the manual. But I'm wondering if this
>  >> wouldn't replicate quite a lot of informations already in the manual,
>  >> though it's true the idea of testing with some specific toolchain
>  >> configurations isn't written anywhere.
> 
>  > I certainly think a checklist would be a good addition to the
>  > manual. The checklist would not contain details, but only references
>  > to other parts of the manual.
> 
>  > Adding a list of toolchain configurations to test packages with is
>  > also on my todo list but I haven't gotten around these improvements
>  > yet...
> 
> Perhaps we need something like checkpatch.pl to test a package with the
> various toolchain combinations?

That could work with the packages that don't have crazy dependencies.
But as soon as the package starts depending on OpenGL or things like
that, it would be more difficult I believe.

Thomas