Date   

Re: [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config

Joe MacDonald
 

[Re: [yocto] [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config] On 21.03.09 (Tue 14:53) Anatol Belski wrote:

Hi Joe,

thanks for the quick check. The patch applies fine to dunfell and
gatesgarth, master has the changed recipe version in the bb name. I was
about to rebase to master but pulling shows already did it. I was too slow
:) thanks for the quick fix.
No problem! I assumed you were working on a just-slightly-out-of-date
master branch and my work tree already had your patch half applied when
the 'git am' failed, so I just finished that part up.

I'll get to the other branches in a bit.

-Joe.


Regards

Anatol

On 3/9/2021 2:00 PM, Joe MacDonald wrote:
Hi Anatol,

I will confirm this against the other branches (dunfell and gatesgarth)
but your patch doesn't appear to be against the current master branch (and
it's unlikely one patch will apply to all branches). Can you send out
specific patches against the head of tree for each branch you care about,
please? Then I can get them merged for you.

Thanks,
-Joe.

[[yocto] [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config] On 21.03.09 (Tue 11:55) Anatol Belski wrote:

This fixes the error below:

gcc: error: unrecognized command line option
‘-fmacro-prefix-map=/path/to/build/libselinux-python/3.0-r0=/usr/src/debug/libselinux-python/3.0-r0’

Without inheriting the config, supposedly a wrong compiler is used.

Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
---
recipes-security/selinux/libselinux-python_3.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-security/selinux/libselinux-python_3.0.bb b/recipes-security/selinux/libselinux-python_3.0.bb
index 2b5438d..3c03df1 100644
--- a/recipes-security/selinux/libselinux-python_3.0.bb
+++ b/recipes-security/selinux/libselinux-python_3.0.bb
@@ -4,6 +4,8 @@ SRC_URI = "https://github.com/SELinuxProject/selinux/releases/download/${SELINUX
require ${BPN}.inc
+inherit python3targetconfig
+
LIC_FILES_CHKSUM = "file://LICENSE;md5=84b4d2c6ef954a2d4081e775a270d0d0"
SRC_URI[md5sum] = "b387a66f087b6d97713570e85ec89d89"
--
2.17.1


--
-Joe MacDonald.
:wq


Re: how often would one use "VAR_someoverride_append = ..."?

Quentin Schulz
 

Hi Leon,

On Tue, Mar 09, 2021 at 03:55:03PM +0100, Leon Woestenberg wrote:
Hello Robert, all,

On Tue, Mar 9, 2021 at 3:39 PM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
is there an actual practical usage of, say:

VAR_x86_append = "huh"
$grep -re '[A-Z_]\+_[a-z0-9]\+_append' poky/meta*
poky/meta/recipes-support/gmp/gmp_6.2.0.bb:EXTRA_OECONF_mipsarchr6_append
= " --disable-assembly"
poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb:IMAGE_CMD_ext4_append
() {
poky/meta/recipes-devtools/python/python3_3.8.2.bb:RDEPENDS_libpython3_append_libc-glibc
= " libgcc"
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdb_append_linux
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdb_append_linux-gnueabi
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdbserver_append_linux
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdbserver_append_linux-gnueabi
= " glibc-thread-db "

which is appending an override variable conditionally with another
override condition. (If I put this correctly.) Is this a valid use
case where += would not work?
Define what you mean by "where += would not work", I'm not sure to have
enough context to answer this question.

gdb/gdbserver above would be replaced with ${PN} in many/most recipes.
I am not sure how ${PN} "overrides" are handled but that would be a
valid use case for VAR_foo_append.

I think Robert and I were talking about foo being part of OVERRIDES
variable meaning we (I at least) oversaw this, thanks for the heads up.

Other appearances without an override condition:
$ grep -re '[A-Z_]\+_[a-z0-9]\+_append' meta-*
meta-openembedded/<..>/libnma_1.8.28.bb:EXTRA_OEMESON_mipsarchn32_append
= " -Dvapi=false"
meta-openembedded/<..>/libnma_1.8.28.bb:EXTRA_OEMESON_riscv32_append =
" -Dvapi=false"

Could these have been replaced with the following?

EXTRA_OEMESON_mipsarchn32 += "-Dvapi=false"
EXTRA_OEMESON_riscv32 += "-Dvapi=false"
Considering there are no EXTRA_OEMESON_mipsarchn32 in any of the classes
included and that EXTRA_OEMESON expects a space-separated list of
strings, it'd probably be ok.

However, this seems fishy... It is possible that this is a mistake and
one should have written EXTRA_OEMESON_append_mipsarchn32...

If EXTRA_OEMESON was intended to be overwritten completly for
mipsarchn32 to disable gobject-introspection, having
GI_DATA_ENABLED_mipsarchn32 = "False" and
EXTRA_OEMESON_append_mipsarchn32 = " -Dvapi=false" would be more
suitable.

If I were you, I would ask on the ML if it was intended and adding the
committer in Cc :)

Quentin


Re: how often would one use "VAR_someoverride_append = ..."?

Leon Woestenberg
 

Hello Robert, all,

On Tue, Mar 9, 2021 at 3:39 PM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
is there an actual practical usage of, say:

VAR_x86_append = "huh"
$grep -re '[A-Z_]\+_[a-z0-9]\+_append' poky/meta*
poky/meta/recipes-support/gmp/gmp_6.2.0.bb:EXTRA_OECONF_mipsarchr6_append
= " --disable-assembly"
poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb:IMAGE_CMD_ext4_append
() {
poky/meta/recipes-devtools/python/python3_3.8.2.bb:RDEPENDS_libpython3_append_libc-glibc
= " libgcc"
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdb_append_linux
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdb_append_linux-gnueabi
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdbserver_append_linux
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdbserver_append_linux-gnueabi
= " glibc-thread-db "

which is appending an override variable conditionally with another
override condition. (If I put this correctly.) Is this a valid use
case where += would not work?

Other appearances without an override condition:
$ grep -re '[A-Z_]\+_[a-z0-9]\+_append' meta-*
meta-openembedded/<..>/libnma_1.8.28.bb:EXTRA_OEMESON_mipsarchn32_append
= " -Dvapi=false"
meta-openembedded/<..>/libnma_1.8.28.bb:EXTRA_OEMESON_riscv32_append =
" -Dvapi=false"

Could these have been replaced with the following?

EXTRA_OEMESON_mipsarchn32 += "-Dvapi=false"
EXTRA_OEMESON_riscv32 += "-Dvapi=false"

Seems like a good test case indeed.

Regards,

Leon.


Re: how often would one use "VAR_someoverride_append = ..."?

Robert P. J. Day
 

On Tue, 9 Mar 2021, Quentin Schulz wrote:

Hi Robert,

On Tue, Mar 09, 2021 at 09:39:14AM -0500, Robert P. J. Day wrote:

bitbake manual, chapter 3, examples of conditional syntax:

https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#examples

correctly distinguishes between A_foo_append and A_append_foo, but how
often would one use that first form, anyway?

most uses of conditional appending are either just straight
appending:

VAR_append = "fubar"

or used with an override thusly:

VAR_append_x86 = "snafu"

is there an actual practical usage of, say:

VAR_x86_append = "huh"

i can't remember the last time i saw something of that form and,
while it might be worth explaining, it seems that the reader might be
warned that that form is almost certainly *not* what they want.
Yes, in 99% of the cases, you want VAR_append_foo and not
VAR_foo_append.

VAR_foo_append makes sense when you want to append to VAR_foo which
is a way to override completely VAR for builds matching the foo
override. This happens in kernel-yocto recipes where branches and
defconfigs are different per machine for example.

The sneaky thing about VAR_foo_append is that it creates VAR_foo
even if it didn't exist beforehand, meaning you though you
*appended* something to VAR while you actually replaced VAR entirely
with what VAR_foo_append is set too.
i remember testing this a few years back, and making sure i
appreciated the subtleties. i might take a shot at rewriting that
section, since i think it has potential for confusion. mostly, warning
the reader that the first form is almost always what they want.

rday


Re: how often would one use "VAR_someoverride_append = ..."?

Quentin Schulz
 

Hi Robert,

On Tue, Mar 09, 2021 at 09:39:14AM -0500, Robert P. J. Day wrote:

bitbake manual, chapter 3, examples of conditional syntax:

https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#examples

correctly distinguishes between A_foo_append and A_append_foo, but how
often would one use that first form, anyway?

most uses of conditional appending are either just straight
appending:

VAR_append = "fubar"

or used with an override thusly:

VAR_append_x86 = "snafu"

is there an actual practical usage of, say:

VAR_x86_append = "huh"

i can't remember the last time i saw something of that form and,
while it might be worth explaining, it seems that the reader might be
warned that that form is almost certainly *not* what they want.
Yes, in 99% of the cases, you want VAR_append_foo and not VAR_foo_append.

VAR_foo_append makes sense when you want to append to VAR_foo which is a
way to override completely VAR for builds matching the foo override.
This happens in kernel-yocto recipes where branches and defconfigs are
different per machine for example.

The sneaky thing about VAR_foo_append is that it creates VAR_foo even if
it didn't exist beforehand, meaning you though you *appended* something
to VAR while you actually replaced VAR entirely with what VAR_foo_append
is set too.

Quentin


how often would one use "VAR_someoverride_append = ..."?

Robert P. J. Day
 

bitbake manual, chapter 3, examples of conditional syntax:

https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#examples

correctly distinguishes between A_foo_append and A_append_foo, but how
often would one use that first form, anyway?

most uses of conditional appending are either just straight
appending:

VAR_append = "fubar"

or used with an override thusly:

VAR_append_x86 = "snafu"

is there an actual practical usage of, say:

VAR_x86_append = "huh"

i can't remember the last time i saw something of that form and,
while it might be worth explaining, it seems that the reader might be
warned that that form is almost certainly *not* what they want.

thoughts?

rday


Re: [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config

Anatol Belski
 

Hi Joe,

thanks for the quick check. The patch applies fine to dunfell and gatesgarth, master has the changed recipe version in the bb name. I was about to rebase to master but pulling shows already did it. I was too slow :) thanks for the quick fix.

Regards

Anatol

On 3/9/2021 2:00 PM, Joe MacDonald wrote:
Hi Anatol,

I will confirm this against the other branches (dunfell and gatesgarth)
but your patch doesn't appear to be against the current master branch (and
it's unlikely one patch will apply to all branches). Can you send out
specific patches against the head of tree for each branch you care about,
please? Then I can get them merged for you.

Thanks,
-Joe.

[[yocto] [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config] On 21.03.09 (Tue 11:55) Anatol Belski wrote:

This fixes the error below:

gcc: error: unrecognized command line option
‘-fmacro-prefix-map=/path/to/build/libselinux-python/3.0-r0=/usr/src/debug/libselinux-python/3.0-r0’

Without inheriting the config, supposedly a wrong compiler is used.

Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
---
recipes-security/selinux/libselinux-python_3.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-security/selinux/libselinux-python_3.0.bb b/recipes-security/selinux/libselinux-python_3.0.bb
index 2b5438d..3c03df1 100644
--- a/recipes-security/selinux/libselinux-python_3.0.bb
+++ b/recipes-security/selinux/libselinux-python_3.0.bb
@@ -4,6 +4,8 @@ SRC_URI = "https://github.com/SELinuxProject/selinux/releases/download/${SELINUX
require ${BPN}.inc
+inherit python3targetconfig
+
LIC_FILES_CHKSUM = "file://LICENSE;md5=84b4d2c6ef954a2d4081e775a270d0d0"
SRC_URI[md5sum] = "b387a66f087b6d97713570e85ec89d89"
--
2.17.1


Re: [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config

Joe MacDonald
 

Hi Anatol,

I will confirm this against the other branches (dunfell and gatesgarth)
but your patch doesn't appear to be against the current master branch (and
it's unlikely one patch will apply to all branches). Can you send out
specific patches against the head of tree for each branch you care about,
please? Then I can get them merged for you.

Thanks,
-Joe.

[[yocto] [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config] On 21.03.09 (Tue 11:55) Anatol Belski wrote:

This fixes the error below:

gcc: error: unrecognized command line option
‘-fmacro-prefix-map=/path/to/build/libselinux-python/3.0-r0=/usr/src/debug/libselinux-python/3.0-r0’

Without inheriting the config, supposedly a wrong compiler is used.

Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
---
recipes-security/selinux/libselinux-python_3.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-security/selinux/libselinux-python_3.0.bb b/recipes-security/selinux/libselinux-python_3.0.bb
index 2b5438d..3c03df1 100644
--- a/recipes-security/selinux/libselinux-python_3.0.bb
+++ b/recipes-security/selinux/libselinux-python_3.0.bb
@@ -4,6 +4,8 @@ SRC_URI = "https://github.com/SELinuxProject/selinux/releases/download/${SELINUX

require ${BPN}.inc

+inherit python3targetconfig
+
LIC_FILES_CHKSUM = "file://LICENSE;md5=84b4d2c6ef954a2d4081e775a270d0d0"

SRC_URI[md5sum] = "b387a66f087b6d97713570e85ec89d89"
--
2.17.1


--
-Joe MacDonald.
:wq


Re: #yocto #sdk #yocto #sdk

Monsees, Steven C (US)
 

 

What is the difference between using “SIGGEN_UNLOCKED_RECIPES +=” and “BB_HASHBASE_WHITELIST_append =” ?

 

 

From: Khem Raj <raj.khem@...>
Sent: Thursday, March 4, 2021 1:22 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #sdk

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

right, the change seems to be happening in task checksums and that happens if some of bitbake variables change when SDK is built built and when it is being installed ( when it will run parse again ) perhaps the workspace under the hood is still accessible and you can use bitbake-diffsigs to narrow it down the variable that is changing

 

On Thu, Mar 4, 2021 at 9:38 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

I am seeing similar issues on line  for my eSDK install issue, but no resolutions…

 

Can someone advise on best course of action to debug this ?

 

11:10 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/deploy/sdk> ./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y

Extracting SDK..............................................................................done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100% |##########################################################################################| Time: 0:01:36

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

Checking sstate mirror object availability: 100% |###############################################################| Time: 0:00:02

WARNING: The efitools:do_compile sig is computed to be 5851605e22907038837428950427053e22ea655641a08b5dafa39d6d6e1c5e15, but the sig is locked to b81a26e3591c71acd3d22212bfdb70a15a0df49af72e7634e6a39851f16e18b5 in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_install sig is computed to be 13a65b26dfff91f2432a8064d98003559eafffa214d81c3c6ea112c2dfba0391, but the sig is locked to 2058fc9032b0e7f5c1ea358de4fa8d25ccec7204b73ebc636e79222d8cc00469 in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_compile sig is computed to be ac0c5c19cdbe7484046657ccb7b768c02fbbabb43166befa93b71a85d5fcf55b, but the sig is locked to cf5c3f72489f447b1199aafe4b4148988ff91cecd970422352f2238afb127683 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi-native:do_clean_grub sig is computed to be 4e16b100c32e9428126eb10864508038527cec795c5e4391208d96a55735c90a, but the sig is locked to a2bd26be0297624af53d6f8cf657d79740fb229db821c446d564c5ee9dc80ea3 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_compile sig is computed to be 630cc346f7ececf98c54f9134e8fee546e85c92f1e3c6ac3c258a1cdf24d4565, but the sig is locked to 802bba0874ce26169a9e16dcdb440795e8fa904977b036d637d6c4086ce72de8 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi:do_clean_grub sig is computed to be faf0ae3c9159ef3ebb13d2521ecf51dfeeac0c2c47691cd0aaa80de91187af3c, but the sig is locked to 0075bbd34297bfbc62685ff5477feec11d0dd2bcda6787a151cfb7927a7f39c2 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_compile sig is computed to be 30c09f3e8db4059b7e1ff23823f208be94d0e622904fc43eda497027be095a71, but the sig is locked to a9e8ddd9ecac11e67c66d9fccbabe23b6eb4a19c5996baef8ff960dfcdc898ed in SIGGEN_LOCKEDSIGS_t-corei7-64

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/db/db_5.3.28.bb:do_populate_sysroot, unihash dcfb179ae99ac73583d33eec1357ff5d06fb58f160e5d7285061b6e1c9c3a9c0, taskhash dcfb179ae99ac73583d33eec1357ff5d06fb58f160e5d7285061b6e1c9c3a9c0

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-extended/sed/sed_4.2.2.bb:do_package_write_ipk, unihash a37dc1cc0064749d1f6de69d0a9b8eab9ff6ef4089eff28a76e1851f8f8f8fe3, taskhash a37dc1cc0064749d1f6de69d0a9b8eab9ff6ef4089eff28a76e1851f8f8f8fe3

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/libatomic-ops/libatomic-ops_7.6.10.bb:do_package_qa, unihash 2b17b70b3e1568840e3b39488b9e6470c89d5ffd502f02b2c129331d7609add8, taskhash 2b17b70b3e1568840e3b39488b9e6470c89d5ffd502f02b2c129331d7609add8

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-connectivity/openssh/openssh_8.0p1.bb:do_package_qa, unihash 87a24567344a646de9ab6fba50b398e41711ff4d1bca749ebe02d84359c2a155, taskhash 87a24567344a646de9ab6fba50b398e41711ff4d1bca749ebe02d84359c2a155

.

.

 

 

https://www.mail-archive.com/search?l=yocto@...&q=subject:%22Re%5C%3A+%5C%5Byocto%5C%5D+eSDK+install+script+failure%22&o=newest&f=1

 

https://www.yoctoproject.org/pipermail/yocto/2017-August/037359.html

 

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12344

 

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Thursday, March 4, 2021 8:13 AM
To: Monsees, Steven C (US) <steven.monsees@...>; yocto@...
Subject: Re: [yocto] #yocto #sdk

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

 

Is there a list of certain classes that might interfere with the ability of the eSDK to lock down the configuratiuon ?
 
Thanks,
Steve

 

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, March 2, 2021 3:26 PM
To: yocto@...
Subject: [yocto] #yocto #sdk

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

I still appear to be having an issue with the SXT SDK install…

 

Building for zeus/x86_64 Intel based platform…

I build my kernel image clean, fully functional…

Standard SDK builds clean and appears functional…

 

Ext SDK builds clean, but on install I am still seeing Error below…

 

(1)    What is it comparing  between unhash/task hash ?, more sig issues ?

 

(2)    What is meant by “This is usually due to missing setscene tasks” ?

 

(3)    In the local.conf under the SDK they set :

 

SSTATE_MIRRORS += " file://universal/(.*) file://universal-4.9/\1 file://universal-4.9/(.*) file://universal-4.8/\1"

 

Under sdk-extra.conf I set :

 

SSTATE_MIRRORS += file://.* file:///ede/tms/yocto/zeus/sstate_cache/PATH

 

My SSTATE_MIRRIOR is based off the clean builds I mentioned above, is this the correct procedure ?

 

I am trying to figure out how best to debug this issue, it is occurring on the post install, and everything pretty much appears in place.

 

Steve

 

14:43 smonsees@yix490038 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/deploy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y

Extracting SDK..............................................................................done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100% |###########################################################################################| Time: 0:01:32

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

Checking sstate mirror object availability: 100% |################################################################| Time: 0:00:03

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/liburcu/liburcu_0.11.1.bb:do_populate_sysroot, unihash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601, taskhash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-devtools/python/python3_3.7.8.bb:do_packagedata, unihash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f, taskhash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f

.

.

.

 

This is usually due to missing setscene tasks. Those missing in this build were:

 

<<appears to list every recipe under ./testSDK/layers directory here>>



[meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config

Anatol Belski
 

This fixes the error below:

gcc: error: unrecognized command line option
‘-fmacro-prefix-map=/path/to/build/libselinux-python/3.0-r0=/usr/src/debug/libselinux-python/3.0-r0’

Without inheriting the config, supposedly a wrong compiler is used.

Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
---
recipes-security/selinux/libselinux-python_3.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-security/selinux/libselinux-python_3.0.bb b/recipes-security/selinux/libselinux-python_3.0.bb
index 2b5438d..3c03df1 100644
--- a/recipes-security/selinux/libselinux-python_3.0.bb
+++ b/recipes-security/selinux/libselinux-python_3.0.bb
@@ -4,6 +4,8 @@ SRC_URI = "https://github.com/SELinuxProject/selinux/releases/download/${SELINUX

require ${BPN}.inc

+inherit python3targetconfig
+
LIC_FILES_CHKSUM = "file://LICENSE;md5=84b4d2c6ef954a2d4081e775a270d0d0"

SRC_URI[md5sum] = "b387a66f087b6d97713570e85ec89d89"
--
2.17.1


Re: Swap management: vm.swappiness best values?

Laurent Gauthier
 

Ciao Mauro,

Sounds more like a pure Linux/UNIX question than a yocto one :-)

As you most likely know on an embedded system which uses permanent storage (NAND flash or eMMC) that is subject to wear it is important to completely turn off swap.

At runtime if the system is up and running then you should issue the "swapoff -a" command.

But the proper fix is to remove any entry from your /etc/fstab designating a swap partition.

However I would be surprised if you had a swap partition configured in your system as most embedded systems don't have one.

Instead what I am thinking is that you are likely seeing a system slow-down due to your system's memory usage coming close to 100% of the available RAM, which in turn causes all calls to memory allocation functions to slow down (algorithms have to look harder to find available memory).

I would suggest that when the issue occurs that you first check the current system memory usage and have a look at which application is using the most memory and figure out if there is a way to optimize it and reduce the memory usage.

Kind regards, Laurent.


On Tue, Mar 9, 2021 at 10:03 AM Mauro Ziliani <mauro@...> wrote:
Hi all.
I'm working with Krogoth on a imx6dl board with 1GB of RAM.
I don't setup the swap space, but sometimes I see that kswap0 task starts, and the board slow down.

I'd like to change  the value of vm.swappiness to avoid swap requests

The default value  of vm.swappiness is 60.

There is a minimum value for vm.swappiness?

Best regards,
   MZ





--
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
https://soccasys.com


Swap management: vm.swappiness best values?

Mauro Ziliani
 

Hi all.
I'm working with Krogoth on a imx6dl board with 1GB of RAM.
I don't setup the swap space, but sometimes I see that kswap0 task starts, and the board slow down.

I'd like to change  the value of vm.swappiness to avoid swap requests

The default value  of vm.swappiness is 60.

There is a minimum value for vm.swappiness?

Best regards,
   MZ


Re: Remove *-dev packages from final image

Mauro Ziliani
 

Thanks a lot.
I'll do it

MZ


On mar 8 2021, at 7:39 pm, Khem Raj <raj.khem@...> wrote:


On 3/8/21 3:59 AM, Mauro Ziliani wrote:
> Hi all.
> I'm in trouble to remove the *-dev packages from final image.
>
> I remove dev-pkgs and dbg-pkgs from EXTRA_IMAGE_FEATURES and
> IMAGE_FEATURES with lines
>
> IMAGE_FEATURES_remove = " \
>        dbg-pkgs \
>        dev-pkgs \
> "
>
> EXTRA_IMAGE_FEATURES_remove = " \
>        dbg-pkgs \
>        dev-pkgs \
> "
>
> But *-dev persists.
>
> I suppose there is some package-group which installs *-dev
>
> In the image recipe I includes
>
> require recipes-sato/images/core-image-sato.bb
> require recipes-fsl/images/fsl-image-multimedia-full.bb
>
> and I force a remove with
>
> IMAGE_INSTALL_remove = " \
>         packagegroup-fsl-tools-gpu \
>         imx-gpu-sdk \
>         packagegroup-core-x11-sato-games \
>         attr-dev \
>         alsa-lib-dev \
>         base-file-dev \
>         connman \
> "
>
> Even if I remove alsa-lib-dev  I find it in the manifest.
>
> I'm working with a Krogoth
>
> Any idea?

you might find the dependency with bitbake -g <your-image> and
insepcting the generated dependecy files.

>
> Thanks all
>    MZ
>
>
>
>
>
>


[meta-security][PATCH] python3-fail2ban: fix building with ptest enabled

Armin Kuster
 

Use new structure for testing.

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-security/fail2ban/files/run-ptest | 2 +-
recipes-security/fail2ban/python3-fail2ban_0.11.2.bb | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/recipes-security/fail2ban/files/run-ptest b/recipes-security/fail2ban/files/run-ptest
index 9f6aebe..64d07d5 100644
--- a/recipes-security/fail2ban/files/run-ptest
+++ b/recipes-security/fail2ban/files/run-ptest
@@ -1,3 +1,3 @@
#!/bin/sh

-##PYTHON## fail2ban-testcases
+##PYTHON## bin/fail2ban-testcases
diff --git a/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb b/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
index 6767d80..b480c76 100644
--- a/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
+++ b/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
@@ -35,8 +35,9 @@ do_install_append () {

do_install_ptest_append () {
install -d ${D}${PTEST_PATH}
+ install -d ${D}${PTEST_PATH}/bin
sed -i -e 's/##PYTHON##/${PYTHON_PN}/g' ${D}${PTEST_PATH}/run-ptest
- install -D ${S}/fail2ban-testcases-all-python3 ${D}${PTEST_PATH}
+ install -D ${S}/bin/* ${D}${PTEST_PATH}/bin
}

FILES_${PN} += "/run"
--
2.17.1


Re: Remove *-dev packages from final image

Khem Raj
 

On 3/8/21 3:59 AM, Mauro Ziliani wrote:
Hi all.
I'm in trouble to remove the *-dev packages from final image.
I remove dev-pkgs and dbg-pkgs from EXTRA_IMAGE_FEATURES and IMAGE_FEATURES with lines
IMAGE_FEATURES_remove = " \
       dbg-pkgs \
       dev-pkgs \
"
EXTRA_IMAGE_FEATURES_remove = " \
       dbg-pkgs \
       dev-pkgs \
"
But *-dev persists.
I suppose there is some package-group which installs *-dev
In the image recipe I includes
require recipes-sato/images/core-image-sato.bb
require recipes-fsl/images/fsl-image-multimedia-full.bb
and I force a remove with
IMAGE_INSTALL_remove = " \
        packagegroup-fsl-tools-gpu \
        imx-gpu-sdk \
        packagegroup-core-x11-sato-games \
        attr-dev \
        alsa-lib-dev \
        base-file-dev \
        connman \
"
Even if I remove alsa-lib-dev  I find it in the manifest.
I'm working with a Krogoth
Any idea?
you might find the dependency with bitbake -g <your-image> and insepcting the generated dependecy files.

Thanks all
   MZ


Re: [PATCH yocto-autobuilder-helper] config.json: add a systemd no-x11 build

Alexander Kanavin
 

Ping :)

Alex


On Wed, 3 Mar 2021 at 14:16, Alexander Kanavin via lists.yoctoproject.org <alex.kanavin=gmail.com@...> wrote:
Particularly the weston image has now regressed twice under systemd,
so I think there should be a quality gate for it.

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
 config.json | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/config.json b/config.json
index 8025166..d6e7df8 100644
--- a/config.json
+++ b/config.json
@@ -715,8 +715,19 @@
             "SANITYTARGETS" : "core-image-full-cmdline:do_testimage core-image-weston:do_testimage",
             "extravars" : [
                 "DISTRO_FEATURES_remove = 'x11'"
-            ]
-
+            ],
+            "step1" : {
+                "shortname" : "Sysvinit weston"
+            },
+            "step2" : {
+                "shortname" : "Systemd weston",
+                "extravars" : [
+                     "TEST_SUITES_append = ' systemd'",
+                     "DISTRO_FEATURES_append = ' pam systemd'",
+                     "VIRTUAL-RUNTIME_init_manager = 'systemd'",
+                     "DISTRO_FEATURES_BACKFILL_CONSIDERED = 'sysvinit'"
+                ]
+            }
         },
         "musl-qemux86" : {
             "MACHINE" : "qemux86",
--
2.29.2





M+ & H bugs with Milestone Movements WW10

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW10 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

5389

bitbake/lib/bb/fetch2: filename too long

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

10061

Ctrl+C during BB_HASHCHECK_FUNCTION execution does not interrupt processing nicely

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

10731

bitbake --observe-only doesn't work with memres

randy.macleod@...

unassigned@...

3.3 M3

3.4 M1

 

11781

bitbake --observe-only may get KeyError

randy.macleod@...

unassigned@...

3.3 M3

3.4 M1

 

11899

broken 'bitbake --status-only' and 'bitbake -m'

randy.macleod@...

unassigned@...

3.3 M3

3.4 M1

 

12023

bitbake-layers show-layers doesn't show layer if it doesn't append itself to BBFILE_COLLECTIONS

randy.macleod@...

unassigned@...

3.3 M3

3.4 M1

 

 

 

 

3.4 M1

3.3 M4

 

12290

cross recipe kernel module dependency generation stopped working

randy.macleod@...

unassigned@...

3.3 M3

3.4 M1

 

 

 

 

3.4 M1

3.3 M4

 

12374

do_rootfs failed when len(TMPDIR) == 410

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

12367

moving or removing tmp breaks persistent bitbake server

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

12760

CMake Toolchain File Has Wrong Module Path

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

12963

nativesdk-opkg prefixes all internal paths with $SDKPATH and won't work

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13004

Automate yocto-check-layer -m option

randy.macleod@...

unassigned@...

3.3 M3

3.4 M1

 

13023

Switch to memory resident bitbake by default in 3.3

randy.macleod@...

unassigned@...

3.3 M3

3.4 M1

 

13039

fetch2: PREMIRROR and SRC_URI with type https and parameter downloadfilename yields invalid url

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13123

package.PackageTests.test_gdb_hardlink_debug failed

randy.macleod@...

randy.macleod@...

3.3 M3

3.3 M4

 

13181

persist_data sqlite database mixed with forking is irreparably broken

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13233

fetch2: try_premirror(): improve on updating repo from mirror

randy.macleod@...

unassigned@...

3.3 M3

3.4 M1

 

13236

sstate for host native packages

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13279

Make sure users/groups exist for package_write_* tasks

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13338

SDK  build fails if image contains bash

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13353

bitbake git fetcher does not honour BB_FETCH_PREMIRRORONLY

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13419

recipes that add users to groups cannot rely on other recipes creating those groups (when population from sstate happens)

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13463

test linux-yocto-rt kernels too

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13631

core-image-full-cmdline qemumips systemd boot failure

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13705

master] bitbake and hashserve.sock left behind when ^C a build

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13843

bitbake worker stuck using 100% cpu on aborted build

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13868

Python cache files get lost in packages

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13897

POSTINST_INTERCEPTS_DIR broken by undocumented POSTINST_INTERCEPTS_PATHS since thud

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13910

Intermittent host UID contamination highlighted by devtool tests

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13920

uninative tarball license compliance in ESDK

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13976

gdb8.3 do compile with musl is error

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

13998

Changing create_sdk_files doesn't rebuild buildtools-tarball

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14015

URL Arguments in MIRROR/PREMIRROR get encoded

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14023

oe-selftest doesn't work with BB_SERVER_TIMEOUT=60

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14028

Autobuilder buildtools run fails with "Qemu ended unexpectedly"

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14045

git fetcher deadlock with self-referencing sub-modules

randy.macleod@...

unassigned@...

3.3 M3

3.4 M1

 

14066

bitbake core-image-base -c populate_sdk fails when image contains bash, core-utils and package_deb is used

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14081

Not possible to get src package in image when using PACKAGE_DEBUG_SPLIT_STYLE='debug-file-directory'

randy.macleod@...

unassigned@...

3.3 M3

3.4 M1

 

14096

perl install race (pod2text)

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14090

devtool.DevtoolExtractTests.test_devtool_deploy_target selftest failure

randy.macleod@...

stacygaikovaia@...

3.3 M3

3.3 M4

 

14104

3.1.2 (not an option above) devtool finish does not copy recipe in layer

randy.macleod@...

unassigned@...

3.3 M3

3.4 M1

 

14128

qemuppc failed to shutdown

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14150

devtool: modify: fails for gstreamer1.0-plugins-good

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14151

devtool build fails for python3

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14154

yocto-check-layer fails incorrectly with kernel hash changes

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14155

yocto-check-layer fails with hash changes if license added

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14190

qa-extra2 failing on AB with dnf checksum failures

randy.macleod@...

ross@...

3.3 M3

3.3 M4

 

14196

Add integration to send data to KCIDB

randy.macleod@...

unassigned@...

3.3 M3

3.4 M1

 

14201

Bitbake server intermittent timeout

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14206

oe-selftest perl errors on rpm based distros

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14218

Recipe rebuilds can contaminate builds

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14244

util-linux script:_size ptest failure

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14246

devtool test failures: github tls timeout

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14251

core-image-sato-1.0-r0:do_testimage FAILED when starting qemu

randy.macleod@...

unassigned@...

3.3 M3

3.3 M4

 

14258

perl ptest intermittent failure

timothy.t.orling@...

timothy.t.orling@...

3.3 M4

---

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW10!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

richard.purdie@...

3

yifan.yu@...

2

randy.macleod@...

1

doug.chapman@...

1

alexandre.belloni@...

1

Grand Total

8

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.3

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW10 of who have open medium or higher bugs and enhancements against YP 3.3.   There are 38 possible work days left until the final release candidates for YP 3.3 needs to be released.

Who

Count

richard.purdie@...

30

ross@...

26

david.reyna@...

20

bluelightning@...

15

JPEWhacker@...

10

bruce.ashfield@...

9

trevor.gamblin@...

9

kai.kang@...

8

mark.morton@...

7

yifan.yu@...

6

raj.khem@...

6

chee.yang.lee@...

6

Qi.Chen@...

5

sakib.sajal@...

5

akuster808@...

5

idadelm@...

4

yi.zhao@...

4

mostthingsweb@...

3

hongxu.jia@...

3

randy.macleod@...

3

saul.wold@...

3

mingli.yu@...

3

timothy.t.orling@...

3

jeanmarie.lemetayer@...

2

limon.anibal@...

2

jaewon@...

2

stacygaikovaia@...

2

liezhi.yang@...

2

jon.mason@...

2

matthewzmd@...

2

ydirson@...

2

nicolas.dechesne@...

2

pokylinux@...

2

sangeeta.jain@...

2

alejandro@...

2

mister_rs@...

1

mhalstead@...

1

charles.davies@...

1

Martin.Jansa@...

1

anuj.mittal@...

1

mshah@...

1

kexin.hao@...

1

steve@...

1

dorindabassey@...

1

john.kaldas.enpj@...

1

shachar@...

1

matt.ranostay@...

1

kergoth@...

1

aehs29@...

1

yoctoproject@...

1

dl9pf@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 367 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 

1681 - 1700 of 54277