[yocto] [PATCH][autobuilder-helper][warrior 03/41] README: Add pointer to the mailing list for patches
Signed-off-by: Richard Purdie --- README | 5 + 1 file changed, 5 insertions(+) diff --git a/README b/README index a6c4f1d..2747510 100644 --- a/README +++ b/README @@ -25,3 +25,8 @@ would also allow customisation. Authors: Richard Purdie Joshua Lock + +Contributions: + +Patches for this code should be sent to the yo...@yoctoproject.org mailing list +with [yocto-autobuilder-helper] in the subject. -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50539): https://lists.yoctoproject.org/g/yocto/message/50539 Mute This Topic: https://lists.yoctoproject.org/mt/76754397/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][warrior 19/41] scripts/run-config: Add support for local filesystem buildtools urls
Signed-off-by: Richard Purdie
---
scripts/run-config | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/run-config b/scripts/run-config
index b4f1d58..d4ff6b3 100755
--- a/scripts/run-config
+++ b/scripts/run-config
@@ -103,7 +103,10 @@ if bttarball:
fileno = lf.fileno()
fcntl.flock(fileno, fcntl.LOCK_EX)
if not os.path.exists(btdlpath):
-subprocess.check_call(["wget", "-O", btdlpath, bttarball])
+if bttarball.startswith("/"):
+subprocess.check_call(["cp", bttarball, btdlpath])
+else:
+subprocess.check_call(["wget", "-O", btdlpath, bttarball])
os.chmod(btdlpath, 0o775)
subprocess.check_call(["bash", btdlpath, "-d", btdir, "-y"])
btenv = glob.glob(btdir + "/environment-setup*")
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50555): https://lists.yoctoproject.org/g/yocto/message/50555
Mute This Topic: https://lists.yoctoproject.org/mt/76754417/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 25/32] build-perf/send-qa-email: Fallback to master as a comparision branch
Signed-off-by: Richard Purdie
---
scripts/build-perf-test-wrapper | 3 +++
scripts/send-qa-email | 3 +++
2 files changed, 6 insertions(+)
diff --git a/scripts/build-perf-test-wrapper b/scripts/build-perf-test-wrapper
index e7b24ad..660ef82 100755
--- a/scripts/build-perf-test-wrapper
+++ b/scripts/build-perf-test-wrapper
@@ -185,6 +185,9 @@ if git_repo:
basebranch, comparebranch = utils.getcomparisonbranch(ourconfig,
args.repo, args.branch)
if comparebranch:
extraopts = extraopts + " --branch2 %s" % (comparebranch)
+else:
+print("No comparision branch found, comparing to master")
+extraopts = extraopts + " --branch2 master"
print("\nGenerating test report")
open(report_txt, "w").close()
diff --git a/scripts/send-qa-email b/scripts/send-qa-email
index a265a7c..b4d4cec 100755
--- a/scripts/send-qa-email
+++ b/scripts/send-qa-email
@@ -54,6 +54,9 @@ if 'poky' in repos and os.path.exists(resulttool) and
args.results_dir:
extraopts = " --branch %s --commit %s" % (branch, revision)
if comparebranch:
extraopts = extraopts + " --branch2 %s" % (comparebranch)
+elif basebranch:
+print("No comparision branch found, comparing to master")
+extraopts = extraopts + " --branch2 master"
report = subprocess.check_output([resulttool, "report", args.results_dir])
with open(args.results_dir + "/testresult-report.txt", "wb") as f:
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50497): https://lists.yoctoproject.org/g/yocto/message/50497
Mute This Topic: https://lists.yoctoproject.org/mt/76695587/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 18/32] config.json: Use new buildtools tarball
Signed-off-by: Richard Purdie
---
config.json | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/config.json b/config.json
index ef5ff6d..d494679 100644
--- a/config.json
+++ b/config.json
@@ -9,7 +9,8 @@
"BUILD_HISTORY_FORKPUSH" : {"poky-contrib:ross/mut" : "poky:master",
"poky:master-next" : "poky:master"},
"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" :
"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_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/20200427-22/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.1.sh",
"REPO_STASH_DIR" : "${BASE_HOMEDIR}/git/mirror",
"TRASH_DIR" : "${BASE_HOMEDIR}/git/trash",
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50490): https://lists.yoctoproject.org/g/yocto/message/50490
Mute This Topic: https://lists.yoctoproject.org/mt/76695579/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 19/32] config.json: Update to new buildtools tarball
Signed-off-by: Richard Purdie
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.json b/config.json
index d494679..d3b39fd 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/20200427-22/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.1.sh",
+"BUILDTOOLS_URL" :
"/srv/autobuilder/autobuilder.yoctoproject.org/pub/non-release/20200430-14/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.1.sh",
"REPO_STASH_DIR" : "${BASE_HOMEDIR}/git/mirror",
"TRASH_DIR" : "${BASE_HOMEDIR}/git/trash",
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50491): https://lists.yoctoproject.org/g/yocto/message/50491
Mute This Topic: https://lists.yoctoproject.org/mt/76695580/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 31/32] scripts/utils: Ensuring new logging is flushed from buffers
Signed-off-by: Richard Purdie
---
scripts/utils.py | 6 ++
1 file changed, 6 insertions(+)
diff --git a/scripts/utils.py b/scripts/utils.py
index 1dfc9a2..10e3cc1 100644
--- a/scripts/utils.py
+++ b/scripts/utils.py
@@ -233,18 +233,24 @@ def fetchgitrepo(clonedir, repo, params, stashdir):
branch = params["branch"]
revision = params["revision"]
print("Checking for stash at: " + stashdir + "/" + repo)
+flush()
if os.path.exists(stashdir + "/" + repo):
print("Cloning from stash to %s..." % sharedrepo)
+flush()
subprocess.check_call(["git", "clone", "file://%s/%s" % (stashdir,
repo), "%s/%s" % (clonedir, repo)])
subprocess.check_call(["git", "remote", "rm", "origin"],
cwd=sharedrepo)
subprocess.check_call(["git", "remote", "add", "origin",
params["url"]], cwd=sharedrepo)
print("Updating from origin...")
+flush()
subprocess.check_call(["git", "fetch", "origin"], cwd=sharedrepo)
subprocess.check_call(["git", "fetch", "origin", "-t"], cwd=sharedrepo)
else:
print("Cloning from origin to %s..." % sharedrepo)
+flush()
subprocess.check_call(["git", "clone", params["url"], sharedrepo])
+print("Updating checkout...")
+flush()
subprocess.check_call(["git", "checkout", branch], cwd=sharedrepo)
# git reset revision==HEAD won't help, we need to reset onto the
potentially fetched origin branch
subprocess.check_call(["git", "reset", "origin/" + branch, "--hard"],
cwd=sharedrepo)
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50503): https://lists.yoctoproject.org/g/yocto/message/50503
Mute This Topic: https://lists.yoctoproject.org/mt/76695595/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 29/32] config.json: Build buildtools-extended-tarball for x86_64 and aarch64
Signed-off-by: Richard Purdie
---
config.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config.json b/config.json
index 2218891..ab6943b 100644
--- a/config.json
+++ b/config.json
@@ -595,7 +595,7 @@
"MACHINE" : "qemux86-64",
"step1" : {
"SDKMACHINE" : "x86_64",
-"BBTARGETS" : "buildtools-tarball uninative-tarball"
+"BBTARGETS" : "buildtools-tarball buildtools-extended-tarball
uninative-tarball"
},
"step2" : {
"SDKMACHINE" : "i686",
@@ -603,7 +603,7 @@
},
"step3" : {
"SDKMACHINE" : "aarch64",
-"BBTARGETS" : "uninative-tarball"
+"BBTARGETS" : "buildtools-tarball buildtools-extended-tarball
uninative-tarball"
}
},
"build-appliance" : {
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50501): https://lists.yoctoproject.org/g/yocto/message/50501
Mute This Topic: https://lists.yoctoproject.org/mt/76695593/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 22/32] scripts/publish-artefacts: Convert md5sum to sha256sum
Signed-off-by: Richard Purdie
(cherry picked from commit 80c53d03ea32e3b4831e8945eaa2e1d643d0ce89)
Signed-off-by: Steve Sakoman
---
scripts/publish-artefacts | 88 +++
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/scripts/publish-artefacts b/scripts/publish-artefacts
index 75ed1b5..a2625d7 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"|"mpc8315e-rdb"|"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,69 +42,69 @@ 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
[yocto] [PATCH][autobuilder-helper][zeus 20/32] config.json: ltp QB_MEM parameter was being lost, fix this
Signed-off-by: Richard Purdie
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.json b/config.json
index d3b39fd..df67545 100644
--- a/config.json
+++ b/config.json
@@ -109,7 +109,7 @@
"TEST_SUITES = 'ping ssh ltp ltp_compliance'",
"IMAGE_OVERHEAD_FACTOR = '1.0'",
"IMAGE_ROOTFS_EXTRA_SPACE = '1324288'",
-"QB_MEM = '-m 1024'"
+"QB_MEM_forcevariable = '-m 1024'"
]
},
"arch-hw" : {
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50492): https://lists.yoctoproject.org/g/yocto/message/50492
Mute This Topic: https://lists.yoctoproject.org/mt/76695582/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 24/32] scripts/utils.py: Convert md5sum to sha256sum for layer tarballs
From: Vineela
Signed-off-by: Vineela Tummalapalli
Signed-off-by: Richard Purdie
(cherry picked from commit 3aefa5a763125c760813a8f8434c574ecd3ca99b)
Signed-off-by: Steve Sakoman
---
scripts/utils.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/utils.py b/scripts/utils.py
index d7b9ae7..ec43832 100644
--- a/scripts/utils.py
+++ b/scripts/utils.py
@@ -251,7 +251,7 @@ def publishrepo(clonedir, repo, publishdir):
revision = subprocess.check_output(["git", "rev-parse", "HEAD"],
cwd=sharedrepo).decode('utf-8').strip()
archive_name = repo + "-" + revision + ".tar.bz2"
subprocess.check_call("git archive --format=tar HEAD --prefix=" + repo +
"/ | bzip2 -c > " + archive_name, shell=True, cwd=sharedrepo)
-subprocess.check_call("md5sum " + archive_name + " >> " + archive_name +
".md5sum", shell=True, cwd=sharedrepo)
+subprocess.check_call("sha256sum " + archive_name + " >> " + archive_name
+ ".sha256sum", shell=True, cwd=sharedrepo)
mkdir(publishdir)
subprocess.check_call("rsync -av " + archive_name + "* " + publishdir,
shell=True, cwd=sharedrepo)
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50496): https://lists.yoctoproject.org/g/yocto/message/50496
Mute This Topic: https://lists.yoctoproject.org/mt/76695586/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 26/32] send-qa-email: Fix stable branch test result history issues
On stable release branch builds, it will clone "master" since comparebranch
is None. It will then fail to push since there is already a dunfell
branch upstream with changes on which it needs to rebase on top of.
The change to use shallow clones significantly increases this problem.
To fix this, fall back to cloning basebranch by name, then master
if it doesn't exist.
Signed-off-by: Richard Purdie
---
scripts/send-qa-email | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/scripts/send-qa-email b/scripts/send-qa-email
index b4d4cec..abc17e2 100755
--- a/scripts/send-qa-email
+++ b/scripts/send-qa-email
@@ -55,8 +55,8 @@ if 'poky' in repos and os.path.exists(resulttool) and
args.results_dir:
if comparebranch:
extraopts = extraopts + " --branch2 %s" % (comparebranch)
elif basebranch:
-print("No comparision branch found, comparing to master")
-extraopts = extraopts + " --branch2 master"
+print("No comparision branch found, comparing to %s" % basebranch)
+extraopts = extraopts + " --branch2 %s" % basebranch
report = subprocess.check_output([resulttool, "report", args.results_dir])
with open(args.results_dir + "/testresult-report.txt", "wb") as f:
@@ -64,7 +64,16 @@ if 'poky' in repos and os.path.exists(resulttool) and
args.results_dir:
tempdir = tempfile.mkdtemp(prefix='sendqaemail.')
try:
-subprocess.check_call(["git", "clone",
"g...@git.yoctoproject.org:yocto-testresults", tempdir, "--depth", "5"])
+cloneopts = []
+if comparebranch:
+cloneopts = ["--branch", comparebranch]
+elif basebranch:
+cloneopts = ["--branch", basebranch]
+try:
+subprocess.check_call(["git", "clone",
"g...@git.yoctoproject.org:yocto-testresults", tempdir, "--depth", "5"] +
cloneopts)
+except subprocess.CalledProcessError:
+print("No comparision branch found, falling back to master")
+subprocess.check_call(["git", "clone",
"g...@git.yoctoproject.org:yocto-testresults", tempdir, "--depth", "5"])
# If the base comparision branch isn't present regression comparision
won't work
# at least until we can tell the tool to ignore internal branch
information
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50498): https://lists.yoctoproject.org/g/yocto/message/50498
Mute This Topic: https://lists.yoctoproject.org/mt/76695590/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 32/32] scripts/utils: Ensure buildtools tarball hash matches any supplied value
Signed-off-by: Richard Purdie
---
scripts/utils.py | 26 ++
1 file changed, 26 insertions(+)
diff --git a/scripts/utils.py b/scripts/utils.py
index 10e3cc1..46346fb 100644
--- a/scripts/utils.py
+++ b/scripts/utils.py
@@ -378,6 +378,25 @@ def getcomparisonbranch(ourconfig, reponame, branchname):
return branchname, None
return None, None
+def sha256_file(filename):
+"""
+Return the hex string representation of the 256-bit SHA checksum of
+filename.
+"""
+import hashlib
+import mmap
+
+method = hashlib.sha256()
+with open(filename, "rb") as f:
+try:
+with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) as mm:
+for chunk in iter(lambda: mm.read(8192), b''):
+method.update(chunk)
+except ValueError:
+# You can't mmap() an empty file so silence this exception
+pass
+return method.hexdigest()
+
def setup_buildtools_tarball(ourconfig, workername, btdir):
bttarball = None
if "buildtools" in ourconfig and workername:
@@ -389,6 +408,9 @@ def setup_buildtools_tarball(ourconfig, workername, btdir):
btenv = None
if bttarball:
+sha256 = None
+if ";" in bttarball:
+bttarball, sha256 = bttarball.split(";")
btdir = os.path.abspath(btdir)
if not os.path.exists(btdir):
btdlpath = getconfig("BASE_SHAREDDIR", ourconfig) + "/buildtools/"
+ os.path.basename(bttarball)
@@ -401,6 +423,10 @@ def setup_buildtools_tarball(ourconfig, workername, btdir):
with open(btlock, 'a+') as lf:
fileno = lf.fileno()
fcntl.flock(fileno, fcntl.LOCK_EX)
+if sha256 and os.path.exists(btdlpath):
+dl_sha256 = sha256_file(btdlpath)
+if dl_sha256 != sha256:
+os.unlink(btdlpath)
if not os.path.exists(btdlpath):
if bttarball.startswith("/"):
subprocess.check_call(["cp", bttarball,
btdlpath])
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50504): https://lists.yoctoproject.org/g/yocto/message/50504
Mute This Topic: https://lists.yoctoproject.org/mt/76695596/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 28/32] config.json: Update buildtools config
Need to use buildtools on centos8 and fedora32 as they lack makeinfo
as part of the default install now.
Also use buildtools to standard and extended as appropriate.
Signed-off-by: Richard Purdie
---
config.json | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/config.json b/config.json
index 516e050..2218891 100644
--- a/config.json
+++ b/config.json
@@ -8,9 +8,8 @@
"BUILD_HISTORY_DIRECTPUSH" : ["poky:morty", "poky:pyro", "poky:rocko",
"poky:sumo", "poky:thud", "poky:warrior", "poky:zeus", "poky:master"],
"BUILD_HISTORY_FORKPUSH" : {"poky-contrib:ross/mut" : "poky:master",
"poky:master-next" : "poky:master"},
-"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" :
"http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.2_M1/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.1+snapshot-20200617.sh";,
+"BUILDTOOLS_URL" :
"/srv/autobuilder/autobuilder.yoctoproject.org/pub/non-release/20200907-11/buildtools/x86_64-buildtools-nativesdk-standalone-3.0.4.sh;f0c06b2cfd2f5d92ef5fb592f4d726f9ad270d83d7846f817a08abfd017d159d",
+"BUILDTOOLS_URL_EXT" :
"/srv/autobuilder/autobuilder.yoctoproject.org/pub/non-release/20200907-11/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.0.4.sh;a5fea6b64109a604f3718dfb2a7b5ad32402d13ed5472d9d791e7bf9900621bd",
"REPO_STASH_DIR" : "${BASE_HOMEDIR}/git/mirror",
"TRASH_DIR" : "${BASE_HOMEDIR}/git/trash",
@@ -963,6 +962,11 @@
"buildtools" : {
"debian8*" : "${BUILDTOOLS_URL}",
"centos7*" : "${BUILDTOOLS_URL}",
+"centos8*" : "${BUILDTOOLS_URL_EXT}",
+"debian10*" : "${BUILDTOOLS_URL_EXT}",
+"tumbleweed*" : "${BUILDTOOLS_URL_EXT}",
+"fedora31*" : "${BUILDTOOLS_URL_EXT}",
+"fedora32*" : "${BUILDTOOLS_URL_EXT}",
"perf-centos7*" : "${BUILDTOOLS_URL}"
}
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50500): https://lists.yoctoproject.org/g/yocto/message/50500
Mute This Topic: https://lists.yoctoproject.org/mt/76695592/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 21/32] config.json: Use buildtools from 3.2 M1 to fix bugs in openssl reporting
Signed-off-by: Richard Purdie
(cherry picked from commit 385fdf2295d514d0b0883957a110825235f9647f)
Signed-off-by: Steve Sakoman
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.json b/config.json
index df67545..516e050 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.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50493): https://lists.yoctoproject.org/g/yocto/message/50493
Mute This Topic: https://lists.yoctoproject.org/mt/76695583/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 27/32] scripts/send-qa-email: Update to dedicated push capable domain
From: Michael Halstead
Signed-off-by: Michael Halstead
Signed-off-by: Richard Purdie
---
scripts/send-qa-email | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/send-qa-email b/scripts/send-qa-email
index abc17e2..f38c876 100755
--- a/scripts/send-qa-email
+++ b/scripts/send-qa-email
@@ -70,10 +70,10 @@ if 'poky' in repos and os.path.exists(resulttool) and
args.results_dir:
elif basebranch:
cloneopts = ["--branch", basebranch]
try:
-subprocess.check_call(["git", "clone",
"g...@git.yoctoproject.org:yocto-testresults", tempdir, "--depth", "5"] +
cloneopts)
+subprocess.check_call(["git", "clone",
"g...@push.yoctoproject.org:yocto-testresults", tempdir, "--depth", "5"] +
cloneopts)
except subprocess.CalledProcessError:
print("No comparision branch found, falling back to master")
-subprocess.check_call(["git", "clone",
"g...@git.yoctoproject.org:yocto-testresults", tempdir, "--depth", "5"])
+subprocess.check_call(["git", "clone",
"g...@push.yoctoproject.org:yocto-testresults", tempdir, "--depth", "5"])
# If the base comparision branch isn't present regression comparision
won't work
# at least until we can tell the tool to ignore internal branch
information
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50499): https://lists.yoctoproject.org/g/yocto/message/50499
Mute This Topic: https://lists.yoctoproject.org/mt/76695591/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 23/32] publish-artefacts: Improve sha256 checksum handling
From: "Tummalapalli, Vineela"
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
Signed-off-by: Richard Purdie
(cherry picked from commit 835ac325a4ed3e421a5a9bfd7c75f552ae2103cf)
Signed-off-by: Steve Sakoman
---
scripts/publish-artefacts | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/scripts/publish-artefacts b/scripts/publish-artefacts
index a2625d7..8c6653c 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.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50495): https://lists.yoctoproject.org/g/yocto/message/50495
Mute This Topic: https://lists.yoctoproject.org/mt/76695585/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 30/32] scripts/utils: Add more logging for fetchgitrepo
Signed-off-by: Richard Purdie
---
scripts/utils.py | 4
1 file changed, 4 insertions(+)
diff --git a/scripts/utils.py b/scripts/utils.py
index ec43832..1dfc9a2 100644
--- a/scripts/utils.py
+++ b/scripts/utils.py
@@ -232,13 +232,17 @@ def fetchgitrepo(clonedir, repo, params, stashdir):
sharedrepo = "%s/%s" % (clonedir, repo)
branch = params["branch"]
revision = params["revision"]
+print("Checking for stash at: " + stashdir + "/" + repo)
if os.path.exists(stashdir + "/" + repo):
+print("Cloning from stash to %s..." % sharedrepo)
subprocess.check_call(["git", "clone", "file://%s/%s" % (stashdir,
repo), "%s/%s" % (clonedir, repo)])
subprocess.check_call(["git", "remote", "rm", "origin"],
cwd=sharedrepo)
subprocess.check_call(["git", "remote", "add", "origin",
params["url"]], cwd=sharedrepo)
+print("Updating from origin...")
subprocess.check_call(["git", "fetch", "origin"], cwd=sharedrepo)
subprocess.check_call(["git", "fetch", "origin", "-t"], cwd=sharedrepo)
else:
+print("Cloning from origin to %s..." % sharedrepo)
subprocess.check_call(["git", "clone", params["url"], sharedrepo])
subprocess.check_call(["git", "checkout", branch], cwd=sharedrepo)
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50502): https://lists.yoctoproject.org/g/yocto/message/50502
Mute This Topic: https://lists.yoctoproject.org/mt/76695594/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 17/32] scripts/run-config: Share buildtools setup code with shared-repo-unpack
Signed-off-by: Richard Purdie
---
scripts/run-config | 49 +
scripts/shared-repo-unpack | 2 ++
scripts/utils.py | 50 ++
3 files changed, 53 insertions(+), 48 deletions(-)
diff --git a/scripts/run-config b/scripts/run-config
index 45a417f..0134841 100755
--- a/scripts/run-config
+++ b/scripts/run-config
@@ -8,9 +8,6 @@ import os
import sys
import subprocess
import errno
-import fnmatch
-import glob
-import fcntl
import utils
@@ -95,51 +92,7 @@ if args.target in ourconfig['overrides']:
hp.printheader("Target task %s has %d steps" % (args.target, maxsteps))
-bttarball = None
-if "buildtools" in ourconfig and args.workername:
-btcfg = utils.getconfig("buildtools", ourconfig)
-for entry in btcfg:
-if fnmatch.fnmatch(args.workername, entry):
-bttarball = btcfg[entry]
-break
-
-btenv = None
-if bttarball:
-btdir = args.builddir + "/../buildtools"
-if not os.path.exists(btdir):
-btdlpath = utils.getconfig("BASE_SHAREDDIR", ourconfig) +
"/buildtools/" + os.path.basename(bttarball)
-print("Extracting buildtools %s" % bttarball)
-btlock = btdlpath + ".lock"
-if not os.path.exists(os.path.dirname(btdlpath)):
-os.makedirs(os.path.dirname(btdlpath), exist_ok=True)
-while True:
-try:
-with open(btlock, 'a+') as lf:
-fileno = lf.fileno()
-fcntl.flock(fileno, fcntl.LOCK_EX)
-if not os.path.exists(btdlpath):
-if bttarball.startswith("/"):
-subprocess.check_call(["cp", bttarball, btdlpath])
-else:
-subprocess.check_call(["wget", "-O", btdlpath,
bttarball])
-os.chmod(btdlpath, 0o775)
-break
-except OSError:
-# We raced with someone else, try again
-pass
-subprocess.check_call(["bash", btdlpath, "-d", btdir, "-y"])
-btenv = glob.glob(btdir + "/environment-setup*")
-print("Using buildtools %s" % btenv)
-# We either parse or wrap all our execution calls, rock and a hard place :(
-with open(btenv[0], "r") as f:
-for line in f.readlines():
-if line.startswith("export "):
-line = line.strip().split(" ", 1)[1].split("=", 1)
-if "$PATH" in line[1]:
-line[1] = line[1].replace("$PATH", os.environ["PATH"])
-if line[1].startswith(("'", '"')):
-line[1] = line[1][1:-1]
-os.environ[line[0]] = line[1]
+utils.setup_buildtools_tarball(ourconfig, args.workername, args.builddir +
"/../buildtools")
finalret = 0
diff --git a/scripts/shared-repo-unpack b/scripts/shared-repo-unpack
index 4a2b1c9..7dc250c 100755
--- a/scripts/shared-repo-unpack
+++ b/scripts/shared-repo-unpack
@@ -61,6 +61,8 @@ for repo in sorted(repos.keys()):
if args.publish_dir:
utils.publishrepo(targetsubdir, repo, args.publish_dir)
+utils.setup_buildtools_tarball(ourconfig, args.workername, args.abworkdir +
"/buildtools")
+
try:
subprocess.check_call([scriptsdir + "/layer-config", args.abworkdir,
args.target])
except subprocess.CalledProcessError as e:
diff --git a/scripts/utils.py b/scripts/utils.py
index 5542fe2..d7b9ae7 100644
--- a/scripts/utils.py
+++ b/scripts/utils.py
@@ -8,6 +8,9 @@ import codecs
import sys
import re
import argparse
+import fnmatch
+import glob
+import fcntl
#
# Check if config contains all the listed params
@@ -364,3 +367,50 @@ def getcomparisonbranch(ourconfig, reponame, branchname):
if (reponame + ":" + branchname) in getconfig("BUILD_HISTORY_DIRECTPUSH",
ourconfig):
return branchname, None
return None, None
+
+def setup_buildtools_tarball(ourconfig, workername, btdir):
+bttarball = None
+if "buildtools" in ourconfig and workername:
+btcfg = getconfig("buildtools", ourconfig)
+for entry in btcfg:
+if fnmatch.fnmatch(workername, entry):
+bttarball = btcfg[entry]
+break
+
+btenv = None
+if bttarball:
+btdir = os.path.abspath(btdir)
+if not os.path.exists(btdir):
+btdlpath = getconfig("BASE_SHAREDDIR", ourconfig) + "/buildtools/"
+ os.path.basename(bttarball)
+print("Extracting buildtools %s" % bttarball)
+btlock = btdlpath + ".lock&
[yocto] [PATCH][autobuilder-helper][zeus 16/32] scripts/run-config: Add extra debug about buildtools to show when active
Signed-off-by: Richard Purdie
---
scripts/run-config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/run-config b/scripts/run-config
index 2ad38e2..45a417f 100755
--- a/scripts/run-config
+++ b/scripts/run-config
@@ -108,6 +108,7 @@ if bttarball:
btdir = args.builddir + "/../buildtools"
if not os.path.exists(btdir):
btdlpath = utils.getconfig("BASE_SHAREDDIR", ourconfig) +
"/buildtools/" + os.path.basename(bttarball)
+print("Extracting buildtools %s" % bttarball)
btlock = btdlpath + ".lock"
if not os.path.exists(os.path.dirname(btdlpath)):
os.makedirs(os.path.dirname(btdlpath), exist_ok=True)
@@ -128,6 +129,7 @@ if bttarball:
pass
subprocess.check_call(["bash", btdlpath, "-d", btdir, "-y"])
btenv = glob.glob(btdir + "/environment-setup*")
+print("Using buildtools %s" % btenv)
# We either parse or wrap all our execution calls, rock and a hard place :(
with open(btenv[0], "r") as f:
for line in f.readlines():
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50488): https://lists.yoctoproject.org/g/yocto/message/50488
Mute This Topic: https://lists.yoctoproject.org/mt/76695577/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 14/32] scripts/utils.py: Fix confusing naming of getcomparisonbranch() return value
From: Steve Sakoman
This code was copy/pasted but in this case the variables should
be called "compare", not base.
Signed-off-by: Steve Sakoman
Signed-off-by: Richard Purdie
---
scripts/utils.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/utils.py b/scripts/utils.py
index 68652d9..5542fe2 100644
--- a/scripts/utils.py
+++ b/scripts/utils.py
@@ -358,9 +358,9 @@ def getcomparisonbranch(ourconfig, reponame, branchname):
if (reponame + ":" + branchname) in getconfig("BUILD_HISTORY_FORKPUSH",
ourconfig):
base = getconfig("BUILD_HISTORY_FORKPUSH", ourconfig)[reponame + ":" +
branchname]
if base:
-baserepo, basebranch = base.split(":")
-print("Comparing to %s\n" % (basebranch))
-return branchname, basebranch
+comparerepo, comparebranch = base.split(":")
+print("Comparing to %s\n" % (comparebranch))
+return branchname, comparebranch
if (reponame + ":" + branchname) in getconfig("BUILD_HISTORY_DIRECTPUSH",
ourconfig):
return branchname, None
return None, None
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50486): https://lists.yoctoproject.org/g/yocto/message/50486
Mute This Topic: https://lists.yoctoproject.org/mt/76695574/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 08/32] scripts/run-config: Handle quoting issues in buildtools environment files
Signed-off-by: Richard Purdie
---
scripts/run-config | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/run-config b/scripts/run-config
index 5c6a9ca..29d783e 100755
--- a/scripts/run-config
+++ b/scripts/run-config
@@ -123,9 +123,11 @@ if bttarball:
with open(btenv[0], "r") as f:
for line in f.readlines():
if line.startswith("export "):
-line = line.split(" ", 1)[1].split("=", 1)
+line = line.strip().split(" ", 1)[1].split("=", 1)
if "$PATH" in line[1]:
line[1] = line[1].replace("$PATH", os.environ["PATH"])
+if line[1].startswith(("'", '"')):
+line[1] = line[1][1:-1]
os.environ[line[0]] = line[1]
finalret = 0
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50480): https://lists.yoctoproject.org/g/yocto/message/50480
Mute This Topic: https://lists.yoctoproject.org/mt/76695567/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 05/32] scripts/run-config: Fix buildtools path
Signed-off-by: Richard Purdie
---
scripts/run-config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/run-config b/scripts/run-config
index 161cca4..8e175d0 100755
--- a/scripts/run-config
+++ b/scripts/run-config
@@ -104,7 +104,7 @@ if "buildtools" in ourconfig and args.workername:
btenv = None
if bttarball:
-btdir = args.builddir + "../buildtools"
+btdir = args.builddir + "/../buildtools"
if not os.path.exists(btdir):
btdlpath = utils.getconfig("BASE_SHAREDDIR", ourconfig) +
"/buildtools/" + os.path.basename(bttarball)
if not os.path.exists(btdlpath):
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50477): https://lists.yoctoproject.org/g/yocto/message/50477
Mute This Topic: https://lists.yoctoproject.org/mt/76695564/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 02/32] run-config: Add support for wrapping builds in a buildtools tarball
Signed-off-by: Richard Purdie
---
scripts/run-config | 30 ++
1 file changed, 30 insertions(+)
diff --git a/scripts/run-config b/scripts/run-config
index a0e0204..161cca4 100755
--- a/scripts/run-config
+++ b/scripts/run-config
@@ -8,6 +8,8 @@ import os
import sys
import subprocess
import errno
+import fnmatch
+import glob
import utils
@@ -92,6 +94,34 @@ if args.target in ourconfig['overrides']:
hp.printheader("Target task %s has %d steps" % (args.target, maxsteps))
+bttarball = None
+if "buildtools" in ourconfig and args.workername:
+btcfg = utils.getconfig("buildtools", ourconfig)
+for entry in btcfg:
+if fnmatch.fnmatch(args.workername, entry):
+bttarball = btcfg[entry]
+break
+
+btenv = None
+if bttarball:
+btdir = args.builddir + "../buildtools"
+if not os.path.exists(btdir):
+btdlpath = utils.getconfig("BASE_SHAREDDIR", ourconfig) +
"/buildtools/" + os.path.basename(bttarball)
+if not os.path.exists(btdlpath):
+os.makedirs(os.path.dirname(btdlpath), exist_ok=True)
+subprocess.check_call(["wget", "-O", btdlpath, bttarball])
+os.chmod(btdlpath, 0o775)
+subprocess.check_call(["bash", btdlpath, "-d", btdir, "-y"])
+btenv = glob.glob(btdir + "/environment-setup*")
+# We either parse or wrap all our execution calls, rock and a hard place :(
+with open(btenv[0], "r") as f:
+for line in f.readlines():
+if line.startswith("export "):
+line = line.split(" ", 1)[1].split("=", 1)
+if "$PATH" in line[1]:
+line[1] = line[1].replace("$PATH", os.environ["PATH"])
+os.environ[line[0]] = line[1]
+
finalret = 0
def flush():
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50474): https://lists.yoctoproject.org/g/yocto/message/50474
Mute This Topic: https://lists.yoctoproject.org/mt/76695558/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 11/32] run-config: Fix lockfile loop handling
Signed-off-by: Richard Purdie --- scripts/run-config | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/run-config b/scripts/run-config index ed13ca0..2ad38e2 100755 --- a/scripts/run-config +++ b/scripts/run-config @@ -122,6 +122,7 @@ if bttarball: else: subprocess.check_call(["wget", "-O", btdlpath, bttarball]) os.chmod(btdlpath, 0o775) +break except OSError: # We raced with someone else, try again pass -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50483): https://lists.yoctoproject.org/g/yocto/message/50483 Mute This Topic: https://lists.yoctoproject.org/mt/76695571/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 03/32] config.json: Enable buildtools for centos7 workers (as a test for now)
Signed-off-by: Richard Purdie
---
config.json | 5 +
1 file changed, 5 insertions(+)
diff --git a/config.json b/config.json
index 7a88e6e..a251d53 100644
--- a/config.json
+++ b/config.json
@@ -8,6 +8,8 @@
"BUILD_HISTORY_DIRECTPUSH" : ["poky:morty", "poky:pyro", "poky:rocko",
"poky:sumo", "poky:thud", "poky:warrior", "poky:zeus", "poky:master"],
"BUILD_HISTORY_FORKPUSH" : {"poky-contrib:ross/mut" : "poky:master",
"poky:master-next" : "poky:master"},
+"BUILDTOOLS_URL" :
"http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M2/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.0%2Bsnapshot-20200122.sh";,
+
"REPO_STASH_DIR" : "${BASE_HOMEDIR}/git/mirror",
"TRASH_DIR" : "${BASE_HOMEDIR}/git/trash",
@@ -955,5 +957,8 @@
"no-layer-add" : true
}
+},
+"buildtools" : {
+"centos7*" : "${BUILDTOOLS_URL}"
}
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50475): https://lists.yoctoproject.org/g/yocto/message/50475
Mute This Topic: https://lists.yoctoproject.org/mt/76695560/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 13/32] config.json: Apply buildtools tarball to centos7 perf worker too
Signed-off-by: Richard Purdie
---
config.json | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/config.json b/config.json
index 20e74e1..ef5ff6d 100644
--- a/config.json
+++ b/config.json
@@ -961,6 +961,7 @@
},
"buildtools" : {
"debian8*" : "${BUILDTOOLS_URL}",
-"centos7*" : "${BUILDTOOLS_URL}"
+"centos7*" : "${BUILDTOOLS_URL}",
+"perf-centos7*" : "${BUILDTOOLS_URL}"
}
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50485): https://lists.yoctoproject.org/g/yocto/message/50485
Mute This Topic: https://lists.yoctoproject.org/mt/76695573/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 09/32] scripts/run-config: Add support for local filesystem buildtools urls
Signed-off-by: Richard Purdie
---
scripts/run-config | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/run-config b/scripts/run-config
index 29d783e..9d8d48a 100755
--- a/scripts/run-config
+++ b/scripts/run-config
@@ -115,7 +115,10 @@ if bttarball:
fileno = lf.fileno()
fcntl.flock(fileno, fcntl.LOCK_EX)
if not os.path.exists(btdlpath):
-subprocess.check_call(["wget", "-O", btdlpath, bttarball])
+if bttarball.startswith("/"):
+subprocess.check_call(["cp", bttarball, btdlpath])
+else:
+subprocess.check_call(["wget", "-O", btdlpath, bttarball])
os.chmod(btdlpath, 0o775)
subprocess.check_call(["bash", btdlpath, "-d", btdir, "-y"])
btenv = glob.glob(btdir + "/environment-setup*")
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50481): https://lists.yoctoproject.org/g/yocto/message/50481
Mute This Topic: https://lists.yoctoproject.org/mt/76695568/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 00/32] Update zeus to match master/dunfell
The helper code for zeus is way behind master/dunfell and is becomming unmaintainable. This series brings it much more closely into line with the other codebases, adding many fixes and the buildtools tarball capabilities. Michael Halstead (1): scripts/send-qa-email: Update to dedicated push capable domain Richard Purdie (27): run-config: Preface log output with auto.conf settings to aid debugging run-config: Add support for wrapping builds in a buildtools tarball config.json: Enable buildtools for centos7 workers (as a test for now) config.json: Disable buildtools tarball on centos7 as its missing crypt.h scripts/run-config: Fix buildtools path send-qa-email: Limit results clone to shallow depth to avoid timeouts scripts/run-config: Handle multiple builds racing with lockfile for buildtools scripts/run-config: Handle quoting issues in buildtools environment files scripts/run-config: Add support for local filesystem buildtools urls scripts/run-config: Ensure racing for the lockfile doesn't traceback run-config: Fix lockfile loop handling config.json: Update to 3.1M3 for buildtools tarball and apply to centos7/debian8 config.json: Apply buildtools tarball to centos7 perf worker too scripts/run-config: Add extra debug about buildtools to show when active scripts/run-config: Share buildtools setup code with shared-repo-unpack config.json: Use new buildtools tarball config.json: Update to new buildtools tarball config.json: ltp QB_MEM parameter was being lost, fix this config.json: Use buildtools from 3.2 M1 to fix bugs in openssl reporting scripts/publish-artefacts: Convert md5sum to sha256sum build-perf/send-qa-email: Fallback to master as a comparision branch send-qa-email: Fix stable branch test result history issues config.json: Update buildtools config config.json: Build buildtools-extended-tarball for x86_64 and aarch64 scripts/utils: Add more logging for fetchgitrepo scripts/utils: Ensuring new logging is flushed from buffers scripts/utils: Ensure buildtools tarball hash matches any supplied value Steve Sakoman (2): scripts/utils.py: Fix confusing naming of getcomparisonbranch() return value scripts/send-qa-email: fix bug in git push logic for yocto-testresults Tummalapalli, Vineela (1): publish-artefacts: Improve sha256 checksum handling Vineela (1): scripts/utils.py: Convert md5sum to sha256sum for layer tarballs config.json | 19 +-- scripts/build-perf-test-wrapper | 3 ++ scripts/publish-artefacts | 94 + scripts/run-config | 10 scripts/send-qa-email | 18 +-- scripts/shared-repo-unpack | 2 + scripts/utils.py| 94 +++-- 7 files changed, 185 insertions(+), 55 deletions(-) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50472): https://lists.yoctoproject.org/g/yocto/message/50472 Mute This Topic: https://lists.yoctoproject.org/mt/76695556/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 06/32] send-qa-email: Limit results clone to shallow depth to avoid timeouts
Signed-off-by: Richard Purdie --- scripts/send-qa-email | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/send-qa-email b/scripts/send-qa-email index d2f4574..7dbc290 100755 --- a/scripts/send-qa-email +++ b/scripts/send-qa-email @@ -61,7 +61,7 @@ if 'poky' in repos and os.path.exists(resulttool) and args.results_dir: tempdir = tempfile.mkdtemp(prefix='sendqaemail.') try: -subprocess.check_call(["git", "clone", "g...@git.yoctoproject.org:yocto-testresults", tempdir]) +subprocess.check_call(["git", "clone", "g...@git.yoctoproject.org:yocto-testresults", tempdir, "--depth", "5"]) # If the base comparision branch isn't present regression comparision won't work # at least until we can tell the tool to ignore internal branch information -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50478): https://lists.yoctoproject.org/g/yocto/message/50478 Mute This Topic: https://lists.yoctoproject.org/mt/76695565/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 01/32] run-config: Preface log output with auto.conf settings to aid debugging
Signed-off-by: Richard Purdie
---
scripts/run-config | 8
1 file changed, 8 insertions(+)
diff --git a/scripts/run-config b/scripts/run-config
index 3566d3b..a0e0204 100755
--- a/scripts/run-config
+++ b/scripts/run-config
@@ -133,6 +133,14 @@ def bitbakecmd(builddir, cmd, report, stepnum, logsuffix,
oeenv=True):
print("Running '%s' with output to %s" % (cmd, log))
flush()
+autoconf = builddir + "/conf/auto.conf"
+if os.path.exists(autoconf):
+with open(autoconf, "r") as inf, open(log, "a") as outf:
+outf.write("auto.conf settings:\n")
+for line in inf.readlines():
+outf.write(line)
+outf.write("\n")
+
with subprocess.Popen(cmd, shell=True, cwd=builddir + "/..",
stdout=subprocess.PIPE, stderr=subprocess.STDOUT, bufsize=1) as p, open(log,
'ab') as f:
for line in p.stdout:
if not args.quietlogging:
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50473): https://lists.yoctoproject.org/g/yocto/message/50473
Mute This Topic: https://lists.yoctoproject.org/mt/76695557/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 15/32] scripts/send-qa-email: fix bug in git push logic for yocto-testresults
From: Steve Sakoman We were mistakenly doing a force push if the branch was in either BUILD_HISTORY_FORKPUSH or BUILD_HISTORY_DIRECTPUSH. Now we force push for branches in BUILD_HISTORY_FORKPUSH, regular push for branches in BUILD_HISTORY_DIRECTPUSH, and no push if the branch is in neither list. Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie --- scripts/send-qa-email | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/send-qa-email b/scripts/send-qa-email index 7dbc290..a265a7c 100755 --- a/scripts/send-qa-email +++ b/scripts/send-qa-email @@ -77,10 +77,10 @@ if 'poky' in repos and os.path.exists(resulttool) and args.results_dir: extraopts = None subprocess.check_call([resulttool, "store", args.results_dir, tempdir]) -if basebranch: +if comparebranch: subprocess.check_call(["git", "push", "--all", "--force"], cwd=tempdir) subprocess.check_call(["git", "push", "--tags", "--force"], cwd=tempdir) -else: +elif basebranch: subprocess.check_call(["git", "push", "--all"], cwd=tempdir) subprocess.check_call(["git", "push", "--tags"], cwd=tempdir) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50487): https://lists.yoctoproject.org/g/yocto/message/50487 Mute This Topic: https://lists.yoctoproject.org/mt/76695576/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 04/32] config.json: Disable buildtools tarball on centos7 as its missing crypt.h
Signed-off-by: Richard Purdie
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.json b/config.json
index a251d53..70faf73 100644
--- a/config.json
+++ b/config.json
@@ -959,6 +959,6 @@
},
"buildtools" : {
-"centos7*" : "${BUILDTOOLS_URL}"
+"disabled-centos7*" : "${BUILDTOOLS_URL}"
}
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50476): https://lists.yoctoproject.org/g/yocto/message/50476
Mute This Topic: https://lists.yoctoproject.org/mt/76695563/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 12/32] config.json: Update to 3.1M3 for buildtools tarball and apply to centos7/debian8
Signed-off-by: Richard Purdie
---
config.json | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/config.json b/config.json
index 70faf73..20e74e1 100644
--- a/config.json
+++ b/config.json
@@ -8,7 +8,8 @@
"BUILD_HISTORY_DIRECTPUSH" : ["poky:morty", "poky:pyro", "poky:rocko",
"poky:sumo", "poky:thud", "poky:warrior", "poky:zeus", "poky:master"],
"BUILD_HISTORY_FORKPUSH" : {"poky-contrib:ross/mut" : "poky:master",
"poky:master-next" : "poky:master"},
-"BUILDTOOLS_URL" :
"http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M2/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.0%2Bsnapshot-20200122.sh";,
+"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" :
"http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M3/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.0+snapshot-20200315.sh";,
"REPO_STASH_DIR" : "${BASE_HOMEDIR}/git/mirror",
"TRASH_DIR" : "${BASE_HOMEDIR}/git/trash",
@@ -959,6 +960,7 @@
},
"buildtools" : {
-"disabled-centos7*" : "${BUILDTOOLS_URL}"
+"debian8*" : "${BUILDTOOLS_URL}",
+"centos7*" : "${BUILDTOOLS_URL}"
}
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50484): https://lists.yoctoproject.org/g/yocto/message/50484
Mute This Topic: https://lists.yoctoproject.org/mt/76695572/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 07/32] scripts/run-config: Handle multiple builds racing with lockfile for buildtools
Signed-off-by: Richard Purdie
---
scripts/run-config | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/scripts/run-config b/scripts/run-config
index 8e175d0..5c6a9ca 100755
--- a/scripts/run-config
+++ b/scripts/run-config
@@ -10,6 +10,7 @@ import subprocess
import errno
import fnmatch
import glob
+import fcntl
import utils
@@ -107,10 +108,15 @@ if bttarball:
btdir = args.builddir + "/../buildtools"
if not os.path.exists(btdir):
btdlpath = utils.getconfig("BASE_SHAREDDIR", ourconfig) +
"/buildtools/" + os.path.basename(bttarball)
-if not os.path.exists(btdlpath):
+btlock = btdlpath + ".lock"
+if not os.path.exists(os.path.dirname(btdlpath)):
os.makedirs(os.path.dirname(btdlpath), exist_ok=True)
-subprocess.check_call(["wget", "-O", btdlpath, bttarball])
-os.chmod(btdlpath, 0o775)
+with open(btlock, 'a+') as lf:
+fileno = lf.fileno()
+fcntl.flock(fileno, fcntl.LOCK_EX)
+if not os.path.exists(btdlpath):
+subprocess.check_call(["wget", "-O", btdlpath, bttarball])
+os.chmod(btdlpath, 0o775)
subprocess.check_call(["bash", btdlpath, "-d", btdir, "-y"])
btenv = glob.glob(btdir + "/environment-setup*")
# We either parse or wrap all our execution calls, rock and a hard place :(
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50479): https://lists.yoctoproject.org/g/yocto/message/50479
Mute This Topic: https://lists.yoctoproject.org/mt/76695566/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH][autobuilder-helper][zeus 10/32] scripts/run-config: Ensure racing for the lockfile doesn't traceback
Traceback (most recent call last):
File "yocto-autobuilder-helper/scripts/run-config", line 116, in
fcntl.flock(fileno, fcntl.LOCK_EX)
OSError: [Errno 22] Invalid argument
Signed-off-by: Richard Purdie
---
scripts/run-config | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/scripts/run-config b/scripts/run-config
index 9d8d48a..ed13ca0 100755
--- a/scripts/run-config
+++ b/scripts/run-config
@@ -111,15 +111,20 @@ if bttarball:
btlock = btdlpath + ".lock"
if not os.path.exists(os.path.dirname(btdlpath)):
os.makedirs(os.path.dirname(btdlpath), exist_ok=True)
-with open(btlock, 'a+') as lf:
-fileno = lf.fileno()
-fcntl.flock(fileno, fcntl.LOCK_EX)
-if not os.path.exists(btdlpath):
-if bttarball.startswith("/"):
-subprocess.check_call(["cp", bttarball, btdlpath])
-else:
-subprocess.check_call(["wget", "-O", btdlpath, bttarball])
-os.chmod(btdlpath, 0o775)
+while True:
+try:
+with open(btlock, 'a+') as lf:
+fileno = lf.fileno()
+fcntl.flock(fileno, fcntl.LOCK_EX)
+if not os.path.exists(btdlpath):
+if bttarball.startswith("/"):
+subprocess.check_call(["cp", bttarball, btdlpath])
+else:
+subprocess.check_call(["wget", "-O", btdlpath,
bttarball])
+os.chmod(btdlpath, 0o775)
+except OSError:
+# We raced with someone else, try again
+pass
subprocess.check_call(["bash", btdlpath, "-d", btdir, "-y"])
btenv = glob.glob(btdir + "/environment-setup*")
# We either parse or wrap all our execution calls, rock and a hard place :(
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50482): https://lists.yoctoproject.org/g/yocto/message/50482
Mute This Topic: https://lists.yoctoproject.org/mt/76695570/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Multiconfig question
On Mon, 2020-09-07 at 15:53 +0100, Eil?s N? Fhlannag?in wrote: > Assuming this: > > bitbake multiconfig:ConfigA:core-image-foo multiconfig:ConfigB:core- > image-bar > > Is there a way during or before the rootfs of ConfigB:core-image-bar > to tell what else was run during execution? > > What I'm trying to do is set an mcdepends in ConfigB:core-image-bar > to magically know everything else it was built with. That sounds potentially quite problematic from a determinism perspective? We do try and be deterministic. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50471): https://lists.yoctoproject.org/g/yocto/message/50471 Mute This Topic: https://lists.yoctoproject.org/mt/76688021/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH yocto-autobuilder-helper] config.json: add binutils to images where it's required by tests
On Thu, 2020-08-27 at 13:01 +0200, Alexander Kanavin wrote: > On Wed, 26 Aug 2020 at 23:03, Richard Purdie < > richard.pur...@linuxfoundation.org> wrote: > > > I didn't write either of the tests, but yes - I can work on this > > > tomorrow. > > > > Right, I didn't write them either, they're rather old. I'm just > > thinking whilst we've gotten this far we may as well fix this > > properly > > and stop it being copy and pasted onward. I appreciate the help! > > And done, patches sent :) Bonus fix: one of the multilib tests was > erroneously always skipped. Thanks, much appreciated! I had a question on the skipped test. I think its only applicable to one specific multilib test case... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50388): https://lists.yoctoproject.org/g/yocto/message/50388 Mute This Topic: https://lists.yoctoproject.org/mt/76431587/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH yocto-autobuilder-helper] config.json: add binutils to images where it's required by tests
On Wed, 2020-08-26 at 23:00 +0200, Alexander Kanavin wrote:
> On Wed, 26 Aug 2020 at 22:50, Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
> > I suspect we need binutils-symlinks instead of binutils?
>
> binutils-symlinks is only an alias to the main package according to
> binutils.inc:
>
> RPROVIDES_${PN} += "${PN}-symlinks"
Fair enough, I suspect I'm getting it confused with gcc-symlinks.
> > Also, thinking about this more, why aren't these tests scp'ing the
> > file
> > to the host system and running readelf there? That would remove the
> > need for the dependency?
>
> I didn't write either of the tests, but yes - I can work on this
> tomorrow.
Right, I didn't write them either, they're rather old. I'm just
thinking whilst we've gotten this far we may as well fix this properly
and stop it being copy and pasted onward. I appreciate the help!
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50383): https://lists.yoctoproject.org/g/yocto/message/50383
Mute This Topic: https://lists.yoctoproject.org/mt/76431587/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH yocto-autobuilder-helper] config.json: add binutils to images where it's required by tests
On Wed, 2020-08-26 at 17:54 +0200, Alexander Kanavin wrote:
> Previously it was pulled in implicitly via poky default config.
>
> Signed-off-by: Alexander Kanavin
> ---
> config.json | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/config.json b/config.json
> index b78cba7..25be864 100644
> --- a/config.json
> +++ b/config.json
> @@ -452,6 +452,7 @@
> "step2" : {
> "SANITYTARGETS" : "core-image-sato:do_testimage",
> "extravars" : [
> +"IMAGE_INSTALL_append = ' binutils'",
> "TEST_SUITES_append = ' x32lib'"
> ]
> }
> @@ -501,7 +502,7 @@
> "MULTILIBS = 'multilib:lib32'",
> "DEFAULTTUNE_virtclass-multilib-lib32 = 'x86'",
> "RPM_PREFER_ELF_ARCH = '1'",
> -"IMAGE_INSTALL_append = ' lib32-connman-gnome
> gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png
> lib32-gdk-pixbuf-loader-png pango-module-basic-fc
> lib32-pango-module-basic-fc'"
> +"IMAGE_INSTALL_append = ' binutils lib32-connman-gnome
> gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png
> lib32-gdk-pixbuf-loader-png pango-module-basic-fc
> lib32-pango-module-basic-fc'"
> ]
> },
> "step4" : {
> @@ -514,7 +515,7 @@
> "MULTILIBS = 'multilib:lib32'",
> "DEFAULTTUNE_virtclass-multilib-lib32 = 'x86'",
> "RPM_PREFER_ELF_ARCH = '1'",
> -"IMAGE_INSTALL_append = ' lib32-connman-gnome
> gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png
> lib32-gdk-pixbuf-loader-png pango-module-basic-fc
> lib32-pango-module-basic-fc'"
> +"IMAGE_INSTALL_append = ' binutils lib32-connman-gnome
> gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png
> lib32-gdk-pixbuf-loader-png pango-module-basic-fc
> lib32-pango-module-basic-fc'"
> ]
> },
> "step5" : {
I suspect we need binutils-symlinks instead of binutils?
Also, thinking about this more, why aren't these tests scp'ing the file
to the host system and running readelf there? That would remove the
need for the dependency?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50381): https://lists.yoctoproject.org/g/yocto/message/50381
Mute This Topic: https://lists.yoctoproject.org/mt/76431587/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH] meta-yocto-bsp: Bump to the v5.8 kernel
On Wed, 2020-08-26 at 08:44 -0400, Bruce Ashfield wrote: > On Wed, Aug 26, 2020 at 2:22 AM Kevin Hao > wrote: > > Boot test for all the supported boards. There is a kernel config > > check warning for beaglebone-yocto, the fix [1] has been sent to > > kernel-meta for merging. > > > > [1] https://lists.yoctoproject.org/g/linux-yocto/message/8992 > > > > Thanks Kevin! Most appreciated. > > I'll have that meta data change merged today. Its timely and very much appreciated! Also merged now as testing was fine, thanks! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50376): https://lists.yoctoproject.org/g/yocto/message/50376 Mute This Topic: https://lists.yoctoproject.org/mt/76423360/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [devtool] problem with PACKAGE_ARCH and TARGET_OS
On Tue, 2020-08-25 at 14:47 +0200, Adrian wrote:
> Hi,
>
> After recent update of poky, I started to experience an issue with
> devtool. Currently, I am using the latest zeus version. I have a
> multiconfig environment (Xilinx ZynqMP+ with ARM64 and Microblaze). I
> am
> modifying my recipe compiled from local sources. The custom target
> machine configuration sets DEAULTTUNE="cortexa53"
>
> When I call:
>
> $> devtool build peary
> $>devtool deploy-target peary root@192.168.33.167
>
> I get the error:
>
> ERROR: No files to deploy - have you built the peary recipe? If so,
> the
> install step has not installed any files.
>
> In fact, I see that 'devtool build' creates image under
> '/home/afiergol/poky/build/tmp/work/aarch64-poky-
> linux/peary/1.0+git999-r0/image',
> while 'devtool deploy-target' search for files under
> '/home/afiergol/poky/build/tmp/work/cortexa53-poky-linux-
> gnueabi/peary/1.0+git999-r0/image'
>
> If in the 'peary' recipe I add a line
>
> PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> 'devtool deploy-target' starts to search under
> '/home/afiergol/poky/build/tmp/work/aarch64-poky-linux-
> gnueabi/peary/1.0+git999-r0/image'
>
> If further, I fix in the 'peary' recipe:
>
> TARGET_OS = "linux"
>
> 'devtool deploy-target' properly deploys the binaries to the target
> machine.
>
> However, as I explained, I had to fix in the recipe PACKAGE_ARCH and
> TARGET_OS variables. It is required only for devtool to work, as
> bitbake
> builds properly my custom Linux image containing the recipe without
> those variables being set anywhere in my layer.
>
> Has anybody else experienced a similar issue? Could somebody give a
> reference (I didn't find) to documentation which explains why and how
> those variables need to be set (I especially concerned about
> TARGET_OS)?
devtool is working for other recipes in oe-core so this peary recipe is
probably doing something which is confusing devtool. Or its perhaps the
machine configuration. Is that a public recipe? If not, is there a
recipe you could share which shows the issue?
Basically we need some way to reproduce the issue to be able to
comment. You certainly should not have to set those variables.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50356): https://lists.yoctoproject.org/g/yocto/message/50356
Mute This Topic: https://lists.yoctoproject.org/mt/76406086/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Additional log handler
On Mon, 2020-08-24 at 08:10 -0500, Joshua Watt wrote: > The newer log handling uses Python's structure logging configuration > [1], so you should be able to use whatever capabilities it has > (including logging different domains/levels to a separate file). In > fact, this is the only way logging is handled by core bitbake now; > all of the other logging mechanisms used by the UI are additional > configuration specified on top of the user's BB_LOGCONFIG file. If > you are interested, you can see this in bitbake/lib/bb/ui/knotty.py. > In that file is an additional tool that might be helpful. Around line > 553, there are two commented lines of code: > > #import logging_tree > #logging_tree.printout() > > uncommenting them and installing the logging_tree python package will > make bitbake dump the entire structured logging configuration to > stdout on startup so you can look at it. On a slightly different but related note, could we remove the debug_domains code now? I assume that can all be handled by BB_LOGCONFIG? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50334): https://lists.yoctoproject.org/g/yocto/message/50334 Mute This Topic: https://lists.yoctoproject.org/mt/76366066/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Additional log handler
On Sun, 2020-08-23 at 17:01 +0200, Konrad Weihmann wrote: > Hi all, > > when running bitbake in CI I would like to add an additional log > handler to used python logging to catch *ALL* (task warnings, > dangling append, qa issues, a.s.o.), instead of manually grepping > through the console log. > The information coming from this should be ideally be written to a > file, file, which can then serve as some sort of report. > > Is there a way to do that? > > In theory it should be possible to hook to an (obviously non- > existing) > event and handle it from there, right? > > Or am I thinking in the wrong direction? > > Any pointers are appreciated from my side... On the autobuilder the code simple watches the console log, filtering on WARNING: and produces a separate warning stream. A non empty file triggers the build to show a having warnings. At the bitbake level it would also definitely be possible, the log messages are seen in the UI code as events and it can do whatever it wants with them. There was a also much more advanced log handling added recently through the BB_LOGCONFIG variable. I'm not sure if that can define a completely separate stream or not, I've not tried that. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50328): https://lists.yoctoproject.org/g/yocto/message/50328 Mute This Topic: https://lists.yoctoproject.org/mt/76366066/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH] [meta-mingw] nativesdk-packagegroup-sdk-host: Update to match oe-core default providers handling
This was repsonsible for some strange differences in behaviour between
other OE-Core recipes and this one. Its assumed this package is present
in any SDK build.
Signed-off-by: Richard Purdie
---
.../packagegroups/nativesdk-packagegroup-sdk-host.bbappend | 1 +
1 file changed, 1 insertion(+)
diff --git
a/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
b/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
index a9a51a6..b3ffb82 100644
--- a/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
+++ b/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
@@ -1,4 +1,5 @@
RDEPENDS_${PN}_mingw32 = "\
+nativesdk-sdk-provides-dummy \
nativesdk-pkgconfig \
nativesdk-libtool \
nativesdk-qemu \
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50314): https://lists.yoctoproject.org/g/yocto/message/50314
Mute This Topic: https://lists.yoctoproject.org/mt/76328787/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-3.0.4.rc1)
On Wed, 2020-08-19 at 09:09 +, Jain, Sangeeta wrote: > This is the full report for yocto-3.0.4.rc1: > https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults > > === Summary > No high milestone defects. > No new defects are found in this cycle. Thanks Sangeeta and team! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50307): https://lists.yoctoproject.org/g/yocto/message/50307 Mute This Topic: https://lists.yoctoproject.org/mt/76203993/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-3.0.4.rc1)
On Mon, 2020-08-17 at 09:48 +0200, Zoran Stojsavljevic wrote: > > Intel and WR YP QA is planning for QA execution for YP > > build yocto-3.0.3.rc2. > > With all due respect... INTEL part I'll drop out. ;-) > > Better to keep YOCTO as an Open Source project without > mentioning ECO systems financing it... Correct?! > > YOCTO is an (Force Major context) Open Source project... Isn't it?! Yocto Project is an open source project and it accepts contributions to both code and in other work like QA from anyone. The QA process is publicly documented, publicly announced and anyone can help with ensuring our releases are up to the quality expected of us. It is perfectly reasonable that companies stepping forward like this to do work can refer to themselves by name. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50289): https://lists.yoctoproject.org/g/yocto/message/50289 Mute This Topic: https://lists.yoctoproject.org/mt/76203993/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-3.0.4.rc1)
On Sat, 2020-08-15 at 05:06 +, Poky Build User wrote: > A build flagged for QA (yocto-3.0.4.rc1) was completed on the > autobuilder and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-3.0.4.rc1 > > > Build hash information: > > bitbake: fd279f857c98d492f43cc62d9ebae18ce6412b6e > meta-arm: 38de27d05f104f989adfed5c5363464dd600b316 > meta-gplv2: 0f4eecc000f66d114ad258fa31aed66afa292166 > meta-intel: ce6f8ddd2d7f42a9fe530d30332b0d9695e4904b > meta-kernel: cb7f0dc5bb1ea0998c8d4fcb486148d4cab575f4 > meta-mingw: 756963cc28ebc163df7d7f4b4ee004c18d3d3260 > oecore: 9cad716656b427e625a470a820b8b29b1ec9f976 > poky: f2eb22a8783f1eecf99bd4042695bab920eed00e Looks like there were 4 failures in this build: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/2309 https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1247 https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/1249 https://autobuilder.yoctoproject.org/typhoon/#/builders/69/builds/2302 Two are from vulkan-tools where time.clock() was removed from python 3.8. I think one is a known virtgl failure. We should perhaps just abort that test on the problematic host? The other set of failures are timeout issues on centos7-ty-1 which look like known intermittent failures, particularly on that host. I don't think any of there are 3.0.4 regressions and therefore shouldn't stop the release IMO. We do need to release note the vulkan- tools issue with py 3.8. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50276): https://lists.yoctoproject.org/g/yocto/message/50276 Mute This Topic: https://lists.yoctoproject.org/mt/76203993/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Is http://downloads.yoctoproject.org/ down?
On Thu, 2020-08-06 at 15:31 -0700, Scott Branden wrote:
> > diff --git a/meta/classes/uninative.bbclass
> > b/meta/classes/uninative.bbclass
> > index 70799bbf6d..99072e1326 100644
> > --- a/meta/classes/uninative.bbclass
> > +++ b/meta/classes/uninative.bbclass
> > @@ -56,9 +56,14 @@ python uninative_event_fetchloader() {
> > # Our games with path manipulation of DL_DIR mean
> > standard PREMIRRORS don't work
> > # and we can't easily put 'chksum' into the url path
> > from a url parameter with
> > # the current fetcher url handling
> > -ownmirror = d.getVar('SOURCE_MIRROR_URL')
> > -if ownmirror:
> > -localdata.appendVar("PREMIRRORS", "
> > ${UNINATIVE_URL}${UNINATIVE_TARBALL}
> > ${SOURCE_MIRROR_URL}/uninative/%s/${UNINATIVE_TARBALL}" % chksum)
> > +premirrors =
> > bb.fetch2.mirror_from_string(localdata.getVar("PREMIRRORS"))
> > +for line in premirrors:
> > +try:
> > +(find, replace) = line
> > +except ValueError:
> > +continue
> > +if find.startswith("http"):
> > +localdata.appendVar("PREMIRRORS", "
> > ${UNINATIVE_URL}${UNINATIVE_TARBALL}
> > %s/uninative/%s/${UNINATIVE_TARBALL}" % (replace, chksum))
> >
> > srcuri =
> > d.expand("${UNINATIVE_URL}${UNINATIVE_TARBALL};sha256sum=%s" %
> > chksum)
> > bb.note("Fetching uninative binary shim from %s" %
> > srcuri)
>
> Note is missleading as it is going to fetch from PREMIRRORS.
>
> > Hopefully that handles this case more generically.
> Yes, this works. uninative is now fetched from the PREMIRRORS like
> all the other downloads even though it prints the note about Fetching
> uninative binary shim from the URL.
Thanks, I've tweaked the patch to improve the note and submitted it.
Good to get to the bottom of this!
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50241): https://lists.yoctoproject.org/g/yocto/message/50241
Mute This Topic: https://lists.yoctoproject.org/mt/74157229/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Is http://downloads.yoctoproject.org/ down?
On Thu, 2020-08-06 at 11:05 -0700, Scott Branden wrote:
> We found the source of the uninative fetch problem:
>
> SOURCE_MIRROR_URL needs to be set in order for uninative to be picked
> up from local mirror.
>
> The standard PREMIRRORS mechanism doesn't work for this single
> tarball.
> So every time a clean poky build took place it always went to the
> internet to fetch the uninative tarball
> the first time and store it in the local build download.
>
> I think this should be clearly documented somewhere in the yocto
> manual?
That definitely explains things. I think its assumed that people would
set appropriate PREMIRRORS to cover uninative in this case but that
isn't documented. I'm not even sure we want for people to have to care
about this :/.
Can you try this change:
diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 70799bbf6d..99072e1326 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -56,9 +56,14 @@ python uninative_event_fetchloader() {
# Our games with path manipulation of DL_DIR mean standard
PREMIRRORS don't work
# and we can't easily put 'chksum' into the url path from a url
parameter with
# the current fetcher url handling
-ownmirror = d.getVar('SOURCE_MIRROR_URL')
-if ownmirror:
-localdata.appendVar("PREMIRRORS", "
${UNINATIVE_URL}${UNINATIVE_TARBALL}
${SOURCE_MIRROR_URL}/uninative/%s/${UNINATIVE_TARBALL}" % chksum)
+premirrors =
bb.fetch2.mirror_from_string(localdata.getVar("PREMIRRORS"))
+for line in premirrors:
+try:
+(find, replace) = line
+except ValueError:
+continue
+if find.startswith("http"):
+localdata.appendVar("PREMIRRORS", "
${UNINATIVE_URL}${UNINATIVE_TARBALL} %s/uninative/%s/${UNINATIVE_TARBALL}" %
(replace, chksum))
srcuri =
d.expand("${UNINATIVE_URL}${UNINATIVE_TARBALL};sha256sum=%s" % chksum)
bb.note("Fetching uninative binary shim from %s" % srcuri)
Hopefully that handles this case more generically.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50231): https://lists.yoctoproject.org/g/yocto/message/50231
Mute This Topic: https://lists.yoctoproject.org/mt/74157229/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Mirroring meta-kernel on git.yoctoproject.org
On Mon, 2020-08-03 at 09:56 +0100, Paul Barker wrote: > I'd like to get the meta-kernel layer mirrored on > git.yoctoproject.org > so that we've got a backup available in case of any issues with > GitLab. This has been requested by one of our users > (https://gitlab.com/openembedded/community/meta-kernel/-/issues/11). > I > also think it's important now that meta-arm-bsp and a few other > layers > depend on meta-kernel. > > I can enable an automatic push from GitLab whenever the repository is > updated so all we would need on git.yoctoproject.org is a meta-kernel > repository and push access from the relevant SSH keys. I've had to think carefully about this and I think we can only say no. The reason is the namespacing. This is taking a special namespace and its doing it by stealth, not a conscious decision. If we do this, its going to create confusion for users and also create friction with other Yocto Project components. This was warned about when "meta-kernel" was started and now its coming back to bite us :(. I suspect this is something which will you'll want to appeal against and I should therefore refer it to the YP TSC? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50211): https://lists.yoctoproject.org/g/yocto/message/50211 Mute This Topic: https://lists.yoctoproject.org/mt/75961854/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Yocto host not found
On Tue, 2020-08-04 at 14:10 -0700, Rick Liu via lists.yoctoproject.org wrote: > Does http://downloads.yoctoproject.org/ have HA or hot-backup > machine? > Is there an instruction on how to create a > http://downloads.yoctoproject.org/ local mirror and sync? The standard DL_DIR should be enough for normal builds to work, based on Scott's questions, it sounds like there is some issue somewhere which would be worth looking into. I don't see that issue locally or on the autobuilder infrastructure so its hard for me to say what is wrong. Regarding HA or hot-backup, our resilience places are supposed to be that: a) DL_DIR should allow existing builds to work b) kernel.org has a partial mirror of the key components c) we just have to accept the autobuilder would be unavailable in the case of NAS failure until its repaired It sounds like something isn't working quite right for a) to be having an issue. We'd love to have more server infrastructure and have things like hot backup machines. Our budgets and infrastructure allow us to have what we have. I'd note that broadcom were once a silver member but dropped project membership, sadly :(. We do the best we can with what we have. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50207): https://lists.yoctoproject.org/g/yocto/message/50207 Mute This Topic: https://lists.yoctoproject.org/mt/69588660/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Is http://downloads.yoctoproject.org/ down?
On Tue, 2020-08-04 at 14:36 -0700, Scott Branden via lists.yoctoproject.org wrote: > With downloads.yoctoproject.org down again this begs the question: > > Why does uninative tarball get fetched by default from the internet > every time? > Why is it in not cached like every other tarball that is downloaded > by recipes? > The default behaviour for the yocto project should be to have the > tarball stored in the yocto cache such that it is not fetched every > time? Those are good questions. As far as I know on my own local builds, the uninative tarball *is* cached locally in DL_DIR. We don't see repeated downloads on the autobuilder either so it appears to work there too. If you're not seeing that it would definitely be something to investigate. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50206): https://lists.yoctoproject.org/g/yocto/message/50206 Mute This Topic: https://lists.yoctoproject.org/mt/74157229/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [swupdate] [meta-swupdate][PATCH] mtd-utils: Remove patchs
On Thu, 2020-07-30 at 10:34 +0200, Stefano Babic wrote: > Hi Zheng, > > I do not discuss abot the correctness of these patches (that I will > aplly to meta-swupdate, -master), but about mtd-utils version (for > this I pick up Richard in CC). There were in last month more breakage > around mtd-utils due to patches (required !) that are applied to an > undefined (from recipe) version of mtd-utils. > > In fact, we have mtd-utils_git.bb in poky, and as "git" version, the > expectation is that it points to TOT. But this is not the case, and > meta- outside poky just add some patches to a not well > defined version. > > Should we also replace mtd-utils_git.bb with a more precise > mtd-utils_2.1.2.bb ? Adding patches in bbappends is always going to be high maintenance. Are these patches swupdate specific? The recipes use "git" in the filename and then set a sepcific SRCREV and set PV correctly. This is an accepted behaviour. I can see how renaming the recipe would also help for certain usecases but both are really correct for different reasons. I'd also note that git versions in oe-core are always locked down to something and that something is therefore likely not to be TOT as they don't get updated frequently enough. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50143): https://lists.yoctoproject.org/g/yocto/message/50143 Mute This Topic: https://lists.yoctoproject.org/mt/75882692/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [bitbake-devel] [yocto] Stable Warrior branch
On Tue, 2020-07-14 at 16:56 +0300, Adrian Bunk wrote: > On Thu, Jun 04, 2020 at 09:28:00PM -0700, akuster wrote: > > Hello, > > > > The Warrior branch of Poky has had its last official dot release. > > It > > will be moving to Community support and EOL within 6 weeks if no > > one > > steps up. > > If someone is interested in taking on the responsibilities of > > maintaining the "Warrior" branch moving forward, please email this > > list. > > I have an interest in keeping warrior branch alive in poky and meta- > oe, > and I'll take this responsibility since noone else seems to be > interested. > > > Please look at the > > https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS for what > > will > > be expected. > > I have some ideas, but not yet a fixed plan how I will set this up. Ok. FWIW we are struggling a little with keeping the older releases building on the autobuilder as the workers change. We do have plans for handling this with buildtools but its not rolled out on the older autobuilder-helper branches. I do have work in progress working with Jeremy for thud (contrib/rpurdie/thud), much of which should apply to warrior too (contrib/rpurdie/warrior is a guess). I just really want to highlight that there may be some initial work to get these older branches to the point where they continue to work on the infrastructure. I think we may have to accept backporting a lot of patches in helper to bring things more into sync with master/dunfell to make all this easier to maintain/get working. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50034): https://lists.yoctoproject.org/g/yocto/message/50034 Mute This Topic: https://lists.yoctoproject.org/mt/75699867/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Adjusting Extensible SDK for build setup
On Mon, 2020-07-20 at 17:13 +, Monsees, Steven C (US) wrote: > No, I guess I wasn't clear, I needed to add to lines of code in the > scripts to adjust things so that my env script was copied to the > proper SDK build env "layers" directory and set the conf_initpath to > use my env script... > > The variable assignments mentioned are configured in my distro config > for the overall SDK build. It would be helpful to understand which two lines you needed to modify and how. Was the setup script being copied at all without your changes? If so where was it being copied? If not, what did you change and where was it copied afterwards? What value are you setting conf_initpath to? Its very difficult to answer questions on a layer structure which isn't clearly described :( Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50014): https://lists.yoctoproject.org/g/yocto/message/50014 Mute This Topic: https://lists.yoctoproject.org/mt/75683471/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Adjusting Extensible SDK for build setup
On Mon, 2020-07-20 at 16:28 +, Monsees, Steven C (US) wrote: > Yes, this is what I saw as well... > > I had to add two lines to the populate_sdk_ext.bbclass to properly > get it to pick up my env script. > I set : > > OE_INIT_ENV_SCRIPT = "setup-build-env" > CORE_BASE_Files = " \ >Scripts \ >LICENSE \ >.templateconf \ > " > This allowed me to build the "minimale SDK EXT. > > SDK_EXT_TYPE = "minimal" > SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS" > > Was hoping I would be able to configure the variables rather than > modify the script... > Do not want to introduce future support ussues if possible. Both variables are assigned with weak defaults. Can't you just set those variables in your own distro config to override the defaults? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50011): https://lists.yoctoproject.org/g/yocto/message/50011 Mute This Topic: https://lists.yoctoproject.org/mt/75683471/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Adjusting Extensible SDK for build setup
On Mon, 2020-07-20 at 15:57 +, Monsees, Steven C (US) wrote: > The BUILDDIR is defined as configurable under Yocto... > > I set this up as per the Yocto docs based on the "MACHINE' I am > building, I do not believe this is the issue. > > There is no issue when building the standard SDK... > > I am looking for the proper variable settings for COREBASE, > COREBASE_FILES, and OE_INIT_ENV_SCRIPT variables required by eSDK > when working with > a different environment setup script not located in the COREBASE > (i.e. poky) directory... Looking at the code in populate_sdk_ext.bbclass:copy_buildsystem(), it looks in each layer for the script specified in OE_INIT_ENV_SCRIPT. >From your description its impossible to know whether meta-limws or meta-bae is seen as individual layers and whether they're copied individually into layers/ in the eSDK or not. I'd guess that " meta-limws/setup-build-env" or "meta-bae/meta- limws/setup-build-env" should work as the value for OE_INIT_ENV_SCRIPT. If poky is being used and is unaltered, COREBASE and COREBASE_FILES should work unaltered. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50009): https://lists.yoctoproject.org/g/yocto/message/50009 Mute This Topic: https://lists.yoctoproject.org/mt/75683471/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Adjusting Extensible SDK for build setup
On Mon, 2020-07-20 at 15:06 +, Monsees, Steven C (US) wrote:
>
> I am fairly new to the Yocto SDK build process, and am looking to
> create an extensible SDK for one of our platforms.
>
> I am currently working with Rocko 2.4.1, in conjunction with
> uninative release 1.9…
>
> My current build system setup does not follow the standard
> configuration, I use a different environment setup script other than
> “oe-init-build-env”.
>
> My environment setup script “setup-build-env” is also not located in
> the ${COREBASE}, i.e. the “poky” directory, but rather at
> “${COREBASE}/../meta-bae/meta-limws”, the meta-limws level has
> multiple architecture sub levels (each an independent build), I am
> only looking to build an SDK for one of these architectures. Each
> architecture’s bblayers.conf provides the appropriate layers…
>
> My build directory is expected to reside here:
> “${COREBASE}/../meta-bae/meta-limws/builds, and there are multiple
> architecture builds under this directory
I think the build directory expectation isn't going to work with the
eSDK.
The eSDK is really designed against one configuration and the build
directory becomes that specific SDK. You therefore can't require some
sub directory of the eSDK become the build directory as that isn't how
its designed to operate.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50007): https://lists.yoctoproject.org/g/yocto/message/50007
Mute This Topic: https://lists.yoctoproject.org/mt/75683471/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Offline Build #yocto
On Mon, 2020-07-20 at 07:18 -0700, Amrun Nisha.R wrote: > For gnu-config-native-20150728, I have copied the git2 folder from > older build folder to new build folder. It is fixed now. > > But I'm getting do_fetch error for the ncurses and ncurses_native. I > have attached the log file for both packages. > > Actually I have doubts regarding the build folders: > 1. As mentioned above, I have copied the sources and download folder > to the another machine. While bitbaking, it again doing the do_fetch > process. Whether I have to copy the build folder (build_wayland)? > 2. Is there any particular folders should be copy other than the > sources and download folder to build the yocto project in offline? When you run the original build, where is DL_DIR pointing? Find that and make sure the same directory is available to the second build. It sounds a bit like you have multiple builds are not sharing the same DL_DIR so either make them share them, or copy them all. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50006): https://lists.yoctoproject.org/g/yocto/message/50006 Mute This Topic: https://lists.yoctoproject.org/mt/75676959/21656 Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Offline Build #yocto
On Sun, 2020-07-19 at 23:05 -0700, Amrun Nisha.R wrote: > I want to create a offline build using yocto. > > I have sources and downloads packages directory in which i can able to create > a successful bitbake. I have transferred those files to another system and > tried to build them in offline but it is not working. During Bitbake, I got > the below error. > > ERROR: gnu-config-native-20150728+gitAUTOINC+b576fa87c1-r0 do_unpack: Fetcher > failure: Fetch command export PSEUDO_DISABLED=1; export > DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-g7k0CS09Dd,guid=12ec7c389f454edf56e65e9a5f1271ce"; > export SSH_AGENT_PID="1474"; export > SSH_AUTH_SOCK="/tmp/ssh-uwTL38C6OxLZ/agent.1310"; export > PATH="/home/admin/Platform_Build/yocto/sources/poky/scripts/native-intercept:/home/admin/Platform_Build/yocto/sources/poky/scripts:/home/admin/Platform_Build/yocto/build/tmp/work/x86_64-linux/gnu-config-native/20150728+gitAUTOINC+b576fa87c1-r0/recipe-sysroot-native/usr/bin/x86_64-linux:/home/admin/Platform_Build/yocto/build/tmp/work/x86_64-linux/gnu-config-native/20150728+gitAUTOINC+b576fa87c1-r0/recipe-sysroot-native/usr/bin:/home/admin/Platform_Build/yocto/build/tmp/work/x86_64-linux/gnu-config-native/20150728+gitAUTOINC+b576fa87c1-r0/recipe-sysroot-native/usr/sbin:/home/admin/Platform_Build/yocto/build/tmp/work/x86_64-linux/gnu-config-native/20150728+gitAUTOINC+b576fa87c1-r0/recipe-sysroot-native/usr/bin:/home/admin/Platform_Build/yocto/build/tmp/work/x86_64-linux/gnu-config-native/20150728+gitAUTOINC+b576fa87c1-r0/recipe-sysroot-native/sbin:/home/admin/Platform_Build/yocto/build/tmp/work/x86_64-linux/gnu-config-native/20150728+gitAUTOINC+b576fa87c1-r0/recipe-sysroot-native/bin:/home/admin/Platform_Build/yocto/sources/poky/bitbake/bin:/home/admin/Platform_Build/yocto/build/tmp/hosttools"; > export HOME="/home/admin"; git -c core.fsyncobjectfiles=0 clone -s -n > /home/admin/Platform_Build/pltswcode/Yocto/Linux/downloads//git2/git.savannah.gnu.org.config.git/ > > /home/admin/Platform_Build/yocto/build/tmp/work/x86_64-linux/gnu-config-native/20150728+gitAUTOINC+b576fa87c1-r0/git/ > failed with exit code 128, output: > fatal: repository > '/home/admin/Platform_Build/pltswcode/Yocto/Linux/downloads//git2/git.savannah.gnu.org.config.git/' > does not exist > > ERROR: gnu-config-native-20150728+gitAUTOINC+b576fa87c1-r0 do_unpack: > Function failed: base_do_unpack > ERROR: Logfile of failure stored in: > /home/admin/Platform_Build/yocto/build/tmp/work/x86_64-linux/gnu-config-native/20150728+gitAUTOINC+b576fa87c1-r0/temp/log.do_unpack.619 > ERROR: Task > (virtual:native:/home/admin/Platform_Build/yocto/sources/poky/meta/recipes-devtools/gnu-config/gnu-config_git.bb:do_unpack) > failed with exit code '1' > NOTE: Tasks Summary: Attempted 68 tasks of which 63 didn't need to be rerun > and 1 failed. > > Summary: 1 task failed: > > virtual:native:/home/admin/Platform_Build/yocto/sources/poky/meta/recipes-devtools/gnu-config/gnu-config_git.bb:do_unpack > Summary: There was 1 WARNING message shown. > Summary: There were 2 ERROR messages shown, returning a non-zero exit code. > > I want to know : > 1. Why the bitbake command is not taking the downloads directory as it is ? > 2. Is there any other way to create the offline build without downloading the > yocto packages? In theory what you're describing should work. Could you share the do_fetch and do_unpack logs for the failing recipe so what we can see why it thinks it needs to download this again. gnu-config-native-20150728 suggests this is an older yocto project release too (between 2015 and 2018), its possible the issue was fixed in master or later release branches. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50002): https://lists.yoctoproject.org/g/yocto/message/50002 Mute This Topic: https://lists.yoctoproject.org/mt/75676959/21656 Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] how does "bitbake meta-toolchain" map to a particular "image" when generating SDK?
On Sun, 2020-07-05 at 15:24 -0400, Robert P. J. Day wrote: > Quoting Ross Burton : > > > On Sun, 5 Jul 2020 at 11:50, Robert P. J. Day wrote: > > >however, one can also generate a standard SDK with the generic > > > (image-independent): > > > > > >$ bitbake meta-toolchain > > > > > > which clearly does not identify an image (all that recipe does, > > > really, is "inherit populate_sdk"), so i *guessed* that using that > > > command will generate a standard SDK based only on what can be found > > > in the various .conf files and associated variables (MACHINE, DISTRO, > > > etc.) without being tied to a particular image. > > > > > >just about to dive into the details, but is the above at least a > > > simplistic way of looking at it? > > > > At the most fundamental level, you've asked bitbake to build > > 'meta-toolchain'. Looking in meta-toolchain.bb will show you what > > that entails. It's basically just the compilers and a few other tools > > that were added as needed over the years. > >i'd assumed as much, but is there a reason that the meta-toolchain target > is not mentioned at all in the SDK manual? Would that not be the right > place to mention it, even briefly? meta-toolchain is really old, from the days before the populate_sdk task for images existed. It was created as a compatibility artefact and as an example to show you could do standalone SDKs like that without images. I'd imagine its not mentioned as we envisaged the populate_sdk tasks taking over from meta-toolchain. I'm not even sure we test meta- toolchain on the autobuilder. It probably continues to work as its so similar to buildtools-tarball and friends. Should it be mentioned? Maybe... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49876): https://lists.yoctoproject.org/g/yocto/message/49876 Mute This Topic: https://lists.yoctoproject.org/mt/75311311/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] how crippled is ruby support in YP 3.0?
On Fri, 2020-06-26 at 14:19 -0400, Robert P. J. Day wrote: > background: trying to get ruby and a number of ruby gems migrated > from "morty" to "zeus", and nothing but grief trying to > compile/install ruby gems. > > plan A: start with standard YP layers all checked out to "zeus", > and > add vendor layer -- still similar grief. > > current plan: start from absolute scratch, new project targeting > x86_64, all layers checked out to "zeus", and build for > core-image-minimal (*that* i know i can do). > > then, little by little, add ruby content. has anyone here worked > with ruby and ruby gems extensively and has had to struggle to get > stuff working? as soon as this basic build is done, i'm going to just > add "ruby" to the image, and from there, start adding gems one by > one. > > should i expect this to go smoothly, or should i expect the pain > i've been through for the last couple days? If we actually had some tests for it, we might have a much better idea. The areas of the project with good automated tests tend not to regress without our noticing. Areas with no tests can and do :( Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49766): https://lists.yoctoproject.org/g/yocto/message/49766 Mute This Topic: https://lists.yoctoproject.org/mt/75130191/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH yocto-autobuilder-helper]scripts/publish-artefacts: Fix for Bug 13947:Change checksum file extension from sha256sum to sha256
On Wed, 2020-06-17 at 20:12 +, Vineela wrote:
> From: Vineela Tummalapalli
>
>
> ---
> scripts/publish-artefacts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/publish-artefacts b/scripts/publish-artefacts
> index 6ed922a..3ef7206 100755
> --- a/scripts/publish-artefacts
> +++ b/scripts/publish-artefacts
> @@ -7,10 +7,10 @@ sha256sums(){
> dest=$1
> for x in `find -L $dest -maxdepth 5 -type f`; do
> for w in $x;do
> -if [ ${w##*.} != sha256sum ]; then
> +if [ ${w##*.} != sha256 ]; then
> shasum=`sha256sum $w | awk '{print $1}'`
> filename=${w##*/}
> -echo $shasum $filename >> $w.sha256sum
> +echo $shasum $filename > $w.sha256
> fi
> done
> done
This is turning into a bit of a mess. The preferred naming is
"X.sha256sum" since it says what they are and is the most clear. In 3.1
and mostly in 3.1.1 they were called "X.sha256".
We need to decide if we just switch to the naming most of us don't
like, or we switch to the one which we'd prefer. I'm leaning to
switching as there isn't much that depends on these (yet) apart from
the buildtools script which we'd need to patch with the new version url
anyway.
Any other strong opinions? There was a recent comment we should
probably have a manifest file containing the checksums, I'm wondering
if that should replace the individual checksum files anyway?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49675): https://lists.yoctoproject.org/g/yocto/message/49675
Mute This Topic: https://lists.yoctoproject.org/mt/74945598/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] devtool modify issues with ubuntu 20 and fedora core 32
On Wed, 2020-06-03 at 11:06 +0200, Alexander Kanavin wrote: > I'm not sure if this is distro specific. _PYTHON_SYSCONFIGDATA_NAME > is set from python3native.bbclass so that native python can pick up > target configuration, and if the target configuration is not there > (it comes with target python3 build), then there will be a failure > like the above. How does your recipe look like? Do you get the same > failure if you try devtool modify in a plain yocto environment (not > the SDK)? Chris and I did talk about this on irc: (22:33:38) kergoth: actually fails even without prserv enabled at all (22:34:07) kergoth: just import pydoc will call sysconfig.get_path() which enters that codepath (22:34:22) kergoth: so calling anything that imports bb from a task will explode (22:34:33) kergoth: cooker pulls in xmlrpc, which pulls in pydoc (22:34:41) kergoth: breaks devtool modify (22:37:04) RP: kergoth: right, it was more about it being a hint at the kinds of issues (22:37:11) kergoth: ah, fair enough (22:37:26) kergoth: i expect we may need to change how python3native is doing its thing (22:42:55) RP: kergoth: quite possibly. I never liked that fix and suspected there was more to it :/ (23:21:39) kergoth: RP: maybe something like https://github.com/openembedded/openembedded-core/compare/master...kergoth:python-sysconfig ? i'll mull it over. makes sense, though. we rename _sysconfig only for the python3-native recipe, so it'd make sense for us to only change that name for our python, not any python run from the task (23:21:49) kergoth: _sysconfigdata, that is (23:46:35) RP: kergoth: something like that would make sense, yes Chris: Did you come to any conclusion? Does someone want to send a patch? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49568): https://lists.yoctoproject.org/g/yocto/message/49568 Mute This Topic: https://lists.yoctoproject.org/mt/74637733/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.4.rc2)
On Thu, 2020-05-28 at 00:28 -0400, William Mills via lists.yoctoproject.org wrote: > > On 5/27/20 6:42 PM, Michael Halstead wrote: > > I've rebuilt the fancyindex module and enabled it. The full filenames > > are displayed now. The module is disabled automatically when new > > versions of EPEL are released. Hopefully the change in html output > > doesn't break any script you've started writing. > > > > Thanks Michael. Its funny because I had switched machines in the > meantime and I was scratching my head. "how does Firefox know how to do > that when Chrome did not"? But I figured out you had made a change :) > > I also remembered "wget -r -np ". I have not used that is so long > I forgot about it. It downloads too much but it is a quick start. (It > downloads each symlink as a unique file.) > > So for the real solution I think I am only going to download the files > that have a .md5sum. I suppose I could recreate the symlinks > based on heuristics of the filename but I probably won't bother. > > It would still be nice to have an intentionally machine readable > directory of the full release content in one file in the root. > md5sum and crew won't show symlink vs real files. I'll keep thinking > about any existing format that might work. We do have a place we can hook in such a thing: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/scripts/send-qa-email Ignore the name, its purpose has changed since it was written, its now about summarising things at the end the build and the qa email is one possible outcome. So if someone wants to have a go at summarising the release output into a file we can plug it in there. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49523): https://lists.yoctoproject.org/g/yocto/message/49523 Mute This Topic: https://lists.yoctoproject.org/mt/74498171/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.4.rc2)
Hi Bill, On Wed, 2020-05-27 at 12:31 +, Mills, William wrote: > In a script, how would I download all the files in this dir: > > https://autobuilder.yocto.io/pub/releases/yocto-2.7.4.rc2/machines/beaglebone-yocto/ > > I see no global md5sum (or sha256sum etc) file in the tree anywhere. > > The names are cut off in the default html list format so screen > scrapping won't work. Is there an automated way to request a better > format? WebDav? Am I missing something obvious? If you look at the raw html it looks like: am335x-bone--5.0.13+git0+7f6e97c357_f990fd0ce1-..> 27-May-2020 07:00 56237 so the href is correct and its only the displayed url that is shortened. That is why you can click on them to get the artefacts and it is 'just' a display issue. It also means any script can pull the correct urls the same way. I think Michael has tweaked the line lengths in the past but it keeps getting reset to distro defaults as the machine is upgraded. He knows about it and will look at sorting that again. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49508): https://lists.yoctoproject.org/g/yocto/message/49508 Mute This Topic: https://lists.yoctoproject.org/mt/74498171/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [matchbox-desktop-2][PATCH] Add SPDX-License-Identifier: GPL-2.0-or-later
On Mon, 2020-03-23 at 11:53 -0400, Matthew wrote: > Fixes [YOCTO #13319] > > Signed-off-by: Mingde (Matthew) Zeng > --- > libtaku/inotify/inotify-diag.c| 2 ++ > libtaku/inotify/inotify-diag.h| 2 ++ > libtaku/inotify/inotify-kernel.c | 2 ++ > libtaku/inotify/inotify-kernel.h | 2 ++ > libtaku/inotify/inotify-missing.c | 2 ++ > libtaku/inotify/inotify-missing.h | 2 ++ > libtaku/inotify/inotify-path.c| 2 ++ > libtaku/inotify/inotify-path.h| 2 ++ > libtaku/inotify/inotify-sub.c | 2 ++ > libtaku/inotify/inotify-sub.h | 2 ++ Thanks for this. I did merge it however to be clear, the above files are under LGPL, not GPL. As such, I removed this part of the commit and added a second one of my own which resolves this. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49380): https://lists.yoctoproject.org/g/yocto/message/49380 Mute This Topic: https://lists.yoctoproject.org/mt/72495096/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] oddities(?) when appending to an override
On Mon, 2020-05-04 at 16:28 -0400, Robert P. J. Day wrote: > i bring this up because i've run across occasional examples of that > in the code base -- here's > meta-gnome/recipes-connectivity/libnma/libnma_1.8.28.bb: > > EXTRA_OEMESON_mipsarchn32_append = " -Dvapi=false" > > is that deliberate, or is it just asking for trouble? I suspect its a mistake. If you want to create a list of the potentially incorrect entries we can review them. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49340): https://lists.yoctoproject.org/g/yocto/message/49340 Mute This Topic: https://lists.yoctoproject.org/mt/73984196/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-gplv2] [PATCH 3/3] README: Document how to configure repo for sending patches
On Tue, 2020-05-05 at 12:01 +0100, Richard Purdie via lists.yoctoproject.org wrote: > Signed-off-by: Richard Purdie > --- > README | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/README b/README > index 4558a99..6a61331 100644 > --- a/README > +++ b/README > @@ -27,3 +27,8 @@ intended target branch of the Git repository. > > Git repository: http://git.yoctoproject.org/cgit.cgi/meta-gplv2/ > Mailing list: yo...@yoctoproject.org > + > +This can be confiured within the repository with the commands: configured. Tweaked in master-next. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49339): https://lists.yoctoproject.org/g/yocto/message/49339 Mute This Topic: https://lists.yoctoproject.org/mt/73996064/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-gplv2] [PATCH 3/3] README: Document how to configure repo for sending patches
Signed-off-by: Richard Purdie --- README | 5 + 1 file changed, 5 insertions(+) diff --git a/README b/README index 4558a99..6a61331 100644 --- a/README +++ b/README @@ -27,3 +27,8 @@ intended target branch of the Git repository. Git repository: http://git.yoctoproject.org/cgit.cgi/meta-gplv2/ Mailing list: yo...@yoctoproject.org + +This can be confiured within the repository with the commands: + +git config sendemail.to yocto@lists.yoctoproject.org +git config format.subjectprefix "meta-gplv2] [PATCH" -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49338): https://lists.yoctoproject.org/g/yocto/message/49338 Mute This Topic: https://lists.yoctoproject.org/mt/73995056/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-gplv2] [PATCH 2/3] disable-gplv3.inc: Disable glib-2.0 ptest python3-dbusmock dependency
The newly added dependency on python3-dbusmock in OE-Core is GPLv3
and would fail to work with this layer. Remove it in the config
for enabling the layer.
Signed-off-by: Richard Purdie
---
conf/distro/include/disable-gplv3.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/distro/include/disable-gplv3.inc
b/conf/distro/include/disable-gplv3.inc
index 45834b7..761be7d 100644
--- a/conf/distro/include/disable-gplv3.inc
+++ b/conf/distro/include/disable-gplv3.inc
@@ -1,2 +1,3 @@
INCOMPATIBLE_LICENSE = '*GPLv3'
WARN_QA_remove = 'incompatible-license'
+RDEPENDS_${PN}-ptest_remove_pn-glib-2.0 = "python3-dbusmock"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49337): https://lists.yoctoproject.org/g/yocto/message/49337
Mute This Topic: https://lists.yoctoproject.org/mt/73995055/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe:
https://lists.yoctoproject.org/g/yocto/leave/6691583/737036229/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-gplv2] [PATCH 1/3] conf/distro: Add disable-gplv3.inc
We're finding meta-gplv2 needs configuration to work as intended. Rather than teaching this to things like the project autobuilder, collect the configuration inside an include file in the layer itself which everyone can either use directly or refer to. Initial population is from the autobuilder config currently used for testing meta-gplv2. Signed-off-by: Richard Purdie --- conf/distro/include/disable-gplv3.inc | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 conf/distro/include/disable-gplv3.inc diff --git a/conf/distro/include/disable-gplv3.inc b/conf/distro/include/disable-gplv3.inc new file mode 100644 index 000..45834b7 --- /dev/null +++ b/conf/distro/include/disable-gplv3.inc @@ -0,0 +1,2 @@ +INCOMPATIBLE_LICENSE = '*GPLv3' +WARN_QA_remove = 'incompatible-license' -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49336): https://lists.yoctoproject.org/g/yocto/message/49336 Mute This Topic: https://lists.yoctoproject.org/mt/73995054/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH 1/2] conf/distro: Add disable-gplv3.inc
We're finding this layer needs configuration to work as intended. Rather than teaching this to things like the project autobuilder, collect the configuration inside an include file in the layer itself which everyone can either use directly or refer to. Initial population from the autobuilder config used for this testing this layer. Signed-off-by: Richard Purdie --- conf/distro/include/disable-gplv3.inc | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 conf/distro/include/disable-gplv3.inc diff --git a/conf/distro/include/disable-gplv3.inc b/conf/distro/include/disable-gplv3.inc new file mode 100644 index 000..45834b7 --- /dev/null +++ b/conf/distro/include/disable-gplv3.inc @@ -0,0 +1,2 @@ +INCOMPATIBLE_LICENSE = '*GPLv3' +WARN_QA_remove = 'incompatible-license' -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49334): https://lists.yoctoproject.org/g/yocto/message/49334 Mute This Topic: https://lists.yoctoproject.org/mt/73994698/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH 2/2] disable-gplv3.inc: Disable glib-2.0 ptest python3-dbusmock dependency
The newly added dependency on python3-dbusmock in OE-Core is GPLv3
and would fail to work with this layer. Remove it in the config
for enabling the layer.
Signed-off-by: Richard Purdie
---
conf/distro/include/disable-gplv3.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/distro/include/disable-gplv3.inc
b/conf/distro/include/disable-gplv3.inc
index 45834b7..761be7d 100644
--- a/conf/distro/include/disable-gplv3.inc
+++ b/conf/distro/include/disable-gplv3.inc
@@ -1,2 +1,3 @@
INCOMPATIBLE_LICENSE = '*GPLv3'
WARN_QA_remove = 'incompatible-license'
+RDEPENDS_${PN}-ptest_remove_pn-glib-2.0 = "python3-dbusmock"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49335): https://lists.yoctoproject.org/g/yocto/message/49335
Mute This Topic: https://lists.yoctoproject.org/mt/73994699/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe:
https://lists.yoctoproject.org/g/yocto/leave/6691583/737036229/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Can not use wildcard in SRC_URI to apply patches #yocto
On Sun, 2020-04-26 at 08:24 +0900, Hao Qian wrote: > Hi, Richard > > Thanks for replying. > > Yes, it makes sense why patches not be applied by using wildcard. > > Just for confirmation, it looks like more than one person made it to > use wildcard for patching as below: > https://stackoverflow.com/questions/41266742/adding-multiple-patches-to-src-uri-in-a-recipe-yocto > > As you said, wildcard is not supported for patches in SRC_URI. > So, do you mean the answers and replies in above issue of > stackoverflow are wrong? > Or did I miss something? The patch linked to from there: https://patchwork.openembedded.org/patch/8443/ gives some clues about when it might happen to work: "Wildcards in SRC_URI are not supported by oe-core and work only when last (or first?) FILESPATH element points to the containing directory" So it sounds like it can work in some cases but isn't something we really support or encourage. I'd also note that information is 9 years old. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49244): https://lists.yoctoproject.org/g/yocto/message/49244 Mute This Topic: https://lists.yoctoproject.org/mt/73258946/21656 Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto&subid=6691583 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Can not use wildcard in SRC_URI to apply patches #yocto
On Sat, 2020-04-25 at 17:30 +0900, Hao Qian wrote:
> However, if I change files' name into wildcard in SRC_URI like:
> ===
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> SRC_URI += "file://*"
> ===
[...]
> Could anyone tell me how to apply patches by wildcard?
That isn't supported. Its hard to get determinism correct and the patch
ordering could also be problematic.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49239): https://lists.yoctoproject.org/g/yocto/message/49239
Mute This Topic: https://lists.yoctoproject.org/mt/73258946/21656
Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto&subid=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH yocto-autobuilder-helper 2/2] scripts/send-qa-email: fix bug in git push logic for yocto-testresults
On Wed, 2020-04-22 at 14:43 -1000, Steve Sakoman wrote: > We were mistakenly doing a force push if the branch was in either > BUILD_HISTORY_FORKPUSH or BUILD_HISTORY_DIRECTPUSH. > > Now we force push for branches in BUILD_HISTORY_FORKPUSH, regular push > for branches in BUILD_HISTORY_DIRECTPUSH, and no push if the branch is > in neither list. > > Signed-off-by: Steve Sakoman > --- > scripts/send-qa-email | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/scripts/send-qa-email b/scripts/send-qa-email > index 205f6d1..b4d4cec 100755 > --- a/scripts/send-qa-email > +++ b/scripts/send-qa-email > @@ -80,10 +80,10 @@ if 'poky' in repos and os.path.exists(resulttool) and > args.results_dir: > extraopts = None > > subprocess.check_call([resulttool, "store", args.results_dir, > tempdir]) > -if basebranch: > +if comparebranch: > subprocess.check_call(["git", "push", "--all", "--force"], > cwd=tempdir) > subprocess.check_call(["git", "push", "--tags", "--force"], > cwd=tempdir) > -else: > +elif basebranch: > subprocess.check_call(["git", "push", "--all"], cwd=tempdir) > subprocess.check_call(["git", "push", "--tags"], cwd=tempdir) > Thanks, well found! I tweaked the first patch to use comparerepo instead of baserepo. The confusion came from cut and paste from the buildhistory code. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49224): https://lists.yoctoproject.org/g/yocto/message/49224 Mute This Topic: https://lists.yoctoproject.org/mt/73210216/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-3.1.rc2)
On Wed, 2020-04-15 at 16:05 -0700, akuster wrote: > > > On 4/15/20 3:25 PM, Paul Eggleton wrote: > > Release notes draft attached, including a dedication to Scott > > (wasn't sure where to put that so I've just left it at the top) and > > contributors list. Let me know if you notice anything > > missing/incorrect. > Thanks for pulling this together. > > I've also sent out the 3.1 migration guide for the reference > > manual, Richard has just merged the changes: > I see the review window is down to an hour before merging. Is code > review by twitter the next new thing ; ) It was merged on the basis it was a good starter and followup patches are easy and very welcome. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49167): https://lists.yoctoproject.org/g/yocto/message/49167 Mute This Topic: https://lists.yoctoproject.org/mt/72873678/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-3.1.rc2)
Hi Sangeeta/Vineela, On Sat, 2020-04-11 at 07:26 +, Jain, Sangeeta wrote: > This is the full report for yocto-3.1.rc2: > https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults > > === Summary > No high milestone defects. > No new defects are found in this cycle. > > Note: Few failures are observed. These are setup issue since running > tests remotely, not real yocto issue. Thanks for the QA run! The TSC met today and this was one of the topics discussed. We would have time for another build and QA run but none of the queued changes or open bugs appear to be significant enough to warrant that. We'd therefore like to proceed to release rc2 which will be slightly ahead of schedule and aim to have a prompt point release thereafter with the inevitable fixes as people start using it. Paul (cc'd) is working on the release notes which is a ton of work and much appreciated, thanks Paul. Vineela: Could you prepare the release so we're ready when we have the release notes please? We're also pleased to say we do have an LTS maintainer lined up and that should be announced soon. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49158): https://lists.yoctoproject.org/g/yocto/message/49158 Mute This Topic: https://lists.yoctoproject.org/mt/72873678/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-autobuilder-helper][zeus][PATCH] config.json: Override BBTARGETS for meta-intel
On Thu, 2020-04-09 at 09:54 +0800, mohamad.noor.alim.hus...@intel.com wrote:
> From: Mohamad Noor Alim Hussin
>
> Using meta-intel with core-image-sato-(sdk)-ptest
> results in a hddimg size of more than 4 GB. Remove
> that image type from testing.
>
> hddimg is not built by default in dunfell so this
> is applicable only to zeus.
>
> Signed-off-by: Mohamad Noor Alim Hussin
> ---
> config.json | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/config.json b/config.json
> index 7a88e6e..2989b8a 100644
> --- a/config.json
> +++ b/config.json
> @@ -384,7 +384,10 @@
> "NEEDREPOS" : ["poky", "meta-intel"],
> "ADDLAYER" : ["${BUILDDIR}/../meta-intel"],
> "MACHINE" : "intel-corei7-64",
> -"TEMPLATE" : "arch-hw"
> +"TEMPLATE" : "arch-hw",
> + "step1": {
> + "BBTARGETS": "core-image-sato core-image-sato-dev
> core-image-sato-sdk core-image-minimal core-image-minimal-dev
> core-image-sato:do_populate_sdk"
> + }
> },
> "genericx86-64-alt" : {
> "MACHINE" : "genericx86-64",
Whilst this will "fix" the problem, it is just by hiding it. Any user
using meta-intel will run into a failure if they try and build this
image and it may as well be disabled and it won't work for anyone.
A better fix would be to disable hddimg for this image, then a user can
actually build it without failures.
Its Intel's layer so its your call but I'd want to fix this properly.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49093): https://lists.yoctoproject.org/g/yocto/message/49093
Mute This Topic: https://lists.yoctoproject.org/mt/72888688/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-3.1.rc2)
On Wed, 2020-04-08 at 04:01 +, pokybu...@localhost.yoctoproject.org wrote: > A build flagged for QA (yocto-3.1.rc2) was completed on the > autobuilder and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc2 > > > Build hash information: > > bitbake: 4618da2094189e4d814b7d65672cb65c86c0626a > meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac > meta-intel: bd539ea962ee285eb71053583e3c17fa166fc610 > meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7 > oecore: 1795f30d8ab73d35710ca99064c51190dc84853e > poky: 5d47cdf448b6cff5bb7cc5b0ba0426b8235ec478 > > There were two failures in this build due to collect-results failing. I fixed the missing dependency on that autobuilder worker (there was already an open bug but it wasn't fixed yet) and reran the collections scripts so the results were added and handled. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49086): https://lists.yoctoproject.org/g/yocto/message/49086 Mute This Topic: https://lists.yoctoproject.org/mt/72873678/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-3.1.rc1)
On Wed, 2020-04-08 at 01:14 +, Jain, Sangeeta wrote: > Hi Richard, > > Thanks for update on > https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc1 > Unfortunately, I didn't received any mail for 3.1.rc1 or rc2 build > notification. > Looks like automated mail has some issues. > > I will now start the QA on > https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc2/ > > Thanks, > Sangeeta > > > > -Original Message- > > From: yocto@lists.yoctoproject.org > > On Behalf > > Of Richard Purdie > > Sent: Wednesday, 8 April, 2020 5:05 AM > > To: Poky Build User ; > > yocto@lists.yoctoproject.org > > Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv > > ; Yeoh, Ee Peng ; > > Chan, > > Aaron Chun Yew ; > > akuster...@gmail.com; > > sjolley.yp...@gmail.com; Jain, Sangeeta > > Subject: Re: [yocto] QA notification for completed autobuilder > > build (yocto- > > 3.1.rc1) Thanks. For reference you can see you're included in the Cc: list above so I'm not sure why you aren't getting email. I'll ask Michael to look into that. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49084): https://lists.yoctoproject.org/g/yocto/message/49084 Mute This Topic: https://lists.yoctoproject.org/mt/72860381/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-3.1.rc1)
On Mon, 2020-04-06 at 22:53 +, Poky Build User wrote: > A build flagged for QA (yocto-3.1.rc1) was completed on the > autobuilder and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc1 I haven't see any "started QA" email about this yet. We have had some issues with rc1 reported by people so given that and the above, I'm going to abort rc1 and build rc2. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49081): https://lists.yoctoproject.org/g/yocto/message/49081 Mute This Topic: https://lists.yoctoproject.org/mt/72860381/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] What are the key factors for yocto build speed?
On Thu, 2020-03-19 at 19:21 +0200, Adrian Bunk wrote: > On Thu, Mar 19, 2020 at 05:07:17PM +0100, Mike Looijmans wrote: > > ... > > With both parallelization options > > to "16", I might end up with 16 compile tasks running 16 compile > > threads > > each, i.e. 256 running processes. > > ... > > This is a bug: > http://bugzilla.yoctoproject.org/show_bug.cgi?id=13306 > > I sometimes wonder whether something basic like "no more than one > compile task at a time" would be sufficient in practice to avoid > overloading all cores. You can test with: do_compile[number_threads] = "1" Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48864): https://lists.yoctoproject.org/g/yocto/message/48864 Mute This Topic: https://lists.yoctoproject.org/mt/72047879/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] What are the key factors for yocto build speed?
On Thu, 2020-03-19 at 17:29 +0100, Yann Dirson wrote: > > > Le jeu. 19 mars 2020 à 17:07, Mike Looijmans a > écrit : > > On 19-03-2020 12:04, Richard Purdie via Lists.Yoctoproject.Org wrote: > > >> , fetch, configure, package and rootfs tasks. > > > > > > Sadly these tasks are much harder. > > > > It would be really great if some sort of "weight" could be attached to a > > task. This relates to memory usage. > > > > My system has 16 cores but only 8GB RAM. With both parallelization > > options to "16", I might end up with 16 compile tasks running 16 compile > > threads each, i.e. 256 running processes. In practice this doesn't > > actually happen, but the memory load gets high sometimes, so I reduce > > the TASKS to 8 at most. That has kept my system out of swap trouble for > > the time being. > > This could be neatly handled by using the GNU-make job-server mechanism. > If bitbake itself would provide a jub-server, all make-based recipes would > automatically get their jobs properly limited. There is a (sadly not merged > yet) > MR [1] for ninja tu gain job-server support as well, through which we should > have > a pretty good coverage of the recipes set (as a backend for cmake, meson, and > more). > > [1] https://github.com/ninja-build/ninja/issues/1139 You mean like: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237 ? :) Sadly we never fixed all the issues to let that merge. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48862): https://lists.yoctoproject.org/g/yocto/message/48862 Mute This Topic: https://lists.yoctoproject.org/mt/72047879/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] What are the key factors for yocto build speed?
On Thu, 2020-03-19 at 11:43 +, mikko.rap...@bmw.de wrote: > On Thu, Mar 19, 2020 at 11:04:26AM +0000, Richard Purdie wrote: > > Recipe parsing should hit 100% CPU, its one of the few places we > > can do > > that. > > I'm not fully aware what bitbake does before starting task execution. > With sumo, there is an initial spike in CPU use and then a long > single thread wait where log shows "Initialising tasks..." and Cooker > process is using a single core. For me this takes at least one > minutes for every build. Same is visible with zeus too. This isn't recipe parsing but runqueue setup and taskgraph calculation which happens after parsing but before task execution. More recent bitbake is probably a bit better at it but it is unfortunately a single threaded process :( Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48854): https://lists.yoctoproject.org/g/yocto/message/48854 Mute This Topic: https://lists.yoctoproject.org/mt/72047879/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] What are the key factors for yocto build speed?
On Thu, 2020-03-19 at 08:05 +, Mikko Rapeli wrote: > Once this is done, IO still happens when anything calls sync() and > fsync() and worst offenders are package management tools. In yocto > builds, package manager actions to flush to disk are always useless > since rootfs images are going to be compressed and original ones > wiped by rm_work anyway. > I've tried to hook eatmydata library into the build which makes > sync() and fsync() calls no-ops but I've still failed to fix all the > tools and processes called during build from python code. For shell > based tasks this does it: > > $ export LD_LIBRARY_PATH=/usr/lib/libeatmydata > $ export LD_PRELOAD=libeatmydata.so > $ grep -rn LD_PRELOAD conf/local.conf > conf/local.conf:305:BB_HASHBASE_WHITELIST_append = " LD_PRELOAD" > conf/local.conf:306:BB_HASHCONFIG_WHITELIST_append = " LD_PRELOAD" Doesn't pseudo intercept and stop these sync calls already? Its supposed to so if its not, we should fix that. > The effect is clearly visible during build time using Performance Co- > Pilot (pcp) or similar tools to monitor CPU, memory, IO and network > IO. The usage of RAM as page cache grows until limits are hit and > only then writes to disk start, except for the python image > classes... Hints to fix this are welcome! > > To my knowledge of monitoring our builds, there is a lot of > optimization > potential to better build times. CPU are under utilized during > bitbake recipe parsing Recipe parsing should hit 100% CPU, its one of the few places we can do that. > , fetch, configure, package and rootfs tasks. Sadly these tasks are much harder. > Memory is not fully utilized either since IO through sync()/fsync() > happens everywhere non-pseudo tasks? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48852): https://lists.yoctoproject.org/g/yocto/message/48852 Mute This Topic: https://lists.yoctoproject.org/mt/72047879/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] git fetcher: does not execute git fetch --tags or similar when HEAD has not changed
On Thu, 2020-03-12 at 14:55 +0100, Matthias Schoepfer via
Lists.Yoctoproject.Org wrote:
> We have noticed the following issue: We keep the versions of out
> software by means of tags on the git repositories, i.e. during the
> build, somethings like git describe --tags gets called. In yocto,
> our
> recipe of SomeLibrary might look then similar to this:
>
> SRC_URI =
> "git://our.private.gitserver.org/git/SomeLibrary.git;tags=v${PV}"
>
> When we build the image, and *then* apply a tag to HEAD, that was
> already built before, it seems like the tags are not fetched (my
> guess
> is git fetcher sees that origins HEAD and local HEAD have the same
> hash
> and is fine with it).
>
> The error is, that while the correct version is built, it will
> report
> itself with a wrong version.
>
> Is this a bug?
Each of the fetcher backends makes some assumptions about what it
considers to be "the same".
For tarballs from whatever source this is easy and we use the hash of
the tarball.
For git, we work off the hash from git itself. If the hash changes, the
source is taken to be different. Hashes of the same data are taken to
be the same.
What we don't do is account for any tag that represents that hash. If
you have some extra part of the build process which is using that as a
factor for the build you would also have to account for it in the task
hashes. Nothing does that by default.
git tags are a pain as they require network access to evaluate and they
break the mirroring structure as you can't know a given tag was fetched
into the mirror.
So no, I'd not define it as a bug, the bug is you're relying on the tag
data but not adding it to the task hashes.
You'd somehow need to inject the "git tag for revision X" output into
the do_fetch task dependencies.
For autorev this happens via:
meta/classes/base.bbclass:d.setVar("SRCPV",
"${@bb.fetch2.get_srcrev(d)}"
so you'd need a new version of get_srcrev() and need to inject that
into the vardeps of the fetch task.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#48776): https://lists.yoctoproject.org/g/yocto/message/48776
Mute This Topic: https://lists.yoctoproject.org/mt/71902370/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Should changing a task in the .bb file cause the task to be rerun?
On Tue, 2020-03-10 at 11:33 +, mikko.rap...@bmw.de wrote: > On Fri, Feb 28, 2020 at 11:25:59PM +0000, Richard Purdie wrote: > > On Fri, 2020-02-28 at 22:51 +, Sean McKay wrote: > > > This is probably a fairly short question (I hope): > > > I’m working on a branch based on zeus. I found a bug in the way that > > > one of our recipes was handling something during do_configure (which > > > caused an error to pop up in a do_compile task). When I modified the > > > do_configure task (do_configure_append, actually) to behave properly > > > (which involved changing the actual commands run in that function) > > > and reran bitbake -c compile , the do_configure task wasn’t > > > rerun despite the change to the function’s code. > > > > > > Is it safe to assume this means we’ve done something to mess up the > > > way our system is processing things? Or is that expected behavior > > > > Its not expected behaviour and yes, it sounds like something is messed > > up... > > This is what I've come to expect with yocto 2.0 jethro, 2.5 sumo and > 3.0 zeus. > > That's why I always write: > > $ bitbake -c clean recipe && bitbake -c cleansstate && bitbake -c compile > recipe > > when debugging changes in recipes to_compile and other dependent tasks. > I'm also cleaning up sstate to be sure it's not corrupt or filled with > somehow bad data. This is bad and shouldn't be happening. Can anyone provide some examples I can look at? You shouldn't ever need to run cleansstate in particular. If you have to, there is another underlying bug that should get fixed. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48725): https://lists.yoctoproject.org/g/yocto/message/48725 Mute This Topic: https://lists.yoctoproject.org/mt/71618711/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] Yocto Project Status WW09'20
On Sat, 2020-03-07 at 16:58 +, Richard Purdie wrote: > On Fri, 2020-03-06 at 22:53 +0100, Alexander Kanavin wrote: > > On Wed, 4 Mar 2020 at 23:42, Richard Purdie < > > richard.pur...@linuxfoundation.org> wrote: > > > Just FYI I think there may also be a couple of other packages > > > coreutils > > > pulls in and they may also have reproducibility issues (gettext- > > > ptest, > > > glibc-locale-* and procps*). > > > > Patch for gettext also sent :) glibc-locale and procps I could not > > reproduce :-/ > > Thanks for that fix, it helps! > > FWIW, what I'm seeing with glibc-locale is that these files > "disappear" > from the packages in one of my builds: > > ./usr/share/locale/vi/LC_MESSAGES/libc.mo > ./usr/share/locale/ko/LC_MESSAGES/libc.mo > ./usr/share/locale/en_GB/LC_MESSAGES/libc.mo > ./usr/share/locale/ca/LC_MESSAGES/libc.mo > ./usr/share/locale/fr/LC_MESSAGES/libc.mo > ./usr/share/locale/pl/LC_MESSAGES/libc.mo > ./usr/share/locale/id/LC_MESSAGES/libc.mo > ./usr/share/locale/hr/LC_MESSAGES/libc.mo > ./usr/share/locale/uk/LC_MESSAGES/libc.mo > ./usr/share/locale/ja/LC_MESSAGES/libc.mo > ./usr/share/locale/gl/LC_MESSAGES/libc.mo > ./usr/share/locale/es/LC_MESSAGES/libc.mo > ./usr/share/locale/el/LC_MESSAGES/libc.mo > ./usr/share/locale/pt_BR/LC_MESSAGES/libc.mo > ./usr/share/locale/sl/LC_MESSAGES/libc.mo > ./usr/share/locale/lt/LC_MESSAGES/libc.mo > ./usr/share/locale/rw/LC_MESSAGES/libc.mo > ./usr/share/locale/sv/LC_MESSAGES/libc.mo > ./usr/share/locale/cs/LC_MESSAGES/libc.mo > ./usr/share/locale/nl/LC_MESSAGES/libc.mo > ./usr/share/locale/zh_CN/LC_MESSAGES/libc.mo > ./usr/share/locale/ia/LC_MESSAGES/libc.mo > ./usr/share/locale/fi/LC_MESSAGES/libc.mo > ./usr/share/locale/be/LC_MESSAGES/libc.mo > ./usr/share/locale/ru/LC_MESSAGES/libc.mo > ./usr/share/locale/nb/LC_MESSAGES/libc.mo > ./usr/share/locale/zh_TW/LC_MESSAGES/libc.mo > ./usr/share/locale/tr/LC_MESSAGES/libc.mo > ./usr/share/locale/de/LC_MESSAGES/libc.mo > ./usr/share/locale/da/LC_MESSAGES/libc.mo > ./usr/share/locale/pt/LC_MESSAGES/libc.mo > ./usr/share/locale/hu/LC_MESSAGES/libc.mo > ./usr/share/locale/eo/LC_MESSAGES/libc.mo > ./usr/share/locale/it/LC_MESSAGES/libc.mo > ./usr/share/locale/bg/LC_MESSAGES/libc.mo > ./usr/share/locale/sk/LC_MESSAGES/libc.mo > > I can conform they're not in the glibc stashed-locale sstate object > so > they disappear somewhere before that in the glibc recipe itself. > > Quite where/why I don't know as yet. Just to save anyone digging, the difference is in configure, one has msgfmt in the sysroot, one does not. It is there later in the build so its probably task dependencies not being right. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48708): https://lists.yoctoproject.org/g/yocto/message/48708 Mute This Topic: https://lists.yoctoproject.org/mt/71725433/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] Yocto Project Status WW09'20
On Fri, 2020-03-06 at 22:53 +0100, Alexander Kanavin wrote: > On Wed, 4 Mar 2020 at 23:42, Richard Purdie < > richard.pur...@linuxfoundation.org> wrote: > > Just FYI I think there may also be a couple of other packages > > coreutils > > pulls in and they may also have reproducibility issues (gettext- > > ptest, > > glibc-locale-* and procps*). > > Patch for gettext also sent :) glibc-locale and procps I could not > reproduce :-/ Thanks for that fix, it helps! FWIW, what I'm seeing with glibc-locale is that these files "disappear" from the packages in one of my builds: ./usr/share/locale/vi/LC_MESSAGES/libc.mo ./usr/share/locale/ko/LC_MESSAGES/libc.mo ./usr/share/locale/en_GB/LC_MESSAGES/libc.mo ./usr/share/locale/ca/LC_MESSAGES/libc.mo ./usr/share/locale/fr/LC_MESSAGES/libc.mo ./usr/share/locale/pl/LC_MESSAGES/libc.mo ./usr/share/locale/id/LC_MESSAGES/libc.mo ./usr/share/locale/hr/LC_MESSAGES/libc.mo ./usr/share/locale/uk/LC_MESSAGES/libc.mo ./usr/share/locale/ja/LC_MESSAGES/libc.mo ./usr/share/locale/gl/LC_MESSAGES/libc.mo ./usr/share/locale/es/LC_MESSAGES/libc.mo ./usr/share/locale/el/LC_MESSAGES/libc.mo ./usr/share/locale/pt_BR/LC_MESSAGES/libc.mo ./usr/share/locale/sl/LC_MESSAGES/libc.mo ./usr/share/locale/lt/LC_MESSAGES/libc.mo ./usr/share/locale/rw/LC_MESSAGES/libc.mo ./usr/share/locale/sv/LC_MESSAGES/libc.mo ./usr/share/locale/cs/LC_MESSAGES/libc.mo ./usr/share/locale/nl/LC_MESSAGES/libc.mo ./usr/share/locale/zh_CN/LC_MESSAGES/libc.mo ./usr/share/locale/ia/LC_MESSAGES/libc.mo ./usr/share/locale/fi/LC_MESSAGES/libc.mo ./usr/share/locale/be/LC_MESSAGES/libc.mo ./usr/share/locale/ru/LC_MESSAGES/libc.mo ./usr/share/locale/nb/LC_MESSAGES/libc.mo ./usr/share/locale/zh_TW/LC_MESSAGES/libc.mo ./usr/share/locale/tr/LC_MESSAGES/libc.mo ./usr/share/locale/de/LC_MESSAGES/libc.mo ./usr/share/locale/da/LC_MESSAGES/libc.mo ./usr/share/locale/pt/LC_MESSAGES/libc.mo ./usr/share/locale/hu/LC_MESSAGES/libc.mo ./usr/share/locale/eo/LC_MESSAGES/libc.mo ./usr/share/locale/it/LC_MESSAGES/libc.mo ./usr/share/locale/bg/LC_MESSAGES/libc.mo ./usr/share/locale/sk/LC_MESSAGES/libc.mo I can conform they're not in the glibc stashed-locale sstate object so they disappear somewhere before that in the glibc recipe itself. Quite where/why I don't know as yet. For procps, the timestamps in the output are different, that is the only difference. That means something is indeterminate with the source epoch for that recipe. Again, why, I don't know. The two stamps are: 2019-12-08·04:06:03 2019-12-08·04:05:49 This latter one could potentially be a bug in hashequiv (cc Joshua). It may need that stamps patch I have fixed up to resolve it. The fix it needs is to make it apply only to certain tasks. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48707): https://lists.yoctoproject.org/g/yocto/message/48707 Mute This Topic: https://lists.yoctoproject.org/mt/71725433/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] Yocto Project Status WW09'20
On Wed, 2020-03-04 at 14:00 +0100, Alexander Kanavin wrote: > On Tue, 3 Mar 2020 at 16:59, wrote: > > coreutils ptest blocked on libmodule-build-perl reproducibility > > issue > > > > I sent a patch for this. Thanks! Just FYI I think there may also be a couple of other packages coreutils pulls in and they may also have reproducibility issues (gettext-ptest, glibc-locale-* and procps*). Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48693): https://lists.yoctoproject.org/g/yocto/message/48693 Mute This Topic: https://lists.yoctoproject.org/mt/71725433/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Yocto Project Long Term Support (LTS) Announced
Its posted at: https://www.yoctoproject.org/yocto-project-long-term-support-announced/ but I'll copy it below since this is an important announcement """ To fulfill the evolving requirements of its members and users, the Yocto Project announced a new plan to extend support for selected releases. The new support plan covers an initial two-year period and the first candidate to benefit from this change will be the Yocto Project 3.1 release. A very important criterion for evaluating and adopting a software platform is support. This holds true when it comes to development tools as well. Yocto Project releases are usually maintained for one year. Beyond this period, releases move to community support, which means they only receive occasional patches for critical defects and updates, and no regular defect fixes and security updates. Although this follows the open source culture, where development is particularly known for speed and bleeding-edge innovation, there has been a rising interest among project members and end users for extending this period. As a result, the Yocto Project technical leadership put together a proposal to address this need as well as arranging the tools and processes to allow it to best benefit the project and its users. The project aims to choose an LTS release every two years. The project components covered under the new plan will match the core subset of those included in the standard release process: Bitbake, OE-Core, meta- yocto, and yocto-docs. These components will now receive the usual defect fixes and updates for the extended period of two years. Additional layers, such as meta-mingw, meta-gplv2 or general OSV vendor layers will not be covered and will follow their usual standard support models. The LTS release will support the original kernel it has been shipped with. Yocto Project technical leadership will continuously evaluate other similar older LTS kernels on a case by case basis depending on the status of upstream support. The version of linux-libc-headers would not change to avoid user-space problems. This change will also benefit other downstream projects relying on Yocto Project releases that have longer life cycles such as AGL, RDK etc. The decisions that the technical leadership makes will take into account the community feedback, people committing resources and input from the member organizations. The LTS maintainer will be responsible for queuing and reviewing suitable changes and starting and monitoring builds. The maintainer may have assistance from the community in resolving new issues identified during build or the QA run. Reviews will use the usual community review mailing list processes. For example, where applicable, a merge request will be sent to the appropriate repo owner once all issues found during the review have been addressed. The Yocto Project LTS maintainer role hasn’t been appointed yet. At the moment, the project technical leadership is focused on finding the dedicated resources. For more information, and to discuss the LTS maintainer role, contact lts-maintai...@yoctoproject.org. """ I think there will be some questions and the TSC has been working on documenting the processes around this which are on the wiki. I believe Armin will follow up with some details about what this means for the existing stable series. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48681): https://lists.yoctoproject.org/g/yocto/message/48681 Mute This Topic: https://lists.yoctoproject.org/mt/71713076/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Should changing a task in the .bb file cause the task to be rerun?
On Fri, 2020-02-28 at 22:51 +, Sean McKay wrote: > This is probably a fairly short question (I hope): > I’m working on a branch based on zeus. I found a bug in the way that > one of our recipes was handling something during do_configure (which > caused an error to pop up in a do_compile task). When I modified the > do_configure task (do_configure_append, actually) to behave properly > (which involved changing the actual commands run in that function) > and reran bitbake -c compile , the do_configure task wasn’t > rerun despite the change to the function’s code. > > Is it safe to assume this means we’ve done something to mess up the > way our system is processing things? Or is that expected behavior Its not expected behaviour and yes, it sounds like something is messed up... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48643): https://lists.yoctoproject.org/g/yocto/message/48643 Mute This Topic: https://lists.yoctoproject.org/mt/71618711/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Building CentOS based filesystem #yocto
On Mon, 2020-02-24 at 08:15 -0800, bill.k...@azuresummit.com wrote: > Hello! I am currently using Yocto with default Poky distro. A > customer would like a CentOS-based filesystem, and I am wondering if > this is possible using Yocto? > > My initial thought is to imitate > https://github.com/meta-debian/meta-debian, creating Bitbake recipes > to directly download CentOS binary .rpm packages, or to download and > build CentOS .rpm source packages. > > Does this approach seem feasible? Would it be fairly > straightforward, or are there pitfalls to beware of? I would really > appreciate any insight. If you want CentOS, use CentOS. By definition anything else is playing catchup and will never quite match. We've looked into spec generation before but the worlds are quite different, we cross compile, spec files do not. "Our" output is therefore always going to be different from say the spec file built on target in a native build. We've tried experiments with this before and ended up deciding we should accept Yocto Project is Yocto Project, its not trying to be anything else. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48589): https://lists.yoctoproject.org/g/yocto/message/48589 Mute This Topic: https://lists.yoctoproject.org/mt/71514441/21656 Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto&subid=6691583 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH] yocto-bsps: update to v5.4.20
On Fri, 2020-02-21 at 18:10 -0500, bruce.ashfi...@gmail.com wrote: > From: Bruce Ashfield > > Updating the SRCREVs for the h/w references to v5.4.20, which includes > the binutils fix for perf. > > Signed-off-by: Bruce Ashfield > --- > .../recipes-kernel/linux/linux-yocto_5.4.bbappend | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Thanks, I added some kernel version changes too. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48576): https://lists.yoctoproject.org/g/yocto/message/48576 Mute This Topic: https://lists.yoctoproject.org/mt/71461621/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)
On Fri, 2020-02-21 at 17:26 +, Tummalapalli, Vineela wrote: > [Vineela]: So we will have 3.0.2.rc3 as the release candidate and not > 3.0.2.rc2 as we see issues with that. Am I correct? > If so, in terms of release process I just have to redo the things > like staging 3.0.2.rc3 and do the release notes and test report and > get it reviewed once I get the test results for 3.0.2.rc3 from QA > team. Yes, however the QA team aren't going to rerun all the tests, only check the issue which regressed is fixed. A new build did complete but a QA email wasn't sent out. Armin started that build so I'm not sure whether that was the plan or not (the build wasn't configured to). Armin? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48557): https://lists.yoctoproject.org/g/yocto/message/48557 Mute This Topic: https://lists.yoctoproject.org/mt/7139/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)
On Fri, 2020-02-21 at 10:03 +0200, Adrian Bunk wrote: > On Thu, Feb 20, 2020 at 10:44:24PM +0000, Richard Purdie wrote: > > ... > > This would also include the bitbake memory optimisation during > > parsing > > which merged. > > ... > > I would consider this too risky for a last-minute addition > since it is a non-urgent optimization and not a regression fix. It can be argued its a bug fix which lets things work which otherwise bring machines to a halt with swap/OOM conditions, its a pretty serious memory usage leak (latest report says it reduces a 45GB memory use to 4.5GB on a real workload). Speaking as someone who knows the code well and has an idea of the impact of the change, I believe it to be safe. It was already also merged with 3.0.3 in mind and hasn't caused any issues in master. Excluding it from the respin would be harder and more disruptive than not at this point due to the change to 3.0.3 so its been included. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48552): https://lists.yoctoproject.org/g/yocto/message/48552 Mute This Topic: https://lists.yoctoproject.org/mt/7139/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)
I discussed this quickly in bug triage today with Armin. We agreed that: * The openssh bug is minor and doesn't affect release * Anuj resolved one of the bugs as being execution error so again it doesn't affect release * The bash issue does affect release We're proposing we build and release an rc3 with the bash CVE reverted. This would also include the bitbake memory optimisation during parsing which merged. We wouldn't rerun the manual QA for rc3, just check the automated test results. Does anyone have any objection to that? If not, QA should see an rc3 email but we're just expecting to check the test results if that works for everyone? Vineela: Not sure how this affects release process, we'll just have to figure that out. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48543): https://lists.yoctoproject.org/g/yocto/message/48543 Mute This Topic: https://lists.yoctoproject.org/mt/7139/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Bitbake returning non-zero due to sstate errors
On Thu, 2020-02-20 at 11:59 +, Paul Barker wrote: > I'm now looking into this... > > In sstate_checkhashes() we mark sstate as available if > fetcher.checkstatus() succeeds. Then at a later point > sstate_setscene() calls sstate_installpkg() calls pstaging_fetch() > calls fetcher.download() to actually get the sstate artifact. If the > artifact is removed from the mirror between these two accesses (due > to an sstate mirror clean up running in parallel to a build), or if > there is an intermittent download failure we could see checkstatus() > succeed then download() fail. > > I don't think we should ignore all setscene errors but in the > specific case where it's the download step that fails I think that > should be a warning. Or it could be an error by default with a > variable we can set to turn it into a warning. Does that sound > reasonable? If so I'll work up a patch. Thinking about the code, I'm not sure how you're generically going to tell the difference between a setscene task that fails as the file disappeared compared to a setscene failure with another real error? :/ We could make all failed setscene tasks warnings but I think that buries actual real errors. This is probably why I've not changed the code before now. Special exit code values? :/ I'm open to proposals. I know we could put in some configuration option but in general I hate these as it just means more test matrix combinations and more ways for people to see different behaviours. They have a time/place but I'm not sure its here. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48532): https://lists.yoctoproject.org/g/yocto/message/48532 Mute This Topic: https://lists.yoctoproject.org/mt/71426351/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
