1. yocto@lists.yoctoproject.org
  2. Messages
   Date   
Re: How to run the recipe Go tests on Yocto

Javier Tia
 

Found the root cause. The Go UT binaries files generated by the recipes
with ptest or generated manually need to be executed with the same ld
command from the toolchain used to build them. In this case, it is the
default GNU toolchain native provided by poky.

Thanks,

▷ Javier's 🖊

On 3/2/21 5:10 PM, Javier Tia wrote:
Hi,

Is there a way to run the recipe Go tests in Yocto?

I have tried several ways (1. Manually and 2. ptest) with unsuccess.

1. Manually exporting all the toolchain variables:

GOARCH="${BUILD_GOARCH}"
CGO_ENABLED="1"
CFLAGS="${BUILD_CFLAGS}"
LDFLAGS="${BUILD_LDFLAGS}"
CGO_CFLAGS="${BUILD_CFLAGS}"
CGO_LDFLAGS="${BUILD_LDFLAGS}"
CC="${BUILD_CC}"
LD="${BUILD_LD}"

and run it with the Go test native version.


2. Using ptest, and adding to the Go recipe:

do_compile_ptest() {
${GO} test -vet off $(go_list_package_tests)
}

In both cases the error messages are like this:

fork/exec .../recipe_name/1.0-r0/go-tmp/go-build7113/b338/util.test: no
such file or directory
FAIL util 0.000s

It's happening with Yocto Zeus (v3.0.4) and Go v1.4.17


Regards,

▷ Javier's 🖊
Re: [meta-security][PATCH] ima-policy-hashed: add CGROUP2_SUPER_MAGIC fsmagic

Armin Kuster
 

merged.
Thanks,
Armin

On 3/1/21 4:35 AM, liu.ming50@... wrote:
From: Ming Liu <liu.ming50@...>

This fixes following systemd boot issues:
[ 7.455580] systemd[1]: Failed to create /init.scope control group: Permission denied
[ 7.457677] systemd[1]: Failed to allocate manager object: Permission denied
[!!!!!!] Failed to allocate manager object.
[ 7.459270] systemd[1]: Freezing execution.

Signed-off-by: Ming Liu <liu.ming50@...>
---
.../recipes-security/ima_policy_hashed/files/ima_policy_hashed | 3 +++
1 file changed, 3 insertions(+)

diff --git a/meta-integrity/recipes-security/ima_policy_hashed/files/ima_policy_hashed b/meta-integrity/recipes-security/ima_policy_hashed/files/ima_policy_hashed
index 7f89c8d..4d9e4ca 100644
--- a/meta-integrity/recipes-security/ima_policy_hashed/files/ima_policy_hashed
+++ b/meta-integrity/recipes-security/ima_policy_hashed/files/ima_policy_hashed
@@ -53,6 +53,9 @@ dont_measure fsmagic=0x43415d53
# CGROUP_SUPER_MAGIC
dont_appraise fsmagic=0x27e0eb
dont_measure fsmagic=0x27e0eb
+# CGROUP2_SUPER_MAGIC
+dont_appraise fsmagic=0x63677270
+dont_measure fsmagic=0x63677270
# EFIVARFS_MAGIC
dont_appraise fsmagic=0xde5e81e4
dont_measure fsmagic=0xde5e81e4
safe escape library for HTML

sswarnas@...
 

Hi,

Please let me know if we have recipes i can use for HTML sanitization. I want to do this sanitization in C code.

Thanks,
S
Re: #yocto #sdk #yocto #sdk

Khem Raj
 

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>>
Re: cc1 binary in final rootfs even when no reference to it

Khem Raj
 

On Thu, Mar 4, 2021 at 10:04 AM Anders Montonen <Anders.Montonen@...> wrote:

On 4.3.2021 2.06, Khem Raj wrote:
On 3/3/21 11:29 AM, Belisko Marek wrote:
On Wed, Mar 3, 2021 at 6:31 PM Khem Raj <raj.khem@...> wrote:

this file comes from cpp output package. Can you check if somehow cpp
is being pulled into your image
It turns out that cpp + cpp-symlinks is pulled by python3-pycparser.
It is really necessary to be as runtime dependency in recipe?
it a parser for C language written in python, so my initial thoughts
will be no. but there might be some dependencies on cpp, you might
have to dive a bit deeper.

I've run into this, and from memory cpp is needed if you intend to run
the parser, but since the dependency is added through
RDEPENDS_${PN}_class-target it gets installed even if you're only
running the parser on the host. I ended up removing the target
dependency due to license conflicts, and didn't encounter any problems.
right perhaps its fine to drop this and maybe add it as rsuggests or something

-anders
Re: cc1 binary in final rootfs even when no reference to it

Anders Montonen
 

On 4.3.2021 2.06, Khem Raj wrote:
On 3/3/21 11:29 AM, Belisko Marek wrote:
On Wed, Mar 3, 2021 at 6:31 PM Khem Raj <raj.khem@...> wrote:

this file comes from cpp output package. Can you check if somehow cpp
is being pulled into your image
It turns out that cpp + cpp-symlinks is pulled by python3-pycparser.
It is really necessary to be as runtime dependency in recipe?
it a parser for C language written in python, so my initial thoughts will be no. but there might be some dependencies on cpp, you might have to dive a bit deeper.

I've run into this, and from memory cpp is needed if you intend to run the parser, but since the dependency is added through RDEPENDS_${PN}_class-target it gets installed even if you're only running the parser on the host. I ended up removing the target dependency due to license conflicts, and didn't encounter any problems.

-anders
Re: #yocto #sdk #yocto #sdk

Monsees, Steven C (US)
 

Nope, just validated...

I build the my kernel image clean and the eSDK image right after, cache should be good, no ?

Not sure how to go about resolving... it occurs on the back end of the eSDK installation. I can actually go to the install and build the kernel image under the umbrella of the eSDK and it builds/runs correctly...

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Khem Raj
Sent: Thursday, March 4, 2021 12:18 PM
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.


if you have AUTOREVs e.g. can be problematic, and also using TIME/DATE in recipes which can interfere

On 3/4/21 5:13 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
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/(.*)>
file://universal-4.9/\1 <file://universal-4.9/1>
file://universal-4.9/(.*) <file://universal-4.9/(.*)>
file://universal-4.8/\1 <file://universal-4.8/1>"

Under sdk-extra.conf I set :

SSTATE_MIRRORS += file://.*
file:///ede/tms/yocto/zeus/sstate_cache/PATH
<file://.*%20file:/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/dep
loy/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/libur
cu/liburcu_0.11.1.bb:do_populate_sysroot,
unihash
cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601,
taskhash
cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601

Task
/disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-devtools/pyth
on/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>>
Re: #yocto #sdk #yocto #sdk

Monsees, Steven C (US)
 

 

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>>
Re: #yocto #sdk #yocto #sdk

Khem Raj
 

if you have AUTOREVs e.g. can be problematic, and also using TIME/DATE in recipes which can interfere

On 3/4/21 5:13 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
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/(.*)> file://universal-4.9/\1 <file://universal-4.9/1> file://universal-4.9/(.*) <file://universal-4.9/(.*)> file://universal-4.8/\1 <file://universal-4.8/1>"
Under sdk-extra.conf I set :
SSTATE_MIRRORS += file://.* file:///ede/tms/yocto/zeus/sstate_cache/PATH <file://.*%20file:/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>>
[auh][PATCH] auh: Add port 465 and 587 client support

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
modules/utils/emailhandler.py | 23 +++++++++++++++++++++--
upgrade-helper.conf | 3 +++
2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/modules/utils/emailhandler.py b/modules/utils/emailhandler.py
index 8c8b85b..a70bf23 100644
--- a/modules/utils/emailhandler.py
+++ b/modules/utils/emailhandler.py
@@ -27,7 +27,7 @@ import os
import logging as log
from logging import error as E
from logging import info as I
-from smtplib import SMTP
+from smtplib import SMTP, SMTP_SSL
import mimetypes
from email.mime.text import MIMEText
from email.mime.base import MIMEBase
@@ -35,12 +35,14 @@ from email.mime.multipart import MIMEMultipart
from email.generator import Generator
import shutil
from io import StringIO
+import ssl

class Email(object):
def __init__(self, settings):
self.smtp_host = None
self.smtp_port = None
self.from_addr = None
+ self.from_addr_pswd = None
if "smtp" in settings:
smtp_entry = settings["smtp"].split(":")
if len(smtp_entry) == 1:
@@ -57,6 +59,13 @@ class Email(object):
else:
E(" 'From' address not set! Sending emails disabled!")

+ if "email_client_pswd" in settings:
+ self.from_addr_pswd = settings["email_client_pswd"]
+
+ if self.smtp_port != '25':
+ if self.from_addr_pswd == None:
+ E(" Port %s needs a password, None set!" % self.smtp_port)
+
super(Email, self).__init__()

def send_email(self, to_addr, subject, text, files=[], cc_addr=None):
@@ -101,7 +110,17 @@ class Email(object):
msg_text = out.getvalue()

try:
- smtp = SMTP(self.smtp_host, self.smtp_port)
+ if self.smtp_port == '465':
+ smtp = SMTP_SSL(self.smtp_host, self.smtp_port)
+ smtp.login(self.from_addr, self.from_addr_pswd)
+ else:
+ smtp = SMTP(self.smtp_host, self.smtp_port)
+ if self.smtp_port == '587':
+ smtp.ehlo()
+ smtp.starttls(context=ssl.create_default_context())
+ smtp.ehlo()
+ smtp.login(self.from_addr, self.from_addr_pswd)
+
smtp.sendmail(self.from_addr, to_addr, msg_text)
if cc_addr is not None:
smtp.sendmail(self.from_addr, cc_addr, msg_text)
diff --git a/upgrade-helper.conf b/upgrade-helper.conf
index 5696564..3a5b3db 100644
--- a/upgrade-helper.conf
+++ b/upgrade-helper.conf
@@ -25,6 +25,9 @@
# If no port is specified, port 25 is assumed.
#smtp=smtp.my-server.com:25

+# Define a password needed to contect to email server
+#email_client_pswd=
+
# from whom should the e-mails be sent (mandatory if --send-emails is passed).
# Also sets the email address of the author of automated commits.
#from=uh@...
--
2.17.1
Re: #yocto #sdk #yocto #sdk

Monsees, Steven C (US)
 

 

 

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>>
Re: cc1 binary in final rootfs even when no reference to it

Khem Raj
 

On 3/3/21 11:29 AM, Belisko Marek wrote:
On Wed, Mar 3, 2021 at 6:31 PM Khem Raj <raj.khem@...> wrote:

this file comes from cpp output package. Can you check if somehow cpp
is being pulled into your image
It turns out that cpp + cpp-symlinks is pulled by python3-pycparser.
It is really necessary to be as runtime dependency in recipe?
it a parser for C language written in python, so my initial thoughts will be no. but there might be some dependencies on cpp, you might have to dive a bit deeper.


On Wed, Mar 3, 2021 at 6:10 AM Marek Belisko <marek.belisko@...> wrote:

Hello,

on dunfell images I start seeing that cc1 binary (checked by buildhistory):
files-in-image.txt:-rwxr-xr-x root root 17674124
./usr/libexec/gcc/arm-poky-linux-gnueabi/9.3.0/cc1

is present in the final image. I check taskexp but cannot find any
reference which pointes to it.
Any ideas how to check or it's a common problem?

Thanks and regards,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
Re: Reducing the perl footprint on my image

Tim Orling
 



On Wed, Mar 3, 2021 at 12:28 PM Tim Orling via lists.yoctoproject.org <ticotimo=gmail.com@...> wrote:


On Wed, Mar 3, 2021 at 7:06 AM Rusty Howell <rustyhowell@...> wrote:
Steve, you're right.  My image.bb is adding various lmsensors packages to the IMAGE_INSTALL, some of which depend on perl-modules.   perl-modules seems to be the big monster, not perl.  We need lmsensors.  So I guess my question is really, how can I (or can I at all) reduce the footprint of perl-modules?  perl-modules doesn't have any Depends, rather it has a long list (~ 670) of Recommends. 


If you look at the lmsensors recipe, the lmsensors-sensorsdetect [1] and lmsensors-sensorsconfconvert [2] subpackages both have perl-modules in RDEPENDS.
One way to determine the ACTUAL dependencies is to run the perl.req script from rpm [3].

Related bug [6]

$ perl.req sensors-detect
perl >= 0:5.004
perl(Fcntl)
perl(File::Basename)
perl(constant)
perl(strict)
perl(vars)

$ perl.req sensors-conf-convert
perl(strict)
perl(vars)

You then need to translate those into the perl-modules-* subpackages, which is easiest to see in perl-rdepends.txt [4].

I have not built nor tested this, but using the described approach I have a patch for lmsensors [5].

Please cherry-pick, test and if it works, add your signed-off-by and submit to the mailing list.


On Tue, Mar 2, 2021 at 1:49 PM Richard Purdie <richard.purdie@...> wrote:
On Tue, 2021-03-02 at 20:42 +0000, Diego Santa Cruz via lists.yoctoproject.org wrote:
> > -----Original Message-----
> > From: yocto@... <yocto@...> On
> > Behalf Of Steve Sakoman via lists.yoctoproject.org
> > Sent: 02 March 2021 21:06
> > To: Steve Sakoman <steve@...>
> > Cc: rustyhowell@...; Yocto (yocto@...)
> > <yocto@...>
> > Subject: Re: [yocto] Reducing the perl footprint on my image
> >
> > On Tue, Mar 2, 2021 at 10:01 AM Steve Sakoman via
> > lists.yoctoproject.org <steve=sakoman.com@...>
> > wrote:
> > >
> > > On Tue, Mar 2, 2021 at 6:26 AM <rustyhowell@...> wrote:
> > > >
> > > > I have an image that is using debian package management
> > (PACKAGE_CLASSES = "package_deb").  Because apt and dpkg require perl,
> > perl is being installed in the image.   No problem.  Except that the entire perl
> > stack is 669 packages.
> > >
> > > I just took a look at the manifest for one of my images that includes
> > > PACKAGE_CLASSES = "package_deb".  I see the perl package plus 43
> > > perl-module packages.  Are you sure that something else in your images
> > > isn't pulling in all of those other perl-module packages?
> >
> > It just occurred to me to make sure you are looking in the image
> > manifest to see which packages are actually installed in your image.
> > The perl recipe does generate 676 packages (in dunfell) so perhaps you
> > might be looking at the generated packages rather than the installed
> > packages??
> >
>
> I encountered a similar problem with package management enabled and rpm 
> as package format, where I also just install rpm for package management 
> and not all dnf stack. I get quite a lot of perl and python packages 
> into the image which are pulled by the rpm package, but they are only
> needed for things like rpm-build, rpm-sign, etc., not for the bare 
> rpm command, which is the only one I need in the image.
>
> So I locally extended the rpm recipe to split those tools into rpm-build, 
> rpm-sign and rpm-archive and skip those packages in the image. I should 
> probably send patches for that to oe-core. Is that something that could
> be accepted?

Not sure they need to go to separate packages but moving those 
three to some kind of "build" package would make a lot of sense
to me at least.

Cheers,

Richard
Re: Reducing the perl footprint on my image

Tim Orling
 



On Wed, Mar 3, 2021 at 7:06 AM Rusty Howell <rustyhowell@...> wrote:
Steve, you're right.  My image.bb is adding various lmsensors packages to the IMAGE_INSTALL, some of which depend on perl-modules.   perl-modules seems to be the big monster, not perl.  We need lmsensors.  So I guess my question is really, how can I (or can I at all) reduce the footprint of perl-modules?  perl-modules doesn't have any Depends, rather it has a long list (~ 670) of Recommends. 


If you look at the lmsensors recipe, the lmsensors-sensorsdetect [1] and lmsensors-sensorsconfconvert [2] subpackages both have perl-modules in RDEPENDS.
One way to determine the ACTUAL dependencies is to run the perl.req script from rpm [3].

$ perl.req sensors-detect
perl >= 0:5.004
perl(Fcntl)
perl(File::Basename)
perl(constant)
perl(strict)
perl(vars)

$ perl.req sensors-conf-convert
perl(strict)
perl(vars)

You then need to translate those into the perl-modules-* subpackages, which is easiest to see in perl-rdepends.txt [4].

I have not built nor tested this, but using the described approach I have a patch for lmsensors [5].

Please cherry-pick, test and if it works, add your signed-off-by and submit to the mailing list.


On Tue, Mar 2, 2021 at 1:49 PM Richard Purdie <richard.purdie@...> wrote:
On Tue, 2021-03-02 at 20:42 +0000, Diego Santa Cruz via lists.yoctoproject.org wrote:
> > -----Original Message-----
> > From: yocto@... <yocto@...> On
> > Behalf Of Steve Sakoman via lists.yoctoproject.org
> > Sent: 02 March 2021 21:06
> > To: Steve Sakoman <steve@...>
> > Cc: rustyhowell@...; Yocto (yocto@...)
> > <yocto@...>
> > Subject: Re: [yocto] Reducing the perl footprint on my image
> >
> > On Tue, Mar 2, 2021 at 10:01 AM Steve Sakoman via
> > lists.yoctoproject.org <steve=sakoman.com@...>
> > wrote:
> > >
> > > On Tue, Mar 2, 2021 at 6:26 AM <rustyhowell@...> wrote:
> > > >
> > > > I have an image that is using debian package management
> > (PACKAGE_CLASSES = "package_deb").  Because apt and dpkg require perl,
> > perl is being installed in the image.   No problem.  Except that the entire perl
> > stack is 669 packages.
> > >
> > > I just took a look at the manifest for one of my images that includes
> > > PACKAGE_CLASSES = "package_deb".  I see the perl package plus 43
> > > perl-module packages.  Are you sure that something else in your images
> > > isn't pulling in all of those other perl-module packages?
> >
> > It just occurred to me to make sure you are looking in the image
> > manifest to see which packages are actually installed in your image.
> > The perl recipe does generate 676 packages (in dunfell) so perhaps you
> > might be looking at the generated packages rather than the installed
> > packages??
> >
>
> I encountered a similar problem with package management enabled and rpm 
> as package format, where I also just install rpm for package management 
> and not all dnf stack. I get quite a lot of perl and python packages 
> into the image which are pulled by the rpm package, but they are only
> needed for things like rpm-build, rpm-sign, etc., not for the bare 
> rpm command, which is the only one I need in the image.
>
> So I locally extended the rpm recipe to split those tools into rpm-build, 
> rpm-sign and rpm-archive and skip those packages in the image. I should 
> probably send patches for that to oe-core. Is that something that could
> be accepted?

Not sure they need to go to separate packages but moving those 
three to some kind of "build" package would make a lot of sense
to me at least.

Cheers,

Richard
Re: cc1 binary in final rootfs even when no reference to it

Marek Belisko
 

On Wed, Mar 3, 2021 at 6:31 PM Khem Raj <raj.khem@...> wrote:

this file comes from cpp output package. Can you check if somehow cpp
is being pulled into your image
It turns out that cpp + cpp-symlinks is pulled by python3-pycparser.
It is really necessary to be as runtime dependency in recipe?

On Wed, Mar 3, 2021 at 6:10 AM Marek Belisko <marek.belisko@...> wrote:

Hello,

on dunfell images I start seeing that cc1 binary (checked by buildhistory):
files-in-image.txt:-rwxr-xr-x root root 17674124
./usr/libexec/gcc/arm-poky-linux-gnueabi/9.3.0/cc1

is present in the final image. I check taskexp but cannot find any
reference which pointes to it.
Any ideas how to check or it's a common problem?

Thanks and regards,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com




--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
[GDP] : Query on container development for Genivi GDP. #linux #meta-virtualization #yocto

Siddhartha V
 

I need to build a docker container/lxc container image for Genivi GDP. I searched a lot (almost 2 weeks) on this, but didn't get proper data to refer. 
 
But, recently, I found these links, https://github.com/gmacario/easy-build/pull/258 and https://github.com/gmacario/easy-build/issues/251 . I found them bit informative. 
 
I kindly request you to suggest me if there is any material/links to refer so that, it helps me in container development for GDP.
 
 
   Any suggestion will help me a lot. Thanks in advance


Regards,
Siddhartha V.
Re: cc1 binary in final rootfs even when no reference to it

Khem Raj
 

this file comes from cpp output package. Can you check if somehow cpp
is being pulled into your image

On Wed, Mar 3, 2021 at 6:10 AM Marek Belisko <marek.belisko@...> wrote:

Hello,

on dunfell images I start seeing that cc1 binary (checked by buildhistory):
files-in-image.txt:-rwxr-xr-x root root 17674124
./usr/libexec/gcc/arm-poky-linux-gnueabi/9.3.0/cc1

is present in the final image. I check taskexp but cannot find any
reference which pointes to it.
Any ideas how to check or it's a common problem?

Thanks and regards,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
Re: Reducing the perl footprint on my image

Diego Santa Cruz
 

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: 02 March 2021 21:50
To: Diego Santa Cruz <Diego.SantaCruz@...>;
steve@...
Cc: rustyhowell@...; Yocto (yocto@...)
<yocto@...>
Subject: Re: [yocto] Reducing the perl footprint on my image
[...]
So I locally extended the rpm recipe to split those tools into rpm-build,
rpm-sign and rpm-archive and skip those packages in the image. I should
probably send patches for that to oe-core. Is that something that could
be accepted?
Not sure they need to go to separate packages but moving those
three to some kind of "build" package would make a lot of sense
to me at least.
I'll be sending a patch to split it then. Having the sign and archive in separate packages allows to skip their dependencies in images too, and they are not really related to the rpm build part and the complexity delta is minimal; usually there is no need to have rpm-sign in a target image nor rpm2archive if the archive PACKAGECONFIG is enabled.

Best,
Diego

--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com
Re: Reducing the perl footprint on my image

Rusty Howell
 

Steve, you're right.  My image.bb is adding various lmsensors packages to the IMAGE_INSTALL, some of which depend on perl-modules.   perl-modules seems to be the big monster, not perl.  We need lmsensors.  So I guess my question is really, how can I (or can I at all) reduce the footprint of perl-modules?  perl-modules doesn't have any Depends, rather it has a long list (~ 670) of Recommends. 


On Tue, Mar 2, 2021 at 1:49 PM Richard Purdie <richard.purdie@...> wrote:
On Tue, 2021-03-02 at 20:42 +0000, Diego Santa Cruz via lists.yoctoproject.org wrote:
> > -----Original Message-----
> > From: yocto@... <yocto@...> On
> > Behalf Of Steve Sakoman via lists.yoctoproject.org
> > Sent: 02 March 2021 21:06
> > To: Steve Sakoman <steve@...>
> > Cc: rustyhowell@...; Yocto (yocto@...)
> > <yocto@...>
> > Subject: Re: [yocto] Reducing the perl footprint on my image
> >
> > On Tue, Mar 2, 2021 at 10:01 AM Steve Sakoman via
> > lists.yoctoproject.org <steve=sakoman.com@...>
> > wrote:
> > >
> > > On Tue, Mar 2, 2021 at 6:26 AM <rustyhowell@...> wrote:
> > > >
> > > > I have an image that is using debian package management
> > (PACKAGE_CLASSES = "package_deb").  Because apt and dpkg require perl,
> > perl is being installed in the image.   No problem.  Except that the entire perl
> > stack is 669 packages.
> > >
> > > I just took a look at the manifest for one of my images that includes
> > > PACKAGE_CLASSES = "package_deb".  I see the perl package plus 43
> > > perl-module packages.  Are you sure that something else in your images
> > > isn't pulling in all of those other perl-module packages?
> >
> > It just occurred to me to make sure you are looking in the image
> > manifest to see which packages are actually installed in your image.
> > The perl recipe does generate 676 packages (in dunfell) so perhaps you
> > might be looking at the generated packages rather than the installed
> > packages??
> >
>
> I encountered a similar problem with package management enabled and rpm 
> as package format, where I also just install rpm for package management 
> and not all dnf stack. I get quite a lot of perl and python packages 
> into the image which are pulled by the rpm package, but they are only
> needed for things like rpm-build, rpm-sign, etc., not for the bare 
> rpm command, which is the only one I need in the image.
>
> So I locally extended the rpm recipe to split those tools into rpm-build, 
> rpm-sign and rpm-archive and skip those packages in the image. I should 
> probably send patches for that to oe-core. Is that something that could
> be accepted?

Not sure they need to go to separate packages but moving those 
three to some kind of "build" package would make a lot of sense
to me at least.

Cheers,

Richard
cc1 binary in final rootfs even when no reference to it

Marek Belisko
 

Hello,

on dunfell images I start seeing that cc1 binary (checked by buildhistory):
files-in-image.txt:-rwxr-xr-x root root 17674124
./usr/libexec/gcc/arm-poky-linux-gnueabi/9.3.0/cc1

is present in the final image. I check taskexp but cannot find any
reference which pointes to it.
Any ideas how to check or it's a common problem?

Thanks and regards,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
5241 - 5260 of 57792