[OE-core] [PATCH 04/10] lib/oe/package_manager: turn postinst_intercept warnings into failures for nativesdk

[Alexander Kanavin]

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.

Alex

On Fri, 25 Jan 2019 at 00:18, Joshua Watt <jpewhacker at gmail.com> wrote:
>
>
>
> On Thu, Jan 24, 2019, 4:43 PM Richard Purdie <richard.purdie at linuxfoundation.org wrote:
>>
>> On Wed, 2019-01-23 at 17:17 +0100, Alexander Kanavin wrote:
>> > The few cases where they failed should be now all fixed. The only allowed
>> > exception is when building mingw32 SDKs, as there is currently no support for running
>> > postinst_intercepts through wine.
>> >
>> > Signed-off-by: Alexander Kanavin <alex.kanavin at gmail.com>
>> > ---
>> >  meta/lib/oe/package_manager.py | 7 ++++++-
>> >  1 file changed, 6 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
>> > index 1087144d47f..f26f597d03d 100644
>> > --- a/meta/lib/oe/package_manager.py
>> > +++ b/meta/lib/oe/package_manager.py
>> > @@ -439,6 +439,11 @@ class PackageManager(object, metaclass=ABCMeta):
>> >                  self._postpone_to_first_boot(script_full)
>> >                  continue
>> >
>> > +            if populate_sdk == 'host' and self.d.getVar('SDK_OS') == 'mingw32':
>> > +                bb.warn("The postinstall intercept hook '%s' could not be executed due to missing wine support, details in %s/log.do_%s"
>> > +                                % (script, self.d.getVar('T'), self.d.getVar('BB_CURRENTTASK')))
>> > +                continue
>> > +
>> >              bb.note("> Executing %s intercept ..." % script)
>> >
>> >              try:
>> > @@ -447,7 +452,7 @@ class PackageManager(object, metaclass=ABCMeta):
>> >              except subprocess.CalledProcessError as e:
>> >                  bb.note("Exit code %d. Output:\n%s" % (e.returncode, e.output.decode("utf-8")))
>> >                  if populate_sdk == 'host':
>> > -                    bb.warn("The postinstall intercept hook '%s' failed, details in %s/log.do_%s" % (script, self.d.getVar('T'), self.d.getVar('BB_CURRENTTASK')))
>> > +                    bb.fatal("The postinstall intercept hook '%s' failed, details in %s/log.do_%s" % (script, self.d.getVar('T'), self.d.getVar('BB_CURRENTTASK')))
>> >                  elif populate_sdk == 'target':
>> >                      if "qemuwrapper: qemu usermode is not supported" in e.output.decode("utf-8"):
>> >                          bb.warn("The postinstall intercept hook '%s' could not be executed due to missing qemu usermode support, details in %s/log.do_%s"
>>
>> I'm ok with this but could we change the bb.warn to something less
>> important like a note?
>>
>> The reason I say this is that I'd like to get the autobuilder to the
>> point where its warning free. This warning is the only reason meta-
>> mingw shows warnings now. Either we fix them or if we can't, they
>> probably aren't warnings.
>>
>> What should we do here?
>>
>> (also cc'd Joshua)
>
>
> I think the one that fails currently is updating the GIO module cache. I'm not sure if this is even necessary for mingw (my guess is no, since this has never worked and no one has complained). We probably just need to disable it in mingw, but when I looked very briefly a while ago, I didn't see a straight forward way of doing that.
>
> See https://bugzilla.yoctoproject.org/show_bug.cgi?id=12962
>
>>
>> Cheers,
>>
>> Richard
>>