Re: [OE-core] [oe] [yocto] OEDAM, April 8 in San Diego after ELC

[Philip Balister]

On 04/11/2016 09:35 PM, Denys Dmytriyenko wrote:
> On Mon, Apr 11, 2016 at 03:35:21PM -0700, Rudolf J Streif wrote:
>> Hello Everyone:
>>
>> If you attended OEDAM last Friday in San Diego, I very much hope that you 
>> enjoyed being here.
>>
>> The Catamaran Hotel, where we held the meeting, would very much appreciate 
>> your feedback:
>>
>> www.catamaranresort.com/trip
>>
>> I hope you all had a safe trip back home,
> 
> And huge thanks to Rudi and Jefro for their help in organizing the event!
> 

And an even bigger thanks to everyone that came to the meeting. You are
the people that make OpenEmbedded great!

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

Re: [OE-core] [oe] [yocto] OEDAM, April 8 in San Diego after ELC

[Denys Dmytriyenko]

On Mon, Apr 11, 2016 at 03:35:21PM -0700, Rudolf J Streif wrote:
> Hello Everyone:
> 
> If you attended OEDAM last Friday in San Diego, I very much hope that you 
> enjoyed being here.
> 
> The Catamaran Hotel, where we held the meeting, would very much appreciate 
> your feedback:
> 
> www.catamaranresort.com/trip
> 
> I hope you all had a safe trip back home,

And huge thanks to Rudi and Jefro for their help in organizing the event!

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

Re: [OE-core] [PATCH 1/1] pbzip2: fix for rebuild

[Robert Yang]

On 04/11/2016 10:48 PM, Burton, Ross wrote:


On 11 April 2016 at 15:46, Burton, Ross > wrote:

Wouldn't "oe_runmake clean" be simpler?


Or not disabling do_configure in the recipe, as base.bbclass's do_configure
includes an invocation to make clean.


Thanks, Andre McCurdy has sent the patch, thanks.

// Robert



Ross

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

Re: [OE-core] [PATCH 1/1] pbzip2: fix for rebuild

[Andre McCurdy]

On Mon, Apr 11, 2016 at 4:43 PM, Andre McCurdy  wrote:
> On Mon, Apr 11, 2016 at 7:48 AM, Burton, Ross  wrote:
>>
>> On 11 April 2016 at 15:46, Burton, Ross  wrote:
>>>
>>> Wouldn't "oe_runmake clean" be simpler?
>>
>> Or not disabling do_configure in the recipe, as base.bbclass's do_configure
>> includes an invocation to make clean.
>
> Since the bzip2 source files were changed, updating bzip2's PR (r5 ->
> r6) to force a full rebuild of pbzip2 might be a more robust solution?

To answer my own question, updating bzip2's PR doesn't help. It's the
pbzip2 recipe which needs fixing.

> More curious though is that after cleansstate, pbzip2-native doesn't
> build for me at all - the LIC_FILES_CHKSUM is wrong following the
> update from pbzip2 1.1.12 -> 1.1.13
>
>   
> http://git.openembedded.org/openembedded-core/commit/?id=80712b7c0959c197ccb21efd5e7a963d1d2e83ae
>
> ???
>
>> Ross
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] pbzip2: fix LIC_FILES_CHKSUM following 1.1.12 -> 1.1.13 upgrade

[Andre McCurdy]

The 1.1.3 update to COPYING changes a reference to pbzip2's version
number and release date. LIC_FILES_CHKSUM should have been updated
accordingly as part of the 1.1.12 -> 1.1.13 upgrade:

  
http://git.openembedded.org/openembedded-core/commit/?id=80712b7c0959c197ccb21efd5e7a963d1d2e83ae

Signed-off-by: Andre McCurdy 
---
 meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb 
b/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb
index b3c5975..77e70fc 100644
--- a/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb
+++ b/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb
@@ -6,7 +6,7 @@ newer (ie: anything compressed with pbzip2 can be decompressed 
with bzip2)."
 HOMEPAGE = "http://compression.ca/pbzip2/;
 SECTION = "console/utils"
 LICENSE = "BSD"
-LIC_FILES_CHKSUM = "file://COPYING;md5=4c4f2edec9679d5abef3514a816b54a4"
+LIC_FILES_CHKSUM = "file://COPYING;md5=398b8832c6f840cfebd20ab2be6a3743"
 
 DEPENDS = "bzip2"
 DEPENDS_append_class-native = " bzip2-replacement-native"
-- 
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] pbzip2: don't skip do_configure

[Andre McCurdy]

Although pbzip2 itself doesn't require any configuring, skipping
do_configure means the 'make clean' step performed by the default
base.bbclass do_configure is skipped too, which means that pbzip2
may not be rebuilt if something it depends on has changed (e.g. if
libbz2 has been modified).

Signed-off-by: Andre McCurdy 
---
 meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb 
b/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb
index 77e70fc..06d37ad 100644
--- a/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb
+++ b/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb
@@ -18,8 +18,6 @@ SRC_URI[sha256sum] = 
"8fd13eaaa266f7ee91f85c1ea97c86d9c9cc985969db9059cdebcb1e1b
 
 UPSTREAM_CHECK_URI = "http://compression.ca/pbzip2/;
 
-do_configure[noexec] = "1"
-
 EXTRA_OEMAKE = "CXX='${CXX} ${CXXFLAGS}' LDFLAGS='${LDFLAGS}'"
 
 do_install() {
-- 
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] pbzip2: fix rebuild issues

[Andre McCurdy]

Andre McCurdy (2):
  pbzip2: fix LIC_FILES_CHKSUM following 1.1.12 -> 1.1.13 upgrade
  pbzip2: don't skip do_configure

 meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

-- 
1.9.1

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

Re: [OE-core] [PATCH 1/1] pbzip2: fix for rebuild

[Andre McCurdy]

On Mon, Apr 11, 2016 at 7:48 AM, Burton, Ross  wrote:
>
> On 11 April 2016 at 15:46, Burton, Ross  wrote:
>>
>> Wouldn't "oe_runmake clean" be simpler?
>
> Or not disabling do_configure in the recipe, as base.bbclass's do_configure
> includes an invocation to make clean.

Since the bzip2 source files were changed, updating bzip2's PR (r5 ->
r6) to force a full rebuild of pbzip2 might be a more robust solution?

More curious though is that after cleansstate, pbzip2-native doesn't
build for me at all - the LIC_FILES_CHKSUM is wrong following the
update from pbzip2 1.1.12 -> 1.1.13

  
http://git.openembedded.org/openembedded-core/commit/?id=80712b7c0959c197ccb21efd5e7a963d1d2e83ae

???


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

Re: [OE-core] [oe] [yocto] OEDAM, April 8 in San Diego after ELC

[Rudolf J Streif]

Hello Everyone:

If you attended OEDAM last Friday in San Diego, I very much hope that you 
enjoyed being here.

The Catamaran Hotel, where we held the meeting, would very much appreciate your 
feedback:

www.catamaranresort.com/trip

I hope you all had a safe trip back home,
Rudi


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

[OE-core] [meta][patch] gcc-common.inc: String format tweak for available tunes

[noel eck]

Small change to python string formatting for error logging.
Previously, tune and availtunes would print out at the end of
the log message.  This change allows them to print out in the
correct locations of the error string.

Signed-off-by: noel eck 
---
 meta/recipes-devtools/gcc/gcc-common.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/gcc-common.inc 
b/meta/recipes-devtools/gcc/gcc-common.inc
index 6f2f224..e4fd4d6 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -54,7 +54,7 @@ def get_gcc_multiarch_setting(bb, d):
 def get_tune_parameters(tune, d):
 availtunes = d.getVar('AVAILTUNES', True)
 if tune not in availtunes.split():
-bb.error('The tune: %s is not one of the available tunes: %s', tune or 
None, availtunes)
+bb.error('The tune: %s is not one of the available tunes: %s' % (tune 
or None, availtunes))
 
 localdata = bb.data.createCopy(d)
 override = ':tune-' + tune
-- 
2.5.0

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

[OE-core] [PATCH] util-linux: take ownership of hwclock if installed

[Ross Burton]

Previously util-linux had a lower priority for hwclock than busybox but the
reasoning was lost in the mists of time, with just this enigmatic comment
remaining:

There seems to be problem, atleast on nslu2, with these, until they are
fixed the busybox ones have higher priority.

Chasing the comment back through history it first appeared in the following
oe-classic commit:

commit 5e01906b8433bc6a8c03be2e31758589641124c9
Author: David Karlstrom 
Date:   Sat Jul 23 13:36:38 2005 +

Updated to use update-alternatives and fix some FHS bugs

Which doesn't really give a lot away.

Let's assume that in the past eleven years both hwclock and hardware have
improved, and restore util-linux's hwclock to it's intended priority.

[ YOCTO #9103 ]

Signed-off-by: Ross Burton 
---
 meta/recipes-core/util-linux/util-linux.inc | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index c2a91e1..a1614c2 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -132,7 +132,7 @@ SYSTEMD_AUTO_ENABLE_${PN}-fstrim = "disable"
 
 do_compile () {
set -e
-   oe_runmake ARCH=${TARGET_ARCH} CPU= CPUOPT= 'OPT=${CFLAGS}' 
+   oe_runmake ARCH=${TARGET_ARCH} CPU= CPUOPT= 'OPT=${CFLAGS}'
 }
 
 do_install () {
@@ -220,9 +220,6 @@ ALTERNATIVE_LINK_NAME[fsck.8] = "${mandir}/man8/fsck.8"
 ALTERNATIVE_LINK_NAME[uuid.3] = "${mandir}/man3/uuid.3"
 
 ALTERNATIVE_util-linux-hwclock = "hwclock"
-# There seems to be problem, atleast on nslu2, with these, untill they are
-# fixed the busybox ones have higher priority
-ALTERNATIVE_PRIORITY[hwclock] = "10"
 ALTERNATIVE_LINK_NAME[hwclock] = "${base_sbindir}/hwclock"
 
 ALTERNATIVE_util-linux-fdisk = "fdisk"
-- 
2.8.0.rc3

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

Re: [OE-core] [PATCH 1/1] grub2: fix do_configure failure when largefile is not in DISTRO_FEATURES

[Burton, Ross]

On 8 April 2016 at 03:08, Khem Raj  wrote:

> We cache sizeof off_t with out considering lfs support thats the
> fundamental problem. We should probably stop doing that.
>
>
Thanks for reminding me, patch on the list shortly.

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

[OE-core] [PATCH 2/2] meta: remove redundant ac_cv_sizeof_off_t assignments

[Ross Burton]

ac_cv_sizeof_off_t was previously in the site cache files, which was breaking
large file support and required a workaround in each recipe that actually wanted
to use large files.

Now that the entry has been removed from the site cache, we can remove the
workarounds.

Signed-off-by: Ross Burton 
---
 meta/recipes-bsp/grub/grub-efi_2.00.bb   | 2 +-
 meta/recipes-bsp/grub/grub_2.00.bb   | 2 +-
 meta/recipes-bsp/grub/grub_git.bb| 2 +-
 meta/recipes-devtools/python/python.inc  | 2 --
 meta/recipes-devtools/python/python_2.7.11.bb| 3 +--
 meta/recipes-extended/pax/pax_3.4.bb | 4 
 meta/recipes-multimedia/libsndfile/libsndfile1_1.0.26.bb | 1 -
 meta/recipes-support/curl/curl_7.47.1.bb | 4 
 8 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-bsp/grub/grub-efi_2.00.bb 
b/meta/recipes-bsp/grub/grub-efi_2.00.bb
index dbc034c..5a0dc95 100644
--- a/meta/recipes-bsp/grub/grub-efi_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi_2.00.bb
@@ -33,7 +33,7 @@ EXTRA_OECONF = "--with-platform=efi --disable-grub-mkfont \
 --enable-efiemu=no --program-prefix='' \
 --enable-liblzma=no --enable-device-mapper=no 
--enable-libzfs=no"
 
-EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile', 
'--enable-largefile ac_cv_sizeof_off_t=8', '--disable-largefile', d)}"
+EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile', 
'--enable-largefile', '--disable-largefile', d)}"
 
 # ldm.c:114:7: error: trampoline generated for nested function 'hook' 
[-Werror=trampolines]
 # and many other places in the grub code when compiled with some native gcc 
compilers (specifically, gentoo)
diff --git a/meta/recipes-bsp/grub/grub_2.00.bb 
b/meta/recipes-bsp/grub/grub_2.00.bb
index addc1b2..778074a 100644
--- a/meta/recipes-bsp/grub/grub_2.00.bb
+++ b/meta/recipes-bsp/grub/grub_2.00.bb
@@ -6,7 +6,7 @@ PR = "r1"
 EXTRA_OECONF = "--with-platform=pc --disable-grub-mkfont --program-prefix="" \
--enable-liblzma=no --enable-device-mapper=no 
--enable-libzfs=no"
 
-EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile', 
'--enable-largefile ac_cv_sizeof_off_t=8', '--disable-largefile', d)}"
+EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile', 
'--enable-largefile', '--disable-largefile', d)}"
 
 do_install_append () {
 install -d ${D}${sysconfdir}/grub.d
diff --git a/meta/recipes-bsp/grub/grub_git.bb 
b/meta/recipes-bsp/grub/grub_git.bb
index 3ebab7f..6919c9a 100644
--- a/meta/recipes-bsp/grub/grub_git.bb
+++ b/meta/recipes-bsp/grub/grub_git.bb
@@ -31,7 +31,7 @@ GRUBPLATFORM ??= "pc"
 EXTRA_OECONF = "--with-platform=${GRUBPLATFORM} --disable-grub-mkfont 
--program-prefix="" \
 --enable-liblzma=no --enable-device-mapper=no 
--enable-libzfs=no"
 
-EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile', 
'--enable-largefile ac_cv_sizeof_off_t=8', '--disable-largefile', d)}"
+EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile', 
'--enable-largefile', '--disable-largefile', d)}"
 
 do_configure_prepend() {
 ( cd ${S}
diff --git a/meta/recipes-devtools/python/python.inc 
b/meta/recipes-devtools/python/python.inc
index 52250d2..f4818c6 100644
--- a/meta/recipes-devtools/python/python.inc
+++ b/meta/recipes-devtools/python/python.inc
@@ -20,8 +20,6 @@ PYTHON_MAJMIN = "2.7"
 
 inherit autotools
 
-PYTHONLSBOPTS_linuxstdbase = "ac_cv_sizeof_off_t=8"
-
 EXTRA_OECONF = "\
   --with-threads \
   --with-pymalloc \
diff --git a/meta/recipes-devtools/python/python_2.7.11.bb 
b/meta/recipes-devtools/python/python_2.7.11.bb
index 0c00d6e..606f153 100644
--- a/meta/recipes-devtools/python/python_2.7.11.bb
+++ b/meta/recipes-devtools/python/python_2.7.11.bb
@@ -35,8 +35,7 @@ inherit autotools multilib_header python-dir pythonnative
 
 CONFIGUREOPTS += " --with-system-ffi "
 
-# The following is a hack until we drop ac_cv_sizeof_off_t from site files
-EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile', 
'ac_cv_sizeof_off_t=8', '', d)} ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no"
+EXTRA_OECONF += "ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no"
 
 do_configure_append() {
rm -f ${S}/Makefile.orig
diff --git a/meta/recipes-extended/pax/pax_3.4.bb 
b/meta/recipes-extended/pax/pax_3.4.bb
index cee52e3..9d1abfb 100644
--- a/meta/recipes-extended/pax/pax_3.4.bb
+++ b/meta/recipes-extended/pax/pax_3.4.bb
@@ -25,8 +25,4 @@ SRC_URI_append_libc-musl = " 
file://0001-Fix-build-with-musl.patch \
 SRC_URI[md5sum] = "fbd9023b590b45ac3ade95870702a0d6"
 SRC_URI[sha256sum] = 
"ac3c06048e02828077cf7757d3d142241429238893b91d529af29a2e8cc5623b"
 
-# see https://lists.yoctoproject.org/pipermail/poky/2013-December/009435.html
-# We should ideally drop ac_cv_sizeof_off_t from site files but until then
-EXTRA_OECONF += 

[OE-core] [PATCH 1/2] meta/site: remove sizeof_off_t

[Ross Burton]

The size of off_t depends on whether large file support is enabled through
preprocessor flags, so we can't cache this.

Signed-off-by: Ross Burton 
---
 meta/site/arm-linux   | 1 -
 meta/site/ix86-common | 1 -
 meta/site/nios2-linux | 1 -
 meta/site/powerpc32-linux | 1 -
 meta/site/x32-linux   | 1 -
 meta/site/x86_64-linux| 1 -
 6 files changed, 6 deletions(-)

diff --git a/meta/site/arm-linux b/meta/site/arm-linux
index 14b1889..e6b9a72 100644
--- a/meta/site/arm-linux
+++ b/meta/site/arm-linux
@@ -10,7 +10,6 @@ ac_cv_sizeof_int_p=${ac_cv_sizeof_int_p=4}
 ac_cv_sizeof_long=${ac_cv_sizeof_long=4}
 ac_cv_sizeof_long_int=${ac_cv_sizeof_long_int=4}
 ac_cv_sizeof_long_long=${ac_cv_sizeof_long_long=8}
-ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=4}
 ac_cv_sizeof_short=${ac_cv_sizeof_short=2}
 ac_cv_sizeof_short_int=${ac_cv_sizeof_short_int=2}
 ac_cv_sizeof_size_t=${ac_cv_sizeof_size_t=4}
diff --git a/meta/site/ix86-common b/meta/site/ix86-common
index 135c305..23b8e8b 100644
--- a/meta/site/ix86-common
+++ b/meta/site/ix86-common
@@ -17,7 +17,6 @@ ac_cv_sizeof_ssize_t=${ac_cv_sizeof_ssize_t=4}
 ac_cv_sizeof_void_p=${ac_cv_sizeof_void_p=4}
 ac_cv_sizeof_long_p=${ac_cv_sizeof_long_p=4}
 ac_cv_sizeof_float=${ac_cv_sizeof_float=4}
-ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=4}
 ac_cv_sizeof_uid_t=${ac_cv_sizeof_uid_t=4}
 ac_cv_sizeof_gid_t=${ac_cv_sizeof_gid_t=4}
 ac_cv_sizeof_ino_t=${ac_cv_sizeof_ino_t=4}
diff --git a/meta/site/nios2-linux b/meta/site/nios2-linux
index 434f09b..95c09d3 100644
--- a/meta/site/nios2-linux
+++ b/meta/site/nios2-linux
@@ -241,7 +241,6 @@ ac_cv_sizeof_int_p=${ac_cv_sizeof_int_p=4}
 ac_cv_sizeof_long=${ac_cv_sizeof_long=4}
 ac_cv_sizeof_long_int=${ac_cv_sizeof_long_int=4}
 ac_cv_sizeof_long_long=${ac_cv_sizeof_long_long=8}
-ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=4}
 ac_cv_sizeof_short=${ac_cv_sizeof_short=2}
 ac_cv_sizeof_short_int=${ac_cv_sizeof_short_int=2}
 ac_cv_sizeof_size_t=${ac_cv_sizeof_size_t=4}
diff --git a/meta/site/powerpc32-linux b/meta/site/powerpc32-linux
index a7744fb..06d961f 100644
--- a/meta/site/powerpc32-linux
+++ b/meta/site/powerpc32-linux
@@ -203,7 +203,6 @@ apr_cv_pthreads_cflags=${apr_cv_pthreads_cflags=-pthread}
 apr_cv_pthreads_lib=${apr_cv_pthreads_lib=-lpthread}
 ac_cv_func_mmap=${ac_cv_func_mmap=yes}
 ac_cv_file__dev_zero=${ac_cv_file__dev_zero=yes}
-ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=4}
 ac_cv_sizeof_pid_t=${ac_cv_sizeof_pid_t=4}
 ac_cv_socklen_t=${ac_cv_socklen_t=yes}
 ac_cv_struct_rlimit=${ac_cv_struct_rlimit=yes}
diff --git a/meta/site/x32-linux b/meta/site/x32-linux
index 36ee68b..308d6e2 100644
--- a/meta/site/x32-linux
+++ b/meta/site/x32-linux
@@ -1,6 +1,5 @@
 # general
 ac_cv_sizeof_long_double=${ac_cv_sizeof_long_double=16}
-ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=8}
 ac_cv_sizeof_ino_t=${ac_cv_sizeof_ino_t=8}
 ac_cv_sizeof_dev_t=${ac_cv_sizeof_dev_t=8}
 ac_cv_sys_file_offset_bits=${ac_cv_sys_file_offset_bits=64}
diff --git a/meta/site/x86_64-linux b/meta/site/x86_64-linux
index 573a907..ebdcf69 100644
--- a/meta/site/x86_64-linux
+++ b/meta/site/x86_64-linux
@@ -18,7 +18,6 @@ ac_cv_sizeof_unsigned_long=${ac_cv_sizeof_unsigned_long=8}
 ac_cv_sizeof_long_double=${ac_cv_sizeof_long_double=16}
 ac_cv_sizeof_long_int=${ac_cv_sizeof_long_int=8}
 ac_cv_sizeof_long_long=${ac_cv_sizeof_long_long=8}
-ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=8}
 ac_cv_sizeof_short=${ac_cv_sizeof_short=2}
 ac_cv_sizeof_unsigned_short=${ac_cv_sizeof_unsigned_short=2}
 ac_cv_sizeof_short_int=${ac_cv_sizeof_short_int=2}
-- 
2.8.0.rc3

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

Re: [OE-core] [RFC PATCH 0/2] unique -dev package

[Burton, Ross]

On 11 April 2016 at 20:10, Denys Dmytriyenko  wrote:

> So, why -dbg cannot follow the example of -dev and -staticdev packages?
> I.e.
> in your ffmpeg example it would mean creating all the necessary libblah-dbg
> packages. Why isn't it the option?
>

To save time and effort the debug packaging happens automatically in modern
OE, so it's actually effort to split the debug files into multiple
packages.  If you split the packaging from PN-dbg to libfoo-dbg libbar-dbg,
where does the debug source go?  There's even more packages to follow the
dependencies for now too.

As much as I'd like to see 9104 disappear (being the assignee for it), I do
think that supporting a single -dbg package is the right thing to do.

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

[OE-core] [ANN] Yocto Explorer: command line tool to ease the manipulation of files inside Yocto Project based systems

[Otavio Salvador]

[ DISCLAIMER: I am posting this here as many people may find it
useful, I would like to apologize in advance for any inconvenience ]

ye[1] is a command line tool to ease the manipulation of files under
the directory structure adopted by O.S. Systems (using repo tool) to
organize projects that use the Yocto Project. ye provides means to
quickly locate files and directories into projects' directory tree,
and act on them.

1. http://code.ossystems.com.br/gitweb?p=apps/ye.git;a=summary
http://code.ossystems.com.br/p/apps/ye.git

I won't paste the full documentation about the tool as it would flood
people not intending to use it, however there is a fairly complete
documentation in our doc[2] server.

2. http://doc.ossystems.com.br/ye.html

Thanks in advance,

-- 
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] [RFC PATCH 0/2] unique -dev package

[Denys Dmytriyenko]

On Mon, Apr 11, 2016 at 04:12:06PM +0200, Gary Thomas wrote:
> On 2016-04-11 15:42, Denys Dmytriyenko wrote:
> >On Mon, Apr 11, 2016 at 09:35:48AM +0100, Richard Purdie wrote:
> >>On Sun, 2016-04-10 at 21:49 -0400, Denys Dmytriyenko wrote:
> >>>On Mon, Apr 11, 2016 at 09:19:32AM +0800, Robert Yang wrote:
> On 04/11/2016 06:51 AM, Denys Dmytriyenko wrote:
> >On Tue, Apr 07, 2015 at 05:58:13AM -0700, Robert Yang wrote:
> >>Hello,
> >>
> >>I think that one recipe should only have one -dev package, I'm
> >>not sure
> >>whether this is right or not, please feel free to give your
> >>comments, we
> >
> >I know it is already 1 year since this change. But I can't seem
> >to find any
> >discussion or any explanation to why this change was required and
> >what
> >specific problem it was supposed to fix. Please point me to a
> >clear reasoning
> >of this change. Thanks.
> 
> There is only one source package, so there should be only one pack
> of header
> files, dev libs, and so on, and they should be placed in a uniq
> pkg.
> >>>
> >>>Since you are using "should" twice in the same sentence, can you
> >>>please point
> >>>me to a ratified RFC?
> >>
> >>I couldn't seem to see the history of this discussion in my mail folder
> >>but I do remember some patches along these lines.
> >>
> >>The reason for a single -dev package is that the "package chain"
> >>functions we have assumes this. I know there are some specific cases
> >>where we do have multiple -dev packages (qt4, gcc-runtime) but they are
> >>very much in the minority and are special cases.
> >>
> >>I'm definitely on record as saying the depchains code needs revisiting
> >>and redoing, preferably with a structured rethink so that we can better
> >>handle situations like this. Until that is done, multiple -dev packages
> >>can cause issues and we did remove some where there didn't seem to be
> >>any real benefit.
> >>
> >>Which case is causing problems for you?
> >
> >Thanks, Richard.
> >
> >I was updating some of our old recipes to work with the latest code and had 
> >to
> >replace dependencies on libblah-dev to blah-dev as well as -staticdev and 
> >-dbg
> >in several places. When tried to dig up any relevant discussion on this 
> >matter
> >either as a discussion or clear explanation of the problem this causes, I
> >couldn't find any, hence my inquiry.
> >
> 
> You might have been thinking about my problems with -dbg packaging that
> currently breaks a number of dependencies.  Bug #9104

So, why -dbg cannot follow the example of -dev and -staticdev packages? I.e. 
in your ffmpeg example it would mean creating all the necessary libblah-dbg 
packages. Why isn't it the option?

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

[OE-core] [PATCH] oeqa/selftest/sstatetests: remove obsolete exclusion

[Ross Burton]

These changes have been fixed in oe-core now, so remove the workaround.

Signed-off-by: Ross Burton 
---
 meta/lib/oeqa/selftest/sstatetests.py | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/lib/oeqa/selftest/sstatetests.py 
b/meta/lib/oeqa/selftest/sstatetests.py
index d41b1d3..6a9ae9a 100644
--- a/meta/lib/oeqa/selftest/sstatetests.py
+++ b/meta/lib/oeqa/selftest/sstatetests.py
@@ -329,8 +329,6 @@ MACHINE = \"qemuarm\"
 f = {}
 for root, dirs, files in os.walk(d):
 for name in files:
-if "meta-environment" in root or "cross-canadian" in root:
-continue
 if "do_build" not in name:
 # 
1.4.1+gitAUTOINC+302fca9f4c-r0.do_package_write_ipk.sigdata.f3a2a38697da743f0dbed8b56aafcf79
 (_, task, _, shash) = name.rsplit(".", 3)
-- 
2.8.0.rc3

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

[OE-core] [PATCH] oeqa/selftest/sstatetests: split 32/64 build host from no-op action tests

[Ross Burton]

As more variables were being added it made sense to split this test into two:
one quick test that verifies that the host being 32-bit or 64-bit doesn't impact
the hashes, and another which compares stamps for two builds with several
variables changed and classes inherited.

Signed-off-by: Ross Burton 
---
 meta/lib/oeqa/selftest/sstatetests.py | 80 +--
 1 file changed, 68 insertions(+), 12 deletions(-)

diff --git a/meta/lib/oeqa/selftest/sstatetests.py 
b/meta/lib/oeqa/selftest/sstatetests.py
index c02d16d..d41b1d3 100644
--- a/meta/lib/oeqa/selftest/sstatetests.py
+++ b/meta/lib/oeqa/selftest/sstatetests.py
@@ -4,6 +4,7 @@ import os
 import re
 import shutil
 import glob
+import subprocess
 
 import oeqa.utils.ftools as ftools
 from oeqa.selftest.base import oeSelfTest
@@ -226,9 +227,6 @@ class SStateTests(SStateBase):
 they're built on a 32 or 64 bit system. Rather than requiring two 
different
 build machines and running a builds, override the variables calling 
uname()
 manually and check using bitbake -S.
-
-Also check that SDKMACHINE and PARALLEL_MAKE changing doesn't change 
any
-of these stamps.
 """
 
 topdir = get_bb_var('TOPDIR')
@@ -239,9 +237,6 @@ TMPDIR = "${TOPDIR}/tmp-sstatesamehash"
 BUILD_ARCH = "x86_64"
 BUILD_OS = "linux"
 SDKMACHINE = "x86_64"
-PARALLEL_MAKE = "-j 1"
-DL_DIR = "${TOPDIR}/download1"
-TIME = "11"
 """)
 self.track_for_cleanup(topdir + "/tmp-sstatesamehash")
 bitbake("core-image-sato -S none")
@@ -251,9 +246,6 @@ TMPDIR = "${TOPDIR}/tmp-sstatesamehash2"
 BUILD_ARCH = "i686"
 BUILD_OS = "linux"
 SDKMACHINE = "i686"
-PARALLEL_MAKE = "-j 2"
-DL_DIR = "${TOPDIR}/download2"
-TIME = "22"
 """)
 self.track_for_cleanup(topdir + "/tmp-sstatesamehash2")
 bitbake("core-image-sato -S none")
@@ -279,7 +271,7 @@ TIME = "22"
 def test_sstate_nativelsbstring_same_hash(self):
 """
 The sstate checksums should be independent of whichever 
NATIVELSBSTRING is
-detected. Rather than requiring two different build machines and 
running 
+detected. Rather than requiring two different build machines and 
running
 builds, override the variables manually and check using bitbake -S.
 """
 
@@ -311,7 +303,7 @@ NATIVELSBSTRING = \"DistroB\"
 @testcase(1368)
 def test_sstate_allarch_samesigs(self):
 """
-The sstate checksums of allarch packages should be independent of 
whichever 
+The sstate checksums of allarch packages should be independent of 
whichever
 MACHINE is set. Check this using bitbake -S.
 Also, rather than duplicate the test, check nativesdk stamps are the 
same between
 the two MACHINE values.
@@ -359,7 +351,7 @@ MACHINE = \"qemuarm\"
 @testcase(1369)
 def test_sstate_sametune_samesigs(self):
 """
-The sstate checksums of two identical machines (using the same tune) 
should be the 
+The sstate checksums of two identical machines (using the same tune) 
should be the
 same, apart from changes within the machine specific stamps directory. 
We use the
 qemux86copy machine to test this. Also include multilibs in the test.
 """
@@ -402,3 +394,67 @@ DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
 files2 = [x.replace("tmp-sstatesamehash2", "tmp-sstatesamehash") for x 
in files2]
 self.maxDiff = None
 self.assertItemsEqual(files1, files2)
+
+
+def test_sstate_noop_samesigs(self):
+"""
+The sstate checksums of two builds with these variables changed or
+classes inherits should be the same.
+"""
+
+topdir = get_bb_var('TOPDIR')
+targetvendor = get_bb_var('TARGET_VENDOR')
+self.write_config("""
+TMPDIR = "${TOPDIR}/tmp-sstatesamehash"
+BB_NUMBER_THREADS = "1"
+PARALLEL_MAKE = "-j 1"
+DL_DIR = "${TOPDIR}/download1"
+TIME = "11"
+DATE = "2016"
+""")
+self.track_for_cleanup(topdir + "/tmp-sstatesamehash")
+bitbake("world meta-toolchain -S none")
+self.write_config("""
+TMPDIR = "${TOPDIR}/tmp-sstatesamehash2"
+BB_NUMBER_THREADS = "2"
+PARALLEL_MAKE = "-j 2"
+DL_DIR = "${TOPDIR}/download2"
+TIME = "22"
+DATE = "20161212"
+INHERIT += "buildstats-summary buildhistory"
+""")
+self.track_for_cleanup(topdir + "/tmp-sstatesamehash2")
+bitbake("world meta-toolchain -S none")
+
+def get_files(d):
+f = {}
+for root, dirs, files in os.walk(d):
+for name in files:
+name, shash = name.rsplit('.', 1)
+# Extract just the machine and recipe name
+base = os.sep.join(root.rsplit(os.sep, 2)[-2:] + [name])
+f[base] = shash
+return f
+files1 = get_files(topdir + "/tmp-sstatesamehash/stamps/")
+files2 = get_files(topdir + 

Re: [OE-core] [PATCH] opkg-utils: re-do find/ls code to not fail on filenames with spaces

[Denys Dmytriyenko]

On Mon, Apr 11, 2016 at 11:13:42AM -0500, Alejandro del Castillo wrote:
> On 04/07/2016 11:57 PM, Denys Dmytriyenko wrote:
> > From: Denys Dmytriyenko 
> > 
> > Signed-off-by: Denys Dmytriyenko 
> > ---
> 
> do you mind posting the patch to the opkg-de...@googlegroups.com list too?

Sure, will do.

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

Re: [OE-core] [PATCH] opkg-utils: re-do find/ls code to not fail on filenames with spaces

[Burton, Ross]

On 8 April 2016 at 05:57, Denys Dmytriyenko  wrote:

> +From 8e424296ce2af4a5a7392c38a31f8723f9b9fbda Mon Sep 17 00:00:00 2001
> +From: Denys Dmytriyenko 
> +Date: Thu, 7 Apr 2016 20:43:13 -0400
> +Subject: [PATCH] opkg-build: re-do find/ls code to not fail on filenames
> with
> + spaces
> +
> +Signed-off-by: Denys Dmytriyenko 
>

Speaking of which, this is missing an Upstream-Status.

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

Re: [OE-core] [PATCH] opkg-utils: re-do find/ls code to not fail on filenames with spaces

[Alejandro del Castillo]

On 04/07/2016 11:57 PM, Denys Dmytriyenko wrote:
> From: Denys Dmytriyenko 
> 
> Signed-off-by: Denys Dmytriyenko 
> ---

do you mind posting the patch to the opkg-de...@googlegroups.com list too?

-- 
Cheers,

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

Re: [OE-core] [PATCH] oeqa/runexported.py: Fix exported test

[Aníbal Limón]

+ RP to integrate this patch before release 2.1

On 04/11/2016 10:13 AM, Aníbal Limón wrote:
> Also will be a good idea to add testing for this functionality to avoid
> future broke.
> 
> Mariano could you load the bug for this task?
> 
> Best regards,
>   alimon
> 
> On 04/11/2016 01:55 AM, mariano.lo...@linux.intel.com wrote:
>> From: Mariano Lopez 
>>
>> With the changes introduced to test the eSDK
>> the runexported test failed during the execution.
>>
>> This change fix runexported test in the least invasive
>> way, because of the release cycle.
>>
>> Signed-off-by: Mariano Lopez 
> Acked-by: Aníbal Limón 
> 
>> ---
>>  meta/lib/oeqa/oetest.py |  6 +-
>>  meta/lib/oeqa/runexported.py| 19 ++-
>>  meta/lib/oeqa/utils/commands.py |  6 +-
>>  3 files changed, 20 insertions(+), 11 deletions(-)
>>
>> diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
>> index fc1e8b5..8eb84ed 100644
>> --- a/meta/lib/oeqa/oetest.py
>> +++ b/meta/lib/oeqa/oetest.py
>> @@ -19,7 +19,11 @@ except ImportError:
>>  import logging
>>  
>>  import oeqa.runtime
>> -import oeqa.sdkext
>> +# Exported test doesn't require sdkext
>> +try:
>> +import oeqa.sdkext
>> +except ImportError:
>> +pass
>>  from oeqa.utils.decorators import LogResults, gettag, getResults
>>  from oeqa.utils import avoid_paths_in_environ
>>  
>> diff --git a/meta/lib/oeqa/runexported.py b/meta/lib/oeqa/runexported.py
>> index e9a2912..cc89e13 100755
>> --- a/meta/lib/oeqa/runexported.py
>> +++ b/meta/lib/oeqa/runexported.py
>> @@ -30,7 +30,7 @@ except ImportError:
>>  
>>  sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), 
>> "oeqa")))
>>  
>> -from oeqa.oetest import runTests
>> +from oeqa.oetest import TestContext
>>  from oeqa.utils.sshcontrol import SSHControl
>>  from oeqa.utils.dump import get_host_dumper
>>  
>> @@ -49,7 +49,7 @@ class FakeTarget(object):
>>  def exportStart(self):
>>  self.sshlog = os.path.join(self.testdir, "ssh_target_log.%s" % 
>> self.datetime)
>>  sshloglink = os.path.join(self.testdir, "ssh_target_log")
>> -if os.path.exists(sshloglink):
>> +if os.path.lexists(sshloglink):
>>  os.remove(sshloglink)
>>  os.symlink(self.sshlog, sshloglink)
>>  print("SSH log file: %s" %  self.sshlog)
>> @@ -69,10 +69,9 @@ class MyDataDict(dict):
>>  def getVar(self, key, unused = None):
>>  return self.get(key, "")
>>  
>> -class TestContext(object):
>> -def __init__(self):
>> -self.d = None
>> -self.target = None
>> +class ExportTestContext(TestContext):
>> +def __init__(self, d):
>> +self.d = d
>>  
>>  def main():
>>  
>> @@ -121,7 +120,9 @@ def main():
>>  host_dumper.parent_dir = loaded["host_dumper"]["parent_dir"]
>>  host_dumper.cmds = loaded["host_dumper"]["cmds"]
>>  
>> -tc = TestContext()
>> +target.exportStart()
>> +tc = ExportTestContext(d)
>> +
>>  setattr(tc, "d", d)
>>  setattr(tc, "target", target)
>>  setattr(tc, "host_dumper", host_dumper)
>> @@ -129,8 +130,8 @@ def main():
>>  if key != "d" and key != "target" and key != "host_dumper":
>>  setattr(tc, key, loaded[key])
>>  
>> -target.exportStart()
>> -runTests(tc)
>> +tc.loadTests()
>> +tc.runTests()
>>  
>>  return 0
>>  
>> diff --git a/meta/lib/oeqa/utils/commands.py 
>> b/meta/lib/oeqa/utils/commands.py
>> index 32e001c..48f6441 100644
>> --- a/meta/lib/oeqa/utils/commands.py
>> +++ b/meta/lib/oeqa/utils/commands.py
>> @@ -18,7 +18,11 @@ from oeqa.utils import CommandError
>>  from oeqa.utils import ftools
>>  import re
>>  import contextlib
>> -import bb
>> +# Export test doesn't require bb
>> +try:
>> +import bb
>> +except ImportError:
>> +pass
>>  
>>  class Command(object):
>>  def __init__(self, command, bg=False, timeout=None, data=None, 
>> **options):
>>
> 
> 
> 



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] oeqa/runexported.py: Fix exported test

[Aníbal Limón]

Also will be a good idea to add testing for this functionality to avoid
future broke.

Mariano could you load the bug for this task?

Best regards,
alimon

On 04/11/2016 01:55 AM, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez 
> 
> With the changes introduced to test the eSDK
> the runexported test failed during the execution.
> 
> This change fix runexported test in the least invasive
> way, because of the release cycle.
> 
> Signed-off-by: Mariano Lopez 
Acked-by: Aníbal Limón 

> ---
>  meta/lib/oeqa/oetest.py |  6 +-
>  meta/lib/oeqa/runexported.py| 19 ++-
>  meta/lib/oeqa/utils/commands.py |  6 +-
>  3 files changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
> index fc1e8b5..8eb84ed 100644
> --- a/meta/lib/oeqa/oetest.py
> +++ b/meta/lib/oeqa/oetest.py
> @@ -19,7 +19,11 @@ except ImportError:
>  import logging
>  
>  import oeqa.runtime
> -import oeqa.sdkext
> +# Exported test doesn't require sdkext
> +try:
> +import oeqa.sdkext
> +except ImportError:
> +pass
>  from oeqa.utils.decorators import LogResults, gettag, getResults
>  from oeqa.utils import avoid_paths_in_environ
>  
> diff --git a/meta/lib/oeqa/runexported.py b/meta/lib/oeqa/runexported.py
> index e9a2912..cc89e13 100755
> --- a/meta/lib/oeqa/runexported.py
> +++ b/meta/lib/oeqa/runexported.py
> @@ -30,7 +30,7 @@ except ImportError:
>  
>  sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), 
> "oeqa")))
>  
> -from oeqa.oetest import runTests
> +from oeqa.oetest import TestContext
>  from oeqa.utils.sshcontrol import SSHControl
>  from oeqa.utils.dump import get_host_dumper
>  
> @@ -49,7 +49,7 @@ class FakeTarget(object):
>  def exportStart(self):
>  self.sshlog = os.path.join(self.testdir, "ssh_target_log.%s" % 
> self.datetime)
>  sshloglink = os.path.join(self.testdir, "ssh_target_log")
> -if os.path.exists(sshloglink):
> +if os.path.lexists(sshloglink):
>  os.remove(sshloglink)
>  os.symlink(self.sshlog, sshloglink)
>  print("SSH log file: %s" %  self.sshlog)
> @@ -69,10 +69,9 @@ class MyDataDict(dict):
>  def getVar(self, key, unused = None):
>  return self.get(key, "")
>  
> -class TestContext(object):
> -def __init__(self):
> -self.d = None
> -self.target = None
> +class ExportTestContext(TestContext):
> +def __init__(self, d):
> +self.d = d
>  
>  def main():
>  
> @@ -121,7 +120,9 @@ def main():
>  host_dumper.parent_dir = loaded["host_dumper"]["parent_dir"]
>  host_dumper.cmds = loaded["host_dumper"]["cmds"]
>  
> -tc = TestContext()
> +target.exportStart()
> +tc = ExportTestContext(d)
> +
>  setattr(tc, "d", d)
>  setattr(tc, "target", target)
>  setattr(tc, "host_dumper", host_dumper)
> @@ -129,8 +130,8 @@ def main():
>  if key != "d" and key != "target" and key != "host_dumper":
>  setattr(tc, key, loaded[key])
>  
> -target.exportStart()
> -runTests(tc)
> +tc.loadTests()
> +tc.runTests()
>  
>  return 0
>  
> diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
> index 32e001c..48f6441 100644
> --- a/meta/lib/oeqa/utils/commands.py
> +++ b/meta/lib/oeqa/utils/commands.py
> @@ -18,7 +18,11 @@ from oeqa.utils import CommandError
>  from oeqa.utils import ftools
>  import re
>  import contextlib
> -import bb
> +# Export test doesn't require bb
> +try:
> +import bb
> +except ImportError:
> +pass
>  
>  class Command(object):
>  def __init__(self, command, bg=False, timeout=None, data=None, 
> **options):
> 



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] oeqa/runexported.py: Fix exported test

[mariano . lopez]

From: Mariano Lopez 

With the changes introduced to test the eSDK
the runexported test failed during the execution.

This change fix runexported test in the least invasive
way, because of the release cycle.

Signed-off-by: Mariano Lopez 
---
 meta/lib/oeqa/oetest.py |  6 +-
 meta/lib/oeqa/runexported.py| 19 ++-
 meta/lib/oeqa/utils/commands.py |  6 +-
 3 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
index fc1e8b5..8eb84ed 100644
--- a/meta/lib/oeqa/oetest.py
+++ b/meta/lib/oeqa/oetest.py
@@ -19,7 +19,11 @@ except ImportError:
 import logging
 
 import oeqa.runtime
-import oeqa.sdkext
+# Exported test doesn't require sdkext
+try:
+import oeqa.sdkext
+except ImportError:
+pass
 from oeqa.utils.decorators import LogResults, gettag, getResults
 from oeqa.utils import avoid_paths_in_environ
 
diff --git a/meta/lib/oeqa/runexported.py b/meta/lib/oeqa/runexported.py
index e9a2912..cc89e13 100755
--- a/meta/lib/oeqa/runexported.py
+++ b/meta/lib/oeqa/runexported.py
@@ -30,7 +30,7 @@ except ImportError:
 
 sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), 
"oeqa")))
 
-from oeqa.oetest import runTests
+from oeqa.oetest import TestContext
 from oeqa.utils.sshcontrol import SSHControl
 from oeqa.utils.dump import get_host_dumper
 
@@ -49,7 +49,7 @@ class FakeTarget(object):
 def exportStart(self):
 self.sshlog = os.path.join(self.testdir, "ssh_target_log.%s" % 
self.datetime)
 sshloglink = os.path.join(self.testdir, "ssh_target_log")
-if os.path.exists(sshloglink):
+if os.path.lexists(sshloglink):
 os.remove(sshloglink)
 os.symlink(self.sshlog, sshloglink)
 print("SSH log file: %s" %  self.sshlog)
@@ -69,10 +69,9 @@ class MyDataDict(dict):
 def getVar(self, key, unused = None):
 return self.get(key, "")
 
-class TestContext(object):
-def __init__(self):
-self.d = None
-self.target = None
+class ExportTestContext(TestContext):
+def __init__(self, d):
+self.d = d
 
 def main():
 
@@ -121,7 +120,9 @@ def main():
 host_dumper.parent_dir = loaded["host_dumper"]["parent_dir"]
 host_dumper.cmds = loaded["host_dumper"]["cmds"]
 
-tc = TestContext()
+target.exportStart()
+tc = ExportTestContext(d)
+
 setattr(tc, "d", d)
 setattr(tc, "target", target)
 setattr(tc, "host_dumper", host_dumper)
@@ -129,8 +130,8 @@ def main():
 if key != "d" and key != "target" and key != "host_dumper":
 setattr(tc, key, loaded[key])
 
-target.exportStart()
-runTests(tc)
+tc.loadTests()
+tc.runTests()
 
 return 0
 
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index 32e001c..48f6441 100644
--- a/meta/lib/oeqa/utils/commands.py
+++ b/meta/lib/oeqa/utils/commands.py
@@ -18,7 +18,11 @@ from oeqa.utils import CommandError
 from oeqa.utils import ftools
 import re
 import contextlib
-import bb
+# Export test doesn't require bb
+try:
+import bb
+except ImportError:
+pass
 
 class Command(object):
 def __init__(self, command, bg=False, timeout=None, data=None, **options):
-- 
2.6.2

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

Re: [OE-core] [PATCH 1/1] pbzip2: fix for rebuild

[Burton, Ross]

On 8 April 2016 at 04:13, Robert Yang  wrote:

> +do_compile_prepend() {
> +# Update timestamp to fix rebuild
> +src_files="pbzip2.cpp BZ2StreamScanner.cpp ErrorContext.cpp"
> +for f in $src_files; do
> +if [ -f $f ]; then
> +touch $f
> +else
> +bbwarn "Regular file $f not found"
> +fi
> +done
>

Wouldn't "oe_runmake clean" be simpler?

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

Re: [OE-core] [PATCH 1/1] pbzip2: fix for rebuild

[Burton, Ross]

On 11 April 2016 at 15:46, Burton, Ross  wrote:

> Wouldn't "oe_runmake clean" be simpler?
>

Or not disabling do_configure in the recipe, as base.bbclass's do_configure
includes an invocation to make clean.

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

Re: [OE-core] [PATCH 00/14] [jethro] Consolidated pull

[akuster808]

On 04/11/2016 12:29 AM, Robert Yang wrote:
> The following changes since commit 4d879cb8d7384ac4a96f22c1664b8875f2d8f615:
> 
>   devtool: extract: update SRCTREECOVEREDTASKS for kernel (2016-03-20 
> 10:22:55 +)
> 
> are available in the git repository at:
> 
>   git://git.openembedded.org/openembedded-core-contrib rbt/jethro-next
>   
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/jethro-next

please cherry-pick the timezone updates too.

tdata:
d3ab7005f0c899da9f9f132b22861bd5d4f952ba
66031bcf8cec2e8e7a6803f2c6cfc2c2ba071ffe

and
tzcode:
0c4816c1f723951179988a274f236f28fe4db20f
41adb87c2f1aa20e51f1af3542d65c920eb94be6


> 
> Awais Belal (2):
>   systemd-serialgetty: allow baud rate overriding
>   lttng-tools: fix regression tests hang
> 
> Bill Randle (1):
>   systemd: fix segfault on shutdown
> 
> Brad Mouring (2):
>   busybox-1.23: Backport patch to fix zcip false-conflict
>   busybox_git: Fix SRCREV
> 
> Christopher Larson (1):
>   systemd: chown hwdb.bin to root:root for do_rootfs
> 
> Javier Viguera (1):
>   bluez5: allow D-Bus to spawn obexd in systems without systemd
> 
> Juro Bystricky (1):
>   python3: fix building nativesdk-python3
> 
> Khem Raj (1):
>   ruby-native: Depend on openssl-native
> 
> Li Xin (1):
>   gcc-cross-canadian.inc: add INSANE_SKIP_ to avoid build warning
> 
> Lukas Bulwahn (1):
>   boost: ensure boost to remain an empty metapackage
> 
> Ross Burton (2):
>   cdrtools: update SRC_URI
>   ncurses: update SRC_URI
> 
> Ulrich Ölmann (1):
>   nfs-utils: bugfix: adjust name of statd service unit
> 
>  meta/recipes-connectivity/bluez5/bluez5.inc|   1 +
>  ...-obexd-without-systemd-in-the-user-sessio.patch |  63 +++
>  .../files/bugfix-adjust-statd-service-name.patch   |  34 ++
>  .../nfs-utils/nfs-utils_1.3.1.bb   |   1 +
>  ...wrong-comparison-of-source-IP-with-our-IP.patch |  38 ++
>  meta/recipes-core/busybox/busybox_1.23.2.bb|   1 +
>  meta/recipes-core/busybox/busybox_git.bb   |   2 +-
>  meta/recipes-core/ncurses/ncurses_5.9.bb   |   6 +-
>  .../systemd-serialgetty/serial-getty@.service  |   2 +-
>  .../0023-backported-fixes-for-null-messages.patch  | 101 +
>  meta/recipes-core/systemd/systemd_225.bb   |   2 +
>  .../cdrtools/cdrtools-native_3.01a31.bb|   2 +-
>  meta/recipes-devtools/gcc/gcc-cross-canadian.inc   |   2 +
>  meta/recipes-devtools/python/python3_3.4.3.bb  |   1 +
>  meta/recipes-devtools/ruby/ruby.inc|   2 +-
>  .../lttng/lttng-tools/Fix-regression-tests.patch   | 480 
> +
>  meta/recipes-kernel/lttng/lttng-tools_2.6.0.bb |   1 +
>  meta/recipes-support/boost/boost.inc   |   1 +
>  18 files changed, 734 insertions(+), 6 deletions(-)
>  create mode 100644 
> meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
>  create mode 100644 
> meta/recipes-connectivity/nfs-utils/files/bugfix-adjust-statd-service-name.patch
>  create mode 100644 
> meta/recipes-core/busybox/busybox/0001-zcip-fix-wrong-comparison-of-source-IP-with-our-IP.patch
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0023-backported-fixes-for-null-messages.patch
>  create mode 100644 
> meta/recipes-kernel/lttng/lttng-tools/Fix-regression-tests.patch
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 0/2] unique -dev package

[Gary Thomas]

On 2016-04-11 15:42, Denys Dmytriyenko wrote:

On Mon, Apr 11, 2016 at 09:35:48AM +0100, Richard Purdie wrote:

On Sun, 2016-04-10 at 21:49 -0400, Denys Dmytriyenko wrote:

On Mon, Apr 11, 2016 at 09:19:32AM +0800, Robert Yang wrote:

On 04/11/2016 06:51 AM, Denys Dmytriyenko wrote:

On Tue, Apr 07, 2015 at 05:58:13AM -0700, Robert Yang wrote:

Hello,

I think that one recipe should only have one -dev package, I'm
not sure
whether this is right or not, please feel free to give your
comments, we


I know it is already 1 year since this change. But I can't seem
to find any
discussion or any explanation to why this change was required and
what
specific problem it was supposed to fix. Please point me to a
clear reasoning
of this change. Thanks.


There is only one source package, so there should be only one pack
of header
files, dev libs, and so on, and they should be placed in a uniq
pkg.


Since you are using "should" twice in the same sentence, can you
please point
me to a ratified RFC?


I couldn't seem to see the history of this discussion in my mail folder
but I do remember some patches along these lines.

The reason for a single -dev package is that the "package chain"
functions we have assumes this. I know there are some specific cases
where we do have multiple -dev packages (qt4, gcc-runtime) but they are
very much in the minority and are special cases.

I'm definitely on record as saying the depchains code needs revisiting
and redoing, preferably with a structured rethink so that we can better
handle situations like this. Until that is done, multiple -dev packages
can cause issues and we did remove some where there didn't seem to be
any real benefit.

Which case is causing problems for you?


Thanks, Richard.

I was updating some of our old recipes to work with the latest code and had to
replace dependencies on libblah-dev to blah-dev as well as -staticdev and -dbg
in several places. When tried to dig up any relevant discussion on this matter
either as a discussion or clear explanation of the problem this causes, I
couldn't find any, hence my inquiry.



You might have been thinking about my problems with -dbg packaging that
currently breaks a number of dependencies.  Bug #9104

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] glib-2.0: Put glib-compile-schemas back in -utils

[Gary Thomas]

On 2016-04-11 13:07, Jussi Kukkonen wrote:

Commit cc97d576 moved a bunch of development tools to the -dev
package. glib-compile-schemas is actually used in postinst by
gsettings.bbclass so it needs to be available on target at package
install time: Move the tool back to glib-2.0-utils which
gsettings.bbclass depends on.

Fixes [YOCTO #9431].

Signed-off-by: Jussi Kukkonen 


Looks like this fixes it, thanks.

Acked-by: Gary Thomas 


---

I also reviewed again the other tools that were moved in cc97d576:
this one seems like the only one that is needed at postinst.

Possibly glib-compile-schemas should be installed with the library
(like qio-querymodules now is) but I'd rather not do that at this
point in the release as it would mean other changes like moving
the binary install location.

This commit is also available in the git repository at:

   git://git.yoctoproject.org/poky-contrib jku/glib-compile-schemas


  meta/recipes-core/glib-2.0/glib.inc | 1 -
  1 file changed, 1 deletion(-)

diff --git a/meta/recipes-core/glib-2.0/glib.inc 
b/meta/recipes-core/glib-2.0/glib.inc
index 3a03191..e764fad 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -57,7 +57,6 @@ FILES_${PN}-dev += "${libdir}/glib-2.0/include \
  ${bindir}/glib-genmarshal \
  ${bindir}/glib-gettextize \
  ${bindir}/glib-mkenums \
-${bindir}/glib-compile-schemas \
  ${bindir}/glib-compile-resources \
  ${datadir}/glib-2.0/gettext/po/Makefile.in.in \
  ${datadir}/glib-2.0/schemas/gschema.dtd"




--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [RFC PATCH 0/2] unique -dev package

[Denys Dmytriyenko]

On Mon, Apr 11, 2016 at 09:35:48AM +0100, Richard Purdie wrote:
> On Sun, 2016-04-10 at 21:49 -0400, Denys Dmytriyenko wrote:
> > On Mon, Apr 11, 2016 at 09:19:32AM +0800, Robert Yang wrote:
> > > On 04/11/2016 06:51 AM, Denys Dmytriyenko wrote:
> > > > On Tue, Apr 07, 2015 at 05:58:13AM -0700, Robert Yang wrote:
> > > > > Hello,
> > > > > 
> > > > > I think that one recipe should only have one -dev package, I'm
> > > > > not sure
> > > > > whether this is right or not, please feel free to give your
> > > > > comments, we
> > > > 
> > > > I know it is already 1 year since this change. But I can't seem
> > > > to find any
> > > > discussion or any explanation to why this change was required and
> > > > what
> > > > specific problem it was supposed to fix. Please point me to a
> > > > clear reasoning
> > > > of this change. Thanks.
> > > 
> > > There is only one source package, so there should be only one pack
> > > of header
> > > files, dev libs, and so on, and they should be placed in a uniq
> > > pkg.
> > 
> > Since you are using "should" twice in the same sentence, can you
> > please point 
> > me to a ratified RFC?
> 
> I couldn't seem to see the history of this discussion in my mail folder
> but I do remember some patches along these lines.
> 
> The reason for a single -dev package is that the "package chain"
> functions we have assumes this. I know there are some specific cases
> where we do have multiple -dev packages (qt4, gcc-runtime) but they are
> very much in the minority and are special cases.
> 
> I'm definitely on record as saying the depchains code needs revisiting
> and redoing, preferably with a structured rethink so that we can better
> handle situations like this. Until that is done, multiple -dev packages
> can cause issues and we did remove some where there didn't seem to be
> any real benefit.
> 
> Which case is causing problems for you?

Thanks, Richard.

I was updating some of our old recipes to work with the latest code and had to 
replace dependencies on libblah-dev to blah-dev as well as -staticdev and -dbg 
in several places. When tried to dig up any relevant discussion on this matter 
either as a discussion or clear explanation of the problem this causes, I 
couldn't find any, hence my inquiry.

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

Re: [OE-core] [PATCH] build-appliance-image: Support for VirtualBox guest additions

[Otavio Salvador]

On Sat, Apr 9, 2016 at 5:11 PM, Juro Bystricky  wrote:
> Add support for VirtualBox guest additions.
> The additions are built inside the Build Appliance VM.
> For this to be possible, the environment for out-of-tree kernel module builds
> must be present and set up properly.
> A README file with detailed steps on how to build the guest additions is 
> placed
> in the home directory of the user "builder" as well.
> The main purpose of the guest additions is to allow sharing folders between
> the host and Build Appliance VM.
>
> [YOCTO #8073]
>
> Signed-off-by: Juro Bystricky 

We have guestadditions (without X driver) supported on meta-oe, why
not included this here and avoid all this manual work from the end
user?

-- 
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 1/1] base.bbclass: fix COMPATIBLE_MACHINE

[Denys Dmytriyenko]

> > Since introduced ? I did a grep in oe-core and meta-openembedded, it seems
> > that no ?
> 
> Not really sure what you are trying to say here... Are you arguing that it 
> was 
> never used as a regular expression? I beg to differ and I can provide 
> multiple 
> examples for that:
> 
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/nodejs/nodejs_4.4.1.bb#n8
> http://arago-project.org/git/?p=meta-arago.git;a=blob;f=meta-arago-distro/recipes-core/images/arago-console-image.bb;hb=HEAD#l6
> 
> It was like that for 15+ years, since OpenEmbedded Classic days...

Oops, that does sound more impressive, but I meant 10+ years - my math failed 
me that late at night... :)

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

Re: [OE-core] [PATCH 1/2] wic/utils/partitionedfs.py: assemble .wic images as sparse files

[Alexander Kanevskiy]

On Sat, Apr 9, 2016 at 7:41 PM, Philip Balister  wrote:

> > This might be dangerous. Even in recent version of DD (coreutils 8.25),
> it
> > might not detect in source file mapped/unmapped blocks properly,
> > (just use is_nul() function to check if block contains only zeros,
> instead
> > of e.g. fiemap).
> > Result might be so, that in output file block which must be zeros is
> > actually become unmapped. And as consequence, if it might not be written
> to
> > destination drive.
>
> Does it work with bmaptool?
>

bmaptool can work with practically any sparse file (even if bmap file are
not provided) to flash it efficiently on raw device.
However, with such cases like "dd conv=sparse" it should be used with extra
caution, as some of needed zeroed blocks might not be written to
destination device.

Yocto bug #9099 now has two patches attached that adding initial bmap-tools
support to OE-core.
Those patches allows to create bmap files for simpler cases, like .hddimg
as well as shipping standalone version of bmaptool in deploy/tools/*
It probably would be content of next release, as I don't think anyone would
be merging them now.

For assembling images with wic, it would require a bit more work.

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

[OE-core] [PATCH] glib-2.0: Put glib-compile-schemas back in -utils

[Jussi Kukkonen]

Commit cc97d576 moved a bunch of development tools to the -dev
package. glib-compile-schemas is actually used in postinst by
gsettings.bbclass so it needs to be available on target at package
install time: Move the tool back to glib-2.0-utils which
gsettings.bbclass depends on.

Fixes [YOCTO #9431].

Signed-off-by: Jussi Kukkonen 
---

I also reviewed again the other tools that were moved in cc97d576:
this one seems like the only one that is needed at postinst.

Possibly glib-compile-schemas should be installed with the library
(like qio-querymodules now is) but I'd rather not do that at this
point in the release as it would mean other changes like moving
the binary install location.

This commit is also available in the git repository at:

  git://git.yoctoproject.org/poky-contrib jku/glib-compile-schemas


 meta/recipes-core/glib-2.0/glib.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-core/glib-2.0/glib.inc 
b/meta/recipes-core/glib-2.0/glib.inc
index 3a03191..e764fad 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -57,7 +57,6 @@ FILES_${PN}-dev += "${libdir}/glib-2.0/include \
 ${bindir}/glib-genmarshal \
 ${bindir}/glib-gettextize \
 ${bindir}/glib-mkenums \
-${bindir}/glib-compile-schemas \
 ${bindir}/glib-compile-resources \
 ${datadir}/glib-2.0/gettext/po/Makefile.in.in \
 ${datadir}/glib-2.0/schemas/gschema.dtd"
-- 
2.1.4

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

Re: [OE-core] does a normal OE kernel build negate the ability to generate a local version string?

[Robert P. J. Day]

On Fri, 8 Apr 2016, Martin Jansa wrote:

> On Fri, Apr 08, 2016 at 09:57:02AM -0400, Robert P. J. Day wrote:
> >
> >   i was just playing with wind river linux 8 and trying to figure out
> > why i couldn't generate a local version string that contained the git
> > commit ID, so i zipped over to oe-core to see how it was done there,
> > and it seems to be the same way, so can someone clarify that my
> > understanding here is correct?
> >
> >   normally, if i want to add the git commit ID ("-g") to the
> > kernel version string so it's available via "uname", i'm used to
> > selecting the kernel config option CONFIG_LOCALVERSION_AUTO, which
> > uses:
> >
> >  $ git rev-parse --verify HEAD
> >
> > to extract the first 8 characters of the commit ID. so i selected that
> > option, but wasn't getting that string.
> >
> >   poking around further, i saw this in scripts/setlocalversion:
> >
> > scm_version()
> > {
> > local short
> > short=false
> >
> > cd "$srctree"
> > if test -e .scmversion; then
> > cat .scmversion
> > return
> > fi
> > ... snip ...
> >
> > so if the file ".scmversion" exists, its contents are used instead.
> > now *i* never set that file, but lo and behold, in the kernel source
> > tree, there it was, empty, which explains why i wasn't getting any
> > local version string.
> >
> >   and where did that empty .scmversion file come from? i see this in
> > kernel.bbclass:
> >
> > kernel_do_configure() {
> > # fixes extra + in /lib/modules/2.6.37+
> > # $ scripts/setlocalversion . => +
> > # $ make kernelversion => 2.6.37
> > # $ make kernelrelease => 2.6.37+
> > touch ${B}/.scmversion ${S}/.scmversion< there
> > ... snip ...
> >
> > which clearly appears to touch that empty file. is that deliberate? is
> > this an explicit decision by this bbclass file to prevent people from
> > generating that local version string? am i reading all this correctly?
>
> Yes, see
> http://lists.openembedded.org/pipermail/openembedded-core/2011-December/053263.html
> for more details

  hm ... that's disappointing as i could have used that feature. i
guess i can always tweak a recipe that removes those files.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [OE-core] [daisy][PATCH] eglibc: security fix CVE-2015-7547

[Khem Raj]

This is an important fix. Looks good to me
On Apr 6, 2016 5:35 AM, "Javier Viguera"  wrote:

> CVE-2015-7547: getaddrinfo() stack-based buffer overflow
>
> Backport patch from GLIBC-2.20 to EGLIBC-2.19.
>
> Signed-off-by: Javier Viguera 
> ---
>  .../eglibc/eglibc-2.19/CVE-2015-7547.patch | 585
> +
>  meta/recipes-core/eglibc/eglibc_2.19.bb|   1 +
>  2 files changed, 586 insertions(+)
>  create mode 100644
> meta/recipes-core/eglibc/eglibc-2.19/CVE-2015-7547.patch
>
> diff --git a/meta/recipes-core/eglibc/eglibc-2.19/CVE-2015-7547.patch
> b/meta/recipes-core/eglibc/eglibc-2.19/CVE-2015-7547.patch
> new file mode 100644
> index ..2a52e56cb7f4
> --- /dev/null
> +++ b/meta/recipes-core/eglibc/eglibc-2.19/CVE-2015-7547.patch
> @@ -0,0 +1,585 @@
> +From: Carlos O'Donell 
> +Date: Tue, 16 Feb 2016 21:26:37 -0500
> +Subject: [PATCH] CVE-2015-7547: getaddrinfo() stack-based buffer overflow
> (Bug
> + 18665).
> +
> +* A stack-based buffer overflow was found in libresolv when invoked from
> +  libnss_dns, allowing specially crafted DNS responses to seize control
> +  of execution flow in the DNS client.  The buffer overflow occurs in
> +  the functions send_dg (send datagram) and send_vc (send TCP) for the
> +  NSS module libnss_dns.so.2 when calling getaddrinfo with AF_UNSPEC
> +  family.  The use of AF_UNSPEC triggers the low-level resolver code to
> +  send out two parallel queries for A and .  A mismanagement of the
> +  buffers used for those queries could result in the response of a query
> +  writing beyond the alloca allocated buffer created by
> +  _nss_dns_gethostbyname4_r.  Buffer management is simplified to remove
> +  the overflow.  Thanks to the Google Security Team and Red Hat for
> +  reporting the security impact of this issue, and Robert Holiday of
> +  Ciena for reporting the related bug 18665. (CVE-2015-7547)
> +
> +See also:
> +https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
> +https://sourceware.org/ml/libc-alpha/2016-02/msg00418.html
> +
> +Upstream-Status: Backport
> +CVE: CVE-2015-7547
> +
> +Upstream commit:
> +
> https://sourceware.org/git/?p=glibc.git;a=commit;h=16d0a0ce7613552301786bf05d7eba8784b5732c
> +
> +Tweaks:
> +* Adapted from GLIBC-2.20 to EGLIBC-2.19
> +* Removed changes to ChangeLog and NEWS files
> +
> +Signed-off-by: Javier Viguera 
> +---
> + resolv/nss_dns/dns-host.c | 111 +++-
> + resolv/res_query.c|   3 +
> + resolv/res_send.c | 257
> +++---
> + 3 files changed, 309 insertions(+), 62 deletions(-)
> +
> +diff --git a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c
> +index f8f192e5afb5..e7e2c7137a50 100644
> +--- a/resolv/nss_dns/dns-host.c
>  b/resolv/nss_dns/dns-host.c
> +@@ -1049,7 +1049,10 @@ gaih_getanswer_slice (const querybuf *answer, int
> anslen, const char *qname,
> +   int h_namelen = 0;
> +
> +   if (ancount == 0)
> +-return NSS_STATUS_NOTFOUND;
> ++{
> ++  *h_errnop = HOST_NOT_FOUND;
> ++  return NSS_STATUS_NOTFOUND;
> ++}
> +
> +   while (ancount-- > 0 && cp < end_of_message && had_error == 0)
> + {
> +@@ -1226,7 +1229,14 @@ gaih_getanswer_slice (const querybuf *answer, int
> anslen, const char *qname,
> +   /* Special case here: if the resolver sent a result but it only
> +  contains a CNAME while we are looking for a T_A or T_ record,
> +  we fail with NOTFOUND instead of TRYAGAIN.  */
> +-  return canon == NULL ? NSS_STATUS_TRYAGAIN : NSS_STATUS_NOTFOUND;
> ++  if (canon != NULL)
> ++{
> ++  *h_errnop = HOST_NOT_FOUND;
> ++  return NSS_STATUS_NOTFOUND;
> ++}
> ++
> ++  *h_errnop = NETDB_INTERNAL;
> ++  return NSS_STATUS_TRYAGAIN;
> + }
> +
> +
> +@@ -1240,11 +1250,101 @@ gaih_getanswer (const querybuf *answer1, int
> anslen1, const querybuf *answer2,
> +
> +   enum nss_status status = NSS_STATUS_NOTFOUND;
> +
> ++  /* Combining the NSS status of two distinct queries requires some
> ++ compromise and attention to symmetry (A or  queries can be
> ++ returned in any order).  What follows is a breakdown of how this
> ++ code is expected to work and why. We discuss only SUCCESS,
> ++ TRYAGAIN, NOTFOUND and UNAVAIL, since they are the only returns
> ++ that apply (though RETURN and MERGE exist).  We make a distinction
> ++ between TRYAGAIN (recoverable) and TRYAGAIN' (not-recoverable).
> ++ A recoverable TRYAGAIN is almost always due to buffer size issues
> ++ and returns ERANGE in errno and the caller is expected to retry
> ++ with a larger buffer.
> ++
> ++ Lastly, you may be tempted to make significant changes to the
> ++ conditions in this code to bring about symmetry between responses.
> ++ Please don't change anything without due consideration for
> ++ expected application behaviour.  Some of the 

Re: [OE-core] [daisy][PATCH] eglibc: security fix CVE-2015-7547

[Javier Viguera]

Hi all,

According to the Yocto release page:

https://wiki.yoctoproject.org/wiki/Releases

Daisy is now community maintained.

As the "community" does not have push-permissions to the git server, is 
anyone with permission willing to merge this patch?


The patch is a backport of the CVE-2015-7547 vulnerability fix from 
glibc-2.20 to eglibc-2.19.


I can put this patch in our own BSP layer, but I think oe-core is the 
proper place to commit it, and this way it will benefit to other people 
still using Daisy branch.


--
Thanks,

Javier Viguera
Software Engineer
Digi International® Spain S.A.U.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1 V2] linux-yocto-tiny: fix COMPATIBLE_MACHINE

[Robert Yang]

* V2:
  Fix from linux-yocto-tiny rather than base.bbclass.

// Robert

The following changes since commit 2279c6d20c2a33283ce9a8d1ef91a8acdad0a20e:

  archiver: Fix ASSUME_PROVIDED issues (2016-04-09 23:17:52 +0100)

are available in the git repository at:

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

Robert Yang (1):
  linux-yocto-tiny: fix COMPATIBLE_MACHINE

 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.8.0

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

[OE-core] [PATCH 1/1] linux-yocto-tiny: fix COMPATIBLE_MACHINE

[Robert Yang]

It only works with qemux86, but mismatched qemux86-64 which caused
runtime errros. (kernel is bigger, can't boot, no output, and so on).

Add '$' in the end to fix the problem.

Signed-off-by: Robert Yang 
---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

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 4c79bfd..36f83b5 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -17,7 +17,7 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
 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}"
 
-COMPATIBLE_MACHINE = "(qemux86)"
+COMPATIBLE_MACHINE = "(qemux86$)"
 
 # Functionality flags
 KERNEL_FEATURES = ""
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 9446da9..04e6258 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
@@ -17,7 +17,7 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
 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}"
 
-COMPATIBLE_MACHINE = "(qemux86)"
+COMPATIBLE_MACHINE = "(qemux86$)"
 
 # Functionality flags
 KERNEL_FEATURES = ""
-- 
2.8.0

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

Re: [OE-core] [RFC PATCH 0/2] unique -dev package

[Richard Purdie]

On Sun, 2016-04-10 at 21:49 -0400, Denys Dmytriyenko wrote:
> On Mon, Apr 11, 2016 at 09:19:32AM +0800, Robert Yang wrote:
> > On 04/11/2016 06:51 AM, Denys Dmytriyenko wrote:
> > > On Tue, Apr 07, 2015 at 05:58:13AM -0700, Robert Yang wrote:
> > > > Hello,
> > > > 
> > > > I think that one recipe should only have one -dev package, I'm
> > > > not sure
> > > > whether this is right or not, please feel free to give your
> > > > comments, we
> > > 
> > > I know it is already 1 year since this change. But I can't seem
> > > to find any
> > > discussion or any explanation to why this change was required and
> > > what
> > > specific problem it was supposed to fix. Please point me to a
> > > clear reasoning
> > > of this change. Thanks.
> > 
> > There is only one source package, so there should be only one pack
> > of header
> > files, dev libs, and so on, and they should be placed in a uniq
> > pkg.
> 
> Since you are using "should" twice in the same sentence, can you
> please point 
> me to a ratified RFC?

I couldn't seem to see the history of this discussion in my mail folder
but I do remember some patches along these lines.

The reason for a single -dev package is that the "package chain"
functions we have assumes this. I know there are some specific cases
where we do have multiple -dev packages (qt4, gcc-runtime) but they are
very much in the minority and are special cases.

I'm definitely on record as saying the depchains code needs revisiting
and redoing, preferably with a structured rethink so that we can better
handle situations like this. Until that is done, multiple -dev packages
can cause issues and we did remove some where there didn't seem to be
any real benefit.

Which case is causing problems for you?

Cheers,

Richard



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

Re: [OE-core] [PATCH 1/1] base.bbclass: fix COMPATIBLE_MACHINE

[Robert Yang]

On 04/11/2016 04:29 PM, Richard Purdie wrote:

On Mon, 2016-04-11 at 10:11 +0800, Robert Yang wrote:


On 04/11/2016 09:56 AM, Christopher Larson wrote:

On Sun, Apr 10, 2016 at 6:17 PM Robert Yang <
liezhi.y...@windriver.com
> wrote:



 On 04/11/2016 03:06 AM, Denys Dmytriyenko wrote:
  > On Sun, Apr 10, 2016 at 07:14:56AM -0700, Robert Yang wrote:
  >> It mismatched such as qemux86 and qemux86-64 which was
incorrect, for
  >> example:
  >> COMPATIBLE_MACHINE = "(qemux86)"
  >
  > That will match qemux86 and qemux86-64 and is by design!
It's a regular

 I'm afraid no, please see my last reply, for others such as
 MACHINE_OVERRIDES, they never design to work in such a way, so
I don't
 think that COMPATIBLE_MACHINE should work in this way. If you
really
 want to match more, I think that you can set it as
"(qemux86.*)" or
 something familiar.


That's an apples and oranges comparison. MACHINEOVERRIDES is part
of OVERRIDES,
which has *completely* different semantics than COMPATIBLE_*.
COMPATIBLE_MACHINE
is a regex variable more like BBMASK than anything else, and it's
been that way
since we introduced it. OVERRIDES has nothing to do with regular
expressions.


Since introduced ? I did a grep in oe-core and meta-openembedded, it
seems
that no ?

In oe-core:

$ grep 'COMPATIBLE_MACHINE.*qemux86' meta/recipes* -r
linux-yocto_4.4.bb:COMPATIBLE_MACHINE =
"qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
linux-yocto-tiny_4.4.bb:COMPATIBLE_MACHINE = "(qemux86)"
linux-yocto-dev.bb:COMPATIBLE_MACHINE =
"(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64)"
linux-yocto-tiny_4.1.bb:COMPATIBLE_MACHINE = "(qemux86)"
linux-yocto-rt_4.1.bb:COMPATIBLE_MACHINE =
"(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
linux-yocto-rt_4.4.bb:COMPATIBLE_MACHINE =
"(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
linux-yocto_4.1.bb:COMPATIBLE_MACHINE =
"qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"

In meta-openembedded:
vboxguestdrivers_4.3.30.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86
-64)"

We can see that the only one sets qemux86 but no set qemux86-64 is
linux-yocto-tiny:
COMPATIBLE_MACHINE = "(qemux86)"

And it really doesn't work with qemux86-64.


The trouble is as others have mentioned, COMPATIBLE_MACHINE has always
worked this way. We can't really change that without a wider discussion
and at this point in the release in particular, I can't take such a
patch.

We do really need to think about the behaviour as it does do unexpected
things and catch people out.

I'd suggest you add a '$' to the end of the regex in linux-yocto-tiny


Thanks, I will send a new patch it.


to resolve this. We could also add '$' to the end of the other usages
and make it clear it is a regex?


I'd like to only fix linux-yocto-tiny atm in case of cause other errors,
maybe we can do that for other recipes in YP 2.2.

// Robert



Cheers,

Richard




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

Re: [OE-core] [PATCH 1/1] base.bbclass: fix COMPATIBLE_MACHINE

[Richard Purdie]

On Mon, 2016-04-11 at 10:11 +0800, Robert Yang wrote:
> 
> On 04/11/2016 09:56 AM, Christopher Larson wrote:
> > On Sun, Apr 10, 2016 at 6:17 PM Robert Yang <
> > liezhi.y...@windriver.com
> > > wrote:
> > 
> > 
> > 
> > On 04/11/2016 03:06 AM, Denys Dmytriyenko wrote:
> >  > On Sun, Apr 10, 2016 at 07:14:56AM -0700, Robert Yang wrote:
> >  >> It mismatched such as qemux86 and qemux86-64 which was
> > incorrect, for
> >  >> example:
> >  >> COMPATIBLE_MACHINE = "(qemux86)"
> >  >
> >  > That will match qemux86 and qemux86-64 and is by design!
> > It's a regular
> > 
> > I'm afraid no, please see my last reply, for others such as
> > MACHINE_OVERRIDES, they never design to work in such a way, so
> > I don't
> > think that COMPATIBLE_MACHINE should work in this way. If you
> > really
> > want to match more, I think that you can set it as
> > "(qemux86.*)" or
> > something familiar.
> > 
> > 
> > That's an apples and oranges comparison. MACHINEOVERRIDES is part
> > of OVERRIDES,
> > which has *completely* different semantics than COMPATIBLE_*.
> > COMPATIBLE_MACHINE
> > is a regex variable more like BBMASK than anything else, and it's
> > been that way
> > since we introduced it. OVERRIDES has nothing to do with regular
> > expressions.
> 
> Since introduced ? I did a grep in oe-core and meta-openembedded, it
> seems
> that no ?
> 
> In oe-core:
> 
> $ grep 'COMPATIBLE_MACHINE.*qemux86' meta/recipes* -r
> linux-yocto_4.4.bb:COMPATIBLE_MACHINE = 
> "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
> linux-yocto-tiny_4.4.bb:COMPATIBLE_MACHINE = "(qemux86)"
> linux-yocto-dev.bb:COMPATIBLE_MACHINE = 
> "(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64)"
> linux-yocto-tiny_4.1.bb:COMPATIBLE_MACHINE = "(qemux86)"
> linux-yocto-rt_4.1.bb:COMPATIBLE_MACHINE = 
> "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
> linux-yocto-rt_4.4.bb:COMPATIBLE_MACHINE = 
> "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
> linux-yocto_4.1.bb:COMPATIBLE_MACHINE = 
> "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
> 
> In meta-openembedded:
> vboxguestdrivers_4.3.30.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86
> -64)"
> 
> We can see that the only one sets qemux86 but no set qemux86-64 is
> linux-yocto-tiny:
> COMPATIBLE_MACHINE = "(qemux86)"
> 
> And it really doesn't work with qemux86-64.

The trouble is as others have mentioned, COMPATIBLE_MACHINE has always
worked this way. We can't really change that without a wider discussion
and at this point in the release in particular, I can't take such a
patch.

We do really need to think about the behaviour as it does do unexpected
things and catch people out.

I'd suggest you add a '$' to the end of the regex in linux-yocto-tiny
to resolve this. We could also add '$' to the end of the other usages
and make it clear it is a regex?

Cheers,

Richard


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

[OE-core] [PATCH 13/14] ncurses: update SRC_URI

[Robert Yang]

From: Ross Burton 

Upstream re-arranged their FTP server and deleted the tarball that we were
downloading.  This tarball is mirrors on downloads.yoctoproject.org but not
everyone uses that, so Work around this by pointing the SRC_URI at the Yocto
Project source mirror directly.

[ YOCTO #9379 ]

Signed-off-by: Ross Burton 
Signed-off-by: Robert Yang 
---
 meta/recipes-core/ncurses/ncurses_5.9.bb | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/ncurses/ncurses_5.9.bb 
b/meta/recipes-core/ncurses/ncurses_5.9.bb
index 54d27a9..35ef9c3 100644
--- a/meta/recipes-core/ncurses/ncurses_5.9.bb
+++ b/meta/recipes-core/ncurses/ncurses_5.9.bb
@@ -4,9 +4,11 @@ REVISION = "20150329"
 
 PR = "${INC_PR}.1"
 
-SRC_URI += "file://tic-hang.patch \
-file://config.cache \
+SRC_URI = 
"http://downloads.yoctoproject.org/mirror/sources/ncurses-5.9-20150329.tgz \
+   file://tic-hang.patch \
+   file://config.cache \
 "
+
 S = "${WORKDIR}/${BP}-${REVISION}"
 SRC_URI[md5sum] = "cee991d09e69e60ebedef424804c52d4"
 SRC_URI[sha256sum] = 
"5b64f40e4dce73e3aa83d15bd9257c6eff8790ec41150f0938bd87c0eb75828f"
-- 
2.7.4

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

[OE-core] [PATCH 12/14] python3: fix building nativesdk-python3

[Robert Yang]

From: Juro Bystricky 

When the class nativesdk.bbclass is inherited, it redefines TARGET_CC_ARCH,
in the case of python3, this enables debug, causing an error while linking.
Since we don't enable debug during configure some functions are not declared.
This patch makes sure we keep debug disabled, fixing the linking errors.

[YOCTO #9357]

Signed-off-by: Juro Bystricky 
Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/python/python3_3.4.3.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/python/python3_3.4.3.bb 
b/meta/recipes-devtools/python/python3_3.4.3.bb
index f61d278..4f4e79c 100644
--- a/meta/recipes-devtools/python/python3_3.4.3.bb
+++ b/meta/recipes-devtools/python/python3_3.4.3.bb
@@ -61,6 +61,7 @@ CACHED_CONFIGUREVARS = "ac_cv_have_chflags=no \
 TARGET_CC_ARCH_append_armv6 = " -D__SOFTFP__"
 TARGET_CC_ARCH_append_armv7a = " -D__SOFTFP__"
 TARGET_CC_ARCH += "-DNDEBUG -fno-inline"
+SDK_CC_ARCH += "-DNDEBUG -fno-inline"
 EXTRA_OEMAKE += "CROSS_COMPILE=yes"
 EXTRA_OECONF += 
"CROSSPYTHONPATH=${STAGING_LIBDIR_NATIVE}/python${PYTHON_MAJMIN}/lib-dynload/ 
--without-ensurepip"
 
-- 
2.7.4

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

[OE-core] [PATCH 11/14] systemd-serialgetty: allow baud rate overriding

[Robert Yang]

From: Awais Belal 

In case a getty is required on a UART which is not being
used as the kernel console, the current agetty invocation
fails to obey the baud rate configured through the
SERIAL_CONSOLES variable because it uses --keep-baud.

(From OE-Core master rev: b54b73834e73d55de1038b55d0a4d7f49cda52d0)

Signed-off-by: Awais Belal 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Yang 
---
 meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service 
b/meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service
index 182167b..e8b027e 100644
--- a/meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service
+++ b/meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service
@@ -21,7 +21,7 @@ IgnoreOnIsolate=yes
 
 [Service]
 Environment="TERM=xterm"
-ExecStart=-/sbin/agetty -8 -L --keep-baud %I @BAUDRATE@ $TERM
+ExecStart=-/sbin/agetty -8 -L %I @BAUDRATE@ $TERM
 Type=idle
 Restart=always
 RestartSec=0
-- 
2.7.4

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

[OE-core] [PATCH 10/14] boost: ensure boost to remain an empty metapackage

[Robert Yang]

From: Lukas Bulwahn 

To ensure that boost remains an empty metapackage after version
updates, we explicitly require boost files to be empty. If new
libraries exist after a version update of the boost recipe,
bitbake will emit a warning at the do_package task. For example,
at the version update from 1.58.0 to 1.59.0, the new timer
library is indicated with:

WARNING: QA Issue: boost: Files/directories were installed but not shipped in 
any package:
  /usr/lib/libboost_timer.so.1.59.0
Please set FILES such that these items are packaged. Alternatively if they are 
unneeded, avoid installing them or delete them within do_install.
boost: 1 installed and not shipped files. [installed-vs-shipped]

Ross Burton suggested this improvement on the openembedded-core
mailing list during review of the boost recipe version update [1].

[1] 
http://lists.openembedded.org/pipermail/openembedded-core/2015-December/114314.html

(From OE-Core master rev: c4e33232db2da3594cc4ba38eea56ee1acb54d3a)

Signed-off-by: Lukas Bulwahn 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Yang 
---
 meta/recipes-support/boost/boost.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/boost/boost.inc 
b/meta/recipes-support/boost/boost.inc
index 3288e84..bb49d60 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -59,6 +59,7 @@ FILES_boost-test = "${libdir}/libboost_prg_exec_monitor*.so.* 
\
 
 # -dev last to pick up the remaining stuff
 PACKAGES += "${PN}-dev ${PN}-staticdev"
+FILES_${PN} = ""
 FILES_${PN}-dev = "${includedir} ${libdir}/libboost_*.so"
 FILES_${PN}-staticdev = "${libdir}/libboost_*.a"
 
-- 
2.7.4

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

[OE-core] [PATCH 14/14] lttng-tools: fix regression tests hang

[Robert Yang]

From: Awais Belal 

Some of the lttng fast_regression ptests have race
conditions which end up in a deadlock so the test
case never returns and the only way around is to
kill the process.
This is fixed by picking up relevant patches from
lttng-tools mainstream that fix up the behavior
of these tests.

Signed-off-by: Awais Belal 
Signed-off-by: Robert Yang 
---
 .../lttng/lttng-tools/Fix-regression-tests.patch   | 480 +
 meta/recipes-kernel/lttng/lttng-tools_2.6.0.bb |   1 +
 2 files changed, 481 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-tools/Fix-regression-tests.patch

diff --git a/meta/recipes-kernel/lttng/lttng-tools/Fix-regression-tests.patch 
b/meta/recipes-kernel/lttng/lttng-tools/Fix-regression-tests.patch
new file mode 100644
index 000..42f2074
--- /dev/null
+++ b/meta/recipes-kernel/lttng/lttng-tools/Fix-regression-tests.patch
@@ -0,0 +1,480 @@
+From 971c0ba5c008735b3c5013ca6e0e2e96ab63db90 Mon Sep 17 00:00:00 2001
+From: Mathieu Desnoyers 
+Date: Thu, 24 Sep 2015 12:23:58 -0400
+Subject: [PATCH] Fix: regression tests
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Fix racy session/relayd wait-after-kill scheme.
+Fix racy live test where application may not have generated events yet
+when we attach to the live trace.
+
+Signed-off-by: Mathieu Desnoyers 
+Signed-off-by: Jérémie Galarneau 
+
+Conflicts:
+   tests/utils/utils.sh
+
+Upstream-Status: Backport
+---
+ tests/regression/tools/health/test_health.sh   |   4 +-
+ tests/regression/tools/live/test_kernel|  47 +-
+ tests/regression/tools/live/test_ust   |  60 
+ .../regression/tools/live/test_ust_tracefile_count |  60 
+ tests/regression/tools/save-load/test_load |   6 +-
+ tests/utils/utils.sh   | 103 -
+ 6 files changed, 120 insertions(+), 160 deletions(-)
+
+diff --git a/tests/regression/tools/health/test_health.sh 
b/tests/regression/tools/health/test_health.sh
+index 6ae8885..ddc104c 100644
+--- a/tests/regression/tools/health/test_health.sh
 b/tests/regression/tools/health/test_health.sh
+@@ -146,7 +146,9 @@ function test_health
+   fi
+ 
+   if [ ${test_relayd} -eq 1 ]; then
+-  stop_lttng_relayd_nocheck
++  # We may fail to stop relayd here, and this is OK, since
++  # it may have been killed volountarily by testpoint.
++  stop_lttng_relayd_notap
+   fi
+   stop_lttng_sessiond
+ 
+diff --git a/tests/regression/tools/live/test_kernel 
b/tests/regression/tools/live/test_kernel
+index 4b958df..0e542da 100755
+--- a/tests/regression/tools/live/test_kernel
 b/tests/regression/tools/live/test_kernel
+@@ -62,22 +62,8 @@ else
+   exit 0
+ fi
+ 
+-if [ -z $(pidof lt-$SESSIOND_BIN) ]; then
+-  $DIR/../src/bin/lttng-sessiond/$SESSIOND_BIN --background --quiet 
--consumerd32-path="$DIR/../src/bin/lttng-consumerd/lttng-consumerd" 
--consumerd64-path="$DIR/../src/bin/lttng-consumerd/lttng-consumerd"
+-  if [ $? -eq 1 ]; then
+-  echo "Fail to start lttng-sessiond"
+-  exit 1
+-  fi
+-fi
+-
+-opt="--background -o $TRACE_PATH"
+-if [ -z $(pidof lt-$RELAYD_BIN) ]; then
+-  $DIR/../src/bin/lttng-relayd/$RELAYD_BIN $opt >/dev/null 2>&1
+-  if [ $? -eq 1 ]; then
+-  echo "Fail to start lttng-relayd (opt: $opt)"
+-  return 1
+-  fi
+-fi
++start_lttng_sessiond_notap
++start_lttng_relayd_notap "-o $TRACE_PATH"
+ 
+ setup_live_tracing
+ 
+@@ -86,30 +72,5 @@ $TESTDIR/regression/tools/live/live_test
+ 
+ clean_live_tracing
+ 
+-# Kill the relayd
+-PID_RELAYD=`pidof lt-$RELAYD_BIN`
+-kill $PID_RELAYD
+-if [ $? -eq 1 ]; then
+-  echo "Kill lttng-relayd (pid: $PID_RELAYD)"
+-  exit 1
+-else
+-  out=1
+-  while [ -n "$out" ]; do
+-  out=$(pidof lt-$RELAYD_BIN)
+-  sleep 0.5
+-  done
+-fi
+-
+-# Kill the sessiond
+-PID_SESSIOND=`pidof lt-$SESSIOND_BIN`
+-kill $PID_SESSIOND
+-if [ $? -eq 1 ]; then
+-  echo "Kill sessiond daemon"
+-  exit 1
+-else
+-  out=1
+-  while [ -n "$out" ]; do
+-  out=$(pidof lt-$SESSIOND_BIN)
+-  sleep 0.5
+-  done
+-fi
++stop_lttng_relayd_notap
++stop_lttng_sessiond_notap
+diff --git a/tests/regression/tools/live/test_ust 
b/tests/regression/tools/live/test_ust
+index ae69195..0b96858 100755
+--- a/tests/regression/tools/live/test_ust
 b/tests/regression/tools/live/test_ust
+@@ -59,57 +59,29 @@ function clean_live_tracing()
+   rm -rf $TRACE_PATH
+ }
+ 
+-if [ -z $(pidof lt-$SESSIOND_BIN) ]; then
+-  $DIR/../src/bin/lttng-sessiond/$SESSIOND_BIN --background --quiet 

[OE-core] [PATCH 08/14] cdrtools: update SRC_URI

[Robert Yang]

From: Ross Burton 

Upstream released their 3.01 so the alpha releases we were downloading have
moved.  Update the SRC_URI so it continues to download.

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/cdrtools/cdrtools-native_3.01a31.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a31.bb 
b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a31.bb
index d0f36e2..50e284c 100644
--- a/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a31.bb
+++ b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a31.bb
@@ -7,7 +7,7 @@ SECTION = "console/utils"
 LICENSE = "GPLv2 & CDDL-1.0 & LGPLv2.1+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=32f68170be424c2cd64804337726b312"
 
-SRC_URI = "${SOURCEFORGE_MIRROR}/project/cdrtools/alpha/cdrtools-${PV}.tar.bz2"
+SRC_URI = 
"${SOURCEFORGE_MIRROR}/project/cdrtools/alpha/OLD/3.01aX/cdrtools-${PV}.tar.bz2"
 
 SRC_URI[md5sum] = "78172557894f469b4584d008e93ec469"
 SRC_URI[sha256sum] = 
"183b5c1279e78d8b69461aae52401f863768e7e7391d60730006f8cadc5a"
-- 
2.7.4

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

[OE-core] [PATCH 09/14] systemd: chown hwdb.bin to root:root for do_rootfs

[Robert Yang]

From: Christopher Larson 

This is created by qemu for the do_rootfs case, which bypasses pseudo, so we
need to correct the ownership. This fixes a warning issued by
rootfs_check_host_user_contaminated.

(From OE-Core master rev: 4ff6b8cadec10e17dbf884a873a227e29944f5d1)

Signed-off-by: Christopher Larson 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Yang 
---
 meta/recipes-core/systemd/systemd_225.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_225.bb 
b/meta/recipes-core/systemd/systemd_225.bb
index 7c66ba2..9346260 100644
--- a/meta/recipes-core/systemd/systemd_225.bb
+++ b/meta/recipes-core/systemd/systemd_225.bb
@@ -402,6 +402,7 @@ pkg_postinst_udev-hwdb () {
if test -n "$D"; then
${@qemu_run_binary(d, '$D', '${base_bindir}/udevadm')} hwdb 
--update \
--root $D
+   chown root:root $D${sysconfdir}/udev/hwdb.bin
else
udevadm hwdb --update
fi
-- 
2.7.4

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

[OE-core] [PATCH 06/14] systemd: fix segfault on shutdown

[Robert Yang]

From: Bill Randle 

This applies upstream fixes to fix a segfault in systemd-logind on
shutdown.

[Fixes YOCTO #9265]

Signed-off-by: Bill Randle 
---
 .../0023-backported-fixes-for-null-messages.patch  | 101 +
 meta/recipes-core/systemd/systemd_225.bb   |   1 +
 2 files changed, 102 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0023-backported-fixes-for-null-messages.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0023-backported-fixes-for-null-messages.patch
 
b/meta/recipes-core/systemd/systemd/0023-backported-fixes-for-null-messages.patch
new file mode 100644
index 000..b39037f
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0023-backported-fixes-for-null-messages.patch
@@ -0,0 +1,101 @@
+From ce88232a1c8e914936e18edbee2551ab95fc4c1d Mon Sep 17 00:00:00 2001
+From: Bill Randle 
+Date: Mon, 21 Mar 2016 15:52:30 -0700
+Subject: [PATCH] backported fixes for null messages
+
+Apply upstream commits 5744f59a3ee883ef3a78214bd5236157acdc35ba,
+2cf088b56d72cb6a3243041524f1fbae7c1cb28e and
+c7430c3d1a0c14aed631864b9da504ba1a9352c2 to fix Yocto #9265.
+
+Upstream-Status: Backport
+
+Signed-off-by: Bill Randle 
+---
+ src/login/logind-dbus.c | 31 ++-
+ 1 file changed, 18 insertions(+), 13 deletions(-)
+
+diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
+index 5b2b36b..e433549 100644
+--- a/src/login/logind-dbus.c
 b/src/login/logind-dbus.c
+@@ -1339,8 +1339,7 @@ static int bus_manager_log_shutdown(
+ InhibitWhat w,
+ const char *unit_name) {
+ 
+-const char *p;
+-const char *q;
++const char *p, *q;
+ 
+ assert(m);
+ assert(unit_name);
+@@ -1365,8 +1364,8 @@ static int bus_manager_log_shutdown(
+ q = NULL;
+ }
+ 
+-if (m->wall_message)
+-p = strjoina(p, " (", m->wall_message, ")", NULL);
++if (!isempty(m->wall_message))
++p = strjoina(p, " (", m->wall_message, ")");
+ 
+ return log_struct(LOG_NOTICE,
+   LOG_MESSAGE_ID(SD_MESSAGE_SHUTDOWN),
+@@ -1797,9 +1796,11 @@ static int update_schedule_file(Manager *m) {
+ if (r < 0)
+ return log_error_errno(r, "Failed to create shutdown 
subdirectory: %m");
+ 
+-t = cescape(m->wall_message);
+-if (!t)
+-return log_oom();
++if (!isempty(m->wall_message)) {
++t = cescape(m->wall_message);
++if (!t)
++return log_oom();
++}
+ 
+ r = fopen_temporary("/run/systemd/shutdown/scheduled", , 
_path);
+ if (r < 0)
+@@ -1815,7 +1816,7 @@ static int update_schedule_file(Manager *m) {
+ m->enable_wall_messages,
+ m->scheduled_shutdown_type);
+ 
+-if (!isempty(m->wall_message))
++if (t)
+ fprintf(f, "WALL_MESSAGE=%s\n", t);
+ 
+ r = fflush_and_check(f);
+@@ -2294,7 +2295,7 @@ static int method_set_wall_message(
+ int r;
+ Manager *m = userdata;
+ char *wall_message;
+-bool enable_wall_messages;
++int enable_wall_messages;
+ 
+ assert(message);
+ assert(m);
+@@ -2310,15 +2311,19 @@ static int method_set_wall_message(
+ UID_INVALID,
+ >polkit_registry,
+ error);
+-
+ if (r < 0)
+ return r;
+ if (r == 0)
+ return 1; /* Will call us back */
+ 
+-r = free_and_strdup(>wall_message, wall_message);
+-if (r < 0)
+-return log_oom();
++if (isempty(wall_message))
++m->wall_message = mfree(m->wall_message);
++else {
++r = free_and_strdup(>wall_message, wall_message);
++if (r < 0)
++return log_oom();
++}
++
+ m->enable_wall_messages = enable_wall_messages;
+ 
+ return sd_bus_reply_method_return(message, NULL);
+-- 
+2.5.0
+
diff --git a/meta/recipes-core/systemd/systemd_225.bb 
b/meta/recipes-core/systemd/systemd_225.bb
index 18c2448..7c66ba2 100644
--- a/meta/recipes-core/systemd/systemd_225.bb
+++ b/meta/recipes-core/systemd/systemd_225.bb
@@ -46,6 +46,7 @@ SRC_URI = "git://github.com/systemd/systemd.git;protocol=git \
file://init \
file://run-ptest \
file://rules-whitelist-hd-devices.patch \
+   file://0023-backported-fixes-for-null-messages.patch \
   "
 SRC_URI_append_qemuall = " 
file://qemuall_io_latency-core-device.c-Change-the-default-device-timeout-to-2.patch"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list

[OE-core] [PATCH 04/14] busybox_git: Fix SRCREV

[Robert Yang]

From: Brad Mouring 

The SRCREV in the busybox git recipe did not point to a commit ID
on the master branch. Point the variable to something reachable from
the master branch (which fixes this recipe's fetch()).

Suggested-by: Khem Raj 
Signed-off-by: Brad Mouring 
---
 meta/recipes-core/busybox/busybox_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/busybox/busybox_git.bb 
b/meta/recipes-core/busybox/busybox_git.bb
index ade72f4..7c1b650 100644
--- a/meta/recipes-core/busybox/busybox_git.bb
+++ b/meta/recipes-core/busybox/busybox_git.bb
@@ -1,6 +1,6 @@
 require busybox.inc
 
-SRCREV = "be947c4d97c0dacb703a6f24dd813ff6dd3a33b6"
+SRCREV = "4d15068d83054a9f82b3f8842706cd6deb401e25"
 # Lookout for PV bump too when SRCREV is changed
 PV = "1.23.2+git${SRCPV}"
 
-- 
2.7.4

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

[OE-core] [PATCH 05/14] nfs-utils: bugfix: adjust name of statd service unit

[Robert Yang]

From: Ulrich Ölmann 

Upstream nfs-utils use 'rpc-statd.service' and Yocto introduced
'nfs-statd.service' instead but forgot to update the mount.nfs helper
'start-statd' accordingly.

Signed-off-by: Ulrich Ölmann 
---
 .../files/bugfix-adjust-statd-service-name.patch   | 34 ++
 .../nfs-utils/nfs-utils_1.3.1.bb   |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 
meta/recipes-connectivity/nfs-utils/files/bugfix-adjust-statd-service-name.patch

diff --git 
a/meta/recipes-connectivity/nfs-utils/files/bugfix-adjust-statd-service-name.patch
 
b/meta/recipes-connectivity/nfs-utils/files/bugfix-adjust-statd-service-name.patch
new file mode 100644
index 000..14bd403
--- /dev/null
+++ 
b/meta/recipes-connectivity/nfs-utils/files/bugfix-adjust-statd-service-name.patch
@@ -0,0 +1,34 @@
+From 398fed3bb0350cb1229e54e7020ae0e044c206d1 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ulrich=20=C3=96lmann?= 
+Date: Wed, 17 Feb 2016 08:33:45 +0100
+Subject: bugfix: adjust statd service name
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Upstream uses 'rpc-statd.service' and Yocto introduced 'nfs-statd.service'
+instead but forgot to update the mount.nfs helper 'start-statd' accordingly.
+
+Upstream-Status: Inappropriate [other]
+
+Signed-off-by: Ulrich Ölmann 
+---
+ utils/statd/start-statd | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/utils/statd/start-statd b/utils/statd/start-statd
+index 8211a90..3c2aa6f 100755
+--- a/utils/statd/start-statd
 b/utils/statd/start-statd
+@@ -16,7 +16,7 @@ fi
+ # First try systemd if it's installed.
+ if [ -d /run/systemd/system ]; then
+ # Quit only if the call worked.
+-systemctl start rpc-statd.service && exit
++systemctl start nfs-statd.service && exit
+ fi
+ 
+ # Fall back to launching it ourselves.
+-- 
+2.1.4
+
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb 
b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
index 42101de..f346fdc 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
@@ -31,6 +31,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x
file://proc-fs-nfsd.mount \
file://nfs-utils-Do-not-pass-CFLAGS-to-gcc-while-building.patch \
file://nfs-utils-debianize-start-statd.patch \
+   file://bugfix-adjust-statd-service-name.patch \
 "
 
 SRC_URI[md5sum] = "8de676b9ff34b8f9addc1d0800fabdf8"
-- 
2.7.4

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

[OE-core] [PATCH 07/14] gcc-cross-canadian.inc: add INSANE_SKIP_ to avoid build warning

[Robert Yang]

From: Li Xin 

WARNING: QA Issue: gcc-cross-canadian-i586-dbg: found library in wrong location:
/PATH/sysroots/x86_64-oesdk-linux/usr/libexec/i586-oe-linux/gcc/
i586-oe-linux/5.2.0/.debug/libcc1.so.0.0.0

This warning is introduced by commit f6e47aa(gcc-target 5.1: fix for libcc1)

Signed-off-by: Li Xin 
---
 meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc 
b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
index 54e4881..027c09a 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
@@ -83,6 +83,8 @@ FILES_${PN} = "\
 ${prefix}/${TARGET_SYS}/usr/include/* \
 "
 INSANE_SKIP_${PN} += "dev-so"
+INSANE_SKIP_${PN} += "libdir"
+INSANE_SKIP_${PN}-dbg += "libdir"
 
 FILES_${PN}-dbg += " \
 ${libexecdir}/gcc/${TARGET_SYS}/${BINV}/.debug \
-- 
2.7.4

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

[OE-core] [PATCH 00/14] [jethro] Consolidated pull

[Robert Yang]

The following changes since commit 4d879cb8d7384ac4a96f22c1664b8875f2d8f615:

  devtool: extract: update SRCTREECOVEREDTASKS for kernel (2016-03-20 10:22:55 
+)

are available in the git repository at:

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

Awais Belal (2):
  systemd-serialgetty: allow baud rate overriding
  lttng-tools: fix regression tests hang

Bill Randle (1):
  systemd: fix segfault on shutdown

Brad Mouring (2):
  busybox-1.23: Backport patch to fix zcip false-conflict
  busybox_git: Fix SRCREV

Christopher Larson (1):
  systemd: chown hwdb.bin to root:root for do_rootfs

Javier Viguera (1):
  bluez5: allow D-Bus to spawn obexd in systems without systemd

Juro Bystricky (1):
  python3: fix building nativesdk-python3

Khem Raj (1):
  ruby-native: Depend on openssl-native

Li Xin (1):
  gcc-cross-canadian.inc: add INSANE_SKIP_ to avoid build warning

Lukas Bulwahn (1):
  boost: ensure boost to remain an empty metapackage

Ross Burton (2):
  cdrtools: update SRC_URI
  ncurses: update SRC_URI

Ulrich Ölmann (1):
  nfs-utils: bugfix: adjust name of statd service unit

 meta/recipes-connectivity/bluez5/bluez5.inc|   1 +
 ...-obexd-without-systemd-in-the-user-sessio.patch |  63 +++
 .../files/bugfix-adjust-statd-service-name.patch   |  34 ++
 .../nfs-utils/nfs-utils_1.3.1.bb   |   1 +
 ...wrong-comparison-of-source-IP-with-our-IP.patch |  38 ++
 meta/recipes-core/busybox/busybox_1.23.2.bb|   1 +
 meta/recipes-core/busybox/busybox_git.bb   |   2 +-
 meta/recipes-core/ncurses/ncurses_5.9.bb   |   6 +-
 .../systemd-serialgetty/serial-getty@.service  |   2 +-
 .../0023-backported-fixes-for-null-messages.patch  | 101 +
 meta/recipes-core/systemd/systemd_225.bb   |   2 +
 .../cdrtools/cdrtools-native_3.01a31.bb|   2 +-
 meta/recipes-devtools/gcc/gcc-cross-canadian.inc   |   2 +
 meta/recipes-devtools/python/python3_3.4.3.bb  |   1 +
 meta/recipes-devtools/ruby/ruby.inc|   2 +-
 .../lttng/lttng-tools/Fix-regression-tests.patch   | 480 +
 meta/recipes-kernel/lttng/lttng-tools_2.6.0.bb |   1 +
 meta/recipes-support/boost/boost.inc   |   1 +
 18 files changed, 734 insertions(+), 6 deletions(-)
 create mode 100644 
meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
 create mode 100644 
meta/recipes-connectivity/nfs-utils/files/bugfix-adjust-statd-service-name.patch
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-zcip-fix-wrong-comparison-of-source-IP-with-our-IP.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0023-backported-fixes-for-null-messages.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-tools/Fix-regression-tests.patch

-- 
2.7.4

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

[OE-core] [PATCH 02/14] bluez5: allow D-Bus to spawn obexd in systems without systemd

[Robert Yang]

From: Javier Viguera 

This includes a proper D-Bus service file for obexd in systems that do
not support systemd.

(From OE-Core rev: 75c5dc8d4a5506bf5b89292a96c7b9f91e9d71c8)

Signed-off-by: Javier Viguera 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Yang 
---
 meta/recipes-connectivity/bluez5/bluez5.inc|  1 +
 ...-obexd-without-systemd-in-the-user-sessio.patch | 63 ++
 2 files changed, 64 insertions(+)
 create mode 100644 
meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index df42c88..d1af31e 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -18,6 +18,7 @@ PACKAGECONFIG[experimental] = 
"--enable-experimental,--disable-experimental,"
 
 SRC_URI = "\
 ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
+${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '', 
'file://0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch', d)} \
 "
 S = "${WORKDIR}/bluez-${PV}"
 
diff --git 
a/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
 
b/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
new file mode 100644
index 000..2fde7bc
--- /dev/null
+++ 
b/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
@@ -0,0 +1,63 @@
+From: Giovanni Campagna 
+Date: Sat, 12 Oct 2013 17:45:25 +0200
+Subject: [PATCH] Allow using obexd without systemd in the user session
+
+Not all sessions run systemd --user (actually, the majority
+doesn't), so the dbus daemon must be able to spawn obexd
+directly, and to do so it needs the full path of the daemon.
+
+Upstream-Status: Denied
+
+Not accepted by upstream maintainer for being a distro specific
+configuration. See thread:
+
+http://thread.gmane.org/gmane.linux.bluez.kernel/38725/focus=38843
+
+Signed-off-by: Javier Viguera 
+---
+ Makefile.obexd  | 4 ++--
+ obexd/src/org.bluez.obex.service| 4 
+ obexd/src/org.bluez.obex.service.in | 4 
+ 3 files changed, 6 insertions(+), 6 deletions(-)
+ delete mode 100644 obexd/src/org.bluez.obex.service
+ create mode 100644 obexd/src/org.bluez.obex.service.in
+
+diff --git a/Makefile.obexd b/Makefile.obexd
+index 2e33cbc72f2b..d5d858c857b4 100644
+--- a/Makefile.obexd
 b/Makefile.obexd
+@@ -2,12 +2,12 @@
+ if SYSTEMD
+ systemduserunitdir = @SYSTEMD_USERUNITDIR@
+ systemduserunit_DATA = obexd/src/obex.service
++endif
+ 
+ dbussessionbusdir = @DBUS_SESSIONBUSDIR@
+ dbussessionbus_DATA = obexd/src/org.bluez.obex.service
+-endif
+ 
+-EXTRA_DIST += obexd/src/obex.service.in obexd/src/org.bluez.obex.service
++EXTRA_DIST += obexd/src/obex.service.in obexd/src/org.bluez.obex.service.in
+ 
+ obex_plugindir = $(libdir)/obex/plugins
+ 
+diff --git a/obexd/src/org.bluez.obex.service 
b/obexd/src/org.bluez.obex.service
+deleted file mode 100644
+index a53808884554..
+--- a/obexd/src/org.bluez.obex.service
 /dev/null
+@@ -1,4 +0,0 @@
+-[D-BUS Service]
+-Name=org.bluez.obex
+-Exec=/bin/false
+-SystemdService=dbus-org.bluez.obex.service
+diff --git a/obexd/src/org.bluez.obex.service.in 
b/obexd/src/org.bluez.obex.service.in
+new file mode 100644
+index ..9c815f246b77
+--- /dev/null
 b/obexd/src/org.bluez.obex.service.in
+@@ -0,0 +1,4 @@
++[D-BUS Service]
++Name=org.bluez.obex
++Exec=@libexecdir@/obexd
++SystemdService=dbus-org.bluez.obex.service
-- 
2.7.4

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

[OE-core] [PATCH 03/14] busybox-1.23: Backport patch to fix zcip false-conflict

[Robert Yang]

From: Brad Mouring 

Busybox upstream fixed the issue where an incorrect comparison of
addresses led to bogus renegotiation of a new ll ip in 1.24. Backport
this change to 1.23.2.

Signed-off-by: Brad Mouring 
---
 ...wrong-comparison-of-source-IP-with-our-IP.patch | 38 ++
 meta/recipes-core/busybox/busybox_1.23.2.bb|  1 +
 2 files changed, 39 insertions(+)
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-zcip-fix-wrong-comparison-of-source-IP-with-our-IP.patch

diff --git 
a/meta/recipes-core/busybox/busybox/0001-zcip-fix-wrong-comparison-of-source-IP-with-our-IP.patch
 
b/meta/recipes-core/busybox/busybox/0001-zcip-fix-wrong-comparison-of-source-IP-with-our-IP.patch
new file mode 100644
index 000..dec5eb5
--- /dev/null
+++ 
b/meta/recipes-core/busybox/busybox/0001-zcip-fix-wrong-comparison-of-source-IP-with-our-IP.patch
@@ -0,0 +1,38 @@
+From 4d15068d83054a9f82b3f8842706cd6deb401e25 Mon Sep 17 00:00:00 2001
+From: Vladislav Grishenko 
+Date: Thu, 19 Mar 2015 16:19:35 +0500
+Subject: [PATCH] zcip: fix wrong comparison of source IP with our IP
+
+Commit "zcip: fix link-local IP conflict detection" has introduced
+wrong comparsion of source IP with our IP. This leads to a new IP
+being picked unnecessarily on every incoming ARP packet.
+
+Signed-off-by: Vladislav Grishenko 
+Signed-off-by: Denys Vlasenko 
+
+This change was picked from Busybox without modification
+(git://git.busybox.net/busybox, commit 4d15068)
+
+Upstream-Status: Backport (added in 1.24)
+Signed-off-by: Brad Mouring 
+
+---
+ networking/zcip.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/networking/zcip.c b/networking/zcip.c
+index a3307c5..962ba2e 100644
+--- a/networking/zcip.c
 b/networking/zcip.c
+@@ -521,7 +521,7 @@ int zcip_main(int argc UNUSED_PARAM, char **argv)
+   target_ip_conflict = 0;
+ 
+   if (memcmp(_sha, _addr, ETH_ALEN) != 0) {
+-  if (memcmp(p.arp.arp_spa, _addr, 
sizeof(struct in_addr))) {
++  if (memcmp(p.arp.arp_spa, _addr, 
sizeof(struct in_addr)) == 0) {
+   /* A probe or reply with source_ip == 
chosen ip */
+   source_ip_conflict = 1;
+   }
+-- 
+2.7.3
+
diff --git a/meta/recipes-core/busybox/busybox_1.23.2.bb 
b/meta/recipes-core/busybox/busybox_1.23.2.bb
index 7258df0..5edcbfd 100644
--- a/meta/recipes-core/busybox/busybox_1.23.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.23.2.bb
@@ -36,6 +36,7 @@ SRC_URI = 
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \

file://0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch \
file://0002-Passthrough-r-to-linker.patch \
file://0001-randconfig-fix.patch \
+   
file://0001-zcip-fix-wrong-comparison-of-source-IP-with-our-IP.patch \
file://mount-via-label.cfg \
file://sha1sum.cfg \
file://sha256sum.cfg \
-- 
2.7.4

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

[OE-core] [PATCH 01/14] ruby-native: Depend on openssl-native

[Robert Yang]

From: Khem Raj 

This dependency is floating otherwise, It races against openssl-native
and when openssl config does not match with openssl on build host the
build fails occasionally

x86_64-linux/usr/include/openssl/ripemd.h:70:4: error: #error RIPEMD is
disabled.
 #  error RIPEMD is disabled.

Change-Id: I5ff6d8f058ff99c64ad4dc7c0377724071003ae6
(From OE-Core master rev: d0c8d98077622a700d92384f676770cb4d6d4f46)

Signed-off-by: Khem Raj 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/ruby/ruby.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/ruby/ruby.inc 
b/meta/recipes-devtools/ruby/ruby.inc
index 17aa789..313e752 100644
--- a/meta/recipes-devtools/ruby/ruby.inc
+++ b/meta/recipes-devtools/ruby/ruby.inc
@@ -15,7 +15,7 @@ LIC_FILES_CHKSUM = "\
 "
 
 DEPENDS = "ruby-native zlib openssl tcl libyaml db gdbm readline"
-DEPENDS_class-native = "libyaml-native"
+DEPENDS_class-native = "openssl-native libyaml-native"
 
 SHRT_VER = "${@oe.utils.trim_version("${PV}", 2)}"
 SRC_URI = "http://cache.ruby-lang.org/pub/ruby/${SHRT_VER}/ruby-${PV}.tar.gz \
-- 
2.7.4

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

Re: [OE-core] State of bitbake world, test-dependencies 2016-04-10

[Martin Jansa]

On Sun, Apr 10, 2016 at 08:14:25AM +0200, Martin Jansa wrote:
> This time complete test of all recipes, for both qemux86 and qemuarm.

Somehow I managed to delete the links to logs when sending this.

http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.20160408_062500.log/
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.20160408_180900.log/

> qemux86:
> 
> Found differences: 
> WARN: jasper: jasper-bin rdepends on libgl-mesa, but it isn't a build 
> dependency?
> WARN: jasper: jasper-bin rdepends on libglu, but it isn't a build dependency?
> WARN: jasper: jasper-bin rdepends on mesa-glut, but it isn't a build 
> dependency?
> WARN: samba: samba rdepends on libpam, but it isn't a build dependency?
> WARN: libdrm: libdrm-tests rdepends on cunit, but it isn't a build dependency?
> WARN: libdrm: libdrm-tests rdepends on libdrm-amdgpu, but it isn't a build 
> dependency?
> WARN: enchant: enchant rdepends on hunspell, but it isn't a build dependency?
> Found errors: 
> ERROR: 50 issues were found in these recipes: chkconfig-alternatives-native 
> core-image-rt core-image-rt-sdk core-image-sato-dev core-image-sato-sdk 
> core-image-sato-sdk-ptest cpupower cyrus-sasl enchant fontforge gtkmathview 
> jasper libdrm lttng-modules meta-ide-support meta-world-pkgdata 
> nativesdk-zeroc-ice netmap netmap-modules openlmi-networking 
> openlmi-providers openlmi-storage packagegroup-core-tools-profile perf 
> proxy-libintl python-pyparsing samba sblim-sfcb tiptop zeroc-ice
> 
> 2_max/failed/chkconfig-alternatives-native.log
> 2_max/failed/core-image-rt-sdk.log
> 2_max/failed/core-image-rt.log
> 2_max/failed/core-image-sato-dev.log
> 2_max/failed/core-image-sato-sdk-ptest.log
> 2_max/failed/core-image-sato-sdk.log
> 2_max/failed/cpupower.log
> 2_max/failed/cyrus-sasl.log
> 2_max/failed/fontforge.log
> 2_max/failed/lttng-modules.log
> 2_max/failed/meta-world-pkgdata.log
> 2_max/failed/nativesdk-zeroc-ice.log
> 2_max/failed/netmap-modules.log
> 2_max/failed/netmap.log
> 2_max/failed/openlmi-networking.log
> 2_max/failed/openlmi-providers.log
> 2_max/failed/openlmi-storage.log
> 2_max/failed/packagegroup-core-tools-profile.log
> 2_max/failed/proxy-libintl.log
> 2_max/failed/zeroc-ice.log
> 
> 3_min/failed/core-image-rt-sdk.log
> 3_min/failed/core-image-rt.log
> 3_min/failed/core-image-sato-dev.log
> 3_min/failed/core-image-sato-sdk-ptest.log
> 3_min/failed/core-image-sato-sdk.log
> 3_min/failed/cyrus-sasl.log
> 3_min/failed/fontforge.log
> 3_min/failed/gtkmathview.log
> 3_min/failed/meta-world-pkgdata.log
> 3_min/failed/nativesdk-zeroc-ice.log
> 3_min/failed/perf.log
> 3_min/failed/proxy-libintl.log
> 3_min/failed/python-pyparsing.log
> 3_min/failed/sblim-sfcb.log
> 3_min/failed/zeroc-ice.log
> 
> qemuarm:
> 
> Found differences: 
> WARN: samba: samba rdepends on libpam, but it isn't a build dependency?
> WARN: libdrm: libdrm-tests rdepends on cunit, but it isn't a build dependency?
> WARN: libdrm: libdrm-tests rdepends on libdrm-amdgpu, but it isn't a build 
> dependency?
> WARN: enchant: enchant rdepends on hunspell, but it isn't a build dependency?
> Found errors: 
> ERROR: 55 issues were found in these recipes: chkconfig-alternatives-native 
> core-image-minimal-initramfs core-image-rt core-image-rt-sdk 
> core-image-sato-dev core-image-sato-sdk core-image-sato-sdk-ptest 
> core-image-testmaster-initramfs cyrus-sasl enchant fontforge gtkmathview 
> ipmiutil libdrm meta-world-pkgdata nativesdk-zeroc-ice netmap-modules perf 
> proxy-libintl remake samba sblim-sfcb zeroc-ice
> 
> 2_max/failed/chkconfig-alternatives-native.log
> 2_max/failed/core-image-minimal-initramfs.log
> 2_max/failed/core-image-rt-sdk.log
> 2_max/failed/core-image-rt.log
> 2_max/failed/core-image-sato-dev.log
> 2_max/failed/core-image-sato-sdk-ptest.log
> 2_max/failed/core-image-sato-sdk.log
> 2_max/failed/core-image-testmaster-initramfs.log
> 2_max/failed/cyrus-sasl.log
> 2_max/failed/fontforge.log
> 2_max/failed/ipmiutil.log
> 2_max/failed/meta-world-pkgdata.log
> 2_max/failed/nativesdk-zeroc-ice.log
> 2_max/failed/netmap-modules.log
> 2_max/failed/proxy-libintl.log
> 2_max/failed/remake.log
> 2_max/failed/zeroc-ice.log
> 
> 3_min/failed/core-image-minimal-initramfs.log
> 3_min/failed/core-image-rt-sdk.log
> 3_min/failed/core-image-rt.log
> 3_min/failed/core-image-sato-dev.log
> 3_min/failed/core-image-sato-sdk-ptest.log
> 3_min/failed/core-image-sato-sdk.log
> 3_min/failed/core-image-testmaster-initramfs.log
> 3_min/failed/cyrus-sasl.log
> 3_min/failed/fontforge.log
> 3_min/failed/gtkmathview.log
> 3_min/failed/ipmiutil.log
> 3_min/failed/meta-world-pkgdata.log
> 3_min/failed/nativesdk-zeroc-ice.log
> 3_min/failed/perf.log
> 3_min/failed/proxy-libintl.log
> 3_min/failed/remake.log
> 3_min/failed/sblim-sfcb.log
> 3_min/failed/zeroc-ice.log
> -- 
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com



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


signature.asc
Description: Digital signature
-- 

Re: [OE-core] Issues installing GTK based packages

[Jussi Kukkonen]

On 11 April 2016 at 08:46, Gary Thomas  wrote:

> When installing epiphany into an existing system, I'm now
> getting these errors:
>   Configuring libgtk-3.0.
>   ///var/lib/opkg/info/libgtk-3.0.postinst: line 3: glib-compile-schemas:
> not found
>   Configuring gsettings-desktop-schemas.
>   ///var/lib/opkg/info/gsettings-desktop-schemas.postinst: line 2:
> glib-compile-schemas: not found
>   Configuring epiphany.
>   ///var/lib/opkg/info/epiphany.postinst: line 2: glib-compile-schemas:
> not found
>
> I believe this is because glib-compile-schemas was moved from
> glib-2.0-utils to glib-2.0-dev by this change (Poky)
>
> commit cc97d5760100415ed22fa329e8962e5f37b8d741
> Author: Jussi Kukkonen 
> Date:   Wed Mar 23 10:59:08 2016 +0200
>
> glib-2.0: Fix packaging
>
> * move gdbus-codegen to ${PN}-codegen
> * move other development tools and data files to ${PN}-dev
> * remove references to non-existent paths
>
> (From OE-Core rev: 351064e9c5deb6411c8a0d40ebd4fd4f83299d4e)
>
> Signed-off-by: Jussi Kukkonen 
> Signed-off-by: Richard Purdie 
>
> Installing glib-2.0-dev just to get this tool doesn't seem reasonable as
> it hauls in a boatload of other packages, including bash and friends, which
> I don't want on my target.
>

That's a valid point, I did not realize schema XML compilation was done on
postinst (instead of build time). I'll fix this.

Thanks,
  Jussi

Filed as bug #9431
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> 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