Date   

[yocto-autobuilder-helper][dunfell 5/6] publish-artefacts: Improve sha256 checksum handling

Steve Sakoman
 

From: "Tummalapalli, Vineela" <vineela.tummalapalli@intel.com>

The existing checksum files were encoding full paths. This patch changes
this to use just the filename which allows relocation of the directories
and is more appropriate for sharing over http.

Signed-off-by: Vineela Tummalapalli <vineela.tummalapalli@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 835ac325a4ed3e421a5a9bfd7c75f552ae2103cf)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
scripts/publish-artefacts | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/scripts/publish-artefacts b/scripts/publish-artefacts
index e773350..6ed922a 100755
--- a/scripts/publish-artefacts
+++ b/scripts/publish-artefacts
@@ -5,10 +5,14 @@ target=$3

sha256sums(){
dest=$1
- for x in `find $dest -maxdepth 5 -type f`; do
- if [ ${x##*.} != sha256sum ]; then
- sha256sum $x >> $x.sha256sum
- fi
+ for x in `find -L $dest -maxdepth 5 -type f`; do
+ for w in $x;do
+ if [ ${w##*.} != sha256sum ]; then
+ shasum=`sha256sum $w | awk '{print $1}'`
+ filename=${w##*/}
+ echo $shasum $filename >> $w.sha256sum
+ fi
+ done
done
}

--
2.17.1


[yocto-autobuilder-helper][dunfell 4/6] scripts/publish-artefacts: Convert md5sum to sha256sum

Steve Sakoman
 

From: Richard Purdie <richard.purdie@linuxfoundation.org>

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 80c53d03ea32e3b4831e8945eaa2e1d643d0ce89)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
scripts/publish-artefacts | 88 +++++++++++++++++++--------------------
1 file changed, 44 insertions(+), 44 deletions(-)

diff --git a/scripts/publish-artefacts b/scripts/publish-artefacts
index f642fac..e773350 100755
--- a/scripts/publish-artefacts
+++ b/scripts/publish-artefacts
@@ -3,11 +3,11 @@ WORKDIR=$1
DEST=$2
target=$3

-md5sums(){
+sha256sums(){
dest=$1
- for x in `find $dest -maxdepth 5 -type f`; do
- if [ ${x##*.} != md5sum ]; then
- md5sum $x >> $x.md5sum
+ for x in `find $dest -maxdepth 5 -type f`; do
+ if [ ${x##*.} != sha256sum ]; then
+ sha256sum $x >> $x.sha256sum
fi
done
}
@@ -18,7 +18,7 @@ case "$target" in
"qemuarm"|"qemuarm64"|"qemumips64"|"qemumips"|"qemuppc"|"qemux86"|"qemux86-64"|"edgerouter"|"genericx86"|"genericx86-64"|"beaglebone")
mkdir -p $DEST/toolchain/i686
mkdir -p $DEST/toolchain/x86_64
- md5sums $TMPDIR/deploy/sdk
+ sha256sums $TMPDIR/deploy/sdk
cp -R --no-dereference --preserve=links $TMPDIR/deploy/sdk/poky-*i686-core-image* $DEST/toolchain/i686
cp -R --no-dereference --preserve=links $TMPDIR/deploy/sdk/poky-*x86_64-core-image* $DEST/toolchain/x86_64
;;
@@ -34,7 +34,7 @@ case "$target" in
mkdir -p $DEST/toolchain/i686
mkdir -p $DEST/toolchain/x86_64
mkdir -p $DEST/toolchain/aarch64
- md5sums $TMPDIR/deploy/sdk
+ sha256sums $TMPDIR/deploy/sdk
cp -R --no-dereference --preserve=links $TMPDIR/deploy/sdk/*buildtools* $DEST/buildtools
cp -R --no-dereference --preserve=links $TMPDIR/deploy/sdk/i686-nativesdk-libc* $DEST/toolchain/i686
cp -R --no-dereference --preserve=links $TMPDIR/deploy/sdk/x86_64-nativesdk-libc* $DEST/toolchain/x86_64
@@ -42,165 +42,165 @@ case "$target" in
;;
"qemuarm64")
mkdir -p $DEST/machines/qemu/qemuarm64
- md5sums $TMPDIR/deploy/images/qemuarm64
+ sha256sums $TMPDIR/deploy/images/qemuarm64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemuarm64/*qemuarm64* $DEST/machines/qemu/qemuarm64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemuarm64/*Image* $DEST/machines/qemu/qemuarm64
;;
"qemuarm64-ptest")
mkdir -p $DEST/machines/qemu/qemuarm64
- md5sums $TMPDIR/deploy/images/qemuarm64
+ sha256sums $TMPDIR/deploy/images/qemuarm64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemuarm64/*qemuarm64* $DEST/machines/qemu/qemuarm64
;;
"qemuarm")
mkdir -p $DEST/machines/qemu/qemuarm
- md5sums $TMPDIR/deploy/images/qemuarm
+ sha256sums $TMPDIR/deploy/images/qemuarm
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemuarm/*qemuarm* $DEST/machines/qemu/qemuarm
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemuarm/*Image* $DEST/machines/qemu/qemuarm
;;
"beaglebone")
mkdir -p $DEST/machines/beaglebone-yocto
- md5sums $TMPDIR/deploy/images/beaglebone-yocto
+ sha256sums $TMPDIR/deploy/images/beaglebone-yocto
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/beaglebone-yocto/*Image* $DEST/machines/beaglebone-yocto
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/beaglebone-yocto/*u-boot* $DEST/machines/beaglebone-yocto
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/beaglebone-yocto/*beaglebone-yocto* $DEST/machines/beaglebone-yocto
;;
"qemuarm-alt")
mkdir -p $DEST/machines/qemu/qemuarm-alt
- md5sums $TMPDIR/deploy/images/qemuarm
+ sha256sums $TMPDIR/deploy/images/qemuarm
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemuarm/*qemuarm* $DEST/machines/qemu/qemuarm-alt
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemuarm/*Image* $DEST/machines/qemu/qemuarm-alt
;;
"beaglebone-alt")
mkdir -p $DEST/machines/beaglebone-yocto-alt
- md5sums $TMPDIR/deploy/images/beaglebone-yocto
+ sha256sums $TMPDIR/deploy/images/beaglebone-yocto
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/beaglebone-yocto/*Image* $DEST/machines/beaglebone-yocto-alt
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/beaglebone-yocto/*u-boot* $DEST/machines/beaglebone-yocto-alt
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/beaglebone-yocto/*beaglebone-yocto* $DEST/machines/beaglebone-yocto-alt
;;
"qemumips64")
mkdir -p $DEST/machines/qemu/qemumips64
- md5sums $TMPDIR/deploy/images/qemumips64
+ sha256sums $TMPDIR/deploy/images/qemumips64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemumips64/*qemumips64* $DEST/machines/qemu/qemumips64
;;
"qemumips")
mkdir -p $DEST/machines/qemu/qemumips
- md5sums $TMPDIR/deploy/images/qemumips
+ sha256sums $TMPDIR/deploy/images/qemumips
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemumips/*qemumips* $DEST/machines/qemu/qemumips
;;
"edgerouter")
mkdir -p $DEST/machines/edgerouter
- md5sums $TMPDIR/deploy/images/edgerouter
+ sha256sums $TMPDIR/deploy/images/edgerouter
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/edgerouter/*edgerouter* $DEST/machines/edgerouter
;;
"qemumips-alt")
mkdir -p $DEST/machines/qemu/qemumips-alt
- md5sums $TMPDIR/deploy/images/qemumips
+ sha256sums $TMPDIR/deploy/images/qemumips
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemumips/*qemumips* $DEST/machines/qemu/qemumips-alt
;;
"edgerouter-alt")
mkdir -p $DEST/machines/edgerouter-alt
- md5sums $TMPDIR/deploy/images/edgerouter
+ sha256sums $TMPDIR/deploy/images/edgerouter
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/edgerouter/*edgerouter* $DEST/machines/edgerouter-alt
;;
"qemuppc")
mkdir -p $DEST/machines/qemu/qemuppc
- md5sums $TMPDIR/deploy/images/qemuppc
+ sha256sums $TMPDIR/deploy/images/qemuppc
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemuppc/*qemuppc* $DEST/machines/qemu/qemuppc
;;
"qemuppc-alt")
mkdir -p $DEST/machines/qemu/qemuppc-alt
- md5sums $TMPDIR/deploy/images/qemuppc
+ sha256sums $TMPDIR/deploy/images/qemuppc
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemuppc/*qemuppc* $DEST/machines/qemu/qemuppc-alt
;;
"wic")
mkdir -p $DEST/machines/qemu/qemux86
- md5sums $TMPDIR/deploy/wic_images/qemux86
+ sha256sums $TMPDIR/deploy/wic_images/qemux86
cp -R --no-dereference --preserve=links $TMPDIR/deploy/wic_images/qemux86/*/*/*.direct $DEST/machines/qemu/qemux86
- cp -R --no-dereference --preserve=links $TMPDIR/deploy/wic_images/qemux86/*/*/*.direct.md5sum $DEST/machines/qemu/qemux86
+ cp -R --no-dereference --preserve=links $TMPDIR/deploy/wic_images/qemux86/*/*/*.direct.sha256sum $DEST/machines/qemu/qemux86
mkdir -p $DEST/machines/genericx86
- md5sums $TMPDIR/deploy/wic_images/genericx86
+ sha256sums $TMPDIR/deploy/wic_images/genericx86
cp -R --no-dereference --preserve=links $TMPDIR/deploy/wic_images/genericx86/*/*/*.direct $DEST/machines/genericx86
- cp -R --no-dereference --preserve=links $TMPDIR/deploy/wic_images/genericx86/*/*/*.direct.md5sum $DEST/machines/genericx86
+ cp -R --no-dereference --preserve=links $TMPDIR/deploy/wic_images/genericx86/*/*/*.direct.sha256sum $DEST/machines/genericx86
mkdir -p $DEST/machines/qemu/qemux86-64
- md5sums $TMPDIR/deploy/wic_images/qemux86-64
+ sha256sums $TMPDIR/deploy/wic_images/qemux86-64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/wic_images/qemux86-64/*/*/*.direct $DEST/machines/qemu/qemux86-64
- cp -R --no-dereference --preserve=links $TMPDIR/deploy/wic_images/qemux86-64/*/*/*.direct.md5sum $DEST/machines/qemu/qemux86-64
+ cp -R --no-dereference --preserve=links $TMPDIR/deploy/wic_images/qemux86-64/*/*/*.direct.sha256sum $DEST/machines/qemu/qemux86-64
mkdir -p $DEST/machines/genericx86-64
- md5sums $TMPDIR/deploy/wic_images/genericx86-64
+ sha256sums $TMPDIR/deploy/wic_images/genericx86-64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/wic_images/genericx86-64/*/*/*.direct $DEST/machines/genericx86-64
- cp -R --no-dereference --preserve=links $TMPDIR/deploy/wic_images/genericx86-64/*/*/*.direct.md5sum $DEST/machines/genericx86-64
+ cp -R --no-dereference --preserve=links $TMPDIR/deploy/wic_images/genericx86-64/*/*/*.direct.sha256sum $DEST/machines/genericx86-64
;;
"qemux86-64")
mkdir -p $DEST/machines/qemu/qemux86-64
- md5sums $TMPDIR/deploy/images/qemux86-64
+ sha256sums $TMPDIR/deploy/images/qemux86-64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemux86-64/*qemux86-64* $DEST/machines/qemu/qemux86-64
;;
"qemux86-64-ptest")
mkdir -p $DEST/machines/qemu/qemux86-64
- md5sums $TMPDIR/deploy/images/qemux86-64
+ sha256sums $TMPDIR/deploy/images/qemux86-64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemux86-64/*qemux86-64* $DEST/machines/qemu/qemux86-64
;;
"genericx86-64")
mkdir -p $DEST/machines/genericx86-64
- md5sums $TMPDIR/deploy/images/genericx86-64
+ sha256sums $TMPDIR/deploy/images/genericx86-64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/genericx86-64/*genericx86-64* $DEST/machines/genericx86-64
;;
"qemux86-64-alt")
mkdir -p $DEST/machines/qemu/qemux86-64-alt
- md5sums $TMPDIR/deploy/images/qemux86-64
+ sha256sums $TMPDIR/deploy/images/qemux86-64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemux86-64/*qemux86-64* $DEST/machines/qemu/qemux86-64-alt
;;
"genericx86-64-alt")
mkdir -p $DEST/machines/genericx86-64-alt
- md5sums $TMPDIR/deploy/images/genericx86-64
+ sha256sums $TMPDIR/deploy/images/genericx86-64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/genericx86-64/*genericx86-64* $DEST/machines/genericx86-64-alt
;;
"nightly-x86-64-bsp")
rm -rf $DEST/$target/images/intel-corei7-64/*
mkdir -p $DEST/$target/images/intel-corei7-64
- md5sums $TMPDIR/deploy/images/intel-corei7-64
+ sha256sums $TMPDIR/deploy/images/intel-corei7-64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/intel-corei7-64/bzImage* $DEST/$target/images/intel-corei7-64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/intel-corei7-64/*core-image-sato-sdk-intel-corei7-64*tar* $DEST/$target/images/intel-corei7-64
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/intel-corei7-64/*modules-* $DEST/$target/images/intel-corei7-64
;;
"qemux86")
mkdir -p $DEST/machines/qemu/qemux86
- md5sums $TMPDIR/deploy/images/qemux86
+ sha256sums $TMPDIR/deploy/images/qemux86
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemux86/*qemux86* $DEST/machines/qemu/qemux86
;;
"genericx86")
mkdir -p $DEST/machines/genericx86
- md5sums $TMPDIR/deploy/images/genericx86
+ sha256sums $TMPDIR/deploy/images/genericx86
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/genericx86/*genericx86* $DEST/machines/genericx86
;;
"qemux86-alt")
mkdir -p $DEST/machines/qemu/qemux86-alt
- md5sums $TMPDIR/deploy/images/qemux86
+ sha256sums $TMPDIR/deploy/images/qemux86
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemux86/*qemux86* $DEST/machines/qemu/qemux86-alt
;;
"genericx86-alt")
mkdir -p $DEST/machines/genericx86-alt
- md5sums $TMPDIR/deploy/images/genericx86
+ sha256sums $TMPDIR/deploy/images/genericx86
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/genericx86/*genericx86* $DEST/machines/genericx86-alt
;;
"poky-tiny")
mkdir -p $DEST/machines/qemu/qemu-tiny
- md5sums $TMPDIR/deploy/images/qemux86
+ sha256sums $TMPDIR/deploy/images/qemux86
cp -R --no-dereference --preserve=links $TMPDIR/deploy/images/qemux86/*qemux86* $DEST/machines/qemu/qemu-tiny
;;
"eclipse-plugin-neon")
DIR=$WORKDIR/../scripts
- # create md5sums only for the zip files
- for x in `ls $DIR/*.zip`; do md5sum $x >> $x.md5sum; done
+ # create sha256sums only for the zip files
+ for x in `ls $DIR/*.zip`; do sha256sum $x >> $x.sha256sum; done
mkdir -p $DEST/eclipse-plugin/neon
- cp --no-dereference --preserve=links $DIR/org.*.zip $DIR/org.*.md5sum $DEST/eclipse-plugin/neon
+ cp --no-dereference --preserve=links $DIR/org.*.zip $DIR/org.*.sha256sum $DEST/eclipse-plugin/neon
;;
"eclipse-plugin-oxygen")
DIR=$WORKDIR/../scripts
- # create md5sums only for the zip files
- for x in `ls $DIR/*.zip`; do md5sum $x >> $x.md5sum; done
+ # create sha256sums only for the zip files
+ for x in `ls $DIR/*.zip`; do sha256sum $x >> $x.sha256sum; done
mkdir -p $DEST/eclipse-plugin/oxygen
- cp --no-dereference --preserve=links $DIR/org.*.zip $DIR/org.*.md5sum $DEST/eclipse-plugin/oxygen
+ cp --no-dereference --preserve=links $DIR/org.*.zip $DIR/org.*.sha256sum $DEST/eclipse-plugin/oxygen
;;
esac

--
2.17.1


[yocto-autobuilder-helper][dunfell 3/6] config.json: Use buildtools from 3.2 M1 to fix bugs in openssl reporting

Steve Sakoman
 

From: Richard Purdie <richard.purdie@linuxfoundation.org>

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 385fdf2295d514d0b0883957a110825235f9647f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 9303086..9d5a0cf 100644
--- a/config.json
+++ b/config.json
@@ -10,7 +10,7 @@

"BUILDTOOLS_URL_TEMPLOCAL" : "/srv/autobuilder/autobuilder.yoctoproject.org/pub/non-release/20200309-15/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.0+snapshot-20200309.sh",
"BUILDTOOLS_URL_TEMPLOCAL2" : "http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M3/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.0+snapshot-20200315.sh",
- "BUILDTOOLS_URL" : "/srv/autobuilder/autobuilder.yoctoproject.org/pub/non-release/20200430-14/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.1.sh",
+ "BUILDTOOLS_URL" : "http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.2_M1/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.1+snapshot-20200617.sh",

"REPO_STASH_DIR" : "${BASE_HOMEDIR}/git/mirror",
"TRASH_DIR" : "${BASE_HOMEDIR}/git/trash",
--
2.17.1


[yocto-autobuilder-helper][dunfell 2/6] config.json: generate the buildtools tarballs for aarch64

Steve Sakoman
 

From: Ross Burton <ross.burton@arm.com>

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 6876a5536c297741cccccc22a5c2daafb8f95156)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index f1032f8..9303086 100644
--- a/config.json
+++ b/config.json
@@ -609,7 +609,7 @@
},
"step3" : {
"SDKMACHINE" : "aarch64",
- "BBTARGETS" : "uninative-tarball"
+ "BBTARGETS" : "buildtools-tarball buildtools-extended-tarball uninative-tarball"
}
},
"build-appliance" : {
--
2.17.1


[yocto-autobuilder-helper][dunfell 1/6] config.json: Ensure trigger-build and trigger-build-posttrigger match layer setup

Steve Sakoman
 

From: Richard Purdie <richard.purdie@linuxfoundation.org>

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit d1d56776fa19f7ffb1e6be33631ccf10f2c4989f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
config.json | 1 +
1 file changed, 1 insertion(+)

diff --git a/config.json b/config.json
index 9636ea1..f1032f8 100644
--- a/config.json
+++ b/config.json
@@ -179,6 +179,7 @@
"MACHINE" : "qemux86",
"step1" : {
"BBTARGETS" : "universe -c fetch -k",
+ "ADDLAYER" : ["${BUILDDIR}/../meta-selftest"],
"extravars" : [
"SOURCE_MIRROR_FETCH = '1'"
]
--
2.17.1


[yocto-autobuilder-helper][dunfell 0/6] Patch review

Steve Sakoman
 

Please review this set of patches for dunfell and have comments back
by end of day Monday.

The following changes since commit 2e8b103c4fb3b6aa07c271e716d057d71b7fa543:

config.json: add steve@sakoman.com to QA email list (2020-06-10 18:23:06 +0100)

are available in the Git repository at:

git://git.yoctoproject.org/yocto-autobuilder-helper contrib/sakoman
http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/log/?h=contrib/sakoman

Richard Purdie (3):
config.json: Ensure trigger-build and trigger-build-posttrigger match
layer setup
config.json: Use buildtools from 3.2 M1 to fix bugs in openssl
reporting
scripts/publish-artefacts: Convert md5sum to sha256sum

Ross Burton (1):
config.json: generate the buildtools tarballs for aarch64

Tummalapalli, Vineela (1):
publish-artefacts: Improve sha256 checksum handling

Vineela (1):
scripts/utils.py: Convert md5sum to sha256sum for layer tarballs

config.json | 5 ++-
scripts/publish-artefacts | 94 ++++++++++++++++++++-------------------
scripts/utils.py | 2 +-
3 files changed, 53 insertions(+), 48 deletions(-)

--
2.17.1


Re: Dunfell 3.1.1 gcc-sanitizers build failure

MikeB
 

Yes, I am using the archiver.bbclass.  However, I'm using the one in poky/meta.  I applied your patch (manually) to that one.

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index a8d3afcbe9..bf275f4543 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -583,8 +583,8 @@ do_deploy_archives[sstate-outputdirs] = "${DEPLOY_DIR_SRC}"
 addtask do_deploy_archives_setscene
 
 addtask do_ar_original after do_unpack
-addtask do_unpack_and_patch after do_patch
-addtask do_ar_patched after do_unpack_and_patch before do_preconfigure do_configure
+addtask do_unpack_and_patch after do_patch do_preconfigure
+addtask do_ar_patched after do_unpack_and_patch before do_configure
 addtask do_ar_configured after do_unpack_and_patch
 addtask do_ar_mirror after do_fetch
 addtask do_dumpdata

I should also point out that the failure is not limited to gcc-sanitizers.  On different architectures, the  same failure has occurred in gcc-cross-canadian_9.3.bb:do_configure and gcc-crosssdk_9.3.bb:do_configure.  So there are multiple recipes that reference work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h but it is missing.

On all architectures (that I use), executing a 'bitbake -c cleanall gcc-source-9.3.0' and rebuilding works around the issue and the build succeeds.

Please note that it is not the image build that is failing; it is the populate_sdk command that fails.

Regards, Mike


On Wed, Jul 1, 2020 at 10:52 AM Joshua Watt <jpewhacker@...> wrote:
On Wed, Jul 1, 2020 at 9:47 AM MikeB <mabnhdev@...> wrote:
>
> The rumors of my success were exaggerated.  If performing a fresh build from scratch, the image build succeeds, but the populate_sdk still fails as in the original post.  If I then do a 'bitbake -ccleansstate on gcc-source-9.3.0', the populate_sdk succeeds.

Ok. Are you using archiver.bbclass?

>
> Mike
>
> On Wed, Jul 1, 2020 at 6:45 AM MikeB <mabnhdev@...> wrote:
>>
>> The combination of the https://lists.openembedded.org/g/openembedded-core/message/140161 and a 'bitbake -ccleansstate on gcc-source-9.3.0' has gotten me back on track.
>>
>> Thank you all for the help!
>>
>> On Tue, Jun 30, 2020 at 11:10 PM Steve Sakoman <steve@...> wrote:
>>>
>>> On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via
>>> lists.yoctoproject.org <steve=sakoman.com@...>
>>> wrote:
>>> >
>>> > On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <JPEWhacker@...> wrote:
>>> > >
>>> > > On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@...> wrote:
>>> > > >
>>> > > > On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@...> wrote:
>>> > > > >
>>> > > > > I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if this is a bug or just my problem.  I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.
>>> > > > >
>>> > > > > | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
>>> > > > > | WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
>>> > > > > | ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
>>> > > > > | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
>>> > > > > | WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
>>> > > > >
>>> > > > > At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
>>> > > >
>>> > > > I've encountered a similar error just today when switching SDKMACHINE.
>>> > > > Are you using archive.bbclass by any chance (INHERIT += "archive")? I
>>> > > > just recently fixed a bug in archive.bbclass
>>> > > > (7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
>>> > > > gcc-source raced with do_preconfigure and I'm wondering if it's
>>> > > > related
>>> > >
>>> > > I believe I have fixed this in
>>> > > https://lists.openembedded.org/g/openembedded-core/message/140161,
>>> > > please try it out to make sure it solves your issue as well.
>>> >
>>> > That patch came in after the 3.1.1 release, but it is present in the
>>> > dunfell branch so it will make it into 3.1.2
>>>
>>> Doh, I'm getting ahead of myself! I was thinking of another
>>> classes/archiver patch that Joshua sent :-)
>>>
>>> Steve


Re: The following packages have unmet dependencies: packagegroup-core-x11-base : Depends: packagegroup-core-x11-xserver but it is not going to be installed #yocto

Pankaj Vinadrao Joshi
 

ok..Thanks for response


Re: The following packages have unmet dependencies: packagegroup-core-x11-base : Depends: packagegroup-core-x11-xserver but it is not going to be installed #yocto

Quentin Schulz
 

Hi Pankaj,

On Wed, Jul 01, 2020 at 11:22:00AM -0700, Pankaj Vinadrao Joshi wrote:
Hi,
i am trying to build core-image-sato and i am using PACKAGE_CLASSES = "package_deb" but while building i am getting following error
pankaj@exaleap-Inspiron-3584:~/Oe-Raspberrypi4$ bitbake core-image-sato
Parsing recipes: 100% |######################################################################################################################################################################| Time: 0:01:56
Parsing of 2279 .bb files complete (0 cached, 2279 parsed). 3439 targets, 195 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-18.04"
TARGET_SYS           = "aarch64-oe-linux"
MACHINE              = "raspberrypi4-64"
DISTRO               = "Exaleap-arm-linux"
DISTRO_VERSION       = "Exaleap-arm-linux-r1.0.0"
TUNE_FEATURES        = "aarch64 cortexa72 crc crypto"
TARGET_FPU           = ""
meta                 = "master:982b7f98b8423236cc986346379b1bde3694f131"
meta-oe
meta-python
meta-networking
meta-multimedia
meta-perl            = "dunfell:e413c1ef621688e69bb7830bb3151ed23b30b73e"
meta-raspberrypi     = "master:5ac6f013339b0b1ab2d71f9f6af48a186e126c19"
meta-pankaj          = "<unknown>:<unknown>"

Initialising tasks: 100% |###################################################################################################################################################################| Time: 0:00:05
Sstate summary: Wanted 270 Found 0 Missed 270 Current 1913 (0% match, 87% complete)
NOTE: Executing Tasks
ERROR: core-image-sato-1.0-r0 do_rootfs: Unable to install packages. Command '/home/pankaj/Oe-Raspberrypi4/tmp-glibc/work/raspberrypi4_64-oe-linux/core-image-sato/1.0-r0/recipe-sysroot-native/usr/bin/apt-get  install --force-yes --allow-unauthenticated --no-remove apt bash bsdtar cmake dhcp-client dhcp-server dosfstools dpkg e2fsprogs git glibc-utils kernel-modules localedef lsb-release mtd-utils-ubifs mtools openssh os-release packagegroup-base-extended packagegroup-core-boot packagegroup-core-sdk packagegroup-core-ssh-openssh packagegroup-core-standalone-sdk-target packagegroup-core-tools-debug packagegroup-core-x11-base packagegroup-core-x11-sato parted pseudo psplash-raspberrypi python3-pip ruby run-postinsts unicode-ucd' returned 100:
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
packagegroup-core-x11-base : Depends: packagegroup-core-x11-xserver but it is not going to be installed
Missing x11 in DISTRO_FEATURES in your distro.
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-graphics/packagegroups/packagegroup-core-x11-xserver.bb?h=master#n12

(I also maintain you shouldn't put a capital letter in your distro name,
you'll encounter issues later).

Quentin


Re: How to install rrdtool-per package?

ingemar0720@...
 

ok. I've found the cause. 

rrdtool-perl is empty so yocto doesn't generate rpm package for it. 

I create another .bbappend file and add `ALLOW_EMPTY_${PN}-perl = "1"` and it works.
Thanks for all the helps. 


Generating SDK and postinstall intercepts failure #sdk #yocto #toolchain

ppayeur01@...
 

Hi, 
 
I am having trouble generating the SDK for my image after upgrading from sumo to zeus. Here is an extract of my log.do_populate_sdk :

NOTE: Running intercept scripts:
NOTE: > Executing update_gio_module_cache-nativesdk intercept ...
NOTE: + '[' True = False -a nativesdk-qemuwrapper-cross '!=' nativesdk-qemuwrapper-cross ']'
+ qemu-x86_64 -r 3.2.0 -E LD_LIBRARY_PATH=/home/ops/next/poky/build/tmp/work/k700-poky-linux/dev-image-ops/1.0-r0/sdk/image/opt/ops-dist/1.1.0a/sysroots/x86_64-pokysdk-linux/usr/lib:/home/ops/next/poky/build/tmp/work/k700-poky-linux/dev-image-ops/1.0-r0/sdk/image/opt/ops-dist/1.1.0a/sysroots/x86_64-pokysdk-linux/lib -L /home/ops/next/poky/build/tmp/work/k700-poky-linux/dev-image-ops/1.0-r0/sdk/image /home/ops/next/poky/build/tmp/work/k700-poky-linux/dev-image-ops/1.0-r0/sdk/image/opt/ops-dist/1.1.0a/sysroots/x86_64-pokysdk-linux/usr/libexec/nativesdk-gio-querymodules /home/ops/next/poky/build/tmp/work/k700-poky-linux/dev-image-ops/1.0-r0/sdk/image/opt/ops-dist/1.1.0a/sysroots/x86_64-pokysdk-linux/usr/lib/gio/modules/
NOTE: > Executing update_pixbuf_cache intercept ...
NOTE: Exit code 1. Output:
/home/ops/next/poky/build/tmp/work/k700-poky-linux/dev-image-ops/1.0-r0/intercept_scripts-b57cc07ebc7fd06264e08c306ab25a797a944ba96238037685bb1148afe1842d/update_pixbuf_cache: line 11: /home/ops/next/poky/build/tmp/work/k700-poky-linux/dev-image-ops/1.0-r0/sdk/image/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/../loaders.cache: No such file or directory
 
ERROR: The postinstall intercept hook 'update_pixbuf_cache' failed, details in /home/ops/next/poky/build/tmp/work/k700-poky-linux/dev-image-ops/1.0-r0/temp/log.do_populate_sdk
DEBUG: Python function do_populate_sdk finished
 
Seems like update_pixbuf_cache cannot find the required loaders files. I am not sure why it looks in /sdk/image directly instead of the target or host rootfs in /sdk/image/opt/.../sysroots. In fact I am not sure why this postinstall intercept needs to run at all when generating the SDK.

As a bit of added info, when building my image prior to the SDK I had to manually add gdk-pixbuf to the rootfs via IMAGE_INSTALL for this intercept to work since the loaders files were missing. Also I noticed that some postinst intercepts were already failing before upgrading to zeus (including the update_pixbuf_cache one) but were only generating warnings.
 
Is it possible to disable this intercept as a quick (dirty) way to be able to build the SDK? In the long term I'd like to find out what causes this intercept to run and why the required tools are not added automatically to my image.

Any troubleshooting advice is appreciated.
 
Thank you,
 
Patrick
 


Re: #yocto #yocto

Tim Orling
 

The key error is this:
ERROR: Nothing PROVIDES 'core-image-sato'
core-image-sato was skipped: 'package-managementtools-debug' in IMAGE_FEATURES is not a valid image feature. 
So you need to figure out what is happening there.


On Wed, Jul 1, 2020 at 9:05 AM Pankaj Vinadrao Joshi <pankaj.vj@...> wrote:
Hi Quentin,
Thanks for response
I didnt got solution yet as previously u suggested to remove
hwcodecstools-debug but i after i faced one more issue with other features from core-image-sato.bb file but simply removing from there is ok,i did not got like why i am getting like so error which i didnt got earlier with the same image.Also kindly suggest why after logging trough ssh its asking for password though i have not set any password,where could be the problem??


The following packages have unmet dependencies: packagegroup-core-x11-base : Depends: packagegroup-core-x11-xserver but it is not going to be installed #yocto

Pankaj Vinadrao Joshi
 

Hi,
i am trying to build core-image-sato and i am using PACKAGE_CLASSES = "package_deb" but while building i am getting following error
pankaj@exaleap-Inspiron-3584:~/Oe-Raspberrypi4$ bitbake core-image-sato
Parsing recipes: 100% |######################################################################################################################################################################| Time: 0:01:56
Parsing of 2279 .bb files complete (0 cached, 2279 parsed). 3439 targets, 195 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
 
Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-18.04"
TARGET_SYS           = "aarch64-oe-linux"
MACHINE              = "raspberrypi4-64"
DISTRO               = "Exaleap-arm-linux"
DISTRO_VERSION       = "Exaleap-arm-linux-r1.0.0"
TUNE_FEATURES        = "aarch64 cortexa72 crc crypto"
TARGET_FPU           = ""
meta                 = "master:982b7f98b8423236cc986346379b1bde3694f131"
meta-oe              
meta-python          
meta-networking      
meta-multimedia      
meta-perl            = "dunfell:e413c1ef621688e69bb7830bb3151ed23b30b73e"
meta-raspberrypi     = "master:5ac6f013339b0b1ab2d71f9f6af48a186e126c19"
meta-pankaj          = "<unknown>:<unknown>"
 
Initialising tasks: 100% |###################################################################################################################################################################| Time: 0:00:05
Sstate summary: Wanted 270 Found 0 Missed 270 Current 1913 (0% match, 87% complete)
NOTE: Executing Tasks
ERROR: core-image-sato-1.0-r0 do_rootfs: Unable to install packages. Command '/home/pankaj/Oe-Raspberrypi4/tmp-glibc/work/raspberrypi4_64-oe-linux/core-image-sato/1.0-r0/recipe-sysroot-native/usr/bin/apt-get  install --force-yes --allow-unauthenticated --no-remove apt bash bsdtar cmake dhcp-client dhcp-server dosfstools dpkg e2fsprogs git glibc-utils kernel-modules localedef lsb-release mtd-utils-ubifs mtools openssh os-release packagegroup-base-extended packagegroup-core-boot packagegroup-core-sdk packagegroup-core-ssh-openssh packagegroup-core-standalone-sdk-target packagegroup-core-tools-debug packagegroup-core-x11-base packagegroup-core-x11-sato parted pseudo psplash-raspberrypi python3-pip ruby run-postinsts unicode-ucd' returned 100:
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
 
The following packages have unmet dependencies:
 packagegroup-core-x11-base : Depends: packagegroup-core-x11-xserver but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
 
ERROR: Logfile of failure stored in: /home/pankaj/Oe-Raspberrypi4/tmp-glibc/work/raspberrypi4_64-oe-linux/core-image-sato/1.0-r0/temp/log.do_rootfs.12854
ERROR: Task (/home/pankaj/openembedded-core/meta/recipes-sato/images/core-image-sato.bb:do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 5894 tasks of which 5893 didn't need to be rerun and 1 failed.
 
Summary: 1 task failed:
  /home/pankaj/openembedded-core/meta/recipes-sato/images/core-image-sato.bb:do_rootfs
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
 
when i am trying to build image without PACKAGE_CLASSES = "package_deb" i am able to buld i really dont have much knowledge about this can someone help??
 


Re: #yocto #yocto

Pankaj Vinadrao Joshi
 

Hi Quentin,
Thanks for response
I didnt got solution yet as previously u suggested to remove
hwcodecstools-debug but i after i faced one more issue with other features from core-image-sato.bb file but simply removing from there is ok,i did not got like why i am getting like so error which i didnt got earlier with the same image.Also kindly suggest why after logging trough ssh its asking for password though i have not set any password,where could be the problem??


Re: #yocto #yocto

Quentin Schulz
 

Hi Pankaj,

On Wed, Jul 01, 2020 at 08:36:50AM -0700, Pankaj Vinadrao Joshi wrote:
[...]
2) I have built the image without these configuration but after booting the image its asking for password for connecting from ssh thought i have not set any packages
i have included following features in local.conf file of build dir

EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
ENABLE_UART = "1"
#EXTRA_IMAGE_FEATURES ?= "allow-empty-password allow-root-login"
CORE_IMAGE_EXTRA_INSTALL += "git ruby bsdtar pseudo os-release lsb-release cmake"
DISTRO_FEATURES_append = "opengl python3-pip"
DISTRO_FEATURES_append = " opengl python3-pip"
^ missing space

EXTRA_IMAGE_FEATURES_append += "src-pkgs package-management ssh-server-dropbear ssh-server-openssh stateless-rootfs "
PACKAGE_CLASSES = "package_deb"
IMAGE_INSTALL_append = " glibc-utils localedef unicode-ucd "
IMAGE_FEATURES_append = "tools-debug tools-sdk dev-pkgs"
IMAGE_FEATURES_append = " tools-debug tools-sdk dev-pkgs"
^ missing space

CORE_IMAGE_EXTRA_INSTALL += " kernel-modules bash e2fsprogs mtools parted dosfstools mtd-utils-ubifs openssh"
IMAGE_INSTALL_append += " dhcp-client dhcp-server python3-pip "
DISTRO ?= "Exaleap-arm-linux"
DISTRO ?= "exaleap-arm-linux"
^ avoid uppercase letter like the plague

can someone help me to ressolve this issue???
Please read when I answer your mails before asking the same question
again :)

Quentin


Re: ERROR: Nothing PROVIDES 'core-image-sato' #raspberrypi #yocto

Pankaj Vinadrao Joshi
 

Sorry this message was posted by mistake. 


#yocto #yocto

Pankaj Vinadrao Joshi
 

Hi,
i am building an image for RPI4 but while building core-image-sato i am getting the following error
pankaj@exaleap-Inspiron-3584:~/Oe-Raspberrypi4$ bitbake core-image-sato
Parsing recipes: 100% |######################################################################################################################################################################| Time: 0:01:56
Parsing of 2279 .bb files complete (0 cached, 2279 parsed). 3439 targets, 196 skipped, 0 masked, 0 errors.
ERROR: Nothing PROVIDES 'core-image-sato'
core-image-sato was skipped: 'hwcodecstools-debug' in IMAGE_FEATURES is not a valid image feature. Valid features: allow-empty-password allow-root-login bash-completion-pkgs dbg-pkgs debug-tweaks dev-pkgs doc doc-pkgs eclipse-debug empty-root-password hwcodecs nfs-client nfs-server package-management post-install-logging ptest-pkgs read-only-rootfs splash src-pkgs ssh-server-dropbear ssh-server-openssh stateless-rootfs staticdev-pkgs tools-debug tools-profile tools-sdk tools-testapps x11 x11-base x11-sato

later i have removed the hwcodecstools-debug feature from core-image-sato.bb then i got same above error for  ssh-server-dropbeartools-debug' likewise for all features (# IMAGE_FEATURES += "splash package-management x11-base x11-sato ssh-server-dropbear hwcodecs") from  core-image-sato.bb 

i am attaching detailed error message

ERROR: Nothing PROVIDES 'core-image-sato'
core-image-sato was skipped: 'hwcodecstools-debug' in IMAGE_FEATURES is not a valid image feature. Valid features: allow-empty-password allow-root-login bash-completion-pkgs dbg-pkgs debug-tweaks dev-pkgs doc doc-pkgs eclipse-debug empty-root-password hwcodecs nfs-client nfs-server package-management post-install-logging ptest-pkgs read-only-rootfs splash src-pkgs ssh-server-dropbear ssh-server-openssh stateless-rootfs staticdev-pkgs tools-debug tools-profile tools-sdk tools-testapps x11 x11-base x11-sato

This is error message when i removed  hwcodecstools-debug from 'core-image-sato
pankaj@exaleap-Inspiron-3584:~/Oe-Raspberrypi4$ bitbake core-image-sato
Loading cache: 100% |########################################################################################################################################################################| Time: 0:00:00
Loaded 3439 entries from dependency cache.
Parsing recipes: 100% |######################################################################################################################################################################| Time: 0:00:00
Parsing of 2279 .bb files complete (2274 cached, 5 parsed). 3439 targets, 196 skipped, 0 masked, 0 errors.
ERROR: Nothing PROVIDES 'core-image-sato'
core-image-sato was skipped: 'package-managementtools-debug' in IMAGE_FEATURES is not a valid image feature. Valid features: allow-empty-password allow-root-login bash-completion-pkgs dbg-pkgs debug-tweaks dev-pkgs doc doc-pkgs eclipse-debug empty-root-password hwcodecs nfs-client nfs-server package-management post-install-logging ptest-pkgs read-only-rootfs splash src-pkgs ssh-server-dropbear ssh-server-openssh stateless-rootfs staticdev-pkgs tools-debug tools-profile tools-sdk tools-testapps x11 x11-base x11-sato
 
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

This is error message when i removed  package-managementtools-debug' and  x11-base x11-sato ssh-server-dropbear from 'core-image-sato
pankaj@exaleap-Inspiron-3584:~/Oe-Raspberrypi4$ bitbake core-image-sato
Loading cache: 100% |########################################################################################################################################################################| Time: 0:00:00
Loaded 3439 entries from dependency cache.
Parsing recipes: 100% |######################################################################################################################################################################| Time: 0:00:00
Parsing of 2279 .bb files complete (2274 cached, 5 parsed). 3439 targets, 196 skipped, 0 mask 0 errors.
ERROR: Nothing PROVIDES 'core-image-sato'
core-image-sato was skipped: 'splashtools-debug' in IMAGE_FEATURES is not a valid image feature. Valid features: allow-empty-password allow-root-login bash-completion-pkgs dbg-pkgs debug-tweaks dev-pkgs doc doc-pkgs eclipse-debug empty-root-password hwcodecs nfs-client nfs-server package-management post-install-logging ptest-pkgs read-only-rootfs splash src-pkgs ssh-server-dropbear ssh-server-openssh stateless-rootfs staticdev-pkgs tools-debug tools-profile tools-sdk tools-testapps x11 x11-base x11-sato

1) Now i have removed all the features from that .bb file why i am getting these errors??

2) I have built the image without these configuration but after booting the image its asking for password for connecting from ssh thought i have not set any packages
i have included following features in local.conf file of build dir

EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
ENABLE_UART = "1"
#EXTRA_IMAGE_FEATURES ?= "allow-empty-password allow-root-login"
CORE_IMAGE_EXTRA_INSTALL += "git ruby bsdtar pseudo os-release lsb-release cmake"
DISTRO_FEATURES_append = "opengl python3-pip"
EXTRA_IMAGE_FEATURES_append += "src-pkgs package-management ssh-server-dropbear ssh-server-openssh stateless-rootfs "
PACKAGE_CLASSES = "package_deb"
IMAGE_INSTALL_append = " glibc-utils localedef unicode-ucd "
IMAGE_FEATURES_append = "tools-debug tools-sdk dev-pkgs"
CORE_IMAGE_EXTRA_INSTALL += " kernel-modules bash e2fsprogs mtools parted dosfstools mtd-utils-ubifs openssh"
IMAGE_INSTALL_append += " dhcp-client dhcp-server python3-pip "
DISTRO ?= "Exaleap-arm-linux"
 
can someone help me to ressolve this issue???


Re: How to install rrdtool-per package?

ingemar0720@...
 

Hi Quentin
I've execute command "bitbake rrdtool -e" to checked the result and find it's been set as I expected.

This rrdtool-perl is actually required by "rpimonitor", if I execute command "bitbake rpimonitor" and it would success.
But when I execute command "bitbake mydistro", it always say "nothing provides rrdtool-perl" at "do_rootfs" stage. 

Is there any other suggestion?

 


Re: Dunfell 3.1.1 gcc-sanitizers build failure

Joshua Watt
 

On Wed, Jul 1, 2020 at 9:47 AM MikeB <mabnhdev@gmail.com> wrote:

The rumors of my success were exaggerated. If performing a fresh build from scratch, the image build succeeds, but the populate_sdk still fails as in the original post. If I then do a 'bitbake -ccleansstate on gcc-source-9.3.0', the populate_sdk succeeds.
Ok. Are you using archiver.bbclass?


Mike

On Wed, Jul 1, 2020 at 6:45 AM MikeB <mabnhdev@gmail.com> wrote:

The combination of the https://lists.openembedded.org/g/openembedded-core/message/140161 and a 'bitbake -ccleansstate on gcc-source-9.3.0' has gotten me back on track.

Thank you all for the help!

On Tue, Jun 30, 2020 at 11:10 PM Steve Sakoman <steve@sakoman.com> wrote:

On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@lists.yoctoproject.org>
wrote:

On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <JPEWhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@gmail.com> wrote:

I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a bug or just my problem. I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.

| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'

At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
I've encountered a similar error just today when switching SDKMACHINE.
Are you using archive.bbclass by any chance (INHERIT += "archive")? I
just recently fixed a bug in archive.bbclass
(7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
gcc-source raced with do_preconfigure and I'm wondering if it's
related
I believe I have fixed this in
https://lists.openembedded.org/g/openembedded-core/message/140161,
please try it out to make sure it solves your issue as well.
That patch came in after the 3.1.1 release, but it is present in the
dunfell branch so it will make it into 3.1.2
Doh, I'm getting ahead of myself! I was thinking of another
classes/archiver patch that Joshua sent :-)

Steve


Re: Dunfell 3.1.1 gcc-sanitizers build failure

MikeB
 

The rumors of my success were exaggerated.  If performing a fresh build from scratch, the image build succeeds, but the populate_sdk still fails as in the original post.  If I then do a 'bitbake -ccleansstate on gcc-source-9.3.0', the populate_sdk succeeds.

Mike

On Wed, Jul 1, 2020 at 6:45 AM MikeB <mabnhdev@...> wrote:
The combination of the https://lists.openembedded.org/g/openembedded-core/message/140161 and a 'bitbake -ccleansstate on gcc-source-9.3.0' has gotten me back on track.

Thank you all for the help!

On Tue, Jun 30, 2020 at 11:10 PM Steve Sakoman <steve@...> wrote:
On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@...>
wrote:
>
> On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <JPEWhacker@...> wrote:
> >
> > On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@...> wrote:
> > >
> > > On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@...> wrote:
> > > >
> > > > I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if this is a bug or just my problem.  I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.
> > > >
> > > > | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
> > > > | WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > > > | ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
> > > > | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
> > > > | WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > > >
> > > > At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
> > >
> > > I've encountered a similar error just today when switching SDKMACHINE.
> > > Are you using archive.bbclass by any chance (INHERIT += "archive")? I
> > > just recently fixed a bug in archive.bbclass
> > > (7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
> > > gcc-source raced with do_preconfigure and I'm wondering if it's
> > > related
> >
> > I believe I have fixed this in
> > https://lists.openembedded.org/g/openembedded-core/message/140161,
> > please try it out to make sure it solves your issue as well.
>
> That patch came in after the 3.1.1 release, but it is present in the
> dunfell branch so it will make it into 3.1.2

Doh, I'm getting ahead of myself! I was thinking of another
classes/archiver patch that Joshua sent :-)

Steve

3301 - 3320 of 53123