* [PATCH 0/2 v2] libcap-ng, swig: add packages @ 2015-08-21 5:38 wenzong.fan 2015-08-21 5:38 ` [PATCH 1/2 v2] swig: add package 3.0.6 wenzong.fan 2015-08-21 5:38 ` [PATCH 2/2 v2] libcap-ng: add package 0.7.7 wenzong.fan 0 siblings, 2 replies; 13+ messages in thread From: wenzong.fan @ 2015-08-21 5:38 UTC (permalink / raw) To: openembedded-core From: Wenzong Fan <wenzong.fan@windriver.com> V2 changes: * add swig 3.0.6 which the latest version from meta-oe The following changes since commit a01a33b17861c227c1c16fbc2d819d86fb9bf893: linux-yocto-3.14: Update to branch HEADs (2015-08-20 15:17:01 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib wenzong/libcap-ng http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/libcap-ng Wenzong Fan (2): swig: add package 3.0.6 libcap-ng: add package 0.7.7 meta/recipes-devtools/swig/swig.inc | 63 ++++++++++++++++++++ ...lf-exe-for-swig-swiglib-on-non-Win32-plat.patch | 69 ++++++++++++++++++++++ ...nfigure-use-pkg-config-for-pcre-detection.patch | 64 ++++++++++++++++++++ meta/recipes-devtools/swig/swig_3.0.6.bb | 8 +++ .../libcap-ng/libcap-ng/python.patch | 58 ++++++++++++++++++ meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 ++++++++++++ 6 files changed, 301 insertions(+) create mode 100644 meta/recipes-devtools/swig/swig.inc create mode 100644 meta/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch create mode 100644 meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch create mode 100644 meta/recipes-devtools/swig/swig_3.0.6.bb create mode 100644 meta/recipes-support/libcap-ng/libcap-ng/python.patch create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb -- 1.9.1 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 1/2 v2] swig: add package 3.0.6 2015-08-21 5:38 [PATCH 0/2 v2] libcap-ng, swig: add packages wenzong.fan @ 2015-08-21 5:38 ` wenzong.fan 2015-08-21 5:38 ` [PATCH 2/2 v2] libcap-ng: add package 0.7.7 wenzong.fan 1 sibling, 0 replies; 13+ messages in thread From: wenzong.fan @ 2015-08-21 5:38 UTC (permalink / raw) To: openembedded-core From: Wenzong Fan <wenzong.fan@windriver.com> Ackage from meta-oe to oe-core: meta-oe commit: 9cc54e10efa5ca70d9980f833a8e5a310e5ad21d It's required for libcap-ng to build python bindings. With adding it to oe-core, the copies from following layers could be removed: * meta-oe, meta-selinux, meta-intel-iot-middleware ... Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com> --- meta/recipes-devtools/swig/swig.inc | 63 ++++++++++++++++++++ ...lf-exe-for-swig-swiglib-on-non-Win32-plat.patch | 69 ++++++++++++++++++++++ ...nfigure-use-pkg-config-for-pcre-detection.patch | 64 ++++++++++++++++++++ meta/recipes-devtools/swig/swig_3.0.6.bb | 8 +++ 4 files changed, 204 insertions(+) create mode 100644 meta/recipes-devtools/swig/swig.inc create mode 100644 meta/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch create mode 100644 meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch create mode 100644 meta/recipes-devtools/swig/swig_3.0.6.bb diff --git a/meta/recipes-devtools/swig/swig.inc b/meta/recipes-devtools/swig/swig.inc new file mode 100644 index 0000000..9821fa5 --- /dev/null +++ b/meta/recipes-devtools/swig/swig.inc @@ -0,0 +1,63 @@ +DESCRIPTION = "SWIG - Simplified Wrapper and Interface Generator" +HOMEPAGE = "http://swig.sourceforge.net/" +LICENSE = "BSD & GPLv3" +LIC_FILES_CHKSUM = "file://LICENSE;md5=e7807a6282784a7dde4c846626b08fc6 \ + file://LICENSE-GPL;md5=d32239bcb673463ab874e80d47fae504 \ + file://LICENSE-UNIVERSITIES;md5=8ce9dcc8f7c994de4a408b205c72ba08" + +SECTION = "devel" + +DEPENDS = "libpcre python" + +SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz" + +inherit autotools pythonnative + +EXTRA_OECONF = " \ + --with-python=${PYTHON} \ + --without-allegrocl \ + --without-android \ + --without-boost \ + --without-chicken \ + --without-clisp \ + --without-csharp \ + --without-d \ + --without-gcj \ + --without-go \ + --without-guile \ + --without-java \ + --without-lua \ + --without-mzscheme \ + --without-ocaml \ + --without-octave \ + --without-perl5 \ + --without-pike \ + --without-php \ + --without-python3 \ + --without-r \ + --without-ruby \ + --without-tcl \ +" + +BBCLASSEXTEND = "native nativesdk" + +do_configure() { + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess ${S}/Tools/config + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub ${S}/Tools/config + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess ${S} + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub ${S} + oe_runconf +} + +do_install_append_class-nativesdk() { + cd ${D}${bindir} + ln -s swig swig2.0 +} + +def swiglib_relpath(d): + swiglib = d.getVar('datadir', True) + "/" + d.getVar('BPN', True) + "/" + d.getVar('PV', True) + return os.path.relpath(swiglib, d.getVar('bindir', True)) + +do_install_append_class-native() { + create_wrapper ${D}${bindir}/swig SWIG_LIB='`dirname $''realpath`'/${@swiglib_relpath(d)} +} diff --git a/meta/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch b/meta/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch new file mode 100644 index 0000000..81df3e2 --- /dev/null +++ b/meta/recipes-devtools/swig/swig/0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch @@ -0,0 +1,69 @@ +From a4a0440a644c6c5e5da096efe3cf05ba309a284f Mon Sep 17 00:00:00 2001 +From: "NODA, Kai" <nodakai@gmail.com> +Date: Sun, 22 Apr 2012 17:01:02 +0900 +Subject: [PATCH] Use /proc/self/exe for "swig -swiglib" on non-Win32 + platforms. + +If it wasn't found, then fall back to a fixed string just as before. + +Upstream-Status: Submitted +http://sourceforge.net/mailarchive/message.php?msg_id=29179733 + +--- + Source/Modules/main.cxx | 24 ++++++++++++++++++++++-- + 1 file changed, 22 insertions(+), 2 deletions(-) + +diff --git a/Source/Modules/main.cxx b/Source/Modules/main.cxx +index d2f5d3b..cbb0a12 100644 +--- a/Source/Modules/main.cxx ++++ b/Source/Modules/main.cxx +@@ -26,6 +26,11 @@ char cvsroot_main_cxx[] = "$Id$"; + #include "cparse.h" + #include <ctype.h> + #include <limits.h> // for INT_MAX ++#ifndef _WIN32 ++#include <cstddef> ++#include <unistd.h> // for readlink ++#include <sys/stat.h> // for stat ++#endif + + // Global variables + +@@ -902,9 +907,9 @@ int SWIG_main(int argc, char *argv[], Language *l) { + + // Check for SWIG_LIB environment variable + if ((c = getenv("SWIG_LIB")) == (char *) 0) { ++ char *p; + #if defined(_WIN32) + char buf[MAX_PATH]; +- char *p; + if (!(GetModuleFileName(0, buf, MAX_PATH) == 0 || (p = strrchr(buf, '\\')) == 0)) { + *(p + 1) = '\0'; + SwigLib = NewStringf("%sLib", buf); // Native windows installation path +@@ -914,7 +919,22 @@ int SWIG_main(int argc, char *argv[], Language *l) { + if (Len(SWIG_LIB_WIN_UNIX) > 0) + SwigLibWinUnix = NewString(SWIG_LIB_WIN_UNIX); // Unix installation path using a drive letter (for msys/mingw) + #else +- SwigLib = NewString(SWIG_LIB); ++ char buf[PATH_MAX]; ++ if (0 < ::readlink("/proc/self/exe", buf, sizeof(buf)) && ++ (p = ::strstr(buf, "/bin/swig"))) { ++ int major, minor, patch; ++ const int ret = ::sscanf(VERSION, "%d.%d.%d", &major, &minor, &patch); ++ if (3 == ret) { ++ const ::ptrdiff_t dir_part_len = p - buf; ++ ::snprintf(p, PATH_MAX - dir_part_len, "/share/swig/%d.%d.%d", major, minor, patch); ++ struct ::stat stat_res; ++ if (0 == ::stat(buf, &stat_res) && S_ISDIR(stat_res.st_mode)) { ++ SwigLib = NewString(buf); ++ } ++ } ++ } ++ if (NULL == SwigLib) ++ SwigLib = NewString(SWIG_LIB); + #endif + } else { + SwigLib = NewString(c); +-- +1.7.9.5 + diff --git a/meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch b/meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch new file mode 100644 index 0000000..1b1128a --- /dev/null +++ b/meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch @@ -0,0 +1,64 @@ +From 5c4d6d8538994d5fe9b3b46bfafaf0a605e3bda6 Mon Sep 17 00:00:00 2001 +From: Koen Kooi <koen.kooi@linaro.org> +Date: Tue, 17 Jun 2014 08:18:17 +0200 +Subject: [PATCH] configure: use pkg-config for pcre detection + +Signed-off-by: Koen Kooi <koen.kooi@linaro.org> +Upstream-Status: pending +--- + configure.ac | 38 +++++++------------------------------- + 1 file changed, 7 insertions(+), 31 deletions(-) + +diff --git a/configure.ac b/configure.ac +index 0c984b7..6edcec1 100644 +--- a/configure.ac ++++ b/configure.ac +@@ -70,38 +70,14 @@ AC_MSG_RESULT([$with_pcre]) + + dnl To make configuring easier, check for a locally built PCRE using the Tools/pcre-build.sh script + if test x"${with_pcre}" = xyes ; then +- AC_MSG_CHECKING([whether to use local PCRE]) +- local_pcre_config=no +- if test -z $PCRE_CONFIG; then +- if test -f `pwd`/pcre/pcre-swig-install/bin/pcre-config; then +- PCRE_CONFIG=`pwd`/pcre/pcre-swig-install/bin/pcre-config +- local_pcre_config=$PCRE_CONFIG +- fi +- fi +- AC_MSG_RESULT([$local_pcre_config]) +-fi +-AS_IF([test "x$with_pcre" != xno], +- [AX_PATH_GENERIC([pcre], +- [], dnl Minimal version of PCRE we need -- accept any +- [], dnl custom sed script for version parsing is not needed +- [AC_DEFINE([HAVE_PCRE], [1], [Define if you have PCRE library]) +- LIBS="$LIBS $PCRE_LIBS" +- CPPFLAGS="$CPPFLAGS $PCRE_CFLAGS" +- ], +- [AC_MSG_FAILURE([ +- Cannot find pcre-config script from PCRE (Perl Compatible Regular Expressions) +- library package. This dependency is needed for configure to complete, +- Either: +- - Install the PCRE developer package on your system (preferred approach). +- - Download the PCRE source tarball, build and install on your system +- as you would for any package built from source distribution. +- - Use the Tools/pcre-build.sh script to build PCRE just for SWIG to statically +- link against. Run 'Tools/pcre-build.sh --help' for instructions. +- (quite easy and does not require privileges to install PCRE on your system) +- - Use configure --without-pcre to disable regular expressions support in SWIG +- (not recommended).]) +- ]) ++ PKG_CHECK_MODULES([PCRE], [libpcre], [ ++ AC_DEFINE([HAVE_PCRE], [1], [Define if you have PCRE library]) ++ LIBS="$LIBS $PCRE_LIBS" ++ CPPFLAGS="$CPPFLAGS $PCRE_CFLAGS" ++ ], [ ++ AC_MSG_WARN([$PCRE_PKG_ERRORS]) + ]) ++fi + + + dnl CCache +-- +1.9.3 + diff --git a/meta/recipes-devtools/swig/swig_3.0.6.bb b/meta/recipes-devtools/swig/swig_3.0.6.bb new file mode 100644 index 0000000..2a0917e --- /dev/null +++ b/meta/recipes-devtools/swig/swig_3.0.6.bb @@ -0,0 +1,8 @@ +require ${BPN}.inc + +SRC_URI += "file://0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch \ + file://0001-configure-use-pkg-config-for-pcre-detection.patch \ + " +SRC_URI[md5sum] = "df43ae271642bcfa61c1e59f970f9963" +SRC_URI[sha256sum] = "c67f63ea11956106e4cda66416d5020330dc4ce2ee45057d39a9494ce33eca05" + -- 1.9.1 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 2/2 v2] libcap-ng: add package 0.7.7 2015-08-21 5:38 [PATCH 0/2 v2] libcap-ng, swig: add packages wenzong.fan 2015-08-21 5:38 ` [PATCH 1/2 v2] swig: add package 3.0.6 wenzong.fan @ 2015-08-21 5:38 ` wenzong.fan 2015-08-21 7:25 ` Khem Raj 1 sibling, 1 reply; 13+ messages in thread From: wenzong.fan @ 2015-08-21 5:38 UTC (permalink / raw) To: openembedded-core From: Wenzong Fan <wenzong.fan@windriver.com> Pull package from meta-oe to oe-core: meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6 The libcap-ng library is intended to make programming with posix capabilities much easier than the traditional libcap library. It's not a replacement to libcap, it provides different library (libcap-ng.so) while packages explicitly look for libcap.so. It could be used by qemu, util-linux, libvirt, audit ... With adding it to oe-core, the copies from following layers could be removed: * meta-oe, meta-selinux, meta-security-framework ... Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com> --- .../libcap-ng/libcap-ng/python.patch | 58 ++++++++++++++++++++++ meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++++++++++++++ 2 files changed, 97 insertions(+) create mode 100644 meta/recipes-support/libcap-ng/libcap-ng/python.patch create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch b/meta/recipes-support/libcap-ng/libcap-ng/python.patch new file mode 100644 index 0000000..59591eb --- /dev/null +++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch @@ -0,0 +1,58 @@ +From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001 +From: Li xin <lixin.fnst@cn.fujitsu.com> +Date: Sat, 18 Jul 2015 23:03:30 +0900 +Subject: [PATCH] configure.ac - Avoid an incorrect check for python. + Makefile.am - avoid hard coded host include paths. + +Upstream-Status: pending + +Signed-off-by: Mark Hatle <mark.hatle@windriver.com> +Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com> +--- + bindings/python/Makefile.am | 3 ++- + configure.ac | 15 ++------------- + 2 files changed, 4 insertions(+), 14 deletions(-) + +diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am +index 82b9bb8..f9fe7a8 100644 +--- a/bindings/python/Makefile.am ++++ b/bindings/python/Makefile.am +@@ -23,7 +23,8 @@ SUBDIRS = test + CONFIG_CLEAN_FILES = *.loT *.rej *.orig + AM_CFLAGS = -fPIC -DPIC + PYLIBVER ?= python$(PYTHON_VERSION) +-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@ ++PYINC ?= /usr/include/$(PYLIBVER) ++AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC) + LIBS = $(top_builddir)/src/libcap-ng.la + SWIG_FLAGS = -python + SWIG_INCLUDES = ${AM_CPPFLAGS} +diff --git a/configure.ac b/configure.ac +index 1d777d5..9d90f64 100644 +--- a/configure.ac ++++ b/configure.ac +@@ -123,19 +123,8 @@ if test x$use_python = xno ; then + else + AC_MSG_RESULT(testing) + AM_PATH_PYTHON +-PYINCLUDEDIR=`python${am_cv_python_version} -c "from distutils import sysconfig; print(sysconfig.get_config_var('INCLUDEPY'))"` +-if test -f ${PYINCLUDEDIR}/Python.h ; then +- python_found="yes" +- AC_SUBST(PYINCLUDEDIR) +- AC_MSG_NOTICE(Python bindings will be built) +-else +- python_found="no" +- if test x$use_python = xyes ; then +- AC_MSG_ERROR([Python explicitly required and python headers found]) +- else +- AC_MSG_WARN("Python headers not found - python bindings will not be made") +- fi +-fi ++python_found="yes" ++AC_MSG_NOTICE(Python bindings will be built) + fi + AM_CONDITIONAL(HAVE_PYTHON, test ${python_found} = "yes") + +-- +1.8.4.2 + diff --git a/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb new file mode 100644 index 0000000..a31d5dc --- /dev/null +++ b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb @@ -0,0 +1,39 @@ +SUMMARY = "An alternate posix capabilities library" +DESCRIPTION = "The libcap-ng library is intended to make programming \ +with POSIX capabilities much easier than the traditional libcap library." +HOMEPAGE = "http://freecode.com/projects/libcap-ng" +SECTION = "base" +LICENSE = "GPLv2+ & LGPLv2.1+" +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ + file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06" + +SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \ + file://python.patch" + +inherit lib_package autotools pythonnative + +SRC_URI[md5sum] = "3d7d126b29e2869a0257c17c8b0d9b2e" +SRC_URI[sha256sum] = "615549ce39b333f6b78baee0c0b4ef18bc726c6bf1cca123dfd89dd963f6d06b" + +DEPENDS += "swig-native python" + +EXTRA_OECONF += "--without-python3" + +EXTRA_OEMAKE += "PYLIBVER='python${PYTHON_BASEVERSION}' PYINC='${STAGING_INCDIR}/${PYLIBVER}'" + +PACKAGES += "${PN}-python" + +FILES_${PN}-dbg += "${libdir}/python${PYTHON_BASEVERSION}/*/.debug" +FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}" + +BBCLASSEXTEND = "native" + +do_install_append() { + # Moving libcap-ng to base_libdir + if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then + mkdir -p ${D}/${base_libdir}/ + mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/ + relpath=${@os.path.relpath("${base_libdir}", "${libdir}")} + ln -sf ${relpath}/libcap-ng.so.0.0.0 ${D}${libdir}/libcap-ng.so + fi +} -- 1.9.1 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2 v2] libcap-ng: add package 0.7.7 2015-08-21 5:38 ` [PATCH 2/2 v2] libcap-ng: add package 0.7.7 wenzong.fan @ 2015-08-21 7:25 ` Khem Raj 2015-08-22 0:55 ` Randy MacLeod 2015-08-24 22:27 ` Mark Hatle 0 siblings, 2 replies; 13+ messages in thread From: Khem Raj @ 2015-08-21 7:25 UTC (permalink / raw) To: wenzong fan; +Cc: Patches and discussions about the oe-core layer On Thu, Aug 20, 2015 at 10:38 PM, <wenzong.fan@windriver.com> wrote: > From: Wenzong Fan <wenzong.fan@windriver.com> > > Pull package from meta-oe to oe-core: > meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6 > > The libcap-ng library is intended to make programming with posix > capabilities much easier than the traditional libcap library. > > It's not a replacement to libcap, it provides different library > (libcap-ng.so) while packages explicitly look for libcap.so. It > could be used by qemu, util-linux, libvirt, audit ... > > With adding it to oe-core, the copies from following layers could > be removed: > > * meta-oe, meta-selinux, meta-security-framework ... I am afraid that we are setting a pretext for moving all recipes that are in multiple layers to be eligible for OE-core now. met-oe is common layer for extended recipes, so may be other layers should have been a bit more vigilant and made sure there requirements were met with whats in meta-oe. we should ask what core feature does it enable for reference images and machines. > > Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com> > --- > .../libcap-ng/libcap-ng/python.patch | 58 ++++++++++++++++++++++ > meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++++++++++++++ > 2 files changed, 97 insertions(+) > create mode 100644 meta/recipes-support/libcap-ng/libcap-ng/python.patch > create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb > > diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch b/meta/recipes-support/libcap-ng/libcap-ng/python.patch > new file mode 100644 > index 0000000..59591eb > --- /dev/null > +++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch > @@ -0,0 +1,58 @@ > +From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001 > +From: Li xin <lixin.fnst@cn.fujitsu.com> > +Date: Sat, 18 Jul 2015 23:03:30 +0900 > +Subject: [PATCH] configure.ac - Avoid an incorrect check for python. > + Makefile.am - avoid hard coded host include paths. > + > +Upstream-Status: pending > + > +Signed-off-by: Mark Hatle <mark.hatle@windriver.com> > +Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com> > +--- > + bindings/python/Makefile.am | 3 ++- > + configure.ac | 15 ++------------- > + 2 files changed, 4 insertions(+), 14 deletions(-) > + > +diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am > +index 82b9bb8..f9fe7a8 100644 > +--- a/bindings/python/Makefile.am > ++++ b/bindings/python/Makefile.am > +@@ -23,7 +23,8 @@ SUBDIRS = test > + CONFIG_CLEAN_FILES = *.loT *.rej *.orig > + AM_CFLAGS = -fPIC -DPIC > + PYLIBVER ?= python$(PYTHON_VERSION) > +-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@ > ++PYINC ?= /usr/include/$(PYLIBVER) > ++AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC) > + LIBS = $(top_builddir)/src/libcap-ng.la > + SWIG_FLAGS = -python > + SWIG_INCLUDES = ${AM_CPPFLAGS} > +diff --git a/configure.ac b/configure.ac > +index 1d777d5..9d90f64 100644 > +--- a/configure.ac > ++++ b/configure.ac > +@@ -123,19 +123,8 @@ if test x$use_python = xno ; then > + else > + AC_MSG_RESULT(testing) > + AM_PATH_PYTHON > +-PYINCLUDEDIR=`python${am_cv_python_version} -c "from distutils import sysconfig; print(sysconfig.get_config_var('INCLUDEPY'))"` > +-if test -f ${PYINCLUDEDIR}/Python.h ; then > +- python_found="yes" > +- AC_SUBST(PYINCLUDEDIR) > +- AC_MSG_NOTICE(Python bindings will be built) > +-else > +- python_found="no" > +- if test x$use_python = xyes ; then > +- AC_MSG_ERROR([Python explicitly required and python headers found]) > +- else > +- AC_MSG_WARN("Python headers not found - python bindings will not be made") > +- fi > +-fi > ++python_found="yes" > ++AC_MSG_NOTICE(Python bindings will be built) > + fi > + AM_CONDITIONAL(HAVE_PYTHON, test ${python_found} = "yes") > + > +-- > +1.8.4.2 > + > diff --git a/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb > new file mode 100644 > index 0000000..a31d5dc > --- /dev/null > +++ b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb > @@ -0,0 +1,39 @@ > +SUMMARY = "An alternate posix capabilities library" > +DESCRIPTION = "The libcap-ng library is intended to make programming \ > +with POSIX capabilities much easier than the traditional libcap library." > +HOMEPAGE = "http://freecode.com/projects/libcap-ng" > +SECTION = "base" > +LICENSE = "GPLv2+ & LGPLv2.1+" > +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ > + file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06" > + > +SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \ > + file://python.patch" > + > +inherit lib_package autotools pythonnative > + > +SRC_URI[md5sum] = "3d7d126b29e2869a0257c17c8b0d9b2e" > +SRC_URI[sha256sum] = "615549ce39b333f6b78baee0c0b4ef18bc726c6bf1cca123dfd89dd963f6d06b" > + > +DEPENDS += "swig-native python" > + > +EXTRA_OECONF += "--without-python3" > + > +EXTRA_OEMAKE += "PYLIBVER='python${PYTHON_BASEVERSION}' PYINC='${STAGING_INCDIR}/${PYLIBVER}'" > + > +PACKAGES += "${PN}-python" > + > +FILES_${PN}-dbg += "${libdir}/python${PYTHON_BASEVERSION}/*/.debug" > +FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}" > + > +BBCLASSEXTEND = "native" > + > +do_install_append() { > + # Moving libcap-ng to base_libdir > + if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then > + mkdir -p ${D}/${base_libdir}/ > + mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/ > + relpath=${@os.path.relpath("${base_libdir}", "${libdir}")} > + ln -sf ${relpath}/libcap-ng.so.0.0.0 ${D}${libdir}/libcap-ng.so > + fi > +} > -- > 1.9.1 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2 v2] libcap-ng: add package 0.7.7 2015-08-21 7:25 ` Khem Raj @ 2015-08-22 0:55 ` Randy MacLeod 2015-08-22 1:14 ` Andre McCurdy 2015-08-22 1:36 ` Khem Raj 2015-08-24 22:27 ` Mark Hatle 1 sibling, 2 replies; 13+ messages in thread From: Randy MacLeod @ 2015-08-22 0:55 UTC (permalink / raw) To: openembedded-core, Khem Raj, Wenzong Fan On 2015-08-21 03:25 AM, Khem Raj wrote: > On Thu, Aug 20, 2015 at 10:38 PM, <wenzong.fan@windriver.com> wrote: >> From: Wenzong Fan <wenzong.fan@windriver.com> >> >> Pull package from meta-oe to oe-core: >> meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6 >> >> The libcap-ng library is intended to make programming with posix >> capabilities much easier than the traditional libcap library. >> >> It's not a replacement to libcap, it provides different library >> (libcap-ng.so) while packages explicitly look for libcap.so. It >> could be used by qemu, util-linux, libvirt, audit ... >> >> With adding it to oe-core, the copies from following layers could >> be removed: >> >> * meta-oe, meta-selinux, meta-security-framework ... > > I am afraid that we are setting a pretext for moving all recipes that > are in multiple layers to be eligible for OE-core now. > meta-oe is common layer for extended recipes, so may be other layers > should have been a bit more vigilant and made sure > there requirements were met with whats in meta-oe. Meta-oe has far to many recipes for some people to want to include the entire layer: meta-oe.git $ find meta-oe/ -name "*bb" | wc -l 618 We can certainly use the new whitelist layer filtering to get to a smaller collection of recipes but I'd like to suggest we need to document and maybe design the layer structure a bit more. There are lots of different opinions about how to split collections of packages in to different layers so unless someone has a dependency-based analysis of all pacakges in all layers, I don't see much point in a long discussion on this topic. Has the idea of creating a new meta-openembedded layer for widely-used, OS interface libraries been proposed? These 80 recipes could be considered for inclusion: $ find meta-oe -name "lib*bb" | wc -l 80 but more consideration is probably needed. In the short term (oe-core-1.9 (now 2.0), I guess we leave things as they are. Sigh... ../Randy While I'm at it, for reference of layer size: $ for i in `ls -d meta-*`; do echo -n $i": "; find $i -name "*bb" | wc -l; done meta-efl: 57 meta-filesystems: 16 meta-gnome: 82 meta-gpe: 5 meta-initramfs: 14 meta-multimedia: 51 meta-networking: 115 meta-oe: 618 meta-perl: 30 meta-python: 74 meta-ruby: 4 meta-systemd: 1 meta-webserver: 13 meta-xfce: 67 ----------------------------------------- > we should ask what core feature does it enable for reference images > and machines. > >> >> Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com> >> --- >> .../libcap-ng/libcap-ng/python.patch | 58 ++++++++++++++++++++++ >> meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++++++++++++++ >> 2 files changed, 97 insertions(+) >> create mode 100644 meta/recipes-support/libcap-ng/libcap-ng/python.patch >> create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >> >> diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >> new file mode 100644 >> index 0000000..59591eb >> --- /dev/null >> +++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >> @@ -0,0 +1,58 @@ >> +From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001 >> +From: Li xin <lixin.fnst@cn.fujitsu.com> >> +Date: Sat, 18 Jul 2015 23:03:30 +0900 >> +Subject: [PATCH] configure.ac - Avoid an incorrect check for python. >> + Makefile.am - avoid hard coded host include paths. >> + >> +Upstream-Status: pending >> + >> +Signed-off-by: Mark Hatle <mark.hatle@windriver.com> >> +Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com> >> +--- >> + bindings/python/Makefile.am | 3 ++- >> + configure.ac | 15 ++------------- >> + 2 files changed, 4 insertions(+), 14 deletions(-) >> + >> +diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am >> +index 82b9bb8..f9fe7a8 100644 >> +--- a/bindings/python/Makefile.am >> ++++ b/bindings/python/Makefile.am >> +@@ -23,7 +23,8 @@ SUBDIRS = test >> + CONFIG_CLEAN_FILES = *.loT *.rej *.orig >> + AM_CFLAGS = -fPIC -DPIC >> + PYLIBVER ?= python$(PYTHON_VERSION) >> +-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@ >> ++PYINC ?= /usr/include/$(PYLIBVER) >> ++AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC) >> + LIBS = $(top_builddir)/src/libcap-ng.la >> + SWIG_FLAGS = -python >> + SWIG_INCLUDES = ${AM_CPPFLAGS} >> +diff --git a/configure.ac b/configure.ac >> +index 1d777d5..9d90f64 100644 >> +--- a/configure.ac >> ++++ b/configure.ac >> +@@ -123,19 +123,8 @@ if test x$use_python = xno ; then >> + else >> + AC_MSG_RESULT(testing) >> + AM_PATH_PYTHON >> +-PYINCLUDEDIR=`python${am_cv_python_version} -c "from distutils import sysconfig; print(sysconfig.get_config_var('INCLUDEPY'))"` >> +-if test -f ${PYINCLUDEDIR}/Python.h ; then >> +- python_found="yes" >> +- AC_SUBST(PYINCLUDEDIR) >> +- AC_MSG_NOTICE(Python bindings will be built) >> +-else >> +- python_found="no" >> +- if test x$use_python = xyes ; then >> +- AC_MSG_ERROR([Python explicitly required and python headers found]) >> +- else >> +- AC_MSG_WARN("Python headers not found - python bindings will not be made") >> +- fi >> +-fi >> ++python_found="yes" >> ++AC_MSG_NOTICE(Python bindings will be built) >> + fi >> + AM_CONDITIONAL(HAVE_PYTHON, test ${python_found} = "yes") >> + >> +-- >> +1.8.4.2 >> + >> diff --git a/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >> new file mode 100644 >> index 0000000..a31d5dc >> --- /dev/null >> +++ b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >> @@ -0,0 +1,39 @@ >> +SUMMARY = "An alternate posix capabilities library" >> +DESCRIPTION = "The libcap-ng library is intended to make programming \ >> +with POSIX capabilities much easier than the traditional libcap library." >> +HOMEPAGE = "http://freecode.com/projects/libcap-ng" >> +SECTION = "base" >> +LICENSE = "GPLv2+ & LGPLv2.1+" >> +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ >> + file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06" >> + >> +SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \ >> + file://python.patch" >> + >> +inherit lib_package autotools pythonnative >> + >> +SRC_URI[md5sum] = "3d7d126b29e2869a0257c17c8b0d9b2e" >> +SRC_URI[sha256sum] = "615549ce39b333f6b78baee0c0b4ef18bc726c6bf1cca123dfd89dd963f6d06b" >> + >> +DEPENDS += "swig-native python" >> + >> +EXTRA_OECONF += "--without-python3" >> + >> +EXTRA_OEMAKE += "PYLIBVER='python${PYTHON_BASEVERSION}' PYINC='${STAGING_INCDIR}/${PYLIBVER}'" >> + >> +PACKAGES += "${PN}-python" >> + >> +FILES_${PN}-dbg += "${libdir}/python${PYTHON_BASEVERSION}/*/.debug" >> +FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}" >> + >> +BBCLASSEXTEND = "native" >> + >> +do_install_append() { >> + # Moving libcap-ng to base_libdir >> + if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then >> + mkdir -p ${D}/${base_libdir}/ >> + mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/ >> + relpath=${@os.path.relpath("${base_libdir}", "${libdir}")} >> + ln -sf ${relpath}/libcap-ng.so.0.0.0 ${D}${libdir}/libcap-ng.so >> + fi >> +} >> -- >> 1.9.1 >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2 v2] libcap-ng: add package 0.7.7 2015-08-22 0:55 ` Randy MacLeod @ 2015-08-22 1:14 ` Andre McCurdy 2015-08-24 22:30 ` Mark Hatle 2015-08-24 22:53 ` Randy MacLeod 2015-08-22 1:36 ` Khem Raj 1 sibling, 2 replies; 13+ messages in thread From: Andre McCurdy @ 2015-08-22 1:14 UTC (permalink / raw) To: Randy MacLeod; +Cc: OE Core mailing list On Fri, Aug 21, 2015 at 5:55 PM, Randy MacLeod <randy.macleod@windriver.com> wrote: > On 2015-08-21 03:25 AM, Khem Raj wrote: >> >> On Thu, Aug 20, 2015 at 10:38 PM, <wenzong.fan@windriver.com> wrote: >>> >>> From: Wenzong Fan <wenzong.fan@windriver.com> >>> >>> Pull package from meta-oe to oe-core: >>> meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6 >>> >>> The libcap-ng library is intended to make programming with posix >>> capabilities much easier than the traditional libcap library. >>> >>> It's not a replacement to libcap, it provides different library >>> (libcap-ng.so) while packages explicitly look for libcap.so. It >>> could be used by qemu, util-linux, libvirt, audit ... >>> >>> With adding it to oe-core, the copies from following layers could >>> be removed: >>> >>> * meta-oe, meta-selinux, meta-security-framework ... >> >> >> I am afraid that we are setting a pretext for moving all recipes that >> are in multiple layers to be eligible for OE-core now. >> meta-oe is common layer for extended recipes, so may be other layers >> should have been a bit more vigilant and made sure >> there requirements were met with whats in meta-oe. > > > Meta-oe has far to many recipes for some people to want > to include the entire layer: > meta-oe.git $ find meta-oe/ -name "*bb" | wc -l > 618 I typically include most of the meta-oe layers, but I've never really given much thought to how many recipes there are. Is the concern that parsing too many recipes makes bitbake slow? Or is there another reason why I wouldn't want to include them all? > We can certainly use the new whitelist layer filtering to > get to a smaller collection of recipes but I'd like to suggest we > need to document and maybe design the layer structure > a bit more. There are lots of different opinions about > how to split collections of packages in to different layers so > unless someone has a dependency-based analysis of all > pacakges in all layers, I don't see much point in a long > discussion on this topic. > > Has the idea of creating a new meta-openembedded layer > for widely-used, OS interface libraries been proposed? > These 80 recipes could be considered for inclusion: > $ find meta-oe -name "lib*bb" | wc -l > 80 > but more consideration is probably needed. > > In the short term (oe-core-1.9 (now 2.0), I guess we leave > things as they are. Sigh... > > ../Randy > > > While I'm at it, for reference of layer size: > > $ for i in `ls -d meta-*`; do echo -n $i": "; find $i -name "*bb" | wc -l; > done > meta-efl: 57 > meta-filesystems: 16 > meta-gnome: 82 > meta-gpe: 5 > meta-initramfs: 14 > meta-multimedia: 51 > meta-networking: 115 > meta-oe: 618 > meta-perl: 30 > meta-python: 74 > meta-ruby: 4 > meta-systemd: 1 > meta-webserver: 13 > meta-xfce: 67 > > ----------------------------------------- > > > >> we should ask what core feature does it enable for reference images >> and machines. >> >>> >>> Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com> >>> --- >>> .../libcap-ng/libcap-ng/python.patch | 58 >>> ++++++++++++++++++++++ >>> meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++++++++++++++ >>> 2 files changed, 97 insertions(+) >>> create mode 100644 >>> meta/recipes-support/libcap-ng/libcap-ng/python.patch >>> create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>> >>> diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>> b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>> new file mode 100644 >>> index 0000000..59591eb >>> --- /dev/null >>> +++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>> @@ -0,0 +1,58 @@ >>> +From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001 >>> +From: Li xin <lixin.fnst@cn.fujitsu.com> >>> +Date: Sat, 18 Jul 2015 23:03:30 +0900 >>> +Subject: [PATCH] configure.ac - Avoid an incorrect check for python. >>> + Makefile.am - avoid hard coded host include paths. >>> + >>> +Upstream-Status: pending >>> + >>> +Signed-off-by: Mark Hatle <mark.hatle@windriver.com> >>> +Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com> >>> +--- >>> + bindings/python/Makefile.am | 3 ++- >>> + configure.ac | 15 ++------------- >>> + 2 files changed, 4 insertions(+), 14 deletions(-) >>> + >>> +diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am >>> +index 82b9bb8..f9fe7a8 100644 >>> +--- a/bindings/python/Makefile.am >>> ++++ b/bindings/python/Makefile.am >>> +@@ -23,7 +23,8 @@ SUBDIRS = test >>> + CONFIG_CLEAN_FILES = *.loT *.rej *.orig >>> + AM_CFLAGS = -fPIC -DPIC >>> + PYLIBVER ?= python$(PYTHON_VERSION) >>> +-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@ >>> ++PYINC ?= /usr/include/$(PYLIBVER) >>> ++AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC) >>> + LIBS = $(top_builddir)/src/libcap-ng.la >>> + SWIG_FLAGS = -python >>> + SWIG_INCLUDES = ${AM_CPPFLAGS} >>> +diff --git a/configure.ac b/configure.ac >>> +index 1d777d5..9d90f64 100644 >>> +--- a/configure.ac >>> ++++ b/configure.ac >>> +@@ -123,19 +123,8 @@ if test x$use_python = xno ; then >>> + else >>> + AC_MSG_RESULT(testing) >>> + AM_PATH_PYTHON >>> +-PYINCLUDEDIR=`python${am_cv_python_version} -c "from distutils import >>> sysconfig; print(sysconfig.get_config_var('INCLUDEPY'))"` >>> +-if test -f ${PYINCLUDEDIR}/Python.h ; then >>> +- python_found="yes" >>> +- AC_SUBST(PYINCLUDEDIR) >>> +- AC_MSG_NOTICE(Python bindings will be built) >>> +-else >>> +- python_found="no" >>> +- if test x$use_python = xyes ; then >>> +- AC_MSG_ERROR([Python explicitly required and python >>> headers found]) >>> +- else >>> +- AC_MSG_WARN("Python headers not found - python bindings >>> will not be made") >>> +- fi >>> +-fi >>> ++python_found="yes" >>> ++AC_MSG_NOTICE(Python bindings will be built) >>> + fi >>> + AM_CONDITIONAL(HAVE_PYTHON, test ${python_found} = "yes") >>> + >>> +-- >>> +1.8.4.2 >>> + >>> diff --git a/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>> b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>> new file mode 100644 >>> index 0000000..a31d5dc >>> --- /dev/null >>> +++ b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>> @@ -0,0 +1,39 @@ >>> +SUMMARY = "An alternate posix capabilities library" >>> +DESCRIPTION = "The libcap-ng library is intended to make programming \ >>> +with POSIX capabilities much easier than the traditional libcap >>> library." >>> +HOMEPAGE = "http://freecode.com/projects/libcap-ng" >>> +SECTION = "base" >>> +LICENSE = "GPLv2+ & LGPLv2.1+" >>> +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f >>> \ >>> + >>> file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06" >>> + >>> +SRC_URI = >>> "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \ >>> + file://python.patch" >>> + >>> +inherit lib_package autotools pythonnative >>> + >>> +SRC_URI[md5sum] = "3d7d126b29e2869a0257c17c8b0d9b2e" >>> +SRC_URI[sha256sum] = >>> "615549ce39b333f6b78baee0c0b4ef18bc726c6bf1cca123dfd89dd963f6d06b" >>> + >>> +DEPENDS += "swig-native python" >>> + >>> +EXTRA_OECONF += "--without-python3" >>> + >>> +EXTRA_OEMAKE += "PYLIBVER='python${PYTHON_BASEVERSION}' >>> PYINC='${STAGING_INCDIR}/${PYLIBVER}'" >>> + >>> +PACKAGES += "${PN}-python" >>> + >>> +FILES_${PN}-dbg += "${libdir}/python${PYTHON_BASEVERSION}/*/.debug" >>> +FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}" >>> + >>> +BBCLASSEXTEND = "native" >>> + >>> +do_install_append() { >>> + # Moving libcap-ng to base_libdir >>> + if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then >>> + mkdir -p ${D}/${base_libdir}/ >>> + mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/ >>> + relpath=${@os.path.relpath("${base_libdir}", >>> "${libdir}")} >>> + ln -sf ${relpath}/libcap-ng.so.0.0.0 >>> ${D}${libdir}/libcap-ng.so >>> + fi >>> +} >>> -- >>> 1.9.1 >>> >>> -- >>> _______________________________________________ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > -- > # Randy MacLeod. SMTS, Linux, Wind River > Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, > K2K 2W5 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2 v2] libcap-ng: add package 0.7.7 2015-08-22 1:14 ` Andre McCurdy @ 2015-08-24 22:30 ` Mark Hatle 2015-08-24 22:53 ` Randy MacLeod 1 sibling, 0 replies; 13+ messages in thread From: Mark Hatle @ 2015-08-24 22:30 UTC (permalink / raw) To: openembedded-core On 8/21/15 8:14 PM, Andre McCurdy wrote: > On Fri, Aug 21, 2015 at 5:55 PM, Randy MacLeod > <randy.macleod@windriver.com> wrote: >> On 2015-08-21 03:25 AM, Khem Raj wrote: >>> >>> On Thu, Aug 20, 2015 at 10:38 PM, <wenzong.fan@windriver.com> wrote: >>>> >>>> From: Wenzong Fan <wenzong.fan@windriver.com> >>>> >>>> Pull package from meta-oe to oe-core: >>>> meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6 >>>> >>>> The libcap-ng library is intended to make programming with posix >>>> capabilities much easier than the traditional libcap library. >>>> >>>> It's not a replacement to libcap, it provides different library >>>> (libcap-ng.so) while packages explicitly look for libcap.so. It >>>> could be used by qemu, util-linux, libvirt, audit ... >>>> >>>> With adding it to oe-core, the copies from following layers could >>>> be removed: >>>> >>>> * meta-oe, meta-selinux, meta-security-framework ... >>> >>> >>> I am afraid that we are setting a pretext for moving all recipes that >>> are in multiple layers to be eligible for OE-core now. >>> meta-oe is common layer for extended recipes, so may be other layers >>> should have been a bit more vigilant and made sure >>> there requirements were met with whats in meta-oe. >> >> >> Meta-oe has far to many recipes for some people to want >> to include the entire layer: >> meta-oe.git $ find meta-oe/ -name "*bb" | wc -l >> 618 > > I typically include most of the meta-oe layers, but I've never really > given much thought to how many recipes there are. > > Is the concern that parsing too many recipes makes bitbake slow? Or is > there another reason why I wouldn't want to include them all? Slow has nothing to do with it. It's purely from a support perspective. If we claim to our customers to support a layer, and don't make it explicit that certain pieces of it are 'unsupported', then we're on the hook for everything. (I'm not singling out meta-oe BTW...) What we want is an easy way for our customers to use meta-oe, but also understand where our product support ends and custom or community support begins. This whitelisting, subsetting, masking, blacklisting, etc are all ways we can accomplish this goal. I don't believe this is unique to my environment, but it's likely more common for OSVs then end device makers. --Mark >> We can certainly use the new whitelist layer filtering to >> get to a smaller collection of recipes but I'd like to suggest we >> need to document and maybe design the layer structure >> a bit more. There are lots of different opinions about >> how to split collections of packages in to different layers so >> unless someone has a dependency-based analysis of all >> pacakges in all layers, I don't see much point in a long >> discussion on this topic. >> >> Has the idea of creating a new meta-openembedded layer >> for widely-used, OS interface libraries been proposed? >> These 80 recipes could be considered for inclusion: >> $ find meta-oe -name "lib*bb" | wc -l >> 80 >> but more consideration is probably needed. >> >> In the short term (oe-core-1.9 (now 2.0), I guess we leave >> things as they are. Sigh... >> >> ../Randy >> >> >> While I'm at it, for reference of layer size: >> >> $ for i in `ls -d meta-*`; do echo -n $i": "; find $i -name "*bb" | wc -l; >> done >> meta-efl: 57 >> meta-filesystems: 16 >> meta-gnome: 82 >> meta-gpe: 5 >> meta-initramfs: 14 >> meta-multimedia: 51 >> meta-networking: 115 >> meta-oe: 618 >> meta-perl: 30 >> meta-python: 74 >> meta-ruby: 4 >> meta-systemd: 1 >> meta-webserver: 13 >> meta-xfce: 67 >> >> ----------------------------------------- >> >> >> >>> we should ask what core feature does it enable for reference images >>> and machines. >>> >>>> >>>> Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com> >>>> --- >>>> .../libcap-ng/libcap-ng/python.patch | 58 >>>> ++++++++++++++++++++++ >>>> meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++++++++++++++ >>>> 2 files changed, 97 insertions(+) >>>> create mode 100644 >>>> meta/recipes-support/libcap-ng/libcap-ng/python.patch >>>> create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>>> >>>> diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>>> b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>>> new file mode 100644 >>>> index 0000000..59591eb >>>> --- /dev/null >>>> +++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>>> @@ -0,0 +1,58 @@ >>>> +From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001 >>>> +From: Li xin <lixin.fnst@cn.fujitsu.com> >>>> +Date: Sat, 18 Jul 2015 23:03:30 +0900 >>>> +Subject: [PATCH] configure.ac - Avoid an incorrect check for python. >>>> + Makefile.am - avoid hard coded host include paths. >>>> + >>>> +Upstream-Status: pending >>>> + >>>> +Signed-off-by: Mark Hatle <mark.hatle@windriver.com> >>>> +Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com> >>>> +--- >>>> + bindings/python/Makefile.am | 3 ++- >>>> + configure.ac | 15 ++------------- >>>> + 2 files changed, 4 insertions(+), 14 deletions(-) >>>> + >>>> +diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am >>>> +index 82b9bb8..f9fe7a8 100644 >>>> +--- a/bindings/python/Makefile.am >>>> ++++ b/bindings/python/Makefile.am >>>> +@@ -23,7 +23,8 @@ SUBDIRS = test >>>> + CONFIG_CLEAN_FILES = *.loT *.rej *.orig >>>> + AM_CFLAGS = -fPIC -DPIC >>>> + PYLIBVER ?= python$(PYTHON_VERSION) >>>> +-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@ >>>> ++PYINC ?= /usr/include/$(PYLIBVER) >>>> ++AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC) >>>> + LIBS = $(top_builddir)/src/libcap-ng.la >>>> + SWIG_FLAGS = -python >>>> + SWIG_INCLUDES = ${AM_CPPFLAGS} >>>> +diff --git a/configure.ac b/configure.ac >>>> +index 1d777d5..9d90f64 100644 >>>> +--- a/configure.ac >>>> ++++ b/configure.ac >>>> +@@ -123,19 +123,8 @@ if test x$use_python = xno ; then >>>> + else >>>> + AC_MSG_RESULT(testing) >>>> + AM_PATH_PYTHON >>>> +-PYINCLUDEDIR=`python${am_cv_python_version} -c "from distutils import >>>> sysconfig; print(sysconfig.get_config_var('INCLUDEPY'))"` >>>> +-if test -f ${PYINCLUDEDIR}/Python.h ; then >>>> +- python_found="yes" >>>> +- AC_SUBST(PYINCLUDEDIR) >>>> +- AC_MSG_NOTICE(Python bindings will be built) >>>> +-else >>>> +- python_found="no" >>>> +- if test x$use_python = xyes ; then >>>> +- AC_MSG_ERROR([Python explicitly required and python >>>> headers found]) >>>> +- else >>>> +- AC_MSG_WARN("Python headers not found - python bindings >>>> will not be made") >>>> +- fi >>>> +-fi >>>> ++python_found="yes" >>>> ++AC_MSG_NOTICE(Python bindings will be built) >>>> + fi >>>> + AM_CONDITIONAL(HAVE_PYTHON, test ${python_found} = "yes") >>>> + >>>> +-- >>>> +1.8.4.2 >>>> + >>>> diff --git a/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>>> b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>>> new file mode 100644 >>>> index 0000000..a31d5dc >>>> --- /dev/null >>>> +++ b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>>> @@ -0,0 +1,39 @@ >>>> +SUMMARY = "An alternate posix capabilities library" >>>> +DESCRIPTION = "The libcap-ng library is intended to make programming \ >>>> +with POSIX capabilities much easier than the traditional libcap >>>> library." >>>> +HOMEPAGE = "http://freecode.com/projects/libcap-ng" >>>> +SECTION = "base" >>>> +LICENSE = "GPLv2+ & LGPLv2.1+" >>>> +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f >>>> \ >>>> + >>>> file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06" >>>> + >>>> +SRC_URI = >>>> "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \ >>>> + file://python.patch" >>>> + >>>> +inherit lib_package autotools pythonnative >>>> + >>>> +SRC_URI[md5sum] = "3d7d126b29e2869a0257c17c8b0d9b2e" >>>> +SRC_URI[sha256sum] = >>>> "615549ce39b333f6b78baee0c0b4ef18bc726c6bf1cca123dfd89dd963f6d06b" >>>> + >>>> +DEPENDS += "swig-native python" >>>> + >>>> +EXTRA_OECONF += "--without-python3" >>>> + >>>> +EXTRA_OEMAKE += "PYLIBVER='python${PYTHON_BASEVERSION}' >>>> PYINC='${STAGING_INCDIR}/${PYLIBVER}'" >>>> + >>>> +PACKAGES += "${PN}-python" >>>> + >>>> +FILES_${PN}-dbg += "${libdir}/python${PYTHON_BASEVERSION}/*/.debug" >>>> +FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}" >>>> + >>>> +BBCLASSEXTEND = "native" >>>> + >>>> +do_install_append() { >>>> + # Moving libcap-ng to base_libdir >>>> + if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then >>>> + mkdir -p ${D}/${base_libdir}/ >>>> + mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/ >>>> + relpath=${@os.path.relpath("${base_libdir}", >>>> "${libdir}")} >>>> + ln -sf ${relpath}/libcap-ng.so.0.0.0 >>>> ${D}${libdir}/libcap-ng.so >>>> + fi >>>> +} >>>> -- >>>> 1.9.1 >>>> >>>> -- >>>> _______________________________________________ >>>> Openembedded-core mailing list >>>> Openembedded-core@lists.openembedded.org >>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> >> >> >> -- >> # Randy MacLeod. SMTS, Linux, Wind River >> Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, >> K2K 2W5 >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2 v2] libcap-ng: add package 0.7.7 2015-08-22 1:14 ` Andre McCurdy 2015-08-24 22:30 ` Mark Hatle @ 2015-08-24 22:53 ` Randy MacLeod 2015-08-24 23:48 ` Khem Raj 1 sibling, 1 reply; 13+ messages in thread From: Randy MacLeod @ 2015-08-24 22:53 UTC (permalink / raw) To: Patches and discussions about the oe-core layer, armccurdy [-- Attachment #1: Type: text/plain, Size: 10362 bytes --] On 2015-08-21 09:14 PM, Andre McCurdy wrote:> On Fri, Aug 21, 2015 at 5:55 PM, Randy MacLeod > <randy.macleod@windriver.com> wrote: >> On 2015-08-21 03:25 AM, Khem Raj wrote: >>> >>> On Thu, Aug 20, 2015 at 10:38 PM, <wenzong.fan@windriver.com> wrote: >>>> >>>> From: Wenzong Fan <wenzong.fan@windriver.com> >>>> >>>> Pull package from meta-oe to oe-core: >>>> meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6 >>>> >>>> The libcap-ng library is intended to make programming with posix >>>> capabilities much easier than the traditional libcap library. >>>> >>>> It's not a replacement to libcap, it provides different library >>>> (libcap-ng.so) while packages explicitly look for libcap.so. It >>>> could be used by qemu, util-linux, libvirt, audit ... >>>> >>>> With adding it to oe-core, the copies from following layers could >>>> be removed: >>>> >>>> * meta-oe, meta-selinux, meta-security-framework ... >>> >>> >>> I am afraid that we are setting a pretext for moving all recipes that >>> are in multiple layers to be eligible for OE-core now. >>> meta-oe is common layer for extended recipes, so may be other layers >>> should have been a bit more vigilant and made sure >>> there requirements were met with whats in meta-oe. >> >> >> Meta-oe has far to many recipes for some people to want >> to include the entire layer: >> meta-oe.git $ find meta-oe/ -name "*bb" | wc -l >> 618 > > I typically include most of the meta-oe layers, but I've never really > given much thought to how many recipes there are. > > Is the concern that parsing too many recipes makes bitbake slow? Or is Parsing time and probably memory used scale ~ linearly with the number of recipes, so that's a *bit* of a concern especially since it's > 500 additional recipes or an increase of > 25% for our distro but it's not the top issue. > there another reason why I wouldn't want to include them all? As Mark said, it's a business decision. There are (probably more than linear) engineering costs to adding a recipe to a distribution. That's why we were using the meta-FOO-subset approach. Of course, personally I'd like to provide the full set of meta-openembedded layers and more! We might be able to support all of meta-openembedded at some point but I don't think it's the right decision now. ../Randy > >> We can certainly use the new whitelist layer filtering to >> get to a smaller collection of recipes but I'd like to suggest we >> need to document and maybe design the layer structure >> a bit more. There are lots of different opinions about >> how to split collections of packages in to different layers so >> unless someone has a dependency-based analysis of all >> pacakges in all layers, I don't see much point in a long >> discussion on this topic. >> >> Has the idea of creating a new meta-openembedded layer >> for widely-used, OS interface libraries been proposed? >> These 80 recipes could be considered for inclusion: >> $ find meta-oe -name "lib*bb" | wc -l >> 80 >> but more consideration is probably needed. >> >> In the short term (oe-core-1.9 (now 2.0), I guess we leave >> things as they are. Sigh... >> >> ../Randy >> >> >> While I'm at it, for reference of layer size: >> >> $ for i in `ls -d meta-*`; do echo -n $i": "; find $i -name "*bb" | wc -l; >> done >> meta-efl: 57 >> meta-filesystems: 16 >> meta-gnome: 82 >> meta-gpe: 5 >> meta-initramfs: 14 >> meta-multimedia: 51 >> meta-networking: 115 >> meta-oe: 618 >> meta-perl: 30 >> meta-python: 74 >> meta-ruby: 4 >> meta-systemd: 1 >> meta-webserver: 13 >> meta-xfce: 67 >> >> ----------------------------------------- >> >> >> >>> we should ask what core feature does it enable for reference images >>> and machines. >>> >>>> >>>> Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com> >>>> --- >>>> .../libcap-ng/libcap-ng/python.patch | 58 >>>> ++++++++++++++++++++++ >>>> meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++++++++++++++ >>>> 2 files changed, 97 insertions(+) >>>> create mode 100644 >>>> meta/recipes-support/libcap-ng/libcap-ng/python.patch >>>> create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>>> >>>> diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>>> b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>>> new file mode 100644 >>>> index 0000000..59591eb >>>> --- /dev/null >>>> +++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>>> @@ -0,0 +1,58 @@ >>>> +From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001 >>>> +From: Li xin <lixin.fnst@cn.fujitsu.com> >>>> +Date: Sat, 18 Jul 2015 23:03:30 +0900 >>>> +Subject: [PATCH] configure.ac - Avoid an incorrect check for python. >>>> + Makefile.am - avoid hard coded host include paths. >>>> + >>>> +Upstream-Status: pending >>>> + >>>> +Signed-off-by: Mark Hatle <mark.hatle@windriver.com> >>>> +Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com> >>>> +--- >>>> + bindings/python/Makefile.am | 3 ++- >>>> + configure.ac | 15 ++------------- >>>> + 2 files changed, 4 insertions(+), 14 deletions(-) >>>> + >>>> +diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am >>>> +index 82b9bb8..f9fe7a8 100644 >>>> +--- a/bindings/python/Makefile.am >>>> ++++ b/bindings/python/Makefile.am >>>> +@@ -23,7 +23,8 @@ SUBDIRS = test >>>> + CONFIG_CLEAN_FILES = *.loT *.rej *.orig >>>> + AM_CFLAGS = -fPIC -DPIC >>>> + PYLIBVER ?= python$(PYTHON_VERSION) >>>> +-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@ >>>> ++PYINC ?= /usr/include/$(PYLIBVER) >>>> ++AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC) >>>> + LIBS = $(top_builddir)/src/libcap-ng.la >>>> + SWIG_FLAGS = -python >>>> + SWIG_INCLUDES = ${AM_CPPFLAGS} >>>> +diff --git a/configure.ac b/configure.ac >>>> +index 1d777d5..9d90f64 100644 >>>> +--- a/configure.ac >>>> ++++ b/configure.ac >>>> +@@ -123,19 +123,8 @@ if test x$use_python = xno ; then >>>> + else >>>> + AC_MSG_RESULT(testing) >>>> + AM_PATH_PYTHON >>>> +-PYINCLUDEDIR=`python${am_cv_python_version} -c "from distutils import >>>> sysconfig; print(sysconfig.get_config_var('INCLUDEPY'))"` >>>> +-if test -f ${PYINCLUDEDIR}/Python.h ; then >>>> +- python_found="yes" >>>> +- AC_SUBST(PYINCLUDEDIR) >>>> +- AC_MSG_NOTICE(Python bindings will be built) >>>> +-else >>>> +- python_found="no" >>>> +- if test x$use_python = xyes ; then >>>> +- AC_MSG_ERROR([Python explicitly required and python >>>> headers found]) >>>> +- else >>>> +- AC_MSG_WARN("Python headers not found - python bindings >>>> will not be made") >>>> +- fi >>>> +-fi >>>> ++python_found="yes" >>>> ++AC_MSG_NOTICE(Python bindings will be built) >>>> + fi >>>> + AM_CONDITIONAL(HAVE_PYTHON, test ${python_found} = "yes") >>>> + >>>> +-- >>>> +1.8.4.2 >>>> + >>>> diff --git a/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>>> b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>>> new file mode 100644 >>>> index 0000000..a31d5dc >>>> --- /dev/null >>>> +++ b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>>> @@ -0,0 +1,39 @@ >>>> +SUMMARY = "An alternate posix capabilities library" >>>> +DESCRIPTION = "The libcap-ng library is intended to make programming \ >>>> +with POSIX capabilities much easier than the traditional libcap >>>> library." >>>> +HOMEPAGE = "http://freecode.com/projects/libcap-ng" >>>> +SECTION = "base" >>>> +LICENSE = "GPLv2+ & LGPLv2.1+" >>>> +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f >>>> \ >>>> + >>>> file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06" >>>> + >>>> +SRC_URI = >>>> "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \ >>>> + file://python.patch" >>>> + >>>> +inherit lib_package autotools pythonnative >>>> + >>>> +SRC_URI[md5sum] = "3d7d126b29e2869a0257c17c8b0d9b2e" >>>> +SRC_URI[sha256sum] = >>>> "615549ce39b333f6b78baee0c0b4ef18bc726c6bf1cca123dfd89dd963f6d06b" >>>> + >>>> +DEPENDS += "swig-native python" >>>> + >>>> +EXTRA_OECONF += "--without-python3" >>>> + >>>> +EXTRA_OEMAKE += "PYLIBVER='python${PYTHON_BASEVERSION}' >>>> PYINC='${STAGING_INCDIR}/${PYLIBVER}'" >>>> + >>>> +PACKAGES += "${PN}-python" >>>> + >>>> +FILES_${PN}-dbg += "${libdir}/python${PYTHON_BASEVERSION}/*/.debug" >>>> +FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}" >>>> + >>>> +BBCLASSEXTEND = "native" >>>> + >>>> +do_install_append() { >>>> + # Moving libcap-ng to base_libdir >>>> + if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then >>>> + mkdir -p ${D}/${base_libdir}/ >>>> + mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/ >>>> + relpath=${@os.path.relpath("${base_libdir}", >>>> "${libdir}")} >>>> + ln -sf ${relpath}/libcap-ng.so.0.0.0 >>>> ${D}${libdir}/libcap-ng.so >>>> + fi >>>> +} >>>> -- >>>> 1.9.1 >>>> >>>> -- >>>> _______________________________________________ >>>> Openembedded-core mailing list >>>> Openembedded-core@lists.openembedded.org >>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> >> >> >> -- >> # Randy MacLeod. SMTS, Linux, Wind River >> Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, >> K2K 2W5 >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 [-- Attachment #2: Re: [OE-core] [PATCH 2/2 v2] libcap-ng: add package 0_7_7.eml --] [-- Type: message/rfc822, Size: 12195 bytes --] From: Andre McCurdy <armccurdy@gmail.com> To: Randy MacLeod <randy.macleod@windriver.com> Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>, Khem Raj <raj.khem@gmail.com>, Wenzong Fan <wenzong.fan@windriver.com> Subject: Re: [OE-core] [PATCH 2/2 v2] libcap-ng: add package 0.7.7 Date: Fri, 21 Aug 2015 18:14:04 -0700 Message-ID: <CAJ86T=U8Gw5RcJz8RNzH=8MNbxHVHGJgdZd3N+pvdLCVdH+yXw@mail.gmail.com> On Fri, Aug 21, 2015 at 5:55 PM, Randy MacLeod <randy.macleod@windriver.com> wrote: > On 2015-08-21 03:25 AM, Khem Raj wrote: >> >> On Thu, Aug 20, 2015 at 10:38 PM, <wenzong.fan@windriver.com> wrote: >>> >>> From: Wenzong Fan <wenzong.fan@windriver.com> >>> >>> Pull package from meta-oe to oe-core: >>> meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6 >>> >>> The libcap-ng library is intended to make programming with posix >>> capabilities much easier than the traditional libcap library. >>> >>> It's not a replacement to libcap, it provides different library >>> (libcap-ng.so) while packages explicitly look for libcap.so. It >>> could be used by qemu, util-linux, libvirt, audit ... >>> >>> With adding it to oe-core, the copies from following layers could >>> be removed: >>> >>> * meta-oe, meta-selinux, meta-security-framework ... >> >> >> I am afraid that we are setting a pretext for moving all recipes that >> are in multiple layers to be eligible for OE-core now. >> meta-oe is common layer for extended recipes, so may be other layers >> should have been a bit more vigilant and made sure >> there requirements were met with whats in meta-oe. > > > Meta-oe has far to many recipes for some people to want > to include the entire layer: > meta-oe.git $ find meta-oe/ -name "*bb" | wc -l > 618 I typically include most of the meta-oe layers, but I've never really given much thought to how many recipes there are. Is the concern that parsing too many recipes makes bitbake slow? Or is there another reason why I wouldn't want to include them all? > We can certainly use the new whitelist layer filtering to > get to a smaller collection of recipes but I'd like to suggest we > need to document and maybe design the layer structure > a bit more. There are lots of different opinions about > how to split collections of packages in to different layers so > unless someone has a dependency-based analysis of all > pacakges in all layers, I don't see much point in a long > discussion on this topic. > > Has the idea of creating a new meta-openembedded layer > for widely-used, OS interface libraries been proposed? > These 80 recipes could be considered for inclusion: > $ find meta-oe -name "lib*bb" | wc -l > 80 > but more consideration is probably needed. > > In the short term (oe-core-1.9 (now 2.0), I guess we leave > things as they are. Sigh... > > ../Randy > > > While I'm at it, for reference of layer size: > > $ for i in `ls -d meta-*`; do echo -n $i": "; find $i -name "*bb" | wc -l; > done > meta-efl: 57 > meta-filesystems: 16 > meta-gnome: 82 > meta-gpe: 5 > meta-initramfs: 14 > meta-multimedia: 51 > meta-networking: 115 > meta-oe: 618 > meta-perl: 30 > meta-python: 74 > meta-ruby: 4 > meta-systemd: 1 > meta-webserver: 13 > meta-xfce: 67 > > ----------------------------------------- > > > >> we should ask what core feature does it enable for reference images >> and machines. >> >>> >>> Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com> >>> --- >>> .../libcap-ng/libcap-ng/python.patch | 58 >>> ++++++++++++++++++++++ >>> meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++++++++++++++ >>> 2 files changed, 97 insertions(+) >>> create mode 100644 >>> meta/recipes-support/libcap-ng/libcap-ng/python.patch >>> create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>> >>> diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>> b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>> new file mode 100644 >>> index 0000000..59591eb >>> --- /dev/null >>> +++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>> @@ -0,0 +1,58 @@ >>> +From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001 >>> +From: Li xin <lixin.fnst@cn.fujitsu.com> >>> +Date: Sat, 18 Jul 2015 23:03:30 +0900 >>> +Subject: [PATCH] configure.ac - Avoid an incorrect check for python. >>> + Makefile.am - avoid hard coded host include paths. >>> + >>> +Upstream-Status: pending >>> + >>> +Signed-off-by: Mark Hatle <mark.hatle@windriver.com> >>> +Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com> >>> +--- >>> + bindings/python/Makefile.am | 3 ++- >>> + configure.ac | 15 ++------------- >>> + 2 files changed, 4 insertions(+), 14 deletions(-) >>> + >>> +diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am >>> +index 82b9bb8..f9fe7a8 100644 >>> +--- a/bindings/python/Makefile.am >>> ++++ b/bindings/python/Makefile.am >>> +@@ -23,7 +23,8 @@ SUBDIRS = test >>> + CONFIG_CLEAN_FILES = *.loT *.rej *.orig >>> + AM_CFLAGS = -fPIC -DPIC >>> + PYLIBVER ?= python$(PYTHON_VERSION) >>> +-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@ >>> ++PYINC ?= /usr/include/$(PYLIBVER) >>> ++AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC) >>> + LIBS = $(top_builddir)/src/libcap-ng.la >>> + SWIG_FLAGS = -python >>> + SWIG_INCLUDES = ${AM_CPPFLAGS} >>> +diff --git a/configure.ac b/configure.ac >>> +index 1d777d5..9d90f64 100644 >>> +--- a/configure.ac >>> ++++ b/configure.ac >>> +@@ -123,19 +123,8 @@ if test x$use_python = xno ; then >>> + else >>> + AC_MSG_RESULT(testing) >>> + AM_PATH_PYTHON >>> +-PYINCLUDEDIR=`python${am_cv_python_version} -c "from distutils import >>> sysconfig; print(sysconfig.get_config_var('INCLUDEPY'))"` >>> +-if test -f ${PYINCLUDEDIR}/Python.h ; then >>> +- python_found="yes" >>> +- AC_SUBST(PYINCLUDEDIR) >>> +- AC_MSG_NOTICE(Python bindings will be built) >>> +-else >>> +- python_found="no" >>> +- if test x$use_python = xyes ; then >>> +- AC_MSG_ERROR([Python explicitly required and python >>> headers found]) >>> +- else >>> +- AC_MSG_WARN("Python headers not found - python bindings >>> will not be made") >>> +- fi >>> +-fi >>> ++python_found="yes" >>> ++AC_MSG_NOTICE(Python bindings will be built) >>> + fi >>> + AM_CONDITIONAL(HAVE_PYTHON, test ${python_found} = "yes") >>> + >>> +-- >>> +1.8.4.2 >>> + >>> diff --git a/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>> b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>> new file mode 100644 >>> index 0000000..a31d5dc >>> --- /dev/null >>> +++ b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>> @@ -0,0 +1,39 @@ >>> +SUMMARY = "An alternate posix capabilities library" >>> +DESCRIPTION = "The libcap-ng library is intended to make programming \ >>> +with POSIX capabilities much easier than the traditional libcap >>> library." >>> +HOMEPAGE = "http://freecode.com/projects/libcap-ng" >>> +SECTION = "base" >>> +LICENSE = "GPLv2+ & LGPLv2.1+" >>> +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f >>> \ >>> + >>> file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06" >>> + >>> +SRC_URI = >>> "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \ >>> + file://python.patch" >>> + >>> +inherit lib_package autotools pythonnative >>> + >>> +SRC_URI[md5sum] = "3d7d126b29e2869a0257c17c8b0d9b2e" >>> +SRC_URI[sha256sum] = >>> "615549ce39b333f6b78baee0c0b4ef18bc726c6bf1cca123dfd89dd963f6d06b" >>> + >>> +DEPENDS += "swig-native python" >>> + >>> +EXTRA_OECONF += "--without-python3" >>> + >>> +EXTRA_OEMAKE += "PYLIBVER='python${PYTHON_BASEVERSION}' >>> PYINC='${STAGING_INCDIR}/${PYLIBVER}'" >>> + >>> +PACKAGES += "${PN}-python" >>> + >>> +FILES_${PN}-dbg += "${libdir}/python${PYTHON_BASEVERSION}/*/.debug" >>> +FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}" >>> + >>> +BBCLASSEXTEND = "native" >>> + >>> +do_install_append() { >>> + # Moving libcap-ng to base_libdir >>> + if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then >>> + mkdir -p ${D}/${base_libdir}/ >>> + mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/ >>> + relpath=${@os.path.relpath("${base_libdir}", >>> "${libdir}")} >>> + ln -sf ${relpath}/libcap-ng.so.0.0.0 >>> ${D}${libdir}/libcap-ng.so >>> + fi >>> +} >>> -- >>> 1.9.1 >>> >>> -- >>> _______________________________________________ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > -- > # Randy MacLeod. SMTS, Linux, Wind River > Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, > K2K 2W5 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2 v2] libcap-ng: add package 0.7.7 2015-08-24 22:53 ` Randy MacLeod @ 2015-08-24 23:48 ` Khem Raj 0 siblings, 0 replies; 13+ messages in thread From: Khem Raj @ 2015-08-24 23:48 UTC (permalink / raw) To: Randy MacLeod; +Cc: Patches and discussions about the oe-core layer On Mon, Aug 24, 2015 at 3:53 PM, Randy MacLeod <randy.macleod@windriver.com> wrote: > Parsing time and probably memory used scale ~ linearly with the number > of recipes, so that's a *bit* of a concern especially since it's > > 500 additional recipes or an increase of > 25% for our distro > but it's not the top issue. > > > there another reason why I wouldn't want to include them all? > > As Mark said, it's a business decision. > > There are (probably more than linear) engineering costs to > adding a recipe to a distribution. That's why we were using > the meta-FOO-subset approach. > > Of course, personally I'd like to provide the full set of > meta-openembedded layers and more! We might be able to support > all of meta-openembedded at some point but I don't think it's > the right decision now. Its fine, and you are free to do whatever you wish to in your fork. Its when these policies start to shape up layers, that's when we have to be vigilant and thats the point I have been raising. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2 v2] libcap-ng: add package 0.7.7 2015-08-22 0:55 ` Randy MacLeod 2015-08-22 1:14 ` Andre McCurdy @ 2015-08-22 1:36 ` Khem Raj 1 sibling, 0 replies; 13+ messages in thread From: Khem Raj @ 2015-08-22 1:36 UTC (permalink / raw) To: Randy MacLeod; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 9018 bytes --] > On Aug 21, 2015, at 5:55 PM, Randy MacLeod <randy.macleod@windriver.com> wrote: > > On 2015-08-21 03:25 AM, Khem Raj wrote: >> On Thu, Aug 20, 2015 at 10:38 PM, <wenzong.fan@windriver.com> wrote: >>> From: Wenzong Fan <wenzong.fan@windriver.com> >>> >>> Pull package from meta-oe to oe-core: >>> meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6 >>> >>> The libcap-ng library is intended to make programming with posix >>> capabilities much easier than the traditional libcap library. >>> >>> It's not a replacement to libcap, it provides different library >>> (libcap-ng.so) while packages explicitly look for libcap.so. It >>> could be used by qemu, util-linux, libvirt, audit ... >>> >>> With adding it to oe-core, the copies from following layers could >>> be removed: >>> >>> * meta-oe, meta-selinux, meta-security-framework ... >> >> I am afraid that we are setting a pretext for moving all recipes that >> are in multiple layers to be eligible for OE-core now. >> meta-oe is common layer for extended recipes, so may be other layers >> should have been a bit more vigilant and made sure >> there requirements were met with whats in meta-oe. > > Meta-oe has far to many recipes for some people to want > to include the entire layer: > meta-oe.git $ find meta-oe/ -name "*bb" | wc -l > 618 > We can certainly use the new whitelist layer filtering to > get to a smaller collection of recipes but I'd like to suggest we > need to document and maybe design the layer structure > a bit more. There are lots of different opinions about > how to split collections of packages in to different layers so > unless someone has a dependency-based analysis of all > pacakges in all layers, I don't see much point in a long > discussion on this topic. if someone wants to ignore certain recipes use BBMASK, I do not think this whitelisting is a good idea, it does not help in maintaining layer quality, and its much better that we maintained layers in good quality collectively may be with some extra recipes in it instead of cannibalizing few recipes from it into private layers or other layer which one happens to use. It seriously dents the layers user base and quality. If meta-oe hosts certain layers that could be a fit in another middleware or topic layer, lets move it to that layer but lets not encourage the behavior of duplicating the recipes or severely crippling the layer before using it. > > Has the idea of creating a new meta-openembedded layer > for widely-used, OS interface libraries been proposed? > These 80 recipes could be considered for inclusion: > $ find meta-oe -name "lib*bb" | wc -l > 80 > but more consideration is probably needed. > > In the short term (oe-core-1.9 (now 2.0), I guess we leave > things as they are. Sigh… number of layers is a delicate balance too. The more you divide them more smaller the userbase will become and complex becomes the distros. > > ../Randy > > > While I'm at it, for reference of layer size: > > $ for i in `ls -d meta-*`; do echo -n $i": "; find $i -name "*bb" | wc -l; done > meta-efl: 57 > meta-filesystems: 16 > meta-gnome: 82 > meta-gpe: 5 > meta-initramfs: 14 > meta-multimedia: 51 > meta-networking: 115 > meta-oe: 618 > meta-perl: 30 > meta-python: 74 > meta-ruby: 4 > meta-systemd: 1 > meta-webserver: 13 > meta-xfce: 67 > > ----------------------------------------- > > >> we should ask what core feature does it enable for reference images >> and machines. >> >>> >>> Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com> >>> --- >>> .../libcap-ng/libcap-ng/python.patch | 58 ++++++++++++++++++++++ >>> meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++++++++++++++ >>> 2 files changed, 97 insertions(+) >>> create mode 100644 meta/recipes-support/libcap-ng/libcap-ng/python.patch >>> create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>> >>> diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>> new file mode 100644 >>> index 0000000..59591eb >>> --- /dev/null >>> +++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >>> @@ -0,0 +1,58 @@ >>> +From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001 >>> +From: Li xin <lixin.fnst@cn.fujitsu.com> >>> +Date: Sat, 18 Jul 2015 23:03:30 +0900 >>> +Subject: [PATCH] configure.ac - Avoid an incorrect check for python. >>> + Makefile.am - avoid hard coded host include paths. >>> + >>> +Upstream-Status: pending >>> + >>> +Signed-off-by: Mark Hatle <mark.hatle@windriver.com> >>> +Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com> >>> +--- >>> + bindings/python/Makefile.am | 3 ++- >>> + configure.ac | 15 ++------------- >>> + 2 files changed, 4 insertions(+), 14 deletions(-) >>> + >>> +diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am >>> +index 82b9bb8..f9fe7a8 100644 >>> +--- a/bindings/python/Makefile.am >>> ++++ b/bindings/python/Makefile.am >>> +@@ -23,7 +23,8 @@ SUBDIRS = test >>> + CONFIG_CLEAN_FILES = *.loT *.rej *.orig >>> + AM_CFLAGS = -fPIC -DPIC >>> + PYLIBVER ?= python$(PYTHON_VERSION) >>> +-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@ >>> ++PYINC ?= /usr/include/$(PYLIBVER) >>> ++AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC) >>> + LIBS = $(top_builddir)/src/libcap-ng.la >>> + SWIG_FLAGS = -python >>> + SWIG_INCLUDES = ${AM_CPPFLAGS} >>> +diff --git a/configure.ac b/configure.ac >>> +index 1d777d5..9d90f64 100644 >>> +--- a/configure.ac >>> ++++ b/configure.ac >>> +@@ -123,19 +123,8 @@ if test x$use_python = xno ; then >>> + else >>> + AC_MSG_RESULT(testing) >>> + AM_PATH_PYTHON >>> +-PYINCLUDEDIR=`python${am_cv_python_version} -c "from distutils import sysconfig; print(sysconfig.get_config_var('INCLUDEPY'))"` >>> +-if test -f ${PYINCLUDEDIR}/Python.h ; then >>> +- python_found="yes" >>> +- AC_SUBST(PYINCLUDEDIR) >>> +- AC_MSG_NOTICE(Python bindings will be built) >>> +-else >>> +- python_found="no" >>> +- if test x$use_python = xyes ; then >>> +- AC_MSG_ERROR([Python explicitly required and python headers found]) >>> +- else >>> +- AC_MSG_WARN("Python headers not found - python bindings will not be made") >>> +- fi >>> +-fi >>> ++python_found="yes" >>> ++AC_MSG_NOTICE(Python bindings will be built) >>> + fi >>> + AM_CONDITIONAL(HAVE_PYTHON, test ${python_found} = "yes") >>> + >>> +-- >>> +1.8.4.2 >>> + >>> diff --git a/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>> new file mode 100644 >>> index 0000000..a31d5dc >>> --- /dev/null >>> +++ b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >>> @@ -0,0 +1,39 @@ >>> +SUMMARY = "An alternate posix capabilities library" >>> +DESCRIPTION = "The libcap-ng library is intended to make programming \ >>> +with POSIX capabilities much easier than the traditional libcap library." >>> +HOMEPAGE = "http://freecode.com/projects/libcap-ng" >>> +SECTION = "base" >>> +LICENSE = "GPLv2+ & LGPLv2.1+" >>> +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ >>> + file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06" >>> + >>> +SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \ >>> + file://python.patch" >>> + >>> +inherit lib_package autotools pythonnative >>> + >>> +SRC_URI[md5sum] = "3d7d126b29e2869a0257c17c8b0d9b2e" >>> +SRC_URI[sha256sum] = "615549ce39b333f6b78baee0c0b4ef18bc726c6bf1cca123dfd89dd963f6d06b" >>> + >>> +DEPENDS += "swig-native python" >>> + >>> +EXTRA_OECONF += "--without-python3" >>> + >>> +EXTRA_OEMAKE += "PYLIBVER='python${PYTHON_BASEVERSION}' PYINC='${STAGING_INCDIR}/${PYLIBVER}'" >>> + >>> +PACKAGES += "${PN}-python" >>> + >>> +FILES_${PN}-dbg += "${libdir}/python${PYTHON_BASEVERSION}/*/.debug" >>> +FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}" >>> + >>> +BBCLASSEXTEND = "native" >>> + >>> +do_install_append() { >>> + # Moving libcap-ng to base_libdir >>> + if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then >>> + mkdir -p ${D}/${base_libdir}/ >>> + mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/ >>> + relpath=${@os.path.relpath("${base_libdir}", "${libdir}")} >>> + ln -sf ${relpath}/libcap-ng.so.0.0.0 ${D}${libdir}/libcap-ng.so >>> + fi >>> +} >>> -- >>> 1.9.1 >>> >>> -- >>> _______________________________________________ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > -- > # Randy MacLeod. SMTS, Linux, Wind River > Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 211 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2 v2] libcap-ng: add package 0.7.7 2015-08-21 7:25 ` Khem Raj 2015-08-22 0:55 ` Randy MacLeod @ 2015-08-24 22:27 ` Mark Hatle 2015-08-24 23:41 ` Khem Raj 1 sibling, 1 reply; 13+ messages in thread From: Mark Hatle @ 2015-08-24 22:27 UTC (permalink / raw) To: openembedded-core On 8/21/15 2:25 AM, Khem Raj wrote: > On Thu, Aug 20, 2015 at 10:38 PM, <wenzong.fan@windriver.com> wrote: >> From: Wenzong Fan <wenzong.fan@windriver.com> >> >> Pull package from meta-oe to oe-core: >> meta-oe commit: bce4dba5546480c8e43c6442959ac7d0a4ef32f6 >> >> The libcap-ng library is intended to make programming with posix >> capabilities much easier than the traditional libcap library. >> >> It's not a replacement to libcap, it provides different library >> (libcap-ng.so) while packages explicitly look for libcap.so. It >> could be used by qemu, util-linux, libvirt, audit ... >> >> With adding it to oe-core, the copies from following layers could >> be removed: >> >> * meta-oe, meta-selinux, meta-security-framework ... > > I am afraid that we are setting a pretext for moving all recipes that > are in multiple layers to be eligible for OE-core now. > met-oe is common layer for extended recipes, so may be other layers > should have been a bit more vigilant and made sure > there requirements were met with whats in meta-oe. > we should ask what core feature does it enable for reference images > and machines. I agree BTW that it's the wrong answer to say since it's used in multiple places that it belongs in oe-core. HOWEVER, in this case, I think the use in multiple places is a reasonable justification that it's a commonly used, and potentially core component. Add that that it's implementing posix capabilities.. and I do think it's reasonable to put this -one- in oe-core. (The key to this, as always, is that these things need to be looked at individually to see if it's reasonable.) Anyway, this ONE has my vote to go into oe-core, based on the usage patterns I routinely see.. and that fact that I believe we have people willing to step in and upgrade/maintain it moving forward. --Mark >> >> Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com> >> --- >> .../libcap-ng/libcap-ng/python.patch | 58 ++++++++++++++++++++++ >> meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb | 39 +++++++++++++++ >> 2 files changed, 97 insertions(+) >> create mode 100644 meta/recipes-support/libcap-ng/libcap-ng/python.patch >> create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >> >> diff --git a/meta/recipes-support/libcap-ng/libcap-ng/python.patch b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >> new file mode 100644 >> index 0000000..59591eb >> --- /dev/null >> +++ b/meta/recipes-support/libcap-ng/libcap-ng/python.patch >> @@ -0,0 +1,58 @@ >> +From b01bb2694f66cd981e6d61523433dc3eb5ed32f2 Mon Sep 17 00:00:00 2001 >> +From: Li xin <lixin.fnst@cn.fujitsu.com> >> +Date: Sat, 18 Jul 2015 23:03:30 +0900 >> +Subject: [PATCH] configure.ac - Avoid an incorrect check for python. >> + Makefile.am - avoid hard coded host include paths. >> + >> +Upstream-Status: pending >> + >> +Signed-off-by: Mark Hatle <mark.hatle@windriver.com> >> +Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com> >> +--- >> + bindings/python/Makefile.am | 3 ++- >> + configure.ac | 15 ++------------- >> + 2 files changed, 4 insertions(+), 14 deletions(-) >> + >> +diff --git a/bindings/python/Makefile.am b/bindings/python/Makefile.am >> +index 82b9bb8..f9fe7a8 100644 >> +--- a/bindings/python/Makefile.am >> ++++ b/bindings/python/Makefile.am >> +@@ -23,7 +23,8 @@ SUBDIRS = test >> + CONFIG_CLEAN_FILES = *.loT *.rej *.orig >> + AM_CFLAGS = -fPIC -DPIC >> + PYLIBVER ?= python$(PYTHON_VERSION) >> +-AM_CPPFLAGS = -I. -I$(top_builddir) -I@PYINCLUDEDIR@ >> ++PYINC ?= /usr/include/$(PYLIBVER) >> ++AM_CPPFLAGS = -I. -I$(top_builddir) -I$(PYINC) >> + LIBS = $(top_builddir)/src/libcap-ng.la >> + SWIG_FLAGS = -python >> + SWIG_INCLUDES = ${AM_CPPFLAGS} >> +diff --git a/configure.ac b/configure.ac >> +index 1d777d5..9d90f64 100644 >> +--- a/configure.ac >> ++++ b/configure.ac >> +@@ -123,19 +123,8 @@ if test x$use_python = xno ; then >> + else >> + AC_MSG_RESULT(testing) >> + AM_PATH_PYTHON >> +-PYINCLUDEDIR=`python${am_cv_python_version} -c "from distutils import sysconfig; print(sysconfig.get_config_var('INCLUDEPY'))"` >> +-if test -f ${PYINCLUDEDIR}/Python.h ; then >> +- python_found="yes" >> +- AC_SUBST(PYINCLUDEDIR) >> +- AC_MSG_NOTICE(Python bindings will be built) >> +-else >> +- python_found="no" >> +- if test x$use_python = xyes ; then >> +- AC_MSG_ERROR([Python explicitly required and python headers found]) >> +- else >> +- AC_MSG_WARN("Python headers not found - python bindings will not be made") >> +- fi >> +-fi >> ++python_found="yes" >> ++AC_MSG_NOTICE(Python bindings will be built) >> + fi >> + AM_CONDITIONAL(HAVE_PYTHON, test ${python_found} = "yes") >> + >> +-- >> +1.8.4.2 >> + >> diff --git a/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >> new file mode 100644 >> index 0000000..a31d5dc >> --- /dev/null >> +++ b/meta/recipes-support/libcap-ng/libcap-ng_0.7.7.bb >> @@ -0,0 +1,39 @@ >> +SUMMARY = "An alternate posix capabilities library" >> +DESCRIPTION = "The libcap-ng library is intended to make programming \ >> +with POSIX capabilities much easier than the traditional libcap library." >> +HOMEPAGE = "http://freecode.com/projects/libcap-ng" >> +SECTION = "base" >> +LICENSE = "GPLv2+ & LGPLv2.1+" >> +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ >> + file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06" >> + >> +SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \ >> + file://python.patch" >> + >> +inherit lib_package autotools pythonnative >> + >> +SRC_URI[md5sum] = "3d7d126b29e2869a0257c17c8b0d9b2e" >> +SRC_URI[sha256sum] = "615549ce39b333f6b78baee0c0b4ef18bc726c6bf1cca123dfd89dd963f6d06b" >> + >> +DEPENDS += "swig-native python" >> + >> +EXTRA_OECONF += "--without-python3" >> + >> +EXTRA_OEMAKE += "PYLIBVER='python${PYTHON_BASEVERSION}' PYINC='${STAGING_INCDIR}/${PYLIBVER}'" >> + >> +PACKAGES += "${PN}-python" >> + >> +FILES_${PN}-dbg += "${libdir}/python${PYTHON_BASEVERSION}/*/.debug" >> +FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}" >> + >> +BBCLASSEXTEND = "native" >> + >> +do_install_append() { >> + # Moving libcap-ng to base_libdir >> + if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then >> + mkdir -p ${D}/${base_libdir}/ >> + mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/ >> + relpath=${@os.path.relpath("${base_libdir}", "${libdir}")} >> + ln -sf ${relpath}/libcap-ng.so.0.0.0 ${D}${libdir}/libcap-ng.so >> + fi >> +} >> -- >> 1.9.1 >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2 v2] libcap-ng: add package 0.7.7 2015-08-24 22:27 ` Mark Hatle @ 2015-08-24 23:41 ` Khem Raj 2015-08-25 13:21 ` Mark Hatle 0 siblings, 1 reply; 13+ messages in thread From: Khem Raj @ 2015-08-24 23:41 UTC (permalink / raw) To: Mark Hatle; +Cc: Patches and discussions about the oe-core layer On Mon, Aug 24, 2015 at 3:27 PM, Mark Hatle <mark.hatle@windriver.com> wrote: > I agree BTW that it's the wrong answer to say since it's used in multiple places > that it belongs in oe-core. > > HOWEVER, in this case, I think the use in multiple places is a reasonable > justification that it's a commonly used, and potentially core component. > > Add that that it's implementing posix capabilities.. and I do think it's > reasonable to put this -one- in oe-core. (The key to this, as always, is that > these things need to be looked at individually to see if it's reasonable.) > > Anyway, this ONE has my vote to go into oe-core, based on the usage patterns I > routinely see.. and that fact that I believe we have people willing to step in > and upgrade/maintain it moving forward. you have it your way, the patch has been pushed into OE-Core so further discussions is moot from here on, I wish we wait for discussions to finish for little we discuss on patches now a days. anyway for this but on debian I see there aren't many reverse deps given thousands of debian packages its only needed by handful libcap-ng0 Reverse Depends: qemu-system-common libvirt0 libvirt-bin suricata libcap-ng-utils ladvd heimdal-kdc audispd-plugins smartmontools qemu-system-common libvirt0 libvirt-bin libcap-ng-dev irqbalance gnome-keyring dbus-1-dbg dbus That doesn't look much core component to me to be frank, But yes when one needs it in his own setup then it becomes pretty core. I can site you an example of many, RDK depend on yajl its found in multiple layers too but we happily take it from meta-oe because we want to respect the layer boundaries. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2 v2] libcap-ng: add package 0.7.7 2015-08-24 23:41 ` Khem Raj @ 2015-08-25 13:21 ` Mark Hatle 0 siblings, 0 replies; 13+ messages in thread From: Mark Hatle @ 2015-08-25 13:21 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer On 8/24/15 6:41 PM, Khem Raj wrote: > On Mon, Aug 24, 2015 at 3:27 PM, Mark Hatle <mark.hatle@windriver.com> wrote: >> I agree BTW that it's the wrong answer to say since it's used in multiple places >> that it belongs in oe-core. >> >> HOWEVER, in this case, I think the use in multiple places is a reasonable >> justification that it's a commonly used, and potentially core component. >> >> Add that that it's implementing posix capabilities.. and I do think it's >> reasonable to put this -one- in oe-core. (The key to this, as always, is that >> these things need to be looked at individually to see if it's reasonable.) >> >> Anyway, this ONE has my vote to go into oe-core, based on the usage patterns I >> routinely see.. and that fact that I believe we have people willing to step in >> and upgrade/maintain it moving forward. > > you have it your way, the patch has been pushed into OE-Core so > further discussions is moot from here on, I wish we wait for > discussions to finish for little we discuss on patches now a days. > anyway for this > but on debian I see there aren't many reverse deps given thousands of > debian packages its only needed by handful > > libcap-ng0 I find it heavily used by security and auditing software. Specifically selinux (and related auditing), dbus, keyrings, etc.. This is why I think it was good for oe-core. But as you said point is moot now. (I don't develop with debian at all, but from the list below, it looks like that set of debian doesn't use support or use an LSM items, like selinux...) --Mark > Reverse Depends: > qemu-system-common > libvirt0 > libvirt-bin > suricata > libcap-ng-utils > ladvd > heimdal-kdc > audispd-plugins > smartmontools > qemu-system-common > libvirt0 > libvirt-bin > libcap-ng-dev > irqbalance > gnome-keyring > dbus-1-dbg > dbus > > That doesn't look much core component to me to be frank, But yes when > one needs it in his own setup then it becomes pretty core. I can site > you an example of many, RDK depend on yajl its found in multiple > layers too but we happily take it from meta-oe because we want to > respect the layer boundaries. > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-08-25 13:21 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-08-21 5:38 [PATCH 0/2 v2] libcap-ng, swig: add packages wenzong.fan 2015-08-21 5:38 ` [PATCH 1/2 v2] swig: add package 3.0.6 wenzong.fan 2015-08-21 5:38 ` [PATCH 2/2 v2] libcap-ng: add package 0.7.7 wenzong.fan 2015-08-21 7:25 ` Khem Raj 2015-08-22 0:55 ` Randy MacLeod 2015-08-22 1:14 ` Andre McCurdy 2015-08-24 22:30 ` Mark Hatle 2015-08-24 22:53 ` Randy MacLeod 2015-08-24 23:48 ` Khem Raj 2015-08-22 1:36 ` Khem Raj 2015-08-24 22:27 ` Mark Hatle 2015-08-24 23:41 ` Khem Raj 2015-08-25 13:21 ` Mark Hatle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox