Re: Error logging broken with next?

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

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.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux