Re: [OE-core] [meta-xilinx] liblzma: Memory allocation failed on do_package_rpm

2018-01-15 Thread Alejandro Enedino Hernandez Samaniego
Hey Manju,

I'd like to see if I can reproduce this, could you please send the the steps 
you followed?

Thanks!

Alejandro

-Original Message-
From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Manjukumar 
Harthikote Matha
Sent: Sunday, January 14, 2018 10:20 PM
To: openembedded-core@lists.openembedded.org; yo...@yoctoproject.org; 
meta-xil...@yoctoproject.org
Subject: [meta-xilinx] liblzma: Memory allocation failed on do_package_rpm

All,

Has anybody seen this error?

Finished binary package job, result 0, filename (null)
error: create archive failed: cpio: write failed - Cannot allocate memory
error: liblzma: Memory allocation failederror: liblzma: Memory allocation 
failedFinished binary package job, result 2,

...

RPM build errors:
| Deprecated external dependency generator is used!
| Deprecated external dependency generator is used!
| Deprecated external dependency generator is used!
| Deprecated external dependency generator is used!
| Deprecated external dependency generator is used!
| Deprecated external dependency generator is used!
| Deprecated external dependency generator is used!
| Deprecated external dependency generator is used!
| Deprecated external dependency generator is used!
| liblzma: Memory allocation failedliblzma: Memory allocation failed
liblzma: Memory allocation failedliblzma: Memory allocation failed
liblzma: Memory allocation failedliblzma: Memory allocation failed

This happens in do_package_rpm task on various recipes, 
coreutils/libgpg/diffutils etc.

The host machine has good amount on memory, 256G to be exact. When I see the 
error and issue free -h command, I still see ~120G free memory available.
This is a RHEL 7.2 machine and I am running rocko baseline.

Any reason why this would happen? Where should I look to fix this issue?

Thanks,
Manju
This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
-- 
___
meta-xilinx mailing list
meta-xil...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2018-01-15 Thread jackie.huang
From: Jackie Huang 

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 on glibc-utils for libnss-db, and add RSUGGESTS on make
  since it's optional to generate the db with make.

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

Signed-off-by: Jackie Huang 
---
 meta/recipes-core/glibc/glibc-package.inc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 817d850358..6ee33e61e6 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,9 @@ 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"
+RSUGGESTS_libnss-db = "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 +62,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


[OE-core] [PATCH 0/1 v3] glibc: re-package for libnss-db

2018-01-15 Thread jackie.huang
From: Jackie Huang 

v3 comments:
Change the dependency on make to RSUGGESTS.

--
The following changes since commit b9dcab772fd37ed8376a87d3194195e13ff52d10:

  qemu: CVE-2017-17381 (2018-01-14 09:11:58 +)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib.git jhuang0/d_nscd_v3_180116_0
  http://git.pokylinux.org/cgit.cgi//log/?h=jhuang0/d_nscd_v3_180116_0

Jackie Huang (1):
  glibc: re-package for libnss-db

 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



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

2018-01-15 Thread 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 
> %s" %
> (result.status, result.output))
> AssertionError: 1 != 0 : Bitbake failed, exit code 1, output Parsing 
> recipes...done.
> Parsing of 829 .bb files complete (0 cached, 829 parsed). 1287 targets, 99
> skipped, 0 masked, 0 errors.
> Removing 35 recipes from the core2-64 sysroot...done.
> Removing 35 recipes from the qemux86-64 sysroot...done.
> NOTE: Resolving any missing task queue dependencies
> 

[OE-core] [PATCH] python/python3: use cc_basename to replace CC for checking compiler

2018-01-15 Thread Li Zhou
When working path contains "clang"/"gcc"/"icc", it might be part of $CC
because of the "--sysroot" parameter. That could cause judgement error
about clang/gcc/icc compilers. e.g.
When "icc" is containded in working path, below errors are reported when
compiling python/python3:
x86_64-wrs-linux-gcc: error: strict: No such file or directory
x86_64-wrs-linux-gcc: error: unrecognized command line option '-fp-model'

Here use cc_basename to replace CC for checking compiler to avoid such
kind of issue.

Signed-off-by: Li Zhou 
---
 ...cc_basename-to-replace-CC-for-checking-co.patch | 118 ++
 ...-cc_basename-to-replace-CC-for-checking-c.patch | 136 +
 meta/recipes-devtools/python/python3_3.5.3.bb  |   1 +
 meta/recipes-devtools/python/python_2.7.13.bb  |   1 +
 4 files changed, 256 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python/0001-python-use-cc_basename-to-replace-CC-for-checking-co.patch
 create mode 100644 
meta/recipes-devtools/python/python3/0001-python3-use-cc_basename-to-replace-CC-for-checking-c.patch

diff --git 
a/meta/recipes-devtools/python/python/0001-python-use-cc_basename-to-replace-CC-for-checking-co.patch
 
b/meta/recipes-devtools/python/python/0001-python-use-cc_basename-to-replace-CC-for-checking-co.patch
new file mode 100644
index 000..fae324f
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python/0001-python-use-cc_basename-to-replace-CC-for-checking-co.patch
@@ -0,0 +1,118 @@
+From b60dea18372dabbef0ec9abf06855e209af4f53d Mon Sep 17 00:00:00 2001
+From: Li Zhou 
+Date: Tue, 16 Jan 2018 10:31:49 +0800
+Subject: [PATCH] python: use cc_basename to replace CC for checking compiler
+
+When working path contains "clang"/"gcc"/"icc", it might be part of $CC
+because of the "--sysroot" parameter. That could cause judgement error
+about clang/gcc/icc compilers. e.g.
+When "icc" is containded in working path, below errors are reported when
+compiling python:
+x86_64-wrs-linux-gcc: error: strict: No such file or directory
+x86_64-wrs-linux-gcc: error: unrecognized command line option '-fp-model'
+
+Here use cc_basename to replace CC for checking compiler to avoid such
+kind of issue.
+
+Upstream-Status: Pending
+
+Signed-off-by: Li Zhou 
+---
+ configure.ac | 19 ++-
+ 1 file changed, 10 insertions(+), 9 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index dcf733f..f1e9a7b 100644
+--- a/configure.ac
 b/configure.ac
+@@ -15,6 +15,7 @@ AC_CONFIG_HEADER(pyconfig.h)
+ AC_CANONICAL_HOST
+ AC_SUBST(build)
+ AC_SUBST(host)
++LT_INIT
+ 
+ # pybuilddir.txt will be created by --generate-posix-vars in the Makefile
+ rm -f pybuilddir.txt
+@@ -670,7 +671,7 @@ AC_MSG_RESULT($with_cxx_main)
+ preset_cxx="$CXX"
+ if test -z "$CXX"
+ then
+-case "$CC" in
++case "$cc_basename" in
+ gcc)AC_PATH_TOOL(CXX, [g++], [g++], [notfound]) ;;
+ cc) AC_PATH_TOOL(CXX, [c++], [c++], [notfound]) ;;
+ esac
+@@ -743,14 +744,14 @@ rmdir CaseSensitiveTestDir
+ 
+ case $MACHDEP in
+ bsdos*)
+-case $CC in
++case $cc_basename in
+ gcc) CC="$CC -D_HAVE_BSDI";;
+ esac;;
+ esac
+ 
+ case $ac_sys_system in
+ hp*|HP*)
+-case $CC in
++case $cc_basename in
+ cc|*/cc) CC="$CC -Ae";;
+ esac;;
+ SunOS*)
+@@ -1073,7 +1074,7 @@ then
+ fi
+ 
+ # Clang also needs -fwrapv
+-case $CC in
++case $cc_basename in
+ *clang*) WRAP="-fwrapv"
+ ;;
+ esac
+@@ -1277,7 +1278,7 @@ yes)
+ esac
+ 
+ # ICC needs -fp-model strict or floats behave badly
+-case "$CC" in
++case "$cc_basename" in
+ *icc*)
+ BASECFLAGS="$BASECFLAGS -fp-model strict"
+ ;;
+@@ -1417,7 +1418,7 @@ else
+ fi],
+ [AC_MSG_RESULT(no)])
+ if test "$Py_LTO" = 'true' ; then
+-  case $CC in
++  case $cc_basename in
+ *clang*)
+   # Any changes made here should be reflected in the GCC+Darwin case below
+   LTOFLAGS="-flto"
+@@ -1482,7 +1483,7 @@ then
+   fi
+ fi
+ LLVM_PROF_ERR=no
+-case $CC in
++case $cc_basename in
+   *clang*)
+ # Any changes made here should be reflected in the GCC+Darwin case below
+ PGO_PROF_GEN_FLAG="-fprofile-instr-generate"
+@@ -2300,7 +2301,7 @@ then
+   then CCSHARED="-fPIC"
+   else CCSHARED="-Kpic -belf"
+   fi;;
+-  IRIX*/6*)  case $CC in
++  IRIX*/6*)  case $cc_basename in
+  *gcc*) CCSHARED="-shared";;
+  *) CCSHARED="";;
+  esac;;
+@@ -2344,7 +2345,7 @@ then
+   then
+   LINKFORSHARED="-Wl,--export-dynamic"
+   fi;;
+-  SunOS/5*) case $CC in
++  SunOS/5*) case $cc_basename in
+ *gcc*)
+   if $CC -Xlinker --help 2>&1 | grep export-dynamic >/dev/null
+   then
+-- 
+1.9.1
+
diff --git 

Re: [OE-core] [yocto] OpenEmbedded developer meeting Sunday before ELC in Portland

2018-01-15 Thread Philip Balister
On 01/15/2018 10:57 PM, Tom King wrote:
> What time...a number of us are headed up from SCaLE sunday morning to ELC...
> 
> its only about 2.5hrs to get there but early will leave a number of us late.

We know. It is painful. YP Dev Day is the Thursday after, and I suspect
we would lose people waiting until Friday.

I tried really hard to avoid the usual day/date error. I blundered the year.

Philip

> 
> T
> 
> On Mon, Jan 15, 2018 at 3:41 PM, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
> 
>>> March 11, 2108, Portland
>>
>> I guess, by this date yocto community will experience release 24.7 or
>> similar... If?! ;-)
>>
>> Zoran
>> ___
>>
>> On Mon, Jan 15, 2018 at 11:30 PM, Philip Balister 
>> wrote:
>>
>>> We are setting up an OpenEmbedded developer meeting on the Sunday before
>>> ELC. More information to follow, I just wanted to make sure everyone had
>>> the date before making ELC travel arrangements.
>>>
>>> March 11, 2108, Portland
>>>
>>> Philip
>>> --
>>> ___
>>> yocto mailing list
>>> yo...@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>>
>> --
>> ___
>> yocto mailing list
>> yo...@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [yocto] OpenEmbedded developer meeting Sunday before ELC in Portland

2018-01-15 Thread Tom King
What time...a number of us are headed up from SCaLE sunday morning to ELC...

its only about 2.5hrs to get there but early will leave a number of us late.

T

On Mon, Jan 15, 2018 at 3:41 PM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > March 11, 2108, Portland
>
> I guess, by this date yocto community will experience release 24.7 or
> similar... If?! ;-)
>
> Zoran
> ___
>
> On Mon, Jan 15, 2018 at 11:30 PM, Philip Balister 
> wrote:
>
>> We are setting up an OpenEmbedded developer meeting on the Sunday before
>> ELC. More information to follow, I just wanted to make sure everyone had
>> the date before making ELC travel arrangements.
>>
>> March 11, 2108, Portland
>>
>> Philip
>> --
>> ___
>> yocto mailing list
>> yo...@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
> --
> ___
> yocto mailing list
> yo...@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] kernel: drop unnecessary True options from calls to getVar

2018-01-15 Thread Andre McCurdy
The older style calls (plus a bashism in kernel.bbclass, fixed
separately) were introduced via the recent change to add support for
multiple kernel packages:

  
http://git.openembedded.org/openembedded-core/commit/?id=6c8c899849d101fd1b86aad0b8eed05c7c785924

Signed-off-by: Andre McCurdy 
---
 meta/classes/kernel-module-split.bbclass |  6 +++---
 meta/classes/kernel.bbclass  | 12 ++--
 meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb |  2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.12.bb |  2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb  |  2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.9.bb  |  2 +-
 meta/recipes-kernel/linux/linux-yocto.inc|  2 +-
 7 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index 73c7f18..67ab416 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -30,7 +30,7 @@ do_install_append() {
 
 PACKAGESPLITFUNCS_prepend = "split_kernel_module_packages "
 
-KERNEL_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME", True) or 
"kernel" }-modules"
+KERNEL_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or 
"kernel" }-modules"
 
 KERNEL_MODULE_PACKAGE_PREFIX ?= ""
 KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
@@ -129,8 +129,8 @@ python split_kernel_module_packages () {
postfix = format.split('%s')[1]
d.setVar('RPROVIDES_' + pkg, pkg.replace(postfix, ''))
 
-kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME", True) or "kernel"
-kernel_version = d.getVar("KERNEL_VERSION", True)
+kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
+kernel_version = d.getVar("KERNEL_VERSION")
 
 module_regex = '^(.*)\.k?o$'
 
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index c42f85c..a36f4f9 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -1,9 +1,9 @@
 inherit linux-kernel-base kernel-module-split
 
 KERNEL_PACKAGE_NAME ??= "kernel"
-KERNEL_DEPLOYSUBDIR ??= "${@ "" if (d.getVar("KERNEL_PACKAGE_NAME", True) == 
"kernel") else d.getVar("KERNEL_PACKAGE_NAME", True) }"
+KERNEL_DEPLOYSUBDIR ??= "${@ "" if (d.getVar("KERNEL_PACKAGE_NAME") == 
"kernel") else d.getVar("KERNEL_PACKAGE_NAME") }"
 
-PROVIDES += "${@ "virtual/kernel" if (d.getVar("KERNEL_PACKAGE_NAME", True) == 
"kernel") else "" }"
+PROVIDES += "${@ "virtual/kernel" if (d.getVar("KERNEL_PACKAGE_NAME") == 
"kernel") else "" }"
 DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc 
kmod-native bc-native lzop-native"
 PACKAGE_WRITE_DEPS += "depmodwrapper-cross"
 
@@ -37,8 +37,8 @@ KERNEL_VERSION_PKG_NAME = 
"${@legitimize_package_name(d.getVar('KERNEL_VERSION')
 KERNEL_VERSION_PKG_NAME[vardepvalue] = "${LINUX_VERSION}"
 
 python __anonymous () {
-pn = d.getVar("PN", True)
-kpn = d.getVar("KERNEL_PACKAGE_NAME", True)
+pn = d.getVar("PN")
+kpn = d.getVar("KERNEL_PACKAGE_NAME")
 
 # XXX Remove this after bug 11905 is resolved
 #  FILES_${KERNEL_PACKAGE_NAME}-dev doesn't expand correctly
@@ -52,7 +52,7 @@ python __anonymous () {
 # kernel recipes (I.e. where KERNEL_PACKAGE_NAME != kernel) so that they
 # may build in parallel with the default kernel without clobbering.
 if kpn != "kernel":
-workdir = d.getVar("WORKDIR", True)
+workdir = d.getVar("WORKDIR")
 sourceDir = os.path.join(workdir, 'kernel-source')
 artifactsDir = os.path.join(workdir, 'kernel-build-artifacts')
 d.setVar("STAGING_KERNEL_DIR", sourceDir)
@@ -62,7 +62,7 @@ python __anonymous () {
 type = d.getVar('KERNEL_IMAGETYPE') or ""
 alttype = d.getVar('KERNEL_ALT_IMAGETYPE') or ""
 types = d.getVar('KERNEL_IMAGETYPES') or ""
-kname = d.getVar('KERNEL_PACKAGE_NAME', True) or "kernel"
+kname = d.getVar('KERNEL_PACKAGE_NAME') or "kernel"
 if type not in types.split():
 types = (type + ' ' + types).strip()
 if alttype not in types.split():
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb
index 40d6e4a..8938ab8 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb
@@ -7,7 +7,7 @@ require recipes-kernel/linux/linux-yocto.inc
 # to build multiple virtual/kernel providers, e.g. as dependency of
 # core-image-rt-sdk, core-image-rt.
 python () {
-if d.getVar("KERNEL_PACKAGE_NAME", True) == "kernel" and 
d.getVar("PREFERRED_PROVIDER_virtual/kernel") != "linux-yocto-rt":
+if d.getVar("KERNEL_PACKAGE_NAME") == "kernel" and 
d.getVar("PREFERRED_PROVIDER_virtual/kernel") != "linux-yocto-rt":
 raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.12.bb 

Re: [OE-core] [PATCH] busybox: drop obsolete CONFIG_FEATURE_SYSTEMD reference from musl.cfg

2018-01-15 Thread Andre McCurdy
On Wed, Dec 13, 2017 at 5:33 PM, Andre McCurdy  wrote:
> From 1.25.0 onwards, busybox dropped systemd compatibility from its
> version of syslogd:
>
>   
> https://git.busybox.net/busybox/commit/?id=accd9eeb719916da974584b33b1aeced5f3bb346

Ping.

> Signed-off-by: Andre McCurdy 
> ---
>  meta/recipes-core/busybox/busybox/musl.cfg | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/meta/recipes-core/busybox/busybox/musl.cfg 
> b/meta/recipes-core/busybox/busybox/musl.cfg
> index facfe85..6fffc91 100644
> --- a/meta/recipes-core/busybox/busybox/musl.cfg
> +++ b/meta/recipes-core/busybox/busybox/musl.cfg
> @@ -2,7 +2,6 @@
>  # CONFIG_SELINUX is not set
>  # CONFIG_FEATURE_HAVE_RPC is not set
>  # CONFIG_WERROR is not set
> -# CONFIG_FEATURE_SYSTEMD is not set
>  # CONFIG_FEATURE_VI_REGEX_SEARCH is not set
>  # CONFIG_PAM is not set
>  # CONFIG_FEATURE_INETD_RPC is not set
> --
> 1.9.1
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

2018-01-15 Thread wenzong fan



On 01/15/2018 10:33 PM, José Bollo wrote:

On Wed, 10 Jan 2018 17:50:19 +0800
wenzong fan  wrote:


On 01/10/2018 01:01 AM, Patrick Ohly wrote:

On Fri, 2018-01-05 at 01:07 +, Fan, Wenzong wrote:

It works and will override the labels of home dir that SELinux
applied, that's the issue.

For SELinux enabled system, the user's home dir should have lavel
'user_home_dir_t' instead of 'etc_t', it prevents users from
creating files in their home dir.


Sounds like the "copy xattr" function needs to become a bit
smarter: it needs to understand some of the semantic involved and
skip those SELinux xattrs that are always meant to be set
dynamically by the running kernel.

Wenzong, which xattrs are those? Do you agree with the proposed
solution?


The xattr for selinux is "security.selinux":

$ getfattr -n security.selinux /home/t1
security.selinux="user_u:object_r:user_home_dir_t:s0-s15:c0.c1023"

I think the "attr_copy_file()" is doing right thing, but it should be
used in a limited situation, such as only for Smack ...

Thanks
Wenzong


The LSM "SELinux" is complicated enough to change label of template
files to label of instance files correctly. The approach with Smack is
different and the template files embed the expected complex hierarchy
that otherwise could only be created with a program.

A possible approach would be with smack to add a program for creating
homes. Conversely, SELinux could consider to use template approach too
instead of increasing its rules set (with templating splitted in two
parts: files and "creation" rules).


From "man 7 xattr" we know:

  - extended attributes are namespaced
  - the fully qualified name is "namespace.attribute"
  - actual namespaces are security, system, trusted, and user

A possibility would be to filter the copied extended attributes. For
SELinux we can just tell to not copy "security" attributes. See
manual of the command "tar" (recent version) that has options
--xattrs-exclude and --xattr-include.

Is there a need to copy extended attributes except for Smack?


I incline to limit the patch only for Smack with a proper bbappend, and 
maybe we'll want a distro feature as well. Both enable SELinux and Smack 
is not a normal use case, sometimes user choice Smack is because SELinux 
is too weight for their system. (except for you know a case that Smack 
can do but SELinux can't)


About how to get Smack and SELinux work together, I'm not sure if their 
communities also considered about that. Only fix the xattr issue maybe 
not enough ...


Thanks
Wenzong




Jose, can you look into updating your patch accordingly?


Perhaps yes but not now because I don't now what to do.

Best regards
Jose


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


[OE-core] [PATCH] json-glib: update to 1.4.2

2018-01-15 Thread Yi Zhao
Drop 0001-Do-not-disable-gobject-introspection-when-cross-comp.patch
since it has been fixed upstream.

Signed-off-by: Yi Zhao 
---
 ...ble-gobject-introspection-when-cross-comp.patch | 32 --
 .../{json-glib_1.2.8.bb => json-glib_1.4.2.bb} |  7 ++---
 2 files changed, 2 insertions(+), 37 deletions(-)
 delete mode 100644 
meta/recipes-gnome/json-glib/json-glib/0001-Do-not-disable-gobject-introspection-when-cross-comp.patch
 rename meta/recipes-gnome/json-glib/{json-glib_1.2.8.bb => json-glib_1.4.2.bb} 
(84%)

diff --git 
a/meta/recipes-gnome/json-glib/json-glib/0001-Do-not-disable-gobject-introspection-when-cross-comp.patch
 
b/meta/recipes-gnome/json-glib/json-glib/0001-Do-not-disable-gobject-introspection-when-cross-comp.patch
deleted file mode 100644
index 849bb9d..000
--- 
a/meta/recipes-gnome/json-glib/json-glib/0001-Do-not-disable-gobject-introspection-when-cross-comp.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-From 293452c963188666dae99521294f09a0cf9582e2 Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin 
-Date: Fri, 4 Aug 2017 16:01:11 +0300
-Subject: [PATCH] Do not disable gobject introspection when cross-compiling.
-
-Introspection does work fine for instance in Open Embedded,
-one of the most prominent cross-compilation frameworks
-(through qemu emulating target hardware), so let the user
-decide if he wants the feature or not.
-
-Upstream-Status: Pending
-Signed-off-by: Alexander Kanavin 

- meson.build | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/meson.build b/meson.build
-index 43cbfd9..8a32f26 100644
 a/meson.build
-+++ b/meson.build
-@@ -147,7 +147,7 @@ root_dir = include_directories('.')
- 
- gnome = import('gnome')
- gir = find_program('g-ir-scanner', required: false)
--build_gir = gir.found() and not meson.is_cross_build() and not 
get_option('disable_introspection')
-+build_gir = gir.found() and not get_option('disable_introspection')
- 
- subdir('json-glib')
- 
--- 
-2.13.2
-
diff --git a/meta/recipes-gnome/json-glib/json-glib_1.2.8.bb 
b/meta/recipes-gnome/json-glib/json-glib_1.4.2.bb
similarity index 84%
rename from meta/recipes-gnome/json-glib/json-glib_1.2.8.bb
rename to meta/recipes-gnome/json-glib/json-glib_1.4.2.bb
index 31912d1..fad0a2d 100644
--- a/meta/recipes-gnome/json-glib/json-glib_1.2.8.bb
+++ b/meta/recipes-gnome/json-glib/json-glib_1.4.2.bb
@@ -10,11 +10,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34"
 
 DEPENDS = "glib-2.0"
 
-SRC_URI_append = " \
-   
file://0001-Do-not-disable-gobject-introspection-when-cross-comp.patch \
-   "
-SRC_URI[archive.md5sum] = "ff31e7d0594df44318e12facda3d086e"
-SRC_URI[archive.sha256sum] = 
"fd55a9037d39e7a10f0db64309f5f0265fa32ec962bf85066087b83a2807f40a"
+SRC_URI[archive.md5sum] = "35107e23a7bbbc70f31c34f7b9adf1c3"
+SRC_URI[archive.sha256sum] = 
"2d7709a44749c7318599a6829322e081915bdc73f5be5045882ed120bb686dc8"
 
 GNOMEBASEBUILDCLASS = "meson"
 inherit gnomebase lib_package gobject-introspection gtk-doc manpages gettext
-- 
2.7.4

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


[OE-core] OpenEmbedded developer meeting Sunday before ELC in Portland

2018-01-15 Thread Philip Balister
We are setting up an OpenEmbedded developer meeting on the Sunday before
ELC. More information to follow, I just wanted to make sure everyone had
the date before making ELC travel arrangements.

March 11, 2108, Portland

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


Re: [OE-core] [AUH] Upgrade status: 2018-01-15

2018-01-15 Thread Burton, Ross
On 15 January 2018 at 18:21, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 01/15/2018 07:38 PM, Alexander Kanavin wrote:
>
>> On 01/15/2018 07:25 PM, alexander.kana...@linux.intel.com wrote:
>>
>>> Recipe upgrade statistics:
>>>
>>>  * Succeeded: 1
>>>  iso-codes, 3.77, Alexander Kanavin >> >
>>>
>>
>> Yay!
>>
>> Dear all, please bear with these emails, there'll be a few more. I'm now
>> setting up AUH to run in an automated, unattended fashion; it's gonna be
>> awesome.
>>
>
> Alright. In about 10 minutes, a cron job will start that will attempt
> upgrading *all* of oe-core recipes, and results (both successful, with
> patches, and failures, with error messages) will be mailed to respective
> maintainers. This will be repeated on the 15th of every odd-numbered month
> (so six times a year).
>
> Please take those emails not as irritating noise, but as a polite reminder
> to keep oe-core up-to-date. Suggestions for improvements also appreciated.
>
> (I've done my best to test this, but it may of course also fail in various
> spectacular ways).


AWESOME NEWS.

Thanks Alex for the work reviving AUH!

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


[OE-core] [PATCH v2] tune-i686: Add new tune for better support of 686-class CPUs.

2018-01-15 Thread Carlos Alberto Lopez Perez
There isn't currently any tune available for i686 x86 optimizations.
The tune for i586 doesn't enable i686 specific optimizations, and the
one for core2 enables things that won't work on a i686 CPU (like SSE3).

Make the tune for core2 inherits from this one and move there the
setting of X86ARCH32.

Signed-off-by: Carlos Alberto Lopez Perez 
---
 meta/conf/machine/include/tune-core2.inc |  7 ++-
 meta/conf/machine/include/tune-i686.inc  | 27 +++
 2 files changed, 29 insertions(+), 5 deletions(-)
 create mode 100644 meta/conf/machine/include/tune-i686.inc

diff --git a/meta/conf/machine/include/tune-core2.inc 
b/meta/conf/machine/include/tune-core2.inc
index f4ba43fbfd..6a03466650 100644
--- a/meta/conf/machine/include/tune-core2.inc
+++ b/meta/conf/machine/include/tune-core2.inc
@@ -8,11 +8,8 @@
 #
 DEFAULTTUNE ?= "core2-32"
 
-# Set x86 target arch to i686, so that glibc enables SSE optimised memcpy, etc.
-X86ARCH32 ?= "i686"
-
 # Include the previous tune to pull in PACKAGE_EXTRA_ARCHS
-require conf/machine/include/tune-i586.inc
+require conf/machine/include/tune-i686.inc
 
 # Extra tune features
 TUNEVALID[core2] = "Enable core2 specific processor optimizations"
@@ -23,7 +20,7 @@ AVAILTUNES += "core2-32"
 TUNE_FEATURES_tune-core2-32 = "${TUNE_FEATURES_tune-x86} core2"
 BASE_LIB_tune-core2-32 = "lib"
 TUNE_PKGARCH_tune-core2-32 = "core2-32"
-PACKAGE_EXTRA_ARCHS_tune-core2-32 = "${PACKAGE_EXTRA_ARCHS_tune-i586} core2-32"
+PACKAGE_EXTRA_ARCHS_tune-core2-32 = "${PACKAGE_EXTRA_ARCHS_tune-i686} core2-32"
 
 AVAILTUNES += "core2-64"
 TUNE_FEATURES_tune-core2-64 = "${TUNE_FEATURES_tune-x86-64} core2"
diff --git a/meta/conf/machine/include/tune-i686.inc 
b/meta/conf/machine/include/tune-i686.inc
new file mode 100644
index 00..bdb4799209
--- /dev/null
+++ b/meta/conf/machine/include/tune-i686.inc
@@ -0,0 +1,27 @@
+#
+# The i686 CPU family was introduced with the Intel Pentium Pro in 1995.
+# It has as required feature flags: fpu tsc cx8 cmov.
+#
+# It is the minimum CPU required by the Debian i386 port.
+# https://lists.debian.org/debian-devel-announce/2016/05/msg1.html
+#
+#
+
+DEFAULTTUNE ?= "i686"
+
+# Set x86 target arch to i686, so that glibc enables SSE optimised memcpy, etc.
+X86ARCH32 ?= "i686"
+
+# Include the previous tune to pull in PACKAGE_EXTRA_ARCHS
+require conf/machine/include/tune-i586.inc
+
+# Extra tune features
+TUNEVALID[i686] = "Enable i686 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'i686', ' -march=i686', 
'', d)}"
+
+# Extra tune selections
+AVAILTUNES += "i686"
+TUNE_FEATURES_tune-i686 = "${TUNE_FEATURES_tune-x86} i686"
+BASE_LIB_tune-i686 = "lib"
+TUNE_PKGARCH_tune-i686 = "i686"
+PACKAGE_EXTRA_ARCHS_tune-i686 = "${PACKAGE_EXTRA_ARCHS_tune-i586} i686"
-- 
2.11.0

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


Re: [OE-core] glib-2.0 fails to configure with USE_NLS="no"

2018-01-15 Thread Burton, Ross
Have a look at what just landed in master...

Ross

On 15 January 2018 at 17:53, Mike Crowe  wrote:

> If I add USE_NLS = "no" to local.conf, then glib-2.0 fails to configure:
>
> | checking for ngettext in libc... yes
> | checking for dgettext in libc... yes
> | checking for bind_textdomain_codeset... (cached) yes
> | checking for msgfmt... no
> | configure: error:
> | *** You must have either have gettext support in your C library, or use
> | the
> | *** GNU gettext library.
> | (http://www.gnu.org/software/gettext/gettext.html)
>
> It seems that glib-2.0 does not support --disable-nls and always requires
> gettext.
>
> I can avoid this error by adding gettext-native to glib-2.0's DEPENDS, but
> I'm not sure whether this is solution would be acceptable.
>
> Is there a better way?
>
> Thanks.
>
> Mike.
> --
> ___
> 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] [AUH] Upgrade status: 2018-01-15

2018-01-15 Thread Alexander Kanavin

On 01/15/2018 07:38 PM, Alexander Kanavin wrote:

On 01/15/2018 07:25 PM, alexander.kana...@linux.intel.com wrote:

Recipe upgrade statistics:

 * Succeeded: 1
 iso-codes, 3.77, Alexander Kanavin 


Yay!

Dear all, please bear with these emails, there'll be a few more. I'm now 
setting up AUH to run in an automated, unattended fashion; it's gonna be 
awesome.


Alright. In about 10 minutes, a cron job will start that will attempt 
upgrading *all* of oe-core recipes, and results (both successful, with 
patches, and failures, with error messages) will be mailed to respective 
maintainers. This will be repeated on the 15th of every odd-numbered 
month (so six times a year).


Please take those emails not as irritating noise, but as a polite 
reminder to keep oe-core up-to-date. Suggestions for improvements also 
appreciated.


(I've done my best to test this, but it may of course also fail in 
various spectacular ways).


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


[OE-core] [AUH] Upgrade status: 2018-01-15

2018-01-15 Thread auh
Recipe upgrade statistics:

* Succeeded: 1
iso-codes, 3.77, Alexander Kanavin 

TOTAL: attempted=1 succeeded=1(100.00%) failed=0(0.00%)

Recipe upgrade statistics per Maintainer:

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


[OE-core] glib-2.0 fails to configure with USE_NLS="no"

2018-01-15 Thread Mike Crowe
If I add USE_NLS = "no" to local.conf, then glib-2.0 fails to configure:

| checking for ngettext in libc... yes
| checking for dgettext in libc... yes
| checking for bind_textdomain_codeset... (cached) yes
| checking for msgfmt... no
| configure: error:
| *** You must have either have gettext support in your C library, or use
| the
| *** GNU gettext library.
| (http://www.gnu.org/software/gettext/gettext.html)

It seems that glib-2.0 does not support --disable-nls and always requires
gettext.

I can avoid this error by adding gettext-native to glib-2.0's DEPENDS, but
I'm not sure whether this is solution would be acceptable.

Is there a better way?

Thanks.

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


[OE-core] [AUH] Upgrade status: 2018-01-15

2018-01-15 Thread auh
Recipe upgrade statistics:

* Succeeded: 1
iso-codes, 3.77, Alexander Kanavin 

TOTAL: attempted=1 succeeded=1(100.00%) failed=0(0.00%)

Recipe upgrade statistics per Maintainer:

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


Re: [OE-core] [AUH] Upgrade status: 2018-01-15

2018-01-15 Thread Alexander Kanavin

On 01/15/2018 07:25 PM, alexander.kana...@linux.intel.com wrote:

Recipe upgrade statistics:

 * Succeeded: 1
 iso-codes, 3.77, Alexander Kanavin 


Yay!

Dear all, please bear with these emails, there'll be a few more. I'm now 
setting up AUH to run in an automated, unattended fashion; it's gonna be 
awesome.


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



[OE-core] [AUH] Upgrade status: 2018-01-15

2018-01-15 Thread alexander . kanavin
Recipe upgrade statistics:

* Succeeded: 1
iso-codes, 3.77, Alexander Kanavin 

TOTAL: attempted=1 succeeded=1(100.00%) failed=0(0.00%)

Recipe upgrade statistics per Maintainer:

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


[OE-core] [PATCHv2] rpm: backport configure fix for multiple users/groups with ID 0

2018-01-15 Thread Mike Crowe
Backport upstream configure fix for hosts that have multiple users with UID
0 or groups with GID 0.

Signed-off-by: Mike Crowe 
---
 ...ure-cope-with-multiple-users-groups-with-.patch | 43 ++
 meta/recipes-devtools/rpm/rpm_4.14.0.bb|  1 +
 2 files changed, 44 insertions(+)
 create mode 100644 
meta/recipes-devtools/rpm/files/0001-Make-configure-cope-with-multiple-users-groups-with-.patch

diff --git 
a/meta/recipes-devtools/rpm/files/0001-Make-configure-cope-with-multiple-users-groups-with-.patch
 
b/meta/recipes-devtools/rpm/files/0001-Make-configure-cope-with-multiple-users-groups-with-.patch
new file mode 100644
index 00..31024bd7e8
--- /dev/null
+++ 
b/meta/recipes-devtools/rpm/files/0001-Make-configure-cope-with-multiple-users-groups-with-.patch
@@ -0,0 +1,43 @@
+Upstream-Status: Backport 
[https://github.com/rpm-software-management/rpm/commit/a3652af66fa2a1f272d771323fee019f23d350f5]
+
+From 68a7b60f89419e53a4bd3c412f816f0576ffd8c4 Mon Sep 17 00:00:00 2001
+From: Mike Crowe 
+Date: Thu, 4 Jan 2018 14:39:51 +
+Subject: [PATCH] Make configure cope with multiple users/groups with ID 0
+
+If /etc/passwd contains multiple users with UID 0 then user_with_uid0 will
+contain a line feed which results in config.h containing:
+
+ #define UID_0_USER "root
+
+(i.e. without a closing quote.)
+
+The same problem occurs with /etc/group.
+
+Let's only emit the first match in each case so that there is only ever a
+single result.
+
+Signed-off-by: Mike Crowe 
+
+---
+ configure.ac | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index ab8ca4f54..5259ad243 100644
+--- a/configure.ac
 b/configure.ac
+@@ -996,8 +996,8 @@ if test "$with_dmalloc" = yes ; then
+   LIBS="$LIBS -ldmalloc"
+ fi
+ 
+-user_with_uid0=$(awk -F: '$3==0 {print $1}' /etc/passwd)
+-group_with_gid0=$(awk -F: '$3==0 {print $1}' /etc/group)
++user_with_uid0=$(awk -F: '$3==0 {print $1;exit}' /etc/passwd)
++group_with_gid0=$(awk -F: '$3==0 {print $1;exit}' /etc/group)
+ AC_DEFINE_UNQUOTED([UID_0_USER],["$user_with_uid0"],[Get the user name having 
userid 0])
+ AC_DEFINE_UNQUOTED([GID_0_GROUP],["$group_with_gid0"],[Get the group name 
having groupid 0])
+ 
+-- 
+2.11.0
+
diff --git a/meta/recipes-devtools/rpm/rpm_4.14.0.bb 
b/meta/recipes-devtools/rpm/rpm_4.14.0.bb
index e4e9c3e634..aa2579e3bf 100644
--- a/meta/recipes-devtools/rpm/rpm_4.14.0.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.14.0.bb
@@ -40,6 +40,7 @@ SRC_URI = 
"git://github.com/rpm-software-management/rpm;branch=rpm-4.14.x \

file://0003-rpmstrpool.c-make-operations-over-string-pools-threa.patch \

file://0004-build-pack.c-remove-static-local-variables-from-buil.patch \
file://0001-perl-disable-auto-reqs.patch \
+   
file://0001-Make-configure-cope-with-multiple-users-groups-with-.patch \
"
 
 PE = "1"
-- 
2.11.0


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


Re: [OE-core] [PATCH] rpm: backport configure fix for multiple users/groups with ID 0

2018-01-15 Thread Mike Crowe
On Monday 15 January 2018 at 17:27:19 +0200, Alexander Kanavin wrote:
> On 01/15/2018 05:22 PM, Mike Crowe wrote:
> > +Upstream-Status: Backport 
> > [https://github.com/rpm-software-management/rpm/pull/377]
> 
> If this is merged by upstream, you should point to the commit. If you merely
> made a submission, then the status should say Submitted.

The fix was merged. I used the pull request URL because it was shorter, but
I will change it to the commit URL instead.

Thanks.

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


Re: [OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

2018-01-15 Thread Patrick Ohly
On Mon, 2018-01-15 at 15:33 +0100, José Bollo wrote:
> A possibility would be to filter the copied extended attributes. For
> SELinux we can just tell to not copy "security" attributes. See
> manual of the command "tar" (recent version) that has options
> --xattrs-exclude and --xattr-include.
> 
> Is there a need to copy extended attributes except for Smack?

In theory file-based capabilities. In practice those probably don't
occur in a home directory template.

-- 
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] [PATCH v2] recipes-core: move hwclock.sh to util-linux

2018-01-15 Thread Otavio Salvador
On Mon, Jan 15, 2018 at 1:59 PM, Alex Stewart  wrote:
> On 01/13/2018 05:48 AM, Otavio Salvador wrote:
>
>> On Fri, Jan 12, 2018 at 11:06 AM, Alex Stewart 
>> wrote:
>> As mentioned by Christopher, it will increase the build time for
>> everyone and there is real gain in this this change. If you want to
>> disable the busybox dependency then move hwclock.sh to a hwclock-init
>> package that has no standard dependencies and is allarch and make
>> busybox and util-linux to depends on it.
>
> Either solution works for my purposes, so I'm fine breaking hwclock.sh out
> as its own recipe. It seems degenerative to break such a small piece of
> common-code into its own recipe, but I suppose there isn't a better solution
> if util-linux isn't commonly built.

Leaving it on busybox seems to be the commonly built package; moving
to a specific package works too.

-- 
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 v2] recipes-core: move hwclock.sh to util-linux

2018-01-15 Thread Alex Stewart

On 01/13/2018 05:48 AM, Otavio Salvador wrote:


On Fri, Jan 12, 2018 at 11:06 AM, Alex Stewart  wrote:

* Move the hwclock.sh initscript from the busybox recipe to util-linux.
   This script is generally useful for distros that get their hwclock
   implementation from sources other than busybox and we follow debian's
   example by providing it in util-linux.

:busybox/*
* Remove the busybox-hwclock package, as it no longer has a purpose.
* If busybox is configured to include hwclock, the busybox package will
   RDEPEND on util-linux-hwclock-init.

:util-linux/*
* Provide the hwclock.sh script in util-linux-hwclock-init, which can be
   pulled by any packages that depend on its functionality.
* util-linux-hwclock RDEPENDS on util-linux-hwclock-init for its
   initscript.

Signed-off-by: Alex Stewart 
Acked-by: Haris Okanovic 
Acked-by: Adrian Ratiu 
Acked-by: Ken Sharp 
Natinst-ReviewBoard-ID: 214983, 215755

As mentioned by Christopher, it will increase the build time for
everyone and there is real gain in this this change. If you want to
disable the busybox dependency then move hwclock.sh to a hwclock-init
package that has no standard dependencies and is allarch and make
busybox and util-linux to depends on it.

Either solution works for my purposes, so I'm fine breaking hwclock.sh 
out as its own recipe. It seems degenerative to break such a small piece 
of common-code into its own recipe, but I suppose there isn't a better 
solution if util-linux isn't commonly built.


--
Alex Stewart
Software Engineer - LabVIEW Real-Time
National Instruments

alex.stew...@ni.com

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


[OE-core] halt problem

2018-01-15 Thread Ryan Meulenkamp

Hi y'all,

I ran into a problem using shutdown -h (or halt) on an openembedded-core 
(yocto) distro running on the Atmel at91sam9g45.


We used to run an openembedded-classic (angström) based OS with kernel 
version 2.6.35.14+. Here, halting the system would cause it to shutdown 
without resetting, or turning the power off, to await a manual reset.


Now we are building a new distro based on openembedded-core and yocto. 
Halting the system now causes a watchdog intervention. I tried all 
different arguments for both the shutdown and the halt command. It looks 
if though the classic based distro left the watchdog daemon running 
during a halt.


What could be the cause of this problem? In what direction should I look 
(e.g. kernel config, sysvinit config, openembedded config, processor 
specific code etc.)?


I'm not sure if this is the right mailing list to ask this question, but 
I guess one of you could point me in the right direction.


Thanks in advance and kind regards,

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


[OE-core] ✗ patchtest: failure for rpm: backport configure fix for multiple users/groups with ID 0

2018-01-15 Thread Patchwork
== Series Details ==

Series: rpm: backport configure fix for multiple users/groups with ID 0
Revision: 1
URL   : https://patchwork.openembedded.org/series/10544/
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 A patch file has been added, but does not have a 
Signed-off-by tag [test_signed_off_by_presence] 
  Suggested fixSign off the added patch file 
(meta/recipes-devtools/rpm/files/0001-Make-configure-cope-with-multiple-users-groups-with-.patch)



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_Guidelines
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] rpm: backport configure fix for multiple users/groups with ID 0

2018-01-15 Thread Alexander Kanavin

On 01/15/2018 05:22 PM, Mike Crowe wrote:

+Upstream-Status: Backport 
[https://github.com/rpm-software-management/rpm/pull/377]


If this is merged by upstream, you should point to the commit. If you 
merely made a submission, then the status should say Submitted.


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


[OE-core] [PATCH] rpm: backport configure fix for multiple users/groups with ID 0

2018-01-15 Thread Mike Crowe
Backport upstream configure fix for hosts that have multiple users with UID
0 or groups with GID 0.

Signed-off-by: Mike Crowe 
---
 ...ure-cope-with-multiple-users-groups-with-.patch | 40 ++
 meta/recipes-devtools/rpm/rpm_4.14.0.bb|  1 +
 2 files changed, 41 insertions(+)
 create mode 100644 
meta/recipes-devtools/rpm/files/0001-Make-configure-cope-with-multiple-users-groups-with-.patch

diff --git 
a/meta/recipes-devtools/rpm/files/0001-Make-configure-cope-with-multiple-users-groups-with-.patch
 
b/meta/recipes-devtools/rpm/files/0001-Make-configure-cope-with-multiple-users-groups-with-.patch
new file mode 100644
index 00..077fae3ba8
--- /dev/null
+++ 
b/meta/recipes-devtools/rpm/files/0001-Make-configure-cope-with-multiple-users-groups-with-.patch
@@ -0,0 +1,40 @@
+Upstream-Status: Backport 
[https://github.com/rpm-software-management/rpm/pull/377]
+
+From 68a7b60f89419e53a4bd3c412f816f0576ffd8c4 Mon Sep 17 00:00:00 2001
+From: Mike Crowe 
+Date: Thu, 4 Jan 2018 14:39:51 +
+Subject: [PATCH] Make configure cope with multiple users/groups with ID 0
+
+If /etc/passwd contains multiple users with UID 0 then user_with_uid0 will
+contain a line feed which results in config.h containing:
+
+ #define UID_0_USER "root
+
+(i.e. without a closing quote.)
+
+The same problem occurs with /etc/group.
+
+Let's only emit the first match in each case so that there is only ever a
+single result.
+---
+ configure.ac | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index ab8ca4f54..5259ad243 100644
+--- a/configure.ac
 b/configure.ac
+@@ -996,8 +996,8 @@ if test "$with_dmalloc" = yes ; then
+   LIBS="$LIBS -ldmalloc"
+ fi
+ 
+-user_with_uid0=$(awk -F: '$3==0 {print $1}' /etc/passwd)
+-group_with_gid0=$(awk -F: '$3==0 {print $1}' /etc/group)
++user_with_uid0=$(awk -F: '$3==0 {print $1;exit}' /etc/passwd)
++group_with_gid0=$(awk -F: '$3==0 {print $1;exit}' /etc/group)
+ AC_DEFINE_UNQUOTED([UID_0_USER],["$user_with_uid0"],[Get the user name having 
userid 0])
+ AC_DEFINE_UNQUOTED([GID_0_GROUP],["$group_with_gid0"],[Get the group name 
having groupid 0])
+ 
+-- 
+2.11.0
+
diff --git a/meta/recipes-devtools/rpm/rpm_4.14.0.bb 
b/meta/recipes-devtools/rpm/rpm_4.14.0.bb
index e4e9c3e634..aa2579e3bf 100644
--- a/meta/recipes-devtools/rpm/rpm_4.14.0.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.14.0.bb
@@ -40,6 +40,7 @@ SRC_URI = 
"git://github.com/rpm-software-management/rpm;branch=rpm-4.14.x \

file://0003-rpmstrpool.c-make-operations-over-string-pools-threa.patch \

file://0004-build-pack.c-remove-static-local-variables-from-buil.patch \
file://0001-perl-disable-auto-reqs.patch \
+   
file://0001-Make-configure-cope-with-multiple-users-groups-with-.patch \
"
 
 PE = "1"
-- 
2.11.0


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


Re: [OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

2018-01-15 Thread José Bollo
On Wed, 10 Jan 2018 17:50:19 +0800
wenzong fan  wrote:

> On 01/10/2018 01:01 AM, Patrick Ohly wrote:
> > On Fri, 2018-01-05 at 01:07 +, Fan, Wenzong wrote:  
> >> It works and will override the labels of home dir that SELinux
> >> applied, that's the issue.
> >>
> >> For SELinux enabled system, the user's home dir should have lavel
> >> 'user_home_dir_t' instead of 'etc_t', it prevents users from
> >> creating files in their home dir.  
> > 
> > Sounds like the "copy xattr" function needs to become a bit
> > smarter: it needs to understand some of the semantic involved and
> > skip those SELinux xattrs that are always meant to be set
> > dynamically by the running kernel.
> > 
> > Wenzong, which xattrs are those? Do you agree with the proposed
> > solution?  
> 
> The xattr for selinux is "security.selinux":
> 
> $ getfattr -n security.selinux /home/t1
> security.selinux="user_u:object_r:user_home_dir_t:s0-s15:c0.c1023"
> 
> I think the "attr_copy_file()" is doing right thing, but it should be 
> used in a limited situation, such as only for Smack ...
> 
> Thanks
> Wenzong

The LSM "SELinux" is complicated enough to change label of template
files to label of instance files correctly. The approach with Smack is
different and the template files embed the expected complex hierarchy
that otherwise could only be created with a program.

A possible approach would be with smack to add a program for creating
homes. Conversely, SELinux could consider to use template approach too
instead of increasing its rules set (with templating splitted in two
parts: files and "creation" rules).

>From "man 7 xattr" we know:
 - extended attributes are namespaced
 - the fully qualified name is "namespace.attribute"
 - actual namespaces are security, system, trusted, and user

A possibility would be to filter the copied extended attributes. For
SELinux we can just tell to not copy "security" attributes. See
manual of the command "tar" (recent version) that has options
--xattrs-exclude and --xattr-include.

Is there a need to copy extended attributes except for Smack?

> > Jose, can you look into updating your patch accordingly?

Perhaps yes but not now because I don't now what to do.

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


Re: [OE-core] [PATCH] Fix COMPATIBLE_MACHINE for -native recipe variants.

2018-01-15 Thread Richard Purdie
On Mon, 2018-01-15 at 09:01 +0100, Paulo De Sousa Neves (Nokia -
PL/Wroclaw) wrote:
> Hello Richard,
> 
> My problem is that I have the PV expansion happens on the recipe, at 
> parsing time regardless of it being on the dependency chain or not.
> On 
> the other hand, the PV is not expanded if the COMPATIBLE_MACHINE is 
> honored. This makes my build significantly faster also, as it avoids 
> other expansions altogether.
> 
> Coming back to our issue, this means that with the
> COMPATIBLE_MACHINE 
> being honored, my recipes work for all cases except when they are in 
> native mode.

Native recipes should not be machine dependent so using
COMPATIBLE_MACHINE for this isn't an option.

The good news is its trivial to add your own anonymous python fragment
which does the same thing. Your layer will not pass the layer
compatibility tests should you do that though.

Cheers,

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


[OE-core] [PATCH 1/1] scripts/oe-depends-dot: add it to handle dot files

2018-01-15 Thread Robert Yang
Add it to handle recipe-depends.dot and task-depends.dot. E.g.:

* Print why rpm is built
  $ oe-depends-dot -k rpm --why/-w recipe-depends.dot
  Because: core-image-sato libdnf libsolv dnf

* Print bzip2-native's depends
  $ oe-depends-dot -k bzip2-native --depends/-d recipe-depends.dot
  Depends: automake-native gnu-config-native libtool-native quilt-native 
autoconf-native

* Remove duplicated dependencies to reduce the size of the dot files.
  For example, A->B, B->C, A->C, then A->C can be removed. The dot files are too
  big, we nearly couldn't use 'dot -T' to generate pictcures for target recipes,
  remove the duplicated dependencies makes is it possible.
  $ bitbake core-image-sato -g
  $ oe-depends-dot -r recipe-depends.dot
  Saving reduced dot file to recipe-depends-reduced.dot
  $ du -sh recipe-depends*.dot
  608Krecipe-depends.dot
  32K recipe-depends-reduced.dot

  It has been recuded from 608K to 32K, now we can generate a picture,
  otherwise, it is too big:
  $ dot -Tpng recipe-depends-reduced.dot -O

It also can handle task-depends.dot.

Signed-off-by: Robert Yang 
---
 scripts/oe-depends-dot | 121 +
 1 file changed, 121 insertions(+)
 create mode 100755 scripts/oe-depends-dot

diff --git a/scripts/oe-depends-dot b/scripts/oe-depends-dot
new file mode 100755
index 000..5cec23b
--- /dev/null
+++ b/scripts/oe-depends-dot
@@ -0,0 +1,121 @@
+#!/usr/bin/env python3
+#
+# Copyright (C) 2018 Wind River Systems, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+# See the GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
+import os
+import sys
+import argparse
+import logging
+import re
+
+class Dot(object):
+def __init__(self):
+parser = argparse.ArgumentParser(
+description="Analyse recipe-depends.dot generated by bitbake -g",
+epilog="Use %(prog)s --help to get help")
+parser.add_argument("dotfile",
+help = "Specify the dotfile", nargs = 1, action='store', 
default='')
+parser.add_argument("-k", "--key",
+help = "Specify the key, e.g., recipe name",
+action="store", default='')
+parser.add_argument("-d", "--depends",
+help = "Print the key's dependencies",
+action="store_true", default=False)
+parser.add_argument("-w", "--why",
+help = "Print why the key is built",
+action="store_true", default=False)
+parser.add_argument("-r", "--remove",
+help = "Remove duplicated dependencies to reduce the size of the 
dot files."
+" For example, A->B, B->C, A->C, then A->C can be 
removed.",
+action="store_true", default=False)
+
+self.args = parser.parse_args()
+
+if len(sys.argv) != 3 and len(sys.argv) < 5:
+print('ERROR: Not enough args, see --help for usage')
+
+def main(self):
+#print(self.args.dotfile[0])
+# The format is {key: depends}
+depends = {}
+with open(self.args.dotfile[0], 'r') as f:
+for line in f.readlines():
+if ' -> ' not in line:
+continue
+line_no_quotes = line.replace('"', '')
+m = re.match("(.*) -> (.*)", line_no_quotes)
+if not m:
+print('WARNING: Found unexpected line: %s' % line)
+continue
+key = m.group(1)
+if key == "meta-world-pkgdata":
+continue
+dep = m.group(2)
+if key in depends:
+if not key in depends[key]:
+depends[key].add(dep)
+else:
+print('WARNING: Fonud duplicated line: %s' % line)
+else:
+depends[key] = set()
+depends[key].add(dep)
+
+if self.args.remove:
+reduced_depends = {}
+for k, deps in depends.items():
+child_deps = set()
+added = set()
+# Both direct and indirect depends are already in the dict, so
+# we don't have to do this recursively.
+for dep in deps:
+if dep in depends:
+child_deps |= depends[dep]
+
+reduced_depends[k] = deps - child_deps
+ 

[OE-core] [PATCH 0/1] scripts/oe-depends-dot: add it to handle dot files

2018-01-15 Thread Robert Yang
The following changes since commit 92a0513837182e2e9aa6c7d4958e495f4b5b4c47:

  qemu: CVE-2017-17381 (2018-01-14 09:11:28 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/oe-dot
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/oe-dot

Robert Yang (1):
  scripts/oe-depends-dot: add it to handle dot files

 scripts/oe-depends-dot | 121 +
 1 file changed, 121 insertions(+)
 create mode 100755 scripts/oe-depends-dot

-- 
2.7.4

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


Re: [OE-core] [morty][RESEND][PATCH] gnutls_3.5.3.bb: Fix native build on distro with kernel < 3.4.17

2018-01-15 Thread Martin Jansa
ping

On Sat, Dec 2, 2017 at 1:37 AM, Martin Jansa  wrote:

> From: Khem Raj 
>
> When using distros which use old kernels gnutls fails to build
> due to missing SYS_getrandom, therefore we need to check for this
> before using it.
> Fixes errorr e.g.
>
> | ../../../gnutls-3.5.3/lib/nettle/rnd-linux.c: In function
> 'have_getrandom':
> | ../../../gnutls-3.5.3/lib/nettle/rnd-linux.c:59:42: error:
> 'SYS_getrandom' undeclared (first use in this function)
> |  #  define getrandom(dst,s,flags) syscall(SYS_getrandom, (void*)dst,
> (size_t)s, (unsigned int)flags)
>
> Signed-off-by: Khem Raj 
> Signed-off-by: Martin Jansa 
> ---
>  .../gnutls/gnutls/check_SYS_getrandom.patch| 35
> ++
>  meta/recipes-support/gnutls/gnutls_3.5.3.bb|  1 +
>  2 files changed, 36 insertions(+)
>  create mode 100644 meta/recipes-support/gnutls/
> gnutls/check_SYS_getrandom.patch
>
> diff --git a/meta/recipes-support/gnutls/gnutls/check_SYS_getrandom.patch
> b/meta/recipes-support/gnutls/gnutls/check_SYS_getrandom.patch
> new file mode 100644
> index 000..535c22a
> --- /dev/null
> +++ b/meta/recipes-support/gnutls/gnutls/check_SYS_getrandom.patch
> @@ -0,0 +1,35 @@
> +From f26c3979ab0325edb2e410d287bc501cf00e0ac0 Mon Sep 17 00:00:00 2001
> +From: Nikos Mavrogiannopoulos 
> +Date: Mon, 22 Aug 2016 16:32:34 +0200
> +Subject: [PATCH] rnd-linux: added check for SYS_getrandom being defined
> +
> +This allows to compile the getrandom() code in old Linux systems
> +which do not have the system call defined.
> +---
> +
> +Upstream-Status: Backport
> +Signed-off-by: Khem Raj 
> +
> + lib/nettle/rnd-linux.c | 6 +-
> + 1 file changed, 5 insertions(+), 1 deletion(-)
> +
> +diff --git a/lib/nettle/rnd-linux.c b/lib/nettle/rnd-linux.c
> +index d7f07a6..7a24d05 100644
> +--- a/lib/nettle/rnd-linux.c
>  b/lib/nettle/rnd-linux.c
> +@@ -56,7 +56,11 @@ static dev_t _gnutls_urandom_fd_rdev = 0;
> + # else
> + #  include 
> + #  undef getrandom
> +-#  define getrandom(dst,s,flags) syscall(SYS_getrandom, (void*)dst,
> (size_t)s, (unsigned int)flags)
> ++#  if defined(SYS_getrandom)
> ++#   define getrandom(dst,s,flags) syscall(SYS_getrandom, (void*)dst,
> (size_t)s, (unsigned int)flags)
> ++#  else
> ++#   define getrandom(dst,s,flags) -1
> ++#  endif
> + # endif
> +
> + static unsigned have_getrandom(void)
> +--
> +libgit2 0.24.0
> +
> diff --git a/meta/recipes-support/gnutls/gnutls_3.5.3.bb
> b/meta/recipes-support/gnutls/gnutls_3.5.3.bb
> index b2dbb07..0400588 100644
> --- a/meta/recipes-support/gnutls/gnutls_3.5.3.bb
> +++ b/meta/recipes-support/gnutls/gnutls_3.5.3.bb
> @@ -4,6 +4,7 @@ SRC_URI += "file://correct_rpl_gettimeofday_signature.patch
> \
>  file://0001-configure.ac-fix-sed-command.patch \
>  file://use-pkg-config-to-locate-zlib.patch \
>  file://0001-Use-correct-include-dir-with-minitasn.patch \
> +file://check_SYS_getrandom.patch \
>  file://CVE-2016-7444.patch \
> "
>  SRC_URI[md5sum] = "6c2c7f40ddf52933ee3ca474cb8cb63c"
> --
> 2.7.4
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core