Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Randy MacLeod <randy.macleod@windriver.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>, <armccurdy@gmail.com>
Subject: Re: [PATCH 2/2 v2] libcap-ng: add package 0.7.7
Date: Mon, 24 Aug 2015 18:53:20 -0400	[thread overview]
Message-ID: <55DBA060.5070109@windriver.com> (raw)
In-Reply-To: <CAJ86T=U8Gw5RcJz8RNzH=8MNbxHVHGJgdZd3N+pvdLCVdH+yXw@mail.gmail.com>

[-- 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


  parent reply	other threads:[~2015-08-24 22:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55DBA060.5070109@windriver.com \
    --to=randy.macleod@windriver.com \
    --cc=armccurdy@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox