Re: Error logging broken with next?

[Jan Kiszka <jan.kiszka@siemens.com>]

On 24.05.22 17:54, Jan Kiszka wrote:
> On 24.05.22 16:23, Anton Mikanovich wrote:
>> 23.05.2022 22:06, Jan Kiszka wrote:
>>> It's actually much simpler: Just call "bitbake borken-target" on the
>>> shell, and you will only get the lengthy backtrace but not log report.
>>>
>>> I'm not yet down to the core of the problem, but when you force such a
>>> failure in upstream poky (today's master), you also get no immediate
>>> output of bitbake - but then the knotty UI jumps in and does a
>>>
>>> Log data follows:
>>> | DEBUG: Executing python function extend_recipe_sysroot
>>> ...
>>> | DEBUG: Python function patch_do_patch finished
>>> | DEBUG: Executing shell function do_fix_readlib_c
>>> | FAIL!
>>> | WARNING: exit code 1 from a shell command.
>>> | DEBUG: Python function do_patch finished
>>> ERROR: Task (/poky/meta/recipes-core/glibc/glibc_2.35.bb:do_patch)
>>> failed with exit code '1'
>>>
>>>
>>> I've done this to poky to trigger it:
>>>
>>> diff --git a/meta/recipes-core/glibc/glibc_2.35.bb
>>> b/meta/recipes-core/glibc/glibc_2.35.bb
>>> index 6ea5b1efb5..9500c8a128 100644
>>> --- a/meta/recipes-core/glibc/glibc_2.35.bb
>>> +++ b/meta/recipes-core/glibc/glibc_2.35.bb
>>> @@ -91,6 +91,8 @@ do_patch:append() {
>>>   }
>>>     do_fix_readlib_c () {
>>> +    echo "FAIL!"
>>> +    false
>>>       sed -i -e
>>> 's#OECORE_KNOWN_INTERPRETER_NAMES#${EGLIBC_KNOWN_INTERPRETER_NAMES}#'
>>> ${S}/elf/readlib.c
>>>   }
>>>   Analogous trigger for isar:
>>>
>>> diff --git a/meta-isar/recipes-app/example-raw/files/rules
>>> b/meta-isar/recipes-app/example-raw/files/rules
>>> index a1167375..ed63d364 100644
>>> --- a/meta-isar/recipes-app/example-raw/files/rules
>>> +++ b/meta-isar/recipes-app/example-raw/files/rules
>>> @@ -5,4 +5,5 @@
>>>   # we do violate debian quality rules here, but on purpose to demo how
>>>   # to deal with it
>>>   override_dh_usrlocal:
>>> -    true
>>> +    echo "FAIL!"
>>> +    false
>>>
>>> So, Isar has a bug here of not letting knotty (as default UI) do its
>>> job it seems to me. Didn't this work before? Didn't we also have those
>>> duplicate dumps in the past that upstream bitbake seem to have resolved
>>> now?
>>>
>>>
>>> BTW, I've received first reports of this bug from the field today. We
>>> must fix this before the release, or our users will kill us.
>>>
>>> Jan
>>>
>> I didn't find any differences between Yocto and Isar.
>> If putting glibc_2.35.bb change example into Isar it behaves in the same
>> way
>> outputting full error log.
>> Otherwise if executing the second example in Yocto (running bash code from
>> python task with bb.build.exec_func) it will output only exception message
>> just like Isar.
>> So there are no issues in Isar itself, it behaves just like Yocto.
>> If we need to have full log printed Bitbake should be fixed.
>>
> 
> Ok, then the environment of the glibc case is not the same as our for
> the dpkg_runbuild. The latter is broken, and we need to understand how
> to restore its output in Isar - very likely not in bitbake.
> 

Just thinking loudly: Is it our try-finally that changes the output
trigger for knotty?

    try:
        bb.build.exec_func("dpkg_runbuild", d)
    finally:
        bb.build.exec_func("dpkg_undo_mounts", d)
        bb.utils.unlockfile(lock)

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux