On Fri, 25 Jan 2019 at 16:38, Richard Purdie <[email protected]> wrote: > > > There is a similar issue in multilib for target packages (a warning > > > because qemu usermode support is missing): > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/214/steps/7/logs/warnings > > > > > > I'm as well not sure how to handle this: > > > 1. Keep these two warnings as warnings so users see them in their > > > local builds, but > > > add some kind of string pattern to AB so it excludes missing qemu > > > support and missing wine support warnings. > > > > > > 2. Turn them into notes, which means they will go to the logs only, > > > and users are not going to see them ever. On the other hand, the > > > postinsts tend to > > > create things like font caches and similar, which should not > > > generally > > > be needed at compile time (which is what SDKs are for). > > > > > > I'm leaning towards option two. > > > > I was leaning toward keeping them warnings and then suppressing them in > > the cases where we know they don't work and are unnecessary (perhaps > > with a variable like POSTINST_INTERCEPT_${PN} = "0" ?) > > > > That way if a user enables a package where it's not going to run and we > > haven't previously evaluated it to be OK, they will at least see the > > warning. I naively think this might help reduce the number of bugs > > filed, or at least make them easier to triage :) > > I think this may be safer...
The postinst_intercepts are not executed per package (and accordingly can't be suppressed in that manner), they are run as a set of scripts available in scripts/postinst-intercepts/ during "populate_sdk" phase for an image. I have sent a patch where both specific failures are turned from warning to note (mingw, populating the target sysroot for nativesdk) - both should be actually okay to suppress, as a) mingw case never worked and has not been a problem as Joshua says; b) target nativesdk sysroot should not be a problem either, as it will be used just to build stuff, in a way similar to target Yocto builds, where those intercept scripts are not executed either, at least not until we populate a rootfs for the final image - and this has not been an issue for anyone. The scripts all create some kind of 'caches' which are only needed at runtime really. Hope this helps, Alex -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
