Re: [OE-core] [PATCH] busybox.inc: Add sanity check to test if the suid binary provides sh

[Andrej Valek]

I don't think so, that adding bbfatal into this recipe is a good
solution. Someone could build the busybox with /bin/sh linking into
.suid eg. for more secure. We can leave live with this one as before.

Andrej

On 11/09/2017 02:25 PM, Nathan Rossi wrote:
> Add a sanity check during the do_compile task to fail if the suid
> busybox provides /bin/sh. This is considered as a hard fail since not
> only is providing sh as suid problematic for security reasons but also
> because the sh configured for suid is less functional than the nosuid
> configured sh and breaks a number of required features (e.g. 64-bit
> test).
> 
> Signed-off-by: Nathan Rossi 
> Cc: Ross Burton 
> ---
>  meta/recipes-core/busybox/busybox.inc | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/meta/recipes-core/busybox/busybox.inc 
> b/meta/recipes-core/busybox/busybox.inc
> index 4012f921c6..157aea3968 100644
> --- a/meta/recipes-core/busybox/busybox.inc
> +++ b/meta/recipes-core/busybox/busybox.inc
> @@ -183,6 +183,12 @@ do_compile() {
>   oe_runmake busybox.links
>   mv busybox.links busybox.links.$s
>   done
> +
> + # hard fail if sh is being linked to the suid busybox (detects 
> bug 10346)
> + if grep -q -x "/bin/sh" busybox.links.suid; then
> + bbfatal "busybox suid binary incorrectly provides 
> /bin/sh"
> + fi
> +
>   # copy .config.orig back to .config, because the install 
> process may check this file
>   cp .config.orig .config
>   # cleanup
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] gcc6: enable FL_LPAE flag for armv7ve cores

[Andre McCurdy]

The following commit added the FL_LPAE flag to FL_FOR_ARCH7VE, but
neglected to also add it to the armv7ve compatible cores defined in
arm-cores.def.

  
https://github.com/gcc-mirror/gcc/commit/af2d9b9e58e8be576c53d94f30c48c68146b0c98

The result is that gcc 6.4 now refuses to allow -march=armv7ve and
-mcpu=XXX to be used together, even when -mcpu is set to an armv7ve
compatible core:

  arm-linux-gnueabi-gcc -march=armv7ve -mcpu=cortex-a7 -Werror ...
  error: switch -mcpu=cortex-a7 conflicts with -march=armv7ve switch [-Werror]

Fix by defining flags for armv7ve compatible cores directly from
FL_FOR_ARCH7VE, rather than re-creating the armv7ve flags
independently by combining FL_FOR_ARCH7A with the armv7ve specific
FL_THUMB_DIV and FL_ARM_DIV flags.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-devtools/gcc/gcc-6.4.inc  |  1 +
 ...001-enable-FL_LPAE-flag-for-armv7ve-cores.patch | 67 ++
 2 files changed, 68 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-6.4/backport/0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch

diff --git a/meta/recipes-devtools/gcc/gcc-6.4.inc 
b/meta/recipes-devtools/gcc/gcc-6.4.inc
index a42b7d8..942b39f 100644
--- a/meta/recipes-devtools/gcc/gcc-6.4.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.4.inc
@@ -80,6 +80,7 @@ SRC_URI = "\
 "
 BACKPORTS = "\
file://CVE-2016-6131.patch \
+   file://0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch \
 "
 SRC_URI[md5sum] = "11ba51a0cfb8471927f387c8895fe232"
 SRC_URI[sha256sum] = 
"850bf21eafdfe5cd5f6827148184c08c4a0852a37ccf36ce69855334d2c914d4"
diff --git 
a/meta/recipes-devtools/gcc/gcc-6.4/backport/0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch
 
b/meta/recipes-devtools/gcc/gcc-6.4/backport/0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch
new file mode 100644
index 000..9ee029c
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-6.4/backport/0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch
@@ -0,0 +1,67 @@
+From 22fcc126fad61a8e9ddaaabbc8036644273642dc Mon Sep 17 00:00:00 2001
+From: ktkachov 
+Date: Thu, 9 Nov 2017 14:34:28 +
+Subject: [PATCH] enable FL_LPAE flag for armv7ve cores
+
+The following commit added the FL_LPAE flag to FL_FOR_ARCH7VE, but
+neglected to also add it to the armv7ve compatible cores defined in
+arm-cores.def.
+
+  
https://github.com/gcc-mirror/gcc/commit/af2d9b9e58e8be576c53d94f30c48c68146b0c98
+
+The result is that gcc 6.4 now refuses to allow -march=armv7ve and
+-mcpu=XXX to be used together, even when -mcpu is set to an armv7ve
+compatible core:
+
+  arm-linux-gnueabi-gcc -march=armv7ve -mcpu=cortex-a7 -Werror ...
+  error: switch -mcpu=cortex-a7 conflicts with -march=armv7ve switch [-Werror]
+
+Fix by defining flags for armv7ve compatible cores directly from
+FL_FOR_ARCH7VE, rather than re-creating the armv7ve flags
+independently by combining FL_FOR_ARCH7A with the armv7ve specific
+FL_THUMB_DIV and FL_ARM_DIV flags.
+
+Upstream-Status: Backport
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-6-branch@254584 
138bc75d-0d04-0410-961f-82ee72b054a4
+
+Signed-off-by: Andre McCurdy 
+---
+ gcc/config/arm/arm-cores.def | 12 ++--
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/gcc/config/arm/arm-cores.def b/gcc/config/arm/arm-cores.def
+index 829b839..ca37e6f 100644
+--- a/gcc/config/arm/arm-cores.def
 b/gcc/config/arm/arm-cores.def
+@@ -145,12 +145,12 @@ 
ARM_CORE("cortex-m0plus.small-multiply",cortexm0plussmallmultiply, cortexm0plus,
+ /* V7 Architecture Processors */
+ ARM_CORE("generic-armv7-a",   genericv7a, genericv7a, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7A), cortex)
+ ARM_CORE("cortex-a5", cortexa5, cortexa5, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7A), cortex_a5)
+-ARM_CORE("cortex-a7", cortexa7, cortexa7, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV | FL_FOR_ARCH7A), 
cortex_a7)
++ARM_CORE("cortex-a7", cortexa7, cortexa7, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7VE), cortex_a7)
+ ARM_CORE("cortex-a8", cortexa8, cortexa8, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7A), cortex_a8)
+ ARM_CORE("cortex-a9", cortexa9, cortexa9, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7A), cortex_a9)
+-ARM_CORE("cortex-a12",cortexa12, cortexa17,   7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV | FL_FOR_ARCH7A), 
cortex_a12)
+-ARM_CORE("cortex-a15",cortexa15, cortexa15,   7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV | FL_FOR_ARCH7A), 
cortex_a15)
+-ARM_CORE("cortex-a17",cortexa17, cortexa17,   7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV | FL_FOR_ARCH7A), 
cortex_a12)
++ARM_CORE("cortex-a12",

[OE-core] ✗ patchtest: failure for gcc6: enable FL_LPAE flag for armv7ve cores

[Patchwork]

== Series Details ==

Series: gcc6: enable FL_LPAE flag for armv7ve cores
Revision: 1
URL   : https://patchwork.openembedded.org/series/9693/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Upstream-Status is in incorrect format 
[test_upstream_status_presence_format] 
  Suggested fixFix Upstream-Status format in 
0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch
  Current  UpStream-Status: Backport
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH] systemd: create wheel sysuser group offline

[Andre McCurdy]

The default systemd-tmpfiles config file expects to be able to create
files etc belonging to the wheel system group. Currently the wheel
group is created at run time by systemd-sysusers, but that doesn't
happen if systemd-sysusers is disabled (as it currently is by default
when building with musl libc).

Signed-off-by: Andre McCurdy 
---
 meta/recipes-core/systemd/systemd_234.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_234.bb 
b/meta/recipes-core/systemd/systemd_234.bb
index 81a9509..7fdb65f 100644
--- a/meta/recipes-core/systemd/systemd_234.bb
+++ b/meta/recipes-core/systemd/systemd_234.bb
@@ -333,7 +333,7 @@ USERADD_PARAM_${PN} += 
"${@bb.utils.contains('PACKAGECONFIG', 'networkd', '--sys
 USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'coredump', 
'--system -d / -M --shell /bin/nologin systemd-coredump;', '', d)}"
 USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'resolved', 
'--system -d / -M --shell /bin/nologin systemd-resolve;', '', d)}"
 USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'polkit', 
'--system --no-create-home --user-group --home-dir ${sysconfdir}/polkit-1 
polkitd;', '', d)}"
-GROUPADD_PARAM_${PN} = "-r lock; -r systemd-journal"
+GROUPADD_PARAM_${PN} = "-r lock; -r systemd-journal; -r wheel"
 USERADD_PARAM_${PN}-extra-utils += "--system -d / -M --shell /bin/nologin 
systemd-bus-proxy;"
 
 FILES_${PN}-analyze = "${bindir}/systemd-analyze"
-- 
1.9.1

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

[OE-core] [PATCH] gcc6: enable FL_LPAE flag for armv7ve cores

[Andre McCurdy]

The following commit added the FL_LPAE flag to FL_FOR_ARCH7VE, but
neglected to also add it to the armv7ve compatible cores defined in
arm-cores.def.

  
https://github.com/gcc-mirror/gcc/commit/af2d9b9e58e8be576c53d94f30c48c68146b0c98

The result is that gcc 6.4 now refuses to allow -march=armv7ve and
-mcpu=XXX to be used together, even when -mcpu is set to an armv7ve
compatible core:

  arm-linux-gnueabi-gcc -march=armv7ve -mcpu=cortex-a7 -Werror ...
  error: switch -mcpu=cortex-a7 conflicts with -march=armv7ve switch [-Werror]

Fix by defining flags for armv7ve compatible cores directly from
FL_FOR_ARCH7VE, rather than re-creating the armv7ve flags
independently by combining FL_FOR_ARCH7A with the armv7ve specific
FL_THUMB_DIV and FL_ARM_DIV flags.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-devtools/gcc/gcc-6.4.inc  |  1 +
 ...001-enable-FL_LPAE-flag-for-armv7ve-cores.patch | 67 ++
 2 files changed, 68 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-6.4/backport/0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch

diff --git a/meta/recipes-devtools/gcc/gcc-6.4.inc 
b/meta/recipes-devtools/gcc/gcc-6.4.inc
index a42b7d8..942b39f 100644
--- a/meta/recipes-devtools/gcc/gcc-6.4.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.4.inc
@@ -80,6 +80,7 @@ SRC_URI = "\
 "
 BACKPORTS = "\
file://CVE-2016-6131.patch \
+   file://0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch \
 "
 SRC_URI[md5sum] = "11ba51a0cfb8471927f387c8895fe232"
 SRC_URI[sha256sum] = 
"850bf21eafdfe5cd5f6827148184c08c4a0852a37ccf36ce69855334d2c914d4"
diff --git 
a/meta/recipes-devtools/gcc/gcc-6.4/backport/0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch
 
b/meta/recipes-devtools/gcc/gcc-6.4/backport/0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch
new file mode 100644
index 000..9ee029c
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-6.4/backport/0001-enable-FL_LPAE-flag-for-armv7ve-cores.patch
@@ -0,0 +1,67 @@
+From 22fcc126fad61a8e9ddaaabbc8036644273642dc Mon Sep 17 00:00:00 2001
+From: ktkachov 
+Date: Thu, 9 Nov 2017 14:34:28 +
+Subject: [PATCH] enable FL_LPAE flag for armv7ve cores
+
+The following commit added the FL_LPAE flag to FL_FOR_ARCH7VE, but
+neglected to also add it to the armv7ve compatible cores defined in
+arm-cores.def.
+
+  
https://github.com/gcc-mirror/gcc/commit/af2d9b9e58e8be576c53d94f30c48c68146b0c98
+
+The result is that gcc 6.4 now refuses to allow -march=armv7ve and
+-mcpu=XXX to be used together, even when -mcpu is set to an armv7ve
+compatible core:
+
+  arm-linux-gnueabi-gcc -march=armv7ve -mcpu=cortex-a7 -Werror ...
+  error: switch -mcpu=cortex-a7 conflicts with -march=armv7ve switch [-Werror]
+
+Fix by defining flags for armv7ve compatible cores directly from
+FL_FOR_ARCH7VE, rather than re-creating the armv7ve flags
+independently by combining FL_FOR_ARCH7A with the armv7ve specific
+FL_THUMB_DIV and FL_ARM_DIV flags.
+
+UpStream-Status: Backport
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-6-branch@254584 
138bc75d-0d04-0410-961f-82ee72b054a4
+
+Signed-off-by: Andre McCurdy 
+---
+ gcc/config/arm/arm-cores.def | 12 ++--
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/gcc/config/arm/arm-cores.def b/gcc/config/arm/arm-cores.def
+index 829b839..ca37e6f 100644
+--- a/gcc/config/arm/arm-cores.def
 b/gcc/config/arm/arm-cores.def
+@@ -145,12 +145,12 @@ 
ARM_CORE("cortex-m0plus.small-multiply",cortexm0plussmallmultiply, cortexm0plus,
+ /* V7 Architecture Processors */
+ ARM_CORE("generic-armv7-a",   genericv7a, genericv7a, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7A), cortex)
+ ARM_CORE("cortex-a5", cortexa5, cortexa5, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7A), cortex_a5)
+-ARM_CORE("cortex-a7", cortexa7, cortexa7, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV | FL_FOR_ARCH7A), 
cortex_a7)
++ARM_CORE("cortex-a7", cortexa7, cortexa7, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7VE), cortex_a7)
+ ARM_CORE("cortex-a8", cortexa8, cortexa8, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7A), cortex_a8)
+ ARM_CORE("cortex-a9", cortexa9, cortexa9, 7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH7A), cortex_a9)
+-ARM_CORE("cortex-a12",cortexa12, cortexa17,   7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV | FL_FOR_ARCH7A), 
cortex_a12)
+-ARM_CORE("cortex-a15",cortexa15, cortexa15,   7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV | FL_FOR_ARCH7A), 
cortex_a15)
+-ARM_CORE("cortex-a17",cortexa17, cortexa17,   7A, 
ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV | FL_FOR_ARCH7A), 
cortex_a12)
++ARM_CORE("cortex-a12",

Re: [OE-core] State of bitbake world, Failed tasks 2017-10-31

[akuster808]

On 11/01/2017 08:30 AM, Khem Raj wrote:
> Hi Martin/Armin
>
> I looked at the first report with musl from Martin. Most of the
> failures are familiar except 2 I think which I plan to look at. I
> haven't blacklisted them intentionally, to get annoyed enough to keep
> fixing them as time permits.
> infact none of the build failures are due to musl limitation. So we
> need to fix the applications to behave. We can use "musl:" token in
> blacklist message so, if we need to fix one of these recipes them we
> know what to look for
> to find not yet ported recipes.
thanks. I going to grab the netkit packages.

- armin
> On Wed, Nov 1, 2017 at 2:59 AM, Martin Jansa  wrote:
>> Hi Armin,
>>
>> I'll leave this question to Khem, this was my just 2nd build with musl, Khem
>> is doing musl builds for very long time and fixing all the issue he finds,
>> maybe some of the issues detected in world builds already have fixes in
>> Khem's queue.
>>
>> Regards,
>>
>> On Wed, Nov 1, 2017 at 5:53 AM, akuster808  wrote:
>>> Martin,
>>>
>>>
>>> On 10/31/2017 01:58 PM, Martin Jansa wrote:
>>>
>>> With 2 pending patches from Khem to build systemd with musl:
>>>
>>> 62c7c98 systemd: Fix build on musl
>>> de68252 systemd: Fix build with musl/mips64
>>>
>>> the qemux86+musl build was able to progress much further and fewer ERROR
>>> messages were shown. Basically only uim recipe now depends on glibc and
>>> fails to be included in build queue:
>>>
>>>
>>> Are we going to blacklist the recipes failing via musl? is there
>>> blacklisting by TCLIB?
>>>
>>> - armin
>>>
>>> Summary: There were 55 ERROR messages shown, returning a non-zero exit
>>> code.
>>>
>>> Parsing of 2356 .bb files complete (2355 cached, 1 parsed). 3228 targets,
>>> 48 skipped, 0 masked, 0 errors.
>>> NOTE: Resolving any missing task queue dependencies
>>> ERROR: Nothing RPROVIDES 'glibc-gconv-euc-jp' (but
>>> /home/jenkins/oe/world/shr-core/meta-openembedded/meta-oe/recipes-support/uim/uim_1.8.6.bb
>>> RDEPENDS on or otherwise requires it)
>>> NOTE: Runtime target 'glibc-gconv-euc-jp' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['glibc-gconv-euc-jp']
>>> NOTE: Runtime target 'uim-dev' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['uim-dev',
>>> 'glibc-gconv-euc-jp']
>>> NOTE: Runtime target 'uim' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['uim', 'glibc-gconv-euc-jp']
>>> NOTE: Runtime target 'libuim0' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['libuim0',
>>> 'glibc-gconv-euc-jp']
>>> ERROR: Nothing RPROVIDES 'glibc-utils' (but
>>> /home/jenkins/oe/world/shr-core/meta-openembedded/meta-oe/recipes-support/uim/uim_1.8.6.bb
>>> RDEPENDS on or otherwise requires it)
>>> NOTE: Runtime target 'glibc-utils' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['glibc-utils']
>>>
>>> Some logs weren't uploaded to the http://logs.nslu2-linux.org/buildlogs
>>> because it run out of disk space again.
>>>
>>> http://www.openembedded.org/wiki/Bitbake_World_Status
>>>
>>> == Number of issues - stats ==
>>> {| class='wikitable'
>>> !|Date   !!colspan='4'|Failed tasks 
>>> !!|Signatures   
>>> !!colspan='15'|QA !!Comment
>>> |-
>>> ||  ||qemuarm   ||qemuarm64 ||qemux86   ||qemux86_64
>>> ||all
>>> ||already-stripped  ||libdir||textrel   ||build-deps
>>> ||file-rdeps||version-going-backwards   ||host-user-contaminated
>>> ||installed-vs-shipped  ||unknown-configure-option  
>>> ||symlink-to-sysroot||invalid-pkgconfig ||pkgname   ||ldflags   
>>> ||compile-host-path ||qa_pseudo ||  
>>> |-
>>>
>>>
>>> ||2017-10-30||2 ||6 ||26||1 ||0 ||0 
>>> ||0 ||1 ||0 ||0 ||28
>>> ||2 ||0 ||0 ||0 ||0 
>>> ||0 ||0 ||0 ||158   ||  
>>> 
>>> |}
>>>
>>> == Failed tasks 2017-10-30 ==
>>>
>>> INFO: jenkins-job.sh-1.8.39 Complete log available at
>>> http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.report.20171031_095148.log
>>>
>>> === common (0) ===
>>>
>>> === common-x86 (0) ===
>>>
>>> === qemuarm (2) ===
>>> *
>>> meta-openembedded/meta-oe/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb:do_compile
>>> *
>>> openembedded-core/meta/recipes-core/glibc/glibc-locale_2.26.bb:do_package_qa
>>>
>>> === qemuarm64 (5) ===
>>> *
>>> meta-browser/recipes-browser/chromium/chromium_54.0.2810.2.bb:do_compile
>>> *
>>> meta-browser/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb:do_compile
>>> *
>>> meta-openembedded/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.2.bb:do_install
>>> *
>>> 

Re: [OE-core] [PATCH 1/2] systemctl-native: add target.wants to target regex

[Martin Kelly]

Got it, thanks. My patch *should* just convert runtime failures into 
compile-time failures, but it looks like we're seeing actual runtime 
failures, so I'll try to figure out what happened.


On 11/08/2017 12:31 PM, Burton, Ross wrote:

Thanks for reminding me.  :)

1/2 is queued but 2/2 was implicated in a number of systemd-related boot 
failures on the autobuilder 
(https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/553).


I've not yet got around to looking at exactly what sanity test 5 and 7 
do to trigger this.


Ross

On 8 November 2017 at 17:40, Martin Kelly > wrote:


(ping) for this patch series.

On 10/16/2017 09:31 AM, Martin Kelly wrote:

The regex for acceptable systemd WantedBy/RequiredBy targets
does not include
target.wants, so a line like this:

WantedBy=multi-user.target.wants

gets silently ignored, even though it works fine on a real system.

Signed-off-by: Martin Kelly >
---
   meta/recipes-core/systemd/systemd-systemctl/systemctl | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/meta/recipes-core/systemd/systemd-systemctl/systemctl
b/meta/recipes-core/systemd/systemd-systemctl/systemctl
index efad14ce17..6e5a1b7181 100755
--- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
+++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
@@ -108,7 +108,7 @@ for service in $services; do
         # If any new unit types are added to systemd they
should be added
         # to this regular expression.
- 
  unit_types_re='\.\(service\|socket\|device\|mount\|automount\|swap\|target\|path\|timer\|snapshot\)\s*$'
+ 
  unit_types_re='\.\(service\|socket\|device\|mount\|automount\|swap\|target\|target\.wants\|path\|timer\|snapshot\)\s*$'

         if [ "$action" = "preset" ]; then
                 action=`egrep -sh  $service
$ROOT/etc/systemd/user-preset/*.preset | cut -f1 -d' '`
                 if [ -z "$action" ]; then

-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core




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

Re: [OE-core] [PATCH 1/5] binutils: Convert SRC_URI and SRCREV to weak defines

[Khem Raj]

On Thu, Nov 9, 2017 at 12:54 PM, Burton, Ross  wrote:
> How does this help?  A bbappend is parsed after the bb so it can just assign
> to SRCREV.
>
> Also is it actually useful to change the git url but apply the same patches?
>

yes, this helps with using local forks of upstream and at the same
time apply the
patches from OE-Core being on same version. Especially for new archirectures
where all support may not be upstream.

> Ross
>
> On 9 November 2017 at 01:58, Khem Raj  wrote:
>>
>> This makes it easy to override them in bbappends
>>
>> Signed-off-by: Khem Raj 
>> ---
>>  meta/recipes-devtools/binutils/binutils-2.29.inc | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-devtools/binutils/binutils-2.29.inc
>> b/meta/recipes-devtools/binutils/binutils-2.29.inc
>> index 27d46eb088..35f76cba6d 100644
>> --- a/meta/recipes-devtools/binutils/binutils-2.29.inc
>> +++ b/meta/recipes-devtools/binutils/binutils-2.29.inc
>> @@ -18,9 +18,10 @@ BINUPV = "${@binutils_branch_version(d)}"
>>
>>  UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P\d+_(\d_?)*)"
>>
>> -SRCREV = "37e991bb143ca2106330bcdc625590d53838b7a1"
>> +SRCREV ?= "37e991bb143ca2106330bcdc625590d53838b7a1"
>> +BINUTILS_GIT_URI ?=
>> "git://sourceware.org/git/binutils-gdb.git;branch=binutils-${BINUPV}-branch;protocol=git"
>>  SRC_URI = "\
>> -
>> git://sourceware.org/git/binutils-gdb.git;branch=binutils-${BINUPV}-branch;protocol=git
>> \
>> + ${BINUTILS_GIT_URI} \
>>   file://0003-configure-widen-the-regexp-for-SH-architectures.patch \
>>   file://0004-Point-scripts-location-to-libdir.patch \
>>
>> file://0005-Only-generate-an-RPATH-entry-if-LD_RUN_PATH-is-not-e.patch \
>> --
>> 2.15.0
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/5] binutils: Convert SRC_URI and SRCREV to weak defines

[Burton, Ross]

How does this help?  A bbappend is parsed after the bb so it can just
assign to SRCREV.

Also is it actually useful to change the git url but apply the same patches?

Ross

On 9 November 2017 at 01:58, Khem Raj  wrote:

> This makes it easy to override them in bbappends
>
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-devtools/binutils/binutils-2.29.inc | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-devtools/binutils/binutils-2.29.inc
> b/meta/recipes-devtools/binutils/binutils-2.29.inc
> index 27d46eb088..35f76cba6d 100644
> --- a/meta/recipes-devtools/binutils/binutils-2.29.inc
> +++ b/meta/recipes-devtools/binutils/binutils-2.29.inc
> @@ -18,9 +18,10 @@ BINUPV = "${@binutils_branch_version(d)}"
>
>  UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P\d+_(\d_?)*)"
>
> -SRCREV = "37e991bb143ca2106330bcdc625590d53838b7a1"
> +SRCREV ?= "37e991bb143ca2106330bcdc625590d53838b7a1"
> +BINUTILS_GIT_URI ?= "git://sourceware.org/git/binutils-gdb.git;branch=
> binutils-${BINUPV}-branch;protocol=git"
>  SRC_URI = "\
> - git://sourceware.org/git/binutils-gdb.git;branch=
> binutils-${BINUPV}-branch;protocol=git \
> + ${BINUTILS_GIT_URI} \
>   file://0003-configure-widen-the-regexp-for-SH-architectures.patch \
>   file://0004-Point-scripts-location-to-libdir.patch \
>   file://0005-Only-generate-an-RPATH-entry-if-LD_RUN_PATH-is-not-e.patch
> \
> --
> 2.15.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution

[Leonardo Sandoval]

On Thu, 26 Oct 2017 10:33:19 -0700
leonardo.sandoval.gonza...@linux.intel.com wrote:

RP indicated two scenarios that this v1 won't work:

1) if oe-selftest comes from a tarball (together with the other repo files)
2) if other no-poky layers are present on current BBLAYERS.

I will review both items and send a v2.

Leo


> From: Leonardo Sandoval 
> 
> The main idea is to isolate the oe-selftest execution so neither the current
> build dir nor the configuration data is touch/polluted. This approach uses
> a wrapper script (which is the one presented on this commit) which creates
> a unique directory and inside it does a shallow of repo(s) (OE-Core and 
> Bitbake),
> re-initializes the enviroment (re-sources oe-init-build-env) and finally 
> launches
> the oe-selftest-internal (which used to be oe-selftest) command, passing 
> command
> arguments to the latter.
> 
> The new build directory created when re-initializing the enviroment has the
> same configuration data (local.conf, auto.conf, site.conf) as the
> main build directory. The latter means that one can set DL_DIR and SSTATE_DIR
> into /conf/site.conf and the oe-selftest execution will use 
> this.
> 
> [YOCTO #11429]
> 
> Signed-off-by: Leonardo Sandoval 
> ---
>  scripts/oe-selftest  | 102 
> +++
>  scripts/oe-selftest-internal |  75 +++
>  2 files changed, 129 insertions(+), 48 deletions(-)
>  create mode 100755 scripts/oe-selftest-internal
> 
> diff --git a/scripts/oe-selftest b/scripts/oe-selftest
> index 1bf860a415..f3ce89cedb 100755
> --- a/scripts/oe-selftest
> +++ b/scripts/oe-selftest
> @@ -1,5 +1,7 @@
> -#!/usr/bin/env python3
> +#!/bin/sh
>  
> +# scripts/oe-selftest: calls oe-selftest-internal in a isolated environment
> +#
>  # Copyright (c) 2013-2017 Intel Corporation
>  #
>  # This program is free software; you can redistribute it and/or modify
> @@ -14,62 +16,66 @@
>  # You should have received a copy of the GNU General Public License along
>  # with this program; if not, write to the Free Software Foundation, Inc.,
>  # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> +#
> +
> +# Variable definitions
> +ORIGBUILDDIR="$BUILDDIR"
> +OESELFTESTSCRIPTDIR="$(which oe-selftest)"
> +SCRIPTSDIR="$(dirname $OESELFTESTSCRIPTDIR)"
> +OECOREDIR="$(dirname $SCRIPTSDIR)"
> +
> +# oe-selftest-$$ related
> +OESELFTESTDIR="$ORIGBUILDDIR/oe-selftest-$$"
> +OESELFTESTOECOREDIR="$OESELFTESTDIR/openembedded-core"
> +OESELFTESTBUILDDIR="$OESELFTESTDIR/openembedded-core/build"
> +TEMPLATEPATH="$OESELFTESTDIR/template/conf"
>  
> -# DESCRIPTION
> -# This script runs tests defined in meta/lib/oeqa/selftest/
> -# It's purpose is to automate the testing of different bitbake tools.
> -# To use it you just need to source your build environment setup script and
> -# add the meta-selftest layer to your BBLAYERS.
> -# Call the script as: "oe-selftest -a" to run all the tests in 
> meta/lib/oeqa/selftest/
> -# Call the script as: "oe-selftest -r .." to run just 
> a single test
> -# E.g: "oe-selftest -r bblayers.BitbakeLayers" will run just the 
> BitbakeLayers class from meta/lib/oeqa/selftest/bblayers.py
> +# 0. Return immediately in case no test execution
> +ADDTESTS="$(echo "$@" | grep -i '\-a')"
> +SOMETESTS="$(echo "$@" | grep -i '\-r')"
> +if [ -z "$ADDTESTS" -a -z "$SOMETESTS" ]; then
> +if [ -z "$@" ]; then
> + oe-selftest-internal -h
> +else
> + oe-selftest-internal "$@"
> +fi
> +exit 0
> +fi
>  
> +# 1. All work will be done under OESELFTESTDIR
> +mkdir $OESELFTESTDIR && cd $OESELFTESTDIR
>  
> +# 2.1 Shallow clone OE-Core
> +git clone file://$OECOREDIR --depth 1 $OESELFTESTOECOREDIR
>  
> -import os
> -import sys
> -import argparse
> -import logging
> +# 2.2 Shallow clone bitbake if necessary (if OE-Core is embedded on a combo 
> repo, like Poky, there is no need)
> +if [ ! -d "$OESELFTESTOECOREDIR/bitbake" ]; then
> +git clone file://$OECOREDIR/bitbake --depth 1 
> $OESELFTESTOECOREDIR/bitbake
> +fi
>  
> -scripts_path = os.path.dirname(os.path.realpath(__file__))
> -lib_path = scripts_path + '/lib'
> -sys.path = sys.path + [lib_path]
> -import argparse_oe
> -import scriptutils
> -import scriptpath
> -scriptpath.add_oe_lib_path()
> -scriptpath.add_bitbake_lib_path()
> +# 3. Template: create template directory based on BUILDIR/conf/local.conf
> +mkdir -p $TEMPLATEPATH
> +cp $ORIGBUILDDIR/conf/local.conf $TEMPLATEPATH/local.conf.sample
>  
> -from oeqa.utils import load_test_components
> -from oeqa.core.exception import OEQAPreRun
> +# 4. re-initialized environment with new metadata and templateconf 
> environement
> +cd $OESELFTESTOECOREDIR
> +export TEMPLATEPATH && source ./oe-init-build-env $OESELFTESTBUILDDIR
>  
> -logger = scriptutils.logger_create('oe-selftest', stream=sys.stdout)
> +# 5. Respect any site.conf and/or auto.conf and place it into 

[OE-core] [rocko][PATCH 4/4] sshcontrol.py: in copy_to() always use scp

[Stephano Cetola]

From: Erik Botö 

The current implementation is broken when the localpath is a link.
Then only a symlink would be created on the target, instead of copying
the actual file.

[YOCTO #11524]

Signed-off-by: Erik Botö 
Signed-off-by: Stephano Cetola 
---
 meta/lib/oeqa/utils/sshcontrol.py | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oeqa/utils/sshcontrol.py 
b/meta/lib/oeqa/utils/sshcontrol.py
index 05d6502550..d292893c08 100644
--- a/meta/lib/oeqa/utils/sshcontrol.py
+++ b/meta/lib/oeqa/utils/sshcontrol.py
@@ -150,12 +150,9 @@ class SSHControl(object):
 
 def copy_to(self, localpath, remotepath):
 if os.path.islink(localpath):
-link = os.readlink(localpath)
-dst_dir, dst_base = os.path.split(remotepath)
-return self.run("cd %s; ln -s %s %s" % (dst_dir, link, dst_base))
-else:
-command = self.scp + [localpath, '%s@%s:%s' % (self.user, self.ip, 
remotepath)]
-return self._internal_run(command, ignore_status=False)
+localpath = os.path.dirname(localpath) + "/" + 
os.readlink(localpath)
+command = self.scp + [localpath, '%s@%s:%s' % (self.user, self.ip, 
remotepath)]
+return self._internal_run(command, ignore_status=False)
 
 def copy_from(self, remotepath, localpath):
 command = self.scp + ['%s@%s:%s' % (self.user, self.ip, remotepath), 
localpath]
-- 
2.14.2

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

[OE-core] [rocko][PATCH 3/4] masterimage.py: rename parameter "params" in start() to "extra_bootparams"

[Stephano Cetola]

From: Erik Botö 

This matches how it is called, and how it is named in qmeu target.

[YOCTO #11524]

Signed-off-by: Erik Botö 
Signed-off-by: Stephano Cetola 
---
 meta/lib/oeqa/controllers/masterimage.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/controllers/masterimage.py 
b/meta/lib/oeqa/controllers/masterimage.py
index e2ff3f12c2..a2912fc568 100644
--- a/meta/lib/oeqa/controllers/masterimage.py
+++ b/meta/lib/oeqa/controllers/masterimage.py
@@ -143,7 +143,7 @@ class 
MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
 def _deploy(self):
 pass
 
-def start(self, params=None):
+def start(self, extra_bootparams=None):
 bb.plain("%s - boot test image on target" % self.pn)
 self._start()
 # set the ssh object for the target/test image
-- 
2.14.2

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

[OE-core] [rocko][PATCH 1/4] masterimage.py: fix issue with calling reboot on masterimage/DUT

[Stephano Cetola]

From: Erik Botö 

On systemd systems calling reboot over an ssh connection doesn't
return as expected causing an exception, therefore wrap the call
to reboot in order to avoid this issue.

Also sync the filesystems before rebooting cause otherwise, it will be
done as part of the reboot and could take a very long time and testimage
will fail to access the machine. This issue was observed consistently with
one of our rootfs at Pelagicore.

[YOCTO #11524]

Signed-off-by: Erik Botö 
Signed-off-by: Stephano Cetola 
---
 meta/lib/oeqa/controllers/masterimage.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/controllers/masterimage.py 
b/meta/lib/oeqa/controllers/masterimage.py
index 07418fcda1..fe90967923 100644
--- a/meta/lib/oeqa/controllers/masterimage.py
+++ b/meta/lib/oeqa/controllers/masterimage.py
@@ -108,7 +108,7 @@ class 
MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
 time.sleep(10)
 self.power_ctl("cycle")
 else:
-status, output = conn.run("reboot")
+status, output = conn.run("sync; { sleep 1; reboot; } > /dev/null 
&")
 if status != 0:
 bb.error("Failed rebooting target and no power control command 
defined. You need to manually reset the device.\n%s" % output)
 
-- 
2.14.2

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

[OE-core] [rocko][PATCH 0/4] Backport masterimage fixes

[Stephano Cetola]

Backporting fixes since I never got these into 2.4.

Requested by erik.b...@pelagicore.com.

This fixes [YOCTO #11524]

Erik Botö (4):
  masterimage.py: fix issue with calling reboot on masterimage/DUT
  masterimage.py: fix stop()
  masterimage.py: rename parameter "params" in start() to
"extra_bootparams"
  sshcontrol.py: in copy_to() always use scp

 meta/lib/oeqa/controllers/masterimage.py | 6 +++---
 meta/lib/oeqa/utils/sshcontrol.py| 9 +++--
 2 files changed, 6 insertions(+), 9 deletions(-)

-- 
2.14.2

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

[OE-core] [rocko][PATCH 2/4] masterimage.py: fix stop()

[Stephano Cetola]

From: Erik Botö 

The stop() function is called in the context of the masterimage,
so self.master should be used instead of self.connection which is
undefined at that time.

[YOCTO #11524]

Signed-off-by: Erik Botö 
Signed-off-by: Stephano Cetola 
---
 meta/lib/oeqa/controllers/masterimage.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/controllers/masterimage.py 
b/meta/lib/oeqa/controllers/masterimage.py
index fe90967923..e2ff3f12c2 100644
--- a/meta/lib/oeqa/controllers/masterimage.py
+++ b/meta/lib/oeqa/controllers/masterimage.py
@@ -156,7 +156,7 @@ class 
MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
 
 def stop(self):
 bb.plain("%s - reboot/powercycle target" % self.pn)
-self.power_cycle(self.connection)
+self.power_cycle(self.master)
 
 
 class SystemdbootTarget(MasterImageHardwareTarget):
-- 
2.14.2

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

Re: [OE-core] [daisy][PATCH v2] wpa_supplicant: fix WPA2 key replay security bug

[Hermida, Isaac]

Ping, is there any plan to include this patch in a short term?

Regards.

On 11/03/2017 01:46 PM, Isaac Hermida wrote:
> WPA2 is vulnerable to replay attacks which result in unauthenticated users
> having access to the network.
>
> * CVE-2017-13077: reinstallation of the pairwise key in the Four-way handshake
>
> * CVE-2017-13078: reinstallation of the group key in the Four-way handshake
>
> * CVE-2017-13079: reinstallation of the integrity group key in the Four-way
> handshake
>
> * CVE-2017-13080: reinstallation of the group key in the Group Key handshake
>
> * CVE-2017-13081: reinstallation of the integrity group key in the Group Key
> handshake
>
> * CVE-2017-13082: accepting a retransmitted Fast BSS Transition Reassociation
> Request and reinstalling the pairwise key while processing it
>
> * CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS)
> PeerKey (TPK) key in the TDLS handshake
>
> * CVE-2017-13087: reinstallation of the group key (GTK) when processing a
> Wireless Network Management (WNM) Sleep Mode Response frame
>
> * CVE-2017-13088: reinstallation of the integrity group key (IGTK) when
> processing a Wireless Network Management (WNM) Sleep Mode Response frame
>
> This is the backport to wpa_supplicant 2.1.
>
> Signed-off-by: Isaac Hermida 
> ---
>   .../wpa-supplicant/wpa-supplicant.inc  |   1 +
>   .../wpa-supplicant/key-replay-cve-multiple.patch   | 944 
> +
>   2 files changed, 945 insertions(+)
>   create mode 100644 
> meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/key-replay-cve-multiple.patch
>
> diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant.inc 
> b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant.inc
> index 2229b8f5e960..de3f926515e6 100644
> --- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant.inc
> +++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant.inc
> @@ -21,6 +21,7 @@ SRC_URI = 
> "http://hostap.epitest.fi/releases/wpa_supplicant-${PV}.tar.gz \
>  file://wpa_supplicant.conf-sane \
>  file://99_wpa_supplicant \
>  file://fix-libnl3-host-contamination.patch \
> +   file://key-replay-cve-multiple.patch \
> "
>   SRC_URI[md5sum] = "e96b8db5a8171cd17a5b2012d6ad7cc7"
>   SRC_URI[sha256sum] = 
> "91632e7e3b49a340ce408e2f978a93546a697383abf2e5a60f146faae9e1b277"
> diff --git 
> a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/key-replay-cve-multiple.patch
>  
> b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/key-replay-cve-multiple.patch
> new file mode 100644
> index ..0bc6a8b9a5e9
> --- /dev/null
> +++ 
> b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/key-replay-cve-multiple.patch
> @@ -0,0 +1,944 @@
> +The WPA2 four-way handshake protocol is vulnerable to replay attacks which 
> can
> +result in unauthenticated clients gaining access to the network.
> +
> +CVE: CVE-2017-13077
> +CVE: CVE-2017-13078
> +CVE: CVE-2017-13079
> +CVE: CVE-2017-13080
> +CVE: CVE-2017-13081
> +CVE: CVE-2017-13082
> +CVE: CVE-2017-13086
> +CVE: CVE-2017-13087
> +CVE: CVE-2017-13088
> +
> +From 7e11b9d657d869ec0736021fd873484c806fa903 Mon Sep 17 00:00:00 2001
> +From: Mathy Vanhoef 
> +Date: Fri, 14 Jul 2017 15:15:35 +0200
> +Subject: [PATCH 1/8] hostapd: Avoid key reinstallation in FT handshake
> +
> +Do not reinstall TK to the driver during Reassociation Response frame
> +processing if the first attempt of setting the TK succeeded. This avoids
> +issues related to clearing the TX/RX PN that could result in reusing
> +same PN values for transmitted frames (e.g., due to CCM nonce reuse and
> +also hitting replay protection on the receiver) and accepting replayed
> +frames on RX side.
> +
> +This issue was introduced by the commit
> +0e84c25434e6a1f283c7b4e62e483729085b78d2 ('FT: Fix PTK configuration in
> +authenticator') which allowed wpa_ft_install_ptk() to be called multiple
> +times with the same PTK. While the second configuration attempt is
> +needed with some drivers, it must be done only if the first attempt
> +failed.
> +
> +Upstream-Status: Backport
> +
> +Signed-off-by: Mathy Vanhoef 
> 
> +---
> + src/ap/wpa_auth.c| 11 +++
> + src/ap/wpa_auth.h|  3 ++-
> + src/ap/wpa_auth_ft.c | 10 ++
> + src/ap/wpa_auth_i.h  |  1 +
> + 4 files changed, 24 insertions(+), 1 deletion(-)
> +
> +diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c
> +index 707a63f0cf63..950d14ea1ca6 100644
> +--- a/src/ap/wpa_auth.c
>  b/src/ap/wpa_auth.c
> +@@ -1555,6 +1555,9 @@ int wpa_auth_sm_event(struct wpa_state_machine *sm, 
> wpa_event event)
> + #else /* CONFIG_IEEE80211R */
> + break;
> + #endif /* CONFIG_IEEE80211R */
> ++case WPA_DRV_STA_REMOVED:
> ++sm->tk_already_set = FALSE;
> ++return 0;
> +

Re: [OE-core] [PATCH] rpm: update to 4.14.0

[Alexander Kanavin]

On 11/08/2017 05:31 PM, Mark Hatle wrote:


BTW. If you really don't want to use debugedit then you could use
something simple like a quick hack to list all sources I wrote some
time ago:
https://lists.fedorahosted.org/archives/list/elfutils-devel@lists.fedor
ahosted.org/message/VZP4G5N2ELYZEDAB3QYLXYHDGX4WMCUF/
(see the dwarfsrcfiles.c attachement)


This may very well do what we need.   Our output does not depend on RPM (or any
specific package manager.)  We had simply been using the debugedit from RPM as
it was the best tool for the job.  Now that GCC has the debug-prefix-map option,
we no longer really need debugedit.


After poking some more at elfutils/binutils, I think that indeed the 
dwarfsrcfiles.c is what we need.


The standard utilities can dump the full debug table content on you, but 
they don't have a simple 'give me all sources' feature. And parsing that 
output is more fragile than I thought: there are 'compile units' and 
there are sources used to form them, and linking the two into a simple 
list of sources isn't easy.


Thanks a lot!

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

Re: [OE-core] State of bitbake world, Failed tasks 2017-11-07

[Martin Jansa]

FYI: You can use PV = "2.0.99+2.1.0-beta3" to make sure that it's sorted
higher than any 2.0.* release and that final 2.1.0 again sorts higher than
this beta3 without PE bump.

On Thu, Nov 9, 2017 at 4:23 PM, akuster808  wrote:

>
>
> On 11/08/2017 11:05 AM, Martin Jansa wrote:
>
> The only change from previous report is slightly newer oe-core and bitbake.
>
> http://www.openembedded.org/wiki/Bitbake_World_Status
>
> == Number of issues - stats ==
> {| class='wikitable'
> !|Date !!colspan='4'|Failed tasks 
> !!|Signatures !!colspan='15'|QA !!Comment
> |-
> ||||qemuarm   ||qemuarm64 ||qemux86   ||qemux86_64
> ||all   ||already-stripped  ||libdir||textrel   ||build-deps  
>   ||file-rdeps||version-going-backwards   ||host-user-contaminated
> ||installed-vs-shipped  ||unknown-configure-option  
> ||symlink-to-sysroot||invalid-pkgconfig ||pkgname   ||ldflags 
>   ||compile-host-path ||qa_pseudo ||  
> |-
> ||2017-11-07  ||3 ||6 ||28||2 ||0 ||0 ||0 
> ||1 ||0 ||0 ||0 ||1   
>   ||0 ||0 ||0 ||0 ||0 
> ||0 ||0 ||365   ||  
> |}
>
> == Failed tasks 2017-11-07 ==
>
> INFO: jenkins-job.sh-1.8.39 Complete log available at 
> http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.report.20171108_081616.log
>
> === common (1) ===
> * 
> meta-openembedded/meta-oe/recipes-support/freerdp/freerdp_git.bb:do_configure
>
> === common-x86 (0) ===
>
> === qemuarm (2) ===
> * 
> meta-openembedded/meta-oe/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb:do_compile
> * meta-qt5/recipes-qt/qt5/qtbase_git.bb:do_package_qa
>
> === qemuarm64 (5) ===
> * meta-browser/recipes-browser/chromium/chromium_54.0.2810.2.bb:do_compile
> * 
> meta-browser/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb:do_compile
> * 
> meta-openembedded/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.2.bb:do_install
> * 
> meta-openembedded/meta-initramfs/recipes-kernel/kexec/kexec-tools-klibc_2.0.2.bb:do_configure
>
>
> * 
> meta-openembedded/meta-oe/recipes-devtools/luajit/luajit_2.0.5.bb:do_compile
>
>
> The Arm64 fix  should be in the 2.1.0 when it releases. The fix is in
> LuaJIT-2.1.0-beta3.  I didn't want to backport (beta) it as it may trigger
> the need for PE when 2.1.0 officially releases.
>
>
>
>
> === qemux86 (27) ===
>
>
> * meta-browser/recipes-mozilla/firefox/firefox_45.9.0esr.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-connectivity/rdist/rdist_6.1.5.bb:do_package
> * 
> meta-openembedded/meta-networking/recipes-daemons/opensaf/opensaf_5.17.07.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.3.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-netkit/netkit-rsh/netkit-rsh_0.17.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-netkit/netkit-telnet/netkit-telnet_0.17.bb:do_configure
> * 
> meta-openembedded/meta-networking/recipes-protocols/mdns/mdns_765.50.9.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-protocols/tsocks/tsocks_1.8beta5.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-support/open-isns/open-isns_0.97.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-connectivity/umip/umip_1.0.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb:do_compile
> * meta-openembedded/meta-oe/recipes-devtools/pm-qa/pm-qa_git.bb:do_compile
> * meta-openembedded/meta-oe/recipes-extended/mraa/mraa_git.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-extended/tiptop/tiptop_2.3.bb:do_compile
> * meta-openembedded/meta-oe/recipes-kernel/crash/crash_7.1.9.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-kernel/minicoredumper/minicoredumper_2.0.0.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-multimedia/alsa/alsa-oss_1.0.17.bb:do_compile
> * 
> meta-openembedded/meta-python/recipes-devtools/python/python3-systemd_234.bb:do_compile
> * 
> meta-openembedded/meta-python/recipes-devtools/python/python-systemd_234.bb:do_compile
> * meta-qt5/recipes-qt/qt5/qtlocation_git.bb:do_compile
> * 
> openembedded-core/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb:do_compile
> * 
> openembedded-core/meta/recipes-graphics/cogl/cogl-1.0_1.22.2.bb:do_compile
> * 
> openembedded-core/meta/recipes-graphics/virglrenderer/virglrenderer_git.bb:do_compile
> * 
> 

Re: [OE-core] State of bitbake world, Failed tasks 2017-11-07

[akuster808]

On 11/08/2017 11:05 AM, Martin Jansa wrote:
> The only change from previous report is slightly newer oe-core and bitbake.
> http://www.openembedded.org/wiki/Bitbake_World_Status
>
> == Number of issues - stats ==
> {| class='wikitable'
> !|Date !!colspan='4'|Failed tasks 
> !!|Signatures !!colspan='15'|QA !!Comment
> |-
> ||||qemuarm   ||qemuarm64 ||qemux86   ||qemux86_64
> ||all   ||already-stripped  ||libdir||textrel   ||build-deps  
>   ||file-rdeps||version-going-backwards   ||host-user-contaminated
> ||installed-vs-shipped  ||unknown-configure-option  
> ||symlink-to-sysroot||invalid-pkgconfig ||pkgname   ||ldflags 
>   ||compile-host-path ||qa_pseudo ||  
> |-
> ||2017-11-07  ||3 ||6 ||28||2 ||0 ||0 ||0 
> ||1 ||0 ||0 ||0 ||1   
>   ||0 ||0 ||0 ||0 ||0 
> ||0 ||0 ||365   ||  
> |}
>
> == Failed tasks 2017-11-07 ==
>
> INFO: jenkins-job.sh-1.8.39 Complete log available at 
> http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.report.20171108_081616.log
>
> === common (1) ===
> * 
> meta-openembedded/meta-oe/recipes-support/freerdp/freerdp_git.bb:do_configure
>
> === common-x86 (0) ===
>
> === qemuarm (2) ===
> * 
> meta-openembedded/meta-oe/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb:do_compile
> * meta-qt5/recipes-qt/qt5/qtbase_git.bb:do_package_qa
>
> === qemuarm64 (5) ===
> * meta-browser/recipes-browser/chromium/chromium_54.0.2810.2.bb:do_compile
> * 
> meta-browser/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb:do_compile
> * 
> meta-openembedded/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.2.bb:do_install
> * 
> meta-openembedded/meta-initramfs/recipes-kernel/kexec/kexec-tools-klibc_2.0.2.bb:do_configure

> * 
> meta-openembedded/meta-oe/recipes-devtools/luajit/luajit_2.0.5.bb:do_compile

The Arm64 fix  should be in the 2.1.0 when it releases. The fix is in
LuaJIT-2.1.0-beta3.  I didn't want to backport (beta) it as it may
trigger the need for PE when 2.1.0 officially releases.


>
> === qemux86 (27) ===

> * meta-browser/recipes-mozilla/firefox/firefox_45.9.0esr.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-connectivity/rdist/rdist_6.1.5.bb:do_package
> * 
> meta-openembedded/meta-networking/recipes-daemons/opensaf/opensaf_5.17.07.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.3.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-netkit/netkit-rsh/netkit-rsh_0.17.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-netkit/netkit-telnet/netkit-telnet_0.17.bb:do_configure
> * 
> meta-openembedded/meta-networking/recipes-protocols/mdns/mdns_765.50.9.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-protocols/tsocks/tsocks_1.8beta5.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-support/open-isns/open-isns_0.97.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-connectivity/umip/umip_1.0.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb:do_compile
> * meta-openembedded/meta-oe/recipes-devtools/pm-qa/pm-qa_git.bb:do_compile
> * meta-openembedded/meta-oe/recipes-extended/mraa/mraa_git.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-extended/tiptop/tiptop_2.3.bb:do_compile
> * meta-openembedded/meta-oe/recipes-kernel/crash/crash_7.1.9.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-kernel/minicoredumper/minicoredumper_2.0.0.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-multimedia/alsa/alsa-oss_1.0.17.bb:do_compile
> * 
> meta-openembedded/meta-python/recipes-devtools/python/python3-systemd_234.bb:do_compile
> * 
> meta-openembedded/meta-python/recipes-devtools/python/python-systemd_234.bb:do_compile
> * meta-qt5/recipes-qt/qt5/qtlocation_git.bb:do_compile
> * 
> openembedded-core/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb:do_compile
> * 
> openembedded-core/meta/recipes-graphics/cogl/cogl-1.0_1.22.2.bb:do_compile
> * 
> openembedded-core/meta/recipes-graphics/virglrenderer/virglrenderer_git.bb:do_compile
> * 
> openembedded-core/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.3.bb:do_compile
> * openembedded-core/meta/recipes-multimedia/x264/x264_git.bb:do_package_qa
>
> === qemux86_64 (1) ===
> * 
> 

[OE-core] [PATCH] ca-certificates: Add /etc to SYSROOT_DIRS

[Patrick Vacek]

From: Patrick Vacek 

For recipes that depend on native ca-certificates.crt, /etc should be
added to the list of directories that automatically populate the
sysroot, otherwise the file may not be there.

Signed-off-by: Patrick Vacek 
---
 meta/recipes-support/ca-certificates/ca-certificates_20170717.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb 
b/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
index 59e7d51437..7d59fa6374 100644
--- a/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
+++ b/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
@@ -24,6 +24,7 @@ SRC_URI = 
"git://anonscm.debian.org/collab-maint/ca-certificates.git \
file://sbindir.patch"
 
 S = "${WORKDIR}/git"
+SYSROOT_DIRS_class-native += "/etc"
 
 inherit allarch
 
-- 
2.11.0

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

[OE-core] [PATCH] lttng-modules: Upgrade to 2.9.5 release

[Otavio Salvador]

This upgrade is critical as it fixes the support for Linux 4.14 LTS kernel.

The changlog is:

2017-10-05 LTTng modules 2.9.5
* Fix: update block instrumentation for 4.14 kernel
* Revert "Fix: update block instrumentation for kernel 4.14"

2017-10-03 (National Techies Day) LTTng modules 2.9.4
* Fix: version check error in btrfs instrumentation
* Fix: update btrfs instrumentation for kernel 4.14
* Fix: update writeback instrumentation for kernel 4.14
* Fix: update block instrumentation for kernel 4.14
* Fix: vmalloc wrapper on kernel < 2.6.38
* Fix: vmalloc wrapper on kernel >= 4.12
* Add kmalloc failover to vmalloc
* Fix: mmap: caches aliased on virtual addresses
* Fix: update ext4 instrumentation for kernel 4.13
* Fix: Sleeping function called from invalid context
* Fix: sched for v4.11.5-rt1
* Fix: handle missing ftrace header on v4.12

This also removes the previously backported patches as they are part
of 2.9.4 release and the missing fix is part of 2.9.5 release.

Signed-off-by: Otavio Salvador 
---
This patch should be backported for rocko. Even though this is a
version bump, it makes sense to upgrade instead of including all those
changes as patches.


 ...Fix-handle-missing-ftrace-header-on-v4.12.patch |  96 
 .../0002-Fix-sched-for-v4.11.5-rt1.patch   |  31 --
 ...ping-function-called-from-invalid-context.patch | 133 --
 ...date-ext4-instrumentation-for-kernel-4.13.patch | 189 
 ...-mmap-caches-aliased-on-virtual-addresses.patch | 100 
 .../0006-Add-kmalloc-failover-to-vmalloc.patch | 519 -
 .../0007-Fix-vmalloc-wrapper-on-kernel-4.12.patch  |  37 --
 ...0008-Fix-vmalloc-wrapper-on-kernel-2.6.38.patch |  34 --
 ...tng-modules_2.9.3.bb => lttng-modules_2.9.5.bb} |  15 +-
 9 files changed, 4 insertions(+), 1150 deletions(-)
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-Fix-handle-missing-ftrace-header-on-v4.12.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0002-Fix-sched-for-v4.11.5-rt1.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0003-Fix-Sleeping-function-called-from-invalid-context.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0004-Fix-update-ext4-instrumentation-for-kernel-4.13.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0005-Fix-mmap-caches-aliased-on-virtual-addresses.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0006-Add-kmalloc-failover-to-vmalloc.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0007-Fix-vmalloc-wrapper-on-kernel-4.12.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0008-Fix-vmalloc-wrapper-on-kernel-2.6.38.patch
 rename meta/recipes-kernel/lttng/{lttng-modules_2.9.3.bb => 
lttng-modules_2.9.5.bb} (63%)

diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0001-Fix-handle-missing-ftrace-header-on-v4.12.patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0001-Fix-handle-missing-ftrace-header-on-v4.12.patch
deleted file mode 100644
index 37c1f9af49..00
--- 
a/meta/recipes-kernel/lttng/lttng-modules/0001-Fix-handle-missing-ftrace-header-on-v4.12.patch
+++ /dev/null
@@ -1,96 +0,0 @@
-From fea65d0c097a42cf163bf7035985a6da330b9a1f Mon Sep 17 00:00:00 2001
-From: Michael Jeanson 
-Date: Fri, 23 Jun 2017 14:29:42 -0400
-Subject: [PATCH 1/8] Fix: handle missing ftrace header on v4.12
-Organization: O.S. Systems Software LTDA.
-
-Properly handle the case where we build against the distro headers of a
-kernel >= 4.12 and ftrace is enabled but the private header is
-unavailable.
-
-Upstream-Status: Backport [2.9.4]
-
-Signed-off-by: Michael Jeanson 
-Signed-off-by: Mathieu Desnoyers 

- Makefile.ABI.workarounds | 21 +
- lttng-events.h   |  2 +-
- probes/Kbuild| 19 ---
- 3 files changed, 26 insertions(+), 16 deletions(-)
-
-diff --git a/Makefile.ABI.workarounds b/Makefile.ABI.workarounds
-index c3717f8..2e6c4aa 100644
 a/Makefile.ABI.workarounds
-+++ b/Makefile.ABI.workarounds
-@@ -27,3 +27,24 @@ RT_PATCH_VERSION:=$(shell 
$(TOP_LTTNG_MODULES_DIR)/rt-patch-version.sh $(CURDIR)
- ifneq ($(RT_PATCH_VERSION), 0)
-   ccflags-y += -DRT_PATCH_VERSION=$(RT_PATCH_VERSION)
- endif
-+
-+# Starting with kernel 4.12, the ftrace header was moved to private headers
-+# and as such is not available when building against distro headers instead
-+# of the full kernel sources. In the situation, define 
LTTNG_FTRACE_MISSING_HEADER
-+# so we can enable the compat code even if CONFIG_DYNAMIC_FTRACE is enabled.
-+ifneq ($(CONFIG_DYNAMIC_FTRACE),)
-+  ftrace_dep = $(srctree)/kernel/trace/trace.h
-+  ftrace_dep_check = $(wildcard $(ftrace_dep))
-+  have_ftrace_header = $(shell \
-+if [ $(VERSION) -ge 5 -o \( 

[OE-core] [PATCH] busybox.inc: Add sanity check to test if the suid binary provides sh

[Nathan Rossi]

Add a sanity check during the do_compile task to fail if the suid
busybox provides /bin/sh. This is considered as a hard fail since not
only is providing sh as suid problematic for security reasons but also
because the sh configured for suid is less functional than the nosuid
configured sh and breaks a number of required features (e.g. 64-bit
test).

Signed-off-by: Nathan Rossi 
Cc: Ross Burton 
---
 meta/recipes-core/busybox/busybox.inc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index 4012f921c6..157aea3968 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -183,6 +183,12 @@ do_compile() {
oe_runmake busybox.links
mv busybox.links busybox.links.$s
done
+
+   # hard fail if sh is being linked to the suid busybox (detects 
bug 10346)
+   if grep -q -x "/bin/sh" busybox.links.suid; then
+   bbfatal "busybox suid binary incorrectly provides 
/bin/sh"
+   fi
+
# copy .config.orig back to .config, because the install 
process may check this file
cp .config.orig .config
# cleanup
-- 
2.14.2


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

Re: [OE-core] [PATCH 2/7] oeqa/runqemu: Only show stdout/stderr upon test failure

[Richard Purdie]

On Thu, 2017-11-09 at 14:04 +0100, Patrick Ohly wrote:
> On Thu, 2017-11-09 at 11:55 +, Richard Purdie wrote:
> > 
> > +    # We only want to print runqemu stdout/stderr if there is a
> > test
> > case failure
> > +    buffer = True
> Does the value matter? The other code only seems to check for the
> presence of the "buffer" attribute.

True, I think I should tweak that other code so it passes on the
value...

Cheers,

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

Re: [OE-core] [PATCH] rpm: update to 4.14.0

[Alexander Kanavin]

On 11/08/2017 05:31 PM, Mark Hatle wrote:


So a couple of questions.

- What exactly breaks currently when you let debugedit rewrite the
   debuginfo source paths?


Alexander has more info then I do here, but I believe running it against grub
modules breaks the modules.


Here's how you can reproduce the breakage:


1) download 
https://drive.google.com/open?id=1yKav0llpfrLjuMZOCj6ZyfVWGbxZQzIA


(a binary module from a grub build)

2) run
objcopy --only-keep-debug ./ntldr.module ntldr.module.debug

to establish that objcopy is happy with the download

3) run

debugedit -l debug.source ./ntldr.module


4) run the same objcopy command again ---> kaboom

objcopy: ./ntldr.module: invalid relocation type 112
objcopy: ./ntldr.module(rel.debug_info): relocation 556 has invalid 
symbol index 7497472

objcopy: ./ntldr.module: invalid relocation type 98
objcopy: ./ntldr.module(rel.debug_info): relocation 557 has invalid 
symbol index 6648415

objcopy: ./ntldr.module: invalid relocation type 108
objcopy: ./ntldr.module(rel.debug_info): relocation 558 has invalid 
symbol index 7495522

objcopy: ./ntldr.module: invalid relocation type 117
objcopy: ./ntldr.module(rel.debug_info): relocation 559 has invalid 
symbol index 7499636

objcopy: ./ntldr.module: invalid relocation type 97
objcopy: ./ntldr.module(rel.debug_info): relocation 560 has invalid 
symbol index 25697

objcopy: ./ntldr.module: invalid relocation type 111
.
Segmentation fault (core dumped)


Like Mark said, this isn't really the main issue for us; we would want 
to not have the binary file modified at all. Currently debugedit doesn't 
seem to provide that (and that's totally fine - a replacement is not 
difficult to find).


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

Re: [OE-core] [PATCH 2/7] oeqa/runqemu: Only show stdout/stderr upon test failure

[Patrick Ohly]

On Thu, 2017-11-09 at 11:55 +, Richard Purdie wrote:
> +    # We only want to print runqemu stdout/stderr if there is a test
> case failure
> +    buffer = True

Does the value matter? The other code only seems to check for the
presence of the "buffer" attribute.

Changing this to "buffer = False" and still get buffering would be
surprising.

-- 
Best Regards, Patrick Ohly

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


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

[OE-core] [PATCH 1/7] qemurunner: Ensure logging handler is removed

[Richard Purdie]

If we don't remove the handler we end up with duplicate log messages
which is undesireable.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/utils/qemurunner.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 72f05d5..aa2600b 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -58,7 +58,8 @@ class QemuRunner:
 self.host_dumper = HostDumper(dump_host_cmds, dump_dir)
 
 self.logger = logging.getLogger("BitBake.QemuRunner")
-self.logger.addHandler(logging.StreamHandler(sys.stdout))
+self.handler = logging.StreamHandler(sys.stdout)
+self.logger.addHandler(self.handler)
 
 def create_socket(self):
 try:
@@ -370,6 +371,7 @@ class QemuRunner:
 self.ip = None
 if os.path.exists(self.qemu_pidfile):
 os.remove(self.qemu_pidfile)
+self.logger.removeHandler(self.handler)
 
 def stop_qemu_system(self):
 if self.qemupid:
-- 
2.7.4

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

[OE-core] [PATCH 7/7] oeqa/target/ssh: Drop command/output logging to debug level

[Richard Purdie]

This ensures the console is kept clear of confusing output but that
the main logs contain good debugging information.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/core/target/ssh.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/core/target/ssh.py b/meta/lib/oeqa/core/target/ssh.py
index 927d659..151b99a 100644
--- a/meta/lib/oeqa/core/target/ssh.py
+++ b/meta/lib/oeqa/core/target/ssh.py
@@ -83,7 +83,7 @@ class OESSHTarget(OETarget):
 processTimeout = self.timeout
 
 status, output = self._run(sshCmd, processTimeout, True)
-self.logger.info('\nCommand: %s\nOutput:  %s\n' % (command, output))
+self.logger.debug('Command: %s\nOutput:  %s\n' % (command, output))
 return (status, output)
 
 def copyTo(self, localSrc, remoteDst):
-- 
2.7.4

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

[OE-core] [PATCH 4/7] oeqa/qemurunner: Use logger.debug, not logger.info

[Richard Purdie]

Bitbake logs info messages to the console. These messages are really
there as debugging information. At the debug level, they will be shown
in failure logs and in the task logs but not on the console which
is what we want in this case.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/utils/qemurunner.py | 74 +++
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index aa2600b..3214887 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -68,7 +68,7 @@ class QemuRunner:
 sock.bind(("127.0.0.1",0))
 sock.listen(2)
 port = sock.getsockname()[1]
-self.logger.info("Created listening socket for qemu serial console 
on: 127.0.0.1:%s" % port)
+self.logger.debug("Created listening socket for qemu serial 
console on: 127.0.0.1:%s" % port)
 return (sock, port)
 
 except socket.error:
@@ -95,8 +95,8 @@ class QemuRunner:
 def handleSIGCHLD(self, signum, frame):
 if self.runqemu and self.runqemu.poll():
 if self.runqemu.returncode:
-self.logger.info('runqemu exited with code %d' % 
self.runqemu.returncode)
-self.logger.info("Output from runqemu:\n%s" % 
self.getOutput(self.runqemu.stdout))
+self.logger.debug('runqemu exited with code %d' % 
self.runqemu.returncode)
+self.logger.debug("Output from runqemu:\n%s" % 
self.getOutput(self.runqemu.stdout))
 self.stop()
 self._dump_host()
 raise SystemExit
@@ -125,10 +125,10 @@ class QemuRunner:
 if not launch_cmd:
 launch_cmd = 'runqemu %s %s ' % ('snapshot' if discard_writes else 
'', runqemuparams)
 if self.use_kvm:
-self.logger.info('Using kvm for runqemu')
+self.logger.debug('Using kvm for runqemu')
 launch_cmd += ' kvm'
 else:
-self.logger.info('Not using kvm for runqemu')
+self.logger.debug('Not using kvm for runqemu')
 if not self.display:
 launch_cmd += ' nographic'
 launch_cmd += ' %s %s' % (self.machine, self.rootfs)
@@ -160,7 +160,7 @@ class QemuRunner:
 self.origchldhandler = signal.getsignal(signal.SIGCHLD)
 signal.signal(signal.SIGCHLD, self.handleSIGCHLD)
 
-self.logger.info('launchcmd=%s'%(launch_cmd))
+self.logger.debug('launchcmd=%s'%(launch_cmd))
 
 # FIXME: We pass in stdin=subprocess.PIPE here to work around stty
 # blocking at the end of the runqemu script when using this within
@@ -195,17 +195,17 @@ class QemuRunner:
 os.killpg(os.getpgid(self.runqemu.pid), signal.SIGTERM)
 sys.exit(0)
 
-self.logger.info("runqemu started, pid is %s" % self.runqemu.pid)
-self.logger.info("waiting at most %s seconds for qemu pid" % 
self.runqemutime)
+self.logger.debug("runqemu started, pid is %s" % self.runqemu.pid)
+self.logger.debug("waiting at most %s seconds for qemu pid" % 
self.runqemutime)
 endtime = time.time() + self.runqemutime
 while not self.is_alive() and time.time() < endtime:
 if self.runqemu.poll():
 if self.runqemu.returncode:
 # No point waiting any longer
-self.logger.info('runqemu exited with code %d' % 
self.runqemu.returncode)
+self.logger.debug('runqemu exited with code %d' % 
self.runqemu.returncode)
 self._dump_host()
 self.stop()
-self.logger.info("Output from runqemu:\n%s" % 
self.getOutput(output))
+self.logger.debug("Output from runqemu:\n%s" % 
self.getOutput(output))
 return False
 time.sleep(0.5)
 
@@ -214,7 +214,7 @@ class QemuRunner:
 # Dump all processes to help us to figure out what is going on...
 ps = subprocess.Popen(['ps', 'axww', '-o', 'pid,ppid,command '], 
stdout=subprocess.PIPE).communicate()[0]
 processes = ps.decode("utf-8")
-self.logger.info("Running processes:\n%s" % processes)
+self.logger.debug("Running processes:\n%s" % processes)
 self._dump_host()
 self.stop()
 op = self.getOutput(output)
@@ -227,7 +227,7 @@ class QemuRunner:
 # We are alive: qemu is running
 out = self.getOutput(output)
 netconf = False # network configuration is not required by default
-self.logger.info("qemu started in %s seconds - qemu procces pid is %s" 
% (time.time() - (endtime - self.runqemutime), self.qemupid))
+self.logger.debug("qemu started in %s seconds - qemu procces pid is 
%s" % (time.time() - (endtime - self.runqemutime), 

[OE-core] [PATCH 2/7] oeqa/runqemu: Only show stdout/stderr upon test failure

[Richard Purdie]

In general we don't need to see the output of runqemu however if it fails
we do. Use the buffer option that already exists in TestResult but allow
us to trigger it on a per test basis.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/core/runner.py| 8 
 meta/lib/oeqa/selftest/cases/runqemu.py | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/meta/lib/oeqa/core/runner.py b/meta/lib/oeqa/core/runner.py
index f6539e6..2d756da 100644
--- a/meta/lib/oeqa/core/runner.py
+++ b/meta/lib/oeqa/core/runner.py
@@ -45,6 +45,14 @@ class OETestResult(_TestResult):
 self.tc = tc
 self._tc_map_results()
 
+def startTest(self, test):
+# Allow us to trigger the testcase buffer mode on a per test basis
+# so stdout/stderr are only printed upon failure. Enables debugging
+# but clean output
+if hasattr(test, "buffer"):
+self.buffer = True
+super(OETestResult, self).startTest(test)
+
 def _tc_map_results(self):
 self.tc._results['failures'] = self.failures
 self.tc._results['errors'] = self.errors
diff --git a/meta/lib/oeqa/selftest/cases/runqemu.py 
b/meta/lib/oeqa/selftest/cases/runqemu.py
index 1991be7..1a8d121 100644
--- a/meta/lib/oeqa/selftest/cases/runqemu.py
+++ b/meta/lib/oeqa/selftest/cases/runqemu.py
@@ -14,6 +14,8 @@ class RunqemuTests(OESelftestTestCase):
 
 image_is_ready = False
 deploy_dir_image = ''
+# We only want to print runqemu stdout/stderr if there is a test case 
failure
+buffer = True
 
 def setUpLocal(self):
 super(RunqemuTests, self).setUpLocal()
-- 
2.7.4

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

[OE-core] [PATCH 6/7] oeqa: Clean up logger handling

[Richard Purdie]

The logger handling in oeqa was confused at best. This patch:

a) Passes in a logger through various qemu runner pieces
b) Uses that logger consistently in the code
c) Creates a logger for QemuRunner outside the bitbake namespace
   meaning we don't conflict with the tinfoil logging changes

The result of this is more consistency. For runtime tests in testimage,
the logs always contain the debug info, nothing is shwon on the console.
For the oe-selftests, logs are intercepted and only shown if the test
fails.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/core/target/qemu.py   |  2 +-
 meta/lib/oeqa/selftest/cases/runqemu.py |  5 -
 meta/lib/oeqa/targetcontrol.py  | 25 +
 meta/lib/oeqa/utils/commands.py | 25 -
 meta/lib/oeqa/utils/qemurunner.py   |  7 ++-
 meta/lib/oeqa/utils/qemutinyrunner.py   |  3 ++-
 6 files changed, 26 insertions(+), 41 deletions(-)

diff --git a/meta/lib/oeqa/core/target/qemu.py 
b/meta/lib/oeqa/core/target/qemu.py
index 2dc521c..d359bf9 100644
--- a/meta/lib/oeqa/core/target/qemu.py
+++ b/meta/lib/oeqa/core/target/qemu.py
@@ -31,7 +31,7 @@ class OEQemuTarget(OESSHTarget):
  deploy_dir_image=dir_image, display=display,
  logfile=bootlog, boottime=boottime,
  use_kvm=kvm, dump_dir=dump_dir,
- dump_host_cmds=dump_host_cmds)
+ dump_host_cmds=dump_host_cmds, logger=logger)
 
 def start(self, params=None, extra_bootparams=None):
 if self.runner.start(params, extra_bootparams=extra_bootparams):
diff --git a/meta/lib/oeqa/selftest/cases/runqemu.py 
b/meta/lib/oeqa/selftest/cases/runqemu.py
index 1a8d121..47d41f5 100644
--- a/meta/lib/oeqa/selftest/cases/runqemu.py
+++ b/meta/lib/oeqa/selftest/cases/runqemu.py
@@ -3,7 +3,6 @@
 #
 
 import re
-import logging
 
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import bitbake, runqemu, get_bb_var
@@ -24,10 +23,6 @@ class RunqemuTests(OESelftestTestCase):
 self.fstypes = "ext4 iso hddimg wic.vmdk wic.qcow2 wic.vdi"
 self.cmd_common = "runqemu nographic"
 
-# Avoid emit the same record multiple times.
-mainlogger = logging.getLogger("BitBake.Main")
-mainlogger.propagate = False
-
 self.write_config(
 """
 MACHINE = "%s"
diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
index e17c895..f63936c 100644
--- a/meta/lib/oeqa/targetcontrol.py
+++ b/meta/lib/oeqa/targetcontrol.py
@@ -18,19 +18,18 @@ from oeqa.utils.dump import TargetDumper
 from oeqa.controllers.testtargetloader import TestTargetLoader
 from abc import ABCMeta, abstractmethod
 
-logger = logging.getLogger('BitBake.QemuRunner')
-
 class BaseTarget(object, metaclass=ABCMeta):
 
 supported_image_fstypes = []
 
-def __init__(self, d):
+def __init__(self, d, logger):
 self.connection = None
 self.ip = None
 self.server_ip = None
 self.datetime = d.getVar('DATETIME')
 self.testdir = d.getVar("TEST_LOG_DIR")
 self.pn = d.getVar("PN")
+self.logger = logger
 
 @abstractmethod
 def deploy(self):
@@ -40,7 +39,7 @@ class BaseTarget(object, metaclass=ABCMeta):
 if os.path.islink(sshloglink):
 os.unlink(sshloglink)
 os.symlink(self.sshlog, sshloglink)
-logger.info("SSH log file: %s" %  self.sshlog)
+self.logger.info("SSH log file: %s" %  self.sshlog)
 
 @abstractmethod
 def start(self, params=None, ssh=True, extra_bootparams=None):
@@ -90,7 +89,7 @@ class QemuTarget(BaseTarget):
 
 supported_image_fstypes = ['ext3', 'ext4', 'cpio.gz', 'wic']
 
-def __init__(self, d, image_fstype=None, logger=None):
+def __init__(self, d, logger, image_fstype=None):
 
 super(QemuTarget, self).__init__(d, logger)
 
@@ -120,7 +119,7 @@ class QemuTarget(BaseTarget):
 self.qemurunnerlog = os.path.join(self.testdir, 'qemurunner_log.%s' % 
self.datetime)
 loggerhandler = logging.FileHandler(self.qemurunnerlog)
 loggerhandler.setFormatter(logging.Formatter("%(levelname)s: 
%(message)s"))
-logger.addHandler(loggerhandler)
+self.logger.addHandler(loggerhandler)
 oe.path.symlink(os.path.basename(self.qemurunnerlog), 
os.path.join(self.testdir, 'qemurunner_log'), force=True)
 
 if d.getVar("DISTRO") == "poky-tiny":
@@ -131,7 +130,8 @@ class QemuTarget(BaseTarget):
 display = d.getVar("BB_ORIGENV", 
False).getVar("DISPLAY"),
 logfile = self.qemulog,
 kernel = self.kernel,
-boottime = int(d.getVar("TEST_QEMUBOOT_TIMEOUT")))
+boottime = int(d.getVar("TEST_QEMUBOOT_TIMEOUT")),
+

[OE-core] [PATCH 3/7] oeqa/targetcontrol: Drop unused get_target_controller function

[Richard Purdie]

This funciton appears completely unused, drop it.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/targetcontrol.py | 29 ++---
 1 file changed, 2 insertions(+), 27 deletions(-)

diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
index 3255e3a..e17c895 100644
--- a/meta/lib/oeqa/targetcontrol.py
+++ b/meta/lib/oeqa/targetcontrol.py
@@ -20,31 +20,6 @@ from abc import ABCMeta, abstractmethod
 
 logger = logging.getLogger('BitBake.QemuRunner')
 
-def get_target_controller(d):
-testtarget = d.getVar("TEST_TARGET")
-# old, simple names
-if testtarget == "qemu":
-return QemuTarget(d)
-elif testtarget == "simpleremote":
-return SimpleRemoteTarget(d)
-else:
-# use the class name
-try:
-# is it a core class defined here?
-controller = getattr(sys.modules[__name__], testtarget)
-except AttributeError:
-# nope, perhaps a layer defined one
-try:
-bbpath = d.getVar("BBPATH").split(':')
-testtargetloader = TestTargetLoader()
-controller = 
testtargetloader.get_controller_module(testtarget, bbpath)
-except ImportError as e:
-bb.fatal("Failed to import {0} from available controller 
modules:\n{1}".format(testtarget,traceback.format_exc()))
-except AttributeError as e:
-bb.fatal("Invalid TEST_TARGET - " + str(e))
-return controller(d)
-
-
 class BaseTarget(object, metaclass=ABCMeta):
 
 supported_image_fstypes = []
@@ -115,9 +90,9 @@ class QemuTarget(BaseTarget):
 
 supported_image_fstypes = ['ext3', 'ext4', 'cpio.gz', 'wic']
 
-def __init__(self, d, image_fstype=None):
+def __init__(self, d, image_fstype=None, logger=None):
 
-super(QemuTarget, self).__init__(d)
+super(QemuTarget, self).__init__(d, logger)
 
 self.rootfs = ''
 self.kernel = ''
-- 
2.7.4

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

[OE-core] [PATCH 5/7] testimage: Pass the logger into OERuntimeTestContextExecutor.getTarget()

[Richard Purdie]

I have no idea why we didn't do this but it means the code has nowhere
to log to unless we do this. This means we can then use the logger
to log data to the task logs.

Signed-off-by: Richard Purdie 
---
 meta/classes/testimage.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 6a43560..b955fc1 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -248,7 +248,7 @@ def testimage_main(d):
 
 # the robot dance
 target = OERuntimeTestContextExecutor.getTarget(
-d.getVar("TEST_TARGET"), None, d.getVar("TEST_TARGET_IP"),
+d.getVar("TEST_TARGET"), logger, d.getVar("TEST_TARGET_IP"),
 d.getVar("TEST_SERVER_IP"), **target_kwargs)
 
 # test context
-- 
2.7.4

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

[OE-core] [PATCH] busybox.inc: Fix bashism in compile, which fixes sh being suid

[Nathan Rossi]

Fix the bashism in the suid check. This ensures that the check works
correctly on hosts that default sh to e.g. dash. If this check fails the
suid shell workaround does not remove sh from the suid binary and
results in the target system containing a busybox.suid with sh as well
as /bin/sh -> /bin/busybox.suid.

Signed-off-by: Nathan Rossi 
Cc: Andrej Valek 
Cc: Radovan Scasny 
---
 meta/recipes-core/busybox/busybox.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index 86f0c60249..4012f921c6 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -173,7 +173,7 @@ do_compile() {
done > .config.app.$s
 
# workaround for suid bug 10346
-   if [ "$s" == "suid" ] ; then
+   if [ "$s" = "suid" ] ; then
sed 
"s/.*CONFIG_SH_IS_NONE.*$/CONFIG_SH_IS_NONE=y/" -i .config.app.suid
fi
 
-- 
2.14.2


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

Re: [OE-core] State of bitbake world, Failed tasks 2017-11-07

[Andrea Adami]

On Thu, Nov 9, 2017 at 10:43 AM, Andrea Adami  wrote:
> On Wed, Nov 8, 2017 at 8:05 PM, Martin Jansa  wrote:
>> The only change from previous report is slightly newer oe-core and bitbake.
>>
>>
>> http://www.openembedded.org/wiki/Bitbake_World_Status
>>
>> == Number of issues - stats ==
>> {| class='wikitable'
>> !|Date !!colspan='4'|Failed tasks!!|Signatures
>> !!colspan='15'|QA !!Comment
>> |-
>> || ||qemuarm ||qemuarm64 ||qemux86 ||qemux86_64 ||all
>> ||already-stripped ||libdir ||textrel ||build-deps ||file-rdeps 
>> ||version-going-backwards ||host-user-contaminated ||installed-vs-shipped 
>> ||unknown-configure-option ||symlink-to-sysroot ||invalid-pkgconfig 
>> ||pkgname ||ldflags ||compile-host-path ||qa_pseudo ||
>> |-
>> ||2017-11-07 ||3 ||6 ||28 ||2 ||0 ||0 ||0 ||1 ||0 ||0 ||0 ||1 ||0 ||0 ||0 
>> ||0 ||0 ||0 ||0 ||365 ||
>> |}
>>
>> == Failed tasks 2017-11-07 ==
>>
>> INFO: jenkins-job.sh-1.8.39 Complete log available at
>> http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.report.20171108_081616.log
>>
>> === common (1) ===
>> *
>> meta-openembedded/meta-oe/recipes-support/freerdp/freerdp_git.bb:do_configure
>>
>> === common-x86 (0) ===
>>
>> === qemuarm (2) ===
>> *
>> meta-openembedded/meta-oe/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb:do_compile
>> * meta-qt5/recipes-qt/qt5/qtbase_git.bb:do_package_qa
>>
>> === qemuarm64 (5) ===
>> *
>> meta-browser/recipes-browser/chromium/chromium_54.0.2810.2.bb:do_compile
>> *
>> meta-browser/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb:do_compile
>> *
>> meta-openembedded/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.2.bb:do_install
>
> I am wondering about this failure, specific for aarch64-oe-linux
>
>  error: '-mgeneral-regs-only' is incompatible with floating-point
>
> Klibc does not support floating point and -mgeneral-regs-only should
> "Prevents the use of floating-point instructions or floating-point registers."
>
> Khem, do you have an idea?
>
>
>> *
>> meta-openembedded/meta-initramfs/recipes-kernel/kexec/kexec-tools-klibc_2.0.2.bb:do_configure
>
>
> | configure: loading site script
> /home/jenkins/oe/world/shr-core/tmp-glibc/work/aarch64-oe-linux/kexec-tools-klibc/2.0.2-r1/recipe-sysroot/usr/share/aarch64-oe-linux_config_site.d/glibc_config
> | checking build system type... x86_64-pc-linux-gnu
> | checking host system type... aarch64-oe-linux-gnu
> | checking target system type... aarch64-oe-linux-gnu
> | configure: error: unsupported architecture aarch64
>
> I think there is something wrong because the main package kexec-tools
> seems not giving build errors on aarch64.
>

In fact for kexec-tools_2.0.14.bb there is a specific patch "Add arm64 support"

We will backport it.

> Cheers
> Andrea
>
>> *
>> meta-openembedded/meta-oe/recipes-devtools/luajit/luajit_2.0.5.bb:do_compile
>>
>> === qemux86 (27) ===
>> * meta-browser/recipes-mozilla/firefox/firefox_45.9.0esr.bb:do_compile
>> *
>> meta-openembedded/meta-networking/recipes-connectivity/rdist/rdist_6.1.5.bb:do_package
>> *
>> meta-openembedded/meta-networking/recipes-daemons/opensaf/opensaf_5.17.07.bb:do_compile
>> *
>> meta-openembedded/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.3.bb:do_compile
>> *
>> meta-openembedded/meta-networking/recipes-netkit/netkit-rsh/netkit-rsh_0.17.bb:do_compile
>> *
>> meta-openembedded/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb:do_compile
>> *
>> meta-openembedded/meta-networking/recipes-netkit/netkit-telnet/netkit-telnet_0.17.bb:do_configure
>> *
>> meta-openembedded/meta-networking/recipes-protocols/mdns/mdns_765.50.9.bb:do_compile
>> *
>> meta-openembedded/meta-networking/recipes-protocols/tsocks/tsocks_1.8beta5.bb:do_compile
>> *
>> meta-openembedded/meta-networking/recipes-support/open-isns/open-isns_0.97.bb:do_compile
>> *
>> meta-openembedded/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb:do_compile
>> *
>> meta-openembedded/meta-oe/recipes-connectivity/umip/umip_1.0.bb:do_compile
>> *
>> meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb:do_compile
>> *
>> meta-openembedded/meta-oe/recipes-devtools/pm-qa/pm-qa_git.bb:do_compile
>> * meta-openembedded/meta-oe/recipes-extended/mraa/mraa_git.bb:do_compile
>> *
>> meta-openembedded/meta-oe/recipes-extended/tiptop/tiptop_2.3.bb:do_compile
>> *
>> meta-openembedded/meta-oe/recipes-kernel/crash/crash_7.1.9.bb:do_compile
>> *
>> meta-openembedded/meta-oe/recipes-kernel/minicoredumper/minicoredumper_2.0.0.bb:do_compile
>> *
>> meta-openembedded/meta-oe/recipes-multimedia/alsa/alsa-oss_1.0.17.bb:do_compile
>> *
>> meta-openembedded/meta-python/recipes-devtools/python/python3-systemd_234.bb:do_compile
>> *
>> meta-openembedded/meta-python/recipes-devtools/python/python-systemd_234.bb:do_compile
>> * 

Re: [OE-core] State of bitbake world, Failed tasks 2017-11-07

[Andrea Adami]

On Wed, Nov 8, 2017 at 8:05 PM, Martin Jansa  wrote:
> The only change from previous report is slightly newer oe-core and bitbake.
>
>
> http://www.openembedded.org/wiki/Bitbake_World_Status
>
> == Number of issues - stats ==
> {| class='wikitable'
> !|Date !!colspan='4'|Failed tasks!!|Signatures
> !!colspan='15'|QA !!Comment
> |-
> || ||qemuarm ||qemuarm64 ||qemux86 ||qemux86_64 ||all
> ||already-stripped ||libdir ||textrel ||build-deps ||file-rdeps 
> ||version-going-backwards ||host-user-contaminated ||installed-vs-shipped 
> ||unknown-configure-option ||symlink-to-sysroot ||invalid-pkgconfig ||pkgname 
> ||ldflags ||compile-host-path ||qa_pseudo ||
> |-
> ||2017-11-07 ||3 ||6 ||28 ||2 ||0 ||0 ||0 ||1 ||0 ||0 ||0 ||1 ||0 ||0 ||0 ||0 
> ||0 ||0 ||0 ||365 ||
> |}
>
> == Failed tasks 2017-11-07 ==
>
> INFO: jenkins-job.sh-1.8.39 Complete log available at
> http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.report.20171108_081616.log
>
> === common (1) ===
> *
> meta-openembedded/meta-oe/recipes-support/freerdp/freerdp_git.bb:do_configure
>
> === common-x86 (0) ===
>
> === qemuarm (2) ===
> *
> meta-openembedded/meta-oe/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb:do_compile
> * meta-qt5/recipes-qt/qt5/qtbase_git.bb:do_package_qa
>
> === qemuarm64 (5) ===
> *
> meta-browser/recipes-browser/chromium/chromium_54.0.2810.2.bb:do_compile
> *
> meta-browser/recipes-browser/chromium/chromium-wayland_53.0.2785.143.bb:do_compile
> *
> meta-openembedded/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.2.bb:do_install

I am wondering about this failure, specific for aarch64-oe-linux

 error: '-mgeneral-regs-only' is incompatible with floating-point

Klibc does not support floating point and -mgeneral-regs-only should
"Prevents the use of floating-point instructions or floating-point registers."

Khem, do you have an idea?


> *
> meta-openembedded/meta-initramfs/recipes-kernel/kexec/kexec-tools-klibc_2.0.2.bb:do_configure


| configure: loading site script
/home/jenkins/oe/world/shr-core/tmp-glibc/work/aarch64-oe-linux/kexec-tools-klibc/2.0.2-r1/recipe-sysroot/usr/share/aarch64-oe-linux_config_site.d/glibc_config
| checking build system type... x86_64-pc-linux-gnu
| checking host system type... aarch64-oe-linux-gnu
| checking target system type... aarch64-oe-linux-gnu
| configure: error: unsupported architecture aarch64

I think there is something wrong because the main package kexec-tools
seems not giving build errors on aarch64.

Cheers
Andrea

> *
> meta-openembedded/meta-oe/recipes-devtools/luajit/luajit_2.0.5.bb:do_compile
>
> === qemux86 (27) ===
> * meta-browser/recipes-mozilla/firefox/firefox_45.9.0esr.bb:do_compile
> *
> meta-openembedded/meta-networking/recipes-connectivity/rdist/rdist_6.1.5.bb:do_package
> *
> meta-openembedded/meta-networking/recipes-daemons/opensaf/opensaf_5.17.07.bb:do_compile
> *
> meta-openembedded/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.3.bb:do_compile
> *
> meta-openembedded/meta-networking/recipes-netkit/netkit-rsh/netkit-rsh_0.17.bb:do_compile
> *
> meta-openembedded/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb:do_compile
> *
> meta-openembedded/meta-networking/recipes-netkit/netkit-telnet/netkit-telnet_0.17.bb:do_configure
> *
> meta-openembedded/meta-networking/recipes-protocols/mdns/mdns_765.50.9.bb:do_compile
> *
> meta-openembedded/meta-networking/recipes-protocols/tsocks/tsocks_1.8beta5.bb:do_compile
> *
> meta-openembedded/meta-networking/recipes-support/open-isns/open-isns_0.97.bb:do_compile
> *
> meta-openembedded/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb:do_compile
> *
> meta-openembedded/meta-oe/recipes-connectivity/umip/umip_1.0.bb:do_compile
> *
> meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb:do_compile
> *
> meta-openembedded/meta-oe/recipes-devtools/pm-qa/pm-qa_git.bb:do_compile
> * meta-openembedded/meta-oe/recipes-extended/mraa/mraa_git.bb:do_compile
> *
> meta-openembedded/meta-oe/recipes-extended/tiptop/tiptop_2.3.bb:do_compile
> *
> meta-openembedded/meta-oe/recipes-kernel/crash/crash_7.1.9.bb:do_compile
> *
> meta-openembedded/meta-oe/recipes-kernel/minicoredumper/minicoredumper_2.0.0.bb:do_compile
> *
> meta-openembedded/meta-oe/recipes-multimedia/alsa/alsa-oss_1.0.17.bb:do_compile
> *
> meta-openembedded/meta-python/recipes-devtools/python/python3-systemd_234.bb:do_compile
> *
> meta-openembedded/meta-python/recipes-devtools/python/python-systemd_234.bb:do_compile
> * meta-qt5/recipes-qt/qt5/qtlocation_git.bb:do_compile
> *
> openembedded-core/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb:do_compile
> *
> openembedded-core/meta/recipes-graphics/cogl/cogl-1.0_1.22.2.bb:do_compile
> *
> openembedded-core/meta/recipes-graphics/virglrenderer/virglrenderer_git.bb:do_compile
> *
> 

Re: [OE-core] [PATCH][jethro] bluez5: fix out-of-bounds access in SDP server (CVE-2017-1000250)

[Buzarra, Arturo]

(ping) for this backport patch.

Thx.
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Arturo 
Buzarra
Sent: Thursday, November 02, 2017 14:47
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH][jethro] bluez5: fix out-of-bounds access in SDP 
server (CVE-2017-1000250)

From: Ross Burton 

All versions of the SDP server in BlueZ 5.46 and earlier are vulnerable to an 
information disclosure vulnerability which allows remote attackers to obtain 
sensitive information from the bluetoothd process memory. This vulnerability 
lies in the processing of SDP search attribute requests.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit 7351e0b260876b9bbc8660c2bb4173ab4c130f8b)
---
 meta/recipes-connectivity/bluez5/bluez5.inc|  1 +
 .../bluez5/bluez5/cve-2017-1000250.patch   | 34 ++
 2 files changed, 35 insertions(+)
 create mode 100644 
meta/recipes-connectivity/bluez5/bluez5/cve-2017-1000250.patch

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index d1af31ea45..d5b86c7925 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -19,6 +19,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)} \
+file://cve-2017-1000250.patch \
 "
 S = "${WORKDIR}/bluez-${PV}"
 
diff --git a/meta/recipes-connectivity/bluez5/bluez5/cve-2017-1000250.patch 
b/meta/recipes-connectivity/bluez5/bluez5/cve-2017-1000250.patch
new file mode 100644
index 00..9fac961bcf
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5/cve-2017-1000250.patch
@@ -0,0 +1,34 @@
+All versions of the SDP server in BlueZ 5.46 and earlier are vulnerable 
+to an information disclosure vulnerability which allows remote 
+attackers to obtain sensitive information from the bluetoothd process 
+memory. This vulnerability lies in the processing of SDP search attribute 
requests.
+
+CVE: CVE-2017-1000250
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From 9e009647b14e810e06626dde7f1bb9ea3c375d09 Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz 
+Date: Wed, 13 Sep 2017 10:01:40 +0300
+Subject: sdp: Fix Out-of-bounds heap read in service_search_attr_req 
+function
+
+Check if there is enough data to continue otherwise return an error.
+---
+ src/sdpd-request.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/sdpd-request.c b/src/sdpd-request.c index 
+1eefdce..318d044 100644
+--- a/src/sdpd-request.c
 b/src/sdpd-request.c
+@@ -917,7 +917,7 @@ static int service_search_attr_req(sdp_req_t *req, 
sdp_buf_t *buf)
+   } else {
+   /* continuation State exists -> get from cache */
+   sdp_buf_t *pCache = sdp_get_cached_rsp(cstate);
+-  if (pCache) {
++  if (pCache && cstate->cStateValue.maxBytesSent < 
pCache->data_size) 
++{
+   uint16_t sent = MIN(max, pCache->data_size - 
cstate->cStateValue.maxBytesSent);
+   pResponse = pCache->data;
+   memcpy(buf->data, pResponse + 
cstate->cStateValue.maxBytesSent, 
+sent);
+--
+cgit v1.1
--
2.14.2

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