[OE-core][PATCH] linux-firmware: add a package for ath12k firmware
From: Bartosz Golaszewski
Add the firmware package for the ATH12K module.
Signed-off-by: Bartosz Golaszewski
---
.../linux-firmware/linux-firmware_20240312.bb | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
index ff79bb9b33..53851b58fe 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
@@ -322,7 +322,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
${PN}-cnm-license ${PN}-cnm \
${PN}-atheros-license ${PN}-ar5523 ${PN}-ar9170 ${PN}-ath6k
${PN}-ath9k ${PN}-ath3k \
${PN}-carl9170 \
- ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k
${PN}-ath11k ${PN}-qca \
+ ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k
${PN}-ath11k ${PN}-ath12k ${PN}-qca \
\
${PN}-imx-sdma-license ${PN}-imx-sdma-imx6q ${PN}-imx-sdma-imx7d \
\
@@ -487,6 +487,10 @@ FILES:${PN}-ath11k = " \
${nonarch_base_libdir}/firmware/ath11k \
"
+FILES:${PN}-ath12k = " \
+ ${nonarch_base_libdir}/firmware/ath12k \
+"
+
FILES:${PN}-qca = " \
${nonarch_base_libdir}/firmware/qca \
"
@@ -494,6 +498,7 @@ FILES:${PN}-qca = " \
RDEPENDS:${PN}-ar3k += "${PN}-ar3k-license ${PN}-atheros-license"
RDEPENDS:${PN}-ath10k += "${PN}-ath10k-license"
RDEPENDS:${PN}-ath11k += "${PN}-ath10k-license"
+RDEPENDS:${PN}-ath12k += "${PN}-ath10k-license"
RDEPENDS:${PN}-qca += "${PN}-ath10k-license"
# For ralink
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198582):
https://lists.openembedded.org/g/openembedded-core/message/198582
Mute This Topic: https://lists.openembedded.org/mt/105666734/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][dunfell 11/12] linux-firmware: upgrade 20231211 -> 20240220
On Tue, Mar 26, 2024 at 11:56 AM Bartosz Golaszewski wrote:
>
> On Wed, Mar 20, 2024 at 5:44 PM Steve Sakoman wrote:
> >
> > From: Alexander Kanavin
> >
> > License-Update: additional files
> >
> > Signed-off-by: Alexander Kanavin
> > Signed-off-by: Richard Purdie
> > (cherry picked from commit add81ef0299ea5260f9bdc59ffc8f5cc0e74276f)
> > Signed-off-by: Steve Sakoman
> > ---
> > ...{linux-firmware_20231211.bb => linux-firmware_20240220.bb} | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> > rename meta/recipes-kernel/linux-firmware/{linux-firmware_20231211.bb =>
> > linux-firmware_20240220.bb} (99%)
> >
> > diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> > b/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
> > similarity index 99%
> > rename from meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> > rename to meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
> > index 3f201d853f..873ba9cdf0 100644
> > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
> > @@ -134,7 +134,7 @@ LIC_FILES_CHKSUM =
> > "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
> > "
> > # WHENCE checksum is defined separately to ease overriding it if
> > # class-devupstream is selected.
> > -WHENCE_CHKSUM = "3113c4ea08e5171555f3bf49eceb5b07"
> > +WHENCE_CHKSUM = "a344e6c28970fc7daafa81c10247aeb6"
> >
> > # These are not common licenses, set NO_GENERIC_LICENSE for them
> > # so that the license files will be copied from fetched source
> > @@ -212,7 +212,7 @@ SRC_URI:class-devupstream =
> > "git://git.kernel.org/pub/scm/linux/kernel/git/firmw
> > # Pin this to the 20220509 release, override this in local.conf
> > SRCREV:class-devupstream ?= "b19cbdca78ab2adfd210c91be15a22568e8b8cae"
> >
> > -SRC_URI[sha256sum] =
> > "96af7e4b5eabd37869cdb3dcbb7ab36911106d39b76e799fa1caab16a9dbe8bb"
> > +SRC_URI[sha256sum] =
> > "bf0f239dc0801e9d6bf5d5fb3e2f549575632cf4688f4348184199cb02c2bcd7"
> >
> > inherit allarch
> >
> > --
> > 2.34.1
> >
> >
>
> I already sent a patch upgrading linux-firmware to the most recent tag[1].
>
> Bart
>
> [1] https://lore.kernel.org/all/20240314100610.21815-1-b...@bgdev.pl/T/
Ah, nevermind, I didn't see this is for dunfell.
Bart
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197533):
https://lists.openembedded.org/g/openembedded-core/message/197533
Mute This Topic: https://lists.openembedded.org/mt/105048447/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][dunfell 11/12] linux-firmware: upgrade 20231211 -> 20240220
On Wed, Mar 20, 2024 at 5:44 PM Steve Sakoman wrote:
>
> From: Alexander Kanavin
>
> License-Update: additional files
>
> Signed-off-by: Alexander Kanavin
> Signed-off-by: Richard Purdie
> (cherry picked from commit add81ef0299ea5260f9bdc59ffc8f5cc0e74276f)
> Signed-off-by: Steve Sakoman
> ---
> ...{linux-firmware_20231211.bb => linux-firmware_20240220.bb} | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-kernel/linux-firmware/{linux-firmware_20231211.bb =>
> linux-firmware_20240220.bb} (99%)
>
> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> b/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
> similarity index 99%
> rename from meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> rename to meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
> index 3f201d853f..873ba9cdf0 100644
> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
> @@ -134,7 +134,7 @@ LIC_FILES_CHKSUM =
> "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
> "
> # WHENCE checksum is defined separately to ease overriding it if
> # class-devupstream is selected.
> -WHENCE_CHKSUM = "3113c4ea08e5171555f3bf49eceb5b07"
> +WHENCE_CHKSUM = "a344e6c28970fc7daafa81c10247aeb6"
>
> # These are not common licenses, set NO_GENERIC_LICENSE for them
> # so that the license files will be copied from fetched source
> @@ -212,7 +212,7 @@ SRC_URI:class-devupstream =
> "git://git.kernel.org/pub/scm/linux/kernel/git/firmw
> # Pin this to the 20220509 release, override this in local.conf
> SRCREV:class-devupstream ?= "b19cbdca78ab2adfd210c91be15a22568e8b8cae"
>
> -SRC_URI[sha256sum] =
> "96af7e4b5eabd37869cdb3dcbb7ab36911106d39b76e799fa1caab16a9dbe8bb"
> +SRC_URI[sha256sum] =
> "bf0f239dc0801e9d6bf5d5fb3e2f549575632cf4688f4348184199cb02c2bcd7"
>
> inherit allarch
>
> --
> 2.34.1
>
>
I already sent a patch upgrading linux-firmware to the most recent tag[1].
Bart
[1] https://lore.kernel.org/all/20240314100610.21815-1-b...@bgdev.pl/T/
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197532):
https://lists.openembedded.org/g/openembedded-core/message/197532
Mute This Topic: https://lists.openembedded.org/mt/105048447/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] linux-firmware: add a package for ath12k firmware
From: Bartosz Golaszewski
Add the firmware package for the ATH12K module.
Signed-off-by: Bartosz Golaszewski
---
.../linux-firmware/linux-firmware_20240312.bb | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
index 390d10d2f3..4961b43ad5 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
@@ -320,7 +320,8 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
${PN}-cnm-license ${PN}-cnm \
${PN}-atheros-license ${PN}-ar5523 ${PN}-ar9170 ${PN}-ath6k
${PN}-ath9k ${PN}-ath3k \
${PN}-gplv2-license ${PN}-carl9170 \
- ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k
${PN}-ath11k ${PN}-qca \
+ ${PN}-ar3k-license ${PN}-ar3k \
+ ${PN}-ath10k-license ${PN}-ath10k ${PN}-ath11k ${PN}-ath12k
${PN}-qca \
\
${PN}-imx-sdma-license ${PN}-imx-sdma-imx6q ${PN}-imx-sdma-imx7d \
\
@@ -488,6 +489,10 @@ FILES:${PN}-ath11k = " \
${nonarch_base_libdir}/firmware/ath11k \
"
+FILES:${PN}-ath12k = " \
+ ${nonarch_base_libdir}/firmware/ath12k \
+"
+
FILES:${PN}-qca = " \
${nonarch_base_libdir}/firmware/qca \
"
@@ -495,6 +500,7 @@ FILES:${PN}-qca = " \
RDEPENDS:${PN}-ar3k += "${PN}-ar3k-license ${PN}-atheros-license"
RDEPENDS:${PN}-ath10k += "${PN}-ath10k-license"
RDEPENDS:${PN}-ath11k += "${PN}-ath10k-license"
+RDEPENDS:${PN}-ath12k += "${PN}-ath10k-license"
RDEPENDS:${PN}-qca += "${PN}-ath10k-license"
# For ralink
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197102):
https://lists.openembedded.org/g/openembedded-core/message/197102
Mute This Topic: https://lists.openembedded.org/mt/104923522/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] linux-firmware: update to 20240312
From: Bartosz Golaszewski
Update the linux-firmware recipe to the most recent upstream tag.
Signed-off-by: Bartosz Golaszewski
---
...{linux-firmware_20240220.bb => linux-firmware_20240312.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-kernel/linux-firmware/{linux-firmware_20240220.bb =>
linux-firmware_20240312.bb} (99%)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
similarity index 99%
rename from meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
rename to meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
index 1fd44f4d53..390d10d2f3 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
@@ -155,7 +155,7 @@ LIC_FILES_CHKSUM =
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
"
# WHENCE checksum is defined separately to ease overriding it if
# class-devupstream is selected.
-WHENCE_CHKSUM = "a344e6c28970fc7daafa81c10247aeb6"
+WHENCE_CHKSUM = "514da1cd8b363373030f0c16749feb8d"
# These are not common licenses, set NO_GENERIC_LICENSE for them
# so that the license files will be copied from fetched source
@@ -243,7 +243,7 @@ SRC_URI:class-devupstream =
"git://git.kernel.org/pub/scm/linux/kernel/git/firmw
# Pin this to the 20220509 release, override this in local.conf
SRCREV:class-devupstream ?= "b19cbdca78ab2adfd210c91be15a22568e8b8cae"
-SRC_URI[sha256sum] =
"bf0f239dc0801e9d6bf5d5fb3e2f549575632cf4688f4348184199cb02c2bcd7"
+SRC_URI[sha256sum] =
"b2327a54ad1897c828008caf63af5ee15469ba723a5016be58f2b44f07bd4b94"
inherit allarch
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197101):
https://lists.openembedded.org/g/openembedded-core/message/197101
Mute This Topic: https://lists.openembedded.org/mt/104923521/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 06/20] python3-libfdt: new package
On Thu, May 18, 2023 at 6:56 PM Ross Burton wrote: > > > > > On 17 May 2023, at 17:32, Bruce Ashfield via lists.openembedded.org > > wrote: > > > > I'm not sure if you saw the old threads on this, but we went through this > > binding in detail in february: > > > > See the series from TrevorW: > > > > [PATCH v3 1/4] dtc: version bump and add python wrapper > > > > The pypi releases of libfdt bindings are not kept in sync with the dtc > > releases and rarely update. Not that they change a lot, but that is > > still the case. > > > > The suggestion for the bindings is the same, they'd be better of built > > from dtc, versus using pypi. > > > > There may be some issues remaining with the build, as Trevor hasn't > > updated his series in a while now. > > Agreed - that series needs to be resurrected as it’s the canonical source of > the bindings. > > Ross > > In this case I propose to just drop patches 06/20 and 07/20 from this series for now when applying. Bart -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181547): https://lists.openembedded.org/g/openembedded-core/message/181547 Mute This Topic: https://lists.openembedded.org/mt/98944002/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 01/20] python3-async: add missing run-time dependencies
On Wed, May 17, 2023 at 6:15 PM Trevor Gamblin wrote:
>
>
> On 2023-05-17 04:06, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Add missing RDEPENDS for this package.
> >
> > Signed-off-by: Bartosz Golaszewski
> > ---
> > meta/recipes-devtools/python/python-async.inc | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-devtools/python/python-async.inc
> > b/meta/recipes-devtools/python/python-async.inc
> > index fde864601c..53f8d79361 100644
> > --- a/meta/recipes-devtools/python/python-async.inc
> > +++ b/meta/recipes-devtools/python/python-async.inc
> > @@ -9,6 +9,9 @@ inherit pypi
> > SRC_URI[md5sum] = "9b06b5997de2154f3bc0273f80bcef6b"
> > SRC_URI[sha256sum] =
> > "ac6894d876e45878faae493b0cf61d0e28ec417334448ac0a6ea2229d8343051"
> >
> > -RDEPENDS:${PN} += "${PYTHON_PN}-threading"
> > +RDEPENDS:${PN} += " \
> > +python3-logging \
> > +python3-threading \
> > +"
> >
> > BBCLASSEXTEND = "native nativesdk"
>
> This is an OK change, but the recipe should arguably be removed from
> oe-core instead, given that it 1) hasn't been updated in 9 years and has
> been abandoned in favor of alternatives by the maintainer, and 2)
> doesn't appear to be a dependency for anything else in oe-core or
> meta-openembedded.
>
> - Trevor
>
I admit I didn't really pay attention to how well maintained the
packages are, just fixed their run-time dependencies. I have nothing
against removing this. This is precisely why I split the series into
individual patches - some may be skipped while others go upstream.
Bart
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181499):
https://lists.openembedded.org/g/openembedded-core/message/181499
Mute This Topic: https://lists.openembedded.org/mt/98943997/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 20/20] python3-manifest: turtle: new package
From: Bartosz Golaszewski
Extend the manifest with definitions for the turtle package from the
Python standard library. Currently this package cannot be imported at
run-time because python3-misc doesn't pull the required dependencies.
Signed-off-by: Bartosz Golaszewski
---
.../python/python3/python3-manifest.json | 12
1 file changed, 12 insertions(+)
diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json
b/meta/recipes-devtools/python/python3/python3-manifest.json
index d368b162bd..766f083ae4 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1236,6 +1236,18 @@
"${libdir}/python${PYTHON_MAJMIN}/tomllib/_parser.*.pyc"
]
},
+"turtle": {
+"summary": "Turtle graphics is a popular way for introducing
programming to kids.",
+"rdepends": [
+"tkinter"
+],
+"files": [
+"${libdir}/python${PYTHON_MAJMIN}/turtle.py"
+],
+"cached": [
+"${libdir}/python${PYTHON_MAJMIN}/__pycache__/turtle.*.pyc"
+]
+ },
"unittest": {
"summary": "Python unit testing framework",
"rdepends": [
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181469):
https://lists.openembedded.org/g/openembedded-core/message/181469
Mute This Topic: https://lists.openembedded.org/mt/98944018/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 19/20] python3-manifest: zipapp: new package
From: Bartosz Golaszewski
Extend the manifest with definitions for the zipapp package from the
Python standard library. Currently this package cannot be imported at
run-time because python3-misc doesn't pull the required dependencies.
Signed-off-by: Bartosz Golaszewski
---
.../python/python3/python3-manifest.json| 13 +
1 file changed, 13 insertions(+)
diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json
b/meta/recipes-devtools/python/python3/python3-manifest.json
index f60c83d76b..d368b162bd 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1321,6 +1321,19 @@
],
"cached": []
},
+"zipapp": {
+"summary": "Tools to manage the creation of zip files containing
Python code",
+"rdepends": [
+"compression",
+"core"
+],
+"files": [
+"${libdir}/python${PYTHON_MAJMIN}/zipapp.py"
+],
+"cached": [
+"${libdir}/python${PYTHON_MAJMIN}/__pycache__/zipapp.*.pyc"
+]
+},
"zoneinfo": {
"summary": "IANA time zone support",
"rdepends": [
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181468):
https://lists.openembedded.org/g/openembedded-core/message/181468
Mute This Topic: https://lists.openembedded.org/mt/98944017/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 17/20] python3-pygobject: add missing run-time dependencies
From: Bartosz Golaszewski
Add missing RDEPENDS for this package.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-pygobject_3.44.1.bb | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python3-pygobject_3.44.1.bb
b/meta/recipes-devtools/python/python3-pygobject_3.44.1.bb
index 8bfff43560..a5eecd33aa 100644
--- a/meta/recipes-devtools/python/python3-pygobject_3.44.1.bb
+++ b/meta/recipes-devtools/python/python3-pygobject_3.44.1.bb
@@ -24,7 +24,10 @@ S = "${WORKDIR}/${SRCNAME}-${PV}"
PACKAGECONFIG ??= "${@bb.utils.contains_any('DISTRO_FEATURES', [ 'directfb',
'wayland', 'x11' ], 'cairo', '', d)}"
-RDEPENDS:${PN} += "python3-pkgutil"
+RDEPENDS:${PN} += " \
+python3-io \
+python3-pkgutil \
+"
# python3-pycairo is checked on configuration -> DEPENDS
# we don't link against python3-pycairo -> RDEPENDS
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181466):
https://lists.openembedded.org/g/openembedded-core/message/181466
Mute This Topic: https://lists.openembedded.org/mt/98944015/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 18/20] python3-manifest: cgitb: new package
From: Bartosz Golaszewski
Extend the manifest with definitions for the cgitb package from the
Python standard library. Currently this package cannot be imported at
run-time because python3-misc doesn't pull the required dependencies.
Signed-off-by: Bartosz Golaszewski
---
.../python/python3/python3-manifest.json| 17 +
1 file changed, 17 insertions(+)
diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json
b/meta/recipes-devtools/python/python3/python3-manifest.json
index f278b18775..f60c83d76b 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -152,6 +152,23 @@
"${libdir}/python${PYTHON_MAJMIN}/__pycache__/wave.*.pyc"
]
},
+"cgitb": {
+"summary": "Special exception handler for Python scripts",
+"rdepends": [
+"core",
+"crypt",
+"html",
+"io",
+"math",
+"pydoc"
+],
+"files": [
+"${libdir}/python${PYTHON_MAJMIN}/cgitb.py"
+],
+"cached": [
+"${libdir}/python${PYTHON_MAJMIN}/__pycache__/cgitb.*.pyc"
+]
+},
"codecs": {
"summary": "Python codec",
"rdepends": [
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181467):
https://lists.openembedded.org/g/openembedded-core/message/181467
Mute This Topic: https://lists.openembedded.org/mt/98944016/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 16/20] python3-pycryptodome: add missing run-time dependencies
From: Bartosz Golaszewski
Add missing RDEPENDS for this package.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python-pycryptodome.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/python/python-pycryptodome.inc
b/meta/recipes-devtools/python/python-pycryptodome.inc
index 86d7f261af..8d9b6d911e 100644
--- a/meta/recipes-devtools/python/python-pycryptodome.inc
+++ b/meta/recipes-devtools/python/python-pycryptodome.inc
@@ -10,6 +10,8 @@ inherit pypi
PYPI_PACKAGE_EXT = "tar.gz"
RDEPENDS:${PN} += " \
+python3-cffi \
+python3-ctypes \
python3-io \
python3-math \
"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181465):
https://lists.openembedded.org/g/openembedded-core/message/181465
Mute This Topic: https://lists.openembedded.org/mt/98944013/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 14/20] python3-pyproject-hooks: add missing run-time dependencies
From: Bartosz Golaszewski
Add missing RDEPENDS for this package.
Signed-off-by: Bartosz Golaszewski
---
.../recipes-devtools/python/python3-pyproject-hooks_1.0.0.bb | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python3-pyproject-hooks_1.0.0.bb
b/meta/recipes-devtools/python/python3-pyproject-hooks_1.0.0.bb
index e3893d51cb..c3f1fb75ed 100644
--- a/meta/recipes-devtools/python/python3-pyproject-hooks_1.0.0.bb
+++ b/meta/recipes-devtools/python/python3-pyproject-hooks_1.0.0.bb
@@ -14,7 +14,10 @@ BBCLASSEXTEND = "native nativesdk"
# Bootstrap the native build
DEPENDS:remove:class-native = "python3-build-native"
-RDEPENDS:${PN} += "python3-json"
+RDEPENDS:${PN} += " \
+python3-io \
+python3-json \
+"
do_compile:class-native () {
python_flit_core_do_manual_build
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181464):
https://lists.openembedded.org/g/openembedded-core/message/181464
Mute This Topic: https://lists.openembedded.org/mt/98944012/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 15/20] python3-pycryptodome: don't use PYTHON_PN
From: Bartosz Golaszewski
We no longer support python2. Drop PYTHON_PN and use python3 explicitly.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python-pycryptodome.inc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/python/python-pycryptodome.inc
b/meta/recipes-devtools/python/python-pycryptodome.inc
index 29fe80d224..86d7f261af 100644
--- a/meta/recipes-devtools/python/python-pycryptodome.inc
+++ b/meta/recipes-devtools/python/python-pycryptodome.inc
@@ -10,12 +10,12 @@ inherit pypi
PYPI_PACKAGE_EXT = "tar.gz"
RDEPENDS:${PN} += " \
-${PYTHON_PN}-io \
-${PYTHON_PN}-math \
+python3-io \
+python3-math \
"
RDEPENDS:${PN}-tests += " \
-${PYTHON_PN}-unittest \
+python3-unittest \
"
PACKAGES =+ "${PN}-tests"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181463):
https://lists.openembedded.org/g/openembedded-core/message/181463
Mute This Topic: https://lists.openembedded.org/mt/98944011/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 13/20] python3-setuptools-rust: fix RDEPENDS and allow target build
From: Bartosz Golaszewski
Cargo and rustc can now be built for the target architecture. There's no
reason to limit the setuptools rust extensions to native build only so
make the RDEPENDS global. Also: add the missing ones.
Signed-off-by: Bartosz Golaszewski
---
.../python/python3-setuptools-rust_1.5.2.bb | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-devtools/python/python3-setuptools-rust_1.5.2.bb
b/meta/recipes-devtools/python/python3-setuptools-rust_1.5.2.bb
index 502967fd20..01e29cc6d8 100644
--- a/meta/recipes-devtools/python/python3-setuptools-rust_1.5.2.bb
+++ b/meta/recipes-devtools/python/python3-setuptools-rust_1.5.2.bb
@@ -18,13 +18,16 @@ inherit cargo pypi python_setuptools_build_meta
DEPENDS += "python3-setuptools-scm-native python3-wheel-native"
-RDEPENDS:${PN}:class-native += " \
-python3-semantic-version-native \
-python3-setuptools-native \
-python3-setuptools-scm-native \
-python3-toml-native \
-python3-typing-extensions-native \
-python3-wheel-native \
+RDEPENDS:${PN} += " \
+python3-distutils \
+python3-json \
+python3-semantic-version \
+python3-setuptools \
+python3-setuptools-scm \
+python3-shell \
+python3-toml \
+python3-typing-extensions \
+python3-wheel \
"
BBCLASSEXTEND = "native"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181462):
https://lists.openembedded.org/g/openembedded-core/message/181462
Mute This Topic: https://lists.openembedded.org/mt/98944010/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 12/20] python3-sphinx-rtd-theme: add missing run-time dependencies
From: Bartosz Golaszewski
Add missing RDEPENDS for this package.
Remove DEPENDS as this package doesn't really have any.
Signed-off-by: Bartosz Golaszewski
---
.../python/python3-sphinx-rtd-theme_1.2.0.bb | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python3-sphinx-rtd-theme_1.2.0.bb
b/meta/recipes-devtools/python/python3-sphinx-rtd-theme_1.2.0.bb
index e8a422b2e7..d9cd18e0ed 100644
--- a/meta/recipes-devtools/python/python3-sphinx-rtd-theme_1.2.0.bb
+++ b/meta/recipes-devtools/python/python3-sphinx-rtd-theme_1.2.0.bb
@@ -6,7 +6,10 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=a1db7d4ef426c2935227264e1d4ae8f9 \
file://OFL-License.txt;md5=4534c22e0147eadb6828bd9fe86d4868 \
file://Apache-License-2.0.txt;md5=8a75796f0ef19c3f601d69857f5a9a5b"
-DEPENDS = "python3-sphinx"
+RDEPENDS:${PN} += " \
+python3-compile \
+python3-sphinx \
+"
PYPI_PACKAGE = "sphinx_rtd_theme"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181461):
https://lists.openembedded.org/g/openembedded-core/message/181461
Mute This Topic: https://lists.openembedded.org/mt/98944009/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 11/20] python3-installer: add missing run-time dependencies
From: Bartosz Golaszewski
Add missing RDEPENDS for this package.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-installer_0.7.0.bb | 6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/recipes-devtools/python/python3-installer_0.7.0.bb
b/meta/recipes-devtools/python/python3-installer_0.7.0.bb
index d7f1e79a5c..9429705b1f 100644
--- a/meta/recipes-devtools/python/python3-installer_0.7.0.bb
+++ b/meta/recipes-devtools/python/python3-installer_0.7.0.bb
@@ -15,6 +15,12 @@ inherit pypi python_flit_core
# Bootstrap the native build
DEPENDS:remove:class-native = "python3-build-native python3-installer-native"
+RDEPENDS:${PN} += " \
+python3-compile \
+python3-compression \
+python3-netclient \
+"
+
INSTALL_WHEEL_COMPILE_BYTECODE:class-native = "--no-compile-bytecode"
do_compile:class-native () {
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181460):
https://lists.openembedded.org/g/openembedded-core/message/181460
Mute This Topic: https://lists.openembedded.org/mt/98944008/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 10/20] python3-pathspec: add missing run-time dependencies
From: Bartosz Golaszewski
Add missing RDEPENDS for this package.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-pathspec_0.11.1.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/python/python3-pathspec_0.11.1.bb
b/meta/recipes-devtools/python/python3-pathspec_0.11.1.bb
index f49bf080e9..79f03da984 100644
--- a/meta/recipes-devtools/python/python3-pathspec_0.11.1.bb
+++ b/meta/recipes-devtools/python/python3-pathspec_0.11.1.bb
@@ -9,3 +9,5 @@ SRC_URI[sha256sum] =
"2798de800fa92780e33acca925945e9a19a133b715067cf165b8866c15
inherit pypi setuptools3
BBCLASSEXTEND = "native nativesdk"
+
+RDEPENDS:${PN} += "python3-profile"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181459):
https://lists.openembedded.org/g/openembedded-core/message/181459
Mute This Topic: https://lists.openembedded.org/mt/98944007/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 09/20] python3-tomli: add missing run-time dependencies
From: Bartosz Golaszewski
Add missing RDEPENDS for this package.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-tomli_2.0.1.bb | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-devtools/python/python3-tomli_2.0.1.bb
b/meta/recipes-devtools/python/python3-tomli_2.0.1.bb
index 6118a6a9c3..9401ed897f 100644
--- a/meta/recipes-devtools/python/python3-tomli_2.0.1.bb
+++ b/meta/recipes-devtools/python/python3-tomli_2.0.1.bb
@@ -11,3 +11,8 @@ inherit pypi python_flit_core
SRC_URI[sha256sum] =
"de526c12914f0c550d15924c62d72abc48d6fe7364aa87328337a31007fe8a4f"
BBCLASSEXTEND = "native nativesdk"
+
+RDEPENDS:${PN} += " \
+python3-datetime \
+python3-stringold \
+"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181458):
https://lists.openembedded.org/g/openembedded-core/message/181458
Mute This Topic: https://lists.openembedded.org/mt/98944005/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 08/20] python3-hypothesis: fix run-time dependencies
From: Bartosz Golaszewski
The main hypothesis module depends on pytest already so move it to
global RDEPENDS from ptest-specific ones.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-hypothesis_6.71.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python3-hypothesis_6.71.0.bb
b/meta/recipes-devtools/python/python3-hypothesis_6.71.0.bb
index 8ec885fabf..15f4090c6d 100644
--- a/meta/recipes-devtools/python/python3-hypothesis_6.71.0.bb
+++ b/meta/recipes-devtools/python/python3-hypothesis_6.71.0.bb
@@ -20,13 +20,13 @@ RDEPENDS:${PN} += " \
python3-compression \
python3-core \
python3-json \
+python3-pytest \
python3-sortedcontainers \
python3-statistics \
python3-unittest \
"
RDEPENDS:${PN}-ptest += " \
-${PYTHON_PN}-pytest \
${PYTHON_PN}-unittest-automake-output \
"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181457):
https://lists.openembedded.org/g/openembedded-core/message/181457
Mute This Topic: https://lists.openembedded.org/mt/98944004/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 07/20] python3-dtschema: add missing run-time dependencies
From: Bartosz Golaszewski
Add missing RDEPENDS for this package.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-dtschema_2023.4.bb | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python3-dtschema_2023.4.bb
b/meta/recipes-devtools/python/python3-dtschema_2023.4.bb
index f87563facd..e5a18b0649 100644
--- a/meta/recipes-devtools/python/python3-dtschema_2023.4.bb
+++ b/meta/recipes-devtools/python/python3-dtschema_2023.4.bb
@@ -10,6 +10,11 @@ PYPI_PACKAGE = "dtschema"
SRC_URI[sha256sum] =
"6daefb8f54403b4d82961b3346571200571747ab01950fd36c1f69950fa7a8cf"
DEPENDS += "python3-setuptools-scm-native"
-RDEPENDS:${PN} += "python3-ruamel-yaml python3-jsonschema python3-rfc3987"
+RDEPENDS:${PN} += " \
+python3-jsonschema \
+python3-libfdt \
+python3-rfc3987 \
+python3-ruamel-yaml \
+"
BBCLASSEXTEND = "native nativesdk"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181456):
https://lists.openembedded.org/g/openembedded-core/message/181456
Mute This Topic: https://lists.openembedded.org/mt/98944003/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 06/20] python3-libfdt: new package
From: Bartosz Golaszewski Add a recipe for python bindings for libfdt (spun out of upstream dtc) fetched from pypi. Signed-off-by: Bartosz Golaszewski --- .../python/python3-libfdt_1.7.0.post1.bb | 20 +++ 1 file changed, 20 insertions(+) create mode 100644 meta/recipes-devtools/python/python3-libfdt_1.7.0.post1.bb diff --git a/meta/recipes-devtools/python/python3-libfdt_1.7.0.post1.bb b/meta/recipes-devtools/python/python3-libfdt_1.7.0.post1.bb new file mode 100644 index 00..1ff3decbb9 --- /dev/null +++ b/meta/recipes-devtools/python/python3-libfdt_1.7.0.post1.bb @@ -0,0 +1,20 @@ +SUMMARY = "Python bindings for libfdt." +LICENSE = "GPL-2.0-only | BSD-2-Clause" +LIC_FILES_CHKSUM = " \ +file://BSD-2-Clause;md5=5d6306d1b08f8df623178dfd81880927 \ +file://GPL;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ +" + +inherit pypi setuptools3 + +PYPI_PACKAGE = "pylibfdt" + +SRC_URI[sha256sum] = "2d048f9f8ce9a0527d497f423dea1f1135f9811c05b009cc5d5753771c1f9ba1" + +BBCLASSEXTEND = "native nativesdk" + +DEPENDS += " \ +python3-pip-native \ +python3-setuptools-scm-native \ +swig-native \ +" -- 2.39.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181455): https://lists.openembedded.org/g/openembedded-core/message/181455 Mute This Topic: https://lists.openembedded.org/mt/98944002/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 05/20] python3-certifi: add missing run-time dependencies
From: Bartosz Golaszewski
Add missing RDEPENDS for this package.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-certifi_2022.12.7.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/python/python3-certifi_2022.12.7.bb
b/meta/recipes-devtools/python/python3-certifi_2022.12.7.bb
index dca3d26811..b2e3ec125a 100644
--- a/meta/recipes-devtools/python/python3-certifi_2022.12.7.bb
+++ b/meta/recipes-devtools/python/python3-certifi_2022.12.7.bb
@@ -12,3 +12,5 @@ SRC_URI[sha256sum] =
"35824b4c3a97115964b408844d64aa14db1cc518f6562e8d7261699d13
inherit pypi setuptools3
BBCLASSEXTEND = "native nativesdk"
+
+RDEPENDS:${PN} += "python3-io"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181454):
https://lists.openembedded.org/g/openembedded-core/message/181454
Mute This Topic: https://lists.openembedded.org/mt/98944001/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 04/20] python3-attrs: add missing run-time dependencies
From: Bartosz Golaszewski
Add missing RDEPENDS for this package.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-attrs_23.1.0.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
b/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
index ab3a08073d..314053de08 100644
--- a/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
+++ b/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
@@ -13,6 +13,7 @@ DEPENDS += " \
"
RDEPENDS:${PN}+= " \
+python3-compression \
python3-ctypes \
python3-crypt \
"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181453):
https://lists.openembedded.org/g/openembedded-core/message/181453
Mute This Topic: https://lists.openembedded.org/mt/98944000/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 03/20] python3-attrs: don't use PYTHON_PN
From: Bartosz Golaszewski
We no longer support python2. Drop PYTHON_PN and use python3 explicitly.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-attrs_23.1.0.bb | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
b/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
index 207636d62e..ab3a08073d 100644
--- a/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
+++ b/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
@@ -8,13 +8,13 @@ SRC_URI[sha256sum] =
"6279836d581513a26f1bf235f9acd333bc9115683f14f7e8fae46c98fc
inherit pypi python_hatchling
DEPENDS += " \
-${PYTHON_PN}-hatch-vcs-native \
-${PYTHON_PN}-hatch-fancy-pypi-readme-native \
+python3-hatch-vcs-native \
+python3-hatch-fancy-pypi-readme-native \
"
RDEPENDS:${PN}+= " \
-${PYTHON_PN}-ctypes \
-${PYTHON_PN}-crypt \
+python3-ctypes \
+python3-crypt \
"
BBCLASSEXTEND = "native nativesdk"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181452):
https://lists.openembedded.org/g/openembedded-core/message/181452
Mute This Topic: https://lists.openembedded.org/mt/98943999/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 00/20] python3: fix run-time dependencies
From: Bartosz Golaszewski I noticed that every now and then I import some python package into an image only to find out the recipe didn't pull in all required run-time dependencies. I would fix it whenever I noticed it but figured that I could right a script that would go over all python packages, build a minimal image and see that all its modules can be imported. The patches in this series are the result of that. Most simply add missing RDEPENDS, some are additional tweaks to recipes and the last three add new standard library packages to the manifest. These are the ones for which simply adding python3-misc would still be insufficient in terms of run-time dependencies. I plan to do the same for meta-python but this will take more time and I need to think of some automated way of updating the recipes first. Bartosz Golaszewski (20): python3-async: add missing run-time dependencies python3-attrs: unify RDEPENDS python3-attrs: don't use PYTHON_PN python3-attrs: add missing run-time dependencies python3-certifi: add missing run-time dependencies python3-libfdt: new package python3-dtschema: add missing run-time dependencies python3-hypothesis: fix run-time dependencies python3-tomli: add missing run-time dependencies python3-pathspec: add missing run-time dependencies python3-installer: add missing run-time dependencies python3-sphinx-rtd-theme: add missing run-time dependencies python3-setuptools-rust: fix RDEPENDS and allow target build python3-pyproject-hooks: add missing run-time dependencies python3-pycryptodome: don't use PYTHON_PN python3-pycryptodome: add missing run-time dependencies python3-pygobject: add missing run-time dependencies python3-manifest: cgitb: new package python3-manifest: zipapp: new package python3-manifest: turtle: new package meta/recipes-devtools/python/python-async.inc | 5 ++- .../python/python-pycryptodome.inc| 8 ++-- .../python/python3-attrs_23.1.0.bb| 15 +++ .../python/python3-certifi_2022.12.7.bb | 2 + .../python/python3-dtschema_2023.4.bb | 7 +++- .../python/python3-hypothesis_6.71.0.bb | 2 +- .../python/python3-installer_0.7.0.bb | 6 +++ .../python/python3-libfdt_1.7.0.post1.bb | 20 + .../python/python3-pathspec_0.11.1.bb | 2 + .../python/python3-pygobject_3.44.1.bb| 5 ++- .../python/python3-pyproject-hooks_1.0.0.bb | 5 ++- .../python/python3-setuptools-rust_1.5.2.bb | 17 .../python/python3-sphinx-rtd-theme_1.2.0.bb | 5 ++- .../python/python3-tomli_2.0.1.bb | 5 +++ .../python/python3/python3-manifest.json | 42 +++ 15 files changed, 121 insertions(+), 25 deletions(-) create mode 100644 meta/recipes-devtools/python/python3-libfdt_1.7.0.post1.bb -- 2.39.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181449): https://lists.openembedded.org/g/openembedded-core/message/181449 Mute This Topic: https://lists.openembedded.org/mt/98943996/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 02/20] python3-attrs: unify RDEPENDS
From: Bartosz Golaszewski
The nativesdk and target RDEPENDS are the same and there's nothing that
prohibits this package from build built for the native sysroot either.
Use the global RDEPENDS instead of per-class assignments.
While at it: order the dependencies alphabetically.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-attrs_23.1.0.bb | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
b/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
index c8e2e514a4..207636d62e 100644
--- a/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
+++ b/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
@@ -12,13 +12,9 @@ DEPENDS += " \
${PYTHON_PN}-hatch-fancy-pypi-readme-native \
"
-RDEPENDS:${PN}:class-target += " \
-${PYTHON_PN}-crypt \
+RDEPENDS:${PN}+= " \
${PYTHON_PN}-ctypes \
-"
-RDEPENDS:${PN}:class-nativesdk += " \
${PYTHON_PN}-crypt \
-${PYTHON_PN}-ctypes \
"
BBCLASSEXTEND = "native nativesdk"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181451):
https://lists.openembedded.org/g/openembedded-core/message/181451
Mute This Topic: https://lists.openembedded.org/mt/98943998/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 01/20] python3-async: add missing run-time dependencies
From: Bartosz Golaszewski
Add missing RDEPENDS for this package.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python-async.inc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python-async.inc
b/meta/recipes-devtools/python/python-async.inc
index fde864601c..53f8d79361 100644
--- a/meta/recipes-devtools/python/python-async.inc
+++ b/meta/recipes-devtools/python/python-async.inc
@@ -9,6 +9,9 @@ inherit pypi
SRC_URI[md5sum] = "9b06b5997de2154f3bc0273f80bcef6b"
SRC_URI[sha256sum] =
"ac6894d876e45878faae493b0cf61d0e28ec417334448ac0a6ea2229d8343051"
-RDEPENDS:${PN} += "${PYTHON_PN}-threading"
+RDEPENDS:${PN} += " \
+python3-logging \
+python3-threading \
+"
BBCLASSEXTEND = "native nativesdk"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181450):
https://lists.openembedded.org/g/openembedded-core/message/181450
Mute This Topic: https://lists.openembedded.org/mt/98943997/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 5/5] python3-build: add missing run-time dependencies
From: Bartosz Golaszewski
python3-build has several run-time dependencies that are missing from
the recipe. This makes it impossible to use the module in self-hosted
images. Add missing RDEPENDS.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-build_0.10.0.bb | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python3-build_0.10.0.bb
b/meta/recipes-devtools/python/python3-build_0.10.0.bb
index 770a32023d..b446fa391d 100644
--- a/meta/recipes-devtools/python/python3-build_0.10.0.bb
+++ b/meta/recipes-devtools/python/python3-build_0.10.0.bb
@@ -18,6 +18,15 @@ do_compile:prepend:class-native() {
export PYTHONPATH="${S}/src"
}
-RDEPENDS:${PN} += "python3-packaging python3-pyproject-hooks"
+RDEPENDS:${PN} += " \
+python3-compression \
+python3-difflib \
+python3-ensurepip \
+python3-logging \
+python3-packaging \
+python3-pyproject-hooks \
+python3-tomllib \
+python3-venv \
+"
BBCLASSEXTEND = "native nativesdk"
--
2.37.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179966):
https://lists.openembedded.org/g/openembedded-core/message/179966
Mute This Topic: https://lists.openembedded.org/mt/98237120/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 3/5] python3-manifest: add tomllib
From: Bartosz Golaszewski
Add the TOML parsing module from the standard library to the manifest.
Signed-off-by: Bartosz Golaszewski
---
.../python/python3/python3-manifest.json| 17 +
1 file changed, 17 insertions(+)
diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json
b/meta/recipes-devtools/python/python3/python3-manifest.json
index 498402af42..9e91270a50 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -829,6 +829,7 @@
"stringold",
"syslog",
"terminal",
+"tomllib",
"threading",
"tkinter",
"unittest",
@@ -1179,6 +1180,22 @@
],
"cached": []
},
+"tomllib": {
+"summary": "Provides an interface for parsing TOML",
+"rdepends": [
+"core",
+"datetime",
+"stringold"
+],
+"files": [
+"${libdir}/python${PYTHON_MAJMIN}/tomllib/"
+],
+"cached": [
+"${libdir}/python${PYTHON_MAJMIN}/tomllib/_re.*.pyc",
+"${libdir}/python${PYTHON_MAJMIN}/tomllib/_types.*.pyc",
+"${libdir}/python${PYTHON_MAJMIN}/tomllib/_parser.*.pyc"
+]
+},
"unittest": {
"summary": "Python unit testing framework",
"rdepends": [
--
2.37.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179964):
https://lists.openembedded.org/g/openembedded-core/message/179964
Mute This Topic: https://lists.openembedded.org/mt/98237118/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 4/5] python3-manifest: add ensurepip
From: Bartosz Golaszewski
Add the pip bootstrapping module from the standard library to the
manifest. This module is a run-time requirement of python3-build.
Signed-off-by: Bartosz Golaszewski
---
.../python/python3/python3-manifest.json | 23 +++
1 file changed, 23 insertions(+)
diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json
b/meta/recipes-devtools/python/python3/python3-manifest.json
index 9e91270a50..f278b18775 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -610,6 +610,28 @@
"${libdir}/python${PYTHON_MAJMIN}/__pycache__/imaplib.*.pyc"
]
},
+"ensurepip": {
+"summary": "Support for bootstrapping the pip installer",
+"rdepends": [
+"asyncio",
+"compile",
+"core",
+"ctypes",
+"image",
+"io",
+"mmap",
+"plistlib",
+"pprint",
+"unixadmin",
+"xmlrpc"
+],
+"files": [
+"${libdir}/python${PYTHON_MAJMIN}/ensurepip/"
+],
+"cached": [
+"${libdir}/python${PYTHON_MAJMIN}/ensurepip/_uninstall.*.pyc"
+]
+},
"fcntl": {
"summary": "Python's fcntl interface",
"rdepends": [
@@ -800,6 +822,7 @@
"distutils",
"doctest",
"email",
+"ensurepip",
"fcntl",
"html",
"idle",
--
2.37.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179965):
https://lists.openembedded.org/g/openembedded-core/message/179965
Mute This Topic: https://lists.openembedded.org/mt/98237119/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/5] python3: fix run-time availability of python3-build
From: Bartosz Golaszewski python3-build cannot be used in self-hosted images due to missing run-time dependencies in several packages. This series adds required RDEPENDS to python3-packaging and python3-pyproject-hooks, extends the manifest to include standard tomllib and ensurepip package and finally fixes run-time dependencies of python3-build itself. Bartosz Golaszewski (5): python3-pyproject-hooks: add missing run-time dependencies python3-packaging: add missing run-time dependencies python3-manifest: add tomllib python3-manifest: add ensurepip python3-build: add missing run-time dependencies .../python/python3-build_0.10.0.bb| 11 - .../python/python3-packaging_23.0.bb | 1 + .../python/python3-pyproject-hooks_1.0.0.bb | 2 + .../python/python3/python3-manifest.json | 40 +++ 4 files changed, 53 insertions(+), 1 deletion(-) -- 2.37.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#179961): https://lists.openembedded.org/g/openembedded-core/message/179961 Mute This Topic: https://lists.openembedded.org/mt/98237113/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/5] python3-pyproject-hooks: add missing run-time dependencies
From: Bartosz Golaszewski
JSON module is required at run-time by pyproject-hooks.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-pyproject-hooks_1.0.0.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/python/python3-pyproject-hooks_1.0.0.bb
b/meta/recipes-devtools/python/python3-pyproject-hooks_1.0.0.bb
index 9aca5918ec..e3893d51cb 100644
--- a/meta/recipes-devtools/python/python3-pyproject-hooks_1.0.0.bb
+++ b/meta/recipes-devtools/python/python3-pyproject-hooks_1.0.0.bb
@@ -14,6 +14,8 @@ BBCLASSEXTEND = "native nativesdk"
# Bootstrap the native build
DEPENDS:remove:class-native = "python3-build-native"
+RDEPENDS:${PN} += "python3-json"
+
do_compile:class-native () {
python_flit_core_do_manual_build
}
--
2.37.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179962):
https://lists.openembedded.org/g/openembedded-core/message/179962
Mute This Topic: https://lists.openembedded.org/mt/98237115/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/5] python3-packaging: add missing run-time dependencies
From: Bartosz Golaszewski
python3-profile is required by python3-packaging at run-time.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3-packaging_23.0.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/python/python3-packaging_23.0.bb
b/meta/recipes-devtools/python/python3-packaging_23.0.bb
index 7b69c880c1..c3d748911c 100644
--- a/meta/recipes-devtools/python/python3-packaging_23.0.bb
+++ b/meta/recipes-devtools/python/python3-packaging_23.0.bb
@@ -11,6 +11,7 @@ BBCLASSEXTEND = "native nativesdk"
# Bootstrap the native build
DEPENDS:remove:class-native = "python3-build-native"
+RDEPENDS:${PN} += "python3-profile"
do_compile:class-native () {
python_flit_core_do_manual_build
--
2.37.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179963):
https://lists.openembedded.org/g/openembedded-core/message/179963
Mute This Topic: https://lists.openembedded.org/mt/98237117/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][RFC PATCH] base: implement support for the PACKAGECONFIGEXTENDS variable
From: Bartosz Golaszewski
Some PACKAGECONFIG switches enable building of additional artifacts that
end up in sub-packages for a recipe. For example in foo.bb we have:
PACKAGES =+ "foo-bar"
PACKAGECONFIG[bar] = "--enable-bar,--disable-bar,libdep"
FILES:foo-bar = "${bindir}/bar"
Where ${bindir}/bar is only installed if PACKAGECONFIG contains "bar".
In order to add foo-bar to the image we need to do:
IMAGE_INSTALL:append = " foo-bar"
PACKAGECONFIG:append:pn-foo = " bar"
This is redundant so with this change we need to add:
PACKAGECONFIGEXTENDS:foo-bar = "bar"
to foo.bb and now adding "foo-bar" to IMAGE_INSTALL will automatically
append "bar" to foo.bb's PACKAGECONFIG.
Signed-off-by: Bartosz Golaszewski
---
documentation/ref-manual/variables.rst| 15 +++
.../packageconfigextends.bb | 27 +++
.../packageconfigextends/pkgext-bar.sh| 3 +++
.../packageconfigextends/pkgext.sh| 3 +++
meta/classes-global/base.bbclass | 13 +
.../oeqa/selftest/cases/packageconfigdeps.py | 11
6 files changed, 72 insertions(+)
create mode 100644
meta-selftest/recipes-test/packageconfigextends/packageconfigextends.bb
create mode 100644
meta-selftest/recipes-test/packageconfigextends/packageconfigextends/pkgext-bar.sh
create mode 100644
meta-selftest/recipes-test/packageconfigextends/packageconfigextends/pkgext.sh
create mode 100644 meta/lib/oeqa/selftest/cases/packageconfigdeps.py
diff --git a/documentation/ref-manual/variables.rst
b/documentation/ref-manual/variables.rst
index c787a17937..dcb5cdccd9 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -6016,6 +6016,21 @@ system and gives an overview of their function and
contents.
PACKAGECONFIG:append:pn-recipename = " f4"
+ :term:`PACKAGECONFIGEXTENDS`
+ List of :term:`PACKAGECONFIG` flags automatically enabled for a package
+ present in :term:`IMAGE_INSTALL`. The :term:`PACKAGES` variable lists
+ the packages generated by a recipe.
+
+ Some :term:`PACKAGECONFIG` switches enable building additional artifacts
+ that are part of sub-packages for a recipe. In order to avoid having to
+ explictly add :term:`PACKAGECONFIG` flags AND include the additional
+ packages in :term:`IMAGE_INSTALL`, the user can just do::
+
+ PACKAGECONFIGEXTENDS:packagename = " foo"
+
+ in which case pulling in `packagename` from the recipe will automatically
+ add `foo` to this recipe's :term:`PACKAGECONFIG`.
+
:term:`PACKAGECONFIG_CONFARGS`
A space-separated list of configuration options generated from the
:term:`PACKAGECONFIG` setting.
diff --git
a/meta-selftest/recipes-test/packageconfigextends/packageconfigextends.bb
b/meta-selftest/recipes-test/packageconfigextends/packageconfigextends.bb
new file mode 100644
index 00..189b9779b3
--- /dev/null
+++ b/meta-selftest/recipes-test/packageconfigextends/packageconfigextends.bb
@@ -0,0 +1,27 @@
+SUMMARY = "Test case making sure that sub-packages pull in correct
PACKAGECONFIG switches."
+LICENSE = "MIT"
+LIC_FILES_CHKSUM =
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+SRC_URI = " \
+file://pkgext.sh \
+file://pkgext-bar.sh \
+"
+
+PACKAGES =+ "${PN}-bar"
+FILES:${PN}-bar += "${bindir}/pkgext-bar"
+
+PACKAGECONFIG = ""
+PACKAGECONFIG[bar] = ""
+
+PACKAGECONFIGEXTENDS:${PN}-bar = "bar"
+
+do_compile[noexec] = "1"
+
+S = "${WORKDIR}"
+
+do_install() {
+install -D -m 0755 ${S}/pkgext.sh ${D}${bindir}/pkgext
+if [ "${@bb.utils.contains("PACKAGECONFIG", "bar", "1", "", d)}" = "1" ];
then
+install -D -m 0755 ${S}/pkgext-bar.sh ${D}${bindir}/pkgext-bar
+fi
+}
diff --git
a/meta-selftest/recipes-test/packageconfigextends/packageconfigextends/pkgext-bar.sh
b/meta-selftest/recipes-test/packageconfigextends/packageconfigextends/pkgext-bar.sh
new file mode 100644
index 00..1b208b154f
--- /dev/null
+++
b/meta-selftest/recipes-test/packageconfigextends/packageconfigextends/pkgext-bar.sh
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+echo "BAR"
diff --git
a/meta-selftest/recipes-test/packageconfigextends/packageconfigextends/pkgext.sh
b/meta-selftest/recipes-test/packageconfigextends/packageconfigextends/pkgext.sh
new file mode 100644
index 00..c5beb15283
--- /dev/null
+++
b/meta-selftest/recipes-test/packageconfigextends/packageconfigextends/pkgext.sh
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+echo "FOO"
diff --git a/meta/classes-global/base.bbclass b/meta/classes-global/base.bbclass
index b6e339ed9c..7ee43d85e0 100644
--- a/m
[OE-core][PATCH v2] bluez5: add dbus to RDEPENDS
From: Bartosz Golaszewski
Unless we're using systemd, dbus is not pulled into the system
automatically. Bluez5 will not work without dbus so add it to RDEPENDS
explicitly.
Signed-off-by: Bartosz Golaszewski
---
v1 -> v2:
- don't overwrite RDEPENDS, use '+='
meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 79d4645ca8..f07e318897 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
file://src/main.c;beginline=1;endline=24;md5=0ad83ca0dc37ab08af448777c581e7ac"
DEPENDS = "dbus glib-2.0"
+RDEPENDS:${PN} += "dbus"
PROVIDES += "bluez-hcidump"
RPROVIDES:${PN} += "bluez-hcidump"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171902):
https://lists.openembedded.org/g/openembedded-core/message/171902
Mute This Topic: https://lists.openembedded.org/mt/94379685/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] bluez5: add dbus to RDEPENDS
From: Bartosz Golaszewski
Unless we're using systemd, dbus is not pulled into the system
automatically. Bluez5 will not work without dbus so add it to RDEPENDS
explicitly.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 79d4645ca8..b6f1c00c14 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
file://src/main.c;beginline=1;endline=24;md5=0ad83ca0dc37ab08af448777c581e7ac"
DEPENDS = "dbus glib-2.0"
+RDEPENDS:${PN} = "dbus"
PROVIDES += "bluez-hcidump"
RPROVIDES:${PN} += "bluez-hcidump"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171739):
https://lists.openembedded.org/g/openembedded-core/message/171739
Mute This Topic: https://lists.openembedded.org/mt/94334177/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] [oe] [meta-zephyr] build broken with current oe-core master
On Thu, Jul 21, 2022 at 3:52 PM Khem Raj wrote: > > I don’t see config.log for Libstdc++ folder in there > Can you see why that’s missing ? > I was missing because I misunderstood you - you were probably asking for the config.log *with* Jon's patch applied. Here's the log: https://controlc.com/4544edd8 Bart -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#168400): https://lists.openembedded.org/g/openembedded-core/message/168400 Mute This Topic: https://lists.openembedded.org/mt/92467688/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] [oe] [meta-zephyr] build broken with current oe-core master
On Wed, Jul 20, 2022 at 5:59 PM Khem Raj wrote:
>
>
>
> On Wed, Jul 20, 2022 at 11:35 AM Bartosz Golaszewski wrote:
>>
>> On Tue, Jul 19, 2022 at 4:58 PM Khem Raj wrote:
>> >
>> > On Tue, Jul 19, 2022 at 10:48 AM Bartosz Golaszewski wrote:
>> > >
>> > > On Tue, Jul 19, 2022 at 2:54 PM Khem Raj wrote:
>> > > >
>> > > >
>> > > >
>> > > > On Tue, Jul 19, 2022 at 3:40 AM Bartosz Golaszewski
>> > > > wrote:
>> > > >>
>> > > >> On Tue, Jul 19, 2022 at 12:10 AM Jon Mason wrote:
>> > > >> >
>> > > >> > On Mon, Jul 18, 2022 at 4:06 PM Khem Raj wrote:
>> > > >> > >
>> > > >> > > Can you try something like this
>> > > >> > >
>> > > >> > > diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
>> > > >> > > b/meta/recipes-devtools/gcc/gcc-runtime.inc
>> > > >> > > index 5d74e4494d..61d5bf6058 100644
>> > > >> > > --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
>> > > >> > > +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
>> > > >> > > @@ -68,8 +68,7 @@ do_configure () {
>> > > >> > > # libstdc++ isn't built yet so CXX would error not able to
>> > > >> > > find it
>> > > >> > > which breaks stdc++'s configure
>> > > >> > > # tests. Create a dummy empty lib for the purposes of
>> > > >> > > configure.
>> > > >> > > mkdir -p ${WORKDIR}/dummylib
>> > > >> > > - touch ${WORKDIR}/dummylib/dummylib.c
>> > > >> > > - ${CC} ${WORKDIR}/dummylib/dummylib.c -shared -o
>> > > >> > > ${WORKDIR}/dummylib/libstdc++.so
>> > > >> > > + ${CC} -nostartfiles -shared -x c /dev/null -o
>> > > >> > > ${WORKDIR}/dummylib/libstdc++.so
>> > > >> > > for d in libgcc ${RUNTIMETARGET}; do
>> > > >> > > echo "Configuring $d"
>> > > >> > > rm -rf ${B}/${TARGET_SYS}/$d/
>> > > >> > >
>> > > >> > >
>> > > >> > > and see if it helps ?
>> > > >> >
>> > > >> > That appears to work for the 2 zephyr machines in meta-arm
>> > > >> >
>> > > >>
>> > > >> This still fails for arduino nano 33 ble:
>> > > >>
>> > > >> | checking for dirent.h... no
>> > > >> | checking sys/statvfs.h usability... no
>> > > >> | checking sys/statvfs.h presence... no
>> > > >> | checking for sys/statvfs.h... no
>> > > >> | checking utime.h usability... yes
>> > > >> | checking utime.h presence... yes
>> > > >> | checking for utime.h... yes
>> > > >> | checking whether to build Filesystem TS support... no
>> > > >> | checking for struct dirent.d_type... no
>> > > >> | checking for realpath... no
>> > > >> | checking for utimensat... no
>> > > >> | checking for utime... no
>> > > >> | checking for lstat... no
>> > > >> | checking for struct stat.st_mtim.tv_nsec... yes
>> > > >> | checking for fchmod... yes
>> > > >> | checking for fchmodat... yes
>> > > >> | checking for sendfile that can copy files... no
>> > > >> | checking for link... yes
>> > > >> | checking for readlink... yes
>> > > >> | checking for symlink... yes
>> > > >> | checking for truncate... yes
>> > > >> | checking for fdopendir... no
>> > > >> | checking for dirfd... no
>> > > >> | checking for unlinkat... yes
>> > > >> | checking __sync extensions... yes
>> > > >> | checking link.h usability... no
>> > > >> | checking link.h presence... no
>> > > >> | checking for link.h... no
>> > > >> | checking for fcntl... configure: error: Link tests are not allowed
>> > > >> after GCC_NO_EXECUTABLES.
>> > > >
>> > > >
>> > > >
>> > > > Can you post config.log from this component
>> > > >
>> > >
&
Re: [OE-core] [oe] [meta-zephyr] build broken with current oe-core master
On Tue, Jul 19, 2022 at 4:58 PM Khem Raj wrote:
>
> On Tue, Jul 19, 2022 at 10:48 AM Bartosz Golaszewski wrote:
> >
> > On Tue, Jul 19, 2022 at 2:54 PM Khem Raj wrote:
> > >
> > >
> > >
> > > On Tue, Jul 19, 2022 at 3:40 AM Bartosz Golaszewski wrote:
> > >>
> > >> On Tue, Jul 19, 2022 at 12:10 AM Jon Mason wrote:
> > >> >
> > >> > On Mon, Jul 18, 2022 at 4:06 PM Khem Raj wrote:
> > >> > >
> > >> > > Can you try something like this
> > >> > >
> > >> > > diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
> > >> > > b/meta/recipes-devtools/gcc/gcc-runtime.inc
> > >> > > index 5d74e4494d..61d5bf6058 100644
> > >> > > --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> > >> > > +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> > >> > > @@ -68,8 +68,7 @@ do_configure () {
> > >> > > # libstdc++ isn't built yet so CXX would error not able to find
> > >> > > it
> > >> > > which breaks stdc++'s configure
> > >> > > # tests. Create a dummy empty lib for the purposes of configure.
> > >> > > mkdir -p ${WORKDIR}/dummylib
> > >> > > - touch ${WORKDIR}/dummylib/dummylib.c
> > >> > > - ${CC} ${WORKDIR}/dummylib/dummylib.c -shared -o
> > >> > > ${WORKDIR}/dummylib/libstdc++.so
> > >> > > + ${CC} -nostartfiles -shared -x c /dev/null -o
> > >> > > ${WORKDIR}/dummylib/libstdc++.so
> > >> > > for d in libgcc ${RUNTIMETARGET}; do
> > >> > > echo "Configuring $d"
> > >> > > rm -rf ${B}/${TARGET_SYS}/$d/
> > >> > >
> > >> > >
> > >> > > and see if it helps ?
> > >> >
> > >> > That appears to work for the 2 zephyr machines in meta-arm
> > >> >
> > >>
> > >> This still fails for arduino nano 33 ble:
> > >>
> > >> | checking for dirent.h... no
> > >> | checking sys/statvfs.h usability... no
> > >> | checking sys/statvfs.h presence... no
> > >> | checking for sys/statvfs.h... no
> > >> | checking utime.h usability... yes
> > >> | checking utime.h presence... yes
> > >> | checking for utime.h... yes
> > >> | checking whether to build Filesystem TS support... no
> > >> | checking for struct dirent.d_type... no
> > >> | checking for realpath... no
> > >> | checking for utimensat... no
> > >> | checking for utime... no
> > >> | checking for lstat... no
> > >> | checking for struct stat.st_mtim.tv_nsec... yes
> > >> | checking for fchmod... yes
> > >> | checking for fchmodat... yes
> > >> | checking for sendfile that can copy files... no
> > >> | checking for link... yes
> > >> | checking for readlink... yes
> > >> | checking for symlink... yes
> > >> | checking for truncate... yes
> > >> | checking for fdopendir... no
> > >> | checking for dirfd... no
> > >> | checking for unlinkat... yes
> > >> | checking __sync extensions... yes
> > >> | checking link.h usability... no
> > >> | checking link.h presence... no
> > >> | checking for link.h... no
> > >> | checking for fcntl... configure: error: Link tests are not allowed
> > >> after GCC_NO_EXECUTABLES.
> > >
> > >
> > >
> > > Can you post config.log from this component
> > >
> >
> > Here you go: https://pastebin.com/6KMD9PhX
>
> this one has succeeded. I guess there are multiple config.log files in
> your build tree. Perhaps the one which shows exit 1 at the end is one
> I am interested in.
>
> >
> > Bart
I don't see any config.h that would fail and I just ran a clean build.
| DEBUG: Executing python function extract_stashed_builddir
| DEBUG: sed -e
's:^[^/]*/:/home/brgl/workspace/zephyr-yocto/build/tmp-newlib/work/armv7m-yocto-eabi/gcc-runtime/12.1.0-r0/gcc-12.1.0/build.arm-yocto-eabi.arm-yocto-eabi/:g'
/home/brgl/workspace/zephyr-yocto/build/tmp-newlib/sysroots-components/x86_64/gcc-stashed-builddir-arm-yocto-eabi/fixmepath
| xargs sed -i -e
's:FIXMESTAGINGDIRTARGET:/home/brgl/workspace/zephyr-yocto/build/tmp-newlib/work/armv7m-yocto-eabi/gcc-runtime/12.1.0-r0/recipe-sysroot:g;
s:FIXMESTAGINGDIRHOST:/home/brgl/workspace/zephyr-yo
Re: [OE-core] [oe] [meta-zephyr] build broken with current oe-core master
On Tue, Jul 19, 2022 at 2:54 PM Khem Raj wrote:
>
>
>
> On Tue, Jul 19, 2022 at 3:40 AM Bartosz Golaszewski wrote:
>>
>> On Tue, Jul 19, 2022 at 12:10 AM Jon Mason wrote:
>> >
>> > On Mon, Jul 18, 2022 at 4:06 PM Khem Raj wrote:
>> > >
>> > > Can you try something like this
>> > >
>> > > diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
>> > > b/meta/recipes-devtools/gcc/gcc-runtime.inc
>> > > index 5d74e4494d..61d5bf6058 100644
>> > > --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
>> > > +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
>> > > @@ -68,8 +68,7 @@ do_configure () {
>> > > # libstdc++ isn't built yet so CXX would error not able to find it
>> > > which breaks stdc++'s configure
>> > > # tests. Create a dummy empty lib for the purposes of configure.
>> > > mkdir -p ${WORKDIR}/dummylib
>> > > - touch ${WORKDIR}/dummylib/dummylib.c
>> > > - ${CC} ${WORKDIR}/dummylib/dummylib.c -shared -o
>> > > ${WORKDIR}/dummylib/libstdc++.so
>> > > + ${CC} -nostartfiles -shared -x c /dev/null -o
>> > > ${WORKDIR}/dummylib/libstdc++.so
>> > > for d in libgcc ${RUNTIMETARGET}; do
>> > > echo "Configuring $d"
>> > > rm -rf ${B}/${TARGET_SYS}/$d/
>> > >
>> > >
>> > > and see if it helps ?
>> >
>> > That appears to work for the 2 zephyr machines in meta-arm
>> >
>>
>> This still fails for arduino nano 33 ble:
>>
>> | checking for dirent.h... no
>> | checking sys/statvfs.h usability... no
>> | checking sys/statvfs.h presence... no
>> | checking for sys/statvfs.h... no
>> | checking utime.h usability... yes
>> | checking utime.h presence... yes
>> | checking for utime.h... yes
>> | checking whether to build Filesystem TS support... no
>> | checking for struct dirent.d_type... no
>> | checking for realpath... no
>> | checking for utimensat... no
>> | checking for utime... no
>> | checking for lstat... no
>> | checking for struct stat.st_mtim.tv_nsec... yes
>> | checking for fchmod... yes
>> | checking for fchmodat... yes
>> | checking for sendfile that can copy files... no
>> | checking for link... yes
>> | checking for readlink... yes
>> | checking for symlink... yes
>> | checking for truncate... yes
>> | checking for fdopendir... no
>> | checking for dirfd... no
>> | checking for unlinkat... yes
>> | checking __sync extensions... yes
>> | checking link.h usability... no
>> | checking link.h presence... no
>> | checking for link.h... no
>> | checking for fcntl... configure: error: Link tests are not allowed
>> after GCC_NO_EXECUTABLES.
>
>
>
> Can you post config.log from this component
>
Here you go: https://pastebin.com/6KMD9PhX
Bart
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168281):
https://lists.openembedded.org/g/openembedded-core/message/168281
Mute This Topic: https://lists.openembedded.org/mt/92467688/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] [oe] [meta-zephyr] build broken with current oe-core master
On Tue, Jul 19, 2022 at 12:10 AM Jon Mason wrote:
>
> On Mon, Jul 18, 2022 at 4:06 PM Khem Raj wrote:
> >
> > Can you try something like this
> >
> > diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
> > b/meta/recipes-devtools/gcc/gcc-runtime.inc
> > index 5d74e4494d..61d5bf6058 100644
> > --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> > +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> > @@ -68,8 +68,7 @@ do_configure () {
> > # libstdc++ isn't built yet so CXX would error not able to find it
> > which breaks stdc++'s configure
> > # tests. Create a dummy empty lib for the purposes of configure.
> > mkdir -p ${WORKDIR}/dummylib
> > - touch ${WORKDIR}/dummylib/dummylib.c
> > - ${CC} ${WORKDIR}/dummylib/dummylib.c -shared -o
> > ${WORKDIR}/dummylib/libstdc++.so
> > + ${CC} -nostartfiles -shared -x c /dev/null -o
> > ${WORKDIR}/dummylib/libstdc++.so
> > for d in libgcc ${RUNTIMETARGET}; do
> > echo "Configuring $d"
> > rm -rf ${B}/${TARGET_SYS}/$d/
> >
> >
> > and see if it helps ?
>
> That appears to work for the 2 zephyr machines in meta-arm
>
This still fails for arduino nano 33 ble:
| checking for dirent.h... no
| checking sys/statvfs.h usability... no
| checking sys/statvfs.h presence... no
| checking for sys/statvfs.h... no
| checking utime.h usability... yes
| checking utime.h presence... yes
| checking for utime.h... yes
| checking whether to build Filesystem TS support... no
| checking for struct dirent.d_type... no
| checking for realpath... no
| checking for utimensat... no
| checking for utime... no
| checking for lstat... no
| checking for struct stat.st_mtim.tv_nsec... yes
| checking for fchmod... yes
| checking for fchmodat... yes
| checking for sendfile that can copy files... no
| checking for link... yes
| checking for readlink... yes
| checking for symlink... yes
| checking for truncate... yes
| checking for fdopendir... no
| checking for dirfd... no
| checking for unlinkat... yes
| checking __sync extensions... yes
| checking link.h usability... no
| checking link.h presence... no
| checking for link.h... no
| checking for fcntl... configure: error: Link tests are not allowed
after GCC_NO_EXECUTABLES.
| WARNING: exit code 1 from a shell command.
ERROR: Task
(/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/gcc/gcc-runtime_12.1.bb:do_configure)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 795 tasks of which 774 didn't need to
be rerun and 1 failed.
Summary: 1 task failed:
/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/gcc/gcc-runtime_12.1.bb:do_configure
Summary: There was 1 ERROR message, returning a non-zero exit code.
Bart
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168274):
https://lists.openembedded.org/g/openembedded-core/message/168274
Mute This Topic: https://lists.openembedded.org/mt/92467688/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [meta-zephyr] build broken with current oe-core master
Hi!
It seems that the zephyr build is currently broken with master (and
master-next) for meta-zephyr samples:
Build Configuration:
BB_VERSION = "2.0.1"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-yocto-eabi"
MACHINE = "arduino-nano-33-ble"
DISTRO = "zephyr"
DISTRO_VERSION = "1.0"
TUNE_FEATURES= "armv7m cortexm4"
TARGET_FPU = "soft"
meta
meta-poky= "HEAD:67b9303d72c14d2aedb3f0313cb7b27dfb1499d3"
meta-zephyr-core
meta-zephyr-bsp = "master:6d184ce6b66349a87dc114c7ab59d0dd3bf92785"
meta-oe
meta-python = "master:cb7d3afba838f159a5df4ef5091dba8e770159a8"
Initialising tasks: 100%
|#|
Time: 0:00:01
Sstate summary: Wanted 101 Local 66 Mirrors 0 Missed 35 Current 98
(65% match, 82% complete)
NOTE: Executing Tasks
ERROR: gcc-runtime-12.1.0-r0 do_configure:
ExecutionError('/home/brgl/workspace/zephyr-yocto/build/tmp-newlib/work/armv7m-yocto-eabi/gcc-runtime/12.1.0-r0/temp/run.do_configure.2702410',
1, None, None)
ERROR: Logfile of failure stored in:
/home/brgl/workspace/zephyr-yocto/build/tmp-newlib/work/armv7m-yocto-eabi/gcc-runtime/12.1.0-r0/temp/log.do_configure.2702410
Log data follows:
| DEBUG: Executing python function extend_recipe_sysroot
| NOTE: Direct dependencies are
['/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-core/newlib/newlib_4.2.0.bb:do_populate_sysroot',
'/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/binutils/binutils-cross_2.38.bb:do_populate_sysroot',
'/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/gcc/gcc-cross_12.1.bb:do_populate_sysroot',
'/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/gcc/libgcc_12.1.bb:do_populate_sysroot',
'/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/libtool/libtool-native_2.4.7.bb:do_populate_sysroot',
'/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot',
'/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy-native.bb:do_populate_sysroot',
'virtual:native:/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-core/zlib/zlib_1.2.12.bb:do_populate_sysroot',
'virtual:native:/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/autoconf/autoconf_2.71.bb:do_populate_sysroot',
'virtual:native:/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/automake/automake_1.16.5.bb:do_populate_sysroot',
'virtual:native:/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/flex/flex_2.6.4.bb:do_populate_sysroot',
'virtual:native:/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/gnu-config/gnu-config_git.bb:do_populate_sysroot',
'virtual:native:/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot',
'virtual:native:/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot',
'virtual:native:/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-extended/xz/xz_5.2.5.bb:do_populate_sysroot',
'virtual:native:/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-extended/zstd/zstd_1.5.2.bb:do_populate_sysroot',
'virtual:native:/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-support/gmp/gmp_6.2.1.bb:do_populate_sysroot',
'virtual:native:/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-support/libmpc/libmpc_1.2.1.bb:do_populate_sysroot',
'virtual:native:/home/brgl/workspace/zephyr-yocto/sources/poky/meta/recipes-support/mpfr/mpfr_4.1.0.bb:do_populate_sysroot']
| NOTE: Installed into sysroot: []
| NOTE: Skipping as already exists in sysroot: ['newlib',
'binutils-cross-arm', 'gcc-cross-arm', 'libgcc', 'libtool-native',
'quilt-native', 'texinfo-dummy-native', 'zlib-native',
'autoconf-native', 'automake-native', 'flex-native',
'gnu-config-native', 'patch-native', 'pseudo-native', 'xz-native',
'zstd-native', 'gmp-native', 'libmpc-native', 'mpfr-native',
'attr-native', 'gettext-minimal-native', 'm4-native']
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing python function autotools_aclocals
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
'arm-32', 'arm-eabi', 'common']
| DEBUG: Python function autotools_aclocals finished
| DEBUG: Executing python function gcc_multilib_setup
| DEBUG: Python function gcc_multilib_setup finished
| DEBUG: Executing python function extract_stashed_builddir
| DEBUG: sed -e
's:^[^/]*/:/home/brgl/workspace/zephyr-yocto/build/tmp-newlib/work/armv7m-yocto-eabi/gcc-runtime/12.1.0-r0/gcc-12.1.0/build.arm-yocto-eabi.arm-yocto-eabi/:g'
/home/brgl/workspace/zephyr
[OE-core] [meta-java] icedtea7-native build fails on kirkstone and in master
Hi! I'm trying to build java support with the following configuration: Build Configuration: BB_VERSION = "2.0.0" BUILD_SYS= "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "x86_64-poky-linux" MACHINE = "qemux86-64" DISTRO = "poky" DISTRO_VERSION = "4.0.1" TUNE_FEATURES= "m64 core2" TARGET_FPU = "" meta meta-poky= "kirkstone:45d7615dfef8093a2467d52ca1130e62db6a1187" meta-oe = "kirkstone:fcc7d7eae82be4c180f2e8fa3db90a8ab3be07b7" meta-java= "kirkstone:1a8059f6b257ebe6fcae6416e499784d976afd24" --- PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native" PREFERRED_PROVIDER_virtual/java-native = "jamvm-native" PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native" --- The build fails for icedtea7-native but it's hard to tell why exactly from the logs. Here is the full output: https://pastebin.com/3dRt6J0Y It seems to be failing here: | Checking for mapfile use in: /home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk.build-boot/lib/amd64/libmanagement.so | Library loads for: /home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk.build-boot/lib/amd64/libmanagement.so | make[5]: Leaving directory '/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot/jdk/make/java/management' | make[5]: *** [../../common/Library.gmk:225: /home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk.build-boot/lib/amd64/libmanagement.so] Error 1 | make[4]: Leaving directory '/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot/jdk/make/java' | make[4]: *** [Makefile:63: all] Error 1 | make[3]: Leaving directory '/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot/jdk/make' | make[3]: *** [Makefile:247: all] Error 1 | make[2]: Leaving directory '/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot' | make[2]: *** [make/jdk-rules.gmk:79: jdk-build] Error 2 | make[1]: Leaving directory '/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot' | make[1]: *** [Makefile:244: build_product_image] Error 2 | make: *** [Makefile:2252: stamps/icedtea-boot.stamp] Error 2 But not sure why. Thanks in advance for any help. Bart -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#166766): https://lists.openembedded.org/g/openembedded-core/message/166766 Mute This Topic: https://lists.openembedded.org/mt/91641852/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] Rust recipe fails to build project on kirkstone but works on dunfell
On Wed, Jun 8, 2022 at 3:21 AM Randy MacLeod wrote: > [snip] > > Naveen or I will take a look at some point and at least let you know if > we can reproduce the error. > Can you try using the master branch to use rust_1.60 ? > I doubt it will help but it might be easy to check. > Actually, the reason seems to be with outdated packages. I updated my recipe to a newer version and hit a bunch of different issues but they seem to be in cargo and not in oe-core (for reference: https://github.com/rust-lang/cargo/pull/10730). Bart -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#166710): https://lists.openembedded.org/g/openembedded-core/message/166710 Mute This Topic: https://lists.openembedded.org/mt/91495505/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 4/4] gstreamer1.0-plugins-rs: new package
On Mon, Jun 6, 2022 at 5:23 PM Alexander Kanavin wrote: > > Thanks; is this something that oe-core needs to provide? As it's not > in version lockstep with the rest of gstreamer, it seems more like a > collection of experimental plugins and is maybe a better fit for > meta-oe for now? > Fine with me but the first three patches need to go into oe-core anyway so I'd like to hear some feedback and then this one can be put into meta-oe. Bart -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#166650): https://lists.openembedded.org/g/openembedded-core/message/166650 Mute This Topic: https://lists.openembedded.org/mt/91576745/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 3/4] cargo: pass PACKAGECONFIG_CONFARGS to cargo build
In order to allow rust packages to define PACKAGECONFIG options, append
the contents of PACKAGECONFIG_CONFARGS to the build command.
Signed-off-by: Bartosz Golaszewski
---
meta/classes/cargo.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/cargo.bbclass b/meta/classes/cargo.bbclass
index 7cfd4a2666..2a62fda4a3 100644
--- a/meta/classes/cargo.bbclass
+++ b/meta/classes/cargo.bbclass
@@ -44,7 +44,7 @@ oe_cargo_build () {
bbnote "cargo = $(which ${CARGO})"
bbnote "rustc = $(which ${RUSTC})"
bbnote "${CARGO} build ${CARGO_BUILD_FLAGS} $@"
- "${CARGO}" build ${CARGO_BUILD_FLAGS} "$@"
+ "${CARGO}" build ${CARGO_BUILD_FLAGS} ${PACKAGECONFIG_CONFARGS} "$@"
}
do_compile[progress] = "outof:\s+(\d+)/(\d+)"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#166630):
https://lists.openembedded.org/g/openembedded-core/message/166630
Mute This Topic: https://lists.openembedded.org/mt/91576744/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 4/4] gstreamer1.0-plugins-rs: new package
This adds a recipe for gstreamer plugins written in Rust. Signed-off-by: Bartosz Golaszewski --- .../gstreamer1.0-plugins-rs_0.8.4.bb | 465 ++ 1 file changed, 465 insertions(+) create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-rs_0.8.4.bb diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-rs_0.8.4.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-rs_0.8.4.bb new file mode 100644 index 00..0b299e0257 --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-rs_0.8.4.bb @@ -0,0 +1,465 @@ +SUMMARY = "Various GStreamer plugins and elements written in the Rust programming language." +LICENSE = "Apache-2.0 & MIT & LGPL-2.1-only" +LIC_FILES_CHKSUM = " \ +file://LICENSE-APACHE;md5=1836efb2eb779966696f473ee8540542 \ +file://LICENSE-MIT;md5=b377b220f43d747efdec40d69fcaa69d \ +file://LICENSE-LGPLv2;md5=4fbd65380cdd255951079008b364516c \ +" + +SRC_URI = " \ + git://gitlab.freedesktop.org/gstreamer/gst-plugins-rs.git;protocol=https;branch=0.8;name=default \ + gitsm://gitlab.freedesktop.org/gstreamer/gstreamer-rs.git;protocol=https;branch=0.18;name=gstreamer-rs;destsuffix=cargo_home/git/db/gstreamer-rs-79e52a2d27eb91a3 \ + git://github.com/gtk-rs/gtk-rs-core.git;protocol=https;branch=0.15;name=gtk-rs-core;destsuffix=cargo_home/git/db/gtk-rs-core-7be42ca38bd6361c \ + git://github.com/gtk-rs/gtk3-rs;protocol=https;branch=0.15;name=gtk3-rs;destsuffix=cargo_home/git/db/gtk3-rs-a818089b55180ee1 \ + git://github.com/rust-av/ffv1.git;protocol=https;branch=master;name=ffv1;destsuffix=cargo_home/git/db/ffv1-08f2e3b26709fb34 \ + git://github.com/rust-av/flavors;protocol=https;branch=master;name=flavors;destsuffix=cargo_home/git/db/flavors-0f978a4d88ad8592 \ + git://github.com/gtk-rs/gtk4-rs;protocol=https;branch=0.4;name=gtk4-rs;destsuffix=cargo_home/git/db/gtk4-rs-e74ad56283dfeb5e \ +crate://crates.io/adler/1.0.2 \ +crate://crates.io/adler32/1.2.0 \ +crate://crates.io/aes/0.6.0 \ +crate://crates.io/aes-ctr/0.6.0 \ +crate://crates.io/aes-soft/0.6.4 \ +crate://crates.io/aesni/0.10.0 \ +crate://crates.io/aho-corasick/0.7.18 \ +crate://crates.io/ansi_term/0.12.1 \ +crate://crates.io/anyhow/1.0.57 \ +crate://crates.io/arbitrary/0.4.7 \ +crate://crates.io/arg_enum_proc_macro/0.3.2 \ +crate://crates.io/array-init/2.0.0 \ +crate://crates.io/arrayvec/0.7.2 \ +crate://crates.io/async-compression/0.3.12 \ +crate://crates.io/async-task/4.2.0 \ +crate://crates.io/async-trait/0.1.53 \ +crate://crates.io/async-tungstenite/0.17.2 \ +crate://crates.io/atomic_refcell/0.1.8 \ +crate://crates.io/atty/0.2.14 \ +crate://crates.io/autocfg/1.1.0 \ +crate://crates.io/backoff/0.4.0 \ +crate://crates.io/base-x/0.2.10 \ +crate://crates.io/base32/0.4.0 \ +crate://crates.io/base64/0.13.0 \ +crate://crates.io/bincode/1.3.3 \ +crate://crates.io/bindgen/0.59.2 \ +crate://crates.io/bitflags/1.3.2 \ +crate://crates.io/bitstream-io/1.3.0 \ +crate://crates.io/block-buffer/0.9.0 \ +crate://crates.io/block-buffer/0.10.2 \ +crate://crates.io/build_const/0.2.2 \ +crate://crates.io/bumpalo/3.9.1 \ +crate://crates.io/byte-slice-cast/1.2.1 \ +crate://crates.io/bytemuck/1.9.1 \ +crate://crates.io/byteorder/1.4.3 \ +crate://crates.io/bytes/1.1.0 \ +crate://crates.io/cache-padded/1.2.0 \ +crate://crates.io/cc/1.0.73 \ +crate://crates.io/cdg/0.1.0 \ +crate://crates.io/cdg_renderer/0.7.0 \ +crate://crates.io/cexpr/0.6.0 \ +crate://crates.io/cfg-expr/0.7.4 \ +crate://crates.io/cfg-expr/0.10.2 \ +crate://crates.io/cfg-if/0.1.10 \ +crate://crates.io/cfg-if/1.0.0 \ +crate://crates.io/chrono/0.4.19 \ +crate://crates.io/cipher/0.2.5 \ +crate://crates.io/clang-sys/1.3.1 \ +crate://crates.io/clap/2.34.0 \ +crate://crates.io/clap/3.1.12 \ +crate://crates.io/clap_derive/3.1.7 \ +crate://crates.io/clap_lex/0.1.1 \ +crate://crates.io/claxon/0.4.3 \ +crate://crates.io/color_quant/1.1.0 \ +crate://crates.io/concurrent-queue/1.2.2 \ +crate://crates.io/const_fn/0.4.9 \ +crate://crates.io/cookie/0.15.1 \ +crate://crates.io/cookie_store/0.15.1 \ +crate://crates.io/core-foundation/0.9.3 \ +crate://crates.io/core-foundation-sys/0.8.3 \ +crate://crates.io/cpufeatures/0.2.2 \ +crate://crates.io/crc/1.8.1 \ +crate://crates.io/crc/3.0.0 \ +crate://crates.io/crc-catalog/2.1.0 \ +crate://crates.io/crc32fast/1.3.2 \ +crate://crates.io/crossbeam-channel/0.5.4 \ +crate://crates.io/crossbeam-deque/0.8.1 \ +crate://crates.io/crossbeam-epoch/0.9.8 \ +crate://crates.io/crossbeam-utils/0.8.8 \ +crate://crates.io/crypto-common/0.1.3 \ +crate://crates.io/crypto-mac/0.11.1 \ +crate://crates.io/csound/0.1.8 \ +crate://crates.i
[OE-core][PATCH 1/4] cargo: don't update git submodules in --offline mode
This adds a patch to the cargo recipe that prohibits cargo from trying
to update git submodules when running in --offline mode.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/cargo/cargo.inc | 2 +-
...-t-update-submodules-in-offline-mode.patch | 32 +++
2 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/cargo/cargo/0001-git-don-t-update-submodules-in-offline-mode.patch
diff --git a/meta/recipes-devtools/cargo/cargo.inc
b/meta/recipes-devtools/cargo/cargo.inc
index 607c51fc3d..6ab4e0a5f7 100644
--- a/meta/recipes-devtools/cargo/cargo.inc
+++ b/meta/recipes-devtools/cargo/cargo.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = " \
file://LICENSE-THIRD-PARTY;md5=f257ad009884cb88a3a87d6920e7180a \
"
-
+SRC_URI += "file://0001-git-don-t-update-submodules-in-offline-mode.patch"
S = "${RUSTSRC}/src/tools/cargo"
CARGO_VENDORING_DIRECTORY = "${RUSTSRC}/vendor"
EXCLUDE_FROM_WORLD = "1"
diff --git
a/meta/recipes-devtools/cargo/cargo/0001-git-don-t-update-submodules-in-offline-mode.patch
b/meta/recipes-devtools/cargo/cargo/0001-git-don-t-update-submodules-in-offline-mode.patch
new file mode 100644
index 00..d138c4b911
--- /dev/null
+++
b/meta/recipes-devtools/cargo/cargo/0001-git-don-t-update-submodules-in-offline-mode.patch
@@ -0,0 +1,32 @@
+From 4768c657905356da417f50d3cbb203c76baf1ab2 Mon Sep 17 00:00:00 2001
+From: Bartosz Golaszewski
+Date: Mon, 6 Jun 2022 12:13:02 +0200
+Subject: [PATCH] git: don't update submodules in offline mode
+
+When we're running in --offline mode, don't try to update git
+submodules or else we're bail out with a network error if it's actually
+inaccessible.
+---
+Upstream-Status: Submitted [https://github.com/rust-lang/cargo/pull/10730]
+
+ src/tools/cargo/src/cargo/sources/git/utils.rs | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/src/cargo/sources/git/utils.rs b/src/cargo/sources/git/utils.rs
+index 4eafae1c9..9ed991e36 100644
+--- a/src/cargo/sources/git/utils.rs
b/src/cargo/sources/git/utils.rs
+@@ -177,7 +177,9 @@ impl GitDatabase {
+ Some(c) => c,
+ None => GitCheckout::clone_into(dest, self, rev, cargo_config)?,
+ };
+-checkout.update_submodules(cargo_config)?;
++if !cargo_config.offline() {
++checkout.update_submodules(cargo_config)?;
++}
+ Ok(checkout)
+ }
+
+--
+2.34.1
+
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#166628):
https://lists.openembedded.org/g/openembedded-core/message/166628
Mute This Topic: https://lists.openembedded.org/mt/91576742/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/4] cargo: improve the build process and add a new recipe
This series contains some improvements to the cargo build and adds a new recipe for gstreamer plugins written in rust. Bartosz Golaszewski (4): cargo: don't update git submodules in --offline mode cargo: run in --offline mode cargo: pass PACKAGECONFIG_CONFARGS to cargo build gstreamer1.0-plugins-rs: new package meta/classes/cargo.bbclass| 4 +- meta/recipes-devtools/cargo/cargo.inc | 2 +- ...-t-update-submodules-in-offline-mode.patch | 32 ++ .../gstreamer1.0-plugins-rs_0.8.4.bb | 465 ++ 4 files changed, 500 insertions(+), 3 deletions(-) create mode 100644 meta/recipes-devtools/cargo/cargo/0001-git-don-t-update-submodules-in-offline-mode.patch create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-rs_0.8.4.bb -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#166627): https://lists.openembedded.org/g/openembedded-core/message/166627 Mute This Topic: https://lists.openembedded.org/mt/91576741/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/4] cargo: run in --offline mode
We fetch sources ourselves in do_fetch, don't let cargo fetch anything
else on its own during the build stage.
Signed-off-by: Bartosz Golaszewski
---
meta/classes/cargo.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/cargo.bbclass b/meta/classes/cargo.bbclass
index 4a780a501f..7cfd4a2666 100644
--- a/meta/classes/cargo.bbclass
+++ b/meta/classes/cargo.bbclass
@@ -32,7 +32,7 @@ MANIFEST_PATH ??= "${S}/${CARGO_SRC_DIR}/Cargo.toml"
RUSTFLAGS ??= ""
BUILD_MODE = "${@['--release', ''][d.getVar('DEBUG_BUILD') == '1']}"
-CARGO_BUILD_FLAGS = "-v --target ${HOST_SYS} ${BUILD_MODE}
--manifest-path=${MANIFEST_PATH}"
+CARGO_BUILD_FLAGS = "-v --target ${HOST_SYS} ${BUILD_MODE}
--manifest-path=${MANIFEST_PATH} --offline"
# This is based on the content of CARGO_BUILD_FLAGS and generally will need to
# change if CARGO_BUILD_FLAGS changes.
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#166629):
https://lists.openembedded.org/g/openembedded-core/message/166629
Mute This Topic: https://lists.openembedded.org/mt/91576743/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Rust recipe fails to build project on kirkstone but works on dunfell
Hi! I have a recipe[1] for a rust project. It builds the gstreamer plugin for streaming from AWS S3 that is part of the gst-plugins-rs repo. I'm upgrading the system from dunfell to kirkstone and trying to switch from using meta-rust to using the rust support from openembedded-core. The target is aarch64 and host is x86-64. Unfortunately the build fails on kirkstone with the following error: | Building [===> ] 132/254: num-integer(build), quote... | Running `rustc --crate-name iovec /home/brgl/workspace/veki-kirkstone/build/tmp-glibc/work/armv8a-oe-linux/gstreamer1.0-rusoto/0.6.0-r0/cargo_home/bitbake/iovec-0.1.4/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C debuginfo=2 -C metadata=16f5461729d008fd -C extra-filename=-16f5461729d008fd --out-dir /home/brgl/workspace/veki-kirkstone/build/tmp-glibc/work/armv8a-oe-linux/gstreamer1.0-rusoto/0.6.0-r0/build/target/aarch64-oe-linux/release/deps --target aarch64-oe-linux -C linker=/home/brgl/workspace/veki-kirkstone/build/tmp-glibc/work/armv8a-oe-linux/gstreamer1.0-rusoto/0.6.0-r0/wrapper/target-rust-ccld -L dependency=/home/brgl/workspace/veki-kirkstone/build/tmp-glibc/work/armv8a-oe-linux/gstreamer1.0-rusoto/0.6.0-r0/build/target/aarch64-oe-linux/release/deps -L dependency=/home/brgl/workspace/veki-kirkstone/build/tmp-glibc/work/armv8a-oe-linux/gstreamer1.0-rusoto/0.6.0-r0/build/target/release/deps --extern libc=/home/brgl/workspace/veki-kirkstone/build/tmp-glibc/work/armv8a-oe-linux/gstreamer1.0-rusoto/0.6.0-r0/build/target/aarch64-oe-linux/release/deps/liblibc-f4d4da8aaaf5cc3b.rmeta --cap-lints allow -L /home/brgl/workspace/veki-kirkstone/build/tmp-glibc/work/armv8a-oe-linux/gstreamer1.0-rusoto/0.6.0-r0/recipe-sysroot/usr/lib/rust --remap-path-prefix=/home/brgl/workspace/veki-kirkstone/build/tmp-glibc/work/armv8a-oe-linux/gstreamer1.0-rusoto/0.6.0-r0=/usr/src/debug/gstreamer1.0-rusoto/0.6.0-r0` | warning: target json file contains unused fields: has-elf-tls | | error: failed to run custom build command for `num-traits v0.2.12` | | Caused by: | process didn't exit successfully: `/home/brgl/workspace/veki-kirkstone/build/tmp-glibc/work/armv8a-oe-linux/gstreamer1.0-rusoto/0.6.0-r0/build/target/release/build/num-traits-399d85941461afdf/build-script-build` (exit status: 101) | --- stderr | warning: target json file contains unused fields: has-elf-tls | | warning: target json file contains unused fields: has-elf-tls | | error[E0463]: can't find crate for `std` | | | = note: the `aarch64-oe-linux` target may not be installed | = help: consider downloading the target with `rustup target add aarch64-oe-linux` | | error: aborting due to previous error | | For more information about this error, try `rustc --explain E0463`. | warning: target json file contains unused fields: has-elf-tls | | warning: target json file contains unused fields: has-elf-tls | | error[E0463]: can't find crate for `core` | | | = note: the `aarch64-oe-linux` target may not be installed | = help: consider downloading the target with `rustup target add aarch64-oe-linux` | | error[E0463]: can't find crate for `compiler_builtins` | | error: aborting due to 2 previous errors | | For more information about this error, try `rustc --explain E0463`. | warning: autocfg could not probe for `std` | warning: target json file contains unused fields: has-elf-tls | | warning: target json file contains unused fields: has-elf-tls | | error[E0463]: can't find crate for `std` | | | = note: the `aarch64-oe-linux` target may not be installed | = help: consider downloading the target with `rustup target add aarch64-oe-linux` | | error: aborting due to previous error | | For more information about this error, try `rustc --explain E0463`. | thread 'main' panicked at 'i128 support was not detected!', /home/brgl/workspace/veki-kirkstone/build/tmp-glibc/work/armv8a-oe-linux/gstreamer1.0-rusoto/0.6.0-r0/cargo_home/bitbake/num-traits-0.2.12/build.rs:10:9 | stack backtrace: | 0: std::panicking::begin_panic |at /home/brgl/workspace/veki-kirkstone/build/tmp-glibc/work/x86_64-linux/rust-native/1.59.0-r0/rustc-1.59.0-src/library/std/src/panicking.rs:525:12 | 1: build_script_build::main |at ./build.rs:10:9 | 2: core::ops::function::FnOnce::call_once |at /home/brgl/workspace/veki-kirkstone/build/tmp-glibc/work/x86_64-linux/rust-native/1.59.0-r0/rustc-1.59.0-src/library/core/src/ops/function.rs:227:5 | note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. | warning: build failed, waiting for other jobs to finish... | Building [>] 134/254: num-integer(build), quote... | Building [>] 135/254: quote, http-body, typenum... | warning: `paste` (lib) generated 2 warnings (2
Re: [OE-core][PATCH] python3: make pydoc rdepend on python3-io
On Sun, Mar 7, 2021 at 4:19 PM Bartosz Golaszewski wrote:
>
> From: Bartosz Golaszewski
>
> pydoc needs tempfile (provided by python3-io) to work. Add python3-io
> to its RDEPENDS.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> meta/recipes-devtools/python/python3_3.9.2.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/python/python3_3.9.2.bb
> b/meta/recipes-devtools/python/python3_3.9.2.bb
> index af1843a180..c5e47eec4f 100644
> --- a/meta/recipes-devtools/python/python3_3.9.2.bb
> +++ b/meta/recipes-devtools/python/python3_3.9.2.bb
> @@ -371,6 +371,7 @@ RDEPENDS_${PN}-ptest_append_libc-glibc = "
> locale-base-tr-tr.iso-8859-9"
> RDEPENDS_${PN}-tkinter += "${@bb.utils.contains('PACKAGECONFIG', 'tk', 'tk
> tk-lib', '', d)}"
> RDEPENDS_${PN}-idle += "${@bb.utils.contains('PACKAGECONFIG', 'tk',
> '${PN}-tkinter tcl', '', d)}"
> RDEPENDS_${PN}-dev = ""
> +RDEPENDS_${PN}-pydoc += "${PN}-io"
>
> RDEPENDS_${PN}-tests_append_class-target = " ${MLPREFIX}bash"
> RDEPENDS_${PN}-tests_append_class-nativesdk = " ${MLPREFIX}bash"
> --
> 2.30.1
>
Gentle ping.
Bartosz
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149579):
https://lists.openembedded.org/g/openembedded-core/message/149579
Mute This Topic: https://lists.openembedded.org/mt/81150661/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] python3: make pydoc rdepend on python3-io
From: Bartosz Golaszewski
pydoc needs tempfile (provided by python3-io) to work. Add python3-io
to its RDEPENDS.
Signed-off-by: Bartosz Golaszewski
---
meta/recipes-devtools/python/python3_3.9.2.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/python/python3_3.9.2.bb
b/meta/recipes-devtools/python/python3_3.9.2.bb
index af1843a180..c5e47eec4f 100644
--- a/meta/recipes-devtools/python/python3_3.9.2.bb
+++ b/meta/recipes-devtools/python/python3_3.9.2.bb
@@ -371,6 +371,7 @@ RDEPENDS_${PN}-ptest_append_libc-glibc = "
locale-base-tr-tr.iso-8859-9"
RDEPENDS_${PN}-tkinter += "${@bb.utils.contains('PACKAGECONFIG', 'tk', 'tk
tk-lib', '', d)}"
RDEPENDS_${PN}-idle += "${@bb.utils.contains('PACKAGECONFIG', 'tk',
'${PN}-tkinter tcl', '', d)}"
RDEPENDS_${PN}-dev = ""
+RDEPENDS_${PN}-pydoc += "${PN}-io"
RDEPENDS_${PN}-tests_append_class-target = " ${MLPREFIX}bash"
RDEPENDS_${PN}-tests_append_class-nativesdk = " ${MLPREFIX}bash"
--
2.30.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149082):
https://lists.openembedded.org/g/openembedded-core/message/149082
Mute This Topic: https://lists.openembedded.org/mt/81150661/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] [meta-OE][PATCH v3] image.bbclass: deploy image artifacts in stages
On Fri, May 15, 2020 at 7:56 AM Richard Purdie wrote: > > On Tue, 2020-05-12 at 16:05 +0200, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > Make each IMAGE_CMD task an sstate task with its own IMGDEPLOYDIR > > override. This way each generated set of artifacts is deployed as soon > > as it's ready instead of the do_image_complete task handling the entire > > deployement. This allows us to better fine-tune dependencies e.g. we > > can make do_image_wic depend on fitImage task which can in turn depend > > on do_image_ext4. > > > > We need delete the IMGDEPLOYDIR variable from the data object passed > > to each image task so that it gets expanded with the correct override. > > > > In order to make sure that tasks added to SSTATETASKS in anonymous python > > functions are correctly setup, move the code that assigns pre- and > > postfuncs to an event handler invoked on bb.event.RecipeTaskPreProcess > > in sstate.bbclass. This event is fired right after the anonymous > > functions. > > > > Signed-off-by: Bartosz Golaszewski > > --- > > Changes since v2: > > - dropped the qemuboot patch (already upstream) > > - switched to % string formatting instead of using .format() for consistency > > Thanks, I included this in automated testing and its shown a few > issues: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/943 > > "oe-selftest -r > sstatetests.SStateTests.test_sstate_nativelsbstring_same_hash " should > reproduce > > I think multiconfig.MultiConfig.test_multiconfig and > multiconfig.MultiConfig.test_multiconfig are also related but its > harder to be sure. > > package.PackageTests.test_gdb_hardlink_debug isn't related in there. > runqemu.RunqemuTests.test_boot_deploy_hddimg and > runqemu.RunqemuTests.test_boot_machine_iso could be, not sure. > Hi Richard, I've been trying to figure out what's wrong on and off for some time now but I'm afraid I don't get the idea behind the NATIVELSBSTRING variable and how it affects generating the hashes. Could you maybe point me in the right direction because so far I've been unable to find a way to fix these tests. Best regards, Bartosz -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#141303): https://lists.openembedded.org/g/openembedded-core/message/141303 Mute This Topic: https://lists.openembedded.org/mt/74158924/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] [meta-OE][PATCH v3] image.bbclass: deploy image artifacts in stages
wt., 12 maj 2020 o 16:05 Bartosz Golaszewski napisał(a): > > From: Bartosz Golaszewski > > Make each IMAGE_CMD task an sstate task with its own IMGDEPLOYDIR > override. This way each generated set of artifacts is deployed as soon > as it's ready instead of the do_image_complete task handling the entire > deployement. This allows us to better fine-tune dependencies e.g. we > can make do_image_wic depend on fitImage task which can in turn depend > on do_image_ext4. > > We need delete the IMGDEPLOYDIR variable from the data object passed > to each image task so that it gets expanded with the correct override. > > In order to make sure that tasks added to SSTATETASKS in anonymous python > functions are correctly setup, move the code that assigns pre- and > postfuncs to an event handler invoked on bb.event.RecipeTaskPreProcess > in sstate.bbclass. This event is fired right after the anonymous > functions. > > Signed-off-by: Bartosz Golaszewski > --- Hi all! I just noticed I tagged this patch as [meta-OE] instead of [OE-core] - hope it's not an issue? Should I resend it with a correct tag? Bartosz -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138274): https://lists.openembedded.org/g/openembedded-core/message/138274 Mute This Topic: https://lists.openembedded.org/mt/74158924/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [meta-OE][PATCH v3] image.bbclass: deploy image artifacts in stages
From: Bartosz Golaszewski
Make each IMAGE_CMD task an sstate task with its own IMGDEPLOYDIR
override. This way each generated set of artifacts is deployed as soon
as it's ready instead of the do_image_complete task handling the entire
deployement. This allows us to better fine-tune dependencies e.g. we
can make do_image_wic depend on fitImage task which can in turn depend
on do_image_ext4.
We need delete the IMGDEPLOYDIR variable from the data object passed
to each image task so that it gets expanded with the correct override.
In order to make sure that tasks added to SSTATETASKS in anonymous python
functions are correctly setup, move the code that assigns pre- and
postfuncs to an event handler invoked on bb.event.RecipeTaskPreProcess
in sstate.bbclass. This event is fired right after the anonymous
functions.
Signed-off-by: Bartosz Golaszewski
---
Changes since v2:
- dropped the qemuboot patch (already upstream)
- switched to % string formatting instead of using .format() for consistency
meta/classes/image.bbclass | 17 +
meta/classes/sstate.bbclass | 4
2 files changed, 21 insertions(+)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 694b58fc9f..3cf8ceb2d6 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -425,10 +425,12 @@ python () {
# date/time values. It will get expanded at execution time.
# Similarly TMPDIR since otherwise we see QA stamp comparision problems
# Expand PV else it can trigger get_srcrev which can fail due to these
variables being unset
+# Delete IMGDEPLOYDIR so that each task gets its own, overriden value
localdata.setVar('PV', d.getVar('PV'))
localdata.delVar('DATETIME')
localdata.delVar('DATE')
localdata.delVar('TMPDIR')
+localdata.delVar('IMGDEPLOYDIR')
vardepsexclude = (d.getVarFlag('IMAGE_CMD_' + realt, 'vardepsexclude',
True) or '').split()
for dep in vardepsexclude:
localdata.delVar(dep)
@@ -499,6 +501,21 @@ python () {
bb.debug(2, "Adding task %s before %s, after %s" % (task,
'do_image_complete', after))
bb.build.addtask(task, 'do_image_complete', after, d)
+
+imgdeploydir = d.getVar('IMGDEPLOYDIR')
+task_override = task[3:].replace('_', '-') # 'do_image_ext4' becomes
'image-ext4'
+taskdeploydir = '%s/deploy-%s-%s' % (os.path.dirname(imgdeploydir),
+ d.getVar('PN'), task_override)
+
+# Each image task gets its own IMGDEPLOYDIR directory and is added to
+# SSTATETASKS. This way every set of artifacts gets deployed right
after
+# the do_image_foo task completes.
+d.setVar('IMGDEPLOYDIR_task-%s' % task_override, taskdeploydir)
+d.appendVar('SSTATETASKS', ' %s' % task)
+d.setVarFlag(task, 'sstate-inputdirs', taskdeploydir)
+d.setVarFlag(task, 'sstate-outputdirs', d.getVar('DEPLOY_DIR_IMAGE'))
+d.setVarFlag(task, 'cleandirs', taskdeploydir)
+d.setVar('SSTATE_SKIP_CREATION_task-%s' % task_override, '1')
}
#
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index aa9c30b4e1..5bdada673f 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -138,13 +138,17 @@ python () {
d.setVar('SSTATE_EXTRAPATH', "${NATIVELSBSTRING}/")
d.setVar('BB_HASHFILENAME', "True ${SSTATE_PKGSPEC} ${SSTATE_SWSPEC}")
d.setVar('SSTATE_EXTRAPATHWILDCARD', "${NATIVELSBSTRING}/")
+}
+python sstate_setup_tasks() {
unique_tasks = sorted(set((d.getVar('SSTATETASKS') or "").split()))
d.setVar('SSTATETASKS', " ".join(unique_tasks))
for task in unique_tasks:
d.prependVarFlag(task, 'prefuncs', "sstate_task_prefunc ")
d.appendVarFlag(task, 'postfuncs', " sstate_task_postfunc")
}
+addhandler sstate_setup_tasks
+sstate_setup_tasks[eventmask] = "bb.event.RecipeTaskPreProcess"
def sstate_init(task, d):
ss = {}
--
2.25.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138161):
https://lists.openembedded.org/g/openembedded-core/message/138161
Mute This Topic: https://lists.openembedded.org/mt/74158924/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 2/2] image.bbclass: deploy image artifacts in stages
śr., 15 kwi 2020 o 12:32 Richard Purdie napisał(a): > > > > > > > > Gentle ping. > > Gentle reminder that we're in the middle of sorting out a release. This > will not merge until after the release and I don't have the cycles for > review of this kind of change right now. > Got it, I'll get back to you after the release then. > FWIW I still don't like the way this integrates into sstate and I want > to spend some time trying to find a better way. I don't have any > constructive suggestion as to what that would look like so I haven't > replied, I simply don't know and that isn't a useful answer to you. > Sure, thanks. Despite my best efforts I couldn't figure out any solution without touching sstate. > You've also ignored my request to follow the coding style used in the > rest of the class code :(. > Indeed, although "forgot" would describe it better. :) Bart -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#137237): https://lists.openembedded.org/g/openembedded-core/message/137237 Mute This Topic: https://lists.openembedded.org/mt/72816245/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 2/2] image.bbclass: deploy image artifacts in stages
pon., 6 kwi 2020 o 19:02 Bartosz Golaszewski napisał(a):
>
> From: Bartosz Golaszewski
>
> Make each IMAGE_CMD task an sstate task with its own IMGDEPLOYDIR
> override. This way each generated set of artifacts is deployed as soon
> as it's ready instead of the do_image_complete task handling the entire
> deployement. This allows us to better fine-tune dependencies e.g. we
> can make do_image_wic depend on fitImage task which can in turn depend
> on do_image_ext4.
>
> We need delete the IMGDEPLOYDIR variable from the data object passed
> to each image task so that it gets expanded with the correct override.
>
> In order to make sure that tasks added to SSTATETASKS in anonymous python
> functions are correctly setup, move the code that assigns pre- and
> postfuncs to an event handler invoked on bb.event.RecipeTaskPreProcess
> in sstate.bbclass. This event is fired right after the anonymous
> functions.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> meta/classes/image.bbclass | 17 +
> meta/classes/sstate.bbclass | 4
> 2 files changed, 21 insertions(+)
>
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 07aa1f1fa5..ffd63aa82a 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -428,10 +428,12 @@ python () {
> # date/time values. It will get expanded at execution time.
> # Similarly TMPDIR since otherwise we see QA stamp comparision
> problems
> # Expand PV else it can trigger get_srcrev which can fail due to
> these variables being unset
> +# Delete IMGDEPLOYDIR so that each task gets its own, overriden value
> localdata.setVar('PV', d.getVar('PV'))
> localdata.delVar('DATETIME')
> localdata.delVar('DATE')
> localdata.delVar('TMPDIR')
> +localdata.delVar('IMGDEPLOYDIR')
> vardepsexclude = (d.getVarFlag('IMAGE_CMD_' + realt,
> 'vardepsexclude', True) or '').split()
> for dep in vardepsexclude:
> localdata.delVar(dep)
> @@ -502,6 +504,21 @@ python () {
>
> bb.debug(2, "Adding task %s before %s, after %s" % (task,
> 'do_image_complete', after))
> bb.build.addtask(task, 'do_image_complete', after, d)
> +
> +imgdeploydir = d.getVar('IMGDEPLOYDIR')
> +task_override = task[3:].replace('_', '-') # 'do_image_ext4' becomes
> 'image-ext4'
> +taskdeploydir =
> '{}/deploy-{}-{}'.format(os.path.dirname(imgdeploydir),
> + d.getVar('PN'),
> task_override)
> +
> +# Each image task gets its own IMGDEPLOYDIR directory and is added to
> +# SSTATETASKS. This way every set of artifacts gets deployed right
> after
> +# the do_image_foo task completes.
> +d.setVar('IMGDEPLOYDIR_task-{}'.format(task_override), taskdeploydir)
> +d.appendVar('SSTATETASKS', ' {}'.format(task))
> +d.setVarFlag(task, 'sstate-inputdirs', taskdeploydir)
> +d.setVarFlag(task, 'sstate-outputdirs', d.getVar('DEPLOY_DIR_IMAGE'))
> +d.setVarFlag(task, 'cleandirs', taskdeploydir)
> +d.setVar('SSTATE_SKIP_CREATION_task-{}'.format(task_override), '1')
> }
>
> #
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index c73c3b42a7..3c71312010 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -138,13 +138,17 @@ python () {
> d.setVar('SSTATE_EXTRAPATH', "${NATIVELSBSTRING}/")
> d.setVar('BB_HASHFILENAME', "True ${SSTATE_PKGSPEC}
> ${SSTATE_SWSPEC}")
> d.setVar('SSTATE_EXTRAPATHWILDCARD', "${NATIVELSBSTRING}/")
> +}
>
> +python sstate_setup_tasks() {
> unique_tasks = sorted(set((d.getVar('SSTATETASKS') or "").split()))
> d.setVar('SSTATETASKS', " ".join(unique_tasks))
> for task in unique_tasks:
> d.prependVarFlag(task, 'prefuncs', "sstate_task_prefunc ")
> d.appendVarFlag(task, 'postfuncs', " sstate_task_postfunc")
> }
> +addhandler sstate_setup_tasks
> +sstate_setup_tasks[eventmask] = "bb.event.RecipeTaskPreProcess"
>
> def sstate_init(task, d):
> ss = {}
> --
> 2.25.0
>
Gentle ping.
Bart
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137235):
https://lists.openembedded.org/g/openembedded-core/message/137235
Mute This Topic: https://lists.openembedded.org/mt/72816245/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 0/2] introduce multi-state image deployment
From: Bartosz Golaszewski Hi Richard et al, This is another shot at multi-stage image deployment. This time around I managed to fix the problem with changing task hashes and anonymous python functions ordering by simply moving the code assigning pre- and postfuncs for sstate into an even handler invoked right after all anonymous python code is run. Seems to work fine and there's no need to deltask do_package anymore. Just like before: each image task becomes an sstate task and handles the deployment of the artifacts it generates. Files created by tasks other than IMAGE_CMD are still deployed by do_image_complete. The dm-verity problem I'm trying to solve is described here: https://lists.openembedded.org/g/openembedded-core/message/136203 Bartosz Golaszewski (2): qemuboot.bbclass: don't redefine IMGDEPLOYDIR image.bbclass: deploy image artifacts in stages meta/classes/image.bbclass| 17 + meta/classes/qemuboot.bbclass | 1 - meta/classes/sstate.bbclass | 4 3 files changed, 21 insertions(+), 1 deletion(-) -- 2.25.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#137073): https://lists.openembedded.org/g/openembedded-core/message/137073 Mute This Topic: https://lists.openembedded.org/mt/72816243/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 2/2] image.bbclass: deploy image artifacts in stages
From: Bartosz Golaszewski
Make each IMAGE_CMD task an sstate task with its own IMGDEPLOYDIR
override. This way each generated set of artifacts is deployed as soon
as it's ready instead of the do_image_complete task handling the entire
deployement. This allows us to better fine-tune dependencies e.g. we
can make do_image_wic depend on fitImage task which can in turn depend
on do_image_ext4.
We need delete the IMGDEPLOYDIR variable from the data object passed
to each image task so that it gets expanded with the correct override.
In order to make sure that tasks added to SSTATETASKS in anonymous python
functions are correctly setup, move the code that assigns pre- and
postfuncs to an event handler invoked on bb.event.RecipeTaskPreProcess
in sstate.bbclass. This event is fired right after the anonymous
functions.
Signed-off-by: Bartosz Golaszewski
---
meta/classes/image.bbclass | 17 +
meta/classes/sstate.bbclass | 4
2 files changed, 21 insertions(+)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 07aa1f1fa5..ffd63aa82a 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -428,10 +428,12 @@ python () {
# date/time values. It will get expanded at execution time.
# Similarly TMPDIR since otherwise we see QA stamp comparision problems
# Expand PV else it can trigger get_srcrev which can fail due to these
variables being unset
+# Delete IMGDEPLOYDIR so that each task gets its own, overriden value
localdata.setVar('PV', d.getVar('PV'))
localdata.delVar('DATETIME')
localdata.delVar('DATE')
localdata.delVar('TMPDIR')
+localdata.delVar('IMGDEPLOYDIR')
vardepsexclude = (d.getVarFlag('IMAGE_CMD_' + realt, 'vardepsexclude',
True) or '').split()
for dep in vardepsexclude:
localdata.delVar(dep)
@@ -502,6 +504,21 @@ python () {
bb.debug(2, "Adding task %s before %s, after %s" % (task,
'do_image_complete', after))
bb.build.addtask(task, 'do_image_complete', after, d)
+
+imgdeploydir = d.getVar('IMGDEPLOYDIR')
+task_override = task[3:].replace('_', '-') # 'do_image_ext4' becomes
'image-ext4'
+taskdeploydir = '{}/deploy-{}-{}'.format(os.path.dirname(imgdeploydir),
+ d.getVar('PN'), task_override)
+
+# Each image task gets its own IMGDEPLOYDIR directory and is added to
+# SSTATETASKS. This way every set of artifacts gets deployed right
after
+# the do_image_foo task completes.
+d.setVar('IMGDEPLOYDIR_task-{}'.format(task_override), taskdeploydir)
+d.appendVar('SSTATETASKS', ' {}'.format(task))
+d.setVarFlag(task, 'sstate-inputdirs', taskdeploydir)
+d.setVarFlag(task, 'sstate-outputdirs', d.getVar('DEPLOY_DIR_IMAGE'))
+d.setVarFlag(task, 'cleandirs', taskdeploydir)
+d.setVar('SSTATE_SKIP_CREATION_task-{}'.format(task_override), '1')
}
#
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index c73c3b42a7..3c71312010 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -138,13 +138,17 @@ python () {
d.setVar('SSTATE_EXTRAPATH', "${NATIVELSBSTRING}/")
d.setVar('BB_HASHFILENAME', "True ${SSTATE_PKGSPEC} ${SSTATE_SWSPEC}")
d.setVar('SSTATE_EXTRAPATHWILDCARD', "${NATIVELSBSTRING}/")
+}
+python sstate_setup_tasks() {
unique_tasks = sorted(set((d.getVar('SSTATETASKS') or "").split()))
d.setVar('SSTATETASKS', " ".join(unique_tasks))
for task in unique_tasks:
d.prependVarFlag(task, 'prefuncs', "sstate_task_prefunc ")
d.appendVarFlag(task, 'postfuncs', " sstate_task_postfunc")
}
+addhandler sstate_setup_tasks
+sstate_setup_tasks[eventmask] = "bb.event.RecipeTaskPreProcess"
def sstate_init(task, d):
ss = {}
--
2.25.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137075):
https://lists.openembedded.org/g/openembedded-core/message/137075
Mute This Topic: https://lists.openembedded.org/mt/72816245/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 1/2] qemuboot.bbclass: don't redefine IMGDEPLOYDIR
From: Bartosz Golaszewski
This variable is already defined in image.bbclass and there's not need
to redefine it here.
Signed-off-by: Bartosz Golaszewski
---
meta/classes/qemuboot.bbclass | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 54044c38da..68f7a03619 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -83,7 +83,6 @@ QB_DRIVE_TYPE ?= "/dev/sd"
# Create qemuboot.conf
addtask do_write_qemuboot_conf after do_rootfs before do_image
-IMGDEPLOYDIR ?= "${WORKDIR}/deploy-${PN}-image-complete"
def qemuboot_vars(d):
build_vars = ['MACHINE', 'TUNE_ARCH', 'DEPLOY_DIR_IMAGE',
--
2.25.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137074):
https://lists.openembedded.org/g/openembedded-core/message/137074
Mute This Topic: https://lists.openembedded.org/mt/72816244/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][RFC PATCH 1/2] qemuboot.bbclass: don't redefine IMGDEPLOYDIR
pon., 23 mar 2020 o 18:28 Bartosz Golaszewski napisał(a):
>
> From: Bartosz Golaszewski
>
> This variable is already defined in image.bbclass and there's not need
> to redefine it here.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> meta/classes/qemuboot.bbclass | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
> index 54044c38da..68f7a03619 100644
> --- a/meta/classes/qemuboot.bbclass
> +++ b/meta/classes/qemuboot.bbclass
> @@ -83,7 +83,6 @@ QB_DRIVE_TYPE ?= "/dev/sd"
>
> # Create qemuboot.conf
> addtask do_write_qemuboot_conf after do_rootfs before do_image
> -IMGDEPLOYDIR ?= "${WORKDIR}/deploy-${PN}-image-complete"
>
> def qemuboot_vars(d):
> build_vars = ['MACHINE', 'TUNE_ARCH', 'DEPLOY_DIR_IMAGE',
> --
> 2.19.1
>
Hi Richard,
this patch can be applied without waiting for the v2 of the image
deployment patch. Would you mind picking it up into your tree?
Bartosz
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136959):
https://lists.openembedded.org/g/openembedded-core/message/136959
Mute This Topic: https://lists.openembedded.org/mt/72497791/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][RFC PATCH 2/2] image.bbclass: deploy image artifacts in stages
pon., 30 mar 2020 o 18:31 Richard Purdie
napisał(a):
>
> On Mon, 2020-03-30 at 18:26 +0200, Bartosz Golaszewski wrote:
> > pon., 23 mar 2020 o 18:28 Bartosz Golaszewski
> > napisał(a):
> > > From: Bartosz Golaszewski
> > >
> > > Make each IMAGE_CMD task an sstate task with its own IMGDEPLOYDIR
> > > override. This way each generated set of artifacts is deployed as
> > > soon
> > > as it's ready instead of the do_image_complete task handling the
> > > entire
> > > deployement. This allows us to better fine-tune dependencies e.g.
> > > we
> > > can make do_image_wic depend on fitImage task which can in turn
> > > depend
> > > on do_image_ext4.
> > >
> > > We need to completely delete the do_package task in order to avoid
> > > problems with task hash changes as well as delete the IMGDEPLOYDIR
> > > variable from the data object passed to each image task so that
> > > it's
> > > expanded with the correct override.
> > >
> > > Signed-off-by: Bartosz Golaszewski
> >
> > It's been a week. Can I get some feedback on this? Is the idea at
> > least remotely acceptable/can we build upon it?
>
> FWIW at a quick glance I didn't think it was too bad.
>
> I think there will be corner cases to resolve which I was hoping to
> look into and give some pointers to but I haven't had the time.
>
> I'm hoping somehow we can improve the FIXME you mention too.
>
Yeah, after thinking about it more, I figured that if a task signature
changes, then something is wrong. I guess it's because we end up
assigning pre- and postfuncs to tasks twice: once in anonymous python
code from image.bbclass and then from sstate.bbclass. Maybe we should
provide a python helper for explicitly making a task an sstate task
and - when using it - not add said task to SSTATETASKS, so that
sstate.bbclass code ignores it? Or maybe this anonymous function
should become an event handler invoked at event.RecipeParsed?
> The do_package change should probably be separated out - I'm guessing
> we did noexec there for a reason though?
>
I couldn't find a reason. Maybe it's a leftover from some previous,
now cleaned up change.
> Also, you used {}.format which I'm torn on since most of the codebase
> uses the other approach.
>
I couldn't find any official guidelines for that. {} is the preferred
way in Python. Maybe it's time to start slowly converting the bitbake
codebase?
> Its too late to get this into 3.1 and that is where I'm focusing my
> effort right now but I think this is probably going the right way.
>
Sure, I didn't expect it to go into the next release. If you're happy
with this direction I'll try to improve it and send a v2.
Bartosz
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136877):
https://lists.openembedded.org/g/openembedded-core/message/136877
Mute This Topic: https://lists.openembedded.org/mt/72497792/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][RFC PATCH 2/2] image.bbclass: deploy image artifacts in stages
pon., 23 mar 2020 o 18:28 Bartosz Golaszewski napisał(a): > > From: Bartosz Golaszewski > > Make each IMAGE_CMD task an sstate task with its own IMGDEPLOYDIR > override. This way each generated set of artifacts is deployed as soon > as it's ready instead of the do_image_complete task handling the entire > deployement. This allows us to better fine-tune dependencies e.g. we > can make do_image_wic depend on fitImage task which can in turn depend > on do_image_ext4. > > We need to completely delete the do_package task in order to avoid > problems with task hash changes as well as delete the IMGDEPLOYDIR > variable from the data object passed to each image task so that it's > expanded with the correct override. > > Signed-off-by: Bartosz Golaszewski Hi all! It's been a week. Can I get some feedback on this? Is the idea at least remotely acceptable/can we build upon it? Bart -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#136859): https://lists.openembedded.org/g/openembedded-core/message/136859 Mute This Topic: https://lists.openembedded.org/mt/72497792/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][RFC PATCH 1/2] qemuboot.bbclass: don't redefine IMGDEPLOYDIR
From: Bartosz Golaszewski
This variable is already defined in image.bbclass and there's not need
to redefine it here.
Signed-off-by: Bartosz Golaszewski
---
meta/classes/qemuboot.bbclass | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 54044c38da..68f7a03619 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -83,7 +83,6 @@ QB_DRIVE_TYPE ?= "/dev/sd"
# Create qemuboot.conf
addtask do_write_qemuboot_conf after do_rootfs before do_image
-IMGDEPLOYDIR ?= "${WORKDIR}/deploy-${PN}-image-complete"
def qemuboot_vars(d):
build_vars = ['MACHINE', 'TUNE_ARCH', 'DEPLOY_DIR_IMAGE',
--
2.19.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136615):
https://lists.openembedded.org/g/openembedded-core/message/136615
Mute This Topic: https://lists.openembedded.org/mt/72497791/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][RFC PATCH 2/2] image.bbclass: deploy image artifacts in stages
From: Bartosz Golaszewski
Make each IMAGE_CMD task an sstate task with its own IMGDEPLOYDIR
override. This way each generated set of artifacts is deployed as soon
as it's ready instead of the do_image_complete task handling the entire
deployement. This allows us to better fine-tune dependencies e.g. we
can make do_image_wic depend on fitImage task which can in turn depend
on do_image_ext4.
We need to completely delete the do_package task in order to avoid
problems with task hash changes as well as delete the IMGDEPLOYDIR
variable from the data object passed to each image task so that it's
expanded with the correct override.
Signed-off-by: Bartosz Golaszewski
---
meta/classes/image.bbclass | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 07aa1f1fa5..3487e2abe4 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -428,10 +428,12 @@ python () {
# date/time values. It will get expanded at execution time.
# Similarly TMPDIR since otherwise we see QA stamp comparision problems
# Expand PV else it can trigger get_srcrev which can fail due to these
variables being unset
+# Delete IMGDEPLOYDIR so that each task gets its own, overriden value
localdata.setVar('PV', d.getVar('PV'))
localdata.delVar('DATETIME')
localdata.delVar('DATE')
localdata.delVar('TMPDIR')
+localdata.delVar('IMGDEPLOYDIR')
vardepsexclude = (d.getVarFlag('IMAGE_CMD_' + realt, 'vardepsexclude',
True) or '').split()
for dep in vardepsexclude:
localdata.delVar(dep)
@@ -502,6 +504,28 @@ python () {
bb.debug(2, "Adding task %s before %s, after %s" % (task,
'do_image_complete', after))
bb.build.addtask(task, 'do_image_complete', after, d)
+
+imgdeploydir = d.getVar('IMGDEPLOYDIR')
+task_override = task[3:].replace('_', '-') # 'do_image_ext4' becomes
'image-ext4'
+taskdeploydir = '{}/deploy-{}-{}'.format(os.path.dirname(imgdeploydir),
+ d.getVar('PN'), task_override)
+
+# Each image task gets its own IMGDEPLOYDIR and becomes part of
SSTATETASKS
+# so that each set of artifacts be deployed right after the task
completes.
+d.setVar('IMGDEPLOYDIR_task-{}'.format(task_override), taskdeploydir)
+d.appendVar('SSTATETASKS', ' {}'.format(task))
+d.setVarFlag(task, 'sstate-inputdirs', taskdeploydir)
+d.setVarFlag(task, 'sstate-outputdirs', d.getVar('DEPLOY_DIR_IMAGE'))
+d.setVarFlag(task, 'cleandirs', taskdeploydir)
+d.setVar('SSTATE_SKIP_CREATION_task-{}'.format(task_override), '1')
+
+# FIXME We need to do this manually if we want to set the sstate flags
from
+# python code. The reason for this is that sstate.bbclass does this
from an
+# annonymous python function too and we can't guarantee correct
ordering.
+# This isn't a problem for most recipes as they define sstate tasks
statically
+# with bitbake variables.
+d.prependVarFlag(task, 'prefuncs', 'sstate_task_prefunc ')
+d.appendVarFlag(task, 'postfuncs', ' sstate_task_postfunc')
}
#
@@ -611,7 +635,7 @@ do_compile[noexec] = "1"
do_install[noexec] = "1"
deltask do_populate_lic
deltask do_populate_sysroot
-do_package[noexec] = "1"
+deltask do_package
deltask do_package_qa
do_packagedata[noexec] = "1"
deltask do_package_write_ipk
--
2.19.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136616):
https://lists.openembedded.org/g/openembedded-core/message/136616
Mute This Topic: https://lists.openembedded.org/mt/72497792/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][RFC PATCH 0/2] introduce multi-state image deployment
From: Bartosz Golaszewski Hi Richard, please take a look at the following patch series. It's a follow up to my previous attempt[1] and is also related to the dm-verity problem I described on the list[2]. This time instead of having hardcoded two stages of deployment for simple and composed image types, each image task becomes an sstate task and handles the deployment of the artifacts it generates. Files created by tasks other than IMAGE_CMD are still deployed by do_image_complete. I'm tagging this series as RFC but actually the code turned out to be surprisingly clean and straightforward. Please let me know what you think. [1] https://lists.openembedded.org/g/openembedded-core/message/136526 [2] https://lists.openembedded.org/g/openembedded-core/message/136203 Bartosz Golaszewski (2): qemuboot.bbclass: don't redefine IMGDEPLOYDIR image.bbclass: deploy image artifacts in stages meta/classes/image.bbclass| 26 +- meta/classes/qemuboot.bbclass | 1 - 2 files changed, 25 insertions(+), 2 deletions(-) -- 2.19.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#136614): https://lists.openembedded.org/g/openembedded-core/message/136614 Mute This Topic: https://lists.openembedded.org/mt/72497789/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] [RFC PATCH 0/2] image.bbclass: support two-stage deployment of image artifacts
pt., 20 mar 2020 o 00:38 Richard Purdie
napisał(a):
>
> On Thu, 2020-03-19 at 19:20 +0100, Bartosz Golaszewski wrote:
> > If we'll really get to a point where we need to create a hierarchy of
> > multiple levels of image deployment, then maybe we should switch to
> > deploying each image right after it is created in its dedicated
> > do_image_ task, then we could really fine-tune the inter-task
> > dependencies. But we're not there yet and IMO currently it would be
> > overkill. The rule of thumb for me is not to add new interfaces
> > nobody asks for.
>
> Going back in time I'm the person who split the image pieces off from
> do_rootfs and split the different image commands into different tasks.
> I did this for several reasons but one was we were developing new task
> dependency code inside the image construction which was just crazy.
>
> I was wondering about the option of having the image task deploy the
> image earlier. I think that could be made to work. I think conceptually
> it makes more sense architecturally than adding in arbitrary new task
> levels to the existing structure.
>
> > This also makes your argument about adding a third category purely
> > theoretical: I don't see how we would need another category of images
> > anytime soon.
>
> I often think things like that but then new use cases come along...
>
> > Please do - I'm open for other ideas. Just please keep in mind:
> > there's obviously a problem with the current approach. I described it
> > in detail and it turned out Quentin had encountered it too and dealt
> > with it using a nasty workaround (fitImage deployed by the image
> > recipe and not the kernel). I'd like to fix it upstream and proposed
> > a solution that is IMO not horrible. I'd appreciate if we could reach
> > a compromise that wouldn't leave us with downstream hacks.
>
> I do understand there is a problem. We also have problems with people
> not understanding the code as it works today. Your proposal adds
> something else with is hard to explain to users ("Is my image simple or
> composed?") and whilst we can and do add complexity where we need to,
> I'm not yet convinced this change makes enough sense to have it.
>
> Changing the way image deployment works would in many ways be much
> easier for people to understand and makes the system more flexible
> without adding problematic terminology.
>
> > Please also note that sometimes "gets the job done" really is better
> > than not solving problems. Just look at initcall levels in the linux
> > kernel - they are similar to what I proposed here and serve as a
> > surrogate for real dependencies.
>
> We have piles of "get the job done" and also need to sometimes take a
> step back and see if we can do something better. Right now I think your
> proposal makes things worse and will be hard to explain to people. My
> instinct is we can do better here.
>
Fair enough. I don't quite agree and I'd like to hear other voices too
but I also don't want to waste time arguing either.
As I'm afraid that if I don't follow up on this myself, it will simply
be forgotten, I'm offering to spend some time figuring out per-task
deployment.
I started looking into it and figured that ideally we could have each
image task use a separate local-deploy directory and make them all
part of SSTATETASKS. Unfortunately a lot of places reference the
IMGDEPLOYDIR variable so it probably has to stay in some form. I
couldn't find any info on that - does bitbake offer anything like
"per-task variables"? Variables that expand to different values
depending on the task that calls them? Otherwise we could replace
IMGDEPLOYDIR calls with some helper function that would return a
different value depending on BB_CURRENTTASK?
Any advice on technicalities is welcome.
Bart
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/2] image.bbclass: support two-stage deployment of image artifacts
czw., 19 mar 2020 o 18:13 Richard Purdie napisał(a): > > On Thu, 2020-03-19 at 17:44 +0100, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > This is a follow-up to the discussion I started on the OE-core > > mailing > > list a couple days ago[1]. These patches propose to split the > > deployment > > of image artifacts into two stages where the first one includes all > > "regular" images and takes place before do_image_complete and the > > second > > is mostly aimed at wic right now and happens after do_image_complete. > > > > These patches work but I'm sending them as RFC mostly to continue the > > discussion about possible solutions for the circular dependencies > > between > > the rootfs and initramfs. > > > > [1] > > http://lists.openembedded.org/pipermail/openembedded-core/2020-March/294094.html > > This works fine until we have some new image type which then has to > depend on happening after wic. We then add a three stage process and so > on. Basically this feels like we're hardcoding something for one > specific use case which will later break and not scale to other > problems/solutions. > I understand you see it as controversial but let me try to convince you: If we'll really get to a point where we need to create a hierarchy of multiple levels of image deployment, then maybe we should switch to deploying each image right after it is created in its dedicated do_image_ task, then we could really fine-tune the inter-task dependencies. But we're not there yet and IMO currently it would be overkill. The rule of thumb for me is not to add new interfaces nobody asks for. The thing with wic is that it's aggregating other deployed images. What we're dealing with are *two* categories of image artifacts: let's call them simple and composed types. Obviously composed types may need to access the simple types and, due to the use-case I described in my previous thread, it's useful if we can depend on the tasks for simple and composed images separately. Maybe if I renamed the tasks: do_image_deploy_simple and do_image_deploy_composed it would look better than an ambiguous do_image_deploy_late. This also makes your argument about adding a third category purely theoretical: I don't see how we would need another category of images anytime soon. Even if we added another aggregating type (one could argue that hddimg qualifies as such) it could, with a 99% chance, run in parallel to wic and thus qualify as a deploy_late/composed image. > Sorry, I'm not convinced this is the right way to move forward. I will > try and have a think about what the right way is but sadly I don't get > much time to spend on specific problems like this :( > Please do - I'm open for other ideas. Just please keep in mind: there's obviously a problem with the current approach. I described it in detail and it turned out Quentin had encountered it too and dealt with it using a nasty workaround (fitImage deployed by the image recipe and not the kernel). I'd like to fix it upstream and proposed a solution that is IMO not horrible. I'd appreciate if we could reach a compromise that wouldn't leave us with downstream hacks. Please also note that sometimes "gets the job done" really is better than not solving problems. Just look at initcall levels in the linux kernel - they are similar to what I proposed here and serve as a surrogate for real dependencies. Best regards, Bartosz Golaszewski -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/2] image.bbclass: support two-stage deployment of image artifacts
czw., 19 mar 2020 o 17:44 Bartosz Golaszewski napisał(a): > > From: Bartosz Golaszewski > > This is a follow-up to the discussion I started on the OE-core mailing > list a couple days ago[1]. These patches propose to split the deployment > of image artifacts into two stages where the first one includes all > "regular" images and takes place before do_image_complete and the second > is mostly aimed at wic right now and happens after do_image_complete. > > These patches work but I'm sending them as RFC mostly to continue the > discussion about possible solutions for the circular dependencies between > the rootfs and initramfs. > > [1] > http://lists.openembedded.org/pipermail/openembedded-core/2020-March/294094.html > > Bartosz Golaszewski (2): > image.bbclass: add an intermediate deploy task > image.bbclass: deploy artifacts in two stages > > meta/classes/image.bbclass| 54 ++- > meta/classes/image_types.bbclass | 3 ++ > meta/classes/image_types_wic.bbclass | 4 +- > .../images/build-appliance-image_15.0.0.bb| 2 +- > 4 files changed, 47 insertions(+), 16 deletions(-) > > -- > 2.19.1 > Just for clarity: this what the task order would look like for a standard beaglebone-yocto image with these patches: do_prepare_recipe_sysroot (32199): log.do_prepare_recipe_sysroot.32199 do_deploy_source_date_epoch (32201): log.do_deploy_source_date_epoch.32201 do_rootfs (32246): log.do_rootfs.32246 do_write_qemuboot_conf (8655): log.do_write_qemuboot_conf.8655 do_image_qa (8657): log.do_image_qa.8657 do_image (8661): log.do_image.8661 do_image_ext4 (35128): log.do_image_ext4.35128 do_image_tar (35133): log.do_image_tar.35133 do_image_jffs2 (35136): log.do_image_jffs2.35136 do_image_deploy (35246): log.do_image_deploy.35246 do_image_complete (35262): log.do_image_complete.35262 do_rootfs_wicenv (35264): log.do_rootfs_wicenv.35264 do_populate_lic_deploy (35267): log.do_populate_lic_deploy.35267 do_image_wic (35283): log.do_image_wic.35283 do_image_deploy_late (35448): log.do_image_deploy_late.35448 Bart -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 1/2] image.bbclass: add an intermediate deploy task
From: Bartosz Golaszewski
Instead of using do_image_complete for both the deployment of image
artifacts into DEPLOY_DIR_IMAGE as well as calling the image
post-process commands, split the responsability between two separate
tasks: do_image_deploy will take care of the sstate deployment, while
do_image_complete will only do the post-processing. This way we can
make the dependencies more fine-grained.
Signed-off-by: Bartosz Golaszewski
---
meta/classes/image.bbclass | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 07aa1f1fa5..6e2b864f73 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -144,7 +144,7 @@ python () {
deps += " %s:%s" % (dep, task)
return deps
-d.appendVarFlag('do_image_complete', 'depends',
extraimage_getdepends('do_populate_sysroot'))
+d.appendVarFlag('do_image_deploy', 'depends',
extraimage_getdepends('do_populate_sysroot'))
deps = " " + imagetypes_getdepends(d)
d.appendVarFlag('do_rootfs', 'depends', deps)
@@ -264,6 +264,17 @@ do_image[dirs] = "${TOPDIR}"
do_image[umask] = "022"
addtask do_image after do_rootfs
+do_image_deploy() {
+# This is a placeholder really but it still needs to run for sstate
+# to correctly deploy the image artifacts.
+true
+}
+SSTATETASKS += "do_image_deploy"
+do_image_deploy[sstate-inputdirs] = "${IMGDEPLOYDIR}"
+do_image_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
+SSTATE_SKIP_CREATION_task-image-deploy = '1'
+addtask do_image_deploy after do_image before do_build
+
fakeroot python do_image_complete () {
from oe.utils import execute_pre_post_process
@@ -273,12 +284,8 @@ fakeroot python do_image_complete () {
}
do_image_complete[dirs] = "${TOPDIR}"
do_image_complete[umask] = "022"
-SSTATETASKS += "do_image_complete"
-SSTATE_SKIP_CREATION_task-image-complete = '1'
-do_image_complete[sstate-inputdirs] = "${IMGDEPLOYDIR}"
-do_image_complete[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
do_image_complete[stamp-extra-info] = "${MACHINE_ARCH}"
-addtask do_image_complete after do_image before do_build
+addtask do_image_complete after do_image_deploy before do_build
python do_image_complete_setscene () {
sstate_setscene(d)
}
@@ -500,8 +507,8 @@ python () {
d.appendVarFlag(task, 'vardeps', ' ' + ' '.join(vardeps))
d.appendVarFlag(task, 'vardepsexclude', ' DATETIME DATE ' + '
'.join(vardepsexclude))
-bb.debug(2, "Adding task %s before %s, after %s" % (task,
'do_image_complete', after))
-bb.build.addtask(task, 'do_image_complete', after, d)
+bb.debug(2, "Adding task %s before do_image_deploy, after %s" % (task,
after))
+bb.build.addtask(task, 'do_image_deploy', after, d)
}
#
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 0/2] image.bbclass: support two-stage deployment of image artifacts
From: Bartosz Golaszewski This is a follow-up to the discussion I started on the OE-core mailing list a couple days ago[1]. These patches propose to split the deployment of image artifacts into two stages where the first one includes all "regular" images and takes place before do_image_complete and the second is mostly aimed at wic right now and happens after do_image_complete. These patches work but I'm sending them as RFC mostly to continue the discussion about possible solutions for the circular dependencies between the rootfs and initramfs. [1] http://lists.openembedded.org/pipermail/openembedded-core/2020-March/294094.html Bartosz Golaszewski (2): image.bbclass: add an intermediate deploy task image.bbclass: deploy artifacts in two stages meta/classes/image.bbclass| 54 ++- meta/classes/image_types.bbclass | 3 ++ meta/classes/image_types_wic.bbclass | 4 +- .../images/build-appliance-image_15.0.0.bb| 2 +- 4 files changed, 47 insertions(+), 16 deletions(-) -- 2.19.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 2/2] image.bbclass: deploy artifacts in two stages
From: Bartosz Golaszewski
Currently the artifacts for all image types are deployed to the shared
space at the same time by the do_image_deploy task. This however creates
a problem with circular dependencies if we want to use certain security
features[1]. Because wic is designed to fetch artifacts generated by other
recipes as well as other images generated by the same recipe it's useful
to delay its creation and deployment until after do_image_complete.
This patch adds a new variable: IMAGE_TYPES_DEPLOY_LATE which contains
a list of image types for which the associated IMAGE_CMD tasks should be
called after do_image_complete. The deployment is now done in two stages:
before do_image_complete for all regular types and after for types listed
in the new variable.
This will allow us to fine tune the dependencies in order to implement
dm-verity support where initramfs on which the main image depends needs to
access the partition image before we create the wic image.
[1]
http://lists.openembedded.org/pipermail/openembedded-core/2020-March/294094.html
Signed-off-by: Bartosz Golaszewski
---
meta/classes/image.bbclass| 39 ++-
meta/classes/image_types.bbclass | 3 ++
meta/classes/image_types_wic.bbclass | 4 +-
.../images/build-appliance-image_15.0.0.bb| 2 +-
4 files changed, 36 insertions(+), 12 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 6e2b864f73..7d0dd6ee50 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -83,6 +83,7 @@ export PACKAGE_INSTALL ?= "${IMAGE_INSTALL}
${ROOTFS_BOOTSTRAP_INSTALL} ${FEATUR
PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}"
IMGDEPLOYDIR = "${WORKDIR}/deploy-${PN}-image-complete"
+LATEIMGDEPLOYDIR = "${WORKDIR}/deploy-${PN}-image-complete-late"
# Images are generally built explicitly, do not need to be part of world.
EXCLUDE_FROM_WORLD = "1"
@@ -127,7 +128,7 @@ def rootfs_variables(d):
'IMAGE_ROOTFS_MAXSIZE','IMAGE_NAME','IMAGE_LINK_NAME','IMAGE_MANIFEST','DEPLOY_DIR_IMAGE','IMAGE_FSTYPES','IMAGE_INSTALL_COMPLEMENTARY','IMAGE_LINGUAS',
'IMAGE_LINGUAS_COMPLEMENTARY',
'MULTILIBRE_ALLOW_REP','MULTILIB_TEMP_ROOTFS','MULTILIB_VARIANTS','MULTILIBS','ALL_MULTILIB_PACKAGE_ARCHS','MULTILIB_GLOBAL_VARIANTS','BAD_RECOMMENDATIONS','NO_RECOMMENDATIONS',
'PACKAGE_ARCHS','PACKAGE_CLASSES','TARGET_VENDOR','TARGET_ARCH','TARGET_OS','OVERRIDES','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI','INTERCEPT_DIR','USE_DEVFS',
- 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED',
'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY',
'REPRODUCIBLE_TIMESTAMP_ROOTFS', 'IMAGE_INSTALL_DEBUGFS']
+ 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED',
'IMGDEPLOYDIR', 'LATEIMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY',
'REPRODUCIBLE_TIMESTAMP_ROOTFS', 'IMAGE_INSTALL_DEBUGFS']
variables.extend(rootfs_command_variables(d))
variables.extend(variable_depends(d))
return " ".join(variables)
@@ -247,7 +248,7 @@ fakeroot python do_rootfs () {
progress_reporter.finish()
}
do_rootfs[dirs] = "${TOPDIR}"
-do_rootfs[cleandirs] += "${S} ${IMGDEPLOYDIR}"
+do_rootfs[cleandirs] += "${S} ${IMGDEPLOYDIR} ${LATEIMGDEPLOYDIR}"
do_rootfs[umask] = "022"
do_rootfs[file-checksums] += "${POSTINST_INTERCEPT_CHECKSUMS}"
addtask rootfs after do_prepare_recipe_sysroot
@@ -273,7 +274,21 @@ SSTATETASKS += "do_image_deploy"
do_image_deploy[sstate-inputdirs] = "${IMGDEPLOYDIR}"
do_image_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
SSTATE_SKIP_CREATION_task-image-deploy = '1'
-addtask do_image_deploy after do_image before do_build
+addtask do_image_deploy after do_image before do_image_complete
+
+do_image_deploy_late() {
+# Avoid using SSTATE_DUPWHITELIST - check which images have already been
+# deployed and copy those that haven't into a separate pre-deploy directory
+# which will serve as the sstate input directory for this task.
+for file in $(ls ${IMGDEPLOYDIR}) ; do
+test -e ${DEPLOY_DIR_IMAGE}/$file || cp -a ${IMGDEPLOYDIR}/$file
${LATEIMGDEPLOYDIR}/$file
+done
+}
+SSTATETASKS += "do_image_deploy_late"
+do_image_deploy_late[sstate-inputdirs] = "${LATEIMGDEPLOYDIR}"
+do_image_deploy_late[sstate-outputdirs] = "
Re: [OE-core] Solving a circular dependency issue between the main image and initramfs
wt., 17 mar 2020 o 14:45 Quentin Schulz napisał(a): > > Hi Bartosz, > > On Tue, Mar 17, 2020 at 02:26:37PM +0100, Bartosz Golaszewski wrote: > > pon., 16 mar 2020 o 12:01 Richard Purdie > > napisał(a): > > > > > > On Mon, 2020-03-16 at 11:48 +0100, Bartosz Golaszewski wrote: > > > > There has been no relevant feedback, but I've been experimenting with > > > > various things. I think that the best approach would be to make image > > > > artifacts installable into dependant recipes' sysroots (in > > > > /usr/share/images/). This way the initramfs recipe could calculate > > > > the > > > > dm-verity hashes from the resulting ext4 image before it gets > > > > deployed. We could also modify the kernel recipe to not fetch the > > > > initramfs image from the shared directory but instead have it > > > > installed in its sysroot. > > > > > > > > For this I tried to re-enable the do_install task in image.bbclass. > > > > Unfortunately either I'm doing something wrong or standard tasks are > > > > subject to different rules when it comes to dependencies. I've been > > > > so > > > > far unable to make do_install depend on any image tasks (i.e. make > > > > do_install depend on do_image_ext4/wic etc.) no matter if I use > > > > do_install[depends] or addtask or appropriate helpers from python. > > > > Unfortunately I've been unable to find any information on that in the > > > > manual. > > > > > > > > Is there some trick to changing the dependencies of standard tasks? > > > > > > I don't know how exactly you're configuring the system but it should be > > > possible to have the main rootfs built first, adding in the signing, > > > then have the initramfs depend on that. > > > > > > > I too thought this should be possible with current implementation and > > yet I've spent so many hours on this to no avail it's not funny. :( > > > > I haven't read carefully your thread but ran into what seems to be a > similar situation two years ago: > > https://youtu.be/jtLQ8SzfrDU?t=2336 > > So, TL;DR, couldn't create a fitimage with kernel-fitimage because of > circular dependencies and we had to create a new fitimage bbclass which > wasn't inherited in the kernel but by the image recipe IIRC. > > I didn't think at that time kernel-fitimage made sense because you can > technically put whatever you want in a fitimage. I can technically not > have a kernel in it. I thought a fitimage bbclass inherited by an image > recipe made much more sense. It was two years ago, didn't share anything > with the YP folks back then, so my bad. I haven't had this issue since > then (no product requiring this) so didn't think much more about it :/ > > I promised once we had something good enough we would give back to the > community. Now that I've left that company and forgot to do it, you can > throw rocks at me. > > Good luck and keep us posted please. > Quentin Thanks Quentin, this is pretty much what Ernst suggested earlier in this thread too. I'm not a fan of this solution. Richard et al: do you think making the fitimage class something an image recipe could inherit is a good idea? So far I think there are three solutions to the problem: 1. Make wic image a separate recipe that could run after everything else is done and deployed. 2. Make image.bbclass install its artifacts into whatever recipe DEPENDS on it. 3. Make fitimage a bbclass that could be added to IMAGE_CLASSES. Bartosz -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Solving a circular dependency issue between the main image and initramfs
pon., 16 mar 2020 o 15:03 Ernst Sjöstrand
napisał(a):
>
> Hi!
>
> I have done something very similar, here's what I did.
>
> My ramdisk is just a vanilla cpio.
> My kernel is just vanilla zImage.
>
> My main image does "inherit magic" and magic.bbclass does something like
> this, where create_custom_fitimage has a lot of kernel-fitimage.bbclass
> copied out.
> do_magic () {
> create_custom_fitimage
> install fitImage.bin ${IMAGE_ROOTFS}/boot/fitImage
> }
> do_magic[depends] += "my-ramdisk:do_image_complete virtual/kernel"
> addtask magic before do_image after do_pre_image_task
>
> It does read a lot of stuff from deploy but so does the main
> kernel-fitimage.bbclass so I don't think that's a problem.
>
> Regards
> //Ernst
>
There are probably many workarounds for this, but if we can't do this
with upstream OE-core then something is broken/missing upstream and we
should fix it. This is what I'm trying to do. I'm just looking for the
right way. I don't want to carry some non-upstreamable workaround over
to every other project I'm working on - optimally this should be made
part of OE-core/meta-security.
Best regards,
Bartosz Golaszewski
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Solving a circular dependency issue between the main image and initramfs
pon., 16 mar 2020 o 12:01 Richard Purdie napisał(a): > > On Mon, 2020-03-16 at 11:48 +0100, Bartosz Golaszewski wrote: > > There has been no relevant feedback, but I've been experimenting with > > various things. I think that the best approach would be to make image > > artifacts installable into dependant recipes' sysroots (in > > /usr/share/images/). This way the initramfs recipe could calculate > > the > > dm-verity hashes from the resulting ext4 image before it gets > > deployed. We could also modify the kernel recipe to not fetch the > > initramfs image from the shared directory but instead have it > > installed in its sysroot. > > > > For this I tried to re-enable the do_install task in image.bbclass. > > Unfortunately either I'm doing something wrong or standard tasks are > > subject to different rules when it comes to dependencies. I've been > > so > > far unable to make do_install depend on any image tasks (i.e. make > > do_install depend on do_image_ext4/wic etc.) no matter if I use > > do_install[depends] or addtask or appropriate helpers from python. > > Unfortunately I've been unable to find any information on that in the > > manual. > > > > Is there some trick to changing the dependencies of standard tasks? > > I don't know how exactly you're configuring the system but it should be > possible to have the main rootfs built first, adding in the signing, > then have the initramfs depend on that. > I too thought this should be possible with current implementation and yet I've spent so many hours on this to no avail it's not funny. :( > I can understand some circular dependencies could creep in as many > configurations have the initramfs as part of the main image but if you > don't configure that, you shouldn't see those dependencies. > I think there are more problems with this and the main reason is the fact that wic is just a regular image type. I'd argue it should be its own recipe since it can fetch deployed files from multiple recipes (including different images - for instance if we wanted to build a special recovery image that would need to include the main image + minimal rootfs). First: the initramfs recipe needs to access an artifact generated by do_image_ext4 from the main image. If we're not running do_install from image.bbclass (which we currently don't), this can only happen after do_image_complete which does the sstate deployment. So initramfs.do_image_ext4 depends on rootfs.do_image_complete. Next the kernel bbclass needs the initramfs image to assemble the fitimage - so kernel.do_assemble_fitimage_initramfs depends on initramfs.do_image_complete. Next we have the inter-dependencies between the kernel and u-boot because we need to sign the fitImage for dm-verity to make sense. Currently u-boot.do_build depends on kernel.do_deploy. And then the culprit: rootfs.do_image_wic needs to fetch the boot files so it depends on u-boot.do_deploy but rootfs.do_image_complete runs after rootfs.do_image_wic. I guess if we made wic a separate recipe - not just an image type, it could help here. > I do fear your "re-enable" do_install route isn't going to get you > where you want to be. > Why not? This is what currently happens with the dependencies between fitimage <-> u-boot when UBOOT_SIGN_ENABLE is set to "1". U-boot installs the DTB image - that would normally be deployed - into the /usr/share directory of kernel's sysroot. > Can you give a simple example of how you reproduce the circular > dependencies with standard poky or oe-core? That might let others give > comment more easily. > It's very simple: add an initramfs to the recipe (INITRAMFS_IMAGE = "some-image") and add the following to some-image.bb recipe: do_rootfs[depends] += "core-image-minimal:do_image_complete" with the assumption that you're building core-image-minimal. You also need "wic" in IMAGE_FSTYPES. Best regards, Bartosz Golaszewski -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Solving a circular dependency issue between the main image and initramfs
wt., 10 mar 2020 o 22:23 Bartosz Golaszewski napisał(a): > > Hi, > > I've been struggling for a while now trying to fix a circular > dependency issue when the initramfs image needs to access an image > file generated by the main (for lack of a better term) image recipe. > > I've tried to fix our downstream layer only to come to the conclusion > that some things must probably be modified upstream to make sense. > Unfortunately when trying different solutions I always arrive at some > kind of circular dependency with the current task order. > > My use-case is the following: > > I'd like to use dm-verity to protect the rootfs from tampering as part > of the verified boot flow. At boot-time the rootfs partition is mapped > using veritysetup from a trusted initramfs stored in a signed > fitImage. This initramfs also contains the root verity hash while the > rest of the hash tree is stored on a different partition. > > The dm-verity meta data is generated from a class[1] I wrote with the > aim of upstreaming it to meta-security as an image conversion of > ext[234] and btrfs images. > > For the sake of clarity of the example let's assume we're generating > an ext4 image for core-image-full-cmdline and set INITRAMFS_IMAGE to > "dm-verity-image-initramfs". > > The veritysetup conversion becomes part of the > core-image-full-cmdline:do_image_ext4 task, while > dm-verity-image-initramfs:do_rootfs needs to depend on > core-image-full-cmdline:do_image_ext4 as it needs to compute the > hashes based on the block device image. It cannot however depend on > core-image-full-cmdline:do_image_complete as it depends on many tasks > (e.g. kernel and u-boot tasks) that would inevitably lead to a > circular dependency. > > The output files from recipes inheriting image.bbclass are not > deployed before do_image_complete nor is anything done in do_install > or do_populate_sysroot (these tasks are flagged noexec or deleted), so > I cannot access them from dm-verity-image-initramfs:do_rootfs. > > As a workaround in the downstream layer I've been manually putting the > verity meta data into the DEPLOY_DIR_IMAGE from > core-image-full-cmdline:do_image_ext4 but this obviously isn't correct > as far as the deploy class and sstate are concerned. > > Now the question is: how do I approach it so that I can eventually > make it part of upstream meta-security? > > Do I implement do_install in image.bbclass so that initramfs can > depend on core-image-full-cmdline:do_populate_sysroot and have the > artifacts installed locally? But this would mean that the initramfs > recipe deploys the main image artifact. Should we deploy the images > earlier (before do_image_complete) for the initramfs recipe to fetch > from DEPLOY_DIR_IMAGE? Any other ideas? > > Best regards, > Bartosz Golaszewski > > [1] > https://github.com/brgl/meta-security/blob/topic/verity-et-al/classes/dm-verity-img.bbclass There has been no relevant feedback, but I've been experimenting with various things. I think that the best approach would be to make image artifacts installable into dependant recipes' sysroots (in /usr/share/images/). This way the initramfs recipe could calculate the dm-verity hashes from the resulting ext4 image before it gets deployed. We could also modify the kernel recipe to not fetch the initramfs image from the shared directory but instead have it installed in its sysroot. For this I tried to re-enable the do_install task in image.bbclass. Unfortunately either I'm doing something wrong or standard tasks are subject to different rules when it comes to dependencies. I've been so far unable to make do_install depend on any image tasks (i.e. make do_install depend on do_image_ext4/wic etc.) no matter if I use do_install[depends] or addtask or appropriate helpers from python. Unfortunately I've been unable to find any information on that in the manual. Is there some trick to changing the dependencies of standard tasks? Bartosz -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Solving a circular dependency issue between the main image and initramfs
wt., 10 mar 2020 o 23:54 Ayoub Zaki napisał(a):
>
>
> On 10.03.20 23:02, Bartosz Golaszewski wrote:
>
> wt., 10 mar 2020 o 22:33 Ayoub Zaki napisał(a):
>
> Do I implement do_install in image.bbclass so that initramfs can
> depend on core-image-full-cmdline:do_populate_sysroot and have the
> artifacts installed locally? But this would mean that the initramfs
> recipe deploys the main image artifact. Should we deploy the images
> earlier (before do_image_complete) for the initramfs recipe to fetch
> from DEPLOY_DIR_IMAGE? Any other ideas?
>
> I think that best thing is to implement the dm-verity stuffs as a wic
> plugin, check this example:
>
>
> https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/scripts/lib/wic/plugins/source/dm-verity.py
>
> This doesn't look like a correct solution. For starters: not every
> platform uses wic. The platform I'm aiming this at uses fastboot and
> requires separate images for each partition.
>
>
> My proposition was refering to your example :
>
The example is there just to include support for one of the reference
boards - BBB in this case. The initramfs itself as well as the rest
should be generic though.
>
> https://github.com/brgl/meta-security/commit/83c8e8fba6988249c9d351aa2ad6e02a71b010df#diff-33f7c29b373860ec45379a5f2dc42a75
>
>
> your are trying to include the dm-verity conversion output to your wic wks
> using the following:
>
>
> part / --source rawcopy --ondisk mmcblk
> --sourceparams="file=${IMGDEPLOYDIR}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_TYPE}"
>
>
> In this case you will definitely stuck in a circular dependency unless using
> a Wic plugin.
>
Actually this isn't a problem. The dm-verity class makes do_image_wic
depend on do_image_ext[234] and do_image_btrfs and since do_image_wic
is part of the same recipe, we can fetch the image from IMGDEPLOYDIR
before it's deployed.
Best regards,
Bartosz Golaszewski
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Solving a circular dependency issue between the main image and initramfs
wt., 10 mar 2020 o 22:33 Ayoub Zaki napisał(a): > > > > > Do I implement do_install in image.bbclass so that initramfs can > > depend on core-image-full-cmdline:do_populate_sysroot and have the > > artifacts installed locally? But this would mean that the initramfs > > recipe deploys the main image artifact. Should we deploy the images > > earlier (before do_image_complete) for the initramfs recipe to fetch > > from DEPLOY_DIR_IMAGE? Any other ideas? > > > I think that best thing is to implement the dm-verity stuffs as a wic > plugin, check this example: > > > https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/scripts/lib/wic/plugins/source/dm-verity.py > This doesn't look like a correct solution. For starters: not every platform uses wic. The platform I'm aiming this at uses fastboot and requires separate images for each partition. This plugin also seems to be unnecessarily complicated with additional signature for the verity hash tree. This is not needed as long as the root hash comes from a secure place - which it does in my case: the fitImage containing the initramfs is signed and the key is appended to u-boot's DTB. When do_image_wic starts, u-boot and initramfs assembly are long completed - another reason for not using a wic plugin. Best regards, Bartosz Golaszewski -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Solving a circular dependency issue between the main image and initramfs
Hi, I've been struggling for a while now trying to fix a circular dependency issue when the initramfs image needs to access an image file generated by the main (for lack of a better term) image recipe. I've tried to fix our downstream layer only to come to the conclusion that some things must probably be modified upstream to make sense. Unfortunately when trying different solutions I always arrive at some kind of circular dependency with the current task order. My use-case is the following: I'd like to use dm-verity to protect the rootfs from tampering as part of the verified boot flow. At boot-time the rootfs partition is mapped using veritysetup from a trusted initramfs stored in a signed fitImage. This initramfs also contains the root verity hash while the rest of the hash tree is stored on a different partition. The dm-verity meta data is generated from a class[1] I wrote with the aim of upstreaming it to meta-security as an image conversion of ext[234] and btrfs images. For the sake of clarity of the example let's assume we're generating an ext4 image for core-image-full-cmdline and set INITRAMFS_IMAGE to "dm-verity-image-initramfs". The veritysetup conversion becomes part of the core-image-full-cmdline:do_image_ext4 task, while dm-verity-image-initramfs:do_rootfs needs to depend on core-image-full-cmdline:do_image_ext4 as it needs to compute the hashes based on the block device image. It cannot however depend on core-image-full-cmdline:do_image_complete as it depends on many tasks (e.g. kernel and u-boot tasks) that would inevitably lead to a circular dependency. The output files from recipes inheriting image.bbclass are not deployed before do_image_complete nor is anything done in do_install or do_populate_sysroot (these tasks are flagged noexec or deleted), so I cannot access them from dm-verity-image-initramfs:do_rootfs. As a workaround in the downstream layer I've been manually putting the verity meta data into the DEPLOY_DIR_IMAGE from core-image-full-cmdline:do_image_ext4 but this obviously isn't correct as far as the deploy class and sstate are concerned. Now the question is: how do I approach it so that I can eventually make it part of upstream meta-security? Do I implement do_install in image.bbclass so that initramfs can depend on core-image-full-cmdline:do_populate_sysroot and have the artifacts installed locally? But this would mean that the initramfs recipe deploys the main image artifact. Should we deploy the images earlier (before do_image_complete) for the initramfs recipe to fetch from DEPLOY_DIR_IMAGE? Any other ideas? Best regards, Bartosz Golaszewski [1] https://github.com/brgl/meta-security/blob/topic/verity-et-al/classes/dm-verity-img.bbclass -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-security][PATCH] linux: drop the bbappend for linux v4.x series
pon., 24 lut 2020 o 17:16 akuster808 napisał(a): > > wrong ml. > > should be yo...@list.yoctoproject.org > > On 2/24/20 7:45 AM, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > v4.19 LTS has been dropped in poky in favor of v5.4. Drop the bbappend > > from meta-security as right now the build fails. > > Thanks for the patch. I saw this issue yesterday and you beat me to > fixing it. > Hi Armin, just a gentle ping as this is still broken - do you want me to resend it to the right mailing list? Bartosz -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] hosttools: add utilities for all supported checksums
From: Bartosz Golaszewski Only md5sum and sha256sum are currently provided by HOSTTOOLS. Trying to use any other checksum conversion will result in a build failure. Fix it by adding other supported checksum utilities to HOSTTOOLS. Signed-off-by: Bartosz Golaszewski --- meta/conf/bitbake.conf | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 954c06b313..e201b671bb 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -489,7 +489,8 @@ HOSTTOOLS += " \ fgrep file find flock g++ gawk gcc getconf getopt git grep gunzip gzip \ head hostname iconv id install ld ldd ln ls make md5sum mkdir mknod \ mktemp mv nm objcopy objdump od patch perl pr printf pwd \ -python3 ranlib readelf readlink realpath rm rmdir rpcgen sed seq sh sha256sum \ +python3 ranlib readelf readlink realpath rm rmdir rpcgen sed seq sh \ +sha1sum sha224sum sha256sum sha384sum sha512sum \ sleep sort split stat strings strip tail tar tee test touch tr true uname \ uniq wc wget which xargs \ " -- 2.25.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta-security][PATCH] linux: drop the bbappend for linux v4.x series
From: Bartosz Golaszewski
v4.19 LTS has been dropped in poky in favor of v5.4. Drop the bbappend
from meta-security as right now the build fails.
Signed-off-by: Bartosz Golaszewski
---
recipes-kernel/linux/linux-yocto_4.%.bbappend | 2 --
1 file changed, 2 deletions(-)
delete mode 100644 recipes-kernel/linux/linux-yocto_4.%.bbappend
diff --git a/recipes-kernel/linux/linux-yocto_4.%.bbappend
b/recipes-kernel/linux/linux-yocto_4.%.bbappend
deleted file mode 100644
index 39d4e6f..000
--- a/recipes-kernel/linux/linux-yocto_4.%.bbappend
+++ /dev/null
@@ -1,2 +0,0 @@
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor",
" features/apparmor/apparmor.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", "
features/smack/smack.scc", "" ,d)}"
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] image_types: fix checksum conversion dependencies
From: Bartosz Golaszewski Only md5sum and sha256sum tools are provided by HOSTTOOLS. For other checksum utils, the conversions need to depend on coreutils-native. Signed-off-by: Bartosz Golaszewski --- meta/classes/image_types.bbclass | 4 1 file changed, 4 insertions(+) diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass index f82f1d8862..63ffbac7e6 100644 --- a/meta/classes/image_types.bbclass +++ b/meta/classes/image_types.bbclass @@ -315,6 +315,10 @@ CONVERSION_DEPENDS_lzo = "lzop-native" CONVERSION_DEPENDS_zip = "zip-native" CONVERSION_DEPENDS_zst = "zstd-native" CONVERSION_DEPENDS_sum = "mtd-utils-native" +CONVERSION_DEPENDS_sha1sum = "coreutils-native" +CONVERSION_DEPENDS_sha224sum = "coreutils-native" +CONVERSION_DEPENDS_sha384sum = "coreutils-native" +CONVERSION_DEPENDS_sha512sum = "coreutils-native" CONVERSION_DEPENDS_bmap = "bmap-tools-native" CONVERSION_DEPENDS_u-boot = "u-boot-tools-native" CONVERSION_DEPENDS_vmdk = "qemu-system-native" -- 2.19.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] pthreads should rdepend on libgcc
śr., 13 lis 2019 o 23:37 Khem Raj napisał(a):
>
> On Wed, Nov 13, 2019 at 7:50 AM Ross Burton wrote:
> >
> > On 13/11/2019 15:04, Mark Hatle wrote:
> > >> This is because the implementation of __pthread_exit() in glibc calls
> > >> pthread_cancel() which leads to pthread_cancel_init() being called in
> > >> which said shared object is being loaded with dlopen(). When this
> > >> fails, the program aborts with the following error message:
> > >>
> > >> libgcc_s.so.1 must be installed for pthread_cancel to work
> > >> Aborted
> > >
> > > Fix for this would be to declare a runtime-dependency on libgcc_s.so.1 in
> > > the
> > > glibc libpthread package.
> >
> > On my todo list for a long time has been:
> >
> > 1) a QA test to find binaries that link to pthread_cancel but don't
> > depend on libgcc_s
> > 2) Automatically finding use of pthread_cancel and adding the RDEPENDS
> > automatically.
> >
> > (2) is definitely the best long term solution, but as Mark says: the now
> > fix is to add libgcc to RDEPENDS. There's plenty of prior art in oe-core:
> >
> > $ git grep -h RDEPENDS.*libgcc
> > RDEPENDS_${PN}-ptest += "make ${@bb.utils.contains('PACKAGECONFIG',
> > 'python', 'libgcc python3-core python3-logging python3-shell
> > python3-stringold python3-threading python3-unittest ${PN}-python', '', d)}"
> > RDEPENDS_${PN} = "libgcc"
> > RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests unzip bzip2 libgcc
> > tzdata-europe coreutils sed"
> > RDEPENDS_${PN}-ptest += "libgcc"
> > RDEPENDS_${PN} = "libgcc"
> > RDEPENDS_${PN}-ptest += "libgcc"
> > RDEPENDS_${PN}-ptest += "libgcc"
> >
>
> There are two issues here, one is where dependency is missing which
> this solution will address
> however, there could be another problem, where libgcc_s is lazily
> loaded during pthread_exit and
> application is not using root user which many daemons do where they
> use less privileged user to run
> and it would fail in the exact same manner. I also see few other uses
> of libgcc_s.so being dlopened in
> nptl unwind code and libbacktrace in glibc. so even if you were to do
> one of above you won't solve the
> problem. in fact the part this will solve can simply be solved by
> adding libgcc_s as rdep for libc6
> and then if we still get failures of such kind then we know its the
> second problem since we would have
> taken care of the first issue with rdep. Its fine if we want to be
> surgical, but it might be over-optimization
So can I submit such a patch then?
Bart
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] pthreads should rdepend on libgcc
śr., 13 lis 2019 o 23:39 Khem Raj napisał(a): > > On Wed, Nov 13, 2019 at 12:34 AM Bartosz Golaszewski wrote: > > > > This isn't a patch as I'm not sure how to fix the right way it but it > > seems to my that every program that calls pthread_exit() indirectly > > rdepends on libgcc_s.so.1 being installed in the system (at least when > > using glibc). > > > > This is because the implementation of __pthread_exit() in glibc calls > > pthread_cancel() which leads to pthread_cancel_init() being called in > > which said shared object is being loaded with dlopen(). When this > > fails, the program aborts with the following error message: > > > > libgcc_s.so.1 must be installed for pthread_cancel to work > > Aborted > > > > A quick way of reproducing it is building a core-image-minimal (which > > by default doesn't contain libgcc) with the core python3 package and > > running the simple python HTTP server: > > > > python3 -m http.server 8000 > > > > Fetching any file will result in the above crash of the python process > > when the thread serving the file exits. > > > > I'm not sure if the same issue is present in musl - the implementation > > of __pthread_exit() there is different. > > > > musl will not have this issue since it does not depend on libgcc > unwinder implicitly. > > > Please advise on how to best approach this. > > > > use musl ;) I'd love to, but I'm stuck with systemd. :) Bart > > > Thanks in advance, > > Bartosz Golaszewski > > -- > > ___ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] pthreads should rdepend on libgcc
śr., 13 lis 2019 o 16:04 Mark Hatle napisał(a): > > > > On 11/13/19 2:34 AM, Bartosz Golaszewski wrote: > > This isn't a patch as I'm not sure how to fix the right way it but it > > seems to my that every program that calls pthread_exit() indirectly > > rdepends on libgcc_s.so.1 being installed in the system (at least when > > using glibc). > > > > This is because the implementation of __pthread_exit() in glibc calls > > pthread_cancel() which leads to pthread_cancel_init() being called in > > which said shared object is being loaded with dlopen(). When this > > fails, the program aborts with the following error message: > > > > libgcc_s.so.1 must be installed for pthread_cancel to work > > Aborted > > Fix for this would be to declare a runtime-dependency on libgcc_s.so.1 in the > glibc libpthread package. > There is no real libpthread package. There's libpthread-stubs but it only contains pkgconfig files. The actual pthread shared library is in libc6 package and its inclusion doesn't seem to be conditional. In that case - isn't it better to just make libgcc_s.so.1 part of libc6? Bart > --Mark > > > A quick way of reproducing it is building a core-image-minimal (which > > by default doesn't contain libgcc) with the core python3 package and > > running the simple python HTTP server: > > > > python3 -m http.server 8000 > > > > Fetching any file will result in the above crash of the python process > > when the thread serving the file exits. > > > > I'm not sure if the same issue is present in musl - the implementation > > of __pthread_exit() there is different. > > > > Please advise on how to best approach this. > > > > Thanks in advance, > > Bartosz Golaszewski > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] pthreads should rdepend on libgcc
This isn't a patch as I'm not sure how to fix the right way it but it seems to my that every program that calls pthread_exit() indirectly rdepends on libgcc_s.so.1 being installed in the system (at least when using glibc). This is because the implementation of __pthread_exit() in glibc calls pthread_cancel() which leads to pthread_cancel_init() being called in which said shared object is being loaded with dlopen(). When this fails, the program aborts with the following error message: libgcc_s.so.1 must be installed for pthread_cancel to work Aborted A quick way of reproducing it is building a core-image-minimal (which by default doesn't contain libgcc) with the core python3 package and running the simple python HTTP server: python3 -m http.server 8000 Fetching any file will result in the above crash of the python process when the thread serving the file exits. I'm not sure if the same issue is present in musl - the implementation of __pthread_exit() there is different. Please advise on how to best approach this. Thanks in advance, Bartosz Golaszewski -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qemu: fix patch authorship
pon., 12 sie 2019 o 10:51 Richard Purdie napisał(a): > > On Mon, 2019-08-12 at 09:01 +0200, Bartosz Golaszewski wrote: > > wt., 30 lip 2019 o 09:22 Bartosz Golaszewski > > napisał(a): > > > From: Bartosz Golaszewski > > > > > > I accidentally changed the patch author when backporting this from > > > upstream qemu. This commit restores the original author. > > > > > > Signed-off-by: Bartosz Golaszewski > > > --- > > > ...4-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch | > > > 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix- > > > to-handle-variably-sized-SIOCGSTAMP-w.patch b/meta/recipes- > > > devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized- > > > SIOCGSTAMP-w.patch > > > index 2feb567f1c..f7939b84bf 100644 > > > --- a/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to- > > > handle-variably-sized-SIOCGSTAMP-w.patch > > > +++ b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to- > > > handle-variably-sized-SIOCGSTAMP-w.patch > > > @@ -1,5 +1,5 @@ > > > From 8104018ba4c66e568d2583a3a0ee940851ee7471 Mon Sep 17 00:00:00 > > > 2001 > > > -From: Bartosz Golaszewski > > > +From: Daniel P. Berrangé > > > Date: Tue, 23 Jul 2019 17:50:00 +0200 > > > Subject: [PATCH] linux-user: fix to handle variably sized > > > SIOCGSTAMP with new > > > kernels > > > -- > > > 2.21.0 > > > > > > > Gentle ping. > > The original patch hadn't merged when this was posted and you were the > author of the original submission to us so it was squashed. You can see > the correct author in: > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=57d702ed5de571751517568872eda2b5ba9fa8df > > Cheers, > > Richard > > Cool, I didn't notice it. Thanks! Bart -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qemu: fix patch authorship
wt., 30 lip 2019 o 09:22 Bartosz Golaszewski napisał(a): > > From: Bartosz Golaszewski > > I accidentally changed the patch author when backporting this from > upstream qemu. This commit restores the original author. > > Signed-off-by: Bartosz Golaszewski > --- > ...4-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch > > b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch > index 2feb567f1c..f7939b84bf 100644 > --- > a/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch > +++ > b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch > @@ -1,5 +1,5 @@ > From 8104018ba4c66e568d2583a3a0ee940851ee7471 Mon Sep 17 00:00:00 2001 > -From: Bartosz Golaszewski > +From: Daniel P. Berrangé > Date: Tue, 23 Jul 2019 17:50:00 +0200 > Subject: [PATCH] linux-user: fix to handle variably sized SIOCGSTAMP with new > kernels > -- > 2.21.0 > Gentle ping. Bart -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] qemu: add a patch fixing the native build on newer kernels
pon., 29 lip 2019 o 09:17 Bartosz Golaszewski napisał(a):
>
> From: Bartosz Golaszewski
>
> The build fails on qemu-native if we're using kernels after commit
> 0768e17073dc527ccd18ed5f96ce85f9985e9115. This adds an upstream
> patch that fixes the issue.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> v1 -> v2:
> - fixed authorship which was accidentally changed when backporting
>
> meta/recipes-devtools/qemu/qemu.inc | 1 +
> ...o-handle-variably-sized-SIOCGSTAMP-w.patch | 339 ++
> 2 files changed, 340 insertions(+)
> create mode 100644
> meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc
> b/meta/recipes-devtools/qemu/qemu.inc
> index 7f0b3a7a73..46c40b7d4f 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -24,6 +24,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
>
> file://0009-linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \
>
> file://0010-Revert-linux-user-fix-mmap-munmap-mprotect-mremap-sh.patch \
> file://0013-target-arm-Fix-vector-operation-segfault.patch \
> +
> file://0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch \
>file://CVE-2019-12155.patch \
> "
> UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
> diff --git
> a/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
>
> b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
> new file mode 100644
> index 00..f7939b84bf
> --- /dev/null
> +++
> b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
> @@ -0,0 +1,339 @@
> +From 8104018ba4c66e568d2583a3a0ee940851ee7471 Mon Sep 17 00:00:00 2001
> +From: Daniel P. Berrangé
> +Date: Tue, 23 Jul 2019 17:50:00 +0200
> +Subject: [PATCH] linux-user: fix to handle variably sized SIOCGSTAMP with new
> + kernels
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +The SIOCGSTAMP symbol was previously defined in the
> +asm-generic/sockios.h header file. QEMU sees that header
> +indirectly via sys/socket.h
> +
> +In linux kernel commit 0768e17073dc527ccd18ed5f96ce85f9985e9115
> +the asm-generic/sockios.h header no longer defines SIOCGSTAMP.
> +Instead it provides only SIOCGSTAMP_OLD, which only uses a
> +32-bit time_t on 32-bit architectures.
> +
> +The linux/sockios.h header then defines SIOCGSTAMP using
> +either SIOCGSTAMP_OLD or SIOCGSTAMP_NEW as appropriate. If
> +SIOCGSTAMP_NEW is used, then the tv_sec field is 64-bit even
> +on 32-bit architectures
> +
> +To cope with this we must now convert the old and new type from
> +the target to the host one.
> +
> +Signed-off-by: Daniel P. Berrangé
> +Signed-off-by: Laurent Vivier
> +Reviewed-by: Arnd Bergmann
> +Message-Id: <20190718130641.15294-1-laur...@vivier.eu>
> +Signed-off-by: Laurent Vivier
> +Signed-off-by: Bartosz Golaszewski
> +---
> +Uptream-status: Backport (upstream commit:
> 6d5d5dde9adb5acb32e6b8e3dfbf47fff0f308d2)
> +
> + linux-user/ioctls.h| 21 +-
> + linux-user/syscall.c | 140 +
> + linux-user/syscall_defs.h | 30 +++-
> + linux-user/syscall_types.h | 6 --
> + 4 files changed, 159 insertions(+), 38 deletions(-)
> +
> +diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
> +index ae8951625f..e6a27ad9d6 100644
> +--- a/linux-user/ioctls.h
> b/linux-user/ioctls.h
> +@@ -219,8 +219,25 @@
> + IOCTL(SIOCGRARP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_arpreq)))
> + IOCTL(SIOCGIWNAME, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_char_ifreq)))
> + IOCTL(SIOCGPGRP, IOC_R, MK_PTR(TYPE_INT)) /* pid_t */
> +- IOCTL(SIOCGSTAMP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timeval)))
> +- IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec)))
> ++
> ++ /*
> ++ * We can't use IOCTL_SPECIAL() because it will set
> ++ * host_cmd to XXX_OLD and XXX_NEW and these macros
> ++ * are not defined with kernel prior to 5.2.
> ++ * We must set host_cmd to the same value as in target_cmd
> ++ * otherwise the consistency check in syscall_init()
> ++ * will trigger an error.
> ++ * host_cmd is ignored by the do_ioctl_XXX() helpers.
> ++ * FIXME: create a macro to define this kind of entry
> ++ */
> ++ { TARGET_SIOCGSTAMP_OLD, TARGET_SIOCGSTAMP_OLD,
> ++"SIOCGSTAMP_OLD", IOC_R, do_ioctl_SIOCGSTAMP },
> ++ { TARGET_SIOC
[OE-core] [PATCH] qemu: fix patch authorship
From: Bartosz Golaszewski I accidentally changed the patch author when backporting this from upstream qemu. This commit restores the original author. Signed-off-by: Bartosz Golaszewski --- ...4-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch index 2feb567f1c..f7939b84bf 100644 --- a/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch +++ b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch @@ -1,5 +1,5 @@ From 8104018ba4c66e568d2583a3a0ee940851ee7471 Mon Sep 17 00:00:00 2001 -From: Bartosz Golaszewski +From: Daniel P. Berrangé Date: Tue, 23 Jul 2019 17:50:00 +0200 Subject: [PATCH] linux-user: fix to handle variably sized SIOCGSTAMP with new kernels -- 2.21.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] qemu: add a patch fixing the native build on newer kernels
From: Bartosz Golaszewski
The build fails on qemu-native if we're using kernels after commit
0768e17073dc527ccd18ed5f96ce85f9985e9115. This adds an upstream
patch that fixes the issue.
Signed-off-by: Bartosz Golaszewski
---
v1 -> v2:
- fixed authorship which was accidentally changed when backporting
meta/recipes-devtools/qemu/qemu.inc | 1 +
...o-handle-variably-sized-SIOCGSTAMP-w.patch | 339 ++
2 files changed, 340 insertions(+)
create mode 100644
meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 7f0b3a7a73..46c40b7d4f 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -24,6 +24,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://0009-linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \
file://0010-Revert-linux-user-fix-mmap-munmap-mprotect-mremap-sh.patch \
file://0013-target-arm-Fix-vector-operation-segfault.patch \
+
file://0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch \
file://CVE-2019-12155.patch \
"
UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
diff --git
a/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
new file mode 100644
index 00..f7939b84bf
--- /dev/null
+++
b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
@@ -0,0 +1,339 @@
+From 8104018ba4c66e568d2583a3a0ee940851ee7471 Mon Sep 17 00:00:00 2001
+From: Daniel P. Berrangé
+Date: Tue, 23 Jul 2019 17:50:00 +0200
+Subject: [PATCH] linux-user: fix to handle variably sized SIOCGSTAMP with new
+ kernels
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The SIOCGSTAMP symbol was previously defined in the
+asm-generic/sockios.h header file. QEMU sees that header
+indirectly via sys/socket.h
+
+In linux kernel commit 0768e17073dc527ccd18ed5f96ce85f9985e9115
+the asm-generic/sockios.h header no longer defines SIOCGSTAMP.
+Instead it provides only SIOCGSTAMP_OLD, which only uses a
+32-bit time_t on 32-bit architectures.
+
+The linux/sockios.h header then defines SIOCGSTAMP using
+either SIOCGSTAMP_OLD or SIOCGSTAMP_NEW as appropriate. If
+SIOCGSTAMP_NEW is used, then the tv_sec field is 64-bit even
+on 32-bit architectures
+
+To cope with this we must now convert the old and new type from
+the target to the host one.
+
+Signed-off-by: Daniel P. Berrangé
+Signed-off-by: Laurent Vivier
+Reviewed-by: Arnd Bergmann
+Message-Id: <20190718130641.15294-1-laur...@vivier.eu>
+Signed-off-by: Laurent Vivier
+Signed-off-by: Bartosz Golaszewski
+---
+Uptream-status: Backport (upstream commit:
6d5d5dde9adb5acb32e6b8e3dfbf47fff0f308d2)
+
+ linux-user/ioctls.h| 21 +-
+ linux-user/syscall.c | 140 +
+ linux-user/syscall_defs.h | 30 +++-
+ linux-user/syscall_types.h | 6 --
+ 4 files changed, 159 insertions(+), 38 deletions(-)
+
+diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
+index ae8951625f..e6a27ad9d6 100644
+--- a/linux-user/ioctls.h
b/linux-user/ioctls.h
+@@ -219,8 +219,25 @@
+ IOCTL(SIOCGRARP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_arpreq)))
+ IOCTL(SIOCGIWNAME, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_char_ifreq)))
+ IOCTL(SIOCGPGRP, IOC_R, MK_PTR(TYPE_INT)) /* pid_t */
+- IOCTL(SIOCGSTAMP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timeval)))
+- IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec)))
++
++ /*
++ * We can't use IOCTL_SPECIAL() because it will set
++ * host_cmd to XXX_OLD and XXX_NEW and these macros
++ * are not defined with kernel prior to 5.2.
++ * We must set host_cmd to the same value as in target_cmd
++ * otherwise the consistency check in syscall_init()
++ * will trigger an error.
++ * host_cmd is ignored by the do_ioctl_XXX() helpers.
++ * FIXME: create a macro to define this kind of entry
++ */
++ { TARGET_SIOCGSTAMP_OLD, TARGET_SIOCGSTAMP_OLD,
++"SIOCGSTAMP_OLD", IOC_R, do_ioctl_SIOCGSTAMP },
++ { TARGET_SIOCGSTAMPNS_OLD, TARGET_SIOCGSTAMPNS_OLD,
++"SIOCGSTAMPNS_OLD", IOC_R, do_ioctl_SIOCGSTAMPNS },
++ { TARGET_SIOCGSTAMP_NEW, TARGET_SIOCGSTAMP_NEW,
++"SIOCGSTAMP_NEW", IOC_R, do_ioctl_SIOCGSTAMP },
++ { TARGET_SIOCGSTAMPNS_NEW, TARGET_SIOCGSTAMPNS_NEW,
++"SIOCGSTAMPNS_NEW", IOC_R, do_ioctl_SIOCGSTAMPNS },
+
+ IOCTL(RNDGETENTCNT, IOC_R, MK_PTR(TYPE_INT))
+ IOCTL(RNDADDTOENTCNT, IOC_W, MK_PTR(TYPE_INT))
+diff --git a/linux-user/syscall.c b/linux-user/syscall.c
+index 96cd4bf86d..6df480e13d 100644
+--- a/linux-user/syscall.c
b/linux-user/syscall.c
+@@ -37,6
[OE-core] [RESEND PATCH] qemu: add a patch fixing the native build on newer kernels
From: Bartosz Golaszewski
The build fails on qemu-native if we're using kernels after commit
0768e17073dc527ccd18ed5f96ce85f9985e9115. This adds an upstream
patch that fixes the issue.
Signed-off-by: Bartosz Golaszewski
---
NOTE: Resending this because I sent it to the wrong list previously.
meta/recipes-devtools/qemu/qemu.inc | 1 +
...o-handle-variably-sized-SIOCGSTAMP-w.patch | 339 ++
2 files changed, 340 insertions(+)
create mode 100644
meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 7f0b3a7a73..46c40b7d4f 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -24,6 +24,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://0009-linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \
file://0010-Revert-linux-user-fix-mmap-munmap-mprotect-mremap-sh.patch \
file://0013-target-arm-Fix-vector-operation-segfault.patch \
+
file://0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch \
file://CVE-2019-12155.patch \
"
UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
diff --git
a/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
new file mode 100644
index 00..2feb567f1c
--- /dev/null
+++
b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
@@ -0,0 +1,339 @@
+From 8104018ba4c66e568d2583a3a0ee940851ee7471 Mon Sep 17 00:00:00 2001
+From: Bartosz Golaszewski
+Date: Tue, 23 Jul 2019 17:50:00 +0200
+Subject: [PATCH] linux-user: fix to handle variably sized SIOCGSTAMP with new
+ kernels
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The SIOCGSTAMP symbol was previously defined in the
+asm-generic/sockios.h header file. QEMU sees that header
+indirectly via sys/socket.h
+
+In linux kernel commit 0768e17073dc527ccd18ed5f96ce85f9985e9115
+the asm-generic/sockios.h header no longer defines SIOCGSTAMP.
+Instead it provides only SIOCGSTAMP_OLD, which only uses a
+32-bit time_t on 32-bit architectures.
+
+The linux/sockios.h header then defines SIOCGSTAMP using
+either SIOCGSTAMP_OLD or SIOCGSTAMP_NEW as appropriate. If
+SIOCGSTAMP_NEW is used, then the tv_sec field is 64-bit even
+on 32-bit architectures
+
+To cope with this we must now convert the old and new type from
+the target to the host one.
+
+Signed-off-by: Daniel P. Berrangé
+Signed-off-by: Laurent Vivier
+Reviewed-by: Arnd Bergmann
+Message-Id: <20190718130641.15294-1-laur...@vivier.eu>
+Signed-off-by: Laurent Vivier
+Signed-off-by: Bartosz Golaszewski
+---
+Uptream-status: Backport (upstream commit:
6d5d5dde9adb5acb32e6b8e3dfbf47fff0f308d2)
+
+ linux-user/ioctls.h| 21 +-
+ linux-user/syscall.c | 140 +
+ linux-user/syscall_defs.h | 30 +++-
+ linux-user/syscall_types.h | 6 --
+ 4 files changed, 159 insertions(+), 38 deletions(-)
+
+diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
+index ae8951625f..e6a27ad9d6 100644
+--- a/linux-user/ioctls.h
b/linux-user/ioctls.h
+@@ -219,8 +219,25 @@
+ IOCTL(SIOCGRARP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_arpreq)))
+ IOCTL(SIOCGIWNAME, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_char_ifreq)))
+ IOCTL(SIOCGPGRP, IOC_R, MK_PTR(TYPE_INT)) /* pid_t */
+- IOCTL(SIOCGSTAMP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timeval)))
+- IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec)))
++
++ /*
++ * We can't use IOCTL_SPECIAL() because it will set
++ * host_cmd to XXX_OLD and XXX_NEW and these macros
++ * are not defined with kernel prior to 5.2.
++ * We must set host_cmd to the same value as in target_cmd
++ * otherwise the consistency check in syscall_init()
++ * will trigger an error.
++ * host_cmd is ignored by the do_ioctl_XXX() helpers.
++ * FIXME: create a macro to define this kind of entry
++ */
++ { TARGET_SIOCGSTAMP_OLD, TARGET_SIOCGSTAMP_OLD,
++"SIOCGSTAMP_OLD", IOC_R, do_ioctl_SIOCGSTAMP },
++ { TARGET_SIOCGSTAMPNS_OLD, TARGET_SIOCGSTAMPNS_OLD,
++"SIOCGSTAMPNS_OLD", IOC_R, do_ioctl_SIOCGSTAMPNS },
++ { TARGET_SIOCGSTAMP_NEW, TARGET_SIOCGSTAMP_NEW,
++"SIOCGSTAMP_NEW", IOC_R, do_ioctl_SIOCGSTAMP },
++ { TARGET_SIOCGSTAMPNS_NEW, TARGET_SIOCGSTAMPNS_NEW,
++"SIOCGSTAMPNS_NEW", IOC_R, do_ioctl_SIOCGSTAMPNS },
+
+ IOCTL(RNDGETENTCNT, IOC_R, MK_PTR(TYPE_INT))
+ IOCTL(RNDADDTOENTCNT, IOC_W, MK_PTR(TYPE_INT))
+diff --git a/linux-user/syscall.c b/linux-user/syscall.c
+index 96cd4bf86d..6df480e13d 100644
+--- a/linux-user/syscall.c
b/linux-user/syscall.c
+@@ -37,6 +37
