[yocto] [PATCH 2/2] meta-yocto-bsp: beaglebone: Enable the serial console for the WIC image

[Kevin Hao]

Signed-off-by: Kevin Hao 
---
 meta-yocto-bsp/wic/beaglebone-yocto.wks | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta-yocto-bsp/wic/beaglebone-yocto.wks 
b/meta-yocto-bsp/wic/beaglebone-yocto.wks
index b75f238df937..97bd480a0875 100644
--- a/meta-yocto-bsp/wic/beaglebone-yocto.wks
+++ b/meta-yocto-bsp/wic/beaglebone-yocto.wks
@@ -4,3 +4,4 @@
 
 part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label 
boot --active --align 4 --size 16 --sourceparams="loader=u-boot" --use-uuid
 part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 4 
--use-uuid
+bootloader --append="console=ttyS0,115200"
-- 
2.14.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/2] meta-yocto-bsp: Bump to the latest stable kernel for all the BSPs

[Kevin Hao]

Boot test for all these boards.

Signed-off-by: Kevin Hao 
---
 .../recipes-kernel/linux/linux-yocto_5.0.bbappend| 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
index fe52a06550d2..5cf6e1f0649e 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
@@ -8,11 +8,11 @@ KMACHINE_genericx86 ?= "common-pc"
 KMACHINE_genericx86-64 ?= "common-pc-64"
 KMACHINE_beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine_genericx86?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
-SRCREV_machine_genericx86-64 ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
-SRCREV_machine_edgerouter ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
-SRCREV_machine_beaglebone-yocto ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
-SRCREV_machine_mpc8315e-rdb ?= "21aae3b4437eb6eec18804f1bad692030352430c"
+SRCREV_machine_genericx86?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+SRCREV_machine_genericx86-64 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+SRCREV_machine_edgerouter ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+SRCREV_machine_beaglebone-yocto ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+SRCREV_machine_mpc8315e-rdb ?= "8b62af7f252af10588276802c4c6d7c502e875be"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
 COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
@@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
 COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
-LINUX_VERSION_genericx86 = "5.0"
-LINUX_VERSION_genericx86-64 = "5.0"
-LINUX_VERSION_edgerouter = "5.0"
-LINUX_VERSION_beaglebone-yocto = "5.0"
-LINUX_VERSION_mpc8315e-rdb = "5.0"
+LINUX_VERSION_genericx86 = "5.0.3"
+LINUX_VERSION_genericx86-64 = "5.0.3"
+LINUX_VERSION_edgerouter = "5.0.3"
+LINUX_VERSION_beaglebone-yocto = "5.0.3"
+LINUX_VERSION_mpc8315e-rdb = "5.0.3"
-- 
2.14.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto on OnBoard Intel Galileo Flash

[Chris Simmonds]

Hi Nick,

The Galileo board has 8 MiB of NOR flash connected via SPI. That is not
enough for any meaningful embedded Linux image created by Yocto Project.
Even if you were to build an image less than 8 MiB, it still wouldn't
help because the Galileo needs that memory for the UEFI boot loader.

There is a very good write up of the way the Quark chip boots here:

"Anatomy of the UEFI Boot Sequence on the Intel Galileo"
http://blog.hansenpartnership.com/anatomy-of-the-uefi-boot-sequence-on-the-intel-galileo/

And there is a guide on how to write a new UEFI loader to the SPI flash
here:
"Programming SPI Flash with UEFI Internal Shell for Intel® Galileo Boards"
http://www.intel.co.uk/content/www/uk/en/support/boards-and-kits/intel-galileo-boards/06212.html

Cheers,
Chris

On 30/03/2019 22:33, nick wrote:
> Greetings All,
> 
> What is the best way to put a image on the 8mb of Yocto onboard flash or is
> this not possible with the Yocto Project.
> 
> Nick
> 


-- 
Chris Simmonds, trainer and consultant at 2net
http://www.2net.co.uk
Author of "Mastering Embedded Linux Programming"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] PN is uppercase

[Ralf Spiwoks]

Hi,

I am getting warning issues about the package name containing uppercase 
letters, e.g.

WARNING: QA Issue: PN: ... is upper case, this can result in unexpected 
behavior. [uppercase-pn]

And sometimes later, I am getting many errors like the following one:

ERROR: ...-1.0-r0 do_package_qa: QA Issue: /usr/bin/... contained in package ... requires libgcc_s.so.1, but no providers found in RDEPENDS_...? 
[file-rdeps]



TWO questions:

1) Are those two issues related?

2) What is the logic behind allowing only lower case package names? This is to 
me
   a serious restriction on the use of Yocto.

Thanks for your help,

Ralf Spiwoks, CERN
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH] layer.conf: Update to warrior release name series

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 43d578b..59f6a89 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,4 +14,4 @@ LAYERVERSION_gplv2 = "1"
 
 LAYERDEPENDS_gplv2 = "core"
 
-LAYERSERIES_COMPAT_gplv2 = "thud"
+LAYERSERIES_COMPAT_gplv2 = "warrior"
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] gdb built with musl libc segfault

[Lluis Campos]

Hi all,

This is my very first question in the Yocto mailing list. Very exited! 
Please let me know if I should use other list for this.



I am building an image using musl libc instead of gnu libc. I am not 
using yocto-tiny distro, instead I achieve this by setting on my local.conf:


TCLIBC = "musl"


My app (mender) got a segfault just starting. See output from strace:

root@raspberrypi3:~# strace mender
execve("/usr/bin/mender", ["mender"], 0x7ee65e10 /* 13 vars */) = 0
set_tls(0x76f1bffc) = 0
set_tid_address(0x76f1bfa0) = 3020
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x530bc8} ---
+++ killed by SIGSEGV +++
Segmentation fault


To be able to debug the process, I added gdb to my image adding to my 
local.conf:


CORE_IMAGE_EXTRA_INSTALL += "packagegroup-core-buildessential 
packagegroup-core-tools-debug"



Then, ironically, gdb itself also segfaults:

root@raspberrypi3:~# strace gdb 2>&1 | tail
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 6 entries */, 2048)    = 144
getdents64(3, /* 0 entries */, 2048)    = 0
close(3)    = 0
ioctl(0, TIOCGWINSZ, {ws_row=25, ws_col=74, ws_xpixel=0, ws_ypixel=0}) = 0
getcwd("/home/root", 4096)  = 11
access("/usr/local/bin/gdb", X_OK)  = -1 ENOENT (No such file or 
directory)

access("/usr/bin/gdb", X_OK)    = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7e35aff0} ---
+++ killed by SIGSEGV +++


So, what is going on here? My guess is that some recipes are being 
wrongly linked with gnu libc instead of musl, and then cannot run in my 
device.


Any ideas on how to debug the issue?

Thanks!


Lluís Campos
mender.io
Northen Tech

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PN is uppercase

[Burton, Ross]

On Tue, 2 Apr 2019 at 12:36, Ralf Spiwoks  wrote:
> TWO questions:
>
> 1) Are those two issues related?

Probably not, unless you're trying to use a mixed-case override.

> 2) What is the logic behind allowing only lower case package names? This is 
> to me
> a serious restriction on the use of Yocto.

Two reasons: some package managers forbid packages with uppercase
names; and for performance reasons overrides are lowercase and as
package names are often embedded in overrides this implies that
package names need to be lowercase.

What's the problem with using lowercase names?

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] selinux: remove git version

[Joe MacDonald]

Hi Yi,

I'm in the process of updating a big portion of the meta-selinux layer,
starting with the policy and working outward.  I am planning to update
these packages (and likely merge this) but I'm not merging your patch
yet until everything else is sorted out.

Just wanted to follow up with you so you knew what was happening.

-J.

[[meta-selinux][PATCH] selinux: remove git version] On 19.04.02 (Tue 08:54) Yi 
Zhao wrote:

> The git version of libselinux libsemanage libsepol checkpolicy and
> policycoreutils are far behind the master branch and now they can not
> build due to the do_patch error. The current stable 2.8 version works
> well so we can remove them.
> 
> Signed-off-by: Yi Zhao 
> ---
>  recipes-security/selinux/checkpolicy_git.bb |  6 --
>  recipes-security/selinux/libselinux_git.bb  | 14 --
>  recipes-security/selinux/libsemanage_git.bb | 17 -
>  recipes-security/selinux/libsepol_git.bb|  8 
>  recipes-security/selinux/policycoreutils_git.bb |  6 --
>  recipes-security/selinux/selinux_git.inc| 11 ---
>  6 files changed, 62 deletions(-)
>  delete mode 100644 recipes-security/selinux/checkpolicy_git.bb
>  delete mode 100644 recipes-security/selinux/libselinux_git.bb
>  delete mode 100644 recipes-security/selinux/libsemanage_git.bb
>  delete mode 100644 recipes-security/selinux/libsepol_git.bb
>  delete mode 100644 recipes-security/selinux/policycoreutils_git.bb
>  delete mode 100644 recipes-security/selinux/selinux_git.inc
> 
> diff --git a/recipes-security/selinux/checkpolicy_git.bb 
> b/recipes-security/selinux/checkpolicy_git.bb
> deleted file mode 100644
> index 6d1d23a..000
> --- a/recipes-security/selinux/checkpolicy_git.bb
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -PV = "2.7+git${SRCPV}"
> -
> -include selinux_git.inc
> -include ${BPN}.inc
> -
> -LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
> diff --git a/recipes-security/selinux/libselinux_git.bb 
> b/recipes-security/selinux/libselinux_git.bb
> deleted file mode 100644
> index a43b184..000
> --- a/recipes-security/selinux/libselinux_git.bb
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -PV = "2.7+git${SRCPV}"
> -
> -include selinux_git.inc
> -include ${BPN}.inc
> -
> -LIC_FILES_CHKSUM = "file://LICENSE;md5=84b4d2c6ef954a2d4081e775a270d0d0"
> -
> -SRC_URI += "\
> - file://libselinux-drop-Wno-unused-but-set-variable.patch \
> - file://libselinux-make-O_CLOEXEC-optional.patch \
> - file://libselinux-make-SOCK_CLOEXEC-optional.patch \
> - file://libselinux-define-FD_CLOEXEC-as-necessary.patch \
> - file://0001-src-Makefile-fix-includedir-in-libselinux.pc.patch \
> - "
> diff --git a/recipes-security/selinux/libsemanage_git.bb 
> b/recipes-security/selinux/libsemanage_git.bb
> deleted file mode 100644
> index 2e1fdc8..000
> --- a/recipes-security/selinux/libsemanage_git.bb
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -PV = "2.7+git${SRCPV}"
> -
> -include selinux_git.inc
> -include ${BPN}.inc
> -
> -LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343"
> -
> -SRC_URI += "\
> - file://libsemanage-Fix-execve-segfaults-on-Ubuntu.patch \
> - file://libsemanage-fix-path-nologin.patch \
> - file://libsemanage-drop-Wno-unused-but-set-variable.patch \
> - file://libsemanage-define-FD_CLOEXEC-as-necessary.patch;striplevel=2 \
> - file://libsemanage-allow-to-disable-audit-support.patch \
> - file://libsemanage-disable-expand-check-on-policy-load.patch \
> - file://0001-src-Makefile-fix-includedir-in-libselinux.pc.patch \
> - "
> -FILES_${PN} += "/usr/libexec"
> diff --git a/recipes-security/selinux/libsepol_git.bb 
> b/recipes-security/selinux/libsepol_git.bb
> deleted file mode 100644
> index f9b8010..000
> --- a/recipes-security/selinux/libsepol_git.bb
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -PV = "2.7+git${SRCPV}"
> -
> -include selinux_git.inc
> -include ${BPN}.inc
> -
> -LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343"
> -
> -SRC_URI += "file://0001-src-Makefile-fix-includedir-in-libsepol.pc.patch"
> diff --git a/recipes-security/selinux/policycoreutils_git.bb 
> b/recipes-security/selinux/policycoreutils_git.bb
> deleted file mode 100644
> index 6d1d23a..000
> --- a/recipes-security/selinux/policycoreutils_git.bb
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -PV = "2.7+git${SRCPV}"
> -
> -include selinux_git.inc
> -include ${BPN}.inc
> -
> -LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
> diff --git a/recipes-security/selinux/selinux_git.inc 
> b/recipes-security/selinux/selinux_git.inc
> deleted file mode 100644
> index 9887bd1..000
> --- a/recipes-security/selinux/selinux_git.inc
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -SRCREV = "1bac758bf6cf884c112b80545d5fc5b668fc7d71"
> -
> -SRC_URI = "git://github.com/SELinuxProject/selinux.git;protocol=http"
> -
> -include selinux_common.inc
> -
> -# ${S} is set in selinux_common above, but w

Re: [yocto] gdb built with musl libc segfault

[Paul Barker]

On 02/04/2019 12:45, Lluis Campos wrote:

Hi all,

This is my very first question in the Yocto mailing list. Very exited! 
Please let me know if I should use other list for this.



I am building an image using musl libc instead of gnu libc. I am not 
using yocto-tiny distro, instead I achieve this by setting on my 
local.conf:


TCLIBC = "musl"


My app (mender) got a segfault just starting. See output from strace:

root@raspberrypi3:~# strace mender
execve("/usr/bin/mender", ["mender"], 0x7ee65e10 /* 13 vars */) = 0
set_tls(0x76f1bffc) = 0
set_tid_address(0x76f1bfa0) = 3020
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x530bc8} ---
+++ killed by SIGSEGV +++
Segmentation fault


To be able to debug the process, I added gdb to my image adding to my 
local.conf:


CORE_IMAGE_EXTRA_INSTALL += "packagegroup-core-buildessential 
packagegroup-core-tools-debug"



Then, ironically, gdb itself also segfaults:

root@raspberrypi3:~# strace gdb 2>&1 | tail
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 6 entries */, 2048)    = 144
getdents64(3, /* 0 entries */, 2048)    = 0
close(3)    = 0
ioctl(0, TIOCGWINSZ, {ws_row=25, ws_col=74, ws_xpixel=0, ws_ypixel=0}) = 0
getcwd("/home/root", 4096)  = 11
access("/usr/local/bin/gdb", X_OK)  = -1 ENOENT (No such file or 
directory)

access("/usr/bin/gdb", X_OK)    = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7e35aff0} ---
+++ killed by SIGSEGV +++


So, what is going on here? My guess is that some recipes are being 
wrongly linked with gnu libc instead of musl, and then cannot run in my 
device.


Any ideas on how to debug the issue?



Hi Lluis,

This is an issue I've seen before with runc and gdb.

In runc we saw SIGILL which I tracked down to some hideous 
setjmp/longjmp magic written in C. cgo is used to include this C code in 
with the Go code that comprises the rest of the application.


In gdb we saw SIGSEGV which is what you've got above.

I think things are being correctly linked against musl but then there's 
some runtime issue in recent musl versions, possibly in conjunction with 
recent kernel headers.


Are you using the thud or master branch?

--
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] gdb built with musl libc segfault

[Lluis Campos]

Hi Paul,


On 02.04.2019 14:49, Paul Barker wrote:

On 02/04/2019 12:45, Lluis Campos wrote:

Hi all,

This is my very first question in the Yocto mailing list. Very 
exited! Please let me know if I should use other list for this.



I am building an image using musl libc instead of gnu libc. I am not 
using yocto-tiny distro, instead I achieve this by setting on my 
local.conf:


TCLIBC = "musl"


My app (mender) got a segfault just starting. See output from strace:

root@raspberrypi3:~# strace mender
execve("/usr/bin/mender", ["mender"], 0x7ee65e10 /* 13 vars */) = 0
set_tls(0x76f1bffc) = 0
set_tid_address(0x76f1bfa0) = 3020
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x530bc8} 
---

+++ killed by SIGSEGV +++
Segmentation fault


To be able to debug the process, I added gdb to my image adding to my 
local.conf:


CORE_IMAGE_EXTRA_INSTALL += "packagegroup-core-buildessential 
packagegroup-core-tools-debug"



Then, ironically, gdb itself also segfaults:

root@raspberrypi3:~# strace gdb 2>&1 | tail
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 6 entries */, 2048)    = 144
getdents64(3, /* 0 entries */, 2048)    = 0
close(3)    = 0
ioctl(0, TIOCGWINSZ, {ws_row=25, ws_col=74, ws_xpixel=0, 
ws_ypixel=0}) = 0

getcwd("/home/root", 4096)  = 11
access("/usr/local/bin/gdb", X_OK)  = -1 ENOENT (No such file or 
directory)

access("/usr/bin/gdb", X_OK)    = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, 
si_addr=0x7e35aff0} ---

+++ killed by SIGSEGV +++


So, what is going on here? My guess is that some recipes are being 
wrongly linked with gnu libc instead of musl, and then cannot run in 
my device.


Any ideas on how to debug the issue?



Hi Lluis,

This is an issue I've seen before with runc and gdb.

In runc we saw SIGILL which I tracked down to some hideous 
setjmp/longjmp magic written in C. cgo is used to include this C code 
in with the Go code that comprises the rest of the application.


Our application is written in Go and we use CGO as well. So it sounds 
quite similar.





In gdb we saw SIGSEGV which is what you've got above.

I think things are being correctly linked against musl but then 
there's some runtime issue in recent musl versions, possibly in 
conjunction with recent kernel headers.


Are you using the thud or master branch?

I am using thud branch. I haven't actually tried with master but I will 
do it later today



Thanks,

Lluís

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW14'19

[sjolley.yp.pm]

Current Dev Position: YP 2.7 M4 (New feature Freeze has begun.)

Next Deadline: YP 2.7 M3 Release Target was Mar. 8, 2019

 

SWAT Team Rotation:

*   SWAT lead is currently: Ross
*   SWAT team rotation: Ross -> Amanda on Apr. 5, 2019
*   SWAT team rotation: Amanda -> Chen on Apr. 12, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Next Team Meetings:

*   YP 2.8 Planning meeting Tuesday April 2nd at 8am PDT (
 https://zoom.us/j/990892712) or see the invite
on the mailing list at: (

https://lists.yoctoproject.org/pipermail/yocto/2019-April/044654.html) 
*   Bug Triage meeting Thursday April 4th at 7:30am PDT (
 https://zoom.us/j/454367603)

 

Key Status/Updates:

*   The QA report for M3 rc1 is available. This is the first time we've
used the new QA process so we're still understanding how the new format for
the data works out. There are some issues but right now we believe we'll aim
to fix these before the final release build and proceed to that with the
first build of M4 aiming for next week.
*   The YP 2.7 M3 rc1 report is summarized at

https://lists.yoctoproject.org/pipermail/yocto/2019-April/044667.html and
the results are at

https://autobuilder.yocto.io/pub/releases/yocto-2.7_M3.rc1/testresults/.
*   2.5.3 and 2.6.2 stable releases were built and submitted to QA last
week.
*   The "warrior" branches for 2.7 have been created and the metadata
updated. This will have a ripple effect across the layers as they update to
match this. This process is important as it allows layers to indicate which
versions of the project they are compatible with.
*   The 2.8 planning discussions are starting and there is a google doc
summarising the discussions so far:

https://docs.google.com/document/d/1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJG
XbU/

If people are planning to work on specific things in 2.8 please let us know
so we can incorporate this into our plans. If you're interested in working
on anything in the document, please also let us know or talk with us in one
of the planning meetings.

 

Planned Releases for YP 2.7:

*   YP 2.7 M4 Cutoff is Apr. 1, 2019
*   YP 2.7 M4 Release Target is Apr. 26, 2019

 

Planned upcoming dot releases:

*   YP 2.5.3 (Sumo) is in QA.
*   YP 2.6.2 (Thud) is in QA.

 

Tracking Metrics:

*   WDD 2442 (last week 2418) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1542 (last week 1538)
*   Patches in the Pending State: 654 (42%) [last week 656 (43%)]

 

Key Status Links for YP:

 
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status

 
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule

 
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

*Cell:(208) 244-4460

* Email:   
sjolley.yp...@gmail.com

 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] YPTM minutes

[sjolley.yp.pm]

Attendees: Stephen, Joshua, Alex, Jon, Randy, Richard, Michael, David,
Bruce, Shawn, Jaewon, Manjukum, Tracey, Chris, Tim, Chandana, Aitronics,
Paul, Tomas, Ross, 

 

YP 2.7 M3 rc1 is out of QA.  The YP 2.7 M3 rc1 report is summarized at

https://lists.yoctoproject.org/pipermail/yocto/2019-April/044667.html and
the results are at

https://autobuilder.yocto.io/pub/releases/yocto-2.7_M3.rc1/testresults/.

YP 2.5.3 and YP 2.6.2 stable releases were built and submitted to QA last
week.

We discuss the YP 2.8 Ideas document at:

https://docs.google.com/document/d/1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJG
XbU/ - If you wish to edit the file, send a request. 

 

AR: Tim - Add to planning document details about installable images via WIC.


AR: Stephen - Cancel 4/16 engineering meeting and add 4/16 Planning meeting.

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Invitation: Yocto Project Technical Team Meeting @ Monthly from 8am to 9am on the third Tuesday (PDT) (yocto@yoctoproject.org)

[theyoctoproject]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20190416T08
DTEND;TZID=America/Los_Angeles:20190416T09
RRULE:FREQ=MONTHLY;BYDAY=3TU
DTSTAMP:20190402T160350Z
ORGANIZER;CN=theyoctoproj...@gmail.com:mailto:theyoctoproj...@gmail.com
UID:1ecajdkto3oaaghe0t5gvns...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=theyoctoproj...@gmail.com;X-NUM-GUESTS=0:mailto:theyoctoproject@gmail.c
 om
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=stephen.k.jol...@intel.com;X-NUM-GUESTS=0:mailto:stephen.k.jolley@i
 ntel.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=yocto@yoctoproject.org;X-NUM-GUESTS=0:mailto:yocto@yoctoproject.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=sjolley.yp...@gmail.com;X-NUM-GUESTS=0:mailto:sjolley.yp.pm@gmail.c
 om
CREATED:20190402T160348Z
DESCRIPTION:We encourage people attending the meeting to logon and announce
  themselves on the Yocto Project IRC chancel during the meeting (optional):
 Yocto IRC: http://webchat.freenode.net/?channels=#yocto"; t
 arget="_blank">http://webchat.freenode.net/?channels=#yoctoWiki
 : https://www.yoctoproject.org/public-virtual-meetings/";>https://w
 ww.yoctoproject.org/public-virtual-meetings/Bridge is with Zoom
  at: https://zoom.us/j/990892712"; target="_blank" id="ow341" __is_
 owner="true">https://zoom.us/j/990892712Technical Meeting Minut
 es at: https://drive.google.com/open?id=1Y5IIuE-z0Ykdl-DwuzUJh52flOZuhN_TSA
 fw2tdU9pgYP 2.8 Planning Ideas at: https://drive.google.com/open?id
 =1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJGXbU\n\n-::~:~::~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do no
 t edit this section of the description.\n\nView your event at https://www.g
 oogle.com/calendar/event?action=VIEW&eid=MWVjYWpka3RvM29hYWdoZTB0NWd2bnNpZ2
 UgeW9jdG9AeW9jdG9wcm9qZWN0Lm9yZw&tok=MjUjdGhleW9jdG9wcm9qZWN0QGdtYWlsLmNvbW
 I1ZDA3MTc2NTYxMTI4MjFlZGJiOWNlMzkyYjRiNDI2ZjRkMjAwMjU&ctz=America%2FLos_Ang
 eles&hl=en&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20190402T160348Z
LOCATION:Zoom Meeting: https://zoom.us/j/990892712
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Yocto Project Technical Team Meeting
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P0DT0H15M0S
END:VALARM
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] Documentation: unify the spacing for questions in various places e.g. before the [Y/n] there should be a space, and before "?" there should be none. Unify the questions where the s

[Scott Rifenbark]

Hi,

I applied changes for docs.  Someone else needs to get the changes into the
*.sh files.
See inline comments for links to adjusted text.

Scott

On Fri, Mar 29, 2019 at 2:33 AM Gianfranco Costamagna <
costamagna.gianfra...@gmail.com> wrote:

> Signed-off-by: Gianfranco Costamagna 
> Signed-off-by: Gianfranco Costamagna 
> ---
>  documentation/kernel-dev/kernel-dev-common.xml| 2 +-
>  documentation/sdk-manual/sdk-extensible.xml   | 2 +-
>  documentation/sdk-manual/sdk-using.xml| 2 +-
>  meta/files/toolchain-shar-extract.sh  | 4 ++--
>  .../initrdscripts/files/init-install-efi-testfs.sh| 2 +-
>  5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/documentation/kernel-dev/kernel-dev-common.xml
> b/documentation/kernel-dev/kernel-dev-common.xml
> index 7ff4cba3b0..7d8826fa35 100644
> --- a/documentation/kernel-dev/kernel-dev-common.xml
> +++ b/documentation/kernel-dev/kernel-dev-common.xml
> @@ -185,7 +185,7 @@
>   Poky (Yocto Project Reference Distro) Extensible SDK installer
> version &DISTRO;
>
> 
>   Enter target directory for SDK (default: ~/poky_sdk):
> - You are about to install the SDK to "/home/scottrif/poky_sdk".
> Proceed[Y/n]? Y
> + You are about to install the SDK to "/home/scottrif/poky_sdk".
> Proceed [Y/n]? Y
>

See step 6 for this doc change -
https://yoctoproject.org/docs/2.7/kernel-dev/kernel-dev.html#getting-ready-to-develop-using-devtool


  Extracting SDK..done
>   Setting it up...
>   Extracting buildtools...
> diff --git a/documentation/sdk-manual/sdk-extensible.xml
> b/documentation/sdk-manual/sdk-extensible.xml
> index 09f06088d2..9be082d8ba 100644
> --- a/documentation/sdk-manual/sdk-extensible.xml
> +++ b/documentation/sdk-manual/sdk-extensible.xml
> @@ -157,7 +157,7 @@
>   Poky (Yocto Project Reference Distro) Extensible SDK installer
> version 2.5
>
> ==
>   Enter target directory for SDK (default: ~/poky_sdk):
> - You are about to install the SDK to "/home/scottrif/poky_sdk".
> Proceed[Y/n]? Y
> + You are about to install the SDK to "/home/scottrif/poky_sdk".
> Proceed [Y/n]? Y
>

See the output here -
https://yoctoproject.org/docs/2.7/sdk-manual/sdk-manual.html#sdk-installing-the-extensible-sdk


  Extracting SDK..done
>   Setting it up...
>   Extracting buildtools...
> diff --git a/documentation/sdk-manual/sdk-using.xml
> b/documentation/sdk-manual/sdk-using.xml
> index dd220c340b..06fdb573ed 100644
> --- a/documentation/sdk-manual/sdk-using.xml
> +++ b/documentation/sdk-manual/sdk-using.xml
> @@ -149,7 +149,7 @@
>   Poky (Yocto Project Reference Distro) SDK installer version &DISTRO;
>   ===
>   Enter target directory for SDK (default: /opt/poky/&DISTRO;):
> - You are about to install the SDK to "/opt/poky/&DISTRO;".
> Proceed[Y/n]? Y
> + You are about to install the SDK to "/opt/poky/&DISTRO;". Proceed
> [Y/n]? Y
>

See the output here -
https://yoctoproject.org/docs/2.7/sdk-manual/sdk-manual.html#sdk-installing-the-sdk


  Extracting SDK
> ..done
>   Setting it up...done
>   SDK has been successfully set up and is ready to be used.
> diff --git a/meta/files/toolchain-shar-extract.sh
> b/meta/files/toolchain-shar-extract.sh
> index 9eabd62630..156085b500 100644
> --- a/meta/files/toolchain-shar-extract.sh
> +++ b/meta/files/toolchain-shar-extract.sh
> @@ -185,11 +185,11 @@ fi
>
>  if [ -e "$target_sdk_dir/environment-setup-@REAL_MULTIMACH_TARGET_SYS@"
> ]; then
> echo "The directory \"$target_sdk_dir\" already contains a SDK for
> this architecture."
> -   printf "If you continue, existing files will be overwritten!
> Proceed[y/N]? "
> +   printf "If you continue, existing files will be overwritten!
> Proceed [y/N]? "
>
> default_answer="n"
>  else
> -   printf "You are about to install the SDK to \"$target_sdk_dir\".
> Proceed[Y/n]? "
> +   printf "You are about to install the SDK to \"$target_sdk_dir\".
> Proceed [Y/n]? "
>
> default_answer="y"
>  fi
> diff --git
> a/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
> b/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
> index 9c4b263d54..b351985a61 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
> @@ -27,7 +27,7 @@ do
>  # Try sleeping here to avoid getting kernel messages
>  # obscuring/confusing user
>  sleep 5
> -echo "Found drive at /dev/${device}. Do you want to
> install

[yocto] devtool generated npm recipe building binary package for wrong system

[Andrew Wilcox]

I used devtool to generate a recipe for installing the Node NPM
package "firebase":

  devtool add "npm://registry.npmjs.org;name=firebase;version=5.9.2"

I needed to add

  RDEPENDS_node-firebase_append = " bash"

to the recipe because an included utility was looking for the bash shell.

On the target system, in Node when I require firebase:

> require('firebase')
Error: Failed to load gRPC binary module because it was not installed
for the current system
Expected directory: node-v57-linux-arm-unknown
Found: [node-v57-linux-arm-glibc]
This problem can often be fixed by running "npm rebuild" on the current system
Original error: Cannot find module
'/usr/lib/node/firebase/node_modules/grpc/src/node/extension_binary/node-v57-linux-arm-unknown/grpc_node.node'

On the target system,
/usr/lib/node/firebase/node_modules/grpc/src/node/extension_binary
does contain node-v57-linux-arm-glibc

I'm building the raspberrypi0-wifi image from meta-raspberrypi.

Any ideas on what I could try?

Thanks!

Andrew
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.7 M3 RC1

[richard . purdie]

Hi Sangeeta/Ee Peng,

On Tue, 2019-04-02 at 05:02 +, Jain, Sangeeta wrote:
> QA cycle report for 2.7 M3 RC1:
>  
> No high milestone defects. 
> This is completion of first QA cycle after adoption of new QA
> process. Test results are available at following location:
> ·For results of all automated tests, please refer to results
> at public AB [1].
> ·For other test results, refer to attachment [2].
> ·For test report for test cases run by Intel and WR team,
> refer attachment [3]
> ·For full test report, refer attachment [4]
> 2 new defects are found in this cycle, oe-selftest [5] and qemu-
> shutdown[6].
> Number of existing issues observed in this release is 3- toaster [7],
> Build-appliance [8] and Beaglebone [9]
> For ptest, 3 package tests are failing in this release which were
> passing in previous release: python [10], python3[11] and strace[12].
> 3 packages are facing timeout issues: lttng-tools [13], openssh [14]
> and python3 [15].

Thanks for this. I have some questions/observations.

Looking at the Intel/WR report, I see tests which start oeselftest_XXX
for sdk-extras and qemu-shutdown. I think this means you have some QA
test infrastructure running "oe-selftest -r runqemu,meta_ide",
iterating over MACHINE=qemuppc, qemumips, qemuarm, qemux86?

Is this some automation we're missing in the autobuilder configuration?
We all other tests covered and this is the only remaining automated
piece we haven't covered? What configuration are we missing exactly for
the missing tests?

I'm partly wondering how you found the shutdown issue but this would
explain that.

I think going forward we need to add some kind of "who" identifier to
the test results so we can say where/who they came from (main
autobuilder, Intel, WR, anywhere else). We could add a resulttool
command to "stamp" a set of test results with this, maybe as a
parameter to the store command?

Of the bugs, I didn't see any which I think should block M3, I think we
probably should release that and move forward to M4. I do want to see
some of these fixed before we build M4 though. I've made comments on
them below.
 
> New Bugs :
>  
> [5] Bug 13237 - [2.7 M3 RC1][OE-selftest][Opensuseleap 15.0][Public
> AB]:"test_wic_cp_ext" failing for Opensuseleap 15.0.
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13237

Ross: Are you looking into that one?

> [6] Bug 13234 - [2.7 M3 RC1] qemumips & qemumips64: failed to
> shutdown
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13234

This needs looking into and fixing, as well as figuring out why the
autobuilder doesn't see this (see above for my hypothesis).

> Previous Bugs observed in this release:
>  
> [7] Bug 13191 – [Test Case 1439] Build Failure after adding or
> removing packages with and without dependencies
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13191
>  
> [8] Bug 12991 - [Bug] [2.6 M4 RC1][Build-Appliance] Bitbake build-
> appliance-image getting failed during building image due to webkitgtk
> package.
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12991

We need to do something about this. I believe its related to resource
starvation in the VM.

> [9] Bug 13153 – [2.7 M2 RC1] Systemtap doesn't work on beaglebone
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13153

I'm hoping a SRCREV bump for beaglebone-yocto fixes this.

> ptest Bugs:
>  
> [10] Bug 13249 - [2.7 M3 RC1] python ptest failure
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13249

I'm hoping a patch from Ross in master fixes this, need to retest ptest
with this applied.
 
> [11] Bug 13253 - [2.7 M3 RC1] python3 ptest failure
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13253

I'm hoping a patch from Ross in master fixes this, need to retest ptest
with this applied.

> [12] Bug 13254 - [2.7 M3 RC1] strace ptest failure
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13254

No ideas on this one yet.
 
> [13] Bug 13255 - [2.7 M3 rc1] lttng-tools ptest facing timeout issue
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13255

There are patches which are due to arrive soon which should address
this.

> [14] Bug 13256 - [2.7 M3 rc1] openssh ptest facing timeout issue
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13256

No ideas on this one yet.

> [15] Bug 13257 - [2.7 M3 rc1] python3 ptest facing timeout issue
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13257

I'm hoping a patch from Ross in master fixes this, need to retest ptest
with this applied.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Git commit process question.

[Tom Rini]

On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote:
> On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
> > 
> > 
> > On 4/1/19 4:02 PM, Richard Purdie wrote:
> > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >> Hello,
> > >>
> > >> I have noticed a large number of git commits with no header
> > >> information being accepted.
> > > Can you be more specific about what "no header information" means? You
> > > mean a shortlog and no full log message?
> > Commits with just a "subject" and signoff. No additional information
> > 
> > We tend to reference back to how the kernel does things.
> > 
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > These two sections in particular.
> > 
> > 
> > 2) Describe your changes
> > 
> > Describe your problem. Whether your patch is a one-line bug fix or 5000
> > lines of a new feature, there must be an underlying problem that
> > motivated you to do this work. Convince the reviewer that there is a
> > problem worth fixing and that it makes sense for them to read past the
> > first paragraph.
> >...
> 
> The kernel does not have "upgrade foo to the latest upstream version" commits.
> 
> With the Automatic Upgrade Helper this is a semi-automatic task, and 
> most of the time there is no specific motivation other than upgrading
> to the latest upstream version.

But since that's just filling in a template the body can also be a
template perhaps with useful AUH data (run at ... by ... ?) ?

-- 
Tom


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Git commit process question.

[Tom Rini]

On Tue, Apr 02, 2019 at 04:45:16AM +, Jon Mason wrote:
> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle  wrote:
> >
> > On 4/1/19 6:20 PM, akuster808 wrote:
> > >
> > >
> > > On 4/1/19 4:02 PM, Richard Purdie wrote:
> > >> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >>> Hello,
> > >>>
> > >>> I have noticed a large number of git commits with no header
> > >>> information being accepted.
> > >> Can you be more specific about what "no header information" means? You
> > >> mean a shortlog and no full log message?
> > > Commits with just a "subject" and signoff. No additional information
> >
> > If you can convey the reason for the change in just the subject, that is
> > acceptable.. but there is -always- supposed to be a signed-off-by line 
> > according
> > to our guidelines.
> >
> > So if you see this, I think we need to step back and figure out where and 
> > why
> > it's happening and get it resolved in the future.
> >
> > (Places I've seen in the past were one-off mistakes and clearly that -- so 
> > it
> > wasn't anything that we needed to work on a correction.)
> >
> > --Mark
> >
> > > We tend to reference back to how the kernel does things.
> > >
> > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > > These two sections in particular.
> > >
> > >
> > > 2) Describe your changes
> > >
> > > Describe your problem. Whether your patch is a one-line bug fix or 5000 
> > > lines of
> > > a new feature, there must be an underlying problem that motivated you to 
> > > do this
> > > work. Convince the reviewer that there is a problem worth fixing and that 
> > > it
> > > makes sense for them to read past the first paragraph.
> > >
> > >
> > > along with this section.
> > >
> > >
> > > 14) The canonical patch format
> > >
> > > This section describes how the patch itself should be formatted. Note 
> > > that, if
> > > you have your patches stored in a |git| repository, proper patch 
> > > formatting can
> > > be had with |git format-patch|. The tools cannot create the necessary 
> > > text,
> > > though, so read the instructions below anyway.
> > >
> > > The canonical patch subject line is:
> > >
> > > Subject: [PATCH 001/123] subsystem: summary phrase
> > >
> > > The canonical patch message body contains the following:
> > >
> > >   * A |from| line specifying the patch author, followed by an empty 
> > > line
> > > (only needed if the person sending the patch is not the author).
> > >   * The body of the explanation, line wrapped at 75 columns, which 
> > > will be
> > > copied to the permanent changelog to describe this patch.
> > >   * An empty line.
> > >   * The |Signed-off-by:| lines, described above, which will also go 
> > > in the
> > > changelog.
> > >   * A marker line containing simply |---|.
> > >   * Any additional comments not suitable for the changelog.
> > >   * The actual patch (|diff| output).
> > >
> > >
> > > - Armin
> 
> There are existing git hooks that can be used to detect and fail to
> merge patches like this.  For Linux, I have the following in
> .git/hooks/pre-commit
> #!/bin/sh
> exec git diff --cached | scripts/checkpatch.pl -

FWIW, over in U-Boot land I do:
./scripts/checkpatch.pl -q --git origin/master..
as part of checking things prior to pushing to master.

-- 
Tom


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Proposed new QA process

[richard . purdie]

This is a good start. I've filled out some details below and had some
questions.

On Tue, 2019-04-02 at 03:28 +, Yeoh, Ee Peng wrote:
> Given the new QA tooling (resulttool) available to manage QA test
> results and reporting, here was the proposed new QA process.
>  
> The new QA process consists below:
> ·   Test Trigger
> ·   Test Planning
> ·   Test Execution
> ·   Test Result Store
> ·   Test Monitoring & Reporting
> ·   Release Decision
>  
> Test Trigger: Each QA team will subscribe to QA notification email
> (request through Richard Purdie).

The list of notifications is maintained on config.json in the yocto-
autobuilder-helper which has a branch per release.
 
> Test Planning: The lead QA team no longer need to setup Testopia and
> wiki page.  Each QA team (eg. intel, windriver, etc) will perform
> planning on what extra tests they plan to run and when they'll send
> the results back, then send these planning information as acknowledge
> email to QA stakeholders (eg. Richard Purdie, Stephen Jolley) and the
> lead QA team.  Each QA team can refer to OEQA for automated and
> manual test cases for their planning.

What form will these notifications take? Is there a time limit for when
they'll be received after a QA notification email? Can we agree to
include an estimate of execution time in this notification?

> Test Execution: Each QA team will execute the planned extra tests. To
> make sure test result from the test execution could fully integrated
> to the new QA tooling (resulttool for test result management and
> reporting/regression), execute OEQA automated tests and OEQA manual
> tests through resulttool (refer 
> https://wiki.yoctoproject.org/wiki/Resulttool#manualexecution).
>  
> Test Result Store: Each QA team will store test result to the remote
> yocto-testresults git repository using resulttool (refer 
> https://wiki.yoctoproject.org/wiki/Resulttool#store), then send the
> QA completion email (include new defects information) to both QA
> stakeholder and the lead QA team.  Each QA team will request write
> access to remote yocto-testresults git repository (request through
> Richard Purdie).

Ultimately, yes but I want to have things working before we have
multiple people pushing things there. Need to document the commands
used here to add the results too.

Do we need to add something to the results to indicate which results
are from "who"? (i.e. from the public autobuilder, Intel QA, WR QA, any
other sources?). We may want to add something such as a parameter to
the resulttool store command so we can add this info to results?
 
> Test Monitoring & Reporting: QA stakeholder will monitor testing
> progress from remote yocto-testresults git repository using
> resulttool (refer 
> https://wiki.yoctoproject.org/wiki/Resulttool#report).  Once every QA
> team completed the test execution, the lead QA team will create QA
> test report and regression using resulttool. Send email report to QA
> stakeholder and public yocto mailing list.

We should document the command to do this. I'm also wondering where the
list of stakeholders would be maintained?

Is Intel volunteering to help with this role for the time being or does
someone else need to start doing this.

A key thing we need to document here is that someone, somewhere in this
process needs to:

a) Open a bug for each unique QA test failure
b) List the bugs found in the QA report
c) Notice any ptest timeouts and file bugs for those too

> Release Decision: QA stakeholder will make the final decision for
> release.

The release decision will ultimately be made by the Yocto Project TSC
who will review the responses to the QA report (including suggestions
from QA) and make a go/nogo decision on that information (exact process
to be agreed by the TSC).

Cheers,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Git commit process question.

[akuster808]

On 4/2/19 12:46 PM, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote:
>> On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
>>>
>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
 On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> Hello,
>
> I have noticed a large number of git commits with no header
> information being accepted.
 Can you be more specific about what "no header information" means? You
 mean a shortlog and no full log message?
>>> Commits with just a "subject" and signoff. No additional information
>>>
>>> We tend to reference back to how the kernel does things.
>>>
>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>>> These two sections in particular.
>>>
>>>
>>> 2) Describe your changes
>>>
>>> Describe your problem. Whether your patch is a one-line bug fix or 5000
>>> lines of a new feature, there must be an underlying problem that
>>> motivated you to do this work. Convince the reviewer that there is a
>>> problem worth fixing and that it makes sense for them to read past the
>>> first paragraph.
>>> ...
>> The kernel does not have "upgrade foo to the latest upstream version" 
>> commits.
>>
>> With the Automatic Upgrade Helper this is a semi-automatic task, and 
>> most of the time there is no specific motivation other than upgrading
>> to the latest upstream version.
> But since that's just filling in a template the body can also be a
> template perhaps with useful AUH data (run at ... by ... ?) ?..

Maybe, if someone want to enhance the AUH.

- armin
>

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] [OE-core] Git commit process question.

[akuster808]

On 4/2/19 12:47 PM, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 04:45:16AM +, Jon Mason wrote:
>> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle  wrote:
>>> On 4/1/19 6:20 PM, akuster808 wrote:

 On 4/1/19 4:02 PM, Richard Purdie wrote:
> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>> Hello,
>>
>> I have noticed a large number of git commits with no header
>> information being accepted.
> Can you be more specific about what "no header information" means? You
> mean a shortlog and no full log message?
 Commits with just a "subject" and signoff. No additional information
>>> If you can convey the reason for the change in just the subject, that is
>>> acceptable.. but there is -always- supposed to be a signed-off-by line 
>>> according
>>> to our guidelines.
>>>
>>> So if you see this, I think we need to step back and figure out where and 
>>> why
>>> it's happening and get it resolved in the future.
>>>
>>> (Places I've seen in the past were one-off mistakes and clearly that -- so 
>>> it
>>> wasn't anything that we needed to work on a correction.)
>>>
>>> --Mark
>>>
 We tend to reference back to how the kernel does things.

 https://www.kernel.org/doc/html/latest/process/submitting-patches.html
 These two sections in particular.


 2) Describe your changes

 Describe your problem. Whether your patch is a one-line bug fix or 5000 
 lines of
 a new feature, there must be an underlying problem that motivated you to 
 do this
 work. Convince the reviewer that there is a problem worth fixing and that 
 it
 makes sense for them to read past the first paragraph.


 along with this section.


 14) The canonical patch format

 This section describes how the patch itself should be formatted. Note 
 that, if
 you have your patches stored in a |git| repository, proper patch 
 formatting can
 be had with |git format-patch|. The tools cannot create the necessary text,
 though, so read the instructions below anyway.

 The canonical patch subject line is:

 Subject: [PATCH 001/123] subsystem: summary phrase

 The canonical patch message body contains the following:

   * A |from| line specifying the patch author, followed by an empty 
 line
 (only needed if the person sending the patch is not the author).
   * The body of the explanation, line wrapped at 75 columns, which 
 will be
 copied to the permanent changelog to describe this patch.
   * An empty line.
   * The |Signed-off-by:| lines, described above, which will also go in 
 the
 changelog.
   * A marker line containing simply |---|.
   * Any additional comments not suitable for the changelog.
   * The actual patch (|diff| output).


 - Armin
>> There are existing git hooks that can be used to detect and fail to
>> merge patches like this.  For Linux, I have the following in
>> .git/hooks/pre-commit
>> #!/bin/sh
>> exec git diff --cached | scripts/checkpatch.pl -
> FWIW, over in U-Boot land I do:
> ./scripts/checkpatch.pl -q --git origin/master..
> as part of checking things prior to pushing to master.
Having hooks is fine but after the fact. It puts the burden back on the
Layer maintainer to resolve. If we think more info is better, it needs
to happen at time of change submittal.

- armin
>
>



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] [OE-core] Git commit process question.

[Tom Rini]

On Tue, Apr 02, 2019 at 02:24:51PM -0700, akuster808 wrote:
> 
> 
> On 4/2/19 12:47 PM, Tom Rini wrote:
> > On Tue, Apr 02, 2019 at 04:45:16AM +, Jon Mason wrote:
> >> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle  wrote:
> >>> On 4/1/19 6:20 PM, akuster808 wrote:
> 
>  On 4/1/19 4:02 PM, Richard Purdie wrote:
> > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> >> Hello,
> >>
> >> I have noticed a large number of git commits with no header
> >> information being accepted.
> > Can you be more specific about what "no header information" means? You
> > mean a shortlog and no full log message?
>  Commits with just a "subject" and signoff. No additional information
> >>> If you can convey the reason for the change in just the subject, that is
> >>> acceptable.. but there is -always- supposed to be a signed-off-by line 
> >>> according
> >>> to our guidelines.
> >>>
> >>> So if you see this, I think we need to step back and figure out where and 
> >>> why
> >>> it's happening and get it resolved in the future.
> >>>
> >>> (Places I've seen in the past were one-off mistakes and clearly that -- 
> >>> so it
> >>> wasn't anything that we needed to work on a correction.)
> >>>
> >>> --Mark
> >>>
>  We tend to reference back to how the kernel does things.
> 
>  https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>  These two sections in particular.
> 
> 
>  2) Describe your changes
> 
>  Describe your problem. Whether your patch is a one-line bug fix or 5000 
>  lines of
>  a new feature, there must be an underlying problem that motivated you to 
>  do this
>  work. Convince the reviewer that there is a problem worth fixing and 
>  that it
>  makes sense for them to read past the first paragraph.
> 
> 
>  along with this section.
> 
> 
>  14) The canonical patch format
> 
>  This section describes how the patch itself should be formatted. Note 
>  that, if
>  you have your patches stored in a |git| repository, proper patch 
>  formatting can
>  be had with |git format-patch|. The tools cannot create the necessary 
>  text,
>  though, so read the instructions below anyway.
> 
>  The canonical patch subject line is:
> 
>  Subject: [PATCH 001/123] subsystem: summary phrase
> 
>  The canonical patch message body contains the following:
> 
>    * A |from| line specifying the patch author, followed by an empty 
>  line
>  (only needed if the person sending the patch is not the author).
>    * The body of the explanation, line wrapped at 75 columns, which 
>  will be
>  copied to the permanent changelog to describe this patch.
>    * An empty line.
>    * The |Signed-off-by:| lines, described above, which will also go 
>  in the
>  changelog.
>    * A marker line containing simply |---|.
>    * Any additional comments not suitable for the changelog.
>    * The actual patch (|diff| output).
> 
> 
>  - Armin
> >> There are existing git hooks that can be used to detect and fail to
> >> merge patches like this.  For Linux, I have the following in
> >> .git/hooks/pre-commit
> >> #!/bin/sh
> >> exec git diff --cached | scripts/checkpatch.pl -
> > FWIW, over in U-Boot land I do:
> > ./scripts/checkpatch.pl -q --git origin/master..
> > as part of checking things prior to pushing to master.
> Having hooks is fine but after the fact. It puts the burden back on the
> Layer maintainer to resolve. If we think more info is better, it needs
> to happen at time of change submittal.

Note that I'm not talking about a hook, I'm talking about what's part of
my CI process.  And when something pops up there is when I grab the
patch in question and push back on the submitter.

-- 
Tom


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] [OE-core] Git commit process question.

[Jon Mason]

On Wed, Apr 3, 2019 at 7:45 AM Tom Rini  wrote:
>
> On Tue, Apr 02, 2019 at 02:24:51PM -0700, akuster808 wrote:
> >
> >
> > On 4/2/19 12:47 PM, Tom Rini wrote:
> > > On Tue, Apr 02, 2019 at 04:45:16AM +, Jon Mason wrote:
> > >> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle  
> > >> wrote:
> > >>> On 4/1/19 6:20 PM, akuster808 wrote:
> > 
> >  On 4/1/19 4:02 PM, Richard Purdie wrote:
> > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >> Hello,
> > >>
> > >> I have noticed a large number of git commits with no header
> > >> information being accepted.
> > > Can you be more specific about what "no header information" means? You
> > > mean a shortlog and no full log message?
> >  Commits with just a "subject" and signoff. No additional information
> > >>> If you can convey the reason for the change in just the subject, that is
> > >>> acceptable.. but there is -always- supposed to be a signed-off-by line 
> > >>> according
> > >>> to our guidelines.
> > >>>
> > >>> So if you see this, I think we need to step back and figure out where 
> > >>> and why
> > >>> it's happening and get it resolved in the future.
> > >>>
> > >>> (Places I've seen in the past were one-off mistakes and clearly that -- 
> > >>> so it
> > >>> wasn't anything that we needed to work on a correction.)
> > >>>
> > >>> --Mark
> > >>>
> >  We tend to reference back to how the kernel does things.
> > 
> >  https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> >  These two sections in particular.
> > 
> > 
> >  2) Describe your changes
> > 
> >  Describe your problem. Whether your patch is a one-line bug fix or 
> >  5000 lines of
> >  a new feature, there must be an underlying problem that motivated you 
> >  to do this
> >  work. Convince the reviewer that there is a problem worth fixing and 
> >  that it
> >  makes sense for them to read past the first paragraph.
> > 
> > 
> >  along with this section.
> > 
> > 
> >  14) The canonical patch format
> > 
> >  This section describes how the patch itself should be formatted. Note 
> >  that, if
> >  you have your patches stored in a |git| repository, proper patch 
> >  formatting can
> >  be had with |git format-patch|. The tools cannot create the necessary 
> >  text,
> >  though, so read the instructions below anyway.
> > 
> >  The canonical patch subject line is:
> > 
> >  Subject: [PATCH 001/123] subsystem: summary phrase
> > 
> >  The canonical patch message body contains the following:
> > 
> >    * A |from| line specifying the patch author, followed by an 
> >  empty line
> >  (only needed if the person sending the patch is not the 
> >  author).
> >    * The body of the explanation, line wrapped at 75 columns, which 
> >  will be
> >  copied to the permanent changelog to describe this patch.
> >    * An empty line.
> >    * The |Signed-off-by:| lines, described above, which will also 
> >  go in the
> >  changelog.
> >    * A marker line containing simply |---|.
> >    * Any additional comments not suitable for the changelog.
> >    * The actual patch (|diff| output).
> > 
> > 
> >  - Armin
> > >> There are existing git hooks that can be used to detect and fail to
> > >> merge patches like this.  For Linux, I have the following in
> > >> .git/hooks/pre-commit
> > >> #!/bin/sh
> > >> exec git diff --cached | scripts/checkpatch.pl -
> > > FWIW, over in U-Boot land I do:
> > > ./scripts/checkpatch.pl -q --git origin/master..
> > > as part of checking things prior to pushing to master.
> > Having hooks is fine but after the fact. It puts the burden back on the
> > Layer maintainer to resolve. If we think more info is better, it needs
> > to happen at time of change submittal.
>
> Note that I'm not talking about a hook, I'm talking about what's part of
> my CI process.  And when something pops up there is when I grab the
> patch in question and push back on the submitter.

Exactly!  I do the same things for the Linux stuff I own.  I'll do a
git-am, then redir the output and publicly shame them.  Public shaming
is a vastly underrated method of behavior modification.

Thanks,
Jon

>
> --
> Tom
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Error during qtbase compilation on "thud" branch

[Gaurav Pathak]

Hi,

I am getting an error "undefined reference to main" during qtbase compilation.
I am not getting any idea about how this error.

The error log is here: https://pastebin.com/Wt0SXH4M



Thanks,
Gaurav
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.7 M3 RC1

[Jain, Sangeeta]

Hi Richard,

For oe-selftest -r runqemu,meta_ide, configuration we are using is only 
changing the machine type.

For adding "who" identifier in resulttool command, we can take it up as an 
enhancement.

Thanks & Regards,
Sangeeta Jain

>-Original Message-
>From: richard.pur...@linuxfoundation.org 
>Sent: Wednesday, 3 April, 2019 2:32 AM
>To: Jain, Sangeeta ; 'yocto@yoctoproject.org'
>; Eggleton, Paul ; 'Michael
>Halstead' ; Erway, Tracey M
>; sjolley.yp...@gmail.com; Burton, Ross
>
>Cc: OTC Embedded Malaysia 
>Subject: Re: QA cycle report for 2.7 M3 RC1
>
>Hi Sangeeta/Ee Peng,
>
>On Tue, 2019-04-02 at 05:02 +, Jain, Sangeeta wrote:
>> QA cycle report for 2.7 M3 RC1:
>>
>> No high milestone defects.
>> This is completion of first QA cycle after adoption of new QA process.
>> Test results are available at following location:
>> ·For results of all automated tests, please refer to results
>> at public AB [1].
>> ·For other test results, refer to attachment [2].
>> ·For test report for test cases run by Intel and WR team,
>> refer attachment [3]
>> ·For full test report, refer attachment [4]
>> 2 new defects are found in this cycle, oe-selftest [5] and qemu-
>> shutdown[6].
>> Number of existing issues observed in this release is 3- toaster [7],
>> Build-appliance [8] and Beaglebone [9] For ptest, 3 package tests are
>> failing in this release which were passing in previous release: python
>> [10], python3[11] and strace[12].
>> 3 packages are facing timeout issues: lttng-tools [13], openssh [14]
>> and python3 [15].
>
>Thanks for this. I have some questions/observations.
>
>Looking at the Intel/WR report, I see tests which start oeselftest_XXX for sdk-
>extras and qemu-shutdown. I think this means you have some QA test
>infrastructure running "oe-selftest -r runqemu,meta_ide", iterating over
>MACHINE=qemuppc, qemumips, qemuarm, qemux86?
>
>Is this some automation we're missing in the autobuilder configuration?
>We all other tests covered and this is the only remaining automated piece we
>haven't covered? What configuration are we missing exactly for the missing
>tests?

Just run for MACHINE=qemuppc /qemumips / qemuarm / qemux86

>
>I'm partly wondering how you found the shutdown issue but this would explain
>that.
>
>I think going forward we need to add some kind of "who" identifier to the test
>results so we can say where/who they came from (main autobuilder, Intel, WR,
>anywhere else). We could add a resulttool command to "stamp" a set of test
>results with this, maybe as a parameter to the store command?

Will work on resulttool to add this enhancement. Though not sure about timeline 
as of now.

>
>Of the bugs, I didn't see any which I think should block M3, I think we 
>probably
>should release that and move forward to M4. I do want to see some of these
>fixed before we build M4 though. I've made comments on them below.
>
>> New Bugs :
>>
>> [5] Bug 13237 - [2.7 M3 RC1][OE-selftest][Opensuseleap 15.0][Public
>> AB]:"test_wic_cp_ext" failing for Opensuseleap 15.0.
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13237
>
>Ross: Are you looking into that one?
>
>> [6] Bug 13234 - [2.7 M3 RC1] qemumips & qemumips64: failed to shutdown
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13234
>
>This needs looking into and fixing, as well as figuring out why the autobuilder
>doesn't see this (see above for my hypothesis).
>
>> Previous Bugs observed in this release:
>>
>> [7] Bug 13191 – [Test Case 1439] Build Failure after adding or
>> removing packages with and without dependencies
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13191
>>
>> [8] Bug 12991 - [Bug] [2.6 M4 RC1][Build-Appliance] Bitbake build-
>> appliance-image getting failed during building image due to webkitgtk
>> package.
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12991
>
>We need to do something about this. I believe its related to resource 
>starvation in
>the VM.
>
>> [9] Bug 13153 – [2.7 M2 RC1] Systemtap doesn't work on beaglebone
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13153
>
>I'm hoping a SRCREV bump for beaglebone-yocto fixes this.
>
>> ptest Bugs:
>>
>> [10] Bug 13249 - [2.7 M3 RC1] python ptest failure
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13249
>
>I'm hoping a patch from Ross in master fixes this, need to retest ptest with 
>this
>applied.
>
>> [11] Bug 13253 - [2.7 M3 RC1] python3 ptest failure
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13253
>
>I'm hoping a patch from Ross in master fixes this, need to retest ptest with 
>this
>applied.
>
>> [12] Bug 13254 - [2.7 M3 RC1] strace ptest failure
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13254
>
>No ideas on this one yet.
>
>> [13] Bug 13255 - [2.7 M3 rc1] lttng-tools ptest facing timeout issue
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13255
>
>There are patches which are due to arrive soon which should address this.
>
>> [14] Bug 13256 - [2.7 M3 rc1] openss