Date   

Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device

Trevor Woerner
 

On Thu 2021-09-23 @ 09:46:40 PM, Khem Raj wrote:
are you both using systemd or sysvinit
Ah, good catch. I'm using sysvinit.


#yocto -third party licensimg #yocto

Monsees, Steven C (US)
 

 

Hello:

 

I am running zeus 3.0.4…

 

A vendor has supplied us with a generic license.txt file, which we were able to add to the acexpci recipe we use to build in their package.

The license provided to us by the vendor is not part of the generic licenses list that yocto recognizes.

 

We get a warning though which says:

 

WARNING: aiox-defaultfs-1.0-r0 do_rootfs: The license listed DataDeviceCorporation was not in the licenses collected for recipe acexpci

 

Though the warning occurs, I can see the license.txt being saved inside the rootfs on and is saved under tmp/deploy/licenses/acexpci.

I’ve been trying to get rid of this warning when the image builds, but I can’t seem to find anything in the manuals or online.

 

The one solution I found says : Add LICENSE_PATH += "${LAYERDIR}/custom-licenses" under conf/layer.conf, this does not resolve this warning.

 

This is a new item being added to our Yocto build.

The Data Direct vendor does not submit their code to Yocto because they sell thier code.

We are adding code to Yocto that has a private license and we are attempting to have Yocto accept the license, is this proper way to handle this ?

 

Can you tell me the proper way to add a custom license to a recipe in yocto ?

 

Thanks,

Steve


Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device

Markus Volk
 


Am 24.09.21 um 06:46 schrieb Khem Raj:
are you both using systemd or sysvinit
I am using systemd


Re: Cross-compiling or compiling on target VM?

Alexander Kanavin
 

Yocto has built-in qemu targets for this purpose, and associated infrastructure to start qemu VMs and run tests in them. But to make it practical, these qemu images need to be started on a baremetal Linux machine. So I'd suggest you start by giving all your developers Linux laptops.

Alex


On Fri, 24 Sept 2021 at 11:06, <arnaud.bienner@...> wrote:
Hi,

We are starting a new project using Yocto to build a custom Linux image which matches our needs.
We are new to Yocto and still trying to figure out the best way to work with it.

Especially, if it is best to cross-compile or to build on a VM running an image of the target.

Some background:
Our target system is x86_64, and we are all working on x86_64 computers obviously.
For now, we don't have yet a physical target system so we are running the image generated by Yocto in VirtualBox or VMWare.

For practical reasons, since not all developers use the same OS (Windows, macOS) we decided to do all development work on Linux VM (Debian distribution) so everyone has the same system.
For now, we are cross-compiling applications using Yocto SDK in that Debian VM, copying it to the Yocto VM to run it.
Even though copying/deploying and running them could be somehow automated, since we are developing on a Linux VM anyway, I thought it could be best to build a Yocto image (maybe as an additional "dev" image based on the existing one) which contains all tools we need (gcc, cmake, etc.).

This way, we could execute the binaries (in particular the unit tests) locally.
For some of our unit tests in particular that we run at build time, it sounds easier to run them locally, compared to deploying them and running them remotely.

Any thoughts about this?

In advance, thanks a lot for your help.

Best regards,
Arnaud



[meta-selinux][PATCH] libsepol: Security fix for CVE-2021-36086

Yi Zhao
 

CVE-2021-36086:
The CIL compiler in SELinux 3.2 has a use-after-free in cil_reset_classpermission
(called from cil_reset_classperms_set and cil_reset_classperms_list).

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2021-36086

Patch from:
https://github.com/SELinuxProject/selinux/commit/c49a8ea09501ad66e799ea41b8154b6770fec2c8

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../selinux/libsepol/CVE-2021-36086.patch | 46 +++++++++++++++++++
recipes-security/selinux/libsepol_3.2.bb | 3 +-
2 files changed, 48 insertions(+), 1 deletion(-)
create mode 100644 recipes-security/selinux/libsepol/CVE-2021-36086.patch

diff --git a/recipes-security/selinux/libsepol/CVE-2021-36086.patch b/recipes-security/selinux/libsepol/CVE-2021-36086.patch
new file mode 100644
index 0000000..7a2d616
--- /dev/null
+++ b/recipes-security/selinux/libsepol/CVE-2021-36086.patch
@@ -0,0 +1,46 @@
+From 49f9aa2a460fc95f04c99b44f4dd0d22e2f0e5ee Mon Sep 17 00:00:00 2001
+From: James Carter <jwcart2@...>
+Date: Thu, 8 Apr 2021 13:32:06 -0400
+Subject: [PATCH] libsepol/cil: cil_reset_classperms_set() should not reset
+ classpermission
+
+In struct cil_classperms_set, the set field is a pointer to a
+struct cil_classpermission which is looked up in the symbol table.
+Since the cil_classperms_set does not create the cil_classpermission,
+it should not reset it.
+
+Set the set field to NULL instead of resetting the classpermission
+that it points to.
+
+Signed-off-by: James Carter <jwcart2@...>
+
+Upstream-Status: Backport
+[https://github.com/SELinuxProject/selinux/commit/c49a8ea09501ad66e799ea41b8154b6770fec2c8]
+
+CVE: CVE-2021-36086
+
+Signed-off-by: Yi Zhao <yi.zhao@...>
+---
+ cil/src/cil_reset_ast.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/cil/src/cil_reset_ast.c b/cil/src/cil_reset_ast.c
+index 89f91e5..1d9ca70 100644
+--- a/cil/src/cil_reset_ast.c
++++ b/cil/src/cil_reset_ast.c
+@@ -59,7 +59,11 @@ static void cil_reset_classpermission(struct cil_classpermission *cp)
+
+ static void cil_reset_classperms_set(struct cil_classperms_set *cp_set)
+ {
+- cil_reset_classpermission(cp_set->set);
++ if (cp_set == NULL) {
++ return;
++ }
++
++ cp_set->set = NULL;
+ }
+
+ static inline void cil_reset_classperms_list(struct cil_list *cp_list)
+--
+2.17.1
+
diff --git a/recipes-security/selinux/libsepol_3.2.bb b/recipes-security/selinux/libsepol_3.2.bb
index ef5de1e..192f1b3 100644
--- a/recipes-security/selinux/libsepol_3.2.bb
+++ b/recipes-security/selinux/libsepol_3.2.bb
@@ -10,7 +10,8 @@ LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343"
require selinux_common.inc

SRC_URI += "file://CVE-2021-36084.patch \
- file://CVE-2021-36085.patch "
+ file://CVE-2021-36085.patch \
+ file://CVE-2021-36086.patch "

inherit lib_package

--
2.25.1


Cross-compiling or compiling on target VM?

arnaud.bienner@...
 

Hi,

We are starting a new project using Yocto to build a custom Linux image which matches our needs.
We are new to Yocto and still trying to figure out the best way to work with it.

Especially, if it is best to cross-compile or to build on a VM running an image of the target.

Some background:
Our target system is x86_64, and we are all working on x86_64 computers obviously.
For now, we don't have yet a physical target system so we are running the image generated by Yocto in VirtualBox or VMWare.

For practical reasons, since not all developers use the same OS (Windows, macOS) we decided to do all development work on Linux VM (Debian distribution) so everyone has the same system.
For now, we are cross-compiling applications using Yocto SDK in that Debian VM, copying it to the Yocto VM to run it.
Even though copying/deploying and running them could be somehow automated, since we are developing on a Linux VM anyway, I thought it could be best to build a Yocto image (maybe as an additional "dev" image based on the existing one) which contains all tools we need (gcc, cmake, etc.).

This way, we could execute the binaries (in particular the unit tests) locally.
For some of our unit tests in particular that we run at build time, it sounds easier to run them locally, compared to deploying them and running them remotely.

Any thoughts about this?

In advance, thanks a lot for your help.

Best regards,
Arnaud


Re: Using bitbake with external SDK #sdk #zeus #toolchain

Marco Cavallini
 

Hello Enrico,
an eSDK would be enough to do everything, however I would demand the entire development system if I were to start a project, but that is my opinion.
I don't know well Node-RED but using devtool add you should be able to create or manage a recipe for any Node application.
Happy hacking!
--
Marco Cavallini | KOAN sas
Bergamo - Italia
embedded software engineering
https://KoanSoftware.com


Re: Using bitbake with external SDK #sdk #zeus #toolchain

enrico.buffoli1994@...
 

Hello Marco,

In your opinion isn't enough to ask for eSDK? for instance if i want to add Node-RED, it would be difficult to build with devtool? because i've seen that it doesn't resolve dependencies automatically.
Thanks.


Re: Using bitbake with external SDK #sdk #zeus #toolchain

enrico.buffoli1994@...
 

With the eSDK i've to use devtool right?


Re: Using bitbake with external SDK #sdk #zeus #toolchain

Marco Cavallini
 

Hello Enrico,
usually nowadays every honest hardware manufacturer provides all the sources of the BSP and the development system to their customers.
Try asking your supplier for them.
--
Marco Cavallini | KOAN sas
Bergamo - Italia
embedded software engineering
https://KoanSoftware.com


[meta-zephyr][PATCH 1/2] zephyr-qemuboot: fix parse build failure

Naveen Saini
 

As OE-core explicitly have added depends for qemu-helper addto_recipe_sysroot task, which
breaks zephyr-qemuboot implementation of adding build dependencies
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=282d596b8cc81d650b6d20c6131fdc236bad2c20

ERROR: Error for meta-zephyr/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb:
do_bootconf_write[depends], dependency qemu-helper-native:do_addto_recipe_sysroot:do_addto_recipe_sysroot in
' qemu-helper-native:do_addto_recipe_sysroot:do_addto_recipe_sysroot qemu-helper-native:do_addto_recipe_sysroot:do_populate_sysroot' does not contain exactly one ':' character.
Task 'depends' should be specified in the form 'packagename:task'
ERROR: Command execution failed: Exited with 1

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
classes/zephyr-qemuboot.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/zephyr-qemuboot.bbclass b/classes/zephyr-qemuboot.bbclass
index c268e9e..b45e6f6 100644
--- a/classes/zephyr-qemuboot.bbclass
+++ b/classes/zephyr-qemuboot.bbclass
@@ -48,7 +48,7 @@ python () {
for dep in (d.getVar('EXTRA_IMAGEDEPENDS') or "").split():
# Make sure we only add it for qemu
if 'qemu-helper-native' in dep:
- deps += " %s:%s" % (dep, task)
+ deps += " qemu-helper-native:%s" % (task)
return deps
d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_addto_recipe_sysroot'))
d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_populate_sysroot'))
--
2.17.1


[meta-zephyr][PATCH 2/2] zephyr-kernel: upgrade 2.6.0 -> 2.6.1

Naveen Saini
 

It has GCC-11 fixes.
https://github.com/zephyrproject-rtos/zephyr/issues/35707

Commits included:
2d6322d74a demand_paging: eviction/nru: fix incorrect dirty bit return val
25771e6928 drivers: clock_control: stm32: enable PWR clock unconditionally
92e36185e8 [Backport v2.6-branch] Microchip: XEC GPIO driver interrupt enable part 2
68d33e3834 libc/minimal: locate the memory pool for malloc() to .bss
7f3abab9bf net: tcp: accept [FIN, PSH, ACK] in TCP_FIN_WAIT_2 state
533dcaf374 lib/os/cbprintf_nano.c: avoid sign extension on unsigned formats
ea55ebfa74 tests: schedule_api: use stack array extern macro
95bb8841b8 tests: mem_protect: fix warning on uninitialized variable
1f8c53dfaf tests: kernel/common: avoid using compiler builtin popcount
7bb7454a00 kernel: use proper macro to declare extern interrupt stacks
25fd176014 kernel: add macros to allow declaring extern stack arrays
e1cde092ac kernel: move Z_KERNEL_STACK_LEN higher in thread_stack.h
244049bd71 x86: type cast to uint8_t* for bit ops
5dae0c1bf0 kernel: ignore array bound warnings for generated syscall funcs
5666e4d525 cmake: force GCC to emit DWARF version 4
91a78866ca Bluetooth: Controller: Fix advertising after connections from same peer
0afddb2341 x86/cache: fix issues in arch dcache flush function
9bcf9b6a53 json: fix parsing first array-array element
2595cce714 cmake: oneApi: add oneApi support on windows.
18d314e750 cmake: oneApi: add oneApi support on windows
c8755e0b46 (tag: v2.6.1-rc1) tests/benchmarks: add dynamic memory allocation measurement
a4d35f0a3e doc: 2.6.1 release notes
7094aaee55 release: Bump release to 2.6.1-rc1
585c03a0b6 drivers/clock_control: stm32: Fix macro to get HCLK freq
cacb0a4e59 Bluetooth: L2CAP: Fix missing net_buf_unref()
78ab750540 timer: hpet: convert register access to functions
d9df404d47 timer: hpet: don't force TIMER_READS_ITS_FREQUENCY_AT_RUNTIME
8e80955511 timer: hpet: allow overriding MIN_DELAY
99dc33faaf timer: hpet: extract Counter Clock Period into a macro
02fbe652a5 logging: fs: fix leak of opened directories in check_log_file_exist()
80b406d784 x86: acpi: limit search on where EBDA can be

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
...ephyr-kernel-src-2.6.0.inc => zephyr-kernel-src-2.6.1.inc} | 4 ++--
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
rename recipes-kernel/zephyr-kernel/{zephyr-kernel-src-2.6.0.inc => zephyr-kernel-src-2.6.1.inc} (90%)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
similarity index 90%
rename from recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
rename to recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
index 63665bf..109242e 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
@@ -1,5 +1,5 @@
SRCREV_FORMAT = "default_cmsis"
-SRCREV_default = "837ab4a915f7802a6fb02a27e4b024e287ac93c2"
+SRCREV_default = "2d6322d74aaac838ead46bfcba0db619cff4b534"
SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e"
SRCREV_nordic = "574493fe29c79140df4827ab5d4a23df79d03681"
SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
@@ -10,7 +10,7 @@ SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"

ZEPHYR_BRANCH = "v2.6-branch"
-PV = "2.6.0+git${SRCPV}"
+PV = "2.6.1+git${SRCPV}"

SRC_URI:append = " file://0001-cmake-add-yocto-toolchain.patch \
file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index abe755d..458ff1e 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -22,5 +22,5 @@ SRC_URI = "\
S = "${WORKDIR}/git"

# Default to a stable version
-PREFERRED_VERSION_zephyr-kernel ??= "2.6.0"
+PREFERRED_VERSION_zephyr-kernel ??= "2.6.1"
include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
--
2.17.1


Re: "stack smashing detected" when building aarch64 kernel

Khem Raj
 

its hard to say what might be going on. Perhaps enable builds with V=1
so you can see if its always failing to compile at same file.
or atleast you can get one file where it fails then you can use
preprocessed file to build it in a loop and see if you can get it to
fail more.

On Thu, Sep 23, 2021 at 8:16 AM Rasmus Villemoes via
lists.yoctoproject.org
<rasmus.villemoes=prevas.dk@...> wrote:


I've recently started getting an internal compiler error when building
an aarch64 kernel. It only happens once in a while, and re-running the
task usually just succeeds, so I don't know how to reproduce or trigger
this at will.

Two examples:

===
CC [M] drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm20b.o
CC [M] drivers/net/ethernet/mellanox/mlx5/core/rl.o
CC [M] drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp100.o
*** stack smashing detected ***: <unknown> terminated
In file included from .../kernel-source/arch/arm64/include/asm/atomic.h:15,
from .../kernel-source/include/linux/atomic.h:7,
from
.../kernel-source/include/asm-generic/bitops/atomic.h:5,
from .../kernel-source/arch/arm64/include/asm/bitops.h:26,
from .../kernel-source/include/linux/bitops.h:29,
from .../kernel-source/include/linux/kernel.h:12,
from .../kernel-source/include/linux/uio.h:8,
from .../kernel-source/include/linux/socket.h:8,
from .../kernel-source/include/uapi/linux/if.h:25,
from .../kernel-source/net/mac80211/led.c:7:
.../kernel-source/include/net/inet_sock.h: In function 'inet_sk_state_load':
.../kernel-source/arch/arm64/include/asm/barrier.h:114:8: internal
compiler error: Aborted
114 | union { __unqual_scalar_typeof(*p) __val; char __c[1]; } __u; \
| ^
.../kernel-source/include/asm-generic/barrier.h:142:29: note: in
expansion of macro '__smp_load_acquire'
142 | #define smp_load_acquire(p) __smp_load_acquire(p)
| ^~~~~~~~~~~~~~~~~~
.../kernel-source/include/net/inet_sock.h:312:9: note: in expansion of
macro 'smp_load_acquire'
312 | return smp_load_acquire(&sk->sk_state);
| ^~~~~~~~~~~~~~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
.../kernel-source/scripts/Makefile.build:279: recipe for target
'net/mac80211/led.o' failed
make[3]: *** [net/mac80211/led.o] Error 1
make[3]: *** Waiting for unfinished jobs....
CC [M] drivers/net/ethernet/mellanox/mlx5/core/lag.o
===
CC [M] drivers/gpu/drm/nouveau/nvkm/nvfw/ls.o
CC [M] drivers/gpu/drm/drm_modeset_helper.o
CC [M] drivers/gpu/drm/drm_scdc_helper.o
*** stack smashing detected ***: <unknown> terminated
In file included from
.../kernel-source/include/linux/regulator/consumer.h:35,
from
.../kernel-source/drivers/gpu/drm/nouveau/include/nvif/os.h:27,
from
.../kernel-source/drivers/gpu/drm/nouveau/include/nvkm/core/os.h:4,
from
.../kernel-source/drivers/gpu/drm/nouveau/include/nvkm/core/oclass.h:3,
from
.../kernel-source/drivers/gpu/drm/nouveau/include/nvkm/core/device.h:4,
from
.../kernel-source/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:4,
from
.../kernel-source/drivers/gpu/drm/nouveau/nvkm/nvfw/ls.c:22:
.../kernel-source/include/linux/suspend.h:364:36: internal compiler
error: Aborted
364 | extern void mark_free_pages(struct zone *zone);
| ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
.../kernel-source/scripts/Makefile.build:280: recipe for target
'drivers/gpu/drm/nouveau/nvkm/nvfw/ls.o' failed
make[5]: *** [drivers/gpu/drm/nouveau/nvkm/nvfw/ls.o] Error 1
make[5]: *** Waiting for unfinished jobs....
CC [M] drivers/gpu/drm/drm_gem_framebuffer_helper.o
===

This is with hardknott, aarch64-oe-linux-gcc (GCC) 10.2.0, building
5.10.* kernels (5.10.45 and 5.10.65 in the cases above IIRC). The build
is visiting drivers/gpu/drm/ in both cases, but in the former case it's
not actually a TU in there that fails, but one in net/, so I'm not even
sure it it has to do with something peculiar to the drivers/gpu/drm/
modules.

Has anyone seem something like this, or any ideas for figuring out
what's going on?

Rasmus



Re: gcov support for target in Yocto

Khem Raj
 

On Thu, Sep 23, 2021 at 9:53 AM Lijun Chen <lijchen@...> wrote:

Hi,


Anybody knows how to enable gcov support for the target in Yocto?
IMAGE_INSTALL += "gcov gcov-symlinks"


Thanks,

Lijun

________________________________
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.



Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device

Khem Raj
 

are you both using systemd or sysvinit

On Thu, Sep 23, 2021 at 3:26 PM Markus Volk <f_l_k@...> wrote:

I'm surprised mount doesn't complain about those first 5 lines! Those are not
properly-formed fstab(5) entries.

No, it doesn't. Those entries are ignored except /boot.
One interesting thing: i always had that bunch of malformed fstab entries.
Before the change from static to uuid it looked like this in fstab:

/dev/mmcblk1p1 loader1 vfat defaults 0 0
/dev/mmcblk1p2 reserved1 vfat defaults 0 0
/dev/mmcblk1p3 reserved2 vfat defaults 0 0
/dev/mmcblk1p4 loader2 vfat defaults 0 0
/dev/mmcblk1p5 atf vfat defaults 0 0
/dev/mmcblk1p6 /boot vfat defaults 0 0

Now it looks like wic fails in getting the correct value and uses sda as a best bet

you're proposing (a bunch of malformed fstab(5) entries) should be considered
correct.

I guess i just got used to it because it has always been like this since i build for the rock-pi

In the mean time I'd like to apply your patch 2/2, if you could please add
your SoB line?

Have sent new patches. Just delete the first one if you dont need it




Re: googletest shared library

Federico Pellegrin
 


Hi,
Regarding the INSANE_SKIP: as that files get packed in the "-dev" package, you should probably then accordingly have:

INSANE_SKIP_${PN}-dev += "dev-elf"

Cheers,
Federico


Il giorno gio 23 set 2021 alle ore 16:46 Lijun Chen <lijchen@...> ha scritto:

I tried INSANE_SKIP_${PN} += "dev-elf" and "dev-so", still got the QA error:

ERROR: googletest-1.10.0-r0 do_package_qa: QA Issue: -dev package googletest-dev contains non-symlink .so '/usr/lib/libgmock.so'
-dev package googletest-dev contains non-symlink .so '/usr/lib/libgtest_main.so'
-dev package googletest-dev contains non-symlink .so '/usr/lib/libgmock_main.so'
-dev package googletest-dev contains non-symlink .so '/usr/lib/libgtest.so' [dev-elf]
ERROR: googletest-1.10.0-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: Logfile of failure stored in: /home/lijchen/hdd/ivdp/yocto/imx8/imx-yocto-bsp-Hardknott/build-imx8qmmek/tmp/work/cortexa72-cortexa53-crypto-poky-linux/googletest/1.10.0-r0/temp/log.do_package_qa.24701
ERROR: Task (/home/lijchen/hdd/ivdp/yocto/imx8/imx-yocto-bsp-Hardknott/sources/meta-openembedded/meta-oe/recipes-test/googletest/googletest_git.bb:do_package_qa) failed with exit code '1'

I also tried adding " -DCMAKE_INSTALL_PREFIX=/usr/local" to EXTRA_OEMAKE, and got the following error:

ERROR: googletest-1.10.0-r0 do_package: QA Issue: googletest: Files/directories were installed but not shipped in any package:
  /usr/local/include
  /usr/local/lib/libgmock.so
  /usr/local/lib/libgtest_main.so
  /usr/local/lib/libgmock_main.so
  /usr/local/lib/libgtest.so
  /usr/local/lib/cmake
  /usr/local/lib/pkgconfig
  /usr/local/lib/cmake/GTest
  /usr/local/lib/cmake/GTest/GTestTargets.cmake
  /usr/local/lib/cmake/GTest/GTestConfigVersion.cmake
  /usr/local/lib/cmake/GTest/GTestConfig.cmake
  /usr/local/lib/cmake/GTest/GTestTargets-noconfig.cmake
  /usr/local/lib/pkgconfig/gtest_main.pc
  /usr/local/lib/pkgconfig/gtest.pc
  /usr/local/lib/pkgconfig/gmock_main.pc
  /usr/local/lib/pkgconfig/gmock.pc
  /usr/local/include/gtest
  /usr/local/include/gmock
  /usr/local/include/gtest/gtest_prod.h
  /usr/local/include/gtest/gtest-test-part.h
  /usr/local/include/gtest/gtest_pred_impl.h
  /usr/local/include/gtest/gtest-matchers.h
  /usr/local/include/gtest/gtest-printers.h
  /usr/local/include/gtest/gtest.h
  /usr/local/include/gtest/gtest-param-test.h
  /usr/local/include/gtest/gtest-death-test.h
  /usr/local/include/gtest/gtest-typed-test.h
  /usr/local/include/gtest/gtest-message.h
  /usr/local/include/gtest/gtest-spi.h
  /usr/local/include/gtest/internal
  /usr/local/include/gtest/internal/gtest-death-test-internal.h
  /usr/local/include/gtest/internal/gtest-filepath.h
  /usr/local/include/gtest/internal/gtest-param-util.h
  /usr/local/include/gtest/internal/gtest-string.h
  /usr/local/include/gtest/internal/gtest-type-util.h
  /usr/local/include/gtest/internal/gtest-internal.h
  /usr/local/include/gtest/internal/gtest-type-util.h.pump
  /usr/local/include/gtest/internal/gtest-port-arch.h
  /usr/local/include/gtest/internal/gtest-port.h
  /usr/local/include/gtest/internal/custom
  /usr/local/include/gtest/internal/custom/gtest-printers.h
  /usr/local/include/gtest/internal/custom/gtest.h
  /usr/local/include/gtest/internal/custom/README.md
  /usr/local/include/gtest/internal/custom/gtest-port.h
  /usr/local/include/gmock/gmock-function-mocker.h
  /usr/local/include/gmock/gmock-generated-function-mockers.h
  /usr/local/include/gmock/gmock-generated-actions.h.pump
  /usr/local/include/gmock/gmock-matchers.h
  /usr/local/include/gmock/gmock-generated-matchers.h
  /usr/local/include/gmock/gmock-more-matchers.h
  /usr/local/include/gmock/gmock.h
  /usr/local/include/gmock/gmock-generated-actions.h
  /usr/local/include/gmock/gmock-nice-strict.h
  /usr/local/include/gmock/gmock-spec-builders.h
  /usr/local/include/gmock/gmock-more-actions.h
  /usr/local/include/gmock/gmock-generated-function-mockers.h.pump
  /usr/local/include/gmock/gmock-cardinalities.h
  /usr/local/include/gmock/gmock-actions.h
  /usr/local/include/gmock/gmock-generated-matchers.h.pump
  /usr/local/include/gmock/internal
  /usr/local/include/gmock/internal/gmock-port.h
  /usr/local/include/gmock/internal/gmock-pp.h
  /usr/local/include/gmock/internal/gmock-internal-utils.h
  /usr/local/include/gmock/internal/custom
  /usr/local/include/gmock/internal/custom/gmock-port.h
  /usr/local/include/gmock/internal/custom/gmock-generated-actions.h.pump
  /usr/local/include/gmock/internal/custom/gmock-matchers.h
  /usr/local/include/gmock/internal/custom/gmock-generated-actions.h
  /usr/local/include/gmock/internal/custom/README.md
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
googletest: 69 installed and not shipped files. [installed-vs-shipped]
ERROR: googletest-1.10.0-r0 do_package: Fatal QA errors found, failing task.



From: Federico Pellegrin <fede@...>
Sent: Thursday, September 23, 2021 10:27:39 AM
To: Lijun Chen
Cc: yocto@...
Subject: Re: [yocto] googletest shared library
 

Hi,
To skip the QA you can use:

INSANE_SKIP_${PN} += "dev-elf"

(or any QA part you'd like to skip, ie. dev-elf or dev-so ...)

Cheers,
Federico



Il giorno gio 23 set 2021 alle ore 15:33 Lijun Chen <lijchen@...> ha scritto:

Hi,


If I switch to the default setting of the googletest recipe, the header files are included in the SDK image. However, the libgtest libraries are static.

Looks FILES_SOLIBSDEV = "" disables googletest-dev to be included in the SDK.


Is there a way to change the library to dynamic and keep the header files? i.e. just add EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON " but skip the do_package_qa part to avoid the QA issue due to un-versioned library?


Thanks,

Lijun




From: yocto@... <yocto@...> on behalf of Lijun Chen <lijchen@...>
Sent: Wednesday, September 22, 2021 1:45 PM
To: Khem Raj; yocto@...
Subject: Re: [yocto] googletest shared library
 

Tried adding googletest to TOOLCHAIN_TARGET_TASK. The gtest .h files are still not showing up.

Thanks,


From: Khem Raj <raj.khem@...>
Sent: Wednesday, September 22, 2021 11:28:05 AM
To: Lijun Chen; yocto@...
Subject: Re: [yocto] googletest shared library
 
The .h files will be in dev pkg in this case googletest-dev
what happens if you add googletest to TOOLCHAIN_TARGET_TASK

On 9/22/21 6:18 AM, Lijun Chen wrote:
> Hi,
>
>
> Now I included googletest to the IMAGE_INSTALL in my image file, and
> built both board image and SDK image. I can see libgtest.so is available
> in both images. However, gtest/gtest.h is a not present in SDK. How do I
> add the header files to the SDK image? Looks the following lines affect
> that?
>
> SOLIBS = ".so"
> FILES_SOLIBSDEV = ""
>
> Thanks,
> Lijun
>
> ------------------------------------------------------------------------
> *From:* yocto@... <yocto@...> on
> behalf of Lijun Chen <lijchen@...>
> *Sent:* Tuesday, September 21, 2021 3:50 PM
> *To:* Konrad Weihmann; yocto@...
> *Subject:* Re: [yocto] googletest shared library
>
> Thanks Konrad. That worked.
>
> ------------------------------------------------------------------------
> *From:* Konrad Weihmann <kweihmann@...>
> *Sent:* Tuesday, September 21, 2021 10:26:19 AM
> *To:* Lijun Chen; yocto@...
> *Subject:* Re: [yocto] googletest shared library
>
> On 21.09.21 16:18, Lijun Chen wrote:
>> Hi,
>>
>> I would like to include libgtest.so into my Yocto image. I added
>> googletest to IMAGE_INSTALL and added the following line to
>> sources/meta-openembedded/meta-oe/recipes-test/googletest/googletest_git.bb:
>>
>> EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON "
>>
>>
>> The shared libraries were built successfully. However, there are errors
>> in do_package_qc as following:
>>
>>
>> ERROR: googletest-1.10.0-r0 do_package_qa: QA Issue: -dev package
>> googletest-dev contains non-symlink .so '/usr/lib/libgmock.so'
>> -dev package googletest-dev contains non-symlink .so
>> '/usr/lib/libgtest_main.so'
>> -dev package googletest-dev contains non-symlink .so
>> '/usr/lib/libgmock_main.so'
>> -dev package googletest-dev contains non-symlink .so
>> '/usr/lib/libgtest.so' [dev-elf]
>> ERROR: googletest-1.10.0-r0 do_package_qa: QA run found fatal errors.
>> Please consider fixing them.
>
> https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb*n34__;Iw!!COg3wY07Hnb7!4NI6d6tXUoxCQFleF-343dfbdFGnkZnqrYRVg3nYTCBoGJTY9-K0NANM4iMsNNleww$
> <https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb*n34__;Iw!!COg3wY07Hnb7!4NI6d6tXUoxCQFleF-343dfbdFGnkZnqrYRVg3nYTCBoGJTY9-K0NANM4iMsNNleww$>
>
> (and the next lines) might give you a hint what to do in this case.
> Although one could also consider that's something that needs to be fixed
> in the installation script of googletest, as versioned libraries are the
> expected default
>
>>
>>
>> Any idea to fix this?
>>
>>
>> Thanks,
>>
>> Lijun
>>
>>
>> ------------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute
>> non-public information. Any use of this information by anyone other than
>> the intended recipient is prohibited. If you have received this
>> transmission in error, please immediately reply to the sender and delete
>> this information from your system. Use, dissemination, distribution, or
>> reproduction of this transmission by unintended recipients is not
>> authorized and may be unlawful.
>>
>>
>>
>>
> ------------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> ------------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
>
>
>
>

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.




This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.


Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device

Markus Volk
 

I'm surprised mount doesn't complain about those first 5 lines! Those are not
properly-formed fstab(5) entries.
No, it doesn't. Those entries are ignored except /boot.
One interesting thing: i always had that bunch of malformed fstab entries.
Before the change from static to uuid it looked like this in fstab:

/dev/mmcblk1p1	loader1	vfat	defaults	0	0
/dev/mmcblk1p2	reserved1	vfat	defaults	0	0
/dev/mmcblk1p3	reserved2	vfat	defaults	0	0
/dev/mmcblk1p4	loader2	vfat	defaults	0	0
/dev/mmcblk1p5	atf	vfat	defaults	0	0
/dev/mmcblk1p6	/boot	vfat	defaults	0	0

Now it looks like wic fails in getting the correct value and uses sda as a best bet
you're proposing (a bunch of malformed fstab(5) entries) should be considered
correct.
I guess i just got used to it because it has always been like this since i build for the rock-pi

In the mean time I'd like to apply your patch 2/2, if you could please add
your SoB line?
Have sent new patches. Just delete the first one if you dont need it


[meta-rockchip][PATCH v2 2/2] rockchip-wic.inc: dont let wic edit fstab by default

Markus Volk
 

Signed-off-by: MarkusVolk <f_l_k@...>
---
conf/machine/include/rockchip-wic.inc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/conf/machine/include/rockchip-wic.inc b/conf/machine/include=
/rockchip-wic.inc
index 15010a0..30b0d57 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -26,3 +26,6 @@ WICVARS:append =3D " \
SPL_BINARY \
UBOOT_SUFFIX \
"
+
+# Do not update fstab file while creating wic images
+WIC_CREATE_EXTRA_ARGS ?=3D "--no-fstab-update"
--=20
2.25.1


[meta-rockchip][PATCH v2 1/2] rockchip.wks: use uuid for all partitions

Markus Volk
 

My rock pi 4 refused to boot with the latest changes because there are fa=
lse entries
written to fstab. Fix this by using uuid for all partitions

Signed-off-by: MarkusVolk <f_l_k@...>
---
wic/rockchip.wks | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index 5ee276b..90bdb27 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -15,12 +15,12 @@
# boot 32768 229376
# root 262144 - (suggested)
=20
-part loader1 --offset 32 --fixed-size 4000K --source r=
awcopy --sourceparams=3D"=
file=3D${SPL_BINARY}"
-part reserved1 --offset 4032 --fixed-size 64K
-part reserved2 --offset 4096 --fixed-size 4096K
-part loader2 --offset 8192 --fixed-size 4096K --source r=
awcopy --sourceparams=3D"=
file=3Du-boot.${UBOOT_SUFFIX}"
-part atf --offset 12288 --fixed-size 4096K
-part /boot --offset 16384 --size 114688K --active --source b=
ootimg-partition --fstype=3Dvfat --label boot --sourceparams=3D=
"loader=3Du-boot"
-part / --source r=
ootfs --fstype=3Dext4 --label root --use-uuid
+part loader1 --offset 32 --fixed-size 4000K --source rawcopy --sourcepar=
ams=3D"file=3D${SPL_BINARY}" --use-uuid
+part reserved1 --offset 4032 --fixed-size 64K --use-uuid
+part reserved2 --offset 4096 --fixed-size 4096K --use-uuid
+part loader2 --offset 8192 --fixed-size 4096K --source rawcopy --sourcep=
arams=3D"file=3Du-boot.${UBOOT_SUFFIX}" --use-uuid
+part atf --offset 12288 --fixed-size 4096K --use-uuid
+part /boot --offset 16384 --size 114688K --active --source bootimg-parti=
tion --fstype=3Dvfat --label boot --sourceparams=3D"loader=3Du-boot" --us=
e-uuid
+part / --source rootfs --fstype=3Dext4 --label root --use-uuid
=20
-bootloader --ptable gpt --append=3D"console=3Dtty1 console=3D${RK_CONSOL=
E_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=3Dext4 init=3D/sbin/init"
+bootloader --ptable gpt --append=3D"console=3Dtty1 console=3D${RK_CONSOL=
E_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=3Dext4 init=3D/sbin/init"
--=20
2.25.1


Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device

Trevor Woerner
 

On Thu 2021-09-23 @ 09:45:06 PM, Markus Volk wrote:

Am 23.09.21 um 13:59 schrieb Trevor Woerner:
Curious. I boot tested my patch on multiple boards and I've built and booted
numerous images on my rock-pi-4b and rock64 boards in the last day or so since
I applied the patch. I'll try some "clean" builds and see if that makes a
difference. I don't doubt your report (especially since Khem confirmed it),
I'd just like to know for myself what's different.
That is really strange. As soon as there are those /dev/sda* entries in my fstab
my rock-pi-4c doesn't boot up anymore. As soon as i comment them out or delete them,
everything is working again.
Thanks for testing. It's also strange that my fstab also has those entries,
but they're apparently ignored in my setup since, commented in or commented
out, they don't seem to affect my board's ability to boot.

I wonder if just applying your 2nd patch would be enough (i.e. the one that
removes the /dev/sda* lines from /etc/fstab)? It's odd that the first 6
entries in the wic file would need UUIDs since it's the SoC's ROM firmware
that uses them, and I'm pretty sure the Rockchip firmware isn't using UUIDs
(my guess is it's just blindly grabbing whatever it finds at specific
offsets). The things stored in those partitions are u-boot related bits (atf,
spl, the u-boot binary itself) so by the time Linux starts, those things are
already "behind" us. I can't see how adding UUIDs to the partitions holding
u-boot would affect how the kernel finds the root partition (?).
Applying only the second patch should be enough to hide the problem, but as soon as
one decides to disable WIC_CREATE_EXTRA_ARGS for example because he/she wants /boot to be
mounted automatically, those non working /dev/sda* entries will be written into fstab again.
With the first patch they are included like this and are mountable via fstab:


UUID=0C48-9342 loader1 vfat defaults 0 0
UUID=C4D3-D17A reserved1 vfat defaults 0 0
UUID=8FBE-2551 reserved2 vfat defaults 0 0
UUID=35FA-8BBB loader2 vfat defaults 0 0
UUID=CFF3-5D80 atf vfat defaults 0 0
UUID=832C-48C4 /boot vfat defaults 0 0
I'm surprised mount doesn't complain about those first 5 lines! Those are not
properly-formed fstab(5) entries.

I wouldn't call only applying your second patch a form of "hiding the
problem". Neither what we had before (a bunch of /dev/sda entries) and what
you're proposing (a bunch of malformed fstab(5) entries) should be considered
correct. If a user messes with BSP-level variables, then they should expect
what they get (?).

We can add the --use-uuid line to the /boot entry if you really think it
should be mounted on boot, but we shouldn't use it on the others and cause wic
to generate a bad fstab. There are examples of other boards that don't mount
/boot by default (raspi for sure, and I think bbb too).

I'll try to look deeper to figure out what's generating those /dev/sda
entries. Maybe there's a way to disable them without resorting to
WIC_CREATE_EXTRA_ARGS?

In the mean time I'd like to apply your patch 2/2, if you could please add
your SoB line?

u-boot is able to find its partitons even if '--use-uuid' is set. As you mentioned u-boot doesn't
know about uuid but it seems to be able to find its partitions nevertheless. But if '--use-uuid'
is not set, wic writes /dev/sda* instead of the correct UUID values to fstab. So its not u-boot that
needs uuid to be set but fstab.
Of course it would be nice, if wic didn't try to add the u-boot partitions to fstab at all.
I guess nobody ever needs to have them mounted into userspace ( except possibly /boot).
Sorry, I wasn't clear. u-boot doesn't use those labels to find u-boot, my
guess is that the SoC's ROM firmware blindly looks at fixed offsets for the
"what to boot" (and therefore isn't using UUIDs either). Either the ROM loads
the atf, which then loads u-boot's spl, or the ROM loads the atf and then
loads u-boot's spl from fixed locations. Perhaps u-boot's spl uses labels to
find u-boot proper, but that's irrelevant.

Are you using poky or a distro other than "nodistro"? Perhaps other
layers/distros are affecting the build?
Thats not unlikely. I have a long layer-list in bblayers.conf to build my image:

/home/flk/build/poky/meta \
/home/flk/build/poky/meta-poky \
/home/flk/build/poky/meta-yocto-bsp \
/home/flk/build/poky/meta-rockchip \
/home/flk/build/poky/meta-rockchip-extras \
/home/flk/build/poky/meta-wayland \
/home/flk/build/poky/meta-retro \
/home/flk/build/poky/meta-retro-wayland \
/home/flk/build/poky/meta-rauc \
/home/flk/build/poky/meta-openembedded/meta-oe \
/home/flk/build/poky/meta-openembedded/meta-multimedia \
/home/flk/build/poky/meta-openembedded/meta-networking \
/home/flk/build/poky/meta-openembedded/meta-xfce \
/home/flk/build/poky/meta-openembedded/meta-gnome \
/home/flk/build/poky/meta-openembedded/meta-python \
/home/flk/build/poky/meta-openembedded/meta-filesystems \
/home/flk/build/poky/meta-arm/meta-arm \
/home/flk/build/poky/meta-arm/meta-arm-toolchain \
/home/flk/build/poky/meta-kodi \
/home/flk/build/poky/meta-browser/meta-chromium \
/home/flk/build/poky/meta-browser/meta-firefox \
/home/flk/build/poky/meta-clang \
My guess is that Khem probably likes building with a long list of layers as
well ;-) I'll try using poky to see if that changes anything. Using oecore,
bitbake, meta-arm, and meta-rockchip I can't reproduce what you and Khem are
seeing. One of these days I'll have to check to make sure meta-rockchip is
behaving like it should when mixed with other layers.

2581 - 2600 of 57387