[PATCH 1/5] libva: Split out the base parts into an include file

[PATCH 1/5] libva: Split out the base parts into an include file

[Böszörményi Zoltán]

Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
---
 meta/recipes-graphics/libva/libva-2.6.1.inc | 30 ++++++++++++++++++++
 meta/recipes-graphics/libva/libva_2.6.1.bb  | 31 ++-------------------
 2 files changed, 32 insertions(+), 29 deletions(-)
 create mode 100644 meta/recipes-graphics/libva/libva-2.6.1.inc

diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc b/meta/recipes-graphics/libva/libva-2.6.1.inc
new file mode 100644
index 0000000000..ca1386d80b
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -0,0 +1,30 @@
+SUMMARY = "Video Acceleration (VA) API for Linux"
+DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
+and API specification which enables and provides access to graphics \
+hardware (GPU) acceleration for video processing on Linux and UNIX \
+based operating systems. Accelerated processing includes video \
+decoding, video encoding, subpicture blending and rendering. The \
+specification was originally designed by Intel for its GMA (Graphics \
+Media Accelerator) series of GPU hardware, the API is however not \
+limited to GPUs or Intel specific hardware, as other hardware and \
+manufacturers can also freely use this API for hardware accelerated \
+video decoding."
+
+HOMEPAGE = "https://01.org/linuxmedia/vaapi"
+BUGTRACKER = "https://github.com/intel/libva/issues"
+
+SECTION = "x11"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
+
+SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
+SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
+SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
+
+UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
+
+DEPENDS = "libdrm"
+
+inherit meson pkgconfig features_check
+
+REQUIRED_DISTRO_FEATURES = "opengl"
diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb b/meta/recipes-graphics/libva/libva_2.6.1.bb
index 92cea83bc1..af4c1c98ab 100644
--- a/meta/recipes-graphics/libva/libva_2.6.1.bb
+++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
@@ -1,33 +1,6 @@
-SUMMARY = "Video Acceleration (VA) API for Linux"
-DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
-and API specification which enables and provides access to graphics \
-hardware (GPU) acceleration for video processing on Linux and UNIX \
-based operating systems. Accelerated processing includes video \
-decoding, video encoding, subpicture blending and rendering. The \
-specification was originally designed by Intel for its GMA (Graphics \
-Media Accelerator) series of GPU hardware, the API is however not \
-limited to GPUs or Intel specific hardware, as other hardware and \
-manufacturers can also freely use this API for hardware accelerated \
-video decoding."
+require libva-${PV}.inc
 
-HOMEPAGE = "https://01.org/linuxmedia/vaapi"
-BUGTRACKER = "https://github.com/intel/libva/issues"
-
-SECTION = "x11"
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
-
-SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
-SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
-SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
-
-UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
-
-DEPENDS = "libdrm virtual/mesa"
-
-inherit meson pkgconfig features_check
-
-REQUIRED_DISTRO_FEATURES = "opengl"
+DEPENDS += "virtual/mesa"
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)}"
 PACKAGECONFIG[x11] = "-Dwith_x11=yes, -Dwith_x11=no,virtual/libx11 libxext libxfixes"
-- 
2.24.1

[PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.

Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
---
 meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
 meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
 2 files changed, 8 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb

diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc b/meta/recipes-graphics/libva/libva-2.6.1.inc
index ca1386d80b..5b1cdee7e3 100644
--- a/meta/recipes-graphics/libva/libva-2.6.1.inc
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -17,10 +17,12 @@ SECTION = "x11"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
 
-SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
+SRC_URI = "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
 SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
 SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
 
+S = "${WORKDIR}/libva-${PV}"
+
 UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
 
 DEPENDS = "libdrm"
diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
new file mode 100644
index 0000000000..828ef6fbca
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,5 @@
+require libva-${PV}.inc
+
+do_install_append () {
+	rm -f ${D}${libdir}/*.so*
+}
-- 
2.24.1

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Paul Barker]

On Wed, 26 Feb 2020 at 14:04, Böszörményi Zoltán via Openembedded-core
<openembedded-core@lists.openembedded.org> wrote:
>
> The package name exploits sstate.bbclass so it's not added as
> implicit dependency to packages.
>
> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
> ---
>  meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>  meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
>  2 files changed, 8 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>
> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc b/meta/recipes-graphics/libva/libva-2.6.1.inc
> index ca1386d80b..5b1cdee7e3 100644
> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> @@ -17,10 +17,12 @@ SECTION = "x11"
>  LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>
> -SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
> +SRC_URI = "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
>  SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>  SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>
> +S = "${WORKDIR}/libva-${PV}"
> +
>  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>
>  DEPENDS = "libdrm"
> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> new file mode 100644
> index 0000000000..828ef6fbca
> --- /dev/null
> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> @@ -0,0 +1,5 @@
> +require libva-${PV}.inc
> +
> +do_install_append () {
> +       rm -f ${D}${libdir}/*.so*
> +}

Can you avoid building libva in the -initial recipe and still get the
headers and pkgconfig files?

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

2020. 02. 26. 15:13 keltezéssel, Paul Barker írta:
> On Wed, 26 Feb 2020 at 14:04, Böszörményi Zoltán via Openembedded-core
> <openembedded-core@lists.openembedded.org> wrote:
>>
>> The package name exploits sstate.bbclass so it's not added as
>> implicit dependency to packages.
>>
>> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
>> ---
>>   meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>>   meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
>>   2 files changed, 8 insertions(+), 1 deletion(-)
>>   create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>
>> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc b/meta/recipes-graphics/libva/libva-2.6.1.inc
>> index ca1386d80b..5b1cdee7e3 100644
>> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>> @@ -17,10 +17,12 @@ SECTION = "x11"
>>   LICENSE = "MIT"
>>   LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>>
>> -SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
>> +SRC_URI = "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
>>   SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>>   SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>>
>> +S = "${WORKDIR}/libva-${PV}"
>> +
>>   UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>>
>>   DEPENDS = "libdrm"
>> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>> new file mode 100644
>> index 0000000000..828ef6fbca
>> --- /dev/null
>> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>> @@ -0,0 +1,5 @@
>> +require libva-${PV}.inc
>> +
>> +do_install_append () {
>> +       rm -f ${D}${libdir}/*.so*
>> +}
> 
> Can you avoid building libva in the -initial recipe and still get the
> headers and pkgconfig files?

Not really, as "make install" would still build and install the libraries.

I haven't found a set of "make -C ... install" commands to only install
the headers and the pkgconfig files. I also wanted to avoid adding patches
to keep the recipe minimal.

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Khem Raj]

On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>
> The package name exploits sstate.bbclass so it's not added as
> implicit dependency to packages.
>

what is the use of this recipe and why should it be added to core ?

> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
> ---
>  meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>  meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
>  2 files changed, 8 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>
> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc b/meta/recipes-graphics/libva/libva-2.6.1.inc
> index ca1386d80b..5b1cdee7e3 100644
> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> @@ -17,10 +17,12 @@ SECTION = "x11"
>  LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>
> -SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
> +SRC_URI = "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
>  SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>  SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>
> +S = "${WORKDIR}/libva-${PV}"
> +
>  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>
>  DEPENDS = "libdrm"
> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> new file mode 100644
> index 0000000000..828ef6fbca
> --- /dev/null
> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> @@ -0,0 +1,5 @@
> +require libva-${PV}.inc
> +
> +do_install_append () {
> +       rm -f ${D}${libdir}/*.so*
> +}
> --
> 2.24.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
> Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>>
>> The package name exploits sstate.bbclass so it's not added as
>> implicit dependency to packages.
>>
> 
> what is the use of this recipe and why should it be added to core ?

I should have added a cover letter, shouldn't I?
See patch 3/5 in the series for enabling gallium-va in Mesa.

> 
>> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
>> ---
>>   meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>>   meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
>>   2 files changed, 8 insertions(+), 1 deletion(-)
>>   create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>
>> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc b/meta/recipes-graphics/libva/libva-2.6.1.inc
>> index ca1386d80b..5b1cdee7e3 100644
>> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>> @@ -17,10 +17,12 @@ SECTION = "x11"
>>   LICENSE = "MIT"
>>   LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>>
>> -SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
>> +SRC_URI = "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
>>   SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>>   SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>>
>> +S = "${WORKDIR}/libva-${PV}"
>> +
>>   UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>>
>>   DEPENDS = "libdrm"
>> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>> new file mode 100644
>> index 0000000000..828ef6fbca
>> --- /dev/null
>> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>> @@ -0,0 +1,5 @@
>> +require libva-${PV}.inc
>> +
>> +do_install_append () {
>> +       rm -f ${D}${libdir}/*.so*
>> +}
>> --
>> 2.24.1
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Khem Raj]

On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>
> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
> > On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
> > Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
> >>
> >> The package name exploits sstate.bbclass so it's not added as
> >> implicit dependency to packages.
> >>
> >
> > what is the use of this recipe and why should it be added to core ?
>
> I should have added a cover letter, shouldn't I?
> See patch 3/5 in the series for enabling gallium-va in Mesa.
>

recipe seems to build full libva, so why not just use that instead.

> >
> >> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
> >> ---
> >>   meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
> >>   meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
> >>   2 files changed, 8 insertions(+), 1 deletion(-)
> >>   create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >>
> >> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc b/meta/recipes-graphics/libva/libva-2.6.1.inc
> >> index ca1386d80b..5b1cdee7e3 100644
> >> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
> >> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> >> @@ -17,10 +17,12 @@ SECTION = "x11"
> >>   LICENSE = "MIT"
> >>   LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
> >>
> >> -SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
> >> +SRC_URI = "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
> >>   SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
> >>   SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
> >>
> >> +S = "${WORKDIR}/libva-${PV}"
> >> +
> >>   UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
> >>
> >>   DEPENDS = "libdrm"
> >> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >> new file mode 100644
> >> index 0000000000..828ef6fbca
> >> --- /dev/null
> >> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >> @@ -0,0 +1,5 @@
> >> +require libva-${PV}.inc
> >> +
> >> +do_install_append () {
> >> +       rm -f ${D}${libdir}/*.so*
> >> +}
> >> --
> >> 2.24.1
> >>
> >> --
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
> On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>>
>> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
>>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
>>> Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>>>>
>>>> The package name exploits sstate.bbclass so it's not added as
>>>> implicit dependency to packages.
>>>>
>>>
>>> what is the use of this recipe and why should it be added to core ?
>>
>> I should have added a cover letter, shouldn't I?
>> See patch 3/5 in the series for enabling gallium-va in Mesa.
>>
> 
> recipe seems to build full libva, so why not just use that instead.

You don't seem to be reading mails from openembedded-devel that
you were cc-ed on.
http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html

> 
>>>
>>>> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
>>>> ---
>>>>    meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>>>>    meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
>>>>    2 files changed, 8 insertions(+), 1 deletion(-)
>>>>    create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>
>>>> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>> index ca1386d80b..5b1cdee7e3 100644
>>>> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>> @@ -17,10 +17,12 @@ SECTION = "x11"
>>>>    LICENSE = "MIT"
>>>>    LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>>>>
>>>> -SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
>>>> +SRC_URI = "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
>>>>    SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>>>>    SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>>>>
>>>> +S = "${WORKDIR}/libva-${PV}"
>>>> +
>>>>    UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>>>>
>>>>    DEPENDS = "libdrm"
>>>> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>> new file mode 100644
>>>> index 0000000000..828ef6fbca
>>>> --- /dev/null
>>>> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>> @@ -0,0 +1,5 @@
>>>> +require libva-${PV}.inc
>>>> +
>>>> +do_install_append () {
>>>> +       rm -f ${D}${libdir}/*.so*
>>>> +}
>>>> --
>>>> 2.24.1
>>>>
>>>> --
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

2020. 02. 26. 16:20 keltezéssel, Böszörményi Zoltán írta:
> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
>> On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>>>
>>> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
>>>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
>>>> Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>>>>>
>>>>> The package name exploits sstate.bbclass so it's not added as
>>>>> implicit dependency to packages.
>>>>>
>>>>
>>>> what is the use of this recipe and why should it be added to core ?
>>>
>>> I should have added a cover letter, shouldn't I?
>>> See patch 3/5 in the series for enabling gallium-va in Mesa.
>>>
>>
>> recipe seems to build full libva, so why not just use that instead.
> 
> You don't seem to be reading mails from openembedded-devel that
> you were cc-ed on.
> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html

TL;DR: Making mesa depend on libva would introduce a circular dependency.

> 
>>
>>>>
>>>>> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
>>>>> ---
>>>>>    meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>>>>>    meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
>>>>>    2 files changed, 8 insertions(+), 1 deletion(-)
>>>>>    create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>
>>>>> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc 
>>>>> b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>> index ca1386d80b..5b1cdee7e3 100644
>>>>> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>> @@ -17,10 +17,12 @@ SECTION = "x11"
>>>>>    LICENSE = "MIT"
>>>>>    LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>>>>>
>>>>> -SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
>>>>> +SRC_URI = "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
>>>>>    SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>>>>>    SRC_URI[sha256sum] = 
>>>>> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>>>>>
>>>>> +S = "${WORKDIR}/libva-${PV}"
>>>>> +
>>>>>    UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>>>>>
>>>>>    DEPENDS = "libdrm"
>>>>> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
>>>>> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>> new file mode 100644
>>>>> index 0000000000..828ef6fbca
>>>>> --- /dev/null
>>>>> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>> @@ -0,0 +1,5 @@
>>>>> +require libva-${PV}.inc
>>>>> +
>>>>> +do_install_append () {
>>>>> +       rm -f ${D}${libdir}/*.so*
>>>>> +}
>>>>> -- 
>>>>> 2.24.1
>>>>>
>>>>> -- 
>>>>> _______________________________________________
>>>>> Openembedded-core mailing list
>>>>> Openembedded-core@lists.openembedded.org
>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
> 

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Khem Raj]

On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>
> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
> > On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
> >>
> >> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
> >>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
> >>> Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
> >>>>
> >>>> The package name exploits sstate.bbclass so it's not added as
> >>>> implicit dependency to packages.
> >>>>
> >>>
> >>> what is the use of this recipe and why should it be added to core ?
> >>
> >> I should have added a cover letter, shouldn't I?
> >> See patch 3/5 in the series for enabling gallium-va in Mesa.
> >>
> >
> > recipe seems to build full libva, so why not just use that instead.
>
> You don't seem to be reading mails from openembedded-devel that
> you were cc-ed on.

don't assume things

> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html
>

I am trying to make us thing if -dev package can be used somehow to avoid this
or have we exhausted all possibilities.

> >
> >>>
> >>>> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
> >>>> ---
> >>>>    meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
> >>>>    meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
> >>>>    2 files changed, 8 insertions(+), 1 deletion(-)
> >>>>    create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >>>>
> >>>> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc b/meta/recipes-graphics/libva/libva-2.6.1.inc
> >>>> index ca1386d80b..5b1cdee7e3 100644
> >>>> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
> >>>> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> >>>> @@ -17,10 +17,12 @@ SECTION = "x11"
> >>>>    LICENSE = "MIT"
> >>>>    LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
> >>>>
> >>>> -SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
> >>>> +SRC_URI = "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
> >>>>    SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
> >>>>    SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
> >>>>
> >>>> +S = "${WORKDIR}/libva-${PV}"
> >>>> +
> >>>>    UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
> >>>>
> >>>>    DEPENDS = "libdrm"
> >>>> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >>>> new file mode 100644
> >>>> index 0000000000..828ef6fbca
> >>>> --- /dev/null
> >>>> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >>>> @@ -0,0 +1,5 @@
> >>>> +require libva-${PV}.inc
> >>>> +
> >>>> +do_install_append () {
> >>>> +       rm -f ${D}${libdir}/*.so*
> >>>> +}
> >>>> --
> >>>> 2.24.1
> >>>>
> >>>> --
> >>>> _______________________________________________
> >>>> Openembedded-core mailing list
> >>>> Openembedded-core@lists.openembedded.org
> >>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>
>

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
> On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>>
>> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
>>> On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>>>>
>>>> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
>>>>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
>>>>> Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>>>>>>
>>>>>> The package name exploits sstate.bbclass so it's not added as
>>>>>> implicit dependency to packages.
>>>>>>
>>>>>
>>>>> what is the use of this recipe and why should it be added to core ?
>>>>
>>>> I should have added a cover letter, shouldn't I?
>>>> See patch 3/5 in the series for enabling gallium-va in Mesa.
>>>>
>>>
>>> recipe seems to build full libva, so why not just use that instead.
>>
>> You don't seem to be reading mails from openembedded-devel that
>> you were cc-ed on.
> 
> don't assume things

Understood.

>> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html
>>
> 
> I am trying to make us thing if -dev package can be used somehow to avoid this
> or have we exhausted all possibilities.

Why is it a problem to exploit sstate.bbclass internals implicitly
by using a *-initial package name for an arbitrary package?
Surely it's not reserved for libgcc-initial and friends.

It solves two problems nicely in one go:
1. by using a different package than libva, the libva-vs-mesa
    circular dependency is avoided. mesa needs a crippled libva (pkgconfig + headers)
    to build its VAAPI state tracker and the VAAPI drivers
2. by using libva-initial as the package name, the per-recipe sysroot issue
    is avoided where prepare-sysroot for a 3rd package like intel-vaapi-driver
    would fail because the real libva the crippled variant would install
    identical files

> 
>>>
>>>>>
>>>>>> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
>>>>>> ---
>>>>>>     meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>>>>>>     meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
>>>>>>     2 files changed, 8 insertions(+), 1 deletion(-)
>>>>>>     create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>
>>>>>> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>> index ca1386d80b..5b1cdee7e3 100644
>>>>>> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>> @@ -17,10 +17,12 @@ SECTION = "x11"
>>>>>>     LICENSE = "MIT"
>>>>>>     LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>>>>>>
>>>>>> -SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
>>>>>> +SRC_URI = "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
>>>>>>     SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>>>>>>     SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>>>>>>
>>>>>> +S = "${WORKDIR}/libva-${PV}"
>>>>>> +
>>>>>>     UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>>>>>>
>>>>>>     DEPENDS = "libdrm"
>>>>>> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>> new file mode 100644
>>>>>> index 0000000000..828ef6fbca
>>>>>> --- /dev/null
>>>>>> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>> @@ -0,0 +1,5 @@
>>>>>> +require libva-${PV}.inc
>>>>>> +
>>>>>> +do_install_append () {
>>>>>> +       rm -f ${D}${libdir}/*.so*
>>>>>> +}
>>>>>> --
>>>>>> 2.24.1
>>>>>>
>>>>>> --
>>>>>> _______________________________________________
>>>>>> Openembedded-core mailing list
>>>>>> Openembedded-core@lists.openembedded.org
>>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>>
>>

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Khem Raj]

On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:
> 2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
>> On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>>>
>>> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
>>>> On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor@pr.hu>
>>>> wrote:
>>>>>
>>>>> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
>>>>>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
>>>>>> Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>>>>>>>
>>>>>>> The package name exploits sstate.bbclass so it's not added as
>>>>>>> implicit dependency to packages.
>>>>>>>
>>>>>>
>>>>>> what is the use of this recipe and why should it be added to core ?
>>>>>
>>>>> I should have added a cover letter, shouldn't I?
>>>>> See patch 3/5 in the series for enabling gallium-va in Mesa.
>>>>>
>>>>
>>>> recipe seems to build full libva, so why not just use that instead.
>>>
>>> You don't seem to be reading mails from openembedded-devel that
>>> you were cc-ed on.
>>
>> don't assume things
> 
> Understood.
> 
>>> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html
>>>
>>>
>>
>> I am trying to make us thing if -dev package can be used somehow to
>> avoid this
>> or have we exhausted all possibilities.
> 
> Why is it a problem to exploit sstate.bbclass internals implicitly
> by using a *-initial package name for an arbitrary package?

it is not a problem, however, it is a work to keep such setup going and
also it has to be considered always in dependencies etc.

> Surely it's not reserved for libgcc-initial and friends.
> 

they are different usecases, libgcc-initial is a veneer/trampoline used
to bootstrap toolchain, and that too we want to remove at every
opportunity we get, we use to have lot of initial recipes and they are
very few left, so we have to be mindful of adding another one.

> It solves two problems nicely in one go:
> 1. by using a different package than libva, the libva-vs-mesa
>    circular dependency is avoided. mesa needs a crippled libva
> (pkgconfig + headers)
>    to build its VAAPI state tracker and the VAAPI drivers

I see archlinux using full libva for this. how are other distros doing
it? is this problem unique to OE

> 2. by using libva-initial as the package name, the per-recipe sysroot issue
>    is avoided where prepare-sysroot for a 3rd package like
> intel-vaapi-driver
>    would fail because the real libva the crippled variant would install
>    identical files
> 

right, this is the problem I am afraid of creating almost duplicate packages

>>
>>>>
>>>>>>
>>>>>>> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
>>>>>>> ---
>>>>>>>     meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>>>>>>>     meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
>>>>>>>     2 files changed, 8 insertions(+), 1 deletion(-)
>>>>>>>     create mode 100644
>>>>>>> meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>
>>>>>>> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>> b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>> index ca1386d80b..5b1cdee7e3 100644
>>>>>>> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>> @@ -17,10 +17,12 @@ SECTION = "x11"
>>>>>>>     LICENSE = "MIT"
>>>>>>>     LIC_FILES_CHKSUM =
>>>>>>> "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>>>>>>>
>>>>>>> -SRC_URI =
>>>>>>> "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
>>>>>>>
>>>>>>> +SRC_URI =
>>>>>>> "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
>>>>>>>
>>>>>>>     SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>>>>>>>     SRC_URI[sha256sum] =
>>>>>>> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>>>>>>>
>>>>>>> +S = "${WORKDIR}/libva-${PV}"
>>>>>>> +
>>>>>>>     UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>>>>>>>
>>>>>>>     DEPENDS = "libdrm"
>>>>>>> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>> new file mode 100644
>>>>>>> index 0000000000..828ef6fbca
>>>>>>> --- /dev/null
>>>>>>> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>> @@ -0,0 +1,5 @@
>>>>>>> +require libva-${PV}.inc
>>>>>>> +
>>>>>>> +do_install_append () {
>>>>>>> +       rm -f ${D}${libdir}/*.so*
>>>>>>> +}
>>>>>>> -- 
>>>>>>> 2.24.1
>>>>>>>
>>>>>>> -- 
>>>>>>> _______________________________________________
>>>>>>> Openembedded-core mailing list
>>>>>>> Openembedded-core@lists.openembedded.org
>>>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>>>
>>>
> 

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:
> 
> 
> On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:
>> 2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
>>> On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>>>>
>>>> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
>>>>> On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor@pr.hu>
>>>>> wrote:
>>>>>>
>>>>>> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
>>>>>>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
>>>>>>> Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>>>>>>>>
>>>>>>>> The package name exploits sstate.bbclass so it's not added as
>>>>>>>> implicit dependency to packages.
>>>>>>>>
>>>>>>>
>>>>>>> what is the use of this recipe and why should it be added to core ?
>>>>>>
>>>>>> I should have added a cover letter, shouldn't I?
>>>>>> See patch 3/5 in the series for enabling gallium-va in Mesa.
>>>>>>
>>>>>
>>>>> recipe seems to build full libva, so why not just use that instead.
>>>>
>>>> You don't seem to be reading mails from openembedded-devel that
>>>> you were cc-ed on.
>>>
>>> don't assume things
>>
>> Understood.
>>
>>>> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html
>>>>
>>>>
>>>
>>> I am trying to make us thing if -dev package can be used somehow to
>>> avoid this
>>> or have we exhausted all possibilities.
>>
>> Why is it a problem to exploit sstate.bbclass internals implicitly
>> by using a *-initial package name for an arbitrary package?
> 
> it is not a problem, however, it is a work to keep such setup going and
> also it has to be considered always in dependencies etc.
> 
>> Surely it's not reserved for libgcc-initial and friends.
>>
> 
> they are different usecases, libgcc-initial is a veneer/trampoline used
> to bootstrap toolchain, and that too we want to remove at every
> opportunity we get, we use to have lot of initial recipes and they are
> very few left, so we have to be mindful of adding another one.
> 
>> It solves two problems nicely in one go:
>> 1. by using a different package than libva, the libva-vs-mesa
>>     circular dependency is avoided. mesa needs a crippled libva
>> (pkgconfig + headers)
>>     to build its VAAPI state tracker and the VAAPI drivers
> 
> I see archlinux using full libva for this. how are other distros doing
> it? is this problem unique to OE

Fedora also uses the full libva.

However, the chicken-and-egg circular dependency is broken by history
for these distros.

Koji and Mock build one package at a time with all their dependencies
already available from the staging package repository and the results
will be eventually uploaded to the same repository.

Bitbake doesn't have have this loophole to download pre-built dependencies.

> 
>> 2. by using libva-initial as the package name, the per-recipe sysroot issue
>>     is avoided where prepare-sysroot for a 3rd package like
>> intel-vaapi-driver
>>     would fail because the real libva the crippled variant would install
>>     identical files
>>
> 
> right, this is the problem I am afraid of creating almost duplicate packages
> 
>>>
>>>>>
>>>>>>>
>>>>>>>> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
>>>>>>>> ---
>>>>>>>>      meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>>>>>>>>      meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
>>>>>>>>      2 files changed, 8 insertions(+), 1 deletion(-)
>>>>>>>>      create mode 100644
>>>>>>>> meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>>
>>>>>>>> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>>> b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>>> index ca1386d80b..5b1cdee7e3 100644
>>>>>>>> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>>> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>>> @@ -17,10 +17,12 @@ SECTION = "x11"
>>>>>>>>      LICENSE = "MIT"
>>>>>>>>      LIC_FILES_CHKSUM =
>>>>>>>> "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>>>>>>>>
>>>>>>>> -SRC_URI =
>>>>>>>> "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
>>>>>>>>
>>>>>>>> +SRC_URI =
>>>>>>>> "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
>>>>>>>>
>>>>>>>>      SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>>>>>>>>      SRC_URI[sha256sum] =
>>>>>>>> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>>>>>>>>
>>>>>>>> +S = "${WORKDIR}/libva-${PV}"
>>>>>>>> +
>>>>>>>>      UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>>>>>>>>
>>>>>>>>      DEPENDS = "libdrm"
>>>>>>>> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000000..828ef6fbca
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>> @@ -0,0 +1,5 @@
>>>>>>>> +require libva-${PV}.inc
>>>>>>>> +
>>>>>>>> +do_install_append () {
>>>>>>>> +       rm -f ${D}${libdir}/*.so*
>>>>>>>> +}
>>>>>>>> -- 
>>>>>>>> 2.24.1
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> _______________________________________________
>>>>>>>> Openembedded-core mailing list
>>>>>>>> Openembedded-core@lists.openembedded.org
>>>>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>>>>
>>>>
>>

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

2020. 02. 26. 18:08 keltezéssel, Böszörményi Zoltán írta:
> 2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:
>>
>>
>> On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:
>>> 2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
>>>> On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>>>>>
>>>>> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
>>>>>> On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor@pr.hu>
>>>>>> wrote:
>>>>>>>
>>>>>>> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
>>>>>>>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
>>>>>>>> Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>>>>>>>>>
>>>>>>>>> The package name exploits sstate.bbclass so it's not added as
>>>>>>>>> implicit dependency to packages.
>>>>>>>>>
>>>>>>>>
>>>>>>>> what is the use of this recipe and why should it be added to core ?
>>>>>>>
>>>>>>> I should have added a cover letter, shouldn't I?
>>>>>>> See patch 3/5 in the series for enabling gallium-va in Mesa.
>>>>>>>
>>>>>>
>>>>>> recipe seems to build full libva, so why not just use that instead.
>>>>>
>>>>> You don't seem to be reading mails from openembedded-devel that
>>>>> you were cc-ed on.
>>>>
>>>> don't assume things
>>>
>>> Understood.
>>>
>>>>> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html
>>>>>
>>>>>
>>>>
>>>> I am trying to make us thing if -dev package can be used somehow to
>>>> avoid this
>>>> or have we exhausted all possibilities.
>>>
>>> Why is it a problem to exploit sstate.bbclass internals implicitly
>>> by using a *-initial package name for an arbitrary package?
>>
>> it is not a problem, however, it is a work to keep such setup going and
>> also it has to be considered always in dependencies etc.
>>
>>> Surely it's not reserved for libgcc-initial and friends.
>>>
>>
>> they are different usecases, libgcc-initial is a veneer/trampoline used
>> to bootstrap toolchain, and that too we want to remove at every
>> opportunity we get, we use to have lot of initial recipes and they are
>> very few left, so we have to be mindful of adding another one.
>>
>>> It solves two problems nicely in one go:
>>> 1. by using a different package than libva, the libva-vs-mesa
>>>     circular dependency is avoided. mesa needs a crippled libva
>>> (pkgconfig + headers)
>>>     to build its VAAPI state tracker and the VAAPI drivers
>>
>> I see archlinux using full libva for this. how are other distros doing
>> it? is this problem unique to OE
> 
> Fedora also uses the full libva.
> 
> However, the chicken-and-egg circular dependency is broken by history
> for these distros.
> 
> Koji and Mock build one package at a time with all their dependencies
> already available from the staging package repository and the results
> will be eventually uploaded to the same repository.
> 
> Bitbake doesn't have have this loophole to download pre-built dependencies.

Also, somewhere on 01.org or in the libva sources the same solution
I presented in this patchset is suggested:

1. build libva with --disable-glx (it is needed when Mesa SDK is present)
    but it's not needed by not depending on mesa in libva-initial
2. build mesa with libva build in (1) as it only needs the pkgconfig files
    and the headers
3. build libva with --enable-glx. It's autodetected, set to on with
    depending on mesa in the full libva recipe.

Obviusly the same libva recipe can't be used to build mesa that depends on mesa.

> 
>>
>>> 2. by using libva-initial as the package name, the per-recipe sysroot issue
>>>     is avoided where prepare-sysroot for a 3rd package like
>>> intel-vaapi-driver
>>>     would fail because the real libva the crippled variant would install
>>>     identical files
>>>
>>
>> right, this is the problem I am afraid of creating almost duplicate packages
>>
>>>>
>>>>>>
>>>>>>>>
>>>>>>>>> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
>>>>>>>>> ---
>>>>>>>>>      meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>>>>>>>>>      meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
>>>>>>>>>      2 files changed, 8 insertions(+), 1 deletion(-)
>>>>>>>>>      create mode 100644
>>>>>>>>> meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>>>
>>>>>>>>> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>>>> b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>>>> index ca1386d80b..5b1cdee7e3 100644
>>>>>>>>> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>>>> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>>>> @@ -17,10 +17,12 @@ SECTION = "x11"
>>>>>>>>>      LICENSE = "MIT"
>>>>>>>>>      LIC_FILES_CHKSUM =
>>>>>>>>> "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>>>>>>>>>
>>>>>>>>> -SRC_URI =
>>>>>>>>> "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
>>>>>>>>>
>>>>>>>>> +SRC_URI =
>>>>>>>>> "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
>>>>>>>>>
>>>>>>>>>      SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>>>>>>>>>      SRC_URI[sha256sum] =
>>>>>>>>> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>>>>>>>>>
>>>>>>>>> +S = "${WORKDIR}/libva-${PV}"
>>>>>>>>> +
>>>>>>>>>      UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>>>>>>>>>
>>>>>>>>>      DEPENDS = "libdrm"
>>>>>>>>> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>>> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>>> new file mode 100644
>>>>>>>>> index 0000000000..828ef6fbca
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>>> @@ -0,0 +1,5 @@
>>>>>>>>> +require libva-${PV}.inc
>>>>>>>>> +
>>>>>>>>> +do_install_append () {
>>>>>>>>> +       rm -f ${D}${libdir}/*.so*
>>>>>>>>> +}
>>>>>>>>> -- 
>>>>>>>>> 2.24.1
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> _______________________________________________
>>>>>>>>> Openembedded-core mailing list
>>>>>>>>> Openembedded-core@lists.openembedded.org
>>>>>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>>>>>
>>>>>
>>>
> 

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Khem Raj]

On 2/26/20 9:14 AM, Böszörményi Zoltán wrote:
> 2020. 02. 26. 18:08 keltezéssel, Böszörményi Zoltán írta:
>> 2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:
>>>
>>>
>>> On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:
>>>> 2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
>>>>> On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán <zboszor@pr.hu> 
>>>>> wrote:
>>>>>>
>>>>>> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
>>>>>>> On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor@pr.hu>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
>>>>>>>>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
>>>>>>>>> Openembedded-core <openembedded-core@lists.openembedded.org> 
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> The package name exploits sstate.bbclass so it's not added as
>>>>>>>>>> implicit dependency to packages.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> what is the use of this recipe and why should it be added to 
>>>>>>>>> core ?
>>>>>>>>
>>>>>>>> I should have added a cover letter, shouldn't I?
>>>>>>>> See patch 3/5 in the series for enabling gallium-va in Mesa.
>>>>>>>>
>>>>>>>
>>>>>>> recipe seems to build full libva, so why not just use that instead.
>>>>>>
>>>>>> You don't seem to be reading mails from openembedded-devel that
>>>>>> you were cc-ed on.
>>>>>
>>>>> don't assume things
>>>>
>>>> Understood.
>>>>
>>>>>> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> I am trying to make us thing if -dev package can be used somehow to
>>>>> avoid this
>>>>> or have we exhausted all possibilities.
>>>>
>>>> Why is it a problem to exploit sstate.bbclass internals implicitly
>>>> by using a *-initial package name for an arbitrary package?
>>>
>>> it is not a problem, however, it is a work to keep such setup going and
>>> also it has to be considered always in dependencies etc.
>>>
>>>> Surely it's not reserved for libgcc-initial and friends.
>>>>
>>>
>>> they are different usecases, libgcc-initial is a veneer/trampoline used
>>> to bootstrap toolchain, and that too we want to remove at every
>>> opportunity we get, we use to have lot of initial recipes and they are
>>> very few left, so we have to be mindful of adding another one.
>>>
>>>> It solves two problems nicely in one go:
>>>> 1. by using a different package than libva, the libva-vs-mesa
>>>>     circular dependency is avoided. mesa needs a crippled libva
>>>> (pkgconfig + headers)
>>>>     to build its VAAPI state tracker and the VAAPI drivers
>>>
>>> I see archlinux using full libva for this. how are other distros doing
>>> it? is this problem unique to OE
>>
>> Fedora also uses the full libva.
>>
>> However, the chicken-and-egg circular dependency is broken by history
>> for these distros.
>>
>> Koji and Mock build one package at a time with all their dependencies
>> already available from the staging package repository and the results
>> will be eventually uploaded to the same repository.
>>
>> Bitbake doesn't have have this loophole to download pre-built 
>> dependencies.
> 
> Also, somewhere on 01.org or in the libva sources the same solution
> I presented in this patchset is suggested:
> 
> 1. build libva with --disable-glx (it is needed when Mesa SDK is present)
>     but it's not needed by not depending on mesa in libva-initial
> 2. build mesa with libva build in (1) as it only needs the pkgconfig files
>     and the headers
> 3. build libva with --enable-glx. It's autodetected, set to on with
>     depending on mesa in the full libva recipe.

looking at the nature of the problem, it might be the way to unbreak the 
catch-22, does anything else needs this bootstrap header package ?
do we need to ensure that content of libva-dev and the bootstrap 
packages do not overlap.

> 
> Obviusly the same libva recipe can't be used to build mesa that depends 
> on mesa.
> 

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

2020. 02. 26. 20:44 keltezéssel, Khem Raj írta:
> 
> 
> On 2/26/20 9:14 AM, Böszörményi Zoltán wrote:
>> 2020. 02. 26. 18:08 keltezéssel, Böszörményi Zoltán írta:
>>> 2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:
>>>>
>>>>
>>>> On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:
>>>>> 2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
>>>>>> On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>>>>>>>
>>>>>>> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
>>>>>>>> On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor@pr.hu>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
>>>>>>>>>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
>>>>>>>>>> Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> The package name exploits sstate.bbclass so it's not added as
>>>>>>>>>>> implicit dependency to packages.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> what is the use of this recipe and why should it be added to core ?
>>>>>>>>>
>>>>>>>>> I should have added a cover letter, shouldn't I?
>>>>>>>>> See patch 3/5 in the series for enabling gallium-va in Mesa.
>>>>>>>>>
>>>>>>>>
>>>>>>>> recipe seems to build full libva, so why not just use that instead.
>>>>>>>
>>>>>>> You don't seem to be reading mails from openembedded-devel that
>>>>>>> you were cc-ed on.
>>>>>>
>>>>>> don't assume things
>>>>>
>>>>> Understood.
>>>>>
>>>>>>> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I am trying to make us thing if -dev package can be used somehow to
>>>>>> avoid this
>>>>>> or have we exhausted all possibilities.
>>>>>
>>>>> Why is it a problem to exploit sstate.bbclass internals implicitly
>>>>> by using a *-initial package name for an arbitrary package?
>>>>
>>>> it is not a problem, however, it is a work to keep such setup going and
>>>> also it has to be considered always in dependencies etc.
>>>>
>>>>> Surely it's not reserved for libgcc-initial and friends.
>>>>>
>>>>
>>>> they are different usecases, libgcc-initial is a veneer/trampoline used
>>>> to bootstrap toolchain, and that too we want to remove at every
>>>> opportunity we get, we use to have lot of initial recipes and they are
>>>> very few left, so we have to be mindful of adding another one.
>>>>
>>>>> It solves two problems nicely in one go:
>>>>> 1. by using a different package than libva, the libva-vs-mesa
>>>>>     circular dependency is avoided. mesa needs a crippled libva
>>>>> (pkgconfig + headers)
>>>>>     to build its VAAPI state tracker and the VAAPI drivers
>>>>
>>>> I see archlinux using full libva for this. how are other distros doing
>>>> it? is this problem unique to OE
>>>
>>> Fedora also uses the full libva.
>>>
>>> However, the chicken-and-egg circular dependency is broken by history
>>> for these distros.
>>>
>>> Koji and Mock build one package at a time with all their dependencies
>>> already available from the staging package repository and the results
>>> will be eventually uploaded to the same repository.
>>>
>>> Bitbake doesn't have have this loophole to download pre-built dependencies.
>>
>> Also, somewhere on 01.org or in the libva sources the same solution
>> I presented in this patchset is suggested:
>>
>> 1. build libva with --disable-glx (it is needed when Mesa SDK is present)
>>     but it's not needed by not depending on mesa in libva-initial
>> 2. build mesa with libva build in (1) as it only needs the pkgconfig files
>>     and the headers
>> 3. build libva with --enable-glx. It's autodetected, set to on with
>>     depending on mesa in the full libva recipe.
> 
> looking at the nature of the problem, it might be the way to unbreak the catch-22, does 
> anything else needs this bootstrap header package ?

Besides DEPENDS="libdrm", no.

> do we need to ensure that content of libva-dev and the bootstrap packages do not overlap.

I don't think so.
Apparently, the mesa-dev package built from this patchset
doesn't depend on libva-initial-dev and this latter package
doesn't get included into an image either. I guess the
sstate.bbclass internals deal with this properly.


> 
>>
>> Obviusly the same libva recipe can't be used to build mesa that depends on mesa.
>>
> 
> 

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Khem Raj]

On 2/26/20 12:21 PM, Böszörményi Zoltán wrote:
> 2020. 02. 26. 20:44 keltezéssel, Khem Raj írta:
>>
>>
>> On 2/26/20 9:14 AM, Böszörményi Zoltán wrote:
>>> 2020. 02. 26. 18:08 keltezéssel, Böszörményi Zoltán írta:
>>>> 2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:
>>>>>
>>>>>
>>>>> On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:
>>>>>> 2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
>>>>>>> On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán 
>>>>>>> <zboszor@pr.hu> wrote:
>>>>>>>>
>>>>>>>> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
>>>>>>>>> On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor@pr.hu>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
>>>>>>>>>>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
>>>>>>>>>>> Openembedded-core <openembedded-core@lists.openembedded.org> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> The package name exploits sstate.bbclass so it's not added as
>>>>>>>>>>>> implicit dependency to packages.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> what is the use of this recipe and why should it be added to 
>>>>>>>>>>> core ?
>>>>>>>>>>
>>>>>>>>>> I should have added a cover letter, shouldn't I?
>>>>>>>>>> See patch 3/5 in the series for enabling gallium-va in Mesa.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> recipe seems to build full libva, so why not just use that 
>>>>>>>>> instead.
>>>>>>>>
>>>>>>>> You don't seem to be reading mails from openembedded-devel that
>>>>>>>> you were cc-ed on.
>>>>>>>
>>>>>>> don't assume things
>>>>>>
>>>>>> Understood.
>>>>>>
>>>>>>>> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I am trying to make us thing if -dev package can be used somehow to
>>>>>>> avoid this
>>>>>>> or have we exhausted all possibilities.
>>>>>>
>>>>>> Why is it a problem to exploit sstate.bbclass internals implicitly
>>>>>> by using a *-initial package name for an arbitrary package?
>>>>>
>>>>> it is not a problem, however, it is a work to keep such setup going 
>>>>> and
>>>>> also it has to be considered always in dependencies etc.
>>>>>
>>>>>> Surely it's not reserved for libgcc-initial and friends.
>>>>>>
>>>>>
>>>>> they are different usecases, libgcc-initial is a veneer/trampoline 
>>>>> used
>>>>> to bootstrap toolchain, and that too we want to remove at every
>>>>> opportunity we get, we use to have lot of initial recipes and they are
>>>>> very few left, so we have to be mindful of adding another one.
>>>>>
>>>>>> It solves two problems nicely in one go:
>>>>>> 1. by using a different package than libva, the libva-vs-mesa
>>>>>>     circular dependency is avoided. mesa needs a crippled libva
>>>>>> (pkgconfig + headers)
>>>>>>     to build its VAAPI state tracker and the VAAPI drivers
>>>>>
>>>>> I see archlinux using full libva for this. how are other distros doing
>>>>> it? is this problem unique to OE
>>>>
>>>> Fedora also uses the full libva.
>>>>
>>>> However, the chicken-and-egg circular dependency is broken by history
>>>> for these distros.
>>>>
>>>> Koji and Mock build one package at a time with all their dependencies
>>>> already available from the staging package repository and the results
>>>> will be eventually uploaded to the same repository.
>>>>
>>>> Bitbake doesn't have have this loophole to download pre-built 
>>>> dependencies.
>>>
>>> Also, somewhere on 01.org or in the libva sources the same solution
>>> I presented in this patchset is suggested:
>>>
>>> 1. build libva with --disable-glx (it is needed when Mesa SDK is 
>>> present)
>>>     but it's not needed by not depending on mesa in libva-initial
>>> 2. build mesa with libva build in (1) as it only needs the pkgconfig 
>>> files
>>>     and the headers
>>> 3. build libva with --enable-glx. It's autodetected, set to on with
>>>     depending on mesa in the full libva recipe.
>>
>> looking at the nature of the problem, it might be the way to unbreak 
>> the catch-22, does anything else needs this bootstrap header package ?
> 
> Besides DEPENDS="libdrm", no.
> 
>> do we need to ensure that content of libva-dev and the bootstrap 
>> packages do not overlap.
> 
> I don't think so.
> Apparently, the mesa-dev package built from this patchset
> doesn't depend on libva-initial-dev and this latter package
> doesn't get included into an image either. I guess the
> sstate.bbclass internals deal with this properly.
> 

OK, I guess, we should give it a test.

> 
>>
>>>
>>> Obviusly the same libva recipe can't be used to build mesa that 
>>> depends on mesa.
>>>
>>
>>
> 

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

2020. 02. 26. 21:31 keltezéssel, Khem Raj írta:
> 
> 
> On 2/26/20 12:21 PM, Böszörményi Zoltán wrote:
>> 2020. 02. 26. 20:44 keltezéssel, Khem Raj írta:
>>>
>>>
>>> On 2/26/20 9:14 AM, Böszörményi Zoltán wrote:
>>>> 2020. 02. 26. 18:08 keltezéssel, Böszörményi Zoltán írta:
>>>>> 2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:
>>>>>>
>>>>>>
>>>>>> On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:
>>>>>>> 2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
>>>>>>>> On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>>>>>>>>>
>>>>>>>>> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
>>>>>>>>>> On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor@pr.hu>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
>>>>>>>>>>>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
>>>>>>>>>>>> Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> The package name exploits sstate.bbclass so it's not added as
>>>>>>>>>>>>> implicit dependency to packages.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> what is the use of this recipe and why should it be added to core ?
>>>>>>>>>>>
>>>>>>>>>>> I should have added a cover letter, shouldn't I?
>>>>>>>>>>> See patch 3/5 in the series for enabling gallium-va in Mesa.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> recipe seems to build full libva, so why not just use that instead.
>>>>>>>>>
>>>>>>>>> You don't seem to be reading mails from openembedded-devel that
>>>>>>>>> you were cc-ed on.
>>>>>>>>
>>>>>>>> don't assume things
>>>>>>>
>>>>>>> Understood.
>>>>>>>
>>>>>>>>> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I am trying to make us thing if -dev package can be used somehow to
>>>>>>>> avoid this
>>>>>>>> or have we exhausted all possibilities.
>>>>>>>
>>>>>>> Why is it a problem to exploit sstate.bbclass internals implicitly
>>>>>>> by using a *-initial package name for an arbitrary package?
>>>>>>
>>>>>> it is not a problem, however, it is a work to keep such setup going and
>>>>>> also it has to be considered always in dependencies etc.
>>>>>>
>>>>>>> Surely it's not reserved for libgcc-initial and friends.
>>>>>>>
>>>>>>
>>>>>> they are different usecases, libgcc-initial is a veneer/trampoline used
>>>>>> to bootstrap toolchain, and that too we want to remove at every
>>>>>> opportunity we get, we use to have lot of initial recipes and they are
>>>>>> very few left, so we have to be mindful of adding another one.
>>>>>>
>>>>>>> It solves two problems nicely in one go:
>>>>>>> 1. by using a different package than libva, the libva-vs-mesa
>>>>>>>     circular dependency is avoided. mesa needs a crippled libva
>>>>>>> (pkgconfig + headers)
>>>>>>>     to build its VAAPI state tracker and the VAAPI drivers
>>>>>>
>>>>>> I see archlinux using full libva for this. how are other distros doing
>>>>>> it? is this problem unique to OE
>>>>>
>>>>> Fedora also uses the full libva.
>>>>>
>>>>> However, the chicken-and-egg circular dependency is broken by history
>>>>> for these distros.
>>>>>
>>>>> Koji and Mock build one package at a time with all their dependencies
>>>>> already available from the staging package repository and the results
>>>>> will be eventually uploaded to the same repository.
>>>>>
>>>>> Bitbake doesn't have have this loophole to download pre-built dependencies.
>>>>
>>>> Also, somewhere on 01.org or in the libva sources the same solution
>>>> I presented in this patchset is suggested:
>>>>
>>>> 1. build libva with --disable-glx (it is needed when Mesa SDK is present)
>>>>     but it's not needed by not depending on mesa in libva-initial
>>>> 2. build mesa with libva build in (1) as it only needs the pkgconfig files
>>>>     and the headers
>>>> 3. build libva with --enable-glx. It's autodetected, set to on with
>>>>     depending on mesa in the full libva recipe.
>>>
>>> looking at the nature of the problem, it might be the way to unbreak the catch-22, does 
>>> anything else needs this bootstrap header package ?
>>
>> Besides DEPENDS="libdrm", no.

Sorry, I misread the question, it was too late after a workday.
Nothing else uses this bootstrap package just Mesa.

>>
>>> do we need to ensure that content of libva-dev and the bootstrap packages do not overlap.
>>
>> I don't think so.
>> Apparently, the mesa-dev package built from this patchset
>> doesn't depend on libva-initial-dev and this latter package
>> doesn't get included into an image either. I guess the
>> sstate.bbclass internals deal with this properly.
>>
> 
> OK, I guess, we should give it a test.
> 
>>
>>>
>>>>
>>>> Obviusly the same libva recipe can't be used to build mesa that depends on mesa.
>>>>
>>>
>>>
>>

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]

The 'circular dependency' thing must be explained in the commits, and not
in a discussion link to some email elsewhere.

I still don't get why this is needed. The -initial recipe is identical to
the eventual 'real' recipe, so where is the circularity coming from?

Alex

On Wed, 26 Feb 2020 at 15:05, Böszörményi Zoltán via Openembedded-core <
openembedded-core@lists.openembedded.org> wrote:

> The package name exploits sstate.bbclass so it's not added as
> implicit dependency to packages.
>
> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
> ---
>  meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>  meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
>  2 files changed, 8 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>
> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
> b/meta/recipes-graphics/libva/libva-2.6.1.inc
> index ca1386d80b..5b1cdee7e3 100644
> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> @@ -17,10 +17,12 @@ SECTION = "x11"
>  LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>
> -SRC_URI = "
> https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
> +SRC_URI = "
> https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2
> "
>  SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>  SRC_URI[sha256sum] =
> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>
> +S = "${WORKDIR}/libva-${PV}"
> +
>  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>
>  DEPENDS = "libdrm"
> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> new file mode 100644
> index 0000000000..828ef6fbca
> --- /dev/null
> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> @@ -0,0 +1,5 @@
> +require libva-${PV}.inc
> +
> +do_install_append () {
> +       rm -f ${D}${libdir}/*.so*
> +}
> --
> 2.24.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 3855 bytes --]

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

2020. 02. 26. 17:12 keltezéssel, Alexander Kanavin írta:
> The 'circular dependency' thing must be explained in the commits, and not in a discussion 
> link to some email elsewhere.
> 
> I still don't get why this is needed. The -initial recipe is identical to the eventual 
> 'real' recipe, so where is the circularity coming from?

libva -> mesa -> libva

> 
> Alex
> 
> On Wed, 26 Feb 2020 at 15:05, Böszörményi Zoltán via Openembedded-core 
> <openembedded-core@lists.openembedded.org 
> <mailto:openembedded-core@lists.openembedded.org>> wrote:
> 
>     The package name exploits sstate.bbclass so it's not added as
>     implicit dependency to packages.
> 
>     Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu <mailto:zboszor@pr.hu>>
>     ---
>       meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>       meta/recipes-graphics/libva/libva-initial_2.6.1.bb <http://libva-initial_2.6.1.bb> |
>     5 +++++
>       2 files changed, 8 insertions(+), 1 deletion(-)
>       create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>     <http://libva-initial_2.6.1.bb>
> 
>     diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
>     b/meta/recipes-graphics/libva/libva-2.6.1.inc
>     index ca1386d80b..5b1cdee7e3 100644
>     --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>     +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>     @@ -17,10 +17,12 @@ SECTION = "x11"
>       LICENSE = "MIT"
>       LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
> 
>     -SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2
>     <https://github.com/intel/$%7BBPN%7D/releases/download/$%7BPV%7D/$%7BBP%7D.tar.bz2>"
>     +SRC_URI = "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2
>     <https://github.com/intel/libva/releases/download/$%7BPV%7D/libva-$%7BPV%7D.tar.bz2>"
>       SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>       SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
> 
>     +S = "${WORKDIR}/libva-${PV}"
>     +
>       UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
> 
>       DEPENDS = "libdrm"
>     diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>     <http://libva-initial_2.6.1.bb> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>     <http://libva-initial_2.6.1.bb>
>     new file mode 100644
>     index 0000000000..828ef6fbca
>     --- /dev/null
>     +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb <http://libva-initial_2.6.1.bb>
>     @@ -0,0 +1,5 @@
>     +require libva-${PV}.inc
>     +
>     +do_install_append () {
>     +       rm -f ${D}${libdir}/*.so*
>     +}
>     -- 
>     2.24.1
> 
>     -- 
>     _______________________________________________
>     Openembedded-core mailing list
>     Openembedded-core@lists.openembedded.org <mailto:Openembedded-core@lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

2020. 02. 26. 17:35 keltezéssel, Böszörményi Zoltán via Openembedded-core írta:
> 2020. 02. 26. 17:12 keltezéssel, Alexander Kanavin írta:
>> The 'circular dependency' thing must be explained in the commits, and not in a 
>> discussion link to some email elsewhere.
>>
>> I still don't get why this is needed. The -initial recipe is identical to the eventual 
>> 'real' recipe, so where is the circularity coming from?
> 
> libva -> mesa -> libva

And the -initial recipe is NOT identical to the real one.
The real one always had DEPENDS = "virtual/mesa"

> 
>>
>> Alex
>>
>> On Wed, 26 Feb 2020 at 15:05, Böszörményi Zoltán via Openembedded-core 
>> <openembedded-core@lists.openembedded.org 
>> <mailto:openembedded-core@lists.openembedded.org>> wrote:
>>
>>     The package name exploits sstate.bbclass so it's not added as
>>     implicit dependency to packages.
>>
>>     Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu <mailto:zboszor@pr.hu>>
>>     ---
>>       meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>>       meta/recipes-graphics/libva/libva-initial_2.6.1.bb <http://libva-initial_2.6.1.bb> |
>>     5 +++++
>>       2 files changed, 8 insertions(+), 1 deletion(-)
>>       create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>     <http://libva-initial_2.6.1.bb>
>>
>>     diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>     b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>     index ca1386d80b..5b1cdee7e3 100644
>>     --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>     +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>     @@ -17,10 +17,12 @@ SECTION = "x11"
>>       LICENSE = "MIT"
>>       LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>>
>>     -SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2
>>     <https://github.com/intel/$%7BBPN%7D/releases/download/$%7BPV%7D/$%7BBP%7D.tar.bz2>"
>>     +SRC_URI = "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2
>>     <https://github.com/intel/libva/releases/download/$%7BPV%7D/libva-$%7BPV%7D.tar.bz2>"
>>       SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>>       SRC_URI[sha256sum] = 
>> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>>
>>     +S = "${WORKDIR}/libva-${PV}"
>>     +
>>       UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>>
>>       DEPENDS = "libdrm"
>>     diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>     <http://libva-initial_2.6.1.bb> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>     <http://libva-initial_2.6.1.bb>
>>     new file mode 100644
>>     index 0000000000..828ef6fbca
>>     --- /dev/null
>>     +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
>> <http://libva-initial_2.6.1.bb>
>>     @@ -0,0 +1,5 @@
>>     +require libva-${PV}.inc
>>     +
>>     +do_install_append () {
>>     +       rm -f ${D}${libdir}/*.so*
>>     +}
>>     --     2.24.1
>>
>>     --     _______________________________________________
>>     Openembedded-core mailing list
>>     Openembedded-core@lists.openembedded.org 
>> <mailto:Openembedded-core@lists.openembedded.org>
>>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
> 

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 3762 bytes --]

Right, then I am okay with this, as long as there are proper commit
messages, and no version in .inc filename.

Alex

On Wed, 26 Feb 2020 at 17:37, Böszörményi Zoltán <zboszor@pr.hu> wrote:

> 2020. 02. 26. 17:35 keltezéssel, Böszörményi Zoltán via Openembedded-core
> írta:
> > 2020. 02. 26. 17:12 keltezéssel, Alexander Kanavin írta:
> >> The 'circular dependency' thing must be explained in the commits, and
> not in a
> >> discussion link to some email elsewhere.
> >>
> >> I still don't get why this is needed. The -initial recipe is identical
> to the eventual
> >> 'real' recipe, so where is the circularity coming from?
> >
> > libva -> mesa -> libva
>
> And the -initial recipe is NOT identical to the real one.
> The real one always had DEPENDS = "virtual/mesa"
>
> >
> >>
> >> Alex
> >>
> >> On Wed, 26 Feb 2020 at 15:05, Böszörményi Zoltán via Openembedded-core
> >> <openembedded-core@lists.openembedded.org
> >> <mailto:openembedded-core@lists.openembedded.org>> wrote:
> >>
> >>     The package name exploits sstate.bbclass so it's not added as
> >>     implicit dependency to packages.
> >>
> >>     Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu <mailto:
> zboszor@pr.hu>>
> >>     ---
> >>       meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
> >>       meta/recipes-graphics/libva/libva-initial_2.6.1.bb <
> http://libva-initial_2.6.1.bb> |
> >>     5 +++++
> >>       2 files changed, 8 insertions(+), 1 deletion(-)
> >>       create mode 100644 meta/recipes-graphics/libva/
> libva-initial_2.6.1.bb
> >>     <http://libva-initial_2.6.1.bb>
> >>
> >>     diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
> >>     b/meta/recipes-graphics/libva/libva-2.6.1.inc
> >>     index ca1386d80b..5b1cdee7e3 100644
> >>     --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
> >>     +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> >>     @@ -17,10 +17,12 @@ SECTION = "x11"
> >>       LICENSE = "MIT"
> >>       LIC_FILES_CHKSUM =
> "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
> >>
> >>     -SRC_URI = "
> https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2
> >>     <
> https://github.com/intel/$%7BBPN%7D/releases/download/$%7BPV%7D/$%7BBP%7D.tar.bz2
> >"
> >>     +SRC_URI = "
> https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2
> >>     <
> https://github.com/intel/libva/releases/download/$%7BPV%7D/libva-$%7BPV%7D.tar.bz2
> >"
> >>       SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
> >>       SRC_URI[sha256sum] =
> >> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
> >>
> >>     +S = "${WORKDIR}/libva-${PV}"
> >>     +
> >>       UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
> >>
> >>       DEPENDS = "libdrm"
> >>     diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >>     <http://libva-initial_2.6.1.bb> b/meta/recipes-graphics/libva/
> libva-initial_2.6.1.bb
> >>     <http://libva-initial_2.6.1.bb>
> >>     new file mode 100644
> >>     index 0000000000..828ef6fbca
> >>     --- /dev/null
> >>     +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >> <http://libva-initial_2.6.1.bb>
> >>     @@ -0,0 +1,5 @@
> >>     +require libva-${PV}.inc
> >>     +
> >>     +do_install_append () {
> >>     +       rm -f ${D}${libdir}/*.so*
> >>     +}
> >>     --     2.24.1
> >>
> >>     --     _______________________________________________
> >>     Openembedded-core mailing list
> >>     Openembedded-core@lists.openembedded.org
> >> <mailto:Openembedded-core@lists.openembedded.org>
> >>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>
> >
>
>

[-- Attachment #2: Type: text/html, Size: 6891 bytes --]

Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán]

2020. 02. 26. 18:16 keltezéssel, Alexander Kanavin írta:
> Right, then I am okay with this, as long as there are proper commit messages, and no 
> version in .inc filename.
> 
> Alex

Thank you, I'll send a v2 patchset with proper commit messages and a cover mail tomorrow.

> 
> On Wed, 26 Feb 2020 at 17:37, Böszörményi Zoltán <zboszor@pr.hu <mailto:zboszor@pr.hu>> wrote:
> 
>     2020. 02. 26. 17:35 keltezéssel, Böszörményi Zoltán via Openembedded-core írta:
>      > 2020. 02. 26. 17:12 keltezéssel, Alexander Kanavin írta:
>      >> The 'circular dependency' thing must be explained in the commits, and not in a
>      >> discussion link to some email elsewhere.
>      >>
>      >> I still don't get why this is needed. The -initial recipe is identical to the
>     eventual
>      >> 'real' recipe, so where is the circularity coming from?
>      >
>      > libva -> mesa -> libva
> 
>     And the -initial recipe is NOT identical to the real one.
>     The real one always had DEPENDS = "virtual/mesa"
> 
>      >
>      >>
>      >> Alex
>      >>
>      >> On Wed, 26 Feb 2020 at 15:05, Böszörményi Zoltán via Openembedded-core
>      >> <openembedded-core@lists.openembedded.org
>     <mailto:openembedded-core@lists.openembedded.org>
>      >> <mailto:openembedded-core@lists.openembedded.org
>     <mailto:openembedded-core@lists.openembedded.org>>> wrote:
>      >>
>      >>     The package name exploits sstate.bbclass so it's not added as
>      >>     implicit dependency to packages.
>      >>
>      >>     Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu <mailto:zboszor@pr.hu>
>     <mailto:zboszor@pr.hu <mailto:zboszor@pr.hu>>>
>      >>     ---
>      >>       meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>      >>       meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>     <http://libva-initial_2.6.1.bb> <http://libva-initial_2.6.1.bb> |
>      >>     5 +++++
>      >>       2 files changed, 8 insertions(+), 1 deletion(-)
>      >>       create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>     <http://libva-initial_2.6.1.bb>
>      >>     <http://libva-initial_2.6.1.bb>
>      >>
>      >>     diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
>      >>     b/meta/recipes-graphics/libva/libva-2.6.1.inc
>      >>     index ca1386d80b..5b1cdee7e3 100644
>      >>     --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>      >>     +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>      >>     @@ -17,10 +17,12 @@ SECTION = "x11"
>      >>       LICENSE = "MIT"
>      >>       LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>      >>
>      >>     -SRC_URI =
>     "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2
>     <https://github.com/intel/$%7BBPN%7D/releases/download/$%7BPV%7D/$%7BBP%7D.tar.bz2>
>      >>    
>     <https://github.com/intel/$%7BBPN%7D/releases/download/$%7BPV%7D/$%7BBP%7D.tar.bz2>"
>      >>     +SRC_URI =
>     "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2
>     <https://github.com/intel/libva/releases/download/$%7BPV%7D/libva-$%7BPV%7D.tar.bz2>
>      >>    
>     <https://github.com/intel/libva/releases/download/$%7BPV%7D/libva-$%7BPV%7D.tar.bz2>"
>      >>       SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>      >>       SRC_URI[sha256sum] =
>      >> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>      >>
>      >>     +S = "${WORKDIR}/libva-${PV}"
>      >>     +
>      >>       UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>      >>
>      >>       DEPENDS = "libdrm"
>      >>     diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>     <http://libva-initial_2.6.1.bb>
>      >>     <http://libva-initial_2.6.1.bb>
>     b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb <http://libva-initial_2.6.1.bb>
>      >>     <http://libva-initial_2.6.1.bb>
>      >>     new file mode 100644
>      >>     index 0000000000..828ef6fbca
>      >>     --- /dev/null
>      >>     +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>     <http://libva-initial_2.6.1.bb>
>      >> <http://libva-initial_2.6.1.bb>
>      >>     @@ -0,0 +1,5 @@
>      >>     +require libva-${PV}.inc
>      >>     +
>      >>     +do_install_append () {
>      >>     +       rm -f ${D}${libdir}/*.so*
>      >>     +}
>      >>     --     2.24.1
>      >>
>      >>     --     _______________________________________________
>      >>     Openembedded-core mailing list
>      >> Openembedded-core@lists.openembedded.org
>     <mailto:Openembedded-core@lists.openembedded.org>
>      >> <mailto:Openembedded-core@lists.openembedded.org
>     <mailto:Openembedded-core@lists.openembedded.org>>
>      >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>      >>
>      >
> 

[PATCH 3/5] mesa: Add PACKAGECONFIG knob to enable VAAPI state tracker and drivers

[Böszörményi Zoltán]

Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
---
 meta/recipes-graphics/mesa/mesa.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 87f167c507..479d3223fa 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -142,6 +142,7 @@ PACKAGECONFIG[gallium] = "-Dgallium-drivers=${GALLIUMDRIVERS}, -Dgallium-drivers
 PACKAGECONFIG[gallium-llvm] = "-Dllvm=true -Dshared-llvm=true, -Dllvm=false, llvm${MESA_LLVM_RELEASE} llvm-native \
                                ${@'elfutils' if ${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
 PACKAGECONFIG[xa]  = "-Dgallium-xa=true, -Dgallium-xa=false"
+PACKAGECONFIG[va] = "-Dgallium-va=true,-Dgallium-va=false,libva-initial"
 
 PACKAGECONFIG[lima] = ""
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima', '', d)}"
-- 
2.24.1

[PATCH 4/5] mesa: Add PACKAGECONFIG knob to enable VDPAU state tracker and drivers

[Böszörményi Zoltán]

Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
---
 meta/recipes-graphics/mesa/mesa.inc | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 479d3223fa..800e8813c7 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -144,6 +144,8 @@ PACKAGECONFIG[gallium-llvm] = "-Dllvm=true -Dshared-llvm=true, -Dllvm=false, llv
 PACKAGECONFIG[xa]  = "-Dgallium-xa=true, -Dgallium-xa=false"
 PACKAGECONFIG[va] = "-Dgallium-va=true,-Dgallium-va=false,libva-initial"
 
+PACKAGECONFIG[vdpau] = "-Dgallium-vdpau=true,-Dgallium-vdpau=false,libvdpau"
+
 PACKAGECONFIG[lima] = ""
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima', '', d)}"
 
@@ -179,6 +181,7 @@ PACKAGES =+ "libegl-mesa libegl-mesa-dev \
              libgles3-mesa libgles3-mesa-dev \
              libxatracker libxatracker-dev \
              mesa-megadriver mesa-vulkan-drivers \
+             mesa-vdpau-drivers \
             "
 
 do_install_append () {
@@ -256,6 +259,7 @@ PACKAGES_DYNAMIC += "^mesa-driver-.*"
 
 FILES_mesa-megadriver = "${libdir}/dri/* ${datadir}/drirc.d/00-mesa-defaults.conf"
 FILES_mesa-vulkan-drivers = "${libdir}/libvulkan_*.so ${datadir}/vulkan"
+FILES_${PN}-vdpau-drivers = "${libdir}/vdpau/*.so.*"
 FILES_libegl-mesa = "${libdir}/libEGL.so.*"
 FILES_libgbm = "${libdir}/libgbm.so.*"
 FILES_libgles1-mesa = "${libdir}/libGLESv1*.so.*"
@@ -265,7 +269,7 @@ FILES_libglapi = "${libdir}/libglapi.so.*"
 FILES_libosmesa = "${libdir}/libOSMesa.so.*"
 FILES_libxatracker = "${libdir}/libxatracker.so.*"
 
-FILES_${PN}-dev = "${libdir}/pkgconfig/dri.pc ${includedir}/vulkan"
+FILES_${PN}-dev = "${libdir}/pkgconfig/dri.pc ${includedir}/vulkan ${libdir}/vdpau/*.so"
 FILES_libegl-mesa-dev = "${libdir}/libEGL.* ${includedir}/EGL ${includedir}/KHR ${libdir}/pkgconfig/egl.pc"
 FILES_libgbm-dev = "${libdir}/libgbm.* ${libdir}/pkgconfig/gbm.pc ${includedir}/gbm.h"
 FILES_libgl-mesa-dev = "${libdir}/libGL.* ${includedir}/GL ${libdir}/pkgconfig/gl.pc"
-- 
2.24.1

[RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"

[Böszörményi Zoltán]

When meta-clang is used, for example to build chromium-x11 from
meta-browser, a linker error occurs in Zeus.

See: https://gitlab.freedesktop.org/mesa/mesa/issues/2533

Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
---
 meta/recipes-graphics/mesa/mesa.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 800e8813c7..b8f09a2ed3 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -24,6 +24,8 @@ PROVIDES = " \
     virtual/mesa \
     "
 
+TOOLCHAIN = "gcc"
+
 inherit meson pkgconfig python3native gettext features_check
 
 # Unset these to stop python trying to report the target Python setup
-- 
2.24.1

Re: [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"

[Khem Raj]

On Wed, Feb 26, 2020 at 6:08 AM Böszörményi Zoltán via
Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>
> When meta-clang is used, for example to build chromium-x11 from
> meta-browser, a linker error occurs in Zeus.
>
> See: https://gitlab.freedesktop.org/mesa/mesa/issues/2533
>
> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
> ---
>  meta/recipes-graphics/mesa/mesa.inc | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
> index 800e8813c7..b8f09a2ed3 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -24,6 +24,8 @@ PROVIDES = " \
>      virtual/mesa \
>      "
>
> +TOOLCHAIN = "gcc"

lets fix the linker error instead.

> +
>  inherit meson pkgconfig python3native gettext features_check
>
>  # Unset these to stop python trying to report the target Python setup
> --
> 2.24.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"

[Böszörményi Zoltán]

2020. 02. 26. 16:00 keltezéssel, Khem Raj írta:
> On Wed, Feb 26, 2020 at 6:08 AM Böszörményi Zoltán via
> Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>>
>> When meta-clang is used, for example to build chromium-x11 from
>> meta-browser, a linker error occurs in Zeus.
>>
>> See: https://gitlab.freedesktop.org/mesa/mesa/issues/2533
>>
>> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
>> ---
>>   meta/recipes-graphics/mesa/mesa.inc | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
>> index 800e8813c7..b8f09a2ed3 100644
>> --- a/meta/recipes-graphics/mesa/mesa.inc
>> +++ b/meta/recipes-graphics/mesa/mesa.inc
>> @@ -24,6 +24,8 @@ PROVIDES = " \
>>       virtual/mesa \
>>       "
>>
>> +TOOLCHAIN = "gcc"
> 
> lets fix the linker error instead.

The linker errors were similar to reports I found on some forums
from a couple of years ago and they all pointed to RTTI needed
to be enabled in LLVM/CLANG. But it didn't help.

This is a good workaround until meta-clang is fixed to build Mesa.

> 
>> +
>>   inherit meson pkgconfig python3native gettext features_check
>>
>>   # Unset these to stop python trying to report the target Python setup
>> --
>> 2.24.1
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"

[Khem Raj]

On Wed, Feb 26, 2020 at 7:14 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>
> 2020. 02. 26. 16:00 keltezéssel, Khem Raj írta:
> > On Wed, Feb 26, 2020 at 6:08 AM Böszörményi Zoltán via
> > Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
> >>
> >> When meta-clang is used, for example to build chromium-x11 from
> >> meta-browser, a linker error occurs in Zeus.
> >>
> >> See: https://gitlab.freedesktop.org/mesa/mesa/issues/2533
> >>
> >> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
> >> ---
> >>   meta/recipes-graphics/mesa/mesa.inc | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
> >> index 800e8813c7..b8f09a2ed3 100644
> >> --- a/meta/recipes-graphics/mesa/mesa.inc
> >> +++ b/meta/recipes-graphics/mesa/mesa.inc
> >> @@ -24,6 +24,8 @@ PROVIDES = " \
> >>       virtual/mesa \
> >>       "
> >>
> >> +TOOLCHAIN = "gcc"
> >
> > lets fix the linker error instead.
>
> The linker errors were similar to reports I found on some forums
> from a couple of years ago and they all pointed to RTTI needed
> to be enabled in LLVM/CLANG. But it didn't help.
>
> This is a good workaround until meta-clang is fixed to build Mesa.
>

workaround  is needed to be applied in meta-clang not in core

> >
> >> +
> >>   inherit meson pkgconfig python3native gettext features_check
> >>
> >>   # Unset these to stop python trying to report the target Python setup
> >> --
> >> 2.24.1
> >>
> >> --
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"

[Böszörményi Zoltán]

2020. 02. 26. 16:15 keltezéssel, Khem Raj írta:
> On Wed, Feb 26, 2020 at 7:14 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>>
>> 2020. 02. 26. 16:00 keltezéssel, Khem Raj írta:
>>> On Wed, Feb 26, 2020 at 6:08 AM Böszörményi Zoltán via
>>> Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
>>>>
>>>> When meta-clang is used, for example to build chromium-x11 from
>>>> meta-browser, a linker error occurs in Zeus.
>>>>
>>>> See: https://gitlab.freedesktop.org/mesa/mesa/issues/2533
>>>>
>>>> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
>>>> ---
>>>>    meta/recipes-graphics/mesa/mesa.inc | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
>>>> index 800e8813c7..b8f09a2ed3 100644
>>>> --- a/meta/recipes-graphics/mesa/mesa.inc
>>>> +++ b/meta/recipes-graphics/mesa/mesa.inc
>>>> @@ -24,6 +24,8 @@ PROVIDES = " \
>>>>        virtual/mesa \
>>>>        "
>>>>
>>>> +TOOLCHAIN = "gcc"
>>>
>>> lets fix the linker error instead.
>>
>> The linker errors were similar to reports I found on some forums
>> from a couple of years ago and they all pointed to RTTI needed
>> to be enabled in LLVM/CLANG. But it didn't help.
>>
>> This is a good workaround until meta-clang is fixed to build Mesa.
>>
> 
> workaround  is needed to be applied in meta-clang not in core

This is why this patch has RFC in the title.
I'll send another patch against meta-clang.

> 
>>>
>>>> +
>>>>    inherit meson pkgconfig python3native gettext features_check
>>>>
>>>>    # Unset these to stop python trying to report the target Python setup
>>>> --
>>>> 2.24.1
>>>>
>>>> --
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>

Re: [PATCH 1/5] libva: Split out the base parts into an include file

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 4356 bytes --]

Don't version the .inc please, this will break automated version updates.

Alex

On Wed, 26 Feb 2020 at 15:08, Böszörményi Zoltán via Openembedded-core <
openembedded-core@lists.openembedded.org> wrote:

> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
> ---
>  meta/recipes-graphics/libva/libva-2.6.1.inc | 30 ++++++++++++++++++++
>  meta/recipes-graphics/libva/libva_2.6.1.bb  | 31 ++-------------------
>  2 files changed, 32 insertions(+), 29 deletions(-)
>  create mode 100644 meta/recipes-graphics/libva/libva-2.6.1.inc
>
> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
> b/meta/recipes-graphics/libva/libva-2.6.1.inc
> new file mode 100644
> index 0000000000..ca1386d80b
> --- /dev/null
> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> @@ -0,0 +1,30 @@
> +SUMMARY = "Video Acceleration (VA) API for Linux"
> +DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
> +and API specification which enables and provides access to graphics \
> +hardware (GPU) acceleration for video processing on Linux and UNIX \
> +based operating systems. Accelerated processing includes video \
> +decoding, video encoding, subpicture blending and rendering. The \
> +specification was originally designed by Intel for its GMA (Graphics \
> +Media Accelerator) series of GPU hardware, the API is however not \
> +limited to GPUs or Intel specific hardware, as other hardware and \
> +manufacturers can also freely use this API for hardware accelerated \
> +video decoding."
> +
> +HOMEPAGE = "https://01.org/linuxmedia/vaapi"
> +BUGTRACKER = "https://github.com/intel/libva/issues"
> +
> +SECTION = "x11"
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
> +
> +SRC_URI = "
> https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
> +SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
> +SRC_URI[sha256sum] =
> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
> +
> +UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
> +
> +DEPENDS = "libdrm"
> +
> +inherit meson pkgconfig features_check
> +
> +REQUIRED_DISTRO_FEATURES = "opengl"
> diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb
> b/meta/recipes-graphics/libva/libva_2.6.1.bb
> index 92cea83bc1..af4c1c98ab 100644
> --- a/meta/recipes-graphics/libva/libva_2.6.1.bb
> +++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
> @@ -1,33 +1,6 @@
> -SUMMARY = "Video Acceleration (VA) API for Linux"
> -DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
> -and API specification which enables and provides access to graphics \
> -hardware (GPU) acceleration for video processing on Linux and UNIX \
> -based operating systems. Accelerated processing includes video \
> -decoding, video encoding, subpicture blending and rendering. The \
> -specification was originally designed by Intel for its GMA (Graphics \
> -Media Accelerator) series of GPU hardware, the API is however not \
> -limited to GPUs or Intel specific hardware, as other hardware and \
> -manufacturers can also freely use this API for hardware accelerated \
> -video decoding."
> +require libva-${PV}.inc
>
> -HOMEPAGE = "https://01.org/linuxmedia/vaapi"
> -BUGTRACKER = "https://github.com/intel/libva/issues"
> -
> -SECTION = "x11"
> -LICENSE = "MIT"
> -LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
> -
> -SRC_URI = "
> https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
> -SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
> -SRC_URI[sha256sum] =
> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
> -
> -UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
> -
> -DEPENDS = "libdrm virtual/mesa"
> -
> -inherit meson pkgconfig features_check
> -
> -REQUIRED_DISTRO_FEATURES = "opengl"
> +DEPENDS += "virtual/mesa"
>
>  PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11',
> d)}"
>  PACKAGECONFIG[x11] = "-Dwith_x11=yes, -Dwith_x11=no,virtual/libx11
> libxext libxfixes"
> --
> 2.24.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 6515 bytes --]