linux/meta-intel.git, branch master

libva-intel-utils: fix mpeg2vldemo build with GCC 16

2026-06-10T03:52:36+00:00

GCC 16 defaults to C++20 and rejects the mixed designated/non-designated clauses in the VAPictureParameterBufferMPEG2 initializer. Backport the upstream fix (commit 5fcab2d02c5a), adapted to the v2.22 release branch which uses GNU colon-style designators. Signed-off-by: Yogesh Tyagi

intel-compute-runtime: fix build with GCC 16

2026-06-10T03:52:36+00:00

Newer GCC (16.x) no longer pulls in some standard headers transitively, breaking the build. For ULONG_MAX, backport the upstream commit that switches to std::numeric_limits (0004). For the remaining fixed-width integer uses, add the missing includes (0005, 0006). Also relax the new -Wsfinae-incomplete diagnostic so -Werror does not fail. Signed-off-by: Yogesh Tyagi

recipes-support: intel-crypto-mb: avoid Werror failure on SM4

2026-06-01T09:33:52+00:00

Signed-off-by: Yogesh Tyagi

linux-intel/linux-intel-rt: bump SRCREV_meta to fbc4b73674ba

2026-05-20T04:19:46+00:00

Update kernel meta SRCREV for 6.18.15 to pick up latest kernel-cache updates. Signed-off-by: Yogesh Tyagi

intel-oneapi-toolkit: split mkl and ipp into runtime/sycl/staticdev/dev sub-packages

2026-05-17T15:00:25+00:00

The 2026.0 oneAPI MKL component grew to 1.9 GB on disk, dominated by ~900 MB of static archives, ~330 MB of SYCL/GPU offload libraries and ~80 MB of headers / cmake metadata / sample sources. The IPP component similarly carries ~280 MB of static archives on top of a 537 MB runtime payload. Consumers that only need a CPU BLAS/FFT backend (PyTorch CPU, NumPy, image-processing pipelines) were paying for all of it whenever they installed intel-oneapi-toolkit-mkl or intel-oneapi-toolkit-ipp. Split the two heaviest components along the usual runtime/dev/static seams: intel-oneapi-toolkit-mkl CPU shared libs + dispatch libraries + env/etc/bin glue (~640 MB) intel-oneapi-toolkit-mkl-sycl SYCL / GPU offload shared libs (~330 MB, RDEPENDS -runtime) intel-oneapi-toolkit-mkl-staticdev Static archives, lib/*.a (~900 MB) intel-oneapi-toolkit-mkl-dev Headers, cmake modules, pkgconfig files, share/ examples (~85 MB) intel-oneapi-toolkit-ipp ipp + ippcp runtime shared libs (~540 MB) intel-oneapi-toolkit-ipp-staticdev Static archives (~280 MB) intel-oneapi-toolkit-ipp-dev Headers, cmake, pkgconfig, share PACKAGES ordering places the specific sub-sub-packages before the catch-all component package so first-match-wins puts the heavyweight bits in their dedicated package. FILES patterns use [0-9]* to match the versioned directory only (the sibling 'latest' compatibility symlink is captured by the parent component package). RDEPENDS form a closed chain: -dev depends on the runtime package, -staticdev on -dev, -sycl on -runtime + the CPU runtime, so users that explicitly install a sub-sub-package still get a working environment. The top-level meta-package RDEPENDS:${PN} continues to pull all of the new sub-packages, so an image that asks for the unqualified intel-oneapi-toolkit recipe is unchanged. Signed-off-by: Yogesh Tyagi Tested-by: Zoltán Böszörményi

libipt: drop pttc nasm patch and runtime QA case

2026-05-12T15:28:51+00:00

The 0001-pttc-use-nasm-instead-of-yasm.patch local patch reworked upstream pttc to invoke nasm in place of the unmaintained yasm assembler. The patch was submitted upstream (https://github.com/intel/libipt/pull/120) but has not been merged, and carrying it locally is the only reason meta-intel needs to diverge from a pristine stable/v2.2 checkout. Drop the patch and let pttc fall back to upstream's stock yasm-based behaviour. This matches what Fedora/RHEL already does for the libipt package: ship libipt without yasm support and let libipt's own CMake skip the yasm-driven ptt tests automatically when yasm isn't available. Native nasm support in pttc remains a future upstream enhancement; when it lands we can revisit and re-add a runtime case that exercises pttc end-to-end against nasm. The libipt runtime test (lib/oeqa/runtime/cases/libipt.py) gated on the 'nasm' package and ran pttc on the shipped sample .ptt files. With the patch removed pttc invokes yasm at runtime, so the test would fail on every DUT (yasm is not pulled in as an RDEPENDS anywhere in meta-intel). The test exercised pttc/ptdump end-to-end, not the libipt library itself, and library coverage is provided indirectly by anything that links against libipt2; the runtime case has no remaining utility once the assembler-substitution patch is gone. No change to the recipe's PACKAGES, FILES, or EXTRA_OECMAKE: the libipt-test sub-package still ships pttc, ptdump, ptseg and the .ptt sample sources under ${bindir}/libipt for any user that installs yasm out-of-band and wants to drive pttc manually. This matches the Fedora libipt RPM behaviour. Signed-off-by: Yogesh Tyagi

intel-vaapi-driver: drop archived i965 VA-API backend

2026-05-12T15:12:44+00:00

Upstream https://github.com/intel/intel-vaapi-driver was archived in May 2024 and no longer receives fixes. The i965 driver targeted Gen4-Gen9 Intel GPUs and has been functionally superseded on Gen8+ hardware by intel-media-driver (iHD), which is already the VA-API backend used by every meta-intel BSP machine that ships modern graphics. Remove the recipe, its runtime test case, the maintainer entry, and the only in-tree consumer (intel-core2-32's MACHINE_HWCODECS, which now keeps just the gstreamer1.0-plugins-bad codec set since no maintained VA-API backend supports that legacy 32-bit Core 2 hardware anyway). Recipes / files removed: * recipes-multimedia/libva/intel-vaapi-driver_2.4.1.bb * lib/oeqa/runtime/cases/intel_vaapi_driver.py Other changes: * conf/machine/intel-core2-32.conf: drop intel-vaapi-driver from MACHINE_HWCODECS * conf/include/maintainers.inc: drop pn-intel-vaapi-driver entry Signed-off-by: Yogesh Tyagi

intel-oneapi: drop obsolete standalone component recipes

2026-04-29T15:10:40+00:00

Remove the per-component apt-package recipes superseded by the unified intel-oneapi-toolkit_2026.0.0.198.bb recipe, which packages the same components as sub-packages of a single offline installer (intel-oneapi-toolkit-{compiler,runtime,mkl,tbb,dpl,ipp,...}). Consumers should reference the canonical toolkit sub-package names directly. Recipes removed: * intel-oneapi-dpcpp-cpp_2024.0.0-49819.bb * intel-oneapi-dpcpp-cpp-runtime_2024.0.0-49819.bb * intel-oneapi-mkl_2024.0.0-49656.bb * intel-oneapi-ipp_2021.10.0-653.bb * setup-intel-oneapi-env_2023.0.0-25370.bb (and its intel-oneapi-runtime.conf helper) The setup-intel-oneapi-env helper installed a single ld.so.conf.d snippet pointing the dynamic loader at /opt/intel/oneapi/lib (and lib/intel64, lib/ia32, lib/emu). It dates back to the 2023.0 oneAPI layout. The unified toolkit installs libs under per-component directories such as /opt/intel/oneapi/{compiler,mkl, tbb,...}/2026.0/lib, not the flat /opt/intel/oneapi/lib that the conf file targets, so the ld.so.conf entries no longer point at real directories. Loadability of oneAPI binaries on the target is provided by: * setvars.sh / per-component env/vars.sh sourcing (the canonical Intel-supported entry point that every test and example uses) * $ORIGIN-relative RUNPATH baked into the shipped shared objects by the Intel installer * /etc/OpenCL/vendors/intel-cpu.icd written by the unified toolkit recipe's do_install for ICD loader discovery * virtual-opencl-icd / level-zero-loader RDEPENDS on intel-oneapi-toolkit-runtime for the OpenCL / Level Zero loaders The setup-intel-oneapi-env filename version (2023.0.0-25370) was a stale carry-over from when the recipe was first added; nothing in the recipe ever referenced ${PV}. Signed-off-by: Yogesh Tyagi

packagegroup-sdk: switch ICXSDK to intel-oneapi-toolkit sub-packages

2026-04-29T13:51:34+00:00

The 2024.0 standalone recipes provided per-component package names (intel-oneapi-dpcpp-cpp{,-dev}, intel-oneapi-dpcpp-cpp-runtime{,-dev}) that have been replaced in the unified intel-oneapi-toolkit_2026 recipe by the canonical sub-package layout. Update the SDK host and target packagegroup bbappends to reference the new names directly: intel-oneapi-toolkit-compiler - C/C++/SYCL compiler + headers intel-oneapi-toolkit-runtime - shared runtime libraries The toolkit-compiler sub-package already contains the headers and CMake/pkg-config files the prior *-dev sub-packages exposed, so a separate -dev append is no longer needed. Signed-off-by: Yogesh Tyagi

intel-oneapi-toolkit: add unified 2026.0.0.198 recipe

2026-04-29T13:51:34+00:00

Intel oneAPI 2026.0 ships the former Base and HPC toolkits as a single offline self-extracting installer instead of as the per- component apt packages used in the 2021/2024 layout. Add a recipe that consumes intel-oneapi-toolkit-2026.0.0.198_offline.sh via a pseudo-free do_unpack_vendor task and stages /opt/intel/oneapi into the rootfs. The recipe partitions the installed tree into sub-packages along component boundaries: intel-oneapi-toolkit-{compiler,runtime,mkl, tbb,dpl,debugger,ipp,ccl,vtune,common,licensing}. Consumers should reference these canonical sub-package names directly rather than the per-component apt names that the 2021/2024 standalone recipes exposed. The runtime sub-package additionally: * registers /opt/intel/oneapi/compiler/2026.0/lib/libintelocl.so as /etc/OpenCL/vendors/intel-cpu.icd so systems without an Intel GPU expose an Intel OpenCL platform via the standard ICD mechanism; * installs a libxml2.so.2 -> libxml2.so.16 SONAME compat symlink, because the prebuilt libcommon_clang.so / libintelocl.so are linked against the libxml2 2.x SONAME while current oe-core ships libxml2 3.x as libxml2.so.16. libxml2 3.x is API-compatible with the option-parsing surface the binaries use. The bundle is x86_64-only so COMPATIBLE_HOST is restricted. Signed-off-by: Yogesh Tyagi