Re: [OE-core] [PATCH] distcc: update to 3.3

[Huang, Jie (Jackie)]

> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Thursday, May 10, 2018 20:03
> To: Huang, Jie (Jackie)
> Cc: OE-core
> Subject: Re: [OE-core] [PATCH] distcc: update to 3.3
> 
> Hi Jackie,
> 
> Did you get to look at the distcc 3.3 upgrade failures?  We're open

Sorry I don't have time to fix the failure, I will have one of my  colleagues 
to take it over soon.

Thanks,
Jackie

> again for updates and moving to 3.3 instead of a forked repository on
> Armin's personal github would be nice!
> 
> Ross
> 
> On 22 March 2018 at 01:09, Huang, Jackie (Wind River)
> <jackie.hu...@windriver.com> wrote:
> > I will take a look and fix, thanks!
> >
> >
> >
> > Thanks,
> >
> > Jackie
> >
> >
> >
> > From: Burton, Ross [mailto:ross.bur...@intel.com]
> > Sent: Wednesday, March 21, 2018 18:44
> > To: Huang, Jie (Jackie)
> > Cc: OE-core
> > Subject: Re: [OE-core] [PATCH] distcc: update to 3.3
> >
> >
> >
> > This fails to start under systemd so caused the QA to fail:
> >
> >
> >
> > https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/882/steps/Running%20Sanity%20Tests_7/logs/stdio
> >
> >
> >
> > Ross
> >
> >
> >
> > On 15 March 2018 at 08:24, <jackie.hu...@windriver.com> wrote:
> >
> > From: Jackie Huang <jackie.hu...@windriver.com>
> >
> > * update to version 3.3
> > * Remove 0001-zeroconf-Include-fcntl.h.patch since it's
> >   included in v3.3
> > * Add update-distcc-symlinks into FILES.
> >
> > Signed-off-by: Jackie Huang <jackie.hu...@windriver.com>
> > ---
> >  .../distcc/{distcc_3.2.bb => distcc_3.3.bb}| 10 +---
> >  .../files/0001-zeroconf-Include-fcntl.h.patch  | 29
> > --
> >  2 files changed, 6 insertions(+), 33 deletions(-)
> >  rename meta/recipes-devtools/distcc/{distcc_3.2.bb => distcc_3.3.bb} (91%)
> >  delete mode 100644
> > meta/recipes-devtools/distcc/files/0001-zeroconf-Include-fcntl.h.patch
> >
> > diff --git a/meta/recipes-devtools/distcc/distcc_3.2.bb
> > b/meta/recipes-devtools/distcc/distcc_3.3.bb
> > similarity index 91%
> > rename from meta/recipes-devtools/distcc/distcc_3.2.bb
> > rename to meta/recipes-devtools/distcc/distcc_3.3.bb
> > index b6da65a582a..a266e7dde9b 100644
> > --- a/meta/recipes-devtools/distcc/distcc_3.2.bb
> > +++ b/meta/recipes-devtools/distcc/distcc_3.3.bb
> > @@ -14,14 +14,15 @@ PACKAGECONFIG[popt] =
> > "--without-included-popt,--with-included-popt,popt"
> >
> >  RRECOMMENDS_${PN} = "avahi-daemon"
> >
> > -SRC_URI = "git://github.com/distcc/distcc.git;branch=${PV} \
> > +SRC_URI = "git://github.com/distcc/distcc.git;branch=master \
> > file://separatebuilddir.patch \
> > -   file://0001-zeroconf-Include-fcntl.h.patch \
> > file://default \
> > file://distccmon-gnome.desktop \
> > file://distcc \
> > file://distcc.service"
> > -SRCREV = "d8b18df3e9dcbe4f092bed565835d3975e99432c"
> > +
> > +SRCREV = "002e68b766ccd7ad05551e67d162b71a7a773d0d"
> > +
> >  S = "${WORKDIR}/git"
> >  UPSTREAM_VERSION_UNKNOWN = "1"
> >
> > @@ -60,9 +61,10 @@ PACKAGES += "distcc-distmon-gnome"
> >
> >  FILES_${PN} = " ${sysconfdir} \
> > ${bindir}/distcc \
> > -${bindir}/lsdistcc \
> > +   ${bindir}/lsdistcc \
> > ${bindir}/distccd \
> > ${bindir}/distccmon-text \
> > +   ${sbindir}/update-distcc-symlinks \
> > ${systemd_unitdir}/system/distcc.service"
> >  FILES_distcc-distmon-gnome = "  ${bindir}/distccmon-gnome \
> > ${datadir}/distcc"
> > diff --git
> > a/meta/recipes-devtools/distcc/files/0001-zeroconf-Include-fcntl.h.patch
> > b/meta/recipes-devtools/distcc/files/0001-zeroconf-Include-fcntl.h.patch
> > deleted file mode 100644
> > index b17ec9c9599..000
> > --- a/meta/recipes-devtools/distcc/files/0001-zeroconf-Include-fcntl.h.patch
> > +++ /dev/null
> > @@ -1,29 +0,0 @@
> > -From 8331fc4759d809512f404e7a27f817ad6d616450 Mon Sep 17 00:00:00 2001
> > -From: Khem Raj <raj.k...@gmail.com>
> > -Date: Mon, 13 Apr 2015 18:00:33 -0700
> > -Subject: [PATCH] zeroconf: Include fcntl.h
> > -
> > -We need it for getting 

Re: [OE-core] [PATCH] distcc: update to 3.3

[Huang, Jie (Jackie)]

I will take a look and fix, thanks!

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Wednesday, March 21, 2018 18:44
To: Huang, Jie (Jackie)
Cc: OE-core
Subject: Re: [OE-core] [PATCH] distcc: update to 3.3

This fails to start under systemd so caused the QA to fail:

https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/882/steps/Running%20Sanity%20Tests_7/logs/stdio

Ross

On 15 March 2018 at 08:24, 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
From: Jackie Huang 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>>

* update to version 3.3
* Remove 0001-zeroconf-Include-fcntl.h.patch since it's
  included in v3.3
* Add update-distcc-symlinks into FILES.

Signed-off-by: Jackie Huang 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>>
---
 .../distcc/{distcc_3.2.bb<http://distcc_3.2.bb> => 
distcc_3.3.bb<http://distcc_3.3.bb>}| 10 +---
 .../files/0001-zeroconf-Include-fcntl.h.patch  | 29 --
 2 files changed, 6 insertions(+), 33 deletions(-)
 rename meta/recipes-devtools/distcc/{distcc_3.2.bb<http://distcc_3.2.bb> => 
distcc_3.3.bb<http://distcc_3.3.bb>} (91%)
 delete mode 100644 
meta/recipes-devtools/distcc/files/0001-zeroconf-Include-fcntl.h.patch

diff --git a/meta/recipes-devtools/distcc/distcc_3.2.bb<http://distcc_3.2.bb> 
b/meta/recipes-devtools/distcc/distcc_3.3.bb<http://distcc_3.3.bb>
similarity index 91%
rename from meta/recipes-devtools/distcc/distcc_3.2.bb<http://distcc_3.2.bb>
rename to meta/recipes-devtools/distcc/distcc_3.3.bb<http://distcc_3.3.bb>
index b6da65a582a..a266e7dde9b 100644
--- a/meta/recipes-devtools/distcc/distcc_3.2.bb<http://distcc_3.2.bb>
+++ b/meta/recipes-devtools/distcc/distcc_3.3.bb<http://distcc_3.3.bb>
@@ -14,14 +14,15 @@ PACKAGECONFIG[popt] = 
"--without-included-popt,--with-included-popt,popt"

 RRECOMMENDS_${PN} = "avahi-daemon"

-SRC_URI = 
"git://github.com/distcc/distcc.git;branch=${PV}<http://github.com/distcc/distcc.git;branch=$%7bPV%7d>
 \
+SRC_URI = 
"git://github.com/distcc/distcc.git;branch=master<http://github.com/distcc/distcc.git;branch=master>
 \
file://separatebuilddir.patch \
-   
file://0001-zeroconf-Include-fcntl.h.patch
 \
file://default \
file://distccmon-gnome.desktop \
file://distcc \
file://distcc.service"
-SRCREV = "d8b18df3e9dcbe4f092bed565835d3975e99432c"
+
+SRCREV = "002e68b766ccd7ad05551e67d162b71a7a773d0d"
+
 S = "${WORKDIR}/git"
 UPSTREAM_VERSION_UNKNOWN = "1"

@@ -60,9 +61,10 @@ PACKAGES += "distcc-distmon-gnome"

 FILES_${PN} = " ${sysconfdir} \
${bindir}/distcc \
-${bindir}/lsdistcc \
+   ${bindir}/lsdistcc \
${bindir}/distccd \
${bindir}/distccmon-text \
+   ${sbindir}/update-distcc-symlinks \
${systemd_unitdir}/system/distcc.service"
 FILES_distcc-distmon-gnome = "  ${bindir}/distccmon-gnome \
${datadir}/distcc"
diff --git 
a/meta/recipes-devtools/distcc/files/0001-zeroconf-Include-fcntl.h.patch 
b/meta/recipes-devtools/distcc/files/0001-zeroconf-Include-fcntl.h.patch
deleted file mode 100644
index b17ec9c9599..000
--- a/meta/recipes-devtools/distcc/files/0001-zeroconf-Include-fcntl.h.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From 8331fc4759d809512f404e7a27f817ad6d616450 Mon Sep 17 00:00:00 2001
-From: Khem Raj <raj.k...@gmail.com<mailto:raj.k...@gmail.com>>
-Date: Mon, 13 Apr 2015 18:00:33 -0700
-Subject: [PATCH] zeroconf: Include fcntl.h
-
-We need it for getting deinitions for O_* e.g. O_CREAT
-
-Upstream-Status: Pending
-
-Signed-off-by: Khem Raj <raj.k...@gmail.com<mailto:raj.k...@gmail.com>>

- src/zeroconf.c | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/src/zeroconf.c b/src/zeroconf.c
-index 414ddc4..31bd33f 100644
 a/src/zeroconf.c
-+++ b/src/zeroconf.c
-@@ -33,6 +33,7 @@
- #include 
- #include 
- #include 
-+#include 
-
- #include 
- #include 
---
-2.1.4
-
--
2.13.0

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] ✗ patchtest: failure for e2fsprogs: fixes for ptest

[Huang, Jie (Jackie)]

> -Original Message-
> From: Patchwork [mailto:patchw...@do.openembedded.org]
> Sent: Friday, February 02, 2018 15:33
> To: Huang, Jie (Jackie)
> Cc: openembedded-core@lists.openembedded.org
> Subject: ✗ patchtest: failure for e2fsprogs: fixes for ptest
> 
> == Series Details ==
> 
> Series: e2fsprogs: fixes for ptest
> Revision: 1
> URL   : https://patchwork.openembedded.org/series/10824/
> State : failure
> 
> == Summary ==
> 
> 
> Thank you for submitting this patch series to OpenEmbedded Core. This is
> an automated response. Several tests have been executed on the proposed
> series by patchtest resulting in the following failures:
> 
> 
> 
> * Issue Patches not removed from tree [test_src_uri_left_files]
>   Suggested fixAmend the patch containing the software patch file removal
>   Patchquiet-debugfs.patch

What I did is moving the "quiet-debugfs.patch" from SRC_URI to 
SRC_URI_append_class-native,
the patch file is not meant to be removed.

I think the test_src_uri_left_files needs to consider such changes.

Thanks,
Jackie

> 
> 
> 
> If you believe any of these test results are incorrect, please reply to the
> mailing list (openembedded-core@lists.openembedded.org) raising your
> concerns.
> Otherwise we would appreciate you correcting the issues and submitting a
> new
> version of the patchset if applicable. Please ensure you add/increment the
> version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> [PATCH v3] -> ...).
> 
> ---
> Guidelines:
> https://www.openembedded.org/wiki/Commit_Patch_Message_Guideline
> s
> Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2 v2] glibc: fixes for nscd and libnss-db

[Huang, Jie (Jackie)]

> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Friday, January 12, 2018 16:43
> To: Huang, Jie (Jackie)
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 0/2 v2] glibc: fixes for nscd and libnss-db
> 
> On Thu, 2018-01-04 at 01:31 +, Huang, Jie (Jackie) wrote:
> >
> > >
> > > -Original Message-
> > > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> > > Sent: Wednesday, January 03, 2018 21:54
> > > To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
> > > Subject: Re: [OE-core] [PATCH 0/2 v2] glibc: fixes for nscd and
> > > libnss-db
> > >
> > > On Fri, 2017-12-22 at 02:08 +, Huang, Jie (Jackie) wrote:
> > > >
> > > > Ping, I didn't see any objection on this, but it's not merged
> > > > yet, do
> > > > I miss anything?
> > > When we test it we see:
> > >
> > > WARNING: glibc-2.26-r0 do_package: glibc-extra-nss-2.26 was
> > > registered as
> > > shlib provider for libnss_db.so.2, changing it to libnss-db-2.26
> > > because it was
> > > built later
> > Sorry, but I haven't seen this warning in our builds after this patch
> > merged in our local branch for two weeks. Maybe we missed some cases
> > in our test builds, so could you show me how to reproduce it? Thanks!
> >
> > This patch is simply re-package libnss_db.so* from glibc-extra-nss
> > into libnss-db, I don't understand why libnss_db.so* is still
> > provided by both of them, did I miss anything when I do a re-
> > packaging for a recipe?
> 
> 
> I was able to reproduce this by starting with an existing build without
> the patch, then applying the patch. The error shows once during the
> rebuild and then not again. Its therefore probably less of an issue
> (but does raise a question about why that is happening).
> 
> The new make dependency does cause an additional failure though:

Sorry, I didn't noticed that make is gplv3. I change the dependency to
RSUGGESTS and the test passed:

$ oe-selftest -r bbtests.BitbakeTests.test_non_gplv3
2018-01-16 21:24:54,920 - oe-selftest - WARNING - meta-selftest layer not found 
in BBLAYERS, adding it
2018-01-16 21:25:05,010 - oe-selftest - INFO - Adding layer libraries:
2018-01-16 21:25:05,011 - oe-selftest - INFO -  
/buildarea2/jhuang0/git/yp/poky/meta/lib
2018-01-16 21:25:05,011 - oe-selftest - INFO -  
/buildarea2/jhuang0/git/yp/poky/meta-yocto-bsp/lib
2018-01-16 21:25:05,011 - oe-selftest - INFO -  
/buildarea2/jhuang0/git/yp/poky/meta-selftest/lib
2018-01-16 21:25:05,012 - oe-selftest - INFO - Running bitbake -p
2018-01-16 21:25:10,565 - oe-selftest - INFO - Adding: "include selftest.inc" 
in /buildarea2/jhuang0/yp/y_x64_180112/conf/local.conf
2018-01-16 21:25:10,566 - oe-selftest - INFO - Adding: "include bblayers.inc" 
in bblayers.conf
2018-01-16 21:25:10,566 - oe-selftest - INFO - test_non_gplv3 
(bbtests.BitbakeTests)
2018-01-16 21:46:22,538 - oe-selftest - INFO -  ... ok
2018-01-16 21:46:22,539 - oe-selftest - INFO - 
--
2018-01-16 21:46:22,539 - oe-selftest - INFO - Ran 1 test in 1271.974s
2018-01-16 21:46:22,539 - oe-selftest - INFO - OK
2018-01-16 21:46:22,539 - oe-selftest - INFO - RESULTS:
2018-01-16 21:46:22,539 - oe-selftest - INFO - RESULTS - 
bbtests.BitbakeTests.test_non_gplv3 - Testcase 1119: PASSED
2018-01-16 21:46:22,540 - oe-selftest - INFO - SUMMARY:
2018-01-16 21:46:22,540 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 
1271.975s
2018-01-16 21:46:22,540 - oe-selftest - INFO - oe-selftest - OK - All required 
tests passed

Thanks,
Jackie

> 
> $ oe-selftest -r bbtests.BitbakeTests.test_non_gplv3
> 
> 2018-01-12 08:31:25,196 - oe-selftest - INFO - test_non_gplv3
> (bbtests.BitbakeTests)
> 2018-01-12 08:34:02,940 - oe-selftest - INFO -  ... FAIL
> 2018-01-12 08:34:02,941 - oe-selftest - INFO -
> =
> =
> 2018-01-12 08:34:02,941 - oe-selftest - INFO - FAIL: test_non_gplv3
> (bbtests.BitbakeTests)
> 2018-01-12 08:34:02,941 - oe-selftest - INFO - 
> -
> -
> 2018-01-12 08:34:02,941 - oe-selftest - INFO - Traceback (most recent call 
> last):
>   File "/media/build1/poky/meta/lib/oeqa/core/decorator/__init__.py", line 32,
> in wrapped_f
> return func(*args, **kwargs)
>   File "/media/build1/poky/meta/lib/oeqa/selftest/cases/bbtests.py", line 
> 237, in
> test_non_gplv3
> self.assertEqual(result.status, 0, "Bitbake failed, exit code %s, output 

Re: [OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt

[Huang, Jie (Jackie)]

> -Original Message-
> From: MacLeod, Randy
> Sent: Friday, January 12, 2018 04:16
> To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt
> 
> On 2018-01-10 10:07 PM, jackie.hu...@windriver.com wrote:
> > From: Jackie Huang <jackie.hu...@windriver.com>
> >
> > 'getopt' is needed by systemd-sysv-install, or it fails with:
> > | kdump.service is not a native service, redirecting to 
> > systemd-sysv-install.
> > | Executing: /lib/systemd/systemd-sysv-install enable kdump
> > | /lib/systemd/systemd-sysv-install: line 15: getopt: command not found
> >
> > Signed-off-by: Jackie Huang <jackie.hu...@windriver.com>
> > ---
> >   meta/recipes-core/systemd/systemd_234.bb | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-core/systemd/systemd_234.bb b/meta/recipes-
> core/systemd/systemd_234.bb
> > index 4132cdf40f..5a0e4c2247 100644
> > --- a/meta/recipes-core/systemd/systemd_234.bb
> > +++ b/meta/recipes-core/systemd/systemd_234.bb
> > @@ -521,7 +521,7 @@ FILES_${PN} = " ${base_bindir}/* \
> >
> >   FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-
> 1/interfaces/ ${sysconfdir}/rpm/macros.systemd"
> >
> > -RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})
> util-linux-agetty"
> > +RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})
> util-linux-agetty util-linux-getopt"
> 
> It would be nice to make the dependency conditional on systemd being
> configured to support sysvinit scripts.

The sysvinit script is always supported for now:

commit 9d298d1563b3fd5ad569f806cc296e13279e7cf6
Author: Khem Raj <raj.k...@gmail.com>
Date:   Sun Sep 6 15:25:41 2015 +

systemd: Implement OE-Specific systemd-sysv-install

Support for chkconfig (--enable-chkconfig) was removed in favour of
calling an abstraction /lib/systemd/systemd-sysv-install. This
needs to be implemented for OE.

Signed-off-by: Khem Raj <raj.k...@gmail.com>
Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>

So I think the unconditional dependency is needed unless we change the
support for sysvinit to be optional as well.

Thanks,
Jackie
> 
> ../Randy
> 
> >   RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'serial-getty-
> generator', '', 'systemd-serialgetty', d)}"
> >   RDEPENDS_${PN} += "volatile-binds update-rc.d"
> >
> >
> 
> 
> --
> # Randy MacLeod.  WR Linux
> # Wind River an Intel Company
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2 v2] glibc: fixes for nscd and libnss-db

[Huang, Jie (Jackie)]

> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Wednesday, January 03, 2018 21:54
> To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 0/2 v2] glibc: fixes for nscd and libnss-db
> 
> On Fri, 2017-12-22 at 02:08 +0000, Huang, Jie (Jackie) wrote:
> > Ping, I didn't see any objection on this, but it's not merged yet, do
> > I miss anything?
> 
> When we test it we see:
> 
> WARNING: glibc-2.26-r0 do_package: glibc-extra-nss-2.26 was registered as
> shlib provider for libnss_db.so.2, changing it to libnss-db-2.26 because it 
> was
> built later

Sorry, but I haven't seen this warning in our builds after this patch merged in 
our 
local branch for two weeks. Maybe we missed some cases in our test builds, so
could you show me how to reproduce it? Thanks!

This patch is simply re-package libnss_db.so* from glibc-extra-nss into 
libnss-db,
I don't understand why libnss_db.so* is still provided by both of them, did I 
miss
anything when I do a re-packaging for a recipe?

Thanks,
Jackie

> 
> so it looks like you swapped one race for another?
> 
> Cheers,
> 
> Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2 v2] glibc: fixes for nscd and libnss-db

[Huang, Jie (Jackie)]

Ping, I didn't see any objection on this, but it's not merged yet, do I miss 
anything?

Thanks,
Jackie

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> jackie.hu...@windriver.com
> Sent: Thursday, November 02, 2017 14:41
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 0/2 v2] glibc: fixes for nscd and libnss-db
> 
> From: Jackie Huang 
> 
> v2 comments:
> Add a note for external toolchain in the commit log.
> 
> --
> The following changes since commit
> 514a808f21c37b6ad704ce397bb2740ecc9a93bc:
> 
>   ref-manual: Updates to "Image Generation" section. (2017-10-30 15:55:08
> +)
> 
> are available in the git repository at:
> 
>   git://git.pokylinux.org/poky-contrib.git jhuang0/d_nscd_171102_0
>   http://git.pokylinux.org/cgit.cgi//log/?h=jhuang0/d_nscd_171102_0
> 
> Jackie Huang (2):
>   glibc: re-package for libnss-db
>   glibc/nscd: do not cache for netgroup by default
> 
>  meta/recipes-core/glibc/glibc-package.inc | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> --
> 2.11.0
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] backfill mechanism

[Huang, Jie (Jackie)]

> -Original Message-
> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> Sent: Monday, November 27, 2017 23:46
> To: Slater, Joseph; openembedded-core@lists.openembedded.org
> Cc: MacLeod, Randy; Huang, Jie (Jackie)
> Subject: Re: backfill mechanism
> 
> On 11/17/17 5:32 PM, Slater, Joseph wrote:
> > The backfill mechanism is not compatible with multilib.  This could 
> > possibly be
> > fixed, but the backfill_considered functionality is also obscure, so I 
> > think in
> > at least the machine related .inc files we should replace lines like
> >
> >
> >
> > MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
> > ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"
> >
> 
> This not working with multilibs is definitely a bug that we need to file with
> the community.  We can use the stuff below as a workaround.  But all features
> should work properly with the multilib configurations.
> 
> Please open a bug in the Yocto System and our own (pointing to the YP 
> bugzilla)

I already opened a bug in YP Bugzilla:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12373

And we have also one in our own.

Thanks,
Jackie

> so we can at the minimum track this.
> 
> --Mark
> 
> >
> > with lines like
> >
> >
> >
> > MACHINE_FEATURES_remove_mipsarchn32 = " qemu-usermode"
> >
> >
> >
> > There are two advantages:  the second line works for multilib, and it is far
> > more readable.
> >
> >
> >
> > Joe
> >
> >
> >

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] backfill mechanism

[Huang, Jie (Jackie)]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Slater, Joseph
> Sent: Wednesday, November 22, 2017 03:11
> To: Andre McCurdy
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] backfill mechanism
> 
> The problem is that when backfilling is done, TUNE_FEATURES, etc, all have
> values associated with the base arch, not the current multilib.  The "generic"
> solution, below, should work, although I would still use overrides when 
> available.
> 
> Beyond what actually works, if the special backfill processing can be 
> eliminated
> and regular constructs used I think that would be desirable.
> 
> Joe
> 
> From: Andre McCurdy [armccu...@gmail.com]
> Sent: Monday, November 20, 2017 7:24 PM
> To: Slater, Joseph
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] backfill mechanism
> 
> On Fri, Nov 17, 2017 at 3:32 PM, Slater, Joseph
>  wrote:
> > The backfill mechanism is not compatible with multilib.
> 
> Did anyone ever explain why?

I think it should be a defect, so I just opened one:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12373

Thanks,
Jackie

> 
> > This could possibly
> > be fixed, but the backfill_considered functionality is also obscure, so I
> > think in at least the machine related .inc files we should replace lines
> > like
> >
> > MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
> > ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"
> >
> > with lines like
> >
> > MACHINE_FEATURES_remove_mipsarchn32 = " qemu-usermode"
> 
> That only works for TUNE_FEATURES which happen to have a corresponding
> over-ride, so may not be a generic solution. Does something like:
> 
>   MACHINE_FEATURES_remove = "${@bb.utils.contains('TUNE_FEATURES',
> 'n32', 'qemu-usermode', '', d)}"
> 
> work for multilib?
> 
> > There are two advantages:  the second line works for multilib, and it is far
> > more readable.
> >
> > Joe
> >
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Yocto Project Status WW47’17

[Huang, Jie (Jackie)]

> 
> 
> From: MacLeod, Randy 
> Sent: Tuesday, November 21, 2017 09:22
> To: openembedded-core@lists.openembedded.org; Armin Kuster; Huang, Jie 
> (Jackie); Xu, Chi; Yang, Liezhi; WOLD, SAUL
> Subject: Re: [OE-core] Yocto Project Status WW47’17
> 
> On 2017-11-20 10:36 AM, Jolley, Stephen K wrote:
> Current Dev Position: YP 2.5 Planning and M1 development
> Next Deadline: YP 2.5 M1 cut off of 12/4/17
>  
> SWAT team rotation: Juro -> Paul on Nov.17, 2017.
> SWAT team rotation: Paul -> Todor on Nov. 24, 2017.
> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>  
> Key Status/Updates:
> ?There is no real change to the status from last week. We continue to 
> suffer intermittent build failures and are continuing to attempt to debug 
> these.
> ?Currently open issues are:
> 
> Some US-based people may be on holiday later this week so I'm offering 
> help from the frozen Northland and more importantly from the team in Beijing. 
> ;-)
> 
> 
> o   qemuppc continues to demonstrate random hangs in boot  in userspace
> 
> Is we can create a defect for this and point / copy the wiki notes into it, 
> that
> would help.
>https://wiki.yoctoproject.org/wiki/Qemuppc_Boot_Hangs
> 
> I think I had asked Chi to see if he could reproduce this a week or two ago.
> When the lack of entropy problem was identified and fix, many people thought
> this hang went away as well. Chi can you read the wiki report and see if you
> can add anything to them?
> 
> 
> o   Issues with 4.13.10 host kernels booting kvm x86 guests on Tumbleweed 
> (Suse) and Fedora 26 (attempting to see if 4.13.12 helps)
> 
> Robert, can you test Fedora 26. It would help to have a defect open with 
> steps to reproduce or
> something about the typical workflow/ build time/ day of the week/ phase of 
> the moon. 
> 
> 
> o   nfs inode count for the sstate/dldir share appears to break periodically 
> causing the disk monitor to halt the builds (bug 12267)
> 
> Likely specific to the AB server so no plans to do anything for this bug.
> 
> 
> o   a perf build race (bug 12302)
>  I'll take a look to:
>  - see if I can duplicate the bug on a fast build host
>  - check upstream to see if the bug is known/fixed
>  - see if I can spot a race in the build rules.
> 
> 
> o   An ext filesystem creation/sizing issue (bug 12304)
> 
> Saul, Are you around this week? Do you have any additional information before
> leaving for Thanksgiving?
> 
> Jackie, 
> Can you look at the code around the image creation and try to reproduce this 
> one?

There is no steps to reproduce in this bug and it seems to be a rare issue, but 
yes, I can 
take a look at the code and info from yocto's autobuilder and try to reproduce 
it.

Thanks,
Jackie

> 
> ../Randy
> 
> 
> ?Until we resolve these issues patches will continue to be slow to 
> merge, if at all. This also blocks several core developers from doing any 
> feature work at this point in time (e.g. layer setup tool is on hold, again).
> ?We can only continue to stress that unless others step up and help 
> to try and root cause these issues, things will stall with the project.
>  
> Planned upcoming dot releases:
> YP 2.2.3 is planned and should be out in the next few weeks.
> YP 2.3.3 is planned, but date TBD during YP 2.5 planning.
> YP 2.4.1 is planned, but date TBD during YP 2.5 planning.
>  
> Key YP 2.5 Dates are:
> YP 2.5 M1 cut off of 12/4/17
> YP 2.5 M1 release of 12/15/17
> YP 2.5 M2 cut off of 1/15/18
> YP 2.5 M2 release of 1/26/18
> YP 2.5 M3 cut off of 2/19/18
> YP 2.5 M3 release of 3/2/18
> YP 2.5 M4 cut off of 4/2/18
> YP 2.5 M4 release of 4/27/18
>  
> Tracking Metrics:
> WDD 2655 (last week 2640)
>(https://wiki.yoctoproject.org/charts/combo.html)
>  
> Key Status Links for YP:
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status
> https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule
> https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features
> [If anyone has suggestions for other information you’d like to see on this 
> weekly status update, let us know!]
>  
> Thanks,
>  
> Stephen K. Jolley
> Yocto Project Program Manager
> INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 
> Work Telephone:(503) 712-0534
> 4Cell:  (208) 244-4460
> 00Email:stephen.k.jol...@intel.com
>  
> 
> 
> 
> -- 
> # Randy MacLeod.  WR Linux
> # Wind River an Intel Company
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] glibc: re-package for libnss-db

[Huang, Jie (Jackie)]

> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Wednesday, November 01, 2017 16:35
> To: Huang, Jie (Jackie)
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/2] glibc: re-package for libnss-db
> 
> On Tue, Oct 31, 2017 at 7:03 PM, Huang, Jie (Jackie)
> <jackie.hu...@windriver.com> wrote:
> >
> >
> >> -Original Message-
> >> From: Khem Raj [mailto:raj.k...@gmail.com]
> >> Sent: Wednesday, November 01, 2017 03:40
> >> To: Huang, Jie (Jackie)
> >> Cc: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [PATCH 1/2] glibc: re-package for libnss-db
> >>
> >> On Tue, Oct 31, 2017 at 12:20 AM,  <jackie.hu...@windriver.com> wrote:
> >> > From: Jackie Huang <jackie.hu...@windriver.com>
> >> >
> >> > On other distros like ubuntu/centos, libnss-db usually provides:
> >> > - The libraries
> >> > - The Makefile to create database
> >> >   (in /var/db for centos, /var/lib/misc/ for ubuntu)
> >> > - The makedb command (it's in glibc-common for centos7)
> >> >
> >> > What we had is:
> >> > - The libraries are in glibc-extra-nss
> >> > - The Makefile is removed
> >> > - The makedb command is in glibc-utils (lack of dependency)
> >> >
> >> > So when glibc-extra-nss is installed but glibc-utils is not,
> >> > we see error like:
> >> > nscd[165]: 165 checking for monitored file `/var/db/group.db': No such 
> >> > file
> or
> >> directory
> >> > nscd[165]: 165 checking for monitored file `/var/db/passwd.db': No such
> file
> >> or directory
> >> >
> >> > And there is not an easy way to create these databases.
> >> >
> >> > To fix the issue:
> >> > - Re-package the libraries into libnss-db
> >> > - Don't remove the Makefile and add it in libnss-db
> >> > - Add RDEPENDS for libnss-db on glibc-utils and make
> >> >
> >>
> >> this looks ok although, changing glibc packaging is a bit thorny for
> >> external toolchains and
> >> other libraries. Would be better if this was added to commit saying
> >> that they have yet another
> >> package that they need to provide if replacing glibc from core.
> >
> > Sorry I'm not sure I understand correctly, did you mean I just need to add
> > words in the commit message like the following?
> >
> > "For external toolchain, an extra package 'libnss-db' need to be provided If
> replacing glibc from core."
> >
> 
> yes, someway for folks to notice the change for external layer maintainers.

Got it, I added the note and sent v2 for this.

Thanks,
Jackie

> 
> > Thanks,
> > Jackie
> >
> >>
> >> > Signed-off-by: Jackie Huang <jackie.hu...@windriver.com>
> >> > ---
> >> >  meta/recipes-core/glibc/glibc-package.inc | 5 +++--
> >> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/meta/recipes-core/glibc/glibc-package.inc b/meta/recipes-
> >> core/glibc/glibc-package.inc
> >> > index df3db2cc45..1c3782dbb0 100644
> >> > --- a/meta/recipes-core/glibc/glibc-package.inc
> >> > +++ b/meta/recipes-core/glibc/glibc-package.inc
> >> > @@ -1,6 +1,6 @@
> >> >  INHIBIT_SYSROOT_STRIP = "1"
> >> >
> >> > -PACKAGES = "${PN}-dbg catchsegv sln nscd ldd tzcode glibc-thread-db
> ${PN}-
> >> pic libcidn libmemusage libsegfault ${PN}-pcprofile libsotruss ${PN} ${PN}-
> utils
> >> glibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc"
> >> > +PACKAGES = "${PN}-dbg catchsegv sln nscd ldd tzcode glibc-thread-db
> ${PN}-
> >> pic libcidn libmemusage libnss-db libsegfault ${PN}-pcprofile libsotruss 
> >> ${PN}
> >> ${PN}-utils glibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc"
> >> >
> >> >  # The ld.so in this glibc supports the GNU_HASH
> >> >  RPROVIDES_${PN} = "eglibc rtld(GNU_HASH)"
> >> > @@ -23,6 +23,8 @@ FILES_ldd = "${bindir}/ldd"
> >> >  FILES_libsegfault = "${base_libdir}/libSegFault*"
> >> >  FILES_libcidn = "${base_libdir}/libcidn-*.so 
> >> > ${base_libdir}/libcidn.so.*"
> >> >  FILES_libmemusage = "${base_libdir}/libmemusage.so"
> >> > +FILES_libnss-db

Re: [OE-core] [PATCH 1/2] glibc: re-package for libnss-db

[Huang, Jie (Jackie)]

> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Wednesday, November 01, 2017 03:40
> To: Huang, Jie (Jackie)
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/2] glibc: re-package for libnss-db
> 
> On Tue, Oct 31, 2017 at 12:20 AM,  <jackie.hu...@windriver.com> wrote:
> > From: Jackie Huang <jackie.hu...@windriver.com>
> >
> > On other distros like ubuntu/centos, libnss-db usually provides:
> > - The libraries
> > - The Makefile to create database
> >   (in /var/db for centos, /var/lib/misc/ for ubuntu)
> > - The makedb command (it's in glibc-common for centos7)
> >
> > What we had is:
> > - The libraries are in glibc-extra-nss
> > - The Makefile is removed
> > - The makedb command is in glibc-utils (lack of dependency)
> >
> > So when glibc-extra-nss is installed but glibc-utils is not,
> > we see error like:
> > nscd[165]: 165 checking for monitored file `/var/db/group.db': No such file 
> > or
> directory
> > nscd[165]: 165 checking for monitored file `/var/db/passwd.db': No such file
> or directory
> >
> > And there is not an easy way to create these databases.
> >
> > To fix the issue:
> > - Re-package the libraries into libnss-db
> > - Don't remove the Makefile and add it in libnss-db
> > - Add RDEPENDS for libnss-db on glibc-utils and make
> >
> 
> this looks ok although, changing glibc packaging is a bit thorny for
> external toolchains and
> other libraries. Would be better if this was added to commit saying
> that they have yet another
> package that they need to provide if replacing glibc from core.

Sorry I'm not sure I understand correctly, did you mean I just need to add 
words in the commit message like the following?

"For external toolchain, an extra package 'libnss-db' need to be provided If 
replacing glibc from core."

Thanks,
Jackie 

> 
> > Signed-off-by: Jackie Huang <jackie.hu...@windriver.com>
> > ---
> >  meta/recipes-core/glibc/glibc-package.inc | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-core/glibc/glibc-package.inc b/meta/recipes-
> core/glibc/glibc-package.inc
> > index df3db2cc45..1c3782dbb0 100644
> > --- a/meta/recipes-core/glibc/glibc-package.inc
> > +++ b/meta/recipes-core/glibc/glibc-package.inc
> > @@ -1,6 +1,6 @@
> >  INHIBIT_SYSROOT_STRIP = "1"
> >
> > -PACKAGES = "${PN}-dbg catchsegv sln nscd ldd tzcode glibc-thread-db ${PN}-
> pic libcidn libmemusage libsegfault ${PN}-pcprofile libsotruss ${PN} 
> ${PN}-utils
> glibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc"
> > +PACKAGES = "${PN}-dbg catchsegv sln nscd ldd tzcode glibc-thread-db ${PN}-
> pic libcidn libmemusage libnss-db libsegfault ${PN}-pcprofile libsotruss ${PN}
> ${PN}-utils glibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc"
> >
> >  # The ld.so in this glibc supports the GNU_HASH
> >  RPROVIDES_${PN} = "eglibc rtld(GNU_HASH)"
> > @@ -23,6 +23,8 @@ FILES_ldd = "${bindir}/ldd"
> >  FILES_libsegfault = "${base_libdir}/libSegFault*"
> >  FILES_libcidn = "${base_libdir}/libcidn-*.so ${base_libdir}/libcidn.so.*"
> >  FILES_libmemusage = "${base_libdir}/libmemusage.so"
> > +FILES_libnss-db = "${base_libdir}/libnss_db.so.* 
> > ${base_libdir}/libnss_db-*.so
> ${localstatedir}/db/Makefile"
> > +RDEPENDS_libnss-db = "${PN}-utils make"
> >  FILES_glibc-extra-nss = "${base_libdir}/libnss_*-*.so
> ${base_libdir}/libnss_*.so.*"
> >  FILES_sln = "${base_sbindir}/sln"
> >  FILES_${PN}-pic = "${libdir}/*_pic.a ${libdir}/*_pic.map 
> > ${libdir}/libc_pic/*.o"
> > @@ -59,7 +61,6 @@ inherit libc-common multilib_header
> >
> >  do_install_append () {
> > rm -f ${D}${sysconfdir}/localtime
> > -   rm -rf ${D}${localstatedir}
> >
> > # remove empty glibc dir
> > if [ -d ${D}${libexecdir} ]; then
> > --
> > 2.11.0
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] rootfs-postcommands.bbclass: add support for /etc/ld.so.conf.d/*.conf

[Huang, Jie (Jackie)]

Ok, I will do this in the glibc recipe instead if it’s preferred.

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, September 29, 2017 21:38
To: Huang, Jie (Jackie)
Cc: OE-core
Subject: Re: [OE-core] [PATCH] rootfs-postcommands.bbclass: add support for 
/etc/ld.so.conf.d/*.conf

On 29 September 2017 at 03:58, Huang, Jackie (Wind River) 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
 - This will cause the existing contents of ld.so.conf to be obliterated
   if the file wasn't empty to begin with.  (I know that it is empty in
   oe-core, but a distro layer might be overlaying this file with its
   own.)

 - Also, it seems as though the choice of whether to use an "ld.so.conf.d"
   arrangement or not is one that the distro should be making. Is there
   a strong reason why this needs to be done in oe-core?

This is easily handled in many ways.  Check the include doesn't already exist 
and concatenate the file instead of overwriting it, for example.  Or add the 
include to the default oe-core ld.so.conf, and distros that want to change 
ld.so.conf can by changing that file.

Ross


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] rootfs-postcommands.bbclass: add support for /etc/ld.so.conf.d/*.conf

[Huang, Jie (Jackie)]

I found the original patch:

https://patchwork.openembedded.org/patch/62453/

Thanks,
Jackie

From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Huang, 
Jie (Jackie)
Sent: Friday, September 29, 2017 10:58
To: BURTON, ROSS
Cc: OE-core
Subject: Re: [OE-core] [PATCH] rootfs-postcommands.bbclass: add support for 
/etc/ld.so.conf.d/*.conf

That’s what we did in the original patch, but rejected long time ago
then we have been keeping it in our local branch:

commit 1e43ff11f841247453f1d4106b22d33aa3a150f9
Author: Ming Liu <ming@windriver.com<mailto:ming@windriver.com>>
Date:   Wed Aug 21 16:06:29 2013 +0800

eglibc: add support for /etc/ld.so.conf.d/*.conf

There are advantages in changing the contents of ld.so.conf to
"include /etc/ld.so.conf.d/*.conf" instead of directly listing directories
in it, just like most distributions are doing the same.

Signed-off-by: Ming Liu 
<ming@windriver.com<mailto:ming@windriver.com>>
Signed-off-by: Robert Yang 
<liezhi.y...@windriver.com<mailto:liezhi.y...@windriver.com>>

(LOCAL REV: NOT UPSTREAM) -- Sent to oe-core on 20131127

Rejected by oe-core since:
 - This will cause the existing contents of ld.so.conf to be obliterated
   if the file wasn't empty to begin with.  (I know that it is empty in
   oe-core, but a distro layer might be overlaying this file with its
   own.)

 - Also, it seems as though the choice of whether to use an "ld.so.conf.d"
   arrangement or not is one that the distro should be making. Is there
   a strong reason why this needs to be done in oe-core?

 - I would like to different components to add their own conf files to
   ${D}${sysconfdir}/ld.so.conf.d and let ldconfig executed in do_rootfs
   to find them, but they won't be there when eglibc.do_install is executed.

Signed-off-by: Hongxu Jia 
<hongxu@windriver.com<mailto:hongxu@windriver.com>>


Then we re-implement it as a rootfs postinstall command to avoid the concern
and it could be controlled in distro settings.

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, September 28, 2017 19:28
To: Huang, Jie (Jackie)
Cc: OE-core
Subject: Re: [OE-core] [PATCH] rootfs-postcommands.bbclass: add support for 
/etc/ld.so.conf.d/*.conf

Why implement this as a rootfs postinstall command?  glibc writes this file, so 
we can alter it when that recipe is written.

Ross

On 31 August 2017 at 06:54, 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
From: Jackie Huang 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>>

There are advantages in changing the contents of ld.so.conf to
"include /etc/ld.so.conf.d/*.conf" instead of directly listing
directories in it, just like most distributions are doing the same.

Signed-off-by: Jackie Huang 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>>
---
 meta/classes/rootfs-postcommands.bbclass | 13 +
 1 file changed, 13 insertions(+)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index dc5a76baba..af01eb550a 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -20,6 +20,9 @@ ROOTFS_POSTPROCESS_COMMAND += 
'${@bb.utils.contains("IMAGE_FEATURES", "read-only
 # Generates test data file with data store variables expanded in json format
 ROOTFS_POSTPROCESS_COMMAND += "write_image_test_data ; "

+# Add support for /etc/ld.so.conf.d/*.conf if ldconfig is enabled
+ROOTFS_POSTINSTALL_COMMAND += "${@bb.utils.contains('DISTRO_FEATURES', 
'ldconfig', 'add_ld_so_conf_d ;', '', 
d)}<mailto:$%7b@bb.utils.contains('DISTRO_FEATURES',%20'ldconfig',%20'add_ld_so_conf_d%20;',%20'',%20d)%7d>"
+
 # Write manifest
 IMAGE_MANIFEST = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.manifest"
 ROOTFS_POSTUNINSTALL_COMMAND =+ "write_image_manifest ; "
@@ -244,6 +247,16 @@ make_zimage_symlink_relative () {
fi
 }

+# Add support for /etc/ld.so.conf.d/*.conf
+add_ld_so_conf_d() {
+if [ -f ${IMAGE_ROOTFS}${sysconfdir}/ld.so.conf ]; then
+if ! `grep -q 'include ld.so.conf.d\/\*.conf' /etc/ld.so.conf`; then
+echo 'include ld.so.conf.d/*.conf' >> 
${IMAGE_ROOTFS}${sysconfdir}/ld.so.conf
+fi
+mkdir -p ${IMAGE_ROOTFS}${sysconfdir}/ld.so.conf.d
+fi
+}
+
 python write_image_manifest () {
 from oe.rootfs import image_list_installed_packages
 from oe.utils import format_pkg_list
--
2.11.0

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/op

Re: [OE-core] [PATCH] rootfs-postcommands.bbclass: add support for /etc/ld.so.conf.d/*.conf

[Huang, Jie (Jackie)]

That’s what we did in the original patch, but rejected long time ago
then we have been keeping it in our local branch:

commit 1e43ff11f841247453f1d4106b22d33aa3a150f9
Author: Ming Liu <ming@windriver.com>
Date:   Wed Aug 21 16:06:29 2013 +0800

eglibc: add support for /etc/ld.so.conf.d/*.conf

There are advantages in changing the contents of ld.so.conf to
"include /etc/ld.so.conf.d/*.conf" instead of directly listing directories
in it, just like most distributions are doing the same.

Signed-off-by: Ming Liu <ming@windriver.com>
Signed-off-by: Robert Yang <liezhi.y...@windriver.com>

(LOCAL REV: NOT UPSTREAM) -- Sent to oe-core on 20131127

Rejected by oe-core since:
 - This will cause the existing contents of ld.so.conf to be obliterated
   if the file wasn't empty to begin with.  (I know that it is empty in
   oe-core, but a distro layer might be overlaying this file with its
   own.)

 - Also, it seems as though the choice of whether to use an "ld.so.conf.d"
   arrangement or not is one that the distro should be making. Is there
   a strong reason why this needs to be done in oe-core?

 - I would like to different components to add their own conf files to
   ${D}${sysconfdir}/ld.so.conf.d and let ldconfig executed in do_rootfs
   to find them, but they won't be there when eglibc.do_install is executed.

Signed-off-by: Hongxu Jia <hongxu@windriver.com>


Then we re-implement it as a rootfs postinstall command to avoid the concern
and it could be controlled in distro settings.

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, September 28, 2017 19:28
To: Huang, Jie (Jackie)
Cc: OE-core
Subject: Re: [OE-core] [PATCH] rootfs-postcommands.bbclass: add support for 
/etc/ld.so.conf.d/*.conf

Why implement this as a rootfs postinstall command?  glibc writes this file, so 
we can alter it when that recipe is written.

Ross

On 31 August 2017 at 06:54, 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
From: Jackie Huang 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>>

There are advantages in changing the contents of ld.so.conf to
"include /etc/ld.so.conf.d/*.conf" instead of directly listing
directories in it, just like most distributions are doing the same.

Signed-off-by: Jackie Huang 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>>
---
 meta/classes/rootfs-postcommands.bbclass | 13 +
 1 file changed, 13 insertions(+)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index dc5a76baba..af01eb550a 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -20,6 +20,9 @@ ROOTFS_POSTPROCESS_COMMAND += 
'${@bb.utils.contains("IMAGE_FEATURES", "read-only
 # Generates test data file with data store variables expanded in json format
 ROOTFS_POSTPROCESS_COMMAND += "write_image_test_data ; "

+# Add support for /etc/ld.so.conf.d/*.conf if ldconfig is enabled
+ROOTFS_POSTINSTALL_COMMAND += "${@bb.utils.contains('DISTRO_FEATURES', 
'ldconfig', 'add_ld_so_conf_d ;', '', 
d)}<mailto:$%7b@bb.utils.contains('DISTRO_FEATURES',%20'ldconfig',%20'add_ld_so_conf_d%20;',%20'',%20d)%7d>"
+
 # Write manifest
 IMAGE_MANIFEST = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.manifest"
 ROOTFS_POSTUNINSTALL_COMMAND =+ "write_image_manifest ; "
@@ -244,6 +247,16 @@ make_zimage_symlink_relative () {
fi
 }

+# Add support for /etc/ld.so.conf.d/*.conf
+add_ld_so_conf_d() {
+if [ -f ${IMAGE_ROOTFS}${sysconfdir}/ld.so.conf ]; then
+if ! `grep -q 'include ld.so.conf.d\/\*.conf' /etc/ld.so.conf`; then
+echo 'include ld.so.conf.d/*.conf' >> 
${IMAGE_ROOTFS}${sysconfdir}/ld.so.conf
+fi
+mkdir -p ${IMAGE_ROOTFS}${sysconfdir}/ld.so.conf.d
+fi
+}
+
 python write_image_manifest () {
 from oe.rootfs import image_list_installed_packages
 from oe.utils import format_pkg_list
--
2.11.0

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] boost: add python to default PACKAGECONFIG options

[Huang, Jie (Jackie)]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Huang, Jie (Jackie)
> Sent: Wednesday, August 23, 2017 16:02
> To: MacLeod, Randy; Richard Purdie; Andre McCurdy
> Cc: OE Core mailing list
> Subject: Re: [OE-core] [PATCH] boost: add python to default PACKAGECONFIG
> options
> 
> 
> 
> > -Original Message-
> > From: MacLeod, Randy
> > Sent: Wednesday, August 23, 2017 09:27
> > To: Richard Purdie; Andre McCurdy; Huang, Jie (Jackie)
> > Cc: OE Core mailing list
> > Subject: Re: [OE-core] [PATCH] boost: add python to default PACKAGECONFIG
> > options
> >
> > On 2017-08-22 03:55 PM, Richard Purdie wrote:
> > > On Tue, 2017-08-22 at 12:51 -0700, Andre McCurdy wrote:
> > >> On Tue, Aug 22, 2017 at 12:42 AM,  <jackie.hu...@windriver.com>
> > >> wrote:
> > >>>
> > >>> From: Jackie Huang <jackie.hu...@windriver.com>
> > >>>
> > >>> We want to provide python libs by default, and some other
> > >>> popular Linux distributions like redhat/fedora does the same.
> > >> Has something changed? Is there anything in oe-core or meta-oe which
> > >> now needs boost python support enabled?
> > >
> > > Does it even actually build on all arches? >
> > > I'm rather behind with patch review right now as people are putting so
> > > many patches out there with what seems like minimal testing and
> > > expecting me/Ross and the autobuilder to figure out the problems for
> > > them.
> > >
> > > Each time one fails, it blocks the queue with the rest of them in and I
> > > have to retest until I get something clean.
> > >
> > > Testing this change is quite a way down my priority list I'm afraid.
> > >
> >
> > Maybe this is better done in our distro configuration.
> >
> > We're trying to minimize differences with oe-core and
> > the boost python support doesn't seem to be much of an
> > impact based on looking at logs rather than a having a
> > detailed understanding of boost.
> >
> > We've had this commit in our local branch since before:
> >
> > CommitDate: Wed Dec 21 22:16:31 2016 -0800
> >
> >  boost: add python to default PACKAGECONFIG options
> >
> >  We want to provide python libs by default, and some other
> >  popular Linux distributions like redhat/fedora does the same.
> >
> >  (LOCAL REV: NOT UPSTREAM) -- sent to oe-core on 20160930
> >
> > so it certainly builds for all qemu* for glibc configurations.
> >
> > I'll see if we can add musl builds to our automated builds tonight.
> >
> > Jackie,
> >
> > Did/Can you build for musl?
> 
> No, I didn't build for musl yet, but yes, I can and will do the test with musl
> and fix issues as needed.

I tested for all qemu* with:
$ for i in qemuarm qemuarm64 qemux86 qemux86-64 qemuppc qemumips qemumips64; do 
MACHINE="$i" TCLIBC=musl bitbake boost

And all passed, could you point me out what the failure is caused by this 
patch? 

Thanks,
Jackie

> 
> > Do you have any idea of the impact of this config on users that are not
> > interested in the python interface with boost?
> 
> I don't think there is any impact, each library is packaged into a separate
> package named with boost-
> 
> > What's the additional cost in compile time?
> 
> A quick test indicates that it's less than 1 second:
> 
> $ grep -r 'Elapsed time:' 20170823073306/boost-1.64.0-r0/do_compile
> 20170823075302/boost-1.64.0-r0/do_compile
> 20170823073306/boost-1.64.0-r0/do_compile:Elapsed time: 50.96 seconds
> 20170823075302/boost-1.64.0-r0/do_compile:Elapsed time: 51.63 seconds
> 
> Thanks,
> Jackie
> 
> >
> >
> >
> > There certainly are a rush of package updates and other changes
> > coming in; apologies for the lack of warning and late arrivals.
> > Other than doing more testing and explaining what tests were done,
> > what else can we do to help?
> >
> >
> > ../Randy
> >
> >
> > > Cheers,
> > >
> > > Richard
> > >
> > >
> >
> >
> > --
> > # 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] State of bitbake world, Failed tasks 2017-08-19

[Huang, Jie (Jackie)]

> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Martin Jansa
> Sent: Tuesday, August 22, 2017 21:20
> To: Patches and discussions about the oe-core layer; openembedded-devel
> Subject: [oe] State of bitbake world, Failed tasks 2017-08-19
> 
> Openssl was reverted back to 1.0 version being default, so there is
> fewer errors now, but there was also a fix for package.bbclass:
> http://lists.openembedded.org/pipermail/openembedded-core/2017-
> August/141127.html
> which causes many do_package_qa tasks to fail.
> 
> Please help by sending fixes for issues it found.
> 
> http://www.openembedded.org/wiki/Bitbake_World_Status
> 
> == Number of issues - stats ==
> {| class='wikitable'
> !|Date !!colspan='3'|Failed tasks
>   !!|Signatures !!colspan='14'|QA !!Comment
> |-
> ||||qemuarm   ||qemux86   ||qemux86_64||all
>   ||already-stripped  ||libdir||textrel   ||build-deps
> ||file-
> rdeps ||version-going-backwards   ||host-user-contaminated
>   ||installed-vs-shipped  ||unknown-configure-option  ||symlink-to-
> sysroot   ||invalid-pkgconfig ||pkgname   ||ldflags   
> ||compile-
> host-path ||
> |-
> ||2017-08-19  ||17||21||21||0 ||0 ||0
>   ||5 ||0 ||25||28485
>   ||2 ||0 ||0 ||0 ||0
>   ||0 ||0 ||0 ||
> |}
> 
> == Failed tasks 2017-08-19 ==
> 
> INFO: jenkins-job.sh-1.8.25 Complete log available at http://logs.nslu2-
> linux.org/buildlogs/oe/world/rocko/log.report.20170822_023550.log
> 
> === common (15) ===
> * meta-browser/recipes-mozilla/firefox/firefox_45.9.0esr.bb:do_compile
> * meta-openembedded/meta-filesystems/recipes-
> utils/udevil/udevil_0.4.4.bb:do_package_qa
> * meta-openembedded/meta-gnome/recipes-
> gnome/bonobo/libbonobo_2.32.1.bb:do_package_qa
> * meta-openembedded/meta-networking/recipes-
> daemons/squid/squid_3.5.26.bb:do_package_qa
> * meta-openembedded/meta-networking/recipes-
> kernel/wireguard/wireguard-tools_0.0.20170517.bb:do_package_qa
> * meta-openembedded/meta-networking/recipes-
> support/ndisc6/ndisc6_1.0.3.bb:do_package_qa
> * meta-openembedded/meta-oe/recipes-core/glib-
> 2.0/glibmm_2.50.1.bb:do_package_qa
> * meta-openembedded/meta-oe/recipes-
> devtools/mpich/mpich_3.2.bb:do_package_qa


> * meta-openembedded/meta-oe/recipes-
> extended/corosync/corosync_2.4.2.bb:do_package_qa
> * meta-openembedded/meta-oe/recipes-
> extended/enscript/enscript_1.6.6.bb:do_package_qa
> * meta-openembedded/meta-oe/recipes-
> support/logwarn/logwarn_1.0.14.bb:do_package_qa

I will take these three.

> * meta-openembedded/meta-perl/recipes-perl/libmodule/libmodule-build-
> perl_0.31.bb:do_package_qa
> * meta-openembedded/meta-python/recipes-devtools/python/python3-
> pylint_1.6.5.bb:do_package_qa
> * meta-openembedded/meta-python/recipes-devtools/python/python-
> matplotlib_1.1.0.bb:do_compile
> * meta-smartphone/meta-shr/recipes-shr/3rdparty/ubx-
> utils_git.bb:do_package_qa
> 
> === common-x86 (5) ===
> * meta-openembedded/meta-oe/recipes-devtools/xmlrpc-c/xmlrpc-
> c_1.31.0.bb:do_package_qa
> * meta-openembedded/meta-oe/recipes-support/multipath-tools/multipath-
> tools_0.7.1.bb:do_package_qa

I will take this.

Thanks,
Jackie

> * meta-openembedded/meta-python/recipes-extended/python-
> pykickstart/python3-pykickstart_2.35.bb:do_package_qa
> * meta-qt5/recipes-qt/qt5/qtwebengine_git.bb:do_compile
> * meta-smartphone/meta-shr/recipes-
> shr/3rdparty/numptyphysics_svn.bb:do_package_qa
> 
> === qemuarm (2) ===
> * meta-openembedded/meta-oe/recipes-
> support/mysql/mariadb_5.5.57.bb:do_compile
> * meta-webos-ports/meta-luneui/recipes-luneui/luna-next/luna-
> next.bb:do_compile
> 
> === qemux86 (1) ===
> * meta-openembedded/meta-oe/recipes-
> support/mongodb/mongodb_git.bb:do_compile
> 
> === qemux86_64 (1) ===
> * meta-openembedded/meta-gnome/recipes-gnome/eds/evolution-data-
> server_git.bb:do_compile
> 
> === Number of failed tasks (59) ===
> {| class=wikitable
> |-
> || qemuarm|| 17|| http://logs.nslu2-
> linux.org/buildlogs/oe/world/rocko/log.world.qemuarm.20170820_231852.log/
> || http://errors.yoctoproject.org/Errors/Build/45276/
> |-
> || qemux86|| 21|| http://logs.nslu2-
> linux.org/buildlogs/oe/world/rocko/log.world.qemux86.20170820_161131.log/
> || http://errors.yoctoproject.org/Errors/Build/45273/
> |-
> || qemux86_64 || 21|| http://logs.nslu2-
> linux.org/buildlogs/oe/world/rocko/log.world.qemux86-
> 64.20170819_113439.log/ ||
> http://errors.yoctoproject.org/Errors/Build/44950/
> |}
> 
> === PNBLACKLISTs (1) ===
> 
> === QA issues (28517) ===
> {| class=wikitable

Re: [OE-core] [PATCH] boost: add python to default PACKAGECONFIG options

[Huang, Jie (Jackie)]

> -Original Message-
> From: MacLeod, Randy
> Sent: Wednesday, August 23, 2017 09:27
> To: Richard Purdie; Andre McCurdy; Huang, Jie (Jackie)
> Cc: OE Core mailing list
> Subject: Re: [OE-core] [PATCH] boost: add python to default PACKAGECONFIG
> options
> 
> On 2017-08-22 03:55 PM, Richard Purdie wrote:
> > On Tue, 2017-08-22 at 12:51 -0700, Andre McCurdy wrote:
> >> On Tue, Aug 22, 2017 at 12:42 AM,  <jackie.hu...@windriver.com>
> >> wrote:
> >>>
> >>> From: Jackie Huang <jackie.hu...@windriver.com>
> >>>
> >>> We want to provide python libs by default, and some other
> >>> popular Linux distributions like redhat/fedora does the same.
> >> Has something changed? Is there anything in oe-core or meta-oe which
> >> now needs boost python support enabled?
> >
> > Does it even actually build on all arches? >
> > I'm rather behind with patch review right now as people are putting so
> > many patches out there with what seems like minimal testing and
> > expecting me/Ross and the autobuilder to figure out the problems for
> > them.
> >
> > Each time one fails, it blocks the queue with the rest of them in and I
> > have to retest until I get something clean.
> >
> > Testing this change is quite a way down my priority list I'm afraid.
> >
> 
> Maybe this is better done in our distro configuration.
> 
> We're trying to minimize differences with oe-core and
> the boost python support doesn't seem to be much of an
> impact based on looking at logs rather than a having a
> detailed understanding of boost.
> 
> We've had this commit in our local branch since before:
> 
> CommitDate: Wed Dec 21 22:16:31 2016 -0800
> 
>  boost: add python to default PACKAGECONFIG options
> 
>  We want to provide python libs by default, and some other
>  popular Linux distributions like redhat/fedora does the same.
> 
>  (LOCAL REV: NOT UPSTREAM) -- sent to oe-core on 20160930
> 
> so it certainly builds for all qemu* for glibc configurations.
> 
> I'll see if we can add musl builds to our automated builds tonight.
> 
> Jackie,
> 
> Did/Can you build for musl?

No, I didn't build for musl yet, but yes, I can and will do the test with musl
and fix issues as needed.

> Do you have any idea of the impact of this config on users that are not
> interested in the python interface with boost?

I don't think there is any impact, each library is packaged into a separate
package named with boost-

> What's the additional cost in compile time?

A quick test indicates that it's less than 1 second:

$ grep -r 'Elapsed time:' 20170823073306/boost-1.64.0-r0/do_compile 
20170823075302/boost-1.64.0-r0/do_compile
20170823073306/boost-1.64.0-r0/do_compile:Elapsed time: 50.96 seconds
20170823075302/boost-1.64.0-r0/do_compile:Elapsed time: 51.63 seconds

Thanks,
Jackie

> 
> 
> 
> There certainly are a rush of package updates and other changes
> coming in; apologies for the lack of warning and late arrivals.
> Other than doing more testing and explaining what tests were done,
> what else can we do to help?
> 
> 
> ../Randy
> 
> 
> > Cheers,
> >
> > Richard
> >
> >
> 
> 
> --
> # 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

Re: [OE-core] [PATCH 0/2] rootfs-postcommands: split ssh_allow_empty_password

[Huang, Jie (Jackie)]

Ping again.

I don't see any comment or rejection on this, do I miss anything?

Thanks,
Jackie

> -Original Message-
> From: Huang, Jie (Jackie)
> Sent: Tuesday, July 25, 2017 14:34
> To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
> Subject: RE: [OE-core] [PATCH 0/2] rootfs-postcommands: split
> ssh_allow_empty_password
> 
> Ping.
> 
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> > jackie.hu...@windriver.com
> > Sent: Friday, June 30, 2017 14:30
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH 0/2] rootfs-postcommands: split
> > ssh_allow_empty_password
> >
> > From: Jackie Huang <jackie.hu...@windriver.com>
> >
> > --
> > The following changes since commit
> > de7914954571ea8e717f56b6d6df13157b0973bc:
> >
> >   scripts/contrib/patchreview: add new script (2017-06-29 13:01:32 +0100)
> >
> > are available in the git repository at:
> >
> >   git://git.pokylinux.org/poky-contrib.git jhuang0/d_ssh-allow-
> empty_170630_0
> >   http://git.pokylinux.org/cgit.cgi//log/?h=jhuang0/d_ssh-allow-
> > empty_170630_0
> >
> > Jackie Huang (2):
> >   dropbear: add default config file to disable root login
> >   rootfs-postcommands: split ssh_allow_empty_password
> >
> >  meta/classes/image.bbclass |  2 +-
> >  meta/classes/rootfs-postcommands.bbclass   | 25
> +++-
> > --
> >  meta/recipes-core/dropbear/dropbear.inc|  3 +++
> >  .../dropbear/dropbear/dropbear.default |  2 ++
> >  4 files changed, 28 insertions(+), 4 deletions(-)
> >  create mode 100644 meta/recipes-core/dropbear/dropbear/dropbear.default
> >
> > --
> > 2.11.0
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] debianutils: set higher priority than busybox for run-parts

[Huang, Jie (Jackie)]

I will rebase and send v2 since debianutils is already updated to 4.8.1.1

Thanks,
Jackie

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> jackie.hu...@windriver.com
> Sent: Tuesday, July 25, 2017 16:06
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] debianutils: set higher priority than busybox for 
> run-
> parts
> 
> From: Jackie Huang 
> 
> debianutils-run-parts should have higher priority than
> busybox (which is 50), so set the priority to 60 for
> debianutils-run-parts.
> 
> Signed-off-by: Jackie Huang 
> ---
>  meta/recipes-support/debianutils/debianutils_4.8.1.bb | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-support/debianutils/debianutils_4.8.1.bb
> b/meta/recipes-support/debianutils/debianutils_4.8.1.bb
> index 54c345ea25..0529a50983 100644
> --- a/meta/recipes-support/debianutils/debianutils_4.8.1.bb
> +++ b/meta/recipes-support/debianutils/debianutils_4.8.1.bb
> @@ -38,6 +38,8 @@ RDEPENDS_${PN} += "${PN}-run-parts"
> 
>  ALTERNATIVE_PRIORITY="30"
>  ALTERNATIVE_${PN} = "add-shell installkernel remove-shell savelog tempfile
> which"
> +
> +ALTERNATIVE_PRIORITY_${PN}-run-parts = "60"
>  ALTERNATIVE_${PN}-run-parts = "run-parts"
> 
>  ALTERNATIVE_${PN}-doc = "which.1"
> --
> 2.11.0
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] ncurses: add SYSROOT_DESTDIR for siteconfig_gencache

[Huang, Jie (Jackie)]

> > >
> > >
> > > On 31 May 2017 at 09:27,  wrote:
> > > +EXTRASITECONFIG = "CFLAGS='${CFLAGS} -
> > I${SYSROOT_DESTDIR}${includedir}'"
> > >
> > > Why is this ncurses specific, it sounds like something which will impact 
> > > all
> users
> > of siteconfig?
> 
> Ping.
> 
> Is my explanation clear enough? What's the suggestion if it's not acceptable?

Ping.

Thanks,
Jackie

> 
> Thanks,
> Jackie
> 
> >
> > My original issue is not ncurses specific, that is:
> > After switching to RSS, the siteconfig cache files in ACLOCALDIR setup by
> > autotools.bbclass was dropped, so searching
> > the path ACLOCALDIR for siteconfig files ended up with nothing, which caused
> > some package (like openhpi) fail to configure,
> > so the "PATCH 2/2" change it back to search SITECONFIG_SYSROOTCACHE.
> >
> > But I met the second issue after the that:
> > util-linux depends on ncurses but the siteinfo in ncurses_config which is
> > populated to SITECONFIG_SYSROOTCACHE  is not correct:
> > ac_cv_header_curses_h=${ac_cv_header_curses_h=no}
> > ac_cv_header_ncurses_h=${ac_cv_header_ncurses_h=no}
> >
> > then it fails to build (it should be the same issue for other package that 
> > depend
> > on ncurses), so this patch is needed.
> > And the patch will only impact the packages that depend on ncurses, for 
> > those
> > without dependency on ncurses, there
> > is no ncurses_config at all in their own recipe-sysroot.
> >
> > Thanks,
> > Jackie
> >
> > >
> > > Ross
> > >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] rootfs-postcommands: split ssh_allow_empty_password

[Huang, Jie (Jackie)]

Ping.

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> jackie.hu...@windriver.com
> Sent: Friday, June 30, 2017 14:30
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 0/2] rootfs-postcommands: split
> ssh_allow_empty_password
> 
> From: Jackie Huang 
> 
> --
> The following changes since commit
> de7914954571ea8e717f56b6d6df13157b0973bc:
> 
>   scripts/contrib/patchreview: add new script (2017-06-29 13:01:32 +0100)
> 
> are available in the git repository at:
> 
>   git://git.pokylinux.org/poky-contrib.git jhuang0/d_ssh-allow-empty_170630_0
>   http://git.pokylinux.org/cgit.cgi//log/?h=jhuang0/d_ssh-allow-
> empty_170630_0
> 
> Jackie Huang (2):
>   dropbear: add default config file to disable root login
>   rootfs-postcommands: split ssh_allow_empty_password
> 
>  meta/classes/image.bbclass |  2 +-
>  meta/classes/rootfs-postcommands.bbclass   | 25 +++-
> --
>  meta/recipes-core/dropbear/dropbear.inc|  3 +++
>  .../dropbear/dropbear/dropbear.default |  2 ++
>  4 files changed, 28 insertions(+), 4 deletions(-)
>  create mode 100644 meta/recipes-core/dropbear/dropbear/dropbear.default
> 
> --
> 2.11.0
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] ncurses: add SYSROOT_DESTDIR for siteconfig_gencache

[Huang, Jie (Jackie)]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Huang, Jie (Jackie)
> Sent: Friday, June 16, 2017 09:58
> To: BURTON, ROSS
> Cc: OE-core
> Subject: Re: [OE-core] [PATCH 1/2] ncurses: add SYSROOT_DESTDIR for
> siteconfig_gencache
> 
> >
> >
> > From: Burton, Ross [mailto:ross.bur...@intel.com]
> > Sent: Thursday, June 15, 2017 20:31
> > To: Huang, Jie (Jackie)
> > Cc: OE-core
> > Subject: Re: [OE-core] [PATCH 1/2] ncurses: add SYSROOT_DESTDIR for
> siteconfig_gencache
> >
> >
> > On 31 May 2017 at 09:27, <jackie.hu...@windriver.com> wrote:
> > +EXTRASITECONFIG = "CFLAGS='${CFLAGS} -
> I${SYSROOT_DESTDIR}${includedir}'"
> >
> > Why is this ncurses specific, it sounds like something which will impact 
> > all users
> of siteconfig?

Ping.

Is my explanation clear enough? What's the suggestion if it's not acceptable?

Thanks,
Jackie

> 
> My original issue is not ncurses specific, that is:
> After switching to RSS, the siteconfig cache files in ACLOCALDIR setup by
> autotools.bbclass was dropped, so searching
> the path ACLOCALDIR for siteconfig files ended up with nothing, which caused
> some package (like openhpi) fail to configure,
> so the "PATCH 2/2" change it back to search SITECONFIG_SYSROOTCACHE.
> 
> But I met the second issue after the that:
> util-linux depends on ncurses but the siteinfo in ncurses_config which is
> populated to SITECONFIG_SYSROOTCACHE  is not correct:
> ac_cv_header_curses_h=${ac_cv_header_curses_h=no}
> ac_cv_header_ncurses_h=${ac_cv_header_ncurses_h=no}
> 
> then it fails to build (it should be the same issue for other package that 
> depend
> on ncurses), so this patch is needed.
> And the patch will only impact the packages that depend on ncurses, for those
> without dependency on ncurses, there
> is no ncurses_config at all in their own recipe-sysroot.
> 
> Thanks,
> Jackie
> 
> >
> > Ross
> >
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] ncurses: add SYSROOT_DESTDIR for siteconfig_gencache

[Huang, Jie (Jackie)]

> 
> 
> From: Burton, Ross [mailto:ross.bur...@intel.com] 
> Sent: Thursday, June 15, 2017 20:31
> To: Huang, Jie (Jackie)
> Cc: OE-core
> Subject: Re: [OE-core] [PATCH 1/2] ncurses: add SYSROOT_DESTDIR for 
> siteconfig_gencache
> 
> 
> On 31 May 2017 at 09:27, <jackie.hu...@windriver.com> wrote:
> +EXTRASITECONFIG = "CFLAGS='${CFLAGS} -I${SYSROOT_DESTDIR}${includedir}'"
> 
> Why is this ncurses specific, it sounds like something which will impact all 
> users of siteconfig?

My original issue is not ncurses specific, that is:
After switching to RSS, the siteconfig cache files in ACLOCALDIR setup by 
autotools.bbclass was dropped, so searching
the path ACLOCALDIR for siteconfig files ended up with nothing, which caused 
some package (like openhpi) fail to configure, 
so the "PATCH 2/2" change it back to search SITECONFIG_SYSROOTCACHE.

But I met the second issue after the that:
util-linux depends on ncurses but the siteinfo in ncurses_config which is 
populated to SITECONFIG_SYSROOTCACHE  is not correct:
ac_cv_header_curses_h=${ac_cv_header_curses_h=no}
ac_cv_header_ncurses_h=${ac_cv_header_ncurses_h=no}

then it fails to build (it should be the same issue for other package that 
depend on ncurses), so this patch is needed.
And the patch will only impact the packages that depend on ncurses, for those 
without dependency on ncurses, there 
is no ncurses_config at all in their own recipe-sysroot.

Thanks,
Jackie

> 
> Ross
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] siteinfo: fix siteinfo_get_files to work with RSS

[Huang, Jie (Jackie)]

Ping.

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> jackie.hu...@windriver.com
> Sent: Wednesday, May 31, 2017 16:27
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 0/2] siteinfo: fix siteinfo_get_files to work with 
> RSS
> 
> From: Jackie Huang 
> 
> --
> The following changes since commit
> 4aa6cdfe9f069ecd976c1257702fe8ff28c57f07:
> 
>   tune-mips32*.inc: use consistent comments across all three .inc files 
> (2017-05-
> 30 10:14:33 +0100)
> 
> are available in the git repository at:
> 
>   git://git.pokylinux.org/poky-contrib.git jhuang0/d_siteinfo_170531_0
>   http://git.pokylinux.org/cgit.cgi//log/?h=jhuang0/d_siteinfo_170531_0
> 
> Jackie Huang (2):
>   ncurses: add SYSROOT_DESTDIR for siteconfig_gencache
>   siteinfo: fix siteinfo_get_files to work with RSS
> 
>  meta/classes/autotools.bbclass|  2 +-
>  meta/classes/siteinfo.bbclass | 15 ---
>  meta/recipes-core/ncurses/ncurses.inc |  2 ++
>  3 files changed, 7 insertions(+), 12 deletions(-)
> 
> --
> 2.11.0
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] kmscube: add opengl to REQUIRED_DISTRO_FEATURES

[Huang, Jie (Jackie)]

Sorry I didn't notice that the v1 has been merged, please ignore this.

Thanks,
Jackie

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> jackie.hu...@windriver.com
> Sent: Wednesday, June 07, 2017 09:51
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH v2] kmscube: add opengl to
> REQUIRED_DISTRO_FEATURES
> 
> From: Jackie Huang 
> 
> kmscube depends on virtual/libgles2, virtual/egl and gstreamer1.0
> which require opengl in DISTRO_FEATURES.
> 
> Signed-off-by: Jackie Huang 
> ---
>  meta/recipes-graphics/kmscube/kmscube_git.bb | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-graphics/kmscube/kmscube_git.bb b/meta/recipes-
> graphics/kmscube/kmscube_git.bb
> index 0ec5b2a7fa..9050671ab1 100644
> --- a/meta/recipes-graphics/kmscube/kmscube_git.bb
> +++ b/meta/recipes-graphics/kmscube/kmscube_git.bb
> @@ -11,4 +11,6 @@ SRC_URI =
> "git://anongit.freedesktop.org/mesa/kmscube;branch=master;protocol=git
> 
>  S = "${WORKDIR}/git"
> 
> -inherit autotools pkgconfig
> +inherit autotools pkgconfig distro_features_check
> +
> +REQUIRED_DISTRO_FEATURES = "opengl"
> --
> 2.11.0
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kmscube: add opengl to REQUIRED_DISTRO_FEATURES

[Huang, Jie (Jackie)]

> -Original Message-
> From: Denys Dmytriyenko [mailto:de...@denix.org]
> Sent: Tuesday, June 06, 2017 04:39
> To: Huang, Jie (Jackie)
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] kmscube: add opengl to
> REQUIRED_DISTRO_FEATURES
> 
> On Mon, Jun 05, 2017 at 03:05:57PM +0800, jackie.hu...@windriver.com
> wrote:
> > From: Jackie Huang <jackie.hu...@windriver.com>
> >
> > kmscube depends on virtual/libgles2, virtual/egl (provided
> > by mesa) and gstreamer1.0 which require opengl in DISTRO_FEATURES.
> 
> libgles2 and egl are not only provided by mesa!

Yes, I aware of that, but I only found that they are provided by mesa in oe-core
and mesa is the PREFERRED_PROVIDER in oe-core, so I just mentioned mesa.

Do you think I should mention other providers from other layers or not mention
the provider at all?

Thanks,
Jackie

> 
> 
> > Signed-off-by: Jackie Huang <jackie.hu...@windriver.com>
> > ---
> >  meta/recipes-graphics/kmscube/kmscube_git.bb | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-graphics/kmscube/kmscube_git.bb b/meta/recipes-
> graphics/kmscube/kmscube_git.bb
> > index 0ec5b2a7fa..9050671ab1 100644
> > --- a/meta/recipes-graphics/kmscube/kmscube_git.bb
> > +++ b/meta/recipes-graphics/kmscube/kmscube_git.bb
> > @@ -11,4 +11,6 @@ SRC_URI =
> "git://anongit.freedesktop.org/mesa/kmscube;branch=master;protocol=git
> >
> >  S = "${WORKDIR}/git"
> >
> > -inherit autotools pkgconfig
> > +inherit autotools pkgconfig distro_features_check
> > +
> > +REQUIRED_DISTRO_FEATURES = "opengl"
> > --
> > 2.11.0
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ltp: fix an incorrect macro checking

[Huang, Jie (Jackie)]

Got it, thanks!

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, April 18, 2017 18:03
To: Huang, Jie (Jackie)
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] ltp: fix an incorrect macro checking


On 18 April 2017 at 10:12, Huang, Jie (Jackie) 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
It's not merged yet, and I don't see any rejection on it.

Slipped through the net, we're very close to M4 so this may not make it into 
2.3 but if not it can be backported.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] systemd: fixes for debug-shell service

[Huang, Jie (Jackie)]

Ping.

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> jackie.hu...@windriver.com
> Sent: Wednesday, February 22, 2017 14:42
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 0/2] systemd: fixes for debug-shell service
> 
> From: Jackie Huang 
> 
> --
> The following changes since commit
> e436a6398684d2872cb541f1cfb0f67b3618d15a:
> 
>   layer.conf: bump version for change in eSDK selftest behaviour (2017-02-19
> 09:39:03 -0800)
> 
> are available in the git repository at:
> 
>   git://git.pokylinux.org/poky-contrib.git jhuang0/d_debug-shell_170222_1
>   http://git.pokylinux.org/cgit.cgi//log/?h=jhuang0/d_debug-shell_170222_1
> 
> Jackie Huang (2):
>   initscripts: split sushell into sub package
>   systemd: add dependency on initscripts-sushell for selinux
> 
>  meta/recipes-core/initscripts/initscripts_1.0.bb | 5 +++--
>  meta/recipes-core/systemd/systemd_232.bb | 2 +-
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> --
> 2.8.3
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ltp: fix an incorrect macro checking

[Huang, Jie (Jackie)]

Ping. 

It's not merged yet, and I don't see any rejection on it.

Thanks,
Jackie

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> jackie.hu...@windriver.com
> Sent: Saturday, November 19, 2016 10:11
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] ltp: fix an incorrect macro checking
> 
> From: Jackie Huang 
> 
> The previous patch added a check but incorrectly
> change the elif to if, then it always return 0
> for cpuid if the machine is not __i386__
> 
> getcpu011  TFAIL  :  getcpu01.c:140: getcpu() returned wrong value 
> expected
> cpuid:7, returned value cpuid: 0
> 
> After this fix:
> getcpu011  TPASS  :  getcpu() returned proper cpuid:7, node id:0
> 
> Signed-off-by: Jackie Huang 
> ---
>  .../0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch  | 7 
> ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/meta/recipes-extended/ltp/ltp/0008-Check-if-__GLIBC_PREREQ-is-
> defined-before-using-it.patch b/meta/recipes-extended/ltp/ltp/0008-Check-if-
> __GLIBC_PREREQ-is-defined-before-using-it.patch
> index d123074..41f2623 100644
> --- a/meta/recipes-extended/ltp/ltp/0008-Check-if-__GLIBC_PREREQ-is-
> defined-before-using-it.patch
> +++ b/meta/recipes-extended/ltp/ltp/0008-Check-if-__GLIBC_PREREQ-is-
> defined-before-using-it.patch
> @@ -88,22 +88,19 @@ index c927512..921b107 100644
> 
>   void cleanup(void);
>   void setup(void);
> -@@ -164,9 +172,14 @@ static inline int getcpu(unsigned *cpu_id, unsigned
> *node_id,
> +@@ -164,7 +172,11 @@ static inline int getcpu(unsigned *cpu_id, unsigned
> *node_id,
>   {
>   #if defined(__i386__)
>   return syscall(318, cpu_id, node_id, cache_struct);
>  -#elif __GLIBC_PREREQ(2,6)
> -+#if defined(__GLIBC__)
> ++#elif defined(__GLIBC__)
>  +#if __GLIBC_PREREQ(2,6)
>  +*cpu_id = sched_getcpu();
>  +#endif
>  +#else
>   *cpu_id = sched_getcpu();
>   #endif
> -+#endif
>   return 0;
> - }
> -
>  @@ -191,15 +204,20 @@ unsigned int set_cpu_affinity(void)
>   cpu_set_t *set;
>   size_t size;
> --
> 2.8.3
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] glibc: add -fno-builtin-strlen when not using -O2

[Huang, Jie (Jackie)]

> -Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: Tuesday, December 13, 2016 5:17 PM
> To: Huang, Jie (Jackie)
> Cc: Khem Raj; Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH] glibc: add -fno-builtin-strlen when not using 
> -O2
> 
> On Mon, Dec 12, 2016 at 9:14 PM, Huang, Jie (Jackie)
> <jackie.hu...@windriver.com> wrote:
> >> From: Andre McCurdy [mailto:armccu...@gmail.com]
> >> For reference, here's the patch I've been using. It's a slightly more
> >> generic fix than the one in the KDE bug report.
> >
> > Thanks, It's a better patch and I will take it and send as v2 of this issue 
> > if you're
> > not going to send it yourself, is it fine for you and could you provide 
> > extra info
> > for the patch header like, upstream-status, written by or Signed-off-by?
> 
> Sure. I forget why I didn't submit this at the time. The full patch is:

Thanks, I rebased the patch since valgrind updated  and sent v2 for this issue:

[OE-core] [v2][PATCH] valgrind: make ld-XXX.so strlen intercept optional

Thanks,
Jackie


> 
> From d34e2a50ca5493f5a0ce9ccad83a36ac33689266 Mon Sep 17 00:00:00 2001
> From: Andre McCurdy <armccu...@gmail.com>
> Date: Fri, 12 Feb 2016 18:22:12 -0800
> Subject: [PATCH] make ld-XXX.so strlen intercept optional
> 
> Hack: Depending on how glibc was compiled (e.g. optimised for size or
> built with _FORTIFY_SOURCE enabled) the strlen symbol might not be
> found in ld-XXX.so. Therefore although we should still try to
> intercept it, don't make it mandatory to do so.
> 
> Upstream-Status: Inappropriate
> 
> Signed-off-by: Andre McCurdy <armccu...@gmail.com>
> ---
>  coregrind/m_redir.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/coregrind/m_redir.c b/coregrind/m_redir.c
> index 7e4df8d..640a346 100644
> --- a/coregrind/m_redir.c
> +++ b/coregrind/m_redir.c
> @@ -1220,7 +1220,18 @@ static void add_hardwired_spec (const  HChar*
> sopatt, const HChar* fnpatt,
> spec->from_fnpatt = CONST_CAST(HChar *,fnpatt);
> spec->to_addr = to_addr;
> spec->isWrap  = False;
> -   spec->mandatory   = mandatory;
> +
> +   /* Hack: Depending on how glibc was compiled (e.g. optimised for size or
> +  built with _FORTIFY_SOURCE enabled) the strlen symbol might not be 
> found.
> +  Therefore although we should still try to intercept it, don't make it
> +  mandatory to do so. We over-ride "mandatory" here to avoid the need to
> +  patch the many different architecture specific callers to
> +  add_hardwired_spec(). */
> +   if (0==VG_(strcmp)("strlen", fnpatt))
> +  spec->mandatory = NULL;
> +   else
> +  spec->mandatory = mandatory;
> +
> /* VARIABLE PARTS */
> spec->mark= False; /* not significant */
> spec->done= False; /* not significant */
> --
> 1.9.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] glibc: add -fno-builtin-strlen when not using -O2

[Huang, Jie (Jackie)]

> -Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: Monday, December 12, 2016 5:55 PM
> To: Huang, Jie (Jackie)
> Cc: Khem Raj; Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH] glibc: add -fno-builtin-strlen when not using 
> -O2
> 
> On Sun, Dec 11, 2016 at 11:41 PM, Huang, Jie (Jackie)
> <jackie.hu...@windriver.com> wrote:
> >> -Original Message-
> >> From: Khem Raj [mailto:raj.k...@gmail.com]
> >> Sent: Monday, December 12, 2016 2:37 PM
> >> To: Huang, Jie (Jackie)
> >> Cc: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [PATCH] glibc: add -fno-builtin-strlen when not 
> >> using -O2
> >>
> >> On Sun, Dec 11, 2016 at 9:42 PM,  <jackie.hu...@windriver.com> wrote:
> >> > From: Jackie Huang <jackie.hu...@windriver.com>
> >> >
> >> > The strlen will be inlined when compile with -O, -O1 or -Os,
> >> > so there is no symbol for strlen in ld-linux-x86-64.so.2,
> >> > causing a fatal error in valgrind:
> >> >
> >> > valgrind: Fatal error at startup: a function redirection
> >> > valgrind: which is mandatory for this platform-tool combination
> >> > valgrind: cannot be set up. Details of the redirection are:
> >> > valgrind:
> >> > valgrind: A must-be-redirected function
> >> > valgrind: whose name matches the pattern: strlen
> >> > valgrind: in an object with soname matching: ld-linux-x86-64.so.2
> >> >
> >> > so add -fno-builtin-strlen when compile with -O, -O1 or -Os.
> >>
> >> This is a bug in valgrind, I read the same on forums. KDE has proposed a 
> >> fix
> >> https://bugsfiles.kde.org/attachment.cgi?id=82043
> >> can you check if this fixes the issue
> >
> > Thanks, I will check that and change to patch for valgrind if it works.
> 
> For reference, here's the patch I've been using. It's a slightly more
> generic fix than the one in the KDE bug report.

Thanks, It's a better patch and I will take it and send as v2 of this issue if 
you're
not going to send it yourself, is it fine for you and could you provide extra 
info
for the patch header like, upstream-status, written by or Signed-off-by?

Thanks,
Jackie

> 
> diff --git a/coregrind/m_redir.c b/coregrind/m_redir.c
> index 7e4df8d..640a346 100644
> --- a/coregrind/m_redir.c
> +++ b/coregrind/m_redir.c
> @@ -1220,7 +1220,18 @@ static void add_hardwired_spec (const  HChar*
> sopatt, const HChar* fnpatt,
> spec->from_fnpatt = CONST_CAST(HChar *,fnpatt);
> spec->to_addr = to_addr;
> spec->isWrap  = False;
> -   spec->mandatory   = mandatory;
> +
> +   /* Hack: Depending on how glibc was compiled (e.g. optimised for size or
> +  built with _FORTIFY_SOURCE enabled) the strlen symbol might not be 
> found.
> +  Therefore although we should still try to intercept it, don't make it
> +  mandatory to do so. We over-ride "mandatory" here to avoid the need to
> +  patch the many different architecture specific callers to
> +  add_hardwired_spec(). */
> +   if (0==VG_(strcmp)("strlen", fnpatt))
> +  spec->mandatory = NULL;
> +   else
> +  spec->mandatory = mandatory;
> +
> /* VARIABLE PARTS */
> spec->mark= False; /* not significant */
> spec->done= False; /* not significant */
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] glibc: add -fno-builtin-strlen when not using -O2

[Huang, Jie (Jackie)]

> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Monday, December 12, 2016 2:37 PM
> To: Huang, Jie (Jackie)
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH] glibc: add -fno-builtin-strlen when not using 
> -O2
> 
> On Sun, Dec 11, 2016 at 9:42 PM,  <jackie.hu...@windriver.com> wrote:
> > From: Jackie Huang <jackie.hu...@windriver.com>
> >
> > The strlen will be inlined when compile with -O, -O1 or -Os,
> > so there is no symbol for strlen in ld-linux-x86-64.so.2,
> > causing a fatal error in valgrind:
> >
> > valgrind: Fatal error at startup: a function redirection
> > valgrind: which is mandatory for this platform-tool combination
> > valgrind: cannot be set up. Details of the redirection are:
> > valgrind:
> > valgrind: A must-be-redirected function
> > valgrind: whose name matches the pattern: strlen
> > valgrind: in an object with soname matching: ld-linux-x86-64.so.2
> >
> > so add -fno-builtin-strlen when compile with -O, -O1 or -Os.
> 
> This is a bug in valgrind, I read the same on forums. KDE has proposed a fix
> https://bugsfiles.kde.org/attachment.cgi?id=82043
> can you check if this fixes the issue

Thanks, I will check that and change to patch for valgrind if it works.

Thanks,
Jackie

> 
> >
> > Signed-off-by: Jackie Huang <jackie.hu...@windriver.com>
> > ---
> >  meta/recipes-core/glibc/glibc.inc | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-core/glibc/glibc.inc 
> > b/meta/recipes-core/glibc/glibc.inc
> > index e85c704..7f3e0f6 100644
> > --- a/meta/recipes-core/glibc/glibc.inc
> > +++ b/meta/recipes-core/glibc/glibc.inc
> > @@ -16,8 +16,8 @@ python () {
> >  if opt_effective == "-O0":
> >  bb.fatal("%s can't be built with %s, try -O1 instead" % 
> > (d.getVar('PN', True), opt_effective))
> >  if opt_effective in ("-O", "-O1", "-Os"):
> > -bb.note("%s doesn't build cleanly with %s, adding -Wno-error to 
> > SELECTED_OPTIMIZATION" %
> (d.getVar('PN', True), opt_effective))
> > -d.appendVar("SELECTED_OPTIMIZATION", " -Wno-error")
> > +bb.note("%s doesn't build cleanly with %s, adding -Wno-error and 
> > -fno-builtin-strlen to
> SELECTED_OPTIMIZATION" % (d.getVar('PN', True), opt_effective))
> > +d.appendVar("SELECTED_OPTIMIZATION", " -Wno-error 
> > -fno-builtin-strlen")
> >  }
> >
> >  # siteconfig.bbclass runs configure which needs a working compiler
> > --
> > 2.8.3
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] gcr: add missing dependencies for vapi

[Huang, Jie (Jackie)]

Yes, I will re-send the patch.

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Saturday, December 10, 2016 6:43 PM
To: Huang, Jie (Jackie)
Cc: OE-core
Subject: Re: [OE-core] [PATCH] gcr: add missing dependencies for vapi


On 10 December 2016 at 02:56, 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
+Upstream-Status: Submitted [https://github.com/GNOME/gcr/pull/4]

Did you get the message that GNOME doesn't take pull requests at github?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] classes/cpan-base: fix for PERLVERSION

[Huang, Jie (Jackie)]

Yes, I can fix it in the recipe that uses PERLVERSION as an alternative.

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Monday, December 05, 2016 11:34 PM
To: Huang, Jie (Jackie)
Cc: OE-core
Subject: Re: [OE-core] [PATCH] classes/cpan-base: fix for PERLVERSION


On 9 November 2016 at 05:51, 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
-PERLVERSION := "${@get_perl_version(d)}"
+PERLVERSION = "${@get_perl_version(d)}"

This uses := as the get_perl_version is a non-trivial amount of python which 
doesn't need to be re-evaluated all the time.  Have you looked at how bad the 
performance hit is, and whether there is an alternative?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] ppp: fix building with linux-4.8

[Huang, Jie (Jackie)]

> -Original Message-
> From: Andreas Oberritter [mailto:o...@opendreambox.org]
> Sent: Friday, October 21, 2016 10:01 PM
> To: Huang, Jie (Jackie)
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 2/2] ppp: fix building with linux-4.8
> 
> Dear Jackie,
> 
> this patch broke compilation with linux-libc-headers 4.4, present in
> morty, due to use of incomplete types.

I didn't realize 4.4 is still be used, sorry about that, feel free to send
patch to fix it if you have one already, if not, I will fix it later as 
follow-up.

Thanks,
Jackie

> 
> Regards,
> Andreas
> 
> 
> On 14.10.2016 02:50, jackie.hu...@windriver.com wrote:
> > From: Jackie Huang <jackie.hu...@windriver.com>
> >
> > Fix a build error when using the linux-4.8 headers that results in:
> >
> > In file included from pppoe.h:87:0,
> >  from plugin.c:29:
> > ../usr/include/netinet/in.h:211:8: note: originally defined here
> >  struct in6_addr
> > ^~~~
> > In file included from ../usr/include/linux/if_pppol2tp.h:20:0,
> >  from ../usr/include/linux/if_pppox.h:26,
> >  from plugin.c:52:
> > ../usr/include/linux/in6.h:49:8: error: redefinition of 'struct 
> > sockaddr_in6'
> >  struct sockaddr_in6 {
> > ^~~~
> >
> > Signed-off-by: Jackie Huang <jackie.hu...@windriver.com>
> > ---
> >  .../ppp/ppp/ppp-fix-building-with-linux-4.8.patch  | 44 
> > ++
> >  meta/recipes-connectivity/ppp/ppp_2.4.7.bb |  1 +
> >  2 files changed, 45 insertions(+)
> >  create mode 100644 
> > meta/recipes-connectivity/ppp/ppp/ppp-fix-building-with-linux-4.8.patch
> >
> > diff --git 
> > a/meta/recipes-connectivity/ppp/ppp/ppp-fix-building-with-linux-4.8.patch
> b/meta/recipes-connectivity/ppp/ppp/ppp-fix-building-with-linux-4.8.patch
> > new file mode 100644
> > index 000..f77b0de
> > --- /dev/null
> > +++ 
> > b/meta/recipes-connectivity/ppp/ppp/ppp-fix-building-with-linux-4.8.patch
> > @@ -0,0 +1,44 @@
> > +From 3da19af53e2eee2e77b456cfbb9d633b06656d38 Mon Sep 17 00:00:00 2001
> > +From: Jackie Huang <jackie.hu...@windriver.com>
> > +Date: Thu, 13 Oct 2016 13:41:43 +0800
> > +Subject: [PATCH] ppp: fix building with linux-4.8
> > +
> > +Fix a build error when using the linux-4.8 headers that results in:
> > +
> > +In file included from pppoe.h:87:0,
> > + from plugin.c:29:
> > +../usr/include/netinet/in.h:211:8: note: originally defined here
> > + struct in6_addr
> > +^~~~
> > +In file included from ../usr/include/linux/if_pppol2tp.h:20:0,
> > + from ../usr/include/linux/if_pppox.h:26,
> > + from plugin.c:52:
> > +../usr/include/linux/in6.h:49:8: error: redefinition of 'struct 
> > sockaddr_in6'
> > + struct sockaddr_in6 {
> > +^~~~
> > +
> > +Upstream-Status: Submitted [1]
> > +
> > +[1] https://github.com/paulusmack/ppp/pull/69
> > +
> > +Signed-off-by: Jackie Huang <jackie.hu...@windriver.com>
> > +---
> > + pppd/plugins/rp-pppoe/pppoe.h | 2 +-
> > + 1 file changed, 1 insertion(+), 1 deletion(-)
> > +
> > +diff --git a/pppd/plugins/rp-pppoe/pppoe.h b/pppd/plugins/rp-pppoe/pppoe.h
> > +index 9ab2eee..96d2794 100644
> > +--- a/pppd/plugins/rp-pppoe/pppoe.h
> >  b/pppd/plugins/rp-pppoe/pppoe.h
> > +@@ -84,7 +84,7 @@ typedef unsigned long UINT32_t;
> > + #include 
> > + #endif
> > +
> > +-#include 
> > ++#include 
> > +
> > + #ifdef HAVE_NETINET_IF_ETHER_H
> > + #include 
> > +--
> > +2.8.3
> > +
> > diff --git a/meta/recipes-connectivity/ppp/ppp_2.4.7.bb b/meta/recipes-
> connectivity/ppp/ppp_2.4.7.bb
> > index 4437b5c..56dbd98 100644
> > --- a/meta/recipes-connectivity/ppp/ppp_2.4.7.bb
> > +++ b/meta/recipes-connectivity/ppp/ppp_2.4.7.bb
> > @@ -30,6 +30,7 @@ SRC_URI = "http://ppp.samba.org/ftp/ppp/ppp-${PV}.tar.gz \
> > file://0001-ppp-Fix-compilation-errors-in-Makefile.patch \
> > file://ppp@.service \
> > file://fix-CVE-2015-3310.patch \
> > +   file://ppp-fix-building-with-linux-4.8.patch \
> >  "
> >
> >  SRC_URI_append_libc-musl = "\
> >

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] linux-libc-headers: if_tunnel: remove include of if/ip/in6.h

[Huang, Jie (Jackie)]

> -Original Message-
> From: MacLeod, Randy
> Sent: Friday, October 07, 2016 4:54 AM
> To: Bruce Ashfield; Khem Raj; Huang, Jie (Jackie)
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH] linux-libc-headers: if_tunnel: remove include 
> of if/ip/in6.h
> 
> On 2016-10-03 08:27 PM, Bruce Ashfield wrote:
> >
> > It's something we could drop in the future, but these are mods that have
> > been done since -rc4, and could very well be undone if they start
> > breaking things like this.
> >
> > The alternative is to try and fix the userspace applications, but I
> > currently don't see a fast way to do that (and I'm now officially on
> > vacation).
> >
> 
> I've sent a fix to the net-tools list:
> 
> https://sourceforge.net/p/net-tools/mailman/net-tools-devel/?viewmonth=201610
> 
> Jackie will be back at work on Saturday and he'll revert
> Bruce's change, test all qemu builds and boot an image
> to test iptunnel before sending a patch to the list.

I just sent patches for this to the list.

Thanks,
Jackie

> 
> In oe-core-2.3, we should probably drop net-tools completely or
> at least from packagegroup-core-full-cmdline.bb since iproute2
> replaces it:
>http://xmodulo.com/linux-tcpip-networking-net-tools-iproute2.html
> 
> ( and I'm now officially on vacation for a few days. :) )
> 
> 
> --
> # 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

Re: [OE-core] [PATCH 2/2 v2] boost: add support for additional boost libs

[Huang, Jie (Jackie)]

Yes, they are needed for the cases not handled by the python logic, or I met QA 
issues:

WARNING: Variable key FILES_${PN}-locale (${datadir}/locale) replaces original 
key FILES_boost-locale (${libdir}/libboost_locale.so.*)
WARNING: boost-1.61.0-r0 do_package: QA Issue: boost: Files/directories were 
installed but not shipped in any package:
  /usr/lib64/libboost_locale.so.1.61.0

For the graph parts, all libboost_graph* will go into PN-graph and 
PN-graph_parallel will be empty.

Thanks,
Jackie


From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, September 27, 2016 8:29 PM
To: Huang, Jie (Jackie)
Cc: OE-core
Subject: Re: [OE-core] [PATCH 2/2 v2] boost: add support for additional boost 
libs


On 26 September 2016 at 08:56, 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
+FILES_${PN}-graph = "${libdir}/libboost_graph.so.*"
+FILES_${PN}-graph_parallel = "${libdir}/libboost_graph_parallel.so.*"
+FILES_${PN}-locale = "${libdir}/libboost_locale.so.*"
+FILES_${PN}-mpi = "${libdir}/mpi.so ${libdir}/libboost_mpi*.so.*"

Are all of these really required?  Apart from ${libdir}/mpi.so they look like 
they'll be handled by the Python logic in the recipe.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2 v2] boost: add support for additional boost libs

[Huang, Jie (Jackie)]

> -Original Message-
> From: André Draszik [mailto:g...@andred.net]
> Sent: Tuesday, September 27, 2016 4:09 PM
> To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 2/2 v2] boost: add support for additional boost 
> libs
> 
> On Di, 2016-09-27 at 02:26 +, Huang, Jie (Jackie) wrote:
> >
> > >
> > > -Original Message-
> > > From: André Draszik [mailto:g...@andred.net]
> > > Sent: Monday, September 26, 2016 4:54 PM
> > > To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
> > > Subject: Re: [OE-core] [PATCH 2/2 v2] boost: add support for additional
> > > boost libs
> > >
> > > On Mo, 2016-09-26 at 15:56 +0800, jackie.hu...@windriver.com wrote:
> > > >
> > > > From: Jackie Huang <jackie.hu...@windriver.com>
> > > >
> > > > * Added libs:
> > > >   - container
> > > >   - context
> > > >   - coroutine
> > > >   - exception
> > > >   - graph_parallel
> > > >   - locale
> > > >   - math
> > > >   - mpi
> > > >   - wave
> > > >
> > > > * Add PACKAGECONFIG to add proper dependencies for:
> > > >   graph_parallel, locale, and mpi.
> > > >
> > > > * boost-mpi depends on mpich which is in meta-oe,
> > > >   and boost-graph_parallel depends on boost-mpi,
> > > >   so they are disabled by default, but can be enabled
> > > >   in a distro that needs them.
> > > >
> > > > * context and coroutine are added only for x86 and powerpc.
> > > >
> > > > Signed-off-by: Jackie Huang <jackie.hu...@windriver.com>
> > > > ---
> > > >  meta/recipes-support/boost/boost.inc | 33
> > > > ++-
> > > > --
> > > >  1 file changed, 30 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/meta/recipes-support/boost/boost.inc b/meta/recipes-
> > > > support/boost/boost.inc
> > > > index 5696b6a..7637a4e 100644
> > > > --- a/meta/recipes-support/boost/boost.inc
> > > > +++ b/meta/recipes-support/boost/boost.inc
> > > > @@ -8,11 +8,14 @@ ARM_INSTRUCTION_SET_armv5 = "arm"
> > > >  BOOST_LIBS = "\
> > > >     atomic \
> > > >     chrono \
> > > > +   container \
> > > >     date_time \
> > > > +   exception \
> > > >     filesystem \
> > > >     graph \
> > > >     iostreams \
> > > >     log \
> > > > +   math \
> > > >     program_options \
> > > >     random \
> > > >     regex \
> > > > @@ -22,12 +25,28 @@ BOOST_LIBS = "\
> > > >     timer \
> > > >     test \
> > > >     thread \
> > > > +   wave \
> > > >     "
> > > >
> > > > -# optional boost-python library
> > > > -PACKAGECONFIG ??= ""
> > > > +# only supported by x86 and powerpc
> > > > +BOOST_LIBS_append_x86 = " context coroutine"
> > > > +BOOST_LIBS_append_x86-64 = " context coroutine"
> > > > +BOOST_LIBS_append_powerpc = " context coroutine"
> > > > +
> > > > +# optional libraries
> > > > +PACKAGECONFIG ??= "locale"
> > > > +PACKAGECONFIG[locale] = ",,icu"
> > > > +PACKAGECONFIG[graph_parallel] = ",,,boost-mpi mpich"
> > > > +PACKAGECONFIG[mpi] = ",,mpich"
> > > >  PACKAGECONFIG[python] = ",,python python3"
> > > > -BOOST_LIBS += "${@bb.utils.contains('PACKAGECONFIG', 'python',
> > > > 'python
> > > > python3', '', d)}"
> > > > +
> > > > +BOOST_LIBS += "\
> > > > +${@bb.utils.contains('PACKAGECONFIG', 'locale', 'locale', '', d)}
> > > > \
> > > > +${@bb.utils.contains('PACKAGECONFIG', 'graph_parallel',
> > > > 'graph_parallel mpi', \
> > > > + bb.utils.contains('PACKAGECONFIG', 'mpi',
> > > > 'mpi',
> > > > '', d), d)} \
> > > > +${@bb.utils.contains('PACKAGECONFIG', 'python', 'python python3',
> > > > '',
> > > > d)} \
> > > > +"
> > >
> > > Rather than having two ways to define what packages to build,
> > > PACKAGECONFIG
> > > and BOOST_LIBS, where each of them only supports a different subset of
> >
> > I'm not a fan of this way, I just keep using the way it was.
> >
> > >
> > > boost's libraries, can we just have one, PACKAGECONFIG, and have it
> > > support
> > > all of the potential libraries?
> >
> > Yes, I think it's possible, but it will most likely end up with many empty
> > PACKAGECONFIG definitions like:
> > PACKAGECONFIG[atomic] = ",,,"
> > PACKAGECONFIG[chrono] = ",,,"
> > PACKAGECONFIG[container] = ",,,"
> > PACKAGECONFIG[date_time] = ",,,"
> > PACKAGECONFIG[exception] = ",,,"
> >
> > If you think it's a better way and no other objection, I think I will do
> > that in a
> > separate commit as follow-up.
> 
> I don't think you'd need empty PACKAGECONFIG[flag] definitions, see
> base.bbclass.

Could you be more specific? 

I think it's needed because I got QA issues without the definitions:

WARNING: boost-1.61.0-r0 do_configure: QA Issue: boost: invalid PACKAGECONFIG: 
atomic [invalid-packageconfig]

Thanks,
Jackie

> 
> Cheers,
> Andre'

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2 v2] boost: add support for additional boost libs

[Huang, Jie (Jackie)]

> -Original Message-
> From: André Draszik [mailto:g...@andred.net]
> Sent: Monday, September 26, 2016 4:54 PM
> To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 2/2 v2] boost: add support for additional boost 
> libs
> 
> On Mo, 2016-09-26 at 15:56 +0800, jackie.hu...@windriver.com wrote:
> > From: Jackie Huang <jackie.hu...@windriver.com>
> >
> > * Added libs:
> >   - container
> >   - context
> >   - coroutine
> >   - exception
> >   - graph_parallel
> >   - locale
> >   - math
> >   - mpi
> >   - wave
> >
> > * Add PACKAGECONFIG to add proper dependencies for:
> >   graph_parallel, locale, and mpi.
> >
> > * boost-mpi depends on mpich which is in meta-oe,
> >   and boost-graph_parallel depends on boost-mpi,
> >   so they are disabled by default, but can be enabled
> >   in a distro that needs them.
> >
> > * context and coroutine are added only for x86 and powerpc.
> >
> > Signed-off-by: Jackie Huang <jackie.hu...@windriver.com>
> > ---
> >  meta/recipes-support/boost/boost.inc | 33 ++-
> > --
> >  1 file changed, 30 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/recipes-support/boost/boost.inc b/meta/recipes-
> > support/boost/boost.inc
> > index 5696b6a..7637a4e 100644
> > --- a/meta/recipes-support/boost/boost.inc
> > +++ b/meta/recipes-support/boost/boost.inc
> > @@ -8,11 +8,14 @@ ARM_INSTRUCTION_SET_armv5 = "arm"
> >  BOOST_LIBS = "\
> >     atomic \
> >     chrono \
> > +   container \
> >     date_time \
> > +   exception \
> >     filesystem \
> >     graph \
> >     iostreams \
> >     log \
> > +   math \
> >     program_options \
> >     random \
> >     regex \
> > @@ -22,12 +25,28 @@ BOOST_LIBS = "\
> >     timer \
> >     test \
> >     thread \
> > +   wave \
> >     "
> >
> > -# optional boost-python library
> > -PACKAGECONFIG ??= ""
> > +# only supported by x86 and powerpc
> > +BOOST_LIBS_append_x86 = " context coroutine"
> > +BOOST_LIBS_append_x86-64 = " context coroutine"
> > +BOOST_LIBS_append_powerpc = " context coroutine"
> > +
> > +# optional libraries
> > +PACKAGECONFIG ??= "locale"
> > +PACKAGECONFIG[locale] = ",,icu"
> > +PACKAGECONFIG[graph_parallel] = ",,,boost-mpi mpich"
> > +PACKAGECONFIG[mpi] = ",,mpich"
> >  PACKAGECONFIG[python] = ",,python python3"
> > -BOOST_LIBS += "${@bb.utils.contains('PACKAGECONFIG', 'python', 'python
> > python3', '', d)}"
> > +
> > +BOOST_LIBS += "\
> > +${@bb.utils.contains('PACKAGECONFIG', 'locale', 'locale', '', d)} \
> > +${@bb.utils.contains('PACKAGECONFIG', 'graph_parallel',
> > 'graph_parallel mpi', \
> > + bb.utils.contains('PACKAGECONFIG', 'mpi', 'mpi',
> > '', d), d)} \
> > +${@bb.utils.contains('PACKAGECONFIG', 'python', 'python python3', '',
> > d)} \
> > +"
> 
> Rather than having two ways to define what packages to build, PACKAGECONFIG
> and BOOST_LIBS, where each of them only supports a different subset of

I'm not a fan of this way, I just keep using the way it was.

> boost's libraries, can we just have one, PACKAGECONFIG, and have it support
> all of the potential libraries?

Yes, I think it's possible, but it will most likely end up with many empty
PACKAGECONFIG definitions like:
PACKAGECONFIG[atomic] = ",,,"
PACKAGECONFIG[chrono] = ",,,"
PACKAGECONFIG[container] = ",,,"
PACKAGECONFIG[date_time] = ",,,"
PACKAGECONFIG[exception] = ",,,"

If you think it's a better way and no other objection, I think I will do that 
in a
separate commit as follow-up.

Thanks,
Jackie

> 
> 
> Cheers,
> Andre'
> 
> 
> > +
> >  inherit python-dir
> >  PYTHON_ROOT = "${STAGING_DIR_HOST}/${prefix}"
> >
> > @@ -54,6 +73,10 @@ python __anonymous () {
> >  }
> >
> >  # Override the contents of specific packages
> > +FILES_${PN}-graph = "${libdir}/libboost_graph.so.*"
> > +FILES_${PN}-graph_parallel = "${libdir}/libboost_graph_parallel.so.*"
> > +FILES_${PN}-locale = "${libdir}/libboost_locale.so.*"
> > +FILES_${PN}-mpi = "${libdir}/mpi.so ${libdir}/libboost_mpi*.so.*"
> >  FILES_boost-serialization = "${libdir}/libboost_serialization*.so.* \
> >     ${libdir}

Re: [OE-core] [PATCH] default-distrovars.inc: remove libidn from LGPLv2_WHITELIST_GPL-3.0

[Huang, Jie (Jackie)]

Got it, thanks!

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, September 20, 2016 3:54 PM
To: Huang, Jie (Jackie)
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] default-distrovars.inc: remove libidn from 
LGPLv2_WHITELIST_GPL-3.0


On 20 September 2016 at 01:50, Huang, Jie (Jackie) 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
Ping.

It's queued locally now, should be in master shortly.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][v5] watchdog: enable systemd support

[Huang, Jie (Jackie)]

Ping.

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of jackie.hu...@windriver.com
> Sent: Monday, September 12, 2016 1:01 PM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH][v5] watchdog: enable systemd support
> 
> From: Roy Li 
> 
> 1. inherit systemd, and add two unit files which are from Fedora 23
> 2. auto load soft dog kernel module
> 
> Signed-off-by: Roy Li 
> Signed-off-by: Robert Yang 
> Signed-off-by: Jackie Huang 
> ---
>  .../watchdog/watchdog/watchdog-ping.service   | 11 +++
>  .../watchdog/watchdog/watchdog.service| 11 +++
>  meta/recipes-extended/watchdog/watchdog_5.15.bb   | 19 
> +--
>  3 files changed, 39 insertions(+), 2 deletions(-)
>  create mode 100644 
> meta/recipes-extended/watchdog/watchdog/watchdog-ping.service
>  create mode 100644 meta/recipes-extended/watchdog/watchdog/watchdog.service
> 
> diff --git a/meta/recipes-extended/watchdog/watchdog/watchdog-ping.service 
> b/meta/recipes-
> extended/watchdog/watchdog/watchdog-ping.service
> new file mode 100644
> index 000..44bac9d
> --- /dev/null
> +++ b/meta/recipes-extended/watchdog/watchdog/watchdog-ping.service
> @@ -0,0 +1,11 @@
> +[Unit]
> +Description=watchdog daemon for use with ping test / network dependency
> +After=network.target
> +Conflicts=watchdog.service
> +
> +[Service]
> +Type=forking
> +ExecStart=@SBINDIR@/watchdog
> +
> +[Install]
> +WantedBy=multi-user.target
> diff --git a/meta/recipes-extended/watchdog/watchdog/watchdog.service 
> b/meta/recipes-
> extended/watchdog/watchdog/watchdog.service
> new file mode 100644
> index 000..c5faa4e
> --- /dev/null
> +++ b/meta/recipes-extended/watchdog/watchdog/watchdog.service
> @@ -0,0 +1,11 @@
> +[Unit]
> +Description=watchdog daemon
> +# man systemd.special
> +# auto added After=basic.target
> +
> +[Service]
> +Type=forking
> +ExecStart=@SBINDIR@/watchdog
> +
> +[Install]
> +WantedBy=multi-user.target
> diff --git a/meta/recipes-extended/watchdog/watchdog_5.15.bb b/meta/recipes-
> extended/watchdog/watchdog_5.15.bb
> index cedfc04..826e31f 100644
> --- a/meta/recipes-extended/watchdog/watchdog_5.15.bb
> +++ b/meta/recipes-extended/watchdog/watchdog_5.15.bb
> @@ -13,6 +13,8 @@ SRC_URI = 
> "${SOURCEFORGE_MIRROR}/watchdog/watchdog-${PV}.tar.gz \
> file://watchdog-init.patch \
> file://watchdog-conf.patch \
> file://wd_keepalive.init \
> +   file://watchdog-ping.service \
> +   file://watchdog.service \
>  "
> 
>  SRC_URI[md5sum] = "678c32f6f35a0492c9c1b76b4aa88828"
> @@ -22,7 +24,7 @@ UPSTREAM_CHECK_URI =
> "http://sourceforge.net/projects/watchdog/files/watchdog/;
>  UPSTREAM_CHECK_REGEX = "/watchdog/(?P(\d+[\.\-_]*)+)/"
> 
>  inherit autotools
> -inherit update-rc.d
> +inherit update-rc.d systemd
> 
>  DEPENDS_append_libc-musl = " libtirpc "
>  CFLAGS_append_libc-musl = " -I${STAGING_INCDIR}/tirpc "
> @@ -37,16 +39,29 @@ INITSCRIPT_PARAMS_${PN} = "start 15 1 2 3 4 5 . stop 85 0 
> 6 ."
>  INITSCRIPT_NAME_${PN}-keepalive = "wd_keepalive"
>  INITSCRIPT_PARAMS_${PN}-keepalive = "start 15 1 2 3 4 5 . stop 85 0 6 ."
> 
> +SYSTEMD_SERVICE_${PN} = "watchdog.service"
> +
>  do_install_append() {
> - install -D ${S}/redhat/watchdog.init 
> ${D}/${sysconfdir}/init.d/watchdog.sh
> +install -D ${S}/redhat/watchdog.init 
> ${D}/${sysconfdir}/init.d/watchdog.sh
>  install -Dm 0755 ${WORKDIR}/wd_keepalive.init 
> ${D}${sysconfdir}/init.d/wd_keepalive
> 
>  # watchdog.conf is provided by the watchdog-config recipe
>  rm ${D}${sysconfdir}/watchdog.conf
> +
> +install -d ${D}${systemd_system_unitdir}
> +install -m 0644 ${WORKDIR}/watchdog*.service 
> ${D}${systemd_system_unitdir}
> +
> +if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
> then
> +install -d ${D}${sysconfdir}/modules-load.d
> +echo "softdog" > ${D}${sysconfdir}/modules-load.d/softdog.conf
> +sed -i -e 's,@SBINDIR@,${sbindir},g' 
> ${D}${systemd_system_unitdir}/*.service
> +fi
>  }
> 
>  PACKAGES =+ "${PN}-keepalive"
> 
> +FILES_${PN} += "${systemd_system_unitdir}/*"
> +
>  FILES_${PN}-keepalive = " \
>  ${sysconfdir}/init.d/wd_keepalive \
>  ${sbindir}/wd_keepalive \
> --
> 2.8.1
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] default-distrovars.inc: remove libidn from LGPLv2_WHITELIST_GPL-3.0

[Huang, Jie (Jackie)]

Ping.

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of jackie.hu...@windriver.com
> Sent: Thursday, September 01, 2016 10:48 AM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] default-distrovars.inc: remove libidn from 
> LGPLv2_WHITELIST_GPL-3.0
> 
> From: Jackie Huang 
> 
> The libidn recipe is now buildable in distros which blacklist
> GPL-3.0 without needing to be explicitly whitelisted (since it
> provides at least one non GPLv3 package).
> 
> Signed-off-by: Jackie Huang 
> ---
>  meta/conf/distro/include/default-distrovars.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/conf/distro/include/default-distrovars.inc 
> b/meta/conf/distro/include/default-
> distrovars.inc
> index fac4deb..f7ed943 100644
> --- a/meta/conf/distro/include/default-distrovars.inc
> +++ b/meta/conf/distro/include/default-distrovars.inc
> @@ -23,7 +23,7 @@ DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}
> ${DISTRO_FEATURES_LIBC}"
>  IMAGE_FEATURES ?= ""
> 
>  WHITELIST_GPL-3.0 ?= ""
> -LGPLv2_WHITELIST_GPL-3.0 ?= "libidn"
> +LGPLv2_WHITELIST_GPL-3.0 ?= ""
> 
>  COMMERCIAL_AUDIO_PLUGINS ?= ""
>  # COMMERCIAL_AUDIO_PLUGINS ?= "gst-plugins-ugly-mad 
> gst-plugins-ugly-mpegaudioparse"
> --
> 2.8.1
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] boost: add support for additional boost libs

[Huang, Jie (Jackie)]

No, they were skipped unexpectedly:

warning: Graph library does not contain MPI-based parallel components.
warning: skipping optional Message Passing Interface (MPI) library.

Sorry that I didn’t notice these warnings, I will fix them in v2 so these 
packages
should be created.

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Wednesday, September 14, 2016 8:05 PM
To: Huang, Jie (Jackie)
Cc: OE-core
Subject: Re: [OE-core] [PATCH] boost: add support for additional boost libs


On 14 September 2016 at 06:08, 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
* Added libs:
  - container
  - context
  - coroutine
  - exception
  - graph_parallel
  - locale
  - math
  - mpi
  - wave

I don't see packages created for mpi, graph_parallel or exception.  Is this 
intentional?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] boost: add support for additional boost libs

[Huang, Jie (Jackie)]

I see, I will try to fix it then send v2.

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, September 16, 2016 10:26 PM
To: Huang, Jie (Jackie)
Cc: OE-core
Subject: Re: [OE-core] [PATCH] boost: add support for additional boost libs


On 14 September 2016 at 06:08, 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
From: Jackie Huang 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>>

* Added libs:
  - container
  - context
  - coroutine
  - exception
  - graph_parallel
  - locale
  - math
  - mpi
  - wave

* Add PACKAGECONFIG to add proper dependencies for boost-locale

* context and coroutine are added only for x86 and powerpc

This patch appears to be periodically breaking boost in the autobuilder runs.

| libs/math/build/../src/tr1/asinhf.cpp:6:21: error: while reading precompiled 
header: No such file or directory
See http://autobuilder.yocto.io:8010/builders/nightly-x86-64-lsb/builds/56/ for 
the full logs.  A build earlier also ended with GCC internal errors, but these 
may be related.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][v4] watchdog: enable systemd support

[Huang, Jie (Jackie)]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of Huang, Jie (Jackie)
> Sent: Monday, September 12, 2016 10:27 AM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH][v4] watchdog: enable systemd support
> 
> Ping.
> 
> I don't see any rejection or comments on this but it's not merged yet, is it 
> ignored?
> 
> Anyway, some later changes have been merged so I have to re-base this patch, 
> v5 will be sent soon.

v5 is sent.

Thanks,
Jackie

> 
> Thanks,
> Jackie
> 
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org 
> > [mailto:openembedded-core-
> > boun...@lists.openembedded.org] On Behalf Of jackie.hu...@windriver.com
> > Sent: Wednesday, August 10, 2016 10:19 AM
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH][v4] watchdog: enable systemd support
> >
> > From: Roy Li <rongqing...@windriver.com>
> >
> > 1. inherit systemd, and add two unit files which are from Fedora 23
> > 2. auto load soft dog kernel module
> >
> > Signed-off-by: Roy Li <rongqing...@windriver.com>
> > Signed-off-by: Jackie Huang <jackie.hu...@windriver.com>
> > ---
> >  .../watchdog/watchdog/watchdog-ping.service  | 11 +++
> >  meta/recipes-extended/watchdog/watchdog/watchdog.service | 11 +++
> >  meta/recipes-extended/watchdog/watchdog_5.15.bb  | 16 
> > +++-
> >  3 files changed, 37 insertions(+), 1 deletion(-)
> >  create mode 100644 
> > meta/recipes-extended/watchdog/watchdog/watchdog-ping.service
> >  create mode 100644 meta/recipes-extended/watchdog/watchdog/watchdog.service
> >
> > diff --git a/meta/recipes-extended/watchdog/watchdog/watchdog-ping.service 
> > b/meta/recipes-
> > extended/watchdog/watchdog/watchdog-ping.service
> > new file mode 100644
> > index 000..44bac9d
> > --- /dev/null
> > +++ b/meta/recipes-extended/watchdog/watchdog/watchdog-ping.service
> > @@ -0,0 +1,11 @@
> > +[Unit]
> > +Description=watchdog daemon for use with ping test / network dependency
> > +After=network.target
> > +Conflicts=watchdog.service
> > +
> > +[Service]
> > +Type=forking
> > +ExecStart=@SBINDIR@/watchdog
> > +
> > +[Install]
> > +WantedBy=multi-user.target
> > diff --git a/meta/recipes-extended/watchdog/watchdog/watchdog.service 
> > b/meta/recipes-
> > extended/watchdog/watchdog/watchdog.service
> > new file mode 100644
> > index 000..c5faa4e
> > --- /dev/null
> > +++ b/meta/recipes-extended/watchdog/watchdog/watchdog.service
> > @@ -0,0 +1,11 @@
> > +[Unit]
> > +Description=watchdog daemon
> > +# man systemd.special
> > +# auto added After=basic.target
> > +
> > +[Service]
> > +Type=forking
> > +ExecStart=@SBINDIR@/watchdog
> > +
> > +[Install]
> > +WantedBy=multi-user.target
> > diff --git a/meta/recipes-extended/watchdog/watchdog_5.15.bb b/meta/recipes-
> > extended/watchdog/watchdog_5.15.bb
> > index ee1a893..7ff151c 100644
> > --- a/meta/recipes-extended/watchdog/watchdog_5.15.bb
> > +++ b/meta/recipes-extended/watchdog/watchdog_5.15.bb
> > @@ -12,6 +12,8 @@ SRC_URI = 
> > "${SOURCEFORGE_MIRROR}/watchdog/watchdog-${PV}.tar.gz \
> > 
> > file://0001-Include-linux-param.h-for-EXEC_PAGESIZE-definition.patch \
> > file://watchdog-init.patch \
> > file://watchdog-conf.patch \
> > +   file://watchdog-ping.service \
> > +   file://watchdog.service \
> >  "
> >
> >  SRC_URI[md5sum] = "678c32f6f35a0492c9c1b76b4aa88828"
> > @@ -21,7 +23,7 @@ UPSTREAM_CHECK_URI =
> > "http://sourceforge.net/projects/watchdog/files/watchdog/;
> >  UPSTREAM_CHECK_REGEX = "/watchdog/(?P(\d+[\.\-_]*)+)/"
> >
> >  inherit autotools
> > -inherit update-rc.d
> > +inherit update-rc.d systemd
> >
> >  DEPENDS_append_libc-musl = " libtirpc "
> >  CFLAGS_append_libc-musl = " -I${STAGING_INCDIR}/tirpc "
> > @@ -33,6 +35,18 @@ INITSCRIPT_PARAMS = "start 15 1 2 3 4 5 . stop 85 0 6 ."
> >
> >  RRECOMMENDS_${PN} = "kernel-module-softdog"
> >
> > +SYSTEMD_SERVICE_${PN} = "watchdog.service"
> > +
> >  do_install_append() {
> > install -D ${S}/redhat/watchdog.init 
> > ${D}/${sysconfdir}/init.d/watchdog.sh
> &

Re: [OE-core] [PATCH][v4] watchdog: enable systemd support

[Huang, Jie (Jackie)]

Ping.

I don't see any rejection or comments on this but it's not merged yet, is it 
ignored?

Anyway, some later changes have been merged so I have to re-base this patch, v5 
will be sent soon.

Thanks,
Jackie

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of jackie.hu...@windriver.com
> Sent: Wednesday, August 10, 2016 10:19 AM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH][v4] watchdog: enable systemd support
> 
> From: Roy Li 
> 
> 1. inherit systemd, and add two unit files which are from Fedora 23
> 2. auto load soft dog kernel module
> 
> Signed-off-by: Roy Li 
> Signed-off-by: Jackie Huang 
> ---
>  .../watchdog/watchdog/watchdog-ping.service  | 11 +++
>  meta/recipes-extended/watchdog/watchdog/watchdog.service | 11 +++
>  meta/recipes-extended/watchdog/watchdog_5.15.bb  | 16 
> +++-
>  3 files changed, 37 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-extended/watchdog/watchdog/watchdog-ping.service
>  create mode 100644 meta/recipes-extended/watchdog/watchdog/watchdog.service
> 
> diff --git a/meta/recipes-extended/watchdog/watchdog/watchdog-ping.service 
> b/meta/recipes-
> extended/watchdog/watchdog/watchdog-ping.service
> new file mode 100644
> index 000..44bac9d
> --- /dev/null
> +++ b/meta/recipes-extended/watchdog/watchdog/watchdog-ping.service
> @@ -0,0 +1,11 @@
> +[Unit]
> +Description=watchdog daemon for use with ping test / network dependency
> +After=network.target
> +Conflicts=watchdog.service
> +
> +[Service]
> +Type=forking
> +ExecStart=@SBINDIR@/watchdog
> +
> +[Install]
> +WantedBy=multi-user.target
> diff --git a/meta/recipes-extended/watchdog/watchdog/watchdog.service 
> b/meta/recipes-
> extended/watchdog/watchdog/watchdog.service
> new file mode 100644
> index 000..c5faa4e
> --- /dev/null
> +++ b/meta/recipes-extended/watchdog/watchdog/watchdog.service
> @@ -0,0 +1,11 @@
> +[Unit]
> +Description=watchdog daemon
> +# man systemd.special
> +# auto added After=basic.target
> +
> +[Service]
> +Type=forking
> +ExecStart=@SBINDIR@/watchdog
> +
> +[Install]
> +WantedBy=multi-user.target
> diff --git a/meta/recipes-extended/watchdog/watchdog_5.15.bb b/meta/recipes-
> extended/watchdog/watchdog_5.15.bb
> index ee1a893..7ff151c 100644
> --- a/meta/recipes-extended/watchdog/watchdog_5.15.bb
> +++ b/meta/recipes-extended/watchdog/watchdog_5.15.bb
> @@ -12,6 +12,8 @@ SRC_URI = 
> "${SOURCEFORGE_MIRROR}/watchdog/watchdog-${PV}.tar.gz \
> 
> file://0001-Include-linux-param.h-for-EXEC_PAGESIZE-definition.patch \
> file://watchdog-init.patch \
> file://watchdog-conf.patch \
> +   file://watchdog-ping.service \
> +   file://watchdog.service \
>  "
> 
>  SRC_URI[md5sum] = "678c32f6f35a0492c9c1b76b4aa88828"
> @@ -21,7 +23,7 @@ UPSTREAM_CHECK_URI =
> "http://sourceforge.net/projects/watchdog/files/watchdog/;
>  UPSTREAM_CHECK_REGEX = "/watchdog/(?P(\d+[\.\-_]*)+)/"
> 
>  inherit autotools
> -inherit update-rc.d
> +inherit update-rc.d systemd
> 
>  DEPENDS_append_libc-musl = " libtirpc "
>  CFLAGS_append_libc-musl = " -I${STAGING_INCDIR}/tirpc "
> @@ -33,6 +35,18 @@ INITSCRIPT_PARAMS = "start 15 1 2 3 4 5 . stop 85 0 6 ."
> 
>  RRECOMMENDS_${PN} = "kernel-module-softdog"
> 
> +SYSTEMD_SERVICE_${PN} = "watchdog.service"
> +
>  do_install_append() {
>   install -D ${S}/redhat/watchdog.init 
> ${D}/${sysconfdir}/init.d/watchdog.sh
> + install -d ${D}${systemd_system_unitdir}
> + install -m 0644 ${WORKDIR}/watchdog*.service 
> ${D}${systemd_system_unitdir}
> +
> + if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
> then
> + install -d ${D}${sysconfdir}/modules-load.d
> + echo "softdog" > ${D}${sysconfdir}/modules-load.d/softdog.conf
> + sed -i -e 's,@SBINDIR@,${sbindir},g' 
> ${D}${systemd_system_unitdir}/*.service
> + fi
>  }
> +
> +FILES_${PN} += "${systemd_system_unitdir}/*"
> --
> 2.7.4
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/17] control ipv6 support based on DISTRO_FEATURES

[Huang, Jie (Jackie)]

Ping.

I don't see a comment or rejection on these, will these be merged soon?

Thanks,
Jackie

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of jackie.hu...@windriver.com
> Sent: Monday, August 22, 2016 5:06 PM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 00/17] control ipv6 support based on DISTRO_FEATURES
> 
> From: Jackie Huang 
> 
> There is ipv6 configure option for these packages, and we need to them
> to be controled by DISTRO_FEATURES.
> 
> Tested with and without ipv6 in DISTRO_FEATURES on qemux86-64 and qemuarm.
> 
> --
> The following changes since commit f078ccf1ac60488169853724c35126cc056f975d:
> 
>   bitbake: siggen: Fix file variable typo in compare_sigfiles (2016-08-20 
> 16:11:29 +0100)
> 
> are available in the git repository at:
> 
>   git://git.pokylinux.org/poky-contrib.git jhuang0/r_ipv6_160822_0
>   http://git.pokylinux.org/cgit.cgi//log/?h=jhuang0/r_ipv6_160822_0
> 
> Jackie Huang (17):
>   apr: control ipv6 support based on DISTRO_FEATURES
>   libice: control ipv6 support based on DISTRO_FEATURES
>   libpcap: control ipv6 support based on DISTRO_FEATURES
>   libsm: control ipv6 support based on DISTRO_FEATURES
>   libxfont: control ipv6 support based on DISTRO_FEATURES
>   libxml2: control ipv6 support based on DISTRO_FEATURES
>   libxmu: control ipv6 support based on DISTRO_FEATURES
>   lighttpd: control ipv6 support based on DISTRO_FEATURES
>   nfs-utils: control ipv6 support based on DISTRO_FEATURES
>   nspr: control ipv6 support based on DISTRO_FEATURES
>   psmisc: control ipv6 support based on DISTRO_FEATURES
>   pulseaudio: control ipv6 support based on DISTRO_FEATURES
>   rsync: use rsync.inc to avoid duplicated codes
>   rsync: control ipv6 support based on DISTRO_FEATURES
>   wget: control ipv6 support based on DISTRO_FEATURES
>   xauth: control ipv6 support based on DISTRO_FEATURES
>   xhost: control ipv6 support based on DISTRO_FEATURES
> 
>  meta/recipes-connectivity/libpcap/libpcap.inc  |  5 -
>  .../nfs-utils/nfs-utils_1.3.3.bb   |  5 -
>  meta/recipes-core/libxml/libxml2_2.9.4.bb  |  5 -
>  meta/recipes-devtools/rsync/rsync.inc  |  7 ++
>  meta/recipes-devtools/rsync/rsync_2.6.9.bb | 25 
> ++
>  meta/recipes-devtools/rsync/rsync_3.1.2.bb |  8 ++-
>  meta/recipes-extended/lighttpd/lighttpd_1.4.39.bb  |  5 -
>  meta/recipes-extended/psmisc/psmisc.inc|  3 +++
>  meta/recipes-extended/wget/wget.inc|  5 +++--
>  meta/recipes-graphics/xorg-app/xauth_1.0.9.bb  |  3 +++
>  meta/recipes-graphics/xorg-app/xhost_1.0.7.bb  |  3 +++
>  meta/recipes-graphics/xorg-lib/libice_1.0.9.bb |  3 ++-
>  meta/recipes-graphics/xorg-lib/libsm_1.2.2.bb  |  3 +++
>  meta/recipes-graphics/xorg-lib/libxfont_1.5.1.bb   |  3 +++
>  meta/recipes-graphics/xorg-lib/libxmu_1.1.2.bb |  3 +++
>  meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |  2 ++
>  meta/recipes-support/apr/apr_1.5.2.bb  |  3 +++
>  meta/recipes-support/nspr/nspr_4.12.bb |  3 +++
>  18 files changed, 62 insertions(+), 32 deletions(-)
> 
> --
> 2.8.1
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] meta-ide-support: set noexec for tasks

[Huang, Jie (Jackie)]

> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Tuesday, August 30, 2016 4:41 PM
> To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] meta-ide-support: set noexec for tasks
> 
> On Tue, 2016-08-30 at 16:08 +0800, jackie.hu...@windriver.com wrote:
> > From: Jackie Huang <jackie.hu...@windriver.com>
> >
> > The recipe is to generate an environment script in
> > do_populate_ide_support for using an IDE, the tasks
> > listed are not needed, so set 'noexec' for them.
> 
> Would "inherit nopackage" help here and simplify this patch a bit?

Ah, sorry I didn't know there is such a bbclass. Yes, it works and simplify the 
patch.
I will send v2 for this.

Thanks,
Jackie

> 
> Cheers,
> 
> Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cross-canadian.bbclass: Add BASECANADIANEXTRAOS to specify main extraos

[Huang, Jie (Jackie)]

Ping!

I don't see any objection on this but this is not merged yet, is it ignored?

Thanks,
Jackie

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of Mark Hatle
> Sent: Tuesday, December 08, 2015 5:36 AM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] cross-canadian.bbclass: Add BASECANADIANEXTRAOS to 
> specify main
> extraos
> 
> By default the system will expand the extra os entries for uclibc and musl
> even if they are not enabled in the build.  There was no way to prevent this
> behavior while still getting the expansion for things like x32 or spe.
> 
> The change adds a new setting which a distribution creator can override
> easily, setting the base set of canadianextraos components.  The other
> expansions are then based on this setting.
> 
> Signed-off-by: Mark Hatle 
> ---
>  meta/classes/cross-canadian.bbclass | 22 +-
>  1 file changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/meta/classes/cross-canadian.bbclass 
> b/meta/classes/cross-canadian.bbclass
> index ea17f09..799844b 100644
> --- a/meta/classes/cross-canadian.bbclass
> +++ b/meta/classes/cross-canadian.bbclass
> @@ -15,7 +15,8 @@ STAGING_BINDIR_TOOLCHAIN =
> "${STAGING_DIR_NATIVE}${bindir_native}/${SDK_ARCH}${S
>  # Update BASE_PACKAGE_ARCH and PACKAGE_ARCHS
>  #
>  PACKAGE_ARCH = "${SDK_ARCH}-${SDKPKGSUFFIX}"
> -CANADIANEXTRAOS = "linux-uclibc linux-musl"
> +BASECANADIANEXTRAOS ?= "linux-uclibc linux-musl"
> +CANADIANEXTRAOS = "${BASECANADIANEXTRAOS}"
>  CANADIANEXTRAVENDOR = ""
>  MODIFYTOS ??= "1"
>  python () {
> @@ -34,8 +35,13 @@ python () {
> 
>  tos = d.getVar("TARGET_OS", True)
>  whitelist = []
> +extralibcs = [""]
> +if "uclibc" in d.getVar("BASECANADIANEXTRAOS", True):
> +extralibcs.append("uclibc")
> +if "musl" in d.getVar("BASECANADIANEXTRAOS", True):
> +extralibcs.append("musl")
>  for variant in ["", "spe", "x32", "eabi", "n32"]:
> -for libc in ["", "uclibc", "musl"]:
> +for libc in extralibcs:
>  entry = "linux"
>  if variant and libc:
>  entry = entry + "-" + libc + variant
> @@ -59,14 +65,20 @@ python () {
>  if tarch == "x86_64":
>  d.setVar("LIBCEXTENSION", "")
>  d.setVar("ABIEXTENSION", "")
> -d.appendVar("CANADIANEXTRAOS", " linux-gnux32 linux-uclibcx32 
> linux-muslx32")
> +d.appendVar("CANADIANEXTRAOS", " linux-gnux32")
> +for extraos in d.getVar("BASECANADIANEXTRAOS", True).split():
> +d.appendVar("CANADIANEXTRAOS", " " + extraos + "x32")
>  elif tarch == "powerpc":
>  # PowerPC can build "linux" and "linux-gnuspe"
>  d.setVar("LIBCEXTENSION", "")
>  d.setVar("ABIEXTENSION", "")
> -d.appendVar("CANADIANEXTRAOS", " linux-gnuspe linux-uclibcspe 
> linux-muslspe")
> +d.appendVar("CANADIANEXTRAOS", " linux-gnuspe")
> +for extraos in d.getVar("BASECANADIANEXTRAOS", True).split():
> +d.appendVar("CANADIANEXTRAOS", " " + extraos + "spe")
>  elif tarch == "mips64":
> -d.appendVar("CANADIANEXTRAOS", " linux-gnun32 linux-uclibcn32 
> linux-musln32")
> +d.appendVar("CANADIANEXTRAOS", " linux-gnun32")
> +for extraos in d.getVar("BASECANADIANEXTRAOS", True).split():
> +d.appendVar("CANADIANEXTRAOS", " " + extraos + "n32")
>  if tarch == "arm" or tarch == "armeb":
>  d.setVar("TARGET_OS", "linux-gnueabi")
>  else:
> --
> 1.9.3
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][v3] watchdog: enable systemd support

[Huang, Jie (Jackie)]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of jackie.hu...@windriver.com
> Sent: Friday, July 15, 2016 2:08 PM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH][v3] watchdog: enable systemd support
> 
> From: Roy Li 
> 
> 1. inherit systemd, and add two unit files which are from Fedora 23
> 2. auto load soft dog kernel module
> 
> Signed-off-by: Roy Li 
> Signed-off-by: Jackie Huang 
> ---
>  .../watchdog/watchdog/watchdog-ping.service  | 11 +++
>  meta/recipes-extended/watchdog/watchdog/watchdog.service | 11 +++
>  meta/recipes-extended/watchdog/watchdog_5.15.bb  | 16 
> +++-
>  3 files changed, 37 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-extended/watchdog/watchdog/watchdog-ping.service
>  create mode 100644 meta/recipes-extended/watchdog/watchdog/watchdog.service
> 
> diff --git a/meta/recipes-extended/watchdog/watchdog/watchdog-ping.service 
> b/meta/recipes-
> extended/watchdog/watchdog/watchdog-ping.service
> new file mode 100644
> index 000..44bac9d
> --- /dev/null
> +++ b/meta/recipes-extended/watchdog/watchdog/watchdog-ping.service
> @@ -0,0 +1,11 @@
> +[Unit]
> +Description=watchdog daemon for use with ping test / network dependency
> +After=network.target
> +Conflicts=watchdog.service
> +
> +[Service]
> +Type=forking
> +ExecStart=@SBINDIR@/watchdog
> +
> +[Install]
> +WantedBy=multi-user.target
> diff --git a/meta/recipes-extended/watchdog/watchdog/watchdog.service 
> b/meta/recipes-
> extended/watchdog/watchdog/watchdog.service
> new file mode 100644
> index 000..c5faa4e
> --- /dev/null
> +++ b/meta/recipes-extended/watchdog/watchdog/watchdog.service
> @@ -0,0 +1,11 @@
> +[Unit]
> +Description=watchdog daemon
> +# man systemd.special
> +# auto added After=basic.target
> +
> +[Service]
> +Type=forking
> +ExecStart=@SBINDIR@/watchdog
> +
> +[Install]
> +WantedBy=multi-user.target
> diff --git a/meta/recipes-extended/watchdog/watchdog_5.15.bb b/meta/recipes-
> extended/watchdog/watchdog_5.15.bb
> index ee1a893..ac2ee5c 100644
> --- a/meta/recipes-extended/watchdog/watchdog_5.15.bb
> +++ b/meta/recipes-extended/watchdog/watchdog_5.15.bb
> @@ -12,6 +12,8 @@ SRC_URI = 
> "${SOURCEFORGE_MIRROR}/watchdog/watchdog-${PV}.tar.gz \
> 
> file://0001-Include-linux-param.h-for-EXEC_PAGESIZE-definition.patch \
> file://watchdog-init.patch \
> file://watchdog-conf.patch \
> +   file://watchdog-ping.service \
> +   file://watchdog.service \
>  "
> 
>  SRC_URI[md5sum] = "678c32f6f35a0492c9c1b76b4aa88828"
> @@ -21,7 +23,7 @@ UPSTREAM_CHECK_URI =
> "http://sourceforge.net/projects/watchdog/files/watchdog/;
>  UPSTREAM_CHECK_REGEX = "/watchdog/(?P(\d+[\.\-_]*)+)/"
> 
>  inherit autotools
> -inherit update-rc.d
> +inherit update-rc.d systemd
> 
>  DEPENDS_append_libc-musl = " libtirpc "
>  CFLAGS_append_libc-musl = " -I${STAGING_INCDIR}/tirpc "
> @@ -33,6 +35,18 @@ INITSCRIPT_PARAMS = "start 15 1 2 3 4 5 . stop 85 0 6 ."
> 
>  RRECOMMENDS_${PN} = "kernel-module-softdog"
> 
> +SYSTEMD_SERVICE_${PN} = "watchdog.service"
> +
>  do_install_append() {
>   install -D ${S}/redhat/watchdog.init 
> ${D}/${sysconfdir}/init.d/watchdog.sh
> + install -d ${D}${systemd_system_unitdir}
> + install -m 0644 ${WORKDIR}/watchdog*.service 
> ${D}${systemd_system_unitdir}
> +
> + if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
> then
> + install -d ${D}${sysconfdir}/modules-load.d
> + echo "softdog" > ${D}${sysconfdir}/modules-load.d/softdog.conf
> + sed -i -e 's,@SBINDIR@,${sbindir},g' 
> ${D}${systemd_unitdir}/system/*.service

This should be ${ systemd_system_unitdir} as well, I will change and send v4.

Thanks,
Jackie

> + fi
>  }
> +
> +FILES_${PN} += "${systemd_system_unitdir}/*"
> --
> 2.8.1
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] avahi-ui: use PACKAGECONFIG for gtk features

[Huang, Jie (Jackie)]

Ok, I will leave just gtk3 in the default.

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, July 26, 2016 4:52 AM
To: Huang, Jie (Jackie)
Cc: OE-core
Subject: Re: [OE-core] [PATCH] avahi-ui: use PACKAGECONFIG for gtk features


On 25 July 2016 at 09:42, 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
+AVAHI_GTK = "gtk gtk3"

As we've moved away from GTK+2 for oe-core I still think that the default built 
should be with just GTK+ 3 and anyone who is still using ancient software 
(gnome-disk-utility 2.32 was released in 2010) can enable it at their distro 
level.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] [v2] watchdog: enable systemd support

[Huang, Jie (Jackie)]

Hi,

I’m taking care this of, I will change to use systemd_system_unitdir instead
and remove ControlGroup in the service files since it has been deprecated.

Thanks,
Jackie

From: 
openembedded-core-boun...@lists.openembedded.org
 [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Pau 
Espin Pedrol
Sent: Wednesday, February 03, 2016 6:26 AM
To: Li, Rongqing
Cc: OE-core
Subject: Re: [OE-core] [PATCH] [v2] watchdog: enable systemd support

Hi,
Please could you use ${systemd_system_unitdir} instead of 
${systemd_unitdir}/system ?

Pau Espin Pedrol
mail/jabber: pespin.s...@gmail.com
http://blog.espeweb.net

2016-01-25 3:48 GMT+01:00 
>:
From: Roy Li >

1. inherit systemd, and add two unit files which are from Fedora 23
2. auto load soft dog kernel module

Signed-off-by: Roy Li 
>
---
 .../watchdog/watchdog/watchdog-ping.service | 12 
 .../recipes-extended/watchdog/watchdog/watchdog.service | 12 
 meta/recipes-extended/watchdog/watchdog_5.14.bb   
  | 17 -
 3 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-extended/watchdog/watchdog/watchdog-ping.service
 create mode 100644 meta/recipes-extended/watchdog/watchdog/watchdog.service

diff --git a/meta/recipes-extended/watchdog/watchdog/watchdog-ping.service 
b/meta/recipes-extended/watchdog/watchdog/watchdog-ping.service
new file mode 100644
index 000..fce6e12
--- /dev/null
+++ b/meta/recipes-extended/watchdog/watchdog/watchdog-ping.service
@@ -0,0 +1,12 @@
+[Unit]
+Description=watchdog daemon for use with ping test / network dependency
+After=network.target
+Conflicts=watchdog.service
+
+[Service]
+Type=forking
+ExecStart=@SBINDIR@/watchdog
+ControlGroup=cpu:/
+
+[Install]
+WantedBy=multi-user.target
diff --git a/meta/recipes-extended/watchdog/watchdog/watchdog.service 
b/meta/recipes-extended/watchdog/watchdog/watchdog.service
new file mode 100644
index 000..f945bc9
--- /dev/null
+++ b/meta/recipes-extended/watchdog/watchdog/watchdog.service
@@ -0,0 +1,12 @@
+[Unit]
+Description=watchdog daemon
+# man systemd.special
+# auto added After=basic.target
+
+[Service]
+Type=forking
+ExecStart=@SBINDIR@/watchdog
+ControlGroup=cpu:/
+
+[Install]
+WantedBy=multi-user.target
diff --git 
a/meta/recipes-extended/watchdog/watchdog_5.14.bb 
b/meta/recipes-extended/watchdog/watchdog_5.14.bb
index fc717bc..9e21075 100644
--- a/meta/recipes-extended/watchdog/watchdog_5.14.bb
+++ b/meta/recipes-extended/watchdog/watchdog_5.14.bb
@@ -14,6 +14,8 @@ SRC_URI = 
"${SOURCEFORGE_MIRROR}/watchdog/watchdog-${PV}.tar.gz \
   file://watchdog-init.patch \
   file://watchdog-conf.patch \
   
file://0001-Fix-build-issues-found-with-non-glibc-C-libraries.patch
 \
+  file://watchdog-ping.service \
+  file://watchdog.service \
 "

 SRC_URI[md5sum] = "5b2dba0c593942f4acc100bca0d560c4"
@@ -23,7 +25,7 @@ UPSTREAM_CHECK_URI = 
"http://sourceforge.net/projects/watchdog/files/watchdog/;
 UPSTREAM_CHECK_REGEX = "/watchdog/(?P(\d+[\.\-_]*)+)/"

 inherit autotools
-inherit update-rc.d
+inherit update-rc.d systemd

 DEPENDS_append_libc-musl = " libtirpc "
 CFLAGS_append_libc-musl = " -I${STAGING_INCDIR}/tirpc "
@@ -34,6 +36,19 @@ INITSCRIPT_PARAMS = "start 15 1 2 3 4 5 . stop 85 0 6 ."

 RRECOMMENDS_${PN} = "kernel-module-softdog"

+
+SYSTEMD_SERVICE_${PN} = "watchdog.service"
+
 do_install_append() {
install -D ${S}/redhat/watchdog.init 
${D}/${sysconfdir}/init.d/watchdog.sh
+   install -d ${D}${systemd_unitdir}/system
+   install -m 0644 ${WORKDIR}/watchdog*.service 
${D}${systemd_unitdir}/system
+
+   if 
${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
 then
+   install -d ${D}${sysconfdir}/modules-load.d
+   echo "softdog" > ${D}${sysconfdir}/modules-load.d/softdog.conf
+   sed -i -e 's,@SBINDIR@,${sbindir},g' 
${D}${systemd_unitdir}/system/*.service
+   fi
 }
+
+FILES_${PN} += "${systemd_unitdir}/system/*"
--
1.9.1

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/3] glib-2.0: drop add-march-i486-into-CFLAGS-automatically.patch

[Huang, Jie (Jackie)]

> -Original Message-
> From: Phil Blundell [mailto:p...@pbcl.net]
> Sent: Tuesday, February 02, 2016 6:45 AM
> To: MacLeod, Randy
> Cc: Andre McCurdy; openembedded-core@lists.openembedded.org; Huang, Jie 
> (Jackie)
> Subject: Re: [OE-core] [PATCH 2/3] glib-2.0: drop 
> add-march-i486-into-CFLAGS-automatically.patch
> 
> On Mon, 2016-02-01 at 17:23 -0500, Randy MacLeod wrote:
> > Do you remember why this patch was needed?
> 
> The comments in the patch provide a fairly clear explanation of what
> problem it was trying to solve.  But I agree with Andre that this cure
> is in fact worse than the original disease.
> 
> In any case, the issue is probably moot because neither glibc nor musl
> support cpus without cmpxchg any more.

I'm not the author of that patch, just helped forwarding it.
It seems reasonable to drop it and we may get back to the issue
and solve it with a more proper way.

Thanks,
Jackie

> 
> p.
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] matchbox-desktop: sync with gio for the inotify-sub

[Huang, Jie (Jackie)]

Thanks, so we can ignore this patch and should get rid of the inotify codes in 
the rewrite.

Thanks,
Jackie

From: Jussi Kukkonen [mailto:jussi.kukko...@intel.com]
Sent: Thursday, December 03, 2015 7:58 PM
To: Huang, Jie (Jackie)
Cc: BURTON, ROSS; OE-core
Subject: Re: [OE-core] [PATCH] matchbox-desktop: sync with gio for the 
inotify-sub

On 3 December 2015 at 11:11, Huang, Jie (Jackie) 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
>
> I agree to drop those codes, and it should already be part of the rewrite,
>
> where I can find info about the rewrite, I don’t see any actives in:
>
> git.yoctoproject.org/cgit/cgit.cgi/matchbox-desktop-2<http://git.yoctoproject.org/cgit/cgit.cgi/matchbox-desktop-2>
>
> The latest commit is 3 years ago.


They're not very recent either but most of the matchbox-* repos have a branch 
'gtk3' that contains the most up to date work. I've just started looking at the 
code with the intention of finishing this gtk3 transition: an up-to-date poky 
branch with these changes is 'jku/shuku' in 
git://git.yoctoproject.org/poky-contrib<http://git.yoctoproject.org/poky-contrib>.
 Be warned that it's currently quite broken: I hope I have something that runs 
in a week or two.

I agree with ross about preferably getting rid of things like custom inotify 
code.
 - Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] matchbox-desktop: sync with gio for the inotify-sub

[Huang, Jie (Jackie)]

So I should send the patch to 
yo...@yoctoproject.org<mailto:yo...@yoctoproject.org>, right?

I agree to drop those codes, and it should already be part of the rewrite,
where I can find info about the rewrite, I don’t see any actives in:
git.yoctoproject.org/cgit/cgit.cgi/matchbox-desktop-2

The latest commit is 3 years ago.

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, December 01, 2015 4:56 PM
To: Huang, Jie (Jackie)
Cc: OE-core
Subject: Re: [OE-core] [PATCH] matchbox-desktop: sync with gio for the 
inotify-sub


On 1 December 2015 at 05:47, 
<jackie.hu...@windriver.com<mailto:jackie.hu...@windriver.com>> wrote:
matchbox-desktop builds with included libinotify which
is very old (last sync was in 2008), if we compile glib-2.0
with -fvisibility=default (the default is hidden for libglib
and libgio), it will crash because of inconsistency of
inotify-sub, so port the related parts to fix the issue.

matchbox-desktop is maintained by the Yocto Project, so this patch should be 
applied there and then the recipe updated to the latest git revision.

There's a big rewrite of matchbox-desktop going on, so dropping that code 
entirely is probably the best idea: just use GIO instead.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] mtd-utils: disable xattr if DISTRO_FEATURES doesn't contain acl

[Huang, Jie (Jackie)]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of Andrea Adami
 Sent: Sunday, August 23, 2015 5:59 AM
 To: openembedded-core@lists.openembedded.org
 Subject: [OE-core] [PATCH v2] mtd-utils: disable xattr if DISTRO_FEATURES 
 doesn't contain acl
 
 After commit 24fde4d do_compile fails:
 
 | mkfs.jffs2.c:70:21: fatal error: sys/acl.h: No such file or directory
 | #include sys/acl.h
 
 This is a missing dependency on acl.
 To fix this we add a check to disable xattr when acl is not in 
 DISTRO_FEATURES.

I think you should check the xattr distro feature, but only checking the 
DISTRO_FEATURES
can't ensure the dependency satisfied, why not use the PACKAGECONFIG, something 
like:

PACKAGECONFIG ?= ${@bb.utils.contains('DISTRO_FEATURES', 'xattr', 'xattr', '', 
d)}
PACKAGECONFIG[xattr] = , -DWITHOUT_XATTR,attr acl,

Thanks,
Jackie


 
 Signed-off-by: Andrea Adami andrea.ad...@gmail.com
 ---
  meta/recipes-devtools/mtd/mtd-utils_git.bb | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/meta/recipes-devtools/mtd/mtd-utils_git.bb 
 b/meta/recipes-devtools/mtd/mtd-
 utils_git.bb
 index 8d4892a..6a388c8 100644
 --- a/meta/recipes-devtools/mtd/mtd-utils_git.bb
 +++ b/meta/recipes-devtools/mtd/mtd-utils_git.bb
 @@ -19,7 +19,8 @@ SRC_URI = git://git.infradead.org/mtd-utils.git \
 
  S = ${WORKDIR}/git/
 
 -EXTRA_OEMAKE = 'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}' 'CFLAGS=${CFLAGS} 
 -I${S}/include'
 'BUILDDIR=${S}'
 +DISABLE_XATTR = ${@bb.utils.contains('DISTRO_FEATURES', 'acl', '', 
 '-DWITHOUT_XATTR', d)}
 +EXTRA_OEMAKE = 'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}' 'CFLAGS=${CFLAGS} 
 -I${S}/include
 ${DISABLE_XATTR}' 'BUILDDIR=${S}'
 
  do_install () {
   oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir}
 INCLUDEDIR=${includedir}
 --
 1.9.1
 
 --
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] mtd-utils: disable xattr if DISTRO_FEATURES doesn't contain acl

[Huang, Jie (Jackie)]

 -Original Message-
 From: Patrick Ohly [mailto:patrick.o...@intel.com]
 Sent: Thursday, August 27, 2015 12:04 AM
 To: Huang, Jie (Jackie); Hatle, Mark
 Cc: Andrea Adami; openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH v2] mtd-utils: disable xattr if DISTRO_FEATURES 
 doesn't contain acl
 
 On Wed, 2015-08-26 at 09:50 +, Huang, Jie (Jackie) wrote:
 
   -Original Message-
   From: openembedded-core-boun...@lists.openembedded.org
   [mailto:openembedded-core- boun...@lists.openembedded.org] On Behalf
   Of Andrea Adami
   Sent: Sunday, August 23, 2015 5:59 AM
   To: openembedded-core@lists.openembedded.org
   Subject: [OE-core] [PATCH v2] mtd-utils: disable xattr if
   DISTRO_FEATURES doesn't contain acl
  
   After commit 24fde4d do_compile fails:
  
   | mkfs.jffs2.c:70:21: fatal error: sys/acl.h: No such file or
   | directory #include sys/acl.h
  
   This is a missing dependency on acl.
   To fix this we add a check to disable xattr when acl is not in 
   DISTRO_FEATURES.
 
  I think you should check the xattr distro feature, but only checking
  the DISTRO_FEATURES can't ensure the dependency satisfied, why not use the 
  PACKAGECONFIG,
 something like:
 
  PACKAGECONFIG ?= ${@bb.utils.contains('DISTRO_FEATURES', 'xattr', 'xattr', 
  '', d)}
  PACKAGECONFIG[xattr] = , -DWITHOUT_XATTR,attr acl,
 
 I agree that we should check the xattr distro feature. The actual patch is a 
 bit more complex, though,
 because PACKAGECONFIG cannot influence EXTRA_OEMAKE, can it?

Oh, I didn't notice it was for EXTRA_OEMAKE.

 
 I'll reply with a patch that worked for me.

I see your patch, it looks fine to me.

Thanks,
Jackie

 
 --
 Best Regards, Patrick Ohly
 
 The content of this message is my personal opinion only and although I am an 
 employee of Intel, the
 statements I make here in no way represent Intel's position on the issue, nor 
 am I authorized to speak
 on behalf of Intel on this matter.
 
 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer

[Huang, Jie (Jackie)]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of Patrick Ohly
 Sent: Thursday, August 20, 2015 9:47 PM
 To: Paul Eggleton
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [RFC PATCH 1/1] classes/whitelist: add class to allow 
 whitelisting recipes from a
 layer
 
 On Wed, 2015-08-19 at 14:34 +0100, Paul Eggleton wrote:
  Allow restricting recipes brought from a layer to a specified list.
  This is similar in operation to blacklist.bbclass, but instead
  specifies a per-layer whitelist of recipes (matched by BPN) that are
  able to be built from the layer - anything else is skipped. This is
  potentially useful where you want to bring in a select set of recipes
  from a larger layer e.g. meta-oe.
 
 Worked for all of my tests. I added all layers in meta-openembedded and then 
 white-listed just gmock
 in meta-oe (aka openembedded-layer):

This worked for my tests as well, there are 160 recipes in my whitelist and 
there are 3 different cases:

1) All recipes are needed: nothing need to be done here.
2) No recipe is needed:
PNWHITELIST_efl-layer = Nothing
PNWHITELIST_filesystems-layer = Nothing
PNWHITELIST_gpe-layer = Nothing
PNWHITELIST_meta-initramfs = Nothing
PNWHITELIST_multimedia-layer = Nothing
PNWHITELIST_ruby-layer = Nothing
PNWHITELIST_systemd-layer = Nothing
PNWHITELIST_toolchain-layer = Nothing

3) Some of the recipes are whitelisted, take gnome-layer for example:
PNWHITELIST_gnome-layer = \
gnome-disk-utility \
gnome-keyring \
gsettings-desktop-schemas \
gvfs \
gvfs-gdu-volume-monitor \
libgnome-keyring \
libgtop \
libwnck \
libwnck3 \
libxklavier \
metacity \


I also test to put some recipes both in whitelist and blacklist, and it turned 
out that
the blacklist's priority is higher than whitelist.

 
 INHERIT += whitelist
 
 PNWHITELIST_efl-layer = no-recipe-enabled
 PNWHITELIST_filesystems-layer = no-recipe-enabled
 PNWHITELIST_gnome-layer = no-recipe-enabled
 PNWHITELIST_gpe-layer = no-recipe-enabled
 PNWHITELIST_meta-initramfs = no-recipe-enabled
 PNWHITELIST_meta-python = no-recipe-enabled
 PNWHITELIST_multimedia-layer = no-recipe-enabled
 PNWHITELIST_networking-layer = no-recipe-enabled
 PNWHITELIST_openembedded-layer = gmock
 PNWHITELIST_perl-layer = no-recipe-enabled
 PNWHITELIST_ruby-layer = no-recipe-enabled
 PNWHITELIST_systemd-layer = no-recipe-enabled
 PNWHITELIST_toolchain-layer = no-recipe-enabled
 PNWHITELIST_webserver = no-recipe-enabled
 PNWHITELIST_xfce-layer = no-recipe-enabled
 
 I got warnings for several of the layers, but strangely not for all of
 them:
 
 WARNING: No bb files matched BBFILE_PATTERN_efl-layer 
 '^/work/meta-openembedded/meta-efl/'
 WARNING: No bb files matched BBFILE_PATTERN_filesystems-layer '^/work/meta-
 openembedded/meta-filesystems/'
 WARNING: No bb files matched BBFILE_PATTERN_gpe-layer 
 '^/work/meta-openembedded/meta-
 gpe/'
 WARNING: No bb files matched BBFILE_PATTERN_meta-initramfs '^/work/meta-
 openembedded/meta-initramfs/'
 WARNING: No bb files matched BBFILE_PATTERN_multimedia-layer '^/work/meta-
 openembedded/meta-multimedia/'
 WARNING: No bb files matched BBFILE_PATTERN_networking-layer '^/work/meta-
 openembedded/meta-networking/'
 WARNING: No bb files matched BBFILE_PATTERN_perl-layer 
 '^/work/meta-openembedded/meta-
 perl/'
 WARNING: No bb files matched BBFILE_PATTERN_meta-python '^/work/meta-
 openembedded/meta-python/'
 WARNING: No bb files matched BBFILE_PATTERN_ruby-layer 
 '^/work/meta-openembedded/meta-
 ruby/'
 WARNING: No bb files matched BBFILE_PATTERN_webserver 
 '^/work/meta-openembedded/meta-
 webserver/'
 WARNING: No bb files matched BBFILE_PATTERN_xfce-layer 
 '^/work/meta-openembedded/meta-
 xfce/'
 
 Note that gnome-layer is not warned about, although none of its recipes are 
 enabled (checked with
 bitbake-layers show-recipes -f | grep -v '(skipped)' | grep meta-gnome). 
 Any idea why?
 
 One more comment: it would be slightly nicer if empty whitelist could be 
 distinguished from no
 whitelist, with empty meaning enable no recipes. In other words, replace 
 if whitelist with if
 whitelist is not None.
 
 I want to list all PNWHITELIST_xxx values for meta-openembedded, even when 
 the layer is not (yet) in
 bblayers.sample.conf, in order to be prepared for adding it later. Doing that 
 with an empty string is
 more readable than with a fake recipe name to make the variable non-empty.

I vote for this suggestion, it's better than a fake recipe name.

Thanks,
Jackie

 
 --
 Best Regards, Patrick Ohly
 
 The content of this message is my personal opinion only and although I am an 
 employee of Intel, the
 statements I make here in no way represent Intel's position on the issue, nor 
 am I authorized to speak
 on behalf of Intel on this matter.
 
 
 
 --
 ___
 Openembedded-core mailing list
 

Re: [OE-core] [PATCH] libinput: add configure arg and PACKAGECONFIG for libunwind

[Huang, Jie (Jackie)]

 -Original Message-
 From: Jussi Kukkonen [mailto:jussi.kukko...@intel.com]
 Sent: Tuesday, August 04, 2015 4:23 PM
 To: Huang, Jie (Jackie)
 Cc: Patches and discussions about the oe-core layer
 Subject: Re: [OE-core] [PATCH] libinput: add configure arg and PACKAGECONFIG 
 for libunwind
 
 On 4 August 2015 at 10:25,  jackie.hu...@windriver.com wrote:
  From: Jackie Huang jackie.hu...@windriver.com
 
  libinput use pkg-config to check and decide whether to build
  with libunwind, which causes undeterministic builds or error:
 
  | 
  tmp/work/core2-64-wrs-linux/libinput/0.18.0-r0/libinput-0.18.0/test/litest.c:77:23:
  | fatal error: libunwind.h: No such file or directory
 
  So add configure arg and PACKAGECONFIG for libunwind to make
  deterministic build, but libunwind is disable by default.
 
  Signed-off-by: Jackie Huang jackie.hu...@windriver.com
  ---
   ...input-configure.ac-add-arg-with-libunwind.patch | 44 
  ++
   meta/recipes-graphics/wayland/libinput_0.18.0.bb   |  7 +++-
   2 files changed, 50 insertions(+), 1 deletion(-)
   create mode 100644 
  meta/recipes-graphics/wayland/libinput/libinput-configure.ac-add-arg-with-
 libunwind.patch
 
  diff --git 
  a/meta/recipes-graphics/wayland/libinput/libinput-configure.ac-add-arg-with-
 libunwind.patch 
 b/meta/recipes-graphics/wayland/libinput/libinput-configure.ac-add-arg-with-
 libunwind.patch
  new file mode 100644
  index 000..4090c50
  --- /dev/null
  +++ 
  b/meta/recipes-graphics/wayland/libinput/libinput-configure.ac-add-arg-with-libunwind.patch
  @@ -0,0 +1,44 @@
  +From 713a3892edc94f63e5968b1bb99ea2e08fecfa5d Mon Sep 17 00:00:00 2001
  +From: Jackie Huang jackie.hu...@windriver.com
  +Date: Mon, 3 Aug 2015 20:33:44 -0700
  +Subject: [PATCH] configure.ac: add arg --with-libunwind
  +
  +add arg --with-libunwind for configure so it's optional
  +to check libunwind, and we can use it in bitbake's
  +PACKAGECONFIG to make deterministic builds.
  +
  +Upstream-Status: Inappropriate [OE specific]
 
 Are you sure? I would like to see this sent upstream: I expect they
 will take it as we are not the only people who care about
 deterministic builds.
 
 That said, with --with-libunwind configure should fail if unwind is
 not found. Your patch does not seem to do this -- see comment below
 
 Cheers,
   Jussi
 
 
  +
  +Signed-off-by: Jackie Huang jackie.hu...@windriver.com
  +---
  + configure.ac | 11 ++-
  + 1 file changed, 10 insertions(+), 1 deletion(-)
  +
  +diff --git a/configure.ac b/configure.ac
  +index 314b0d4..7a31aa9 100644
  +--- a/configure.ac
   b/configure.ac
  +@@ -60,10 +60,19 @@ PKG_PROG_PKG_CONFIG()
  + PKG_CHECK_MODULES(MTDEV, [mtdev = 1.1.0])
  + PKG_CHECK_MODULES(LIBUDEV, [libudev])
  + PKG_CHECK_MODULES(LIBEVDEV, [libevdev = 0.4])
  +-PKG_CHECK_MODULES(LIBUNWIND,
  ++
  ++AC_ARG_WITH(libunwind,
  ++AS_HELP_STRING([--with-libunwind],[Build with libunwind]))
  ++
  ++if test x$with_libunwind = xyes; then
  ++  PKG_CHECK_MODULES(LIBUNWIND,
  + [libunwind],
  + [HAVE_LIBUNWIND=yes],
  + [HAVE_LIBUNWIND=no])
  ++else
  ++  HAVE_LIBUNWIND=no
  ++fi
  ++
  + if test x$HAVE_LIBUNWIND = xyes; then
  +   AC_DEFINE(HAVE_LIBUNWIND, 1, [Have libunwind support])
  + fi
 
 
 Configure will succeed if --with-libunwind is set but unwind is not
 present: this should not happen.  Something like this should work
 correctly in both cases (please check that though: I wrote without
 testing):

Yes, you are right, this should be happen. I will check and re-patch, thanks!

Thanks,
Jackie

 
 
 AC_ARG_WITH([libunwind],
 AS_HELP_STRING([--without-libunwind], [Do not use libunwind]))
 
 AS_IF([test x$with_libunwind != xno],
   [PKG_CHECK_MODULES(LIBUNWIND,
  [libunwind],
  [have_libunwind=yes],
  [have_libunwind=no])],
   [have_libunwind=no])
 
 AS_IF([test x$have_libunwind = xyes],
   [AC_DEFINE(HAVE_LIBUNWIND, 1, [Have libunwind support])],
   [AS_IF([test x$with_libunwind = xyes],
  [AC_MSG_ERROR([libunwind requested but not found])])])
 
  +--
  +2.3.5
  +
  diff --git a/meta/recipes-graphics/wayland/libinput_0.18.0.bb 
  b/meta/recipes-
 graphics/wayland/libinput_0.18.0.bb
  index 0fe1c6c..8e8e6a7 100644
  --- a/meta/recipes-graphics/wayland/libinput_0.18.0.bb
  +++ b/meta/recipes-graphics/wayland/libinput_0.18.0.bb
  @@ -7,11 +7,16 @@ LIC_FILES_CHKSUM =
 file://COPYING;md5=2184aef38ff137ed33ce9a63b9d1eb8f
 
   DEPENDS = libevdev udev mtdev
 
  -SRC_URI = http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz;
  +SRC_URI = http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz \
  +   file://libinput-configure.ac-add-arg-with-libunwind.patch \
  +
   SRC_URI[md5sum] = 0ddbb0d53d58dec0a86de6791560011a
   SRC_URI[sha256sum] = 
  64a70f96bab17a22eaf2fd7af17cf83def3388374096c7623be9448f62808cda
 
   inherit autotools

Re: [OE-core] [PATCH v2] qemu: CVE-2014-3689

[Huang, Jie (Jackie)]

Sorry I didn’t notice the upgrate, this patch is not needed with this upgrate, 
thanks!

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, July 24, 2015 6:26 AM
To: Huang, Jie (Jackie)
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2] qemu: CVE-2014-3689


On 23 July 2015 at 02:53, Huang, Jie (Jackie) 
jackie.hu...@windriver.commailto:jackie.hu...@windriver.com wrote:
Ping.

We're now at 2.4.0-rc1 in master and a patch for rc2 is on the list.  Does this 
still need to be applied?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] qemu: CVE-2014-3689

[Huang, Jie (Jackie)]

Ping.

Thanks,
Jackie

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of jackie.hu...@windriver.com
 Sent: Thursday, July 02, 2015 5:02 PM
 To: openembedded-core@lists.openembedded.org
 Subject: [OE-core] [PATCH v2] qemu: CVE-2014-3689
 
 From: Li Wang li.w...@windriver.com
 
 the patch comes from:
 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3689
 http://git.qemu.org/?p=qemu.git;a=commit;h=83afa38eb20ca27e30683edc7729880e091387fc
 
 vmware-vga: CVE-2014-3689: turn off hw accel
 
 Quick  easy stopgap for CVE-2014-3689:  We just compile out the hardware 
 acceleration functions
 which lack sanity checks.  Thankfully we have capability bits for them 
 (SVGA_CAP_RECT_COPY and
 SVGA_CAP_RECT_FILL), so guests should deal just fine, in theory.
 
 Subsequent patches will add the missing checks and re-enable the hardware 
 acceleration emulation.
 
 Cc: qemu-sta...@nongnu.org
 Signed-off-by: Gerd Hoffmann kra...@redhat.com
 Reviewed-by: Don Koch dk...@verizon.com
 Signed-off-by: Li Wang li.w...@windriver.com
 ---
  .../qemu/qemu/qemu-CVE-2014-3689.patch | 46 
 ++
  meta/recipes-devtools/qemu/qemu_2.3.0.bb   |  1 +
  2 files changed, 47 insertions(+)
  create mode 100644 meta/recipes-devtools/qemu/qemu/qemu-CVE-2014-3689.patch
 
 diff --git a/meta/recipes-devtools/qemu/qemu/qemu-CVE-2014-3689.patch 
 b/meta/recipes-
 devtools/qemu/qemu/qemu-CVE-2014-3689.patch
 new file mode 100644
 index 000..a0c3931
 --- /dev/null
 +++ b/meta/recipes-devtools/qemu/qemu/qemu-CVE-2014-3689.patch
 @@ -0,0 +1,46 @@
 +qemu: CVE-2014-3689
 +
 +the patch comes from:
 +https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3689
 +http://git.qemu.org/?p=qemu.git;a=commit;h=83afa38eb20ca27e30683edc7729
 +880e091387fc
 +
 +vmware-vga: CVE-2014-3689: turn off hw accel
 +
 +Quick  easy stopgap for CVE-2014-3689:  We just compile out the
 +hardware acceleration functions which lack sanity checks.  Thankfully
 +we have capability bits for them (SVGA_CAP_RECT_COPY and
 +SVGA_CAP_RECT_FILL), so guests should deal just fine, in theory.
 +
 +Subsequent patches will add the missing checks and re-enable the
 +hardware acceleration emulation.
 +
 +Cc: qemu-sta...@nongnu.org
 +Signed-off-by: Gerd Hoffmann kra...@redhat.com
 +Reviewed-by: Don Koch dk...@verizon.com
 +
 +Upstream-Status: Backport
 +
 +Signed-off-by: Li Wang li.w...@windriver.com
 +---
 + hw/display/vmware_vga.c |2 ++
 + 1 file changed, 2 insertions(+)
 +
 +diff --git a/hw/display/vmware_vga.c b/hw/display/vmware_vga.c index
 +591b645..99a97fe 100644
 +--- a/hw/display/vmware_vga.c
  b/hw/display/vmware_vga.c
 +@@ -29,9 +29,11 @@
 + #include hw/pci/pci.h
 +
 + #undef VERBOSE
 ++#if 0
 + #define HW_RECT_ACCEL
 + #define HW_FILL_ACCEL
 + #define HW_MOUSE_ACCEL
 ++#endif
 +
 + #include vga_int.h
 +
 +--
 +1.7.9.5
 +
 diff --git a/meta/recipes-devtools/qemu/qemu_2.3.0.bb b/meta/recipes-
 devtools/qemu/qemu_2.3.0.bb
 index ec1b101..917febe 100644
 --- a/meta/recipes-devtools/qemu/qemu_2.3.0.bb
 +++ b/meta/recipes-devtools/qemu/qemu_2.3.0.bb
 @@ -18,6 +18,7 @@ SRC_URI += 
 file://configure-fix-Darwin-target-detection.patch \
  
 file://09-xen-pt-mark-reserved-bits-in-PCI-config-space-fields-CVE-2015-4106.patch
  \
  
 file://10-xen-pt-add-a-few-PCI-config-space-field-descriptions-CVE-2015-4106.patch
  \
  
 file://11-xen-pt-unknown-PCI-config-space-fields-should-be-readonly-CVE-2015-4106.patch
  \
 +file://qemu-CVE-2014-3689.patch \
 
  SRC_URI_prepend = http://wiki.qemu-project.org/download/${BP}.tar.bz2;
  SRC_URI[md5sum] = 2fab3ea4460de9b57192e5b8b311f221
 --
 1.9.1
 
 --
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] xorg-proto-common: allow the empty package

[Huang, Jie (Jackie)]

I see your point, I think we can make the empty PN rdepends on PN-dev(but the 
dev-deps QA check need to be skipped),

then when user try to add PN, PN-dev will also be installed, so it’s not an 
useless empty package.



I see that openssh has similar situation, PN is allowed empty, but it rdepends 
on “${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen”.



Does it make sense to you?



Thanks,

Jackie


From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, July 03, 2015 5:14 PM
To: Martin Jansa
Cc: Huang, Jie (Jackie); OE-core
Subject: Re: [OE-core] [PATCH] xorg-proto-common: allow the empty package


On 3 July 2015 at 10:04, Martin Jansa 
martin.ja...@gmail.commailto:martin.ja...@gmail.com wrote:
I as a customer would definitely prefer error message even later in the
build then getting completely useless empty package installed in my
image and blame you for installing it when I was expecting to find
bigreqsproto in my rootfs.

Agreed.  Installing bigreqsproto and not getting anything is far more annoying 
than the error and following epiphany that if you want the development headers 
for bigreqsproto you should install bigreqsproto-dev.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] xorg-proto-common: allow the empty package

[Huang, Jie (Jackie)]

Thanks for the explanation. I think you’re suggesting that we do nothing for 
such issue or
just tell the user to use PN-dev for this kind of packages, right?

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, July 03, 2015 5:39 PM
To: Huang, Jie (Jackie)
Cc: Martin Jansa; OE-core
Subject: Re: [OE-core] [PATCH] xorg-proto-common: allow the empty package


On 3 July 2015 at 10:34, Huang, Jie (Wind River) 
jackie.hu...@windriver.commailto:jackie.hu...@windriver.com wrote:

I see your point, I think we can make the empty PN rdepends on PN-dev(but the 
dev-deps QA check need to be skipped),

then when user try to add PN, PN-dev will also be installed, so it’s not an 
useless empty package.

bigreqsproto is development headers.  Therefore its in the bigreqsproto-dev 
package.  This is not hard to understand, nor should we start filling the feeds 
up with empty packages just to please users who can't verify the package names.

Didn't we have this discussion a few months ago?  There are some recipes where 
PN not existing is unusual (avahi was a good example, and I had a partial 
branch to fix that), but for recipes which entirely consist of development 
files, there only being a development package is reasonable and predictable.

(If I *had* to do this, I'd have RPROVIDES_${PN}-dev += ${PN})

I see that openssh has similar situation, PN is allowed empty, but it rdepends 
on “${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen”.
That's a different use case entirely: pulling in the entire SSH suite in a 
single package whilst still allowing resource-constrained or secure systems to 
pull in only the parts they want.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] qemu: CVE-2014-3689

[Huang, Jie (Jackie)]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of jackie.hu...@windriver.com
 Sent: Thursday, July 02, 2015 2:43 PM
 To: openembedded-core@lists.openembedded.org
 Subject: [OE-core] [PATCH] qemu: CVE-2014-3689
 
 From: Li Wang li.w...@windriver.com
 
 Issue: LIN7-2153

Sorry, this should be removed, please ignore this.

Thanks,
Jackie

 
 the patch comes from:
 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3689
 http://git.qemu.org/?p=qemu.git;a=commit;h=83afa38eb20ca27e30683edc7729880e091387fc
 
 vmware-vga: CVE-2014-3689: turn off hw accel
 
 Quick  easy stopgap for CVE-2014-3689:  We just compile out the hardware 
 acceleration functions
 which lack sanity checks.  Thankfully we have capability bits for them 
 (SVGA_CAP_RECT_COPY and
 SVGA_CAP_RECT_FILL), so guests should deal just fine, in theory.
 
 Subsequent patches will add the missing checks and re-enable the hardware 
 acceleration emulation.
 
 Cc: qemu-sta...@nongnu.org
 Signed-off-by: Gerd Hoffmann kra...@redhat.com
 Reviewed-by: Don Koch dk...@verizon.com
 Signed-off-by: Li Wang li.w...@windriver.com
 ---
  .../qemu/qemu/qemu-CVE-2014-3689.patch | 46 
 ++
  meta/recipes-devtools/qemu/qemu_2.3.0.bb   |  1 +
  2 files changed, 47 insertions(+)
  create mode 100644 meta/recipes-devtools/qemu/qemu/qemu-CVE-2014-3689.patch
 
 diff --git a/meta/recipes-devtools/qemu/qemu/qemu-CVE-2014-3689.patch 
 b/meta/recipes-
 devtools/qemu/qemu/qemu-CVE-2014-3689.patch
 new file mode 100644
 index 000..a0c3931
 --- /dev/null
 +++ b/meta/recipes-devtools/qemu/qemu/qemu-CVE-2014-3689.patch
 @@ -0,0 +1,46 @@
 +qemu: CVE-2014-3689
 +
 +the patch comes from:
 +https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3689
 +http://git.qemu.org/?p=qemu.git;a=commit;h=83afa38eb20ca27e30683edc7729
 +880e091387fc
 +
 +vmware-vga: CVE-2014-3689: turn off hw accel
 +
 +Quick  easy stopgap for CVE-2014-3689:  We just compile out the
 +hardware acceleration functions which lack sanity checks.  Thankfully
 +we have capability bits for them (SVGA_CAP_RECT_COPY and
 +SVGA_CAP_RECT_FILL), so guests should deal just fine, in theory.
 +
 +Subsequent patches will add the missing checks and re-enable the
 +hardware acceleration emulation.
 +
 +Cc: qemu-sta...@nongnu.org
 +Signed-off-by: Gerd Hoffmann kra...@redhat.com
 +Reviewed-by: Don Koch dk...@verizon.com
 +
 +Upstream-Status: Backport
 +
 +Signed-off-by: Li Wang li.w...@windriver.com
 +---
 + hw/display/vmware_vga.c |2 ++
 + 1 file changed, 2 insertions(+)
 +
 +diff --git a/hw/display/vmware_vga.c b/hw/display/vmware_vga.c index
 +591b645..99a97fe 100644
 +--- a/hw/display/vmware_vga.c
  b/hw/display/vmware_vga.c
 +@@ -29,9 +29,11 @@
 + #include hw/pci/pci.h
 +
 + #undef VERBOSE
 ++#if 0
 + #define HW_RECT_ACCEL
 + #define HW_FILL_ACCEL
 + #define HW_MOUSE_ACCEL
 ++#endif
 +
 + #include vga_int.h
 +
 +--
 +1.7.9.5
 +
 diff --git a/meta/recipes-devtools/qemu/qemu_2.3.0.bb b/meta/recipes-
 devtools/qemu/qemu_2.3.0.bb
 index ec1b101..917febe 100644
 --- a/meta/recipes-devtools/qemu/qemu_2.3.0.bb
 +++ b/meta/recipes-devtools/qemu/qemu_2.3.0.bb
 @@ -18,6 +18,7 @@ SRC_URI += 
 file://configure-fix-Darwin-target-detection.patch \
  
 file://09-xen-pt-mark-reserved-bits-in-PCI-config-space-fields-CVE-2015-4106.patch
  \
  
 file://10-xen-pt-add-a-few-PCI-config-space-field-descriptions-CVE-2015-4106.patch
  \
  
 file://11-xen-pt-unknown-PCI-config-space-fields-should-be-readonly-CVE-2015-4106.patch
  \
 +file://qemu-CVE-2014-3689.patch \
 
  SRC_URI_prepend = http://wiki.qemu-project.org/download/${BP}.tar.bz2;
  SRC_URI[md5sum] = 2fab3ea4460de9b57192e5b8b311f221
 --
 1.9.1
 
 --
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] xorg-proto-common: allow the empty package

[Huang, Jie (Jackie)]

Yeah I know it’s not good to have the empty package and we can remove 
dependencies to void error, but
our customer may add the package through IMAGE_INSTALL in local.conf and blame 
it fails until do_rootfs:

ERROR: bigreqsproto not found in the base feeds (intel_x86_64 core2-64 x86_64 
noarch any all).

Do we have a way to find out a PN package is empty at an earlier time so that 
we may warn the user not
to add this package into image?

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, July 03, 2015 3:40 AM
To: Huang, Jie (Jackie)
Cc: OE-core
Subject: Re: [OE-core] [PATCH] xorg-proto-common: allow the empty package


On 1 July 2015 at 08:52, 
jackie.hu...@windriver.commailto:jackie.hu...@windriver.com wrote:
 # ${PN} is empty so we need to tweak -dev and -dbg package dependencies
+# and allow ${PN} to be created empty
+ALLOW_EMPTY_${PN} = 1
 RDEPENDS_${PN}-dev = 
 RRECOMMENDS_${PN}-dbg = ${PN}-dev (= ${EXTENDPKGV})

As the comment and surrounding lines state, the dependencies on PN from PN-dev 
and PN-dbg are already removed.  What other package has a runtime dependency on 
PN, and when you find it a better solution is to remove the dependency instead 
of creating empty packages.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] license.bbclass: allow copying license not in common licenses

[Huang, Jie (Jackie)]

 -Original Message-
 From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
 Sent: Monday, April 27, 2015 10:52 PM
 To: Huang, Jie (Jackie)
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH 1/3] license.bbclass: allow copying license not 
 in common licenses
 
 Hi Jackie,
 
 A couple of comments in-line below.
 
 On Thursday 23 April 2015 17:38:15 jackie.hu...@windriver.com wrote:
  From: Jackie Huang jackie.hu...@windriver.com
 
  Some package like linux-firmware has many licenses that aren't in any
  way common, and new ones will be added from time to time, in order to
  avoid adding bunch of such common license files that are only
  applicable to a specific package, NO_GENERIC_LIC is added to allow
  copying license not in common licenses, it should be used in the recipe as:
 
  NO_GENERIC_LIC[license_name] = license file in fetched source
 
  e.g.
  NO_GENERIC_LIC[Firmware-Abilis] = LICENCE.Abilis.txt
 
 Can we rename this to NO_GENERIC_LICENSE?

Yes, sure, I will rename it.

 
 
  Signed-off-by: Jackie Huang jackie.hu...@windriver.com
  ---
   meta/classes/license.bbclass | 12 +++-
   1 file changed, 11 insertions(+), 1 deletion(-)
 
  diff --git a/meta/classes/license.bbclass
  b/meta/classes/license.bbclass index 73a0e97..990f704 100644
  --- a/meta/classes/license.bbclass
  +++ b/meta/classes/license.bbclass
  @@ -222,7 +222,9 @@ def find_license_files(d):
   pass
   spdx_generic = None
   license_source = None
  -# If the generic does not exist we need to check to see if there is
  an SPDX mapping to it
  +# If the generic does not exist we need to
  check to see if there is an SPDX mapping to it,
  +# unless NO_GENERIC_LIC is set.
  +
   for lic_dir in license_source_dirs:
   if not os.path.isfile(os.path.join(lic_dir, license_type)):
   if d.getVarFlag('SPDXLICENSEMAP', license_type) != None:
  @@ -241,6 +243,14 @@ def find_license_files(d):
   # audit up. This should be fixed in emit_pkgdata (or, we
  actually got and fix all the recipes)
 
   lic_files_paths.append((generic_
   + license_type, os.path.join(license_source,
  spdx_generic)))
  +
  +elif d.getVarFlag('NO_GENERIC_LIC', license_type):
  +# if NO_GENERIC_LIC is set, we copy the license files
  + from the
  fetched source +# of the package rather than the
  license_source_dirs. +for (basename, path) in lic_files_paths:
  +if d.getVarFlag('NO_GENERIC_LIC', license_type) ==
  basename:
  +lic_files_paths.append((generic_ +
  license_type, path))
  +break
   else:
   # And here is where we warn people that their licenses
  are lousy
   bb.warn(%s: No generic license file exists for: %s in any
   provider % (pn, license_type))
 
 Should we detect and warn when the user is attempting to override a common 
 license with this
 mechanism (which shouldn't be allowed)?

Yes, we should, it doesn't make sense to use this mechanism for a common 
license, I will add that.

Thanks
Jackie

 
 Cheers,
 Paul
 
 --
 
 Paul Eggleton
 Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] nss: improve the script signlibs.sh

[Huang, Jie (Jackie)]

Ping, is this going to be merged?

Thanks,
Jackie

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of jackie.hu...@windriver.com
 Sent: Wednesday, March 25, 2015 10:19 AM
 To: openembedded-core@lists.openembedded.org
 Subject: [OE-core] [PATCH] nss: improve the script signlibs.sh
 
 From: Jackie Huang jackie.hu...@windriver.com
 
 The *.chk files are installed in ${libdir} by nss, which is already known, no 
 need to 'find' to get the file
 list, and 'ls' is more faster than 'find'.
 
 Signed-off-by: Jackie Huang jackie.hu...@windriver.com
 ---
  meta/recipes-support/nss/nss/signlibs.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/meta/recipes-support/nss/nss/signlibs.sh 
 b/meta/recipes-support/nss/nss/signlibs.sh
 index 1ec79f4..a74e499 100644
 --- a/meta/recipes-support/nss/nss/signlibs.sh
 +++ b/meta/recipes-support/nss/nss/signlibs.sh
 @@ -9,7 +9,7 @@
  # calculated on the host where they really need to be done on the  # target
 
 -CHK_FILES=`find /lib* /usr/lib* -name *.chk`
 +CHK_FILES=`ls /lib*/*.chk /usr/lib*/*.chk 2/dev/null`
  SIGN_BINARY=`which shlibsign`
  for I in $CHK_FILES
  do
 --
 1.9.1
 
 --
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] linux-firmware: fix the mess of licenses

[Huang, Jie (Jackie)]

 -Original Message-
 From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
 Sent: Friday, April 17, 2015 7:02 PM
 To: Huang, Jie (Jackie)
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH 0/2] linux-firmware: fix the mess of licenses
 
 Hi Jackie,
 
 On Monday 13 April 2015 10:17:19 jackie.hu...@windriver.com wrote:
  From: Jackie Huang jackie.hu...@windriver.com
 
  linux-firmware includes many firmwares and each firmware has their own
  license, previously the LICENSE is set to Proprietary and some
  firmware is split out to separate package such as
  linux-firmware-radeon and LICENSE_linux-firmware-radeon is set to
  Firmware-radeon, but there is no license file in the common-licenses, so 
  we got a lot warnings
 like:
 
  WARNING: The license listed Firmware-radeon was not in the licenses
  collected for linux-firmware
 
  These include adding the missing license files and re-orgnize the
  codes to fix the warnings and avoid the mess.
 
 So doing this cleanup is good, thanks; but I was wondering if we needed an 
 alternative approach for
 linux-firmware. Most of the licenses in it aren't in any way common, and new 
 ones will be added
 from time to time, requiring us to not only update the recipe (probably 
 unavoidable) but also add
 the licenses to the common license directory. Is there any way we could make 
 it so we at least only
 have to update the recipe and dispense with the need to add a bunch of common 
 license files that
 are only applicable to linux-firmware?

Maybe we can keep those linux-firmware licenses in the recipe directory instead 
of COMMON_LICENSE_DIR
and add LICENSE_PATH += ${COREBASE}/meta/ recipes-kernel/linux-firmware/files?

Thanks,
Jackie

 
 Cheers,
 Paul
 
 --
 
 Paul Eggleton
 Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] linux-firmware: fix the mess of licenses

[Huang, Jie (Jackie)]

 -Original Message-
 From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
 Sent: Monday, April 20, 2015 4:20 PM
 To: Huang, Jie (Jackie)
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH 0/2] linux-firmware: fix the mess of licenses
 
 On Monday 20 April 2015 07:33:34 Huang, Jie wrote:
   -Original Message-
   From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
   Sent: Friday, April 17, 2015 7:02 PM
   To: Huang, Jie (Jackie)
   Cc: openembedded-core@lists.openembedded.org
   Subject: Re: [OE-core] [PATCH 0/2] linux-firmware: fix the mess of
   licenses
  
   Hi Jackie,
  
   On Monday 13 April 2015 10:17:19 jackie.hu...@windriver.com wrote:
From: Jackie Huang jackie.hu...@windriver.com
   
linux-firmware includes many firmwares and each firmware has their
own license, previously the LICENSE is set to Proprietary and
some firmware is split out to separate package such as
linux-firmware-radeon and LICENSE_linux-firmware-radeon is set to
Firmware-radeon, but there is no license file in the
common-licenses, so we got a lot warnings
   like:
WARNING: The license listed Firmware-radeon was not in the
licenses collected for linux-firmware
   
These include adding the missing license files and re-orgnize the
codes to fix the warnings and avoid the mess.
  
   So doing this cleanup is good, thanks; but I was wondering if we
   needed an alternative approach for linux-firmware. Most of the
   licenses in it aren't in any way common, and new ones will be added
   from time to time, requiring us to not only update the recipe
   (probably unavoidable) but also add the licenses to the common
   license directory. Is there any way we could make it so we at least
   only have to update the recipe and dispense with the need to add a
   bunch of common license files that are only applicable to linux-firmware?
 
  Maybe we can keep those linux-firmware licenses in the recipe
  directory instead of COMMON_LICENSE_DIR and add LICENSE_PATH +=
  ${COREBASE}/meta/ recipes-kernel/linux-firmware/files?
 
 Could we go one step further and copy the license files from the fetched 
 source rather than having to
 add them to the recipe?

Yes, it's better, I will take a look if we can make this work.

Thanks,
Jackie

 
 Cheers,
 Paul
 
 --
 
 Paul Eggleton
 Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] glib-2.0: filter out -fvisibility=default option

[Huang, Jie (Jackie)]

 -Original Message-
 From: otavio.salva...@gmail.com [mailto:otavio.salva...@gmail.com] On Behalf 
 Of Otavio Salvador
 Sent: Friday, December 26, 2014 10:02 PM
 To: Huang, Jie (Jackie)
 Cc: Patches and discussions about the oe-core layer
 Subject: Re: [OE-core] [PATCH] glib-2.0: filter out -fvisibility=default 
 option
 
 On Thu, Dec 25, 2014 at 1:41 AM,  jackie.hu...@windriver.com wrote:
  From: Jackie Huang jackie.hu...@windriver.com
 
  Once -fvisibility=default option is added, matchbox-desktop will run
  into segfault, so filter it out as a workaround for now.
 
  [YOCTO #7099]
 
  Signed-off-by: Jackie Huang jackie.hu...@windriver.com
 
 Sorry but I think this needs fixing in matchbox-desktop and not a workaround 
 here in a library which

Ok, I will try to fix it in matchbox-desktop.

Thanks,
Jackie

 is used in several projects.
 
 --
 Otavio Salvador O.S. Systems
 http://www.ossystems.com.brhttp://code.ossystems.com.br
 Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] classextend: Do not extend for that already have multilib prefix

[Huang, Jie (Jackie)]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of jackie.hu...@windriver.com
 Sent: Saturday, November 08, 2014 7:20 PM
 To: openembedded-core@lists.openembedded.org
 Subject: [OE-core] [PATCH] classextend: Do not extend for that already have 
 multilib prefix
 
 From: Jackie Huang jackie.hu...@windriver.com
 
 If a BSP supports two or more multilibs, for example:
 
 MULTILIBS = multilib:lib32 multilib:lib64
 
 and a variable is already extended to include multilib variants, for example 
 in populate_sdk_base:
 
 commit 396371588c7fd2d691ca9c39cd02287e43cb665b
 Author: Richard Purdie richard.pur...@linuxfoundation.org
 Date: Thu Jul 24 22:09:09 2014 +0100
 
 populate_sdk_base: Extend TOOLCHAIN_TARGET_TASK to include multilib 
 variants
 
 Most people expect the toolchain from a multilib build to contain multilib
 components. This change makes that happen and is easy for users to 
 override
 should they want something different.
 
 Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
 
 The mapping clsextend.map_depends_variable(TOOLCHAIN_TARGET_TASK)
 ends up with a wrong double extended package name like:
 
 lib32-lib64-packagegroup-core-standalone-sdk-target
 
 This patch avoid such issues.
 
 Signed-off-by: Jackie Huang jackie.hu...@windriver.com
 ---
  meta/lib/oe/classextend.py | 7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/meta/lib/oe/classextend.py b/meta/lib/oe/classextend.py index 
 68efca3..5c993de 100644
 --- a/meta/lib/oe/classextend.py
 +++ b/meta/lib/oe/classextend.py
 @@ -57,6 +57,13 @@ class ClassExtender(object):
  if dep.endswith((-native, -native-runtime)) or ('nativesdk-' in 
 dep) or ('cross-canadian' in dep)
 or ('-crosssdk-' in dep):
  return dep
  else:
 +# Do not extend for that already have multilib prefix
 +var = self.d.getVar(MULTILIB_VARIANTS, True) or 

Robert suggests the 'or ' is not needed, so please ignore this, I will send 
v2 for the change.

Thanks,
Jackie

 +if var:
 +var = var.split()
 +for v in var:
 +if dep.startswith(v):
 +return dep
  return self.extend_name(dep)
 
  def map_depends_variable(self, varname, suffix = ):
 --
 2.0.0
 
 --
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] linux-firmware: resolve linux-firmware and microcode-ctl file conflicts

[Huang, Jie (Jackie)]

 -Original Message-
 From: Huang, Jie (Jackie)
 Sent: Thursday, October 23, 2014 1:14 PM
 To: 'Otavio Salvador'
 Cc: Patches and discussions about the oe-core layer
 Subject: RE: [OE-core] [PATCH] linux-firmware: resolve linux-firmware and 
 microcode-ctl file conflicts
 
 
 
  -Original Message-
  From: otavio.salva...@gmail.com [mailto:otavio.salva...@gmail.com] On
  Behalf Of Otavio Salvador
  Sent: Wednesday, October 22, 2014 9:12 PM
  To: Huang, Jie (Jackie)
  Cc: Patches and discussions about the oe-core layer
  Subject: Re: [OE-core] [PATCH] linux-firmware: resolve linux-firmware
  and microcode-ctl file conflicts
 
  On Wed, Oct 22, 2014 at 6:36 AM,  jackie.hu...@windriver.com wrote:
   From: Yue Tao yue@windriver.com
  
   Use alternatives mechanism to prevent linux-firmware and
   microcode-ctl bin files from causing conflicts.
  
   The error is :
  
   error: file /lib/firmware/amd-ucode/microcode_amd.bin from install
   of linux-firmware conflicts with file from package
   microcode-ctl-firmware
  
   error: file /lib/firmware/amd-ucode/microcode_amd_fam15h.bin from
   install of linux-firmware conflicts with file from package
   microcode-ctl-firmware
  
   Signed-off-by: Yue Tao yue@windriver.com
 
  * The firmware should be split in a specific package, if possible (in
  a separated patch)
 
 Thanks for pointing this, I will re-work on it.
 
  * microcode-ctl-firmware does not exist here
 
 Yes, I know, but we have it in our own layer.
 
  * microcode-ctl-firmware seems useless if you can rely on linux-firmware to 
  provide the file.
 
 Maybe, but someone may choose to use the one provided by 
 microcode-ctl-firmware.

We have fixed this in microcode-ctl-firmware, so this patch is not needed.

Thanks,
Jackie

 
 Thanks,
 Jackie
 
 
  --
  Otavio Salvador O.S. Systems
  http://www.ossystems.com.brhttp://code.ossystems.com.br
  Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] gcc: fix ICE in dwarf2out_var_location

[Huang, Jie (Jackie)]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of Peter A. Bigot
 Sent: Wednesday, October 29, 2014 9:45 PM
 To: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH] gcc: fix ICE in dwarf2out_var_location
 
 On 10/29/2014 08:32 AM, Mark Hatle wrote:
  On 10/29/14, 8:15 AM, Mark Hatle wrote:
  On 10/29/14, 5:59 AM, Peter A. Bigot wrote:
  On 10/28/2014 10:41 PM, Khem Raj wrote:
  On Tue, Oct 28, 2014 at 7:34 PM, jackie.hu...@windriver.com wrote:
  From: Jackie Huang jackie.hu...@windriver.com
 
  Fixed the ICE:
  internal compiler error: in dwarf2out_var_location, at
  dwarf2out.c:21261
 
  this looks ok. but we need the test case too. and a nit more
  documentation
 
  Agreed.  We're getting a lot of Wind River patches these days that
  are pretty sparse on context and justification.
 
  For backport patches to GCC and most other projects, I'd really love
  to see them provided by cloning the upstream repository and using
  format-patch on the upstream commit that's being backported. This
  practice of discarding all that relevant information in favor of a
  terse
 
  I just want to be clear the information isn't being discarded or
  removed.  The original work is being done by taking the latest
  tree, and diffing sections of the code to find a relevant fix -- or
  looking in the mailing list for discussions on similar problems.
 
  Also as far as I know the upstream gcc repository is still SVN, so
  the format-patch git methods don't work.  Yes, I know there are
  people who have converted the GCC SVN to git, but these are not
  canonical sources -- so I'm not sure that is really an acceptable
  place to work.
 
  See: https://gcc.gnu.org
  Our sources are readily and freely available via SVN and weekly
  snapshots.
 
  Just to follow up, there is an apparently undocumented git mirror of
  the SVN on the GNU site.  I still don't know if it's a canonical
  source, but since it's on the GNU website, I'd have to assume it is.
 
  git://gcc.gnu.org/git/gcc.git
 
 Yes, that's the one I was referring to.  It's the source of the gcc backport 
 patches I've added to OE.
 
 Using it, the specific fix referenced has apparently not been backported to 
 gcc-4_9-branch.
 
 Nor does it appear in trunk.
 
 Trunk has 5e9c670f06b9eaa52db639b888e0b0d15ba864c1 which may or may not be 
 fixing the same
 bug, but is definitely not this patch.

Yeah, it's not, sorry that the patch I sent is not upstream, the status is 
wrong, it is actually an early version
we were using. The upstream version fix for this issue is:
https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=212171

but it introduced a regression issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348

which has been fixed by:
https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=215613

so I will send v2 with backporting these two patches.

Thanks,
Jackie

 
 So I'd have to say that, if the submitted patch is a backport, then all the 
 upstream context required to
 understand it has indeed been removed, and this patch to OE should be 
 retracted.
 
 
  (I really wish GNU would get away from SVN...)
 
 Ditto, but it's unlikely to happen.  Too big an impact to too many
 people.  That mirror is what I've used for gcc work for a couple years now.
 
 Peter
 
 
  --Mark
 
  submitter-defined description makes it difficult to keep the OE patch
  set current on upstream updates and trust in the appropriateness of the
  patch.  Add only your sign-off and the Upstream-Status with a reference
  to the upstream bugreport.
 
  As for the other component critiques, I agree.. the message needs more
  information, and if possible more information on what the backport
  actually
  originated from is needed as well.  This example is terse at best and
  generally
  not acceptable.
 
  --Mark
 
  You might look at gcc-4.9's OE patch
  0055-PR-rtl-optimization-61801.patch for an example.
 
  Peter
 
 
  Signed-off-by: Jackie Huang jackie.hu...@windriver.com
  ---
  meta/recipes-devtools/gcc/gcc-4.9.inc  | 1 +
  .../0058-gcc-ice-dwarf2out_var_location.patch  | 31
  ++
  2 files changed, 32 insertions(+)
  create mode 100644
  meta/recipes-devtools/gcc/gcc-4.9/0058-gcc-ice-dwarf2out_var_location.patch
 
  diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc
  b/meta/recipes-devtools/gcc/gcc-4.9.inc
  index 9a66cd2..89c405a 100644
  --- a/meta/recipes-devtools/gcc/gcc-4.9.inc
  +++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
  @@ -71,6 +71,7 @@ SRC_URI = \
  file://0054-gcc-Makefile.in-fix-parallel-building-failure.patch \
  file://0055-PR-rtl-optimization-61801.patch \
  file://0056-top-level-reorder_gcc-bug-61144.patch \
  +file://0058-gcc-ice-dwarf2out_var_location.patch \
  
  SRC_URI[md5sum] = fddf71348546af523353bd43d34919c1
  SRC_URI[sha256sum] =
  

Re: [OE-core] [PATCH] which-2.18: Make sure ChangeLog exists for automake

[Huang, Jie (Jackie)]

 -Original Message-
 From: Martin Jansa [mailto:martin.ja...@gmail.com]
 Sent: Monday, October 27, 2014 5:53 PM
 To: Huang, Jie (Jackie)
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH] which-2.18: Make sure ChangeLog exists for 
 automake
 
 On Mon, Oct 27, 2014 at 05:44:42AM -0400, jackie.hu...@windriver.com wrote:
  From: Jackie Huang jackie.hu...@windriver.com
 
  Fixed:
  Makefile.am: error: required file './ChangeLog' not found
 
 Isn't it better to pass foreign to automake?

Yes, it's better, I will change it, thanks!

Thanks,
Jackie

 
 
  Signed-off-by: Jackie Huang jackie.hu...@windriver.com
  ---
   meta/recipes-extended/which/which_2.18.bb | 3 +++
   1 file changed, 3 insertions(+)
 
  diff --git a/meta/recipes-extended/which/which_2.18.bb b/meta/recipes-
 extended/which/which_2.18.bb
  index 5fa5d9e..49e9248 100644
  --- a/meta/recipes-extended/which/which_2.18.bb
  +++ b/meta/recipes-extended/which/which_2.18.bb
  @@ -25,6 +25,9 @@ do_configure_prepend() {
  OLD=@ACLOCAL_CWFLAGS@
  NEW=-I ${STAGING_DIR_NATIVE}/${datadir}/cwautomacros/m4
  sed -i s#${OLD}#${NEW}#g `grep -rl ${OLD} ${S}`
  +
  +   # Make sure ChangeLog exists for automake
  +   touch ${S}/ChangeLog
   }
 
   ALTERNATIVE_${PN} = which
  --
  2.0.0
 
  --
  ___
  Openembedded-core mailing list
  Openembedded-core@lists.openembedded.org
  http://lists.openembedded.org/mailman/listinfo/openembedded-core
 
 --
 Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] which-2.18: Make sure ChangeLog exists for automake

[Huang, Jie (Jackie)]

The upstream seems not active any more, the home page 
(http://carlo17.home.xs4all.nl/which/) is dead,
and the last update in cvs is 6 years ago: 
http://cvs.savannah.gnu.org/viewvc/which/?root=which

I will add a path with upstream-status inappropriate.

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Monday, October 27, 2014 6:52 PM
To: Martin Jansa
Cc: Huang, Jie (Jackie); OE-core
Subject: Re: [OE-core] [PATCH] which-2.18: Make sure ChangeLog exists for 
automake

On 27 October 2014 09:52, Martin Jansa 
martin.ja...@gmail.commailto:martin.ja...@gmail.com wrote:
On Mon, Oct 27, 2014 at 05:44:42AM -0400, 
jackie.hu...@windriver.commailto:jackie.hu...@windriver.com wrote:
 From: Jackie Huang 
 jackie.hu...@windriver.commailto:jackie.hu...@windriver.com

 Fixed:
 Makefile.am: error: required file './ChangeLog' not found

Isn't it better to pass foreign to automake?

Yes, and talk to upstream to understand why this isn't a problem.  Some 
upstreams are unaware of autoreconf and continue using home-grown tools.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libgcrypt: Fix ARM assembly when building __PIC__

[Huang, Jie (Jackie)]

 -Original Message-
 From: Burton, Ross [mailto:ross.bur...@intel.com]
 Sent: Monday, September 15, 2014 10:23 PM
 To: Huang, Jie (Jackie)
 Cc: OE-core
 Subject: Re: [OE-core] [PATCH] libgcrypt: Fix ARM assembly when building 
 __PIC__
 
 On 15 September 2014 11:16,  jackie.hu...@windriver.com wrote:
  +++ 
  b/meta/recipes-support/libgcrypt/files/libgcrypt-1.6.1-make-arm-asm-fPIC-friendly.patch
 
 This is missing upstream-status/signed-off-by tags.

I had added the status and signed-off, could you re-check?

+Signed-off-by: Jussi Kivilinna jussi.kivili...@iki.fi
+
+Upstream-Status: Backport
+
+Signed-off-by: Jackie Huang jackie.hu...@windriver.com
+---

Thanks,
Jackie

 
 Also, Andrea said:
  Instead of patching 1.6.1, wouldn't it be better to update to 
  libgcrypt_1.6.2 ?
 
 No, we've feature frozen now, so a backport is appropriate.
 
 Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ghostscript: add missing dependencies on libgcrypt and libgpg-error

[Huang, Jie (Jackie)]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of Peter A. Bigot
 Sent: Friday, August 15, 2014 6:54 PM
 To: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH] ghostscript: add missing dependencies on 
 libgcrypt and libgpg-error
 
 On 08/15/2014 04:52 AM, Huang, Jie (Jackie) wrote:
  Ping, could someone help merge this? thanks!
 
 That should have been fixed when cups was updated to not introduce false 
 dependencies on libgcrypt.
 Have you tried with current master?

Yes, but ghostscript use the cups inside its source code, so the issue is still 
there, I will port the fix from
Cups for ghostscript, thanks!

Thanks,
Jackie

 
 Peter
 
 
  Thanks,
  Jackie
 
  -Original Message-
  From: openembedded-core-boun...@lists.openembedded.org
  [mailto:openembedded-core- boun...@lists.openembedded.org] On Behalf
  Of jackie.hu...@windriver.com
  Sent: Wednesday, July 30, 2014 3:55 PM
  To: openembedded-core@lists.openembedded.org
  Subject: [OE-core] [PATCH] ghostscript: add missing dependencies on
  libgcrypt and libgpg-error
 
  From: Jackie Huang jackie.hu...@windriver.com
 
  Fix error:
  tmp/sysroots/x86_64-linux/usr/libexec/x86_64-wrs-linux/gcc/x86_64-wrs
  -linux/4.9.0/ld: cannot find - lgcrypt
  tmp/sysroots/x86_64-linux/usr/libexec/x86_64-wrs-linux/gcc/x86_64-wrs
  -linux/4.9.0/ld: cannot find - lgpg-error
 
  Signed-off-by: Jackie Huang jackie.hu...@windriver.com
  ---
.../ghostscript/ghostscript_9.14.bb|2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.14.bb
  b/meta/recipes- extended/ghostscript/ghostscript_9.14.bb
  index e14e656..fbec6ce 100644
  --- a/meta/recipes-extended/ghostscript/ghostscript_9.14.bb
  +++ b/meta/recipes-extended/ghostscript/ghostscript_9.14.bb
  @@ -15,7 +15,7 @@ SECTION = console/utils
LICENSE = GPLv3
LIC_FILES_CHKSUM = file://LICENSE;md5=aad21ea85123608e6a0a58d54ee23567
 
  -DEPENDS = ghostscript-native tiff jpeg fontconfig cups
  +DEPENDS = ghostscript-native tiff jpeg fontconfig cups libgcrypt 
  libgpg-error
DEPENDS_class-native = 
 
SRC_URI_BASE = 
  http://downloads.ghostscript.com/public/ghostscript-${PV}.tar.gz;
  --
  1.7.9.5
 
  --
  ___
  Openembedded-core mailing list
  Openembedded-core@lists.openembedded.org
  http://lists.openembedded.org/mailman/listinfo/openembedded-core
 
 --
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssl: add DEPENDS on openssl-native for rehash

[Huang, Jie (Jackie)]

No, I should be _append, sorry for that, I will fix and resend.

Thanks,
Jackie

From: kerg...@gmail.com [mailto:kerg...@gmail.com] On Behalf Of Christopher 
Larson
Sent: Monday, August 18, 2014 10:36 PM
To: Huang, Jie (Jackie)
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH] openssl: add DEPENDS on openssl-native for rehash


On Mon, Aug 18, 2014 at 3:12 AM, 
jackie.hu...@windriver.commailto:jackie.hu...@windriver.com wrote:
 DEPENDS = perl-native-runtime
+DEPENDS_class-target = openssl-native

This is removing the perl-native-runtime dependency for the target recipe, is 
that really the intent?
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ghostscript: add missing dependencies on libgcrypt and libgpg-error

[Huang, Jie (Jackie)]

 -Original Message-
 From: Saul Wold [mailto:s...@linux.intel.com]
 Sent: Saturday, August 16, 2014 12:56 AM
 To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH] ghostscript: add missing dependencies on 
 libgcrypt and libgpg-error
 
 On 07/30/2014 12:54 AM, jackie.hu...@windriver.com wrote:
  From: Jackie Huang jackie.hu...@windriver.com
 
  Fix error:
  tmp/sysroots/x86_64-linux/usr/libexec/x86_64-wrs-linux/gcc/x86_64-wrs-linux/4.9.0/ld:
   cannot find
 -lgcrypt
  tmp/sysroots/x86_64-linux/usr/libexec/x86_64-wrs-linux/gcc/x86_64-wrs-linux/4.9.0/ld:
   cannot find
 -lgpg-error
 
 Are these true dependencies or are there optional configurations that
 should be covered with PACKAGECONFIG?

I didn't find optional configurations for them.

  There is a patch to disable gcrypt.

You mean cups-no-gcrypt.patch, right? It looks reasonable, I will port it for 
ghostscript. Thanks!

Thanks,
Jackie

 
 Is this meant to be a daisy patch?
 
 Sau!
 
 
 
  Signed-off-by: Jackie Huang jackie.hu...@windriver.com
  ---
.../ghostscript/ghostscript_9.14.bb|2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.14.bb 
  b/meta/recipes-
 extended/ghostscript/ghostscript_9.14.bb
  index e14e656..fbec6ce 100644
  --- a/meta/recipes-extended/ghostscript/ghostscript_9.14.bb
  +++ b/meta/recipes-extended/ghostscript/ghostscript_9.14.bb
  @@ -15,7 +15,7 @@ SECTION = console/utils
LICENSE = GPLv3
LIC_FILES_CHKSUM = file://LICENSE;md5=aad21ea85123608e6a0a58d54ee23567
 
  -DEPENDS = ghostscript-native tiff jpeg fontconfig cups
  +DEPENDS = ghostscript-native tiff jpeg fontconfig cups libgcrypt 
  libgpg-error
DEPENDS_class-native = 
 
SRC_URI_BASE = 
  http://downloads.ghostscript.com/public/ghostscript-${PV}.tar.gz;
 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ghostscript: add missing dependencies on libgcrypt and libgpg-error

[Huang, Jie (Jackie)]

Ping, could someone help merge this? thanks!

Thanks,
Jackie

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of jackie.hu...@windriver.com
 Sent: Wednesday, July 30, 2014 3:55 PM
 To: openembedded-core@lists.openembedded.org
 Subject: [OE-core] [PATCH] ghostscript: add missing dependencies on libgcrypt 
 and libgpg-error
 
 From: Jackie Huang jackie.hu...@windriver.com
 
 Fix error:
 tmp/sysroots/x86_64-linux/usr/libexec/x86_64-wrs-linux/gcc/x86_64-wrs-linux/4.9.0/ld:
  cannot find -
 lgcrypt
 tmp/sysroots/x86_64-linux/usr/libexec/x86_64-wrs-linux/gcc/x86_64-wrs-linux/4.9.0/ld:
  cannot find -
 lgpg-error
 
 Signed-off-by: Jackie Huang jackie.hu...@windriver.com
 ---
  .../ghostscript/ghostscript_9.14.bb|2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.14.bb 
 b/meta/recipes-
 extended/ghostscript/ghostscript_9.14.bb
 index e14e656..fbec6ce 100644
 --- a/meta/recipes-extended/ghostscript/ghostscript_9.14.bb
 +++ b/meta/recipes-extended/ghostscript/ghostscript_9.14.bb
 @@ -15,7 +15,7 @@ SECTION = console/utils
  LICENSE = GPLv3
  LIC_FILES_CHKSUM = file://LICENSE;md5=aad21ea85123608e6a0a58d54ee23567
 
 -DEPENDS = ghostscript-native tiff jpeg fontconfig cups
 +DEPENDS = ghostscript-native tiff jpeg fontconfig cups libgcrypt 
 libgpg-error
  DEPENDS_class-native = 
 
  SRC_URI_BASE = 
 http://downloads.ghostscript.com/public/ghostscript-${PV}.tar.gz;
 --
 1.7.9.5
 
 --
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages

[Huang, Jie (Jackie)]

 -Original Message-
 From: Koen Kooi [mailto:k...@dominion.thruhere.net]
 Sent: Monday, July 28, 2014 2:30 PM
 To: Huang, Jie (Jackie)
 Cc: OE-core; Richard Purdie
 Subject: Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages
 
 
 Op 25 jul. 2014, om 12:05 heeft jackie.hu...@windriver.com het volgende 
 geschreven:
 
  From: Jackie Huang jackie.hu...@windriver.com
 
  All dev related items should be packaged in the core PN-dev package
  not in seperate packages.
 
 What's the upgrade path here for image and users that have 'alsa-dev' 
 installed? Looks like there are

My patch is removing 'alsa-dev' and all related files goes into '${PN}-dev' 
(PN=alsa-lib here), so users need to install
alsa-lib-dev instead of alsa-dev.

 now 2 conflicting packages, 'alsa-dev' in the feeds and 'alsa-lib-dev' on OE, 
 without and

Only 'alsa-lib-dev' now with my patch, so no conflicts.

Thanks,
Jackie

 RREPLACES/RPROVIDES in place.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages

[Huang, Jie (Jackie)]

 
 Op 28 jul. 2014, om 08:49 heeft Huang, Jie (Jackie) 
 jackie.hu...@windriver.com het volgende
 geschreven:
 
 
 
  -Original Message-
  From: Koen Kooi [mailto:k...@dominion.thruhere.net]
  Sent: Monday, July 28, 2014 2:30 PM
  To: Huang, Jie (Jackie)
  Cc: OE-core; Richard Purdie
  Subject: Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev
  packages
 
 
  Op 25 jul. 2014, om 12:05 heeft jackie.hu...@windriver.com het volgende 
  geschreven:
 
  From: Jackie Huang jackie.hu...@windriver.com
 
  All dev related items should be packaged in the core PN-dev package
  not in seperate packages.
 
  What's the upgrade path here for image and users that have 'alsa-dev'
  installed? Looks like there are
 
  My patch is removing 'alsa-dev' and all related files goes into
  '${PN}-dev' (PN=alsa-lib here), so users need to install alsa-lib-dev 
  instead of alsa-dev.
 
 *sigh* So you have no upgrade path for situations where 'alsa-dev' is already 
 installed or listed in a
 packagegroup or image. Worse, you don't even understand the problem :/

I see your point, I did grep on oe-core and meta-oe and didn't find any 
evidence that 'alsa-dev' is installed or listed
In a packagegroup or image, so I thought it's safe to remove without 
RREPLACES/RPROVIDES in place, sorry that I did
a wrong assumption, I will add a RPROVIDES for this, thanks!

Thanks,
Jackie

 
 
  now 2 conflicting packages, 'alsa-dev' in the feeds and
  'alsa-lib-dev' on OE, without and
 
  Only 'alsa-lib-dev' now with my patch, so no conflicts.
 
 Hahahahahaha you are really funny.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages

[Huang, Jie (Jackie)]

 -Original Message-
 From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
 Sent: Monday, July 28, 2014 5:25 PM
 To: Koen Kooi
 Cc: Huang, Jie (Jackie); OE-core; RIFENBARK, SCOTT
 Subject: Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages
 
 On Mon, 2014-07-28 at 10:51 +0200, Koen Kooi wrote:
  Op 28 jul. 2014, om 08:49 heeft Huang, Jie (Jackie) 
  jackie.hu...@windriver.com het volgende
 geschreven:
   -Original Message-
   From: Koen Kooi [mailto:k...@dominion.thruhere.net]
   Sent: Monday, July 28, 2014 2:30 PM
   To: Huang, Jie (Jackie)
   Cc: OE-core; Richard Purdie
   Subject: Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev
   packages
  
  
   Op 25 jul. 2014, om 12:05 heeft jackie.hu...@windriver.com het volgende 
   geschreven:
  
   From: Jackie Huang jackie.hu...@windriver.com
  
   All dev related items should be packaged in the core PN-dev
   package not in seperate packages.
  
   What's the upgrade path here for image and users that have
   'alsa-dev' installed? Looks like there are
  
   My patch is removing 'alsa-dev' and all related files goes into
   '${PN}-dev' (PN=alsa-lib here), so users need to install alsa-lib-dev 
   instead of alsa-dev.
 
  *sigh* So you have no upgrade path for situations where 'alsa-dev' is
  already installed or listed in a packagegroup or image. Worse, you
  don't even understand the problem :/
 
  
   now 2 conflicting packages, 'alsa-dev' in the feeds and
   'alsa-lib-dev' on OE, without and
  
   Only 'alsa-lib-dev' now with my patch, so no conflicts.
 
  Hahahahahaha you are really funny.
 
 I appreciate there is a problem here and we need to fix that. There is also 
 an education issue, people
 who don't know much about it don't appreciate the struggles of someone 
 maintaining package feeds.

Sorry that I got misunderstanding about the commets since I didn't know much 
the issue, I appreciate that
and will send another patch to fix it since this one is already merged.

Thanks,
Jackie

 
 Perhaps someone could write a short section for the docs about the issues 
 here? In future when this
 kind of problem comes up, we can then at least point at the manual section to 
 explain it.
 
 Currently, most docs come from the same old people, I'm partly writing this 
 to remind people that
 others can submit them and that they can help massively in educating people.
 
 They don't even need to be proper patches against the docs, just write a few 
 paragraphs, send it Scott
 Rifenbark's way and he can usually do something with it. He tends to reword 
 things so the manual has
 a consistent tone and style anyway so it needn't be word perfect either, its 
 the content that matters
 (and that is the part Scott cannot do).
 
 Cheers,
 
 Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] alsa-lib: Add RPROVIDES for alsa-dev

[Huang, Jie (Jackie)]

 -Original Message-
 From: Burton, Ross [mailto:ross.bur...@intel.com]
 Sent: Monday, July 28, 2014 10:24 PM
 To: Huang, Jie (Jackie)
 Cc: OE-core
 Subject: Re: [OE-core] [PATCH] alsa-lib: Add RPROVIDES for alsa-dev
 
 On 28 July 2014 15:19,  jackie.hu...@windriver.com wrote:
  +RPROVIDES_${PN}-dev = alsa-dev
 
 I believe you'll want replaces and conflicts too, so that alsa-dev gets 
 removed.

Thanks for pointing this, but I think I'm still not fully understand what's 
required to get a package
removed, I referred to the commit  4bac11f util-linux: remove non PN based 
-dev packages
and thought adding the RPROVIDES is enough, would you mind explaining a little 
more?

Thanks,
Jackie

 
 Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libxfont: fix for CVE-2014-0209 CVE-2014-0210 CVE-2014-0211

[Huang, Jie (Jackie)]

 -Original Message-
 From: Burton, Ross [mailto:ross.bur...@intel.com]
 Sent: Wednesday, July 23, 2014 4:27 PM
 To: Huang, Jie (Jackie)
 Cc: OE-core
 Subject: Re: [OE-core] [PATCH] libxfont: fix for CVE-2014-0209 CVE-2014-0210 
 CVE-2014-0211
 
 On 23 July 2014 09:04,  jackie.hu...@windriver.com wrote:
  0001-CVE-2014-0209-integer-overflow-of-realloc-size-in-Fo.patch
  CVE-2014-0209:
  Multiple integer overflows in the (1) FontFileAddEntry and
  (2) lexAlias functions in X.Org libXfont before 1.4.8 and 1.4.9x
  before 1.4.99.901 might allow local users to gain privileges by adding
  a directory with a large fonts.dir or fonts.alias file to the font
  path, which triggers a heap-based buffer overflow, related to
  metadata.
 
  CVE-2014-0210:
  Multiple buffer overflows in X.Org libXfont before 1.4.8 and 1.4.9x
  before 1.4.99.901 allow remote font servers to execute arbitrary code
  via a crafted xfs protocol reply to the
  (1) _fs_recv_conn_setup, (2) fs_read_open_font,
  (3) fs_read_query_info, (4) fs_read_extent_info,
  (5) fs_read_glyphs, (6) fs_read_list, or
  (7) fs_read_list_info function.
 
  CVE-2014-0211:
  Multiple integer overflows in the (1) fs_get_reply,
  (2) fs_alloc_glyphs, and (3) fs_read_extent_info functions in X.Org
  libXfont before 1.4.8 and 1.4.9x before 1.4.99.901 allow remote font
  servers to execute arbitrary code via a crafted xfs reply, which
  triggers a buffer overflow.
 
 I sent an upgrade to 1.5.0 yesterday, which has all of these integrated.

Oh, sorry I didn't notice that, thanks for reminding.

Thanks,
Jackie

 
 Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] setserial: package depends on groff-native to build

[Huang, Jie (Jackie)]

 -Original Message-
 From: Burton, Ross [mailto:ross.bur...@intel.com]
 Sent: Monday, July 14, 2014 6:32 PM
 To: Huang, Jie (Jackie)
 Cc: OE-core
 Subject: Re: [OE-core] [PATCH] setserial: package depends on groff-native to 
 build
 
 On 14 July 2014 10:03,  jackie.hu...@windriver.com wrote:
  Add explicit depends to avoid host contamination.
 
 That's not host contamination, please reword the commit to explain that it's 
 a missing build

Sure, I will resend v2 for this.

Thanks,
Jackie

 dependency.
 
 Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] postfix: add new recipe

[Huang, Jie (Jackie)]

Ok, meta-networking is fine to me, I will resend although I had already resent 
to meta-oe.

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, July 11, 2014 7:46 PM
To: Martin Jansa
Cc: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 0/1] postfix: add new recipe

Meta-networking seems the obvious home to me.

Ross

On Friday, 11 July 2014, Martin Jansa 
martin.ja...@gmail.commailto:martin.ja...@gmail.com wrote:
On Fri, Jul 11, 2014 at 12:20:13PM +0200, Martin Jansa wrote:
 On Thu, Jul 10, 2014 at 09:57:56PM -0400, 
 jackie.hu...@windriver.comjavascript:; wrote:
  From: Jackie Huang jackie.hu...@windriver.comjavascript:;
 
  Postfix is Wietse Venema's mail server that started life at IBM
  research as an alternative to the widely-used Sendmail program.
 
  Postfix attempts to be fast, easy to administer, and secure.
  The outside has a definite Sendmail-ish flavor, but the inside
  is completely different.

 Why is it sent to oe-core and meta-oe at the same time?


I'm sorry, I should have finished reading whole backlog before
not-sending this.

I agree with other reviewers it's better in meta-oe (maybe
meta-networking?)

--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.comjavascript:;
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] postfix: add new recipe

[Huang, Jie (Jackie)]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of Anders Darander
 Sent: Friday, July 11, 2014 3:34 PM
 To: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH 0/1] postfix: add new recipe
 
 * jackie.hu...@windriver.com jackie.hu...@windriver.com [140711 03:58]:
  We ported postfix from openembedded a year ago, and updated it to
  2.9.5, now we are updating it to the latest stable release 2.11.1, and
  I'm sending here to see if oe-core take it, if not, I will send it to 
  meta-oe.
 
 I think meta-oe is a better place for postfix. So, please resend it to 
 meta-oe.

Ok, I will resend to meta-oe.

Thanks,
Jackie

 
 Cheers,
 Anders
 
 --
 Anders Darander
 ChargeStorm AB / eStorm AB
 --
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] qt4-4.8.6: fix CVE-2014-0190

[Huang, Jie (Jackie)]

 -Original Message-
 From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
 Sent: Wednesday, June 18, 2014 6:06 PM
 To: Huang, Jie (Jackie)
 Cc: Zhu, Yanjun; openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH 2/2] qt4-4.8.6: fix CVE-2014-0190
 
 Hi Jackie,
 
 On Wednesday 18 June 2014 05:41:31 jackie.hu...@windriver.com wrote:
  From: yzhu1 yanjun@windriver.com
 
  The GIF decoder in QtGui in Qt before 5.3 allows remote attackers to
  cause a denial of service (NULL pointer dereference) via invalid width
  and height values in a GIF image.
  Per: http://cwe.mitre.org/data/definitions/476.html
 
  CWE-476: NULL Pointer Dereference
 
  http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0190
  Signed-off-by: yzhu1 yanjun@windriver.com
  Signed-off-by: Jackie Huang jackie.hu...@windriver.com
  ---
   meta/recipes-qt/qt4/qt4-4.8.6.inc  |  1 +
   .../qt4-4.8.6/qt4-4.8.6-fix-CVE-2014-0190.patch| 31
  ++ 2 files changed, 32 insertions(+)
   create mode 100644
  meta/recipes-qt/qt4/qt4-4.8.6/qt4-4.8.6-fix-CVE-2014-0190.patch
 
  diff --git a/meta/recipes-qt/qt4/qt4-4.8.6.inc
  b/meta/recipes-qt/qt4/qt4-4.8.6.inc index ae6692b..9db77c9 100644
  --- a/meta/recipes-qt/qt4/qt4-4.8.6.inc
  +++ b/meta/recipes-qt/qt4/qt4-4.8.6.inc
  @@ -24,6 +24,7 @@ SRC_URI =
  http://download.qt-project.org/official_releases/qt/4.8/${PV}/qt-ever
  file://0028-Don-t-crash-on-broken-GIF-images.patch \
  file://g++.conf \
  file://linux.conf \
  +   file://qt4-4.8.6-fix-CVE-2014-0190.patch \
  
 
   SRC_URI[md5sum] = 2edbe4d6c2eff33ef91732602f3518eb
  diff --git
  a/meta/recipes-qt/qt4/qt4-4.8.6/qt4-4.8.6-fix-CVE-2014-0190.patch
  b/meta/recipes-qt/qt4/qt4-4.8.6/qt4-4.8.6-fix-CVE-2014-0190.patch new
  file mode 100644 index 000..b8baea8
  --- /dev/null
  +++ b/meta/recipes-qt/qt4/qt4-4.8.6/qt4-4.8.6-fix-CVE-2014-0190.patch
  @@ -0,0 +1,31 @@
  +Upstream-status: Pending
  +Don't crash on broken GIF images
  +
  +Broken GIF images could set invalid width and height values inside
  +the image, leading to Qt creating a null QImage for it. In that case
  +we need to abort decoding the image and return an error.
  +
  +Initial patch by Rich Moore.
  +
  +Task-number: QTBUG-38367
  +Change-Id: Id82a4036f478bd6e49c402d6598f57e7e5bb5e1e
  +Security-advisory: CVE-2014-0190
  +Reviewed-by: Richard J. Moore r...@kde.org
  +
  +--- a/src/gui/image/qgifhandler.cpp
   b/src/gui/image/qgifhandler.cpp
  +@@ -359,6 +359,13 @@ int QGIFFormat::decode(QImage *image, co
  + memset(bits, 0, image-byteCount());
  + }
  +
  ++// Check if the previous attempt to create the image
  failed. If it ++// did then the image is broken and we
  should give up. ++if (image-isNull()) {
  ++state = Error;
  ++return -1;
  ++}
  ++
  + disposePrevious(image);
  + disposed = false;
  +
 
 This upstream patch is already being applied within the recipe - see 
 0028-Don-t-crash-on-broken-GIF-
 images.patch.

Sorry I didn't notice it, thanks for pointing out and please ignore this.

Thanks,
Jackie

 
 Cheers,
 Paul
 
 --
 
 Paul Eggleton
 Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] setserial: package depends on groff-native to build

[Huang, Jie (Jackie)]

Ping, can someone merge this?

Thanks,
Jackie

 -Original Message-
 From: jackie.hu...@windriver.com [mailto:jackie.hu...@windriver.com]
 Sent: Wednesday, March 26, 2014 3:52 PM
 To: openembedded-core@lists.openembedded.org
 Cc: Huang, Jie (Jackie)
 Subject: [PATCH] setserial: package depends on groff-native to build
 
 From: Yue Tao yue@windriver.com
 
 Signed-off-by: Jonas Zetterberg jonas.zetterb...@windriver.com
 Signed-off-by: Yue Tao yue@windriver.com
 Signed-off-by: Jackie Huang jackie.hu...@windriver.com
 ---
  meta/recipes-bsp/setserial/setserial_2.17.bb |2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/meta/recipes-bsp/setserial/setserial_2.17.bb b/meta/recipes-
 bsp/setserial/setserial_2.17.bb
 index 65d6068..f1e8cd3 100644
 --- a/meta/recipes-bsp/setserial/setserial_2.17.bb
 +++ b/meta/recipes-bsp/setserial/setserial_2.17.bb
 @@ -8,6 +8,8 @@ LICENSE = GPLv2.0
  LIC_FILES_CHKSUM =
 file://version.h;beginline=1;endline=6;md5=2e7c59cb9e57e356ae81f50f4e4dfd99
  PR = r3
 
 +DEPENDS += groff-native
 +
  inherit autotools-brokensep
 
  SRC_URI = ${SOURCEFORGE_MIRROR}/setserial/${BPN}-${PV}.tar.gz \
 --
 1.7.9.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-commits] Jackie Huang : gdk-pixbuf: fix the postinstall script failure when no icon is installed

[Huang, Jie (Jackie)]

On Thu, Aug 16, 2012 at 12:33:08PM +0200, Martin Jansa wrote:
 On Wed, Aug 15, 2012 at 01:32:02PM +, g...@git.openembedded.org wrote:
  Module: openembedded-core.git
  Branch: master
  Commit: 1d4fbe4761d3d97e3c4b6e894719ee41b21559b2
  URL:
  http://git.openembedded.org/?p=openembedded-core.gita=commit;h=1d4fbe4761d3d97e3c4b6e894719ee41b21559b2
 
  Author: Jackie Huang jackie.hu...@windriver.com
  Date:   Thu Aug  9 10:30:30 2012 +0800
 
  gdk-pixbuf: fix the postinstall script failure when no icon is installed
 
  If gtk+ is added to core-image-minimal, postinstall script failed on boot:
 
  Running postinst /etc/rpm-postinsts/104...
  gtk-update-icon-cache: No theme index file.
  ERROR: postinst /etc/rpm-postinsts/104 failed.
 
  This patch fixed the postinstall script to check for the icon
  file first and not run the gtk-update-icon-cache if no icon
  is installed.
 
  [YOCTO #2905]
 
  Signed-off-by: Jackie Huang jackie.hu...@windriver.com
  Signed-off-by: Saul Wold s...@linux.intel.com


 Even with this patch I get:
 Configuring gdk-pixbuf-loader-png.
 gtk-update-icon-cache: No theme index file.
 Configuring gdk-pixbuf-loader-jpeg.
 gtk-update-icon-cache: No theme index file.
 Configuring gdk-pixbuf-loader-xpm.
 gtk-update-icon-cache: No theme index file.
 Configuring gdk-pixbuf-loader-gif.
 gtk-update-icon-cache: No theme index file.
 Collected errors:
  * pkg_run_script: package gdk-pixbuf-loader-png postinst script
  * returned status 1.
  * opkg_configure: gdk-pixbuf-loader-png.postinst returned 1.
  * pkg_run_script: package gdk-pixbuf-loader-jpeg postinst script
  * returned status 1.
  * opkg_configure: gdk-pixbuf-loader-jpeg.postinst returned 1.
  * pkg_run_script: package gdk-pixbuf-loader-xpm postinst script
  * returned status 1.
  * opkg_configure: gdk-pixbuf-loader-xpm.postinst returned 1.
  * pkg_run_script: package gdk-pixbuf-loader-gif postinst script
  * returned status 1.
  * opkg_configure: gdk-pixbuf-loader-gif.postinst returned 1.

This problem is caused by
openembedded-core/meta/recipes-graphics/xcursor-transparent-theme/xcursor-transparent-theme_0.1.1.bb
which does not provide index.theme file


Well, in my case, there is no icon installed so there is on ${datadir}/icons at 
all.

Thanks,
Jackie

and commit message of this change should be something like
gdk-pixbuf: call gtk-update-icon-cache for each subdir of ${datadir}/icons
not
gdk-pixbuf: fix the postinstall script failure when no icon is installed

Cheers,

  -test -x ${bindir}/gtk-update-icon-cache  gtk-update-icon-cache  -q 
  ${datadir}/icons/hicolor
  +if [ -x ${bindir}/gtk-update-icon-cache ]  [ -d ${datadir}/icons ]; then
  +for icondir in /usr/share/icons/*; do
  +if [ -d ${icondir} ]; then
  +gtk-update-icon-cache -q ${icondir}
  +fi
  +done
  +fi
   }
 
   PACKAGES_DYNAMIC += gdk-pixbuf-loader-*
 
 
  ___
  Openembedded-commits mailing list
  openembedded-comm...@lists.openembedded.org
  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits

 --
 Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com



--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] useradd.bbclass: use locking of bb.utils to avoid lock race issue of useradd/groupadd

[Huang, Jie (Jackie)]

On Sun, 2012-07-22 at 14:53 +0800, jackie.hu...@windriver.com wrote:
 From: Jackie Huang jackie.hu...@windriver.com

 A race condition can occur when adding users and groups to the
passwd and group files, in [YOCTO #1794], 10 times retry added
 but it is not fixed completely.

 This fix re-writes the useradd_preinst and useradd_sysroot with
 python and use locking of bb.utils to lock the passwd and group
 files before executing useradd/groupadd commands to avoid the
 lock race themselves.

 [YOCTO #2779]

 Signed-off-by: Jackie Huang jackie.hu...@windriver.com
 ---
  meta/classes/useradd.bbclass |  284 
 ++
  1 files changed, 124 insertions(+), 160 deletions(-)

Please resend this with the whitespace issues resolved. Its near
impossible to review as it stands :(

Re-sent, sorry about that.

Thanks,
Jackie


Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core