**** BEGIN LOGGING AT Sun Feb 13 02:59:56 2022 Feb 13 10:24:47 denix: is this https://pastebin.com/vMPLjdct also related? Feb 13 12:41:51 denix: I can't tell from that fragment Feb 13 12:49:03 denix: forget about mine btw, I caused that myself trying to get rid of similiar errors Feb 13 13:50:04 in a multiconfig build with the same workdir I end up with two different run.do_package_write_ipk for the same recipe, they only differ by the order of the needed python functions. Is that expected behaviour? Feb 13 18:17:09 RP: /wrt the missing uboot_env dependency in kernel-fitimage.bbclass, thanks Feb 13 18:47:09 RP: cooker log for the error above - https://pastebin.com/ZyyNH5qu Feb 13 18:48:13 RP: util-linux-native had do_populate_sysroot and do_populate_sysroot_setscene Feb 13 19:56:38 denix: yes, that looks like the same issue :( Feb 13 19:59:10 RP: happen to know how the functions in run.do_package_write_ipk can get reordered? Feb 13 20:00:53 from a while back: "in a multiconfig build with the same workdir I end up with two different run.do_package_write_ipk for the same recipe, they only differ by the order of the needed python functions. Is that expected behaviour?" Feb 13 20:01:53 I would assume it is not, since hashes start to differ and they start to run in parallel Feb 13 20:02:13 jeroen_: which functions specifically ? Feb 13 20:03:24 jeroen_: are the hashes for the tasks the same or not? Feb 13 20:04:01 the order of the functions shouldn't matter as that wouldn't change the task checksum Feb 13 20:05:58 read_subpackage_metadata and do_package_ipk.. Feb 13 20:06:31 jeroen_: whilst we probably should fix the ordering in that file, it almost certainly isn't your build issue :/ Feb 13 20:06:53 jeroen_: Have a look at the sigdata files in stamps and see what the difference is in them Feb 13 20:07:04 bitbake-diffsigs Feb 13 20:07:46 well at least here is the problem, https://pastebin.com/xAm8hgeD Feb 13 20:08:08 private pastebin? Feb 13 20:08:16 there is typically only one sigdata file.. Feb 13 20:09:02 that is odd then :( Feb 13 20:09:16 I can look again, but since I have tried to debug this, I likely have many by now, so better to check that once I have a clean build again Feb 13 20:09:50 jeroen_: if one of the tasks fails, it probably won't write the file out. Feb 13 20:10:11 jeroen_: you could use -S none to force it to write out all the stamp data files Feb 13 20:10:23 RP: no, not private, just hit refresh I guess.. Feb 13 20:10:49 jeroen_: pending moderation then Feb 13 20:12:56 RP: I am suprised how this works, "the order of the functions shouldn't matter as that wouldn't change the task checksum", the write_ipk functions are part of the sigdata..? Feb 13 20:13:26 jeroen_: the run files are debug output and aren't ordered. The code writing out the sigdata files is much more careful Feb 13 20:16:25 jeroen_: well, let me be more clear. The shell ones are run and carefully ordered. The python ones are just comsmetic, never run Feb 13 20:16:40 That task is a python one Feb 13 20:16:43 ok, I will check it tomorrow, but for some magic reason (to me) I have the write_ipk task run in parallel, which isn't going to work.. Feb 13 20:17:52 jeroen_: well, I'm just trying to help by saying what I do/don't know about how bitbake works Feb 13 20:18:22 * RP did write the code which generates those run files, both python and shell, as well as the code which generates the sigdata files Feb 13 20:18:35 RP: oh don't get me wrong, your help is appreciated.. Feb 13 20:23:11 RP: just for completeness, before I call it the day, it are not the bb.build.exec_func which aren't sorted in order but the functions they need. Feb 13 20:26:36 jeroen_: you're saying that in the run file, the functions read_subpackage_metadata and do_package_ipk are sometimes listed in one order and sometimes in the other but the order of the exec_func calls in do_package_write_ipk is always correct? Feb 13 20:33:56 jeroen_: the entries in the run file are probably "unsorted" from the dict inside python. The signatures are generated through a sorted() call so wouldn't have that issue Feb 13 21:44:37 rburton, jonmason: another qemuarm64 ltp hang: https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/2782 **** ENDING LOGGING AT Mon Feb 14 02:59:56 2022