Re: Error logging broken with next?

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

On 19.05.22 08:01, Jan Kiszka wrote:
> On 17.05.22 15:42, Anton Mikanovich wrote:
>> 17.05.2022 15:35, Anton Mikanovich wrote:
>>> 13.05.2022 19:49, Jan Kiszka wrote:
>>>> Hi,
>>>>
>>>> I vaguely recall that you, Baurzhan, told me that logs of failing tasks
>>>> are not always dumped, right? I'm on current next now, building breaking
>>>> kernels, and all I get now is our useless python backtrace, always. All
>>>> is fine with log.do_dpkg_build, though. Is that the issue? Very annoying
>>>> and a no-go for CI. No time to bisect ATM, unfortunately.
>>>>
>>>> Jan
>>>>
>>> Hello,
>>>
>>> Thanks for reporting.
>>> I've reproduced the issue on the latest next and also see the full log
>>> is still there on v0.8
>>> Will try to bisect to find the reason (bitbake update?).
>>>
>> So, that's all about
>> https://github.com/openembedded/bitbake/commit/cf864cd84172f605b0e1777c3defc000fa3a7379
>>
>> (included in bitbake 1.50.4)
>>
> 
> So, already "bitbake ... | cat" causes this issue? Is there any command
> line option that avoids this? I wonder what kas could do here without
> breaking older versions. And why no one reported this so far from kas'
> OE community.
> 

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

-- 
Siemens AG, Technology
Competence Center Embedded Linux