[yocto] QA cycle report for 2.5 M2 RC1
Hello All, This is the full report for 2.5 M2 RC1: https://wiki.yoctoproject.org/wiki/WW07_-_2018-02-14-_Full_Test_Cycle_-_2.5_M2_rc1 === Summary The QA cycle for release 2.5 M2 RC1 was completed including the performance test. Team had discovered a new bug [1] where sdk toolchain downloaded from Public Autobuilder failed when executing runqemu command. YP QA recently requested the performance host machines from linux foundation to replace old machines, where initial setup completed at WW06 and going through testing. Performance tests were executed for both 2.5 M2 RC1 and 2.5 M1 RC3 (as regression and benchmark) on these new machines in linux foundation. === QA-Hints Need to fix the sdk toolchain bug in order to enable runqemu. Performance results show that no significant differences in performance tests. === Bugs New Bugs - 12545 [1] [2.5 M2 RC1] SDK runqemu failed with python import logging Links = 1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12545 [1] Regards Ee Peng -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux][PATCH 1/2] iproute2: remove workaround for selinux
On 2018年02月07日 14:49, kai.k...@windriver.com wrote:
From: Kai Kang
After upgrade to 4.14.1, iproute2 changes it way to create configure output
file config.mk which is also renamed from 'Config'. With RSS, the workaround
for iproute2 is not needed any more.
Ping.
--Kai
Signed-off-by: Kai Kang
---
recipes-connectivity/iproute2/iproute2_%.bbappend | 2 +-
recipes-connectivity/iproute2/iproute2_selinux.inc | 5 -
2 files changed, 1 insertion(+), 6 deletions(-)
delete mode 100644 recipes-connectivity/iproute2/iproute2_selinux.inc
diff --git a/recipes-connectivity/iproute2/iproute2_%.bbappend
b/recipes-connectivity/iproute2/iproute2_%.bbappend
index 7719d3b..b01ad25 100644
--- a/recipes-connectivity/iproute2/iproute2_%.bbappend
+++ b/recipes-connectivity/iproute2/iproute2_%.bbappend
@@ -1 +1 @@
-require ${@bb.utils.contains('DISTRO_FEATURES', 'selinux',
'${BPN}_selinux.inc', '', d)}
+inherit ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'with-selinux', '',
d)}
diff --git a/recipes-connectivity/iproute2/iproute2_selinux.inc
b/recipes-connectivity/iproute2/iproute2_selinux.inc
deleted file mode 100644
index b0a7ffe..000
--- a/recipes-connectivity/iproute2/iproute2_selinux.inc
+++ /dev/null
@@ -1,5 +0,0 @@
-inherit with-selinux
-
-do_configure_append() {
- sed -i 's/\(HAVE_SELINUX:=\).*/\1y/' ${B}/Config
-}
--
Regards,
Neil | Kai Kang
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] behind corporate proxy
On Wed, Feb 21, 2018 at 5:11 AM, Staffa, Christian AVL/DE wrote: > Hi all > > I have got a problem with proxy settings and the yocto build system. > > I already read the ‘Behind a Proxy Guide’ and generally it works. > > But when it comes to build the linux-yocto package the buildsystem tries to > clone a repo with the git:// scheme. > > This results in connecting to git.yoctoproject.org:9418 but this port is > blocked by the corporate proxy and causes the build to fail. > > Had anyone the same problem? Is there a way to fetch the repo via http(s)? Yes, many people have the same problem. If you can update to OE 2.3 or above then this commit should provide a fallback to fetch the repo using https: http://git.openembedded.org/openembedded-core/commit/?id=abb8895d5b42a5dc171360a261a2652acd14ee7e If you can't update, that patch should be an easy backport to older releases. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Expansion of variables inside do_package_prepend task
On Wed, 2018-02-21 at 16:50 +0100, Iván Castell wrote:
> Hello forum.
>
> I have a question regarding the expansion of variables in a recipe.
> Suppose I have a recipe with this "do_install" task defined:
>
> do_install() {
> BBB = ${WORKDIR}
> }
>
> Variable BBB expands to the proper working directory.
>
>
> $ bitbake -e | grep BBB
> BBB = /path/to/working/directory
>
>
> However, suppose now I have a recipe with this "do_package_prepend"
> task defined:
>
> do_package_prepend() {
> AAA = ${WORKDIR}
> }
>
> Variable AAA doesn't expand to the expected working directory. In
> fact, it generates an error:
>
>
> $ bitbake -e | grep AAA
> AAA = ${WORKDIR}
> ^
> SyntaxError: invalid syntax
do_package is a python function, so you prepend code must also be
python. You can do:
AAA = d.getVar('WORKDIR')
> It seems the expansion of variables is not working inside the
> do_package_prepend task. What is going wrong with that?
>
> Thank you in advance! :-)
>
> --
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Expansion of variables inside do_package_prepend task
Hello forum.
I have a question regarding the expansion of variables in a recipe. Suppose
I have a recipe with this "do_install" task defined:
do_install() {
BBB = ${WORKDIR}
}
Variable BBB expands to the proper working directory.
$ bitbake -e | grep BBB
BBB = /path/to/working/directory
However, suppose now I have a recipe with this "do_package_prepend" task
defined:
do_package_prepend() {
AAA = ${WORKDIR}
}
Variable AAA doesn't expand to the expected working directory. In fact, it
generates an error:
$ bitbake -e | grep AAA
AAA = ${WORKDIR}
^
SyntaxError: invalid syntax
It seems the expansion of variables is not working inside the
do_package_prepend task.
What is going wrong with that?
Thank you in advance! :-)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] behind corporate proxy
2018-02-21 14:11 GMT+01:00 Staffa, Christian AVL/DE :
> Hi all
>
>
>
> I have got a problem with proxy settings and the yocto build system.
>
>
>
> I already read the ‘Behind a Proxy Guide’ and generally it works.
>
> But when it comes to build the linux-yocto package the buildsystem tries to
> clone a repo with the git:// scheme.
>
> This results in connecting to git.yoctoproject.org:9418 but this port is
> blocked by the corporate proxy and causes the build to fail.
>
>
>
> Had anyone the same problem? Is there a way to fetch the repo via http(s)?
>
>
>
> Regards
>
> Chris
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
Hi Chris,
I had the same kind of problem.
I fixed it this way (not sure it's the best solution):
===
$ cat ./meta/recipes-bsp/firmware-imx_%.bbappend
SRC_URI_remove =
"git://git.freescale.com/imx/imx-firmware.git;branch=${SRCBRANCH};destsuffix=${S}/git"
SRC_URI_append =
"git://git.freescale.com/imx/imx-firmware.git;branch=${SRCBRANCH};destsuffix=${S}/git;protocole=http"
===
Note: the git server must support the http (or maybe https) protocole.
--
Philippe GISLARD
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] behind corporate proxy
Hi all I have got a problem with proxy settings and the yocto build system. I already read the 'Behind a Proxy Guide' and generally it works. But when it comes to build the linux-yocto package the buildsystem tries to clone a repo with the git:// scheme. This results in connecting to git.yoctoproject.org:9418 but this port is blocked by the corporate proxy and causes the build to fail. Had anyone the same problem? Is there a way to fetch the repo via http(s)? Regards Chris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Integrity checking fails with Atmel SHA hw accelerator enabled
Hi I'm having some trouble using dm-verity for a squashfs root file system that seems to be related to the Atmel SHA hw accelerator in the kernel, CONFIG_CRYPTO_DEV_ATMEL_SHA Some info about my setup: * I'm using a board with a SAMA5D4 CPU. * I'm using Yocto rocko for building an image for that device. The idea is that Using the 4.14.14 Kernel, Integrity checking using Kernel crypto fails with Atmel SHA hw accelerator enabled in kernel. By disabling it, `CONFIG_CRYPTO_DEV_ATMEL_SHA=n`, and using the software sha256 algo, integrity checking works as expected. This is my kernel config: https://gist.githubusercontent.com/gmircea/6e1cc029ef5ed7a16b0fedb8b9524f66/raw/eece8a8faadd2de9373e150ef1daf3cf25f4135c/.config Using the 4.8.4 Kernel and Atmel SHA hw accelerator enabled, everything was ok. So it looks like the new commits, from 4.8.4 to 4.14.14, on atmel-sha.c (or at least I assume that may be a possible source of the problem) changes the behavior and breaks our use case: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/crypto/atmel-sha.c?h=v4.8.4 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/crypto/atmel-sha.c?h=v4.14.14 This is what triggers the error during verified boot: status=`veritysetup create vroot $root_dev $verity_dev --hash-offset $hashoffset $root_hash` mount /dev/mapper/vroot /mnt/ mount_ok=`cat /proc/mounts | grep mnt` if [ -z "$mount_ok" ] ; then echo "Failed to mount $root_dev on mnt/" else echo "Switch rootfs" exec switch_root -c /dev/console /mnt /sbin/init fi The mount operation fails: device-mapper: verity: 179:4: metadata block 2 is corrupted EXT4-fs (dm-0): unable to read superblock device-mapper: verity: 179:4: metadata block 2 is corrupted EXT4-fs (dm-0): unable to read superblock device-mapper: verity: 179:4: metadata block 2 is corrupted EXT4-fs (dm-0): unable to read superblock device-mapper: verity: 179:4: metadata block 2 is corrupted SQUASHFS error: squashfs_read_data failed to read block 0x0 squashfs: SQUASHFS error: unable to read squashfs_super_block device-mapper: verity: 179:4: metadata block 2 is corrupted FAT-fs (dm-0): unable to read boot sector mount: mounting /dev/mapper/vroot on /mnt/ failed: Input/output error Failed to mount /dev/mmcblk0p4 on mnt/ Smartcom initramfs init failed reboot: Restarting system Reboot failed -- System halted Using veritysetup to verify the integrity against the hashes is successful, as it's not using the kernel for that ... Any help is appreciated ! Thanks in advanced and have a nice day. Mircea -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox completely from the generated image
2018-02-21 4:01 GMT+01:00 Paul Eggleton : > On Tuesday, 20 February 2018 9:26:49 PM NZDT Iván Castell wrote: > > 2018-02-20 7:45 GMT+01:00 Martin Hundebøll : > > >> Thank you for the information, I will take into account that tool for > > >> future embedded projects. However, the focus of this issue was to > remove > > >> completely busybox from the image, not replacing it by another > > >> application box. > > >> > > >> I have created a bbappend with a fragment of the busybox configuration > > >> disabling syslog and udhcpc applets. It works. However the busybox > binary > > >> and a lot of applets are still there (adduser, unzip, fbset, > traceroute, > > >> and more). > > >> > > >> Disabling all different applets and installing native tools instead > could > > >> be the right way to procede. Not a nice solution, but at least it > should > > >> work... > > >> > > > > > > Here's what we have in our distro config to disable busybox: > > > > > > > # Disable busybox > > > > VIRTUAL-RUNTIME_base-utils = "" > > > > ALTERNATIVE_PRIORITY_pn-busybox = "1" > > > > > > The priority setting make bitbake pull in alternatives from util-linux > / > > > coreutils when appropriate. > > > > Yes!! That was the trick. It works like a charm!! Thank you so much Mr. > > Martin!! :-) > > I will note that the priority currently set in busybox.inc is 50, which is > lower than coreutils 100 (or 90 for hostname), so that part shouldn't be > needed for coreutils. There are one or two other recipes that set a > priority > lower than 50 for reasons that are not immediately clear to me. > > Additionally, ALTERNATIVE_PRIORITY won't do anything to control what goes > into > the image - it only controls which binary is selected at runtime when more > than one providing the same binary is installed. Thus I can only assume > that > it was the VIRTUAL-RUNTIME_base-utils = "" that finally removed the > packages > you wished removed. > > Cheers, > Paul > I have tested your suggestion, disabling the ALTERNATIVE_PRIORITY declaration: VIRTUAL-RUNTIME_base-utils = "" # ALTERNATIVE_PRIORITY = And effectively the generated image contains any reference to busybox toolbox at all. Thank you very much for the clarification, Mr Paul!! :-) I want to add that, if your custom image installs packagegroup-core-boot, then you also need to set VIRTUAL-RUNTIME_login_manager variable with a valid value different from "busybox". My custom image includes that packagegroup, so to achieve my goal, I define in my distro.conf this variable: VIRTUAL-RUNTIME_login_manager = "shadow" Hope this helps to somebody else. Thank you for all your support! :-) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
