linux/meta-freescale.git/dynamic-layers, branch master

opencv: Document i.MX-fork LIC_FILES_CHKSUM override for oelint

2026-08-17T21:17:04+00:00

opencv_4.13.0.imx.bb is the i.MX fork of the meta-openembedded recipe: its top section is a verbatim copy of meta-oe (see the "meta-openembedded copy" / "Upstream hash" header), and the "i.MX overrides" section re-sets LIC_FILES_CHKSUM. Setting it in both sections trips oelint.var.override. Rewriting or dropping the copied assignment would diverge from the meta-oe recipe the block mirrors and reappear on the next re-sync. Annotate the copied LIC_FILES_CHKSUM with an inline "# nooelint: oelint.var.override" (UPSTREAM-PARITY) instead, matching the weston, gstreamer and libcamera i.MX forks. Comment-only change; no recipe output is affected. Signed-off-by: Luciano Dittgen

opencv: Document FILES overrides per oelint.var.filesoverride

2026-08-14T14:04:09+00:00

oelint.var.filesoverride flags six FILES assignments in this recipe. All are intentional and correct as written, so document each with an inline # nooelint rather than rewriting it: - ${PN} is intentionally empty (ALLOW_EMPTY:${PN}), with everything split into the sub-packages and the PACKAGES_DYNAMIC libopencv-* packages. - -dev is deliberately curated to headers/pkgconfig/cmake because the per-library dev symlinks ship via those dynamic packages; += would re-add the default ${libdir}/*.so and pull them out of the dynamic packages. - -apps, -java, -samples and python3-opencv are recipe-specific split packages with no default FILES, so '=' is a complete definition. These lines are kept byte-identical to meta-oe opencv_4.13.0.bb to avoid drift in this .imx fork. No functional change. Tested with opencv on imx8mp-lpddr4-evk; buildhistory unchanged. Signed-off-by: Luciano Dittgen

libvirt: Order SRC_URI before PACKAGECONFIG per oelint.var.order

2026-08-11T13:14:40+00:00

Variable-definition order among lazily assigned variables does not affect BitBake expansion, so this is behaviour-preserving. Confirmed by a normalized full-layer oelint rescan introducing no new findings. Verified behaviour-preserving: expanded metadata (bitbake -e) unchanged vs master. Signed-off-by: Luciano Dittgen

weston-init: Stop the IVI weston.ini replacing oe-core's everywhere

2026-08-07T12:30:01+00:00

The IVI bbappend is a single FILESEXTRAPATHS:prepend line, and the directory it adds holds a top-level weston.ini. oe-core's weston-init.bb fetches "file://weston.ini" unconditionally, so prepending that path for every machine made NXP's IVI configuration -- shell=ivi-shell.so, hmi-controller.so and ten [ivi-launcher] blocks -- silently replace oe-core's weston.ini on every machine in any build that also has meta-ivi, i.MX or not. Scope the prepend to imx-generic-bsp. The layer already does this where a file would otherwise be picked up too widely: waffle uses FILESEXTRAPATHS:prepend:imxgpu and pulseaudio uses FILESEXTRAPATHS:prepend:imx-nxp-bsp. This is the one FILESEXTRAPATHS line in the layer that needed scoping. The other eighteen are safe unscoped precisely because their directories contain no top-level file that the upstream recipe also fetches -- checked, rather than assumed, across all of them. NOT VALIDATED: meta-ivi is not checked out in this workspace, so this bbappend is not parsed here and the change could not be measured the way the other fixes in this series were. The reasoning is structural -- the file listing, oe-core's SRC_URI, and a diff of the two weston.ini files -- and it needs confirming in a tree that has meta-ivi. Signed-off-by: Luciano Dittgen

oelint: Suppress noncoreoverride on the machine-gated bbappend idiom

2026-08-07T12:30:00+00:00

oelint.vars.noncoreoverride flags every statement in a bbappend that carries no MACHINE or DISTRO override suffix, because an unconditional override of core behaviour fails yocto-check-layer. The check is purely syntactic: it cannot see that a statement's effective value is already machine-gated, which is exactly how most of this layer is written. DRM-REMOVE = "" <- flagged DRM-REMOVE:imxgpu:mx6-nxp-bsp = "drm-gl drm-gles2" PACKAGECONFIG:remove = "${DRM-REMOVE}" <- flagged Neither line can be scoped. A fallback default cannot carry an override for the machines it is the fallback for, and the dispatch line that consumes it is a no-op wherever the helper expands empty. Scoping them anyway would damage correct metadata: weston-init reads HAS_G2D as "elif ${HAS_G2D};" in shell, where an empty value is a syntax error. Suppress the 58 sites proven inert, each with its own rationale. The proof is a bitbake -e comparison on MACHINE=qemuarm64 -- a machine this layer does not own -- with meta-freescale in and out of BBLAYERS. At every suppressed site SRC_URI, DEPENDS, PACKAGECONFIG, OPENGL_PKGCONFIGS and REQUIRED_DISTRO_FEATURES are unchanged; eight recipes show no effective difference at all. The helper variables are defined in the datastore but every consumer is override-scoped. For the 18 FILESEXTRAPATHS sites there is a stronger result: FILESPATH and FILESEXTRAPATHS are both in BB_BASEHASH_IGNORE_VARS, so they cannot reach a task signature. Two anonymous python blocks are deliberately left unsuppressed and explained in place instead. For those, oelint anchors the finding to the line before the block, so a directive placed above only moves the anchor onto itself: the finding survives and inlinesuppress_na is reported for the directive. oelint.task.noanonpython anchors the same block to the 'python' line and suppresses correctly, so the two rules disagree about where the construct starts. Upstream oelint bug candidate. The rule count goes 76 -> 18 and the layer total 548 -> 491. The 16 findings that remain are not noise: they are measured, genuine unconditional changes to machines this layer does not own, and are left open for separate fixes. This change is comment-only; no non-comment line is added or modified. Validated with bitbake -p (1166 recipes, 0 errors) and an authoritative driver rescan showing zero introduced findings in any of the 24 edited files. The residual override/outofcontext churn in the rescan is the known shared-metadata scan non-determinism and nets to zero. Signed-off-by: Luciano Dittgen

fmc: Drop the dead class-native EXTRA_OEMAKE override

2026-08-07T12:29:59+00:00

fmc_git.bb sets no BBCLASSEXTEND and does not inherit native, so the EXTRA_OEMAKE:class-native variant carrying FMCHOSTMODE=1 can never be selected. This is the same dead override removed from spc_git.bb, which shares the recipe shape line for line. The remedy oelint.vars.inappclassoverride documents -- declaring BBCLASSEXTEND = "native" -- is not available here either: DEPENDS lists fmlib, and fmlib_git.bb sets no BBCLASSEXTEND of its own, so there is no fmlib-native for an fmc-native to build against. The validation here is weaker than for spc, and is stated rather than implied. This recipe lives under dynamic-layers/openembedded-layer and meta-openembedded is not part of this build tree, so it is not parsed in this configuration and no bitbake -e capture was taken for it. The evidence is the layer-wide oelint-adv 9.10.1 rescan, which clears the finding and introduces none, together with the byte-identical removal shown inert on spc_git.bb. Signed-off-by: Luciano Dittgen

packagegroups: Correct the dependsordered suppression rationale

2026-08-07T12:29:55+00:00

Both packagegroups suppress oelint.vars.dependsordered on RDEPENDS:${PN}, and oelint reports oelint.file.inlinesuppress_na against both, claiming the suppression is not needed. It is needed: removing either line makes oelint.vars.dependsordered fire again on the same file set, with the same analyzer version and configuration, reported as [branch:true]. oelint 9.10.1 therefore contradicts itself here -- inlinesuppress_na does not account for branch-conditional findings. Keep both suppressions and record the trap, so the next reader does not drop a load-bearing line on the strength of that report. While here, correct the stated mechanism. The entries are not mis-sorted by a tokenizer: they are grouped conditional ${@...} first and then alphabetically, and oelint sorts the expanded branch:true form, in which the conditional entries land out of order. RDEPENDS ordering has no build effect, so the readable grouping is kept. Comment-only change. Verified with oelint-adv 9.10.1 (finding set unchanged) and bitbake -p (1166 recipes, 0 errors). Signed-off-by: Luciano Dittgen

opencv: Correct the patch header metadata

2026-08-03T19:29:57+00:00

Five of the carried patches used "Inappropriate [i.MX specific]", which is not one of the recognised reasons, so oelint.file.inappropriatemsg fired on the recipe. Use [embedded specific], which oelint accepts and which this layer already uses elsewhere. Only the headers change; the diffs are untouched. The two HoughLines patches also trip oelint.file.patchsignedoff, and that one is suppressed rather than fixed. A Signed-off-by is a certification the signer makes about their right to submit the code, so it can be neither invented for the author named in the From: header nor supplied by whoever happens to carry the patch downstream. These two arrived through f95346d4 ("opencv: imx: update the i.mx fork to 4.13.0") already without one, and their upstream submission could not be located to recover it. There is nothing here for this layer to correct, so the finding is marked as such in place. The suppression sits on the SRC_URI block and therefore covers every patch listed in it, not just these two; the comment says so, since a future patch added there without a sign-off will not be reported either. 0001-Use-Os-to-compile-tinyxml2.cpp.patch is deliberately left alone. It belongs to the marked "meta-openembedded copy" block of this recipe and its header is byte-identical to meta-openembedded's own copy, which still reads "[ OE-Specific ]". Rewriting it here would only make the file differ from upstream; that fix belongs in meta-openembedded, so the finding stays visible. Signed-off-by: Luciano Dittgen

opencv: Install the sample binaries instead of copying them

2026-08-03T19:13:00+00:00

The i.MX do_install:append placed the compiled example_* programs into ${datadir}/opencv4/samples/bin with "cp -f", so their mode came from the build tree filtered through the building user's umask instead of being stated by the recipe. They are executables, so install them 0755. The two neighbouring "cp -r" calls are left alone: they copy directory trees of sample and test data, which install cannot express. This block sits inside the recipe's i.MX override section, so the change does not add drift against the meta-openembedded recipe. Resolves an oelint.task.nocopy finding. Validation: - Built opencv on an i.MX 8M target as a bound baseline/candidate pair, with do_install forced so the task could not be served from sstate - Buildhistory and a full ${D}/${PKGDEST} snapshot are identical on both sides; the 443 example_* binaries are 0755 either way, so the recipe now states the mode the build tree was already producing rather than inheriting it from the builder's umask - opencv needs an out-of-tree meta-openembedded to build at all, so this is not a configuration the layer ships Signed-off-by: Luciano Dittgen

opencv: Drop the redundant leading space in SRC_URI overrides

2026-08-03T19:13:00+00:00

oelint.vars.notneededspace flagged three SRC_URI assignments in the i.MX fork whose value opens with a space before the line continuation. None of them needs it: - SRC_URI += already inserts a separating space between the old and the appended value, so the extra one only produced a double space. - SRC_URI:remove and SRC_URI:prepend values are whitespace-split by BitBake, so a leading space is not significant. The trailing space on the SRC_URI:prepend value is deliberately kept: :prepend is a plain string concatenation, so that space is what separates the prepended entries from the pre-existing SRC_URI, and removing it would join two URLs into one. These three lines are i.MX-fork-local (they exist purely to swap the upstream tag for IMX_BASE_VERSION), so the change does not add drift against the meta-openembedded recipe. Validation: oelint-adv rescan of the recipe; oelint.vars.notneededspace is absent afterwards. The expanded value of SRC_URI is unchanged apart from collapsed inter-entry whitespace, which BitBake discards when it splits the variable. Signed-off-by: Luciano Dittgen