All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.