yocto@lists.yoctoproject.org

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

Joe MacDonald

#52628

[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

signature.asc

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

Quentin Schulz

#52627

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

#52626

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

#52625

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

#52624

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

#52623

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

#52622

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

Show quoted text

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

#52621

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:

Show quoted text

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

signature.asc

Re: #yocto #sdk #yocto #sdk

Monsees, Steven C (US)

#52620

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

Show quoted text

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

#52619

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

#52618

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.

Show quoted text

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

#52617

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

#52616

Thanks a lot.

I'll do it

MZ

Show quoted text

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

#52615

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

#52614

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

#52613

Ping :)

Alex

Show quoted text

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

#52612

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

#52611

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

#52610

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

#52609

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