On 6/23/26 4:12 PM, Mathieu Dubois-Briand via lists.openembedded.org wrote:
On Tue Jun 23, 2026 at 1:21 PM CEST, Antoine Gouby via lists.openembedded.org
wrote:
From: Antoine Gouby <[email protected]>
mesa.inc is shared by both mesa.bb and mesa-gl.bb. The variable
INSANE_SKIP:${PN}-megadriver expands to mesa-gl-megadriver when
included by mesa-gl.bb, but the package is always named mesa-megadriver
(hardcoded via PACKAGES =+). The skip therefore had no effect for
mesa-gl builds.
This was hidden until mesa 26.1.0 removed the with_gbm condition from
the dril subdir build, causing mesa-gl to now install DRI driver
symlinks into mesa-megadriver for the first time.
Use the hardcoded package name, consistent with the three RREPLACES/
RCONFLICTS/RPROVIDES lines right below.
Signed-off-by: Antoine Gouby <[email protected]>
---
Hi Antoine,
Thanks for your patch.
This is now producing another QA issue about these symlinks, in multilib
configuration:
ERROR: lib32-mesa-2_26.1.2-r0 do_package_qa: QA Issue: non -dev/-dbg/nativesdk-
package lib32-mesa-megadriver contains symlink .so
'/usr/lib/dri/panel-mipi-dbi_dri.so' [dev-so]
ERROR: lib32-mesa-2_26.1.2-r0 do_package_qa: QA Issue: non -dev/-dbg/nativesdk-
package lib32-mesa-megadriver contains symlink .so '/usr/lib/dri/crocus_dri.so'
[dev-so]
ERROR: lib32-mesa-2_26.1.2-r0 do_package_qa: QA Issue: non -dev/-dbg/nativesdk-
package lib32-mesa-megadriver contains symlink .so
'/usr/lib/dri/ili9225_dri.so' [dev-so]
ERROR: lib32-mesa-2_26.1.2-r0 do_package_qa: QA Issue: non -dev/-dbg/nativesdk-
package lib32-mesa-megadriver contains symlink .so
'/usr/lib/dri/gm12u320_dri.so' [dev-so]
ERROR: lib32-mesa-2_26.1.2-r0 do_package_qa: QA Issue: non -dev/-dbg/nativesdk-
package lib32-mesa-megadriver contains symlink .so
'/usr/lib/dri/rcar-du_dri.so' [dev-so]
https://autobuilder.yoctoproject.org/valkyrie/#/builders/92/builds/3975
Can you have a look at the issue?
Likely simply
INSANE_SKIP:${MLPREFIX}mesa-megadriver += "dev-so"
?
I'm wondering if we also need something for PACKAGES_DYNAMIC for
multilib as well (and RREPLACES, RCONFLICTS, RPROVIDES, etc....). I
really dislike packages which don't use ${PN} in their name, a lot of
headaches are avoided by simply using ${PN} but I guess that ship has
sailed already.
Cheers,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#239404):
https://lists.openembedded.org/g/openembedded-core/message/239404
Mute This Topic: https://lists.openembedded.org/mt/119938865/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
