[OE-core] [PATCH 1/1] gcc: libgcc-common.inc: symlink gthr-posix -> gthr-default.h

[Ioan-Adrian Ratiu]

libgfortran needs gthr-default.h to exist (included by libgcc/gthr.h),
but for some reason it is not symlinked in configure as defined by
AC_CONFIG_LINKS. This patch creates it at the end of do_configure; thus
allowing libgfortran to build without erros.

Signed-off-by: Ioan-Adrian Ratiu 
---
 meta/recipes-devtools/gcc/libgcc-common.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/gcc/libgcc-common.inc 
b/meta/recipes-devtools/gcc/libgcc-common.inc
index b09ea65..2922219 100644
--- a/meta/recipes-devtools/gcc/libgcc-common.inc
+++ b/meta/recipes-devtools/gcc/libgcc-common.inc
@@ -13,6 +13,9 @@ do_configure () {
cd ${B}/${BPN}
chmod a+x ${S}/${BPN}/configure
${S}/${BPN}/configure ${CONFIGUREOPTS} ${EXTRA_OECONF}
+
+   #fix libgfortran build which expects gthr-default.h -> gthr-posix.h
+   ln -sf ${S}/${BPN}/gthr-posix.h ${S}/${BPN}/gthr-default.h
 }
 
 do_compile () {
-- 
2.7.0

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

Re: [OE-core] [PATCH 1/1] gcc: libgcc-common.inc: symlink gthr-posix -> gthr-default.h

[Burton, Ross]

On 26 January 2016 at 11:25, Ioan-Adrian Ratiu  wrote:

> libgfortran needs gthr-default.h to exist (included by libgcc/gthr.h),
> but for some reason it is not symlinked in configure as defined by
> AC_CONFIG_LINKS. This patch creates it at the end of do_configure; thus
> allowing libgfortran to build without erros.
>

Are you sure?  libgfortran builds here and gthr-default.h is in the build
tree:

In
.../work/corei7-64-poky-linux/libgcc/5.3.0-r0/gcc-5.3.0/build.x86_64-poky-linux.x86_64-poky-linux/libgcc
$ ls -l gthr-default.h
lrwxrwxrwx 1 ross ross 76 Jan 25 16:20 gthr-default.h ->
/data/poky-master/tmp/work-shared/gcc-5.3.0-r0/gcc-5.3.0/libgcc/gthr-posix.h

I'll note that libgfortran actually then errors out in package QA:

ERROR: QA Issue: libgfortran: Files/directories were installed but not
shipped in any package:
  /usr/lib/gcc/x86_64-poky-linux/5.3.0/finclude
  /usr/lib/gcc/x86_64-poky-linux/5.3.0/finclude/ieee_features.mod
  /usr/lib/gcc/x86_64-poky-linux/5.3.0/finclude/ieee_arithmetic.mod
  /usr/lib/gcc/x86_64-poky-linux/5.3.0/finclude/ieee_exceptions.mod

If you actually use fortran would you be able to submit the right fix?  I'd
guess at adding those to FILES_PN would be right, but that's a guess.

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

Re: [OE-core] [PATCH] stress-ng: add 0.05.09

[Burton, Ross]

On 26 January 2016 at 03:34, Denys Dmytriyenko  wrote:

> A clean room re-implementation and extension of the original stress tool.
>

What's the rationale for adding this to oe-core over another layer?

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

[OE-core] [PATCH 1/1] image.bbclass: chek circular dependency when IMAGE_FSTYPES append hddimg

[Robert Yang]

Fixed:
IMAGE_FSTYPES_append = " hddimg"

$ bitbake -g core-image-minimal-initramfs
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing RunQueue
ERROR: Task /path/to/core-image-minimal-initramfs.bb (do_bootimg) has circular 
dependency on /path/to/core-image-minimal-initramfs.bb (do_image_complete)
ERROR: Command execution failed: Exited with 1

This is because IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}", and if
IMAGE_FSTYPES append hddimg, then core-image-minimal-initramfs.bb would
be circular dependency:
do_bootimg -> do_image_complete -> do_bootimg.

Now we check and error out.

Signed-off-by: Robert Yang 
---
 meta/classes/image-live.bbclass |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index aafa7d5..d2314aa 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -9,7 +9,6 @@ LABELS_append = " ${SYSLINUX_LABELS} "
 
 ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.ext4"
 
-do_bootimg[depends] += "${INITRD_IMAGE}:do_image_complete"
 do_bootimg[depends] += "${PN}:do_image_ext4"
 
 inherit bootimg
@@ -18,3 +17,13 @@ IMAGE_TYPEDEP_live = "ext4"
 IMAGE_TYPEDEP_iso = "ext4"
 IMAGE_TYPEDEP_hddimg = "ext4"
 IMAGE_TYPES_MASKED += "live hddimg iso"
+
+python() {
+image_b = d.getVar('IMAGE_BASENAME', True)
+initrd_i = d.getVar('INITRD_IMAGE', True)
+if image_b == initrd_i:
+bb.error('INITRD_IMAGE %s cannot use image live, hddimg or iso.' % 
initrd_i)
+bb.fatal('Check IMAGE_FSTYPES and INITRAMFS_FSTYPES settings.')
+else:
+d.appendVarFlag('do_bootimg', 'depends', ' %s:do_image_complete' % 
initrd_i)
+}
-- 
1.7.9.5

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

[OE-core] [PATCH 0/1] image.bbclass: chek circular dependency when IMAGE_FSTYPES append hddimg

[Robert Yang]

The following changes since commit fc4209baa098caebf9c4cb75f9a6f2e85f4c:

  Revert "xz: Allow to work with ASSUME_PROVIDED xz-native" (2016-01-25 
10:08:25 +)

are available in the git repository at:

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

Robert Yang (1):
  image.bbclass: chek circular dependency when IMAGE_FSTYPES append
hddimg

 meta/classes/image-live.bbclass |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

-- 
1.7.9.5

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

Re: [OE-core] [PATCH 1/1] systemd: work around the boot problem on qemuarm64

[ChenQi]

On 01/23/2016 10:03 PM, Khem Raj wrote:

On Sat, Jan 23, 2016 at 1:39 AM, Burton, Ross  wrote:

On 23 January 2016 at 04:52, Khem Raj  wrote:

This is general aarch64 problem, so make this across all aarch64
this is the original problem

https://github.com/systemd/systemd/pull/1190#issuecomment-166294683


And according to that link, is a binutils problem.  Can't we just fix that
instead?


We can. May be try out the binutils patches I posted and see if that fixes it
https://github.com/kraj/openembedded-core/tree/kraj/binutils-2.26



Ross




Hi Khem and Ross,

I've verified the patch above does fix the systemd qemuarm64 problem.
Thanks all :)

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC][PATCH] gcc-runtime.inc: force libstdc++ to always use gcc4 compatible ABI

[Khem Raj]

> On Jan 26, 2016, at 12:18 PM, Andre McCurdy  wrote:
> 
> On Tue, Jan 26, 2016 at 8:38 AM, Khem Raj  wrote:
>> 
>>> On Jan 26, 2016, at 12:10 AM, Andre McCurdy  wrote:
>>> 
>>> Experimental hack, not expected to be merged.
>>> 
>>> Without this, the http://www.cplusplus.com/reference/string/string/append/
>>> example fails to build with -std=c++11 and it's not clear why (it's as if we
>>> build a version of libstdc++ which supports only the old ABI but with 
>>> headers
>>> which try to use the new ABI when compiled with -std=c++11 ?). As a 
>>> workaround,
>>> force libstdc++ to provide, and default to using, the old ABI in all cases.
>>> 
>>> See also:
>>> 
>>> https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html
>>> https://mail.gnome.org/archives/gtkmm-list/2015-June/msg00026.html
>>> https://wiki.debian.org/GCC5
>>> 
>>> Signed-off-by: Andre McCurdy 
>>> ---
>>> meta/recipes-devtools/gcc/gcc-runtime.inc | 13 +
>>> 1 file changed, 13 insertions(+)
>>> 
>>> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
>>> b/meta/recipes-devtools/gcc/gcc-runtime.inc
>>> index f20d298..3a476cd 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
>>> @@ -10,6 +10,19 @@ EXTRA_OECONF_PATHS = "\
>>> 
>>> EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
>>> 
>>> +# gcc-runtime.inc: force libstdc++ to always use gcc4 compatible ABI
>>> +# Experimental hack. Without this, the 
>>> http://www.cplusplus.com/reference/string/string/append/
>>> +# example fails to build with -std=c++11 and it's not clear why (it's as 
>>> if we
>>> +# build a version of libstdc++ which supports only the old ABI but with 
>>> headers
>>> +# which try to use the new ABI when compiled with -std=c++11 ?). As a 
>>> workaround,
>>> +# force libstdc++ to provide, and default to using, the old ABI in all 
>>> cases.
>>> +# See also:
>>> +# https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html
>>> +# https://mail.gnome.org/archives/gtkmm-list/2015-June/msg00026.html
>>> +# https://wiki.debian.org/GCC5
>>> +#
>>> +EXTRA_OECONF_append = " --disable-libstdcxx-dual-abi 
>>> --with-default-libstdcxx-abi=gcc4-compatible”
>> 
>> This change while makes it work compatible to older libstdc++ ABI, we should 
>> make the defaults to be
>> forward looking.
> 
> Yes, I agree. The problem is that currently our libstdc++ doesn't seem
> to support the new ABI.
> 
>> I would rather keep --with-default-libstdcxx-abi=c++11 since gcc6 will 
>> switch to newer
>> c++ std as default. If we revert like you suggest, we will be up for more 
>> work in gcc6 time.
>> 
>> please define _GLIBCXX_USE_CXX11_ABI=0 for your app, where you see the 
>> problem.
> 
> My test case is the example app from:
> 
>  http://www.cplusplus.com/reference/string/string/append/
> 
> It fails when I try to compile to use the new ABI (ie by using
> -stdc++11 or _GLIBCXX_USE_CXX11_ABI=1).

Lets not mix API ( std=c++11 ) and libstdc++ c++11 ABI, both are different.

have you tried the converse where you suspect the test is not c++11 ABI 
compliant for STL
in particular

str.append(5,0x2E);

> 
> There is no legacy code involved.
> 
>> 
>>> RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic \
>>>${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', 
>>> '', d)} \
>>> "
>>> --
>>> 1.9.1
>>> 
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] linux-yocto/4.4: CVEs and preempt-rt update

[Bruce Ashfield]

Integrating the following CVE update:

  Author: Yevgeny Pats 
  Date:   Tue Jan 19 22:09:04 2016 +

  KEYS: Fix keyring ref leak in join_session_keyring()

  This fixes CVE-2016-0728.

We also integrate the 4.4-rt3 version.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb   |  4 ++--
 meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb |  4 ++--
 meta/recipes-kernel/linux/linux-yocto_4.4.bb  | 18 +-
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
index b7509bb58dfc..3c3c0c5523a0 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
@@ -2,8 +2,8 @@ KBRANCH ?= "standard/preempt-rt"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-SRCREV_machine ?= "86a9e1ab51b9acf71d9c2f39a9f02652886bd727"
-SRCREV_meta ?= "ad9d3f01300ba350563e17db00b2518302e172f6"
+SRCREV_machine ?= "49a18bd230aafabe793de56d3c96d62f891e77dc"
+SRCREV_meta ?= "dc760c3189ed868dc59050206b7899c35a4ad8e8"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.4.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
index d348c0a628f8..6ecd0b97e943 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
@@ -9,8 +9,8 @@ LINUX_VERSION ?= "4.4"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "2dadc3524fcbce0c46f5db65b7c20c673fc60503"
-SRCREV_meta ?= "ad9d3f01300ba350563e17db00b2518302e172f6"
+SRCREV_machine ?= "57af322eecf5750f8f09cb8b093d613caede5c48"
+SRCREV_meta ?= "dc760c3189ed868dc59050206b7899c35a4ad8e8"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.4.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
index a440cf7b26ce..be43a212f81b 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
@@ -11,15 +11,15 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "bcfc111e6c14b9f9d6ffa9d357651c0b4489835e"
-SRCREV_machine_qemuarm64 ?= "2dadc3524fcbce0c46f5db65b7c20c673fc60503"
-SRCREV_machine_qemumips ?= "9d9c37432e75eaeb2232e00cc3c2252440b709b3"
-SRCREV_machine_qemuppc ?= "2dadc3524fcbce0c46f5db65b7c20c673fc60503"
-SRCREV_machine_qemux86 ?= "2dadc3524fcbce0c46f5db65b7c20c673fc60503"
-SRCREV_machine_qemux86-64 ?= "2dadc3524fcbce0c46f5db65b7c20c673fc60503"
-SRCREV_machine_qemumips64 ?= "cb3a85329501f541ebfa08febb2f36edcbc6f253"
-SRCREV_machine ?= "2dadc3524fcbce0c46f5db65b7c20c673fc60503"
-SRCREV_meta ?= "ad9d3f01300ba350563e17db00b2518302e172f6"
+SRCREV_machine_qemuarm ?= "f7bc1fb5f438f019bcd3d5fd8362e0960ed0fffc"
+SRCREV_machine_qemuarm64 ?= "57af322eecf5750f8f09cb8b093d613caede5c48"
+SRCREV_machine_qemumips ?= "5b05677721ce8b0625a7e155dcdf93325fc460fe"
+SRCREV_machine_qemuppc ?= "57af322eecf5750f8f09cb8b093d613caede5c48"
+SRCREV_machine_qemux86 ?= "57af322eecf5750f8f09cb8b093d613caede5c48"
+SRCREV_machine_qemux86-64 ?= "57af322eecf5750f8f09cb8b093d613caede5c48"
+SRCREV_machine_qemumips64 ?= "ac3f6e9508fb6963e9db844fe28b7a50589decc4"
+SRCREV_machine ?= "57af322eecf5750f8f09cb8b093d613caede5c48"
+SRCREV_meta ?= "dc760c3189ed868dc59050206b7899c35a4ad8e8"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=${KBRANCH}; 
\

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
-- 
2.1.0

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

[OE-core] [PATCH 1/2] linux-yocto/4.1: update to 4.1.16

[Bruce Ashfield]

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.1.bb  | 20 ++--
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
index b441bf681154..2bc891c7c9fe 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
@@ -2,13 +2,13 @@ KBRANCH ?= "standard/preempt-rt/base"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-SRCREV_machine ?= "3188436876d5eaff8d48f82064367d4a65c3aa97"
-SRCREV_meta ?= "46bb64d605fd336d99fa05bab566b9553b40b4b4"
+SRCREV_machine ?= "368da9a4a63880c315aabff5834c8d3a807b"
+SRCREV_meta ?= "fde1381efc83859fcd873521bd1243646b22ef46"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.1.15"
+LINUX_VERSION ?= "4.1.16"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
index 4caa2523b30e..81f339d2b2d3 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "4.1.15"
+LINUX_VERSION ?= "4.1.16"
 
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "788dfc9859321c09f1c58696bf8998f90ccb4f51"
-SRCREV_meta ?= "46bb64d605fd336d99fa05bab566b9553b40b4b4"
+SRCREV_machine ?= "9acf3d237d07758701d56c75cc2058f05a974899"
+SRCREV_meta ?= "fde1381efc83859fcd873521bd1243646b22ef46"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
index b81458b3c057..cbc5f1a745d8 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -11,20 +11,20 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "cf760f381c5e1e58d0c3372d66f4dfdc33f0984c"
-SRCREV_machine_qemuarm64 ?= "788dfc9859321c09f1c58696bf8998f90ccb4f51"
-SRCREV_machine_qemumips ?= "aa46295ab927bd5c960930c377855dbc4e57b195"
-SRCREV_machine_qemuppc ?= "788dfc9859321c09f1c58696bf8998f90ccb4f51"
-SRCREV_machine_qemux86 ?= "788dfc9859321c09f1c58696bf8998f90ccb4f51"
-SRCREV_machine_qemux86-64 ?= "788dfc9859321c09f1c58696bf8998f90ccb4f51"
-SRCREV_machine_qemumips64 ?= "949c0f2cbb4cf902478d009a7d38b6e4fb29e7c4"
-SRCREV_machine ?= "788dfc9859321c09f1c58696bf8998f90ccb4f51"
-SRCREV_meta ?= "46bb64d605fd336d99fa05bab566b9553b40b4b4"
+SRCREV_machine_qemuarm ?= "b635f136b1c5ffd0f570b1799c9265ba832efc3a"
+SRCREV_machine_qemuarm64 ?= "9acf3d237d07758701d56c75cc2058f05a974899"
+SRCREV_machine_qemumips ?= "fd7be86f6cafbf3947fdffdee23b0e9ca9e4abb0"
+SRCREV_machine_qemuppc ?= "9acf3d237d07758701d56c75cc2058f05a974899"
+SRCREV_machine_qemux86 ?= "9acf3d237d07758701d56c75cc2058f05a974899"
+SRCREV_machine_qemux86-64 ?= "9acf3d237d07758701d56c75cc2058f05a974899"
+SRCREV_machine_qemumips64 ?= "45cc8f9f06eb83d7804d03690e7fa0d76b060e16"
+SRCREV_machine ?= "9acf3d237d07758701d56c75cc2058f05a974899"
+SRCREV_meta ?= "fde1381efc83859fcd873521bd1243646b22ef46"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH}; 
\

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.1.15"
+LINUX_VERSION ?= "4.1.16"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
2.1.0

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

[OE-core] [PATCH 0/2]: linux-yocto: consolidated pull request

[Bruce Ashfield]

Hi all,

Now that we've introduced the 4.4 versioned kernel, and updated the libc-headers
to match, here's the next round of updates.

Obviously the SRCREV updates are -stable and CVE fixes, and I've tested them
on qemu*. These are good for master, and the 4.1 change is suitable for any
stable branches that have the 4.1 kernel.

On the topic of the KEYS CVEs, I also pushed changes to linux-yocto 3.14
and 3.19, but haven't prepared a SRCREV update, since I don't have the
cycles to build and boot those branches. If we do want to update older
releases with those SRCREVs, we'll have to work out a special case.

Cheers,

Bruce

The following changes since commit 3d2c0f5902cacf9d8544bf263b51ef0dd1a7218c:

  cmake: update to 3.4.2 (2016-01-26 22:49:40 +)

are available in the git repository at:

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

Bruce Ashfield (2):
  linux-yocto/4.1: update to 4.1.16
  linux-yocto/4.4: CVEs and preempt-rt update

 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb   |  4 ++--
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb |  4 ++--
 meta/recipes-kernel/linux/linux-yocto_4.1.bb  | 20 ++--
 meta/recipes-kernel/linux/linux-yocto_4.4.bb  | 18 +-
 6 files changed, 29 insertions(+), 29 deletions(-)

-- 
2.1.0

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

Re: [OE-core] [PATCH] busybox: fix stop -vs- start typo in rcS script

[Khem Raj]

> On Jan 26, 2016, at 2:16 PM, Andre McCurdy  wrote:
> 
> Also make the rcS and rcK comments match the code.
> 

thanks looks ok.

> Signed-off-by: Andre McCurdy 
> ---
> meta/recipes-core/busybox/files/rcK | 5 +++--
> meta/recipes-core/busybox/files/rcS | 7 ---
> 2 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/meta/recipes-core/busybox/files/rcK 
> b/meta/recipes-core/busybox/files/rcK
> index 050086e..f8a63e1 100644
> --- a/meta/recipes-core/busybox/files/rcK
> +++ b/meta/recipes-core/busybox/files/rcK
> @@ -1,9 +1,10 @@
> #!/bin/sh
> 
> -# Stop all init scripts in /etc/init.d
> -# executing them in reversed numerical order.
> +# Stop all init scripts in /etc/rc6.d
> +# executing them in numerical order.
> #
> for i in /etc/rc6.d/K??*; do
> +
>  # Ignore dangling symlinks (if any).
>  [ ! -f "$i" ] && continue
> 
> diff --git a/meta/recipes-core/busybox/files/rcS 
> b/meta/recipes-core/busybox/files/rcS
> index d18c26b..bb03eb6 100644
> --- a/meta/recipes-core/busybox/files/rcS
> +++ b/meta/recipes-core/busybox/files/rcS
> @@ -1,10 +1,11 @@
> #!/bin/sh
> 
> -# Stop all init scripts in /etc/init.d
> -# executing them in reversed numerical order.
> +# Start all init scripts in /etc/rcS.d and /etc/rc5.d
> +# executing them in numerical order.
> #
> 
> for i in /etc/rcS.d/S??* /etc/rc5.d/S??* ;do
> +
>  # Ignore dangling symlinks (if any).
>  [ ! -f "$i" ] && continue
> 
> @@ -13,7 +14,7 @@ for i in /etc/rcS.d/S??* /etc/rc5.d/S??* ;do
>   # Source shell script for speed.
>   (
>   trap - INT QUIT TSTP
> - set stop
> + set start
>   . $i
>   )
>   ;;
> --
> 1.9.1
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] mtools: keep v3.9.9 recipe in sync with the v4.0.18 version

[Khem Raj]

> On Jan 26, 2016, at 2:14 PM, Andre McCurdy  wrote:
> 
> Changes are mostly cosmetic, but also include one important fix
> to support builds using musl libc.

Looks ok. I haven’t fixed the GPL2-only recipes yet.

> 
>  
> http://git.openembedded.org/openembedded-core/commit/?id=9f5eb272784d3be17e7fe8e7cab511bd4086ba1e
> 
> Signed-off-by: Andre McCurdy 
> ---
> meta/recipes-devtools/mtools/mtools_3.9.9.bb | 36 +++-
> 1 file changed, 19 insertions(+), 17 deletions(-)
> 
> diff --git a/meta/recipes-devtools/mtools/mtools_3.9.9.bb 
> b/meta/recipes-devtools/mtools/mtools_3.9.9.bb
> index c284a71..26d52a9 100644
> --- a/meta/recipes-devtools/mtools/mtools_3.9.9.bb
> +++ b/meta/recipes-devtools/mtools/mtools_3.9.9.bb
> @@ -1,16 +1,15 @@
> -# mtools OE build file
> -# Copyright (C) 2004-2006, Advanced Micro Devices, Inc.  All Rights Reserved
> -# Released under the MIT license (see packages/COPYING)
> -
> SUMMARY = "Utilities to access MS-DOS disks without mounting them"
> -DESCRIPTION = "Mtools is a collection of utilities for accessing MS-DOS 
> disks from Unix without mounting them."
> +DESCRIPTION = "Mtools is a collection of utilities to access MS-DOS disks 
> from GNU and Unix without mounting them."
> HOMEPAGE = "http://www.gnu.org/software/mtools/;
> +SECTION = "optional"
> LICENSE = "GPLv2+"
> LIC_FILES_CHKSUM = "file://COPYING;md5=92b58ec77696788ce278b044d2a8e9d3"
> PR = "r6"
> 
> -RDEPENDS_${PN} = "glibc-gconv-ibm850"
> -RRECOMMENDS_${PN} = "\
> +DEPENDS += "virtual/libiconv"
> +
> +RDEPENDS_${PN}_libc-glibc = "glibc-gconv-ibm850"
> +RRECOMMENDS_${PN}_libc-glibc = "\
>   glibc-gconv-ibm437 \
>   glibc-gconv-ibm737 \
>   glibc-gconv-ibm775 \
> @@ -26,24 +25,22 @@ RRECOMMENDS_${PN} = "\
>   glibc-gconv-ibm866 \
>   glibc-gconv-ibm869 \
>   "
> -
> -#http://mtools.linux.lu/mtools-${PV}.tar.gz
> -SRC_URI = 
> "http://downloads.yoctoproject.org/mirror/sources/mtools-${PV}.tar.gz \
> - file://mtools-makeinfo.patch \
> - file://mtools.patch \
> - file://no-x11.patch \
> - file://fix-broken-lz.patch \
> -"
> -
> SRC_URI[md5sum] = "3e68b857b4e1f3a6521d1dfefbd30a36"
> SRC_URI[sha256sum] = 
> "af083a73425d664d4607ef6c6564fd9319a0e47ee7c105259a45356cb834690e"
> 
> -S = "${WORKDIR}/mtools-${PV}"
> +#http://mtools.linux.lu/mtools-${PV}.tar.gz
> +SRC_URI = 
> "http://downloads.yoctoproject.org/mirror/sources/mtools-${PV}.tar.gz \
> +   file://mtools-makeinfo.patch \
> +   file://mtools.patch \
> +   file://no-x11.patch \
> +   file://fix-broken-lz.patch"
> 
> inherit autotools texinfo
> 
> EXTRA_OECONF = "--without-x"
> 
> +LDFLAGS_append_libc-uclibc = " -liconv "
> +
> BBCLASSEXTEND = "native nativesdk"
> 
> PACKAGECONFIG ??= ""
> @@ -54,3 +51,8 @@ do_install_prepend () {
> mkdir -p ${D}/${bindir}
> mkdir -p ${D}/${datadir}
> }
> +
> +do_install_append_class-native () {
> +create_wrapper ${D}${bindir}/mcopy \
> +GCONV_PATH=${libdir}/gconv
> +}
> --
> 1.9.1
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] [RFT] Glibc 2.23 and binutils 2.26

[Khem Raj]

> On Jan 26, 2016, at 9:11 PM, ChenQi  wrote:
> 
> On 01/17/2016 07:54 PM, Khem Raj wrote:
>> Hi all
>> 
>> upstream glibc and binutils release branches have been cut out and are being 
>> made ready for next release
>> I have put together update patchset for both of them
>> 
>> here are the branches
>> 
>> https://github.com/kraj/openembedded-core/tree/kraj/binutils-2.26
>> https://github.com/kraj/openembedded-core/tree/kraj/glibc-2.23
>> 
>> FYI These are still using autorev to ensure that we test tip of release 
>> branches
>> 
>> Please give them a shot in your environments and report any issues you 
>> encounter.
>> 
>> Thanks for help
>> 
>> -Khem
>> 
>> 
>> 
>> 
>> 
> 
> 0001-Generate-relocatable-SDKs.patch is included in SRC_URI twice, which 
> causes the following error when building binutils-crosssdk-XXX.
> 
> ERROR: Command Error: exit status: 1  Output:
> Patch 0001-Generate-relocatable-SDKs.patch is already applied; check your 
> series file
> ERROR: Function failed: patch_do_patch
> 
> binutils-2.26.inc and binutils-crosssdk_2.26.bb both has this patch in its 
> SRC_RUI.
> 

Thanks for report. fixed and squashed into original commit in same branch as 
above.

> Regards,
> Chen Qi
> --
> ___
> Openembedded-devel mailing list
> openembedded-de...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv3] ptest-runner_2.0: Add ptest-runner_2.0 recipe.

[Burton, Ross]

On 26 January 2016 at 04:38, Robert Yang  wrote:

> If it is fully compatible with 1.0, how about remove 1.0, please ?
>

Agreed, I squashed that into the patch when merging it into my staging
branch.

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

[OE-core] [PATCH 1/2] externalsrc.bbclas: remove nostamp from do_configure

[Markus Lehtonen]

Be a bit more intelligent than mindlessly re-compiling every time.
Instead of using 'nostamp' flag for do_compile add the whole source tree
as 'file-checksums' flag. This way, do_compile is only re-run if
something in the source tree content changes. Hidden files and
directories in the source tree root are ignored by the glob currently
used. This has the advantage of automatically ignoring .git directory,
for example.

This does not work perfectly, though, as many packages are built under
${S} which effectively changes the source tree causing some unwanted
re-compilations.  However, if do_compile of the recipe does not produce
new/different artefacts on every run (as commonly is and should be the
case) the re-compilation loop stops. Thus, you should usually see only
one re-compilation (if any) after which the source tree is "stabilized"
and no more re-compilations happen.

During the first bitbake run preparing of the task runqueue may take
much longer because all the files in the source tree are hashed.
Subsequent builds are not significantly slower because (most) file
hashes are found from the cache.

[YOCTO #8853]

Signed-off-by: Markus Lehtonen 
---
 meta/classes/externalsrc.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index f7ed66d..fe4963d 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -83,8 +83,7 @@ python () {
 
 d.prependVarFlag('do_compile', 'prefuncs', 
"externalsrc_compile_prefunc ")
 
-# Ensure compilation happens every time
-d.setVarFlag('do_compile', 'nostamp', '1')
+d.setVarFlag('do_compile', 'file-checksums', externalsrc + '/*:True')
 }
 
 python externalsrc_compile_prefunc() {
-- 
2.1.4

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

[OE-core] [PATCH 0/2] Improve externalsrc task dependency tracking

[Markus Lehtonen]

This patchset improves task hashing of do_compile when externalsrc is enabled.
Previously, it was simply a 'nostamp' task that was always being (re-)run. This
patchset changes externalsrc to utilize the file-checksum dependency feature of
tasks to really track changes in the source tree, and thus, aims in preventing
unneeded (re-)compilations.

[YOCTO #8853]


The following changes since commit fc4209baa098caebf9c4cb75f9a6f2e85f4c:

  Revert "xz: Allow to work with ASSUME_PROVIDED xz-native" (2016-01-25 
10:08:25 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib marquiz/devtool/fixes


Markus Lehtonen (2):
  externalsrc.bbclas: remove nostamp from do_configure
  devtool: create-workspace: define separate cache for task file
checksums

 meta/classes/externalsrc.bbclass | 3 +--
 scripts/devtool  | 1 +
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.1.4

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

[OE-core] [PATCH 2/2] devtool: create-workspace: define separate cache for task file checksums

[Markus Lehtonen]

Define BB_HASH_CHECKSUM_CACHE_FILE variable in the workspace layer
config so that a specific cache is used for storing the task file
dependency checksums. The file checksum cache can grow quite large after
hashing of all file in externalsrc trees was enabled.  This patch
prevents polluting/growing the fetcher local file checksum cache. Also,
this new devtool-specific cache is not used after the workspace layer is
disabled.

[YOCTO #8853]

Signed-off-by: Markus Lehtonen 
---
 scripts/devtool | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/devtool b/scripts/devtool
index 2d57da0..e44b87e9 100755
--- a/scripts/devtool
+++ b/scripts/devtool
@@ -152,6 +152,7 @@ def _create_workspace(workspacedir, config, basepath):
 f.write('BBFILE_PATTERN_workspacelayer = "^$' + '{LAYERDIR}/"\n')
 f.write('BBFILE_PATTERN_IGNORE_EMPTY_workspacelayer = "1"\n')
 f.write('BBFILE_PRIORITY_workspacelayer = "99"\n')
+f.write('BB_HASH_CHECKSUM_CACHE_FILE = 
"filedep_checksum_cache.dat"\n')
 # Add a README file
 with open(os.path.join(workspacedir, 'README'), 'w') as f:
 f.write('This layer was created by the OpenEmbedded devtool 
utility in order to\n')
-- 
2.1.4

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

Re: [OE-core] [PATCH] stress-ng: add 0.05.09

[Denys Dmytriyenko]

On Tue, Jan 26, 2016 at 11:24:43AM +, Burton, Ross wrote:
> On 26 January 2016 at 03:34, Denys Dmytriyenko  wrote:
> 
> > A clean room re-implementation and extension of the original stress tool.
> >
> 
> What's the rationale for adding this to oe-core over another layer?

None, besides the original stress is in oe-core. What other layer would you 
suggest?

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

Re: [OE-core] [PATCH] stress-ng: add 0.05.09

[Otavio Salvador]

On Tue, Jan 26, 2016 at 1:34 AM, Denys Dmytriyenko  wrote:
> From: Denys Dmytriyenko 
>
> A clean room re-implementation and extension of the original stress tool.
>
> Signed-off-by: Denys Dmytriyenko 
> ---
>  meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb | 15 +++
>  1 file changed, 15 insertions(+)
>  create mode 100644 meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb
>
> diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb 
> b/meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb
> new file mode 100644
> index 000..2e92c53
> --- /dev/null
> +++ b/meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb
> @@ -0,0 +1,15 @@
> +SUMMARY = "A tool to load and stress a computer system"
> +HOMEPAGE = "http://kernel.ubuntu.com/~cking/stress-ng/;
> +LICENSE = "GPLv2"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> +
> +SRC_URI = "http://kernel.ubuntu.com/~cking/tarballs/${BPN}/${BP}.tar.gz;
> +
> +SRC_URI[md5sum] = "fe65047991f654ffaac3c59ea9537763"
> +SRC_URI[sha256sum] = 
> "d785b5f2df042d42c43ddfd5bbafa19151ed96f0c483d7f44c737f492b52ddd6"
> +
> +CFLAGS += "-Wall -Wextra -DVERSION='"$(VERSION)"' -O2"

Where version comes from?

-- 
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] stress-ng: add 0.05.09

[Otavio Salvador]

On Tue, Jan 26, 2016 at 12:20 PM, Denys Dmytriyenko  wrote:
> On Tue, Jan 26, 2016 at 11:24:43AM +, Burton, Ross wrote:
>> On 26 January 2016 at 03:34, Denys Dmytriyenko  wrote:
>>
>> > A clean room re-implementation and extension of the original stress tool.
>> >
>>
>> What's the rationale for adding this to oe-core over another layer?
>
> None, besides the original stress is in oe-core. What other layer would you
> suggest?

I think meta-oe is better; in fact the 'stress' package could go there as well.

-- 
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] stress-ng: add 0.05.09

[Denys Dmytriyenko]

On Tue, Jan 26, 2016 at 02:01:14PM -0200, Otavio Salvador wrote:
> On Tue, Jan 26, 2016 at 1:34 AM, Denys Dmytriyenko  wrote:
> > From: Denys Dmytriyenko 
> >
> > A clean room re-implementation and extension of the original stress tool.
> >
> > Signed-off-by: Denys Dmytriyenko 
> > ---
> >  meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb | 15 +++
> >  1 file changed, 15 insertions(+)
> >  create mode 100644 meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb
> >
> > diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb 
> > b/meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb
> > new file mode 100644
> > index 000..2e92c53
> > --- /dev/null
> > +++ b/meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb
> > @@ -0,0 +1,15 @@
> > +SUMMARY = "A tool to load and stress a computer system"
> > +HOMEPAGE = "http://kernel.ubuntu.com/~cking/stress-ng/;
> > +LICENSE = "GPLv2"
> > +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> > +
> > +SRC_URI = "http://kernel.ubuntu.com/~cking/tarballs/${BPN}/${BP}.tar.gz;
> > +
> > +SRC_URI[md5sum] = "fe65047991f654ffaac3c59ea9537763"
> > +SRC_URI[sha256sum] = 
> > "d785b5f2df042d42c43ddfd5bbafa19151ed96f0c483d7f44c737f492b52ddd6"
> > +
> > +CFLAGS += "-Wall -Wextra -DVERSION='"$(VERSION)"' -O2"
> 
> Where version comes from?

>From the Makefile

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

Re: [OE-core] [PATCH] stress-ng: add 0.05.09

[Maxin B. John]

Hi Otavio,

On Tue, Jan 26, 2016 at 02:02:26PM -0200, Otavio Salvador wrote:
> On Tue, Jan 26, 2016 at 12:20 PM, Denys Dmytriyenko  wrote:
> > On Tue, Jan 26, 2016 at 11:24:43AM +, Burton, Ross wrote:
> >> On 26 January 2016 at 03:34, Denys Dmytriyenko  wrote:
> >>
> >> > A clean room re-implementation and extension of the original stress tool.
> >> >
> >>
> >> What's the rationale for adding this to oe-core over another layer?
> >
> > None, besides the original stress is in oe-core. What other layer would you
> > suggest?
> 
> I think meta-oe is better; in fact the 'stress' package could go there as 
> well.

"stress" package was moved from meta-linaro to oe-core as a dependency for 
rt-tests ptest.

> -- 
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750

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

Re: [OE-core] [PATCH] stress-ng: add 0.05.09

[Otavio Salvador]

On Tue, Jan 26, 2016 at 2:14 PM, Denys Dmytriyenko  wrote:
> On Tue, Jan 26, 2016 at 02:01:14PM -0200, Otavio Salvador wrote:
>> On Tue, Jan 26, 2016 at 1:34 AM, Denys Dmytriyenko  wrote:
>> > From: Denys Dmytriyenko 
>> >
>> > A clean room re-implementation and extension of the original stress tool.
>> >
>> > Signed-off-by: Denys Dmytriyenko 
>> > ---
>> >  meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb | 15 +++
>> >  1 file changed, 15 insertions(+)
>> >  create mode 100644 meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb
>> >
>> > diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb 
>> > b/meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb
>> > new file mode 100644
>> > index 000..2e92c53
>> > --- /dev/null
>> > +++ b/meta/recipes-extended/stress-ng/stress-ng_0.05.09.bb
>> > @@ -0,0 +1,15 @@
>> > +SUMMARY = "A tool to load and stress a computer system"
>> > +HOMEPAGE = "http://kernel.ubuntu.com/~cking/stress-ng/;
>> > +LICENSE = "GPLv2"
>> > +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
>> > +
>> > +SRC_URI = "http://kernel.ubuntu.com/~cking/tarballs/${BPN}/${BP}.tar.gz;
>> > +
>> > +SRC_URI[md5sum] = "fe65047991f654ffaac3c59ea9537763"
>> > +SRC_URI[sha256sum] = 
>> > "d785b5f2df042d42c43ddfd5bbafa19151ed96f0c483d7f44c737f492b52ddd6"
>> > +
>> > +CFLAGS += "-Wall -Wextra -DVERSION='"$(VERSION)"' -O2"
>>
>> Where version comes from?
>
> From the Makefile

And $(VERSION) ? I think you need to use ${PV} here.

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

[OE-core] [PATCH] rootfs-postcommands: fix allow-empty-password on read-only rootfs

[Ross Burton]

When a read-only rootfs is being used sshd uses a different sshd_config file,
which also needs to be editted.

[ YOCTO #8680 ]

Signed-off-by: Ross Burton 
---
 meta/classes/rootfs-postcommands.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index 0736d6c..f5d6147 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -113,8 +113,8 @@ zap_empty_root_password () {
 #
 ssh_allow_empty_password () {
if [ -e ${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config ]; then
-   sed -i 's/^[#[:space:]]*PermitRootLogin.*/PermitRootLogin yes/' 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config
-   sed -i 
's/^[#[:space:]]*PermitEmptyPasswords.*/PermitEmptyPasswords yes/' 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config
+   sed -i 's/^[#[:space:]]*PermitRootLogin.*/PermitRootLogin yes/' 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config_readonly
+   sed -i 
's/^[#[:space:]]*PermitEmptyPasswords.*/PermitEmptyPasswords yes/' 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config_readonly
fi
 
if [ -e ${IMAGE_ROOTFS}${sbindir}/dropbear ] ; then
-- 
2.6.4

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

Re: [OE-core] Bogus openembedded gcc patch

[Khem Raj]

> On Jan 25, 2016, at 8:02 PM, Mathieu Desnoyers 
>  wrote:
> 
> Hi,
> 
> We are noticing the presence of the following patch in various
> openembedded gcc versions:
> 
> 0024-PR-target-32219.patch
> 
> "From e0d15f4f8bf28c351b9215ca37f1caa24df0e1fd Mon Sep 17 00:00:00 2001
> From: Khem Raj 
> Date: Fri, 29 Mar 2013 09:18:54 +0400
> Subject: [PATCH 24/35] PR target/32219
> 
> * varasm.c (default_binds_local_p_1): Weak data is not local.
> 
> Signed-off-by: Bernhard Reutner-Fischer 
> Signed-off-by: Khem Raj 
> 
> Upstream-Status: Backport"
> 
> However, contrarily to its "Backport" status, that patch is
> not upstream in gcc, and we're starting to wonder if this
> would be the patch that breaks handling of start/stop automatic
> hidden symbols we use in lttng-ust.
> 
> We are only experiencing problems on the various openembedded
> compilers, but on no other distro (with same compiler versions),
> which leads us to suspect a buggy distro-specific gcc patch.
> 
> We've been testing with openembedded gcc-4.9.2-r0.
> 
> The original gold linker issue that this patch was trying to
> address seems to have been fixed in the gold linke since
> then.
> 
> Refs:
> http://lists.lttng.org/pipermail/lttng-dev/2014-May/023112.html
> https://gcc.gnu.org/ml/gcc-help/2014-05/msg00042.html
> http://cgit.openembedded.org/openembedded-core/commit/?id=3cb2b003db7371b3a47d02c08352a262e1e419b4
> https://sourceware.org/bugzilla/show_bug.cgi?id=15435
> 
> Thoughts ?

OE has defaulted to gcc5 since last release, and gold issue is fixed in 
binutils 2.25
which is what we use in 2.0 as well so it might be OK to unbolt this fix. 
Although I am not sure
about the original problem reported in PR32219 is fixed for gcc 4.9 if we 
remove this fix.
Have you narrowed down your issue to this patch ? if not, then it would be good 
to do so

> 
> Thanks,
> 
> Mathieu
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC][PATCH] gcc-runtime.inc: force libstdc++ to always use gcc4 compatible ABI

[Khem Raj]

> On Jan 26, 2016, at 12:10 AM, Andre McCurdy  wrote:
> 
> Experimental hack, not expected to be merged.
> 
> Without this, the http://www.cplusplus.com/reference/string/string/append/
> example fails to build with -std=c++11 and it's not clear why (it's as if we
> build a version of libstdc++ which supports only the old ABI but with headers
> which try to use the new ABI when compiled with -std=c++11 ?). As a 
> workaround,
> force libstdc++ to provide, and default to using, the old ABI in all cases.
> 
> See also:
> 
>  https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html
>  https://mail.gnome.org/archives/gtkmm-list/2015-June/msg00026.html
>  https://wiki.debian.org/GCC5
> 
> Signed-off-by: Andre McCurdy 
> ---
> meta/recipes-devtools/gcc/gcc-runtime.inc | 13 +
> 1 file changed, 13 insertions(+)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
> b/meta/recipes-devtools/gcc/gcc-runtime.inc
> index f20d298..3a476cd 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> @@ -10,6 +10,19 @@ EXTRA_OECONF_PATHS = "\
> 
> EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
> 
> +# gcc-runtime.inc: force libstdc++ to always use gcc4 compatible ABI
> +# Experimental hack. Without this, the 
> http://www.cplusplus.com/reference/string/string/append/
> +# example fails to build with -std=c++11 and it's not clear why (it's as if 
> we
> +# build a version of libstdc++ which supports only the old ABI but with 
> headers
> +# which try to use the new ABI when compiled with -std=c++11 ?). As a 
> workaround,
> +# force libstdc++ to provide, and default to using, the old ABI in all cases.
> +# See also:
> +# https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html
> +# https://mail.gnome.org/archives/gtkmm-list/2015-June/msg00026.html
> +# https://wiki.debian.org/GCC5
> +#
> +EXTRA_OECONF_append = " --disable-libstdcxx-dual-abi 
> --with-default-libstdcxx-abi=gcc4-compatible”

This change while makes it work compatible to older libstdc++ ABI, we should 
make the defaults to be
forward looking. I would rather keep --with-default-libstdcxx-abi=c++11 since 
gcc6 will switch to newer
c++ std as default. If we revert like you suggest, we will be up for more work 
in gcc6 time.

please define _GLIBCXX_USE_CXX11_ABI=0 for your app, where you see the problem.

> +

> RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic \
> ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', 
> '', d)} \
> "
> --
> 1.9.1
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC][PATCH] gcc-runtime.inc: force libstdc++ to always use gcc4 compatible ABI

[Andre McCurdy]

On Tue, Jan 26, 2016 at 8:38 AM, Khem Raj  wrote:
>
>> On Jan 26, 2016, at 12:10 AM, Andre McCurdy  wrote:
>>
>> Experimental hack, not expected to be merged.
>>
>> Without this, the http://www.cplusplus.com/reference/string/string/append/
>> example fails to build with -std=c++11 and it's not clear why (it's as if we
>> build a version of libstdc++ which supports only the old ABI but with headers
>> which try to use the new ABI when compiled with -std=c++11 ?). As a 
>> workaround,
>> force libstdc++ to provide, and default to using, the old ABI in all cases.
>>
>> See also:
>>
>>  https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html
>>  https://mail.gnome.org/archives/gtkmm-list/2015-June/msg00026.html
>>  https://wiki.debian.org/GCC5
>>
>> Signed-off-by: Andre McCurdy 
>> ---
>> meta/recipes-devtools/gcc/gcc-runtime.inc | 13 +
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
>> b/meta/recipes-devtools/gcc/gcc-runtime.inc
>> index f20d298..3a476cd 100644
>> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
>> @@ -10,6 +10,19 @@ EXTRA_OECONF_PATHS = "\
>>
>> EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
>>
>> +# gcc-runtime.inc: force libstdc++ to always use gcc4 compatible ABI
>> +# Experimental hack. Without this, the 
>> http://www.cplusplus.com/reference/string/string/append/
>> +# example fails to build with -std=c++11 and it's not clear why (it's as if 
>> we
>> +# build a version of libstdc++ which supports only the old ABI but with 
>> headers
>> +# which try to use the new ABI when compiled with -std=c++11 ?). As a 
>> workaround,
>> +# force libstdc++ to provide, and default to using, the old ABI in all 
>> cases.
>> +# See also:
>> +# https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html
>> +# https://mail.gnome.org/archives/gtkmm-list/2015-June/msg00026.html
>> +# https://wiki.debian.org/GCC5
>> +#
>> +EXTRA_OECONF_append = " --disable-libstdcxx-dual-abi 
>> --with-default-libstdcxx-abi=gcc4-compatible”
>
> This change while makes it work compatible to older libstdc++ ABI, we should 
> make the defaults to be
> forward looking.

Yes, I agree. The problem is that currently our libstdc++ doesn't seem
to support the new ABI.

> I would rather keep --with-default-libstdcxx-abi=c++11 since gcc6 will switch 
> to newer
> c++ std as default. If we revert like you suggest, we will be up for more 
> work in gcc6 time.
>
> please define _GLIBCXX_USE_CXX11_ABI=0 for your app, where you see the 
> problem.

My test case is the example app from:

  http://www.cplusplus.com/reference/string/string/append/

It fails when I try to compile to use the new ABI (ie by using
-stdc++11 or _GLIBCXX_USE_CXX11_ABI=1).

There is no legacy code involved.

>
>> RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic \
>> ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', 
>> '', d)} \
>> "
>> --
>> 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

[OE-core] [PATCH] image: Don't create tasks with '.' in the name

[Richard Purdie]

Similarly to "-", "." doesn't work well in task names but is used in
some real world image classes. Work around this with some replacements
for now to unbreak layers.

(Issues don't show themselves until runtime, e.g. with --dry-run)

Tested-By: Otavio Salvador 
Signed-off-by: Richard Purdie 

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 3870516..797f342 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -395,9 +395,9 @@ python () {
 
 after = 'do_image'
 for dep in typedeps[t]:
-after += ' do_image_%s' % dep.replace("-", "_")
+after += ' do_image_%s' % dep.replace("-", "_").replace(".", "_")
 
-t = t.replace("-", "_")
+t = t.replace("-", "_").replace(".", "_")
 
 d.setVar('do_image_%s' % t, '\n'.join(cmds))
 d.setVarFlag('do_image_%s' % t, 'func', '1')


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

[OE-core] [PATCH] attr: fix build issue with NLS disabled on non-uclibc targets

[Derek Straka]

Signed-off-by: Derek Straka 
---
 meta/recipes-support/attr/ea-acl.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/attr/ea-acl.inc 
b/meta/recipes-support/attr/ea-acl.inc
index 370e16f..ab98380 100644
--- a/meta/recipes-support/attr/ea-acl.inc
+++ b/meta/recipes-support/attr/ea-acl.inc
@@ -23,8 +23,8 @@ FILES_lib${BPN} = "${base_libdir}/lib*${SOLIBS}"
 
 BBCLASSEXTEND = "native"
 # Only append ldflags for target recipe and if USE_NLS is enabled
-LDFLAGS_append_libc-uclibc_class-target = "${@['', ' -lintl 
'][(d.getVar('USE_NLS', True) == 'yes')]}"
-EXTRA_OECONF_append_libc-uclibc_class-target = "${@['', ' --disable-gettext 
'][(d.getVar('USE_NLS', True) == 'no')]}"
+LDFLAGS_append_class-target = "${@['', ' -lintl '][(d.getVar('USE_NLS', True) 
== 'yes')]}"
+EXTRA_OECONF_append_class-target = "${@['', ' --disable-gettext 
'][(d.getVar('USE_NLS', True) == 'no')]}"
 
 fix_symlink () {
if [ "${BB_CURRENTTASK}" != "populate_sysroot" -a "${BB_CURRENTTASK}" 
!= "populate_sysroot_setscene" ]
-- 
1.9.1

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

Re: [OE-core] Bogus openembedded gcc patch

[Bernhard Reutner-Fischer]

On 26 Jan 2016 17:28, "Khem Raj"  wrote:
>
>
> > On Jan 25, 2016, at 8:02 PM, Mathieu Desnoyers <
mathieu.desnoy...@efficios.com> wrote:
> >
> > Hi,
> >
> > We are noticing the presence of the following patch in various
> > openembedded gcc versions:
> >
> > 0024-PR-target-32219.patch
> >
> > "From e0d15f4f8bf28c351b9215ca37f1caa24df0e1fd Mon Sep 17 00:00:00 2001
> > From: Khem Raj 
> > Date: Fri, 29 Mar 2013 09:18:54 +0400
> > Subject: [PATCH 24/35] PR target/32219
> >
> > * varasm.c (default_binds_local_p_1): Weak data is not local.
> >
> > Signed-off-by: Bernhard Reutner-Fischer 
> > Signed-off-by: Khem Raj 
> >
> > Upstream-Status: Backport"
> >
> > However, contrarily to its "Backport" status, that patch is
> > not upstream in gcc, and we're starting to wonder if this
> > would be the patch that breaks handling of start/stop automatic
> > hidden symbols we use in lttng-ust.
> >
> > We are only experiencing problems on the various openembedded
> > compilers, but on no other distro (with same compiler versions),
> > which leads us to suspect a buggy distro-specific gcc patch.
> >
> > We've been testing with openembedded gcc-4.9.2-r0.
> >
> > The original gold linker issue that this patch was trying to
> > address seems to have been fixed in the gold linke since
> > then.
> >
> > Refs:
> > http://lists.lttng.org/pipermail/lttng-dev/2014-May/023112.html
> > https://gcc.gnu.org/ml/gcc-help/2014-05/msg00042.html
> >
http://cgit.openembedded.org/openembedded-core/commit/?id=3cb2b003db7371b3a47d02c08352a262e1e419b4
> > https://sourceware.org/bugzilla/show_bug.cgi?id=15435
> >
> > Thoughts ?
>
> OE has defaulted to gcc5 since last release, and gold issue is fixed in
binutils 2.25
> which is what we use in 2.0 as well so it might be OK to unbolt this fix.
Although I am not sure
> about the original problem reported in PR32219 is fixed for gcc 4.9 if we
remove this fix.
> Have you narrowed down your issue to this patch ? if not, then it would
be good to do so

See http://gcc.gnu.org/PR32219 this is fixed for at least 6.0 so should
certainly be dropped for any fixed GCC. Not sure if anybody is willing to
backport this one, you might ask.

Thanks,
>
> >
> > Thanks,
> >
> > Mathieu
> >
> > --
> > Mathieu Desnoyers
> > EfficiOS Inc.
> > http://www.efficios.com
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] busybox: fix stop -vs- start typo in rcS script

[Andre McCurdy]

Also make the rcS and rcK comments match the code.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-core/busybox/files/rcK | 5 +++--
 meta/recipes-core/busybox/files/rcS | 7 ---
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/busybox/files/rcK 
b/meta/recipes-core/busybox/files/rcK
index 050086e..f8a63e1 100644
--- a/meta/recipes-core/busybox/files/rcK
+++ b/meta/recipes-core/busybox/files/rcK
@@ -1,9 +1,10 @@
 #!/bin/sh
 
-# Stop all init scripts in /etc/init.d
-# executing them in reversed numerical order.
+# Stop all init scripts in /etc/rc6.d
+# executing them in numerical order.
 #
 for i in /etc/rc6.d/K??*; do
+
  # Ignore dangling symlinks (if any).
  [ ! -f "$i" ] && continue
 
diff --git a/meta/recipes-core/busybox/files/rcS 
b/meta/recipes-core/busybox/files/rcS
index d18c26b..bb03eb6 100644
--- a/meta/recipes-core/busybox/files/rcS
+++ b/meta/recipes-core/busybox/files/rcS
@@ -1,10 +1,11 @@
 #!/bin/sh
 
-# Stop all init scripts in /etc/init.d
-# executing them in reversed numerical order.
+# Start all init scripts in /etc/rcS.d and /etc/rc5.d
+# executing them in numerical order.
 #
 
 for i in /etc/rcS.d/S??* /etc/rc5.d/S??* ;do
+
  # Ignore dangling symlinks (if any).
  [ ! -f "$i" ] && continue
 
@@ -13,7 +14,7 @@ for i in /etc/rcS.d/S??* /etc/rc5.d/S??* ;do
# Source shell script for speed.
(
trap - INT QUIT TSTP
-   set stop
+   set start
. $i
)
;;
-- 
1.9.1

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

[OE-core] [PATCH] mtools: keep v3.9.9 recipe in sync with the v4.0.18 version

[Andre McCurdy]

Changes are mostly cosmetic, but also include one important fix
to support builds using musl libc.

  
http://git.openembedded.org/openembedded-core/commit/?id=9f5eb272784d3be17e7fe8e7cab511bd4086ba1e

Signed-off-by: Andre McCurdy 
---
 meta/recipes-devtools/mtools/mtools_3.9.9.bb | 36 +++-
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/meta/recipes-devtools/mtools/mtools_3.9.9.bb 
b/meta/recipes-devtools/mtools/mtools_3.9.9.bb
index c284a71..26d52a9 100644
--- a/meta/recipes-devtools/mtools/mtools_3.9.9.bb
+++ b/meta/recipes-devtools/mtools/mtools_3.9.9.bb
@@ -1,16 +1,15 @@
-# mtools OE build file
-# Copyright (C) 2004-2006, Advanced Micro Devices, Inc.  All Rights Reserved
-# Released under the MIT license (see packages/COPYING)
-
 SUMMARY = "Utilities to access MS-DOS disks without mounting them"
-DESCRIPTION = "Mtools is a collection of utilities for accessing MS-DOS disks 
from Unix without mounting them."
+DESCRIPTION = "Mtools is a collection of utilities to access MS-DOS disks from 
GNU and Unix without mounting them."
 HOMEPAGE = "http://www.gnu.org/software/mtools/;
+SECTION = "optional"
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=92b58ec77696788ce278b044d2a8e9d3"
 PR = "r6"
 
-RDEPENDS_${PN} = "glibc-gconv-ibm850"
-RRECOMMENDS_${PN} = "\
+DEPENDS += "virtual/libiconv"
+
+RDEPENDS_${PN}_libc-glibc = "glibc-gconv-ibm850"
+RRECOMMENDS_${PN}_libc-glibc = "\
glibc-gconv-ibm437 \
glibc-gconv-ibm737 \
glibc-gconv-ibm775 \
@@ -26,24 +25,22 @@ RRECOMMENDS_${PN} = "\
glibc-gconv-ibm866 \
glibc-gconv-ibm869 \
"
-
-#http://mtools.linux.lu/mtools-${PV}.tar.gz 
-SRC_URI = 
"http://downloads.yoctoproject.org/mirror/sources/mtools-${PV}.tar.gz \
-   file://mtools-makeinfo.patch \
-   file://mtools.patch \
-   file://no-x11.patch \
-   file://fix-broken-lz.patch \
-"
-
 SRC_URI[md5sum] = "3e68b857b4e1f3a6521d1dfefbd30a36"
 SRC_URI[sha256sum] = 
"af083a73425d664d4607ef6c6564fd9319a0e47ee7c105259a45356cb834690e"
 
-S = "${WORKDIR}/mtools-${PV}"
+#http://mtools.linux.lu/mtools-${PV}.tar.gz 
+SRC_URI = 
"http://downloads.yoctoproject.org/mirror/sources/mtools-${PV}.tar.gz \
+   file://mtools-makeinfo.patch \
+   file://mtools.patch \
+   file://no-x11.patch \
+   file://fix-broken-lz.patch"
 
 inherit autotools texinfo
 
 EXTRA_OECONF = "--without-x"
 
+LDFLAGS_append_libc-uclibc = " -liconv "
+
 BBCLASSEXTEND = "native nativesdk"
 
 PACKAGECONFIG ??= ""
@@ -54,3 +51,8 @@ do_install_prepend () {
 mkdir -p ${D}/${bindir}
 mkdir -p ${D}/${datadir}
 }
+
+do_install_append_class-native () {
+create_wrapper ${D}${bindir}/mcopy \
+GCONV_PATH=${libdir}/gconv
+}
-- 
1.9.1

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

Re: [OE-core] Bogus openembedded gcc patch

[Mathieu Desnoyers]

- On Jan 26, 2016, at 11:28 AM, Khem Raj raj.k...@gmail.com wrote:

>> On Jan 25, 2016, at 8:02 PM, Mathieu Desnoyers 
>> 
>> wrote:
>> 
>> Hi,
>> 
>> We are noticing the presence of the following patch in various
>> openembedded gcc versions:
>> 
>> 0024-PR-target-32219.patch
>> 
>> "From e0d15f4f8bf28c351b9215ca37f1caa24df0e1fd Mon Sep 17 00:00:00 2001
>> From: Khem Raj 
>> Date: Fri, 29 Mar 2013 09:18:54 +0400
>> Subject: [PATCH 24/35] PR target/32219
>> 
>> * varasm.c (default_binds_local_p_1): Weak data is not local.
>> 
>> Signed-off-by: Bernhard Reutner-Fischer 
>> Signed-off-by: Khem Raj 
>> 
>> Upstream-Status: Backport"
>> 
>> However, contrarily to its "Backport" status, that patch is
>> not upstream in gcc, and we're starting to wonder if this
>> would be the patch that breaks handling of start/stop automatic
>> hidden symbols we use in lttng-ust.
>> 
>> We are only experiencing problems on the various openembedded
>> compilers, but on no other distro (with same compiler versions),
>> which leads us to suspect a buggy distro-specific gcc patch.
>> 
>> We've been testing with openembedded gcc-4.9.2-r0.
>> 
>> The original gold linker issue that this patch was trying to
>> address seems to have been fixed in the gold linke since
>> then.
>> 
>> Refs:
>> http://lists.lttng.org/pipermail/lttng-dev/2014-May/023112.html
>> https://gcc.gnu.org/ml/gcc-help/2014-05/msg00042.html
>> http://cgit.openembedded.org/openembedded-core/commit/?id=3cb2b003db7371b3a47d02c08352a262e1e419b4
>> https://sourceware.org/bugzilla/show_bug.cgi?id=15435
>> 
>> Thoughts ?
> 
> OE has defaulted to gcc5 since last release, and gold issue is fixed in 
> binutils
> 2.25
> which is what we use in 2.0 as well so it might be OK to unbolt this fix.
> Although I am not sure
> about the original problem reported in PR32219 is fixed for gcc 4.9 if we 
> remove
> this fix.
> Have you narrowed down your issue to this patch ? if not, then it would be 
> good
> to do so

Yes, we have narrowed down our problem to this specific patch by
removing the patch from the OE gcc patches, rebuilding gcc, and
then building our test program with that gcc. The problem goes
away when we do so, which points directly to that patch as a
culprit.

Test program is attached.

Faulty[gcc 4.9-r0 with patch 0024]:

main: myvar addr=0x600c90 __start___test=0x600c90
fct: myvar addr=0x7f8733d1eae8 __start___test=0x600c90
fct2: myvar addr=0x7f8733d1eaec __start___test=0x600c90
fct3: myvar addr=0x600c94 __start___test=0x600c90

Valid[gcc 4.9-r0 without patch 0024]:

main: myvar addr=0x600c60 __start___test=0x600c60
fct: myvar addr=0x7fb62c758a90 __start___test=0x7fb62c758a90
fct2: myvar addr=0x7fb62c758a94 __start___test=0x7fb62c758a90
fct3: myvar addr=0x600c64 __start___test=0x600c60

Thanks,

Mathieu

> 
>> 
>> Thanks,
>> 
>> Mathieu
>> 
>> --
>> Mathieu Desnoyers
>> EfficiOS Inc.
> > http://www.efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com


yocto-hidden-bug2.tar.gz
Description: application/compressed-tar
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 04/11] pth: Delete

[Burton, Ross]

On 25 January 2016 at 18:32, Khem Raj  wrote:

> replacement in npth is available in OE-core
>

This breaks anyone using core-image-lsb because that pulls in pth
explicitly.

I can't see any mention of pth in the LSB specification so it could be that
it can just be removed.  Or maybe it should be replaced with npth.  Does
anyone have any opinions here?

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

Re: [OE-core] [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image

[Ming Liu]

On 01/22/2016 09:39 PM, Bruce Ashfield wrote:

On 16-01-20 6:29 PM, Ming Liu wrote:



On 01/20/2016 05:43 AM, Bruce Ashfield wrote:

On 2016-01-19 4:57 PM, Ming Liu wrote:



On 01/19/2016 08:39 PM, Bruce Ashfield wrote:

On 16-01-05 08:12 AM, Ming Liu wrote:

From: Ming Liu 

It makes no sense to install a initramfs bundled kernel image since
do_package does not depend on do_bundle_initramfs at all,
otherwise, it
leads to a implicit kernel-image package depending on do_package run
before
or after do_bundle_initramfs.


Again. So why not just add the ordering in the task dependencies ?

If we add a intertask dependency like:
add bundle_initramfs before do_install after do_deploy do_package

Then it will somehow introduce a circular dependency as I described in
another mail.


I'm probably missing something, which just means we need to tweak
the commit log a bit more.

Maybe I should add some description in commit log about why I think we
could not introduce a intertask dependency as a fix.



That would be ideal, the more information the better.



The code you are removing is conditional, and is run after an
explicit kernel_do_compile is called, to rebuild the existing
kernel configuration with an embedded initramfs (via alternate 
initrd).

So outside of some ordering/parallel execution issues, I'm not seeing
it as broken.

Yes, I agree, it will not break the kernel re-compiling, the problem I
want to fix here is just that it does not provide a certain way 
that we

could add initramfs bundled kernel image into a rootfs.



Speaking of breaking. What happens to existing users of 
INITRAMFS_IMAGE?

Do their existing image types and bundling continue to work without
modification ?

That depends, the existing users always can find the INITRAMFS_IMAGE
bundled kernel in DEPLOY_DIR with or without my patches, it is not
broken. But if they want it installed in the rootfs, for some reasons,
they will have the problem, like in my company, we want to boot the
kernel from /boot/ on a USB disk, but it is not guaranteed we will get
the INITRAMFS_IMAGE bundled kernel there during the build.


Right. And if someone isn't doing any initramfs bundling, is there
any impact ? No variables to change, etc ?

Would not impact, no need to change any variables.



I'd suggest double checking meta-initramfs:

http://layers.openembedded.org/layerindex/branch/master/layer/meta-initramfs/ 




OK, I will do that and let you know the results.


And checking with Andrea to be sure that none of the existing use
cases are broken.

OK, I will check with Andrea after I finished the tests with 
meta-initramfs layer.


//Ming Liu

Bruce



//Ming Liu


Bruce


//Ming Liu


Bruce



Signed-off-by: Ming Liu 
---
  meta/classes/kernel.bbclass | 4 
  1 file changed, 4 deletions(-)

diff --git a/meta/classes/kernel.bbclass 
b/meta/classes/kernel.bbclass

index 4ce1611..d1ca614 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -179,10 +179,6 @@ do_bundle_initramfs () {
  kernel_do_compile
  mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
  mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
-# Update install area
-echo "There is kernel image bundled with initramfs:
${B}/${KERNEL_OUTPUT}.initramfs"
-install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs
${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
-echo "${B}/${KERNEL_OUTPUT}.initramfs"
  fi
  }














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

Re: [OE-core] Bogus openembedded gcc patch

[Khem Raj]

On Jan 26, 2016 2:59 PM, "Mathieu Desnoyers" 
wrote:
>
> - On Jan 26, 2016, at 11:28 AM, Khem Raj raj.k...@gmail.com wrote:
>
> >> On Jan 25, 2016, at 8:02 PM, Mathieu Desnoyers <
mathieu.desnoy...@efficios.com>
> >> wrote:
> >>
> >> Hi,
> >>
> >> We are noticing the presence of the following patch in various
> >> openembedded gcc versions:
> >>
> >> 0024-PR-target-32219.patch
> >>
> >> "From e0d15f4f8bf28c351b9215ca37f1caa24df0e1fd Mon Sep 17 00:00:00 2001
> >> From: Khem Raj 
> >> Date: Fri, 29 Mar 2013 09:18:54 +0400
> >> Subject: [PATCH 24/35] PR target/32219
> >>
> >> * varasm.c (default_binds_local_p_1): Weak data is not local.
> >>
> >> Signed-off-by: Bernhard Reutner-Fischer 
> >> Signed-off-by: Khem Raj 
> >>
> >> Upstream-Status: Backport"
> >>
> >> However, contrarily to its "Backport" status, that patch is
> >> not upstream in gcc, and we're starting to wonder if this
> >> would be the patch that breaks handling of start/stop automatic
> >> hidden symbols we use in lttng-ust.
> >>
> >> We are only experiencing problems on the various openembedded
> >> compilers, but on no other distro (with same compiler versions),
> >> which leads us to suspect a buggy distro-specific gcc patch.
> >>
> >> We've been testing with openembedded gcc-4.9.2-r0.
> >>
> >> The original gold linker issue that this patch was trying to
> >> address seems to have been fixed in the gold linke since
> >> then.
> >>
> >> Refs:
> >> http://lists.lttng.org/pipermail/lttng-dev/2014-May/023112.html
> >> https://gcc.gnu.org/ml/gcc-help/2014-05/msg00042.html
> >>
http://cgit.openembedded.org/openembedded-core/commit/?id=3cb2b003db7371b3a47d02c08352a262e1e419b4
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=15435
> >>
> >> Thoughts ?
> >
> > OE has defaulted to gcc5 since last release, and gold issue is fixed in
binutils
> > 2.25
> > which is what we use in 2.0 as well so it might be OK to unbolt this
fix.
> > Although I am not sure
> > about the original problem reported in PR32219 is fixed for gcc 4.9 if
we remove
> > this fix.
> > Have you narrowed down your issue to this patch ? if not, then it would
be good
> > to do so
>
> Yes, we have narrowed down our problem to this specific patch by
> removing the patch from the OE gcc patches, rebuilding gcc, and
> then building our test program with that gcc. The problem goes
> away when we do so, which points directly to that patch as a
> culprit.
>
> Test program is attached.

Ok I think we can remove this from master and jethro release
>
> Faulty[gcc 4.9-r0 with patch 0024]:
>
> main: myvar addr=0x600c90 __start___test=0x600c90
> fct: myvar addr=0x7f8733d1eae8 __start___test=0x600c90
> fct2: myvar addr=0x7f8733d1eaec __start___test=0x600c90
> fct3: myvar addr=0x600c94 __start___test=0x600c90
>
> Valid[gcc 4.9-r0 without patch 0024]:
>
> main: myvar addr=0x600c60 __start___test=0x600c60
> fct: myvar addr=0x7fb62c758a90 __start___test=0x7fb62c758a90
> fct2: myvar addr=0x7fb62c758a94 __start___test=0x7fb62c758a90
> fct3: myvar addr=0x600c64 __start___test=0x600c60
>
> Thanks,
>
> Mathieu
>
> >
> >>
> >> Thanks,
> >>
> >> Mathieu
> >>
> >> --
> >> Mathieu Desnoyers
> >> EfficiOS Inc.
> > > http://www.efficios.com
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image

[Andrea Adami]

On Tue, Jan 26, 2016 at 11:12 PM, Ming Liu  wrote:
>
>
> On 01/22/2016 09:39 PM, Bruce Ashfield wrote:
>>
>> On 16-01-20 6:29 PM, Ming Liu wrote:
>>>
>>>
>>>
>>> On 01/20/2016 05:43 AM, Bruce Ashfield wrote:

 On 2016-01-19 4:57 PM, Ming Liu wrote:
>
>
>
> On 01/19/2016 08:39 PM, Bruce Ashfield wrote:
>>
>> On 16-01-05 08:12 AM, Ming Liu wrote:
>>>
>>> From: Ming Liu 
>>>
>>> It makes no sense to install a initramfs bundled kernel image since
>>> do_package does not depend on do_bundle_initramfs at all,
>>> otherwise, it
>>> leads to a implicit kernel-image package depending on do_package run
>>> before
>>> or after do_bundle_initramfs.
>>
>>
>> Again. So why not just add the ordering in the task dependencies ?
>
> If we add a intertask dependency like:
> add bundle_initramfs before do_install after do_deploy do_package
>
> Then it will somehow introduce a circular dependency as I described in
> another mail.
>>
>>
>> I'm probably missing something, which just means we need to tweak
>> the commit log a bit more.
>
> Maybe I should add some description in commit log about why I think we
> could not introduce a intertask dependency as a fix.
>

 That would be ideal, the more information the better.

>>
>> The code you are removing is conditional, and is run after an
>> explicit kernel_do_compile is called, to rebuild the existing
>> kernel configuration with an embedded initramfs (via alternate
>> initrd).
>> So outside of some ordering/parallel execution issues, I'm not seeing
>> it as broken.
>
> Yes, I agree, it will not break the kernel re-compiling, the problem I
> want to fix here is just that it does not provide a certain way that we
> could add initramfs bundled kernel image into a rootfs.
>

 Speaking of breaking. What happens to existing users of INITRAMFS_IMAGE?
 Do their existing image types and bundling continue to work without
 modification ?
>>>
>>> That depends, the existing users always can find the INITRAMFS_IMAGE
>>> bundled kernel in DEPLOY_DIR with or without my patches, it is not
>>> broken. But if they want it installed in the rootfs, for some reasons,
>>> they will have the problem, like in my company, we want to boot the
>>> kernel from /boot/ on a USB disk, but it is not guaranteed we will get
>>> the INITRAMFS_IMAGE bundled kernel there during the build.
>>
>>
>> Right. And if someone isn't doing any initramfs bundling, is there
>> any impact ? No variables to change, etc ?
>
> Would not impact, no need to change any variables.
>
>>
>> I'd suggest double checking meta-initramfs:
>>
>>
>> http://layers.openembedded.org/layerindex/branch/master/layer/meta-initramfs/
>>
> OK, I will do that and let you know the results.
>
>> And checking with Andrea to be sure that none of the existing use
>> cases are broken.
>>
> OK, I will check with Andrea after I finished the tests with meta-initramfs
> layer.
>
>
> //Ming Liu
>>
>> Bruce
>>
>>>
>>> //Ming Liu


 Bruce

> //Ming Liu
>>
>>
>> Bruce
>>
>>>
>>> Signed-off-by: Ming Liu 
>>> ---
>>>   meta/classes/kernel.bbclass | 4 
>>>   1 file changed, 4 deletions(-)
>>>
>>> diff --git a/meta/classes/kernel.bbclass
>>> b/meta/classes/kernel.bbclass
>>> index 4ce1611..d1ca614 100644
>>> --- a/meta/classes/kernel.bbclass
>>> +++ b/meta/classes/kernel.bbclass
>>> @@ -179,10 +179,6 @@ do_bundle_initramfs () {
>>>   kernel_do_compile
>>>   mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
>>>   mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
>>> -# Update install area
>>> -echo "There is kernel image bundled with initramfs:
>>> ${B}/${KERNEL_OUTPUT}.initramfs"
>>> -install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs
>>> ${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
>>> -echo "${B}/${KERNEL_OUTPUT}.initramfs"
>>>   fi
>>>   }
>>>
>>>
>>
>

>>>
>>
>

Hi,

I could not yet test the proposed changes.
For a quick test please do build initramfs-kexecboot-klibc-image for qemu.
Thanks

Andrea

P.S. We did restore the old documentation about plain embedded
initramfs, pls have a look at the (outdated) msg:
https://github.com/kexecboot/kexecboot/wiki/oe-yocto
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libtirpc: remove stray .orig file from Use-netbsd-queue.h.patch

[Andre McCurdy]

The file 'src/clnt_bcast.c.orig' seems to have been accidentally
included when the Use-netbsd-queue.h.patch patch was created.

Signed-off-by: Andre McCurdy 
---
 .../libtirpc/libtirpc/Use-netbsd-queue.h.patch | 701 -
 1 file changed, 701 deletions(-)

diff --git a/meta/recipes-extended/libtirpc/libtirpc/Use-netbsd-queue.h.patch 
b/meta/recipes-extended/libtirpc/libtirpc/Use-netbsd-queue.h.patch
index 21c6c53..f93223f 100644
--- a/meta/recipes-extended/libtirpc/libtirpc/Use-netbsd-queue.h.patch
+++ b/meta/recipes-extended/libtirpc/libtirpc/Use-netbsd-queue.h.patch
@@ -26,707 +26,6 @@ diff -Naur libtirpc-1.0.1-orig/src/clnt_bcast.c 
libtirpc-1.0.1/src/clnt_bcast.c
  #include "rpc_com.h"
  #include "debug.h"
  
-diff -Naur libtirpc-1.0.1-orig/src/clnt_bcast.c.orig 
libtirpc-1.0.1/src/clnt_bcast.c.orig
 libtirpc-1.0.1-orig/src/clnt_bcast.c.orig  1970-01-01 02:00:00.0 
+0200
-+++ libtirpc-1.0.1/src/clnt_bcast.c.orig   2015-10-30 17:15:14.0 
+0200
-@@ -0,0 +1,697 @@
-+/*
-+ * Copyright (c) 2009, Sun Microsystems, Inc.
-+ * All rights reserved.
-+ *
-+ * Redistribution and use in source and binary forms, with or without
-+ * modification, are permitted provided that the following conditions are met:
-+ * - Redistributions of source code must retain the above copyright notice,
-+ *   this list of conditions and the following disclaimer.
-+ * - Redistributions in binary form must reproduce the above copyright notice,
-+ *   this list of conditions and the following disclaimer in the documentation
-+ *   and/or other materials provided with the distribution.
-+ * - Neither the name of Sun Microsystems, Inc. nor the names of its
-+ *   contributors may be used to endorse or promote products derived
-+ *   from this software without specific prior written permission.
-+ *
-+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
-+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
-+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
-+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
-+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
-+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
-+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
-+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-+ * POSSIBILITY OF SUCH DAMAGE.
-+ */
-+/*
-+ * Copyright (c) 1986-1991 by Sun Microsystems Inc. 
-+ */
-+
-+/*
-+ * clnt_bcast.c
-+ * Client interface to broadcast service.
-+ *
-+ * Copyright (C) 1988, Sun Microsystems, Inc.
-+ *
-+ * The following is kludged-up support for simple rpc broadcasts.
-+ * Someday a large, complicated system will replace these routines.
-+ */
-+#include 
-+#include 
-+#include 
-+
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+#ifdef PORTMAP
-+#include 
-+#include 
-+#include 
-+#endif/* PORTMAP */
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+#include 
-+
-+#include "rpc_com.h"
-+#include "debug.h"
-+
-+#define   MAXBCAST 20 /* Max no of broadcasting transports */
-+#define   INITTIME 4000   /* Time to wait initially */
-+#define   WAITTIME 8000   /* Maximum time to wait */
-+
-+# define POLLRDNORM 0x040   /* Normal data may be read.  */
-+# define POLLRDBAND 0x080   /* Priority data may be read.  */
-+
-+
-+
-+/*
-+ * If nettype is NULL, it broadcasts on all the available
-+ * datagram_n transports. May potentially lead to broadacst storms
-+ * and hence should be used with caution, care and courage.
-+ *
-+ * The current parameter xdr packet size is limited by the max tsdu
-+ * size of the transport. If the max tsdu size of any transport is
-+ * smaller than the parameter xdr packet, then broadcast is not
-+ * sent on that transport.
-+ *
-+ * Also, the packet size should be less the packet size of
-+ * the data link layer (for ethernet it is 1400 bytes).  There is
-+ * no easy way to find out the max size of the data link layer and
-+ * we are assuming that the args would be smaller than that.
-+ *
-+ * The result size has to be smaller than the transport tsdu size.
-+ *
-+ * If PORTMAP has been defined, we send two packets for UDP, one for
-+ * rpcbind and one for portmap. For those machines which support
-+ * both rpcbind and portmap, it will cause them to reply twice, and
-+ * also here it will get two responses ... inefficient and clumsy.
-+ */
-+
-+#define   TAILQ_NEXT(elm, field)  ((elm)->field.tqe_next)
-+
-+#define   TAILQ_FIRST(head)   ((head)->tqh_first)
-+
-+
-+struct broadif {
-+  int index;
-+  struct 

[OE-core] [PATCH] libsoup-2.4: add glib-2.0-native dependency

[Andre McCurdy]

Building libsoup requires glib-mkenums.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-support/libsoup/libsoup-2.4_2.52.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.52.1.bb 
b/meta/recipes-support/libsoup/libsoup-2.4_2.52.1.bb
index 5e66197..9d95d0e 100644
--- a/meta/recipes-support/libsoup/libsoup-2.4_2.52.1.bb
+++ b/meta/recipes-support/libsoup/libsoup-2.4_2.52.1.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2"
 
 SECTION = "x11/gnome/libs"
 
-DEPENDS = "glib-2.0 gnutls libxml2 sqlite3 intltool-native"
+DEPENDS = "glib-2.0 glib-2.0-native gnutls libxml2 sqlite3 intltool-native"
 
 EXTRA_OECONF = "--disable-vala"
 
-- 
1.9.1

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

[OE-core] [PATCH 0/2] fix -Os compiler warnings in 1.7.1 gstreamer1.0 plugins

[Andre McCurdy]

Building with -Os generates a few compiler warnings, which
get treated as errors and cause build failures.

Andre McCurdy (2):
  gstreamer1.0-plugins-good: fix compiler warnings with -Os in 1.7.1
  gstreamer1.0-plugins-bad: fix compiler warnings with -Os in 1.7.1

 ...itialized-warnings-when-compiling-with-Os.patch | 28 +++
 .../gstreamer/gstreamer1.0-plugins-bad_git.bb  |  1 +
 ...itialized-warnings-when-compiling-with-Os.patch | 41 ++
 .../gstreamer/gstreamer1.0-plugins-good_git.bb |  1 +
 4 files changed, 71 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch

-- 
1.9.1

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

[OE-core] [PATCH 1/2] gstreamer1.0-plugins-good: fix compiler warnings with -Os in 1.7.1

[Andre McCurdy]

Signed-off-by: Andre McCurdy 
---
 ...itialized-warnings-when-compiling-with-Os.patch | 41 ++
 .../gstreamer/gstreamer1.0-plugins-good_git.bb |  1 +
 2 files changed, 42 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch
new file mode 100644
index 000..59addae
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch
@@ -0,0 +1,41 @@
+From 63a838d9ae2be480be8d28d6f51762d288b2a54a Mon Sep 17 00:00:00 2001
+From: Andre McCurdy 
+Date: Tue, 26 Jan 2016 14:47:36 -0800
+Subject: [PATCH] fix maybe-uninitialized warnings when compiling with -Os
+
+Upstream-Status: Pending
+
+Signed-off-by: Andre McCurdy 
+---
+ gst/isomp4/qtdemux.c| 1 +
+ gst/rtp/gstrtph261pay.c | 2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/gst/isomp4/qtdemux.c b/gst/isomp4/qtdemux.c
+index 77bb73e..1fc60ac 100644
+--- a/gst/isomp4/qtdemux.c
 b/gst/isomp4/qtdemux.c
+@@ -3269,6 +3269,7 @@ qtdemux_parse_cenc_aux_info (GstQTDemux * qtdemux, 
QtDemuxStream * stream,
+ gst_structure_set (properties, "iv", GST_TYPE_BUFFER, buf, NULL);
+ size = info_sizes[i];
+ if (size > iv_size) {
++  n_subsamples = 0;
+   if (!gst_byte_reader_get_uint16_be (br, _subsamples)
+   || !(n_subsamples > 0)) {
+ gst_structure_free (properties);
+diff --git a/gst/rtp/gstrtph261pay.c b/gst/rtp/gstrtph261pay.c
+index 7cdd323..ebcf80e 100644
+--- a/gst/rtp/gstrtph261pay.c
 b/gst/rtp/gstrtph261pay.c
+@@ -867,7 +867,7 @@ gst_rtp_h261_packetize_and_push (GstRtpH261Pay * pay, 
GstBuffer * buffer,
+   gst_rtp_buffer_calc_payload_len (GST_RTP_BASE_PAYLOAD_MTU (pay) -
+   GST_RTP_H261_PAYLOAD_HEADER_LEN, 0, 0);
+   guint startpos;
+-  gint num_gobs;
++  gint num_gobs = 0;
+   Gob gobs[MAX_NUM_GOB];
+   Gob *gob;
+   Macroblock last_mb_in_previous_packet = { 0 };
+-- 
+1.9.1
+
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_git.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_git.bb
index 88137ee..5f36f49 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_git.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_git.bb
@@ -9,6 +9,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
 SRC_URI = " \
 git://anongit.freedesktop.org/gstreamer/gst-plugins-good;name=base \
 
git://anongit.freedesktop.org/gstreamer/common;destsuffix=git/common;name=common
 \
+file://fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch \
 "
 
 PV = "1.7.1+git${SRCPV}"
-- 
1.9.1

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

[OE-core] [PATCH 2/2] gstreamer1.0-plugins-bad: fix compiler warnings with -Os in 1.7.1

[Andre McCurdy]

Signed-off-by: Andre McCurdy 
---
 ...itialized-warnings-when-compiling-with-Os.patch | 28 ++
 .../gstreamer/gstreamer1.0-plugins-bad_git.bb  |  1 +
 2 files changed, 29 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch
new file mode 100644
index 000..5ce5771
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch
@@ -0,0 +1,28 @@
+From a67781000e82bd9ae3813da29401e8c0c852328a Mon Sep 17 00:00:00 2001
+From: Andre McCurdy 
+Date: Tue, 26 Jan 2016 15:16:01 -0800
+Subject: [PATCH] fix maybe-uninitialized warnings when compiling with -Os
+
+Upstream-Status: Pending
+
+Signed-off-by: Andre McCurdy 
+---
+ gst-libs/gst/codecparsers/gstvc1parser.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gst-libs/gst/codecparsers/gstvc1parser.c 
b/gst-libs/gst/codecparsers/gstvc1parser.c
+index fd16ee0..ddb890c 100644
+--- a/gst-libs/gst/codecparsers/gstvc1parser.c
 b/gst-libs/gst/codecparsers/gstvc1parser.c
+@@ -1729,7 +1729,7 @@ gst_vc1_parse_sequence_layer (const guint8 * data, gsize 
size,
+ GstVC1SeqLayer * seqlayer)
+ {
+   guint32 tmp;
+-  guint8 tmp8;
++  guint8 tmp8 = 0;
+   guint8 structA[8] = { 0, };
+   guint8 structB[12] = { 0, };
+   GstBitReader br;
+-- 
+1.9.1
+
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
index ebf579f..99690a3 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
@@ -11,6 +11,7 @@ SRC_URI = " \
 git://anongit.freedesktop.org/gstreamer/gst-plugins-bad;name=base \
 
git://anongit.freedesktop.org/gstreamer/common;destsuffix=git/common;name=common
 \
 file://configure-allow-to-disable-libssh2.patch \
+file://fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch \
 "
 
 PV = "1.7.1+git${SRCPV}"
-- 
1.9.1

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

Re: [OE-core] [oe] [RFT] Glibc 2.23 and binutils 2.26

[ChenQi]

On 01/17/2016 07:54 PM, Khem Raj wrote:

Hi all

upstream glibc and binutils release branches have been cut out and are being 
made ready for next release
I have put together update patchset for both of them

here are the branches

https://github.com/kraj/openembedded-core/tree/kraj/binutils-2.26
https://github.com/kraj/openembedded-core/tree/kraj/glibc-2.23

FYI These are still using autorev to ensure that we test tip of release branches

Please give them a shot in your environments and report any issues you 
encounter.

Thanks for help

-Khem







0001-Generate-relocatable-SDKs.patch is included in SRC_URI twice, which 
causes the following error when building binutils-crosssdk-XXX.


ERROR: Command Error: exit status: 1  Output:
Patch 0001-Generate-relocatable-SDKs.patch is already applied; check 
your series file

ERROR: Function failed: patch_do_patch

binutils-2.26.inc and binutils-crosssdk_2.26.bb both has this patch in 
its SRC_RUI.


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

[OE-core] [PATCH] meta: fix capitalisation in Upstream-Status

[Ross Burton]

Signed-off-by: Ross Burton 
---
 .../dhcp/define-macro-_PATH_DHCPD_CONF-and-_PATH_DHCLIENT_CON.patch | 2 +-
 .../glibc/0010-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch | 2 +-
 meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch   | 2 +-
 meta/recipes-kernel/oprofile/oprofile/root-home-dir.patch   | 2 +-
 meta/recipes-support/apr/apr/upgrade-and-fix-1.5.1.patch| 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/meta/recipes-connectivity/dhcp/dhcp/define-macro-_PATH_DHCPD_CONF-and-_PATH_DHCLIENT_CON.patch
 
b/meta/recipes-connectivity/dhcp/dhcp/define-macro-_PATH_DHCPD_CONF-and-_PATH_DHCLIENT_CON.patch
index 12d3c9b..32bdaf0 100644
--- 
a/meta/recipes-connectivity/dhcp/dhcp/define-macro-_PATH_DHCPD_CONF-and-_PATH_DHCLIENT_CON.patch
+++ 
b/meta/recipes-connectivity/dhcp/dhcp/define-macro-_PATH_DHCPD_CONF-and-_PATH_DHCLIENT_CON.patch
@@ -1,6 +1,6 @@
 define macro _PATH_DHCPD_CONF and _PATH_DHCLIENT_CONF
 
-Upstream-Status: inappropriate 
+Upstream-Status: Inappropriate [OE specific]
 
 Signed-off-by: Hongxu Jia 
 ---
diff --git 
a/meta/recipes-core/glibc/glibc/0010-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch
 
b/meta/recipes-core/glibc/glibc/0010-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch
index d71e576..df3c1ef 100644
--- 
a/meta/recipes-core/glibc/glibc/0010-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch
+++ 
b/meta/recipes-core/glibc/glibc/0010-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch
@@ -10,7 +10,7 @@ 
${S}/.pc/aarch64-0001-glibc-fsf-v1-eaf6f205.patch/ports/sysdeps/
 aarch64/libm-test-ulps), run libm-err-tab.pl with specific dirs
 in ${S}.
 
-Upstream-Status: inappropriate [OE specific]
+Upstream-Status: Inappropriate [OE specific]
 
 Signed-off-by: Ting Liu 
 ---
diff --git 
a/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch 
b/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
index be27341..5b5de07 100644
--- a/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
+++ b/meta/recipes-devtools/tcltk/tcl/fix_issue_with_old_distro_glibc.patch
@@ -1,4 +1,4 @@
-Upstream-Status: inappropriate [embedded specific]
+Upstream-Status: Inappropriate [embedded specific]
 
 Fixes tcl target recipe build on old distros which have glibc older than 2.14
 
diff --git a/meta/recipes-kernel/oprofile/oprofile/root-home-dir.patch 
b/meta/recipes-kernel/oprofile/oprofile/root-home-dir.patch
index 20fc5e5..3eaf6a7 100644
--- a/meta/recipes-kernel/oprofile/oprofile/root-home-dir.patch
+++ b/meta/recipes-kernel/oprofile/oprofile/root-home-dir.patch
@@ -8,7 +8,7 @@ The commit replaces an earlier fix that detected and adjusted a
 patch is that the oprofile tools are adjusted to the current run-time
 path to ~root, not the build time path.
 
-Upstream-Status: inappropriate [OE specific]
+Upstream-Status: Inappropriate [OE specific]
 
 Signed-off-by: Dave Lerner 
 
diff --git a/meta/recipes-support/apr/apr/upgrade-and-fix-1.5.1.patch 
b/meta/recipes-support/apr/apr/upgrade-and-fix-1.5.1.patch
index 9569645..16499f5 100644
--- a/meta/recipes-support/apr/apr/upgrade-and-fix-1.5.1.patch
+++ b/meta/recipes-support/apr/apr/upgrade-and-fix-1.5.1.patch
@@ -8,7 +8,7 @@ Remove the 'tools' dir creation, it always existed.
 And it caused gen_test_char unexpected rebuilt at
 do_install time.
 
-Upstream-Status: inappropriate [oe specific]
+Upstream-Status: Inappropriate [oe specific]
 
 Signed-off-by: Hongxu Jia 
 ---
-- 
2.6.4

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

Re: [OE-core] [PATCH 1/1] gcc: libgcc-common.inc: symlink gthr-posix -> gthr-default.h

[Ioan-Adrian Ratiu]

On Tue, 26 Jan 2016 12:20:43 +
"Burton, Ross"  wrote:

> On 26 January 2016 at 11:25, Ioan-Adrian Ratiu  wrote:
> 
> > libgfortran needs gthr-default.h to exist (included by libgcc/gthr.h),
> > but for some reason it is not symlinked in configure as defined by
> > AC_CONFIG_LINKS. This patch creates it at the end of do_configure; thus
> > allowing libgfortran to build without erros.
> >
> 
> Are you sure?  libgfortran builds here and gthr-default.h is in the build
> tree:
> 
> In
> .../work/corei7-64-poky-linux/libgcc/5.3.0-r0/gcc-5.3.0/build.x86_64-poky-linux.x86_64-poky-linux/libgcc
> $ ls -l gthr-default.h
> lrwxrwxrwx 1 ross ross 76 Jan 25 16:20 gthr-default.h ->
> /data/poky-master/tmp/work-shared/gcc-5.3.0-r0/gcc-5.3.0/libgcc/gthr-posix.h
> 
> I'll note that libgfortran actually then errors out in package QA:
> 
> ERROR: QA Issue: libgfortran: Files/directories were installed but not
> shipped in any package:
>   /usr/lib/gcc/x86_64-poky-linux/5.3.0/finclude
>   /usr/lib/gcc/x86_64-poky-linux/5.3.0/finclude/ieee_features.mod
>   /usr/lib/gcc/x86_64-poky-linux/5.3.0/finclude/ieee_arithmetic.mod
>   /usr/lib/gcc/x86_64-poky-linux/5.3.0/finclude/ieee_exceptions.mod
> 
> If you actually use fortran would you be able to submit the right fix?  I'd
> guess at adding those to FILES_PN would be right, but that's a guess.

I'm using fortran to build a recipe for python-scipy on the fido branch. The 
header symlink is definitely not created in fido.
Also I'm not getting any QA errors; I don't see why the symlink gets created on 
master while not in fido.

I'll try to test more extensively on the master branch and then cherry-pick if 
there are any fixes there to fido.

Thanks,
Adrian

> 
> Ross

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

[OE-core] [PATCH] insane: remove unused variable assignment

[Ross Burton]

Signed-off-by: Ross Burton 
---
 meta/classes/insane.bbclass | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 79d59d6..500a37c 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -727,19 +727,17 @@ def package_qa_check_license(workdir, d):
 
 def package_qa_check_staged(path,d):
 """
-Check staged la and pc files for sanity
-  -e.g. installed being false
+Check staged la and pc files for common problems like references to the 
work
+directory.
 
-As this is run after every stage we should be able
-to find the one responsible for the errors easily even
-if we look at every .pc and .la file
+As this is run after every stage we should be able to find the one
+responsible for the errors easily even if we look at every .pc and .la 
file.
 """
 
 sane = True
 tmpdir = d.getVar('TMPDIR', True)
 workdir = os.path.join(tmpdir, "work")
 
-installed = "installed=yes"
 if bb.data.inherits_class("native", d) or bb.data.inherits_class("cross", 
d):
 pkgconfigcheck = workdir
 else:
-- 
2.6.4

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