Date   

Re: Single page view of a particular manual

Vasyl Vavrychuk <vvavrychuk@...>
 

Hi, Nicolas,

Now, it looks like something changed.

Opening https://docs.yoctoproject.org/bitbake/, then choosing
"All-in-one 'Mega' Manual" leads to what I need: single page BitBake
User Manual - https://docs.yoctoproject.org/bitbake/singleindex.html

But there are few more issues.

1. Open https://docs.yoctoproject.org/bitbake/index.html. Select on
the top has entries "Individual Webpages" and "All-in-one 'Mega'
Manual". The problem is that entry "All-in-one 'Mega' Manual" now does
not reflects to the current behavior. Suggest to replace "All-in-one
'Mega' Manual" with "Single Webpage".

2. Open https://docs.yoctoproject.org/bitbake/. Version select at the
top with options "3.2.1", "3.1.4", etc. are not working.

Thanks,
Vasyl

On Mon, Nov 16, 2020 at 6:27 PM Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:

hi Vasyl,

On Mon, Nov 16, 2020 at 12:55 PM Vasyl Vavrychuk <vvavrychuk@gmail.com> wrote:

Hi, Nicolas,

Thank you for your reply.

On Sun, Nov 15, 2020 at 8:06 PM Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:

Can you please describe what you are doing in the webpage? It should
You need to select "All in one Mega manual" in the
dropdown menu on the top left corner of the page. When you do that, it
should bring you to this URL:
https://docs.yoctoproject.org/singleindex.html

Which contains the whole YP docs in a 'single' html page.
But as far as I remember, previously I could have a single page view
of a particular manual, for example "Development Tasks Manual", etc.
It is much more useful than complete single page view of all documents
at the same time (but this one is useful too in some cases).
Ah, you're right. It was possible with the previous docs, but not
anymore. With the Sphinx based docs the whole Yocto Project docs is
just "one set", not a collection of 'manuals'. So currently the single
html page includes the entire documentation set.

There is no 'easy' way to change that though. I am definitely
interested to gather more feedback about that. We made a conscious
choice to get this way, It's different, and if it's causing more pain,
we should know and discuss..

I heard complaints before that we had too 'many' manuals, and it was
hard to know which one to open, which is the opposite of what you are
asking ;)

let's see if we can gather more feedback.


nativesdk-binutils sysroot bug?

Kenth Eriksson
 

I have added native gcc support to an ARM Yocto SDK. But the native compiler does not work when passing the sysroot argument to the compiler.

kenth@se-kenth-lx yocto-xr $ x86_64-xr-linux-gcc test.c
kenth@se-kenth-lx yocto-xr $ x86_64-xr-linux-gcc test.c --sysroot=/opt/infn-xr/1.0/sysroots/x86_64-xr-linux
/opt/infn-xr/1.0/sysroots/x86_64-xr-linux/usr/lib/gcc/x86_64-xr-linux/9.2.0/../../../../x86_64-xr-linux/bin/ld: cannot find /opt/infn-xr/1.0/sysroots/x86_64-xr-linux/lib/libc.so.6 inside /opt/infn-xr/1.0/sysroots/x86_64-xr-linux
/opt/infn-xr/1.0/sysroots/x86_64-xr-linux/usr/lib/gcc/x86_64-xr-linux/9.2.0/../../../../x86_64-xr-linux/bin/ld: cannot find /opt/infn-xr/1.0/sysroots/x86_64-xr-linux/usr/lib/libc_nonshared.a inside /opt/infn-xr/1.0/sysroots/x86_64-xr-linux
/opt/infn-xr/1.0/sysroots/x86_64-xr-linux/usr/lib/gcc/x86_64-xr-linux/9.2.0/../../../../x86_64-xr-linux/bin/ld: cannot find /opt/infn-xr/1.0/sysroots/x86_64-xr-linux/lib/ld-linux-x86-64.so.2 inside /opt/infn-xr/1.0/sysroots/x86_64-xr-linux
collect2: error: ld returned 1 exit status

Error trace seems to incorrectly tell that libc is missing on that path

kenth@se-kenth-lx yocto-xr $ ls -l /opt/infn-xr/1.0/sysroots/x86_64-xr-linux/lib/libc.so.6
lrwxrwxrwx 1 root root 12 Jan 11 10:33 /opt/infn-xr/1.0/sysroots/x86_64-xr-linux/lib/libc.so.6 -> libc-2.30.so*
kenth@se-kenth-lx yocto-xr $

The sysroot argument works when only compiling the source file (no linking)
kenth@se-kenth-lx yocto-xr $ x86_64-xr-linux-gcc -c test.c -o test.o --sysroot=/opt/infn-xr/1.0/sysroots/x86_64-xr-linux

But when gcc invokes binutils with sysroot argument then it fails. Doing a strace on the invocation of gcc with sysroot shows that sometimes the sysroot path is concatenated twice;

[pid 4197] openat(AT_FDCWD, "/opt/infn-xr/1.0/sysroots/x86_64-xr-linux//opt/infn-xr/1.0/sysroots/x86_64-xr-linux/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 4197] write(2, "/opt/infn-xr/1.0/sysroots/x86_64"..., 110) = 110

The arm compiler has a compiled sysroot (as defined in the bb recipe)
kenth@se-kenth-lx yocto-xr $ aarch64-xr-linux-gcc --print-sysroot
/not/exist
kenth@se-kenth-lx yocto-xr $

whereas the native x86 compiler does not have a compiled sysroot

kenth@se-kenth-lx yocto-xr $ x86_64-xr-linux-gcc --print-sysroot
kenth@se-kenth-lx yocto-xr $

If I symlink the path to mitigate the concatenation effect into binutils then it all works.

Known issue? How to resolve?


Re: insmod - huawei E3372h kernel module

Zoltan Kerenyi Nagy
 

Hi, Im doing this:

KERNEL_MODULE_AUTOLOAD += "ncm_driver"KERNEL_MODULE_PROBECONF += "ncm_driver"cdc_ncm = "options ncm_driver iProduct=USB_Host_Driver_for_Network_Control_Model iManufacturer=NCM"
KERNEL_MODULE_AUTOLOAD += "wmc_device_managment"KERNEL_MODULE_PROBECONF += "wmc_device"cdc_wdm = "options wmc_device iProduct=USB_CDC_WCM_Device_Management iManufacturer=WMC"
KERNEL_MODULE_AUTOLOAD += "lte"KERNEL_MODULE_PROBECONF += "lte"huawei_cdc_ncm = "options lte iProduct=E3372h iManufacturer=Huawei"

Im very curious. I think the cdc_ncm and cdc_wdm should be inserted before huawei_cdc_ncm
 
--
Zolee


Re: How to select Linux kernel version?

Quentin Schulz
 

Hi Jupiter,

On Sat, Jan 09, 2021 at 09:56:13AM +1100, Jupiter wrote:
Hi Quentin,

Thanks for your helps, I finally figured out an old Yocto version thud
is able to pick up the latest the kernel version to run 5.10 where the
Zeus could not, there are a couple of bugs in Zeus which I could not
run Zeus in Ubuntu 20.4, it is time for me to upgrade to the latest
Yocto version which hopefully fixes the kernel version issue.
This should have nothing to do with a Yocto version, if your recipe is
not found, it's just not found and it is usually a tell that you either
put your recipe in the wrong tree layout or that you forgot to add the
layers to your bblayers.conf.

If both were done correctly and you still have the issue, it is an
important bug to report and investigate, so please share with us the
output of bblayers.conf and the path to your linux-yocto_5.10 recipe.

You could also add:
python __anonymous() {
bb.warning("The recipe is being parsed as expected")
}

If when you run bitbake virtual/kernel you don't see a warning, your
recipe is for sure not parsed and obviously cannot be used by Yocto.

Cheers,
Quentin


Re: Unable to extract tar file #dunfell #yocto

Vijay Rakesh Munganda
 

Hi Quentin,

Thank you for the earlier help. After that, I got a QA Issue and I was trying to solve it, but I'm unable to do it. Any suggestions would be helpful. 

Package contains non-symlink .so: tokbox-dev path '/work/aarch64-poky-linux/tokbox/1.0-r0/packages-split/tokbox-dev/usr/lib/libopentok.so' [dev-elf]
ERROR: tokbox-1.0-r0 do_package_qa: QA Issue: /usr/lib/libopentok.so contained in package tokbox-dev requires libc++.so.1()(64bit), but no providers found in RDEPENDS_tokbox-dev? [file-rdeps]

Thanks & Regards,
Vijay Rakesh.
 


Python3-native illegal instruction on poky dunfell

Daniela-Marinela Bistrean
 

Hello community,

I am trying to build core-image-minimal using poky only, on the dunfell branch. On certain machines the build fails unexpectedly with the following error:
Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "x86_64-poky-linux"
MACHINE              = "qemux86-64"
DISTRO               = "poky"
DISTRO_VERSION       = "3.1.4"
TUNE_FEATURES        = "m64 core2"
TARGET_FPU           = ""
meta                
meta-poky            
meta-yocto-bsp       = "dunfell:cd3abf42dae2310ecaa8a97b2c08378a9f6e1282"

Initialising tasks: 100% |####################################################################################################################################################################| Time: 0:00:11
Sstate summary: Wanted 1025 Found 0 Missed 1025 Current 126 (0% match, 10% complete)
NOTE: Executing Tasks
ERROR: python3-setuptools-native-45.2.0-r0 do_compile: 'python3 setup.py build ' execution failed.
ERROR: python3-setuptools-native-45.2.0-r0 do_compile: Execution of '/home/builder/src/build_yocto-test/tmp/work/x86_64-linux/python3-setuptools-native/45.2.0-r0/temp/run.do_compile.141' failed with exit code 1:
Illegal instruction (core dumped)
WARNING: exit code 1 from a shell command.

ERROR: Logfile of failure stored in: /home/builder/src/build_yocto-test/tmp/work/x86_64-linux/python3-setuptools-native/45.2.0-r0/temp/log.do_compile.141
Log data follows:
| DEBUG: Executing shell function do_compile
| Illegal instruction (core dumped)
| ERROR: 'python3 setup.py build ' execution failed.
| WARNING: exit code 1 from a shell command.
| ERROR: Execution of '/home/builder/src/build_yocto-test/tmp/work/x86_64-linux/python3-setuptools-native/45.2.0-r0/temp/run.do_compile.141' failed with exit code 1:
| Illegal instruction (core dumped)
| WARNING: exit code 1 from a shell command.
|
ERROR: Task (virtual:native:/home/builder/src/poky/meta/recipes-devtools/python/python3-setuptools_45.2.0.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 576 tasks of which 572 didn't need to be rerun and 1 failed.

The do_compile task executes the following:
do_compile() {
    distutils3_do_compile
}

distutils3_do_compile() {
        cd /home/builder/src/build_sw.sys.icp21/tmp/work/x86_64-linux/python3-setuptools-native/45.2.0-r0/setuptools-45.2.0
        NO_FETCH_BUILD=1 \
        STAGING_INCDIR=/home/builder/src/build_sw.sys.icp21/tmp/work/x86_64-linux/python3-setuptools-native/45.2.0-r0/recipe-sysroot-native/usr/include \
        STAGING_LIBDIR=/home/builder/src/build_sw.sys.icp21/tmp/work/x86_64-linux/python3-setuptools-native/45.2.0-r0/recipe-sysroot-native/usr/lib \
        /home/builder/src/build_sw.sys.icp21/tmp/work/x86_64-linux/python3-setuptools-native/45.2.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3 /home/builder/src/build_sw.sys.icp21/tmp/work/x86_64-linux/python3-setuptools-native/45.2.0-r0/setuptools-45.2.0/setup.py \
        build --build-base=/home/builder/src/build_sw.sys.icp21/tmp/work/x86_64-linux/python3-setuptools-native/45.2.0-r0/build  || \
        bbfatal_log "'python3 setup.py build ' execution failed."
}

On this particular machine the build fails even when it is tried out from within a container. The configuration of this machine is:
Distributor ID: Ubuntu
Description: Ubuntu 18.04.5 LTS
Release: 18.04
Codename: bionic

Linux vm 5.4.0-54-generic #60~18.04.1-Ubuntu SMP Fri Nov 6 17:25:16 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

4 x Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz

The python3-native binary generated by Yocto works and I can run it on the host. I have identified that setup.py file of python3-setuptools-native recipe, part of do_compile fails with illegal instruction when trying to import setuptools. On other machines the build has no issues. The machine with issues is under a VPN and a proxy (company's machine).

Do you have any hint as why this might happen?

Thank you and looking forward to your feedback,
Daniela-Mărinela Bistrean


[meta-security-compliance][PATCH] scap-security-guide: Fix openembedded platform tests and build

Jate Sujjavanich
 

Add patches to fix openembedded nodistro tests and openembedded build wit=
hin
ssg metadata.

Signed-Off-By: Jate Sujjavanich <jatedev@gmail.com>
---
...c-file-check-tests-in-installed-OS-d.patch | 46 +++++++++++++++++++
...g-openembedded-from-ssg-constants.py.patch | 34 ++++++++++++++
.../scap-security-guide_git.bb | 2 +
3 files changed, 82 insertions(+)
create mode 100644 meta-security-compliance/recipes-openscap/scap-securi=
ty-guide/files/0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.=
patch
create mode 100644 meta-security-compliance/recipes-openscap/scap-securi=
ty-guide/files/0002-Fix-missing-openembedded-from-ssg-constants.py.patch

diff --git a/meta-security-compliance/recipes-openscap/scap-security-guid=
e/files/0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch b=
/meta-security-compliance/recipes-openscap/scap-security-guide/files/0001=
-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch
new file mode 100644
index 0000000..60664a3
--- /dev/null
+++ b/meta-security-compliance/recipes-openscap/scap-security-guide/files=
/0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch
@@ -0,0 +1,46 @@
+From 2beb4bc83a157b21edb1a3fef295cd4cced467df Mon Sep 17 00:00:00 2001
+From: Jate Sujjavanich <jatedev@gmail.com>
+Date: Thu, 7 Jan 2021 18:10:01 -0500
+Subject: [PATCH 1/3] Fix platform spec, file check, tests in installed O=
S
+ detect for openembedded
+
+Change platform to multi in openembedded installed check matching others
+and allowing compile of xml into oval
+---
+ shared/checks/oval/installed_OS_is_openembedded.xml | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/shared/checks/oval/installed_OS_is_openembedded.xml b/share=
d/checks/oval/installed_OS_is_openembedded.xml
+index 763d17bcb..01df16b43 100644
+--- a/shared/checks/oval/installed_OS_is_openembedded.xml
++++ b/shared/checks/oval/installed_OS_is_openembedded.xml
+@@ -1,11 +1,9 @@
+-</def-group>
+-
+ <def-group>
+ <definition class=3D"inventory" id=3D"installed_OS_is_openembedded" v=
ersion=3D"2">
+ <metadata>
+ <title>OpenEmbedded</title>
+ <affected family=3D"unix">
+- <platform>OPENEMBEDDED</platform>
++ <platform>multi_platform_all</platform>
+ </affected>
+ <reference ref_id=3D"cpe:/o:openembedded:openembedded:0"
+ source=3D"CPE" />
+@@ -20,8 +18,11 @@
+ </criteria>
+ </definition>
+=20
+- <ind:textfilecontent54_object id=3D"test_openembedded" version=3D"1" =
comment=3D"Check OPenEmbedded version">
+- <ind:filepath>/etc/os-release/ind:filepath>
++ <ind:textfilecontent54_test check=3D"all" check_existence=3D"at_least=
_one_exists" comment=3D"Check OpenEmbedded version" id=3D"test_openembedd=
ed" version=3D"1">
++ <ind:object object_ref=3D"obj_openembedded" />
++ </ind:textfilecontent54_test>
++ <ind:textfilecontent54_object id=3D"obj_openembedded" version=3D"1" c=
omment=3D"Check OpenEmbedded version">
++ <ind:filepath>/etc/os-release</ind:filepath>
+ <ind:pattern operation=3D"pattern match">^VERSION_ID=3D\"nodistro\.=
[0-9].$</ind:pattern>
+ <ind:instance datatype=3D"int">1</ind:instance>
+ </ind:textfilecontent54_object>
+--=20
+2.24.3 (Apple Git-128)
+
diff --git a/meta-security-compliance/recipes-openscap/scap-security-guid=
e/files/0002-Fix-missing-openembedded-from-ssg-constants.py.patch b/meta-=
security-compliance/recipes-openscap/scap-security-guide/files/0002-Fix-m=
issing-openembedded-from-ssg-constants.py.patch
new file mode 100644
index 0000000..1e712f6
--- /dev/null
+++ b/meta-security-compliance/recipes-openscap/scap-security-guide/files=
/0002-Fix-missing-openembedded-from-ssg-constants.py.patch
@@ -0,0 +1,34 @@
+From 037a12301968a56f0c7e492ea4a05d2eecbd4cc6 Mon Sep 17 00:00:00 2001
+From: Jate Sujjavanich <jatedev@gmail.com>
+Date: Fri, 8 Jan 2021 20:18:00 -0500
+Subject: [PATCH 2/3] Fix missing openembedded from ssg/constants.py
+
+---
+ ssg/constants.py | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/ssg/constants.py b/ssg/constants.py
+index fab7cda5d..2ca289f84 100644
+--- a/ssg/constants.py
++++ b/ssg/constants.py
+@@ -234,7 +234,8 @@ PRODUCT_TO_CPE_MAPPING =3D {
+ }
+=20
+ MULTI_PLATFORM_LIST =3D ["rhel", "fedora", "rhosp", "rhv", "debian", "u=
buntu",
+- "wrlinux", "opensuse", "sle", "ol", "ocp", "exam=
ple"]
++ "wrlinux", "opensuse", "sle", "ol", "ocp", "exam=
ple",
++ "openembedded"]
+=20
+ MULTI_PLATFORM_MAPPING =3D {
+ "multi_platform_debian": ["debian8"],
+@@ -249,6 +250,7 @@ MULTI_PLATFORM_MAPPING =3D {
+ "multi_platform_sle": ["sle11", "sle12"],
+ "multi_platform_ubuntu": ["ubuntu1404", "ubuntu1604", "ubuntu1804"]=
,
+ "multi_platform_wrlinux": ["wrlinux"],
++ "multi_platform_openembedded": ["openembedded"],
+ }
+=20
+ RHEL_CENTOS_CPE_MAPPING =3D {
+--=20
+2.24.3 (Apple Git-128)
+
diff --git a/meta-security-compliance/recipes-openscap/scap-security-guid=
e/scap-security-guide_git.bb b/meta-security-compliance/recipes-openscap/=
scap-security-guide/scap-security-guide_git.bb
index 6e7180f..0617c56 100644
--- a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-=
security-guide_git.bb
+++ b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-=
security-guide_git.bb
@@ -7,6 +7,8 @@ SRC_URI =3D "git://github.com/akuster/scap-security-guide=
.git;branch=3Doe-0.1.44; \
file://0001-fix-deprecated-instance-of-element.getchildren.pa=
tch \
file://0002-fix-deprecated-getiterator-function.patch \
file://0003-fix-remaining-getchildren-and-getiterator-functio=
ns.patch \
+ file://0001-Fix-platform-spec-file-check-tests-in-installed-O=
S-d.patch \
+ file://0002-Fix-missing-openembedded-from-ssg-constants.py.pa=
tch \
"
PV =3D "0.1.44+git${SRCPV}"
=20
--=20
2.25.1


Re: rebuild issues using sstate mirror

Markus Volk
 

I sent patches to openembedded-core@...


Re: How to select Linux kernel version?

JH
 

Hi Quentin,

Thanks for your helps, I finally figured out an old Yocto version thud
is able to pick up the latest the kernel version to run 5.10 where the
Zeus could not, there are a couple of bugs in Zeus which I could not
run Zeus in Ubuntu 20.4, it is time for me to upgrade to the latest
Yocto version which hopefully fixes the kernel version issue.

Thank you.

Kind regards,

jupiter


Re: Suggestions on improvements

Robert Berger
 

Hi,

On 08/01/2021 04:59, Meh Mbeh Ida Delphine wrote:

Due to some mismatches, warnings pop up during the build. Below are some
few sample warnings and I'm aware of false positives;
Why do you think they are false positives?


WARNING: glibc-2.32-r0 do_package: License for package nscd is {'GPL-2.0
WITH Linux-syscall-note'} vs GPLv2 & LGPLv2.1
Check this file:

FileName: ./spdx_temp/git/.pc/0026-inject-file-assembly-directives.patch/sysdeps/aarch64/crti.S
FileChecksum: SHA1: 83c9d68d2f83ca0af8af2a918533f21004aac238
LicenseConcluded: NOASSERTION
LicenseInfoInFile: LGPL-2.1-or-later
LicenseInfoInFile: LicenseRef-scancode-unlimited-linking-exception-lgpl
FileCopyrightText: <text>Copyright (c) 1995-2020 Free Software Foundation, Inc.
</text>


I play around with meta-spdxscanner and if you run e.g. scancode-toolkit it tells you:

FileName: ./spdx_temp/git/nscd/cache.c
FileChecksum: SHA1: ecec99d5427b03fe5c390f5fd78274a2a7c625e7
LicenseConcluded: NOASSERTION
LicenseInfoInFile: GPL-3.0-or-later
FileCopyrightText: <text>Copyright (c) 1998-2020 Free Software Foundation, Inc.
</text>

;)

Which comes from:

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published
by the Free Software Foundation; version 2 of the License, or
(at your option) any later version.

So once someone determines what's the real license, I guess packages could be licensed accordingly ;)

LICENSE_glibc-xxx = "GPLv3+"

is it? Bring in the lawyers.

WARNING: glibc-2.32-r0 do_package: License for package sln is {'GPL-2.0
WITH Linux-syscall-note'} vs GPLv2 & LGPLv2.1
WARNING: glibc-2.32-r0 do_package: License for package ldconfig is
{'GPL-2.0 WITH Linux-syscall-note'} vs GPLv2 & LGPLv2.1
WARNING: glibc-2.32-r0 do_package: License for package glibc is
{'GPL-2.0 WITH Linux-syscall-note'} vs GPLv2 & LGPLv2.1
WARNING: glibc-2.32-r0 do_package: License for package glibc-staticdev
is {'GPL-2.0 WITH Linux-syscall-note'} vs GPLv2 & LGPLv2.1
WARNING: libcap-ng-0.8-r0 do_package: License for package libcap-ng is
{'GPL-2.0 WITH Linux-syscall-note'} vs GPLv2+ & LGPLv2.1+> WARNING:
libtirpc-1.2.6-r0 do_package: License for package libtirpc is
{'GPL-2.0 WITH Linux-syscall-note'} vs BSD-3-Clause
WARNING: ptest-runner-2.4.0+gitAUTOINC+834670317b-r0 do_package: License
for package ptest-runner is {'GPL-2.0-or-later'} vs GPLv2+
I assume GPLv2+ is supposed to mean GPL-2.0-or-later.
One fix would be to put in the LICENSE field of ptest-runnner GPL-2.0-or-later instead of GPLv2+. Another fix could be to add the mapping between GPLv2+ and GPL-2.0-or-later.

WARNING: libcap-2.44-r0 do_package: License for package libcap is
{'GPL-2.0 WITH Linux-syscall-note'} vs BSD | GPLv2> WARNING:
libcap-2.44-r0 do_package: License for package libcap-staticdev
is {'GPL-2.0 WITH Linux-syscall-note'} vs BSD | GPLv2
WARNING: openssl-1.1.1h-r0 do_package: License for package
openssl-engines is {'GPL-2.0 WITH Linux-syscall-note', 'GPL-2.0+ WITH
Linux-syscall-note'} vs openssl
Any suggestions on improvements I can make to this functionality?
Cheers,
Ida.
Regards,

Robert


Re: rebuild issues using sstate mirror

Randy MacLeod
 

On 2021-01-08 6:16 a.m., Markus Volk wrote:
Hi Folks,
i did some research on building a custom yocto image using gatesgarth branch. The testcase was building an image on one machine and rebuild it on another using sstate mirror.
I encountered two issues witch i was able to fix in a way that may also be interesting upstream.
 
The first error:
| /home/flk/yocto/build/poky-3.2/hd51/tmp/work/cortexa15hf-neon-vfpv4-oe-linux-gnueabi/gobject-introspection/1.64.1-r0/recipe-sysroot-native/usr/bin/bison: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory
 
the solution for me was to add 'readline'  to DEPENDS in bison_3.7.2.bb .
 
configure log for bison-native changed from:
 checking for readline... no
checking readline/readline.h usability... no
checking readline/readline.h presence... no
checking for readline/readline.h... no
checking readline/history.h usability... no
checking readline/history.h presence... no
checking for readline/history.h... no
 
to:
checking for readline... yes
checking how to link with libreadline... /home/flk/yocto/build/poky-3.2/hd51/tmp/work/x86_64-linux/bison-native/3.7.2-r0/recipe-sysroot-native/usr/lib/libreadline.so -Wl,-rpath -Wl,/home/flk/yocto/build/poky-3.2/hd51/tmp/work/x86_64-linux/bison-native/3.7.2-r0/recipe-sysroot-native/usr/lib
checking readline/readline.h usability... yes
checking readline/readline.h presence... yes
checking for readline/readline.h... yes
checking readline/history.h usability... yes
checking readline/history.h presence... yes
checking for readline/history.h... yes
 
and the error disappeared
 
The second error:
 
ERROR: neutrino-image-1.0-r0 do_rootfs: Unable to update the package index files. Command '/home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f /home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/opkg.conf -t /home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/temp/ipktemp/ -o /home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/rootfs  --force_postinstall --prefer-arch-to-version   update' returned 127:
/home/flk/yocto/build/poky-3.2/hd60/tmp/work/hd60-oe-linux-gnueabi/neutrino-image/1.0-r0/recipe-sysroot-native/usr/bin/opkg: error while loading shared libraries: libcharset.so.1: cannot open shared object file: No such file or directory
 
after some research why libiconv libs are  being used (which i didn't have installed on the rebuild machine) i found this in libarchive:
configure.ac
 
and was able to avoid the error by including 'gettext' to the inherit line in libarchive_3.4.3.bb


Hi Markus,

Thanks for reporting these problems.
The additions that you made also seem to be missing on the master branch.

Could you send a patch to the oe-core list :

   openembedded-core@...

as explained here:

https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

Thanks,

../Randy


Kind regards



-- 
# Randy MacLeod
# Wind River Linux


why would "file" command not print out "ISO 9660" for .iso image?

Robert P. J. Day
 

was just handed this little puzzler and, before i dive into it,
perhaps someone has an answer.

in working WRL9/morty system, the "file" command (file_5.28.bb) is
used to determine whether a file is a valid ISO image, by running
"file" against the image file, expecting to get output like:

rday.iso: DOS/MBR boot sector ISO 9660 ... etc etc ...

and doing a tacky string comparison simply looking for the substring
"ISO" and, so far, it's worked just fine.

now, moving to an LTS19/zeus system -- same ISO image -- that shell
string comparison fails, apparently because the output from
file_5.37.bb for precisely the same ISO image file is only:

rday.iso: DOS/MBR boot sector

as in, that's the entire output, hence no "ISO" substring, hence
failed comparison.

i'm about to verify that all is as i've been told, then try to
figure out why the newer file command is dropping all the rest of that
output. (it's even possible that the developers put in a weird, custom
magic file but that's just speculation.)

does the above sound familiar to anyone? is the newer "file" command
sufficiently different as to have dropped that "ISO ..." part of the
output? and is there an option to restore it?

thanks for any hints.

rday


Re: insmod - huawei E3372h kernel module

Zoran
 

Even better:

debian@arm:/lib/modules/5.8.18-bone24/kernel/drivers/net/usb$ lsmod
Module                  Size  Used by
huawei_cdc_ncm         16384  0
cdc_wdm                24576  1 huawei_cdc_ncm
cdc_ncm                32768  1 huawei_cdc_ncm

spidev                 20480  0
evdev                  20480  1
usb_f_acm              20480  2
u_serial               24576  3 usb_f_acm
usb_f_ncm              24576  2
usb_f_rndis            24576  4
u_ether                24576  2 usb_f_ncm,usb_f_rndis
libcomposite           49152  16 usb_f_acm,usb_f_ncm,usb_f_rndis
8021q                  24576  0
garp                   16384  1 8021q
stp                    16384  1 garp
mrp                    16384  1 8021q
llc                    16384  2 garp,stp
iptable_nat            16384  0
nf_nat                 28672  1 iptable_nat
nf_conntrack           98304  1 nf_nat
nf_defrag_ipv6         20480  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
iptable_mangle         16384  0
iptable_filter         16384  0
mikrobus_test          16384  1
mikrobus               32768  1 mikrobus_test
ip_tables              24576  3 iptable_mangle,iptable_filter,iptable_nat
x_tables               24576  3 iptable_mangle,ip_tables,iptable_filter
debian@arm:/lib/modules/5.8.18-bone24/kernel/drivers/net/usb$

Zolee, U need (based upon this lsmod on my target) to solve the problem (homework for you).

( U owe me double Glenmorangie on rocks! )

Zee
_______

On Fri, Jan 8, 2021 at 1:49 PM Zoran via lists.yoctoproject.org <zoran.stojsavljevic=gmail.com@...> wrote:
> Does it mean that it will never ever work?
> Could you please try this one? This might match your kernel version:
> https://elixir.bootlin.com/linux/v5.8.18/source/drivers/net/usb/huawei_cdc_ncm.c
>
> Zolee

[vuser@fedora33-ssd usb]$ kdiff3 huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
org.kde.kdiff3: "Loading A: /home/vuser/projects/kernel.bb/bb-kernel-5.8.18-bone24/KERNEL/drivers/net/usb/huawei_cdc_ncm_5.8.18.c"
"/proc/1715042/root"
org.kde.kdiff3: Loading B:  "/home/vuser/projects/kernel.bb/bb-kernel-5.8.18-bone24/KERNEL/drivers/net/usb/huawei_cdc_ncm.c"
[vuser@fedora33-ssd usb]$ diff huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
[vuser@fedora33-ssd usb]$ diff -c huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
[vuser@fedora33-ssd usb]$ diff -s huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
Files huawei_cdc_ncm_5.8.18.c and huawei_cdc_ncm.c are identical
[vuser@fedora33-ssd usb]$

This is the same modul. You need to try to built-in this one in the kernel.

Obviously, you need to load some basic module, this one is dependent upon (my best guess).

This one is missing. Maybe this one!

$ cat config-5.8.18-bone24 | grep HUAWEI
# CONFIG_NET_VENDOR_HUAWEI is not set
CONFIG_USB_NET_HUAWEI_CDC_NCM=m

Zee
_______

On Fri, Jan 8, 2021 at 1:29 PM Zoltan Kerenyi Nagy <kerenyi.nagy.zoltan@...> wrote:
Does it mean that it will never ever work?

Could you please try this one? This might match your kernel version:

https://elixir.bootlin.com/linux/v5.8.18/source/drivers/net/usb/huawei_cdc_ncm.c
--
Zolee






Re: Unable to extract tar file #dunfell #yocto

Vijay Rakesh Munganda
 

On Fri, Jan 8, 2021 at 04:09 AM, Quentin Schulz wrote:
On Fri, Jan 08, 2021 at 04:00:54AM -0800, Vijay Rakesh Munganda wrote:
On Fri, Jan 8, 2021 at 03:15 AM, Quentin Schulz wrote:


On Fri, Jan 08, 2021 at 03:07:43AM -0800, Vijay Rakesh Munganda wrote:

On Fri, Jan 8, 2021 at 01:26 AM, Quentin Schulz wrote:



Hi,

On Fri, Jan 08, 2021 at 01:19:51AM -0800, Vijay Rakesh Munganda wrote:


Hi Paul Barker,

No, ${WORKDIR}/tokbox directory is empty, it is not getting placed. I can
only see it in the downloads directory.
S = "${WORKDIR}/libopentok_linux_llvm_arm64"

This is the root directory of your archive and should be used for `S`

Cheers,
Quentin
By changing to S = "${WORKDIR}/libopentok_linux_llvm_arm64" error got
eliminated, thank you.

Now, how can I install the file under
opentok_linux_llvm_arm64/lib/libopentok.so into the rootfs?

I tried the below code but got an error as *install: cannot stat
'lib/libopentok.so': No such file or directory*.
If you go into ${WORKDIR} of your recipe (tmp/work/<arch>/<recipe name>),
what is the path to libopentok.*.so?
Do you have B set up somewhere in your recipe?
Otherwise try ${S}/lib/libopentok.so for the source path.

Quentin
Thank you! it worked.

Thanks,
Vijay Rakesh.


Re: insmod - huawei E3372h kernel module

Zoran
 

> Does it mean that it will never ever work?
> Could you please try this one? This might match your kernel version:
> https://elixir.bootlin.com/linux/v5.8.18/source/drivers/net/usb/huawei_cdc_ncm.c
>
> Zolee

[vuser@fedora33-ssd usb]$ kdiff3 huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
org.kde.kdiff3: "Loading A: /home/vuser/projects/kernel.bb/bb-kernel-5.8.18-bone24/KERNEL/drivers/net/usb/huawei_cdc_ncm_5.8.18.c"
"/proc/1715042/root"
org.kde.kdiff3: Loading B:  "/home/vuser/projects/kernel.bb/bb-kernel-5.8.18-bone24/KERNEL/drivers/net/usb/huawei_cdc_ncm.c"
[vuser@fedora33-ssd usb]$ diff huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
[vuser@fedora33-ssd usb]$ diff -c huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
[vuser@fedora33-ssd usb]$ diff -s huawei_cdc_ncm_5.8.18.c huawei_cdc_ncm.c
Files huawei_cdc_ncm_5.8.18.c and huawei_cdc_ncm.c are identical
[vuser@fedora33-ssd usb]$

This is the same modul. You need to try to built-in this one in the kernel.

Obviously, you need to load some basic module, this one is dependent upon (my best guess).

This one is missing. Maybe this one!

$ cat config-5.8.18-bone24 | grep HUAWEI
# CONFIG_NET_VENDOR_HUAWEI is not set
CONFIG_USB_NET_HUAWEI_CDC_NCM=m

Zee
_______


On Fri, Jan 8, 2021 at 1:29 PM Zoltan Kerenyi Nagy <kerenyi.nagy.zoltan@...> wrote:
Does it mean that it will never ever work?

Could you please try this one? This might match your kernel version:

https://elixir.bootlin.com/linux/v5.8.18/source/drivers/net/usb/huawei_cdc_ncm.c
--
Zolee



Re: insmod - huawei E3372h kernel module

Zoltan Kerenyi Nagy
 

I experimented with the latest and greatest source, this is my log during bitbake:

http://paste.ubuntu.com/p/R5PjtrtVYn/

Thank you for your efforts!
--
Zolee


Re: insmod - huawei E3372h kernel module

Zoltan Kerenyi Nagy
 

Does it mean that it will never ever work?

Could you please try this one? This might match your kernel version:

https://elixir.bootlin.com/linux/v5.8.18/source/drivers/net/usb/huawei_cdc_ncm.c
--
Zolee


Re: Unable to extract tar file #dunfell #yocto

Quentin Schulz
 

On Fri, Jan 08, 2021 at 04:00:54AM -0800, Vijay Rakesh Munganda wrote:
On Fri, Jan 8, 2021 at 03:15 AM, Quentin Schulz wrote:


On Fri, Jan 08, 2021 at 03:07:43AM -0800, Vijay Rakesh Munganda wrote:

On Fri, Jan 8, 2021 at 01:26 AM, Quentin Schulz wrote:



Hi,

On Fri, Jan 08, 2021 at 01:19:51AM -0800, Vijay Rakesh Munganda wrote:


Hi Paul Barker,

No, ${WORKDIR}/tokbox directory is empty, it is not getting placed. I can
only see it in the downloads directory.
S = "${WORKDIR}/libopentok_linux_llvm_arm64"

This is the root directory of your archive and should be used for `S`

Cheers,
Quentin
By changing to S = "${WORKDIR}/libopentok_linux_llvm_arm64" error got
eliminated, thank you.

Now, how can I install the file under
opentok_linux_llvm_arm64/lib/libopentok.so into the rootfs?

I tried the below code but got an error as *install: cannot stat
'lib/libopentok.so': No such file or directory*.
If you go into ${WORKDIR} of your recipe (tmp/work/<arch>/<recipe name>),
what is the path to libopentok.*.so?
Do you have B set up somewhere in your recipe?
Otherwise try ${S}/lib/libopentok.so for the source path.

Quentin


Re: Unable to extract tar file #dunfell #yocto

Vijay Rakesh Munganda
 

On Fri, Jan 8, 2021 at 03:15 AM, Quentin Schulz wrote:
On Fri, Jan 08, 2021 at 03:07:43AM -0800, Vijay Rakesh Munganda wrote:
On Fri, Jan 8, 2021 at 01:26 AM, Quentin Schulz wrote:


Hi,

On Fri, Jan 08, 2021 at 01:19:51AM -0800, Vijay Rakesh Munganda wrote:

Hi Paul Barker,

No, ${WORKDIR}/tokbox directory is empty, it is not getting placed. I can
only see it in the downloads directory.
S = "${WORKDIR}/libopentok_linux_llvm_arm64"

This is the root directory of your archive and should be used for `S`

Cheers,
Quentin
By changing to S = "${WORKDIR}/libopentok_linux_llvm_arm64" error got eliminated, thank you.

Now, how can I install the file under opentok_linux_llvm_arm64/lib/libopentok.so into the rootfs?

I tried the below code but got an error as *install: cannot stat 'lib/libopentok.so': No such file or directory*.
If you go into ${WORKDIR} of your recipe (tmp/work/<arch>/<recipe name>),
what is the path to libopentok.*.so?

Quentin
This is the path to libopentok.so tmp/work/aarch64-poky-linux/tokbox/1.0-r0/libopentok_linux_llvm_arm64/lib/

Thanks,
Vijay Rakesh.


Re: insmod - huawei E3372h kernel module

Zoran
 

> insmod /lib/modules/4.10.0/extra/huawei_cdc_ncm.ko
> insmod: can't insert '/lib/modules/4.10.0/extra/huawei_cdc_ncm.ko': unknown symbol in module, or unknown parameter


On my target (Pocket Bone):

debian@arm:/lib/modules/5.8.18-bone24/kernel$ find . -name huawei_cdc_ncm*
./drivers/net/usb/huawei_cdc_ncm.ko.xz
debian@arm:/lib/modules/5.8.18-bone24/kernel$ cd ./drivers/net/usb/
debian@arm:/lib/modules/5.8.18-bone24/kernel/drivers/net/sudo insmod huawei_cdc_ncm.ko.xz
[ 6554.826591] huawei_cdc_ncm: Unknown symbol cdc_ncm_tx_fixup (err -2)
[ 6554.833115] huawei_cdc_ncm: Unknown symbol cdc_ncm_bind_common (err -2)
[ 6554.841745] huawei_cdc_ncm: Unknown symbol usb_cdc_wdm_register (err -2)
[ 6554.849680] huawei_cdc_ncm: Unknown symbol cdc_ncm_unbind (err -2)
[ 6554.857042] huawei_cdc_ncm: Unknown symbol cdc_ncm_rx_fixup (err -2)
insmod: ERROR: could not insert module huawei_cdc_ncm.ko.xz: Unknown symbol in module

debian@arm:/lib/modules/5.8.18-bone24/kernel/drivers/net/usb$ uname -a
Linux arm 5.8.18-bone24 #1 PREEMPT Sun Dec 13 19:15:04 CET 2020 armv7l GNU/Linux
debian@arm:/lib/modules/5.8.18-bone24/kernel/drivers/net/usb$ cat /etc/debian_version
10.7
debian@arm:/lib/modules/5.8.18-bone24/kernel/drivers/net/usb$

Good Luck!
Zoran
_______


On Fri, Jan 8, 2021 at 12:22 PM Zoltan Kerenyi Nagy <kerenyi.nagy.zoltan@...> wrote:
No success :-(

insmod /lib/modules/4.10.0/extra/huawei_cdc_ncm.ko
insmod: can't insert '/lib/modules/4.10.0/extra/huawei_cdc_ncm.ko': unknown symbol in module, or unknown parameter

--
Zolee


2301 - 2320 of 54237