[Buildroot] [PATCH 1/4] libcap: bump version

[Buildroot] [PATCH 1/4] libcap: bump version

[Thomas Petazzoni]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

attr is no longer a dependency, not even optional.

Refresh our patches, and drop the backport from upstream.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 ...-build-system-fixes-for-cross-compilation.patch | 26 ++++--------
 ...t-install-into-install-shared-install-sta.patch | 32 +++++++--------
 ...nge-the-location-we-include-linux-xattr.h.patch | 46 ----------------------
 package/libcap/libcap.hash                         |  2 +-
 package/libcap/libcap.mk                           | 18 +++------
 5 files changed, 29 insertions(+), 95 deletions(-)
 delete mode 100644 package/libcap/0003-Change-the-location-we-include-linux-xattr.h.patch

diff --git a/package/libcap/0001-build-system-fixes-for-cross-compilation.patch b/package/libcap/0001-build-system-fixes-for-cross-compilation.patch
index 705bbc7..de24090 100644
--- a/package/libcap/0001-build-system-fixes-for-cross-compilation.patch
+++ b/package/libcap/0001-build-system-fixes-for-cross-compilation.patch
@@ -1,19 +1,19 @@
-From 7f48413ef1688df0d7fc25e477f4e6c0c55edfac Mon Sep 17 00:00:00 2001
+From d8d70559a279706c206761dfaf665d2197934123 Mon Sep 17 00:00:00 2001
 From: Gustavo Zacarias <gustavo@zacarias.com.ar>
 Date: Sun, 6 Mar 2016 22:52:02 +0100
 Subject: [PATCH] build-system: fixes for cross-compilation
 
 Avoid the libcap buildsys forcing CC/CFLAGS/LDFLAGS/AR/RANLIB
-Also install the shared lib +x
 
 Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
+[yann.morin.1998 at free.fr: dont chmod +x the shared lib]
 Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
 
 diff --git a/Make.Rules b/Make.Rules
-index ec1c474..8a8fc50 100644
+index 8347b26..8a07a3f 100644
 --- a/Make.Rules
 +++ b/Make.Rules
-@@ -48,25 +48,25 @@ MINOR=24
+@@ -48,26 +48,26 @@ MINOR=25
  KERNEL_HEADERS := $(topdir)/libcap/include/uapi
  IPATH += -fPIC -I$(KERNEL_HEADERS) -I$(topdir)/libcap/include
  
@@ -37,6 +37,7 @@ index ec1c474..8a8fc50 100644
  LD=$(CC) -Wl,-x -shared
 -LDFLAGS := #-g
 +LDFLAGS ?= #-g
+ BUILD_GPERF := $(shell which gperf >/dev/null 2>/dev/null && echo yes)
  
  SYSTEM_HEADERS = /usr/include
  INCS=$(topdir)/libcap/include/sys/capability.h
@@ -44,22 +45,9 @@ index ec1c474..8a8fc50 100644
  CFLAGS += -Dlinux $(WARNINGS) $(DEBUG)
 -PAM_CAP := $(shell if [ -f /usr/include/security/pam_modules.h ]; then echo yes ; else echo no ; fi)
 +PAM_CAP = no
- INDENT := $(shell if [ -n "$(which indent 2>/dev/null)" ]; then echo "| indent -kr" ; fi)
+ INDENT := $(shell if [ -n "$$(which indent 2>/dev/null)" ]; then echo "| indent -kr" ; fi)
  DYNAMIC := $(shell if [ ! -d "$(topdir)/.git" ]; then echo yes; fi)
- LIBATTR := yes
-diff --git a/libcap/Makefile b/libcap/Makefile
-index 20ab00f..97fea3f 100644
---- a/libcap/Makefile
-+++ b/libcap/Makefile
-@@ -75,7 +75,7 @@ install: all
- 	install -m 0644 include/sys/capability.h $(INCDIR)/sys
- 	mkdir -p -m 0755 $(LIBDIR)
- 	install -m 0644 $(STALIBNAME) $(LIBDIR)/$(STALIBNAME)
--	install -m 0644 $(MINLIBNAME) $(LIBDIR)/$(MINLIBNAME)
-+	install -m 0755 $(MINLIBNAME) $(LIBDIR)/$(MINLIBNAME)
- 	ln -sf $(MINLIBNAME) $(LIBDIR)/$(MAJLIBNAME)
- 	ln -sf $(MAJLIBNAME) $(LIBDIR)/$(LIBNAME)
- ifeq ($(FAKEROOT),)
+ 
 -- 
 1.9.1
 
diff --git a/package/libcap/0002-libcap-split-install-into-install-shared-install-sta.patch b/package/libcap/0002-libcap-split-install-into-install-shared-install-sta.patch
index a7a9d13..a8579b7 100644
--- a/package/libcap/0002-libcap-split-install-into-install-shared-install-sta.patch
+++ b/package/libcap/0002-libcap-split-install-into-install-shared-install-sta.patch
@@ -1,4 +1,4 @@
-From 8d7339169b9a5df2082731fe5468923be4be39af Mon Sep 17 00:00:00 2001
+From af21635665ab568f3333ff9fe8b474f4950e5acb Mon Sep 17 00:00:00 2001
 From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
 Date: Sun, 6 Mar 2016 22:53:24 +0100
 Subject: [PATCH] libcap: split install into install-shared/install-static
@@ -11,10 +11,10 @@ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
 Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
 
 diff --git a/libcap/Makefile b/libcap/Makefile
-index 97fea3f..7ac45dd 100644
+index d189777..44ddb27 100644
 --- a/libcap/Makefile
 +++ b/libcap/Makefile
-@@ -70,19 +70,25 @@ $(MINLIBNAME): $(OBJS)
+@@ -62,19 +62,25 @@ $(MINLIBNAME): $(OBJS)
  cap_text.o: cap_text.c $(USE_GPERF_OUTPUT) $(INCLS)
  	$(CC) $(CFLAGS) $(IPATH) $(INCLUDE_GPERF_OUTPUT) -c $< -o $@
  
@@ -22,24 +22,24 @@ index 97fea3f..7ac45dd 100644
 +install: install-shared install-static
 +
 +install-common:
- 	mkdir -p -m 0755 $(INCDIR)/sys
- 	install -m 0644 include/sys/capability.h $(INCDIR)/sys
-+	mkdir -p -m 0755 $(PKGCONFIGDIR)
-+	install -m 0644 libcap.pc $(PKGCONFIGDIR)/libcap.pc
- 	mkdir -p -m 0755 $(LIBDIR)
+ 	mkdir -p -m 0755 $(FAKEROOT)$(INCDIR)/sys
+ 	install -m 0644 include/sys/capability.h $(FAKEROOT)$(INCDIR)/sys
++	mkdir -p -m 0755 $(FAKEROOT)$(PKGCONFIGDIR)
++	install -m 0644 libcap.pc $(FAKEROOT)$(PKGCONFIGDIR)/libcap.pc
 +
-+install-static: install-common
- 	install -m 0644 $(STALIBNAME) $(LIBDIR)/$(STALIBNAME)
++install-static: $(STALIBNAME) install-common
+ 	mkdir -p -m 0755 $(FAKEROOT)$(LIBDIR)
+ 	install -m 0644 $(STALIBNAME) $(FAKEROOT)$(LIBDIR)/$(STALIBNAME)
 +
-+install-shared: install-common
- 	install -m 0755 $(MINLIBNAME) $(LIBDIR)/$(MINLIBNAME)
- 	ln -sf $(MINLIBNAME) $(LIBDIR)/$(MAJLIBNAME)
- 	ln -sf $(MAJLIBNAME) $(LIBDIR)/$(LIBNAME)
++install-shared: $(MINLIBNAME) install-common
+ 	install -m 0644 $(MINLIBNAME) $(FAKEROOT)$(LIBDIR)/$(MINLIBNAME)
+ 	ln -sf $(MINLIBNAME) $(FAKEROOT)$(LIBDIR)/$(MAJLIBNAME)
+ 	ln -sf $(MAJLIBNAME) $(FAKEROOT)$(LIBDIR)/$(LIBNAME)
  ifeq ($(FAKEROOT),)
  	-/sbin/ldconfig
  endif
--	mkdir -p -m 0755 $(PKGCONFIGDIR)
--	install -m 0644 libcap.pc $(PKGCONFIGDIR)/libcap.pc
+-	mkdir -p -m 0755 $(FAKEROOT)$(PKGCONFIGDIR)
+-	install -m 0644 libcap.pc $(FAKEROOT)$(PKGCONFIGDIR)/libcap.pc
  
  clean:
  	$(LOCALCLEAN)
diff --git a/package/libcap/0003-Change-the-location-we-include-linux-xattr.h.patch b/package/libcap/0003-Change-the-location-we-include-linux-xattr.h.patch
deleted file mode 100644
index 7858780..0000000
--- a/package/libcap/0003-Change-the-location-we-include-linux-xattr.h.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 84fb6007dcc7f6b6da9f6dab77a487c22b6c7beb Mon Sep 17 00:00:00 2001
-From: Andrew G Morgan <morgan@kernel.org>
-Date: Sun, 9 Mar 2014 16:33:15 -0700
-Subject: [PATCH] Change the location we include linux/xattr.h
-
-This header stuff seems a bit fragile, but Serge reports including
-it in sys/capability.h was causing a lot of trouble building dependent
-app packages.
-
-From the perspective of libcap, this API is only needed internally in
-cap_file.c so we put an include there.
-
-Status: upstream.
-
-Signed-off-by: Andrew G Morgan <morgan@kernel.org>
-Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
----
-
-diff --git a/libcap/cap_file.c b/libcap/cap_file.c
-index d3dc1d0..553c2d2 100644
---- a/libcap/cap_file.c
-+++ b/libcap/cap_file.c
-@@ -10,6 +10,8 @@
- #include <sys/stat.h>
- #include <unistd.h>
- 
-+#include <linux/xattr.h>
-+
- #define XATTR_SECURITY_PREFIX "security."
- 
- #include "libcap.h"
-diff --git a/libcap/include/sys/capability.h b/libcap/include/sys/capability.h
-index 64ac50e..dddc75b 100644
---- a/libcap/include/sys/capability.h
-+++ b/libcap/include/sys/capability.h
-@@ -27,7 +27,6 @@ extern "C" {
- #define __user
- #endif
- #include <linux/capability.h>
--#include <linux/xattr.h>
- 
- /*
-  * POSIX capability types
--- 
-2.0.4
-
diff --git a/package/libcap/libcap.hash b/package/libcap/libcap.hash
index 75822e5..a1dcd62 100644
--- a/package/libcap/libcap.hash
+++ b/package/libcap/libcap.hash
@@ -1,2 +1,2 @@
 # https://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/sha256sums.asc
-sha256	cee4568f78dc851d726fc93f25f4ed91cc223b1fe8259daa4a77158d174e6c65	libcap-2.24.tar.xz
+sha256	693c8ac51e983ee678205571ef272439d83afe62dd8e424ea14ad9790bc35162  libcap-2.25.tar.xz
diff --git a/package/libcap/libcap.mk b/package/libcap/libcap.mk
index 8625139..bcb5d8c 100644
--- a/package/libcap/libcap.mk
+++ b/package/libcap/libcap.mk
@@ -4,23 +4,16 @@
 #
 ################################################################################
 
-LIBCAP_VERSION = 2.24
+LIBCAP_VERSION = 2.25
 LIBCAP_SITE = https://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2
 LIBCAP_SOURCE = libcap-$(LIBCAP_VERSION).tar.xz
 LIBCAP_LICENSE = GPLv2 or BSD-3c
 LIBCAP_LICENSE_FILES = License
 
-LIBCAP_DEPENDENCIES = host-libcap
+LIBCAP_DEPENDENCIES = host-libcap host-gperf
 LIBCAP_INSTALL_STAGING = YES
 
-ifeq ($(BR2_PACKAGE_ATTR),y)
-LIBCAP_DEPENDENCIES += attr
-LIBCAP_HAVE_LIBATTR = yes
-else
-LIBCAP_HAVE_LIBATTR = no
-endif
-
-HOST_LIBCAP_DEPENDENCIES = host-attr
+HOST_LIBCAP_DEPENDENCIES = host-gperf
 
 ifeq ($(BR2_STATIC_LIBS),y)
 LIBCAP_MAKE_TARGET = libcap.a libcap.pc
@@ -31,7 +24,6 @@ LIBCAP_MAKE_INSTALL_TARGET = install
 endif
 
 LIBCAP_MAKE_FLAGS = \
-	LIBATTR=$(LIBCAP_HAVE_LIBATTR) \
 	BUILD_CC="$(HOSTCC)" \
 	BUILD_CFLAGS="$(HOST_CFLAGS)"
 
@@ -67,12 +59,12 @@ endef
 
 define HOST_LIBCAP_BUILD_CMDS
 	$(HOST_MAKE_ENV) $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D)\
-		LIBATTR=yes RAISE_SETFCAP=no
+		RAISE_SETFCAP=no
 endef
 
 define HOST_LIBCAP_INSTALL_CMDS
 	$(HOST_MAKE_ENV) $(MAKE) -C $(@D) DESTDIR=$(HOST_DIR) \
-		LIBATTR=yes RAISE_SETFCAP=no prefix=/usr lib=lib install
+		RAISE_SETFCAP=no prefix=/usr lib=lib install
 endef
 
 $(eval $(generic-package))
-- 
2.6.4

[Buildroot] [PATCH 2/4] libcap: add patch to fix build issue with old kernel headers

[Thomas Petazzoni]

Old kernels (before 2.6.36) were defining XATTR_NAME_CAPS in
<linux/capability.h>, but using XATTR_SECURITY_PREFIX and
XATTR_CAPS_SUFFIX which were defined in the kernel-only part of
<linux/xattr.h>.

In kernel 2.6.36 (commit af4f136056c984b0aa67feed7d3170b958370b2f),
the XATTR_NAME_CAPS definition was moved to the kernel-only part of
<linux/xattr.h>. It's only in kernel 3.0 (commit
1dbe39424a43e56a6c9aed12661192af51dcdb9f) that <linux/xattr.h> was
fixed to expose XATTR_NAME_CAPS and the related definitions to
userspace.

This is the reason why the target variant of libcap has a dependency
on headers >= 3.0 for the moment.

However, this doesn't solve the problem for the host variant of
libcap, which doesn't build properly on old systems.

To solve this, we simply add a patch that defines the missing
definitions. Their values haven't changed over time since they are
part of the kernel to userspace ABI.

Fixes:

  http://autobuild.buildroot.org/results/856b71bccf14c3334a8c0fc66c1d985b09734313/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 ..._file.c-fix-build-with-old-kernel-headers.patch | 51 ++++++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 package/libcap/0003-libcap-cap_file.c-fix-build-with-old-kernel-headers.patch

diff --git a/package/libcap/0003-libcap-cap_file.c-fix-build-with-old-kernel-headers.patch b/package/libcap/0003-libcap-cap_file.c-fix-build-with-old-kernel-headers.patch
new file mode 100644
index 0000000..02cc228
--- /dev/null
+++ b/package/libcap/0003-libcap-cap_file.c-fix-build-with-old-kernel-headers.patch
@@ -0,0 +1,51 @@
+From ace694e9574eb38e07cfe0db235434eb40003f47 Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Mon, 14 Mar 2016 22:39:15 +0100
+Subject: [PATCH] libcap/cap_file.c: fix build with old kernel headers
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+---
+ libcap/cap_file.c | 27 +++++++++++++++++++++++++++
+ 1 file changed, 27 insertions(+)
+
+diff --git a/libcap/cap_file.c b/libcap/cap_file.c
+index 40756ea..e3d54dd 100644
+--- a/libcap/cap_file.c
++++ b/libcap/cap_file.c
+@@ -23,6 +23,33 @@ extern int fsetxattr(int, const char *, const void *, size_t, int);
+ extern int removexattr(const char *, const char *);
+ extern int fremovexattr(int, const char *);
+ 
++
++/*
++ * Old kernels (before 2.6.36) were defining XATTR_NAME_CAPS in
++ * <linux/capability.h>, but using XATTR_SECURITY_PREFIX and
++ * XATTR_CAPS_SUFFIX which were defined in the kernel-only part of
++ * <linux/xattr.h>.
++ *
++ * In kernel 2.6.36 (commit af4f136056c984b0aa67feed7d3170b958370b2f),
++ * the XATTR_NAME_CAPS definition was moved to the kernel-only part of
++ * <linux/xattr.h>. It's only in kernel 3.0 (commit
++ * 1dbe39424a43e56a6c9aed12661192af51dcdb9f) that <linux/xattr.h> was
++ * fixed to expose XATTR_NAME_CAPS and the related definitions to
++ * userspace.
++ *
++ * In order to cope with kernels < 3.0, we define here the appropriate
++ * values, which we assume haven't changed over history.
++ */
++#ifndef XATTR_CAPS_SUFFIX
++#define XATTR_CAPS_SUFFIX "capability"
++#endif
++#ifndef XATTR_SECURITY_PREFIX
++#define XATTR_SECURITY_PREFIX "security."
++#endif
++#ifndef XATTR_NAME_CAPS
++#define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
++#endif
++
+ #include "libcap.h"
+ 
+ #ifdef VFS_CAP_U32
+-- 
+2.6.4
+
-- 
2.6.4

[Buildroot] [PATCH 2/4] libcap: add patch to fix build issue with old kernel headers

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Old kernels (before 2.6.36) were defining XATTR_NAME_CAPS in
 > <linux/capability.h>, but using XATTR_SECURITY_PREFIX and
 > XATTR_CAPS_SUFFIX which were defined in the kernel-only part of
 > <linux/xattr.h>.

gcc10 (which uses 2.6.32 headers) has XATTR_CAPS_SUFFIX in
linux/capability.h:

#define XATTR_CAPS_SUFFIX "capability"
#define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX

So this doesn't seem 100% correct, but the fix looks fine to me - So
committed, thanks!

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2/4] libcap: add patch to fix build issue with old kernel headers

[Thomas Petazzoni]

Peter,

On Wed, 16 Mar 2016 23:16:31 +0100, Peter Korsgaard wrote:

>  > Old kernels (before 2.6.36) were defining XATTR_NAME_CAPS in
>  > <linux/capability.h>, but using XATTR_SECURITY_PREFIX and
>  > XATTR_CAPS_SUFFIX which were defined in the kernel-only part of
>  > <linux/xattr.h>.
> 
> gcc10 (which uses 2.6.32 headers) has XATTR_CAPS_SUFFIX in
> linux/capability.h:
> 
> #define XATTR_CAPS_SUFFIX "capability"
> #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX

My commit log is talking about XATTR_SECURITY_PREFIX, not
XATTR_CAPS_SUFFIX.

Do you have XATTR_SECURITY_PREFIX defined ?

I do have XATTR_CAPS_SUFFIX like you, but not XATTR_SECURITY_PREFIX.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2/4] libcap: add patch to fix build issue with old kernel headers

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Peter,
 > On Wed, 16 Mar 2016 23:16:31 +0100, Peter Korsgaard wrote:

 >> > Old kernels (before 2.6.36) were defining XATTR_NAME_CAPS in
 >> > <linux/capability.h>, but using XATTR_SECURITY_PREFIX and
 >> > XATTR_CAPS_SUFFIX which were defined in the kernel-only part of
 >> > <linux/xattr.h>.
 >> 
 >> gcc10 (which uses 2.6.32 headers) has XATTR_CAPS_SUFFIX in
 >> linux/capability.h:
 >> 
 >> #define XATTR_CAPS_SUFFIX "capability"
 >> #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX

 > My commit log is talking about XATTR_SECURITY_PREFIX, not
 > XATTR_CAPS_SUFFIX.

Well, you wrote ".. but using XATTR_SECURITY_PREFIX and
XATTR_CAPS_SUFFIX which were defined in the kernel-only part of
<linux/xattr.h>"


 > Do you have XATTR_SECURITY_PREFIX defined ?

No, indeed not.

 > I do have XATTR_CAPS_SUFFIX like you, but not XATTR_SECURITY_PREFIX.

Ok.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH 2/4] libcap: add patch to fix build issue with old kernel headers

[Thomas Petazzoni]

Hello,

On Wed, 16 Mar 2016 23:44:19 +0100, Peter Korsgaard wrote:

>  > My commit log is talking about XATTR_SECURITY_PREFIX, not
>  > XATTR_CAPS_SUFFIX.
> 
> Well, you wrote ".. but using XATTR_SECURITY_PREFIX and
> XATTR_CAPS_SUFFIX which were defined in the kernel-only part of
> <linux/xattr.h>"

Gaah, bad commit log :-/ Sorry about that.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 3/4] libcap, cdrkit, dvdrw-tools, fastd, squid: remove headers >= 3.0 dependency

[Thomas Petazzoni]

Now that the libcap package has a patch that makes it build with
kernel headers < 3.0 (which was needed for the host variant of
libcap), there is no longer a need to have a dependency on headers >=
3.0 for the target variant of libcap.

All reverse dependencies of libcap are handled in this commit, except
lxc, which will be handled in a separate commit since it needs some
special solution.

The build of all those packages has been tested with a toolchain that
uses kernel headers 2.6.32, which is the oldest that our default glibc
version accepts to use.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/cdrkit/Config.in      | 5 -----
 package/dvdrw-tools/Config.in | 4 ----
 package/fastd/Config.in       | 4 +---
 package/libcap/Config.in      | 4 ----
 package/squid/Config.in       | 5 ++---
 5 files changed, 3 insertions(+), 19 deletions(-)

diff --git a/package/cdrkit/Config.in b/package/cdrkit/Config.in
index 46c0ba9..af18ba9 100644
--- a/package/cdrkit/Config.in
+++ b/package/cdrkit/Config.in
@@ -4,7 +4,6 @@ config BR2_PACKAGE_CDRKIT
 	select BR2_PACKAGE_LIBCAP
 	select BR2_PACKAGE_ZLIB
 	depends on BR2_USE_MMU # fork
-	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 # libcap
 	bool "cdrkit"
 	help
 	  cdrkit is a suite of programs for recording CDs and DVDs,
@@ -12,7 +11,3 @@ config BR2_PACKAGE_CDRKIT
 	  extracting audio CD data, and more.
 
 	  http://www.cdrkit.org/
-
-comment "cdrkit needs a toolchain w/ headers >= 3.0"
-	depends on BR2_USE_MMU
-	depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
diff --git a/package/dvdrw-tools/Config.in b/package/dvdrw-tools/Config.in
index c9dd3dd..d4d6bd2 100644
--- a/package/dvdrw-tools/Config.in
+++ b/package/dvdrw-tools/Config.in
@@ -39,14 +39,10 @@ choice
 
 config BR2_PACKAGE_DVDRW_TOOLS_CDRKIT_BACKEND
 	bool "cdrkit"
-	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 # cdrkit
 	select BR2_PACKAGE_CDRKIT
 	help
 	  Symlink mkisofs to genisoimage from the cdrkit package.
 
-comment "cdrkit needs a toolchain w/ headers >= 3.0"
-	depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
-
 config BR2_PACKAGE_DVDRW_TOOLS_XORRISO_BACKEND
 	bool "xorriso"
 	select BR2_PACKAGE_XORRISO
diff --git a/package/fastd/Config.in b/package/fastd/Config.in
index 55bdbd6..546d449 100644
--- a/package/fastd/Config.in
+++ b/package/fastd/Config.in
@@ -2,7 +2,6 @@ config BR2_PACKAGE_FASTD
 	bool "fastd"
 	depends on BR2_USE_MMU # fork()
 	depends on BR2_TOOLCHAIN_HAS_THREADS
-	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 # libcap
 	depends on !BR2_STATIC_LIBS # libuecc
 	select BR2_PACKAGE_LIBUECC
 	select BR2_PACKAGE_LIBSODIUM
@@ -24,8 +23,7 @@ config BR2_PACKAGE_FASTD_STATUS_SOCKET
 
 endif
 
-comment "fastd needs a toolchain w/ threads, headers >= 3.0, dynamic library"
+comment "fastd needs a toolchain w/ threads, dynamic library"
 	depends on BR2_USE_MMU
 	depends on !BR2_TOOLCHAIN_HAS_THREADS \
-		|| !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 \
 		|| BR2_STATIC_LIBS
diff --git a/package/libcap/Config.in b/package/libcap/Config.in
index 2e3c8d9..5b0c827 100644
--- a/package/libcap/Config.in
+++ b/package/libcap/Config.in
@@ -1,6 +1,5 @@
 config BR2_PACKAGE_LIBCAP
 	bool "libcap"
-	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 # XATTR_NAME_CAPS
 	help
 	  This library implements the user-space interfaces to the
 	  POSIX 1003.1e capabilities available in Linux kernels. These
@@ -23,6 +22,3 @@ config BR2_PACKAGE_LIBCAP_TOOLS
 	  CONFIG_EXT2_FS_XATTR and CONFIG_EXT2_FS_SECURITY for ext2).
 
 endif
-
-comment "libcap needs a toolchain w/ headers >= 3.0"
-	depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
diff --git a/package/squid/Config.in b/package/squid/Config.in
index 0ab6b37..12bfe19 100644
--- a/package/squid/Config.in
+++ b/package/squid/Config.in
@@ -1,13 +1,12 @@
-comment "squid needs a toolchain w/ C++, headers >= 3.0"
+comment "squid needs a toolchain w/ C++"
 	depends on BR2_USE_MMU
-	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
+	depends on !BR2_INSTALL_LIBSTDCPP
 
 config BR2_PACKAGE_SQUID
 	bool "squid"
 	depends on BR2_INSTALL_LIBSTDCPP
 	# needs fork()
 	depends on BR2_USE_MMU
-	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 # libcap
 	select BR2_PACKAGE_LIBCAP
 	help
 	  Caching proxy for the Web supporting HTTP, HTTPS, FTP, and more.
-- 
2.6.4

[Buildroot] [PATCH 3/4] libcap, cdrkit, dvdrw-tools, fastd, squid: remove headers >= 3.0 dependency

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Now that the libcap package has a patch that makes it build with
 > kernel headers < 3.0 (which was needed for the host variant of
 > libcap), there is no longer a need to have a dependency on headers >=
 > 3.0 for the target variant of libcap.

 > All reverse dependencies of libcap are handled in this commit, except
 > lxc, which will be handled in a separate commit since it needs some
 > special solution.

 > The build of all those packages has been tested with a toolchain that
 > uses kernel headers 2.6.32, which is the oldest that our default glibc
 > version accepts to use.

 > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 4/4] lxc: remove dependency on headers >= 3.0

[Thomas Petazzoni]

Now that libcap no longer needs kernel headers >= 3.0, we can remove
this dependency from lxc. However, building with headers 2.6.32
exhibits a build issue caused by the redefinition of the setns()
function.

Since setns() is not implemented in the C library, lxc provides its
own version. However, for some reason, while the C library doesn't
implement setns(), it provides a prototype for it, which is not
exactly the same as the one in lxc, causing a build failure. We re-use
a solution implemented in gdb to solve the same problem: define in lxc
a function called do_setns(), which calls setns() when available, or
manually does the system call otherwise.

Of course, with old kernels the system call will not be available, so
things will fail at runtime, but this was anyway already the behavior
of lxc's setns() dummy implementation.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 ...0002-src-lxc-utils.h-don-t-redefine-setns.patch | 159 +++++++++++++++++++++
 package/lxc/Config.in                              |   4 +-
 2 files changed, 160 insertions(+), 3 deletions(-)
 create mode 100644 package/lxc/0002-src-lxc-utils.h-don-t-redefine-setns.patch

diff --git a/package/lxc/0002-src-lxc-utils.h-don-t-redefine-setns.patch b/package/lxc/0002-src-lxc-utils.h-don-t-redefine-setns.patch
new file mode 100644
index 0000000..78c88f8
--- /dev/null
+++ b/package/lxc/0002-src-lxc-utils.h-don-t-redefine-setns.patch
@@ -0,0 +1,159 @@
+From fc111c5df2ce573f6d01c2a78405455aa4bc766c Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Wed, 16 Mar 2016 11:47:51 +0100
+Subject: [PATCH] src/lxc/utils.h: don't redefine setns()
+
+The current logic in src/lxc/utils.h consists in implementing a
+setns() function if HAVE_SETNS is undefined. However, there are cases
+where the autoconf setns() check will fail (and therefore HAVE_SETNS
+will not be defined), but the C library does provide a setns()
+prototype. Unfortunately, this prototype conflicts with the one used
+internally in LXC. The C library headers define:
+
+extern int setns (int __fd, int __nstype) __THROW;
+
+While LXC defines:
+
+static inline int do_setns(int fd, int nstype)
+
+Which triggers the following build failures:
+
+utils.h:52:19: error: static declaration of 'setns' follows non-static declaration
+ static inline int setns(int fd, int nstype)
+                   ^
+In file included from /home/test/buildroot2/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/sched.h:43:0,
+                 from bdev.c:38:
+/home/test/buildroot2/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/bits/sched.h:91:12: note: previous declaration of 'setns' was here
+ extern int setns (int __fd, int __nstype) __THROW;
+
+In order to resolve this problem, we adopt the solution that was
+adopted by the gdb project at
+https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=a8c636cb54328fb9a71dcf27b66a7e7ab5443d88:
+the function defined by LXC is renamed to do_setns(), and calls
+setns() when available, or otherwise falls back on doing the system
+calls manually.
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+---
+ src/lxc/attach.c       | 2 +-
+ src/lxc/conf.c         | 4 ++--
+ src/lxc/lxc_user_nic.c | 4 ++--
+ src/lxc/start.c        | 2 +-
+ src/lxc/utils.c        | 2 +-
+ src/lxc/utils.h        | 9 ++++-----
+ 6 files changed, 11 insertions(+), 12 deletions(-)
+
+diff --git a/src/lxc/attach.c b/src/lxc/attach.c
+index 436ae7a..953963f 100644
+--- a/src/lxc/attach.c
++++ b/src/lxc/attach.c
+@@ -260,7 +260,7 @@ static int lxc_attach_to_ns(pid_t pid, int which)
+ 	}
+ 
+ 	for (i = 0; i < size; i++) {
+-		if (fd[i] >= 0 && setns(fd[i], 0) != 0) {
++		if (fd[i] >= 0 && do_setns(fd[i], 0) != 0) {
+ 			saved_errno = errno;
+ 
+ 			for (j = i; j < size; j++)
+diff --git a/src/lxc/conf.c b/src/lxc/conf.c
+index 55c2fae..8c7f16f 100644
+--- a/src/lxc/conf.c
++++ b/src/lxc/conf.c
+@@ -2636,7 +2636,7 @@ void restore_phys_nics_to_netns(int netnsfd, struct lxc_conf *conf)
+ 		SYSERROR("Failed to open monitor netns fd");
+ 		return;
+ 	}
+-	if (setns(netnsfd, 0) != 0) {
++	if (do_setns(netnsfd, 0) != 0) {
+ 		SYSERROR("Failed to enter container netns to reset nics");
+ 		close(oldfd);
+ 		return;
+@@ -2647,7 +2647,7 @@ void restore_phys_nics_to_netns(int netnsfd, struct lxc_conf *conf)
+ 			WARN("Error moving nic index:%d back to host netns",
+ 					s->ifindex);
+ 	}
+-	if (setns(oldfd, 0) != 0)
++	if (do_setns(oldfd, 0) != 0)
+ 		SYSERROR("Failed to re-enter monitor's netns");
+ 	close(oldfd);
+ }
+diff --git a/src/lxc/lxc_user_nic.c b/src/lxc/lxc_user_nic.c
+index 6622db0..399e855 100644
+--- a/src/lxc/lxc_user_nic.c
++++ b/src/lxc/lxc_user_nic.c
+@@ -492,7 +492,7 @@ static int rename_in_ns(int pid, char *oldname, char **newnamep)
+ 		fprintf(stderr, "Opening %s\n", nspath);
+ 		goto out_err;
+ 	}
+-	if (setns(fd, 0) < 0) {
++	if (do_setns(fd, 0) < 0) {
+ 		fprintf(stderr, "setns to container network namespace\n");
+ 		goto out_err;
+ 	}
+@@ -519,7 +519,7 @@ static int rename_in_ns(int pid, char *oldname, char **newnamep)
+ 		if (!*newnamep)
+ 			goto out_err;
+ 	}
+-	if (setns(ofd, 0) < 0) {
++	if (do_setns(ofd, 0) < 0) {
+ 		fprintf(stderr, "Error returning to original netns\n");
+ 		close(ofd);
+ 		return -1;
+diff --git a/src/lxc/start.c b/src/lxc/start.c
+index fa905e2..2c76713 100644
+--- a/src/lxc/start.c
++++ b/src/lxc/start.c
+@@ -157,7 +157,7 @@ static int attach_ns(const int ns_fd[LXC_NS_MAX]) {
+ 		if (ns_fd[i] < 0)
+ 			continue;
+ 
+-		if (setns(ns_fd[i], 0) != 0)
++		if (do_setns(ns_fd[i], 0) != 0)
+ 			goto error;
+ 	}
+ 	return 0;
+diff --git a/src/lxc/utils.c b/src/lxc/utils.c
+index d9e769d..a696e0f 100644
+--- a/src/lxc/utils.c
++++ b/src/lxc/utils.c
+@@ -1091,7 +1091,7 @@ bool switch_to_ns(pid_t pid, const char *ns) {
+ 		return false;
+ 	}
+ 
+-	ret = setns(fd, 0);
++	ret = do_setns(fd, 0);
+ 	if (ret) {
+ 		SYSERROR("failed to set process %d to %s of %d.", pid, ns, fd);
+ 		close(fd);
+diff --git a/src/lxc/utils.h b/src/lxc/utils.h
+index 059026f..0f79ba0 100644
+--- a/src/lxc/utils.h
++++ b/src/lxc/utils.h
+@@ -47,11 +47,11 @@ extern char *get_rundir(void);
+ #endif
+ #endif
+ 
+-/* Define setns() if missing from the C library */
+-#ifndef HAVE_SETNS
+-static inline int setns(int fd, int nstype)
++static inline int do_setns(int fd, int nstype)
+ {
+-#ifdef __NR_setns
++#ifdef HAVE_SETNS
++	return setns(fd, nstype);
++#elif defined(__NR_setns)
+ 	return syscall(__NR_setns, fd, nstype);
+ #elif defined(__NR_set_ns)
+ 	return syscall(__NR_set_ns, fd, nstype);
+@@ -60,7 +60,6 @@ static inline int setns(int fd, int nstype)
+ 	return -1;
+ #endif
+ }
+-#endif
+ 
+ /* Define unshare() if missing from the C library */
+ #ifndef HAVE_UNSHARE
+-- 
+2.6.4
+
diff --git a/package/lxc/Config.in b/package/lxc/Config.in
index 3253f14..acc561c 100644
--- a/package/lxc/Config.in
+++ b/package/lxc/Config.in
@@ -5,7 +5,6 @@ config BR2_PACKAGE_LXC
 	depends on BR2_USE_MMU # fork()
 	# build system forcefully builds a shared library
 	depends on !BR2_STATIC_LIBS
-	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 # libcap
 	help
 	  Linux Containers (LXC), provides the ability to group and isolate
 	  of a set of processes in a jail by virtualizing and accounting the
@@ -13,8 +12,7 @@ config BR2_PACKAGE_LXC
 
 	  https://linuxcontainers.org/
 
-comment "lxc needs a toolchain w/ threads, headers >= 3.0, dynamic library"
+comment "lxc needs a toolchain w/ threads, dynamic library"
 	depends on BR2_USE_MMU
 	depends on !BR2_TOOLCHAIN_HAS_THREADS \
-		|| !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 \
 		|| BR2_STATIC_LIBS
-- 
2.6.4

[Buildroot] [PATCH 4/4] lxc: remove dependency on headers >= 3.0

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Now that libcap no longer needs kernel headers >= 3.0, we can remove
 > this dependency from lxc. However, building with headers 2.6.32
 > exhibits a build issue caused by the redefinition of the setns()
 > function.

 > Since setns() is not implemented in the C library, lxc provides its
 > own version. However, for some reason, while the C library doesn't
 > implement setns(), it provides a prototype for it, which is not
 > exactly the same as the one in lxc, causing a build failure. We re-use
 > a solution implemented in gdb to solve the same problem: define in lxc
 > a function called do_setns(), which calls setns() when available, or
 > manually does the system call otherwise.

 > Of course, with old kernels the system call will not be available, so
 > things will fail at runtime, but this was anyway already the behavior
 > of lxc's setns() dummy implementation.

But can missing setns() really just be ignored and still have a working
lxc? From the code snippets failures look critical.

From the man page:

VERSIONS

        The setns() system call first appeared in Linux in kernel 3.0;
        library support was added to glibc in version 2.14.

So I think it is safer to just keep the >= 3.0 headers dependency.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 4/4] lxc: remove dependency on headers >= 3.0

[Thomas Petazzoni]

Hello,

On Wed, 16 Mar 2016 23:31:11 +0100, Peter Korsgaard wrote:

> But can missing setns() really just be ignored and still have a working
> lxc? From the code snippets failures look critical.

Yes, runtime it definitely won't work. But since the LXC code was
already planning on being able to build on systems not providing those
syscalls, I was staying in line with this decision.

> From the man page:
> 
> VERSIONS
> 
>         The setns() system call first appeared in Linux in kernel 3.0;
>         library support was added to glibc in version 2.14.
> 
> So I think it is safer to just keep the >= 3.0 headers dependency.

But I agree with you, it's probably better to keep the >= 3.0 headers
dependency. However, the comment that the dependency comes from libcap
should be changed.

Should I change a patch to fix this?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 4/4] lxc: remove dependency on headers >= 3.0

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

>> The setns() system call first appeared in Linux in kernel 3.0;
 >> library support was added to glibc in version 2.14.
 >> 
 >> So I think it is safer to just keep the >= 3.0 headers dependency.

 > But I agree with you, it's probably better to keep the >= 3.0 headers
 > dependency. However, the comment that the dependency comes from libcap
 > should be changed.

 > Should I change a patch to fix this?

Yes please!

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH 4/4] lxc: remove dependency on headers >= 3.0

[Arnout Vandecappelle]

On 03/16/16 23:36, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 16 Mar 2016 23:31:11 +0100, Peter Korsgaard wrote:
>
>> But can missing setns() really just be ignored and still have a working
>> lxc? From the code snippets failures look critical.
>
> Yes, runtime it definitely won't work. But since the LXC code was
> already planning on being able to build on systems not providing those
> syscalls, I was staying in line with this decision.
>
>>  From the man page:
>>
>> VERSIONS
>>
>>          The setns() system call first appeared in Linux in kernel 3.0;
>>          library support was added to glibc in version 2.14.
>>
>> So I think it is safer to just keep the >= 3.0 headers dependency.
>
> But I agree with you, it's probably better to keep the >= 3.0 headers
> dependency. However, the comment that the dependency comes from libcap
> should be changed.

  Well, it would work with old kernel headers, as long as the actual kernel is 
 >= 3.0. But the only use case for that would be when using an old toolchain, 
e.g. Arago. It's probably safer indeed to avoid runtime trouble by just 
depending on the headers version.


  Regards,
  Arnout

>
> Should I change a patch to fix this?
>
> Thanks,
>
> Thomas
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 4/4] lxc: remove dependency on headers >= 3.0

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >  Well, it would work with old kernel headers, as long as the actual
 > kernel is > = 3.0. But the only use case for that would be when using
 > an old toolchain, e.g. Arago. It's probably safer indeed to avoid
 > runtime trouble by just depending on the headers version.

Yes, or if the kernel has the setns syscall backported - But as we
currently don't differ between build time (E.G. kernel headers) and
runtime (actual kernel), then that's all we can do.

And I don't think we should introduce the extra complexity to have
different symbols for kernel headers and runtime kernel versions.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH 1/4] libcap: bump version

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > From: "Yann E. MORIN" <yann.morin.1998@free.fr>
 > attr is no longer a dependency, not even optional.

 > Refresh our patches, and drop the backport from upstream.

It would have been good to mention something about the new host-gperf
dependency, but ok.
 
 >  define HOST_LIBCAP_BUILD_CMDS
 >  	$(HOST_MAKE_ENV) $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D)\
 > -		LIBATTR=yes RAISE_SETFCAP=no
 > +		RAISE_SETFCAP=no
 >  endef
 
 >  define HOST_LIBCAP_INSTALL_CMDS
 >  	$(HOST_MAKE_ENV) $(MAKE) -C $(@D) DESTDIR=$(HOST_DIR) \
 > -		LIBATTR=yes RAISE_SETFCAP=no prefix=/usr lib=lib install
 > +		RAISE_SETFCAP=no prefix=/usr lib=lib install
 >  endef

Not related to this bump, but this looks wrong. We shouldn't use DESTDIR
/ set prefix to /usr for host builds. From a quick look the prefix is at
least used in libcap.pc, so other host packages will get wrong info if
they use pkgconfig to find host-libcap.

Committed, thanks.

-- 
Bye, Peter Korsgaard