[OE-core] [PATCH v2] toolchain-shar-relocate.sh: Add check for missing command 'file'
On a machine without the file command, the SDK install fails with a cryptic error message. ``` xargs: file: No such file or directory sed: no input files Failed to replace perl. Relocate script failed. Abort! ``` Add a test for 'file' to print a clear error message. ``` The command 'file' is required by the relocation script, please install it first. Abort! ``` Signed-off-by: Tom Hochstein --- meta/files/toolchain-shar-relocate.sh | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/meta/files/toolchain-shar-relocate.sh b/meta/files/toolchain-shar-relocate.sh index e8ab357717..b017714df0 100644 --- a/meta/files/toolchain-shar-relocate.sh +++ b/meta/files/toolchain-shar-relocate.sh @@ -1,7 +1,9 @@ -if ! xargs --version > /dev/null 2>&1; then - echo "xargs is required by the relocation script, please install it first. Abort!" - exit 1 -fi +for cmd in xargs file; do + if ! command -v $cmd > /dev/null 2>&1; then + echo "The command '$cmd' is required by the relocation script, please install it first. Abort!" + exit 1 + fi +done # fix dynamic loader paths in all ELF SDK binaries # allow symlinks to be accessed via the find command too -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197425): https://lists.openembedded.org/g/openembedded-core/message/197425 Mute This Topic: https://lists.openembedded.org/mt/105070397/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]] toolchain-shar-relocate.sh: Add check for missing command 'file'
On a machine without the file command, the SDK install fails with a cryptic error message. ``` xargs: file: No such file or directory sed: no input files Failed to replace perl. Relocate script failed. Abort! ``` Add a test for 'file' to print a clear error message. ``` The command 'file' is required by the relocation script, please install it first. Abort! ``` Signed-off-by: Tom Hochstein --- meta/files/toolchain-shar-relocate.sh | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/meta/files/toolchain-shar-relocate.sh b/meta/files/toolchain-shar-relocate.sh index e8ab357717..b017714df0 100644 --- a/meta/files/toolchain-shar-relocate.sh +++ b/meta/files/toolchain-shar-relocate.sh @@ -1,7 +1,9 @@ -if ! xargs --version > /dev/null 2>&1; then - echo "xargs is required by the relocation script, please install it first. Abort!" - exit 1 -fi +for cmd in xargs file; do + if ! command -v $cmd > /dev/null 2>&1; then + echo "The command '$cmd' is required by the relocation script, please install it first. Abort!" + exit 1 + fi +done # fix dynamic loader paths in all ELF SDK binaries # allow symlinks to be accessed via the find command too -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197424): https://lists.openembedded.org/g/openembedded-core/message/197424 Mute This Topic: https://lists.openembedded.org/mt/105070379/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] toolchain-shar-relocate.sh: Add check for missing command 'file'
Thanks Alexandre, On 3/21/2024 10:19 AM, Alexandre Belloni wrote: Hello Tom, On 16/03/2024 12:35:58-0500, Tom Hochstein wrote: On a machine without the file command, the SDK install fails with a cryptic error message. ``` xargs: file: No such file or directory sed: no input files Failed to replace perl. Relocate script failed. Abort! ``` Add a test for 'file' to print a clear error message. ``` The command 'file' is required by the relocation script, please install it first. Abort! ``` Signed-off-by: Tom Hochstein --- meta/files/toolchain-shar-relocate.sh | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/meta/files/toolchain-shar-relocate.sh b/meta/files/toolchain-shar-relocate.sh index e8ab357717..3d55e38102 100644 --- a/meta/files/toolchain-shar-relocate.sh +++ b/meta/files/toolchain-shar-relocate.sh @@ -1,7 +1,9 @@ -if ! xargs --version > /dev/null 2>&1; then - echo "xargs is required by the relocation script, please install it first. Abort!" - exit 1 -fi +for cmd in xargs file; do + if ! command -v $cmd &> /dev/null; then This fails on some of our builders: https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/9148/steps/12/logs/stdio Aha, looks like &> is a bashism. V2 coming. + echo "The command '$cmd' is required by the relocation script, please install it first. Abort!" + exit 1 + fi +done # fix dynamic loader paths in all ELF SDK binaries # allow symlinks to be accessed via the find command too -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197423): https://lists.openembedded.org/g/openembedded-core/message/197423 Mute This Topic: https://lists.openembedded.org/mt/104970783/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] toolchain-shar-relocate.sh: Add check for missing command 'file'
On a machine without the file command, the SDK install fails with a cryptic error message. ``` xargs: file: No such file or directory sed: no input files Failed to replace perl. Relocate script failed. Abort! ``` Add a test for 'file' to print a clear error message. ``` The command 'file' is required by the relocation script, please install it first. Abort! ``` Signed-off-by: Tom Hochstein --- meta/files/toolchain-shar-relocate.sh | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/meta/files/toolchain-shar-relocate.sh b/meta/files/toolchain-shar-relocate.sh index e8ab357717..3d55e38102 100644 --- a/meta/files/toolchain-shar-relocate.sh +++ b/meta/files/toolchain-shar-relocate.sh @@ -1,7 +1,9 @@ -if ! xargs --version > /dev/null 2>&1; then - echo "xargs is required by the relocation script, please install it first. Abort!" - exit 1 -fi +for cmd in xargs file; do + if ! command -v $cmd &> /dev/null; then + echo "The command '$cmd' is required by the relocation script, please install it first. Abort!" + exit 1 + fi +done # fix dynamic loader paths in all ELF SDK binaries # allow symlinks to be accessed via the find command too -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197256): https://lists.openembedded.org/g/openembedded-core/message/197256 Mute This Topic: https://lists.openembedded.org/mt/104970783/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 v3] bmaptool: Add bmap-tools runtime alias for compatibility
The rename of bmap-tools to bmaptool creates an incompatibility that
will break package feeds. Restore package feed compatibility by adding
a bmap-tools runtime alias.
Acked-by: Otavio Salvador
Signed-off-by: Tom Hochstein
---
meta/recipes-support/bmaptool/bmaptool_git.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-support/bmaptool/bmaptool_git.bb
b/meta/recipes-support/bmaptool/bmaptool_git.bb
index 87328af8c6..f706477323 100644
--- a/meta/recipes-support/bmaptool/bmaptool_git.bb
+++ b/meta/recipes-support/bmaptool/bmaptool_git.bb
@@ -28,4 +28,8 @@ RDEPENDS:${PN} = "python3-core python3-compression
python3-misc python3-mmap pyt
inherit setuptools3
+# For compatibility with layers before scarthgap
+RREPLACES:${PN} = "bmap-tools"
+RCONFLICTS:${PN} = "bmap-tools"
+
BBCLASSEXTEND = "native nativesdk"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196817):
https://lists.openembedded.org/g/openembedded-core/message/196817
Mute This Topic: https://lists.openembedded.org/mt/104793996/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] bmaptool: Add bmap-tools runtime alias for compatibility
The rename of bmap-tools to bmaptool creates an incompatibility that
will break package feeds. Restore compatibility by adding bmap-tools as
a runtime alias.
Acked-by: Otavio Salvador
Signed-off-by: Tom Hochstein
---
meta/recipes-support/bmaptool/bmaptool_git.bb | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-support/bmaptool/bmaptool_git.bb
b/meta/recipes-support/bmaptool/bmaptool_git.bb
index 87328af8c6..f0f3b85902 100644
--- a/meta/recipes-support/bmaptool/bmaptool_git.bb
+++ b/meta/recipes-support/bmaptool/bmaptool_git.bb
@@ -28,4 +28,9 @@ RDEPENDS:${PN} = "python3-core python3-compression
python3-misc python3-mmap pyt
inherit setuptools3
+# For compatibility with layers before scarthgap
+RPROVIDES:${PN} = "bmap-tools"
+RREPLACES:${PN} = "bmap-tools"
+RCONFLICTS:${PN} = "bmap-tools"
+
BBCLASSEXTEND = "native nativesdk"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196791):
https://lists.openembedded.org/g/openembedded-core/message/196791
Mute This Topic: https://lists.openembedded.org/mt/104787184/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] bmaptool: Add bmap-tools alias for compatibility
The rename of bmap-tools to bmaptool creates an incompatibility for
pre-scarthgap layers. Restore compatibility by adding bmap-tools as an
alias.
Acked-by: Otavio Salvador
Signed-off-by: Tom Hochstein
---
meta/recipes-support/bmaptool/bmaptool_git.bb | 8
1 file changed, 8 insertions(+)
diff --git a/meta/recipes-support/bmaptool/bmaptool_git.bb
b/meta/recipes-support/bmaptool/bmaptool_git.bb
index 87328af8c6..33f46d7070 100644
--- a/meta/recipes-support/bmaptool/bmaptool_git.bb
+++ b/meta/recipes-support/bmaptool/bmaptool_git.bb
@@ -9,6 +9,9 @@ SECTION = "console/utils"
LICENSE = "GPL-2.0-only"
LIC_FILES_CHKSUM = "file://LICENSE;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+# For compatibility with layers before scarthgap
+PROVIDES += "bmap-tools"
+
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI = "git://github.com/yoctoproject/${BPN};branch=main;protocol=https \
file://0001-BmapCopy.py-fix-error-message.patch \
@@ -28,4 +31,9 @@ RDEPENDS:${PN} = "python3-core python3-compression
python3-misc python3-mmap pyt
inherit setuptools3
+# For compatibility with layers before scarthgap
+RPROVIDES:${PN} = "bmap-tools"
+RREPLACES:${PN} = "bmap-tools"
+RCONFLICTS:${PN} = "bmap-tools"
+
BBCLASSEXTEND = "native nativesdk"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196650):
https://lists.openembedded.org/g/openembedded-core/message/196650
Mute This Topic: https://lists.openembedded.org/mt/104753355/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] linux-firmware: add firmware files for NXP BT chipsets
These BT only firmware files are submitted for NXP chips.
88w8997-bt:
uartuart8997_bt_v4.bin version: 16.92.21.p81
helper_uart_300.bin version: 16.92.21.p81
88w8987-bt:
uartuart8987_bt.bin version: 16.92.21.p76.5
88w9098-bt:
uartuart9098_bt_v1.bin version: 17.92.1.p136.24
iw416-bt:
uartiw416_bt_v0.bin version: 16.92.21.p81
iw611-bt / iw612-bt:
uartspi_n61x_v1.bin.se version: 18.99.1.p154.40
These firmware files are downloaded over UART interface. The
helper_uart_300.bin needs to be downloaded before
uartuart8997_bt_v4.bin for 88w8997 chip to set download baudrate
to 300.
The above commit message is copied from the source commit message:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/nxp?id=1f82dd25c3ea59b6bed80ee685d860f0c5f19875
Signed-off-by: Tom Hochstein
---
.../linux-firmware/linux-firmware_20230804.bb | 50 +++
1 file changed, 50 insertions(+)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20230804.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20230804.bb
index d761673db3..ee14630ce0 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20230804.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20230804.bb
@@ -41,6 +41,7 @@ LICENSE = "\
& Firmware-myri10ge_firmware \
& Firmware-netronome \
& Firmware-nvidia \
+& Firmware-nxp \
& Firmware-OLPC \
& Firmware-ath9k-htc \
& Firmware-phanfw \
@@ -107,6 +108,7 @@ LIC_FILES_CHKSUM =
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
file://LICENCE.Netronome;md5=4add08f2577086d7996503cddf5f \
file://LICENCE.nvidia;md5=4428a922ed3ba2ceec95f076a488ce07
\
file://LICENCE.NXP;md5=58bb8ba632cd729b9ba6183bc6aed36f \
+file://LICENSE.nxp;md5=cca321ca1524d6a1e4fed87486cd82dc \
file://LICENCE.OLPC;md5=5b917f9d8c061991be4f6f5f108719cd \
file://LICENCE.open-ath9k-htc-firmware;md5=1b33c9f4d17bc4d457bdb23727046837 \
file://LICENCE.phanfw;md5=954dcec0e051f9409812b561ea743bfa
\
@@ -177,6 +179,7 @@ NO_GENERIC_LICENSE[Firmware-moxa] = "LICENCE.moxa"
NO_GENERIC_LICENSE[Firmware-myri10ge_firmware] = "LICENCE.myri10ge_firmware"
NO_GENERIC_LICENSE[Firmware-netronome] = "LICENCE.Netronome"
NO_GENERIC_LICENSE[Firmware-nvidia] = "LICENCE.nvidia"
+NO_GENERIC_LICENSE[Firmware-nxp] = "LICENSE.nxp"
NO_GENERIC_LICENSE[Firmware-OLPC] = "LICENCE.OLPC"
NO_GENERIC_LICENSE[Firmware-ath9k-htc] = "LICENCE.open-ath9k-htc-firmware"
NO_GENERIC_LICENSE[Firmware-phanfw] = "LICENCE.phanfw"
@@ -312,6 +315,16 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
${PN}-nvidia-license \
${PN}-nvidia-tegra-k1 ${PN}-nvidia-tegra \
${PN}-nvidia-gpu \
+ ${PN}-nxp-license \
+ ${PN}-nxp8987-sdio \
+ ${PN}-nxp8997-common \
+ ${PN}-nxp8997-pcie \
+ ${PN}-nxp8997-sdio \
+ ${PN}-nxp9098-common \
+ ${PN}-nxp9098-pcie \
+ ${PN}-nxp9098-sdio \
+ ${PN}-nxpiw416-sdio \
+ ${PN}-nxpiw612-sdio \
${PN}-netronome-license ${PN}-netronome \
${PN}-qat ${PN}-qat-license \
${PN}-qcom-license ${PN}-qcom-yamato-license \
@@ -547,6 +560,42 @@ FILES:${PN}-netronome = " \
RDEPENDS:${PN}-netronome += "${PN}-netronome-license"
+# For NXP
+LICENSE:${PN}-nxp8987-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxp8997-common = "Firmware-nxp"
+LICENSE:${PN}-nxp8997-pcie = "Firmware-nxp"
+LICENSE:${PN}-nxp8997-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxp9098-common = "Firmware-nxp"
+LICENSE:${PN}-nxp9098-pcie = "Firmware-nxp"
+LICENSE:${PN}-nxp9098-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxpiw416-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxpiw612-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxp-license = "Firmware-nxp"
+
+FILES:${PN}-nxp8987-sdio = "${nonarch_base_libdir}/firmware/nxp/*8987*"
+FILES:${PN}-nxp8997-common = " \
+${nonarch_base_libdir}/firmware/nxp/uartuart8997_bt_v4.bin \
+${nonarch_base_libdir}/firmware/nxp/helper_uart_300.bin \
+"
+ALLOW_EMPTY:${PN}-nxp8997-pcie = "1"
+ALLOW_EMPTY:${PN}-nxp8997-sdio = "1"
+FILES:${PN}-nxp9098-common =
"${nonarch_base_libdir}/firmware/nxp/uartuart9098_bt_v1.bin"
+ALLOW_EMPTY:${PN}-nxp9098-pcie = "1"
+ALLOW_EMPTY:${PN}-nxp9098-sdio = "1"
+FILES:${PN}-nxpiw416-sdio = "${nonarch_base_libdir}/firmware/nxp/*iw416*"
+FILES:${PN}-nxpiw612-sdio =
"${nonarch_base_libdir}/firmware/nxp/uartspi_n61x_v1.bin.se"
+FILES:${PN}-nxp-license = "${nonarch_base_libdir}/firmwar
Re: [OE-core] [PATCH] linux-firmware: add firmware files for NXP BT chipsets
On Tue, Aug 29, 2023 at 05:08 AM, Tom Hochstein wrote: > > On Fri, Aug 25, 2023 at 07:37 AM, Tom Hochstein wrote: > >> Please hold off on this. The -common design is not working correctly and >> is causing those firmware packages to be registered as a runtime >> dependency of the main package. > > > > Actually, the -common design is working fine, there was just a > misunderstanding. > > Please do consider this patch as-is. > > Tom > > > Ping -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187250): https://lists.openembedded.org/g/openembedded-core/message/187250 Mute This Topic: https://lists.openembedded.org/mt/100943055/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] linux-firmware: add firmware files for NXP BT chipsets
On Fri, Aug 25, 2023 at 07:37 AM, Tom Hochstein wrote: > > Please hold off on this. The -common design is not working correctly and > is causing those firmware packages to be registered as a runtime > dependency of the main package. Actually, the -common design is working fine, there was just a misunderstanding. Please do consider this patch as-is. Tom -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#186856): https://lists.openembedded.org/g/openembedded-core/message/186856 Mute This Topic: https://lists.openembedded.org/mt/100943055/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] linux-firmware: add firmware files for NXP BT chipsets
Please hold off on this. The -common design is not working correctly and is
causing those firmware packages to be registered as a runtime dependency of the
main package.
Tom
-Original Message-
From: openembedded-core@lists.openembedded.org
On Behalf Of Tom Hochstein via
lists.openembedded.org
Sent: Thursday, August 24, 2023 3:04 PM
To: openembedded-core@lists.openembedded.org; otavio.salva...@ossystems.com.br
Cc: Tom Hochstein
Subject: [OE-core] [PATCH] linux-firmware: add firmware files for NXP BT
chipsets
These BT only firmware files are submitted for NXP chips.
88w8997-bt:
uartuart8997_bt_v4.bin version: 16.92.21.p81
helper_uart_300.bin version: 16.92.21.p81
88w8987-bt:
uartuart8987_bt.bin version: 16.92.21.p76.5
88w9098-bt:
uartuart9098_bt_v1.bin version: 17.92.1.p136.24
iw416-bt:
uartiw416_bt_v0.bin version: 16.92.21.p81
iw611-bt / iw612-bt:
uartspi_n61x_v1.bin.se version: 18.99.1.p154.40
These firmware files are downloaded over UART interface. The
helper_uart_300.bin needs to be downloaded before
uartuart8997_bt_v4.bin for 88w8997 chip to set download baudrate
to 300.
The above commit message is copied from the source commit message:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/nxp?id=1f82dd25c3ea59b6bed80ee685d860f0c5f19875
Signed-off-by: Tom Hochstein
---
.../linux-firmware/linux-firmware_20230625.bb | 50 +++
1 file changed, 50 insertions(+)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
index 6765226b9d..45556d419e 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
@@ -40,6 +40,7 @@ LICENSE = "\
& Firmware-myri10ge_firmware \
& Firmware-netronome \
& Firmware-nvidia \
+& Firmware-nxp \
& Firmware-OLPC \
& Firmware-ath9k-htc \
& Firmware-phanfw \
@@ -105,6 +106,7 @@ LIC_FILES_CHKSUM =
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
file://LICENCE.Netronome;md5=4add08f2577086d7996503cddf5f \
file://LICENCE.nvidia;md5=4428a922ed3ba2ceec95f076a488ce07
\
file://LICENCE.NXP;md5=58bb8ba632cd729b9ba6183bc6aed36f \
+file://LICENSE.nxp;md5=cca321ca1524d6a1e4fed87486cd82dc \
file://LICENCE.OLPC;md5=5b917f9d8c061991be4f6f5f108719cd \
file://LICENCE.open-ath9k-htc-firmware;md5=1b33c9f4d17bc4d457bdb23727046837 \
file://LICENCE.phanfw;md5=954dcec0e051f9409812b561ea743bfa
\
@@ -174,6 +176,7 @@ NO_GENERIC_LICENSE[Firmware-moxa] = "LICENCE.moxa"
NO_GENERIC_LICENSE[Firmware-myri10ge_firmware] = "LICENCE.myri10ge_firmware"
NO_GENERIC_LICENSE[Firmware-netronome] = "LICENCE.Netronome"
NO_GENERIC_LICENSE[Firmware-nvidia] = "LICENCE.nvidia"
+NO_GENERIC_LICENSE[Firmware-nxp] = "LICENSE.nxp"
NO_GENERIC_LICENSE[Firmware-OLPC] = "LICENCE.OLPC"
NO_GENERIC_LICENSE[Firmware-ath9k-htc] = "LICENCE.open-ath9k-htc-firmware"
NO_GENERIC_LICENSE[Firmware-phanfw] = "LICENCE.phanfw"
@@ -309,6 +312,16 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
${PN}-nvidia-license \
${PN}-nvidia-tegra-k1 ${PN}-nvidia-tegra \
${PN}-nvidia-gpu \
+ ${PN}-nxp-license \
+ ${PN}-nxp8987-sdio \
+ ${PN}-nxp8997-common \
+ ${PN}-nxp8997-pcie \
+ ${PN}-nxp8997-sdio \
+ ${PN}-nxp9098-common \
+ ${PN}-nxp9098-pcie \
+ ${PN}-nxp9098-sdio \
+ ${PN}-nxpiw416-sdio \
+ ${PN}-nxpiw612-sdio \
${PN}-netronome-license ${PN}-netronome \
${PN}-qat ${PN}-qat-license \
${PN}-qcom-license ${PN}-qcom-yamato-license \
@@ -543,6 +556,42 @@ FILES:${PN}-netronome = " \
RDEPENDS:${PN}-netronome += "${PN}-netronome-license"
+# For NXP
+LICENSE:${PN}-nxp8987-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxp8997-common = "Firmware-nxp"
+LICENSE:${PN}-nxp8997-pcie = "Firmware-nxp"
+LICENSE:${PN}-nxp8997-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxp9098-common = "Firmware-nxp"
+LICENSE:${PN}-nxp9098-pcie = "Firmware-nxp"
+LICENSE:${PN}-nxp9098-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxpiw416-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxpiw612-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxp-license = "Firmware-nxp"
+
+FILES:${PN}-nxp8987-sdio = "${nonarch_base_libdir}/firmware/nxp/*8987*"
+FILES:${PN}-nxp8997-common = " \
+${nonarch_base_libdir}/firmware/nxp/uartuart8997_bt_v4.bin \
+${nonarch_base_libdir}/firmware/nxp/helper_uart_300.bin \
+"
+ALLOW_EMPTY
[OE-core] [PATCH] linux-firmware: add firmware files for NXP BT chipsets
These BT only firmware files are submitted for NXP chips.
88w8997-bt:
uartuart8997_bt_v4.bin version: 16.92.21.p81
helper_uart_300.bin version: 16.92.21.p81
88w8987-bt:
uartuart8987_bt.bin version: 16.92.21.p76.5
88w9098-bt:
uartuart9098_bt_v1.bin version: 17.92.1.p136.24
iw416-bt:
uartiw416_bt_v0.bin version: 16.92.21.p81
iw611-bt / iw612-bt:
uartspi_n61x_v1.bin.se version: 18.99.1.p154.40
These firmware files are downloaded over UART interface. The
helper_uart_300.bin needs to be downloaded before
uartuart8997_bt_v4.bin for 88w8997 chip to set download baudrate
to 300.
The above commit message is copied from the source commit message:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/nxp?id=1f82dd25c3ea59b6bed80ee685d860f0c5f19875
Signed-off-by: Tom Hochstein
---
.../linux-firmware/linux-firmware_20230625.bb | 50 +++
1 file changed, 50 insertions(+)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
index 6765226b9d..45556d419e 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
@@ -40,6 +40,7 @@ LICENSE = "\
& Firmware-myri10ge_firmware \
& Firmware-netronome \
& Firmware-nvidia \
+& Firmware-nxp \
& Firmware-OLPC \
& Firmware-ath9k-htc \
& Firmware-phanfw \
@@ -105,6 +106,7 @@ LIC_FILES_CHKSUM =
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
file://LICENCE.Netronome;md5=4add08f2577086d7996503cddf5f \
file://LICENCE.nvidia;md5=4428a922ed3ba2ceec95f076a488ce07
\
file://LICENCE.NXP;md5=58bb8ba632cd729b9ba6183bc6aed36f \
+file://LICENSE.nxp;md5=cca321ca1524d6a1e4fed87486cd82dc \
file://LICENCE.OLPC;md5=5b917f9d8c061991be4f6f5f108719cd \
file://LICENCE.open-ath9k-htc-firmware;md5=1b33c9f4d17bc4d457bdb23727046837 \
file://LICENCE.phanfw;md5=954dcec0e051f9409812b561ea743bfa
\
@@ -174,6 +176,7 @@ NO_GENERIC_LICENSE[Firmware-moxa] = "LICENCE.moxa"
NO_GENERIC_LICENSE[Firmware-myri10ge_firmware] = "LICENCE.myri10ge_firmware"
NO_GENERIC_LICENSE[Firmware-netronome] = "LICENCE.Netronome"
NO_GENERIC_LICENSE[Firmware-nvidia] = "LICENCE.nvidia"
+NO_GENERIC_LICENSE[Firmware-nxp] = "LICENSE.nxp"
NO_GENERIC_LICENSE[Firmware-OLPC] = "LICENCE.OLPC"
NO_GENERIC_LICENSE[Firmware-ath9k-htc] = "LICENCE.open-ath9k-htc-firmware"
NO_GENERIC_LICENSE[Firmware-phanfw] = "LICENCE.phanfw"
@@ -309,6 +312,16 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
${PN}-nvidia-license \
${PN}-nvidia-tegra-k1 ${PN}-nvidia-tegra \
${PN}-nvidia-gpu \
+ ${PN}-nxp-license \
+ ${PN}-nxp8987-sdio \
+ ${PN}-nxp8997-common \
+ ${PN}-nxp8997-pcie \
+ ${PN}-nxp8997-sdio \
+ ${PN}-nxp9098-common \
+ ${PN}-nxp9098-pcie \
+ ${PN}-nxp9098-sdio \
+ ${PN}-nxpiw416-sdio \
+ ${PN}-nxpiw612-sdio \
${PN}-netronome-license ${PN}-netronome \
${PN}-qat ${PN}-qat-license \
${PN}-qcom-license ${PN}-qcom-yamato-license \
@@ -543,6 +556,42 @@ FILES:${PN}-netronome = " \
RDEPENDS:${PN}-netronome += "${PN}-netronome-license"
+# For NXP
+LICENSE:${PN}-nxp8987-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxp8997-common = "Firmware-nxp"
+LICENSE:${PN}-nxp8997-pcie = "Firmware-nxp"
+LICENSE:${PN}-nxp8997-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxp9098-common = "Firmware-nxp"
+LICENSE:${PN}-nxp9098-pcie = "Firmware-nxp"
+LICENSE:${PN}-nxp9098-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxpiw416-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxpiw612-sdio = "Firmware-nxp"
+LICENSE:${PN}-nxp-license = "Firmware-nxp"
+
+FILES:${PN}-nxp8987-sdio = "${nonarch_base_libdir}/firmware/nxp/*8987*"
+FILES:${PN}-nxp8997-common = " \
+${nonarch_base_libdir}/firmware/nxp/uartuart8997_bt_v4.bin \
+${nonarch_base_libdir}/firmware/nxp/helper_uart_300.bin \
+"
+ALLOW_EMPTY:${PN}-nxp8997-pcie = "1"
+ALLOW_EMPTY:${PN}-nxp8997-sdio = "1"
+FILES:${PN}-nxp9098-common =
"${nonarch_base_libdir}/firmware/nxp/uartuart9098_bt_v1.bin"
+ALLOW_EMPTY:${PN}-nxp9098-pcie = "1"
+ALLOW_EMPTY:${PN}-nxp9098-sdio = "1"
+FILES:${PN}-nxpiw416-sdio = "${nonarch_base_libdir}/firmware/nxp/*iw416*"
+FILES:${PN}-nxpiw612-sdio =
"${nonarch_base_libdir}/firmware/nxp/uartspi_n61x_v1.bin.se"
+FILES:${PN}-nxp-license = "${nonarch_base_libdir}/firmwar
[OE-core] [PATCH] weston: Cleanup and fix x11 and xwayland dependencies
For the x11 backend package config, drop the redundant dependencies libxcb and cairo. The former is listed twice in the package config, while the latter is also listed globally. For the xwayland package config, add the missing dependencies libxcb and libxcursor. These dependencies are hidden when the x11 backend is enabled by default. When the default setting is overridden to disable the x11 backend, the following error occurs: ``` | Run-time dependency xcursor found: NO (tried pkgconfig and cmake) | | ../git/xwayland/meson.build:34:2: ERROR: Problem encountered: xwayland requires xcursor which was not found. Or, you can use '-Dxwayland=false'. ``` Signed-off-by: Tom Hochstein --- meta/recipes-graphics/wayland/weston_11.0.1.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-graphics/wayland/weston_11.0.1.bb b/meta/recipes-graphics/wayland/weston_11.0.1.bb index 4f6ce19915..0838791a6b 100644 --- a/meta/recipes-graphics/wayland/weston_11.0.1.bb +++ b/meta/recipes-graphics/wayland/weston_11.0.1.bb @@ -57,7 +57,7 @@ PACKAGECONFIG[kms] = "-Dbackend-drm=true,-Dbackend-drm=false,drm udev virtual/eg # Weston on Wayland (nested Weston) PACKAGECONFIG[wayland] = "-Dbackend-wayland=true,-Dbackend-wayland=false,virtual/egl virtual/libgles2" # Weston on X11 -PACKAGECONFIG[x11] = "-Dbackend-x11=true,-Dbackend-x11=false,virtual/libx11 libxcb libxcb libxcursor cairo" +PACKAGECONFIG[x11] = "-Dbackend-x11=true,-Dbackend-x11=false,virtual/libx11 libxcb libxcursor" # Headless Weston PACKAGECONFIG[headless] = "-Dbackend-headless=true,-Dbackend-headless=false" # Weston on RDP @@ -73,7 +73,7 @@ PACKAGECONFIG[webp] = "-Dimage-webp=true,-Dimage-webp=false,libwebp" # Weston with systemd-login support PACKAGECONFIG[systemd] = "-Dsystemd=true -Dlauncher-logind=true,-Dsystemd=false -Dlauncher-logind=false,systemd dbus" # Weston with Xwayland support (requires X11 and Wayland) -PACKAGECONFIG[xwayland] = "-Dxwayland=true,-Dxwayland=false,xwayland" +PACKAGECONFIG[xwayland] = "-Dxwayland=true,-Dxwayland=false,libxcb libxcursor xwayland" # colord CMS support PACKAGECONFIG[colord] = "-Ddeprecated-color-management-colord=true,-Ddeprecated-color-management-colord=false,colord" # Clients support -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183289): https://lists.openembedded.org/g/openembedded-core/message/183289 Mute This Topic: https://lists.openembedded.org/mt/99705852/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] piglit: Add missing glslang dependencies
The vulkan configuration requires glslangValidator for build and
runtime.
Fixes configure error:
```
| CMake Error at CMakeLists.txt:191 (message):
| glslangValidator required by vulkan tests not found
```
Fixes runtime error:
```
name: vulkan@shaders@fs-large-local-array
result: fail
returncode: 1
out:
err: glslangValidator: No such file or directory
glslangValidator failed
```
Signed-off-by: Tom Hochstein
---
meta/recipes-graphics/piglit/piglit_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/piglit/piglit_git.bb
b/meta/recipes-graphics/piglit/piglit_git.bb
index 116d2f5d81..6264483bf6 100644
--- a/meta/recipes-graphics/piglit/piglit_git.bb
+++ b/meta/recipes-graphics/piglit/piglit_git.bb
@@ -41,7 +41,7 @@ PACKAGECONFIG[freeglut] =
"-DPIGLIT_USE_GLUT=1,-DPIGLIT_USE_GLUT=0,freeglut,"
PACKAGECONFIG[glx] = "-DPIGLIT_BUILD_GLX_TESTS=ON,-DPIGLIT_BUILD_GLX_TESTS=OFF"
PACKAGECONFIG[opencl] =
"-DPIGLIT_BUILD_CL_TESTS=ON,-DPIGLIT_BUILD_CL_TESTS=OFF,virtual/opencl-icd"
PACKAGECONFIG[x11] =
"-DPIGLIT_BUILD_GL_TESTS=ON,-DPIGLIT_BUILD_GL_TESTS=OFF,${X11_DEPS},
${X11_RDEPS}"
-PACKAGECONFIG[vulkan] =
"-DPIGLIT_BUILD_VK_TESTS=ON,-DPIGLIT_BUILD_VK_TESTS=OFF,vulkan-loader"
+PACKAGECONFIG[vulkan] =
"-DPIGLIT_BUILD_VK_TESTS=ON,-DPIGLIT_BUILD_VK_TESTS=OFF,glslang-native
vulkan-loader,glslang"
export PIGLIT_BUILD_DIR = "../../../../git"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181423):
https://lists.openembedded.org/g/openembedded-core/message/181423
Mute This Topic: https://lists.openembedded.org/mt/98935286/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] oeqa/sdk: Improve Meson test
The meson wrapper setup command detection is broken in the case of an
implicit setup command with an option with a space-separated argument,
but the test was not detecting it since the case was not covered.
Add the option `--warnlevel 1` to the meson command line to cover this
case.
Signed-off-by: Tom Hochstein
---
meta/lib/oeqa/sdk/cases/buildepoxy.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/sdk/cases/buildepoxy.py
b/meta/lib/oeqa/sdk/cases/buildepoxy.py
index ee515be188..147ee3e0ee 100644
--- a/meta/lib/oeqa/sdk/cases/buildepoxy.py
+++ b/meta/lib/oeqa/sdk/cases/buildepoxy.py
@@ -35,7 +35,7 @@ class EpoxyTest(OESDKTestCase):
self.assertTrue(os.path.isdir(dirs["source"]))
os.makedirs(dirs["build"])
-log = self._run("meson -Degl=no -Dglx=no -Dx11=false {build}
{source}".format(**dirs))
+log = self._run("meson --warnlevel 1 -Degl=no -Dglx=no -Dx11=false
{build} {source}".format(**dirs))
# Check that Meson thinks we're doing a cross build and not a
native
self.assertIn("Build type: cross build", log)
self._run("ninja -C {build} -v".format(**dirs))
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178025):
https://lists.openembedded.org/g/openembedded-core/message/178025
Mute This Topic: https://lists.openembedded.org/mt/97371489/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] meson: Fix wrapper handling of implicit setup command
>From an SDK, running a meson setup build without an explicit setup
command can result in a native build when a cross build is expected.
The problem is in meson-wrapper where it tries to detect whether a
setup command is being used. The logic looks through all arguments for
a command, and the first argument it finds that doesn't start with a -
is treated as the command. This doesn't work for an implicit setup
command if any option with a space-separated argument exists. In this
case, the argument is incorrectly selected as the command, causing the
setup command options for the cross build to be excluded from the
command line, and thus a native build.
Improve the logic by just looking at the first argument. If it is
a known comand, then record it. Otherwise just assume it is the
implicit setup command.
Note that this fix does not address the possibility of a new meson
command. Two new echo statements are included to help the user in case
of trouble:
```
~/git/weston-imx$ meson --warnlevel 3 --prefix=/usr -Ddoc=false
-Dbackend-drm-screencast-vaapi=false -Dcolor-management-lcms=false
-Dpipewire=false -Dbackend-x11=false -Dxwayland=true -Dsimple-clients=all
-Dbackend-wayland=false -Dbackend-default=drm -Dbackend-rdp=false
-Dtest-junit-xml=false -Dlauncher-libseat=false -Dimage-jpeg=false
-Dimage-webp=false -Drenderer-g2d=true build
meson-wrapper: Implicit setup command assumed
meson-wrapper: Running meson with setup options: "
--cross-file=/opt/fsl-imx-internal-xwayland/6.1-langdale/sysroots/x86_64-pokysdk-linux/usr/share/meson/aarch64-poky-linux-meson.cross
--native-file=/opt/fsl-imx-internal-xwayland/6.1-langdale/sysroots/x86_64-pokysdk-linux/usr/share/meson/meson.native
"
The Meson build system
Version: 0.63.3
```
Signed-off-by: Tom Hochstein
---
meta/recipes-devtools/meson/meson/meson-wrapper | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/meta/recipes-devtools/meson/meson/meson-wrapper
b/meta/recipes-devtools/meson/meson/meson-wrapper
index fca64a5692..7455985297 100755
--- a/meta/recipes-devtools/meson/meson/meson-wrapper
+++ b/meta/recipes-devtools/meson/meson/meson-wrapper
@@ -13,20 +13,19 @@ fi
# config is already in meson.cross.
unset CC CXX CPP LD AR NM STRIP
-for arg in "$@"; do
-case "$arg" in
--*) continue ;;
-*) SUBCMD="$arg"; break ;;
-esac
-done
+case "$1" in
+setup|configure|dist|install|introspect|init|test|wrap|subprojects|rewrite|compile|devenv|env2mfile|help)
MESON_CMD="$1" ;;
+*) echo meson-wrapper: Implicit setup command assumed; MESON_CMD=setup ;;
+esac
-if [ "$SUBCMD" = "setup" ] || [ -d "$SUBCMD" ]; then
-MESON_SUB_OPTS=" \
+if [ "$MESON_CMD" = "setup" ]; then
+MESON_SETUP_OPTS=" \
--cross-file="$OECORE_NATIVE_SYSROOT/usr/share/meson/${TARGET_PREFIX}meson.cross"
\
--native-file="$OECORE_NATIVE_SYSROOT/usr/share/meson/meson.native" \
"
+echo meson-wrapper: Running meson with setup options: \"$MESON_SETUP_OPTS\"
fi
exec "$OECORE_NATIVE_SYSROOT/usr/bin/meson.real" \
"$@" \
-$MESON_SUB_OPTS
+$MESON_SETUP_OPTS
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178024):
https://lists.openembedded.org/g/openembedded-core/message/178024
Mute This Topic: https://lists.openembedded.org/mt/97371487/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] meson: Fix wrapper handling of implicit setup command
On Fri, Mar 3, 2023 at 11:08 AM, Alexander Kanavin wrote:
>
> This should have been caught by meta/lib/oeqa/sdk/cases/buildepoxy.py
> - why wasn't it? Does the test need to be fixed?
The simple test case doesn't have the problematic syntax. Should I add this to
the patch?
diff --git a/meta/lib/oeqa/sdk/cases/buildepoxy.py
b/meta/lib/oeqa/sdk/cases/buildepoxy.py
index ee515be188..147ee3e0ee 100644
--- a/meta/lib/oeqa/sdk/cases/buildepoxy.py
+++ b/meta/lib/oeqa/sdk/cases/buildepoxy.py
@@ -35,7 +35,7 @@ class EpoxyTest(OESDKTestCase):
self.assertTrue(os.path.isdir(dirs["source"]))
os.makedirs(dirs["build"])
- log = self._run("meson -Degl=no -Dglx=no -Dx11=false {build}
{source}".format(**dirs))
+ log = self._run("meson --warnlevel 1 -Degl=no -Dglx=no -Dx11=false
{build} {source}".format(**dirs))
# Check that Meson thinks we're doing a cross build and not a native
self.assertIn("Build type: cross build", log)
self._run("ninja -C {build} -v".format(**dirs))
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178023):
https://lists.openembedded.org/g/openembedded-core/message/178023
Mute This Topic: https://lists.openembedded.org/mt/97369067/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] meson: Fix wrapper handling of implicit setup command
>From an SDK, running a meson setup build without an explicit setup
command can result in a native build when a cross build is expected.
The problem is in meson-wrapper where it tries to detect whether a
setup command is being used. The logic looks through all arguments for
a command, and the first argument it finds that doesn't start with a -
is treated as the command. This doesn't work for an implicit setup
command if any option with a space-separated argument exists. In this
case, the argument is incorrectly selected as the command, causing the
setup command options for the cross build to be excluded from the
command line, and thus a native build.
Improve the logic by just looking at the first argument. If it is
a known comand, then record it. Otherwise just assume it is the
implicit setup command.
Note that this fix does not address the possibility of a new meson
command. Two new echo statements are included to help the user in case
of trouble:
```
~/git/weston-imx$ meson --warnlevel 3 --prefix=/usr -Ddoc=false
-Dbackend-drm-screencast-vaapi=false -Dcolor-management-lcms=false
-Dpipewire=false -Dbackend-x11=false -Dxwayland=true -Dsimple-clients=all
-Dbackend-wayland=false -Dbackend-default=drm -Dbackend-rdp=false
-Dtest-junit-xml=false -Dlauncher-libseat=false -Dimage-jpeg=false
-Dimage-webp=false -Drenderer-g2d=true build
meson-wrapper: Implicit setup command assumed
meson-wrapper: Running meson with setup options: "
--cross-file=/opt/fsl-imx-internal-xwayland/6.1-langdale/sysroots/x86_64-pokysdk-linux/usr/share/meson/aarch64-poky-linux-meson.cross
--native-file=/opt/fsl-imx-internal-xwayland/6.1-langdale/sysroots/x86_64-pokysdk-linux/usr/share/meson/meson.native
"
The Meson build system
Version: 0.63.3
```
Signed-off-by: Tom Hochstein
---
meta/recipes-devtools/meson/meson/meson-wrapper | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/meta/recipes-devtools/meson/meson/meson-wrapper
b/meta/recipes-devtools/meson/meson/meson-wrapper
index fca64a5692..7455985297 100755
--- a/meta/recipes-devtools/meson/meson/meson-wrapper
+++ b/meta/recipes-devtools/meson/meson/meson-wrapper
@@ -13,20 +13,19 @@ fi
# config is already in meson.cross.
unset CC CXX CPP LD AR NM STRIP
-for arg in "$@"; do
-case "$arg" in
--*) continue ;;
-*) SUBCMD="$arg"; break ;;
-esac
-done
+case "$1" in
+setup|configure|dist|install|introspect|init|test|wrap|subprojects|rewrite|compile|devenv|env2mfile|help)
MESON_CMD="$1" ;;
+*) echo meson-wrapper: Implicit setup command assumed; MESON_CMD=setup ;;
+esac
-if [ "$SUBCMD" = "setup" ] || [ -d "$SUBCMD" ]; then
-MESON_SUB_OPTS=" \
+if [ "$MESON_CMD" = "setup" ]; then
+MESON_SETUP_OPTS=" \
--cross-file="$OECORE_NATIVE_SYSROOT/usr/share/meson/${TARGET_PREFIX}meson.cross"
\
--native-file="$OECORE_NATIVE_SYSROOT/usr/share/meson/meson.native" \
"
+echo meson-wrapper: Running meson with setup options: \"$MESON_SETUP_OPTS\"
fi
exec "$OECORE_NATIVE_SYSROOT/usr/bin/meson.real" \
"$@" \
-$MESON_SUB_OPTS
+$MESON_SETUP_OPTS
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178021):
https://lists.openembedded.org/g/openembedded-core/message/178021
Mute This Topic: https://lists.openembedded.org/mt/97369067/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] [DISTRO|MACHINE]_FEATURES_BACKFILL_CONSIDERED: confusing variable names?
> -Original Message-
> From: Richard Purdie
> Sent: Tuesday, February 28, 2023 4:04 AM
> To: michael.opdenac...@bootlin.com; Tom Hochstein
> ; OE-core c...@lists.openembedded.org>
> Cc: YP docs mailing list
> Subject: Re: [OE-core] [DISTRO|MACHINE]_FEATURES_BACKFILL_CONSIDERED:
> confusing variable names?
>
> On Tue, 2023-02-28 at 10:52 +0100, Michael Opdenacker via
> lists.openembedded.org wrote:
> > Greetings,
> >
> > Thank you all for your replies and comments!
> >
> > On 24.02.23 at 00:24, Tom Hochstein wrote:
> > > I agree. The problem I have with these variable names is that it's
> > > ambiguous
> whether the features will be included or excluded from the backfill. All you
> can
> tell from the names is that the values were 'considered'. What does that mean?
> You have to go to the manual to find the full meaning.
> > >
> > > What's important about the variables is that they will be 'excluded' from
> > > the
> backfill, so this does look much clearer to me:
> > >
> > > DISTRO_FEATURES_BACKFILL_EXCLUDED += "some-feature"
> >
> >
> > Richard, would you accept it if I sent a patch replacing
> > "BACKFILL_CONSIDERED" by "BACKFILL_EXCLUDED" in the two variables?
> >
> > Of course, I can understand if that's too late for the next release, and
> > instead document this oddity, at least before we can make a change again.
>
> I don't want to rush into this. The idea of the variable was that the
> list were things that distro maintainers would need to consider when
> upgrading and then "mark as considered" so in that context, excluding
> them makes less sense. I'm sure there was discussion about the name at
> the time.
Not sure I understand. When you say 'idea of the variable', are you referring
to the BACKFILL variable? I assume so since that seems to be the one that the
distro maintainers will 'consider', right? After they've 'considered' the
BACKFILL, then they will add the ones they _don't want_ to
BACKFILL_CONSIDERED(_AND_NOT_WANTED). The ones they _do want_ are not marked.
>
> I'm nervous about renaming variables in general as it does create pain
> for users upgrading and some community feedback has been that we're
> bordering on frustrating users. I know we have mechanisms now to help
> but it isn't pain free.
This I totally understand
>
> > > Is there a good reason why we have this separate variable and can't just
> > > do
> this?
> > >
> > > DISTRO_FEATURES_BACKFILL:remove = "some-feature"
> >
> >
> > Good question. Maybe because ":remove" is final, and cannot be
> > overridden, if I understood correctly?
>
> Right, the concern would have been it couldn't be undone and the distro
> setups from when this dates from were more complex.
Since every variable is so afflicted by :remove, perhaps this isn't a good
argument, particularly when there is a more general pattern for this: to add an
extra variable at the point of the removal:
MY_DISTRO_FEATURES_BACKFILL_REMOVALS ??= "some-feature"
DISTRO_FEATURES_BACKFILL:remove = "${ MY_DISTRO_FEATURES_BACKFILL_REMOVALS}"
>
> Cheers,
>
> Richard
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177856):
https://lists.openembedded.org/g/openembedded-core/message/177856
Mute This Topic: https://lists.openembedded.org/mt/97187180/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] [DISTRO|MACHINE]_FEATURES_BACKFILL_CONSIDERED: confusing variable names?
I agree. The problem I have with these variable names is that it's ambiguous whether the features will be included or excluded from the backfill. All you can tell from the names is that the values were 'considered'. What does that mean? You have to go to the manual to find the full meaning. What's important about the variables is that they will be 'excluded' from the backfill, so this does look much clearer to me: DISTRO_FEATURES_BACKFILL_EXCLUDED += "some-feature" Is there a good reason why we have this separate variable and can't just do this? DISTRO_FEATURES_BACKFILL:remove = "some-feature" Tom -Original Message- From: openembedded-core@lists.openembedded.org On Behalf Of Michael Opdenacker via lists.openembedded.org Sent: Thursday, February 23, 2023 11:00 AM To: OE-core Cc: YP docs mailing list Subject: [OE-core] [DISTRO|MACHINE]_FEATURES_BACKFILL_CONSIDERED: confusing variable names? Greetings Anybody else finding the DISTRO_FEATURES_BACKFILL_CONSIDERED and MACHINE_FEATURES_BACKFILL_CONSIDERED variable names confusing? According to the documentation about "feature backfilling" (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.yoctoproject.org%2Fref-manual%2Ffeatures.html%23ref-features-backfill=05%7C01%7Ctom.hochstein%40nxp.com%7Cf4e5b1f4523a469612dc08db15bf5d8e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638127683879148065%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=4i2IX0GpQlQXAh8Jausfvb2o1oF6MBZaU144KHKjcKg%3D=0), these variables allow to exclude some features from being backfilled. I'm not a native English speaker, but for me, "considered" carries the intention to include a feature, not to exclude one. Shouldn't we call these variables DISTRO_FEATURES_BACKFILL_EXCLUDED and MACHINE_FEATURES_BACKFILL_EXCLUDED instead ? Thanks in advance Cheers Michael. -- Michael Opdenacker, Bootlin Embedded Linux and Kernel engineering https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbootlin.com%2F=05%7C01%7Ctom.hochstein%40nxp.com%7Cf4e5b1f4523a469612dc08db15bf5d8e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638127683879148065%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=S4rZtW35Uxk1ww8OkrPlCJdlI2FWgIpxHcq7PDq2M1o%3D=0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177638): https://lists.openembedded.org/g/openembedded-core/message/177638 Mute This Topic: https://lists.openembedded.org/mt/97187180/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] nlohmann-json: Allow empty main package for SDK
> -Original Message- > From: Khem Raj > Sent: Monday, February 6, 2023 8:06 PM > > > > -Original Message- > > > From: Martin Jansa > > > Sent: Monday, February 6, 2023 3:13 PM > > > > > > Wrong ML and why do you want to install empty package? Add > > > nlohmann-json-dev to imx-gpu-sdk recipe instead. > > > > On Mon, Feb 6, 2023 at 1:36 PM Tom Hochstein wrote: > > > > It has the advantage of not installing the header in the image. Should the > > -dev > > solution be preferred? > > if these are development headers and libs then yes its better since it > goes with the general philosophy of putting these files in -dev pkgs. This change does not change the -dev packaging. To make my comment more clear, this change has the advantage of not installing the -dev packages in the rootfs, which is an unintended side-effect of Martin's suggestion to "add nlohmann-json-dev to imx-gpu-sdk recipe instead." -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#176831): https://lists.openembedded.org/g/openembedded-core/message/176831 Mute This Topic: https://lists.openembedded.org/mt/96793459/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] nlohmann-json: Allow empty main package for SDK
Oops, I don't often send for non OE-Core and I forgot there was a separate
mailing list for that. I usually just cut and paste from here:
http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Sending_patches
Which makes it easy to overlook the mailing list requirement.
There are several examples in the repo that use this same pattern. Here's one:
https://github.com/openembedded/meta-openembedded/commit/7163946b56539725d5a5868a9318e56e713a4a95
It has the advantage of not installing the header in the image. Should the -dev
solution be preferred?
Tom
From: Martin Jansa
Sent: Monday, February 6, 2023 3:13 PM
To: Tom Hochstein
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [meta-oe][PATCH] nlohmann-json: Allow empty main package
for SDK
Wrong ML and why do you want to install empty package? Add nlohmann-json-dev to
imx-gpu-sdk recipe instead.
On Mon, Feb 6, 2023 at 10:09 PM Tom Hochstein
mailto:tom.hochst...@nxp.com>> wrote:
The header-only package cannot be included in the SDK without marking
the main package with ALLOW_EMPTY.
Fixes rootfs problem:
```
The following packages have unmet dependencies:
imx-gpu-sdk : Depends: nlohmann-json but it is not installable
E: Unable to correct problems, you have held broken packages.
```
Signed-off-by: Tom Hochstein
mailto:tom.hochst...@nxp.com>>
---
meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnlohmann-json_3.11.2.bb%2F=05%7C01%7Ctom.hochstein%40nxp.com%7Ccd434fb892594f67b4df08db0886f900%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638113148012774729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=vhZ3gJZfb%2FF4qX25hkN%2BQIA6jUK6jBFLgsIFAX6dQAQ%3D=0>
| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnlohmann-json_3.11.2.bb%2F=05%7C01%7Ctom.hochstein%40nxp.com%7Ccd434fb892594f67b4df08db0886f900%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638113148012774729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=vhZ3gJZfb%2FF4qX25hkN%2BQIA6jUK6jBFLgsIFAX6dQAQ%3D=0>
b/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnlohmann-json_3.11.2.bb%2F=05%7C01%7Ctom.hochstein%40nxp.com%7Ccd434fb892594f67b4df08db0886f900%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638113148012774729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=vhZ3gJZfb%2FF4qX25hkN%2BQIA6jUK6jBFLgsIFAX6dQAQ%3D=0>
index 502262820..6cf27755e 100644
---
a/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnlohmann-json_3.11.2.bb%2F=05%7C01%7Ctom.hochstein%40nxp.com%7Ccd434fb892594f67b4df08db0886f900%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638113148012774729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=vhZ3gJZfb%2FF4qX25hkN%2BQIA6jUK6jBFLgsIFAX6dQAQ%3D=0>
+++
b/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnlohmann-json_3.11.2.bb%2F=05%7C01%7Ctom.hochstein%40nxp.com%7Ccd434fb892594f67b4df08db0886f900%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638113148012930975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=svBLqUNpOl3rYXMGmHR6RfR9il6dkPxnxENyv6IUCME%3D=0>
@@ -18,7 +18,7 @@ inherit cmake
EXTRA_OECMAKE += "-DJSON_BuildTests=OFF"
# nlohmann-json is a header only C++ library, so the main package will be
empty.
-
+ALLOW_EMPTY:${PN} = "1"
RDEPENDS:${PN}-dev = ""
BBCLASSEXTEND = "native nativesdk"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176799):
https://lists.openembedded.org/g/openembedded-core/message/176799
Mute This Topic: https://lists.openembedded.org/mt/96793459/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] nlohmann-json: Allow empty main package for SDK
The header-only package cannot be included in the SDK without marking
the main package with ALLOW_EMPTY.
Fixes rootfs problem:
```
The following packages have unmet dependencies:
imx-gpu-sdk : Depends: nlohmann-json but it is not installable
E: Unable to correct problems, you have held broken packages.
```
Signed-off-by: Tom Hochstein
---
meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
b/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
index 502262820..6cf27755e 100644
--- a/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
+++ b/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
@@ -18,7 +18,7 @@ inherit cmake
EXTRA_OECMAKE += "-DJSON_BuildTests=OFF"
# nlohmann-json is a header only C++ library, so the main package will be
empty.
-
+ALLOW_EMPTY:${PN} = "1"
RDEPENDS:${PN}-dev = ""
BBCLASSEXTEND = "native nativesdk"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176797):
https://lists.openembedded.org/g/openembedded-core/message/176797
Mute This Topic: https://lists.openembedded.org/mt/96793459/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 v3] gstreamer1.0-plugins-good: Fix libsoup runtime dependency
The runtime dependency on libsoup set via PACKAGECONFIG does not work.
The problem is the dependency is placed on the main package, but the
soup package has no dependency on the main package.
I considered modifying the call to do_split_packages from
gstreamer1.0-plugins-packaging.inc, changing extra_depends from '' to
None:
```
extra_depends -- extra runtime dependencies (RDEPENDS) to be set for
all packages. The default value of None causes a
dependency on the main package (${PN}) - if you do
not want this, pass '' for this parameter.
```
However, the problem with this solution is that it does add the runtime
dependency to _all_ such split packages.
So, fix the problem with an explicit runtime dependency.
Signed-off-by: Tom Hochstein
---
.../gstreamer/gstreamer1.0-plugins-good_1.20.5.bb | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.5.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.5.bb
index f7ade89ef8..0bd953743e 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.5.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.5.bb
@@ -19,6 +19,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
DEPENDS += "gstreamer1.0-plugins-base libcap zlib"
RPROVIDES:${PN}-pulseaudio += "${PN}-pulse"
RPROVIDES:${PN}-soup += "${PN}-souphttpsrc"
+RDEPENDS:${PN}-soup += "${MLPREFIX}${@bb.utils.contains('PACKAGECONFIG',
'soup2', 'libsoup-2.4', 'libsoup', d)}"
PACKAGECONFIG_SOUP ?= "soup3"
@@ -52,13 +53,8 @@ PACKAGECONFIG[libv4l2]=
"-Dv4l2-libv4l2=enabled,-Dv4l2-libv4l2=disabled,v4l-
PACKAGECONFIG[mpg123] = "-Dmpg123=enabled,-Dmpg123=disabled,mpg123"
PACKAGECONFIG[pulseaudio] = "-Dpulse=enabled,-Dpulse=disabled,pulseaudio"
PACKAGECONFIG[qt5]= "-Dqt5=enabled,-Dqt5=disabled,qtbase qtdeclarative
qtbase-native ${QT5WAYLANDDEPENDS}"
-# Starting with version 1.20, the GStreamer soup plugin loads libsoup with
dlopen()
-# instead of linking to it. And instead of using the default libsoup C
headers, it
-# uses its own stub header. Consequently, objdump will not show the libsoup
.so as
-# a dependency, and libsoup won't be added to an image. Fix this by setting
libsoup
-# as RDEPEND.
-PACKAGECONFIG[soup2] = "-Dsoup=enabled,,libsoup-2.4,libsoup-2.4,,soup3"
-PACKAGECONFIG[soup3] = "-Dsoup=enabled,,libsoup,libsoup,,soup2"
+PACKAGECONFIG[soup2] = "-Dsoup=enabled,,libsoup-2.4,,,soup3"
+PACKAGECONFIG[soup3] = "-Dsoup=enabled,,libsoup,,,soup2"
PACKAGECONFIG[speex] = "-Dspeex=enabled,-Dspeex=disabled,speex"
PACKAGECONFIG[rpi]= "-Drpicamsrc=enabled,-Drpicamsrc=disabled,userland"
PACKAGECONFIG[taglib] = "-Dtaglib=enabled,-Dtaglib=disabled,taglib"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175889):
https://lists.openembedded.org/g/openembedded-core/message/175889
Mute This Topic: https://lists.openembedded.org/mt/96288096/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] gstreamer1.0-plugins-good: Fix libsoup runtime dependency
Okay, will this do the trick?
+RDEPENDS:${PN}-soup += "${MLPREFIX}${@bb.utils.contains('PACKAGECONFIG',
'soup2', 'libsoup-2.4', 'libsoup', d)}"
Is this a general rule that explicit RDEPENDS require explicit MLPREFIX?
Tom
-Original Message-
From: Richard Purdie
Sent: Sunday, January 15, 2023 9:09 AM
To: Tom Hochstein ;
openembedded-core@lists.openembedded.org
Subject: Re: [OE-Core][PATCH v2] gstreamer1.0-plugins-good: Fix libsoup runtime
dependency
On Sat, 2023-01-14 at 17:49 -0600, Tom Hochstein wrote:
> The runtime dependency on libsoup set via PACKAGECONFIG does not work.
> The problem is the dependency is placed on the main package, but the
> soup package has no dependency on the main package.
>
> I considered modifying the call to do_split_packages from
> gstreamer1.0-plugins-packaging.inc, changing extra_depends from '' to
> None:
>
> ```
> extra_depends -- extra runtime dependencies (RDEPENDS) to be set for
> all packages. The default value of None causes a
> dependency on the main package (${PN}) - if you do
> not want this, pass '' for this parameter.
> ```
>
> However, the problem with this solution is that it does add the runtime
> dependency to _all_ such split packages.
>
> So, fix the problem with an explicit runtime dependency.
>
> Signed-off-by: Tom Hochstein
> ---
> .../gstreamer/gstreamer1.0-plugins-good_1.20.5.bb | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
Better but there are still multilib issues:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fautobuilder.yoctoproject.org%2Ftyphoon%2F%23%2Fbuilders%2F44%2Fbuilds%2F6551=05%7C01%7Ctom.hochstein%40nxp.com%7C2519f1815a0e4f78782c08daf70a6dc4%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638093921412421859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=tr%2BSVqrVpQ1zPOMB8bDURNFWyurODBuk8SZk0o%2BOvCo%3D=0
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fautobuilder.yoctoproject.org%2Ftyphoon%2F%23%2Fbuilders%2F52%2Fbuilds%2F6425=05%7C01%7Ctom.hochstein%40nxp.com%7C2519f1815a0e4f78782c08daf70a6dc4%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638093921412421859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=dE5w5xWhVoVARs9hl9FGrzL1ckK2N9ARJ84hmdAuqOo%3D=0
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175887):
https://lists.openembedded.org/g/openembedded-core/message/175887
Mute This Topic: https://lists.openembedded.org/mt/96277460/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] gstreamer1.0-plugins-good: Fix libsoup runtime dependency
The runtime dependency on libsoup set via PACKAGECONFIG does not work.
The problem is the dependency is placed on the main package, but the
soup package has no dependency on the main package.
I considered modifying the call to do_split_packages from
gstreamer1.0-plugins-packaging.inc, changing extra_depends from '' to
None:
```
extra_depends -- extra runtime dependencies (RDEPENDS) to be set for
all packages. The default value of None causes a
dependency on the main package (${PN}) - if you do
not want this, pass '' for this parameter.
```
However, the problem with this solution is that it does add the runtime
dependency to _all_ such split packages.
So, fix the problem with an explicit runtime dependency.
Signed-off-by: Tom Hochstein
---
.../gstreamer/gstreamer1.0-plugins-good_1.20.5.bb | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.5.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.5.bb
index f7ade89ef8..ce2a796928 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.5.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.5.bb
@@ -19,6 +19,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
DEPENDS += "gstreamer1.0-plugins-base libcap zlib"
RPROVIDES:${PN}-pulseaudio += "${PN}-pulse"
RPROVIDES:${PN}-soup += "${PN}-souphttpsrc"
+RDEPENDS:${PN}-soup += "${@bb.utils.contains('PACKAGECONFIG', 'soup2',
'libsoup-2.4', 'libsoup', d)}"
PACKAGECONFIG_SOUP ?= "soup3"
@@ -52,13 +53,8 @@ PACKAGECONFIG[libv4l2]=
"-Dv4l2-libv4l2=enabled,-Dv4l2-libv4l2=disabled,v4l-
PACKAGECONFIG[mpg123] = "-Dmpg123=enabled,-Dmpg123=disabled,mpg123"
PACKAGECONFIG[pulseaudio] = "-Dpulse=enabled,-Dpulse=disabled,pulseaudio"
PACKAGECONFIG[qt5]= "-Dqt5=enabled,-Dqt5=disabled,qtbase qtdeclarative
qtbase-native ${QT5WAYLANDDEPENDS}"
-# Starting with version 1.20, the GStreamer soup plugin loads libsoup with
dlopen()
-# instead of linking to it. And instead of using the default libsoup C
headers, it
-# uses its own stub header. Consequently, objdump will not show the libsoup
.so as
-# a dependency, and libsoup won't be added to an image. Fix this by setting
libsoup
-# as RDEPEND.
-PACKAGECONFIG[soup2] = "-Dsoup=enabled,,libsoup-2.4,libsoup-2.4,,soup3"
-PACKAGECONFIG[soup3] = "-Dsoup=enabled,,libsoup,libsoup,,soup2"
+PACKAGECONFIG[soup2] = "-Dsoup=enabled,,libsoup-2.4,,,soup3"
+PACKAGECONFIG[soup3] = "-Dsoup=enabled,,libsoup,,,soup2"
PACKAGECONFIG[speex] = "-Dspeex=enabled,-Dspeex=disabled,speex"
PACKAGECONFIG[rpi]= "-Drpicamsrc=enabled,-Drpicamsrc=disabled,userland"
PACKAGECONFIG[taglib] = "-Dtaglib=enabled,-Dtaglib=disabled,taglib"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175860):
https://lists.openembedded.org/g/openembedded-core/message/175860
Mute This Topic: https://lists.openembedded.org/mt/96277460/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] gstreamer1.0-plugins-good: Fix libsoup runtime dependency
Thanks. An earlier commit [1] did add libsoup back to the DEPENDS list, though
it was not mentioned in the commit message, and I overlooked it in the code
what with the dropping of the -Dsoup=disabled.
[1]
https://github.com/openembedded/openembedded-core/commit/88d30848981db2cb7b1f2021ba07e40976cd789f
V2 coming.
-Original Message-
From: Richard Purdie
Sent: Saturday, January 14, 2023 11:02 AM
To: Tom Hochstein ;
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] gstreamer1.0-plugins-good: Fix libsoup runtime
dependency
On Fri, 2023-01-13 at 16:51 -0600, Tom Hochstein wrote:
> The runtime dependency on libsoup set via PACKAGECONFIG does not work.
> The problem is the dependency is placed on the main package, but the
> soup package has no dependency on the main package.
>
> I considered modifying the call to do_split_packages from
> gstreamer1.0-plugins-packaging.inc, changing extra_depends from '' to
> None:
>
> ```
> extra_depends -- extra runtime dependencies (RDEPENDS) to be set for
> all packages. The default value of None causes a
> dependency on the main package (${PN}) - if you do
> not want this, pass '' for this parameter.
> ```
>
> However, the problem with this solution is that it does add the runtime
> dependency to _all_ such split packages.
>
> So, fix the problem with an explicit runtime dependency.
>
> Signed-off-by: Tom Hochstein
> ---
> .../gstreamer/gstreamer1.0-plugins-good_1.20.5.bb | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
This threw a load of warnings/errors, see:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fautobuilder.yoctoproject.org%2Ftyphoon%2F%23%2Fbuilders%2F83%2Fbuilds%2F4792=05%7C01%7Ctom.hochstein%40nxp.com%7C2a738415ebef4c494dd108daf6511d1f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638093125482952300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=cfdxmtUBAwPNqIcKtqSxdABCkPq6O6S42ZEkn1CrDAg%3D=0
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175859):
https://lists.openembedded.org/g/openembedded-core/message/175859
Mute This Topic: https://lists.openembedded.org/mt/96257892/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] gstreamer1.0-plugins-good: Fix libsoup runtime dependency
The runtime dependency on libsoup set via PACKAGECONFIG does not work.
The problem is the dependency is placed on the main package, but the
soup package has no dependency on the main package.
I considered modifying the call to do_split_packages from
gstreamer1.0-plugins-packaging.inc, changing extra_depends from '' to
None:
```
extra_depends -- extra runtime dependencies (RDEPENDS) to be set for
all packages. The default value of None causes a
dependency on the main package (${PN}) - if you do
not want this, pass '' for this parameter.
```
However, the problem with this solution is that it does add the runtime
dependency to _all_ such split packages.
So, fix the problem with an explicit runtime dependency.
Signed-off-by: Tom Hochstein
---
.../gstreamer/gstreamer1.0-plugins-good_1.20.5.bb | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.5.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.5.bb
index f7ade89ef8..ed48c57311 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.5.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.20.5.bb
@@ -19,6 +19,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
DEPENDS += "gstreamer1.0-plugins-base libcap zlib"
RPROVIDES:${PN}-pulseaudio += "${PN}-pulse"
RPROVIDES:${PN}-soup += "${PN}-souphttpsrc"
+RDEPENDS:${PN}-soup += "${@bb.utils.contains('PACKAGECONFIG', 'soup2',
'libsoup-2.4', 'libsoup', d)}"
PACKAGECONFIG_SOUP ?= "soup3"
@@ -52,13 +53,8 @@ PACKAGECONFIG[libv4l2]=
"-Dv4l2-libv4l2=enabled,-Dv4l2-libv4l2=disabled,v4l-
PACKAGECONFIG[mpg123] = "-Dmpg123=enabled,-Dmpg123=disabled,mpg123"
PACKAGECONFIG[pulseaudio] = "-Dpulse=enabled,-Dpulse=disabled,pulseaudio"
PACKAGECONFIG[qt5]= "-Dqt5=enabled,-Dqt5=disabled,qtbase qtdeclarative
qtbase-native ${QT5WAYLANDDEPENDS}"
-# Starting with version 1.20, the GStreamer soup plugin loads libsoup with
dlopen()
-# instead of linking to it. And instead of using the default libsoup C
headers, it
-# uses its own stub header. Consequently, objdump will not show the libsoup
.so as
-# a dependency, and libsoup won't be added to an image. Fix this by setting
libsoup
-# as RDEPEND.
-PACKAGECONFIG[soup2] = "-Dsoup=enabled,,libsoup-2.4,libsoup-2.4,,soup3"
-PACKAGECONFIG[soup3] = "-Dsoup=enabled,,libsoup,libsoup,,soup2"
+PACKAGECONFIG[soup2] = "-Dsoup=enabled,soup3"
+PACKAGECONFIG[soup3] = "-Dsoup=enabled,soup2"
PACKAGECONFIG[speex] = "-Dspeex=enabled,-Dspeex=disabled,speex"
PACKAGECONFIG[rpi]= "-Drpicamsrc=enabled,-Drpicamsrc=disabled,userland"
PACKAGECONFIG[taglib] = "-Dtaglib=enabled,-Dtaglib=disabled,taglib"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175847):
https://lists.openembedded.org/g/openembedded-core/message/175847
Mute This Topic: https://lists.openembedded.org/mt/96257892/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] vulkan-loader: Move libvulkan.so to main package
Got it, thank you Ross!
-Original Message-
From: Ross Burton
Sent: Tuesday, October 18, 2022 4:52 AM
To: Tom Hochstein
Cc: Martin Jansa ;
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] vulkan-loader: Move libvulkan.so to main package
On 17 Oct 2022, at 17:12, Tom Hochstein wrote:
>
> I found a few examples online for both ways. In SaschaWillems examples, .so
> is used:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSaschaWillems%2FVulkan%2Fblob%2Fmaster%2Fbase%2FVulkanAndroid.cpp%23L142data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220670988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=D5UDy3Fd%2F%2Fq8Hby31cqj4vxn2g8anMNBTZJJMbBdVHo%3Dreserved=0
>
> In Vulkan-Tools there's a mix. Here the implementation falls back to .so.1 if
> .so is not found:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKhronosGroup%2FVulkan-Tools%2Fblob%2Fmaster%2Fvulkaninfo%2Fvulkaninfo.h%23L256-L257data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220670988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=fNOFnmZUbDGZAXGgU5Cq5N4cKmRBgLA7Od7FXcGXpLY%3Dreserved=0
>
> While here only .so is used:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKhronosGroup%2FVulkan-Tools%2Fblob%2Fmaster%2Fcommon%2Fvulkan_wrapper.cpp%23L25data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220827298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mlM7Mr%2FEt9LTalhmHo5Js1UliBABxqpkXHC4V8KfUUk%3Dreserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKhronosGroup%2FVulkan-Tools%2Fblob%2Fmaster%2Fscripts%2Fgenerate_vulkan_wrapper.py%23L2043data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220827298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=PqV8hitdAseUDE4BnKeqvwOT0B9iQ03h77LCzJbxLj8%3Dreserved=0
>
> With no consistency or guidance I'm not sure what the right solution is. At
> first I thought perhaps it is better for the caller to be more specific so
> that a compatibility problem is detected with a dlopen failure. Complicating
> that, though, is that vulkan-loader 1.2 is not compatible with 1.3. Plus why
> does Vulkan-Tools use .so.1 second? Probably to get around the fact that the
> .so is in the dev package?
I did some research.
libvulkan.so* is the Vulkan Loader, which is responsible for finding the
correct driver and bridging the application with the driver.
As per the documentation at
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvulkan.lunarg.com%2Fdoc%2Fsdk%2F1.3.224.1%2Flinux%2FLoaderApplicationInterface.htmldata=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220827298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mZURlOcefEkwdI0VUUUi8i3M8zdvZGXVNsg6I75VfyU%3Dreserved=0,
you can either directly dynamically link (-lvulkan to the compiler) to the
loader , or indirectly link (dlopen()) to the loader. Quoting from the ABI
Versioning section:
"""
On Linux, applications that have a hard dependency on Vulkan should request
linking to the unversioned name libvulkan.so in their build system. For example
by importing the CMake target Vulkan::Vulkan or by using the output of
pkg-config --cflags --libs vulkan as compiler flags. As usual for Linux
libraries, the compiler and linker will resolve this to a dependency on the
correct versioned SONAME, currently libvulkan.so.1. Linux applications that
load Vulkan-Loader dynamically at runtime do not benefit from this mechanism,
and should instead make sure to pass the versioned name such as libvulkan.so.1
to dlopen(), to ensure that they load a compatible version.
"""
Applications which dlopen("libvulkan.so") without a version are broken and
should be fixed. The vulkan tools doing exactly what the documentation says
not to do is just embarrassing to be honest...
So my position is that we don't mess around with the vulkan-loader recipe, but
instead fix the callers.
Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171939):
https://lists.openembedded.org/g/openembedded-core/message/171939
Mute This Topic: ht
Re: [OE-core] [PATCH] vulkan-loader: Move libvulkan.so to main package
I found a few examples online for both ways. In SaschaWillems examples, .so is used: https://github.com/SaschaWillems/Vulkan/blob/master/base/VulkanAndroid.cpp#L142 In Vulkan-Tools there's a mix. Here the implementation falls back to .so.1 if .so is not found: https://github.com/KhronosGroup/Vulkan-Tools/blob/master/vulkaninfo/vulkaninfo.h#L256-L257 While here only .so is used: https://github.com/KhronosGroup/Vulkan-Tools/blob/master/common/vulkan_wrapper.cpp#L25 https://github.com/KhronosGroup/Vulkan-Tools/blob/master/scripts/generate_vulkan_wrapper.py#L2043 With no consistency or guidance I'm not sure what the right solution is. At first I thought perhaps it is better for the caller to be more specific so that a compatibility problem is detected with a dlopen failure. Complicating that, though, is that vulkan-loader 1.2 is not compatible with 1.3. Plus why does Vulkan-Tools use .so.1 second? Probably to get around the fact that the .so is in the dev package? Is it possible and/or reasonable for a binary to load the .so then check the version and handle that at runtime? If so, then including the .so in the main package makes sense. Or should the user in this case be expected to use RDEPENDS to install the .so? From: Martin Jansa Sent: Monday, October 17, 2022 7:29 AM To: Ross Burton Cc: Tom Hochstein ; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH] vulkan-loader: Move libvulkan.so to main package On Mon, Oct 17, 2022 at 2:10 PM Ross Burton mailto:ross.bur...@arm.com>> wrote: On 16 Oct 2022, at 22:43, Tom Hochstein via lists.openembedded.org<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openembedded.org%2F=05%7C01%7Ctom.hochstein%40nxp.com%7Cb79ae30157f142e2468e08dab03b378b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016065621027269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=ldUoyzxYOQMI33kzqUh9CJ15MGI2n0YRf8rwKopwkJw%3D=0> mailto:nxp@lists.openembedded.org>> wrote: > > Since libvulkan.so is commonly loaded dynamically, put it in the main > package. Can you give an example? I'm wondering the same, because e.g. tensorflow-lite. arm-compute-library were also trying to dlopen libOpenCL.so and we've patched them to dlopen libOpenCL.so.1 instead, so why should libvulkan.so be different. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171915): https://lists.openembedded.org/g/openembedded-core/message/171915 Mute This Topic: https://lists.openembedded.org/mt/94372555/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] vulkan-loader: Move libvulkan.so to main package
Since libvulkan.so is commonly loaded dynamically, put it in the main
package.
Signed-off-by: Tom Hochstein
---
meta/recipes-graphics/vulkan/vulkan-loader_1.3.216.0.bb | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-graphics/vulkan/vulkan-loader_1.3.216.0.bb
b/meta/recipes-graphics/vulkan/vulkan-loader_1.3.216.0.bb
index 15a079879b..698ce112dc 100644
--- a/meta/recipes-graphics/vulkan/vulkan-loader_1.3.216.0.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-loader_1.3.216.0.bb
@@ -35,6 +35,11 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES',
'wayland x11', d)}"
PACKAGECONFIG[x11] = "-DBUILD_WSI_XLIB_SUPPORT=ON -DBUILD_WSI_XCB_SUPPORT=ON,
-DBUILD_WSI_XLIB_SUPPORT=OFF -DBUILD_WSI_XCB_SUPPORT=OFF, libxcb libx11
libxrandr"
PACKAGECONFIG[wayland] = "-DBUILD_WSI_WAYLAND_SUPPORT=ON,
-DBUILD_WSI_WAYLAND_SUPPORT=OFF, wayland"
+# libvulkan.so is commonly loaded dynamically, so put it in the main package
+SOLIBS = ".so*"
+FILES_SOLIBSDEV = ""
+INSANE_SKIP:${PN} += "dev-so"
+
RRECOMMENDS:${PN} = "mesa-vulkan-drivers"
UPSTREAM_CHECK_GITTAGREGEX = "sdk-(?P\d+(\.\d+)+)"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171900):
https://lists.openembedded.org/g/openembedded-core/message/171900
Mute This Topic: https://lists.openembedded.org/mt/94372555/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] cmake: Fix CMAKE_SYSTEM_PROCESSOR setting for SDK
When building using an SDK, cmake complains that the target
architecture 'cortexa53-crypto' is unknown. The same build in bitbake
uses the target architecture 'aarch64'.
Set CMAKE_SYSTEM_PROCESSOR the same as for bitbake.
Signed-off-by: Tom Hochstein
---
meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
b/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
index 3ddef12c83..d6a1e0464c 100644
--- a/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
+++ b/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
@@ -11,10 +11,7 @@ set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
set(CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX
"$ENV{OE_CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX}")
-# Set CMAKE_SYSTEM_PROCESSOR from the sysroot name (assuming
processor-distro-os).
-if ($ENV{SDKTARGETSYSROOT} MATCHES "/sysroots/([a-zA-Z0-9_-]+)-.+-.+")
- set(CMAKE_SYSTEM_PROCESSOR ${CMAKE_MATCH_1})
-endif()
+set( CMAKE_SYSTEM_PROCESSOR $ENV{OECORE_TARGET_ARCH} )
# Include the toolchain configuration subscripts
file( GLOB toolchain_config_files "${CMAKE_CURRENT_LIST_FILE}.d/*.cmake" )
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170432):
https://lists.openembedded.org/g/openembedded-core/message/170432
Mute This Topic: https://lists.openembedded.org/mt/93536574/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] connman: Drop redundant nfsroot handling
connman has nfsroot support built in since version 1.34 [1], so the
nfsroot handling in the init script is redundant.
[1]
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=ef0d26e6ef2b883193469f016117d8238c1c9658
Signed-off-by: Tom Hochstein
---
.../connman/connman/connman | 39 +--
1 file changed, 1 insertion(+), 38 deletions(-)
diff --git a/meta/recipes-connectivity/connman/connman/connman
b/meta/recipes-connectivity/connman/connman/connman
index 310a696863..a021fd4655 100644
--- a/meta/recipes-connectivity/connman/connman/connman
+++ b/meta/recipes-connectivity/connman/connman/connman
@@ -10,48 +10,11 @@ fi
set -e
-nfsroot=0
-
-exec 9<&0 < /proc/mounts
-while read dev mtpt fstype rest; do
- if test $mtpt = "/" ; then
- case $fstype in
- nfs | nfs4)
- nfsroot=1
- break
- ;;
- *)
- ;;
- esac
- fi
-done
-
do_start() {
- if test $nfsroot -eq 1 ; then
- NET_DEVS=`cat /proc/net/dev | sed -ne 's/^\([a-zA-Z0-9
]*\):.*$/\1/p'`
- NET_ADDR=`cat /proc/cmdline | sed -ne 's/^.*ip=\([^ :]*\).*$/\1/p'`
-
- if [ ! -z "$NET_ADDR" ]; then
- if [ "$NET_ADDR" = dhcp ]; then
- ethn=`ifconfig | grep "^eth" | sed -e
"s/\(eth[0-9]\)\(.*\)/\1/"`
- if [ ! -z "$ethn" ]; then
- EXTRA_PARAM="$EXTRA_PARAM -I $ethn"
- fi
- else
- for i in $NET_DEVS; do
- ADDR=`ifconfig $i | sed 's/addr://g' | sed -ne
's/^.*inet \([0-9.]*\) .*$/\1/p'`
- if [ "$NET_ADDR" = "$ADDR" ]; then
- EXTRA_PARAM="$EXTRA_PARAM -I $i"
- break
- fi
- done
- fi
- fi
- fi
if [ -f @DATADIR@/connman/wired-setup ] ; then
. @DATADIR@/connman/wired-setup
fi
- $DAEMON $EXTRA_PARAM
+ $DAEMON
}
do_stop() {
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170425):
https://lists.openembedded.org/g/openembedded-core/message/170425
Mute This Topic: https://lists.openembedded.org/mt/93531638/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] piglit: Add PACKAGECONFIG for glx and opencl
- Allow GLX tests to be disabled for systems that don't support it.
- Allow OpenCL tests to be enabled.
Signed-off-by: Tom Hochstein
---
...roper-WAYLAND_INCLUDE_DIRS-variable.patch} | 0
...-shader.c-do-not-hardcode-build-pat.patch} | 0
...ists.txt-add-missing-endian.h-check.patch} | 0
...n-t-enable-GLX-if-tests-are-disabled.patch | 32 +++
meta/recipes-graphics/piglit/piglit_git.bb| 12 ---
5 files changed, 39 insertions(+), 5 deletions(-)
rename
meta/recipes-graphics/piglit/piglit/{0001-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch
=> 0002-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch} (100%)
rename
meta/recipes-graphics/piglit/piglit/{0002-tests-util-piglit-shader.c-do-not-hardcode-build-pat.patch
=> 0003-tests-util-piglit-shader.c-do-not-hardcode-build-pat.patch} (100%)
rename
meta/recipes-graphics/piglit/piglit/{0001-CMakeLists.txt-add-missing-endian.h-check.patch
=> 0004-CMakeLists.txt-add-missing-endian.h-check.patch} (100%)
create mode 100644
meta/recipes-graphics/piglit/piglit/0005-cmake-Don-t-enable-GLX-if-tests-are-disabled.patch
diff --git
a/meta/recipes-graphics/piglit/piglit/0001-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch
b/meta/recipes-graphics/piglit/piglit/0002-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch
similarity index 100%
rename from
meta/recipes-graphics/piglit/piglit/0001-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch
rename to
meta/recipes-graphics/piglit/piglit/0002-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch
diff --git
a/meta/recipes-graphics/piglit/piglit/0002-tests-util-piglit-shader.c-do-not-hardcode-build-pat.patch
b/meta/recipes-graphics/piglit/piglit/0003-tests-util-piglit-shader.c-do-not-hardcode-build-pat.patch
similarity index 100%
rename from
meta/recipes-graphics/piglit/piglit/0002-tests-util-piglit-shader.c-do-not-hardcode-build-pat.patch
rename to
meta/recipes-graphics/piglit/piglit/0003-tests-util-piglit-shader.c-do-not-hardcode-build-pat.patch
diff --git
a/meta/recipes-graphics/piglit/piglit/0001-CMakeLists.txt-add-missing-endian.h-check.patch
b/meta/recipes-graphics/piglit/piglit/0004-CMakeLists.txt-add-missing-endian.h-check.patch
similarity index 100%
rename from
meta/recipes-graphics/piglit/piglit/0001-CMakeLists.txt-add-missing-endian.h-check.patch
rename to
meta/recipes-graphics/piglit/piglit/0004-CMakeLists.txt-add-missing-endian.h-check.patch
diff --git
a/meta/recipes-graphics/piglit/piglit/0005-cmake-Don-t-enable-GLX-if-tests-are-disabled.patch
b/meta/recipes-graphics/piglit/piglit/0005-cmake-Don-t-enable-GLX-if-tests-are-disabled.patch
new file mode 100644
index 00..ef6fda0f4e
--- /dev/null
+++
b/meta/recipes-graphics/piglit/piglit/0005-cmake-Don-t-enable-GLX-if-tests-are-disabled.patch
@@ -0,0 +1,32 @@
+From 13ff43fe760ac343b33d8e8c84b89886aac07116 Mon Sep 17 00:00:00 2001
+From: Tom Hochstein
+Date: Fri, 3 Jun 2022 10:44:29 -0500
+Subject: [PATCH] cmake: Don't enable GLX if tests are disabled
+
+Allow building for systems that don't support GLX.
+
+Upstream-Status: Submitted
[https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/720]
+Signed-off-by: Tom Hochstein
+---
+ CMakeLists.txt | 5 +
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index e1aeb5ddf..85e171aba 100644
+--- a/CMakeLists.txt
b/CMakeLists.txt
+@@ -134,10 +134,7 @@ if(PIGLIT_BUILD_CL_TESTS)
+ endif(PIGLIT_BUILD_CL_TESTS)
+
+ IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
+- if(X11_FOUND AND OPENGL_gl_LIBRARY)
+- # Assume the system has GLX. In the future, systems may exist
+- # with libGL and libX11 but no GLX, but that world hasn't
+- # arrived yet.
++ if(X11_FOUND AND OPENGL_gl_LIBRARY AND PIGLIT_BUILD_GLX_TESTS)
+ set(PIGLIT_HAS_GLX True)
+ add_definitions(-DPIGLIT_HAS_GLX)
+ endif()
+--
+2.17.1
+
diff --git a/meta/recipes-graphics/piglit/piglit_git.bb
b/meta/recipes-graphics/piglit/piglit_git.bb
index 7c1bc89c22..29360a246b 100644
--- a/meta/recipes-graphics/piglit/piglit_git.bb
+++ b/meta/recipes-graphics/piglit/piglit_git.bb
@@ -8,10 +8,10 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=b2beded7103a3d8a442a2a0391d607b0"
SRC_URI =
"git://gitlab.freedesktop.org/mesa/piglit.git;protocol=https;branch=main \
file://0001-cmake-install-bash-completions-in-the-right-place.patch
\
- file://0001-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch \
-
file://0002-tests-util-piglit-shader.c-do-not-hardcode-build-pat.patch \
- file://0001-CMakeLists.txt-add-missing-endian.h-check.patch \
- "
+ file://0002-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch \
+
file://0003-tests-util-piglit-shader.c-do-not-hardcode-build-pat.patch \
+ file://0004-CMakeLists.txt-add-missing-endian.h-check.patch \
+
[OE-core] [PATCH] uboot-config.bbclass: Raise error for bad key
If an invalid key is used, the class ignores the error, with an
indeterminate result. In my case, the problem surfaced in do_deploy:
```
| cp: cannot stat
'/.../build/tmp/work/imx6qdlsabresd-fsl-linux-gnueabi/u-boot-imx-mfgtool/2022.04-r0/deploy-u-boot-imx-mfgtool/u-boot.imx':
No such file or
| directory
```
The root cause of this was that the uboot config key did not match
a valid option. With the fix, the error is caught by the class:
```
ERROR: Nothing PROVIDES 'u-boot-imx-mfgtool'
u-boot-imx-mfgtool was skipped: The selected UBOOT_CONFIG key ['mfgtool'] has
no match in dict_keys(['sd-fslc', 'sd-imx', 'sd-optee-imx', 'sata-imx',
'mfgtool-imx']).
```
Signed-off-by: Tom Hochstein
---
meta/classes/uboot-config.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/uboot-config.bbclass
b/meta/classes/uboot-config.bbclass
index b9ad35821a..e8da8c7452 100644
--- a/meta/classes/uboot-config.bbclass
+++ b/meta/classes/uboot-config.bbclass
@@ -125,5 +125,6 @@ python () {
else:
bb.debug(1, "Appending '%s' to UBOOT_BINARIES." %
ubootbinary)
d.appendVar('UBOOT_BINARIES', ' ' + ubootbinary)
-break
+return
+raise bb.parse.SkipRecipe("The selected UBOOT_CONFIG key %s has no
match in %s." % (ubootconfig, ubootconfigflags.keys()))
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168614):
https://lists.openembedded.org/g/openembedded-core/message/168614
Mute This Topic: https://lists.openembedded.org/mt/92676883/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] gobject-introspection-data: Disable cache for g-ir-scanner
An intermittent failure occurs in libical-native do_compile:
| Traceback (most recent call last):
| File
"/.../build/tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/python3.10/shutil.py",
line 813, in move
| os.rename(src, real_dst)
| OSError: [Errno 18] Invalid cross-device link:
'/tmp/g-ir-scanner-cache-adxo_2bq' ->
'/home/bamboo/.cache/g-ir-scanner/bab9a83d2cd93e62ed005a2c1d4f89ae75c67251'
|
| During handling of the above exception, another exception occurred:
|
| Traceback (most recent call last):
| File
"/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/bin/g-ir-scanner",
line 99, in
| sys.exit(scanner_main(sys.argv))
| File
"/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/scannermain.py",
line 590, in scanner_main
| transformer = create_transformer(namespace, options)
| File
"/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/scannermain.py",
line 409, in create_transformer
| transformer.register_include(include_obj)
| File
"/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/transformer.py",
line 140, in register_include
| self._parse_include(filename)
| File
"/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/transformer.py",
line 230, in _parse_include
| self._parse_include(dep_filename)
| File
"/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/transformer.py",
line 225, in _parse_include
| self._cachestore.store(filename, parser)
| File
"/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/cachestore.py",
line 153, in store
| shutil.move(tmp_filename, store_filename)
| File
"/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/python3.10/shutil.py",
line 833, in move
| copy_function(src, real_dst)
| File
"/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/python3.10/shutil.py",
line 435, in copy2
| copystat(src, dst, follow_symlinks=follow_symlinks)
| File
"/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/python3.10/shutil.py",
line 374, in copystat
| lookup("utime")(dst, ns=(st.st_atime_ns, st.st_mtime_ns),
| FileNotFoundError: [Errno 2] No such file or directory
A similar issue is described in a fix for gobject-introspection-native.
https://github.com/openembedded/openembedded-core/commit/d3c48ff7d19e86b2338b1778f9563969bba3d336
The problem was fixed there by setting the environment variable
GI_SCANNER_DISABLE_CACHE to disable the use of $HOME/.cache.
Extend the fix to users of gobject-instropection by promoting the fix
to the bbclass.
Signed-off-by: Tom Hochstein
---
meta/classes/gobject-introspection-data.bbclass | 5 +
.../gobject-introspection/gobject-introspection_1.72.0.bb| 3 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/classes/gobject-introspection-data.bbclass
b/meta/classes/gobject-introspection-data.bbclass
index 2ef684626a..d90cdb4839 100644
--- a/meta/classes/gobject-introspection-data.bbclass
+++ b/meta/classes/gobject-introspection-data.bbclass
@@ -5,3 +5,8 @@
# so that qemu use can be avoided when necessary.
GI_DATA_ENABLED ?= "${@bb.utils.contains('DISTRO_FEATURES',
'gobject-introspection-data', \
bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode',
'True', 'False', d), 'False', d)}"
+
+do_compile:prepend() {
+# This prevents g-ir-scanner from writing cache data to $HOME
+export GI_SCANNER_DISABLE_CACHE=1
+}
diff --git
a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.72.0.bb
b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.72.0.bb
index 355e77d107..9a47e908b7 100644
--- a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.72.0.bb
+++ b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.72.0.bb
@@ -113,9 +113,6 @@ EOF
}
do_compile:prepend() {
-# This prevents g-ir-scanner from writing cache data to $HOME
-export GI_SCANNER_DISABLE_CACHE=1
-
# Needed to run g-ir unit tests, which won't be able to find the built
libraries otherwise
export GIR_EXTRA_LIBS_PATH=$B/.libs
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168197):
https://lists.openembedded.org/g/openembedded-core/message/168197
Mute This Topic: https://lists.openembedded.org/mt/92458797/21656
Gro
[OE-core] [meta-python][PATCH] python3-pybind11: Override pip install variables
Fix the pip install variables since the default values don't work
here.
Signed-off-by: Tom Hochstein
---
meta-python/recipes-devtools/python/python3-pybind11_2.8.1.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta-python/recipes-devtools/python/python3-pybind11_2.8.1.bb
b/meta-python/recipes-devtools/python/python3-pybind11_2.8.1.bb
index dfacb41f1..4d94e2033 100644
--- a/meta-python/recipes-devtools/python/python3-pybind11_2.8.1.bb
+++ b/meta-python/recipes-devtools/python/python3-pybind11_2.8.1.bb
@@ -19,6 +19,9 @@ EXTRA_OECMAKE = "-DPYBIND11_TEST=OFF"
inherit cmake setuptools3 python3native
+PIP_INSTALL_DIST_PATH = "${S}/dist"
+PIP_INSTALL_PACKAGE = "pybind11"
+
do_configure() {
cmake_do_configure
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162513):
https://lists.openembedded.org/g/openembedded-core/message/162513
Mute This Topic: https://lists.openembedded.org/mt/89457175/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] bitbake.conf: add BB_NUMBER_THREADS to BB_HASHEXCLUDE_COMMON
> -Original Message- > From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Richard Purdie via > lists.openembedded.org > Sent: Monday, February 28, 2022 8:57 AM > To: Rasmus Villemoes ; openembedded- > c...@lists.openembedded.org > Subject: Re: [OE-core] [PATCH] bitbake.conf: add BB_NUMBER_THREADS to > BB_HASHEXCLUDE_COMMON > > > Just to check, are the meta-imx people aware of it and able to fix the real > problem? Yes, I will fix it. Thanks! Tom -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#162506): https://lists.openembedded.org/g/openembedded-core/message/162506 Mute This Topic: https://lists.openembedded.org/mt/89446852/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] xwayland: Add xkbcomp runtime dependency
Ping.
> -Original Message-
> From: Tom Hochstein
> Sent: Wednesday, January 19, 2022 5:49 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Tom Hochstein
> Subject: [PATCH] xwayland: Add xkbcomp runtime dependency
>
> Trying to run an xterm fails with the error:
> xterm: Xt error: Can't open display: :0
>
> Checking systemctl status weston shows an error:
> Jan 19 21:24:16 imx8mq-evk weston[396]: sh: line 1: /usr/bin/xkbcomp: No such
> file or directory
>
> Adding xkbcomp to the rootfs fixes these errors. Checking the history one
> finds
> that the runtime dependency for the old xserver was removed because it wasn't
> in the correct location [1], then restored because it was still needed [2].
>
> [1] https://github.com/openembedded/openembedded-
> core/commit/bdcc5e8f1286d288baf410458efc39a59b68d751
> [2] https://github.com/openembedded/openembedded-
> core/commit/f2330ebc3071d780cbc6d1ddab5c54bfadf8fffc
>
> Signed-off-by: Tom Hochstein
> ---
> meta/recipes-graphics/xwayland/xwayland_21.1.3.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-graphics/xwayland/xwayland_21.1.3.bb
> b/meta/recipes-graphics/xwayland/xwayland_21.1.3.bb
> index 5d083e8ada..7ea40d9486 100644
> --- a/meta/recipes-graphics/xwayland/xwayland_21.1.3.bb
> +++ b/meta/recipes-graphics/xwayland/xwayland_21.1.3.bb
> @@ -42,3 +42,4 @@ do_install:append() {
>
> FILES:${PN} += "${libdir}/xorg/protocol.txt"
>
> +RDEPENDS:${PN} += "xkbcomp"
> --
> 2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161131):
https://lists.openembedded.org/g/openembedded-core/message/161131
Mute This Topic: https://lists.openembedded.org/mt/88548155/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] xwayland: Add xkbcomp runtime dependency
Trying to run an xterm fails with the error:
xterm: Xt error: Can't open display: :0
Checking systemctl status weston shows an error:
Jan 19 21:24:16 imx8mq-evk weston[396]: sh: line 1: /usr/bin/xkbcomp: No such
file or directory
Adding xkbcomp to the rootfs fixes these errors. Checking the history
one finds that the runtime dependency for the old xserver was
removed because it wasn't in the correct location [1], then restored
because it was still needed [2].
[1]
https://github.com/openembedded/openembedded-core/commit/bdcc5e8f1286d288baf410458efc39a59b68d751
[2]
https://github.com/openembedded/openembedded-core/commit/f2330ebc3071d780cbc6d1ddab5c54bfadf8fffc
Signed-off-by: Tom Hochstein
---
meta/recipes-graphics/xwayland/xwayland_21.1.3.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-graphics/xwayland/xwayland_21.1.3.bb
b/meta/recipes-graphics/xwayland/xwayland_21.1.3.bb
index 5d083e8ada..7ea40d9486 100644
--- a/meta/recipes-graphics/xwayland/xwayland_21.1.3.bb
+++ b/meta/recipes-graphics/xwayland/xwayland_21.1.3.bb
@@ -42,3 +42,4 @@ do_install:append() {
FILES:${PN} += "${libdir}/xorg/protocol.txt"
+RDEPENDS:${PN} += "xkbcomp"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160746):
https://lists.openembedded.org/g/openembedded-core/message/160746
Mute This Topic: https://lists.openembedded.org/mt/88548155/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] CMAKE_SYSTEM_PROCESSOR inconsistent in SDK
A colleague notes a cmake problem in the SDK due to CMAKE_SYSTEM_PROCESSOR being set to 'cortexa53-crypto', which the package doesn't recognize. The package builds fine with bitbake because CMAKE_SYSTEM_PROCESSOR is set to 'aarch64', which the package does recognize. The value for the SDK comes from this commit: https://github.com/openembedded/openembedded-core/commit/4143f3b0ce0d0c52f5b0babc1bb16ac0ac9610eb#diff-68a2f5f7520be29f69417255d4067d5e97b8681596cd851d946d241c8a1dda76 Is there a problem with this commit? Or is there something missing that prevents 'cortexa53-crypto' to resolve to the more general 'aarch64'? Tom <> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159803): https://lists.openembedded.org/g/openembedded-core/message/159803 Mute This Topic: https://lists.openembedded.org/mt/87773810/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] pls comment on weston non-PAM patch (link inside)
Thanks Alex. @Otavio<mailto:otavio.salva...@ossystems.com.br> pushed the hardest for the use case and I don't really have anything to add. Given that Pekka has suggested that there is a better approach without weston-launch, it seems that removing the patch is fine. In the worst case we can backport the patch to meta-freescale until we have a new solution. Tom From: Alexander Kanavin Sent: Friday, November 19, 2021 11:06 AM To: OE-core ; Tom Hochstein ; Denys Dmytriyenko Cc: ppaala...@gmail.com Subject: Re: pls comment on weston non-PAM patch (link inside) Hello guys, reminding you to speak up in the patch submission; if you don't, upstream will close it without merging, and I will start working towards removing the patch from Yocto as well. Alex On Fri, 12 Nov 2021 at 10:48, Alexander Kanavin mailto:alex.kana...@gmail.com>> wrote: Hello folks, I sent the weston non-PAM patch upstream and they have raised questions about its validity, can you please comment on it? https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/725<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fwayland%2Fweston%2F-%2Fmerge_requests%2F725=04%7C01%7Ctom.hochstein%40nxp.com%7C6a003f79d8a44b3beaf008d9ab7ee8ad%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637729383818649026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=mOGax0pBnQjJBMrDsfv6bv%2FgZ96u%2Fd5UcP3wZDph36Q%3D=0> Thanks, Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#158525): https://lists.openembedded.org/g/openembedded-core/message/158525 Mute This Topic: https://lists.openembedded.org/mt/87003161/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [honister][PATCH 3/3] bitbake.conf: Use wayland distro feature for native builds
The wayland-scanner is missing from SDKs with weston, but the weston build requires wayland-scanner. Allow the distro feature in order to include the wayland-scanner packages via nativesdk-packagegroup-sdk-host.bb. Signed-off-by: Tom Hochstein Signed-off-by: Richard Purdie (cherry picked from commit 858cc6f257e22e39df83f4808ea27c6d12cd1b80) --- meta/conf/bitbake.conf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 9274322e3a..c2cb2f0d9d 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -850,8 +850,8 @@ DISTRO_FEATURES_NATIVESDK ?= "x11" # Normally target distro features will not be applied to native builds: # Native distro features on this list will use the target feature value -DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation debuginfod opengl" -DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation debuginfod opengl" +DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation debuginfod opengl wayland" +DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation debuginfod opengl wayland" DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit gobject-introspection-data ldconfig" MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode" -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157993): https://lists.openembedded.org/g/openembedded-core/message/157993 Mute This Topic: https://lists.openembedded.org/mt/86919167/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [honister][PATCH 1/3] wayland: Fix wayland-tools packaging
There are some packaging problems due to the wayland-tools packaging
implementation. The wayland-tools package currently looks like this:
wayland-tools
└── usr
├── bin
│ └── wayland-scanner
└── share
└── wayland
├── wayland.dtd
├── wayland-scanner.mk
└── wayland.xml
The files wayland.dtd and wayland.xml belong in the main package,
while wayland-scanner.mk belongs in wayland-dev.
Fix the wayland.dtd and wayland.xml packaging by prepending the
wayland-tools package and dropping the main package FILES variable
override. The file wayland-scanner.mk is included in the main
package by default, and so must be explicitly added to wayland-dev.
Signed-off-by: Tom Hochstein
Signed-off-by: Richard Purdie
(cherry picked from commit a31fbec45d24df5b74091940d0e0b2daf34d8492)
---
meta/recipes-graphics/wayland/wayland_1.19.0.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/wayland/wayland_1.19.0.bb
b/meta/recipes-graphics/wayland/wayland_1.19.0.bb
index d6e468497d..5f8b972f76 100644
--- a/meta/recipes-graphics/wayland/wayland_1.19.0.bb
+++ b/meta/recipes-graphics/wayland/wayland_1.19.0.bb
@@ -52,10 +52,10 @@ sysroot_stage_all:append:class-target () {
cp ${STAGING_DATADIR_NATIVE}/aclocal/wayland-scanner.m4
${SYSROOT_DESTDIR}/${datadir}/aclocal/
}
-PACKAGES += "${PN}-tools"
+PACKAGES =+ "${PN}-tools"
-FILES:${PN} = "${libdir}/*${SOLIBS}"
-FILES:${PN}-tools += "${bindir} ${datadir}/wayland"
+FILES:${PN}-tools = "${bindir}/wayland-scanner"
+FILES:${PN}-dev += "${datadir}/${BPN}/wayland-scanner.mk"
BBCLASSEXTEND = "native nativesdk"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157991):
https://lists.openembedded.org/g/openembedded-core/message/157991
Mute This Topic: https://lists.openembedded.org/mt/86919162/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [honister][PATCH 2/3] nativesdk-packagegroup-sdk-host.bb: Update host tools for wayland
The wayland-scanner host tool required to build weston is moved to the
wayland-tools package, so update the SDK host tools list accordingly.
Also, the weston build requires wayland-scanner.pc to find wayland-scanner,
so add wayland-dev.
Signed-off-by: Tom Hochstein
Signed-off-by: Richard Purdie
(cherry picked from commit 31ed91bdbb0ec05730fb98d7cc523bb46aca50e3)
---
.../packagegroups/nativesdk-packagegroup-sdk-host.bb| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index 39e5002bb7..9166a0851f 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -25,7 +25,7 @@ RDEPENDS:${PN} = "\
nativesdk-makedevs \
nativesdk-cmake \
nativesdk-meson \
-${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland',
'', d)} \
+${@bb.utils.contains('DISTRO_FEATURES', 'wayland',
'nativesdk-wayland-tools nativesdk-wayland-dev', '', d)} \
nativesdk-sdk-provides-dummy \
nativesdk-bison \
nativesdk-flex \
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157992):
https://lists.openembedded.org/g/openembedded-core/message/157992
Mute This Topic: https://lists.openembedded.org/mt/86919164/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 3/3] bitbake.conf: Use wayland distro feature for native builds
The wayland-scanner is missing from SDKs with weston, but the weston build requires wayland-scanner. Allow the distro feature in order to include the wayland-scanner packages via nativesdk-packagegroup-sdk-host.bb. Signed-off-by: Tom Hochstein --- meta/conf/bitbake.conf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 790f2f7a8c..71c1e52ad6 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -869,8 +869,8 @@ DISTRO_FEATURES_NATIVESDK ?= "x11" # Normally target distro features will not be applied to native builds: # Native distro features on this list will use the target feature value -DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation debuginfod opengl" -DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation debuginfod opengl" +DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation debuginfod opengl wayland" +DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation debuginfod opengl wayland" DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit gobject-introspection-data ldconfig" MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode" -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157960): https://lists.openembedded.org/g/openembedded-core/message/157960 Mute This Topic: https://lists.openembedded.org/mt/86888902/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/3] nativesdk-packagegroup-sdk-host.bb: Update host tools for wayland
The wayland-scanner host tool required to build weston is moved to the
wayland-tools package, so update the SDK host tools list accordingly.
Also, the weston build requires wayland-scanner.pc to find wayland-scanner,
so add wayland-dev.
Signed-off-by: Tom Hochstein
---
.../packagegroups/nativesdk-packagegroup-sdk-host.bb| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index 39e5002bb7..9166a0851f 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -25,7 +25,7 @@ RDEPENDS:${PN} = "\
nativesdk-makedevs \
nativesdk-cmake \
nativesdk-meson \
-${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland',
'', d)} \
+${@bb.utils.contains('DISTRO_FEATURES', 'wayland',
'nativesdk-wayland-tools nativesdk-wayland-dev', '', d)} \
nativesdk-sdk-provides-dummy \
nativesdk-bison \
nativesdk-flex \
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157959):
https://lists.openembedded.org/g/openembedded-core/message/157959
Mute This Topic: https://lists.openembedded.org/mt/86888900/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/3] wayland: Fix wayland-tools packaging
There are some packaging problems due to the wayland-tools packaging
implementation. The wayland-tools package currently looks like this:
wayland-tools
└── usr
├── bin
│ └── wayland-scanner
└── share
└── wayland
├── wayland.dtd
├── wayland-scanner.mk
└── wayland.xml
The files wayland.dtd and wayland.xml belong in the main package,
while wayland-scanner.mk belongs in wayland-dev.
Fix the wayland.dtd and wayland.xml packaging by prepending the
wayland-tools package and dropping the main package FILES variable
override. The file wayland-scanner.mk is included in the main
package by default, and so must be explicitly added to wayland-dev.
Signed-off-by: Tom Hochstein
---
meta/recipes-graphics/wayland/wayland_1.19.0.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/wayland/wayland_1.19.0.bb
b/meta/recipes-graphics/wayland/wayland_1.19.0.bb
index d6e468497d..5f8b972f76 100644
--- a/meta/recipes-graphics/wayland/wayland_1.19.0.bb
+++ b/meta/recipes-graphics/wayland/wayland_1.19.0.bb
@@ -52,10 +52,10 @@ sysroot_stage_all:append:class-target () {
cp ${STAGING_DATADIR_NATIVE}/aclocal/wayland-scanner.m4
${SYSROOT_DESTDIR}/${datadir}/aclocal/
}
-PACKAGES += "${PN}-tools"
+PACKAGES =+ "${PN}-tools"
-FILES:${PN} = "${libdir}/*${SOLIBS}"
-FILES:${PN}-tools += "${bindir} ${datadir}/wayland"
+FILES:${PN}-tools = "${bindir}/wayland-scanner"
+FILES:${PN}-dev += "${datadir}/${BPN}/wayland-scanner.mk"
BBCLASSEXTEND = "native nativesdk"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157958):
https://lists.openembedded.org/g/openembedded-core/message/157958
Mute This Topic: https://lists.openembedded.org/mt/8691/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/3] bitbake.conf: Use wayland distro feature for native builds
The wayland-scanner is missing from SDKs with weston, but the weston build requires wayland-scanner. Allow the distro feature in order to include the wayland-scanner packages via nativesdk-packagegroup-sdk-host.bb. Signed-off-by: Tom Hochstein --- meta/conf/bitbake.conf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 790f2f7a8c..71c1e52ad6 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -869,8 +869,8 @@ DISTRO_FEATURES_NATIVESDK ?= "x11" # Normally target distro features will not be applied to native builds: # Native distro features on this list will use the target feature value -DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation debuginfod opengl" -DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation debuginfod opengl" +DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation debuginfod opengl wayland" +DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation debuginfod opengl wayland" DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit gobject-introspection-data ldconfig" MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode" -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157956): https://lists.openembedded.org/g/openembedded-core/message/157956 Mute This Topic: https://lists.openembedded.org/mt/86885059/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/3] nativesdk-packagegroup-sdk-host.bb: Update host tools for wayland
The wayland-scanner host tool required to build weston is moved to the
wayland-tools package, so update the SDK host tools list accordingly.
Also, the weston build requires wayland-scanner.pc to find wayland-scanner,
so add wayland-tools-dev.
Signed-off-by: Tom Hochstein
---
.../packagegroups/nativesdk-packagegroup-sdk-host.bb| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index 39e5002bb7..16752026d0 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -25,7 +25,7 @@ RDEPENDS:${PN} = "\
nativesdk-makedevs \
nativesdk-cmake \
nativesdk-meson \
-${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland',
'', d)} \
+${@bb.utils.contains('DISTRO_FEATURES', 'wayland',
'nativesdk-wayland-tools nativesdk-wayland-tools-dev', '', d)} \
nativesdk-sdk-provides-dummy \
nativesdk-bison \
nativesdk-flex \
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157955):
https://lists.openembedded.org/g/openembedded-core/message/157955
Mute This Topic: https://lists.openembedded.org/mt/86885057/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/3] wayland: Fix wayland-tools packaging problems
There are several packaging problems due to the wayland-tools packaging
implementation. The wayland-tools package currently looks like this:
wayland-tools
└── usr
├── bin
│ └── wayland-scanner
└── share
└── wayland
├── wayland.dtd
├── wayland-scanner.mk
└── wayland.xml
The files wayland-scanner.pc and wayland-scanner.m4 are incorrectly
located in the main package. The files wayland.dtd and wayland.xml
are incorrectly located here but belong in the main package.
Fix the problems by moving wayland-tools before the other packages,
adding wayland-tools-dev, and dropping the main package FILES
variable override as no longer needed.
After the fix wayland-tools and wayland-tools-dev look like this:
wayland-tools
└── usr
└── bin
└── wayland-scanner
wayland-tools-dev
└── usr
├── lib
│ └── pkgconfig
│ └── wayland-scanner.pc
└── share
├── aclocal
│ └── wayland-scanner.m4
└── wayland
└── wayland-scanner.mk
Signed-off-by: Tom Hochstein
---
meta/recipes-graphics/wayland/wayland_1.19.0.bb | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/wayland/wayland_1.19.0.bb
b/meta/recipes-graphics/wayland/wayland_1.19.0.bb
index d6e468497d..74d6d65e9e 100644
--- a/meta/recipes-graphics/wayland/wayland_1.19.0.bb
+++ b/meta/recipes-graphics/wayland/wayland_1.19.0.bb
@@ -52,10 +52,14 @@ sysroot_stage_all:append:class-target () {
cp ${STAGING_DATADIR_NATIVE}/aclocal/wayland-scanner.m4
${SYSROOT_DESTDIR}/${datadir}/aclocal/
}
-PACKAGES += "${PN}-tools"
+PACKAGES =+ "${PN}-tools ${PN}-tools-dev"
-FILES:${PN} = "${libdir}/*${SOLIBS}"
-FILES:${PN}-tools += "${bindir} ${datadir}/wayland"
+FILES:${PN}-tools = "${bindir}/wayland-scanner"
+FILES:${PN}-tools-dev = " \
+${libdir}/pkgconfig/wayland-scanner.pc \
+${datadir}/aclocal/wayland-scanner.m4 \
+${datadir}/wayland/wayland-scanner.mk \
+"
BBCLASSEXTEND = "native nativesdk"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157954):
https://lists.openembedded.org/g/openembedded-core/message/157954
Mute This Topic: https://lists.openembedded.org/mt/86885053/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] weston systemd watchdog
Hi Khem, This is regarding the weston systemd watchdog timeout of 20 seconds: https://github.com/openembedded/openembedded-core/commit/c21fa5a291ab207a084285935ab73a0b4225c965#diff-ac8a4b56ade4a43a070c93486fb1d7606573da5d44de96bc1529d15b0b216660R36 For GPU-limited parts, we see watchdog timeouts during intense testing, though the part is not hung, it's just going to take longer than 20 seconds. I stumbled across the following systemd commit, which looks like the watchdog used to default to 180 seconds. Yet even then was under scrutiny because it was causing un-necessary failures more often than not: https://github.com/systemd/systemd/commit/21d0dd5a89fe0ef259ca51ebea9f39dd79a341c2#diff-9d3c1cd071b0f173aaf53a7799ac5765bb3a58d0d07125f075b6b49112f0a425 Do you think the default should be raised? Or should we just make a special case in our layer? Tom <> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155193): https://lists.openembedded.org/g/openembedded-core/message/155193 Mute This Topic: https://lists.openembedded.org/mt/85096163/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 2/2] gstreamer1.0-plugins-base: Use bb.utils.filter to reduce code
> -Original Message-
> From: openembedded-core@lists.openembedded.org
> On Behalf Of Otavio Salvador via
> lists.openembedded.org
> Sent: Thursday, April 15, 2021 9:59 AM
> +OPENGL_WINSYS_append = "${@bb.utils.filter('PACKAGECONFIG', 'x11 gbm wayland
> dispmanx egl viv-fb', d)}"
Needs a leading space?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150588):
https://lists.openembedded.org/g/openembedded-core/message/150588
Mute This Topic: https://lists.openembedded.org/mt/82118763/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] glm: Fix packaging for header-only recipe
On Thu, Jan 28, 2021 at 10:57 PM Khem Raj <mailto:raj.k...@gmail.com> wrote: > > On Thu, Jan 28, 2021 at 5:44 PM Tom Hochstein <mailto:tom.hochst...@nxp.com> > wrote: > > Set ALLOW_EMPTY for the main package to "1" for this header-only recipe. > > This > > allows the SDK to be created properly when there is an RDEPENDS on glm. > > Runtime dependency on a header only package seems a bit iffy it's perhaps > better to depend on glm-dev perhaps ? Well, it's all iffy in my mind since these are just different workarounds for the root problem that header-only packages are not included in the SDK. If you think including the headers in the image is the better workaround, then I will switch to that. Tom -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147461): https://lists.openembedded.org/g/openembedded-core/message/147461 Mute This Topic: https://lists.openembedded.org/mt/80200725/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] glm: Fix packaging for header-only recipe
Set ALLOW_EMPTY for the main package to "1" for this header-only recipe. This
allows the SDK to be created properly when there is an RDEPENDS on glm.
Signed-off-by: Tom Hochstein
---
meta-oe/recipes-graphics/glm/glm_0.9.9.6.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta-oe/recipes-graphics/glm/glm_0.9.9.6.bb
b/meta-oe/recipes-graphics/glm/glm_0.9.9.6.bb
index e2f4dbebc..019e6257d 100644
--- a/meta-oe/recipes-graphics/glm/glm_0.9.9.6.bb
+++ b/meta-oe/recipes-graphics/glm/glm_0.9.9.6.bb
@@ -34,6 +34,7 @@ do_install() {
}
-RDEPENDS_${PN}-dev = ""
+# This is a header-only library, so the main package will be empty.
+ALLOW_EMPTY_${PN} = "1"
BBCLASSEXTEND = "native"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147422):
https://lists.openembedded.org/g/openembedded-core/message/147422
Mute This Topic: https://lists.openembedded.org/mt/80200725/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] [RFC] openssl: Enable cryptodev-linux by default
This is a Request for Comment. Would it be a good idea to enable cryptodev-linux
by default, gaining hardware acceleration where supported? Are there any
unacceptable drawbacks? What happens on hardware without acceleration?
Signed-off-by: Tom Hochstein
---
meta/recipes-connectivity/openssl/openssl_1.1.1i.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
index 5617f337e0..d4c19f1a52 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
@@ -28,7 +28,7 @@ SRC_URI[sha256sum] =
"e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee0
inherit lib_package multilib_header multilib_script ptest
MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
-PACKAGECONFIG ?= ""
+PACKAGECONFIG ?= "cryptodev-linux"
PACKAGECONFIG_class-native = ""
PACKAGECONFIG_class-nativesdk = ""
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147412):
https://lists.openembedded.org/g/openembedded-core/message/147412
Mute This Topic: https://lists.openembedded.org/mt/80195674/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] mesa: Add xcb-fixes to loader when using x11 and dri3
> -Original Message- > From: Andrey Zhizhikin > Sent: Thursday, November 12, 2020 3:23 PM > > I believe all patch files are located in `files` folder, while this > patch tries to put it into `mesa` folder which does not exist yet? Is > it intended here? > It was a mistake, thanks for catching it. V2 submitted. Tom -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#144537): https://lists.openembedded.org/g/openembedded-core/message/144537 Mute This Topic: https://lists.openembedded.org/mt/78060312/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] mesa: Add xcb-fixes to loader when using x11 and dri3
Backport fix for undefined symbol for xcb_xfixes_create_region in
loader_dri3_helper.c.
Signed-off-by: Tom Hochstein
---
...xes-to-loader-when-using-x11-and-dri.patch | 36 +++
meta/recipes-graphics/mesa/mesa.inc | 1 +
2 files changed, 37 insertions(+)
create mode 100644
meta/recipes-graphics/mesa/files/0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch
diff --git
a/meta/recipes-graphics/mesa/files/0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch
b/meta/recipes-graphics/mesa/files/0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch
new file mode 100644
index 00..9ee72880a2
--- /dev/null
+++
b/meta/recipes-graphics/mesa/files/0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch
@@ -0,0 +1,36 @@
+From cf17d6251653f4a98e7c4f904ea2f0bc0ecedd5c Mon Sep 17 00:00:00 2001
+From: Duncan Hopkins
+Date: Thu, 15 Oct 2020 12:14:57 +0100
+Subject: [PATCH] meson: Add xcb-fixes to loader when using x11 and dri3. Fixes
+ undefined symbol for xcb_xfixes_create_region in loader_dri3_helper.c
+
+loader_dr3_helper.c uses xcb_xfixes_create_region() that requires
dep_xcb_xfixes to link. This is dependent on with_platform_x11 and with_dri3.
+But the source meson file does not set this up dependent on with_dri3.
+The build was initialsed using platforms=x11 and gallium-drivers=zink,swrast.
+
+Reviewed-by: Eric Anholt
+Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7164>
+
+Upstream-Status: Backport [cf17d6251653f4a98e7c4f904ea2f0bc0ecedd5c]
+
+---
+ meson.build | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/meson.build b/meson.build
+index cfe02fa6373..3cb3c904927 100644
+--- a/meson.build
b/meson.build
+@@ -1782,7 +1782,8 @@ if with_platform_x11
+ dep_xxf86vm = dependency('xxf86vm')
+ endif
+ endif
+- if (with_egl or (
++ if (with_egl or
++ with_dri3 or (
+ with_gallium_vdpau or with_gallium_xvmc or with_gallium_xa or
+ with_gallium_omx != 'disabled'))
+ dep_xcb_xfixes = dependency('xcb-xfixes')
+--
+2.17.1
+
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 5a6caf2662..ca593b8b1f 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -22,6 +22,7 @@ SRC_URI =
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \
file://0001-anv-fix-a-build-race-between-generating-a-header-and.patch \
+
file://0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch \
"
SRC_URI[sha256sum] =
"d1a46d9a3f291bc0e0374600bdcb59844fa3eafaa50398e472a36fc65fd0244a"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144536):
https://lists.openembedded.org/g/openembedded-core/message/144536
Mute This Topic: https://lists.openembedded.org/mt/78217060/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] gtest and gmock not added to SDK
On Fri, May 22, 2020 at 03:33 PM, Andre McCurdy wrote:
>
> On Fri, May 22, 2020 at 2:29 PM Otavio Salvador
> wrote:
>
>> On Fri, May 22, 2020 at 5:48 PM Tom Hochstein
>> wrote:
>>
>>> The gtest and gmock packages provided by googletest are not added to the
>>> SDK by default. I assume it is because the googletest main package is
>>> empty?
>>
>>
>
> Are you including googletest in the image used to create the SDK or
> gmock and gtest?
>
> It looks like gmock and gtest are only mentioned in the googletest
> recipe as PROVIDES, so they are aliases for build time dependencies
> only. For run time dependencies you should use googletest.
Right, I should have mentioned that. I have a DEPENDS on gtest for a package in
my image. To fix the SDK, I added an RDEPENDS on googletest from the same
package.
>
>
>
>>
>>> I added an RDEPENDS_${PN} from the dependent package to fix it. Is there a
>>> better solution?
>>
>> You can change the packages to have their `-dev` to rdepends on
>> `gtest/gmock-dev` for example.
>>
>> --
>> Otavio Salvador O.S. Systems
>> http://www.ossystems.com.br http://code.ossystems.com.br
>> Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138615):
https://lists.openembedded.org/g/openembedded-core/message/138615
Mute This Topic: https://lists.openembedded.org/mt/74408257/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] gtest and gmock not added to SDK
The gtest and gmock packages provided by googletest are not added to the SDK by
default. I assume it is because the googletest main package is empty?
I added an RDEPENDS_${PN} from the dependent package to fix it. Is there a
better solution?
Tom
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138610):
https://lists.openembedded.org/g/openembedded-core/message/138610
Mute This Topic: https://lists.openembedded.org/mt/74408257/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Cannot disable weston
We are no longer able to disable weston service with standard `systemctl disable weston@root.service`. On boot the service is started again. It seems likely this started with the introduction of a starting udev rule: https://github.com/openembedded/openembedded-core/commit/aa3bced2e1de2f4ba507aa014835b06edccc138a#diff-d92aa97566c1bd0dd1eb817bb4511cda Is this behaving correctly? Can the rule be made to honor the service disablement? Tom <>-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#137989): https://lists.openembedded.org/g/openembedded-core/message/137989 Mute This Topic: https://lists.openembedded.org/mt/74037529/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][zeus][PATCH] security_flags.inc: fix flags missing from SDK toolchain
The security flags were missing from the SDK toolchain
because they were added specifically to class-target.
Add them to class-cross-canadian as well (since the SDK environment
file is created from cross-canadian target flags).
Signed-off-by: Tom Hochstein
Signed-off-by: Antoine Manache
Signed-off-by: Richard Purdie
---
meta/conf/distro/include/security_flags.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index aaf04e9e59..568d03693c 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -57,6 +57,8 @@ SECURITY_STRINGFORMAT_pn-gcc = ""
TARGET_CC_ARCH_append_class-target = " ${SECURITY_CFLAGS}"
TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
+TARGET_CC_ARCH_append_class-cross-canadian = " ${SECURITY_CFLAGS}"
+TARGET_LDFLAGS_append_class-cross-canadian = " ${SECURITY_LDFLAGS}"
SECURITY_STACK_PROTECTOR_pn-gcc-runtime = ""
SECURITY_STACK_PROTECTOR_pn-glibc = ""
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136692):
https://lists.openembedded.org/g/openembedded-core/message/136692
Mute This Topic: https://lists.openembedded.org/mt/72540579/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] security_flags.inc: fix flags missing from SDK toolchain
> -Original Message- > From: Richard Purdie > Sent: Tuesday, March 24, 2020 5:58 PM > To: Antoine Manache ; Tom Hochstein > > Cc: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core][PATCH] security_flags.inc: fix flags missing from SDK > toolchain > > I've therefore taken Tom's version with some tweaks to the commit > message. Thanks. Can we get this on zeus? Do I need to cherry-pick and submit the patch? Tom -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#136685): https://lists.openembedded.org/g/openembedded-core/message/136685 Mute This Topic: https://lists.openembedded.org/mt/72521987/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] security_flags.inc: fix flags missing from SDK toolchain
> -Original Message-
> From: Richard Purdie
> Sent: Tuesday, March 24, 2020 1:03 PM
> To: Antoine Manache ; Tom Hochstein
>
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core][PATCH] security_flags.inc: fix flags missing from SDK
> toolchain
>
> On Tue, 2020-03-24 at 18:25 +0100, Antoine Manache wrote:
> > I've already sent this patch few months ago but not taken into
> > account yet.
>
> Can someone explain more about the issue here please?
>
> Shouldn't these flags be added to the SDK toolchain environment files
> rather than coded into the compiler? Why aren't they being coded in? or
> is gcc being misconfigured?
The recipe meta-environment inherits cross-canadian and toolchain-scripts. The
latter generates the SDK toolchain environment file using TARGET_CC_ARCH and
TARGET_LDFLAGS like this:
echo 'export CC="${TARGET_PREFIX}gcc ${TARGET_CC_ARCH}
--sysroot=$SDKTARGETSYSROOT"' >> $script
echo 'export LDFLAGS="${TARGET_LDFLAGS}"' >> $script
https://github.com/openembedded/openembedded-core/blob/master/meta/classes/toolchain-scripts.bbclass#L82
With class-cross-canadian as the applicable override, updating the security
flags for class-target does nothing for the SDK toolchain, hence the proposed
fix:
TARGET_CC_ARCH_append_class-target = " ${SECURITY_CFLAGS}"
+TARGET_CC_ARCH_append_class-cross-canadian = " ${SECURITY_CFLAGS}"
TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
+TARGET_LDFLAGS_append_class-cross-canadian = " ${SECURITY_LDFLAGS}"
Tom
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136665):
https://lists.openembedded.org/g/openembedded-core/message/136665
Mute This Topic: https://lists.openembedded.org/mt/72521987/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] security_flags.inc: fix flags missing from SDK toolchain
The security flags were missing from the SDK toolchain
because they were added specifically to class-target.
Add them to class-cross-canadian as well.
Signed-off-by: Tom Hochstein
---
meta/conf/distro/include/security_flags.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index aaf04e9e59..568d03693c 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -57,6 +57,8 @@ SECURITY_STRINGFORMAT_pn-gcc = ""
TARGET_CC_ARCH_append_class-target = " ${SECURITY_CFLAGS}"
TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
+TARGET_CC_ARCH_append_class-cross-canadian = " ${SECURITY_CFLAGS}"
+TARGET_LDFLAGS_append_class-cross-canadian = " ${SECURITY_LDFLAGS}"
SECURITY_STACK_PROTECTOR_pn-gcc-runtime = ""
SECURITY_STACK_PROTECTOR_pn-glibc = ""
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136657):
https://lists.openembedded.org/g/openembedded-core/message/136657
Mute This Topic: https://lists.openembedded.org/mt/72521987/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] bitbake.conf: Fix nativesdk-wayland missing from SDK
nativesdk-wayland was not being added to the SDK because it relies on checking the distro feature. This fixes that by filtering the wayland feature to the SDK build. Signed-off-by: Tom Hochstein --- meta/conf/bitbake.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 4b544a22cd..e44de34a00 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -830,7 +830,7 @@ DISTRO_FEATURES_NATIVESDK ?= "x11" # Normally target distro features will not be applied to native builds: # Native distro features on this list will use the target feature value DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation" -DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation" +DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation wayland" DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit gobject-introspection-data ldconfig" MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode" -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#136573): https://lists.openembedded.org/g/Openembedded-core/message/136573 Mute This Topic: https://lists.openembedded.org/mt/72439818/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] wayland: Fix wayland-scanner missing from SDK
The FILES variable was customized to package wayland-scanner
in the -dev package. However, this is only correct for the
target package and causes wayland-scanner to be missing from
the SDK.
Fix the nativesdk packaging by properly limiting the
wayland-scanner -dev packaging to the target.
Signed-off-by: Tom Hochstein
---
meta/recipes-graphics/wayland/wayland_1.18.0.bb | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/wayland_1.18.0.bb
b/meta/recipes-graphics/wayland/wayland_1.18.0.bb
index 00be3aac27..4d110a6e1f 100644
--- a/meta/recipes-graphics/wayland/wayland_1.18.0.bb
+++ b/meta/recipes-graphics/wayland/wayland_1.18.0.bb
@@ -54,8 +54,10 @@ sysroot_stage_all_append_class-target () {
cp ${STAGING_DATADIR_NATIVE}/aclocal/wayland-scanner.m4
${SYSROOT_DESTDIR}/${datadir}/aclocal/
}
-FILES_${PN} = "${libdir}/*${SOLIBS}"
-FILES_${PN}-dev += "${bindir} ${datadir}/wayland"
+# Place wayland-scanner in the -dev package for the target.
+# Leave it in the main package for native so it is included
+# in the SDK.
+FILES_${PN}-dev_append_class-target = " ${bindir} ${datadir}/wayland"
BBCLASSEXTEND = "native nativesdk"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136574):
https://lists.openembedded.org/g/Openembedded-core/message/136574
Mute This Topic: https://lists.openembedded.org/mt/72439819/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] bitbake.conf: Fix nativesdk-wayland missing from SDK
nativesdk-wayland was not being added to the SDK because it relies on checking the distro feature. This fixes that by filtering the wayland feature to the SDK build. Signed-off-by: Tom Hochstein --- meta/conf/bitbake.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 4b544a22cd..e44de34a00 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -830,7 +830,7 @@ DISTRO_FEATURES_NATIVESDK ?= "x11" # Normally target distro features will not be applied to native builds: # Native distro features on this list will use the target feature value DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation" -DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation" +DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation wayland" DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit gobject-introspection-data ldconfig" MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] wayland: Fix wayland-scanner missing from SDK
The FILES variable is customized to package wayland-scanner
in the target -dev package. However, this is not correct for
the nativesdk packages and causes wayland-scanner to be
missing from the SDK.
Fix the nativesdk packaging by properly limiting the
wayland-scanner target packaging.
Signed-off-by: Tom Hochstein
---
meta/recipes-graphics/wayland/wayland_1.18.0.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/wayland_1.18.0.bb
b/meta/recipes-graphics/wayland/wayland_1.18.0.bb
index 00be3aac27..c7098483bc 100644
--- a/meta/recipes-graphics/wayland/wayland_1.18.0.bb
+++ b/meta/recipes-graphics/wayland/wayland_1.18.0.bb
@@ -54,8 +54,8 @@ sysroot_stage_all_append_class-target () {
cp ${STAGING_DATADIR_NATIVE}/aclocal/wayland-scanner.m4
${SYSROOT_DESTDIR}/${datadir}/aclocal/
}
-FILES_${PN} = "${libdir}/*${SOLIBS}"
-FILES_${PN}-dev += "${bindir} ${datadir}/wayland"
+FILES_${PN}_class-target = "${libdir}/*${SOLIBS}"
+FILES_${PN}-dev_append_class-target = " ${bindir} ${datadir}/wayland"
BBCLASSEXTEND = "native nativesdk"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] wayland: Fix wayland-scanner missing from SDK
The FILES variable is customized to package wayland-scanner
in the target -dev package. However, this is not correct for
the nativesdk packages and causes wayland-scanner to be
missing from the SDK.
Fix the nativesdk packaging by properly limiting the
wayland-scanner target packaging.
Signed-off-by: Tom Hochstein
---
meta/recipes-graphics/wayland/wayland_1.17.0.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/wayland_1.17.0.bb
b/meta/recipes-graphics/wayland/wayland_1.17.0.bb
index 12916a0c40..cb4ff2c20b 100644
--- a/meta/recipes-graphics/wayland/wayland_1.17.0.bb
+++ b/meta/recipes-graphics/wayland/wayland_1.17.0.bb
@@ -43,7 +43,7 @@ sysroot_stage_all_append_class-target () {
cp ${STAGING_DATADIR_NATIVE}/aclocal/wayland-scanner.m4
${SYSROOT_DESTDIR}/${datadir}/aclocal/
}
-FILES_${PN} = "${libdir}/*${SOLIBS}"
-FILES_${PN}-dev += "${bindir} ${datadir}/wayland"
+FILES_${PN}_class-target = "${libdir}/*${SOLIBS}"
+FILES_${PN}-dev_append_class-target = " ${bindir} ${datadir}/wayland"
BBCLASSEXTEND = "native nativesdk"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] bitbake.conf: Add wayland to DISTRO_FEATURES_FILTER_NATIVESDK
nativesdk-wayland was not being added to the SDK. This fixes that. Signed-off-by: Tom Hochstein --- meta/conf/bitbake.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 2da7c5849a..a93099bf0c 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -826,7 +826,7 @@ DISTRO_FEATURES_NATIVESDK ?= "x11" # Normally target distro features will not be applied to native builds: # Native distro features on this list will use the target feature value DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation" -DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation" +DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation wayland" DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit gobject-introspection-data ldconfig" MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] devtool/standard.py: Allow recipe to disable menuconfig logic
I made a PR as well:
https://github.com/openembedded/openembedded-core/pull/57
Tom
> -Original Message-
> From: Schrempf Frieder
> Sent: Wednesday, December 4, 2019 10:44 AM
> To: Tom Hochstein ;
> openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/2] devtool/standard.py: Allow recipe to
> disable menuconfig logic
>
> Hi,
>
> On 20.11.19 20:25, Tom Hochstein wrote:
> > u-boot.inc supports u-boot recipes with or without menuconfig [1].
> > However, running devtool on a u-boot recipe that does not support menuconfig
> > results in an error:
> >
> > cp: cannot stat
> > '/home/r60874/upstream/fsl-xwayland/tmp/work/imx8mmevk-fsl-linux/u-boot-imx/2018.03-r0/u-boot-imx-
> 2018.03//.config': No such file or directory
> >
> > The problem is the devtool logic assumes that any recipe with a
> > do_menuconfig task
> > will generate a .config in do_configure().
> >
> > Fix the problem by removing the assumption with a flag that the recipe can
> > control,
> > like this:
> >
> > do_configure() {
> > if [ menuconfig-supported ]; then
> > ...
> > else
> > DEVTOOL_DISABLE_MENUCONFIG=true
> > fi
> > }
> >
> > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenembedded%2Fopenembedded-
> core%2Fcommit%2F11278e3b2c75be80645b9841763a97dbb35daadcdata=02%7C01%7Ctom.hochstein%40nxp.com%7C5d668f64
> d3a044abb11e08d778d92bef%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637110746452407756sdata=AHjvw91G8N7
> Wuf%2BORB%2B5E7cxE5cciCpnEktIqkoFKMY%3Dreserved=0
> >
> > Signed-off-by: Tom Hochstein
>
> I'm experiencing this issue since moving to zeus. Your fix in this
> series works fine for me and I would really like to see this merged in zeus.
>
> Thanks,
> Frieder
>
> > ---
> > scripts/lib/devtool/standard.py | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/lib/devtool/standard.py
> > b/scripts/lib/devtool/standard.py
> > index 8d9c1a3022..66bd1415c3 100644
> > --- a/scripts/lib/devtool/standard.py
> > +++ b/scripts/lib/devtool/standard.py
> > @@ -940,8 +940,10 @@ def modify(args, config, basepath, workspace):
> > '}\n')
> > if rd.getVarFlag('do_menuconfig','task'):
> > f.write('\ndo_configure_append() {\n'
> > -'cp ${B}/.config ${S}/.config.baseline\n'
> > -'ln -sfT ${B}/.config ${S}/.config.new\n'
> > +'if [ ! ${DEVTOOL_DISABLE_MENUCONFIG} ]; then\n'
> > +'cp ${B}/.config ${S}/.config.baseline\n'
> > +'ln -sfT ${B}/.config ${S}/.config.new\n'
> > +'fi\n'
> > '}\n')
> > if initial_rev:
> > f.write('\n# initial_rev: %s\n' % initial_rev)
> >
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] devtool/standard.py: Allow recipe to disable menuconfig logic
> -Original Message-
> From: Peter Kjellerstedt
> Sent: Thursday, November 21, 2019 4:24 AM
> To: Tom Hochstein ;
> openembedded-core@lists.openembedded.org
> Subject: RE: [OE-core] [PATCH 1/2] devtool/standard.py: Allow recipe to
> disable menuconfig logic
>
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org > boun...@lists.openembedded.org> On Behalf Of Tom Hochstein
> > Sent: den 20 november 2019 20:26
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH 1/2] devtool/standard.py: Allow recipe to
> > disable menuconfig logic
> >
> > @@ -940,8 +940,10 @@ def modify(args, config, basepath, workspace):
> > '}\n')
> > if rd.getVarFlag('do_menuconfig','task'):
> > f.write('\ndo_configure_append() {\n'
> > -'cp ${B}/.config ${S}/.config.baseline\n'
> > -'ln -sfT ${B}/.config ${S}/.config.new\n'
> > +'if [ ! ${DEVTOOL_DISABLE_MENUCONFIG} ]; then\n'
> > +'cp ${B}/.config ${S}/.config.baseline\n'
> > +'ln -sfT ${B}/.config ${S}/.config.new\n'
> > +'fi\n'
>
> Why do you need the extra variable? Why not just check if the .config
> file exists before copying it:
>
> 'if -e ${B}/.config; then\n'
> 'cp ${B}/.config ${S}/.config.baseline\n'
> 'ln -sfT ${B}/.config ${S}/.config.new\n'
> 'fi\n'
>
> > '}\n')
> > if initial_rev:
> > f.write('\n# initial_rev: %s\n' % initial_rev)
> > --
> > 2.17.1
>
> //Peter
I wanted to preserve the existing error handling in the case that menuconfig is
supported and .config is unexpectedly missing. Having the cp fail immediately
seems best.
Tom
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] u-boot.inc: Fix devtool build u-boot for u-boot without menuconfig
For u-boot recipes without menuconfig support, running devtool results
in a do_configure error:
cp: cannot stat
'/home/r60874/upstream/fsl-xwayland/tmp/work/imx8mmevk-fsl-linux/u-boot-imx/2018.03-r0/u-boot-imx-2018.03//.config':
No such file or directory
The problem arises because u-boot.inc supports recipes with and without
menuconfig.
Fix the problem by properly setting DEVTOOL_DISABLE_MENUCONFIG so that devtool
can control logic that applies only for menuconfig support.
Signed-off-by: Tom Hochstein
---
meta/recipes-bsp/u-boot/u-boot.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
b/meta/recipes-bsp/u-boot/u-boot.inc
index 9a754fd09b..d241347bf7 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -87,6 +87,8 @@ do_configure () {
fi
merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
cml1_do_configure
+else
+DEVTOOL_DISABLE_MENUCONFIG=true
fi
}
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] devtool/standard.py: Allow recipe to disable menuconfig logic
u-boot.inc supports u-boot recipes with or without menuconfig [1].
However, running devtool on a u-boot recipe that does not support menuconfig
results in an error:
cp: cannot stat
'/home/r60874/upstream/fsl-xwayland/tmp/work/imx8mmevk-fsl-linux/u-boot-imx/2018.03-r0/u-boot-imx-2018.03//.config':
No such file or directory
The problem is the devtool logic assumes that any recipe with a do_menuconfig
task
will generate a .config in do_configure().
Fix the problem by removing the assumption with a flag that the recipe can
control,
like this:
do_configure() {
if [ menuconfig-supported ]; then
...
else
DEVTOOL_DISABLE_MENUCONFIG=true
fi
}
[1]
https://github.com/openembedded/openembedded-core/commit/11278e3b2c75be80645b9841763a97dbb35daadc
Signed-off-by: Tom Hochstein
---
scripts/lib/devtool/standard.py | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 8d9c1a3022..66bd1415c3 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -940,8 +940,10 @@ def modify(args, config, basepath, workspace):
'}\n')
if rd.getVarFlag('do_menuconfig','task'):
f.write('\ndo_configure_append() {\n'
-'cp ${B}/.config ${S}/.config.baseline\n'
-'ln -sfT ${B}/.config ${S}/.config.new\n'
+'if [ ! ${DEVTOOL_DISABLE_MENUCONFIG} ]; then\n'
+'cp ${B}/.config ${S}/.config.baseline\n'
+'ln -sfT ${B}/.config ${S}/.config.new\n'
+'fi\n'
'}\n')
if initial_rev:
f.write('\n# initial_rev: %s\n' % initial_rev)
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] python3-native certificate failure
Thanks, Ross. That is indeed what we are doing now.
Tom
-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, April 19, 2018 5:36 AM
To: Tom Hochstein <tom.hochst...@nxp.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] python3-native certificate failure
Why don't you just use the host Python?
This is probably due to the certificate path not being correctly remapped as it
goes in/out of sstate, you'll have to tell the SSL code explicitly where to
find the certificates.
Ross
On 4 April 2018 at 21:09, Tom Hochstein <tom.hochst...@nxp.com> wrote:
> I am trying to download a URL from a source package using
> python3-native, but it is failing with a certificate failure. I added
> DEPENDS on ca-certificates-native and python3-certifi-native, but it
> doesn’t seem to help. A colleague with a corresponding SDK took the
> aarch64 sysroot certificates and dropped them in x86_64 sysroot and the
> problem was fixed.
>
>
>
> Tom
>
>
>
> r60874@tx30imx-01:~/rocko/build-xwayland$ bitbake imx-gpu-sdk -c
> devshell
>
> root@tx30imx-01:~/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-lin
> ux/imx-gpu-sdk/5.0.2-r0/git#
> python3
>
> Python 3.5.3 (default, Mar 6 2018, 14:15:44)
>
> [GCC 5.4.0 20160609] on linux
>
> Type "help", "copyright", "credits" or "license" for more information.
>
>>>> import urllib.request
>
>>>>
>>>> urllib.request.urlretrieve("https://emea01.safelinks.protection.out
>>>> look.com/?url=https%3A%2F%2Fsourceforge.net%2Fprojects%2Ftclap%2Ffi
>>>> les%2Ftclap-1.2.2.tar.gz=02%7C01%7Ctom.hochstein%40nxp.com%7C7
>>>> 096802f05364674162908d5a5e161a0%7C686ea1d3bc2b4c6fa92cd99c5c301635%
>>>> 7C0%7C0%7C636597309792188874=sM3F9XsfnAyJALQv3zOjm4fOiLiV6DuY
>>>> jCg%2FOoD9GHM%3D=0",
>>>> "~")
>
> Traceback (most recent call last):
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/req
> uest.py",
> line 1254, in do_open
>
> h.request(req.get_method(), req.selector, req.data, headers)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 1107, in request
>
> self._send_request(method, url, body, headers)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 1152, in _send_request
>
> self.endheaders(body)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 1103, in endheaders
>
> self._send_output(message_body)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 934, in _send_output
>
> self.send(msg)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 877, in send
>
> self.connect()
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 1261, in connect
>
> server_hostname=server_hostname)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
> line 385, in wrap_socket
>
> _context=self)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
> line 760, in __init__
>
> self.do_handshake()
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
> line 996, in do_handshake
>
> self._sslobj.do_handshake()
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
> line 641, in do_handshake
>
> self._sslobj.do_handshake()
>
> ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] c
[OE-core] [PATCH v2] python3: Add recommended modules to nativesdk install
The python3 installation in the SDK did not include the minimum set
of modules to be functional, particularly in the case where Python
is brought in through dependencies. Rather than requiring the user
to explicitly add the modules, it's better to pull in the modules
through RRECOMMENDS. Note that the Python 2 recipe already does
this.
Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
---
meta/recipes-devtools/python/python3_3.5.5.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/python/python3_3.5.5.bb
b/meta/recipes-devtools/python/python3_3.5.5.bb
index d458d32..f893b84 100644
--- a/meta/recipes-devtools/python/python3_3.5.5.bb
+++ b/meta/recipes-devtools/python/python3_3.5.5.bb
@@ -211,6 +211,7 @@ py_package_preprocess () {
# manual dependency additions
RPROVIDES_${PN}-modules = "${PN}"
+RRECOMMENDS_${PN}-core_append_class-nativesdk = " nativesdk-python3-modules"
RRECOMMENDS_${PN}-crypt = "openssl"
RRECOMMENDS_${PN}-crypt_class-nativesdk = "nativesdk-openssl"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] python3: Add recommended modules to nativesdk install
A colleague pointed out that what we installed in the SDK for python 3 was not
functional, and that a minimal set of modules was required. I'm not an expert,
but I found a similar line in the python 2 recipe and thought it might be what
was needed here.
Tom
-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: Thursday, April 5, 2018 8:56 AM
To: Tom Hochstein <tom.hochst...@nxp.com>;
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] python3: Add recommended modules to nativesdk
install
On Wed, 2018-04-04 at 14:25 -0500, Tom Hochstein wrote:
> The python3 installation in the SDK did not include the minimum set of
> modules.
>
> Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
> ---
> meta/recipes-devtools/python/python3_3.5.5.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/python/python3_3.5.5.bb
> b/meta/recipes-devtools/python/python3_3.5.5.bb
> index d458d32..f893b84 100644
> --- a/meta/recipes-devtools/python/python3_3.5.5.bb
> +++ b/meta/recipes-devtools/python/python3_3.5.5.bb
> @@ -211,6 +211,7 @@ py_package_preprocess () {
>
> # manual dependency additions
> RPROVIDES_${PN}-modules = "${PN}"
> +RRECOMMENDS_${PN}-core_append_class-nativesdk = " nativesdk-python3-
> modules"
> RRECOMMENDS_${PN}-crypt = "openssl"
> RRECOMMENDS_${PN}-crypt_class-nativesdk = "nativesdk-openssl"
This doesn't look correct, if you want the SDK to contain all python modules,
surely you'd just add nativesdk-python3-modules rather than forcing this
everywhere?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] python3-native certificate failure
But I am not using an SDK, I'm doing a straight bitbake. Using the native
Python3 urllib.request.urlopen (via inherit python3native) from do_compile I
see the certificate error. My original email duplicated the issue manually
using -c devshell.
Tom
-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Wednesday, April 4, 2018 7:29 PM
To: Tom Hochstein <tom.hochst...@nxp.com>;
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] python3-native certificate failure
On 4/4/18 1:09 PM, Tom Hochstein wrote:
> I am trying to download a URL from a source package using
> python3-native, but it is failing with a certificate failure. I added
> DEPENDS on ca-certificates-native and python3-certifi-native, but it
> doesn't seem to help. A colleague with a corresponding SDK took the
> aarch64 sysroot certificates and dropped them in x86_64 sysroot and
> the problem was fixed.
>
>
you might try adding nativesdk-ca-certificates to TOOLCHAIN_HOST_TASK and
regenerate SDK
>
> Tom
>
>
>
> r60874@tx30imx-01:~/rocko/build-xwayland$ bitbake imx-gpu-sdk -c
> devshell
>
> root@tx30imx-01:~/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-lin
> ux/imx-gpu-sdk/5.0.2-r0/git#
> python3
>
> Python 3.5.3 (default, Mar 6 2018, 14:15:44)
>
> [GCC 5.4.0 20160609] on linux
>
> Type "help", "copyright", "credits" or "license" for more information.
>
>>>> import urllib.request
>
>>>>
> urllib.request.urlretrieve("https://emea01.safelinks.protection.outloo
> k.com/?url=https%3A%2F%2Fsourceforge.net%2Fprojects%2Ftclap%2Ffiles%2F
> tclap-1.2.2.tar.gz=02%7C01%7Ctom.hochstein%40nxp.com%7Ca40b2e05d7
> aa43d50fc108d59a8c3bf6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
> 6584849450785202=2BmKu3tXThT6%2FsHG0CzQJNPvXQ3gq2GJpahu2t8PNCY%3
> D=0",
> "~")
>
> Traceback (most recent call last):
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/req
> uest.py",
> line 1254, in do_open
>
> h.request(req.get_method(), req.selector, req.data, headers)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 1107, in request
>
> self._send_request(method, url, body, headers)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 1152, in _send_request
>
> self.endheaders(body)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 1103, in endheaders
>
> self._send_output(message_body)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 934, in _send_output
>
> self.send(msg)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 877, in send
>
> self.connect()
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/clien
> t.py",
> line 1261, in connect
>
> server_hostname=server_hostname)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
> line 385, in wrap_socket
>
> _context=self)
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
> line 760, in __init__
>
> self.do_handshake()
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
> line 996, in do_handshake
>
> self._sslobj.do_handshake()
>
> File
> "/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/i
> mx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
> line 641, in do_handshake
>
> self._sslobj.do_handshake()
>
> ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify
> failed
>
[OE-core] python3-native certificate failure
I am trying to download a URL from a source package using python3-native, but
it is failing with a certificate failure. I added DEPENDS on
ca-certificates-native and python3-certifi-native, but it doesn't seem to help.
A colleague with a corresponding SDK took the aarch64 sysroot certificates and
dropped them in x86_64 sysroot and the problem was fixed.
Tom
r60874@tx30imx-01:~/rocko/build-xwayland$ bitbake imx-gpu-sdk -c devshell
root@tx30imx-01:~/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/git#
python3
Python 3.5.3 (default, Mar 6 2018, 14:15:44)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.request
>>> urllib.request.urlretrieve("https://sourceforge.net/projects/tclap/files/tclap-1.2.2.tar.gz;,
>>> "~")
Traceback (most recent call last):
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/request.py",
line 1254, in do_open
h.request(req.get_method(), req.selector, req.data, headers)
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/client.py",
line 1107, in request
self._send_request(method, url, body, headers)
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/client.py",
line 1152, in _send_request
self.endheaders(body)
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/client.py",
line 1103, in endheaders
self._send_output(message_body)
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/client.py",
line 934, in _send_output
self.send(msg)
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/client.py",
line 877, in send
self.connect()
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/http/client.py",
line 1261, in connect
server_hostname=server_hostname)
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
line 385, in wrap_socket
_context=self)
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
line 760, in __init__
self.do_handshake()
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
line 996, in do_handshake
self._sslobj.do_handshake()
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/ssl.py",
line 641, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
(_ssl.c:720)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/request.py",
line 188, in urlretrieve
with contextlib.closing(urlopen(url, data)) as fp:
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/request.py",
line 163, in urlopen
return opener.open(url, data, timeout)
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/request.py",
line 466, in open
response = self._open(req, data)
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/request.py",
line 484, in _open
'_open', req)
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/request.py",
line 444, in _call_chain
result = func(*args)
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/request.py",
line 1297, in https_open
context=self._context, check_hostname=self._check_hostname)
File
"/home/r60874/rocko/build-xwayland/tmp/work/aarch64-mx8qm-poky-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot-native/usr/lib/python3.5/urllib/request.py",
line 1256, in do_open
raise URLError(err)
urllib.error.URLError:
--
___
[OE-core] [PATCH] python3: Add recommended modules to nativesdk install
The python3 installation in the SDK did not include the minimum set
of modules.
Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
---
meta/recipes-devtools/python/python3_3.5.5.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/python/python3_3.5.5.bb
b/meta/recipes-devtools/python/python3_3.5.5.bb
index d458d32..f893b84 100644
--- a/meta/recipes-devtools/python/python3_3.5.5.bb
+++ b/meta/recipes-devtools/python/python3_3.5.5.bb
@@ -211,6 +211,7 @@ py_package_preprocess () {
# manual dependency additions
RPROVIDES_${PN}-modules = "${PN}"
+RRECOMMENDS_${PN}-core_append_class-nativesdk = " nativesdk-python3-modules"
RRECOMMENDS_${PN}-crypt = "openssl"
RRECOMMENDS_${PN}-crypt_class-nativesdk = "nativesdk-openssl"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] archiver: Fix archive for linked kernel source
When archiving a kernel, if S is ${WORKDIR}/git, then
${WORKDIR}/git is in fact a soft link into work-shared,
and the archive contains just the soft link. Fix by
archiving the real directory.
Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
---
meta/classes/archiver.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index c107615..31c9b7e 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -277,6 +277,11 @@ def create_tarball(d, srcdir, suffix, ar_outdir):
if (d.getVar('SRC_URI') == ""):
return
+# For the kernel archive, srcdir may just be a link to the
+# work-shared location. Use os.path.realpath to make sure
+# that we archive the actual directory and not just the link.
+srcdir = os.path.realpath(srcdir)
+
bb.utils.mkdirhier(ar_outdir)
if suffix:
filename = '%s-%s.tar.gz' % (d.getVar('PF'), suffix)
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] archiver: Fix build errors for kernels that don't use kernel-yocto.bbclass
Special handling for kernel source in work-shared was
incorrectly limited to kernel-yocto.bbclass instead
of kernel.bbclass.
Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
---
meta/classes/archiver.bbclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index e17e6b4..c107615 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -319,6 +319,10 @@ def create_diff_gz(d, src_orig, src, ar_outdir):
finally:
os.chdir(cwd)
+def is_work_shared(d):
+pn = d.getVar('PN')
+return bb.data.inherits_class('kernel', d) or pn.startswith('gcc-source')
+
# Run do_unpack and do_patch
python do_unpack_and_patch() {
if d.getVarFlag('ARCHIVER_MODE', 'src') not in \
@@ -331,7 +335,7 @@ python do_unpack_and_patch() {
pn = d.getVar('PN')
# The kernel class functions require it to be on work-shared, so we dont
change WORKDIR
-if not (bb.data.inherits_class('kernel-yocto', d) or
pn.startswith('gcc-source')):
+if not is_work_shared(d):
# Change the WORKDIR to make do_unpack do_patch run in another dir.
d.setVar('WORKDIR', ar_workdir)
# Restore the original path to recipe's native sysroot (it's relative
to WORKDIR).
@@ -351,7 +355,7 @@ python do_unpack_and_patch() {
oe.path.copytree(src, src_orig)
# Make sure gcc and kernel sources are patched only once
-if not (d.getVar('SRC_URI') == "" or
(bb.data.inherits_class('kernel-yocto', d) or pn.startswith('gcc-source'))):
+if not (d.getVar('SRC_URI') == "" or is_work_shared(d)):
bb.build.exec_func('do_patch', d)
# Create the patches
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] libepoxy: Fix build break for EGL_CAST dependency
This is a backport [1] to fix the following build error:
| In file included from
/home/r60874/upstream/xwayland/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/gtk+3/3.22.17-r0/recipe-sysroot/usr/include/epoxy/egl.h:46:0,
| from
../../../gtk+-3.22.17/gdk/wayland/gdkglcontext-wayland.h:32,
| from
../../../gtk+-3.22.17/gdk/wayland/gdkglcontext-wayland.c:24:
| ../../../gtk+-3.22.17/gdk/wayland/gdkglcontext-wayland.c: In function
'gdk_wayland_gl_context_realize':
| ../../../gtk+-3.22.17/gdk/wayland/gdkglcontext-wayland.c:179:43: error:
expected expression before 'EGLContext'
| : EGL_NO_CONTEXT,
|^
[1]
https://github.com/anholt/libepoxy/commit/ebe3a53db1c0bb34e1ca963b95d1f222115f93f8
Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
---
.../Add-fallback-definition-for-EGL-CAST.patch | 33 ++
meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb | 3 +-
2 files changed, 35 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-graphics/libepoxy/libepoxy/Add-fallback-definition-for-EGL-CAST.patch
diff --git
a/meta/recipes-graphics/libepoxy/libepoxy/Add-fallback-definition-for-EGL-CAST.patch
b/meta/recipes-graphics/libepoxy/libepoxy/Add-fallback-definition-for-EGL-CAST.patch
new file mode 100644
index 000..b929725
--- /dev/null
+++
b/meta/recipes-graphics/libepoxy/libepoxy/Add-fallback-definition-for-EGL-CAST.patch
@@ -0,0 +1,33 @@
+Add fallback definition for EGL_CAST
+
+The EGL API update from d11104f introduced a dependency on the
+EGL_CAST() macro, provided by an updated eglplatform.h. Given that we
+don't provide eglplatform.h, add a fallback definition for if we're
+building against Mesa 17.0.x or similar.
+
+https://bugs.gentoo.org/show_bug.cgi?id=623926
+
+Upstream-Status: Backport
[https://github.com/anholt/libepoxy/commit/ebe3a53db1c0bb34e1ca963b95d1f222115f93f8]
+
+Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
+
+Index: libepoxy-1.4.3/src/gen_dispatch.py
+===
+--- libepoxy-1.4.3.orig/src/gen_dispatch.py2017-06-06 04:24:13.0
-0500
libepoxy-1.4.3/src/gen_dispatch.py 2017-11-06 12:45:43.594966473 -0600
+@@ -491,6 +491,15 @@
+ self.outln('#include "epoxy/gl.h"')
+ if self.target == "egl":
+ self.outln('#include "EGL/eglplatform.h"')
++# Account for older eglplatform.h, which doesn't define
++# the EGL_CAST macro.
++self.outln('#ifndef EGL_CAST')
++self.outln('#if defined(__cplusplus)')
++self.outln('#define EGL_CAST(type, value)
(static_cast(value))')
++self.outln('#else')
++self.outln('#define EGL_CAST(type, value) ((type) (value))')
++self.outln('#endif')
++self.outln('#endif')
+ else:
+ # Add some ridiculous inttypes.h redefinitions that are
+ # from khrplatform.h and not included in the XML. We
diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
index c8b398f..0172322 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
@@ -5,7 +5,8 @@ SECTION = "libs"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=58ef4c80d401e07bd9ee8b6b58cf464b"
-SRC_URI =
"https://github.com/anholt/${BPN}/releases/download/${PV}/${BP}.tar.xz;
+SRC_URI =
"https://github.com/anholt/${BPN}/releases/download/${PV}/${BP}.tar.xz \
+ file://Add-fallback-definition-for-EGL-CAST.patch"
SRC_URI[md5sum] = "af4c3ce0fb1143bdc4e43f85695a9bed"
SRC_URI[sha256sum] =
"0b808a06c9685a62fca34b680abb8bc7fb2fda074478e329b063c1f872b826f6"
UPSTREAM_CHECK_URI = "https://github.com/anholt/libepoxy/releases;
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libepoxy: Fix build break for EGL_CAST dependency
This is a backport [1] to fix the following build error:
| In file included from
/home/r60874/upstream/xwayland/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/gtk+3/3.22.17-r0/recipe-sysroot/usr/include/epoxy/egl.h:46:0,
| from
../../../gtk+-3.22.17/gdk/wayland/gdkglcontext-wayland.h:32,
| from
../../../gtk+-3.22.17/gdk/wayland/gdkglcontext-wayland.c:24:
| ../../../gtk+-3.22.17/gdk/wayland/gdkglcontext-wayland.c: In function
'gdk_wayland_gl_context_realize':
| ../../../gtk+-3.22.17/gdk/wayland/gdkglcontext-wayland.c:179:43: error:
expected expression before 'EGLContext'
| : EGL_NO_CONTEXT,
|^
[1]
https://github.com/anholt/libepoxy/commit/ebe3a53db1c0bb34e1ca963b95d1f222115f93f8
Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
---
.../Add-fallback-definition-for-EGL-CAST.patch | 31 ++
meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb | 3 ++-
2 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-graphics/libepoxy/libepoxy/Add-fallback-definition-for-EGL-CAST.patch
diff --git
a/meta/recipes-graphics/libepoxy/libepoxy/Add-fallback-definition-for-EGL-CAST.patch
b/meta/recipes-graphics/libepoxy/libepoxy/Add-fallback-definition-for-EGL-CAST.patch
new file mode 100644
index 000..daa1785
--- /dev/null
+++
b/meta/recipes-graphics/libepoxy/libepoxy/Add-fallback-definition-for-EGL-CAST.patch
@@ -0,0 +1,31 @@
+Add fallback definition for EGL_CAST
+
+The EGL API update from d11104f introduced a dependency on the
+EGL_CAST() macro, provided by an updated eglplatform.h. Given that we
+don't provide eglplatform.h, add a fallback definition for if we're
+building against Mesa 17.0.x or similar.
+
+https://bugs.gentoo.org/show_bug.cgi?id=623926
+
+Upstream-Status: Backport
[https://github.com/anholt/libepoxy/commit/ebe3a53db1c0bb34e1ca963b95d1f222115f93f8]
+
+Index: libepoxy-1.4.3/src/gen_dispatch.py
+===
+--- libepoxy-1.4.3.orig/src/gen_dispatch.py2017-06-06 04:24:13.0
-0500
libepoxy-1.4.3/src/gen_dispatch.py 2017-11-06 12:45:43.594966473 -0600
+@@ -491,6 +491,15 @@
+ self.outln('#include "epoxy/gl.h"')
+ if self.target == "egl":
+ self.outln('#include "EGL/eglplatform.h"')
++# Account for older eglplatform.h, which doesn't define
++# the EGL_CAST macro.
++self.outln('#ifndef EGL_CAST')
++self.outln('#if defined(__cplusplus)')
++self.outln('#define EGL_CAST(type, value)
(static_cast(value))')
++self.outln('#else')
++self.outln('#define EGL_CAST(type, value) ((type) (value))')
++self.outln('#endif')
++self.outln('#endif')
+ else:
+ # Add some ridiculous inttypes.h redefinitions that are
+ # from khrplatform.h and not included in the XML. We
diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
index c8b398f..0172322 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
@@ -5,7 +5,8 @@ SECTION = "libs"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=58ef4c80d401e07bd9ee8b6b58cf464b"
-SRC_URI =
"https://github.com/anholt/${BPN}/releases/download/${PV}/${BP}.tar.xz;
+SRC_URI =
"https://github.com/anholt/${BPN}/releases/download/${PV}/${BP}.tar.xz \
+ file://Add-fallback-definition-for-EGL-CAST.patch"
SRC_URI[md5sum] = "af4c3ce0fb1143bdc4e43f85695a9bed"
SRC_URI[sha256sum] =
"0b808a06c9685a62fca34b680abb8bc7fb2fda074478e329b063c1f872b826f6"
UPSTREAM_CHECK_URI = "https://github.com/anholt/libepoxy/releases;
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] xserver-xorg: Fix X server 1.19 crash
Commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99 removes the configure of
useSIGIO option:
xfree86 SIGIO support is reworked to use internal versions of
OsBlockSIGIO and OsReleaseSIGIO
The check for useSIGIO is no longer needed.
Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
---
.../0003-Remove-check-for-useSIGIO-option.patch| 47 ++
.../xorg-xserver/xserver-xorg_1.19.1.bb| 1 +
2 files changed, 48 insertions(+)
create mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-Remove-check-for-useSIGIO-option.patch
diff --git
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-Remove-check-for-useSIGIO-option.patch
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-Remove-check-for-useSIGIO-option.patch
new file mode 100644
index 000..beed6cb
--- /dev/null
+++
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-Remove-check-for-useSIGIO-option.patch
@@ -0,0 +1,47 @@
+From cf407b16cd65ad6e26a9c8e5984e163409a5c0f7 Mon Sep 17 00:00:00 2001
+From: Prabhu Sundararaj <prabhu.sundara...@nxp.com>
+Date: Mon, 30 Jan 2017 16:32:06 -0600
+Subject: [PATCH] Remove check for useSIGIO option
+
+Commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99 removes the configure of
useSIGIO
+option.
+
+As the xfree86 SIGIO support is reworked to use internal versions of
OsBlockSIGIO
+and OsReleaseSIGIO.
+
+No longer the check for useSIGIO is needed
+
+Upstream-Status: Pending
+
+Signed-off-by: Prabhu Sundararaj <prabhu.sundara...@nxp.com>
+---
+ hw/xfree86/os-support/shared/sigio.c | 6 --
+ 1 file changed, 6 deletions(-)
+
+diff --git a/hw/xfree86/os-support/shared/sigio.c
b/hw/xfree86/os-support/shared/sigio.c
+index 884a71c..be76498 100644
+--- a/hw/xfree86/os-support/shared/sigio.c
b/hw/xfree86/os-support/shared/sigio.c
+@@ -185,9 +185,6 @@ xf86InstallSIGIOHandler(int fd, void (*f) (int, void *),
void *closure)
+ int i;
+ int installed = FALSE;
+
+-if (!xf86Info.useSIGIO)
+-return 0;
+-
+ for (i = 0; i < MAX_FUNCS; i++) {
+ if (!xf86SigIOFuncs[i].f) {
+ if (xf86IsPipe(fd))
+@@ -256,9 +253,6 @@ xf86RemoveSIGIOHandler(int fd)
+ int max;
+ int ret;
+
+-if (!xf86Info.useSIGIO)
+-return 0;
+-
+ max = 0;
+ ret = 0;
+ for (i = 0; i < MAX_FUNCS; i++) {
+--
+2.7.4
+
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.1.bb
b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.1.bb
index 987a2be..5a657e0 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.1.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.1.bb
@@ -3,6 +3,7 @@ require xserver-xorg.inc
SRC_URI += "file://musl-arm-inb-outb.patch \
file://0001-configure.ac-Fix-check-for-CLOCK_MONOTONIC.patch \
file://0002-configure.ac-Fix-wayland-scanner-and-protocols-locat.patch \
+file://0003-Remove-check-for-useSIGIO-option.patch \
"
SRC_URI[md5sum] = "caa8ee7b2950abbf734347d137529fb6"
SRC_URI[sha256sum] =
"79ae2cf39d3f6c4a91201d8dad549d1d774b3420073c5a70d390040aa965a7fb"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] xserver-xorg: Fix X server 1.19 crash
https://lists.yoctoproject.org/pipermail/meta-freescale/2017-January/019980.html From: Jussi Kukkonen [mailto:jussi.kukko...@intel.com] Sent: Wednesday, February 01, 2017 5:38 AM To: Tom Hochstein <tom.hochst...@nxp.com> Cc: Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org> Subject: Re: [OE-core] [PATCH v2] xserver-xorg: Fix X server 1.19 crash On 1 February 2017 at 03:22, Tom Hochstein <tom.hochst...@nxp.com<mailto:tom.hochst...@nxp.com>> wrote: Commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99 removes the configure of useSIGIO option: xfree86 SIGIO support is reworked to use internal versions of OsBlockSIGIO and OsReleaseSIGIO The check for useSIGIO is no longer needed. Can you explain what the crash is or how to reproduce, I can't figure it out from the patch. Link to possible upstream ML discussion is fine as well. Thanks, Jussi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] xserver-xorg: Fix X server 1.19 crash
Commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99 removes the configure of
useSIGIO option:
xfree86 SIGIO support is reworked to use internal versions of
OsBlockSIGIO and OsReleaseSIGIO
The check for useSIGIO is no longer needed.
Upstream-Status: Pending
Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
---
.../0003-Remove-check-for-useSIGIO-option.patch| 47 ++
.../xorg-xserver/xserver-xorg_1.19.1.bb| 1 +
2 files changed, 48 insertions(+)
create mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-Remove-check-for-useSIGIO-option.patch
diff --git
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-Remove-check-for-useSIGIO-option.patch
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-Remove-check-for-useSIGIO-option.patch
new file mode 100644
index 000..beed6cb
--- /dev/null
+++
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-Remove-check-for-useSIGIO-option.patch
@@ -0,0 +1,47 @@
+From cf407b16cd65ad6e26a9c8e5984e163409a5c0f7 Mon Sep 17 00:00:00 2001
+From: Prabhu Sundararaj <prabhu.sundara...@nxp.com>
+Date: Mon, 30 Jan 2017 16:32:06 -0600
+Subject: [PATCH] Remove check for useSIGIO option
+
+Commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99 removes the configure of
useSIGIO
+option.
+
+As the xfree86 SIGIO support is reworked to use internal versions of
OsBlockSIGIO
+and OsReleaseSIGIO.
+
+No longer the check for useSIGIO is needed
+
+Upstream-Status: Pending
+
+Signed-off-by: Prabhu Sundararaj <prabhu.sundara...@nxp.com>
+---
+ hw/xfree86/os-support/shared/sigio.c | 6 --
+ 1 file changed, 6 deletions(-)
+
+diff --git a/hw/xfree86/os-support/shared/sigio.c
b/hw/xfree86/os-support/shared/sigio.c
+index 884a71c..be76498 100644
+--- a/hw/xfree86/os-support/shared/sigio.c
b/hw/xfree86/os-support/shared/sigio.c
+@@ -185,9 +185,6 @@ xf86InstallSIGIOHandler(int fd, void (*f) (int, void *),
void *closure)
+ int i;
+ int installed = FALSE;
+
+-if (!xf86Info.useSIGIO)
+-return 0;
+-
+ for (i = 0; i < MAX_FUNCS; i++) {
+ if (!xf86SigIOFuncs[i].f) {
+ if (xf86IsPipe(fd))
+@@ -256,9 +253,6 @@ xf86RemoveSIGIOHandler(int fd)
+ int max;
+ int ret;
+
+-if (!xf86Info.useSIGIO)
+-return 0;
+-
+ max = 0;
+ ret = 0;
+ for (i = 0; i < MAX_FUNCS; i++) {
+--
+2.7.4
+
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.1.bb
b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.1.bb
index 987a2be..5a657e0 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.1.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.1.bb
@@ -3,6 +3,7 @@ require xserver-xorg.inc
SRC_URI += "file://musl-arm-inb-outb.patch \
file://0001-configure.ac-Fix-check-for-CLOCK_MONOTONIC.patch \
file://0002-configure.ac-Fix-wayland-scanner-and-protocols-locat.patch \
+file://0003-Remove-check-for-useSIGIO-option.patch \
"
SRC_URI[md5sum] = "caa8ee7b2950abbf734347d137529fb6"
SRC_URI[sha256sum] =
"79ae2cf39d3f6c4a91201d8dad549d1d774b3420073c5a70d390040aa965a7fb"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] xserver-xorg: Fix X server 1.19 crash
Commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99 removes the configure of
useSIGIO option:
xfree86 SIGIO support is reworked to use internal versions of
OsBlockSIGIO and OsReleaseSIGIO
The check for useSIGIO is no longer needed.
Upstream-Status: Pending
Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
---
.../0003-Remove-check-for-useSIGIO-option.patch| 45 ++
.../xorg-xserver/xserver-xorg_1.19.1.bb| 1 +
2 files changed, 46 insertions(+)
create mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-Remove-check-for-useSIGIO-option.patch
diff --git
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-Remove-check-for-useSIGIO-option.patch
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-Remove-check-for-useSIGIO-option.patch
new file mode 100644
index 000..db2d845
--- /dev/null
+++
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-Remove-check-for-useSIGIO-option.patch
@@ -0,0 +1,45 @@
+From cf407b16cd65ad6e26a9c8e5984e163409a5c0f7 Mon Sep 17 00:00:00 2001
+From: Prabhu Sundararaj <prabhu.sundara...@nxp.com>
+Date: Mon, 30 Jan 2017 16:32:06 -0600
+Subject: [PATCH] Remove check for useSIGIO option
+
+Commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99 removes the configure of
useSIGIO
+option.
+
+As the xfree86 SIGIO support is reworked to use internal versions of
OsBlockSIGIO
+and OsReleaseSIGIO.
+
+No longer the check for useSIGIO is needed
+
+Signed-off-by: Prabhu Sundararaj <prabhu.sundara...@nxp.com>
+---
+ hw/xfree86/os-support/shared/sigio.c | 6 --
+ 1 file changed, 6 deletions(-)
+
+diff --git a/hw/xfree86/os-support/shared/sigio.c
b/hw/xfree86/os-support/shared/sigio.c
+index 884a71c..be76498 100644
+--- a/hw/xfree86/os-support/shared/sigio.c
b/hw/xfree86/os-support/shared/sigio.c
+@@ -185,9 +185,6 @@ xf86InstallSIGIOHandler(int fd, void (*f) (int, void *),
void *closure)
+ int i;
+ int installed = FALSE;
+
+-if (!xf86Info.useSIGIO)
+-return 0;
+-
+ for (i = 0; i < MAX_FUNCS; i++) {
+ if (!xf86SigIOFuncs[i].f) {
+ if (xf86IsPipe(fd))
+@@ -256,9 +253,6 @@ xf86RemoveSIGIOHandler(int fd)
+ int max;
+ int ret;
+
+-if (!xf86Info.useSIGIO)
+-return 0;
+-
+ max = 0;
+ ret = 0;
+ for (i = 0; i < MAX_FUNCS; i++) {
+--
+2.7.4
+
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.1.bb
b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.1.bb
index 987a2be..5a657e0 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.1.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.1.bb
@@ -3,6 +3,7 @@ require xserver-xorg.inc
SRC_URI += "file://musl-arm-inb-outb.patch \
file://0001-configure.ac-Fix-check-for-CLOCK_MONOTONIC.patch \
file://0002-configure.ac-Fix-wayland-scanner-and-protocols-locat.patch \
+file://0003-Remove-check-for-useSIGIO-option.patch \
"
SRC_URI[md5sum] = "caa8ee7b2950abbf734347d137529fb6"
SRC_URI[sha256sum] =
"79ae2cf39d3f6c4a91201d8dad549d1d774b3420073c5a70d390040aa965a7fb"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] weston startup problem
Hi Jussi, Thanks for the help. Here are the relevant steps of the problem: 1. weston.service sets XDG_RUNTIME_DIR, then starts Weston 2. Weston starts up and registers its Wayland server socket in XDG_RUNTIME_DIR 3. pam starts and sets XDG_RUNTIME_DIR to another location 4. Wayland client fails to find the Wayland server socket. At this point, I realize I’m not exactly sure what will happen. Looking at the Weston man page, it appears possible that the Wayland client will still be able to connect through the default Wayland server socket. I can’t immediately test this to know for sure, but regardless, there is still an issue except for the default case. Tom From: Jussi Kukkonen [mailto:jussi.kukko...@intel.com] Sent: Friday, September 09, 2016 1:41 AM To: Tom Hochstein <tom.hochst...@nxp.com> Cc: Patches and discussions about the oe-core layer (openembedded-core@lists.openembedded.org) <openembedded-core@lists.openembedded.org> Subject: Re: [OE-core] weston startup problem On 24 August 2016 at 20:08, Tom Hochstein <tom.hochst...@nxp.com<mailto:tom.hochst...@nxp.com>> wrote: Hi All, Hi, sorry for missing this in the originally, The weston systemd startup implementation is not working correctly and I need some help fixing it. With systemd and pam on the image, the expected behavior is that XDG_RUNTIME_DIR would already be set when weston is launched from weston.service. Turns out XDG_RUNTIME_DIR is not set, and weston.service sets it itself. This is already a problem, and the problem would be worse except that weston happens to use a different folder. If weston.service is modified to use the same folder name, the folder ends up getting replaced later by pam. I can see our XDG_RUNTIME_DIR handling indeed should be cleaned up but just so I understand the whole issue: can you explain the problem you have in detail? It seems one issue is that the variable isn't set outside of Xsession (it really should) but why is it a problem if weston.service decides a runtime directory for itself? How does pam interfere with that? Thanks, Jussi From looking at the weston-launch code and its pam handling, I thought to try the weston-launch option '--user=root' to force the creation of the pam session. This does seem to help, and I was able to get it mostly working by modifying the openvt args in weston-start, removing -e and adding -w: openvt -v -s -w -- weston-launch --user=root -- --modules=xwayland.so --log=/var/log/weston.log The problem I have now is that keyboard input goes to both weston and the desktop. I tried with and without the -s option, and there is no difference. I'm stuck at this point and would appreciate some help. Tom -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] weston startup problem
Ping. -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Tom Hochstein Sent: Wednesday, August 24, 2016 12:08 PM To: Patches and discussions about the oe-core layer (openembedded-core@lists.openembedded.org) <openembedded-core@lists.openembedded.org> Subject: [OE-core] weston startup problem Hi All, The weston systemd startup implementation is not working correctly and I need some help fixing it. With systemd and pam on the image, the expected behavior is that XDG_RUNTIME_DIR would already be set when weston is launched from weston.service. Turns out XDG_RUNTIME_DIR is not set, and weston.service sets it itself. This is already a problem, and the problem would be worse except that weston happens to use a different folder. If weston.service is modified to use the same folder name, the folder ends up getting replaced later by pam. >From looking at the weston-launch code and its pam handling, I thought to try >the weston-launch option '--user=root' to force the creation of the pam >session. This does seem to help, and I was able to get it mostly working by >modifying the openvt args in weston-start, removing -e and adding -w: openvt -v -s -w -- weston-launch --user=root -- --modules=xwayland.so --log=/var/log/weston.log The problem I have now is that keyboard input goes to both weston and the desktop. I tried with and without the -s option, and there is no difference. I'm stuck at this point and would appreciate some help. Tom -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] weston startup problem
Hi All, The weston systemd startup implementation is not working correctly and I need some help fixing it. With systemd and pam on the image, the expected behavior is that XDG_RUNTIME_DIR would already be set when weston is launched from weston.service. Turns out XDG_RUNTIME_DIR is not set, and weston.service sets it itself. This is already a problem, and the problem would be worse except that weston happens to use a different folder. If weston.service is modified to use the same folder name, the folder ends up getting replaced later by pam. >From looking at the weston-launch code and its pam handling, I thought to try >the weston-launch option '--user=root' to force the creation of the pam >session. This does seem to help, and I was able to get it mostly working by >modifying the openvt args in weston-start, removing -e and adding -w: openvt -v -s -w -- weston-launch --user=root -- --modules=xwayland.so --log=/var/log/weston.log The problem I have now is that keyboard input goes to both weston and the desktop. I tried with and without the -s option, and there is no difference. I'm stuck at this point and would appreciate some help. Tom <>-- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [krogoth][PATCH] mesa-demos: Fix OpenGL ES configurability
No, master does not need this fix. The problematic patch 0011-drop-demos-dependant-on-obsolete-MESA_screen_surface.patch does not exist on master because the underlying issue was addressed upstream (without introducing this bug). Tom From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Tuesday, August 09, 2016 5:10 AM To: Tom Hochstein <tom.hochst...@nxp.com> Cc: OE-core <openembedded-core@lists.openembedded.org> Subject: Re: [OE-core] [krogoth][PATCH] mesa-demos: Fix OpenGL ES configurability On 8 August 2016 at 16:45, Tom Hochstein <tom.hochst...@nxp.com<mailto:tom.hochst...@nxp.com>> wrote: The most recent patch 0011-drop-demos-dependant-on-obsolete-MESA_screen_surface.patch incorrectly removed the configuration constructs that allowed the package to be configured without OpenGL ES support. Does this also need to be applied to master? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [krogoth][PATCH] mesa-demos: Fix OpenGL ES configurability
The most recent patch
0011-drop-demos-dependant-on-obsolete-MESA_screen_surface.patch
incorrectly removed the configuration constructs that allowed the
package to be configured without OpenGL ES support.
Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
---
.../mesa-demos/0012-Fix-gles-configurability.patch | 39 ++
meta/recipes-graphics/mesa/mesa-demos_8.2.0.bb | 1 +
2 files changed, 40 insertions(+)
create mode 100644
meta/recipes-graphics/mesa/mesa-demos/0012-Fix-gles-configurability.patch
diff --git
a/meta/recipes-graphics/mesa/mesa-demos/0012-Fix-gles-configurability.patch
b/meta/recipes-graphics/mesa/mesa-demos/0012-Fix-gles-configurability.patch
new file mode 100644
index 000..0b437a4
--- /dev/null
+++ b/meta/recipes-graphics/mesa/mesa-demos/0012-Fix-gles-configurability.patch
@@ -0,0 +1,39 @@
+Index: mesa-demos-8.2.0/src/egl/opengles1/Makefile.am
+===
+--- mesa-demos-8.2.0.orig/src/egl/opengles1/Makefile.am2016-07-29
10:52:50.131729547 -0500
mesa-demos-8.2.0/src/egl/opengles1/Makefile.am 2016-07-29
10:59:26.0 -0500
+@@ -36,6 +36,8 @@
+ $(EGL_LIBS) \
+ -lm
+
++if HAVE_EGL
++if HAVE_GLESV1
+ bin_PROGRAMS =
+
+ if HAVE_X11
+@@ -76,3 +78,5 @@
+ torus_x11_LDADD = ../eglut/libeglut_x11.la
+ tri_x11_LDADD = ../eglut/libeglut_x11.la
+ endif
++endif
++endif
+Index: mesa-demos-8.2.0/src/egl/opengles2/Makefile.am
+===
+--- mesa-demos-8.2.0.orig/src/egl/opengles2/Makefile.am2016-07-29
10:52:50.131729547 -0500
mesa-demos-8.2.0/src/egl/opengles2/Makefile.am 2016-07-29
10:59:03.0 -0500
+@@ -33,6 +33,8 @@
+ $(EGL_LIBS) \
+ -lm
+
++if HAVE_EGL
++if HAVE_GLESV2
+ bin_PROGRAMS =
+
+ if HAVE_WAYLAND
+@@ -53,4 +55,5 @@
+ es2gears_x11_LDADD = ../eglut/libeglut_x11.la
+ es2tri_LDADD = $(X11_LIBS)
+ endif
+-
++endif
++endif
diff --git a/meta/recipes-graphics/mesa/mesa-demos_8.2.0.bb
b/meta/recipes-graphics/mesa/mesa-demos_8.2.0.bb
index 2df9bba..8e12d82 100644
--- a/meta/recipes-graphics/mesa/mesa-demos_8.2.0.bb
+++ b/meta/recipes-graphics/mesa/mesa-demos_8.2.0.bb
@@ -21,6 +21,7 @@ SRC_URI =
"ftp://ftp.freedesktop.org/pub/mesa/demos/${PV}/${BPN}-${PV}.tar.bz2 \
file://0009-glsl-perf-Install-.glsl-.vert-.frag-files.patch \
file://0010-sharedtex_mt-fix-rendering-thread-hang.patch \
file://0011-drop-demos-dependant-on-obsolete-MESA_screen_surface.patch \
+file://0012-Fix-gles-configurability.patch \
"
SRC_URI[md5sum] = "72613a2c8c013716db02e3ff59d29061"
SRC_URI[sha256sum] =
"e4bfecb5816ddd4b7b37c1bc876b63f1f7f06fda5879221a9774d0952f90ba92"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 3/3] weston-init: Fix weston-start to allow weston args without openvt args
Re-sent. From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Monday, July 18, 2016 11:29 AM To: Otavio Salvador <otavio.salva...@ossystems.com.br> Cc: Tom Hochstein <tom.hochst...@nxp.com>; Otavio Salvador <ota...@ossystems.com.br>; Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org> Subject: Re: [OE-core] [PATCH v3 3/3] weston-init: Fix weston-start to allow weston args without openvt args I can only see 1/3 and 3/3, but no 2/3. On 18 July 2016 at 16:13, Otavio Salvador <otavio.salva...@ossystems.com.br<mailto:otavio.salva...@ossystems.com.br>> wrote: On Mon, Jul 18, 2016 at 11:43 AM, Tom Hochstein <tom.hochst...@nxp.com<mailto:tom.hochst...@nxp.com>> wrote: > The parser didn't properly handle commands of the form > weston-start -- . > > Signed-off-by: Tom Hochstein > <tom.hochst...@nxp.com<mailto:tom.hochst...@nxp.com>> Acked-by: Otavio Salvador <ota...@ossystems.com.br<mailto:ota...@ossystems.com.br>> -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854<tel:%2B55%20%2853%29%209981-7854>Mobile: +1 (347) 903-9750<tel:%2B1%20%28347%29%20903-9750> -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org<mailto: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
[OE-core] [PATCH v3 2/3] weston-init: Fix weston-start to handle 0 or 1 args
The parser incorrectly treated anything less than 2 args as an error.
Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
---
meta/recipes-graphics/wayland/weston-init/weston-start | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start
b/meta/recipes-graphics/wayland/weston-init/weston-start
index d7358ba..cd64216 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -6,7 +6,7 @@ export PATH="/sbin:/usr/sbin:/bin:/usr/bin"
usage() {
cat < --
+$0 [] [-- ]
EOF
}
@@ -23,11 +23,6 @@ add_openvt_argument() {
openvt_args="$openvt_args $1"
}
-if test $# -lt 2; then
- usage
- exit 1
-fi
-
if [ -n "$WAYLAND_DISPLAY" ]; then
echo "ERROR: A Wayland compositor is already running, nested Weston
instance is not supported yet."
exit 1
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 2/3] weston-init: Fix weston-start to handle 0 or 1 args
The parser incorrectly treated anything less than 2 args as an error.
Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com>
---
meta/recipes-graphics/wayland/weston-init/weston-start | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start
b/meta/recipes-graphics/wayland/weston-init/weston-start
index d7358ba..cd64216 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -6,7 +6,7 @@ export PATH="/sbin:/usr/sbin:/bin:/usr/bin"
usage() {
cat < --
+$0 [] [-- ]
EOF
}
@@ -23,11 +23,6 @@ add_openvt_argument() {
openvt_args="$openvt_args $1"
}
-if test $# -lt 2; then
- usage
- exit 1
-fi
-
if [ -n "$WAYLAND_DISPLAY" ]; then
echo "ERROR: A Wayland compositor is already running, nested Weston
instance is not supported yet."
exit 1
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 1/3] weston-init: De-couple framebuffer console from Weston for systemd startup
The framebuffer console was using the same I/O as Weston. We fix this by having openvt switch to the new VT when starting weston-launch, same as is already done for the sysvinit case. Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com> --- meta/recipes-graphics/wayland/weston-init/init | 2 +- meta/recipes-graphics/wayland/weston-init/weston-start | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/meta/recipes-graphics/wayland/weston-init/init b/meta/recipes-graphics/wayland/weston-init/init index 5c925f4..d3e87c6 100644 --- a/meta/recipes-graphics/wayland/weston-init/init +++ b/meta/recipes-graphics/wayland/weston-init/init @@ -31,7 +31,7 @@ case "$1" in start) . /etc/profile -weston-start -s -- $OPTARGS +weston-start -- $OPTARGS ;; stop) diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start b/meta/recipes-graphics/wayland/weston-init/weston-start index 5b7604f..d7358ba 100755 --- a/meta/recipes-graphics/wayland/weston-init/weston-start +++ b/meta/recipes-graphics/wayland/weston-init/weston-start @@ -1,5 +1,6 @@ #!/bin/sh # Copyright (C) 2016 O.S. Systems Software LTDA. +# Copyright (C) 2016 Freescale Semiconductor export PATH="/sbin:/usr/sbin:/bin:/usr/bin" @@ -37,7 +38,7 @@ else launcher="weston-launch --" fi -openvt_args="" +openvt_args="-s" while [ -n "$1" ]; do openvt_args="$openvt_args $1" shift -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 3/3] weston-init: Fix weston-start to allow weston args without openvt args
The parser didn't properly handle commands of the form weston-start -- . Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com> --- meta/recipes-graphics/wayland/weston-init/weston-start | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start b/meta/recipes-graphics/wayland/weston-init/weston-start index cd64216..e72fbaa 100755 --- a/meta/recipes-graphics/wayland/weston-init/weston-start +++ b/meta/recipes-graphics/wayland/weston-init/weston-start @@ -35,13 +35,12 @@ fi openvt_args="-s" while [ -n "$1" ]; do - openvt_args="$openvt_args $1" - shift - if [ "$1" = "--" ]; then shift break fi + openvt_args="$openvt_args $1" + shift done weston_args=$* -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] weston-init: De-couple framebuffer console from Weston for systemd startup
Sorry again, seems that the weston-start parser is not prepared to take no openvt arguments. Will need to fix that as well. Tom -Original Message- From: Otavio Salvador [mailto:otavio.salva...@ossystems.com.br] Sent: Friday, July 15, 2016 12:01 PM To: Tom Hochstein <tom.hochst...@nxp.com> Cc: Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org> Subject: Re: [OE-core] [PATCH v2] weston-init: De-couple framebuffer console from Weston for systemd startup On Fri, Jul 15, 2016 at 1:33 PM, Tom Hochstein <tom.hochst...@nxp.com> wrote: > The framebuffer console was using the same I/O as Weston. We fix this > by having openvt switch to the new VT when starting weston-launch, same > as is already done for the sysvinit case. > > Signed-off-by: Tom Hochstein <tom.hochst...@nxp.com> Acked-by: Otavio Salvador <ota...@ossystems.com.br> -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
