Re: [OE-core] [meta-clang][PATCH] conf/nonclangable.conf: Always build mesa with gcc
2020. 02. 27. 8:44 keltezéssel, Khem Raj írta: Can you send it via github pull request please Sure. On Wed, Feb 26, 2020 at 10:21 PM Böszörményi Zoltán via Openembedded-core wrote: Ignore this, the patch is against the zeus branch. Re-sent with the proper subject. 2020. 02. 27. 7:16 keltezéssel, Böszörményi Zoltán írta: Building mesa (at least version 19.3.4) with clang 9.0.1 leads to linker errors on x86/x86-64: "undefined reference to `typeinfo for llvm::raw_pwrite_stream'" in libvulkan_radeon.so and "undefined reference to `typeinfo for llvm::RTDyldMemoryManager'" in libgallium.a. It was reported at https://gitlab.freedesktop.org/mesa/mesa/issues/2533 It seems it is related to rtti not being enabled, at least reports from a few years ago on forums lead to that conclusion. But enabling rtti for clang in PACKAGECONFIG doesn't help. Just build mesa with gcc, it fixes the linker errors. Signed-off-by: Böszörményi Zoltán --- conf/nonclangable.conf | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/conf/nonclangable.conf b/conf/nonclangable.conf index 70336bb..91b9965 100644 --- a/conf/nonclangable.conf +++ b/conf/nonclangable.conf @@ -45,10 +45,9 @@ TOOLCHAIN_pn-libssp-nonshared = "gcc" TOOLCHAIN_pn-libstd-rs = "gcc" TOOLCHAIN_pn-m4_powerpc = "gcc" # clang does not have 64bit atomics on mips32 -TOOLCHAIN_pn-mesa_mips = "gcc" -TOOLCHAIN_pn-mesa_mipsel = "gcc" -TOOLCHAIN_pn-mesa_riscv64 = "gcc" -TOOLCHAIN_pn-mesa_powerpc = "gcc" +# building Mesa 19.3.x with clang causes linker errors on x86/x86-64 +# See https://gitlab.freedesktop.org/mesa/mesa/issues/2533 +TOOLCHAIN_pn-mesa = "gcc" # multiple definition of 'mongo::error_details::isNamedCode<0>' TOOLCHAIN_pn-mongodb = "gcc" # variant-impl.hpp:309:36: error: 'is_variant' does not name a template but is followed by template arguments -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-clang][PATCH] conf/nonclangable.conf: Always build mesa with gcc
Ignore this, the patch is against the zeus branch. Re-sent with the proper subject. 2020. 02. 27. 7:16 keltezéssel, Böszörményi Zoltán írta: Building mesa (at least version 19.3.4) with clang 9.0.1 leads to linker errors on x86/x86-64: "undefined reference to `typeinfo for llvm::raw_pwrite_stream'" in libvulkan_radeon.so and "undefined reference to `typeinfo for llvm::RTDyldMemoryManager'" in libgallium.a. It was reported at https://gitlab.freedesktop.org/mesa/mesa/issues/2533 It seems it is related to rtti not being enabled, at least reports from a few years ago on forums lead to that conclusion. But enabling rtti for clang in PACKAGECONFIG doesn't help. Just build mesa with gcc, it fixes the linker errors. Signed-off-by: Böszörményi Zoltán --- conf/nonclangable.conf | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/conf/nonclangable.conf b/conf/nonclangable.conf index 70336bb..91b9965 100644 --- a/conf/nonclangable.conf +++ b/conf/nonclangable.conf @@ -45,10 +45,9 @@ TOOLCHAIN_pn-libssp-nonshared = "gcc" TOOLCHAIN_pn-libstd-rs = "gcc" TOOLCHAIN_pn-m4_powerpc = "gcc" # clang does not have 64bit atomics on mips32 -TOOLCHAIN_pn-mesa_mips = "gcc" -TOOLCHAIN_pn-mesa_mipsel = "gcc" -TOOLCHAIN_pn-mesa_riscv64 = "gcc" -TOOLCHAIN_pn-mesa_powerpc = "gcc" +# building Mesa 19.3.x with clang causes linker errors on x86/x86-64 +# See https://gitlab.freedesktop.org/mesa/mesa/issues/2533 +TOOLCHAIN_pn-mesa = "gcc" # multiple definition of 'mongo::error_details::isNamedCode<0>' TOOLCHAIN_pn-mongodb = "gcc" # variant-impl.hpp:309:36: error: 'is_variant' does not name a template but is followed by template arguments -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta-clang][zeus][PATCH] conf/nonclangable.conf: Always build mesa with gcc
Building mesa (at least version 19.3.4) with clang 9.0.1 leads to linker errors on x86/x86-64: "undefined reference to `typeinfo for llvm::raw_pwrite_stream'" in libvulkan_radeon.so and "undefined reference to `typeinfo for llvm::RTDyldMemoryManager'" in libgallium.a. It was reported at https://gitlab.freedesktop.org/mesa/mesa/issues/2533 It seems it is related to rtti not being enabled, at least reports from a few years ago on forums lead to that conclusion. But enabling rtti for clang in PACKAGECONFIG doesn't help. Just build mesa with gcc, it fixes the linker errors. Signed-off-by: Böszörményi Zoltán --- conf/nonclangable.conf | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/conf/nonclangable.conf b/conf/nonclangable.conf index 70336bb..91b9965 100644 --- a/conf/nonclangable.conf +++ b/conf/nonclangable.conf @@ -45,10 +45,9 @@ TOOLCHAIN_pn-libssp-nonshared = "gcc" TOOLCHAIN_pn-libstd-rs = "gcc" TOOLCHAIN_pn-m4_powerpc = "gcc" # clang does not have 64bit atomics on mips32 -TOOLCHAIN_pn-mesa_mips = "gcc" -TOOLCHAIN_pn-mesa_mipsel = "gcc" -TOOLCHAIN_pn-mesa_riscv64 = "gcc" -TOOLCHAIN_pn-mesa_powerpc = "gcc" +# building Mesa 19.3.x with clang causes linker errors on x86/x86-64 +# See https://gitlab.freedesktop.org/mesa/mesa/issues/2533 +TOOLCHAIN_pn-mesa = "gcc" # multiple definition of 'mongo::error_details::isNamedCode<0>' TOOLCHAIN_pn-mongodb = "gcc" # variant-impl.hpp:309:36: error: 'is_variant' does not name a template but is followed by template arguments -- 2.24.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta-clang][PATCH] conf/nonclangable.conf: Always build mesa with gcc
Building mesa (at least version 19.3.4) with clang 9.0.1 leads to linker errors on x86/x86-64: "undefined reference to `typeinfo for llvm::raw_pwrite_stream'" in libvulkan_radeon.so and "undefined reference to `typeinfo for llvm::RTDyldMemoryManager'" in libgallium.a. It was reported at https://gitlab.freedesktop.org/mesa/mesa/issues/2533 It seems it is related to rtti not being enabled, at least reports from a few years ago on forums lead to that conclusion. But enabling rtti for clang in PACKAGECONFIG doesn't help. Just build mesa with gcc, it fixes the linker errors. Signed-off-by: Böszörményi Zoltán --- conf/nonclangable.conf | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/conf/nonclangable.conf b/conf/nonclangable.conf index 70336bb..91b9965 100644 --- a/conf/nonclangable.conf +++ b/conf/nonclangable.conf @@ -45,10 +45,9 @@ TOOLCHAIN_pn-libssp-nonshared = "gcc" TOOLCHAIN_pn-libstd-rs = "gcc" TOOLCHAIN_pn-m4_powerpc = "gcc" # clang does not have 64bit atomics on mips32 -TOOLCHAIN_pn-mesa_mips = "gcc" -TOOLCHAIN_pn-mesa_mipsel = "gcc" -TOOLCHAIN_pn-mesa_riscv64 = "gcc" -TOOLCHAIN_pn-mesa_powerpc = "gcc" +# building Mesa 19.3.x with clang causes linker errors on x86/x86-64 +# See https://gitlab.freedesktop.org/mesa/mesa/issues/2533 +TOOLCHAIN_pn-mesa = "gcc" # multiple definition of 'mongo::error_details::isNamedCode<0>' TOOLCHAIN_pn-mongodb = "gcc" # variant-impl.hpp:309:36: error: 'is_variant' does not name a template but is followed by template arguments -- 2.24.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 4/4] mesa: Add PACKAGECONFIG knob to enable VDPAU state tracker and drivers
Signed-off-by: Böszörményi Zoltán
---
v2: Replaced FILES_${PN}-vdpau-drivers with FILES_mesa-vdpau-drivers
to match the name in PACKAGES.
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_mesa-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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 2/4] libva-initial: New bootstrap recipe
Mesa needs libva.pc and libva headers to enable the VAAPI
state tracker and drivers.
This recipe is a variant of the full libva package build as in:
* it only depends on libdrm to build so it doesn't introduce
the circular dependency between mesa and libva, and
* it doesn't include the libraries in the final package.
However, there is another issue with build dependency handling
in Yocto. libva depends on mesa and mesa depends on this package.
Any package that depends on libva therefore would pull in libva
and this package resulting in an error in the prepare-sysroot
phase because they would install identical files into the
per-recipe sysroot.
Using the package name "*-initial" avoids this because of the
interaction between sstate.bbclass and staging.bbclass: any
package with the pattern "*-initial" in the name is excluded
from the dependency list unless explicitly added to DEPENDS.
Signed-off-by: Böszörményi Zoltán
---
v2: The include file is not versioned, more verbose commit message
meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 9 +
meta/recipes-graphics/libva/libva.inc | 4 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
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 00..a3b04eb02a
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,9 @@
+require libva.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
+SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
+SRC_URI[sha256sum] =
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
+
+do_install_append () {
+ rm -f ${D}${libdir}/*.so*
+}
diff --git a/meta/recipes-graphics/libva/libva.inc
b/meta/recipes-graphics/libva/libva.inc
index 058581f7d1..6a3427b5b1 100644
--- a/meta/recipes-graphics/libva/libva.inc
+++ b/meta/recipes-graphics/libva/libva.inc
@@ -16,7 +16,9 @@ BUGTRACKER = "https://github.com/intel/libva/issues;
SECTION = "x11"
LICENSE = "MIT"
-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;
+
+S = "${WORKDIR}/libva-${PV}"
UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
--
2.24.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 0/4] Enable VAAPI and VDPAU video drivers in Mesa
Mesa needs libva to enable VAAPI state tracker and drivers. libva needs Mesa to enable its GLX part. This is a circular dependency that can be solved by introducing a new libva recipe variant that doesn't enable GLX. Actually, the presence of Mesa/OpenGL headers is autodetected in libva so it's enough to leave out Mesa from DEPENDS in the new libva recipe variant. With magic already existing in sstate.bbclass and staging.bbclass, naming the new libva recipe variant "libva-initial" avoids an error for every other recipe that pulls in libva as dependency, including libva-utils and intel-vaapi-driver. The error (if not naming the recipe as "*-initial") is that the prepare-sysroot phase of a package would pull in the files rom both libva build variants that would obviously install identical files. Enabling the VDPAU state tracker and libraries is trivial, it was just missing from the recipe. [PATCH v2 1/4] libva: Factor out base parts into an include file [PATCH v2 2/4] libva-initial: New bootstrap recipe [PATCH v2 3/4] mesa: Add PACKAGECONFIG knob to enable VAAPI [PATCH v2 4/4] mesa: Add PACKAGECONFIG knob to enable VDPAU state Signed-off-by: Böszörményi Zoltán -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 1/4] libva: Factor out base parts into an include file
To enable the VAAPI state tracker and drivers in mesa, it needs
libva.pc and the libva headers. At the recipe level, this would
create a circular dependency between libva and mesa.
This is a preparation step before introducing a new libva recipe
variant to break the circular dependency.
Signed-off-by: Böszörményi Zoltán
---
v2: The include file is not versioned, verbose commit message
meta/recipes-graphics/libva/libva.inc | 27 ++
meta/recipes-graphics/libva/libva_2.6.1.bb | 27 ++
2 files changed, 29 insertions(+), 25 deletions(-)
create mode 100644 meta/recipes-graphics/libva/libva.inc
diff --git a/meta/recipes-graphics/libva/libva.inc
b/meta/recipes-graphics/libva/libva.inc
new file mode 100644
index 00..058581f7d1
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva.inc
@@ -0,0 +1,27 @@
+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"
+
+SRC_URI =
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+
+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..b68fb27136 100644
--- a/meta/recipes-graphics/libva/libva_2.6.1.bb
+++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
@@ -1,33 +1,10 @@
-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.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
[OE-core] [PATCH v2 3/4] mesa: Add PACKAGECONFIG knob to enable VAAPI
The previously added libva-initial recipe makes it possible and
trivial.
Signed-off-by: Böszörményi Zoltán
---
v2: Small explanation in the commit message
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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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 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 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 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. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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 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 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 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. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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 mailto:zbos...@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
>> 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 mailto:zbos...@pr.hu>
<mailto:zbos...@pr.hu <mailto:zbos...@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 00..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
>>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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 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
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 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
---
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 00..828ef6fbca
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,5 @@
+require libva-${PV}.inc
+
+do_install_append () {
+ rm -f ${D}${libdir}/*.so*
+}
--
2.24.1
--
___
Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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 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
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 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
---
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 00..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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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
<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 mailto:zbos...@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 00..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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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
<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 mailto:zbos...@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 00..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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"
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 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 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 --- 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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 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 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 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
---
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 00..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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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 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 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
---
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 00..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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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 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 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
---
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 00..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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"
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 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 --- 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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 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
---
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 00..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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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
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
---
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 00..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.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] mesa: Add PACKAGECONFIG knob to enable VAAPI state tracker and drivers
Signed-off-by: Böszörményi Zoltán
---
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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] mesa: Add PACKAGECONFIG knob to enable VDPAU state tracker and drivers
Signed-off-by: Böszörményi Zoltán
---
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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"
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 --- 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] libva: Split out the base parts into an include file
Signed-off-by: Böszörményi Zoltán
---
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 00..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
[OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers
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
---
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 00..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
[OE-core] OPKG intercept scripts vs RPM %posttrans
Hi, I know that OPKG supports running scripts at the very end of the package manager transaction. These are the so called "intercept scripts" in OPKG speak. pkg_postinst() scripts can run these scripts that create another script that eventually run at the end of the transaction. However, these are not applicable when building an RPM based system with Yocto. In RPM, there are these %posttrans scriptlets that are scheduled for the end of the transaction. However, creating a %posttrans scriptlet is not supported in package_rpm.bbclass. For example, one package may depend on another for upgraded contents but if this dependency is not versioned, then the upgrade of these two packages may be done in the wrong order, making the pkg_postinst (%post) script of the first package run earlier than the script for the dependency package. An intercept script or RPM %posttrans script is perfect in any case. Is it planned to support %posttrans? Best regards, Zoltán Böszörményi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz
2019. 09. 26. 23:02 keltezéssel, richard.pur...@linuxfoundation.org írta:
On Thu, 2019-09-26 at 19:09 +0200, Böszörményi Zoltán wrote:
2019. 09. 26. 19:02 keltezéssel, Böszörményi Zoltán via Openembedded-
core írta:
2019. 09. 26. 18:50 keltezéssel, Böszörményi Zoltán via
Openembedded-core írta:
2019. 09. 26. 17:45 keltezéssel, Richard Purdie írta:
I'm a little worried that INITRAMFS_FSTYPES can contain
multiple values
by the sounds of its name...
From the looks of the current value, it's already contains
multiple values
delimited by that dot. "cpio" + "gz".
Also, according to meta/conf/documentation.conf, line 228:
INITRAMFS_FSTYPES[doc] = "Defines the format for the output image
of an initial RAM disk
(initramfs), which is used during boot."
Also, image-live.bbclass uses this variable this way:
INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.${INITRAMFS_FSTYPES}"
The initrd/initramfs file name would definitely look strange if
this variable could contain multiple space delimited settings.
Also, openembedded-core/scripts/lib/wic/plugins/source/isoimage-
isohybrid.py
has that _build_initramfs_path function from line 143. The usage of
the same variable in this python function also points back to the
documentation line, i.e. it's a filename suffix and not multiple
settings delimited by space.
This does look ok given the above. Thanks for confirming.
Thanks for merging it into master-next.
I have also sent a patch for warrior separately with [warrior][PATCH]
yesterday, as I experienced the error there first.
Can you please apply it to warrior-next so I won't have to carry
the patch locally for long?
Thanks in advance,
Zoltán Böszörményi
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz
2019. 09. 26. 19:02 keltezéssel, Böszörményi Zoltán via Openembedded-core írta:
2019. 09. 26. 18:50 keltezéssel, Böszörményi Zoltán via Openembedded-core írta:
2019. 09. 26. 17:45 keltezéssel, Richard Purdie írta:
On Thu, 2019-09-26 at 11:05 +0200, Böszörményi Zoltán via Openembedded-
core wrote:
There's INITRAMFS_FSTYPES that can be set differently.
Signed-off-by: Böszörményi Zoltán
---
With the hardcoded initrd filename suffix but INITRAMFS_FSTYPES
set to cpio.lzma, this error occurs:
ERROR: sicom-pos-image-1.0-r0 do_bootimg:
.../deploy/glibc/images/intel-core2-32/core-image-minimal-initramfs-
intel-core2-32.cpio.lzma is invalid. initrd image creation failed.
ERROR: sicom-pos-image-1.0-r0 do_bootimg: Function failed:
build_hddimg (log file is located at .../tmp-sicom-
glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
r0/temp/log.do_bootimg.32210)
ERROR: Logfile of failure stored in: .../tmp-sicom-
glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
r0/temp/log.do_bootimg.32210
ERROR: Task (.../layers/meta-sicom/images/sicom-pos-
image.bb:do_bootimg) failed with exit code '1'
meta/classes/image-live.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-
live.bbclass
index af71be5093..54058b350d 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -37,7 +37,7 @@ do_bootimg[depends] += "dosfstools-
native:do_populate_sysroot \
LABELS_LIVE ?= "boot install"
ROOT_LIVE ?= "root=/dev/ram0"
INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
-INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.cpio.gz"
+INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.${INITRAMFS_FSTYPES}"
LIVE_ROOTFS_TYPE ?= "ext4"
ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"
I'm a little worried that INITRAMFS_FSTYPES can contain multiple values
by the sounds of its name...
From the looks of the current value, it's already contains multiple values
delimited by that dot. "cpio" + "gz".
Also, according to meta/conf/documentation.conf, line 228:
INITRAMFS_FSTYPES[doc] = "Defines the format for the output image of an initial RAM disk
(initramfs), which is used during boot."
Also, image-live.bbclass uses this variable this way:
INITRD_LIVE ?=
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}"
The initrd/initramfs file name would definitely look strange if
this variable could contain multiple space delimited settings.
Also, openembedded-core/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
has that _build_initramfs_path function from line 143. The usage of
the same variable in this python function also points back to the
documentation line, i.e. it's a filename suffix and not multiple
settings delimited by space.
Defines the "format", singular. Maybe the variable is a slight misnomer.
Cheers,
Zoltán Böszörményi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz
2019. 09. 26. 18:50 keltezéssel, Böszörményi Zoltán via Openembedded-core írta:
2019. 09. 26. 17:45 keltezéssel, Richard Purdie írta:
On Thu, 2019-09-26 at 11:05 +0200, Böszörményi Zoltán via Openembedded-
core wrote:
There's INITRAMFS_FSTYPES that can be set differently.
Signed-off-by: Böszörményi Zoltán
---
With the hardcoded initrd filename suffix but INITRAMFS_FSTYPES
set to cpio.lzma, this error occurs:
ERROR: sicom-pos-image-1.0-r0 do_bootimg:
.../deploy/glibc/images/intel-core2-32/core-image-minimal-initramfs-
intel-core2-32.cpio.lzma is invalid. initrd image creation failed.
ERROR: sicom-pos-image-1.0-r0 do_bootimg: Function failed:
build_hddimg (log file is located at .../tmp-sicom-
glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
r0/temp/log.do_bootimg.32210)
ERROR: Logfile of failure stored in: .../tmp-sicom-
glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
r0/temp/log.do_bootimg.32210
ERROR: Task (.../layers/meta-sicom/images/sicom-pos-
image.bb:do_bootimg) failed with exit code '1'
meta/classes/image-live.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-
live.bbclass
index af71be5093..54058b350d 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -37,7 +37,7 @@ do_bootimg[depends] += "dosfstools-
native:do_populate_sysroot \
LABELS_LIVE ?= "boot install"
ROOT_LIVE ?= "root=/dev/ram0"
INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
-INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.cpio.gz"
+INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.${INITRAMFS_FSTYPES}"
LIVE_ROOTFS_TYPE ?= "ext4"
ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"
I'm a little worried that INITRAMFS_FSTYPES can contain multiple values
by the sounds of its name...
From the looks of the current value, it's already contains multiple values
delimited by that dot. "cpio" + "gz".
Also, according to meta/conf/documentation.conf, line 228:
INITRAMFS_FSTYPES[doc] = "Defines the format for the output image of an initial RAM disk
(initramfs), which is used during boot."
Also, image-live.bbclass uses this variable this way:
INITRD_LIVE ?=
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}"
The initrd/initramfs file name would definitely look strange if
this variable could contain multiple space delimited settings.
Defines the "format", singular. Maybe the variable is a slight misnomer.
Cheers,
Zoltán Böszörményi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz
2019. 09. 26. 17:45 keltezéssel, Richard Purdie írta:
On Thu, 2019-09-26 at 11:05 +0200, Böszörményi Zoltán via Openembedded-
core wrote:
There's INITRAMFS_FSTYPES that can be set differently.
Signed-off-by: Böszörményi Zoltán
---
With the hardcoded initrd filename suffix but INITRAMFS_FSTYPES
set to cpio.lzma, this error occurs:
ERROR: sicom-pos-image-1.0-r0 do_bootimg:
.../deploy/glibc/images/intel-core2-32/core-image-minimal-initramfs-
intel-core2-32.cpio.lzma is invalid. initrd image creation failed.
ERROR: sicom-pos-image-1.0-r0 do_bootimg: Function failed:
build_hddimg (log file is located at .../tmp-sicom-
glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
r0/temp/log.do_bootimg.32210)
ERROR: Logfile of failure stored in: .../tmp-sicom-
glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-
r0/temp/log.do_bootimg.32210
ERROR: Task (.../layers/meta-sicom/images/sicom-pos-
image.bb:do_bootimg) failed with exit code '1'
meta/classes/image-live.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-
live.bbclass
index af71be5093..54058b350d 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -37,7 +37,7 @@ do_bootimg[depends] += "dosfstools-
native:do_populate_sysroot \
LABELS_LIVE ?= "boot install"
ROOT_LIVE ?= "root=/dev/ram0"
INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
-INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.cpio.gz"
+INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.${INITRAMFS_FSTYPES}"
LIVE_ROOTFS_TYPE ?= "ext4"
ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"
I'm a little worried that INITRAMFS_FSTYPES can contain multiple values
by the sounds of its name...
From the looks of the current value, it's already contains multiple values
delimited by that dot. "cpio" + "gz".
Also, according to meta/conf/documentation.conf, line 228:
INITRAMFS_FSTYPES[doc] = "Defines the format for the output image of an initial RAM disk
(initramfs), which is used during boot."
Defines the "format", singular. Maybe the variable is a slight misnomer.
Cheers,
Zoltán Böszörményi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz
There's INITRAMFS_FSTYPES that can be set differently.
Signed-off-by: Böszörményi Zoltán
---
With the hardcoded initrd filename suffix but INITRAMFS_FSTYPES
set to cpio.lzma, this error occurs:
ERROR: sicom-pos-image-1.0-r0 do_bootimg:
.../deploy/glibc/images/intel-core2-32/core-image-minimal-initramfs-intel-core2-32.cpio.lzma
is invalid. initrd image creation failed.
ERROR: sicom-pos-image-1.0-r0 do_bootimg: Function failed: build_hddimg (log
file is located at
.../tmp-sicom-glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-r0/temp/log.do_bootimg.32210)
ERROR: Logfile of failure stored in:
.../tmp-sicom-glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-r0/temp/log.do_bootimg.32210
ERROR: Task (.../layers/meta-sicom/images/sicom-pos-image.bb:do_bootimg) failed
with exit code '1'
meta/classes/image-live.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index af71be5093..54058b350d 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -37,7 +37,7 @@ do_bootimg[depends] += "dosfstools-native:do_populate_sysroot
\
LABELS_LIVE ?= "boot install"
ROOT_LIVE ?= "root=/dev/ram0"
INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
-INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.cpio.gz"
+INITRD_LIVE ?=
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}"
LIVE_ROOTFS_TYPE ?= "ext4"
ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [warrior][PATCH] classes/image-live.bbclass: Don't hardcode cpio.gz
There's INITRAMFS_FSTYPES that can be set differently.
Signed-off-by: Böszörményi Zoltán
---
With the hardcoded initrd filename suffix but INITRAMFS_FSTYPES
set to cpio.lzma, this error occurs:
ERROR: sicom-pos-image-1.0-r0 do_bootimg:
.../deploy/glibc/images/intel-core2-32/core-image-minimal-initramfs-intel-core2-32.cpio.lzma
is invalid. initrd image creation failed.
ERROR: sicom-pos-image-1.0-r0 do_bootimg: Function failed: build_hddimg (log
file is located at
.../tmp-sicom-glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-r0/temp/log.do_bootimg.32210)
ERROR: Logfile of failure stored in:
.../tmp-sicom-glibc/work/intel_core2_32-sicom-linux/sicom-pos-image/1.0-r0/temp/log.do_bootimg.32210
ERROR: Task (.../layers/meta-sicom/images/sicom-pos-image.bb:do_bootimg) failed
with exit code '1'
meta/classes/image-live.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index af71be5093..54058b350d 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -37,7 +37,7 @@ do_bootimg[depends] += "dosfstools-native:do_populate_sysroot
\
LABELS_LIVE ?= "boot install"
ROOT_LIVE ?= "root=/dev/ram0"
INITRD_IMAGE_LIVE ?= "${MLPREFIX}core-image-minimal-initramfs"
-INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.cpio.gz"
+INITRD_LIVE ?=
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}"
LIVE_ROOTFS_TYPE ?= "ext4"
ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${LIVE_ROOTFS_TYPE}"
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Bug: warrior vs usrmerge vs chromium build
Hi, I was fighting with building chromium-x11 using our warrior based custom distro that was always failing at the same spot. That spot is when Chromium wants to run cross-compiled binaries in the v8 directory. The binaries all failed with the same error: python ../../v8/tools/run.py ./v8-qemu-wrapper.sh ./bytecode_builtins_list_generator gen/v8/builtins-generated/bytecodes-builtins-list.h ./bytecode_builtins_list_generator: relocation error: /data/OE/sicom-manifest-2.7/tmp-sicom-glibc/work/core2-32-sicom-linux/chromium-x11/76.0.3809.132-r0/recipe-sysroot /usr/lib/libc.so.6: symbol _dl_exception_create, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference It turns out, all target binaries reference /lib/ld-linux.so.2 but there is no lib -> usr/lib symlink in recipe-sysroot, so the binary running in Qemu will not find /lib/ld-linux.so.2, hence the runtime failure. It seems this symlink is only intended to get created during rootfs creation. When I created this symlink manually after the failed build, the second attempt succeeded. Best regards, Zoltán Böszörményi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libcomps: put PV in filename
2019. 03. 26. 0:44 keltezéssel, Ross Burton írta:
This isn't a git snapshot recipe but a release that is fetched over it. For
clarity, put the PV in the filename.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} | 1 -
1 file changed, 1 deletion(-)
rename meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb}
(98%)
diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb
b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
similarity index 98%
rename from meta/recipes-devtools/libcomps/libcomps_git.bb
rename to meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
index ff6820851fe..1c4f3bde65e 100644
--- a/meta/recipes-devtools/libcomps/libcomps_git.bb
+++ b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
@@ -9,7 +9,6 @@ SRC_URI =
"git://github.com/rpm-software-management/libcomps.git \
file://0001-Add-crc32.c-to-sources-list.patch \
"
-PV = "0.1.10"
# opkg compare-version git "<=" 0.1.10 ; echo $?
1
# opkg compare-version git "<=" 1:0.1.10 ; echo $?
0
You need to increase PE to be able to upgrade the new recipe
in case you publish this package in a repository.
Best regards,
Zoltán Böszörményi
SRCREV = "86a82fcd155c27092340d15a34f5c75c4da88243"
S = "${WORKDIR}/git"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libcomps: put PV in filename
2019. 03. 29. 19:45 keltezéssel, Böszörményi Zoltán írta:
2019. 03. 26. 0:44 keltezéssel, Ross Burton írta:
This isn't a git snapshot recipe but a release that is fetched over it. For
clarity, put the PV in the filename.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} | 1 -
1 file changed, 1 deletion(-)
rename meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb}
(98%)
diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb
b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
similarity index 98%
rename from meta/recipes-devtools/libcomps/libcomps_git.bb
rename to meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
index ff6820851fe..1c4f3bde65e 100644
--- a/meta/recipes-devtools/libcomps/libcomps_git.bb
+++ b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
@@ -9,7 +9,6 @@ SRC_URI =
"git://github.com/rpm-software-management/libcomps.git \
file://0001-Add-crc32.c-to-sources-list.patch \
"
-PV = "0.1.10"
# opkg compare-version git "<=" 0.1.10 ; echo $?
1
# opkg compare-version git "<=" 1:0.1.10 ; echo $?
0
You need to increase PE to be able to upgrade the new recipe
in case you publish this package in a repository.
Sorry, dumb comment, ignore it. PV was overridden inside the recipe.
Best regards,
Zoltán Böszörményi
SRCREV = "86a82fcd155c27092340d15a34f5c75c4da88243"
S = "${WORKDIR}/git"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mesa: upgrade 18.1.9 -> 18.3.3
2019. 02. 15. 14:26 keltezéssel, Alexander Kanavin írta: On Fri, 15 Feb 2019 at 14:21, Fabio Berton wrote: In my opinion, there is no relation with an update and change build system, once we can use mesa 18.3.3 without meson. Please see: https://www.phoronix.com/scan.php?page=news_item=Mesa-19.0-Deprecates-Autotools We might as well switch to meson now. The patches are ready and (mostly) working. I have read the mesa-dev list constantly regarding this change. The deprecation process was painful and issues in the meson build system still turn up occasionally. 19.0 will still have a configure option to opt-in for autotools. In this upcoming release they have worked out all known issues for meson but I would in no way want to use meson for older main releases because these changes are not backported offically. So, either keep autotools for 8.3.3 or wait for 9.0 and switch to meson. Just my 2 eurocents. Best regards, Zoltán Böszörményi Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] dracut is impossible to run in do_rootfs
Hi again, I am now replying to myself. If anyone is interested, I have solved it in dracut so it can use a sysroot. See: https://github.com/dracutdevs/dracut/pull/535 Then, the dracut recipe also needs changes so it can be built as native. A recipe is needed for a cross-compiler ldd from this: https://gist.github.com/jerome-pouiller/c403786c1394f53f44a3b61214489e6f Then a dracut.bbclass to be used by a kernel recipe or anything else that wants to be included in the initramfs, like extra dracut modules or custom boot splash themes. I have all of this working now in Yocto 2.5 via a bbappend for dracut and the two extras. Eventually, I would like to upstream these changes when my dracut PR is merged, hopefully before 050 is released. 2018. 11. 14. 10:53 keltezéssel, Böszörményi Zoltán via Openembedded-core írta: Hi, I need to create the initramfs for the target build during do_rootfs using dracut to include systemd and plymouth into it and using the modules from the kernel version the image was built with. Currently I am on Yocto 2.5. There are several problem I am facing. First, the dracut recipe needs some fixes in the RDEPENDS/RRECOMMENDS clauses to only use subpackages of the recipes it depends on in class-target only. I could fix this with a bbappend file. Then, all the packages in the system that use the update-alternatives.bbclass have unusable symlinks during the do_rootfs stage. E.g. coreutils's binaries use this: zboszormenyi@buildbox-0001 rootfs]$ ls -l usr/bin/[ lrwxrwxrwx 1 zboszormenyi zboszormenyi 27 nov 14 03.51 usr/bin/[ -> /usr/bin/lbracket.coreutils Of course, the target of the symlink does not exist on the build host. As a consequence, dracut will not find anything that it needs to copy to the initramfs. Is there a way to tell update-alternatives.bbclass (e.g. globally from my layer.conf) to just use the relative symlink it is given? Thanks in advance, Zoltán Böszörményi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] update-alternatives: Allow using relative symlinks
The alternative links are invalid during do_rootfs.
Add a new ALTERNATIVE_TARGET_RELATIVE family of variables to
conditionally make these links valid.
Signed-off-by: Böszörményi Zoltán
---
v2: Fix the case when the link source and target are not in
the same directory.
v3: Moved the patch version information here so it's not polluting
the git history when applied.
meta/classes/update-alternatives.bbclass | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/meta/classes/update-alternatives.bbclass
b/meta/classes/update-alternatives.bbclass
index aa01058cf9..540bec94e2 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -47,6 +47,15 @@
# the need to rename alternative files in the do_install step, but still
# supports it if necessary for some reason.)
#
+# The default to use relative link for all targets
+# ALTERNATIVE_TARGET_RELATIVE = "1"
+#
+# A non-default setting to use relative link for a target
+# ALTERNATIVE_TARGET_RELATIVE[name] = "1"
+#
+# A package specific setting to use relative link for a target
+# ALTERNATIVE_TARGET_RELATIVE_[name] = "1"
+#
# The default priority for any alternatives
# ALTERNATIVE_PRIORITY = "priority"
#
@@ -214,6 +223,10 @@ python populate_packages_updatealternatives () {
# Sometimes alt_target is specified as relative to the link name.
alt_target = os.path.join(os.path.dirname(alt_link), alt_target)
+# Whether to use relative symlink target
+alt_relative = d.getVarFlag('ALTERNATIVE_TARGET_RELATIVE_%s' %
pkg, alt_name) or d.getVarFlag('ALTERNATIVE_TARGET_RELATIVE', alt_name)
+alt_relative = alt_relative or
d.getVar('ALTERNATIVE_TARGET_RELATIVE_%s' % pkg) or
d.getVar('ALTERNATIVE_TARGET_RELATIVE')
+
alt_priority = d.getVarFlag('ALTERNATIVE_PRIORITY_%s' % pkg,
alt_name) or d.getVarFlag('ALTERNATIVE_PRIORITY', alt_name)
alt_priority = alt_priority or d.getVar('ALTERNATIVE_PRIORITY_%s'
% pkg) or d.getVar('ALTERNATIVE_PRIORITY')
@@ -229,8 +242,15 @@ python populate_packages_updatealternatives () {
# Default to generate shell script.. eventually we may want to
change this...
alt_target = os.path.normpath(alt_target)
-alt_setup_links += '\tupdate-alternatives --install %s %s %s
%s\n' % (alt_link, alt_name, alt_target, alt_priority)
-alt_remove_links += '\tupdate-alternatives --remove %s %s\n' %
(alt_name, alt_target)
+if alt_relative and os.path.dirname(alt_target) ==
os.path.dirname(alt_link):
+alt_target_final = os.path.basename(alt_target)
+elif alt_relative:
+alt_target_final = os.path.join(os.path.join(*['..'] *
len(list(filter(None, os.path.dirname(alt_link).split('/'),
*list(filter(None, alt_target.split('/'
+else:
+alt_target_final = alt_target
+
+alt_setup_links += '\tupdate-alternatives --install %s %s %s
%s\n' % (alt_link, alt_name, alt_target_final, alt_priority)
+alt_remove_links += '\tupdate-alternatives --remove %s %s\n' %
(alt_name, alt_target_final)
if alt_setup_links:
# RDEPENDS setup
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] update-alternatives: Allow using relative symlinks
The alternative links are invalid during do_rootfs.
Add a new ALTERNATIVE_TARGET_RELATIVE family of variables to
conditionally make these links valid.
v2: Fix the case when the link source and target are not in
the same directory.
Signed-off-by: Böszörményi Zoltán
---
meta/classes/update-alternatives.bbclass | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/meta/classes/update-alternatives.bbclass
b/meta/classes/update-alternatives.bbclass
index aa01058cf9..540bec94e2 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -47,6 +47,15 @@
# the need to rename alternative files in the do_install step, but still
# supports it if necessary for some reason.)
#
+# The default to use relative link for all targets
+# ALTERNATIVE_TARGET_RELATIVE = "1"
+#
+# A non-default setting to use relative link for a target
+# ALTERNATIVE_TARGET_RELATIVE[name] = "1"
+#
+# A package specific setting to use relative link for a target
+# ALTERNATIVE_TARGET_RELATIVE_[name] = "1"
+#
# The default priority for any alternatives
# ALTERNATIVE_PRIORITY = "priority"
#
@@ -214,6 +223,10 @@ python populate_packages_updatealternatives () {
# Sometimes alt_target is specified as relative to the link name.
alt_target = os.path.join(os.path.dirname(alt_link), alt_target)
+# Whether to use relative symlink target
+alt_relative = d.getVarFlag('ALTERNATIVE_TARGET_RELATIVE_%s' %
pkg, alt_name) or d.getVarFlag('ALTERNATIVE_TARGET_RELATIVE', alt_name)
+alt_relative = alt_relative or
d.getVar('ALTERNATIVE_TARGET_RELATIVE_%s' % pkg) or
d.getVar('ALTERNATIVE_TARGET_RELATIVE')
+
alt_priority = d.getVarFlag('ALTERNATIVE_PRIORITY_%s' % pkg,
alt_name) or d.getVarFlag('ALTERNATIVE_PRIORITY', alt_name)
alt_priority = alt_priority or d.getVar('ALTERNATIVE_PRIORITY_%s'
% pkg) or d.getVar('ALTERNATIVE_PRIORITY')
@@ -229,8 +242,15 @@ python populate_packages_updatealternatives () {
# Default to generate shell script.. eventually we may want to
change this...
alt_target = os.path.normpath(alt_target)
-alt_setup_links += '\tupdate-alternatives --install %s %s %s
%s\n' % (alt_link, alt_name, alt_target, alt_priority)
-alt_remove_links += '\tupdate-alternatives --remove %s %s\n' %
(alt_name, alt_target)
+if alt_relative and os.path.dirname(alt_target) ==
os.path.dirname(alt_link):
+alt_target_final = os.path.basename(alt_target)
+elif alt_relative:
+alt_target_final = os.path.join(os.path.join(*['..'] *
len(list(filter(None, os.path.dirname(alt_link).split('/'),
*list(filter(None, alt_target.split('/'
+else:
+alt_target_final = alt_target
+
+alt_setup_links += '\tupdate-alternatives --install %s %s %s
%s\n' % (alt_link, alt_name, alt_target_final, alt_priority)
+alt_remove_links += '\tupdate-alternatives --remove %s %s\n' %
(alt_name, alt_target_final)
if alt_setup_links:
# RDEPENDS setup
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] update-alternatives: Allow using relative symlinks
The alternative links are invalid during do_rootfs.
Add a new ALTERNATIVE_TARGET_RELATIVE family of variables to
conditionally make these links valid. This is limited to the
case when the binary and the symlink are in the same directory.
Signed-off-by: Böszörményi Zoltán
---
meta/classes/update-alternatives.bbclass | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/meta/classes/update-alternatives.bbclass
b/meta/classes/update-alternatives.bbclass
index aa01058cf9..7af559c918 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -47,6 +47,15 @@
# the need to rename alternative files in the do_install step, but still
# supports it if necessary for some reason.)
#
+# The default to use relative link for all targets
+# ALTERNATIVE_TARGET_RELATIVE = "1"
+#
+# A non-default setting to use relative link for a target
+# ALTERNATIVE_TARGET_RELATIVE[name] = "1"
+#
+# A package specific setting to use relative link for a target
+# ALTERNATIVE_TARGET_RELATIVE_[name] = "1"
+#
# The default priority for any alternatives
# ALTERNATIVE_PRIORITY = "priority"
#
@@ -214,6 +223,10 @@ python populate_packages_updatealternatives () {
# Sometimes alt_target is specified as relative to the link name.
alt_target = os.path.join(os.path.dirname(alt_link), alt_target)
+# Whether to use relative symlink target
+alt_relative = d.getVarFlag('ALTERNATIVE_TARGET_RELATIVE_%s' %
pkg, alt_name) or d.getVarFlag('ALTERNATIVE_TARGET_RELATIVE', alt_name)
+alt_relative = alt_relative or
d.getVar('ALTERNATIVE_TARGET_RELATIVE_%s' % pkg) or
d.getVar('ALTERNATIVE_TARGET_RELATIVE')
+
alt_priority = d.getVarFlag('ALTERNATIVE_PRIORITY_%s' % pkg,
alt_name) or d.getVarFlag('ALTERNATIVE_PRIORITY', alt_name)
alt_priority = alt_priority or d.getVar('ALTERNATIVE_PRIORITY_%s'
% pkg) or d.getVar('ALTERNATIVE_PRIORITY')
@@ -229,8 +242,13 @@ python populate_packages_updatealternatives () {
# Default to generate shell script.. eventually we may want to
change this...
alt_target = os.path.normpath(alt_target)
-alt_setup_links += '\tupdate-alternatives --install %s %s %s
%s\n' % (alt_link, alt_name, alt_target, alt_priority)
-alt_remove_links += '\tupdate-alternatives --remove %s %s\n' %
(alt_name, alt_target)
+if alt_relative and alt_target.startswith(alt_link):
+alt_target_final = os.path.basename(alt_target)
+else:
+alt_target_final = alt_target
+
+alt_setup_links += '\tupdate-alternatives --install %s %s %s
%s\n' % (alt_link, alt_name, alt_target_final, alt_priority)
+alt_remove_links += '\tupdate-alternatives --remove %s %s\n' %
(alt_name, alt_target_final)
if alt_setup_links:
# RDEPENDS setup
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] dracut is impossible to run in do_rootfs
Hi, I need to create the initramfs for the target build during do_rootfs using dracut to include systemd and plymouth into it and using the modules from the kernel version the image was built with. Currently I am on Yocto 2.5. There are several problem I am facing. First, the dracut recipe needs some fixes in the RDEPENDS/RRECOMMENDS clauses to only use subpackages of the recipes it depends on in class-target only. I could fix this with a bbappend file. Then, all the packages in the system that use the update-alternatives.bbclass have unusable symlinks during the do_rootfs stage. E.g. coreutils's binaries use this: zboszormenyi@buildbox-0001 rootfs]$ ls -l usr/bin/[ lrwxrwxrwx 1 zboszormenyi zboszormenyi 27 nov 14 03.51 usr/bin/[ -> /usr/bin/lbracket.coreutils Of course, the target of the symlink does not exist on the build host. As a consequence, dracut will not find anything that it needs to copy to the initramfs. Is there a way to tell update-alternatives.bbclass (e.g. globally from my layer.conf) to just use the relative symlink it is given? Thanks in advance, Zoltán Böszörményi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] do_rootfs does not create /etc/shadow and /etc/gshadow
Hi, I have started moving my Yocto based custom OS to Yocto 2.5. The problem is that when I want to build an image, groupadd fails during the preinst of the mariadb-server package. It seems the underlying problem is that both shadow and gshadow are missing from the rootfs /etc directory, group and passwd are there. I checked that my previous Yocto 2.2 and 2.4 image builds both have these files. What has changed in Yocto 2.5 that would prevent creating shadow and gshadow in the rootfs? My layer has its own distro related configuration including a custom bitbake.conf that only minimally differs from the openembedded-core/meta one. Thanks in advance, Zoltán Böszörményi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 18/21] *proto: remove depricated xorg proto header recipes and replace by xorgproto
2018-07-12 16:54 keltezéssel, Burton, Ross írta: I guess that tells us how many people actually use xcalibrate... The breakage depends on whether you are using a repository to upgrade your machines running Yocto or bring them in and reflash with a new complete build. But anyway, it's the maintainer's call. The previous patch itself was an incompatible deviation from upstream and xinput_calibrator is usually running locally, not remotely, so it's only an obscure corner case. On 12 July 2018 at 15:07, Böszörményi Zoltán via Openembedded-core wrote: Hi, 2018-04-04 03:49 keltezéssel, Armin Kuster írta: From: Armin Kuster Signed-off-by: Armin Kuster --- .../xorg-proto/bigreqsproto_1.1.2.bb | 16 - .../xorg-proto/calibrateproto/fix.patch| 42 -- ... diff --git a/meta/recipes-graphics/xorg-proto/calibrateproto/fix.patch b/meta/recipes-graphics/xorg-proto/calibrateproto/fix.patch deleted file mode 100644 index ff8cb25..000 --- a/meta/recipes-graphics/xorg-proto/calibrateproto/fix.patch +++ /dev/null @@ -1,42 +0,0 @@ -Upstream-Status: Pending - -Add missing length fields to the replies. Without these, sanity checking in recent X -breaks things. - -RP 11/2/10 - - -Index: git/xcalibrateproto.h -=== git.orig/xcalibrateproto.h 2010-02-11 11:47:45.711985932 + -+++ git/xcalibrateproto.h 2010-02-11 11:40:21.0 + -@@ -67,13 +67,13 @@ - BYTEtype; /* X_Reply */ - BYTEpad1; - CARD16 sequenceNumber B16; -+CARD32 length; - CARD32 status; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - CARD32 pad6 B32; --CARD32 pad7 B32; - } xXCalibrateRawModeReply; - - #define sz_xXCalibrateRawModeReply32 -@@ -92,13 +92,13 @@ - BYTEtype; /* X_Reply */ - BYTEpad1; - CARD16 sequenceNumber B16; -+CARD32 length; - CARD32 x; - CARD32 y; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; --CARD32 pad6 B32; - } xXCalibrateScreenToCoordReply; - - #define sz_xXCalibrateScreenToCoordReply 32 Haven't you just introduced an incompatible change by not adding the identical patch to [PATCH 17/21] xorgproto: add replacement for depricated calibrateproto ? Best regards, Zoltán Böszörményi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 18/21] *proto: remove depricated xorg proto header recipes and replace by xorgproto
Hi, 2018-04-04 03:49 keltezéssel, Armin Kuster írta: From: Armin Kuster Signed-off-by: Armin Kuster --- .../xorg-proto/bigreqsproto_1.1.2.bb | 16 - .../xorg-proto/calibrateproto/fix.patch| 42 -- ... diff --git a/meta/recipes-graphics/xorg-proto/calibrateproto/fix.patch b/meta/recipes-graphics/xorg-proto/calibrateproto/fix.patch deleted file mode 100644 index ff8cb25..000 --- a/meta/recipes-graphics/xorg-proto/calibrateproto/fix.patch +++ /dev/null @@ -1,42 +0,0 @@ -Upstream-Status: Pending - -Add missing length fields to the replies. Without these, sanity checking in recent X -breaks things. - -RP 11/2/10 - - -Index: git/xcalibrateproto.h -=== git.orig/xcalibrateproto.h 2010-02-11 11:47:45.711985932 + -+++ git/xcalibrateproto.h 2010-02-11 11:40:21.0 + -@@ -67,13 +67,13 @@ - BYTEtype; /* X_Reply */ - BYTEpad1; - CARD16 sequenceNumber B16; -+CARD32 length; - CARD32 status; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - CARD32 pad6 B32; --CARD32 pad7 B32; - } xXCalibrateRawModeReply; - - #define sz_xXCalibrateRawModeReply32 -@@ -92,13 +92,13 @@ - BYTEtype; /* X_Reply */ - BYTEpad1; - CARD16 sequenceNumber B16; -+CARD32 length; - CARD32 x; - CARD32 y; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; --CARD32 pad6 B32; - } xXCalibrateScreenToCoordReply; - - #define sz_xXCalibrateScreenToCoordReply 32 Haven't you just introduced an incompatible change by not adding the identical patch to [PATCH 17/21] xorgproto: add replacement for depricated calibrateproto ? Best regards, Zoltán Böszörményi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
