Re: [OE-core] Status of patchtest tool
On Fri, 2023-08-11 at 08:00 +0200, Michael Opdenacker via lists.openembedded.org wrote: > Hi Frederic, > > On 11.08.23 at 07:28, Frederic Martinsons wrote: > > Hello list > > > > Michael recently made a change on contirubing guide talking about > > patchtest as a tool (quoting him) "to test user contributions before > > they hit the mailing lists; and looking in my older emails, Alexander > > also mentioned this tool as a (quoting him) "special bot called > > patchtest that used to check mailing list submissions for common > > problems". > > > > Can you tell me more about it ? Are we talking about the script > > patchtest.sh in scripts/contrib of oe-core ? > > Can you please describe the expectations of this tool . > > I'm willing to improve it and am ready to work on it if you give me > > some directions. > > > Actually, Richard wrote the initial text, and I actually wondered... Is > the intent to have a tool that contributors can run before sending their > patches, and that a bot can run on mailing list submissions too? Yes, that is the intent. The docs are written with the view from where I believe we'll be in a couple of months. I wrote it that way to prompt us to fill in the missing pieces as this is developed and because I wasn't thinking the text would have merged quite so quickly. Patchtest is mentioned here: https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ Even before that we've talked about patchtest a lot and our desire to bring back the code/tests we have and get them working again. There are several mailing list posts where I've talked about it and various open bugs in bugzilla. We're in the process of getting some help to work on some of the things in the RFQ and patchtest should hopefully be getting some attention very soon. https://git.yoctoproject.org/patchtest/ https://git.yoctoproject.org/patchtest-oe/ Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185829): https://lists.openembedded.org/g/openembedded-core/message/185829 Mute This Topic: https://lists.openembedded.org/mt/100678742/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Status of patchtest tool
Le ven. 11 août 2023, 09:05, Richard Purdie < richard.pur...@linuxfoundation.org> a écrit : > On Fri, 2023-08-11 at 08:00 +0200, Michael Opdenacker via > lists.openembedded.org wrote: > > Hi Frederic, > > > > On 11.08.23 at 07:28, Frederic Martinsons wrote: > > > Hello list > > > > > > Michael recently made a change on contirubing guide talking about > > > patchtest as a tool (quoting him) "to test user contributions before > > > they hit the mailing lists; and looking in my older emails, Alexander > > > also mentioned this tool as a (quoting him) "special bot called > > > patchtest that used to check mailing list submissions for common > > > problems". > > > > > > Can you tell me more about it ? Are we talking about the script > > > patchtest.sh in scripts/contrib of oe-core ? > > > Can you please describe the expectations of this tool . > > > I'm willing to improve it and am ready to work on it if you give me > > > some directions. > > > > > > Actually, Richard wrote the initial text, and I actually wondered... Is > > the intent to have a tool that contributors can run before sending their > > patches, and that a bot can run on mailing list submissions too? > > Yes, that is the intent. The docs are written with the view from where > I believe we'll be in a couple of months. I wrote it that way to prompt > us to fill in the missing pieces as this is developed and because I > wasn't thinking the text would have merged quite so quickly. > > Patchtest is mentioned here: > > > https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/ > > Even before that we've talked about patchtest a lot and our desire to > bring back the code/tests we have and get them working again. There are > several mailing list posts where I've talked about it and various open > bugs in bugzilla. > > We're in the process of getting some help to work on some of the things > in the RFQ and patchtest should hopefully be getting some attention > very soon. > > https://git.yoctoproject.org/patchtest/ > https://git.yoctoproject.org/patchtest-oe/ Thank you Richard for the links, if I understand correctly, there are already plan to work on it so I may not step in (since I do not have all the backgrounds). Nevertheless, I'll take a look at the Bugzilla to see if I can bring some help on already open bug. > > Cheers, > > Richard > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185830): https://lists.openembedded.org/g/openembedded-core/message/185830 Mute This Topic: https://lists.openembedded.org/mt/100678742/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v4 0/5] Add bblock helper scripts
On 10/08/2023 15:21:14+0200, Alexandre Belloni wrote: > Hello, this causes oe-selftest failures on the autobuilders: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5589/steps/14/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5577/steps/14/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/5536/steps/14/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/5613/steps/14/logs/stdio > > 2023-08-10 09:44:34,071 - oe-selftest - INFO - > bblock.BBLock.test_lock_architecture_specific (subunit.RemotedTestCase) > 2023-08-10 09:44:34,072 - oe-selftest - INFO - ... FAIL > Stderr: > 2023-08-10 09:40:23,454 - oe-selftest - INFO - Adding: "include selftest.inc" > in > /home/pokybuild/yocto-worker/oe-selftest-centos/build/build-st-2290072/conf/local.conf > 2023-08-10 09:40:23,455 - oe-selftest - INFO - Adding: "include bblayers.inc" > in bblayers.conf > 2023-08-10 09:44:34,072 - oe-selftest - INFO - 3: 1/34 29/533 (250.62s) (0 > failed) (bblock.BBLock.test_lock_architecture_specific) > 2023-08-10 09:44:34,072 - oe-selftest - INFO - > testtools.testresult.real._StringException: Traceback (most recent call last): > File > "/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/lib/oeqa/selftest/cases/bblock.py", > line 103, in test_lock_architecture_specific > self.assertNotIn(info_message, result.output) > File "/usr/lib64/python3.9/unittest/case.py", line , in assertNotIn > self.fail(self._formatMessage(msg, standardMsg)) > File "/usr/lib64/python3.9/unittest/case.py", line 676, in fail > raise self.failureException(msg) > AssertionError: 'NOTE: The following recipes have locked tasks: quilt' > unexpectedly found in 'NOTE: Reconnecting to bitbake server... > Hum, wait, I got this without the patch series. Let me investigate. > > > On 02/08/2023 16:24:27+0200, Julien Stephan wrote: > > Hi all, > > > > This is v4 for bblock script. > > > > Improvement from v3: > > * Add self test > > * Add a new "info" level for SIGGEN_LOCKEDSIGS_TASKSIG_CHECK: this allows to > > display a Note when recipe contains locked task(s) > > > > Limitations: > > * Silently does nothing if given task doesn't exist > > * Silently does nothing when resetting a recipe that doesn't exist > > > > Improvement from v2: > > * Add a function in bb.cooker to compute task signatures > > * Replace the findSigInfo function by the new created one. This has the > > following advantages: > > * findSigInfo needs the task to be already built to get the siginfo > > file, meaning we cannot lock a recipe on a fresh build > > * we can now generate the signatures for all available task of a given > > recipe > > * Check if a given task is already locked. If so, don't duplicate > > entry in bblock.conf > > > > Limitations: > > * Needs to taint tasks that are locked, to display a warning > > * I may be still missing some checks on user input > > * Silently does nothing if given task doesn't exist > > * Silently does nothing when resetting a recipe that doesn't exist > > > > I did some tests using qemux86-64 and qemuarm but I may be missing some > > corner cases. > > > > Improvement from V1: > > * Signatures are now package architecture specific meaning that if you > > switch MACHINE, the lock sig will not be taken into account > > * I added the -r option to unlock recipes > > * I added a -d option to display the current bblock.conf > > * Added an include directive for conf/bblock.conf inside bitbake.conf > > * Added -t option to specify the tasks to lock/unlock > > > > Limitations: > > * I may be still missing some checks on user input > > * I need to find a way to get the list of tasks ( by default still lock > > only the do_compile for now, unless -t is specified) > > * Do not check if a particular recipe/task is already locked when trying > > to add lock. So entries may appear multiple times > > * We still need the signature of the tasks to be already computed before > > locking. Need to find a way to generate it if missing > > > > V3: https://lists.openembedded.org/g/openembedded-core/message/184932 > > V2: https://lists.openembedded.org/g/openembedded-core/message/184697 > > V1: https://lists.openembedded.org/g/openembedded-core/message/184584 > > > > My branch is available here [1] > > > > Cheers > > Julien > > > > [1]: https://git.yoctoproject.org/poky-contrib/commit/?h=jstephan/bblock > > Julien Stephan (5): > > bitbake.conf: include bblock.conf > > bitbake: cooker: add a new function to retrieve task signatures > > sstatesig: add a new info level for SIGGEN_LOCKEDSIGS_TASKSIG_CHECK > > scripts/bblock: add a script to lock/unlock recipes > > oeqa/selftest/bblock: add self test for bblock tool > > > > bitbake/lib/bb/command.py | 6 + > > bitbake/lib/bb/cooker.py | 16 +++ > > bitbake/lib/bb/event.py| 8 ++ > > meta
[OE-core] [PATCH] qemuboot: Update hardcoded path to match new layout
Obviously this code is horrible and shouldn't hardcode it. Update it to match
the WORKDIR change to drop PE/PR for now.
Signed-off-by: Richard Purdie
---
meta/classes-recipe/qemuboot.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/qemuboot.bbclass
b/meta/classes-recipe/qemuboot.bbclass
index 12d0a509f13..e30b380c3dc 100644
--- a/meta/classes-recipe/qemuboot.bbclass
+++ b/meta/classes-recipe/qemuboot.bbclass
@@ -143,7 +143,7 @@ python do_write_qemuboot_conf() {
# contains all tools required by runqemu
if k == 'STAGING_BINDIR_NATIVE':
val = os.path.join(d.getVar('BASE_WORKDIR'), d.getVar('BUILD_SYS'),
-
'qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/')
+
'qemu-helper-native/1.0/recipe-sysroot-native/usr/bin/')
else:
val = d.getVar(k)
if val is None:
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185832):
https://lists.openembedded.org/g/openembedded-core/message/185832
Mute This Topic: https://lists.openembedded.org/mt/100679900/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2] externalsrc: fix dependency chain issues
From: Peter Suti
Instead of deleting setscene tasks, now SSTATE_SKIP_CREATION is set instead.
This seems to fix the compile issues where the populate_sysroot task was
not run when an externalsrc recipe was built as a dependency.
[YOCTO #15164]
[RP addition: The deltask was added by me in 2012 when the class was created.
The trouble is bitbake assumes 'sstate' tasks have a setscene task and by
deleting
the setscene task, bitbake stops thinking the task can be accelerated. There is
other
code in the sysroot code which assumes some tasks are always sstate tasks.
We cannot delete the task without changes to the way bitbake learns about
'setscene'
tasks so the patch is correct, avoiding creating files is the better approach
given
the way the world works now.
There would be concerns about exisitng sstate reuse however this shouldn't occur
since SRC_URI changes and that will change the underlying hashes. Hash
equivalency
could potentially cause issues by joining hashes together again however if the
output
matches, that shouldn't in theory cause any issue.]
Signed-off-by: Peter Suti
Signed-off-by: Richard Purdie
---
meta/classes/externalsrc.bbclass | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index b00fdba8e98..aedd78a03aa 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -75,6 +75,8 @@ python () {
# Dummy value because the default function can't be called with blank
SRC_URI
d.setVar('SRCPV', '999')
+# sstate is never going to work for external source trees, disable it
+d.setVar('SSTATE_SKIP_CREATION', '1')
if d.getVar('CONFIGUREOPT_DEPTRACK') ==
'--disable-dependency-tracking':
d.setVar('CONFIGUREOPT_DEPTRACK', '')
@@ -82,10 +84,7 @@ python () {
tasks = filter(lambda k: d.getVarFlag(k, "task"), d.keys())
for task in tasks:
-if task.endswith("_setscene"):
-# sstate is never going to work for external source trees,
disable it
-bb.build.deltask(task, d)
-elif os.path.realpath(d.getVar('S')) ==
os.path.realpath(d.getVar('B')):
+if os.path.realpath(d.getVar('S')) ==
os.path.realpath(d.getVar('B')):
# Since configure will likely touch ${S}, ensure only we lock
so one task has access at a time
d.appendVarFlag(task, "lockfiles", " ${S}/singletask.lock")
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185833):
https://lists.openembedded.org/g/openembedded-core/message/185833
Mute This Topic: https://lists.openembedded.org/mt/100679925/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v4 0/5] Add bblock helper scripts
On 11/08/2023 10:00:33+0200, Alexandre Belloni wrote: > On 10/08/2023 15:21:14+0200, Alexandre Belloni wrote: > > Hello, this causes oe-selftest failures on the autobuilders: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5589/steps/14/logs/stdio > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5577/steps/14/logs/stdio > > https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/5536/steps/14/logs/stdio > > https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/5613/steps/14/logs/stdio > > > > 2023-08-10 09:44:34,071 - oe-selftest - INFO - > > bblock.BBLock.test_lock_architecture_specific (subunit.RemotedTestCase) > > 2023-08-10 09:44:34,072 - oe-selftest - INFO - ... FAIL > > Stderr: > > 2023-08-10 09:40:23,454 - oe-selftest - INFO - Adding: "include > > selftest.inc" in > > /home/pokybuild/yocto-worker/oe-selftest-centos/build/build-st-2290072/conf/local.conf > > 2023-08-10 09:40:23,455 - oe-selftest - INFO - Adding: "include > > bblayers.inc" in bblayers.conf > > 2023-08-10 09:44:34,072 - oe-selftest - INFO - 3: 1/34 29/533 (250.62s) (0 > > failed) (bblock.BBLock.test_lock_architecture_specific) > > 2023-08-10 09:44:34,072 - oe-selftest - INFO - > > testtools.testresult.real._StringException: Traceback (most recent call > > last): > > File > > "/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/lib/oeqa/selftest/cases/bblock.py", > > line 103, in test_lock_architecture_specific > > self.assertNotIn(info_message, result.output) > > File "/usr/lib64/python3.9/unittest/case.py", line , in assertNotIn > > self.fail(self._formatMessage(msg, standardMsg)) > > File "/usr/lib64/python3.9/unittest/case.py", line 676, in fail > > raise self.failureException(msg) > > AssertionError: 'NOTE: The following recipes have locked tasks: quilt' > > unexpectedly found in 'NOTE: Reconnecting to bitbake server... > > > > Hum, wait, I got this without the patch series. Let me investigate. Actually, I still had the series :) > > > > > > > On 02/08/2023 16:24:27+0200, Julien Stephan wrote: > > > Hi all, > > > > > > This is v4 for bblock script. > > > > > > Improvement from v3: > > > * Add self test > > > * Add a new "info" level for SIGGEN_LOCKEDSIGS_TASKSIG_CHECK: this allows > > > to > > > display a Note when recipe contains locked task(s) > > > > > > Limitations: > > > * Silently does nothing if given task doesn't exist > > > * Silently does nothing when resetting a recipe that doesn't exist > > > > > > Improvement from v2: > > > * Add a function in bb.cooker to compute task signatures > > > * Replace the findSigInfo function by the new created one. This has the > > > following advantages: > > > * findSigInfo needs the task to be already built to get the siginfo > > > file, meaning we cannot lock a recipe on a fresh build > > > * we can now generate the signatures for all available task of a given > > > recipe > > > * Check if a given task is already locked. If so, don't duplicate > > > entry in bblock.conf > > > > > > Limitations: > > > * Needs to taint tasks that are locked, to display a warning > > > * I may be still missing some checks on user input > > > * Silently does nothing if given task doesn't exist > > > * Silently does nothing when resetting a recipe that doesn't exist > > > > > > I did some tests using qemux86-64 and qemuarm but I may be missing some > > > corner cases. > > > > > > Improvement from V1: > > > * Signatures are now package architecture specific meaning that if you > > > switch MACHINE, the lock sig will not be taken into account > > > * I added the -r option to unlock recipes > > > * I added a -d option to display the current bblock.conf > > > * Added an include directive for conf/bblock.conf inside bitbake.conf > > > * Added -t option to specify the tasks to lock/unlock > > > > > > Limitations: > > > * I may be still missing some checks on user input > > > * I need to find a way to get the list of tasks ( by default still lock > > > only the do_compile for now, unless -t is specified) > > > * Do not check if a particular recipe/task is already locked when trying > > > to add lock. So entries may appear multiple times > > > * We still need the signature of the tasks to be already computed before > > > locking. Need to find a way to generate it if missing > > > > > > V3: https://lists.openembedded.org/g/openembedded-core/message/184932 > > > V2: https://lists.openembedded.org/g/openembedded-core/message/184697 > > > V1: https://lists.openembedded.org/g/openembedded-core/message/184584 > > > > > > My branch is available here [1] > > > > > > Cheers > > > Julien > > > > > > [1]: https://git.yoctoproject.org/poky-contrib/commit/?h=jstephan/bblock > > > Julien Stephan (5): > > > bitbake.conf: include bblock.conf > > > bitbake: cooker: add a new function to retrieve task signatures > > > sstatesig: add a new info level for SIGGEN_LOCKED
[OE-core] [PATCH] conf/init-mamager-systemd: Add usrmerge to DISTRO_FEATURES
usrmerge is now required by systemd, ensure this is also added to DISTRO_FEATURES when systemd is selected. Signed-off-by: Richard Purdie --- meta/conf/distro/include/init-manager-systemd.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/conf/distro/include/init-manager-systemd.inc b/meta/conf/distro/include/init-manager-systemd.inc index 7867d900283..595d1f2644b 100644 --- a/meta/conf/distro/include/init-manager-systemd.inc +++ b/meta/conf/distro/include/init-manager-systemd.inc @@ -1,5 +1,5 @@ # Use systemd for system initialization -DISTRO_FEATURES:append = " systemd" +DISTRO_FEATURES:append = " systemd usrmerge" DISTRO_FEATURES_BACKFILL_CONSIDERED:append = " sysvinit" VIRTUAL-RUNTIME_init_manager ??= "systemd" VIRTUAL-RUNTIME_initscripts ??= "systemd-compat-units" -- 2.39.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185835): https://lists.openembedded.org/g/openembedded-core/message/185835 Mute This Topic: https://lists.openembedded.org/mt/100680967/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] systemd: add usrmerge to REQUIRED_DISTRO_FEATURES
On Sat, 2023-08-05 at 22:35 +0100, Luca Bocassi wrote:
> From: Luca Boccassi
>
> Support for unmerged-usr is deprecated upstream, taints the system and
> has been removed for v255 (next release).
> Enforce building merged-usr images when using systemd. This allows one
> release cycle where it can be tested for any remaining issue, and can
> still be overridden, before it stops working completely.
>
> Signed-off-by: Luca Boccassi
> ---
> v2: rearrange so systemd-boot.bb is left as-is for now
>
> meta/recipes-core/systemd/systemd-compat-units.bb | 3 ++-
> meta/recipes-core/systemd/systemd-conf_1.0.bb | 3 +++
> meta/recipes-core/systemd/systemd-machine-units_1.0.bb | 3 ++-
> meta/recipes-core/systemd/systemd-serialgetty.bb | 3 ++-
> meta/recipes-core/systemd/systemd_254.bb | 6 +-
> 5 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-core/systemd/systemd-compat-units.bb
> b/meta/recipes-core/systemd/systemd-compat-units.bb
> index 55ebf99117f..75b1045728a 100644
> --- a/meta/recipes-core/systemd/systemd-compat-units.bb
> +++ b/meta/recipes-core/systemd/systemd-compat-units.bb
> @@ -14,7 +14,8 @@ INHIBIT_DEFAULT_DEPS = "1"
>
> ALLOW_EMPTY:${PN} = "1"
>
> -REQUIRED_DISTRO_FEATURES = "systemd"
> +REQUIRED_DISTRO_FEATURES += "systemd"
> +REQUIRED_DISTRO_FEATURES += "usrmerge"
>
> SYSTEMD_DISABLED_SYSV_SERVICES = " \
>busybox-udhcpc \
> diff --git a/meta/recipes-core/systemd/systemd-conf_1.0.bb
> b/meta/recipes-core/systemd/systemd-conf_1.0.bb
> index 61ce7939d3a..2355936631e 100644
> --- a/meta/recipes-core/systemd/systemd-conf_1.0.bb
> +++ b/meta/recipes-core/systemd/systemd-conf_1.0.bb
> @@ -5,6 +5,9 @@ DefaultTimeoutStartSec setting."
> LICENSE = "MIT"
> LIC_FILES_CHKSUM =
> "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
>
> +inherit features_check
> +REQUIRED_DISTRO_FEATURES += "usrmerge"
> +
> PE = "1"
>
> PACKAGECONFIG ??= "dhcp-ethernet"
> diff --git a/meta/recipes-core/systemd/systemd-machine-units_1.0.bb
> b/meta/recipes-core/systemd/systemd-machine-units_1.0.bb
> index 12f27d6ae30..7e59e86f9be 100644
> --- a/meta/recipes-core/systemd/systemd-machine-units_1.0.bb
> +++ b/meta/recipes-core/systemd/systemd-machine-units_1.0.bb
> @@ -7,7 +7,8 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> PR = "r19"
>
> -inherit systemd
> +inherit systemd features_check
> +REQUIRED_DISTRO_FEATURES += "usrmerge"
> SYSTEMD_SERVICE:${PN} = ""
>
> ALLOW_EMPTY:${PN} = "1"
> diff --git a/meta/recipes-core/systemd/systemd-serialgetty.bb
> b/meta/recipes-core/systemd/systemd-serialgetty.bb
> index fd888bb8340..c2c67e6fe08 100644
> --- a/meta/recipes-core/systemd/systemd-serialgetty.bb
> +++ b/meta/recipes-core/systemd/systemd-serialgetty.bb
> @@ -14,7 +14,8 @@ S = "${WORKDIR}"
>
> # As this package is tied to systemd, only build it when we're also building
> systemd.
> inherit features_check
> -REQUIRED_DISTRO_FEATURES = "systemd"
> +REQUIRED_DISTRO_FEATURES += "systemd"
> +REQUIRED_DISTRO_FEATURES += "usrmerge"
>
> do_install() {
> if [ ! -z "${SERIAL_CONSOLES}" ] ; then
> diff --git a/meta/recipes-core/systemd/systemd_254.bb
> b/meta/recipes-core/systemd/systemd_254.bb
> index 7ba4233f6a2..3fa49122cd6 100644
> --- a/meta/recipes-core/systemd/systemd_254.bb
> +++ b/meta/recipes-core/systemd/systemd_254.bb
> @@ -10,9 +10,13 @@ SECTION = "base/shell"
>
> inherit useradd pkgconfig meson perlnative update-rc.d update-alternatives
> qemu systemd gettext bash-completion manpages features_check
>
> +# unmerged-usr support is deprecated upstream, taints the system and will be
> +# removed in the near future. Fail the build if it is not enabled.
> +REQUIRED_DISTRO_FEATURES += "usrmerge"
> +
> # As this recipe builds udev, respect systemd being in DISTRO_FEATURES so
> # that we don't build both udev and systemd in world builds.
> -REQUIRED_DISTRO_FEATURES = "systemd"
> +REQUIRED_DISTRO_FEATURES += "systemd"
>
> SRC_URI += " \
> file://touchscreen.rules \
FWIW I tried multiple runs of this through the autobuilder and tracked
down all the places this needed fixing so the test work. Once those
fixes merged, I was able to merge this.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185836):
https://lists.openembedded.org/g/openembedded-core/message/185836
Mute This Topic: https://lists.openembedded.org/mt/100572063/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-Core][PATCH 0/2] oeqa/utils/gitarchive: fix tag name computation
Hello, this series brings a fix to a sporadic tag push issue observed in autobuilder. The bug is documented in bugzilla #15140 ([1]). Basically, whenever the autobuilder creates a new tag on test results, it is only aware of "local" tags, which is kind of faulty since used repository is a shallow clone. This series then brings two patches: - a first one to introduce gitarchive tests as a safety net - a second one to implement the fix by replacing "git tag" calls by "git ls-remote" calls where appropriate [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15140 Alexis Lothoré (2): oeqa/selftest: introduce gitarchive tests oeqa/utils/gitarchive: fix tag computation when creating archive .../oeqa/selftest/cases/gitarchivetests.py| 96 +++ meta/lib/oeqa/utils/gitarchive.py | 6 +- 2 files changed, 100 insertions(+), 2 deletions(-) create mode 100644 meta/lib/oeqa/selftest/cases/gitarchivetests.py -- 2.41.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185838): https://lists.openembedded.org/g/openembedded-core/message/185838 Mute This Topic: https://lists.openembedded.org/mt/100682829/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-Core][PATCH 2/2] oeqa/utils/gitarchive: fix tag computation when creating archive
From: Alexis Lothoré
Sporadic errors have been observed in autobuilder when trying to store new
tests results:
error: failed to push some refs to 'push.yoctoproject.org:yocto-testresults'
hint: Updates were rejected because the tag already exists in the remote.
The new tag name is generated by gitarchive based on known tags from the
repository (learnt with git tag). In autobuilder case, this repository is a
shallow clone, so git tag only returns most recent tags, which mean we
could miss some older tags which exist in remote but not locally. In this
case, gitarchive will likely create a tag which already exists in remote,
and so will fail to push
Fix this tag duplication by using git ls-remote to learn about existing
tags instead of git tag. Two places which wrongly read only local tags has
been identified in gitarchive: expand_tag_strings and get_test_runs
Fixes [YOCTO #15140]
Signed-off-by: Alexis Lothoré
---
meta/lib/oeqa/utils/gitarchive.py | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/utils/gitarchive.py
b/meta/lib/oeqa/utils/gitarchive.py
index 6e8040eb5c96..73beafecb5fb 100644
--- a/meta/lib/oeqa/utils/gitarchive.py
+++ b/meta/lib/oeqa/utils/gitarchive.py
@@ -116,7 +116,8 @@ def expand_tag_strings(repo, name_pattern,
msg_subj_pattern, msg_body_pattern,
tag_re = tag_re.format(tag_number='(?P[0-9]{1,5})')
keyws['tag_number'] = 0
-for existing_tag in repo.run_cmd('tag').splitlines():
+tags_refs = repo.run_cmd(['ls-remote', '--refs', '--tags', '-q'])
+for existing_tag in ["".join(d.split()[1].split('/', 2)[2:]) for d in
tags_refs.splitlines()]:
match = re.match(tag_re, existing_tag)
if match and int(match.group('tag_number')) >= keyws['tag_number']:
@@ -181,7 +182,8 @@ def get_test_runs(log, repo, tag_name, **kwargs):
# Get a list of all matching tags
tag_pattern = tag_name.format(**str_fields)
-tags = repo.run_cmd(['tag', '-l', tag_pattern]).splitlines()
+revs = repo.run_cmd(['ls-remote', '--refs', '--tags', 'origin', '-q',
tag_pattern]).splitlines()
+tags = ["".join(d.split()[1].split('/', 2)[2:]) for d in revs]
log.debug("Found %d tags matching pattern '%s'", len(tags), tag_pattern)
# Parse undefined fields from tag names
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185837):
https://lists.openembedded.org/g/openembedded-core/message/185837
Mute This Topic: https://lists.openembedded.org/mt/100682828/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-Core][PATCH 1/2] oeqa/selftest: introduce gitarchive tests
From: Alexis Lothoré
Add a test suite for gitarchive.py. For now, only introduce tests on
methods which needs to read existing tags
The tests rely on tmpdirs to create local, "fake" results repository in
order to allow basic git commands
Signed-off-by: Alexis Lothoré
---
.../oeqa/selftest/cases/gitarchivetests.py| 96 +++
1 file changed, 96 insertions(+)
create mode 100644 meta/lib/oeqa/selftest/cases/gitarchivetests.py
diff --git a/meta/lib/oeqa/selftest/cases/gitarchivetests.py
b/meta/lib/oeqa/selftest/cases/gitarchivetests.py
new file mode 100644
index ..4f7acd3311d5
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/gitarchivetests.py
@@ -0,0 +1,96 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+import os
+import sys
+basepath = os.path.abspath(os.path.dirname(__file__) + '/../../../../../')
+lib_path = basepath + '/scripts/lib'
+sys.path = sys.path + [lib_path]
+import oeqa.utils.gitarchive as ga
+import tempfile
+import shutil
+import scriptutils
+from oeqa.selftest.case import OESelftestTestCase
+
+logger = scriptutils.logger_create('resulttool')
+
+def create_fake_repository(commit, tag_list=[]):
+""" Create a testing git directory
+
+Initialize a simple git repository with one initial commit, and as many
+tags on this commit as listed in tag_list
+Returns both git directory path and gitarchive git object
+If commit is true, fake data will be commited, otherwise it will stay in
staging area
+If commit is true and tag_lsit is non empty, all tags in tag_list will be
+created on the initial commit
+Fake remote will also be added to make git ls-remote work
+"""
+fake_data_file = "fake_data.txt"
+tempdir = tempfile.mkdtemp(prefix='fake_results.')
+repo = ga.init_git_repo(tempdir, False, False, logger)
+repo.run_cmd(["remote", "add", "origin", "."])
+with open(os.path.join(tempdir, fake_data_file), "w") as fake_data:
+fake_data.write("Fake data")
+if commit:
+repo.run_cmd(["add", fake_data_file])
+repo.run_cmd(["commit", "-m", "\"Add fake data\""])
+for tag in tag_list:
+repo.run_cmd(["tag", tag])
+
+return tempdir, repo
+
+def delete_fake_repository(path):
+shutil.rmtree(path)
+
+def tag_exists(git_obj, target_tag):
+for tag in git_obj.run_cmd(["tag"]).splitlines():
+if target_tag == tag:
+return True
+return False
+
+class GitArchiveTests(OESelftestTestCase):
+TEST_BRANCH="main"
+TEST_COMMIT="0f7d5df"
+TEST_COMMIT_COUNT="42"
+
+def test_create_first_test_tag(self):
+path, git_obj = create_fake_repository(False)
+keywords = {'commit': self.TEST_COMMIT, 'branch': self.TEST_BRANCH,
"commit_count": self.TEST_COMMIT_COUNT}
+target_tag =
f"{self.TEST_BRANCH}/{self.TEST_COMMIT_COUNT}-g{self.TEST_COMMIT}/0"
+
+ga.gitarchive(path, path, True, False,
+ "Results of {branch}:{commit}", "branch:
{branch}\ncommit: {commit}", "{branch}",
+ False,
"{branch}/{commit_count}-g{commit}/{tag_number}",
+ 'Test run #{tag_number} of {branch}:{commit}',
'',
+ [], [], False, keywords, logger)
+self.assertTrue(tag_exists(git_obj, target_tag), msg=f"Tag
{target_tag} has not been created")
+delete_fake_repository(path)
+
+def test_create_second_test_tag(self):
+first_tag =
f"{self.TEST_BRANCH}/{self.TEST_COMMIT_COUNT}-g{self.TEST_COMMIT}/0"
+second_tag =
f"{self.TEST_BRANCH}/{self.TEST_COMMIT_COUNT}-g{self.TEST_COMMIT}/1"
+keywords = {'commit': self.TEST_COMMIT, 'branch': self.TEST_BRANCH,
"commit_count": self.TEST_COMMIT_COUNT}
+
+path, git_obj = create_fake_repository(True, [first_tag])
+ga.gitarchive(path, path, True, False,
+ "Results of {branch}:{commit}", "branch:
{branch}\ncommit: {commit}", "{branch}",
+ False,
"{branch}/{commit_count}-g{commit}/{tag_number}",
+ 'Test run #{tag_number} of {branch}:{commit}',
'',
+ [], [], False, keywords, logger)
+self.assertTrue(tag_exists(git_obj, second_tag), msg=f"Second tag
{second_tag} has not been created")
+delete_fake_repository(path)
+
+def test_get_revs_on_branch(self):
+fake_tags_list=["main/10-g0f7d5df/0", "main/10-g0f7d5df/1",
"foo/20-g2468f5d/0"]
+tag_name = "{branch}/{commit_number}-g{commit}/{tag_number}"
+
+path, git_obj = create_fake_repository(True, fake_tags_list)
+revs = ga.get_test_revs(logger, git_obj, tag_name, branch="main")
+self.assertEqual(len(revs), 1)
+self.assertEqual(revs[0].commit, "0f7d5df")
+self.assertEqual(len(revs[0].tags), 2)
+self.assertEqual(revs[0].tags, ['main/10-g0f7d5df/0',
'main/10-g0f7d5df/1'])
Re: [OE-core] [PATCH v2] systemd: add usrmerge to REQUIRED_DISTRO_FEATURES
On Fri, 11 Aug 2023 at 13:24, Richard Purdie
wrote:
>
> On Sat, 2023-08-05 at 22:35 +0100, Luca Bocassi wrote:
> > From: Luca Boccassi
> >
> > Support for unmerged-usr is deprecated upstream, taints the system and
> > has been removed for v255 (next release).
> > Enforce building merged-usr images when using systemd. This allows one
> > release cycle where it can be tested for any remaining issue, and can
> > still be overridden, before it stops working completely.
> >
> > Signed-off-by: Luca Boccassi
> > ---
> > v2: rearrange so systemd-boot.bb is left as-is for now
> >
> > meta/recipes-core/systemd/systemd-compat-units.bb | 3 ++-
> > meta/recipes-core/systemd/systemd-conf_1.0.bb | 3 +++
> > meta/recipes-core/systemd/systemd-machine-units_1.0.bb | 3 ++-
> > meta/recipes-core/systemd/systemd-serialgetty.bb | 3 ++-
> > meta/recipes-core/systemd/systemd_254.bb | 6 +-
> > 5 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/meta/recipes-core/systemd/systemd-compat-units.bb
> > b/meta/recipes-core/systemd/systemd-compat-units.bb
> > index 55ebf99117f..75b1045728a 100644
> > --- a/meta/recipes-core/systemd/systemd-compat-units.bb
> > +++ b/meta/recipes-core/systemd/systemd-compat-units.bb
> > @@ -14,7 +14,8 @@ INHIBIT_DEFAULT_DEPS = "1"
> >
> > ALLOW_EMPTY:${PN} = "1"
> >
> > -REQUIRED_DISTRO_FEATURES = "systemd"
> > +REQUIRED_DISTRO_FEATURES += "systemd"
> > +REQUIRED_DISTRO_FEATURES += "usrmerge"
> >
> > SYSTEMD_DISABLED_SYSV_SERVICES = " \
> >busybox-udhcpc \
> > diff --git a/meta/recipes-core/systemd/systemd-conf_1.0.bb
> > b/meta/recipes-core/systemd/systemd-conf_1.0.bb
> > index 61ce7939d3a..2355936631e 100644
> > --- a/meta/recipes-core/systemd/systemd-conf_1.0.bb
> > +++ b/meta/recipes-core/systemd/systemd-conf_1.0.bb
> > @@ -5,6 +5,9 @@ DefaultTimeoutStartSec setting."
> > LICENSE = "MIT"
> > LIC_FILES_CHKSUM =
> > "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
> >
> > +inherit features_check
> > +REQUIRED_DISTRO_FEATURES += "usrmerge"
> > +
> > PE = "1"
> >
> > PACKAGECONFIG ??= "dhcp-ethernet"
> > diff --git a/meta/recipes-core/systemd/systemd-machine-units_1.0.bb
> > b/meta/recipes-core/systemd/systemd-machine-units_1.0.bb
> > index 12f27d6ae30..7e59e86f9be 100644
> > --- a/meta/recipes-core/systemd/systemd-machine-units_1.0.bb
> > +++ b/meta/recipes-core/systemd/systemd-machine-units_1.0.bb
> > @@ -7,7 +7,8 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> > PR = "r19"
> >
> > -inherit systemd
> > +inherit systemd features_check
> > +REQUIRED_DISTRO_FEATURES += "usrmerge"
> > SYSTEMD_SERVICE:${PN} = ""
> >
> > ALLOW_EMPTY:${PN} = "1"
> > diff --git a/meta/recipes-core/systemd/systemd-serialgetty.bb
> > b/meta/recipes-core/systemd/systemd-serialgetty.bb
> > index fd888bb8340..c2c67e6fe08 100644
> > --- a/meta/recipes-core/systemd/systemd-serialgetty.bb
> > +++ b/meta/recipes-core/systemd/systemd-serialgetty.bb
> > @@ -14,7 +14,8 @@ S = "${WORKDIR}"
> >
> > # As this package is tied to systemd, only build it when we're also
> > building systemd.
> > inherit features_check
> > -REQUIRED_DISTRO_FEATURES = "systemd"
> > +REQUIRED_DISTRO_FEATURES += "systemd"
> > +REQUIRED_DISTRO_FEATURES += "usrmerge"
> >
> > do_install() {
> > if [ ! -z "${SERIAL_CONSOLES}" ] ; then
> > diff --git a/meta/recipes-core/systemd/systemd_254.bb
> > b/meta/recipes-core/systemd/systemd_254.bb
> > index 7ba4233f6a2..3fa49122cd6 100644
> > --- a/meta/recipes-core/systemd/systemd_254.bb
> > +++ b/meta/recipes-core/systemd/systemd_254.bb
> > @@ -10,9 +10,13 @@ SECTION = "base/shell"
> >
> > inherit useradd pkgconfig meson perlnative update-rc.d update-alternatives
> > qemu systemd gettext bash-completion manpages features_check
> >
> > +# unmerged-usr support is deprecated upstream, taints the system and will
> > be
> > +# removed in the near future. Fail the build if it is not enabled.
> > +REQUIRED_DISTRO_FEATURES += "usrmerge"
> > +
> > # As this recipe builds udev, respect systemd being in DISTRO_FEATURES so
> > # that we don't build both udev and systemd in world builds.
> > -REQUIRED_DISTRO_FEATURES = "systemd"
> > +REQUIRED_DISTRO_FEATURES += "systemd"
> >
> > SRC_URI += " \
> > file://touchscreen.rules \
>
> FWIW I tried multiple runs of this through the autobuilder and tracked
> down all the places this needed fixing so the test work. Once those
> fixes merged, I was able to merge this.
Very nice, thank you!
Kind regards,
Luca Boccassi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185840):
https://lists.openembedded.org/g/openembedded-core/message/185840
Mute This Topic: https://lists.openembedded.org/mt/100572063/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] base/package: Move source revision information from PV to PKGV
Source control information being present in PV used to be a hard requirement
for bitbake to operate correctly. Now that hashes are a required part of task
stamps, this requirement no longer exists.
This means we can defer the hash pieces to PKGV and simplify PV.
Use new bitbake fetcher API to inject the source revisions directly into the
hash
allowing removal of some horrible code from base.bbclass and avoiding any
hardcoding
about how SRCREV may or may not be used.
Use that API to object the string to append to PKGV and append that directly.
The user visible effect of this change is that PV will no longer have revision
information in it and this will now be appended to PV through PKGV when the
packages are written. Since PV is used in STAMP and WORKDIR, users will see
small directory naming and stamp naming changes.
This will mean that sstate reuse through hash equivalence where the source
revision changes but the output does not will become possible as the sstate
naming will become less specific and no longer contain the revision.
The SRCPV variable will no longer be needed in PV and is effectively now just
a null operation. Usage can be removed over time.
Signed-off-by: Richard Purdie
---
meta/classes-global/base.bbclass| 26 +-
meta/classes-global/package.bbclass | 6 +-
meta/conf/bitbake.conf | 5 +
3 files changed, 7 insertions(+), 30 deletions(-)
diff --git a/meta/classes-global/base.bbclass b/meta/classes-global/base.bbclass
index cbda8d12f09..271ff13d62c 100644
--- a/meta/classes-global/base.bbclass
+++ b/meta/classes-global/base.bbclass
@@ -130,7 +130,7 @@ addtask fetch
do_fetch[dirs] = "${DL_DIR}"
do_fetch[file-checksums] = "${@bb.fetch.get_checksum_file_list(d)}"
do_fetch[file-checksums] += " ${@get_lic_checksum_file_list(d)}"
-do_fetch[vardeps] += "SRCREV"
+do_fetch[vardepvalue] += "${@bb.fetch.get_hashvalue(d)}"
do_fetch[network] = "1"
python base_do_fetch() {
@@ -606,7 +606,6 @@ python () {
bb.debug(1, "Skipping recipe %s because of incompatible
license(s): %s" % (pn, ' '.join(incompatible_lic)))
raise bb.parse.SkipRecipe("it has incompatible license(s):
%s" % ' '.join(incompatible_lic))
-needsrcrev = False
srcuri = d.getVar('SRC_URI')
for uri_string in srcuri.split():
uri = bb.fetch.URI(uri_string)
@@ -619,24 +618,17 @@ python () {
# Svn packages should DEPEND on subversion-native
if uri.scheme == "svn":
-needsrcrev = True
d.appendVarFlag('do_fetch', 'depends', '
subversion-native:do_populate_sysroot')
# Git packages should DEPEND on git-native
elif uri.scheme in ("git", "gitsm"):
-needsrcrev = True
d.appendVarFlag('do_fetch', 'depends', '
git-native:do_populate_sysroot')
# Mercurial packages should DEPEND on mercurial-native
elif uri.scheme == "hg":
-needsrcrev = True
d.appendVar("EXTRANATIVEPATH", ' python3-native ')
d.appendVarFlag('do_fetch', 'depends', '
mercurial-native:do_populate_sysroot')
-# Perforce packages support SRCREV = "${AUTOREV}"
-elif uri.scheme == "p4":
-needsrcrev = True
-
# OSC packages should DEPEND on osc-native
elif uri.scheme == "osc":
d.appendVarFlag('do_fetch', 'depends', '
osc-native:do_populate_sysroot')
@@ -645,7 +637,6 @@ python () {
d.appendVarFlag('do_fetch', 'depends', '
nodejs-native:do_populate_sysroot')
elif uri.scheme == "repo":
-needsrcrev = True
d.appendVarFlag('do_fetch', 'depends', '
repo-native:do_populate_sysroot')
# *.lz4 should DEPEND on lz4-native for unpacking
@@ -676,21 +667,6 @@ python () {
elif path.endswith('.deb'):
d.appendVarFlag('do_unpack', 'depends', '
xz-native:do_populate_sysroot')
-if needsrcrev:
-d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
-
-# Gather all named SRCREVs to add to the sstate hash calculation
-# This anonymous python snippet is called multiple times so we
-# need to be careful to not double up the appends here and cause
-# the base hash to mismatch the task hash
-for uri in srcuri.split():
-parm = bb.fetch.decodeurl(uri)[5]
-uri_names = parm.get("name", "").split(",")
-for uri_name in filter(None, uri_names):
-srcrev_name = "SRCREV_{}".format(uri_name)
-if srcrev_name not in (d.getVarFlag("do_fetch", "vardeps") or
"").split():
-d.appendVarFlag("do_fetch", "vardeps", "
{}".format(srcrev_name))
-
set_packagetriplet(d)
# 'multimachine' handling
diff --git a/meta/classes-global/package.bbclass
b/meta/classes-global/package.bbclass
index e8055a9cdc5..7f55b123c4e 100644
--- a/meta/classes-global/package.bbclass
+++ b/meta/classes-glob
[OE-core] [PATCH] recipes/classes/scripts: Drop SRCPV usage in OE-Core
Now that SRCPV isn't needed we can simplify things in a few places...
Signed-off-by: Richard Purdie
---
.../recipes-test/devtool/devtool-upgrade-test2_git.bb | 2 +-
.../devtool/devtool-upgrade-test2_git.bb.upgraded | 2 +-
.../recipes-test/gitunpackoffline/gitunpackoffline.bb | 2 +-
meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb| 2 +-
meta/classes-global/sstate.bbclass | 4
meta/classes-recipe/devupstream.bbclass | 2 +-
meta/classes/externalsrc.bbclass| 2 --
meta/conf/bitbake.conf | 2 +-
meta/conf/documentation.conf| 1 -
meta/lib/oe/recipeutils.py | 4 +---
meta/lib/oeqa/selftest/cases/devtool.py | 6 +++---
meta/lib/oeqa/selftest/cases/recipetool.py | 2 +-
meta/lib/oeqa/selftest/cases/sstatetests.py | 1 -
meta/recipes-bsp/efivar/efivar_38.bb| 2 +-
meta/recipes-core/dbus-wait/dbus-wait_git.bb| 2 +-
meta/recipes-core/musl/gcompat_git.bb | 2 +-
meta/recipes-core/musl/libc-test_git.bb | 2 +-
meta/recipes-core/musl/musl-locales_git.bb | 2 +-
meta/recipes-core/musl/musl_git.bb | 2 +-
meta/recipes-core/newlib/newlib.inc | 2 +-
meta/recipes-core/psplash/psplash_git.bb| 2 +-
meta/recipes-devtools/gnu-config/gnu-config_git.bb | 2 +-
meta/recipes-devtools/mmc/mmc-utils_git.bb | 2 +-
meta/recipes-devtools/pkgconfig/pkgconfig_git.bb| 2 +-
meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +-
meta/recipes-devtools/python/python3-dtc_1.6.1.bb | 2 +-
meta/recipes-devtools/tcf-agent/tcf-agent_git.bb| 2 +-
meta/recipes-devtools/xmlto/xmlto_0.0.28.bb | 2 +-
.../baremetal-example/baremetal-helloworld_git.bb | 2 +-
meta/recipes-graphics/libfakekey/libfakekey_git.bb | 2 +-
meta/recipes-graphics/piglit/piglit_git.bb | 2 +-
.../xcursor-transparent-theme_git.bb| 2 +-
.../xinput-calibrator/xinput-calibrator_git.bb | 2 +-
meta/recipes-graphics/xorg-driver/xf86-video-intel_git.bb | 2 +-
meta/recipes-kernel/blktrace/blktrace_git.bb| 2 +-
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-dev.bb| 2 +-
meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-rt_6.4.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_6.4.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_6.1.bb| 2 +-
meta/recipes-kernel/linux/linux-yocto_6.4.bb| 2 +-
meta/recipes-multimedia/x264/x264_git.bb| 2 +-
meta/recipes-sato/l3afpad/l3afpad_git.bb| 2 +-
.../matchbox-config-gtk/matchbox-config-gtk_0.2.bb | 2 +-
.../recipes-sato/matchbox-terminal/matchbox-terminal_0.2.bb | 2 +-
meta/recipes-sato/puzzles/puzzles_git.bb| 2 +-
meta/recipes-support/bmap-tools/bmap-tools_git.bb | 2 +-
meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb | 2 +-
scripts/lib/recipetool/create.py| 2 +-
scripts/lib/scriptutils.py | 2 +-
52 files changed, 50 insertions(+), 60 deletions(-)
diff --git a/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb
b/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb
index 203f4b61c2e..2558a22ce57 100644
--- a/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb
+++ b/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb
@@ -8,7 +8,7 @@ DEPENDS = "dbus"
# Note: this is intentionally not the latest version in the original .bb
SRCREV = "1a3e1343761b30750bed70e0fd688f6d3c7b3717"
-PV = "0.1+git${SRCPV}"
+PV = "0.1+git"
PR = "r2"
SRC_URI = "git://git.yoctoproject.org/dbus-wait;branch=master"
diff --git
a/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb.upgraded
b/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb.upgraded
index 3d45fc48572..eaa8bd898da 100644
--- a/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb.upgraded
+++ b/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb.upgraded
@@ -8,7 +8,7 @@ DEPENDS = "dbus"
# Note: this is intentionally not the latest version in the original .bb
SRCREV = "6cc6077a36fe2648a5f993fe7c16c9632f946517"
-PV = "0.1+git${SRCPV}"
+PV = "0.1+git"
SRC_URI = "git://git.yoctoproject.org/dbus-wait;branch=master"
UPSTREAM_CHECK_COMMITS = "1"
diff --git a/meta-selftest/recipes-test
Re: [OE-core] [PATCH] recipes/classes/scripts: Drop SRCPV usage in OE-Core
Hi Richard,
Something to warm the user about the usage of it on existing layers around
will be useful in my opinion.
Jose
Richard Purdie escreveu no dia sexta,
11/08/2023 à(s) 14:35:
> Now that SRCPV isn't needed we can simplify things in a few places...
>
> Signed-off-by: Richard Purdie
> ---
> .../recipes-test/devtool/devtool-upgrade-test2_git.bb | 2 +-
> .../devtool/devtool-upgrade-test2_git.bb.upgraded | 2 +-
> .../recipes-test/gitunpackoffline/gitunpackoffline.bb | 2 +-
> meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb| 2 +-
> meta/classes-global/sstate.bbclass | 4
> meta/classes-recipe/devupstream.bbclass | 2 +-
> meta/classes/externalsrc.bbclass| 2 --
> meta/conf/bitbake.conf | 2 +-
> meta/conf/documentation.conf| 1 -
> meta/lib/oe/recipeutils.py | 4 +---
> meta/lib/oeqa/selftest/cases/devtool.py | 6 +++---
> meta/lib/oeqa/selftest/cases/recipetool.py | 2 +-
> meta/lib/oeqa/selftest/cases/sstatetests.py | 1 -
> meta/recipes-bsp/efivar/efivar_38.bb| 2 +-
> meta/recipes-core/dbus-wait/dbus-wait_git.bb| 2 +-
> meta/recipes-core/musl/gcompat_git.bb | 2 +-
> meta/recipes-core/musl/libc-test_git.bb | 2 +-
> meta/recipes-core/musl/musl-locales_git.bb | 2 +-
> meta/recipes-core/musl/musl_git.bb | 2 +-
> meta/recipes-core/newlib/newlib.inc | 2 +-
> meta/recipes-core/psplash/psplash_git.bb| 2 +-
> meta/recipes-devtools/gnu-config/gnu-config_git.bb | 2 +-
> meta/recipes-devtools/mmc/mmc-utils_git.bb | 2 +-
> meta/recipes-devtools/pkgconfig/pkgconfig_git.bb| 2 +-
> meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +-
> meta/recipes-devtools/python/python3-dtc_1.6.1.bb | 2 +-
> meta/recipes-devtools/tcf-agent/tcf-agent_git.bb| 2 +-
> meta/recipes-devtools/xmlto/xmlto_0.0.28.bb | 2 +-
> .../baremetal-example/baremetal-helloworld_git.bb | 2 +-
> meta/recipes-graphics/libfakekey/libfakekey_git.bb | 2 +-
> meta/recipes-graphics/piglit/piglit_git.bb | 2 +-
> .../xcursor-transparent-theme_git.bb| 2 +-
> .../xinput-calibrator/xinput-calibrator_git.bb | 2 +-
> meta/recipes-graphics/xorg-driver/xf86-video-intel_git.bb | 2 +-
> meta/recipes-kernel/blktrace/blktrace_git.bb| 2 +-
> meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
> meta/recipes-kernel/linux/linux-yocto-dev.bb| 2 +-
> meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb | 2 +-
> meta/recipes-kernel/linux/linux-yocto-rt_6.4.bb | 2 +-
> meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb | 2 +-
> meta/recipes-kernel/linux/linux-yocto-tiny_6.4.bb | 2 +-
> meta/recipes-kernel/linux/linux-yocto_6.1.bb| 2 +-
> meta/recipes-kernel/linux/linux-yocto_6.4.bb| 2 +-
> meta/recipes-multimedia/x264/x264_git.bb| 2 +-
> meta/recipes-sato/l3afpad/l3afpad_git.bb| 2 +-
> .../matchbox-config-gtk/matchbox-config-gtk_0.2.bb | 2 +-
> .../recipes-sato/matchbox-terminal/matchbox-terminal_0.2.bb | 2 +-
> meta/recipes-sato/puzzles/puzzles_git.bb| 2 +-
> meta/recipes-support/bmap-tools/bmap-tools_git.bb | 2 +-
> meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb | 2 +-
> scripts/lib/recipetool/create.py| 2 +-
> scripts/lib/scriptutils.py | 2 +-
> 52 files changed, 50 insertions(+), 60 deletions(-)
>
> diff --git a/meta-selftest/recipes-test/devtool/
> devtool-upgrade-test2_git.bb b/meta-selftest/recipes-test/devtool/
> devtool-upgrade-test2_git.bb
> index 203f4b61c2e..2558a22ce57 100644
> --- a/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb
> +++ b/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb
> @@ -8,7 +8,7 @@ DEPENDS = "dbus"
>
> # Note: this is intentionally not the latest version in the original .bb
> SRCREV = "1a3e1343761b30750bed70e0fd688f6d3c7b3717"
> -PV = "0.1+git${SRCPV}"
> +PV = "0.1+git"
> PR = "r2"
>
> SRC_URI = "git://git.yoctoproject.org/dbus-wait;branch=master"
> diff --git
> a/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb.upgraded
> b/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb.upgraded
> index 3d45fc48572..eaa8bd898da 100644
> ---
> a/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb.upgraded
> +++
> b/meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb.upg
Re: [OE-core] [PATCH] recipes/classes/scripts: Drop SRCPV usage in OE-Core
On Fri, 2023-08-11 at 14:45 +0100, Jose Quaresma wrote: > Something to warm the user about the usage of it on existing layers > around will be useful in my opinion. It is harmless but I'm sure we'll reach a point where we do something like that. There are also docs changes likely needed and so on. Right now I'd like to get the patch series exposed to the real world a bit as I'm fairly sure there are some issues going to crop up with this. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185844): https://lists.openembedded.org/g/openembedded-core/message/185844 Mute This Topic: https://lists.openembedded.org/mt/100683548/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] recipes/classes/scripts: Drop SRCPV usage in OE-Core
On Fri, Aug 11, 2023 at 9:49 AM Richard Purdie wrote: > > On Fri, 2023-08-11 at 14:45 +0100, Jose Quaresma wrote: > > Something to warm the user about the usage of it on existing layers > > around will be useful in my opinion. > > It is harmless but I'm sure we'll reach a point where we do something > like that. There are also docs changes likely needed and so on. > > Right now I'd like to get the patch series exposed to the real world a > bit as I'm fairly sure there are some issues going to crop up with > this. I'm preparing a similar patch for the layers I maintain. I'll put it on master-next for soaking once the bits are ready. Bruce > > Cheers, > > Richard > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185845): https://lists.openembedded.org/g/openembedded-core/message/185845 Mute This Topic: https://lists.openembedded.org/mt/100683548/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe-core][PATCH] gtk4: upgrade 4.10.4 -> 4.10.5
Overview of Changes in 4.10.5, 05-08-2023
=
* Fix ordering problems with filter model signals
* Avoid lingering resize cursors
* Fix alignment issues on sparc
* Fix a problem with CSS corner values
* Translation updates
Brazilian Portuguese
Czech
Greek
Spanish
Vietnamese
Signed-off-by: Markus Volk
---
meta/recipes-gnome/gtk+/{gtk4_4.10.4.bb => gtk4_4.10.5.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-gnome/gtk+/{gtk4_4.10.4.bb => gtk4_4.10.5.bb} (98%)
diff --git a/meta/recipes-gnome/gtk+/gtk4_4.10.4.bb
b/meta/recipes-gnome/gtk+/gtk4_4.10.5.bb
similarity index 98%
rename from meta/recipes-gnome/gtk+/gtk4_4.10.4.bb
rename to meta/recipes-gnome/gtk+/gtk4_4.10.5.bb
index 2d1e0e74a9..85fff6c61e 100644
--- a/meta/recipes-gnome/gtk+/gtk4_4.10.4.bb
+++ b/meta/recipes-gnome/gtk+/gtk4_4.10.5.bb
@@ -37,7 +37,7 @@ MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
UPSTREAM_CHECK_REGEX = "gtk-(?P\d+\.(\d*[02468])+(\.\d+)+)\.tar.xz"
SRC_URI =
"http://ftp.gnome.org/pub/gnome/sources/gtk/${MAJ_VER}/gtk-${PV}.tar.xz";
-SRC_URI[sha256sum] =
"7725400482e0685e28265e226c62847f4e73cfca9e9b416ac5838207f5377a24"
+SRC_URI[sha256sum] =
"9bd5e437e41d48e3d6a224c336b0fd3fd490036dceb8956ed74b956369af609b"
S = "${WORKDIR}/gtk-${PV}"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185846):
https://lists.openembedded.org/g/openembedded-core/message/185846
Mute This Topic: https://lists.openembedded.org/mt/100684217/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe-core][PATCH] libadwaita: upgrade 1.3.3 -> 1.3.4
=
Version 1.3.4
=
- AdwAboutWindow
- Fix :translator-credits property
- AdwComboRow
- Fix accessible role on the dropdown arrow
- AdwEntryRow
- Fix accessibility
- AdwLeaflet
- Fix back/forward mouse button handling
- AdwTabBar
- Fix accessibility
- AdwTabThumbnail
- Fix duplicate thumbnail during transitions
- Fix the transition curve
- AdwViewSwitcher
- Set correct accessible role for icons
- AdwWindowTitle
- Fix initial title visibility
- Stylesheet
- Fix .card buttons within .osd
- Fix single-item menu height
Signed-off-by: Markus Volk
---
.../libadwaita/{libadwaita_1.3.3.bb => libadwaita_1.3.4.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-gnome/libadwaita/{libadwaita_1.3.3.bb =>
libadwaita_1.3.4.bb} (86%)
diff --git a/meta/recipes-gnome/libadwaita/libadwaita_1.3.3.bb
b/meta/recipes-gnome/libadwaita/libadwaita_1.3.4.bb
similarity index 86%
rename from meta/recipes-gnome/libadwaita/libadwaita_1.3.3.bb
rename to meta/recipes-gnome/libadwaita/libadwaita_1.3.4.bb
index 8ec5258c73..2abc8d9f2f 100644
--- a/meta/recipes-gnome/libadwaita/libadwaita_1.3.3.bb
+++ b/meta/recipes-gnome/libadwaita/libadwaita_1.3.4.bb
@@ -11,7 +11,7 @@ DEPENDS = " \
inherit gnomebase gobject-introspection gi-docgen vala features_check
-SRC_URI[archive.sha256sum] =
"3fb9f6f8f570e543ab2dafb8b4b94d8b376c59ad565efadfede44557e3f3a9e1"
+SRC_URI[archive.sha256sum] =
"801ccaf3a760213b59ebb9b8185327df225049544aee68a1340b165710acb1bd"
ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
REQUIRED_DISTRO_FEATURES = "opengl"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185847):
https://lists.openembedded.org/g/openembedded-core/message/185847
Mute This Topic: https://lists.openembedded.org/mt/100684643/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v4 2/5] bitbake: cooker: add a new function to retrieve task signatures
On Wed, 2023-08-02 at 16:44 +0200, Julien Stephan wrote: > On Wed, Aug 02, 2023 at 04:24:29PM +0200, Julien Stephan wrote: > > adding a new command in cooker to compute and get task signatures > > > > this commit also add the associated command and event needed to get the > > signatures using tinfoil > > > > Signed-off-by: Julien Stephan > > --- > > bitbake/lib/bb/command.py | 6 ++ > > bitbake/lib/bb/cooker.py | 16 > > bitbake/lib/bb/event.py | 8 > > 3 files changed, 30 insertions(+) > > > > diff --git a/bitbake/lib/bb/command.py b/bitbake/lib/bb/command.py > > index a355f56c60c..12202779ac0 100644 > > --- a/bitbake/lib/bb/command.py > > +++ b/bitbake/lib/bb/command.py > > @@ -776,3 +776,9 @@ class CommandsAsync: > > bb.event.fire(bb.event.FindSigInfoResult(res), > > command.cooker.databuilder.mcdata[mc]) > > command.finishAsyncCommand() > > findSigInfo.needcache = False > > + > > +def getTaskSignatures(self, command, params): > > +res = command.cooker.getTaskSignatures(params[0], params[1]) > > +bb.event.fire(bb.event.GetTaskSignatureResult(res), > > command.cooker.data) > > +command.finishAsyncCommand() > > +getTaskSignatures.needcache = True > > diff --git a/bitbake/lib/bb/cooker.py b/bitbake/lib/bb/cooker.py > > index 11c9fa2c40d..687cdde5e6d 100644 > > --- a/bitbake/lib/bb/cooker.py > > +++ b/bitbake/lib/bb/cooker.py > > @@ -1542,6 +1542,22 @@ class BBCooker: > > > > self.idleCallBackRegister(buildFileIdle, rq) > > > > +def getTaskSignatures(self, target, task): > > +sig = [] > > + > > +taskdata, runlist = self.buildTaskData(target, "do_build", > > self.configuration.halt) > > +rq = bb.runqueue.RunQueue(self, self.data, self.recipecaches, > > taskdata, runlist) > > +rq.rqdata.prepare() > > + > > +for key in rq.rqdata.runtaskentries: > > +pn = bb.parse.siggen.tidtopn[key] > > +taskname = bb.runqueue.taskname_from_tid(key) > > +if pn in target: > > +if (task and taskname in task) or (not task): > > +rq.rqdata.prepare_task_hash(key) > > +sig.append([pn, taskname, > > rq.rqdata.get_task_unihash(key)]) > > +return sig > > + Firstly, thanks for working on this! These changes aren't simple and it means the review takes longer as we need to get this right. > I would like some feedback on this function. The goal of this function > was to be able to get a task signature (for bblock to use it, see bblock > series). The idea was: > - get the task signatures of "task" > - if "task" is empty, get the signature of all tasks > > Using buildTaskData with "do_build" task gives me almost all tasks > signatures, at least, the "normal recipe build tasks" according to the doc > [1]. > But we don't get the signatures for the "Manually called Tasks" > > At first I thought it would be good enough for bblock use case, but now > I am not so sure anymore: > * for oeqa self test, I need to have access to the same list of tasks, I think you need to query the tasks available for a recipe, remove the "nostamp" ones and then return the signatures for the rest. > but running `bitbake -c listtasks` gives *all* the tasks > * this function as is is not generic enough: we cannot get the task > signature for all the "manually called tasks" (but is that really a > problem?) > * bblock cannot lock those tasks > > So what do you think? Should I make this function more generic and > called it several times to get *all* the tasks signature? I think bitbake should internally be able to work out the nostamp ones and return a list of all of them with the nostamp ones excluded. Let me know if you need some pointers on how to do that in bitbake, it isn't entirely straightforward and I'd have to look it up. I *think* (without looking to know for sure) that the dataCache object does have the task data in it which can be looked up by target and that lists which ones are nostamp. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185848): https://lists.openembedded.org/g/openembedded-core/message/185848 Mute This Topic: https://lists.openembedded.org/mt/100506392/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v4 3/5] sstatesig: add a new info level for SIGGEN_LOCKEDSIGS_TASKSIG_CHECK
On Wed, 2023-08-02 at 16:24 +0200, Julien Stephan wrote:
> as of now, SIGGEN_LOCKEDSIGS_TASKSIG_CHECK can take 2 values: "warn" and
> "error", displaying respectively a warning or a fatal error message
> only when a task is locked and the task signature is different from
> the locked one.
>
> The "info" level is introduced to add a "note" message to remind the
> user that a recipe is locked even if the signature is equivalent to the
> locked one.
>
> The "warn" and "error" level display the warn/error message for each
> task having a mismatch of the signature. Doing this with the "info"
> level would result in very verbose output if there are several tasks
> locked, so the info level will only print once the list of recipes that
> have locked signature.
>
> Signed-off-by: Julien Stephan
> ---
> meta/lib/oe/sstatesig.py | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
> index f943df181e6..90002f67550 100644
> --- a/meta/lib/oe/sstatesig.py
> +++ b/meta/lib/oe/sstatesig.py
> @@ -104,6 +104,7 @@ class SignatureGeneratorOEBasicHashMixIn(object):
> self.lockedhashfn = {}
> self.machine = data.getVar("MACHINE")
> self.mismatch_msgs = []
> +self.lockedsigs_msgs = ""
> self.unlockedrecipes = (data.getVar("SIGGEN_UNLOCKED_RECIPES") or
> "").split()
> self.unlockedrecipes = { k: "" for k in self.unlockedrecipes }
> @@ -264,6 +265,12 @@ class SignatureGeneratorOEBasicHashMixIn(object):
> warn_msgs = []
> error_msgs = []
> sstate_missing_msgs = []
> +info_msgs = None
> +
> +if self.lockedsigs:
> +self.lockedsigs_msgs = "The following recipes have locked tasks:"
> +for pn in self.lockedsigs:
> +self.lockedsigs_msgs += " %s" % (pn)
>
> for tid in sq_data['hash']:
> if tid not in found:
How about something like:
if len(pn) > 10:
print "There are XX locked recipes (XX matching and XX not matching
parsing)"
so that in the case where lots of things are locked you get a summary
instead showing the amount of match/mismatch?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185849):
https://lists.openembedded.org/g/openembedded-core/message/185849
Mute This Topic: https://lists.openembedded.org/mt/100506393/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][mickledore][PATCH 1/1] python3-pygments: upgrade 2.14.0 -> 2.15.1
Narpat,
I don't see this in Steve's test branch:
https://git.openembedded.org/openembedded-core-contrib/log/?h=stable%2Fmickledore-nut&qt=grep&q=pygments
which is good since for mickledore, I think that you need backport only
the fix commits
because 2.15.1 has added features and build related changes. I'm not
using pygments
so I've CCed Tim to ask him to confirm that this is the right approach.
I think that since we've worked on chromium and maybe vim together, and
seen my
suggest an upgrade rather than a commit backport for dmidecode, you are
under the mistaken impression that it's generally acceptable. It's not.
Also you asked about kirkstone privately, so I'll quote that here:
"the current version of python3-pygments is 2.11.2 in LTS22 and
have tried back-porting these above fixes but, the source files
have been changed a lot and I am unable to back-port these.
So, upgrading this current version 2.11.2 -> 2.15.1 would be
acceptable or not ? "
Here as well, the answer is no, we need you to backport the fixes. If
it's simply not
practical to fix a CVE, in rare cases, you could tag the CVE with
something like:
meta/recipes-devtools/flex/flex_2.6.4.bb:CVE_STATUS[CVE-2019-6293] =
"upstream-wontfix:
or = "backporting-not-sensible"
but that's a last resort and others may rightfully object to that
conclusion.
On 2023-08-08 04:32, Narpat Mali via lists.openembedded.org wrote:
From: Narpat Mali
* Upstream has dropped setup.py
* Inherit python_setuptools_build_meta instead of setuptools3
* Add self as maintainer, as this is a dependency for python3-sphinx
Adds some new lexers, updates a few others. A handful of bug fixes.
https://github.com/pygments/pygments/blob/2.15.1/CHANGES#L6
https://github.com/pygments/pygments/blob/2.15.1/CHANGES#L18
Have cherry-picked the upgrade commit from upstream/master:
https://git.openembedded.org/openembedded-core/commit/?id=22e2569ae4843071b2b48d026ca4742351baf6d1
It's good that you amended the commit log to show where the work
came from. It seems that you dropped these two SOB lines:
Signed-off-by: Tim Orling
Signed-off-by: Richard Purdie
I'd keep them since it's part of the upstream commit.
Signed-off-by: Narpat Mali
---
meta/conf/distro/include/maintainers.inc | 2 +-
...{python3-pygments_2.14.0.bb => python3-pygments_2.15.1.bb} | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-devtools/python/{python3-pygments_2.14.0.bb =>
python3-pygments_2.15.1.bb} (76%)
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 07498a23a9..c9d790ca32 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -666,7 +666,7 @@ RECIPE_MAINTAINER:pn-python3-pyasn1 = "Tim
Orling"
RECIPE_MAINTAINER:pn-python3-pycairo = "Zang Ruochen"
RECIPE_MAINTAINER:pn-python3-pycparser = "Tim Orling"
RECIPE_MAINTAINER:pn-python3-pyelftools = "Joshua Watt"
-RECIPE_MAINTAINER:pn-python3-pygments =
"Unassigned"
+RECIPE_MAINTAINER:pn-python3-pygments = "Tim Orling"
This came from the cherry-pick but clearly you should CC Tim and
probably email
him first to see if he agrees on maintainership for the recipe in
mickledore.
../Randy
RECIPE_MAINTAINER:pn-python3-pygobject = "Zang
Ruochen"
RECIPE_MAINTAINER:pn-python3-pyopenssl = "Tim Orling"
RECIPE_MAINTAINER:pn-python3-pyparsing =
"Unassigned"
diff --git a/meta/recipes-devtools/python/python3-pygments_2.14.0.bb
b/meta/recipes-devtools/python/python3-pygments_2.15.1.bb
similarity index 76%
rename from meta/recipes-devtools/python/python3-pygments_2.14.0.bb
rename to meta/recipes-devtools/python/python3-pygments_2.15.1.bb
index 16769e9263..e0e477100e 100644
--- a/meta/recipes-devtools/python/python3-pygments_2.14.0.bb
+++ b/meta/recipes-devtools/python/python3-pygments_2.15.1.bb
@@ -4,8 +4,8 @@ HOMEPAGE ="http://pygments.org/";
LICENSE = "BSD-2-Clause"
LIC_FILES_CHKSUM ="file://LICENSE;md5=36a13c90514e2899f1eba7f41c3ee592"
-inherit setuptools3
-SRC_URI[sha256sum] =
"b3ed06a9e8ac9a9aae5a6f5dbe78a8a58655d17b43b93c078f094ddc476ae297"
+inherit python_setuptools_build_meta
+SRC_URI[sha256sum] =
"8ace4d3c1dd481894b2005f560ead0f9f19ee64fe983366be1a21e171d12775c"
DEPENDS += "\
${PYTHON_PN} \
--
# Randy MacLeod
# Wind River Linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185850):
https://lists.openembedded.org/g/openembedded-core/message/185850
Mute This Topic: https://lists.openembedded.org/mt/100618182/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][mickledore][PATCH 1/1] python3-pygments: upgrade 2.14.0 -> 2.15.1
On Fri, Aug 11, 2023 at 6:42 AM Randy MacLeod via
lists.openembedded.org
wrote:
>
> Narpat,
>
> I don't see this in Steve's test branch:
>
> https://git.openembedded.org/openembedded-core-contrib/log/?h=stable%2Fmickledore-nut&qt=grep&q=pygments
Yes, for the reasons you discuss below. I was intending to reply this
morning, but you beat me to it :-)
> which is good since for mickledore, I think that you need backport only the
> fix commits
> because 2.15.1 has added features and build related changes. I'm not using
> pygments
> so I've CCed Tim to ask him to confirm that this is the right approach.
>
> I think that since we've worked on chromium and maybe vim together, and seen
> my
> suggest an upgrade rather than a commit backport for dmidecode, you are
> under the mistaken impression that it's generally acceptable. It's not.
>
>
> Also you asked about kirkstone privately, so I'll quote that here:
>"the current version of python3-pygments is 2.11.2 in LTS22 and
> have tried back-porting these above fixes but, the source files
> have been changed a lot and I am unable to back-port these.
> So, upgrading this current version 2.11.2 -> 2.15.1 would be acceptable
> or not ? "
>
> Here as well, the answer is no, we need you to backport the fixes. If it's
> simply not
> practical to fix a CVE, in rare cases, you could tag the CVE with something
> like:
>
> meta/recipes-devtools/flex/flex_2.6.4.bb:CVE_STATUS[CVE-2019-6293] =
> "upstream-wontfix:
> or = "backporting-not-sensible"
>
> but that's a last resort and others may rightfully object to that conclusion.
Yes, same issue with a kirkstone upgrade! However your suggestion to
consider CVE_STATUS isn't possible for any of the stable branches
since we won't be backporting that feature (it is too intrusive)
So for mickledore and kirkstone it would be CVE_CHECK_IGNORE and with
dunfell CVE_CHECK_WHITELIST. And of course comment explaining the
issue and why this is an appropriate resolution.
Steve
> On 2023-08-08 04:32, Narpat Mali via lists.openembedded.org wrote:
>
> From: Narpat Mali
>
> * Upstream has dropped setup.py
> * Inherit python_setuptools_build_meta instead of setuptools3
> * Add self as maintainer, as this is a dependency for python3-sphinx
>
> Adds some new lexers, updates a few others. A handful of bug fixes.
>
> https://github.com/pygments/pygments/blob/2.15.1/CHANGES#L6
> https://github.com/pygments/pygments/blob/2.15.1/CHANGES#L18
>
> Have cherry-picked the upgrade commit from upstream/master:
> https://git.openembedded.org/openembedded-core/commit/?id=22e2569ae4843071b2b48d026ca4742351baf6d1
>
> It's good that you amended the commit log to show where the work
> came from. It seems that you dropped these two SOB lines:
>
> Signed-off-by: Tim Orling
> Signed-off-by: Richard Purdie
>
> I'd keep them since it's part of the upstream commit.
>
>
>
> Signed-off-by: Narpat Mali
> ---
> meta/conf/distro/include/maintainers.inc | 2 +-
> ...{python3-pygments_2.14.0.bb => python3-pygments_2.15.1.bb} | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
> rename meta/recipes-devtools/python/{python3-pygments_2.14.0.bb =>
> python3-pygments_2.15.1.bb} (76%)
>
> diff --git a/meta/conf/distro/include/maintainers.inc
> b/meta/conf/distro/include/maintainers.inc
> index 07498a23a9..c9d790ca32 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -666,7 +666,7 @@ RECIPE_MAINTAINER:pn-python3-pyasn1 = "Tim Orling
> "
> RECIPE_MAINTAINER:pn-python3-pycairo = "Zang Ruochen
> "
> RECIPE_MAINTAINER:pn-python3-pycparser = "Tim Orling
> "
> RECIPE_MAINTAINER:pn-python3-pyelftools = "Joshua Watt
> "
> -RECIPE_MAINTAINER:pn-python3-pygments = "Unassigned
> "
> +RECIPE_MAINTAINER:pn-python3-pygments = "Tim Orling
> "
>
> This came from the cherry-pick but clearly you should CC Tim and probably
> email
>
> him first to see if he agrees on maintainership for the recipe in mickledore.
>
>
> ../Randy
>
>
> RECIPE_MAINTAINER:pn-python3-pygobject = "Zang Ruochen
> "
> RECIPE_MAINTAINER:pn-python3-pyopenssl = "Tim Orling
> "
> RECIPE_MAINTAINER:pn-python3-pyparsing = "Unassigned
> "
> diff --git a/meta/recipes-devtools/python/python3-pygments_2.14.0.bb
> b/meta/recipes-devtools/python/python3-pygments_2.15.1.bb
> similarity index 76%
> rename from meta/recipes-devtools/python/python3-pygments_2.14.0.bb
> rename to meta/recipes-devtools/python/python3-pygments_2.15.1.bb
> index 16769e9263..e0e477100e 100644
> --- a/meta/recipes-devtools/python/python3-pygments_2.14.0.bb
> +++ b/meta/recipes-devtools/python/python3-pygments_2.15.1.bb
> @@ -4,8 +4,8 @@ HOMEPAGE = "http://pygments.org/";
> LICENSE = "BSD-2-Clause"
> LIC_FILES_CHKSUM = "file://LICENSE;md5=36a13c90514e2899f1eba7f41c3ee592"
>
> -inherit setuptools3
> -SRC_URI[sha256sum] =
> "b3ed06a9e8ac9a9aae5a6f5dbe78a8a58655d17b43b93c078f094ddc476ae297"
> +inherit python_setuptools
[OE-core] [PATCH] riscv: Add asm-offsets.s to target for on-target module compilation
From: Alexandru Moise
I wanted to build kernel modules on my riscv target,
cd /usr/src/kernel/
make scripts prepare
<...>
CC scripts/mod/devicetable-offsets.s
UPD scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
CC kernel/bounds.s
/bin/sh: line 1: arch/riscv/kernel/asm-offsets.s: No such file or directory
make[1]: *** [Kbuild:37: include/generated/asm-offsets.h] Error 1
make: *** [Makefile:1219: prepare0] Error 2
The patch just adds the asm-offsets.s file for riscv targets.
With this the prepare target succeeds:
make scripts prepare
<...>
CC kernel/bounds.s
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
LDS arch/riscv/kernel/vdso/vdso.lds
AS arch/riscv/kernel/vdso/rt_sigreturn.o
CC arch/riscv/kernel/vdso/vgettimeofday.o
AS arch/riscv/kernel/vdso/getcpu.o
AS arch/riscv/kernel/vdso/flush_icache.o
AS arch/riscv/kernel/vdso/note.o
VDSOLD arch/riscv/kernel/vdso/vdso.so.dbg
VDSOSYM include/generated/vdso-offsets.h
root@visionfive2:/usr/src/kernel
Signed-off-by: Alexandru Moise
---
meta/recipes-kernel/linux/kernel-devsrc.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 6764598d48..ec14ccf6f2 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -115,6 +115,9 @@ do_install() {
if [ -e arch/${ARCH}/kernel/vdso/vdso.lds ]; then
cp -a --parents arch/${ARCH}/kernel/vdso/vdso.lds
$kerneldir/build/
fi
+if [ -e arch/${ARCH}/kernel/asm-offsets.s ]; then
+ cp -a --parents arch/${ARCH}/kernel/asm-offsets.s
$kerneldir/build/
+fi
fi
if [ "${ARCH}" = "powerpc" ]; then
cp -a --parents arch/powerpc/kernel/vdso32/vdso32.lds
$kerneldir/build 2>/dev/null || :
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185852):
https://lists.openembedded.org/g/openembedded-core/message/185852
Mute This Topic: https://lists.openembedded.org/mt/100693249/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] riscv: Add asm-offsets.s to target for on-target module compilation
On Fri, Aug 11, 2023 at 3:30 PM wrote:
>
> From: Alexandru Moise
>
> I wanted to build kernel modules on my riscv target,
>
> cd /usr/src/kernel/
>
> make scripts prepare
> <...>
> CC scripts/mod/devicetable-offsets.s
> UPD scripts/mod/devicetable-offsets.h
> HOSTCC scripts/mod/file2alias.o
> HOSTCC scripts/mod/sumversion.o
> HOSTLD scripts/mod/modpost
> CC kernel/bounds.s
> /bin/sh: line 1: arch/riscv/kernel/asm-offsets.s: No such file or directory
> make[1]: *** [Kbuild:37: include/generated/asm-offsets.h] Error 1
> make: *** [Makefile:1219: prepare0] Error 2
>
> The patch just adds the asm-offsets.s file for riscv targets.
>
> With this the prepare target succeeds:
>
> make scripts prepare
> <...>
> CC kernel/bounds.s
> CALLscripts/checksyscalls.sh
> CALLscripts/atomic/check-atomics.sh
> LDS arch/riscv/kernel/vdso/vdso.lds
> AS arch/riscv/kernel/vdso/rt_sigreturn.o
> CC arch/riscv/kernel/vdso/vgettimeofday.o
> AS arch/riscv/kernel/vdso/getcpu.o
> AS arch/riscv/kernel/vdso/flush_icache.o
> AS arch/riscv/kernel/vdso/note.o
> VDSOLD arch/riscv/kernel/vdso/vdso.so.dbg
> VDSOSYM include/generated/vdso-offsets.h
> root@visionfive2:/usr/src/kernel
>
> Signed-off-by: Alexandru Moise
> ---
> meta/recipes-kernel/linux/kernel-devsrc.bb | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> b/meta/recipes-kernel/linux/kernel-devsrc.bb
> index 6764598d48..ec14ccf6f2 100644
> --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> @@ -115,6 +115,9 @@ do_install() {
> if [ -e arch/${ARCH}/kernel/vdso/vdso.lds ]; then
> cp -a --parents arch/${ARCH}/kernel/vdso/vdso.lds
> $kerneldir/build/
> fi
> +if [ -e arch/${ARCH}/kernel/asm-offsets.s ]; then
> + cp -a --parents arch/${ARCH}/kernel/asm-offsets.s
> $kerneldir/build/
> +fi
LGTM
> fi
> if [ "${ARCH}" = "powerpc" ]; then
> cp -a --parents arch/powerpc/kernel/vdso32/vdso32.lds
> $kerneldir/build 2>/dev/null || :
> --
> 2.41.0
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185853):
https://lists.openembedded.org/g/openembedded-core/message/185853
Mute This Topic: https://lists.openembedded.org/mt/100693249/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone][PATCH] Fix kirkstone dmidedecode smbios3_decode
From: "Lau, Karn Jye"
Recent CVE fixes in kirkstone dmidecode broke it
functionality, this issue is only observed in kirkstone
version of dmidecode(v3.3).Update smbios3_decode to address
the broken functionality.
Signed-off-by: Lau, Karn Jye
---
...mbios3_decode-in-kirkstone-dmidecode.patch | 125 ++
.../dmidecode/dmidecode_3.3.bb| 1 +
2 files changed, 126 insertions(+)
create mode 100644
meta/recipes-devtools/dmidecode/dmidecode/0002-Fix-smbios3_decode-in-kirkstone-dmidecode.patch
diff --git
a/meta/recipes-devtools/dmidecode/dmidecode/0002-Fix-smbios3_decode-in-kirkstone-dmidecode.patch
b/meta/recipes-devtools/dmidecode/dmidecode/0002-Fix-smbios3_decode-in-kirkstone-dmidecode.patch
new file mode 100644
index 00..00ffb90ce2
--- /dev/null
+++
b/meta/recipes-devtools/dmidecode/dmidecode/0002-Fix-smbios3_decode-in-kirkstone-dmidecode.patch
@@ -0,0 +1,125 @@
+From 8a395982d6f350d0744666cffe42c4a486656c6f Mon Sep 17 00:00:00 2001
+From: "Lau, Karn Jye"
+Date: Sat, 12 Aug 2023 08:41:58 +0800
+Subject: [PATCH 2/2] Fix smbios3_decode in kirkstone dmidecode
+
+Recent CVE fix broke dmidecode functionality,
+port upstream changes to fix smbios3_decodein
+function.
+
+Reference:https://github.com/mirror/dmidecode/commit/39b2dd7b6ab719b920e96ed832cfb4bdd664e808
+
+Signed-off-by: Lau, Karn Jye
+---
+ dmidecode.c | 81 +++--
+ 1 file changed, 79 insertions(+), 2 deletions(-)
+
+diff --git a/dmidecode.c b/dmidecode.c
+index f826f6c..91e1a32 100644
+--- a/dmidecode.c
b/dmidecode.c
+@@ -3514,6 +3514,72 @@ static const char *dmi_power_supply_range_switching(u8
code)
+ return out_of_spec;
+ }
+
++/* Allocates a buffer for the table, must be freed by the caller */
++static u8 *dmi_table_get(off_t base, u32 *len, u16 num, u32 ver,
++ const char *devmem, u32 flags)
++{
++ u8 *buf;
++
++ if (ver > SUPPORTED_SMBIOS_VER && !(opt.flags & FLAG_QUIET))
++ {
++ pr_comment("SMBIOS implementations newer than version %u.%u.%u
are not",
++ SUPPORTED_SMBIOS_VER >> 16,
++ (SUPPORTED_SMBIOS_VER >> 8) & 0xFF,
++ SUPPORTED_SMBIOS_VER & 0xFF);
++ pr_comment("fully supported by this version of dmidecode.");
++ }
++
++ if (!(opt.flags & FLAG_QUIET))
++ {
++ if (opt.type == NULL)
++ {
++ if (num)
++ pr_info("%u structures occupying %u bytes.",
++ num, *len);
++ if (!(opt.flags & FLAG_FROM_DUMP))
++ pr_info("Table at 0x%08llX.",
++ (unsigned long long)base);
++ }
++ pr_sep();
++ }
++
++ if ((flags & FLAG_NO_FILE_OFFSET) || (opt.flags & FLAG_FROM_DUMP))
++ {
++ /*
++ * When reading from sysfs or from a dump file, the file may be
++ * shorter than announced. For SMBIOS v3 this is expcted, as we
++ * only know the maximum table size, not the actual table size.
++ * For older implementations (and for SMBIOS v3 too), this
++ * would be the result of the kernel truncating the table on
++ * parse error.
++ */
++ size_t size = *len;
++ buf = read_file(flags & FLAG_NO_FILE_OFFSET ? 0 : base,
++ &size, devmem);
++ if (!(opt.flags & FLAG_QUIET) && num && size != (size_t)*len)
++ {
++ fprintf(stderr, "Wrong DMI structures length: %u bytes "
++ "announced, only %lu bytes available.\n",
++ *len, (unsigned long)size);
++ }
++ *len = size;
++ }
++ else
++ buf = mem_chunk(base, *len, devmem);
++
++ if (buf == NULL)
++ {
++ fprintf(stderr, "Failed to read table, sorry.\n");
++#ifndef USE_MMAP
++ if (!(flags & FLAG_NO_FILE_OFFSET))
++ fprintf(stderr,
++ "Try compiling dmidecode with -DUSE_MMAP.\n");
++#endif
++ }
++
++ return buf;
++}
++
+ /*
+ * 7.41 Additional Information (Type 40)
+ *
+@@ -5428,8 +5494,11 @@ static int smbios3_decode(u8 *buf, size_t buf_len,
const char *devmem, u32 flags
+ return 0;
+ }
+
+- dmi_table(((off_t)offset.h << 32) | offset.l,
+-DWORD(buf + 0x0C), 0, ver, devmem, flags | FLAG_STOP_AT_EOT);
++ /* Maximum length, may get trimmed */
++
++len = DWORD(buf + 0x0C);
++
++table = dmi_table_get(((off_t)offset.h << 32) | offset.l, &len, 0,
ver,devmem, flags | FLAG_STOP_AT_EOT);
+
+ if (opt.flags & FLAG_DUMP_BIN)
+ {
+@@ -5440,6 +5509,14 @@ static int smbios3_decode(u8 *buf, size
