wayland: Delete recipe

[kraj]

this recipe is close to what core layer has and it seems to be not needed to be forked anymore

here is diff

--- wayland_1.22.0.imx.bb       2023-09-06 20:34:55.169416916 -0700
+++ ../../../poky/meta/recipes-graphics/wayland/wayland_1.22.0.bb       2023-08-02 14:11:05.768744418 -0700
@@ -12,13 +12,11 @@

 DEPENDS = "expat libffi wayland-native"

-SRC_URI = "https://gitlab.freedesktop.org/wayland/wayland/-/releases/1.22.0/downloads/${BP_ORIGINAL}.tar.xz \ +SRC_URI = "https://gitlab.freedesktop.org/wayland/wayland/-/releases/${PV}/downloads/${BPN}-${PV}.tar.xz \
            file://run-ptest \
            file://0001-build-Fix-strndup-detection-on-MinGW.patch \
            "
 SRC_URI[sha256sum] = "1540af1ea698a471c2d8e9d288332c7e0fd360c8f1d12936ebb7e7cbc2425842"
-BP_ORIGINAL = "${BPN}-1.22.0"
-S = "${WORKDIR}/${BP_ORIGINAL}"

 UPSTREAM_CHECK_URI = "https://wayland.freedesktop.org/releases.html"
 UPSTREAM_CHECK_REGEX = "wayland-(?P<pver>\d+\.\d+\.(?!9\d+)\d+)"
@@ -61,7 +59,3 @@
 BBCLASSEXTEND = "native nativesdk"

 RDEPENDS:${PN}-ptest += "binutils sed ${PN}-tools"
-
-PACKAGE_ARCH = "${MACHINE_SOCARCH}"
-
-DEFAULT_PREFERENCE = "-1"

[quaresmajose]

The recipe is mostly to be used from meta-freescale master with oe-core kirstone but we can carry them on our distro. fyi @ricardosalveti

[ricardosalveti]

This was done as a way to keep it compatible with kirkstone as well (https://github.com/Freescale/meta-freescale/commit/60510fbb0ebf471f798fb77e880ac0a7acbdcc50), so up to @otavio as we can indeed just move to our own distro layer if needed..

[otavio]

I prefer to keep it for compatibility. We have several people using master with kirkstone. Once Scarthgap (Yocto Project 4.4) is released, we can drop it from master.

[kraj]

I prefer to keep it for compatibility. We have several people using master with kirkstone. Once Scarthgap (Yocto Project 4.4) is released, we can drop it from master.

I understand its spanning across layer releases is a certain usecase. However there is other side to it, where meta-freescale does not behave well in multi BSP distros which is quite common in end products using yocto.

[otavio]

I understand its spanning across layer releases is a certain usecase. However there is other side to it, where meta-freescale does not behave well in multi BSP distros which is quite common in end products using yocto.

Do you have an example of a failure? I have used it with multi-BSP and have not experienced any drawbacks.

[kraj]

I understand its spanning across layer releases is a certain usecase. However there is other side to it, where meta-freescale does not behave well in multi BSP distros which is quite common in end products using yocto.

Do you have an example of a failure? I have used it with multi-BSP and have not experienced any drawbacks.

this version gets picked up over the one from OE-Core always ( especially native one ) no matter what BSP is used which is fine in master right now since versions are matching but its not good.

There is one issue popping up with latest SPDX enabling where wayland-native is used on one machine from core and for an imx8 machine uses the meta-fsl version which is ok but they are using same tmpdir and conflict in signatures such that bitbake is not able to stage/unstage when they are toggled resulting in weird compilation errors in spdx task.

[quaresmajose]

I understand its spanning across layer releases is a certain usecase. However there is other side to it, where meta-freescale does not behave well in multi BSP distros which is quite common in end products using yocto.

Do you have an example of a failure? I have used it with multi-BSP and have not experienced any drawbacks.

this version gets picked up over the one from OE-Core always ( especially native one ) no matter what BSP is used which is fine in master right now since versions are matching but its not good.

To fix this we should make it compatible with IMX bsp COMPATIBLE_MACHINE = "(imx-nxp-bsp)"

There is one issue popping up with latest SPDX enabling where wayland-native is used on one machine from core and for an imx8 machine uses the meta-fsl version which is ok but they are using same tmpdir and conflict in signatures such that bitbake is not able to stage/unstage when they are toggled resulting in weird compilation errors in spdx task.

I think COMPATIBLE_MACHINE should also fix the native usage when used in other bsp that are not IMX specific.

[kraj]

I understand its spanning across layer releases is a certain usecase. However there is other side to it, where meta-freescale does not behave well in multi BSP distros which is quite common in end products using yocto.

Do you have an example of a failure? I have used it with multi-BSP and have not experienced any drawbacks.

this version gets picked up over the one from OE-Core always ( especially native one ) no matter what BSP is used which is fine in master right now since versions are matching but its not good.

To fix this we should make it compatible with IMX bsp COMPATIBLE_MACHINE = "(imx-nxp-bsp)"

There is one issue popping up with latest SPDX enabling where wayland-native is used on one machine from core and for an imx8 machine uses the meta-fsl version which is ok but they are using same tmpdir and conflict in signatures such that bitbake is not able to stage/unstage when they are toggled resulting in weird compilation errors in spdx task.

I think COMPATIBLE_MACHINE should also fix the native usage when used in other bsp that are not IMX specific.

The problem will still happen in my case where common sstate it used because when you have one imx based machine and other non-imx the dance will still go on.

[otavio]

Please rebase.