IRC logs for #baserock for Wednesday, 2017-10-25

*** persia has quit IRC01:21
*** persia has joined #baserock01:22
*** gtristan has quit IRC06:57
*** jude_ has joined #baserock06:58
*** gtristan has joined #baserock07:25
*** jonathanmaw has joined #baserock08:34
*** ssam2 has joined #baserock09:18
*** ChanServ sets mode: +v ssam209:18
ssam2yess!!!!!!!!!09:18
ssam2https://gitlab.com/baserock/definitions/pipelines/1314446609:18
benbrown_\o/09:18
ssam2well done to all involved in this marathon09:19
ironfootwow, that's soo green09:19
* benbrown_ wonders whether he should rebase out the reverts, of if we should just deal with those during a manual merge09:20
benbrown_s/of/or/09:20
ssam2if you're up for doing a rebase, then yeah09:20
ssam2well, or we could cherry pick bits09:21
ssam2i'm happy either way09:21
gitlab-br-botdefinitions: merge request (benbrown/sam/fix-ci->master: Fix caching in CI and some other optimizations) #63 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6309:27
ssam2let's see how fast a no-op rebuild is now09:28
benbrown_gitlab-br-bot: oh, welcome back09:30
gtristanssam2, nice :)09:30
*** locallycompact has joined #baserock09:44
benbrown_https://gitlab.com/baserock/definitions/-/jobs/37567134 "Unknown exception in SIGCHLD handler" is an interesting error11:00
benbrown_the pipeline seems to be continuing though11:00
benbrown_Also seeing a few "Unknown child process pid 2449, will report returncode 255"11:01
ssam2yes, those might be interesting to tlater11:02
ssam2were he here :-)11:02
ssam2he's done quite a bit on buildstream job control recently11:03
ssam2apparently there's a fix waiting to be merged for that11:05
benbrown_oh, cool11:05
ssam2i noticed that the 'build-or-show' script I wrote for the CI doesn't actually work as intended11:19
ssam2the idea is that if the element to be built is shown as 'downloadable', we skip running `bst build` to avoid spending ages pulling GBs of stuff from ostree.baserock.org11:20
ssam2but the target elements are all stacks, and those don't get pushed to the remote cache11:20
ssam2i guess a reasonable fix would be to generate compose elements for each one11:20
ssam2which we'd want to do anyway if we were actually using these systems for anything other than testing BuildStream11:21
gtristanssam2, stack elements dont get pushed to remote caches ??11:26
gtristanssam2, you sure ? I think they contain metadata and are still valid artifacts11:27
ssam2i'm sure that when i `bst show` a stack that was previously built, it says 'waiting' not 'downloadable'11:27
ssam2maybe it's in the cache, but there's another issue... let's check11:28
ssam2https://ostree.baserock.org/cache/refs/heads/baserock/ doesn't contain any refs with 'systems' in their name11:28
ssam2and e.g. in this build log ... https://gitlab.com/baserock/definitions/-/jobs/3756713311:29
ssam2there's no 'push:systems/base-system-content.bst' task11:29
gtristanssam2, if that is confirmed, I would say it's a bug11:29
ssam2ok, i'll dig a bit deeper and make a bug report11:30
gtristanssam2, it should be very cheap to push them back and forth, and they contain valuable stuff (like the integration commands)11:30
gtristanweird though, I dont see why we would skip them, we would have to have special cases in buildstream saying "dont upload this cause it's a stack"11:31
ssam2yeah11:31
ssam2possibly more a bug triggered by the fact that stacks are empty11:32
gtristanmmm11:39
gtristanOk, perhaps fallout from when we changed the structure to allow for metadata & logs in separate directories11:39
ssam2seems there might be another buildstream bug at play12:38
ssam2https://gitlab.com/baserock/definitions/-/jobs/37475223 is an incomplete but successful build of ivi-system-content.bst12:38
ssam2hmm, i wonder if this is related to the other issue -- perhaps it always ends the pipeline early, but normally only 1 element early?12:39
gtristanssam2, I think we normally do CI with `--on-error continue` to ensure we see all the errors at once, maybe we're just failing to report non-zero exit status in that case ?12:43
ssam2we're not passing `--on-error continue`12:50
ssam2and there's no error; on rerun the job is building fine: https://gitlab.com/baserock/definitions/-/jobs/3756713712:51
ssam2has just built, in fact12:51
ssam2but all that building should have been done as part of the previous job; the definitions are identical for both12:52
ssam2could someone approve https://gitlab.com/baserock/definitions/merge_requests/63/ (fix CI) so we can merge ?13:29
gitlab-br-botdefinitions: merge request (benbrown/sam/fix-ci->master: Fix caching in CI and some other optimizations) #63 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6313:30
gitlab-br-botdefinitions: merge request (benbrown/sam/fix-ci->master: Fix caching in CI and some other optimizations) #63 changed state ("merged"): https://gitlab.com/baserock/definitions/merge_requests/6313:31
ssam2thanks!13:32
benbrown_\o/13:32
ssam2ok, so we're almost back to where we were a month ago when i decided to try and fix the ci to speed up the process of merging the outstanding branches... which seems to have only caused delays :-)13:33
ssam2but, the gitlab CI cache seems to be working reasonably reliably, even if it still takes 10 minutes to get all the sources in place for each job13:34
benbrown_ssam2: !59 first?13:35
ssam2yeah that's the next one. i'll rebase it and see what happens13:35
benbrown_cool13:35
gitlab-br-botdefinitions: merge request (sam/armv8-ppc64->master: Various fixes for armv8 and ppc64) #59 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/5913:45
jjardonnice13:48
jjardonI think is time to depend in a specific version of ybd/spec/def2spec instead current master of everything13:49
jjardonwe used to use latest buildstream, what are we using now? ssam2 do you know?13:49
* jjardon prepares a branch13:59
ssam2we use latest version of buildstream14:00
ssam2we should continue to do that for now... at least until buildstream 1.014:00
jjardonno for master of definitions please; we can not know when the things get broken if not. We can still run the CI periodically with master of everything if you want14:04
ssam2I still consider the buildstream conversions experimental14:06
ssam2buildstream 1.0 would be a good time to try and declare them stable14:07
jjardonrigth, another reason to not use master of the conversion script or buildstream; build can brake at any point, doesnt matter master of definitions has built before14:13
jjardonyou are still completely free to experiment in branches or even in periodic jobs14:13
ssam2sure, i just feel like there's already a load of stuff outstanding14:14
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6414:15
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: WIP: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6414:15
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: WIP: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6414:19
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: WIP: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6414:21
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6414:26
*** gtristan has quit IRC14:46
benbrown_jjardon: you have comments14:52
*** gtristan has joined #baserock15:02
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6415:23
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6415:26
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6415:27
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6415:28
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6415:29
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6415:29
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6415:30
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6415:32
gitlab-br-botdefinitions: merge request (jjardon/no_master2->master: Do not use master of our build tools, but a specific version instead) #64 changed state ("opened"): https://gitlab.com/baserock/definitions/merge_requests/6415:33
jjardonssam2: I think the solution descibed at https://gitlab.com/baserock/definitions/merge_requests/64  will be good enough: we use stable versions of the tools in master of definitions, so CI never breaks. But we still run every day the full CI with master of buildstream and defs2bst, so we can check we are not breaking anything15:36
ssam2sounds good, apart from there isn't a stable version of defs2bst or buildstream yet :-)15:37
ssam2but we can work with it15:37
*** adds68 has quit IRC16:01
*** jonathanmaw has quit IRC16:31
*** ssam2 has quit IRC16:38
*** locallycompact has quit IRC17:12
*** jude_ has quit IRC17:21
*** locallycompact has joined #baserock19:55
*** locallycompact has quit IRC20:44
*** adds68 has joined #baserock22:34
*** adds68 has quit IRC23:01
*** adds68 has joined #baserock23:10
*** adds68 has quit IRC23:16

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!