IRC logs for #baserock for Monday, 2018-07-02

*** toscalix has joined #baserock06:30
*** toscalix has quit IRC06:31
*** toscalix has joined #baserock06:31
*** rdale has joined #baserock08:06
*** jonathanmaw has joined #baserock08:36
*** paulwaters_ has joined #baserock09:43
*** paulwaters_ has left #baserock09:43
noisecell <--- ALL IN GREEN!! \o/10:32
ironfoot"in 605 minutes 14 seconds" xD10:32
ironfootanyway, yaaaaaaaay!10:33
gitlab-br-botdefinitions: merge request (franred/use-1.1.3-BuildStream-release->master: Update buildStream to 1.1.3) #79 changed state ("opened"):
noisecellironfoot, some more minutes ....10:36
noisecellironfoot, and probably we should tell buildstream that downloading multiples times the same repository is causing big issues in our definitions pipeline10:37
noisecellor at least remind them that there is a bug filled 1 year ago about this :/10:38
ironfootthat bug would be a big win for us10:39
ironfootlast comment there is a fair comment, and what we should fix is our CI cache10:42
ironfooti looked into fixing this issue myself, and couldn't think of an easy solution10:42
noisecellironfoot, I think is tangential, we both are right. If for some reason someone doesn't want to use the cache, then they are screw with this bug10:44
ironfootonly if you clean up the environment for every build though (CI)10:45
ironfootyou didn't have this experience building locally10:45
persiaI don't understand how this is a bug after reading ths issue.  Am I correct that it only happens when two elements require the same source?10:48
noisecellpersia, yes, you are correct10:51
persiaIn that case, isn't the easier solution to only build each element once, and split the artifacts if one needs multiple things?10:52
noisecelljonathanmaw, -- I can not see the element pushed for the armv8l64 into . Did they got into the ostree cache anytime?10:52
noisecellpersia, the repository is cloned for different reasons depending on the element. The most common issue is when clonning delta/linux for building linux and getting the linux headers, for example10:53
noisecellthe issue is when cloning the repository not when building the elements10:53
persiaI've expressed myself poorly.  Apologies.10:54
persiaIn a classic environment, there was often an effort to maintain separate "kernel" and "headers" packages, in the interest of avoiding rebuilding things that depended on headers when the kernel changed.10:55
persiaIn an environment where things are built upon other things with careful effort taken to ensure reliable checksums of sources, etc., is this split still needed?10:56
persiaAlso, are there sources other than linux that are used more than once?10:56
ironfooti think the main and most important case is linux.git, because of its size and how many times is used10:57
ironfootit's used a couple of times in the base, to build the headers, once in the stage2 and once in the stage310:57
ironfootin that case we need to build it twice10:57
ironfootregarding using the same build to build the kernels in the bsp... maybe? but it would be a definitions rework10:58
persiaAh, yes, for bootstrapping it probably also applies to things like the core C library and the compiler.10:58
persiaSo bootstrapping will always be affected.10:58
persiaMy thought was that *some* of the pain could be removed with the definitions rework, and reading the gitlab issue against BuildStream, it wasn't clear to me how BuildStream *could* fix this reasonably.10:59
ironfootyes, gcc and others suffer from this too, but their repos don't take that long to clone (probably because we use tarball imports)10:59
noisecelljonathanmaw, Im asking because I am planning to do something similar, if this was done before I can use it and carry on with my real task which is building one system in aarch64.11:00
ironfootNo, it's not clear how to solve this issue easily11:00
ironfootI guess a less easy solution would be to change the fetching scheduler to check for identical jobs in the queue, and make them dependant or something11:00
persiaFor the kernel/header split, I think the right answer is definitions rework (although that isn't necessarily easier than sorting BuildStream).11:02
persiaFor the bootstrap case, if we're seeing parallel fetches, I think something else is wrong with the scheduling.11:02
ironfootwhat do you mean by "something else" other than the scheduler allowing it11:03
persiaIn that, since we don't have the build-dependencies to build the thing being fetched (because we haven't fetched the prior version), we probably shouldn't have scheduled the job.11:03
ironfootaha, I think that BST PoV is to fetch everything before it can be even considered to build11:04
ironfoots/to build/to be built/11:04
persiaOh my.  That definitely matches my "something else is wrong with the scheduling" :)11:06
jonathanmawnoisecell: hrm, iirc I didn't manage to get an armv8 sysroot working11:25
jonathanmawI'm checking to see if I have any stray files to indicate what state I left it in11:25
noisecelljonathanmaw, oh, I see. Yeah, any file that indicates what I'm facing would be great11:27
noisecelland appreciated11:28
jonathanmawnoisecell: looks like I don't have any work to share, if you've already found
jonathanmawI don't think I added anything to that while trying to get armv8 working12:20
jonathanmawaha, I apparently managed to generate a bootstrap tarball with that, but didn't get as far as running it on an aarch64 system12:21
noisecelljonathanmaw, ok, I am following the instructions in: -- let's see if I manage something12:21
noisecelljonathanmaw, I've got the stage2 tarball, now attempting to build the stage3 in aarch6412:22
*** gtristan has joined #baserock14:32
*** gtristan has quit IRC14:38
*** gtristan has joined #baserock14:41
*** toscalix has quit IRC16:51
*** gtristan has quit IRC17:08
*** jonathanmaw has quit IRC17:15

Generated by 2.15.3 by Marius Gedminas - find it at!