**** BEGIN LOGGING AT Mon Feb 21 02:59:56 2022 Feb 21 07:55:26 good morning Feb 21 08:02:35 RP: the arch trouble is caused by debian.bbclass, once that is remove most problems are gone.. Feb 21 10:59:10 RP: the arch trouble is mainly caused by debian.bbclass, once you remove that things are mostly fine. Feb 21 11:00:44 jeroen_: fair enough Feb 21 11:02:56 RP: well I doubt it is fair Feb 21 11:03:25 RP: but shall we try to improve it? Feb 21 11:04:06 jeroen_: well, it depends how. I still don't fully understand exactly what you're running into or whether my other suggestions helped or not Feb 21 11:12:02 RP: well the -S helped :) Feb 21 11:39:29 Is there some way to modify the 'rm' command that's used to clear out the dir before building? Feb 21 11:40:58 say, if you have files marked readonly in the build dir so they have to be chmodded before the rm Feb 21 12:00:53 read only files can be deleted Feb 21 12:00:58 do you mean read only directories Feb 21 12:24:28 rburton: yeah Feb 21 12:25:56 don't do that :) Feb 21 12:26:44 well I'm not the one marking the dirs as readonly Feb 21 12:27:01 but the readonly dirs exist, and I need to get bitbake to delete them Feb 21 13:06:38 assuming they're coming from a tarball, i'd do the chmod in a do_unpack[postfunc] Feb 21 13:13:03 they're coming from the go compiler downloading dependencies during do_compile Feb 21 13:41:28 mort: I am suprised that is even possible, network access is disable for non fetching tasks nowadays Feb 21 13:41:49 huh Feb 21 13:41:56 maybe it's downloaded during fetch then Feb 21 13:42:46 I don't know how the go bbclass handles go 1.11 modules Feb 21 13:43:43 jeroen_: That depends on whether your build machine supports disabling network support or not. If it doesn't, it will silently fall back to the old behavior of allowing network support for all tasks. Feb 21 13:45:32 true, or you can do this https://github.com/victronenergy/bitbake/commit/3dfe84736f315e8179b77dfbad04afe41ab215d4 Feb 21 14:33:15 I am in the illusion that a multiconfig build isn't ordering the tasks on the reference count, not a big problem, but some tasks seem to start really late, libc for a specific machine e.g. Feb 21 14:35:50 is that correct / is it simply difficult to make a global order or there is there something I can help to improve? Feb 21 15:39:18 jeroen_: that's probably a question for RP Feb 21 15:45:43 jeroen_: it all depends. If one multiconfig is more heavily referenced it would prefer to build that Feb 21 15:48:04 RP: I don't understand that, I would expect all libc for all machine to be build first. But that isn't the case. Feb 21 15:51:11 It all depends what you're configuring and asking bitbake to do. I have no idea how you have it configured so I can't really know if it is behaving optimally Feb 21 15:51:26 bitbake has no knowledge of what the tasks are or do though, it just has the taskgraph Feb 21 15:51:35 RP: ah right, I htink I get it Feb 21 15:51:36 in other words, libc isn't special Feb 21 15:54:23 RP: can we fix that? Feb 21 15:55:01 jeroen_: you want to hardcoded libc as special in bitbake? No we're not doing that. It wouldn't work with an rtos or something else (mingw?) Feb 21 15:56:10 I have done performance work before and marking some tasks as special really doesn't appear to make much difference in real world tests. That was without multiconfig though, not that I expect it to make much difference Feb 21 15:56:33 only very special recipes would be interesting (like, it would be useful to get webkit to start building sooner, as it takes forever) Feb 21 15:56:51 but i'm not in favour of the extra complication in bitbake just to get webkit to build a little earlier Feb 21 15:57:08 rburton: webkit's dependencies also mean it tends to run late :( Feb 21 15:57:25 yeah you'd have to skew the entire dependency tree Feb 21 15:57:31 an all-knowing build system would presumably schedule tasks based on how long they will take and how much depends on them Feb 21 15:57:34 in which case you can just 'bitbake webkit; bitbake myimage' Feb 21 15:57:41 mru: how does it know how long they take? Feb 21 15:57:46 also resource availability is a concern, on some hosts that damn final link of webkit takes up a solid chunk of ram of the entire system Feb 21 15:57:50 it would be much better to shorten webkit's dependency tree which would make it then happen earlier naturally Feb 21 15:57:55 sadly, no build system is all-knowing Feb 21 15:58:20 i've seen systems where webkit is built in a separate step purely because its slow and a resource hog Feb 21 15:58:55 hmm, hints like that could be taken from an earlier run Feb 21 15:58:58 mru: it'd be interesting to prototype a build that writes task time and resource usage hints and uses that in subsequent builds to attempt to optimize, but i'd wonder if it'd have much real world effect Feb 21 15:59:02 like profile-guided optimisation in gcc Feb 21 15:59:07 :) Feb 21 15:59:39 exactly what i was thinking. not sure it'd do much, though, previous attempts to add more weighting mechanisms to teh scheduler didn't have much benefit Feb 21 15:59:50 kergoth: I suspect it wouldn't help as much as you'd think. The build order is nearly entirely determined by dependencies and how long they take rather than resource contention :( Feb 21 15:59:55 £10 says the difference is negligible Feb 21 16:00:00 yep, exactly Feb 21 16:00:34 I was amazed how all my attempts to try and improve this with all kinds of tricks inevitably made it slower! Feb 21 16:00:37 time is better spent on keeping builds deterministic and optimizing sstate usage, probably Feb 21 16:00:42 hah Feb 21 16:00:57 reducing dependencies is the best thing you can do Feb 21 16:01:45 RP: indeed, and the best thing to do that is drop debian.bbcclass Feb 21 16:02:55 RP: we might considerer just doing that renaming for non allarch Feb 21 16:03:26 ..considerer.. Feb 21 16:03:41 grr, consider.. Feb 21 16:04:26 jeroen_: We're not just dropping the class, you can disable it, sure Feb 21 16:04:44 threre is no need afaik to rename allarch packages since they have no libs anyway Feb 21 16:05:22 RP: understood, but it can drop the rdpeds for allarch Feb 21 16:06:55 RP: it you do that, python script, php scripts, websites, javascript etc etc is allarch Feb 21 16:07:30 RP: (well some noise with qa, but we can fix that) Feb 21 16:08:23 jeroen_: that is worth thinking about although I think it is hard to know up front if the allarch code will trigger iirc Feb 21 16:11:05 RP: well, I will stat doing it for python, likely nodjes etc. Feb 21 16:11:54 RP: I will let you know if it causes trouble.. Feb 21 16:17:28 RP: well you have some trouble with the qa trying to run again... It does't really need to, can't hurt either. Sstate will invalidate it thouth, that is annoying. Feb 21 16:18:40 grrr, it is though obviously. **** ENDING LOGGING AT Tue Feb 22 02:59:56 2022