Date   

Re: non-existent task do_package_write_rpm error

W. Dobbe <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: 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@...>
---
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 <winfried_mb2@...>
 

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 <winfried_mb2@...>
 

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@...>
---
.../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@...>

Signed-off-by: Changqing Li <changqing.li@...>
---
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@...>

Signed-off-by: Changqing Li <changqing.li@...>
---
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@... 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@...> 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@...
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


Re: Alsa configuration error

mihirdave36@...
 

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  

Thanks
Mihir


Re: Alsa configuration error

Peter Bergin
 


On 2022-01-20 07:05, mihirdave36@... wrote:
recently tried to add ALSA support to core-image-minimal . by adding following lines into local.conf: MACHINE_FEATURES+="alsa" DISTRO_FEATURES+="alsa" CORE_IMAGE_EXTRA_INSTALL+="alsa-utils" but got error of which I have attached image.
please guide me what should I do to solve it.

Check available sound cards in your system. 'aplay -L' It seems you have no suitable default one for speaker-test to use. If you have sound cards in your machine and want to point out another one that speaker-test shall use you can pass that as an argument. https://linux.die.net/man/1/speaker-test

/Peter


Alsa configuration error

mihirdave36@...
 

recently tried to add ALSA support to core-image-minimal . by adding following lines into local.conf: MACHINE_FEATURES+="alsa" DISTRO_FEATURES+="alsa" CORE_IMAGE_EXTRA_INSTALL+="alsa-utils" but got error of which I have attached image.

please guide me what should I do to solve it.

1841 - 1860 of 57741