[yocto] [yocto-autobuilder2] [PATCH] builders: Switch to new qa email scripts name, force updates to helper instead

2023-09-28 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 builders.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builders.py b/builders.py
index 70b2d066..539b7b4e 100644
--- a/builders.py
+++ b/builders.py
@@ -328,7 +328,7 @@ def create_parent_builder_factory(buildername, waitname):
 
 factory.addStep(steps.ShellCommand(
 command=[
-
util.Interpolate("%(prop:builddir)s/yocto-autobuilder-helper/scripts/send-qa-email"),
+
util.Interpolate("%(prop:builddir)s/yocto-autobuilder-helper/scripts/send_qa_email.py"),
 util.Property("send_email"),
 util.Interpolate("%(prop:builddir)s/layerinfo.json"),
 util.Interpolate("%(prop:sharedrepolocation)s"),
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61148): https://lists.yoctoproject.org/g/yocto/message/61148
Mute This Topic: https://lists.yoctoproject.org/mt/101634489/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [yocto-autobuilder2] [PATCH 1/4] config.py: Update perf workers to match autobuilder

2023-09-28 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 config.py | 9 +
 schedulers.py | 6 ++
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/config.py b/config.py
index a9433be5..68c690cc 100644
--- a/config.py
+++ b/config.py
@@ -109,7 +109,7 @@ trigger_builders_wait_full_releases = {
  "oe-selftest-ubuntu", 
"oe-selftest-debian", "oe-selftest-centos"]
 }
 
-trigger_builders_wait_perf = ["buildperf-ubuntu1604", "buildperf-centos7", 
"buildperf-debian11"]
+trigger_builders_wait_perf = ["buildperf-debian11", "buildperf-alma8"]
 
 # Builders which are individually triggered
 builders_others = [
@@ -123,6 +123,8 @@ builders_others = [
 "qemuriscv64", "qemuriscv64-ptest", "qemuriscv64-tc",
 "qemuppc64", "qemuppc64-tc",
 "qemux86-ptest", "qemux86-ptest-fast",
+"buildperf-debian11",
+"buildperf-alma8",
 "auh"
 ]
 
@@ -149,8 +151,8 @@ workers = workers_ubuntu + workers_centos + workers_fedora 
+ workers_debian + wo
 workers_bringup = []
 # workers with wine on them for meta-mingw
 workers_wine = ["ubuntu1804-ty-3"]
-workers_buildperf = ["perf-ubuntu1604", "perf-centos7", "perf-debian11"]
 workers_arm = ["ubuntu1804-arm-1", "ubuntu2004-arm-1", "ubuntu2204-arm-1"]
+workers_buildperf = ["perf-debian11", "perf-alma8"]
 # workers which don't need buildtools for AUH and are able to send email to 
mailing lists
 workers_auh = ["alma8-ty-1", "alma8-ty-2"]
 
@@ -192,9 +194,8 @@ builder_to_workers = {
 "reproducible-opensuse": workers_opensuse,
 "reproducible-centos": workers_centos,
 "meta-mingw": workers_wine,
-"buildperf-ubuntu1604": ["perf-ubuntu1604"],
 "buildperf-debian11": ["perf-debian11"],
-"buildperf-centos7": ["perf-centos7"],
+"buildperf-alma8": ["perf-alma8"],
 "qemuarm-armhost": workers_arm,
 "qemuarm64-ptest": workers_arm,
 "qemuarm64-ptest-fast": workers_arm,
diff --git a/schedulers.py b/schedulers.py
index b70b5edd..4914bcf1 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -471,10 +471,8 @@ 
schedulers.append(sched.Nightly(name='nightly-check-layer-dunfell', properties=p
   builderNames=['check-layer-nightly'], dayOfWeek=[1, 4], 
hour=2, minute=0, codebases = {'' : {'branch' : 'dunfell'}}))
 
 # Run the build performance tests at 3am, 9am, 3pm and 9pm
-schedulers.append(sched.Nightly(name='nightly-buildperf-ubuntu1604', 
branch='master', properties=parent_default_props('buildperf-ubuntu1604'),
-  builderNames=['buildperf-ubuntu1604', 'buildperf-debian11'], 
hour=[3,9,15,21], minute=0))
-schedulers.append(sched.Nightly(name='nightly-buildperf-centos7', 
branch='master', properties=parent_default_props('buildperf-centos7'),
-  builderNames=['buildperf-centos7'], hour=[3,9,15,21], 
minute=0))
+schedulers.append(sched.Nightly(name='nightly-buildperf', branch='master', 
properties=parent_default_props('buildperf-debian11'),
+  builderNames=['buildperf-debian11', 'buildperf-alma8'], 
hour=[3,9,15,21], minute=0)
 
 # Run the AUH twice a month on 1st and 15th
 schedulers.append(sched.Nightly(name='nightly-auh', branch='master', 
properties=parent_default_props('auh'),
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61149): https://lists.yoctoproject.org/g/yocto/message/61149
Mute This Topic: https://lists.yoctoproject.org/mt/101634604/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [yocto-autobuilder2] [PATCH 3/4] services: Update email notification config

2023-09-28 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 services.py | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/services.py b/services.py
index cc891434..bdfdbc1d 100644
--- a/services.py
+++ b/services.py
@@ -3,20 +3,27 @@
 #
 
 from buildbot.plugins import reporters
-
 from yoctoabb import config
-
+import os
 
 services = []
 
-# TODO: we'll replace this with functionality in yocto-autobuilder-helpers
-# to mail the error reports to the list
-# services.append(
-# reporters.MailNotifier(fromaddr="yocto-bui...@yoctoproject.org",
-#sendToInterestedUsers=False,
-#extraRecipients=["yocto-bui...@yoctoproject.org"],
-#mode=('failing',))
-# )
+with open(os.path.join(os.path.dirname(__file__), "default_mail.txt"), "r") as 
f:
+emailtext = "\n".join(f.readlines())
+
+formatter = reporters.MessageFormatter(template=emailtext)
+
+generator = reporters.BuildStatusGenerator(
+mode=('failing', 'warnings', 'exception', 'cancelled'),
+message_formatter=formatter,
+builders=['a-full', 'a-quick', 'buildperf-alma8', 'buildperf-debian11', 
'docs'])
+
+#services.append(
+# reporters.MailNotifier(fromaddr="control...@yoctoproject.org",
+#
extraRecipients=["yocto-bui...@lists.yoctoproject.org"],
+#generators=[generator])
+#)
+
 
 # services.append(
 # reporters.IRC(host="irc.freenode.net",
@@ -39,4 +46,4 @@ services = []
 # from yoctoabb.reporters import swatbot
 # services.append(
 # swatbot.SwatBot("http://localhost:8000/";, "buildbot-notifier", 
"password")
-# )
\ No newline at end of file
+# )
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61151): https://lists.yoctoproject.org/g/yocto/message/61151
Mute This Topic: https://lists.yoctoproject.org/mt/101634606/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [yocto-autobuilder2] [PATCH 2/4] config.py: Add mickledore prev_release documentation on workers

2023-09-28 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 config.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/config.py b/config.py
index 68c690cc..cc44ec3d 100644
--- a/config.py
+++ b/config.py
@@ -160,6 +160,7 @@ all_workers = workers + workers_bringup + workers_buildperf 
+ workers_arm
 
 # Worker filtering for older releases
 workers_prev_releases = {
+"mickledore" : ("alma8", "alma9", "debian10", "debian11", "fedora35", 
"fedora36", "fedora37", "fedora38", "opensuse153", "opensuse154", "ubuntu1804", 
"ubuntu2004","ubuntu2204", "perf-"),
 "langdale" : ("alma8", "alma9", "debian10", "debian11", "fedora35", 
"fedora36", "opensuse153", "opensuse154", "ubuntu1804", 
"ubuntu2004","ubuntu2204", "perf-"),
 "kirkstone" : ("alma8", "centos7", "centos8", "debian8", "debian9", 
"debian10", "debian11", "fedora29", "fedora30", "fedora31", "fedora32", 
"fedora33", "fedora34", "fedora35", "fedora36", "fedora37", "fedora38", 
"opensuse150", "opensuse151", "opensuse152", "opensuse153", "ubuntu1604", 
"ubuntu1804", "ubuntu1904", "ubuntu2004", "ubuntu2110", "ubuntu2204", "perf-"),
 "honister" : ("alma8", "centos7", "centos8", "debian8", "debian9", 
"debian10", "debian11", "fedora29", "fedora30", "fedora31", "fedora32", 
"fedora33", "fedora34", "fedora35", "opensuse150", "opensuse151", 
"opensuse152", "opensuse153", "ubuntu1604", "ubuntu1804", "ubuntu1904", 
"ubuntu2004", "ubuntu2110", "ubuntu2204", "perf-"),
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61150): https://lists.yoctoproject.org/g/yocto/message/61150
Mute This Topic: https://lists.yoctoproject.org/mt/101634605/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [yocto-autobuilder2] [PATCH 4/4] Drop wikilog plugin, we're not going back to it!

2023-09-28 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 README.md|  17 +-
 TODO |   2 -
 lib/__init__.py  |   0
 lib/wiki.py  | 210 -
 reporters/wikilog.py | 361 ---
 services.py  |   6 -
 6 files changed, 5 insertions(+), 591 deletions(-)
 delete mode 100644 lib/__init__.py
 delete mode 100644 lib/wiki.py
 delete mode 100644 reporters/wikilog.py

diff --git a/README.md b/README.md
index 1d976aa0..8b97dd5a 100644
--- a/README.md
+++ b/README.md
@@ -26,16 +26,14 @@ yocto-autobuilder-helper script parameters.
 
 ### Code layout
 - [builders.py](builders.py) -- configures the builders with minimal 
buildsteps to invoke the yocto-autobuilder-helper scripts
-- lib/
-  - [wiki.py](lib/wiki.py) -- implements some mediawiki related functionality 
as used by the wikilog plugin
 reporters/
-  - [wikilog.py](reporters/wikilog.py) -- our custom plugin to write info on 
build failures to a wiki page
+  - [swatbot.py](reporters/swatbot.py) -- our custom plugin to write info on 
build failures to a swatbot instance
 - steps/
   - [writelayerinfo.py](steps/writelayerinfo.py) -- write the user supplied 
(or default) repos to a JSON file for use by the scripts
 - [config.py](config.py) -- goal is to contain all values that might need 
changing to redeploy this code elsewhere. Goal hasn't yet been met.
 - [master.cfg](master.cfg) -- calls into other scripts to do most 
configuration. Cluster specific config still lives here (i.e. controller url).
 - [schedulers.py](schedulers.py) -- sets up the force schedulers with controls 
for modifying inputs for each builder.
-- [services.py](services.py) -- configures irc, mail and wikilog reporters.
+- [services.py](services.py) -- configures irc, mail and swatbot reporters.
 - [workers.py](workers.py) -- configures the worker objects
 - [www.py](www.py) -- sets up the web UI
 
@@ -50,14 +48,9 @@ yocto-autobuilder[2].
 custom buildset to iterate the repo_, branch_, and commit_ properties set by
 the schedulers and write a JSON file with the user's values.
 
-### WikiLog reporter
-[reporters/wikilog.py](reporters/wikilog.py) -- a buildbot service to listen
-for build failures and write some information on them to the configured wiki
-page.
-
-[lib/wiki.py](lib/wiki.py) -- some helper functions for the wiki plugin, much
-of this code can be replaced by porting the plugin to be a
-buildbot.util.service.HTTPClient implementation
+### Swatbot reporter
+[reporters/swatbot.py](reporters/swatbot.py) -- a buildbot service to listen
+for build failures and write some information on them to the swatbot instance 
configured.
 
 ## Deployment
 The following deployment steps assume that the target system has a copy of
diff --git a/TODO b/TODO
index d43bfeed..47b5f58b 100644
--- a/TODO
+++ b/TODO
@@ -1,10 +1,8 @@
 
  * Add nightly-checkuri
- * Add wikilog link on console page
  * per worker auth (workers.py & config.py)
  * Add IRC notifier (services.py) [Michael]
  * add mail notification functionality to yocto-autobuilder-helper, it already
knows how to iterate error reports. (services.py)
  * Simple script to start buildbot controller, janitor and PRServer [Michael]
  * Look into allowed_origins property of built in web server
- * switch wikilog to buildbot.util.service.HTTPClient?
diff --git a/lib/__init__.py b/lib/__init__.py
deleted file mode 100644
index e69de29b..
diff --git a/lib/wiki.py b/lib/wiki.py
deleted file mode 100644
index c9e14ae6..
--- a/lib/wiki.py
+++ /dev/null
@@ -1,210 +0,0 @@
-#
-# SPDX-License-Identifier: GPL-2.0-only
-#
-
-'''
-Created on Dec 13, 2016
-
-__author__ = "Joshua Lock"
-__copyright__ = "Copyright 2016, Intel Corp."
-__credits__ = ["Joshua Lock"]
-'''
-
-import codecs
-import hashlib
-import time
-import requests
-from twisted.python import log
-
-
-class YPWiki(object):
-MAX_TRIES = 5
-TIMEOUT = 60
-
-def __init__(self, wiki_uri, wiki_un, wiki_pass):
-self.wiki_uri = wiki_uri
-self.wiki_un = wiki_un
-self.wiki_pass = wiki_pass
-
-@staticmethod
-def retry_request(requesturl, **kwargs):
-"""
-Rather than failing when a request to a 'requesturl' throws an
-exception retry again a minute later. Perform this retry no more than
-5 times.
-
-@type   requesturl:  string
-"""
-kwargs['timeout'] = YPWiki.TIMEOUT
-
-def try_request():
-try:
-req = requests.get(requesturl, **kwargs)
-return req
-except (requests.exceptions.RequestException,
-requests.exceptions.Timeout):
-return None
-
-tries = 0
-req = None
-while not req and tries < YPWiki.MAX_TRIES:
-if tries > 0:
-time.sleep(60)
-req = try_request()
-tries = tries + 1
-
-return req
-
-@staticmethod
-def parse_json(response

[yocto] [PATCH][yocto-autobuilder-helper] config.json: add reproducible-openembedded build

2023-09-28 Thread Fabien Thomas
The purpose of this new build is to report the reproducibility status of
all meta-openembedded recipes. It use the same reproducible selftest than
OE-Core but setting only world as target, and excluding all oecore recipes
from it. Also, the report output directory for meta-openembedded is
separate from oecore's one.

Signed-off-by: Fabien Thomas 
Reviewed-by: Yoann Congal 
---
 config.json | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/config.json b/config.json
index 05c6794..fde1b1f 100644
--- a/config.json
+++ b/config.json
@@ -264,6 +264,34 @@
 
 }
 },
+"reproducible-openembedded" : {
+"MACHINE" : "qemux86-64",
+"SDKMACHINE" : "x86_64",
+"DISTRO" : "None",
+"NEEDREPOS" : ["oecore", "bitbake", "meta-openembedded"],
+"extravars" : [
+"EXCLUDE_FROM_WORLD:layer-core = '1'",
+"EXCLUDE_FROM_WORLD:layer-selftest = '1'",
+"OEQA_REPRODUCIBLE_TEST_TARGET = 'world'"
+],
+"step1" : {
+"shortname" : "Reproducible Selftest for openembedded layers",
+"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; 
OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded/ 
DISPLAY=:1 oe-selftest -r reproducible"],
+"ADDLAYER" : [
+"${BUILDDIR}/../meta-selftest",
+"${BUILDDIR}/../meta-openembedded/meta-filesystems",
+"${BUILDDIR}/../meta-openembedded/meta-gnome",
+"${BUILDDIR}/../meta-openembedded/meta-initramfs",
+"${BUILDDIR}/../meta-openembedded/meta-multimedia",
+"${BUILDDIR}/../meta-openembedded/meta-networking",
+"${BUILDDIR}/../meta-openembedded/meta-oe",
+"${BUILDDIR}/../meta-openembedded/meta-perl",
+"${BUILDDIR}/../meta-openembedded/meta-python",
+"${BUILDDIR}/../meta-openembedded/meta-webserver",
+"${BUILDDIR}/../meta-openembedded/meta-xfce"
+]
+}
+},
 "trigger-build" : {
 "SDKMACHINE" : "x86_64",
 "MACHINE" : "qemux86-64",
@@ -955,6 +983,9 @@
 "reproducible" : {
 "TEMPLATE" : "reproducible"
 },
+"reproducible-openembedded" : {
+"TEMPLATE" : "reproducible-openembedded"
+},
 "reproducible-ubuntu" : {
 "TEMPLATE" : "reproducible"
 },
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61153): https://lists.yoctoproject.org/g/yocto/message/61153
Mute This Topic: https://lists.yoctoproject.org/mt/101637262/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 reproducible-openembedded build

2023-09-28 Thread Richard Purdie
On Thu, 2023-09-28 at 15:18 +0200, Fabien Thomas wrote:
> The purpose of this new build is to report the reproducibility status of
> all meta-openembedded recipes. It use the same reproducible selftest than
> OE-Core but setting only world as target, and excluding all oecore recipes
> from it. Also, the report output directory for meta-openembedded is
> separate from oecore's one.
> 
> Signed-off-by: Fabien Thomas 
> Reviewed-by: Yoann Congal 
> ---
>  config.json | 31 +++
>  1 file changed, 31 insertions(+)

This is a good start, thanks!

> diff --git a/config.json b/config.json
> index 05c6794..fde1b1f 100644
> --- a/config.json
> +++ b/config.json
> @@ -264,6 +264,34 @@
>  
>  }
>  },
> +"reproducible-openembedded" : {

We should call this something like reproducible-meta-oe since we need
to be clear this is meta-oe related.

> +"MACHINE" : "qemux86-64",
> +"SDKMACHINE" : "x86_64",
> +"DISTRO" : "None",
> +"NEEDREPOS" : ["oecore", "bitbake", "meta-openembedded"],
> +"extravars" : [
> +"EXCLUDE_FROM_WORLD:layer-core = '1'",
> +"EXCLUDE_FROM_WORLD:layer-selftest = '1'",
> +"OEQA_REPRODUCIBLE_TEST_TARGET = 'world'"

I like the use of the layer override :)

> +],
> +"step1" : {
> +"shortname" : "Reproducible Selftest for openembedded 
> layers",
> +"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; 
> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded/ 
> DISPLAY=:1 oe-selftest -r reproducible"],
> +"ADDLAYER" : [
> +"${BUILDDIR}/../meta-selftest",
> +"${BUILDDIR}/../meta-openembedded/meta-filesystems",
> +"${BUILDDIR}/../meta-openembedded/meta-gnome",
> +"${BUILDDIR}/../meta-openembedded/meta-initramfs",
> +"${BUILDDIR}/../meta-openembedded/meta-multimedia",
> +"${BUILDDIR}/../meta-openembedded/meta-networking",
> +"${BUILDDIR}/../meta-openembedded/meta-oe",
> +"${BUILDDIR}/../meta-openembedded/meta-perl",
> +"${BUILDDIR}/../meta-openembedded/meta-python",
> +"${BUILDDIR}/../meta-openembedded/meta-webserver",
> +"${BUILDDIR}/../meta-openembedded/meta-xfce"
> +]
> +}
> +},

Would it make sense to split this into steps for each sublayer? I guess
the downside is we'd have to code the dependencies but those shouldn't
change very often at this point. It would split the build and results
into more manageable chunks?

>  "trigger-build" : {
>  "SDKMACHINE" : "x86_64",
>  "MACHINE" : "qemux86-64",
> @@ -955,6 +983,9 @@
>  "reproducible" : {
>  "TEMPLATE" : "reproducible"
>  },
> +"reproducible-openembedded" : {
> +"TEMPLATE" : "reproducible-openembedded"
> +},
>  "reproducible-ubuntu" : {
>  "TEMPLATE" : "reproducible"
>  },

Otherwise looks good and definitely the right direction.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61155): https://lists.yoctoproject.org/g/yocto/message/61155
Mute This Topic: https://lists.yoctoproject.org/mt/101637262/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [Openembedded-architecture] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?

2023-09-28 Thread Alexander Kanavin
On Fri, 22 Sept 2023 at 12:42, Richard Purdie
 wrote:

> Things which used to be problematic:
>
> a) changes involving changes to gcc-source since it uses a shared
> sources stamps which confused the tools (at least used to). That may
> have been before gcc-source became a recipe?
> b) changes to a very common component (e.g. autoconf-native's
> do_configure) which make it hard to understand where the root cause of
> the changes came from
> c) changes which affect many recipes at once, e.g. the do_configure
> function in base.bbclass
>
> It might be helpful to write test cases for the scenario you showed as
> working above and some of the ones I mention above, then we can
> document they work and have an easier way to add tests for issues
> if/as/when we identify the problematic scenarios in future.

I've now written down the tests for these three scenarios and got them
to pass (in oe-selftest too \0/):
https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/sstate-for-all
(check the commit message too)

I am going to look closer at bitbake-whatchanged, what it aims to do
and why it doesn't work. I have a hunch it can produce useful high
level reports, and so shouldn't be simply thrown away. 'bitbake -S
printdiff' is too techy and verbose for some use cases. Maybe we can
fold that functionality into 'bitbake -S whatchanged'.

I'm on holiday next week.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61156): https://lists.yoctoproject.org/g/yocto/message/61156
Mute This Topic: https://lists.yoctoproject.org/mt/101503345/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [Openembedded-architecture] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?

2023-09-28 Thread Richard Purdie
On Thu, 2023-09-28 at 18:43 +0200, Alexander Kanavin wrote:
> On Fri, 22 Sept 2023 at 12:42, Richard Purdie
>  wrote:
> 
> > Things which used to be problematic:
> > 
> > a) changes involving changes to gcc-source since it uses a shared
> > sources stamps which confused the tools (at least used to). That may
> > have been before gcc-source became a recipe?
> > b) changes to a very common component (e.g. autoconf-native's
> > do_configure) which make it hard to understand where the root cause of
> > the changes came from
> > c) changes which affect many recipes at once, e.g. the do_configure
> > function in base.bbclass
> > 
> > It might be helpful to write test cases for the scenario you showed as
> > working above and some of the ones I mention above, then we can
> > document they work and have an easier way to add tests for issues
> > if/as/when we identify the problematic scenarios in future.
> 
> I've now written down the tests for these three scenarios and got them
> to pass (in oe-selftest too \0/):
> https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/sstate-for-all
> (check the commit message too)
> 
> I am going to look closer at bitbake-whatchanged, what it aims to do
> and why it doesn't work. I have a hunch it can produce useful high
> level reports, and so shouldn't be simply thrown away. 'bitbake -S
> printdiff' is too techy and verbose for some use cases. Maybe we can
> fold that functionality into 'bitbake -S whatchanged'.

I've wondered if we should split bitbake -S printdiff into a separate
utility? It exists from a time before we had bitbake command APIs.

I'm curious to see what you find with analysis of bitbake-whatchanged.
I'm also somewhat surprised the scenarios you're testing all work!

I'm guess one of the commits I pointed to must have fixed them (the
removal of paths from the sig files)?

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61157): https://lists.yoctoproject.org/g/yocto/message/61157
Mute This Topic: https://lists.yoctoproject.org/mt/101503345/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [Openembedded-architecture] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?

2023-09-28 Thread Alexander Kanavin
On Thu, 28 Sept 2023 at 18:49, Richard Purdie
 wrote:
> I've wondered if we should split bitbake -S printdiff into a separate
> utility? It exists from a time before we had bitbake command APIs.

It can also be a simple shell wrapper.

I've separated -S lockedsigs into it's own option as well, so it can
be explicitly requested (just need to fix up a couple of selftests
that relied on -S none to get locked-sigs.inc):
https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/sstate-for-all&id=41e8a8a79bac4e3b9eb74a99e32e0d26ac8af0c5

> I'm curious to see what you find with analysis of bitbake-whatchanged.
> I'm also somewhat surprised the scenarios you're testing all work!

It's not 100% perfect. One out of 2*3=6 scenarios isn't fully
functional (gcc-source:do_preconfigure signature isn't found from
sstate even though it exists there - but it is found if it's in
tmp/stamps/). I left a FIXME in the test.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61158): https://lists.yoctoproject.org/g/yocto/message/61158
Mute This Topic: https://lists.yoctoproject.org/mt/101503345/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] SPDX generation fails every second time the image is created

2023-09-28 Thread Marta Rybczynska
Hello David,
I haven't encountered this one, but it looks like a race condition.
Could you tell us which exact
version of the YP are you using? What is your configuration, if you
can share (which layers and packages activated, especially).

Kind regards,
Marta

On Thu, Sep 28, 2023 at 4:20 PM David Daniel  wrote:
>
> Hello
>
> Something changed in master the last days that makes the image creation
> fail. When I create the image with bitbake, every second time the image
> creation fails with:
>
>Exception: AttributeError: 'NoneType' object has no attribute 'open'
>
> Funnily this only happens every 2nd time - afterwards I cannot build
> the image anymore. Up to now I "solve" this by deleting the entire
> build folder and start over again.
> I attached the log of the build that shows the error - I don't
> understand where this comes from.
>
> Any idea what's causing this?
>
> Have a great day,
> BR
> David
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61159): https://lists.yoctoproject.org/g/yocto/message/61159
Mute This Topic: https://lists.yoctoproject.org/mt/101638471/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] SPDX generation fails every second time the image is created

2023-09-28 Thread Joshua Watt
David,

I just pushed a patch to the ML to provide better debugging when this
happens; it will at least tell us which document is missing. Is there
any way you can run you build again with that patch applied?

https://lists.openembedded.org/g/openembedded-core/message/188378

Thanks,

On Thu, Sep 28, 2023 at 8:20 AM David Daniel  wrote:
>
> Hello
>
> Something changed in master the last days that makes the image creation
> fail. When I create the image with bitbake, every second time the image
> creation fails with:
>
>Exception: AttributeError: 'NoneType' object has no attribute 'open'
>
> Funnily this only happens every 2nd time - afterwards I cannot build
> the image anymore. Up to now I "solve" this by deleting the entire
> build folder and start over again.
> I attached the log of the build that shows the error - I don't
> understand where this comes from.
>
> Any idea what's causing this?
>
> Have a great day,
> BR
> David
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61160): https://lists.yoctoproject.org/g/yocto/message/61160
Mute This Topic: https://lists.yoctoproject.org/mt/101638471/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] Trouble enabling vtable-verify for gcc-cross

2023-09-28 Thread Alex Roberts
Today I revisited cloning gcc-sanitizers.inc and gcc-sanitizers_9.3.bb
in an attempt to make a recipe that configures and builds libvtv. This
somewhat works, but I get errors with libtool


| /bin/sh ./libtool --tag=CXX   --mode=compile  -DPACKAGE_NAME=\"GNU\
Vtable\ Verification\ Runtime\ Library\" -DPACKAGE_TARNAME=\"libvtv\"
-DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"GNU\ Vtable\
Verification\ Runtime\ Library\ 1.0\" -DPACKAGE_BUGREPORT=\"\"
-DPACKAGE_URL=\"http://www.gnu.org/software/libvtv/\"; -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1
-D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DPACKAGE=\"libvtv\"
-DVERSION=\"1.0\" -DHAVE_SECURE_GETENV=1 -DHAVE___FORTIFY_FAIL=1
-DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE__OBSTACK_BEGIN=1 -I.
-I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv
-I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/../include
 -D_GNU_SOURCE -Wall -Wextra -fno-exceptions
-I./../libstdc++-v3/include
-I./../libstdc++-v3/include/aarch64-oe-linux
-I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/../libstdc++-v3/libsupc++
-Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -O2
-fomit-frame-pointer-Wa,--noexecstack -fexpensive-optimizations
-frename-registers -ftree-vectorize   -finline-functions
-finline-limit=64   -Wno-error=maybe-uninitialized
-Wno-error=unused-result -fvisibility-inlines-hidden -c -o
vtv_malloc.lo 
../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/vtv_malloc.cc
| /bin/sh ./libtool --tag=CXX   --mode=compile  -DPACKAGE_NAME=\"GNU\
Vtable\ Verification\ Runtime\ Library\" -DPACKAGE_TARNAME=\"libvtv\"
-DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"GNU\ Vtable\
Verification\ Runtime\ Library\ 1.0\" -DPACKAGE_BUGREPORT=\"\"
-DPACKAGE_URL=\"http://www.gnu.org/software/libvtv/\"; -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1
-D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DPACKAGE=\"libvtv\"
-DVERSION=\"1.0\" -DHAVE_SECURE_GETENV=1 -DHAVE___FORTIFY_FAIL=1
-DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE__OBSTACK_BEGIN=1 -I.
-I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv
-I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/../include
 -D_GNU_SOURCE -Wall -Wextra -fno-exceptions
-I./../libstdc++-v3/include
-I./../libstdc++-v3/include/aarch64-oe-linux
-I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/../libstdc++-v3/libsupc++
-Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -O2
-fomit-frame-pointer-Wa,--noexecstack -fexpensive-optimizations
-frename-registers -ftree-vectorize   -finline-functions
-finline-limit=64   -Wno-error=maybe-uninitialized
-Wno-error=unused-result -fvisibility-inlines-hidden -c -o
vtv_rts.lo 
../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/vtv_rts.cc
| /bin/sh ./libtool --tag=CXX   --mode=compile  -DPACKAGE_NAME=\"GNU\
Vtable\ Verification\ Runtime\ Library\" -DPACKAGE_TARNAME=\"libvtv\"
-DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"GNU\ Vtable\
Verification\ Runtime\ Library\ 1.0\" -DPACKAGE_BUGREPORT=\"\"
-DPACKAGE_URL=\"http://www.gnu.org/software/libvtv/\"; -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1
-D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DPACKAGE=\"libvtv\"
-DVERSION=\"1.0\" -DHAVE_SECURE_GETENV=1 -DHAVE___FORTIFY_FAIL=1
-DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE__OBSTACK_BEGIN=1 -I.
-I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv
-I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/../include
 -D_GNU_SOURCE -Wall -Wextra -fno-exceptions
-I./../libstdc++-v3/include
-I./../libstdc++-v3/include/aarch64-oe-linux
-I../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/../libstdc++-v3/libsupc++
-Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -O2
-fomit-frame-pointer-Wa,--noexecstack -fexpensive-optimizations
-frename-registers -ftree-vectorize   -finline-functions
-finline-limit=64   -Wno-error=maybe-uninitialized
-Wno-error=unused-result -fvisibility-inlines-hidden -c -o
vtv_utils.lo 
../../../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/libvtv/vtv_utils.cc
| libtool: compile: unrecognized option `-DPACKAGE_NAME="GNU Vtable
Verification Runtime Library"'
| libtool: compile: Try `libtool --help' for more information.
| libtool: compile: unrecognized option `-DPACKAGE_NAME="GNU Vtable
Verification Runtime Library"'
| libtool: compile: Try `libtool --help'