Re: [meta-ti] [PATCH] mesa-pvr: correct INSANE_SKIP for mesa-megadriver
Rasmus Villemoes <[email protected]>
| Newsgroups | org.yoctoproject.lists.meta-ti |
|---|---|
| Organization | Prevas |
| Message-ID | <[email protected]> |
On Tue, Jul 28 2026, "Rasmus Villemoes via lists.yoctoproject.org" <[email protected]> wrote: > On Mon, Jul 20 2026, Denys Dmytriyenko <[email protected]> wrote: > >> On Mon, Jul 20, 2026 at 09:14:42AM +0200, Rasmus Villemoes via lists.yoctoproject.org wrote: >>> On Fri, Jul 17 2026, Ryan Eatmon <[email protected]> wrote: >>> >>> > On 7/17/2026 7:48 AM, Rasmus Villemoes via lists.yoctoproject.org wrote: >>> >> In the original file this was copied from, $PN == mesa. But in this >>> >> context, $PN == mesa-pvr, while the PACKAGES and FILES logic still >>> >> explicitly refers to the mesa-megadriver package. Hence the build >>> >> fails >>> >> >>> > >>> > Good catch. I wonder why we are not seeing these QA errors in our >>> > builds. Are you turning something special on? >>> >>> No, not that I know of. I hit this immediately when trying to update >>> from whinlatter to wrynose, but I don't think we have any special flags >>> set anywhere that should increase bitbake warning/pedantic level or >>> something like that. >> >> It's not about warning or pedantic level. It's rather about how you have >> mesa and the entire distro configured. Because we don't have any of those >> 4 libraries in /usr/lib/dri/ being built, as we only build for Wayland, but >> not X11. >> >> PACKAGECONFIG="gallium video-codecs vulkan wayland opengl egl gles gbm virgl opencl libclc gallium-llvm zink xmlconfig gallium-llvm" >> DISTRO_FEATURES="pam opencl systemd usrmerge 3g acl alsa bluetooth debuginfod ext2 gobject-introspection-data ipv4 ipv6 ldconfig multiarch nfc nfs opengl pci pulseaudio seccomp vfat vulkan wayland wifi xattr zeroconf" >> DISTRO_FEATURES_OPTED_OUT="ptest x11" >> >> Might want to compare these to your settings. >> >> Anyway, your fix is correct - this is just an explanation for why we are not >> seeing the error in our builds. > > Thanks. > > Any chance this could be applied/backported to wrynose? Ping. I see it in wrynose-next / wrynose-wip, but not in wrynose proper. This is blocking our upgrade to wrynose. Rasmus