[meta-freescale] [PATCH v2 2/2] wayland-protocols: Fix PACKAGE_ARCH for i.MX-specific version

[Tom Hochstein]

Fix the PACKAGE_ARCH so that our i.MX-specific version does not
override the standard allarch version.

Signed-off-by: Tom Hochstein <***@nxp.com>
---
recipes-graphics/wayland/wayland-protocols_1.13.imx.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb b/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb
index c2ea68e..c722371 100644
--- a/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb
+++ b/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb
@@ -17,7 +17,9 @@ SRC_URI[md5sum] = "29312149dafcd4a0e739ba94995a574d"
SRC_URI[sha256sum] = "0758bc8008d5332f431b2a84fea7de64d971ce270ed208206a098ff2ebc68f38"
S = "${WORKDIR}/${ARCHIVE_NAME}"

-inherit allarch autotools pkgconfig
+inherit autotools pkgconfig

PACKAGES = "${PN}"
FILES_${PN} += "${datadir}/pkgconfig/wayland-protocols.pc"
+
+PACKAGE_ARCH = "${MACHINE_SOCARCH}"

[Andreas Müller]

Post by Tom Hochstein
Fix the PACKAGE_ARCH so that our i.MX-specific version does not
override the standard allarch version.
---
recipes-graphics/wayland/wayland-protocols_1.13.imx.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb b/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb
index c2ea68e..c722371 100644
--- a/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb
+++ b/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb
@@ -17,7 +17,9 @@ SRC_URI[md5sum] = "29312149dafcd4a0e739ba94995a574d"
SRC_URI[sha256sum] = "0758bc8008d5332f431b2a84fea7de64d971ce270ed208206a098ff2ebc68f38"
S = "${WORKDIR}/${ARCHIVE_NAME}"
-inherit allarch autotools pkgconfig
+inherit autotools pkgconfig
PACKAGES = "${PN}"
FILES_${PN} += "${datadir}/pkgconfig/wayland-protocols.pc"
+
+PACKAGE_ARCH = "${MACHINE_SOCARCH}"
--
2.7.4
--

This does not fix the problem. Tested for:

* MACHINE = "imx6qdl-variscite-som" / MACHINEOVERRIDES .= ":use-mainline-bsp"
* raspberrypi3

For both is builds wayland-protocols_1.13.imx. So now the situation is
even worth: It builds fine but the wrong version of wayland protocols.
I think we need something like wayland-protocols-imx and
PREFERRED_PROVIDER solution

Cheers

Andreas
--

[Gary Bisson]

Hi,

Post by Andreas Müller

Post by Tom Hochstein
Fix the PACKAGE_ARCH so that our i.MX-specific version does not
override the standard allarch version.
---
recipes-graphics/wayland/wayland-protocols_1.13.imx.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb b/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb
index c2ea68e..c722371 100644
--- a/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb
+++ b/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb
@@ -17,7 +17,9 @@ SRC_URI[md5sum] = "29312149dafcd4a0e739ba94995a574d"
SRC_URI[sha256sum] = "0758bc8008d5332f431b2a84fea7de64d971ce270ed208206a098ff2ebc68f38"
S = "${WORKDIR}/${ARCHIVE_NAME}"
-inherit allarch autotools pkgconfig
+inherit autotools pkgconfig
PACKAGES = "${PN}"
FILES_${PN} += "${datadir}/pkgconfig/wayland-protocols.pc"
+
+PACKAGE_ARCH = "${MACHINE_SOCARCH}"
--
2.7.4
--

* MACHINE = "imx6qdl-variscite-som" / MACHINEOVERRIDES .= ":use-mainline-bsp"
* raspberrypi3
For both is builds wayland-protocols_1.13.imx. So now the situation is
even worth: It builds fine but the wrong version of wayland protocols.
I think we need something like wayland-protocols-imx and
PREFERRED_PROVIDER solution

The preferred_provider should indeed fix the use-mainline-bsp usecase.

However I wonder why we need such recipe, wouldn't a bbappend to the
wayland protocol recipe be sufficient?

Looking at the patches, they could actually be brought down to 2 patches:
1- add hdr10-metadata protocol
2- add alpha-compositing protocol

Those patches really are not intrusive so I'm pretty sure they'd apply
nicely on any version of wayland-protocol.

Or maybe using the upstream version breaks things?

As a FYI, I revived the alpha-compositing thread upstream so that it
could be merged someday [1].

Tom, is there any plan to upstream the hdr10-metadata protocol?

Regards,
Gary

[1] https://patchwork.freedesktop.org/patch/170804/
--

[Andreas Müller]

On Tue, Sep 11, 2018 at 1:03 PM, Gary Bisson

Post by Gary Bisson

Post by Andreas Müller
For both is builds wayland-protocols_1.13.imx. So now the situation is
even worth: It builds fine but the wrong version of wayland protocols.
I think we need something like wayland-protocols-imx and
PREFERRED_PROVIDER solution

The preferred_provider should indeed fix the use-mainline-bsp usecase.

At the risk of me repeating myself: All boards get wayland-protocols
V3 tailored for imx. This is something a BSP should not do.

Post by Gary Bisson
However I wonder why we need such recipe, wouldn't a bbappend to the
wayland protocol recipe be sufficient?

If yes: same - please make sure other boards are not affected.

Post by Gary Bisson
1- add hdr10-metadata protocol
2- add alpha-compositing protocol
Those patches really are not intrusive so I'm pretty sure they'd apply
nicely on any version of wayland-protocol.
Or maybe using the upstream version breaks things?
As a FYI, I revived the alpha-compositing thread upstream so that it
could be merged someday [1].
Tom, is there any plan to upstream the hdr10-metadata protocol?
Regards,
Gary
[1] https://patchwork.freedesktop.org/patch/170804/

Andreas
--

[Otavio Salvador]

Post by Andreas Müller
On Tue, Sep 11, 2018 at 1:03 PM, Gary Bisson

...

Post by Andreas Müller

Post by Gary Bisson
However I wonder why we need such recipe, wouldn't a bbappend to the
wayland protocol recipe be sufficient?

If yes: same - please make sure other boards are not affected.

NXP needs to suffer from their bad decisions in not upstreaming stuff
so using their own for puts on their side the need to upgrade.

Andreas, I did check here and I belive your tmp directory is messed up
due the previous package being built as allarch.

From a clean sstate, I built for a mainline machine and for sabresd. I got:

% ye pv wayland-protocols
[0] ~/.../deploy/ipk/all/wayland-protocols_1.15-r0.0_all.ipk [0]
[1] ~/.../deploy/ipk/armv7ahf-neon-mx6qdl/wayland-protocols_1.13.imx-r0.0_armv7ahf-neon-mx6qdl.ipk
[1]
Option (ENTER to cancel):

[Andreas Müller]

On Tue, Sep 11, 2018 at 4:40 PM, Otavio Salvador

Post by Otavio Salvador

Post by Andreas Müller
On Tue, Sep 11, 2018 at 1:03 PM, Gary Bisson

...

Post by Andreas Müller

Post by Gary Bisson
However I wonder why we need such recipe, wouldn't a bbappend to the
wayland protocol recipe be sufficient?

If yes: same - please make sure other boards are not affected.

NXP needs to suffer from their bad decisions in not upstreaming stuff
so using their own for puts on their side the need to upgrade.
Andreas, I did check here and I belive your tmp directory is messed up
due the previous package being built as allarch.
% ye pv wayland-protocols
[0] ~/.../deploy/ipk/all/wayland-protocols_1.15-r0.0_all.ipk [0]
[1] ~/.../deploy/ipk/armv7ahf-neon-mx6qdl/wayland-protocols_1.13.imx-r0.0_armv7ahf-neon-mx6qdl.ipk
[1]

Hmm - as far as I can remember I did ccleansstate for
wayland-protocols before applying the last patch series.

Is sstate involved in the decision which version is selected at all?

The fact that it failed for me does not make me feel comfortable...

Cannot test with fresh rootfs and switch machines back and forth
currently - that is a time consuming business and nobody gives me that
time...

Andreas
--

[Otavio Salvador]

Post by Andreas Müller
On Tue, Sep 11, 2018 at 4:40 PM, Otavio Salvador

...

Post by Andreas Müller
Cannot test with fresh rootfs and switch machines back and forth
currently - that is a time consuming business and nobody gives me that
time...

In fact it can indeed misbehave. I suggest you clean tmpdir and do a test.

Doing the build from sstate should be fine.

[Andreas Müller]

On Tue, Sep 11, 2018 at 6:55 PM, Otavio Salvador

Post by Otavio Salvador

Post by Andreas Müller
On Tue, Sep 11, 2018 at 4:40 PM, Otavio Salvador

...

Post by Andreas Müller
Cannot test with fresh rootfs and switch machines back and forth
currently - that is a time consuming business and nobody gives me that
time...

In fact it can indeed misbehave. I suggest you clean tmpdir and do a test.
Doing the build from sstate should be fine.

Just cleaned up my temp dir and did build from scratch for

* imx6-based board with use-mainline-bsp
* raspberrypi3:
ERROR: wayland-protocols-1.13.imx-r0 do_unpack: Unpack failure for
URL: 'https://wayland.freedesktop.org/releases/wayland-protocols-1.13.tar.xz'.
Unpack command PATH="/home/superandy/oe-core/sources/openembedded-core/scripts:/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/recipe-sysroot-native/usr/bin/arm-angstrom-linux-gnueabi:/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/recipe-sysroot/usr/bin/crossscripts:/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/recipe-sysroot-native/usr/sbin:/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/recipe-sysroot-native/usr/bin:/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/recipe-sysroot-native/sbin:/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/recipe-sysroot-native/bin:/home/superandy/oe-core/sources/bitbake/bin:/home/superandy/tmp/oe-core-glibc/hosttools"
xz -dc /home/superandy/data/Downloads/packets/dl/wayland-protocols-1.13.tar.xz
| tar x --no-same-owner -f - failed with return value 2
ERROR: wayland-protocols-1.13.imx-r0 do_unpack: Function failed: base_do_unpack
ERROR: Logfile of failure stored in:
/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/temp/log.do_unpack.26847
ERROR: Task (/home/superandy/oe-core/sources/meta-freescale/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb:do_unpack)
failed with exit code '1'

Both same: it tries to build non-allarch wayland-protocols 1.13.imx.

Something in my configuration is different but I won't check further
since I am really tired of BSP-layers with umpteen of quirks for
graphic-BLOB-pin-all-to-versions-and-still-not-working shit.

Sorry for the harshness, but this waste of resources drives me insane :)

Andreas
--

[Otavio Salvador]

Post by Andreas Müller
On Tue, Sep 11, 2018 at 6:55 PM, Otavio Salvador

Post by Otavio Salvador

Post by Andreas Müller
On Tue, Sep 11, 2018 at 4:40 PM, Otavio Salvador

...

Post by Andreas Müller
Cannot test with fresh rootfs and switch machines back and forth
currently - that is a time consuming business and nobody gives me that
time...

In fact it can indeed misbehave. I suggest you clean tmpdir and do a test.
Doing the build from sstate should be fine.

Just cleaned up my temp dir and did build from scratch for
* imx6-based board with use-mainline-bsp
ERROR: wayland-protocols-1.13.imx-r0 do_unpack: Unpack failure for
URL: 'https://wayland.freedesktop.org/releases/wayland-protocols-1.13.tar.xz'.
Unpack command PATH="/home/superandy/oe-core/sources/openembedded-core/scripts:/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/recipe-sysroot-native/usr/bin/arm-angstrom-linux-gnueabi:/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/recipe-sysroot/usr/bin/crossscripts:/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/recipe-sysroot-native/usr/sbin:/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/recipe-sysroot-native/usr/bin:/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/recipe-sysroot-native/sbin:/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/recipe-sysroot-native/bin:/home/superandy/oe-core/sources/bitbake/bin:/home/superandy/tmp/oe-core-glibc/hosttools"
xz -dc /home/superandy/data/Downloads/packets/dl/wayland-protocols-1.13.tar.xz
| tar x --no-same-owner -f - failed with return value 2
ERROR: wayland-protocols-1.13.imx-r0 do_unpack: Function failed: base_do_unpack
/home/superandy/tmp/oe-core-glibc/work/${MACHINE_SOCARCH}-angstrom-linux-gnueabi/wayland-protocols/1.13.imx-r0/temp/log.do_unpack.26847
ERROR: Task (/home/superandy/oe-core/sources/meta-freescale/recipes-graphics/wayland/wayland-protocols_1.13.imx.bb:do_unpack)
failed with exit code '1'
Both same: it tries to build non-allarch wayland-protocols 1.13.imx.
Something in my configuration is different but I won't check further
since I am really tired of BSP-layers with umpteen of quirks for
graphic-BLOB-pin-all-to-versions-and-still-not-working shit.
Sorry for the harshness, but this waste of resources drives me insane :)

Oh you are using angstrom.

I fixed a missing compatible machine settings which should do the trick.

https://github.com/Freescale/meta-freescale/commit/82e14816a9f07781a792eda4cb2f72b94a7bba8c

[Andreas Müller]

On Wed, Sep 12, 2018 at 2:47 PM, Otavio Salvador

Post by Otavio Salvador
Oh you are using angstrom.

Not really - it is a stripped down fork

Post by Otavio Salvador
I fixed a missing compatible machine settings which should do the trick.
https://github.com/Freescale/meta-freescale/commit/82e14816a9f07781a792eda4cb2f72b94a7bba8c

Thanks - looks good - will try later

Andreas
--