intel-corei7-64 core-image-sato built with meta-intel and PACKAGE_CLASSES ?= "package_rpm" fails to include the package libva-intel-driver in the image. The same build with PACKAGE_CLASSES ?= "package_ipk" does include libva-intel-driver. I'm filing this in oe-core because the meta-intel stuff seems to work correctly: * based on "bitbake -e", va-intel RDEPENDS on libva-intel-driver (and va-intel does end up on the image) * MACHINE_FEATURES has "va-impl-intel", IMAGE_FEATURES has "hwcodecs"
va-intel.spec looks like this: --- Summary: va-intel version 1.0-r1 Name: va-intel Version: 1.0 Release: r1 License: MIT Group: base Packager: Poky <poky@yoctoproject.org> BuildRequires: virtual/libc BuildRequires: virtual/x86_64-poky-linux-compilerlibs BuildRequires: virtual/x86_64-poky-linux-gcc Requires: libva Requires: libva-intel-driver %description Video Acceleration Add-ons for Intel BSPs %files %defattr(-,-,-,-) --- yet when I check on the image: --- # rpm -q --requires va-intel libva rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 ---
The image seemsto pick core2_64 version of the va-intel package even though bitbake built the corei7_64. Starting from empty TMPDIR: $ MACHINE=intel-corei7-64 bitbake core-image-sato $ MACHINE=qemux86-64 bitbake core-image-sato $ MACHINE=intel-corei7-64 bitbake -ccleansstate core-image-sato $ MACHINE=intel-corei7-64 bitbake core-image-sato The first and last images will have completely different manifests: the first one has 0 core2_64 packages, the last one has 583 core2_64 packages. (the above doesn't actually show the va-intel problem because va-intel doesn't get built for qemux86-64 by default, but the reasons are the same)
PACKAGE_ARCHS="all any noarch x86_64 core2-64 corei7-64 corei7-64-intel-common intel_corei7_64" So apparently PACKAGE_ARCHS is supposed to be ordered (right-most first), and dnf does not seem to do that.
(In reply to comment #3) > PACKAGE_ARCHS="all any noarch x86_64 core2-64 corei7-64 > corei7-64-intel-common intel_corei7_64" > > So apparently PACKAGE_ARCHS is supposed to be ordered (right-most first), > and dnf does not seem to do that. The architectures' whitelist is written into rootfs/etc/dnf/vars/arch. What happens if you reverse it?
(In reply to comment #4) > The architectures' whitelist is written into rootfs/etc/dnf/vars/arch. What > happens if you reverse it? This did the trick: correct packages are now getting installed into the rootfs in all my test cases. I've sent a patch so I guess I'll take the bug for now... Let's see if I end up regretting this.
commit adea8003abe383b9bc532ac5477bc274e270c19a Author: Jussi Kukkonen <jussi.kukkonen@intel.com> Date: Wed Apr 19 16:25:57 2017 +0300 package_manager.py: Reverse rpm arch order The architecture list used by dnf/libsolv was in the wrong order. As a result, the images were built with wrong and unpredictable packages. $ MACHINE=intel-corei7-64 bitbake core-image-sato $ MACHINE=qemux86-64 bitbake core-image-sato $ MACHINE=intel-corei7-64 bitbake -ccleansstate core-image-sato $ MACHINE=intel-corei7-64 bitbake core-image-sato The first image had 0 core2_64 packages in it, but the last one had 583 core2_64 packages (which were built for the qemu image in between). Reverse the arch order in etc/dnf/vars/arch. Fixes [YOCTO #11384]. (From OE-Core rev: 4a82433de42943f8219beca3286f40b67157172f) Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>