1. yocto@lists.yoctoproject.org
  2. Messages
   Date   
OPencv 3.1 with Rocko #rocko

rohit jadhav
 

Observing following error
while generationg rootfs with Packages of opencv 2.4 and 3.1

RROR: opencv-3.1+gitAUTOINC+92387b1ef8-r0 do_package: Error executing a python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
     0001:
 *** 0002:populate_packages(d)
     0003:
File: '/home/tel/imx_yocto_Rocko/sources/poky/meta/classes/package.bbclass', lineno: 1109, function: populate_packages
     1105:        d.setVar('FILES_%s' % src_package_name, '/usr/src/debug')
     1106:
     1107:    # Sanity check PACKAGES for duplicates
     1108:    # Sanity should be moved to sanity.bbclass once we have the infrastucture
 *** 1109:    package_list = []
     1110:
     1111:    for pkg in packages.split():
     1112:        if pkg in package_list:
     1113:            msg = "%s is listed in PACKAGES multiple times, this leads to packaging errors." % pkg
Exception: AttributeError: module 'bb.data' has no attribute 'setVar'

ERROR: opencv-3.1+gitAUTOINC+92387b1ef8-r0 do_package: Function failed: populate_packages
ERROR: Logfile of failure stored in: /home/tel/imx_yocto_Rocko/build_imx6ull/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/opencv/3.1+gitAUTOINC+92387b1ef8-r0/temp/log.do_package.17885
ERROR: Task (/home/tel/imx_yocto_Rocko/sources/meta-openembedded/meta-oe/recipes-support/opencv/opencv_3.1.bb:do_package) failed with exit code

does any one guide me throgh this ?
Re: #yocto #sdk #yocto #sdk

Monsees, Steven C (US)
 

 

Thanks for your patience…

 

I was able to followed your advice and I am now able to build and install the Extended SDK for our Intel platform…

 

Can you tell me when building for Arm/Xilinx based platforms, how you incorporate the dependency of the low level Xilinx FPGA support  on “Vivado” into the Ext SDK build env ?

 

Thanks,

Steve

From: Khem Raj <raj.khem@...>
Sent: Thursday, March 25, 2021 5:16 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.

 

 

 

On Thu, Mar 25, 2021 at 1:01 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:


I've been looking at this but still find it odd that they are all " virtual:native"/ "poky/meta"/“do_populate_sysroot” related...

It is a "minimum" plus "toolset" build... and  it builds clean, yet fails on the install...

The error:  "> ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly"

How do you determine unexpected execution ?

Any suggestions on how I should approach this ?

 

Perhaps get into install  env and do signatures check for this task


Thanks,
Steve

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, March 24, 2021 2:43 PM
To: 'Khem Raj' <raj.khem@...>
Cc: yocto@...
Subject: RE: [yocto] #yocto #sdk


The output  you see is from setting:

SDK_EXT_TYPE = "minimal"
SDK_INCLUDE_TOOLCHAIN = "1"

When building minimal only, there are no errors/warnings (and no tools...)


-----Original Message-----
From: Khem Raj <raj.khem@...>
Sent: Wednesday, March 24, 2021 2:35 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.


I think there still are signature differences. perhaps try to add incremntally on top of minimal sdk and see where it breaks.

On 3/24/21 9:18 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
> I corrected for the sig warnings, but still have an issue with the
> extended SDK installing correctly
>
> (though I think I am close…)
>
> *Note: The only issue now appears to be around the “…/poky/meta”
> layer… and all with regards to “do_populate_sysroot” task…*
>
> I am building my kernel clean, and update the MIRRORS after…
>
> The unihash & taskhash values are identical with respect to each
> component below…
>
> I am building “uninative” support into the EXT SDK only…
>
> *None of the poky/meta references below are being modified by
> bbappends… should be a straight build*…
>
> The EXT SDK local.conf appears to be setup correctly for my build env…
>
> Am I missing something, a required variable setting, an additional
> support component ? *- seems odd it is all centered around the one
> unmodified layer…*
>
> I am able to build and install the “minimum” EXT SDK correctly, but I
> of course need the toolset…
>
> I would appreciate any advice on how I might resolve this issue.
>
> Install Output:
>
> 10:50 smonsees@yix490016
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/dep
> loy/sdk>ls
>
> limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.host.mani
> fest
>
> limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh
>
> limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.target.ma
> nifest
>
> limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.testdata.
> json
>
> x86_64-buildtools-nativesdk-standalone-3.0.4.host.manifest
>
> x86_64-buildtools-nativesdk-standalone-3.0.4.sh
>
> x86_64-buildtools-nativesdk-standalone-3.0.4.target.manifest
>
> x86_64-buildtools-nativesdk-standalone-3.0.4.testdata.json
>
> 10:50 smonsees@yix490016
> /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/sbcbSDK_EXT
>
> You are about to install the SDK to
> "/disk0/scratch/smonsees/sbcbSDK_EXT". Proceed [Y/n]? Y
>
> Extracting SDK...............done
>
> Setting it up...
>
> Extracting buildtools...
>
> Preparing build system...
>
> Parsing recipes: 100%
> |#####################################################################
> |########################|
> Time: 0:01:33
>
> Initialising tasks: 100%
> |#####################################################################
> |#####################|
> Time: 0:00:00
>
> Checking sstate mirror object availability: 100%
> |##################################################################|
> Time: 0:00:00
>
> ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> gcc/libgcc_9.2.bb:do_populate_sysroot,
> unihash
> d5a9dff48660903403f33fe67d6d43e03c97c03232c6d8f0ed71f99a94670bce,
> taskhash
> d5a9dff48660903403f33fe67d6d43e03c97c03232c6d8f0ed71f99a94670bce
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-support/gmp/gmp_6.1.2.bb:do_populate_sysroot,
> unihash
> cde9ef4fc769ee9a2733a1023534c15bfe199009270bcebb6c24c638729194dc,
> taskhash
> cde9ef4fc769ee9a2733a1023534c15bfe199009270bcebb6c24c638729194dc
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> libtool/libtool-native_2.4.6.bb:do_populate_sysroot,
> unihash
> a1def57d3e655defdf1f85eec749be672ffe52a0a3c247585da9d6c57617cca2,
> taskhash
> a1def57d3e655defdf1f85eec749be672ffe52a0a3c247585da9d6c57617cca2
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> gcc/gcc-cross_9.2.bb:do_populate_sysroot,
> unihash
> 5f0f3533314c754b184e6f63f11ef2b570c7a5d47bc18fee2b4217aa294f08eb,
> taskhash
> 5f0f3533314c754b184e6f63f11ef2b570c7a5d47bc18fee2b4217aa294f08eb
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-connectivity/openssl/openssl_1.1.1g.bb:do_populate_sysroot,
> unihash
> d5e6bedb0cfb876a2925ea2e7f3bd00b090326b1cebf1182a6322974a6f055a3,
> taskhash
> d5e6bedb0cfb876a2925ea2e7f3bd00b090326b1cebf1182a6322974a6f055a3
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/python/python3_3.7.8.bb:do_populate_sysroot,
> unihash
> 8ee0c0eafd3b1c3f774a26f59659fc0c563816b6badfa57d9fa9097a182b1de5,
> taskhash
> 8ee0c0eafd3b1c3f774a26f59659fc0c563816b6badfa57d9fa9097a182b1de5
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-gnome/gtk-doc/gtk-doc_1.31.bb:do_populate_sysroot,
> unihash
> fbc7421c8a324ed0cbca81f98430f509ce4cf6593b0961cad8109d467df9e35e,
> taskhash
> fbc7421c8a324ed0cbca81f98430f509ce4cf6593b0961cad8109d467df9e35e
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-core/meta
> /meta-extsdk-toolchain.bb:do_populate_sysroot,
> unihash
> b9d46f79061ad82c4630a3db00aefe484f743a84a526e8afb24d953d04752276,
> taskhash
> b9d46f79061ad82c4630a3db00aefe484f743a84a526e8afb24d953d04752276
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-support/attr/attr_2.4.47.bb:do_populate_sysroot,
> unihash
> 3a6c84cf03e3103e46c02b01aed446fc31617f348b40d9e51b5b2ee8c2f3d0ee,
> taskhash
> 3a6c84cf03e3103e46c02b01aed446fc31617f348b40d9e51b5b2ee8c2f3d0ee
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-support/libmpc/libmpc_1.1.0.bb:do_populate_sysroot,
> unihash
> 39109487309272ea510afb753a0dd84775625c73f7a261b9d0078fe0ea718f17,
> taskhash
> 39109487309272ea510afb753a0dd84775625c73f7a261b9d0078fe0ea718f17
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-core/util-linux/util-linux_2.34.bb:do_populate_sysroot,
> unihash
> 51964ba6ff2cd62ad6d9077e9fddfe53be566eb23beca10e9c882a1eee20aa5d,
> taskhash
> 51964ba6ff2cd62ad6d9077e9fddfe53be566eb23beca10e9c882a1eee20aa5d
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-multimedia/libpng/libpng_1.6.37.bb:do_populate_sysroot,
> unihash
> 6d92093db77054a96cd23e00ca2bf3468a9ae8ebddc191a59e1a0136778d6be1,
> taskhash
> 6d92093db77054a96cd23e00ca2bf3468a9ae8ebddc191a59e1a0136778d6be1
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> gcc/gcc-cross_9.2.bb:do_gcc_stash_builddir,
> unihash
> 62ba54c4db5ba11db400ba0277892d92f665f35b5c334c17f8e6ad9ded9c16b1,
> taskhash
> 62ba54c4db5ba11db400ba0277892d92f665f35b5c334c17f8e6ad9ded9c16b1
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-extended/xz/xz_5.2.4.bb:do_populate_sysroot,
> unihash
> 01723d04843fdbeec3fabd109c34281bd49c0979e09c722b2c189335cb6c957a,
> taskhash
> 01723d04843fdbeec3fabd109c34281bd49c0979e09c722b2c189335cb6c957a
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> m4/m4-native_1.4.18.bb:do_populate_sysroot,
> unihash
> 19b266239a8f93f5273ac6213d0f58a73bfc1ecbe84c5cfd273f5351b0740ca1,
> taskhash
> 19b266239a8f93f5273ac6213d0f58a73bfc1ecbe84c5cfd273f5351b0740ca1
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-graphics/xorg-lib/pixman_0.38.4.bb:do_populate_sysroot,
> unihash
> 66cca6669fc3fdc571970b1ccabb7a8b334139013df8b71c8b033d15705ec5a7,
> taskhash
> 66cca6669fc3fdc571970b1ccabb7a8b334139013df8b71c8b033d15705ec5a7
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/unfs3/unfs3_git.bb:do_populate_sysroot,
> unihash
> 46e3dd7e07935b77a618c4587f5bc8dbaaff1ba030e779683e2bf2679f57c8fb,
> taskhash
> 46e3dd7e07935b77a618c4587f5bc8dbaaff1ba030e779683e2bf2679f57c8fb
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> gcc/gcc-runtime_9.2.bb:do_populate_sysroot,
> unihash
> 7200138112d31332099cf647ee83441c6739d6f276f2ba859bd440b7a4eed9fb,
> taskhash
> 7200138112d31332099cf647ee83441c6739d6f276f2ba859bd440b7a4eed9fb
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/meson/meson_0.51.2.bb:do_populate_sysroot,
> unihash
> ac801ce28f4bf45c7c08e2721a765872a1bd6561f783c570ed47dad7e9642901,
> taskhash
> ac801ce28f4bf45c7c08e2721a765872a1bd6561f783c570ed47dad7e9642901
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-core/expat/expat_2.2.8.bb:do_populate_sysroot,
> unihash
> c47a5a2b37341edbfeab516b931c8f0015b52d6159f251e70f57e086a6502fe1,
> taskhash
> c47a5a2b37341edbfeab516b931c8f0015b52d6159f251e70f57e086a6502fe1
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/bison/bison_3.4.1.bb:do_populate_sysroot,
> unihash
> f8fb4d2026cb4192c03bc75c357f9890dcb4f7593d23407f9a60c32d383d7c57,
> taskhash
> f8fb4d2026cb4192c03bc75c357f9890dcb4f7593d23407f9a60c32d383d7c57
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-kernel/dtc/dtc_1.5.1.bb:do_populate_sysroot,
> unihash
> 8ee1e9314ae7a6235f2ec876f7d30336d6e65d7879ac17cd1044ac3f20f969ec,
> taskhash
> 8ee1e9314ae7a6235f2ec876f7d30336d6e65d7879ac17cd1044ac3f20f969ec
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/autoconf-archive/autoconf-archive_2019.01.06.bb:do_popu
> late_sysroot,
> unihash
> 7aaaf6c0cf3a9c104029683b93a62b965e91827c487ee707a23c84560aea1d3e,
> taskhash
> 7aaaf6c0cf3a9c104029683b93a62b965e91827c487ee707a23c84560aea1d3e
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-extended/bzip2/bzip2_1.0.8.bb:do_populate_sysroot,
> unihash
> 66c8139add58f12cae0334108b226f4f91f1fdb34fd34822c9ff9612d6c11b64,
> taskhash
> 66c8139add58f12cae0334108b226f4f91f1fdb34fd34822c9ff9612d6c11b64
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-graphics/xorg-util/util-macros_1.19.2.bb:do_populate_sysroot,
> unihash
> 070d343bb7de5e6402f4190283e6d40ca33031eac71601d7ab92a92ef0e175d0,
> taskhash
> 070d343bb7de5e6402f4190283e6d40ca33031eac71601d7ab92a92ef0e175d0
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/python/python3-setuptools_41.2.0.bb:do_populate_sysroot
> ,
> unihash
> e8771b3e23f0d5c3e799b093dd9657a2fd863abf459fa500399930111a8fd388,
> taskhash
> e8771b3e23f0d5c3e799b093dd9657a2fd863abf459fa500399930111a8fd388
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> qemu/qemu-system-native_4.1.0.bb:do_populate_sysroot,
> unihash
> 33ac287a8d8aded61eb77dd21cb3c54986126430c78a243f706a5917ef0a0183,
> taskhash
> 33ac287a8d8aded61eb77dd21cb3c54986126430c78a243f706a5917ef0a0183
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-support/mpfr/mpfr_4.0.2.bb:do_populate_sysroot,
> unihash
> 25d61942ed599e037b2e75a5b722ce5ff251005c2a4ee23e9faef34c9e54777b,
> taskhash
> 25d61942ed599e037b2e75a5b722ce5ff251005c2a4ee23e9faef34c9e54777b
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-support/re2c/re2c_1.0.1.bb:do_populate_sysroot,
> unihash
> 6ebe8680a921a8927ef6cd0061b2b50667bb787be010c8ee4ca6ccc3593024b7,
> taskhash
> 6ebe8680a921a8927ef6cd0061b2b50667bb787be010c8ee4ca6ccc3593024b7
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot,
> unihash
> 28e64747a95953ec8626d3027958e12d1fd854a7615bc69cf5adbbc3d49c323a,
> taskhash
> 28e64747a95953ec8626d3027958e12d1fd854a7615bc69cf5adbbc3d49c323a
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-extended/libtirpc/libtirpc_1.1.4.bb:do_populate_sysroot,
> unihash
> 147f1ca7d20e89f2786b48fcda4ebaf36c1c3d941b53b0b8b56c42beb9220c1d,
> taskhash
> 147f1ca7d20e89f2786b48fcda4ebaf36c1c3d941b53b0b8b56c42beb9220c1d
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> qemu/qemu-native_4.1.0.bb:do_populate_sysroot,
> unihash
> 00651d4d53b4b7b10e44770326d5f0a1f5482c1262671621523ba12c21508977,
> taskhash
> 00651d4d53b4b7b10e44770326d5f0a1f5482c1262671621523ba12c21508977
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-core/gettext/gettext_0.19.8.1.bb:do_populate_sysroot,
> unihash
> bf9b767f8e30be92fa06079f2e7350aa304648b0d113829d315e6cb64bad0565,
> taskhash
> bf9b767f8e30be92fa06079f2e7350aa304648b0d113829d315e6cb64bad0565
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-core/glib
> c/glibc_2.30.bb:do_stash_locale,
> unihash
> d64e054d019028151912ffface31585789df48f4de7e3a66b201cd614c2f4aca,
> taskhash
> d64e054d019028151912ffface31585789df48f4de7e3a66b201cd614c2f4aca
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/ninja/ninja_1.9.0.bb:do_populate_sysroot,
> unihash
> ab3ecdf2561adc51338d36576f60eab1e05fc09ed69bb6444075d7adbeb57b9e,
> taskhash
> ab3ecdf2561adc51338d36576f60eab1e05fc09ed69bb6444075d7adbeb57b9e
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-support/sqlite/sqlite3_3.29.0.bb:do_populate_sysroot,
> unihash
> c1a988a16d4368098e178f7fe5f0e2e5f8adf4fa485a7b79c4c093a38005264e,
> taskhash
> c1a988a16d4368098e178f7fe5f0e2e5f8adf4fa485a7b79c4c093a38005264e
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/automake/automake_1.16.1.bb:do_populate_sysroot,
> unihash
> ad223f3318940531fa279bd74480cd6410abc46644f8fe98f7399a71cfe09179,
> taskhash
> ad223f3318940531fa279bd74480cd6410abc46644f8fe98f7399a71cfe09179
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot,
> unihash
> be5aa9a356c12c9b4220c3d3d6dfe16c737e9be88e7d331c0511b275e4d603c4,
> taskhash
> be5aa9a356c12c9b4220c3d3d6dfe16c737e9be88e7d331c0511b275e4d603c4
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/flex/flex_2.6.0.bb:do_populate_sysroot,
> unihash
> 9c37027658f2832321efe3657d91f29d1bf286ad1fda0c9916b256adfa246455,
> taskhash
> 9c37027658f2832321efe3657d91f29d1bf286ad1fda0c9916b256adfa246455
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-core/readline/readline_8.0.bb:do_populate_sysroot,
> unihash
> 3d909d0d6de7cf72b631aa1805efc1147459bef5bddca5f60ff07022ba777e0e,
> taskhash
> 3d909d0d6de7cf72b631aa1805efc1147459bef5bddca5f60ff07022ba777e0e
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-extended/libnsl/libnsl2_git.bb:do_populate_sysroot,
> unihash
> 19357ca137093c4e1e063d14a0d3844f889dce933a4eebdc34acf0c321d707ec,
> taskhash
> 19357ca137093c4e1e063d14a0d3844f889dce933a4eebdc34acf0c321d707ec
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-core/glib
> c/glibc_2.30.bb:do_populate_sysroot,
> unihash
> df6ecc8017c1a3fa278fc743c85fa6049465da674f169777b9a544eb423b84b5,
> taskhash
> df6ecc8017c1a3fa278fc743c85fa6049465da674f169777b9a544eb423b84b5
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-support/gdbm/gdbm_1.18.1.bb:do_populate_sysroot,
> unihash
> 8b0d7a859afc0cc39a32d26b8d5c79b5c1b8970a8e5d566098ff59fc916335f5,
> taskhash
> 8b0d7a859afc0cc39a32d26b8d5c79b5c1b8970a8e5d566098ff59fc916335f5
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-support/libcap-ng/libcap-ng_0.7.9.bb:do_populate_sysroot,
> unihash
> 784e3c4b04d227379d94e85251233a568fb9e9f841d737584882d0da0b009d5c,
> taskhash
> 784e3c4b04d227379d94e85251233a568fb9e9f841d737584882d0da0b009d5c
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-core/zlib/zlib_1.2.11.bb:do_populate_sysroot,
> unihash
> 770d0b4be83a17d65464ade3adc3c6be443a9f8fffbe53d303c5765674a274d7,
> taskhash
> 770d0b4be83a17d65464ade3adc3c6be443a9f8fffbe53d303c5765674a274d7
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-extended/unzip/unzip_6.0.bb:do_populate_sysroot,
> unihash
> 82d365cde8a3375461fb47f650aa3fd7c8aa029b0cd2f23ccd38b6f73a9902d9,
> taskhash
> 82d365cde8a3375461fb47f650aa3fd7c8aa029b0cd2f23ccd38b6f73a9902d9
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot,
> unihash
> de3b4482bf2a0878b99c904fecac19e917d374838da4c9df62929bb14d1282d1,
> taskhash
> de3b4482bf2a0878b99c904fecac19e917d374838da4c9df62929bb14d1282d1
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> binutils/binutils-cross_2.32.bb:do_populate_sysroot,
> unihash
> 50ce76092848b0214480dd7a4f0fcc7e5927f4f8071601bc094847d20d2c879d,
> taskhash
> 50ce76092848b0214480dd7a4f0fcc7e5927f4f8071601bc094847d20d2c879d
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/gnu-config/gnu-config_git.bb:do_populate_sysroot,
> unihash
> 90db72e6ab74de51a86e0b14980b2c204076fc3ef8297a374b660d8645853cac,
> taskhash
> 90db72e6ab74de51a86e0b14980b2c204076fc3ef8297a374b660d8645853cac
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-kernel/li
> nux-libc-headers/linux-libc-headers_5.2.bb:do_populate_sysroot,
> unihash
> 7b6f6e59c3431987b308c78d6f72e5aefae1b9afbf158a47540f0db5e04ebdb0,
> taskhash
> 7b6f6e59c3431987b308c78d6f72e5aefae1b9afbf158a47540f0db5e04ebdb0
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> gdb/gdb-cross_8.3.1.bb:do_populate_sysroot,
> unihash
> c623832386a7201b2a59b170e7c9015edfffbfb21dbec6ab44e81662d1d7c504,
> taskhash
> c623832386a7201b2a59b170e7c9015edfffbfb21dbec6ab44e81662d1d7c504
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> quilt/quilt-native_0.66.bb:do_populate_sysroot,
> unihash
> 23290d029e88d49579ce286326ba82d42ad77874a2cd0e05e71166b964190822,
> taskhash
> 23290d029e88d49579ce286326ba82d42ad77874a2cd0e05e71166b964190822
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-support/libffi/libffi_3.3~rc0.bb:do_populate_sysroot,
> unihash
> 5be2fdefd4b14100290247d24d2df8da234ea32cb91e4508ffd793aabc06d30e,
> taskhash
> 5be2fdefd4b14100290247d24d2df8da234ea32cb91e4508ffd793aabc06d30e
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/make/make_4.2.1.bb:do_populate_sysroot,
> unihash
> 7a82e867fd7be399f5d92200e43de6e7d9d42ad98e5f771a6e54a0975053ae2e,
> taskhash
> 7a82e867fd7be399f5d92200e43de6e7d9d42ad98e5f771a6e54a0975053ae2e
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-extended/
> texinfo-dummy-native/texinfo-dummy-native.bb:do_populate_sysroot,
> unihash
> 2d20a98fe86b071366643317507293df9594c15528ef49f3fbeeffe4af532501,
> taskhash
> 2d20a98fe86b071366643317507293df9594c15528ef49f3fbeeffe4af532501
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-core/gett
> ext/gettext-minimal-native_0.19.8.1.bb:do_populate_sysroot,
> unihash
> d579308c5efa4cef283785d540731bf0f02dffeef6ea677b0fa7cec6332e7902,
> taskhash
> d579308c5efa4cef283785d540731bf0f02dffeef6ea677b0fa7cec6332e7902
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-core/glib-2.0/glib-2.0_2.60.7.bb:do_populate_sysroot,
> unihash
> b7ff5dcd7278fab62aa716be6cf652bcc1d463d884738fb3232297fe6f81880a,
> taskhash
> b7ff5dcd7278fab62aa716be6cf652bcc1d463d884738fb3232297fe6f81880a
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-extended/gperf/gperf_3.1.bb:do_populate_sysroot,
> unihash
> 6765ae416e5360039914d6216c0d02541c5afc070545804303d75d1016b7b460,
> taskhash
> 6765ae416e5360039914d6216c0d02541c5afc070545804303d75d1016b7b460
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-core/ncurses/ncurses_6.1+20190803.bb:do_populate_sysroot,
> unihash
> f468831b3be537588a35b7fdf2e1a46dc52d1737fbf168c0e83ff0f162a99cf9,
> taskhash
> f468831b3be537588a35b7fdf2e1a46dc52d1737fbf168c0e83ff0f162a99cf9
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-multimedia/alsa/alsa-lib_1.1.9.bb:do_populate_sysroot,
> unihash
> 39d5b05d5ec0e2b2abbb710c7c31f17d3047a255f5a11deb121d7323e06fb900,
> taskhash
> 39d5b05d5ec0e2b2abbb710c7c31f17d3047a255f5a11deb121d7323e06fb900
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-support/libpcre/libpcre_8.43.bb:do_populate_sysroot,
> unihash
> 3eed4e011c853b98bf31e1c1b2eee2073aeb4ef0546c9bd230f2bfcc3ac05088,
> taskhash
> 3eed4e011c853b98bf31e1c1b2eee2073aeb4ef0546c9bd230f2bfcc3ac05088
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/autoconf/autoconf_2.69.bb:do_populate_sysroot,
> unihash
> 373490cc20455b0913b69b35ab9cc61340356d7b27f7ecb6cf51a3ad9459a068,
> taskhash
> 373490cc20455b0913b69b35ab9cc61340356d7b27f7ecb6cf51a3ad9459a068
>
> Task
> virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/re
> cipes-devtools/unifdef/unifdef_2.11.bb:do_populate_sysroot,
> unihash
> 3e6814932d42ab266096948b4b81f9c1fbdbb26f7b990963ca4322a718e13170,
> taskhash
> 3e6814932d42ab266096948b4b81f9c1fbdbb26f7b990963ca4322a718e13170
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> gcc/libgcc-initial_9.2.bb:do_populate_sysroot,
> unihash
> 07136816c5d9bb085d8dab671c1689d08254d92b7e0edbb4a23abb3ae2628bea,
> taskhash
> 07136816c5d9bb085d8dab671c1689d08254d92b7e0edbb4a23abb3ae2628bea
>
> Task
> /disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools/
> qemu/qemu-helper-native_1.0.bb:do_populate_sysroot,
> unihash
> 4ba7e532221d903e4c3556460d09d7bf7eabc9c4ca73f6a481849be0eaba23a3,
> taskhash
> 4ba7e532221d903e4c3556460d09d7bf7eabc9c4ca73f6a481849be0eaba23a3
>
> This is usually due to missing setscene tasks. Those missing in this
> build were:
> {'/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-core/ge
> ttext/gettext-minimal-native_0.19.8.1.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-core/gli
> bc/glibc_2.30.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-core/gli
> bc/glibc_2.30.bb:do_stash_locale',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-core/met
> a/meta-extsdk-toolchain.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /binutils/binutils-cross_2.32.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /gcc/gcc-cross_9.2.bb:do_gcc_stash_builddir',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /gcc/gcc-cross_9.2.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /gcc/gcc-runtime_9.2.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /gcc/libgcc-initial_9.2.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /gcc/libgcc_9.2.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /gdb/gdb-cross_8.3.1.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /libtool/libtool-native_2.4.6.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /m4/m4-native_1.4.18.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /qemu/qemu-helper-native_1.0.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /qemu/qemu-native_4.1.0.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /qemu/qemu-system-native_4.1.0.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /quilt/quilt-native_0.66.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-extended
> /texinfo-dummy-native/texinfo-dummy-native.bb:do_populate_sysroot',
>
> '/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-kernel/l
> inux-libc-headers/linux-libc-headers_5.2.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-connectivity/openssl/openssl_1.1.1g.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-core/expat/expat_2.2.8.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-core/gettext/gettext_0.19.8.1.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-core/glib-2.0/glib-2.0_2.60.7.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-core/ncurses/ncurses_6.1+20190803.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-core/readline/readline_8.0.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-core/util-linux/util-linux_2.34.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-core/zlib/zlib_1.2.11.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/autoconf-archive/autoconf-archive_2019.01.06.bb:do_pop
> ulate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/autoconf/autoconf_2.69.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/automake/automake_1.16.1.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/bison/bison_3.4.1.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/flex/flex_2.6.0.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/gnu-config/gnu-config_git.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/make/make_4.2.1.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/meson/meson_0.51.2.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/ninja/ninja_1.9.0.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/python/python3-setuptools_41.2.0.bb:do_populate_sysroo
> t',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/python/python3_3.7.8.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/unfs3/unfs3_git.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-devtools/unifdef/unifdef_2.11.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-extended/bzip2/bzip2_1.0.8.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-extended/gperf/gperf_3.1.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-extended/libnsl/libnsl2_git.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-extended/libtirpc/libtirpc_1.1.4.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-extended/unzip/unzip_6.0.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-extended/xz/xz_5.2.4.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-gnome/gtk-doc/gtk-doc_1.31.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-graphics/xorg-lib/pixman_0.38.4.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-graphics/xorg-util/util-macros_1.19.2.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-kernel/dtc/dtc_1.5.1.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-multimedia/alsa/alsa-lib_1.1.9.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-multimedia/libpng/libpng_1.6.37.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-support/attr/attr_2.4.47.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-support/gdbm/gdbm_1.18.1.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-support/gmp/gmp_6.1.2.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-support/libcap-ng/libcap-ng_0.7.9.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-support/libffi/libffi_3.3~rc0.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-support/libmpc/libmpc_1.1.0.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-support/libpcre/libpcre_8.43.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-support/mpfr/mpfr_4.0.2.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-support/re2c/re2c_1.0.1.bb:do_populate_sysroot',
>
> 'virtual:native:/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/r
> ecipes-support/sqlite/sqlite3_3.29.0.bb:do_populate_sysroot'}
>
> ERROR: Task
> (/disk0/scratch/smonsees/sbcbSDK_EXT/layers/poky/meta/recipes-devtools
> /quilt/quilt-native_0.66.bb:do_fetch)
> failed with exit code 'setscene whitelist'
>
> ERROR: SDK preparation failed: error log written to
> /disk0/scratch/smonsees/sbcbSDK_EXT/preparing_build_system.log
>
> 10:52 smonsees@yix490016
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/dep
> loy/sdk>
>
> *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 <http://lists.yoctoproject.org>
> <steven.monsees=baesystems.com@...
> <mailto: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
>     
> <http://limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.s
> h>
>
>     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.mail-archive.com/search?l=yocto@...&q=subjec
> t:%22Re%5C%3A+%5C%5Byocto%5C%5D+eSDK+install+script+failure%22&o=newes
> t&f=1>
>
>     
> https://www.yoctoproject.org/pipermail/yocto/2017-August/037359.html
>     
> <https://www.yoctoproject.org/pipermail/yocto/2017-August/037359.html>
>
>     https://bugzilla.yoctoproject.org/show_bug.cgi?id=12344
>     <https://bugzilla.yoctoproject.org/show_bug.cgi?id=12344>
>
>     *From:* yocto@...
>     <mailto:yocto@...> <yocto@...
>     <mailto:yocto@...>> *On Behalf Of *Monsees,
>     Steven C (US) via lists.yoctoproject.org <http://lists.yoctoproject.org>
>     *Sent:* Thursday, March 4, 2021 8:13 AM
>     *To:* Monsees, Steven C (US) <steven.monsees@...
>     <mailto:steven.monsees@...>>;
>     yocto@... <mailto: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@...
>     <mailto:yocto@...> <yocto@...
>     <mailto:yocto@...>> *On Behalf Of *Monsees,
>     Steven C (US) via lists.yoctoproject.org <http://lists.yoctoproject.org>
>     *Sent:* Tuesday, March 2, 2021 3:26 PM
>     *To:* yocto@... <mailto: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://.*>
>     file:///ede/tms/yocto/zeus/sstate_cache/PATH
>     <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/dep
> loy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4
> .sh
>     
> <http://limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.s
> h>
>
>     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: [meta-rockchip] defconfig alternatives

Yann Dirson
 

My thoughts on this after working on this for the nanopi-m4 have
changed a bit: it looks
like the existing kmeta system already provides us with everything we need:

- the kmeta BSP mechanism already provides the way to declare all the platform
features in "hardware features"
- a minimal kernel can then be obtained with KCONFIG_MODE="--allnoconfig"
and KBUILD_DEFCONFIG="", with some support from
PREFERRED_PROVIDER_virtual/kernel="linux-yocto-tiny"

Above this, downstream layers can easily add the additional features they need,
by appending kmeta features as needed, or their own .cfg snippets if no existing
feature matches.

Did i overlook some use-case that would not be covered ?


Le jeu. 25 mars 2021 à 18:11, Yann Dirson via lists.yoctoproject.org
<yann.dirson=blade-group.com@...> a écrit :

= "Hi Trevor,

Le mer. 24 mars 2021 à 01:41, Trevor Woerner <twoerner@...> a écrit :

On Tue 2021-03-23 @ 12:59:24 PM, Yann Dirson wrote:
Hi Trevor,

Le lun. 22 mars 2021 à 16:50, Trevor Woerner <twoerner@...> a écrit :
BTW, I'm also unclear on what to do next to better support those
boards: with the default
kernel config only a subset of the hardware is supported, and for
state-of-the-art hw
support we'll also need patches not yet in upstream kernel (from eg.
armbian and libreelec).

I feel it would be good to provide defconfig files for those machines,
but then there are
several options to handle that. Would a minimal hw-focused defconfig
suitable for
`KCONFIG_MODE = "--allnoconfig"` be a good option ?
I feel exactly the same way.

By default all arm64 kernels are configured with the one, in-kernel, generic
arm64 defconfig. That gives me a kernel that is over 11MB in size, and
includes all sorts of useless drivers.

I've been working off-and-on on a mechanism for meta-rockchip that would allow
users to decide between the default in-kernel arm64 defconfig (which would
be selected by doing nothing) or using a leaner defconfig that I have been
tweaking specifically for each board. Currently I only have a lean defconfig
for rock-pi-4b, but it was my hope to generate defconfigs for all supported
boards.

Ideally I had wanted to leverage the linux-yocto kmeta mechanism to generate
defconfigs dynamically based on the specific machine and specific user
preferences, but that didn't go as smoothly as I was hoping, then I got
distracted by other things.

I had created a spreadsheet with a comparison between the various boards that
would have been a basis for the individual kmeta pieces. Maybe I'll find some
more time to poke at it later this week. I could also push my WIP stuff to
somewhere if you'd like to take a look.

In any case, my point is, I'm very interested in something better than what
currently exists :-)
On my side I have a minimal defconfig for our own board, which is very similar
to the nanopi-m4, which could be used as a starting point for the latter.


One thing that I'd like to keep clear in meta-rockchip is to always allow the
user to choose between upstream and "extras". My feeling is: the simplest
build, if the user does nothing explicit, will always pull from pure upstream
with no out-of-tree patches or vendor pieces. But I'm not opposed to having
a mechanism whereby if the user does something explicit, they can choose to
use a vendor tree or make use of out-of-tree patches for various things.
One possibility would be using a KERNEL_CONFIG_VARIANT variable, whose
values would select consistent sets of KBUILD_DEFCONFIG + KCONFIG_MODE
+ SRC_URI_append. Standard variants could include "mainline" as the
default, and
maybe "customhw" which would bring just the hw features for the board
in allnoconfig
mode.

Or maybe we could try to fit such a selection mechanism in the PACKAGECONFIG
system, but I'm not sure it would really fit.
The above (if I'm reading it correctly) sounds quite similar to something I
had already started a while back. So I'll go ahead and publish this
work-in-progress. Maybe if I'm lucky it might spark some conversation with
other BSP maintainers.

https://github.com/twoerner/meta-rockchip__twoerner/tree/rockchip-kernel-config-WIP

Here is the text I've added to the README, which I think helps clarify some of
my points:

Kernel configuration:
--------------------
When it comes to configuring the kernel, allow the user to choose between:
1. using the in-kernel defconfig
2. using an in-layer defconfig + config fragments

The in-kernel defconfig is a very generic configuration meant to build a
kernel that could (theoretically) be run on a wide variety of devices of
the same architecture. I.e. a kernel built for one aarch64 machine (e.g.
the Qualcomm-based DragonBoard 410c) could be used without modification on
a completely different aarch64 machine (e.g. an Amlogic-based Odroid-C4). As
you can imagine, the in-kernel configuration generates a very large kernel.
Currently the in-kernel defconfig produces a kernel that is roughly 12MB.

The in-layer defconfig + config fragments is meant to trim down the kernel
configuration to remove all the hardware settings that aren't relevant to the
specific MACHINE being built. I.e. a kernel built for the rock-pi-4b wouldn't
include, for example, Qualcomm-specific drivers or code.

Currently, option #2 is only available for the following MACHINE(s):
- rock-pi-4b

The user indicates their intent via the RK_KERNEL_CONFIG_TYPE variable. If
the user does nothing, the default behaviour is to use the in-kernel
defconfig. If the user sets
RK_KERNEL_CONFIG_TYPE = "inlayer"
then the in-layer defconfig + config fragments will be used.

At this point I don't have everything that I'm wishing for. I had started to
try to add everything that I've wanted, but it wasn't working, so I pulled
back and only committed the parts that I was able to get working.

Right now the user can toggle between the generic in-kernel defconfig, or a
leaner defconfig that I've defined by playing with the RK_KERNEL_CONFIG_TYPE
variable (in local.conf, for example). Right now I've only done that for the
rock-pi-4b, but ideally I'd add others as time goes on.

I think it'll always be good to allow users to choose between the in-kernel
defconfig and something custom. We'll always want to be able to say "does it
work with the in-kernel defconfig?".

But better yet, instead of one big monolithic defconfig per board, ideally the
meta-rockchip BSP layer would contain a whole bunch of little kernel config
fragments for turning on just one thing. For example, there would be a kernel
config fragment for turning on basic Rockchip support, another one to enable
the RK808 pmic, and another one for the RK805 pmic. Others config fragments
would enable various ethernet options, wifi, bluetooth, etc. One would enable
the ES8388 audio codec (found on the rock2-square) and another would enable
just the ES8316 audio codec (the one found on the rock-pi-4).

Then, various parts on the configuration would enable the relevant kernel
config fragments. Simply selecting, for example, rock-pi-e, would include
the include/rk3328.inc, which would pull in basic rockchip/rk3328 support
and some other default things. The rock-pi-e.conf would pull in the correct
networking/bt options, and select the RK805 pmic. Eventually all the little
fragments would be pulled in that would be necessary to generate the whole
defconfig for this board.

That's the dream, anyway :-/
That sound fine :)

I think we can even do something like this with just standard-looking
overrides and no
specific anonymous python. I'm thinking of something like (including
non-arm things, after all
there's no reason to reserve such a mechanism to the arm/rk world):

# how the kernel defconfigs are named
KBUILD_DEFCONFIG_inkernel = "defconfig"
KBUILD_DEFCONFIG_inkernel_x86-64 = "x86_64_defconfig"
# how the layer defconfigs are named
KBUILD_DEFCONFIG_inlayer = "defconfig"

RK_KERNEL_CONFIG_TYPE = "inlayer"

KBUILD_DEFCONFIG = "${KBUILD_DEFCONFIG_${RK_KERNEL_CONFIG_TYPE}}"

RK_KERNEL_CONFIG_URIS_inkernel = ""
RK_KERNEL_CONFIG_URIS_inlayer = "file://defconfig file://soc.cfg
file://board.cfg"

SRC_URI_append = "${RK_KERNEL_CONFIG_URIS_${RK_KERNEL_CONFIG_TYPE}}"


Then we could have in the recipe files:
- a single defconfig for all rockchip
- per-soc, eg. rk3399/soc.cfg
- per-machine, eg. nanopi-m4/board.cfg

How does that sound ?


Technically, this information could be gleaned from the device tree for this
board… :-S

Then we'll need to take a look at all the DT overlays to see how to
incorporate them as well. Most of these boards have the "Raspberry Pi" 40-pin
interface, so users will expect to be able to reconfigure the pins for the
various alternate devices.
--
Yann Dirson <yann@...>
Blade / Shadow -- http://shadow.tech



--
Yann Dirson <yann@...>
Blade / Shadow -- http://shadow.tech
[meta-rockchip][PATCH v2 0/4] kmeta BSP for nanopi-m4

Yann Dirson
 

From: Yann Dirson <yann@...>

This second iteration adds support for KBUILD_DEFCONFIG=3D"", as well as
a loosely-related patch to avoid touching KCONFIG_MODE.

Kernel weight:
- standard 11MB
- tiny 5MB
- tiny with no defconfig 2.5MB

Changes in v2:
- added explicit CONFIG_PHYLIB and CONFIG_MMC to support empty defconfig
- added CONFIG_SPI_ROCKCHIP

Yann Dirson (4):
linux-yocto: reduce bbappend duplication
rockchip-defaults: don't force KCONFIG_MODE to alldefconfig
NanoPi-M4: let all variants use the same KMACHINE type
WIP linux-yocto: add a NanoPi-M4 BSP

conf/machine/include/nanopi-m4.inc | 1 +
conf/machine/include/rockchip-defaults.inc | 1 -
...cto-dev.bbappend =3D> linux-yocto%.bbappend} | 6 +++
.../linux/linux-yocto-rt_%.bbappend | 10 ----
.../linux/linux-yocto-tiny_%.bbappend | 10 ----
.../linux-yocto/bsp/nanopi-m4-standard.scc | 7 +++
.../linux/linux-yocto/bsp/nanopi-m4-tiny.scc | 7 +++
.../linux/linux-yocto/bsp/nanopi-m4.cfg | 40 ++++++++++++++
.../linux/linux-yocto/bsp/nanopi-m4.scc | 5 ++
.../linux/linux-yocto/bsp/rk3399.cfg | 50 +++++++++++++++++
.../linux/linux-yocto/bsp/rk3399.scc | 5 ++
.../linux/linux-yocto/bsp/rockchip.cfg | 53 +++++++++++++++++++
.../linux/linux-yocto/bsp/rockchip.scc | 6 +++
recipes-kernel/linux/linux-yocto_%.bbappend | 10 ----
14 files changed, 180 insertions(+), 31 deletions(-)
rename recipes-kernel/linux/{linux-yocto-dev.bbappend =3D> linux-yocto%.=
bbappend} (80%)
delete mode 100644 recipes-kernel/linux/linux-yocto-rt_%.bbappend
delete mode 100644 recipes-kernel/linux/linux-yocto-tiny_%.bbappend
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standa=
rd.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.s=
cc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rk3399.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rk3399.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rockchip.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rockchip.scc
delete mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend

--=20
2.30.2
[meta-rockchip][PATCH v2 4/4] WIP linux-yocto: add a NanoPi-M4 BSP

Yann Dirson
 

From: Yann Dirson <yann@...>

This patch provides "standard" and "tiny" BSP.

There is still much work to be done in dispatching feature to individual
scc files - the more boards we can support the better it will get.
Not all SoC features are covered yet either.

Tiny is not really testable by itself today, I played with it using:

PREFERRED_PROVIDER_virtual/kernel =3D "linux-yocto-tiny"
KERNEL_FEATURES_append =3D "\
ktypes/base/base.scc \
features/debug/printk.scc \
cfg/fs/ext4.scc \
"

Such a tiny build is still using mainline defconfig with lots of hardware
features, and the kernel can be slimmed down even more by using:

KBUILD_DEFCONFIG =3D ""

Kernel weight:
- standard 11MB
- tiny 5MB
- tiny with no defconfig 2.5MB

Changes in v2:
- added explicit CONFIG_PHYLIB and CONFIG_MMC to support empty defconfig
- added CONFIG_SPI_ROCKCHIP
---
recipes-kernel/linux/linux-yocto%.bbappend | 6 +++
.../linux-yocto/bsp/nanopi-m4-standard.scc | 7 +++
.../linux/linux-yocto/bsp/nanopi-m4-tiny.scc | 7 +++
.../linux/linux-yocto/bsp/nanopi-m4.cfg | 40 ++++++++++++++
.../linux/linux-yocto/bsp/nanopi-m4.scc | 5 ++
.../linux/linux-yocto/bsp/rk3399.cfg | 50 +++++++++++++++++
.../linux/linux-yocto/bsp/rk3399.scc | 5 ++
.../linux/linux-yocto/bsp/rockchip.cfg | 53 +++++++++++++++++++
.../linux/linux-yocto/bsp/rockchip.scc | 6 +++
9 files changed, 179 insertions(+)
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standa=
rd.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.s=
cc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rk3399.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rk3399.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rockchip.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rockchip.scc

diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/=
linux/linux-yocto%.bbappend
index 0bc13d7..99cfc5f 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -1,3 +1,9 @@
+FILESEXTRAPATHS_prepend :=3D "${THISDIR}/linux-yocto:"
+
+SRC_URI_append =3D "\
+ file://bsp;type=3Dkmeta;subdir=3Dkernel-meta \
+"
+
COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
COMPATIBLE_MACHINE_radxarock =3D "radxarock"
diff --git a/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standard.scc =
b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standard.scc
new file mode 100644
index 0000000..5c74d6b
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standard.scc
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: MIT
+define KMACHINE nanopi-m4
+define KTYPE standard
+define KARCH arm
+
+include ktypes/standard/standard.scc
+include nanopi-m4.scc
diff --git a/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.scc b/re=
cipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.scc
new file mode 100644
index 0000000..6e94d6a
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.scc
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: MIT
+define KMACHINE nanopi-m4
+define KTYPE tiny
+define KARCH arm
+
+include ktypes/tiny/tiny.scc
+include nanopi-m4.scc
diff --git a/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg b/recipes=
-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg
new file mode 100644
index 0000000..5864008
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg
@@ -0,0 +1,40 @@
+CONFIG_MFD_RK808=3Dy
+CONFIG_COMMON_CLK_RK808=3Dy
+
+# regulators
+CONFIG_REGULATOR_RK808=3Dy
+CONFIG_REGULATOR_FAN53555=3Dy
+
+CONFIG_MMC_BLOCK=3Dy
+
+# audio jack
+CONFIG_SND_SOC_ROCKCHIP_RT5651=3Dm
+
+# BT, maybe some - RFCOMM for headset voice, MSFTEXT ?
+CONFIG_BT=3Dm
+#CONFIG_BT_BCM=3Dm
+#CONFIG_BT_HCIUART_BCM=3Dm
+CONFIG_BT_RFCOMM=3Dm
+CONFIG_BT_RFCOMM_TTY=3Dy
+CONFIG_BT_BNEP=3Dm
+CONFIG_BT_HS=3Dy
+CONFIG_BT_LE=3Dy
+CONFIG_BT_MSFTEXT=3Dy
+CONFIG_BT_DEBUGFS=3Dy
+CONFIG_WIRELESS=3Dy
+CONFIG_RFKILL=3Dm
+
+CONFIG_PHY_ROCKCHIP_DP=3Dy
+
+CONFIG_VIDEO_DEV=3Dm
+CONFIG_V4L_MEM2MEM_DRIVERS=3Dy
+CONFIG_VIDEO_ROCKCHIP_RGA=3Dm
+
+CONFIG_DRM_DW_HDMI_AHB_AUDIO=3Dm
+CONFIG_SND_SOC_RK3288_HDMI_ANALOG=3Dm
+
+CONFIG_V4L2_H264=3Dm
+CONFIG_MEDIA_CONTROLLER_REQUEST_API=3Dy
+CONFIG_VIDEO_HANTRO=3Dm
+CONFIG_VIDEO_HANTRO_ROCKCHIP=3Dy
+CONFIG_VIDEO_ROCKCHIP_VDEC=3Dm
diff --git a/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.scc b/recipes=
-kernel/linux/linux-yocto/bsp/nanopi-m4.scc
new file mode 100644
index 0000000..f4267aa
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.scc
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware nanopi-m4.cfg
+
+include rk3399.scc
diff --git a/recipes-kernel/linux/linux-yocto/bsp/rk3399.cfg b/recipes-ke=
rnel/linux/linux-yocto/bsp/rk3399.cfg
new file mode 100644
index 0000000..b0002f4
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/rk3399.cfg
@@ -0,0 +1,50 @@
+# A72 errata, all past revisions
+CONFIG_ARM64_ERRATUM_1319367=3Dy
+# A53 errata, all patched on boot when needed
+CONFIG_ARM64_ERRATUM_826319=3Dy
+CONFIG_ARM64_ERRATUM_827319=3Dy
+CONFIG_ARM64_ERRATUM_824069=3Dy
+CONFIG_ARM64_ERRATUM_819472=3Dy
+
+# cru
+CONFIG_CLK_RK3399=3Dy
+
+CONFIG_PL330_DMA=3Dy
+CONFIG_I2C_RK3X=3Dy
+CONFIG_SERIAL_8250_DW=3Dy
+
+# usb
+CONFIG_PHY_ROCKCHIP_INNO_USB2=3Dy
+CONFIG_PHY_ROCKCHIP_TYPEC=3Dy
+
+# ethernet
+CONFIG_NET_VENDOR_STMICRO=3Dy
+CONFIG_STMMAC_ETH=3Dm
+CONFIG_STMMAC_PLATFORM=3Dm
+CONFIG_DWMAC_ROCKCHIP=3Dm
+CONFIG_PHYLIB=3Dm
+CONFIG_ROCKCHIP_PHY=3Dm
+
+# display
+CONFIG_ROCKCHIP_DW_HDMI=3Dy
+CONFIG_ROCKCHIP_DW_MIPI_DSI=3Dy
+CONFIG_ROCKCHIP_ANALOGIX_DP=3Dy
+CONFIG_ROCKCHIP_CDN_DP=3Dy
+CONFIG_DRM_DW_HDMI=3Dm
+CONFIG_DRM_DW_HDMI_I2S_AUDIO=3Dm
+CONFIG_DRM_DW_HDMI_CEC=3Dm
+CONFIG_DRM_DW_MIPI_DSI=3Dm
+CONFIG_DRM_PANFROST=3Dm
+
+# usb
+CONFIG_USB_DWC2=3Dy
+CONFIG_USB_DWC3=3Dy
+CONFIG_USB_DWC3_DUAL_ROLE=3Dy
+
+# sd/mmc
+CONFIG_MMC=3Dy
+CONFIG_MMC_SDHCI=3Dy
+CONFIG_MMC_SDHCI_PLTFM=3Dy
+CONFIG_MMC_DW=3Dy
+CONFIG_MMC_DW_ROCKCHIP=3Dy
+CONFIG_MMC_SDHCI_OF_ARASAN=3Dy
diff --git a/recipes-kernel/linux/linux-yocto/bsp/rk3399.scc b/recipes-ke=
rnel/linux/linux-yocto/bsp/rk3399.scc
new file mode 100644
index 0000000..9b1a88e
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/rk3399.scc
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware rk3399.cfg
+
+include rockchip.scc
diff --git a/recipes-kernel/linux/linux-yocto/bsp/rockchip.cfg b/recipes-=
kernel/linux/linux-yocto/bsp/rockchip.cfg
new file mode 100644
index 0000000..0c91a1a
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/rockchip.cfg
@@ -0,0 +1,53 @@
+CONFIG_ARCH_ROCKCHIP=3Dy
+CONFIG_COMMON_CLK_ROCKCHIP=3Dy
+CONFIG_REGULATOR=3Dy
+CONFIG_REGULATOR_FIXED_VOLTAGE=3Dy
+CONFIG_REGULATOR_PWM=3Dy
+CONFIG_I2C=3Dy
+CONFIG_FW_LOADER=3Dy
+CONFIG_PHY_ROCKCHIP_EMMC=3Dy
+CONFIG_PINCTRL=3Dy
+CONFIG_PINCTRL_ROCKCHIP=3Dy
+CONFIG_ROCKCHIP_IODOMAIN=3Dy
+CONFIG_ROCKCHIP_PM_DOMAINS=3Dy
+
+CONFIG_SPI=3Dy
+CONFIG_SPI_ROCKCHIP=3Dm
+
+CONFIG_PWM=3Dy
+CONFIG_PWM_ROCKCHIP=3Dy
+
+CONFIG_DRM_KMS_HELPER=3Dm
+CONFIG_DRM_FBDEV_EMULATION=3Dy
+CONFIG_ROCKCHIP_IOMMU=3Dy
+CONFIG_DRM_ROCKCHIP=3Dm
+CONFIG_DRM_BRIDGE=3Dy
+
+CONFIG_SND=3Dy
+CONFIG_SND_SOC=3Dy
+CONFIG_SND_HDA_CODEC_HDMI=3Dm
+CONFIG_SND_SOC_ROCKCHIP=3Dm
+CONFIG_SND_SOC_ROCKCHIP_I2S=3Dm
+CONFIG_SND_SOC_ROCKCHIP_SPDIF=3Dm
+
+CONFIG_NVMEM=3Dy
+CONFIG_ROCKCHIP_EFUSE=3Dm
+
+CONFIG_CPU_FREQ=3Dy
+
+# maybe?
+CONFIG_MFD_SYSCON=3Dy
+CONFIG_FB_MODE_HELPERS=3Dy
+
+# possibly for somewhere else
+CONFIG_DRM=3Dm
+CONFIG_DRM_MIPI_DSI=3Dy
+CONFIG_SOUND=3Dy
+CONFIG_USB=3Dy
+CONFIG_SERIAL_8250=3Dy
+CONFIG_SERIAL_8250_CONSOLE=3Dy
+
+# obviously for somewhere else
+CONFIG_MULTIUSER=3Dy
+CONFIG_TTY=3Dy
+CONFIG_SERIAL_EARLYCON=3Dy
diff --git a/recipes-kernel/linux/linux-yocto/bsp/rockchip.scc b/recipes-=
kernel/linux/linux-yocto/bsp/rockchip.scc
new file mode 100644
index 0000000..800f105
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/rockchip.scc
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware rockchip.cfg
+
+include cfg/dmaengine.scc
+include features/mmc/mmc-block.cfg
--=20
2.30.2
[meta-rockchip][PATCH v2 3/4] NanoPi-M4: let all variants use the same KMACHINE type

Yann Dirson
 

From: Yann Dirson <yann@...>

Signed-off-by: Yann Dirson <yann@...>
---
conf/machine/include/nanopi-m4.inc | 1 +
1 file changed, 1 insertion(+)

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/na=
nopi-m4.inc
index 74cdae8..603160f 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
@@ -3,6 +3,7 @@
=20
require rk3399.inc
=20
+KMACHINE =3D "nanopi-m4"
KERNEL_DEVICETREE =3D "rockchip/rk3399-nanopi-m4.dtb"
=20
RK_BOOT_DEVICE =3D "mmcblk1"
--=20
2.30.2
[meta-rockchip][PATCH v2 1/4] linux-yocto: reduce bbappend duplication

Yann Dirson
 

From: Yann Dirson <yann@...>

Signed-off-by: Yann Dirson <yann@...>
---
...{linux-yocto-dev.bbappend =3D> linux-yocto%.bbappend} | 0
recipes-kernel/linux/linux-yocto-rt_%.bbappend | 10 ----------
recipes-kernel/linux/linux-yocto-tiny_%.bbappend | 10 ----------
recipes-kernel/linux/linux-yocto_%.bbappend | 10 ----------
4 files changed, 30 deletions(-)
rename recipes-kernel/linux/{linux-yocto-dev.bbappend =3D> linux-yocto%.=
bbappend} (100%)
delete mode 100644 recipes-kernel/linux/linux-yocto-rt_%.bbappend
delete mode 100644 recipes-kernel/linux/linux-yocto-tiny_%.bbappend
delete mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend

diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kern=
el/linux/linux-yocto%.bbappend
similarity index 100%
rename from recipes-kernel/linux/linux-yocto-dev.bbappend
rename to recipes-kernel/linux/linux-yocto%.bbappend
diff --git a/recipes-kernel/linux/linux-yocto-rt_%.bbappend b/recipes-ker=
nel/linux/linux-yocto-rt_%.bbappend
deleted file mode 100644
index 7702e3f..0000000
--- a/recipes-kernel/linux/linux-yocto-rt_%.bbappend
+++ /dev/null
@@ -1,10 +0,0 @@
-COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
-COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
-COMPATIBLE_MACHINE_radxarock =3D "radxarock"
-COMPATIBLE_MACHINE_firefly-rk3288 =3D "firefly-rk3288"
-COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
-COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
-COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
-COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
-COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
-COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend b/recipes-k=
ernel/linux/linux-yocto-tiny_%.bbappend
deleted file mode 100644
index 7702e3f..0000000
--- a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
+++ /dev/null
@@ -1,10 +0,0 @@
-COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
-COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
-COMPATIBLE_MACHINE_radxarock =3D "radxarock"
-COMPATIBLE_MACHINE_firefly-rk3288 =3D "firefly-rk3288"
-COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
-COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
-COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
-COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
-COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
-COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel=
/linux/linux-yocto_%.bbappend
deleted file mode 100644
index 7702e3f..0000000
--- a/recipes-kernel/linux/linux-yocto_%.bbappend
+++ /dev/null
@@ -1,10 +0,0 @@
-COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
-COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
-COMPATIBLE_MACHINE_radxarock =3D "radxarock"
-COMPATIBLE_MACHINE_firefly-rk3288 =3D "firefly-rk3288"
-COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
-COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
-COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
-COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
-COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
-COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
--=20
2.30.2
[meta-rockchip][PATCH v2 2/4] rockchip-defaults: don't force KCONFIG_MODE to alldefconfig

Yann Dirson
 

From: Yann Dirson <yann@...>

When using in-kernel defconfig this is already the default, but
linux-yocto defaults to "allnoconfig" mode when a defconfig is
specified in SRC_URI, and there is no reason to override this
globally.
---
conf/machine/include/rockchip-defaults.inc | 1 -
1 file changed, 1 deletion(-)

diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/in=
clude/rockchip-defaults.inc
index a4e2a2c..17d1d0b 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -2,7 +2,6 @@
=20
# kernel
PREFERRED_PROVIDER_virtual/kernel ?=3D "linux-yocto"
-KCONFIG_MODE ?=3D "alldefconfig"
LINUX_VERSION_EXTENSION ?=3D "-rockchip"
=20
# xserver
--=20
2.30.2
BeagleBone Black wig image does not boot

Konstantin Kletschke
 

Hi all,

I successfully compile/create a target image and binaries for a BeagleBone Black:

MACHINE ?= "beaglebone-yocto"

The resulting wic image does not boot, when I write it to a sdcard nor when I write it directly into the internal /dev/mmcblk0. There is no console output despite of some capital "C" sometimes (the internal boot loader-loader failing to find u-boot?).
The image looks rather healthy, though:

fdisk p output:

Disk core-image-base-beaglebone-yocto-20210331083925.rootfs.wic: 1 GiB, 1098599424 bytes, 2145702 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa63a46ea

Device Boot Start End Sectors Size Id Type
core-image-base-beaglebone-yocto-20210331083925.rootfs.wic1 * 8 49065 49058 24M c W95 FAT32 (LBA)
core-image-base-beaglebone-yocto-20210331083925.rootfs.wic2 49072 2145701 2096630 1023.8M 83 Linux

ls -la of the mounted first boot partition:

insidem2m@konsti ~/Y $ ls -la /mnt
total 8648
drwxr-xr-x 3 root root 16384 Jan 1 1970 .
drwxr-xr-x 17 root root 4096 Mar 4 12:06 ..
-rwxr-xr-x 1 root root 107940 Apr 6 2011 MLO
-rwxr-xr-x 1 root root 59303 Apr 6 2011 am335x-bone.dtb
-rwxr-xr-x 1 root root 62629 Apr 6 2011 am335x-boneblack.dtb
-rwxr-xr-x 1 root root 59567 Apr 6 2011 am335x-bonegreen.dtb
drwxr-xr-x 2 root root 2048 Apr 6 2011 extlinux
-rwxr-xr-x 1 root root 892736 Apr 6 2011 u-boot.img
-rwxr-xr-x 1 root root 7645608 Apr 6 2011 zImage



The strange thing is, when I prepare a sdcard (or the internal flash!) with partitions manually, format manually and copy the same kernel and u-boot binaries into the first and the rootfs into the second partition, the system works fine!


Since the complete Image layout looks fine to me, what could be the culprit of that?

Kind Regards
Konsti
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.2.3.rc1)

Sangeeta Jain
 

Hello All,

This is the full report for yocto-3.2.3.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

No new issues found


Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Pokybuild User
Sent: Monday, 29 March, 2021 11:49 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.2.3.rc1)


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


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


Build hash information:

bitbake: 5d02c98489d3a5836676b9c3fb3bd0157449db2b
meta-arm: e219ef606e297b98512887c96522d8d8c536bd6b
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: 76e0a427e58d068d0758fa052d2d1548067cf592
meta-kernel: 29329d7cacc71595cecfdd05a455a0cfb164564d
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: fdae970656cc421c542af9856bc9ae038c61db13
poky: 08665a81dcd41069eed1468f1587abe6b5893471



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

Mauro Ziliani
 

Hi all.

I make two images  image1  image1-installer
In image1 I don't need any getty so i'd like to put SYSVINIT_ENALED_GETTYS := ""

image1.bb give the output image1.sdcard
SYSVINIT_ENABLED_GETTYS := "2"
IMAGE_INSTALL_append = "sysvinit-inittab "

This is /etc/inittab i'd like inside image1.sdcard

2:2345:respawn:/sbin/getty 38400 tty2



In image1-installer I need only getty1 so i'd like to setup SYSVINIT_ENABLED GETTYS := "1"

image1-installer.bb give the output image1-installer.sdcard
SYSVINIT_ENABLED_GETTYS := "1"
IMAGE_INSTALL_append = " sysvinit-inittab "

The  /etc/inittab in image1-installer.sdcard contains

1:2345:respawn:/sbin/getty 38400 tty1


There is a way to "configure" sysvinit-inittab_%.bb to make a different output using a PACKAGECONFIG o others variables?

By now I have setup SYSVINIT_ENABLED_GETTYS := "" and than add  2:2345:respawn:/sbin/getty 38400 tty2 or 1:2345:respawn:/sbin/getty 38400 tty1 in the recipe


There is another way?


MZ







Sent from Mailspring, the best free email app for work
what is the state of upcoming(?) NXP S32G2xx support; layer, BSP?

Robert P. J. Day
 

i note that the linux-yocto repo has a nxp-s32g2xx branch:


https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx

so wondering about the subsequent BSP layer, from NXP or
elsewhere. thoughts?

rday
Re: Yocto Technical Team Minutes, Engineering Sync, for Mar 30, 2021

Nicolas Dechesne
 

On Wed, Mar 31, 2021 at 4:25 PM Trevor Woerner <twoerner@...> wrote:

Yocto Technical Team Minutes, Engineering Sync, for March 30, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Armin Kuster, Richard Purdie, Randy
MacLeod, Jan-Simon Möller, Trevor Gamblin, Tim Orling, Michael Halstead,
Paul Barker, Jon Mason, Joshua Watt, Steven Sakoman, Saul Wold, Scott
Murray, Khem Raj, Peter Kjellerstedt (saur), Ross Burton, Michael
Opdenacker

== notes ==
- 3.2-m3 released
- -m4 being built this week, no more update patches

== general ==
Randy: got info collection thingy working on AB thanks to help from SS and
integrated into results
RP: have you had a chance to look at my theory
Randy: not yet
RP: io-nice doesn’t change async write (I think AlexK pointed this out). we
do nice levels for all processes and io-nice for things that write, it’s
possible that this is where we’re hitting the io block. we might want to
try doing some builds under qemu (then we can enforce more nice levels) as
a means of investigating this issue


RP: the valgrind stuff seems to be testing well in master-next, but i will
defer those to -m4
RP: the -m4 build date is, technically, monday, anything else to include?
Randy: lttng modules?


Khem: i have gcc-11 patches, probably not for -m4, but if the AB has cycles
can i send them up?
RP: on the one hand i’d prefer to not do multiple things at the same time,
on the other hand i can’t stop people from sending new features
Khem: i can hold off a bit. i could send an RFC. yocto project has already
submitted gcc-11 patches and i’m looking to expand the testing on it
RP: any issues for -native recipes?
Khem: i’ve found a bunch already and upstreamed them, any that weren’t
accepted in the upstream project have been put into oe-core


Peter: what about the covered/not-covered (on runqueue) issue
RP: i have drafted a patch and is in master-next. it doesn’t appear to break
anything, but proving it fixes things is hard. have you seen the problem
after adding that patch?
Peter: no
SS: i had seen it on 3 builds, and haven’t seen them again either
RP: trying to reproduce an exact same build (wrt sstate, runqueues, etc) is
hard, so it’s hard to know if we’ve solved it


Khem: in the past we’ve seen issues with bitbake running forever due to
“make -l” issue. so we removed it. but we still see long builds with
qemarm
Randy: how much longer?
Khem: (guessing) 30%
Randy: qemuarm64 too?
Khem: no, just qemuarm. same number of CPUs, same underlying machine
Jon: qemuarmv5 as well?
Khem: no
Jon: maybe it’s a qemuarm hardfloat issue. i’ll try to reproduce it
Khem: i’m building lots of stuff, not just the basics. mostly doing world
builds, so maybe it’s a particular package
<various>: we can give it a try
RP: maybe by dropping the -l you’ve introduced something else (e.g. swapping)
Khem: but no other qemu’s are affected. most builds finish in 10 hours,
but qemuarm gets killed after 13 hours (due to a timeout) which is why i
notice it (because it gets killed)
RP: it would be interesting to look at the build stats data then compare build
times recipe-to-recipe
Randy: is there a bug filed?
Khem: not yet, i can file a tracking bug


TimO: Ross asked me about splitting meta-python out to standalone layer (from
meta-openembedded). would allow us to use dynamic layers. might help with
ptest coverage. it might might other workflows possible (i.e. move it
to gitlab and use their things). some have offered strong opinions that
it’s just splitting for splitting sake
RP: i think splitting out would be good. there’s lots of burnout and it
would be great to spread the load a bit more (instead of making one person
responsible for all meta-oe)
TrevorG: having to share the support with the rest of meta-oe is hard
TimO: Khem had asked us to move to a PR mechanism
JPEW: this subset feels like the best one to be pulled out (as a test)
TimO: true, meta-perl might be a good candidate too. in any case i would start
with dunfell, but nothing before that
I think this is a really good discussion, but I wonder why you want to
go back in time.. I expect users of dunfell branch (which is an LTS
from YP perspectives) would be rather unhappy to see such a major
change in their stable builds. I think it's a change for master only,
so either now before the next release or a change for the Oct release,
no?

Khem: have you considered this from the users point of view. obviously we’re
thinking more of the maintenance point of view but let’s not forget to
seek user input
TimO: obviously it’s going to impact users, they’ll need to change URIs
and bblayers
PaulB: just make sure the layer index gets updated and we could leave a stub
behind that points the user to the change
RP: (same)
Khem: i also think it would help if these layers have separate mailing list.
it’s hard for users to know where to send patches (especially poky). so
instead of using mete-oe as a kitchen sink
TimO: i’ve always wished for a separate mailing list. i’ve had to do lots
of filtering but it doesn’t catch everything
Khem: good to bring to TSC and community to get input
TimO: it’s fairly quick to split this out. mechanics aren’t a problem
Armin: looking at layers that depend on meta-python, do you think they would
change to dynamic layers? meta-networking and meta-multimedia depend on
meta-python, so splitting it out would require pulling it in for many
use-cases
RP: i wouldn't get too worried about the details, everything could be
solved, let’s not worry about all possibilities, when only some might
come to pass. i think more layers is good, maybe it opens up the ability
to use the AB for some of this stuff (as stuff gets smaller)
Randy: so the reasons for are:
1. burden on maintainers
2. quality and test coverage
?
TimO: also simplification (if you want some python you don’t need all of
meta-oe)
RP: i see dependency creep in external layers (since you have to pull in
meta-oe for meta-python then we might as well pull in all these other
things too that we’re already getting in meta-oe)
Randy: do we want to see everything in meta-oe split up, or other splits in
oe-core?
RP: case by case, there’s pros and cons
Randy: what about incremental transition vs a full change-over
TimO: i want to make sure all the ptests are in place first, and there’s the
question of review
Khem: why can’t we add ptests now? (i.e. in meta-oe)
TimO: i’d *like* to add more ptests, but doesn’t mean we will/should
Khem: propose it and see what the feedback is. people are making products with
this and we should make sure to move forward in a way the impacts them in
a way they’re happy with
TimO: 10 people will provide 20 opinions
RP: we can do a POC and move forward
TimO: we’ve talked about it so much over the years and we never agree on
trying a change, maybe people can’t see the benefit until they actually
try it
Randy: could this live on git.yoctoproject.org
TimO: maybe git.openembedded.org instead
Randy: would you track bugs on YP bugzilla
RP: where to host is irrelevant, but there are larger issues (such as better
AB usage, maintainer question, burnout, mailing lists)
Khem: lots of people listed as maintainers of individual packages, but little
actual maintainer help. how many maintainers actually review and help?
RP: the same problem exists in oe-core. there are some that are active, but in
the end it’s usually AlexK that does the upgrades
TimO: it could be an issue of timing, sometime you don’t get to it in a
day and someone else does it. with unlimited resources we would use yp
bugzilla, but there are consequences to the members
Randy: do you want more layers removed too?
Khem: yes, that would be great. i’m not maintainer by choice, then i could
sign up to maintain what matters to me
TrevorG: if we do it now with meta-python, then it lets us know if we should
go ahead and do it with others too
RP: yes, good experiment and we can roll it back. meta-python looks like it
would be a good test
TimO: i have tools that make it easy to do, and then easy to roll back. and
the tools are not just meta-python-specific, they could be used for any
sub-layer


TrevorW: there is a Yocto Project related virtual conference being planned:
https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
TrevorW: the CfP is now open:
https://pretalx.com/yocto-project-summit-2021/cfp
Speed up the build

Mauro Ziliani
 

Hi all

I need to speedup the build.
I use package_deb as package method.

I see that the bottlenek is gzip
When yocto runs gzip the cpu runs to 100%, with xz 600% (the pc has 6 core (12threads))

I'd like to use pigz to parallelize "gzip" too.

Is it possible?

MZ
Sent from Mailspring
Yocto Technical Team Minutes, Engineering Sync, for Mar 30, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for March 30, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Armin Kuster, Richard Purdie, Randy
MacLeod, Jan-Simon Möller, Trevor Gamblin, Tim Orling, Michael Halstead,
Paul Barker, Jon Mason, Joshua Watt, Steven Sakoman, Saul Wold, Scott
Murray, Khem Raj, Peter Kjellerstedt (saur), Ross Burton, Michael
Opdenacker

== notes ==
- 3.2-m3 released
- -m4 being built this week, no more update patches

== general ==
Randy: got info collection thingy working on AB thanks to help from SS and
integrated into results
RP: have you had a chance to look at my theory
Randy: not yet
RP: io-nice doesn’t change async write (I think AlexK pointed this out). we
do nice levels for all processes and io-nice for things that write, it’s
possible that this is where we’re hitting the io block. we might want to
try doing some builds under qemu (then we can enforce more nice levels) as
a means of investigating this issue


RP: the valgrind stuff seems to be testing well in master-next, but i will
defer those to -m4
RP: the -m4 build date is, technically, monday, anything else to include?
Randy: lttng modules?


Khem: i have gcc-11 patches, probably not for -m4, but if the AB has cycles
can i send them up?
RP: on the one hand i’d prefer to not do multiple things at the same time,
on the other hand i can’t stop people from sending new features
Khem: i can hold off a bit. i could send an RFC. yocto project has already
submitted gcc-11 patches and i’m looking to expand the testing on it
RP: any issues for -native recipes?
Khem: i’ve found a bunch already and upstreamed them, any that weren’t
accepted in the upstream project have been put into oe-core


Peter: what about the covered/not-covered (on runqueue) issue
RP: i have drafted a patch and is in master-next. it doesn’t appear to break
anything, but proving it fixes things is hard. have you seen the problem
after adding that patch?
Peter: no
SS: i had seen it on 3 builds, and haven’t seen them again either
RP: trying to reproduce an exact same build (wrt sstate, runqueues, etc) is
hard, so it’s hard to know if we’ve solved it


Khem: in the past we’ve seen issues with bitbake running forever due to
“make -l” issue. so we removed it. but we still see long builds with
qemarm
Randy: how much longer?
Khem: (guessing) 30%
Randy: qemuarm64 too?
Khem: no, just qemuarm. same number of CPUs, same underlying machine
Jon: qemuarmv5 as well?
Khem: no
Jon: maybe it’s a qemuarm hardfloat issue. i’ll try to reproduce it
Khem: i’m building lots of stuff, not just the basics. mostly doing world
builds, so maybe it’s a particular package
<various>: we can give it a try
RP: maybe by dropping the -l you’ve introduced something else (e.g. swapping)
Khem: but no other qemu’s are affected. most builds finish in 10 hours,
but qemuarm gets killed after 13 hours (due to a timeout) which is why i
notice it (because it gets killed)
RP: it would be interesting to look at the build stats data then compare build
times recipe-to-recipe
Randy: is there a bug filed?
Khem: not yet, i can file a tracking bug


TimO: Ross asked me about splitting meta-python out to standalone layer (from
meta-openembedded). would allow us to use dynamic layers. might help with
ptest coverage. it might might other workflows possible (i.e. move it
to gitlab and use their things). some have offered strong opinions that
it’s just splitting for splitting sake
RP: i think splitting out would be good. there’s lots of burnout and it
would be great to spread the load a bit more (instead of making one person
responsible for all meta-oe)
TrevorG: having to share the support with the rest of meta-oe is hard
TimO: Khem had asked us to move to a PR mechanism
JPEW: this subset feels like the best one to be pulled out (as a test)
TimO: true, meta-perl might be a good candidate too. in any case i would start
with dunfell, but nothing before that
Khem: have you considered this from the users point of view. obviously we’re
thinking more of the maintenance point of view but let’s not forget to
seek user input
TimO: obviously it’s going to impact users, they’ll need to change URIs
and bblayers
PaulB: just make sure the layer index gets updated and we could leave a stub
behind that points the user to the change
RP: (same)
Khem: i also think it would help if these layers have separate mailing list.
it’s hard for users to know where to send patches (especially poky). so
instead of using mete-oe as a kitchen sink
TimO: i’ve always wished for a separate mailing list. i’ve had to do lots
of filtering but it doesn’t catch everything
Khem: good to bring to TSC and community to get input
TimO: it’s fairly quick to split this out. mechanics aren’t a problem
Armin: looking at layers that depend on meta-python, do you think they would
change to dynamic layers? meta-networking and meta-multimedia depend on
meta-python, so splitting it out would require pulling it in for many
use-cases
RP: i wouldn't get too worried about the details, everything could be
solved, let’s not worry about all possibilities, when only some might
come to pass. i think more layers is good, maybe it opens up the ability
to use the AB for some of this stuff (as stuff gets smaller)
Randy: so the reasons for are:
1. burden on maintainers
2. quality and test coverage
?
TimO: also simplification (if you want some python you don’t need all of
meta-oe)
RP: i see dependency creep in external layers (since you have to pull in
meta-oe for meta-python then we might as well pull in all these other
things too that we’re already getting in meta-oe)
Randy: do we want to see everything in meta-oe split up, or other splits in
oe-core?
RP: case by case, there’s pros and cons
Randy: what about incremental transition vs a full change-over
TimO: i want to make sure all the ptests are in place first, and there’s the
question of review
Khem: why can’t we add ptests now? (i.e. in meta-oe)
TimO: i’d *like* to add more ptests, but doesn’t mean we will/should
Khem: propose it and see what the feedback is. people are making products with
this and we should make sure to move forward in a way the impacts them in
a way they’re happy with
TimO: 10 people will provide 20 opinions
RP: we can do a POC and move forward
TimO: we’ve talked about it so much over the years and we never agree on
trying a change, maybe people can’t see the benefit until they actually
try it
Randy: could this live on git.yoctoproject.org
TimO: maybe git.openembedded.org instead
Randy: would you track bugs on YP bugzilla
RP: where to host is irrelevant, but there are larger issues (such as better
AB usage, maintainer question, burnout, mailing lists)
Khem: lots of people listed as maintainers of individual packages, but little
actual maintainer help. how many maintainers actually review and help?
RP: the same problem exists in oe-core. there are some that are active, but in
the end it’s usually AlexK that does the upgrades
TimO: it could be an issue of timing, sometime you don’t get to it in a
day and someone else does it. with unlimited resources we would use yp
bugzilla, but there are consequences to the members
Randy: do you want more layers removed too?
Khem: yes, that would be great. i’m not maintainer by choice, then i could
sign up to maintain what matters to me
TrevorG: if we do it now with meta-python, then it lets us know if we should
go ahead and do it with others too
RP: yes, good experiment and we can roll it back. meta-python looks like it
would be a good test
TimO: i have tools that make it easy to do, and then easy to roll back. and
the tools are not just meta-python-specific, they could be used for any
sub-layer


TrevorW: there is a Yocto Project related virtual conference being planned:
https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
TrevorW: the CfP is now open:
https://pretalx.com/yocto-project-summit-2021/cfp
Re: How can I use old Package version with latest Yocto version. #cups #zeus

rohit jadhav
 

Thanks @Khem Raj for your valuable response.

As Zeus is not supported with meta-printing Layer . is it feasible to use Zeus in this Scenario?

And For Opencv Package version to use from Krogoth is with zeus is compilable?
[meta-security][PATCH 4/4] swtpm: file pip3 issue

Armin Kuster
 

need native pip3, was using host's

Signed-off-by: Armin Kuster <akuster808@...>
---
meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb b/meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb
index b7ff2ad..c0bd35e 100644
--- a/meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb
+++ b/meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb
@@ -7,7 +7,7 @@ DEPENDS = "libtasn1 coreutils-native expect socat glib-2.0 net-tools-native libt

# configure checks for the tools already during compilation and
# then swtpm_setup needs them at runtime
-DEPENDS += "tpm-tools-native expect-native socat-native"
+DEPENDS += "tpm-tools-native expect-native socat-native python3-pip-native"

SRCREV = "e59c0c1a7b4c8d652dbb280fd6126895a7057464"
SRC_URI = "git://github.com/stefanberger/swtpm.git;branch=stable-0.5 \
@@ -18,7 +18,6 @@ PE = "1"
S = "${WORKDIR}/git"

inherit autotools pkgconfig python3-dir
-PARALLEL_MAKE = ""

TSS_USER="tss"
TSS_GROUP="tss"
--
2.17.1
[meta-security][PATCH 3/4] swtpm: now need python-cryptography, pull in layer

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
meta-tpm/conf/layer.conf | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf
index 65788eb..1b766cb 100644
--- a/meta-tpm/conf/layer.conf
+++ b/meta-tpm/conf/layer.conf
@@ -13,6 +13,7 @@ LAYERSERIES_COMPAT_tpm-layer = "hardknott"
LAYERDEPENDS_tpm-layer = " \
core \
openembedded-layer \
+ meta-python \
"
BBLAYERS_LAYERINDEX_NAME_tpm-layer = "meta-tpm"

--
2.17.1
[meta-security][PATCH 2/4] clamav: fix systemd service install

Armin Kuster
 

ERROR: clamav-0.104.0-r0 do_package: QA Issue: clamav: Files/directories were installed but not shipped in any package:
/lib/systemd/system/clamav-daemon.service
/lib/systemd/system/clamav-clamonacc.service

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-scanners/clamav/clamav_0.104.0.bb | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/recipes-scanners/clamav/clamav_0.104.0.bb b/recipes-scanners/clamav/clamav_0.104.0.bb
index 9e50466..ba036b0 100644
--- a/recipes-scanners/clamav/clamav_0.104.0.bb
+++ b/recipes-scanners/clamav/clamav_0.104.0.bb
@@ -105,7 +105,10 @@ FILES_${PN}-daemon = "${bindir}/clamconf ${bindir}/clamdtop ${sbindir}/clamd \
/usr/etc/clamd.conf* \
${systemd_unitdir}/system/clamav-daemon/* \
${docdir}/clamav-daemon/* ${sysconfdir}/clamav-daemon \
- ${sysconfdir}/logcheck/ignore.d.server/clamav-daemon "
+ ${sysconfdir}/logcheck/ignore.d.server/clamav-daemon \
+ ${systemd_unitdir}/system/clamav-daemon.service \
+ ${systemd_unitdir}/system/clamav-clamonacc.service \
+ "

FILES_${PN}-freshclam = "${bindir}/freshclam \
${sysconfdir}/freshclam.conf* \
--
2.17.1
[meta-security][PATCH 1/4] python3-privacyidea: upgrade 3.5.1 -> 3.5.2

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
...ython3-privacyidea_3.5.1.bb => python3-privacyidea_3.5.2.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename recipes-security/mfa/{python3-privacyidea_3.5.1.bb => python3-privacyidea_3.5.2.bb} (96%)

diff --git a/recipes-security/mfa/python3-privacyidea_3.5.1.bb b/recipes-security/mfa/python3-privacyidea_3.5.2.bb
similarity index 96%
rename from recipes-security/mfa/python3-privacyidea_3.5.1.bb
rename to recipes-security/mfa/python3-privacyidea_3.5.2.bb
index fb84411..cd0acf8 100644
--- a/recipes-security/mfa/python3-privacyidea_3.5.1.bb
+++ b/recipes-security/mfa/python3-privacyidea_3.5.2.bb
@@ -6,7 +6,7 @@ LICENSE = "AGPL-3.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=c0acfa7a8a03b718abee9135bc1a1c55"

PYPI_PACKAGE = "privacyIDEA"
-SRC_URI[sha256sum] = "c10f8e9ec681af4cb42fde70864c2b9a4b47e2bcccfc1290f83c1283748772c6"
+SRC_URI[sha256sum] = "26aeb0d353af1f212c4df476202516953c20f7f31566cfe0b67cbb553de04763"

inherit pypi setuptools3

--
2.17.1
4841 - 4860 of 57806