* [PATCH 1/5] libva: Split out the base parts into an include file
@ 2020-02-26 13:57 Böszörményi Zoltán
2020-02-26 13:57 ` [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers Böszörményi Zoltán
` (4 more replies)
0 siblings, 5 replies; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 13:57 UTC (permalink / raw)
To: openembedded-core
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
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 13:57 [PATCH 1/5] libva: Split out the base parts into an include file Böszörményi Zoltán
@ 2020-02-26 13:57 ` Böszörményi Zoltán
2020-02-26 14:13 ` Paul Barker
` (2 more replies)
2020-02-26 13:57 ` [PATCH 3/5] mesa: Add PACKAGECONFIG knob to enable VAAPI state tracker and drivers Böszörményi Zoltán
` (3 subsequent siblings)
4 siblings, 3 replies; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 13:57 UTC (permalink / raw)
To: openembedded-core
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
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [PATCH 3/5] mesa: Add PACKAGECONFIG knob to enable VAAPI state tracker and drivers
2020-02-26 13:57 [PATCH 1/5] libva: Split out the base parts into an include file Böszörményi Zoltán
2020-02-26 13:57 ` [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers Böszörményi Zoltán
@ 2020-02-26 13:57 ` Böszörményi Zoltán
2020-02-26 13:57 ` [PATCH 4/5] mesa: Add PACKAGECONFIG knob to enable VDPAU " Böszörményi Zoltán
` (2 subsequent siblings)
4 siblings, 0 replies; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 13:57 UTC (permalink / raw)
To: openembedded-core
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
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [PATCH 4/5] mesa: Add PACKAGECONFIG knob to enable VDPAU state tracker and drivers
2020-02-26 13:57 [PATCH 1/5] libva: Split out the base parts into an include file Böszörményi Zoltán
2020-02-26 13:57 ` [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers Böszörményi Zoltán
2020-02-26 13:57 ` [PATCH 3/5] mesa: Add PACKAGECONFIG knob to enable VAAPI state tracker and drivers Böszörményi Zoltán
@ 2020-02-26 13:57 ` Böszörményi Zoltán
2020-02-26 13:57 ` [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc" Böszörményi Zoltán
2020-02-26 16:08 ` [PATCH 1/5] libva: Split out the base parts into an include file Alexander Kanavin
4 siblings, 0 replies; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 13:57 UTC (permalink / raw)
To: openembedded-core
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
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"
2020-02-26 13:57 [PATCH 1/5] libva: Split out the base parts into an include file Böszörményi Zoltán
` (2 preceding siblings ...)
2020-02-26 13:57 ` [PATCH 4/5] mesa: Add PACKAGECONFIG knob to enable VDPAU " Böszörményi Zoltán
@ 2020-02-26 13:57 ` Böszörményi Zoltán
2020-02-26 15:00 ` Khem Raj
2020-02-26 16:08 ` [PATCH 1/5] libva: Split out the base parts into an include file Alexander Kanavin
4 siblings, 1 reply; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 13:57 UTC (permalink / raw)
To: openembedded-core
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
^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 13:57 ` [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers Böszörményi Zoltán
@ 2020-02-26 14:13 ` Paul Barker
2020-02-26 14:22 ` Böszörményi Zoltán
2020-02-26 14:58 ` Khem Raj
2020-02-26 16:12 ` Alexander Kanavin
2 siblings, 1 reply; 31+ messages in thread
From: Paul Barker @ 2020-02-26 14:13 UTC (permalink / raw)
To: Böszörményi Zoltán; +Cc: openembedded-core
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?
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 14:13 ` Paul Barker
@ 2020-02-26 14:22 ` Böszörményi Zoltán
0 siblings, 0 replies; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 14:22 UTC (permalink / raw)
To: Paul Barker; +Cc: openembedded-core
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 13:57 ` [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers Böszörményi Zoltán
2020-02-26 14:13 ` Paul Barker
@ 2020-02-26 14:58 ` Khem Raj
2020-02-26 15:12 ` Böszörményi Zoltán
2020-02-26 16:12 ` Alexander Kanavin
2 siblings, 1 reply; 31+ messages in thread
From: Khem Raj @ 2020-02-26 14:58 UTC (permalink / raw)
To: Böszörményi Zoltán
Cc: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"
2020-02-26 13:57 ` [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc" Böszörményi Zoltán
@ 2020-02-26 15:00 ` Khem Raj
2020-02-26 15:14 ` Böszörményi Zoltán
0 siblings, 1 reply; 31+ messages in thread
From: Khem Raj @ 2020-02-26 15:00 UTC (permalink / raw)
To: Böszörményi Zoltán
Cc: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 14:58 ` Khem Raj
@ 2020-02-26 15:12 ` Böszörményi Zoltán
2020-02-26 15:13 ` Khem Raj
0 siblings, 1 reply; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 15:12 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 15:12 ` Böszörményi Zoltán
@ 2020-02-26 15:13 ` Khem Raj
2020-02-26 15:20 ` Böszörményi Zoltán
0 siblings, 1 reply; 31+ messages in thread
From: Khem Raj @ 2020-02-26 15:13 UTC (permalink / raw)
To: Böszörményi Zoltán
Cc: Patches and discussions about the oe-core layer
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
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"
2020-02-26 15:00 ` Khem Raj
@ 2020-02-26 15:14 ` Böszörményi Zoltán
2020-02-26 15:15 ` Khem Raj
0 siblings, 1 reply; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 15:14 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"
2020-02-26 15:14 ` Böszörményi Zoltán
@ 2020-02-26 15:15 ` Khem Raj
2020-02-26 16:02 ` Böszörményi Zoltán
0 siblings, 1 reply; 31+ messages in thread
From: Khem Raj @ 2020-02-26 15:15 UTC (permalink / raw)
To: Böszörményi Zoltán
Cc: Patches and discussions about the oe-core layer
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
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 15:13 ` Khem Raj
@ 2020-02-26 15:20 ` Böszörményi Zoltán
2020-02-26 15:26 ` Böszörményi Zoltán
2020-02-26 15:30 ` Khem Raj
0 siblings, 2 replies; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 15:20 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
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
>>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 15:20 ` Böszörményi Zoltán
@ 2020-02-26 15:26 ` Böszörményi Zoltán
2020-02-26 15:30 ` Khem Raj
1 sibling, 0 replies; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 15:26 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
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
>>>
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 15:20 ` Böszörményi Zoltán
2020-02-26 15:26 ` Böszörményi Zoltán
@ 2020-02-26 15:30 ` Khem Raj
2020-02-26 15:58 ` Böszörményi Zoltán
1 sibling, 1 reply; 31+ messages in thread
From: Khem Raj @ 2020-02-26 15:30 UTC (permalink / raw)
To: Böszörményi Zoltán
Cc: Patches and discussions about the oe-core layer
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
> >>
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 15:30 ` Khem Raj
@ 2020-02-26 15:58 ` Böszörményi Zoltán
2020-02-26 16:51 ` Khem Raj
0 siblings, 1 reply; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 15:58 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
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
>>>>
>>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"
2020-02-26 15:15 ` Khem Raj
@ 2020-02-26 16:02 ` Böszörményi Zoltán
0 siblings, 0 replies; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 16:02 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
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
>>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 1/5] libva: Split out the base parts into an include file
2020-02-26 13:57 [PATCH 1/5] libva: Split out the base parts into an include file Böszörményi Zoltán
` (3 preceding siblings ...)
2020-02-26 13:57 ` [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc" Böszörményi Zoltán
@ 2020-02-26 16:08 ` Alexander Kanavin
4 siblings, 0 replies; 31+ messages in thread
From: Alexander Kanavin @ 2020-02-26 16:08 UTC (permalink / raw)
To: Böszörményi Zoltán; +Cc: OE-core
[-- 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 --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 13:57 ` [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers Böszörményi Zoltán
2020-02-26 14:13 ` Paul Barker
2020-02-26 14:58 ` Khem Raj
@ 2020-02-26 16:12 ` Alexander Kanavin
2020-02-26 16:35 ` Böszörményi Zoltán
2 siblings, 1 reply; 31+ messages in thread
From: Alexander Kanavin @ 2020-02-26 16:12 UTC (permalink / raw)
To: Böszörményi Zoltán; +Cc: OE-core
[-- 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 --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 16:12 ` Alexander Kanavin
@ 2020-02-26 16:35 ` Böszörményi Zoltán
2020-02-26 16:37 ` Böszörményi Zoltán
0 siblings, 1 reply; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 16:35 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: OE-core
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
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 16:35 ` Böszörményi Zoltán
@ 2020-02-26 16:37 ` Böszörményi Zoltán
2020-02-26 17:16 ` Alexander Kanavin
0 siblings, 1 reply; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 16:37 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: OE-core
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
>>
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 15:58 ` Böszörményi Zoltán
@ 2020-02-26 16:51 ` Khem Raj
2020-02-26 17:08 ` Böszörményi Zoltán
0 siblings, 1 reply; 31+ messages in thread
From: Khem Raj @ 2020-02-26 16:51 UTC (permalink / raw)
To: Böszörményi Zoltán
Cc: Patches and discussions about the oe-core layer
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
>>>>>
>>>
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 16:51 ` Khem Raj
@ 2020-02-26 17:08 ` Böszörményi Zoltán
2020-02-26 17:14 ` Böszörményi Zoltán
0 siblings, 1 reply; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 17:08 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
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
>>>>>>
>>>>
>>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 17:08 ` Böszörményi Zoltán
@ 2020-02-26 17:14 ` Böszörményi Zoltán
2020-02-26 19:44 ` Khem Raj
0 siblings, 1 reply; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 17:14 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
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
>>>>>>>
>>>>>
>>>
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 16:37 ` Böszörményi Zoltán
@ 2020-02-26 17:16 ` Alexander Kanavin
2020-02-26 17:38 ` Böszörményi Zoltán
0 siblings, 1 reply; 31+ messages in thread
From: Alexander Kanavin @ 2020-02-26 17:16 UTC (permalink / raw)
To: Böszörményi Zoltán; +Cc: OE-core
[-- 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 --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 17:16 ` Alexander Kanavin
@ 2020-02-26 17:38 ` Böszörményi Zoltán
0 siblings, 0 replies; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 17:38 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: OE-core
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
> >>
> >
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 17:14 ` Böszörményi Zoltán
@ 2020-02-26 19:44 ` Khem Raj
2020-02-26 20:21 ` Böszörményi Zoltán
0 siblings, 1 reply; 31+ messages in thread
From: Khem Raj @ 2020-02-26 19:44 UTC (permalink / raw)
To: Böszörményi Zoltán
Cc: Patches and discussions about the oe-core layer
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.
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 19:44 ` Khem Raj
@ 2020-02-26 20:21 ` Böszörményi Zoltán
2020-02-26 20:31 ` Khem Raj
0 siblings, 1 reply; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-26 20:21 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
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.
>>
>
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 20:21 ` Böszörményi Zoltán
@ 2020-02-26 20:31 ` Khem Raj
2020-02-27 4:05 ` Böszörményi Zoltán
0 siblings, 1 reply; 31+ messages in thread
From: Khem Raj @ 2020-02-26 20:31 UTC (permalink / raw)
To: Böszörményi Zoltán
Cc: Patches and discussions about the oe-core layer
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.
>>>
>>
>>
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
2020-02-26 20:31 ` Khem Raj
@ 2020-02-27 4:05 ` Böszörményi Zoltán
0 siblings, 0 replies; 31+ messages in thread
From: Böszörményi Zoltán @ 2020-02-27 4:05 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
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.
>>>>
>>>
>>>
>>
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2020-02-27 4:05 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-26 13:57 [PATCH 1/5] libva: Split out the base parts into an include file Böszörményi Zoltán
2020-02-26 13:57 ` [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers Böszörményi Zoltán
2020-02-26 14:13 ` Paul Barker
2020-02-26 14:22 ` Böszörményi Zoltán
2020-02-26 14:58 ` Khem Raj
2020-02-26 15:12 ` Böszörményi Zoltán
2020-02-26 15:13 ` Khem Raj
2020-02-26 15:20 ` Böszörményi Zoltán
2020-02-26 15:26 ` Böszörményi Zoltán
2020-02-26 15:30 ` Khem Raj
2020-02-26 15:58 ` Böszörményi Zoltán
2020-02-26 16:51 ` Khem Raj
2020-02-26 17:08 ` Böszörményi Zoltán
2020-02-26 17:14 ` Böszörményi Zoltán
2020-02-26 19:44 ` Khem Raj
2020-02-26 20:21 ` Böszörményi Zoltán
2020-02-26 20:31 ` Khem Raj
2020-02-27 4:05 ` Böszörményi Zoltán
2020-02-26 16:12 ` Alexander Kanavin
2020-02-26 16:35 ` Böszörményi Zoltán
2020-02-26 16:37 ` Böszörményi Zoltán
2020-02-26 17:16 ` Alexander Kanavin
2020-02-26 17:38 ` Böszörményi Zoltán
2020-02-26 13:57 ` [PATCH 3/5] mesa: Add PACKAGECONFIG knob to enable VAAPI state tracker and drivers Böszörményi Zoltán
2020-02-26 13:57 ` [PATCH 4/5] mesa: Add PACKAGECONFIG knob to enable VDPAU " Böszörményi Zoltán
2020-02-26 13:57 ` [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc" Böszörményi Zoltán
2020-02-26 15:00 ` Khem Raj
2020-02-26 15:14 ` Böszörményi Zoltán
2020-02-26 15:15 ` Khem Raj
2020-02-26 16:02 ` Böszörményi Zoltán
2020-02-26 16:08 ` [PATCH 1/5] libva: Split out the base parts into an include file Alexander Kanavin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.