| *** _longines has quit IRC | 01:24 | |
| *** _longines has joined #baserock | 01:24 | |
| *** gtristan has joined #baserock | 05:15 | |
| *** toscalix has joined #baserock | 07:37 | |
| *** rdale has joined #baserock | 07:43 | |
| *** CTtpollard has quit IRC | 08:26 | |
| *** CTtpollard has joined #baserock | 08:29 | |
| *** toscalix_ has joined #baserock | 08:33 | |
| *** toscalix has quit IRC | 08:34 | |
| *** locallycompact has joined #baserock | 08:58 | |
| *** CTtpollard has quit IRC | 09:01 | |
| *** CTtpollard has joined #baserock | 09:03 | |
| *** rdale has quit IRC | 09:04 | |
| locallycompact | This is going to be way more work than I expected | 09:09 |
|---|---|---|
| rjek | I find that is usually the case for any enterprise. | 09:10 |
| *** rdale has joined #baserock | 09:21 | |
| *** toscalix has joined #baserock | 09:31 | |
| *** toscalix_ has quit IRC | 09:35 | |
| *** JPohlmann has quit IRC | 10:00 | |
| *** JPohlmann has joined #baserock | 10:00 | |
| *** gtristan has quit IRC | 10:38 | |
| *** ctbruce has joined #baserock | 10:57 | |
| *** gtristan has joined #baserock | 11:35 | |
| *** tardyp has joined #baserock | 12:05 | |
| tardyp | hello, I wanted to look at CIAT, and I can see that it is currently down http://ciat.baserock.org/ | 12:06 |
| pedroalvarez | tardyp: yeah, it has been down for quite a long time | 12:06 |
| tardyp | the buildbot is also not responding. Are you still using it? | 12:06 |
| pedroalvarez | tardyp: what do you mean by "the buildbot is not responding", I thought all of it was shut down | 12:08 |
| tardyp | well on http://wiki.baserock.org/ciat/ | 12:08 |
| tardyp | there is a link to buildbot | 12:08 |
| tardyp | http://ciat.baserock.org:8010/ | 12:09 |
| tardyp | and this page timesout | 12:09 |
| pedroalvarez | ah, yes, what I expected | 12:09 |
| tardyp | so CIAT is cancelled project? | 12:10 |
| tardyp | what is baserock using then for CI? | 12:10 |
| pedroalvarez | CIAT was aiming to be more than a simple CI. It was aiming to auto-integrate new versions of upstream components, build them, deploy them and test them | 12:12 |
| tardyp | that what I understood | 12:12 |
| tardyp | and your experience is that it was too difficult? | 12:13 |
| pedroalvarez | we have other simple CIs in place, but it's not doing the same as CIAT was doing | 12:14 |
| pedroalvarez | well, yes difficult, but doable | 12:14 |
| tardyp | but you still cancelled the project? | 12:15 |
| pedroalvarez | I guess we didn't have enough people interested on it | 12:16 |
| pedroalvarez | and keeping it running were it was, was expensive | 12:16 |
| *** jonathanmaw has joined #baserock | 12:18 | |
| tardyp | ok make sense. | 12:21 |
| tardyp | so you dont use buildbot anymore, and now you use concourse, right | 12:24 |
| tardyp | full disclosure: I am th buildbot maintainer | 12:24 |
| pedroalvarez | tardyp: well, we have a concourse instance (http://concourse.baserock.org/), but we have also "a loop in a shell script that builds latest master" (https://mason-x86-64.baserock.org/) , also some pipelines in Gitlab infra (https://gitlab.com/baserock/definitions/pipelines) | 13:19 |
| pedroalvarez | we also tried to move to Zuul .. | 13:19 |
| paulsherwood | tardyp: full disclosure, i'm the guy who thought concourse was sexier :0 | 13:21 |
| paulsherwood | tardyp: i was suprised at the time by the reactions we got, though... i had hoped that folks in genivi/agl would be more interested | 13:21 |
| paulsherwood | since we expressly chose buildbot (in part) because it was already in use at yoctoproject | 13:22 |
| paulsherwood | somehow ciat as interpreted as 'baserock specific' and agl went/stuck with jenkins, genivi went with go.cd | 13:24 |
| paulsherwood | s/ciat as/ciat was/ | 13:26 |
| *** wdutch has joined #baserock | 13:26 | |
| locallycompact | updatesssss, makes actual graphs now https://gitlab.com/baserock/defslib | 13:32 |
| * paulsherwood would love to see a readme/getting-started/video | 13:34 | |
| locallycompact | sure sec | 13:35 |
| locallycompact | have to stop coding anyway have python jitters | 13:35 |
| paulsherwood | :) | 13:35 |
| paulsherwood | do we have to keep callign things 'stratum'? | 13:35 |
| locallycompact | we do as long as it's in the spec | 13:36 |
| tiagogomes | stratum2? | 13:36 |
| paulsherwood | oh, and you should apply a license and copyright | 13:36 |
| tardyp | is there a link on genivi's go.cd instance? | 13:36 |
| wdutch | I guess the CIAT wiki page should be updated | 13:36 |
| paulsherwood | tardyp: http://go.genivi.org/go/auth/login | 13:36 |
| locallycompact | As long as we are running untyped the spec is king of what things are | 13:36 |
| paulsherwood | tardyp: login instructions are on that page (!!!) | 13:36 |
| tardyp | paulsherwood: yep, I saw that | 13:38 |
| paulsherwood | tardyp: can you share what you're interested in? | 13:39 |
| tardyp | I am trying to understand the state of CI in the genivi ecosystem | 13:39 |
| paulsherwood | tardyp: ok, best channel for that would be #automotive | 13:40 |
| tardyp | sorry for the noise :) | 13:40 |
| paulsherwood | the users are there. also gunnarx is online there from time to time, and he's the guy who championed go.cd | 13:40 |
| paulsherwood | tardyp: it's not noise, you're welcome here | 13:40 |
| paulsherwood | we still haven't figured out the perfect ci, i think | 13:41 |
| paulsherwood | concourse is pretty, and cool in lots of ways, but we had to massage some things | 13:43 |
| paulsherwood | and they trust docker/containers way too much imo | 13:43 |
| tardyp | I find it indeed pretty, but not quite obvious to look at | 13:43 |
| tardyp | I am a little lost with the big svg home page | 13:44 |
| tardyp | Also I am not sure how you would make a precommit CI with this | 13:44 |
| tardyp | i.e testing of PR/gerrit reviews | 13:44 |
| paulsherwood | tardyp: that's one of the things we couldn't figure out either | 13:45 |
| tardyp | thats a thing that I have a lot of experience on android systems | 13:45 |
| paulsherwood | ack | 13:46 |
| paulsherwood | gitlab ci and travis seem to have it covered pretty well, without the extra overhead of gerrit | 13:46 |
| * paulsherwood is not a gerrit fan.. but others here like it | 13:46 | |
| *** gtristan has quit IRC | 13:51 | |
| locallycompact | paulsherwood, https://gitlab.com/baserock/defslib | 13:55 |
| pedroalvarez | locallycompact: s/README/README.md/ may help with the visualisation in Gitlab | 14:06 |
| * locallycompact tries | 14:07 | |
| locallycompact | yeha that looks better | 14:07 |
| locallycompact | better stlil | 14:09 |
| locallycompact | https://gitlab.com/baserock/defslib | 14:09 |
| *** gtristan has joined #baserock | 14:17 | |
| paulsherwood | locallycompact: so no plan for defslib.parse('./definitions') ? | 14:19 |
| locallycompact | as in the directory? | 14:20 |
| paulsherwood | yup | 14:20 |
| locallycompact | I don't think it makes sense | 14:21 |
| paulsherwood | and you're hardcoding to system/chunk/stratum | 14:21 |
| locallycompact | I'm writing to the spec | 14:21 |
| paulsherwood | still, you're hardcoding | 14:22 |
| locallycompact | No, it's implemented against the spec | 14:22 |
| paulsherwood | if i change the spec/schema, all of your code would have to change too? | 14:22 |
| leeming | no, cos he is coding against a versioned spec? | 14:22 |
| locallycompact | if you change the spec you change the types, I'd expect the code to change | 14:23 |
| paulsherwood | his function names feature words from the spec | 14:23 |
| rjek | Why doesn't that make sense? | 14:23 |
| * paulsherwood has been trying to undo the daft names we came up with for over three years... and people keep hardcoding them into more stuff | 14:25 | |
| locallycompact | the function names are a substitute for the fact that I can't implicitly deserialize, a la https://github.com/locallycompact/tremor/blob/master/src/lib.rs | 14:25 |
| rjek | If implementing a spec that uses certain nouns, naming functions and variables with those nouns makes sense to me | 14:26 |
| leeming | agreed | 14:26 |
| * paulsherwood thinks, not for the first time, that sw engineers should be forced to uses words of three syllables or less | 14:26 | |
| leeming | not sure if i follow the reasoning for that? | 14:27 |
| leeming | if a spec exists and defines names... you should follow convention in the code.. no? | 14:27 |
| rdale | using nouns with latin plurals should be avoided | 14:27 |
| leeming | but that is more of an issue with the spec though? not implementation | 14:27 |
| locallycompact | I did also add an arbitrary parse_morph(filename), which will deserialize based on kind, if you'd prefer to use that | 14:28 |
| leeming | FTFY : parse_buildy_mc_build_tool(filename) | 14:30 |
| leeming | :) | 14:30 |
| locallycompact | I'm also absolutely fine with further demolishing the spec to get rid of name:, kind: and anything that isn't a local list of things with build-depends between them, in fact I think that's a good idea. Then we get arbitrary nesting and the like for quite little effort | 14:31 |
| paulsherwood | +1 | 14:32 |
| locallycompact | The problem is people are waiting on this V9 in order to integrate things and I still don't know how to wedge it in to ybd | 14:32 |
| leeming | well, the big issue of moulding bits of code, vs having a hard think from ground level | 14:33 |
| paulsherwood | locallycompact: if you can get to an optimum version of the spec (output) based on some migration of current and past definitions (input), i'd be happy to help you wedge it | 14:33 |
| leeming | maintaining backwards compatibility is always an issue | 14:34 |
| * paulsherwood wonders whether to bother refuting that :) | 14:35 | |
| paulsherwood | s/refuting/arguing/ | 14:35 |
| paulsherwood | leeming: have you read http://wiki.baserock.org/back-and-forth/ btw? | 14:36 |
| leeming | paulsherwood, I think that confirms what I indented to say, regardless of my english 'skills' | 14:37 |
| leeming | when i said issue, I mean, it is something to consider | 14:39 |
| leeming | not that it is a PITA, if that was the way it was read? :\ | 14:39 |
| rdale | i think the approach on the 'back and forth' wiki page is incomplete as it doesn't mention migrations | 14:40 |
| leeming | well.. it is a PITA, but needs consideration... yeah... words.. I will stop trying to rephrase | 14:40 |
| locallycompact | backwards is always behind us no matter which way we turn | 14:41 |
| paulsherwood | rdale: agreed. folks would be welcome to improve the text | 14:41 |
| jmacs | By "aiming for forward compatibility" do you mean working with specs you don't know about yet? | 14:41 |
| paulsherwood | leeming: for one thing, it's only something to consider once people realise that it is. i wrote that page to try to tease out some of the things that we were clearly not realising | 14:42 |
| paulsherwood | jmacs: 'Forward compatibility: user's old version still works with the new service/infrastructure/data' | 14:43 |
| paulsherwood | but other definitions are possible of course :) | 14:43 |
| jmacs | Which implies that the old version was designed to take into account new data formats which did not exist when it was written | 14:44 |
| paulsherwood | that may or may not be possible, as you are clearly flagging. but (for example) a tool could at least *try* to parse some future data format, and do whatever it can, rather thna just saying 'your definitions are too new for me' | 14:47 |
| jmacs | So you're saying that we should not deliberately stop forward compatibility. That sounds sensible, at least for non-safety-critical things | 14:49 |
| * SotK thinks "your definitions are too new for me" is more helpful than everything breaking when you try to build definitions with a previously required field no longer present | 14:49 | |
| * paulsherwood will continue to disagree with SotK and others on this | 14:50 | |
| * locallycompact wonders what locallycompact thinks about this problem | 14:50 | |
| leeming | wait.. you disagree with helpful error messages? :\ | 14:50 |
| leeming | or was there some hidden context there | 14:50 |
| paulsherwood | i disagree with error/exit when i could have warn/continue | 14:50 |
| rjek | error please | 14:51 |
| rjek | -Werror | 14:51 |
| paulsherwood | unless i specify that i want error/exit | 14:51 |
| rjek | Otherwise the warning will scroll off my screen unnoticed | 14:51 |
| leeming | Error != warning | 14:51 |
| paulsherwood | i'm the user. every time sw folks make software not work, on purpose, i sigh inside | 14:51 |
| leeming | if it is an error.. people exit with a message | 14:51 |
| leeming | people / please | 14:51 |
| jmacs | No, you deliberately made it an error. It is a warning. | 14:52 |
| leeming | if it is a warning and my terminal isn't spammed, then I can act on it.. | 14:52 |
| paulsherwood | as i said 'do whatever it can | 14:52 |
| locallycompact | what if "what it can" is calculating bad cache keys and uploading blank artifacts | 14:53 |
| rjek | "I have no idea how to interpret these instructions, so I will guess" is never the right thing for software to do, IMO | 14:53 |
| paulsherwood | rjek: bonus points for making it easy for users to decipher warnings, and not flooding with too many of them | 14:53 |
| SotK | rjek: +1 | 14:53 |
| leeming | locallycompact, I think I've actually had this issue before | 14:53 |
| * richard_maw prefers failing early to failing late or not even knowing that you've failed | 14:53 | |
| leeming | agree. early fail is much better | 14:53 |
| leeming | rjek, also bad security/reproducibility | 14:53 |
| rjek | +1 | 14:53 |
| paulsherwood | just because you guys agree, doesn't make you correct :) | 14:54 |
| leeming | not a dig here... but... ybd floods the stdout with non errors/warnings | 14:54 |
| rjek | Failing an hour in because of a trivial typo or something that could have been errors at instantly is a ballache | 14:54 |
| leeming | ybd has loads of warnings.. many are ignored due to them flying off the screen | 14:55 |
| paulsherwood | leeming: agreed | 14:55 |
| leeming | thus why I was trying to add in extra logging for ybd | 14:55 |
| leeming | (as in to file) | 14:55 |
| jmacs | This isn't the first project to have this issue. Warnings, with specific warnings or all warnings made errors with -Werror, is the usual solution. | 14:55 |
| jmacs | As rjek said. | 14:56 |
| leeming | ELI5, -Werror? | 14:56 |
| jmacs | Makes warnings act as errors. | 14:56 |
| leeming | ok | 14:56 |
| richard_maw | gcc style also has -Werror=foo if there's a specific class of warnings you consider to be errors | 14:58 |
| richard_maw | as in there's -Werror=vla if you need your program to be portable to compilers that don't support vlas | 14:58 |
| paulsherwood | fwiw, the main reason ybd 'floods the stdout with non errors/warnings' is to record that our actual definitions have inconsistencies in them. if ybd errored on them by default, it wouldn't build any previous definitions, which from a user perspective would be not useful. it *can* error and exit, but that's not the default | 15:03 |
| paulsherwood | some of the inconsistencies are not even accepted as problems by others here (eg name of file != name of chunk). i expect that if we'd started from locallycompact's perspective of a completely tight schema, we'd have avoided these issues, but we didn't realise that 'back in the day' | 15:06 |
| paulsherwood | this project is (and has been) a learning experience, if nothing else :) | 15:06 |
| locallycompact | mmm | 15:07 |
| locallycompact | when is the five year learning experience in haskell? ^_^ | 15:07 |
| leeming | after the year of linux on the desktop | 15:07 |
| rjek | Linux will never lead on the desktop because nobody uses desktops anymore. It's already won on phones and cars though, and Google now sells as many Chromebooks as Apple does expensive fisher price toys for adults :) | 15:08 |
| paulsherwood | won on cars? perhaps in some parallel universe that's true | 15:09 |
| jmacs | Whoever wins that, we lose | 15:10 |
| * rjek nods sadly | 15:11 | |
| paulsherwood | tardyp: continuing that build discussion from #automotive here, since i think most #automotive folks don't care that much about build systems | 15:23 |
| tardyp | ah | 15:23 |
| rjek | They *should* | 15:23 |
| paulsherwood | https://ninja-build.org/manual.html | 15:23 |
| paulsherwood | maybe they do, i've been wrong before :) | 15:23 |
| tardyp | its very good for incremental builds for huge builds like android were everything is in one Makefile | 15:24 |
| tardyp | for a componentified build like baserock/yocto it is different | 15:25 |
| paulsherwood | ack | 15:25 |
| paulsherwood | but why are they sticking with one Makefile? | 15:25 |
| tardyp | there are huge pros and cons for the two approach | 15:25 |
| tardyp | one build simplify the message for the build | 15:26 |
| * paulsherwood doesn't understand | 15:26 | |
| tardyp | you just have all the source code here, and you can change which ever source code 2 minutes after its reflashfed on your device | 15:26 |
| tardyp | then you repo upload your change and that is done | 15:27 |
| tardyp | I'm not sure about baserock, but with yocto, the developer workflow is very complex | 15:27 |
| tardyp | yocto is for integration, and does not help for development | 15:28 |
| paulsherwood | ack | 15:28 |
| tardyp | while the android system helps both teams | 15:28 |
| tardyp | at the price of getting rid of the componentification | 15:28 |
| tardyp | and letting the dev do -I ../../../kernel in there userland | 15:28 |
| paulsherwood | :) | 15:29 |
| tardyp | I've seen that much more than you can imagine | 15:29 |
| paulsherwood | tardyp: does it require all the source locally? | 15:29 |
| tardyp | it does | 15:29 |
| tardyp | 80GB per work environment minimum | 15:30 |
| locallycompact | idd | 15:30 |
| tardyp | including the generated binaries | 15:30 |
| paulsherwood | tardyp: so to show where we've got to with the baserock workflow | 15:33 |
| paulsherwood | i just made a change direct in gitlab https://gitlab.com/devcurmudgeon/definitions/commit/fd163b1784491a41d97476f56b36c9c49250c003 | 15:34 |
| paulsherwood | it's just bumping the kernel to whatever is master from upstream | 15:34 |
| paulsherwood | a build is running https://gitlab.com/devcurmudgeon/definitions/builds/4246042 | 15:35 |
| paulsherwood | it's checking if any of the things needed for the whole system are already built (and if so is downloading them from a separate cache) | 15:35 |
| tardyp | thats one of the big advantage of the component system | 15:36 |
| paulsherwood | eventually (i hope) it will realize we've not built this version of the kernel before, and will clone and build it | 15:36 |
| tardyp | and for the developer workflow? I want to make a patch to that kernel. how would I do it? | 15:37 |
| paulsherwood | either update the repo: to point to your local checkout of linux or whichever git server you put the patch on | 15:38 |
| tardyp | ok | 15:39 |
| tardyp | gitlab hosted does not help the cache part to be very fast though | 15:39 |
| paulsherwood | we use upstream: by default as an alias for a server hosting the foss repos | 15:40 |
| paulsherwood | true. that's one of the issues we also have with concourse... both want the runners to be isolated, no state from previous builds | 15:40 |
| paulsherwood | which makes sense, except when we need to download 1GB of pre-built content for each run :) | 15:41 |
| tardyp | or you need to store your cache very near from your workers | 15:41 |
| paulsherwood | yup. for private workers or on developer machine, we can keep artifacts locally too | 15:42 |
| tardyp | those days, I am working with hyper.sh startup | 15:47 |
| tardyp | they have very cheap container aas which can be useful for such CI | 15:47 |
| paulsherwood | oh, interesting | 15:47 |
| tardyp | notably you could attach a docker volume pointing to prebuilt artifacts to your worker instances | 15:48 |
| leeming | seems sensible | 15:49 |
| leeming | the gitlab creating new instances each time, is a little... tiresome | 15:49 |
| tardyp | they have an API which is derived from docker | 15:51 |
| tardyp | so if gitlab is already supporting docker, should be able to quickly support hyper | 15:51 |
| paulsherwood | requirements vary ... for ybd releases i prefer just a c4.8xlarge AWS machine... it's fastest wallclock time | 15:51 |
| tardyp | I have made the buildbot port in a few days | 15:51 |
| paulsherwood | cool | 15:52 |
| mwilliams_ct | paulsherwood: oh, speaking of fast instances, you might want to take a look at https://aws.amazon.com/about-aws/whats-new/2016/05/now-available-x1-instances-the-largest-amazon-ec2-memory-optimized-instance-with-2-tb-of-memory/. x1.32xlarge should be faster again (though I'm not convinced it makes economic sense) | 15:53 |
| richard_maw | mwilliams_ct: sheesh, you'd spend a bundle with the CPU time spend loading stuff into that memory! | 15:54 |
| mwilliams_ct | richard_maw: but those numbers are so big and shiny! | 15:54 |
| * paulsherwood is actually tempted to spin one up | 15:54 | |
| mwilliams_ct | paulsherwood: record the build if you do! | 15:55 |
| paulsherwood | of course | 15:55 |
| tardyp | what is the average build time for a full baserock build? | 15:55 |
| CTtpollard | wow | 15:55 |
| rjek | TIL: 1,952MB is 2TB | 15:58 |
| mwilliams_ct | rjek: nope, reread | 15:58 |
| mwilliams_ct | "Instance Memory (GiB)" | 15:58 |
| paulsherwood | tardyp: it very much depends on which system is built, and what it's run on | 16:12 |
| tardyp | obviously, but for your use case of ybd releaes on thos c48x machines | 16:13 |
| tardyp | what is the order of idea? | 16:13 |
| * paulsherwood is looking for specific examples | 16:13 | |
| tardyp | behind that, is hyper per sec billing interresting for your load | 16:14 |
| paulsherwood | https://raw.githubusercontent.com/devcurmudgeon/build-logs/master/aws-c4.8x-large-4x9.log | 16:14 |
| paulsherwood | possibly interesting, yes | 16:14 |
| paulsherwood | so that log is old, back when our default ci included just openstack, genivi and a couple of other systems | 16:15 |
| paulsherwood | it took (as you can see) around 90 minutes. that's from scratch, but without pulling all of the git repos | 16:16 |
| paulsherwood | since then we've added a full gnome system, which has increased the wallclock time dramatically (since WebKitGTK is a monster, and other stuff is slow also) | 16:17 |
| pedroalvarez | webkitgtk is a double sized monster, given that we buld 2 different versions of it | 16:18 |
| paulsherwood | tardyp: while logging various things, i concluded that it didn't make sense to parallelise an indivdiual compile beyond ~ 8-10 cores https://docs.google.com/spreadsheets/d/149jS3VVJ7jA14dSJybeOr4otlEFrzCVJjbxMSppiMcg/edit#gid=245680236 | 16:20 |
| paulsherwood | so that ybd build is actually running up to four separate builders at once when it can | 16:21 |
| tardyp | interresting. Our android infra uses 72 core xeons :) | 16:21 |
| tardyp | or.. no thats 40 core, with 72GB RAM | 16:22 |
| paulsherwood | as one thread with max-jobs=40 ? | 16:22 |
| paulsherwood | sorry -j=40 | 16:22 |
| tardyp | that is also one of the interresting fact about single makefile, you can use -j40 and have the kernel and the java stuff built at the same time | 16:22 |
| tardyp | the yocto build I did was also using those 40cpu quite well by doing several recipes at the same time | 16:23 |
| paulsherwood | ack | 16:23 |
| tardyp | I use -j40 *and* parrallel build = 40 | 16:23 |
| tardyp | I always wonder how it didn't blow up as it is supposed to be actually 40x40 thread worst case | 16:24 |
| paulsherwood | ok, i hazard a guess your wallclock time might be faster with -j10 | 16:24 |
| paulsherwood | but i may be wrong, of course. | 16:24 |
| tardyp | maybe. I did not try | 16:24 |
| tardyp | I did not do the big study on build time yet | 16:25 |
| * paulsherwood has stared at a lot of builds | 16:25 | |
| paulsherwood | https://docs.google.com/spreadsheets/d/149jS3VVJ7jA14dSJybeOr4otlEFrzCVJjbxMSppiMcg/edit#gid=1336804058 | 16:25 |
| tardyp | at the moment, yocto was just PoC level for my team | 16:25 |
| tardyp | still no permission :) | 16:25 |
| paulsherwood | http://wiki.baserock.org/build-times/ | 16:25 |
| * paulsherwood personally doesn't like yocto very much... this is no secret | 16:26 | |
| tardyp | I'd guess that | 16:27 |
| paulsherwood | :) | 16:27 |
| paulsherwood | sorry, i screwed up the permission... fixed now | 16:28 |
| leeming | wait, you don't like yocto? | 16:30 |
| richard_maw | leeming: Quick! Smiley face! | 16:30 |
| paulsherwood | lol | 16:30 |
| leeming | :) | 16:30 |
| * paulsherwood has been called out in public for speaking about it | 16:30 | |
| * paulsherwood will be quiet now | 16:31 | |
| leeming | well the yocto book says good things about us ;) - https://scontent.xx.fbcdn.net/v/t35.0-12/14438982_1308509195836742_355956326_o.jpg?oh=d45e16d67444f96b53ccd890ae67c295&oe=57E335DD | 16:31 |
| * leeming isn't responsible for the fuzz | 16:31 | |
| tardyp | paulsherwood: so this is build time for a single component | 16:34 |
| tardyp | I would have expected gcc to scale better though | 16:35 |
| tardyp | link is often a big part of that time, and its not // | 16:35 |
| paulsherwood | tardyp: yup | 16:37 |
| *** fay_ has quit IRC | 16:37 | |
| richard_maw | gcc has c++ in it these days, which slows things down dramatically, and it has to build the compiler 3 times for its own internal bootstrapping | 16:38 |
| leeming | ah, wondered why gcc was so slow | 16:38 |
| leeming | relative to others | 16:38 |
| jmacs | I'd suggest you are hitting the limit of I/O on those machines | 16:41 |
| *** ctbruce has quit IRC | 16:49 | |
| *** anahuelamo_ has joined #baserock | 16:59 | |
| *** anahuelamo has quit IRC | 16:59 | |
| *** ctbruce has joined #baserock | 17:03 | |
| *** jonathanmaw has quit IRC | 17:05 | |
| *** toscalix has quit IRC | 18:13 | |
| *** ctbruce has quit IRC | 19:48 | |
| *** rdale has quit IRC | 20:08 | |
| *** locallycompact has quit IRC | 20:22 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
