Re: [meta-freescale] [PATCH v2 2/2] wayland-protocols: Fix PACKAGE_ARCH for i.MX-specific version
On Wed, Sep 12, 2018 at 2:47 PM, Otavio Salvador wrote: > > Oh you are using angstrom. Not really - it is a stripped down fork > > 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 -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [PATCH v2 2/2] wayland-protocols: Fix PACKAGE_ARCH for i.MX-specific version
On Wed, Sep 12, 2018 at 6:18 AM Andreas Müller wrote:
> On Tue, Sep 11, 2018 at 6:55 PM, Otavio Salvador
> wrote:
> > On Tue, Sep 11, 2018 at 12:12 PM Andreas Müller
> > wrote:
> >>
> >> On Tue, Sep 11, 2018 at 4:40 PM, Otavio Salvador
> >> wrote:
> > ...
> >> 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 :)
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
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [PATCH v2 2/2] wayland-protocols: Fix PACKAGE_ARCH for i.MX-specific version
On Tue, Sep 11, 2018 at 6:55 PM, Otavio Salvador
wrote:
> On Tue, Sep 11, 2018 at 12:12 PM Andreas Müller
> wrote:
>>
>> On Tue, Sep 11, 2018 at 4:40 PM, Otavio Salvador
>> wrote:
> ...
>> 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
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [PATCH v2 2/2] wayland-protocols: Fix PACKAGE_ARCH for i.MX-specific version
On Tue, Sep 11, 2018 at 12:12 PM Andreas Müller wrote: > > On Tue, Sep 11, 2018 at 4:40 PM, Otavio Salvador > wrote: ... > 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. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [PATCH v2 2/2] wayland-protocols: Fix PACKAGE_ARCH for i.MX-specific version
On Tue, Sep 11, 2018 at 4:40 PM, Otavio Salvador wrote: > On Tue, Sep 11, 2018 at 8:15 AM Andreas Müller > wrote: >> On Tue, Sep 11, 2018 at 1:03 PM, Gary Bisson >> wrote: > ... >> > 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): > > 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 -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [PATCH v2 2/2] wayland-protocols: Fix PACKAGE_ARCH for i.MX-specific version
On Tue, Sep 11, 2018 at 8:15 AM Andreas Müller wrote: > On Tue, Sep 11, 2018 at 1:03 PM, Gary Bisson > wrote: ... > > 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): -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [PATCH v2 2/2] wayland-protocols: Fix PACKAGE_ARCH for i.MX-specific version
On Tue, Sep 11, 2018 at 1:03 PM, Gary Bisson wrote: >> 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. > > 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. > > 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 -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [PATCH v2 2/2] wayland-protocols: Fix PACKAGE_ARCH for i.MX-specific version
Hi,
On Tue, Sep 11, 2018 at 9:44 AM, Andreas Müller wrote:
> On Mon, Sep 10, 2018 at 11:21 PM, Tom Hochstein wrote:
>> Fix the PACKAGE_ARCH so that our i.MX-specific version does not
>> override the standard allarch version.
>>
>> Signed-off-by: Tom Hochstein
>> ---
>> 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
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/
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [PATCH v2 2/2] wayland-protocols: Fix PACKAGE_ARCH for i.MX-specific version
On Mon, Sep 10, 2018 at 11:21 PM, Tom Hochstein wrote:
> Fix the PACKAGE_ARCH so that our i.MX-specific version does not
> override the standard allarch version.
>
> Signed-off-by: Tom Hochstein
> ---
> 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
--
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
