Date   

Re: Packages Missing from Deploy

Robert Joslyn
 

On Jan 19, 2022, at 9:17 PM, Robert Joslyn <robert.joslyn@redrectangle.org> wrote:

I’m testing migrating one of my dunfell builds to master in anticipation of the upcoming LTS, and there is a difference in how packages are populated into deploy that is causing me problems. My builds use a package feed, and the way I’ve been generating my package feed is to create a packagegroup recipe that RDEPENDS on all of the top level packages I want pulled into my feed. Then I’ll generate the packagefeed index and copy the content of tmp/deploy/ipk to the web server.

On dunfell, if I build a recipe like my packagegroup, the packages from that recipe and all recursive dependencies are populated into tmp/deploy/ipk. On master, only the packages from the specific recipe I built are populated into tmp/deploy/ipk, but none of the RDEPENDS. I’m using ipk, but the same behavior holds for rpm and deb.

This can easily be seen with a simple poky checkout and build, for example on dunfell:
$ bitbake curl
$ find tmp/deploy/ipk -type f | wc -l
4691

And on master:
$ bitbake curl
$ find tmp/deploy/ipk -type f | wc -l
10

In this example of building curl, the only packages I get are from curl and ca-certificates.

Is this expected behavior? Is there something I need to configure to get the same package generation as dunfell?
After bisecting, I found that yes, this is now expected behavior:
https://git.yoctoproject.org/poky/commit/?id=568f62214bca3ac6d35eef8d9f4562596fb4c9ab

Basically, that commit removes the recursive dependency on the packaging tasks. Using ‘bitbake --runall build ...’ as suggested in the commit does provide the behavior I want. For me, this is only an issue when building my package feeds. It seems that the documentation for the package feeds should be updated to reflect this change. Unless I missed something, if you follow the docs you end up with a broken feed that is missing a lot of needed packages.

I can probably write something up if needed. I think just a paragraph explaining it in this section somewhere:
https://docs.yoctoproject.org/singleindex.html#using-runtime-package-management

Thanks,
Robert


Re: non-existent task do_package_write_rpm error

Alexander Kanavin
 

Congratulations, you now know the three major flavors of a recipe, and why and where they're needed :)

Alex


On Sat, 22 Jan 2022 at 14:34, Winfried <winfried_mb2@...> wrote:
Update:

TOOLCHAIN_HOST_TASK_append = “ nativesdk-hardening-check”

does work. The SDK build succeeds and the hardening-check script is installed in the x86_64-pokysdk-linux sysroot.

regards,
Winfried
Op 22-01-2022 14:11 schreef Winfried <winfried_mb2@...>:


Thanks.
With TOOLCHAIN_HOST_TASK_append = “ hardening-check” the sdk build progresses a bit further but then stops with error:

ERROR: dynniq-image-flownode-acu-default-1.0-r0 do_populate_sdk: Could not invoke dnf. Command '/home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-f
lownode-acu-default/1.0-r0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownod
e-acu-default/1.0-r0/sdk/image/etc/dnf/dnf.conf --setopt=reposdir=/home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/sdk
/image/etc/yum.repos.d --installroot=/home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/sdk/image --setopt=logdir=/home/
wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/temp --repofrompath=oe-repo,/home/wdobbe/yocto/flownode_zeus/build-flownode
-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/oe-sdk-repo --nogpgcheck install hardening-check nativesdk-cmake nativesdk-packagegroup-qt5-toolchain-host nativesdk
-packagegroup-sdk-host nativesdk-perl-modules nativesdk-rpm packagegroup-cross-canadian-dynniq-flownode-acu' returned 1:                                                                                           
DNF version: 4.2.2                                                                        
cachedir: /home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/sdk/image/var/cache/dnf                                     
Added oe-repo repo from /home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/oe-sdk-repo                                   
repo: using cache for: oe-repo                                                                                                                          (...)                                                                                                                                         
Error:                                                                                                                 
Problem: conflicting requests                                                            
 - package hardening-check-2.6-r0.cortexa9hf_neon does not have a compatible architecture
 - nothing provides /usr/bin/perl needed by hardening-check-2.6-r0.cortexa9hf_neon       
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) 
 
ERROR: Logfile of failure stored in: /home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/temp/log.do_populate_sdk.5994
ERROR: Task (/home/wdobbe/yocto/flownode_zeus/sources/meta-dynniq-flownode-acu/recipes-dynniq/images/dynniq-image-flownode-acu-default.bb:do_populate_sdk) failed with exit code '1'


Bitbake builds package hardening-check for the target architecture (cortexa9hf_neon) i.s.o for x86_64 (or noarch).

Any ideas how to fix that ?

regards,
Winfried

Op 21-01-2022 23:26 schreef Alexander Kanavin <alex.kanavin@...>:


Use TOOLCHAIN_HOST_TASK:append = " ..." in your image recipe.

Alex

On Fri, 21 Jan 2022 at 21:00, Winfried <winfried_mb2@...> wrote:
Hi Alex,

Thanks for the tip. When I add hardening-check to IMAGE_INSTALL the build does indeed succeed.
But then the script is installed in the target sysroot of the SDK. I would like to have it in the native (x86_64-pokysdk-linux) sysroot as it is a tool to use on the build server.

Any idea how to achieve that ?

Thanks,
Winfried
Op 21-01-2022 20:09 schreef Alexander Kanavin <alex.kanavin@...>:


You need to drop the -native suffix when installing to target image or SDK. -native is only for the bitbake build itself.

Alex

On Fri, 21 Jan 2022 at 20:07, W. Dobbe <winfried_mb2@...> wrote:
Hi,

I'm writing a recipe for package hardening-check .
This package builds with only a simple Makefile (that has no install target). The recipe only installs a script hardening-check in /usr/bin.

I would like to include this script in our SDK.
The recipe itself builds fine (bitbake hardening-check-native).

But when I add hardening-check-native to IMAGE_INSTALL in my image the build fails with:
Task do_populate_sdk in myimage.bb rdepends upon non-existent task do_package_write_rpm in virtual:native:(...)/recipes-devtools/hardening-check/hardening-check_2.6.bb
Same error when I append the package to TOOLCHAIN_HOST_TASK instead.

Any idea how to solve this? Do I need to inherit my recipe from something?
Recipe included below.

Thanks in advance for the help!

regards,
Winfried


SUMMARY = "Script to check an executable for certain security weaknesses."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://debian/copyright;md5=06ff97d53f05a9b8ce2a416b30f496b9"

SRC_URI = "http://ftp.debian.org/debian/pool/main/h/hardening-wrapper/hardening-wrapper_${PV}.tar.xz \
          file://0001-perl_regex.patch \
         "
SRC_URI[md5sum] = "47c93c05b4d0199be8df0d35dbd68192"
SRC_URI[sha256sum] = "c5fc46439646d0929a0605e4f3db67e57eefbbf5ceec5a2888440dbdf4450224"

RDEPENDS_${PN} = "perl"

S = "${WORKDIR}/hardening-wrapper"

do_patch () {
   cd ${S}
   patch -p1 -u -i ${WORKDIR}/0001-perl_regex.patch
}

do_configure () {
       # Specify any needed configure commands here
       :
}

do_compile () {
       export DEB_HOST_ARCH=`uname -m`
       export DEB_HOST_ARCH_OS=`uname -s`
       oe_runmake
}

do_install () {
   install -d ${D}/${bindir}
   install -m 755 ${S}/build-tree/hardening-check ${D}/${bindir}
}

BBCLASSEXTEND = "native nativesdk"







Re: non-existent task do_package_write_rpm error

W. Dobbe
 

Update:

TOOLCHAIN_HOST_TASK_append = “ nativesdk-hardening-check”

does work. The SDK build succeeds and the hardening-check script is installed in the x86_64-pokysdk-linux sysroot.

regards,
Winfried

Op 22-01-2022 14:11 schreef Winfried <winfried_mb2@...>:


Thanks.
With TOOLCHAIN_HOST_TASK_append = “ hardening-check” the sdk build progresses a bit further but then stops with error:

ERROR: dynniq-image-flownode-acu-default-1.0-r0 do_populate_sdk: Could not invoke dnf. Command '/home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-f
lownode-acu-default/1.0-r0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownod
e-acu-default/1.0-r0/sdk/image/etc/dnf/dnf.conf --setopt=reposdir=/home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/sdk
/image/etc/yum.repos.d --installroot=/home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/sdk/image --setopt=logdir=/home/
wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/temp --repofrompath=oe-repo,/home/wdobbe/yocto/flownode_zeus/build-flownode
-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/oe-sdk-repo --nogpgcheck install hardening-check nativesdk-cmake nativesdk-packagegroup-qt5-toolchain-host nativesdk
-packagegroup-sdk-host nativesdk-perl-modules nativesdk-rpm packagegroup-cross-canadian-dynniq-flownode-acu' returned 1:                                                                                           
DNF version: 4.2.2                                                                        
cachedir: /home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/sdk/image/var/cache/dnf                                     
Added oe-repo repo from /home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/oe-sdk-repo                                   
repo: using cache for: oe-repo                                                                                                                          (...)                                                                                                                                         
Error:                                                                                                                 
Problem: conflicting requests                                                            
 - package hardening-check-2.6-r0.cortexa9hf_neon does not have a compatible architecture
 - nothing provides /usr/bin/perl needed by hardening-check-2.6-r0.cortexa9hf_neon       
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) 
 
ERROR: Logfile of failure stored in: /home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/temp/log.do_populate_sdk.5994
ERROR: Task (/home/wdobbe/yocto/flownode_zeus/sources/meta-dynniq-flownode-acu/recipes-dynniq/images/dynniq-image-flownode-acu-default.bb:do_populate_sdk) failed with exit code '1'


Bitbake builds package hardening-check for the target architecture (cortexa9hf_neon) i.s.o for x86_64 (or noarch).

Any ideas how to fix that ?

regards,
Winfried

Op 21-01-2022 23:26 schreef Alexander Kanavin <alex.kanavin@...>:


Use TOOLCHAIN_HOST_TASK:append = " ..." in your image recipe.

Alex

On Fri, 21 Jan 2022 at 21:00, Winfried <winfried_mb2@...> wrote:
Hi Alex,

Thanks for the tip. When I add hardening-check to IMAGE_INSTALL the build does indeed succeed.
But then the script is installed in the target sysroot of the SDK. I would like to have it in the native (x86_64-pokysdk-linux) sysroot as it is a tool to use on the build server.

Any idea how to achieve that ?

Thanks,
Winfried
Op 21-01-2022 20:09 schreef Alexander Kanavin <alex.kanavin@...>:


You need to drop the -native suffix when installing to target image or SDK. -native is only for the bitbake build itself.

Alex

On Fri, 21 Jan 2022 at 20:07, W. Dobbe <winfried_mb2@...> wrote:
Hi,

I'm writing a recipe for package hardening-check .
This package builds with only a simple Makefile (that has no install target). The recipe only installs a script hardening-check in /usr/bin.

I would like to include this script in our SDK.
The recipe itself builds fine (bitbake hardening-check-native).

But when I add hardening-check-native to IMAGE_INSTALL in my image the build fails with:
Task do_populate_sdk in myimage.bb rdepends upon non-existent task do_package_write_rpm in virtual:native:(...)/recipes-devtools/hardening-check/hardening-check_2.6.bb
Same error when I append the package to TOOLCHAIN_HOST_TASK instead.

Any idea how to solve this? Do I need to inherit my recipe from something?
Recipe included below.

Thanks in advance for the help!

regards,
Winfried


SUMMARY = "Script to check an executable for certain security weaknesses."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://debian/copyright;md5=06ff97d53f05a9b8ce2a416b30f496b9"

SRC_URI = "http://ftp.debian.org/debian/pool/main/h/hardening-wrapper/hardening-wrapper_${PV}.tar.xz \
          file://0001-perl_regex.patch \
         "
SRC_URI[md5sum] = "47c93c05b4d0199be8df0d35dbd68192"
SRC_URI[sha256sum] = "c5fc46439646d0929a0605e4f3db67e57eefbbf5ceec5a2888440dbdf4450224"

RDEPENDS_${PN} = "perl"

S = "${WORKDIR}/hardening-wrapper"

do_patch () {
   cd ${S}
   patch -p1 -u -i ${WORKDIR}/0001-perl_regex.patch
}

do_configure () {
       # Specify any needed configure commands here
       :
}

do_compile () {
       export DEB_HOST_ARCH=`uname -m`
       export DEB_HOST_ARCH_OS=`uname -s`
       oe_runmake
}

do_install () {
   install -d ${D}/${bindir}
   install -m 755 ${S}/build-tree/hardening-check ${D}/${bindir}
}

BBCLASSEXTEND = "native nativesdk"







Re: non-existent task do_package_write_rpm error

W. Dobbe
 

Thanks.
With TOOLCHAIN_HOST_TASK_append = “ hardening-check” the sdk build progresses a bit further but then stops with error:

ERROR: dynniq-image-flownode-acu-default-1.0-r0 do_populate_sdk: Could not invoke dnf. Command '/home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-f
lownode-acu-default/1.0-r0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownod
e-acu-default/1.0-r0/sdk/image/etc/dnf/dnf.conf --setopt=reposdir=/home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/sdk
/image/etc/yum.repos.d --installroot=/home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/sdk/image --setopt=logdir=/home/
wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/temp --repofrompath=oe-repo,/home/wdobbe/yocto/flownode_zeus/build-flownode
-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/oe-sdk-repo --nogpgcheck install hardening-check nativesdk-cmake nativesdk-packagegroup-qt5-toolchain-host nativesdk
-packagegroup-sdk-host nativesdk-perl-modules nativesdk-rpm packagegroup-cross-canadian-dynniq-flownode-acu' returned 1:                                                                                           
DNF version: 4.2.2                                                                        
cachedir: /home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/sdk/image/var/cache/dnf                                     
Added oe-repo repo from /home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/oe-sdk-repo                                   
repo: using cache for: oe-repo                                                                                                                          (...)                                                                                                                                         
Error:                                                                                                                 
Problem: conflicting requests                                                            
 - package hardening-check-2.6-r0.cortexa9hf_neon does not have a compatible architecture
 - nothing provides /usr/bin/perl needed by hardening-check-2.6-r0.cortexa9hf_neon       
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) 
 
ERROR: Logfile of failure stored in: /home/wdobbe/yocto/flownode_zeus/build-flownode-acu/tmp/work/dynniq_flownode_acu-poky-linux-gnueabi/dynniq-image-flownode-acu-default/1.0-r0/temp/log.do_populate_sdk.5994
ERROR: Task (/home/wdobbe/yocto/flownode_zeus/sources/meta-dynniq-flownode-acu/recipes-dynniq/images/dynniq-image-flownode-acu-default.bb:do_populate_sdk) failed with exit code '1'


Bitbake builds package hardening-check for the target architecture (cortexa9hf_neon) i.s.o for x86_64 (or noarch).

Any ideas how to fix that ?

regards,
Winfried

Op 21-01-2022 23:26 schreef Alexander Kanavin <alex.kanavin@...>:


Use TOOLCHAIN_HOST_TASK:append = " ..." in your image recipe.

Alex

On Fri, 21 Jan 2022 at 21:00, Winfried <winfried_mb2@...> wrote:
Hi Alex,

Thanks for the tip. When I add hardening-check to IMAGE_INSTALL the build does indeed succeed.
But then the script is installed in the target sysroot of the SDK. I would like to have it in the native (x86_64-pokysdk-linux) sysroot as it is a tool to use on the build server.

Any idea how to achieve that ?

Thanks,
Winfried
Op 21-01-2022 20:09 schreef Alexander Kanavin <alex.kanavin@...>:


You need to drop the -native suffix when installing to target image or SDK. -native is only for the bitbake build itself.

Alex

On Fri, 21 Jan 2022 at 20:07, W. Dobbe <winfried_mb2@...> wrote:
Hi,

I'm writing a recipe for package hardening-check .
This package builds with only a simple Makefile (that has no install target). The recipe only installs a script hardening-check in /usr/bin.

I would like to include this script in our SDK.
The recipe itself builds fine (bitbake hardening-check-native).

But when I add hardening-check-native to IMAGE_INSTALL in my image the build fails with:
Task do_populate_sdk in myimage.bb rdepends upon non-existent task do_package_write_rpm in virtual:native:(...)/recipes-devtools/hardening-check/hardening-check_2.6.bb
Same error when I append the package to TOOLCHAIN_HOST_TASK instead.

Any idea how to solve this? Do I need to inherit my recipe from something?
Recipe included below.

Thanks in advance for the help!

regards,
Winfried


SUMMARY = "Script to check an executable for certain security weaknesses."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://debian/copyright;md5=06ff97d53f05a9b8ce2a416b30f496b9"

SRC_URI = "http://ftp.debian.org/debian/pool/main/h/hardening-wrapper/hardening-wrapper_${PV}.tar.xz \
          file://0001-perl_regex.patch \
         "
SRC_URI[md5sum] = "47c93c05b4d0199be8df0d35dbd68192"
SRC_URI[sha256sum] = "c5fc46439646d0929a0605e4f3db67e57eefbbf5ceec5a2888440dbdf4450224"

RDEPENDS_${PN} = "perl"

S = "${WORKDIR}/hardening-wrapper"

do_patch () {
   cd ${S}
   patch -p1 -u -i ${WORKDIR}/0001-perl_regex.patch
}

do_configure () {
       # Specify any needed configure commands here
       :
}

do_compile () {
       export DEB_HOST_ARCH=`uname -m`
       export DEB_HOST_ARCH_OS=`uname -s`
       oe_runmake
}

do_install () {
   install -d ${D}/${bindir}
   install -m 755 ${S}/build-tree/hardening-check ${D}/${bindir}
}

BBCLASSEXTEND = "native nativesdk"







Re: Alsa configuration error

mihirdave36@...
 

Hi Michael,

Thanks for the detail I will try your solution.

Sincerely
Mihir


[meta-security][PATCH] samhain: upgrade 4.4.3 -> 4.4.6

Yi Zhao
 

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
recipes-ids/samhain/samhain.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-ids/samhain/samhain.inc b/recipes-ids/samhain/samhain.inc
index 97f5f2d..077e118 100644
--- a/recipes-ids/samhain/samhain.inc
+++ b/recipes-ids/samhain/samhain.inc
@@ -3,7 +3,7 @@ HOMEPAGE = "http://www.la-samhna.de/samhain/"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=8ca43cbc842c2336e835926c2166c28b"

-PV = "4.4.3"
+PV = "4.4.6"

SRC_URI = "https://la-samhna.de/archive/samhain_signed-${PV}.tar.gz \
file://${INITSCRIPT_NAME}.init \
@@ -21,7 +21,7 @@ SRC_URI = "https://la-samhna.de/archive/samhain_signed-${PV}.tar.gz \
file://samhain-fix-initializer-element-is-not-constant.patch \
"

-SRC_URI[sha256sum] = "3e57574036d5055e9557ec5095818b419ea6c4365370fc2ccce1e9f87f9fad08"
+SRC_URI[sha256sum] = "0b511a184066759cd864f6d15fe941ed3fe60f0cdc886dab68daa191d567de24"

UPSTREAM_CHECK_URI = "https://www.la-samhna.de/samhain/archive.html"
UPSTREAM_CHECK_REGEX = "samhain_signed-(?P<pver>(\d+(\.\d+)+))\.tar"
--
2.25.1


Re: non-existent task do_package_write_rpm error

Alexander Kanavin
 

Use TOOLCHAIN_HOST_TASK:append = " ..." in your image recipe.

Alex


On Fri, 21 Jan 2022 at 21:00, Winfried <winfried_mb2@...> wrote:
Hi Alex,

Thanks for the tip. When I add hardening-check to IMAGE_INSTALL the build does indeed succeed.
But then the script is installed in the target sysroot of the SDK. I would like to have it in the native (x86_64-pokysdk-linux) sysroot as it is a tool to use on the build server.

Any idea how to achieve that ?

Thanks,
Winfried
Op 21-01-2022 20:09 schreef Alexander Kanavin <alex.kanavin@...>:


You need to drop the -native suffix when installing to target image or SDK. -native is only for the bitbake build itself.

Alex

On Fri, 21 Jan 2022 at 20:07, W. Dobbe <winfried_mb2@...> wrote:
Hi,

I'm writing a recipe for package hardening-check .
This package builds with only a simple Makefile (that has no install target). The recipe only installs a script hardening-check in /usr/bin.

I would like to include this script in our SDK.
The recipe itself builds fine (bitbake hardening-check-native).

But when I add hardening-check-native to IMAGE_INSTALL in my image the build fails with:
Task do_populate_sdk in myimage.bb rdepends upon non-existent task do_package_write_rpm in virtual:native:(...)/recipes-devtools/hardening-check/hardening-check_2.6.bb
Same error when I append the package to TOOLCHAIN_HOST_TASK instead.

Any idea how to solve this? Do I need to inherit my recipe from something?
Recipe included below.

Thanks in advance for the help!

regards,
Winfried


SUMMARY = "Script to check an executable for certain security weaknesses."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://debian/copyright;md5=06ff97d53f05a9b8ce2a416b30f496b9"

SRC_URI = "http://ftp.debian.org/debian/pool/main/h/hardening-wrapper/hardening-wrapper_${PV}.tar.xz \
          file://0001-perl_regex.patch \
         "
SRC_URI[md5sum] = "47c93c05b4d0199be8df0d35dbd68192"
SRC_URI[sha256sum] = "c5fc46439646d0929a0605e4f3db67e57eefbbf5ceec5a2888440dbdf4450224"

RDEPENDS_${PN} = "perl"

S = "${WORKDIR}/hardening-wrapper"

do_patch () {
   cd ${S}
   patch -p1 -u -i ${WORKDIR}/0001-perl_regex.patch
}

do_configure () {
       # Specify any needed configure commands here
       :
}

do_compile () {
       export DEB_HOST_ARCH=`uname -m`
       export DEB_HOST_ARCH_OS=`uname -s`
       oe_runmake
}

do_install () {
   install -d ${D}/${bindir}
   install -m 755 ${S}/build-tree/hardening-check ${D}/${bindir}
}

BBCLASSEXTEND = "native nativesdk"







Re: non-existent task do_package_write_rpm error

W. Dobbe
 

Hi Alex,

Thanks for the tip. When I add hardening-check to IMAGE_INSTALL the build does indeed succeed.
But then the script is installed in the target sysroot of the SDK. I would like to have it in the native (x86_64-pokysdk-linux) sysroot as it is a tool to use on the build server.

Any idea how to achieve that ?

Thanks,
Winfried

Op 21-01-2022 20:09 schreef Alexander Kanavin <alex.kanavin@...>:


You need to drop the -native suffix when installing to target image or SDK. -native is only for the bitbake build itself.

Alex

On Fri, 21 Jan 2022 at 20:07, W. Dobbe <winfried_mb2@...> wrote:
Hi,

I'm writing a recipe for package hardening-check .
This package builds with only a simple Makefile (that has no install target). The recipe only installs a script hardening-check in /usr/bin.

I would like to include this script in our SDK.
The recipe itself builds fine (bitbake hardening-check-native).

But when I add hardening-check-native to IMAGE_INSTALL in my image the build fails with:
Task do_populate_sdk in myimage.bb rdepends upon non-existent task do_package_write_rpm in virtual:native:(...)/recipes-devtools/hardening-check/hardening-check_2.6.bb
Same error when I append the package to TOOLCHAIN_HOST_TASK instead.

Any idea how to solve this? Do I need to inherit my recipe from something?
Recipe included below.

Thanks in advance for the help!

regards,
Winfried


SUMMARY = "Script to check an executable for certain security weaknesses."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://debian/copyright;md5=06ff97d53f05a9b8ce2a416b30f496b9"

SRC_URI = "http://ftp.debian.org/debian/pool/main/h/hardening-wrapper/hardening-wrapper_${PV}.tar.xz \
          file://0001-perl_regex.patch \
         "
SRC_URI[md5sum] = "47c93c05b4d0199be8df0d35dbd68192"
SRC_URI[sha256sum] = "c5fc46439646d0929a0605e4f3db67e57eefbbf5ceec5a2888440dbdf4450224"

RDEPENDS_${PN} = "perl"

S = "${WORKDIR}/hardening-wrapper"

do_patch () {
   cd ${S}
   patch -p1 -u -i ${WORKDIR}/0001-perl_regex.patch
}

do_configure () {
       # Specify any needed configure commands here
       :
}

do_compile () {
       export DEB_HOST_ARCH=`uname -m`
       export DEB_HOST_ARCH_OS=`uname -s`
       oe_runmake
}

do_install () {
   install -d ${D}/${bindir}
   install -m 755 ${S}/build-tree/hardening-check ${D}/${bindir}
}

BBCLASSEXTEND = "native nativesdk"







Re: non-existent task do_package_write_rpm error

Alexander Kanavin
 

You need to drop the -native suffix when installing to target image or SDK. -native is only for the bitbake build itself.

Alex


On Fri, 21 Jan 2022 at 20:07, W. Dobbe <winfried_mb2@...> wrote:
Hi,

I'm writing a recipe for package hardening-check .
This package builds with only a simple Makefile (that has no install target). The recipe only installs a script hardening-check in /usr/bin.

I would like to include this script in our SDK.
The recipe itself builds fine (bitbake hardening-check-native).

But when I add hardening-check-native to IMAGE_INSTALL in my image the build fails with:
Task do_populate_sdk in myimage.bb rdepends upon non-existent task do_package_write_rpm in virtual:native:(...)/recipes-devtools/hardening-check/hardening-check_2.6.bb
Same error when I append the package to TOOLCHAIN_HOST_TASK instead.

Any idea how to solve this? Do I need to inherit my recipe from something?
Recipe included below.

Thanks in advance for the help!

regards,
Winfried


SUMMARY = "Script to check an executable for certain security weaknesses."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://debian/copyright;md5=06ff97d53f05a9b8ce2a416b30f496b9"

SRC_URI = "http://ftp.debian.org/debian/pool/main/h/hardening-wrapper/hardening-wrapper_${PV}.tar.xz \
          file://0001-perl_regex.patch \
         "
SRC_URI[md5sum] = "47c93c05b4d0199be8df0d35dbd68192"
SRC_URI[sha256sum] = "c5fc46439646d0929a0605e4f3db67e57eefbbf5ceec5a2888440dbdf4450224"

RDEPENDS_${PN} = "perl"

S = "${WORKDIR}/hardening-wrapper"

do_patch () {
   cd ${S}
   patch -p1 -u -i ${WORKDIR}/0001-perl_regex.patch
}

do_configure () {
       # Specify any needed configure commands here
       :
}

do_compile () {
       export DEB_HOST_ARCH=`uname -m`
       export DEB_HOST_ARCH_OS=`uname -s`
       oe_runmake
}

do_install () {
   install -d ${D}/${bindir}
   install -m 755 ${S}/build-tree/hardening-check ${D}/${bindir}
}

BBCLASSEXTEND = "native nativesdk"




non-existent task do_package_write_rpm error

W. Dobbe
 

Hi,

I'm writing a recipe for package hardening-check .
This package builds with only a simple Makefile (that has no install target). The recipe only installs a script hardening-check in /usr/bin.

I would like to include this script in our SDK.
The recipe itself builds fine (bitbake hardening-check-native).

But when I add hardening-check-native to IMAGE_INSTALL in my image the build fails with:
Task do_populate_sdk in myimage.bb rdepends upon non-existent task do_package_write_rpm in virtual:native:(...)/recipes-devtools/hardening-check/hardening-check_2.6.bb
Same error when I append the package to TOOLCHAIN_HOST_TASK instead.

Any idea how to solve this? Do I need to inherit my recipe from something?
Recipe included below.

Thanks in advance for the help!

regards,
Winfried


SUMMARY = "Script to check an executable for certain security weaknesses."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://debian/copyright;md5=06ff97d53f05a9b8ce2a416b30f496b9"

SRC_URI = "http://ftp.debian.org/debian/pool/main/h/hardening-wrapper/hardening-wrapper_${PV}.tar.xz \
          file://0001-perl_regex.patch \
         "
SRC_URI[md5sum] = "47c93c05b4d0199be8df0d35dbd68192"
SRC_URI[sha256sum] = "c5fc46439646d0929a0605e4f3db67e57eefbbf5ceec5a2888440dbdf4450224"

RDEPENDS_${PN} = "perl"

S = "${WORKDIR}/hardening-wrapper"

do_patch () {
   cd ${S}
   patch -p1 -u -i ${WORKDIR}/0001-perl_regex.patch
}

do_configure () {
       # Specify any needed configure commands here
       :
}

do_compile () {
       export DEB_HOST_ARCH=`uname -m`
       export DEB_HOST_ARCH_OS=`uname -s`
       oe_runmake
}

do_install () {
   install -d ${D}/${bindir}
   install -m 755 ${S}/build-tree/hardening-check ${D}/${bindir}
}

BBCLASSEXTEND = "native nativesdk"


[meta-hardening][PATCH] meta-hardening: Fix override syntax

Akshay Bhat
 

Commit 352e6498a missed updating the override syntax for the
"harden" distro override.

Fixes: 352e6498a ("meta-hardening: Convert to new override syntax")

Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com>
---
.../recipes-connectivity/openssh/openssh_%.bbappend | 2 +-
.../recipes-core/base-files/base-files_%.bbappend | 2 +-
.../recipes-core/initscripts/initscripts_1.0.bbappend | 6 +++---
meta-hardening/recipes-extended/shadow/shadow_%.bbappend | 2 +-
meta-hardening/recipes-extended/sudo/sudo_%.bbappend | 4 ++--
5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta-hardening/recipes-connectivity/openssh/openssh_%.bbappend b/meta-hardening/recipes-connectivity/openssh/openssh_%.bbappend
index 17c06ed..e192d3d 100644
--- a/meta-hardening/recipes-connectivity/openssh/openssh_%.bbappend
+++ b/meta-hardening/recipes-connectivity/openssh/openssh_%.bbappend
@@ -1,4 +1,4 @@
-do_install:append_harden () {
+do_install:append:harden () {
# to hardend
sed -i -e 's:#AllowTcpForwarding yes:AllowTcpForwarding no:' ${D}${sysconfdir}/ssh/sshd_config
sed -i -e 's:ClientAliveCountMax 4:ClientAliveCountMax 2:' ${D}${sysconfdir}/ssh/sshd_config
diff --git a/meta-hardening/recipes-core/base-files/base-files_%.bbappend b/meta-hardening/recipes-core/base-files/base-files_%.bbappend
index 0f0384f..4710b49 100644
--- a/meta-hardening/recipes-core/base-files/base-files_%.bbappend
+++ b/meta-hardening/recipes-core/base-files/base-files_%.bbappend
@@ -1,4 +1,4 @@

-do_install:append_harden () {
+do_install:append:harden () {
sed -i 's/umask.*/umask 027/g' ${D}/${sysconfdir}/profile
}
diff --git a/meta-hardening/recipes-core/initscripts/initscripts_1.0.bbappend b/meta-hardening/recipes-core/initscripts/initscripts_1.0.bbappend
index b27dee9..92e364c 100644
--- a/meta-hardening/recipes-core/initscripts/initscripts_1.0.bbappend
+++ b/meta-hardening/recipes-core/initscripts/initscripts_1.0.bbappend
@@ -1,8 +1,8 @@
-FILESEXTRAPATHS:prepend_harden := "${THISDIR}/files:"
+FILESEXTRAPATHS:prepend:harden := "${THISDIR}/files:"

-SRC_URI:append_harden = " file://mountall.sh"
+SRC_URI:append:harden = " file://mountall.sh"

-do_install:append_harden() {
+do_install:append:harden() {
install -d ${D}${sysconfdir}/init.d
install -m 0755 ${WORKDIR}/mountall.sh ${D}${sysconfdir}/init.d
}
diff --git a/meta-hardening/recipes-extended/shadow/shadow_%.bbappend b/meta-hardening/recipes-extended/shadow/shadow_%.bbappend
index 3058b55..793a075 100644
--- a/meta-hardening/recipes-extended/shadow/shadow_%.bbappend
+++ b/meta-hardening/recipes-extended/shadow/shadow_%.bbappend
@@ -1,4 +1,4 @@
-do_install:append_harden () {
+do_install:append:harden () {
# to hardend
sed -i -e 's:UMASK.*:UMASK 027:' ${D}${sysconfdir}/login.defs
sed -i -e 's:PASS_MAX_DAYS.*:PASS_MAX_DAYS 365:' ${D}${sysconfdir}/login.defs
diff --git a/meta-hardening/recipes-extended/sudo/sudo_%.bbappend b/meta-hardening/recipes-extended/sudo/sudo_%.bbappend
index 97c5f49..2860e8a 100644
--- a/meta-hardening/recipes-extended/sudo/sudo_%.bbappend
+++ b/meta-hardening/recipes-extended/sudo/sudo_%.bbappend
@@ -1,6 +1,6 @@

-PACKAGECONFIG:append_harden = " pam-wheel"
-do_install:append_harden () {
+PACKAGECONFIG:append:harden = " pam-wheel"
+do_install:append:harden () {
if [ "${@bb.utils.contains('DISABLE_ROOT', 'True', 'yes', 'no', d)}" = "yes" ]; then
sed -i -e 's:root ALL=(ALL) ALL:#root ALL=(ALL) ALL:' ${D}${sysconfdir}/sudoers
fi
--
2.25.1


[meta-tensorflow][PATCH] Update SRC_URI git default protocol

Changqing Li
 

From: Changqing Li <changqing.li@windriver.com>

Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
recipes-framework/tensorflow/keras_2.6.0.bb | 2 +-
recipes-framework/tensorflow/tensorflow-estimator_2.6.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-framework/tensorflow/keras_2.6.0.bb b/recipes-framework/tensorflow/keras_2.6.0.bb
index dc1a98d..ebb668d 100644
--- a/recipes-framework/tensorflow/keras_2.6.0.bb
+++ b/recipes-framework/tensorflow/keras_2.6.0.bb
@@ -3,7 +3,7 @@ DESCRIPTION = "TensorFlow Keras is an implementation of the Keras API that\
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=c573baaa40a28002a2d03d3e7e9bc583"

-SRC_URI = "git://github.com/keras-team/keras.git;branch=r2.6 \
+SRC_URI = "git://github.com/keras-team/keras.git;branch=r2.6;protocol=https \
file://0001-customize-for-yocto.patch \
"

diff --git a/recipes-framework/tensorflow/tensorflow-estimator_2.6.bb b/recipes-framework/tensorflow/tensorflow-estimator_2.6.bb
index 910ca4d..83804af 100644
--- a/recipes-framework/tensorflow/tensorflow-estimator_2.6.bb
+++ b/recipes-framework/tensorflow/tensorflow-estimator_2.6.bb
@@ -3,7 +3,7 @@ learning programming."
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=01e86893010a1b87e69a213faa753ebd"

-SRC_URI = "git://github.com/tensorflow/estimator.git;branch=r2.6 \
+SRC_URI = "git://github.com/tensorflow/estimator.git;branch=r2.6;protocol=https \
file://0001-customize-for-yocto.patch \
"
SRCREV = "9a6c1260bbb468a013e39cf7d6f5af369cf2db2b"
--
2.17.1


[meta-anaconda][PATCH] Update SRC_URI git default branch

Changqing Li
 

From: Changqing Li <changqing.li@windriver.com>

Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
recipes-installer/python3-dasbus/python3-dasbus_1.6.bb | 2 +-
recipes-installer/python3-productmd/python3-productmd_1.21.bb | 2 +-
recipes-installer/python3-simpleline/python3-simpleline_1.3.bb | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-installer/python3-dasbus/python3-dasbus_1.6.bb b/recipes-installer/python3-dasbus/python3-dasbus_1.6.bb
index c42ab52..5b87391 100644
--- a/recipes-installer/python3-dasbus/python3-dasbus_1.6.bb
+++ b/recipes-installer/python3-dasbus/python3-dasbus_1.6.bb
@@ -4,7 +4,7 @@ SECTION = "devel"
LICENSE = "LGPLv2.1"
LIC_FILES_CHKSUM = "file://LICENSE;md5=1803fa9c2c3ce8cb06b4861d75310742"

-SRC_URI = "git://github.com/rhinstaller/dasbus.git;protocol=https;"
+SRC_URI = "git://github.com/rhinstaller/dasbus.git;protocol=https;branch=master"
SRCREV = "63b22fe4a7b2f98739279b2a4c6107eebd8d5a58"

S = "${WORKDIR}/git"
diff --git a/recipes-installer/python3-productmd/python3-productmd_1.21.bb b/recipes-installer/python3-productmd/python3-productmd_1.21.bb
index 98fd0de..8dcd434 100644
--- a/recipes-installer/python3-productmd/python3-productmd_1.21.bb
+++ b/recipes-installer/python3-productmd/python3-productmd_1.21.bb
@@ -6,7 +6,7 @@ SECTION = "devel"
LICENSE = "LGPLv2.1"
LIC_FILES_CHKSUM = "file://LICENSE;md5=768997ba510a952bef1775c50bc22b00"

-SRC_URI = "git://github.com/release-engineering/productmd;protocol=https; \
+SRC_URI = "git://github.com/release-engineering/productmd;protocol=https;branch=master \
file://add-wrlinux-version-pattern.patch \
"
SRCREV = "a8268944c8a6064697ccb4d24e52dc666ab03ed4"
diff --git a/recipes-installer/python3-simpleline/python3-simpleline_1.3.bb b/recipes-installer/python3-simpleline/python3-simpleline_1.3.bb
index dcf7e1d..651b9d0 100644
--- a/recipes-installer/python3-simpleline/python3-simpleline_1.3.bb
+++ b/recipes-installer/python3-simpleline/python3-simpleline_1.3.bb
@@ -6,7 +6,7 @@ SECTION = "devel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=5f4f48e95324081879552f19cd16c54a"

-SRC_URI = "git://github.com/rhinstaller/python-simpleline;protocol=https;"
+SRC_URI = "git://github.com/rhinstaller/python-simpleline;protocol=https;branch=master"
SRCREV = "1c21ffdeda9eed27e5ad8ec16aee467f8daecd50"
S = "${WORKDIR}/git"
inherit setuptools3
--
2.17.1


Re: Building embedded app for host machine

Randy MacLeod
 

On 2022-01-20 10:24, Mauro Ziliani via lists.yoctoproject.org wrote:
Hi all.
I have this doubt.
Is it possible the make a toolchain which can produce the same app for host machine?
I try to explain my think.
I produced an app for imx6dlsabresd with qt-5.6.2 using x86_64 as SDKMACHINE
 Can I make the same app with the same qt-5.6.2 but running directly on x86_64?
Hi,


Yes. Likely you just need to do:
$ MACHINE=qemux86-64 bitbake your-image
with the right configuration and then run it in docker. See below.



There are at least three options depending on what your goal is.

1. use qemux86-64 with kvm support
2. maybe use oe-run-native?
3. as above, build for an intel MACHINE using the linux-dummy kernel.


1. use runqemu -- you might know about this already.

This is how most testing for userspace in Yocto happens.
The default target is qemux86-64 and you boot up a fill VM
that can run graphics as well of course. See the docs or just
run:
$ runqemu help
$ runqemu kvm graphics <other options>

but you don't want the kernel overhead.


2. oe-run-native

Let's deal with the idea of building the -native recipe even though
I suspect it isn't the approach you should take.

See:

https://wiki.yoctoproject.org/wiki/Technical_FAQ#What_does_.22native.22_mean.3F
and examples in oe-core such as:

so for any recipe that inherits 'native', you can run:
$ bitbake app-native

Sometimes there problems with this aside from needing the full dependency tree
to also support -native. There are lots of examples in oe-core of -native recipes:

$ find meta -name "*native*bb" | wc -l

29


Consider quilt:
$ bitbake m4-native
...
$ bitbake quilt-native -c addto_recipe_sysroot
$ oe-run-native quilt-native quilt

Running bitbake -e quilt-native

/usr/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__

return f(*args, **kwds)

Usage: quilt [--trace[=verbose]] [--quiltrc=XX] command [-h] ...

quilt --version

Commands are:

add files import previous series

annotate fold mail push setup

...

And for 'fun' I checked that vim works too:
$ oe-run-native vim-native vim.vim

Anyway, that's just an example and it's really mainly suitable for simple command line apps in my opinion.
I doubt, but haven't checked if any of the recipes in the meta-qt5 layer support being built as -native.


3. docker

The option that makes sense to me is to specify your host system as the
target MACHINE or just use qemux86-64 and build a container image as explained here:

https://pretalx.com/media/oe-workshop-2020/submissions/AN87VC/resources/Building_Containers_with_OpenEmbedded__Cur_WqbQgmv.pdf


Reading the pdf, it seems one can just set this in conf/local.conf:

MACHINE = "qemux86-64"
IMAGE_FSTYPES = "container"
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"
IMAGE_LINGUAS:append = " en-us"

$ bitbake core-image-minimal

copy the tarball to the system where you have docker working:

laptop$ scp mybuilder:/path/to/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.tar.bz2 /tmp
laptop$ docker import /tmp/core-image-minimal-qemux86-64.tar.bz2 core-image-minimal
laptop$ docker run -it core-image-minimal /bin/sh

sh-5.1# cat /etc/os-release
ID=wrlinux
NAME="Wind River Linux development"
VERSION="10.22.03.0"
VERSION_ID=10.22.03.0
PRETTY_NAME="Wind River Linux development 22.03"


Note that I've done this in our WR Linux dev environment but it should just work for any recent Yocto distro.


You can run just one X11 app using:

laptop$ xhost + <-- lets anyone connect to your display so careful.
laptop: docker run -it --rm --privileged --net=host \
--env="DISPLAY" \
--volume="$HOME/.Xauthority:/root/.Xauthority:rw" \
wrlinux-image-std-xfce \
/usr/bin/xfce4-terminal

Careful that you don't inadvertently start a second display manager.
That could really mess up your system input and force you to have to:
$ docker ps
$ docker kill <container-id>
;-)

../Randy


Marketing: WR Linux uses this to make app containers easy:

https://docs.windriver.com/bundle/Wind_River_Linux_Open_Virtualization_Features_Guide_LTS_21/page/xvn1630019013539.html

Now i make this, building the same qt version for host machine, but outside yocto ring
[I hope to be clear, mu english is terrible]
Best regards,
  MZ

--
# Randy MacLeod
# Wind River Linux


Re: Alsa configuration error

Michael Opdenacker
 

Hi Mihir

On 1/20/22 11:28 AM, mihirdave36@gmail.com wrote:
Hi Peter,

After entering "/*aplay -l*/" I got message "/*aplay: device_list:274
: no soundcards found...*/".

I am using virtual machine: /*VMware workstation with ubuntu 20.4.3 as
a Linux host machine.*/
Running Image: */core-image-minimal/* using */runqemu /**/qemux86-64
nographic/* 

I could reproduce your issue. I believe I built the system in the same
way you did.
An issue is that the kernel is built with

CONFIG_SOUND=m
CONFIG_SND=m

...plus other sound modules, but there are no such modules in the root
filesystem (under /lib/modules/`uname -r`/kernel/). Something else
probably needs to be tweaked.

Another issue is that passing "audio" to runqemu fails:

runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: warning:
'-soundhw ac97' is deprecated, please use '-device AC97' instead
audio: warning: Using timer based audio emulation

I've just proposed a patch for this one:
https://lore.kernel.org/openembedded-core/20220120174222.1918081-1-michael.opdenacker@bootlin.com/T/#u

Don't hesitate to use it!

Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Minutes: Yocto Project Weekly Triage Meeting 1/20/2022

Trevor Gamblin
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Bruce, Diane, Jate, Joshua, Márton, Michael, Randy, Richard, Saul, Stephen, Steve, Tim, Trevor

ARs:

- Randy/Stephen to move Medium+ 3.5 unassigned bugs to M3

- Stephen to make a note about prelink for next week's status

Notes:

- ~50% of AB workers have been switched to SSDs. Still too early to determine what effect they are having on failure rates

Medium+ 3.5 Unassigned Enhancements/Bugs: 80 (Last week 78)

Medium+ 3.99 Unassigned Enhancements/Bugs: 38 (Last week 38)

AB Bugs: 76 (Last week 74)


Re: bbappend conditional check for advanced metadata (yocto-kernel-cache)?

Bruce Ashfield
 

On Thu, Jan 20, 2022 at 6:20 AM Matthias Klein
<matthias.klein@optimeas.de> wrote:

Hello,



I would like to create a linux-%.bbappend file and add the following to it, for example:



KERNEL_FEATURES:append = " features/overlayfs/overlayfs.scc".



Works also for all kernels which use the advanced metadata. Unfortunately it leads to an error with a kernel which uses a defconfig.

I would only enable the above line if the kernel uses the advanced metadata. Is this possible?
Presumably, the kernel recipe you are using inherits kernel-yocto, and
that whatever recipe is using a defconfig isn't also putting the
kernel-cache into the SRC_URI ? (or that kernel_features append
wouldn't be an actual error). So we can run with that assumption.

One option is to allow dangling kernel features, and you'll get a
warning from a the missing feature
(KERNEL_DANGLING_FEATURES_WARN_ONLY). But of course, you'll get a
warning .. which may or may not be a bad thing :)

Another is to make that append conditional based on something you can
test. i.e. test for kernel-cache in the SRC_URI, and if present, do
the append. Or you could test for the defconfig in the SRC_URI and
don't do the append. There may be other options for this, but without
all the details of the recipes, I can't say for sure.

I have a few variations of that theme in meta-virtualization, since
there's a broad range of kernel types supported
(https://git.yoctoproject.org/meta-virtualization/tree/recipes-kernel/linux/linux-yocto_virtualization.inc).

Cheers,

Bruce




Many greetings,

Matthias




--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Building embedded app for host machine

Mauro Ziliani
 

Hi all.

I have this doubt.

Is it possible the make a toolchain which can produce the same app for host machine?


I try to explain my think.


I produced an app for imx6dlsabresd with qt-5.6.2 using x86_64 as SDKMACHINE

 Can I make the same app with the same qt-5.6.2 but running directly on x86_64?


Now i make this, building the same qt version for host machine, but outside yocto ring


[I hope to be clear, mu english is terrible]


Best regards,

  MZ


Re: Installing only python .pyc files onto the image #yocto

Mike Looijmans
 

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 18-01-2022 06:29, Sam via lists.yoctoproject.org wrote:
Was wondering if there was a way to edit the distitils3.bbclass or a similar file to only install the python .pyc files onto a yocto image?
I saw something about editing the distutils-common-base.bbclass online, however, it was only mentioned and not elaborated on.
I am currently working with a setup that installs .py files, then generates the .pyc files and removes the .py files. I am now looking for a method that will only install the .pyc files.
Any help would be appreciated.
What works well in many recipes is to just move the source files into their own packages, e.g.

PACKAGES =+ "${PN}-src"
FILES_${PN}-src = "${mypythondir}/*.py"

That removes the py files from the package, but still allows you to install the sources to target if you need them...

If you don't want a "src" package, adding them to the "dbg" package also works okay.


bbappend conditional check for advanced metadata (yocto-kernel-cache)?

Matthias Klein
 

Hello,

 

I would like to create a linux-%.bbappend file and add the following to it, for example:

 

KERNEL_FEATURES:append = " features/overlayfs/overlayfs.scc".

 

Works also for all kernels which use the advanced metadata. Unfortunately it leads to an error with a kernel which uses a defconfig.

I would only enable the above line if the kernel uses the advanced metadata. Is this possible?

 

Many greetings,

Matthias

1161 - 1180 of 57064