Date   

question about PREFERRED_RPROVIDER

John Wang
 

Hi,

There is a package with two versions, private and public.
But when I use the PREFERRED_RPROVIDER to select the public version,
bitbake still tries fetch the private one, and then bitabke terminates
because do_fetch fails (no permission)

What I expect is that when I select the public repository version, it
should not fetch the private repository, am I right?
Or, should I not use the PREFERRED_RPROVIDER to select a public/private repo ?

Could someone guide me :)


feature-public.bb

```
SRC_URI = "git://public"

RPROVIDES:${PN} += " \
virtual-feature \
"
```

feature-private.bb

```
SRC_URI= "git://private"

RPROVIDES:${PN} += " \
virtual-feature \
"
```


machine.conf

```
PREFERRED_RPROVIDER_virtual-feature = "feature-public"
```


Re: A bitbake error caused by "Variable BB_ENV_EXTRAWHITE" #bitbake

Alexander Kanavin
 

Hello,

you probably need to exit the shell and then restart it and
re-initialize your environment (with oe-init-build-env), as it
contains the obsolete variable.

Alex

On Sat, 13 Aug 2022 at 05:13, <lucky33newman@...> wrote:

Hellow everyone, this is Yan. I am new to Yocto Project, still, I am learning.

There is a question, when I bitbaked my image I found this ERROR:

yanxk@yanxk-Ubuntu:~/Yocto/poky/build$ bitbake core-image-sato
ERROR: Variable BB_ENV_EXTRAWHITE has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS
ERROR: Variable BB_ENV_EXTRAWHITE from the shell environment has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS
ERROR: Exiting to allow enviroment variables to be corrected

How can I do a quick fix, and why is it working wrong?

By the way, I check the link https://git.openembedded.org/bitbake/commit/?id=87104b6a167188921da157c7dba45938849fb22a , which most likely the main cause.

Waiting for a help.




A bitbake error caused by "Variable BB_ENV_EXTRAWHITE" #bitbake

Yan Xinkuan
 

Hellow everyone, this is Yan. I am new to Yocto Project, still, I am learning.

There is a question, when I bitbaked my image I found this ERROR:

yanxk@yanxk-Ubuntu:~/Yocto/poky/build$ bitbake core-image-sato
ERROR: Variable BB_ENV_EXTRAWHITE has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS
ERROR: Variable BB_ENV_EXTRAWHITE from the shell environment has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS
ERROR: Exiting to allow enviroment variables to be corrected

How can I do a quick fix, and why is it working wrong?

By the way, I check the link https://git.openembedded.org/bitbake/commit/?id=87104b6a167188921da157c7dba45938849fb22a , which most likely the main cause.

Waiting for a help.


Re: [meta-security][PATCH] samhain-standalone: fix buildpaths issue

Armin Kuster
 

merged

On 8/11/22 02:40, Yu, Mingli wrote:
From: Mingli Yu <mingli.yu@...>

Fixes:
WARNING: samhain-standalone-4.4.9-r0 do_package_qa: QA Issue: File /usr/share/doc/samhain-standalone/scripts/samhain.ebuild-light in package samhain-standalone-doc contains reference to TMPDIR
File /usr/share/doc/samhain-standalone/scripts/samhain.ebuild in package samhain-standalone-doc contains reference to TMPDIR [buildpaths]

Signed-off-by: Mingli Yu <mingli.yu@...>
---
.../0001-Don-t-expose-configure-args.patch | 44 +++++++++++++++++++
recipes-ids/samhain/samhain-standalone.bb | 1 +
2 files changed, 45 insertions(+)
create mode 100644 recipes-ids/samhain/files/0001-Don-t-expose-configure-args.patch

diff --git a/recipes-ids/samhain/files/0001-Don-t-expose-configure-args.patch b/recipes-ids/samhain/files/0001-Don-t-expose-configure-args.patch
new file mode 100644
index 0000000..fedbe5b
--- /dev/null
+++ b/recipes-ids/samhain/files/0001-Don-t-expose-configure-args.patch
@@ -0,0 +1,44 @@
+From 111b1e8f35e989513d8961a45a806767109f6e1e Mon Sep 17 00:00:00 2001
+From: Mingli Yu <mingli.yu@...>
+Date: Thu, 11 Aug 2022 17:15:30 +0800
+Subject: [PATCH] Don't expose configure args
+
+Don't expost configure args to fix buildpath issue.
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Mingli Yu <mingli.yu@...>
+---
+ scripts/samhain.ebuild-light.in | 2 +-
+ scripts/samhain.ebuild.in | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/scripts/samhain.ebuild-light.in b/scripts/samhain.ebuild-light.in
+index 2b09cdb..b7f7062 100644
+--- a/scripts/samhain.ebuild-light.in
++++ b/scripts/samhain.ebuild-light.in
+@@ -55,7 +55,7 @@ src_compile() {
+ # --with-state-dir=/var/lib/${PN} \
+ # --with-log-file=/var/log/${PN}.log \
+
+- ./configure ${myconf} @mydefargs@ || die
++ ./configure ${myconf} mydefargs || die
+ emake || die
+
+ echo '#!/bin/sh' > ./sstrip
+diff --git a/scripts/samhain.ebuild.in b/scripts/samhain.ebuild.in
+index 635a746..b9a42e7 100644
+--- a/scripts/samhain.ebuild.in
++++ b/scripts/samhain.ebuild.in
+@@ -55,7 +55,7 @@ src_compile() {
+ # --with-state-dir=/var/lib/${PN} \
+ # --with-log-file=/var/log/${PN}.log \
+
+- ./configure ${myconf} @mydefargs@ || die
++ ./configure ${myconf} mydefargs || die
+ emake || die
+
+ echo '#!/bin/sh' > ./sstrip
+--
+2.25.1
+
diff --git a/recipes-ids/samhain/samhain-standalone.bb b/recipes-ids/samhain/samhain-standalone.bb
index 445cb99..b832dc8 100644
--- a/recipes-ids/samhain/samhain-standalone.bb
+++ b/recipes-ids/samhain/samhain-standalone.bb
@@ -1,6 +1,7 @@
require samhain.inc
SRC_URI += "file://samhain-not-run-ptest-on-host.patch \
+ file://0001-Don-t-expose-configure-args.patch \
file://run-ptest \
"


Re: [meta-security][PATCH V2] meta-security: Add recipe for Glome

Armin Kuster
 

merged

On 8/8/22 11:40, John Broadbent via lists.yoctoproject.org wrote:
From: John Edward Broadbent <jebr@...>

Generic Low Overhead Message Exchange (GLOME) is a protocol providing
secure authentication and authorization for low dependency environments.

Signed-off-by: John Edward Broadbent <jebr@...>
---
.../packagegroup-core-security.bb | 1 +
recipes-security/glome/glome_git.bb | 24 +++++++++++++++++++
2 files changed, 25 insertions(+)
create mode 100644 recipes-security/glome/glome_git.bb

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index a12a4c2..c028c3d 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -31,6 +31,7 @@ RDEPENDS:packagegroup-security-utils = "\
ding-libs \
ecryptfs-utils \
fscryptctl \
+ glome \
keyutils \
nmap \
pinentry \
diff --git a/recipes-security/glome/glome_git.bb b/recipes-security/glome/glome_git.bb
new file mode 100644
index 0000000..12d6d5f
--- /dev/null
+++ b/recipes-security/glome/glome_git.bb
@@ -0,0 +1,24 @@
+SUMMARY = "GLOME Login Client"
+HOME_PAGE = "https://github.com/google/glome"
+DESCRIPTION = "GLOME is used to authorize serial console access to Linux machines"
+PV = "0.1+git${SRCPV}"
+
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
+
+inherit meson pkgconfig
+
+DEPENDS += "openssl"
+
+S = "${WORKDIR}/git"
+SRC_URI = "git://github.com/google/glome.git;branch=master;protocol=https"
+SRCREV = "978ad9fb165f1e382c875f2ce08a1fc4f2ddcf1b"
+
+FILES:${PN} += "${libdir}/security"
+
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[glome-cli] = "-Dglome-cli=true,-Dglome-cli=false"
+PACKAGECONFIG[pam-glome] = "-Dpam-glome=true,-Dpam-glome=false,libpam"
+
+EXTRA_OEMESON = "-Dtests=false"
+


Re: [meta-cgl][PATCH] resource-agents: Bug fix.

Jeremy Puhlman
 

Merged.

On 8/7/2022 7:22 PM, leimaohui wrote:
Fix error as the fowllowing:

resource-agents-4.5.0-r0 do_package_qa: QA Issue: lib32-resource-agents installs files in /var/volatile, but it is expected to be empty [empty-dirs]

Signed-off-by: Lei Maohui <leimaohui@...>
---
.../cluster-resource-agents/resource-agents_4.5.0.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
index 9349ab9..1da020e 100644
--- a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
+++ b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
@@ -59,8 +59,8 @@ EXTRA_OECONF += "--disable-fatal-warnings \
--with-rsctmpdir=/var/run/heartbeat/rsctmp"
do_install:append() {
- rm -rf "${D}${localstatedir}/run"
- rmdir --ignore-fail-on-non-empty "${D}${localstatedir}"
+ rm -rf ${D}${localstatedir}/run
+ rm -rf ${D}${localstatedir}
}
# tickle_tcp is published under GPLv3, we just split it into ${PN}-extra,


Unable to add .bb in a layer - newcomer to Yocto #yocto

shauli.arazi@...
 

Hi all,
I have taken on myself a task to write a custom Yocto-based image for Nvidia Xavier which poses somewhat of a difficult task.
After few videos on Youtube and some documentation, I started writing a new layer on-top of the tegra and poky layer as follows -

meta                  /home/shauli/Git/poky/meta                5
meta-poky             /home/shauli/Git/poky/meta-poky           5
meta-yocto-bsp        /home/shauli/Git/poky/meta-yocto-bsp      5
meta-tegra            /home/shauli/Git/poky/meta-tegra          5
meta-xtra             /home/shauli/Git/poky/meta-xtra           6


meta-xtra is the new layer I wrote that has a .bb file which is supposed to edit the Nvidia logo screen to a custom logo I made. Should be fairly simple.
I copied the logo .bb file from the meta-tegra to my own layer under its own folder.

meta-xtra/
├── conf
│   └── layer.conf
├── COPYING.MIT
├── README
├── recipes-core
│   └── images
│       └── xtra-l4t.bb
└── recipes-logo
    ├── xtra-bootlogo
    │   ├── bootlogo.inc
    │   ├── files
    │   │   └── xtra_logo.tar.gz
    │   └── xtra-bootlogo.bb


As can be seen above, I created a new image named xtra-l4t, a logo .bb file which, and the a regular layer.conf file which includes all the .bb files in the subfolders (same as the example).

The problem I am facing is that while building either the core-image-base or the xtra-l4t image, the .bb simply doesn't do anything. I had syntax errors in the do_compile () function which I noticed only after compiling the .bb file directly using $ bitbake xtra-bootlogo.
The $ bitbake xtra-l4t has no affect whatsoever from the .bb file.
 
I tried adding IMAGE_INSTALL:append = " xtra-bootlogo" to the xtra-l4t.bb file which lead to the following error.

ERROR: Task do_populate_sdk in /home/shauli/Git/poky/meta-xtra/recipes-core/images/xtra-l4t.bb rdepends upon non-existent task do_package_write_deb in /home/shauli/Git/poky/meta-xtra/recipes-logo/xtra-bootlogo/xtra-bootlogo.bb

I think there is something fundamental about how Yocto works which I fail to understand.

This is the logo .bb file -

do_compile() {

    LIST=""

    if [ "${@bb.utils.contains("PACKAGECONFIG", "raw", "1", "0", d)}" = "1" ]; then
        if [ ! -s "${S}/${RAW_GRAPHIC_FILE}" ]; then
            bbfatal "RAW_GRAPHIC_FILE must exist"
        fi

        cook_bitmaps "${S}/${RAW_GRAPHIC_FILE}"
    else
        if [ ! -s "${S}/${COOKED_CONFIG_FILE}" ]; then
            bbfatal "COOKED_CONFIG_FILE must exist"
        fi

        while read _line
        do
            _line="${S}/${_line}"
            LIST="${LIST}${_line};"
        done < ${S}/${COOKED_CONFIG_FILE}
    fi

    # NB that '%?' gets rid of the trailing ';' because BMP_generator blows up
    LIST="${LIST%?}"

    rm -f ${B}/bmp.blob
    rm -f ${B}/bmp-compressed.blob

    OUT=${B} ${STAGING_BINDIR_NATIVE}/${FLASHTOOLS_DIR}/BMP_generator_L4T.py -t bmp -e "${LIST}" -v 0

    if [ ! -s ${B}/bmp.blob ]; then
        bbfatal "BMP_generator_L4T.py failed to create bmp.blob"
    fi

    compress_blob "${B}/bmp.blob" "${B}/bmp-compressed.blob"

    if [ ! -s ${B}/bmp-compressed.blob ]; then
        bbfatal "failed to create compressed bmp-compressed.blob"
    fi
}

do_deploy() {
    install -d ${DEPLOYDIR}
    install -m 0644 ${B}/bmp-compressed.blob ${DEPLOYDIR}/${BMP_BLOB}
    # Should overwrite Nvidia's symlink
    ln -sf ${BMP_BLOB} ${DEPLOYDIR}/${BMP_SYMLINK}
}

PACKAGE_ARCH = "${MACHINE_ARCH}"
do_install[noexec] = "1"

addtask deploy before do_build after do_install



Any help would be very much appreciated.
Thanks,
Shauli






[meta-mingw][PATCH] Switch to HOSTTOOLS_NONFATAL

Joshua Watt
 

The changes to split classes into global vs. image specific contexts
has broken the inclusion of `wine` and `wineserver` host tools for
testing MinGW SDKs. This is because testsdk is an image specific class
and therefore it's inclusion is not detected globally and the wine host
tools are not present so the SDK tests fail.

Resolve this by using HOSTTOOLS_NONFATAL which will include the tools if
they exist, but won't fail if they are not present. This does mean that
users will now not know they need wine "up front" when doing a build,
but it will instead fail later when they actually try to test the SDK,
but there isn't really a better way to fix this.

Signed-off-by: Joshua Watt <JPEWhacker@...>
---
conf/machine-sdk/include/mingw32-common.inc | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/conf/machine-sdk/include/mingw32-common.inc b/conf/machine-sdk/include/mingw32-common.inc
index 966c63b..07b5b8f 100644
--- a/conf/machine-sdk/include/mingw32-common.inc
+++ b/conf/machine-sdk/include/mingw32-common.inc
@@ -50,5 +50,4 @@ DISABLE_STATIC:mingw32 = ""
GCCPIE:mingw32 = ""

# wine and wineserver are required to test MinGW SDKs
-HOSTTOOLS += "${@'wine wineserver' if (bb.utils.contains_any('IMAGE_CLASSES', 'testsdk', True, False, d) or any(x in (d.getVar("BBINCLUDED") or "") for x in ["testsdk.bbclass"])) else ''}"
-
+HOSTTOOLS_NONFATAL += "wine wineserver"
--
2.33.0


Re: Remvove unwanted Udev rules

Khem Raj
 

it is part of systemd recipe if your distro is based on systemd. In
that case, you can write a bbappend where you define
do_install:append() and delete it from staging area before it gets
packaged

On Wed, Aug 10, 2022 at 10:59 PM Nikhil Patil <nvpatil2736@...> wrote:

Hi team ,
Greetings for the day .
We want to remove unwanted udev rules inside yocto , so how we can do ?
eg. like to remove 70-joystick.rules (/lib/udev/rules.d/70-joystick.rules) or eliminate these permanently in which file we need to change ? and what flags we need to use to remove these ?
We stuck at these point can you please help on these .
Thanks in advance


Minutes: Yocto Project Weekly Triage Meeting 8/4/2022

sakib.sajal@...
 

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

Attendees: Steve Sakoman, Joshua Watt, Randy Macleod, Richard Purdie, Aryaman, Bruce Ashfield, Michael Opdenacker, Alexandre Belloni, Pavel Zhukov, Alexandre Belloni, Alejandro Hernandez, Paulo Neves, Satthishkumar Duraisamy

ARs:

Notes:
N/A

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

Medium+ 4.99 Unassigned Enhancements/Bugs: 43 (Last week 43)

AB Bugs: 54 (Last week 50)


meta-security build failure: suricata

Armin Kuster
 

Hello,

I am aware of a new build failure with suricata. I think it related to the glibc update.

https://errors.yoctoproject.org/Errors/Build/150774/

I will have limited time to look into this in the next few weeks.

- armin


[meta-security][PATCH] samhain-standalone: fix buildpaths issue

Yu, Mingli
 

From: Mingli Yu <mingli.yu@...>

Fixes:
WARNING: samhain-standalone-4.4.9-r0 do_package_qa: QA Issue: File /usr/share/doc/samhain-standalone/scripts/samhain.ebuild-light in package samhain-standalone-doc contains reference to TMPDIR
File /usr/share/doc/samhain-standalone/scripts/samhain.ebuild in package samhain-standalone-doc contains reference to TMPDIR [buildpaths]

Signed-off-by: Mingli Yu <mingli.yu@...>
---
.../0001-Don-t-expose-configure-args.patch | 44 +++++++++++++++++++
recipes-ids/samhain/samhain-standalone.bb | 1 +
2 files changed, 45 insertions(+)
create mode 100644 recipes-ids/samhain/files/0001-Don-t-expose-configure-args.patch

diff --git a/recipes-ids/samhain/files/0001-Don-t-expose-configure-args.patch b/recipes-ids/samhain/files/0001-Don-t-expose-configure-args.patch
new file mode 100644
index 0000000..fedbe5b
--- /dev/null
+++ b/recipes-ids/samhain/files/0001-Don-t-expose-configure-args.patch
@@ -0,0 +1,44 @@
+From 111b1e8f35e989513d8961a45a806767109f6e1e Mon Sep 17 00:00:00 2001
+From: Mingli Yu <mingli.yu@...>
+Date: Thu, 11 Aug 2022 17:15:30 +0800
+Subject: [PATCH] Don't expose configure args
+
+Don't expost configure args to fix buildpath issue.
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Mingli Yu <mingli.yu@...>
+---
+ scripts/samhain.ebuild-light.in | 2 +-
+ scripts/samhain.ebuild.in | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/scripts/samhain.ebuild-light.in b/scripts/samhain.ebuild-light.in
+index 2b09cdb..b7f7062 100644
+--- a/scripts/samhain.ebuild-light.in
++++ b/scripts/samhain.ebuild-light.in
+@@ -55,7 +55,7 @@ src_compile() {
+ # --with-state-dir=/var/lib/${PN} \
+ # --with-log-file=/var/log/${PN}.log \
+
+- ./configure ${myconf} @mydefargs@ || die
++ ./configure ${myconf} mydefargs || die
+ emake || die
+
+ echo '#!/bin/sh' > ./sstrip
+diff --git a/scripts/samhain.ebuild.in b/scripts/samhain.ebuild.in
+index 635a746..b9a42e7 100644
+--- a/scripts/samhain.ebuild.in
++++ b/scripts/samhain.ebuild.in
+@@ -55,7 +55,7 @@ src_compile() {
+ # --with-state-dir=/var/lib/${PN} \
+ # --with-log-file=/var/log/${PN}.log \
+
+- ./configure ${myconf} @mydefargs@ || die
++ ./configure ${myconf} mydefargs || die
+ emake || die
+
+ echo '#!/bin/sh' > ./sstrip
+--
+2.25.1
+
diff --git a/recipes-ids/samhain/samhain-standalone.bb b/recipes-ids/samhain/samhain-standalone.bb
index 445cb99..b832dc8 100644
--- a/recipes-ids/samhain/samhain-standalone.bb
+++ b/recipes-ids/samhain/samhain-standalone.bb
@@ -1,6 +1,7 @@
require samhain.inc

SRC_URI += "file://samhain-not-run-ptest-on-host.patch \
+ file://0001-Don-t-expose-configure-args.patch \
file://run-ptest \
"

--
2.25.1


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-4.0.3.rc1)

Teoh, Jay Shen
 

Hello all,

Intel and WR YP QA is planning for QA execution for YP build yocto-4.0.3.rc1. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. NUC 7
3. NUC 6
4. Edgerouter
5. Beaglebone

ETA for completion next Tuesday, August 16.

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Pokybuild User
Sent: Thursday, 11 August, 2022 3:11 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [qa-build-notification] QA notification for completed autobuilder
build (yocto-4.0.3.rc1)


A build flagged for QA (yocto-4.0.3.rc1) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-4.0.3.rc1


Build hash information:

bitbake: b8fd6f5d9959d27176ea016c249cf6d35ac8ba03
meta-agl: 3ff972228b08c37adf41b760c2bbc5313b90715f
meta-arm: cf9365fcec2e741c56ad88db7f3838f636e29cae
meta-aws: 4ffc63cf28ff925bb67477cbaf7e390e968b1f8e
meta-gplv2: d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
meta-intel: ef3aa3064b9bbfa19f600eafb1e7d3473f62af74
meta-mingw: a90614a6498c3345704e9611f2842eb933dc51c1
meta-openembedded: 8f2dc1023482863e2630d1b94052c41ce748b38f
meta-virtualization: 26a361a39ff5ab6fae22efbdc582f84d13330ba2
oecore: 2cafa6ed5f0aa9df5a120b6353755d56c7c7800d
poky: 387ab5f18b17c3af3e9e30dc58584641a70f359f



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...







QA notification for completed autobuilder build (yocto-4.0.3.rc1)

Pokybuild User <pokybuild@...>
 

A build flagged for QA (yocto-4.0.3.rc1) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-4.0.3.rc1


Build hash information:

bitbake: b8fd6f5d9959d27176ea016c249cf6d35ac8ba03
meta-agl: 3ff972228b08c37adf41b760c2bbc5313b90715f
meta-arm: cf9365fcec2e741c56ad88db7f3838f636e29cae
meta-aws: 4ffc63cf28ff925bb67477cbaf7e390e968b1f8e
meta-gplv2: d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
meta-intel: ef3aa3064b9bbfa19f600eafb1e7d3473f62af74
meta-mingw: a90614a6498c3345704e9611f2842eb933dc51c1
meta-openembedded: 8f2dc1023482863e2630d1b94052c41ce748b38f
meta-virtualization: 26a361a39ff5ab6fae22efbdc582f84d13330ba2
oecore: 2cafa6ed5f0aa9df5a120b6353755d56c7c7800d
poky: 387ab5f18b17c3af3e9e30dc58584641a70f359f



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...


Kirkstone Upgrade now gives RDEPENDS error with /usr/bin/python #python #kirkstone

bgctkd@...
 

Good Afternoon, 

I am updating a project from Honister to Kirkstone, Has anyone else run into an issue with python files with a  #!/usr/bin/python header throwing the (abbreviated) Error below?

This did not occur with the prior honister branch, changing to #!/usr/bin/python3 or removing the line altogether seems to resolve the issue. I would prefer to not have to expend the time and effort involved as the same codebase is used on a legacy platforms that do not use python3.

ERROR: do_package_qa: QA Issue: /sample.py contained in package requires /usr/bin/python, but no providers found in RDEPENDS? 

Thanks,

Bruce

 


Mini-Summit in Dublin: Hands on with the Yocto Project

Josef Holzmayr
 

Howdy there!

We're happy to finally announce the Yocto Project Mini-Summit taking place the day before ELC-E in Dublin!

Monday, September 12th, 2022 | 2:00 – 5:30 PM
Location: Convention Centre Dublin
Registration Cost: $25

Bring your boards, your questions, your problems, and your solutions to an interactive hands-on session with fellow Yocto Project experts and colleagues. We will be talking and coding hot topics like BSPs, layers, release migrations, security, and much more. Space is limited; snacks and beverages will be served.

How to Register: Pre-registration is required. To register for Hands-On with Yocto Project, add it to your Open Source Summit Europe registration.


See you there!
Josef on behalf of the YP Advocacy group


Re: Recipe with kernel configuration fragment

Quentin Schulz
 

Hi Maik,

On 8/10/22 17:19, Maik Vermeulen wrote:
Hi,
For a firewall recipe using nftables we need to make some kernel
configuration changes.
At first we added the needed CONFIG_ lines to a bbappend in the
recipes-kernel directory of our own layer, but I think it would be neater
to include the CONFIG_ changes in the recipe that needs them, if possible.
This is not possible because recipe data is local to the recipe, you cannot impact a recipe from another one.

The only way to have 2+ recipes doing some things in sync is by having a variable set in a global scope. Such is the case for configuration files (distro and machine). Since the selection of nftables or not is not related to HW but policy, it should be in a distro configruation file.

You could add a custom DISTRO_FEATURES to your own distro and check the presence of this feature in your kernel recipe and apply the config fragment with required changes. And you can make the nftables package or whatever require this feature with REQUIRED_DISTRO_FEATURES.

Cheers,
Quentin


Recipe with kernel configuration fragment

Maik Vermeulen
 

Hi,

For a firewall recipe using nftables we need to make some kernel configuration changes.
At first we added the needed CONFIG_ lines to a bbappend in the recipes-kernel directory of our own layer, but I think it would be neater to include the CONFIG_ changes in the recipe that needs them, if possible.

So I tried:
SRC_URI = " \
    file://nftables.service \
    file://nftables.conf \
"

RDEPENDS_${PN} += " \
    nftables \
"

inherit systemd

SYSTEMD_AUTO_ENABLE = "enable"
SYSTEMD_SERVICE_${PN} = "nftables.service"

do_install_append() {
  install -d ${D}/${systemd_unitdir}/system
  install -m 0644 ${WORKDIR}/nftables.service ${D}/${systemd_unitdir}/system

  install -d ${D}/${sysconfdir}/nftables
  install -m 0644 ${WORKDIR}/nftables.conf ${D}/${sysconfdir}/nftables
}

FILES_${PN} += "${systemd_unitdir}/system/nftables.service"
FILES_${PN} += "${sysconfdir}/nftables/nftables.conf"

# Make the required changes to the kernel configuration
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

SRC_URI += " \
  file://nftables-kernel.cfg \
"

But unfortunately, the CONFIG_ changes in the nftables-kernel.cfg are not being applied..

Any hints? Thanks!

Kind regards,

Maik Vermeulen

Embedded Software Engineer — Lightyear
+31 6 16 82 73 79






Automotive Campus 70 —5708 JZ Helmond, the Netherlands

This email may contain information which is privileged and/or confidential. If you received this e-mail in error, please notify us immediately by e-mail and delete the email without copying or disclosing its contents to any other person. Lightyear is a trade name of Atlas Technologies B.V. and is registered at the Dutch Chamber of Commerce under number 67264298. 


Re: How to insure SRCREV is consistent with PV

Martin Jansa
 

Hello,

the fetch is still executed in do_fetch task (and uses MIRROR/PREMIRROR etc), maybe you mean the 2nd fetch when the tag doesn't exist in specified branch added here:
and that's executed only when needed (in case the tag WEBOS_VERSION points to was pushed to repo, before the branch was created - at least that was the case almost 10 years ago, there is longer history in old openwebos/meta-webos repo:

Cheers,

On Wed, Aug 10, 2022 at 4:16 PM Philippe Midol-Monnet <philippe.midol-monnet@...> wrote:
Hello

Thanks for your answer.

Reading your code, I wonder why you need to do a fetch, it looks very resource consuming.

Philippe

On Tue, 9 Aug 2022 at 11:27, Martin Jansa <martin.jansa@...> wrote:
In webOS we use do_unpack postinst which checks that the SRCREV matches with the expected tag name and that the tag is annotated, see

Then for our own components (mostly using CMake) we also pass the version from the recipe into CMake:
which is then compared with the version inside the component source during the build:
so you cannot claim different version even if you tag matches it.

It's a bit more complicated, because we use WEBOS_VERSION variable which is then split into PV (VERSION + SUBMISSION) and SRCREV,
but with enforced consistency across all our components this worked quite well.

Cheers,

On Tue, Aug 9, 2022 at 11:00 AM Philippe Midol-Monnet <philippe.midol-monnet@...> wrote:
Hi

Since the last version of bibake it looks like SRCREV must be set with a SHA1 in order to fetch source from a git repository. We previously set it with a tag corresponding to PV.
Manually retrieving the sha1 of the commit of a tag can easily lead to mistakes.

Is there a way to ensure that the SRCREV is consistent with  PV?

Regards

Philippe




#kirkstone qemu #kirkstone

Monsees, Steven C (US)
 

 

Hello:

 

I built kirkstone core-image-sato from scratch no modifications, clean build was going test kirkstone out…

When I went to run using qemu I saw the following issue with “tun”, even after a manual tun config I still got another qemu error (see below):

 

(1)    Is this a known issue and how would I build in proper “tun” support for the core-image-sato/qemu  ?

(2)    How would I run “runqemu-gen-tapdevs” to manually create one for testing ?

 

[yocto_user@9d7e1015e117 poky-kirkstone-4.0.2]$ ls

bitbake        kirkstone2            MAINTAINERS.md  meta-poky       oe-init-build-env   README.poky.md

contrib        LICENSE               Makefile        meta-selftest   README.hardware.md  README.qemu.md

documentation  LICENSE.GPL-2.0-only  MEMORIAM        meta-skeleton   README.md           scripts

kirkstone1     LICENSE.MIT           meta            meta-yocto-bsp  README.OE-Core.md

[yocto_user@9d7e1015e117 poky-kirkstone-4.0.2]$ source oe-init-build-env kirkstone2

You had no conf/bblayers.conf file. This configuration file has therefore been

created for you with some default values. To add additional metadata layers

into your configuration please add entries to conf/bblayers.conf.

 

The Yocto Project has extensive documentation about OE including a reference

manual which can be found at:

    https://docs.yoctoproject.org

 

For more information about OpenEmbedded see the website:

    https://www.openembedded.org/

 

 

### Shell environment set up for builds. ###

 

You can now run 'bitbake <target>'

 

Common targets are:

    core-image-minimal

    core-image-full-cmdline

    core-image-sato

    core-image-weston

    meta-toolchain

    meta-ide-support

 

You can also run generated qemu images with a command like 'runqemu qemux86'

 

Other commonly useful commands are:

- 'devtool' and 'recipetool' handle common recipe tasks

- 'bitbake-layers' handles common layer tasks

- 'oe-pkgdata-util' handles common target package tasks

[yocto_user@9d7e1015e117 kirkstone2]$ bitbake -k core-image-sato

Loading cache: 100% |                                                                                       | ETA:  --:--:--

Loaded 0 entries from dependency cache.

Parsing recipes: 100% |######################################################################################| Time: 0:00:49

Parsing of 882 .bb files complete (0 cached, 882 parsed). 1641 targets, 44 skipped, 0 masked, 0 errors.

NOTE: Resolving any missing task queue dependencies

 

Build Configuration:

BB_VERSION           = "2.0.0"

BUILD_SYS            = "x86_64-linux"

NATIVELSBSTRING      = "centos-7"

TARGET_SYS           = "x86_64-poky-linux"

MACHINE              = "qemux86-64"

DISTRO               = "poky"

DISTRO_VERSION       = "4.0.2"

TUNE_FEATURES        = "m64 core2"

TARGET_FPU           = ""

meta                

meta-poky           

meta-yocto-bsp       = "<unknown>:<unknown>"

 

Initialising tasks: 100% |###################################################################################| Time: 0:00:05

Sstate summary: Wanted 2730 Local 2722 Mirrors 5 Missed 3 Current 0 (99% match, 0% complete)

NOTE: Executing Tasks

NOTE: Tasks Summary: Attempted 6556 tasks of which 6543 didn't need to be rerun and all succeeded.

[yocto_user@9d7e1015e117 kirkstone2]$ runqemu qemux86-64

runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...

runqemu - ERROR - TUN control device /dev/net/tun is unavailable; you may need to enable TUN (e.g. sudo modprobe tun)

runqemu - INFO - Cleaning up

[yocto_user@9d7e1015e117 kirkstone2]$ lsmod |grep tun

tun                    36164  0

[yocto_user@9d7e1015e117 kirkstone2]$ sudo modprobe tun

[sudo] password :

[yocto_user@9d7e1015e117 kirkstone2]$ lsmod |grep tun

tun                    36164  0

[yocto_user@9d7e1015e117 kirkstone2]$ ls /dev

console  core  fd  full  mqueue  null  ptmx  pts  random  shm  stderr  stdin  stdout  tty  urandom  zero

[yocto_user@9d7e1015e117 kirkstone2]$ mkdir -p /dev/net

mkdir: cannot create directory ‘/dev/net’: Permission denied

[yocto_user@9d7e1015e117 kirkstone2]$ sudo mkdir -p /dev/net

[yocto_user@9d7e1015e117 kirkstone2]$ ls /dev

console  core  fd  full  mqueue  net  null  ptmx  pts  random  shm  stderr  stdin  stdout  tty  urandom  zero

[yocto_user@9d7e1015e117 kirkstone2]$ sudo mknod /dev/net/tun c 10 200

[yocto_user@9d7e1015e117 kirkstone2]$ sudo chmod 0666 /dev/net/tun

[yocto_user@9d7e1015e117 kirkstone2]$ ls -l /dev/net/tun

crw-rw-rw-. 1 root root 10, 200 Aug 10 14:10 /dev/net/tun

[yocto_user@9d7e1015e117 kirkstone2]$ runqemu qemux86-64

runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...

runqemu - INFO - Continuing with the following parameters:

KERNEL: [/disk0/scratch/yocto_user/yocto/workspace_zeus/poky-kirkstone-4.0.2/kirkstone2/tmp/deploy/images/qemux86-64/bzImage--5.15.44+git0+947149960e_eb3df10e3f-r0-qemux86-64-20220809161004.bin]

MACHINE: [qemux86-64]

FSTYPE: [ext4]

ROOTFS: [/disk0/scratch/yocto_user/yocto/workspace_zeus/poky-kirkstone-4.0.2/kirkstone2/tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64-20220810140132.rootfs.ext4]

CONFFILE: [/disk0/scratch/yocto_user/yocto/workspace_zeus/poky-kirkstone-4.0.2/kirkstone2/tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64-20220810140132.qemuboot.conf]

 

runqemu - INFO - Setting up tap interface under sudo

runqemu - ERROR - Setting up tap device failed:

Command '('sudo', '/disk0/scratch/yocto_user/yocto/workspace_zeus/poky-kirkstone-4.0.2/scripts/runqemu-ifup', '1000', '1000', '/disk0/scratch/yocto_user/yocto/workspace_zeus/poky-kirkstone-4.0.2/kirkstone2/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin')' returned non-zero exit status 1.

Run runqemu-gen-tapdevs to manually create one.

runqemu - INFO - Cleaning up

[yocto_user@9d7e1015e117 kirkstone2]$

 

Thanks,

Steve

1 - 20 of 57785