**** BEGIN LOGGING AT Wed Jul 24 02:59:57 2019 Jul 24 13:13:38 RP: are you available for a couple questions regarding the runqueue changes? Jul 24 13:13:50 laplante: yes Jul 24 13:14:45 RP: sweet - my main question is regarding the relationship (if any) between the new changes and the hash equivalence work that happened a few months ago. How are they related? Jul 24 13:15:18 laplante: which new changes are we talking about? Jul 24 13:15:31 laplante: the ones that merged or the ones in master-next which haven't been posted yet for review? Jul 24 13:15:45 RP: the ones that have already merged Jul 24 13:16:30 laplante: for those there isn't a direct relationship. We know that work with hashequiv will mean changes to runqueue. Those recent runqueue changes were made working towards what hashequiv will need Jul 24 13:17:30 laplante: think of those patches as laying strong foundations for us to later build off Jul 24 13:19:41 RP: ok, so basically the primary functionality in those patches is to remove the distinction between runqueue and scenequeue, and subsequent patches will make the system work more harmoniously with hashequiv? Jul 24 13:20:07 RP: * and the already-landed patches also optimizie multiconfig Jul 24 13:20:18 laplante: for hashequiv (and the multiconfig optimisations) we need to be able to run setscene tasks after running normal tasks Jul 24 13:20:42 laplante: the old code simply didn't allow that. Those patches allow mixing the two types of task Jul 24 13:21:02 Once you could mix tasks, it was straightforward to optimise multiconfig Jul 24 13:21:18 The patches in -next then enable hashequiv optimisations Jul 24 13:22:12 RP: I guess the "unihash" is a synonym for the hashequiv hash? Jul 24 13:22:24 "Output hash" I think they were called Jul 24 13:22:25 laplante: its what we termed it in the codebase, yes Jul 24 13:22:50 "unique hash" or "universal hash", both work Jul 24 13:23:36 the output hash is different, its used to compare two task hashes. If it matches, one of the task hashes is picked as the unihash Jul 24 13:26:31 RP: So theoretical example: we have a recipe that for whatever reason is recompiled when you change MACHINE, but for all intents and purposes the output is the same. With OEBasicHash, you couldn't reuse the sstate across MACHINE. But with hash equiv, it would be usable as long as the output is the same? Jul 24 13:27:04 does it hash the actual sstate objects to determine if its identical? Jul 24 13:27:38 laplante: it doesn't solve that Jul 24 13:29:16 laplante: hashequiv would look at the output after the first build and store a hash representing it. After a second build, it would look at the output and compare the hash to the first build. If they match, it would then remap all things which depend on it to use the original taskhash, meaning any subsequent sstate would match and not be rebuilt Jul 24 13:29:41 rburton: it hashes the output directories which go on to make up the sstate objects. Jul 24 13:29:52 right Jul 24 13:30:04 so if reproducible are on then that's a good win Jul 24 13:30:31 rburton: reproducibility goes hand in hand with this, yes Jul 24 13:30:48 rburton: the algo is slightly different so for example I think it ignores timestamps at the moment Jul 24 13:30:59 algo is pluggable Jul 24 13:31:52 ignoring timestamps is sensible as a start Jul 24 13:32:24 RP: I think I see. If task_one depends on task_two, then hash equiv will make task_one depend on the output hash of task_two, whereas before it would have a dependency on the task hash of task_two? Jul 24 13:33:47 laplante: effectively, but it works by mapping hashes back to a "standard" on rather than using the output hash Jul 24 13:34:00 laplante: the problem is you can't know what the output hash is in advance of running the task Jul 24 13:34:18 we require to be able to compute the task hash "up front" Jul 24 13:35:22 laplante: you're right about the effect, just not how it works Jul 24 13:36:43 RP: so then how are you able to calculate the task hash up front? Jul 24 13:37:56 laplante: task hashes are based upon inputs, not output Jul 24 13:38:05 right Jul 24 13:39:02 I think I'll have to dig into the code a bit more to understand, I appreciate the explanations thus far. There's a lot of different hashes to keep straight :) Jul 24 13:40:42 laplante: the taskhash is based on the inputs. When we get the output, we hash it and store that in the hashequiv server so we have an in->out mapping. Jul 24 13:41:13 laplante: if later we find that some other input hash gives the same output, we can mark that as equivalent Jul 24 13:41:51 at that point onward, that input hash would now map to the other hash, allowing the original build artefacts to be used Jul 24 13:42:19 RP: ah that' Jul 24 13:42:24 * that's the missing link. Thanks! Jul 24 13:42:51 RP: So your master-next work on hashequiv is being able to dynamically update and augment these in->out mappings at runtime? Jul 24 13:43:10 laplante: yes Jul 24 13:43:16 RP: awesome! Jul 24 16:23:28 Hello guys. I heard sometime back that cve-check tool project is being replaced by another project. May I know the name of the new project? Jul 24 16:40:08 Noor: https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg125505.html Jul 24 16:40:13 cve-check.bbclass means that it now manages the CVE database Jul 24 16:40:14 itself, instead of using cve-check-tool Jul 24 22:57:20 embedded Jul 24 22:57:25 ops Jul 24 22:57:38 hi Jul 24 22:58:19 anybody knows well codeaurora ? Jul 25 00:20:33 blscoe:what do you need to know, from OEs point for codeaurora Jul 25 00:45:48 maybe someone familiar with codeaurora Jul 25 00:46:24 afterall what I seek is oe based **** ENDING LOGGING AT Thu Jul 25 02:59:57 2019