| *** tristan has joined #buildstream | 05:05 | |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 5 commits (last: tests/sources/bzr.py: Removing bzr source test) https://gitlab.com/BuildStream/buildstream/commit/9742899136021d6056c8eb346da7e18cad6e828f | 06:45 |
|---|---|---|
| gitlab-br-bot | buildstream: issue #146 ("Use minimum python version (3.4) for integration tests") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/146 | 07:01 |
| *** givascu has joined #buildstream | 07:18 | |
| *** givascu has quit IRC | 08:05 | |
| *** jude has joined #buildstream | 09:16 | |
| *** valentind has joined #buildstream | 09:21 | |
| gitlab-br-bot | push on buildstream@exceptions-refactor (by Tristan Van Berkom): 6 commits (last: Refactoring: Move ElementError and SourceError to their respective classes, create SandboxError) https://gitlab.com/BuildStream/buildstream/commit/0defb35c0334d78e48bcf21ec6b106b67761e1bc | 09:33 |
| gitlab-br-bot | push on buildstream@sandbox-mounts-refactor (by Tristan Van Berkom): 9 commits (last: Refactoring: Move ElementError and SourceError to their respective classes, create SandboxError) https://gitlab.com/BuildStream/buildstream/commit/0defb35c0334d78e48bcf21ec6b106b67761e1bc | 09:51 |
| *** tiagogomes has joined #buildstream | 09:52 | |
| *** jonathanmaw has joined #buildstream | 09:58 | |
| gitlab-br-bot | push on buildstream@sandbox-mounts-refactor (by Tristan Van Berkom): 1 commit (last: tests/sandboxes/mounting/mount_simple.py: Changed to test new Mounter object) https://gitlab.com/BuildStream/buildstream/commit/bad18ff2b20573a2dbfe0c057bf4d29a6ba0fd4e | 10:12 |
| tristan | https://gitlab.com/BuildStream/buildstream/-/jobs/39149160 <-- this has been happening for I think over a week now, "Failed to create cache" | 10:14 |
| tristan | This might just be a gitlab issue, if it's our fault we should fix that... it causes us to re-download stuff during integration tests, which takes more time | 10:15 |
| tlater | tristan: It might be because cache/buildstream/sources ends up empty for some reason | 10:18 |
| tristan | :-S | 10:18 |
| tlater | Then the cache server rejects it because the file is empty, causing that error | 10:18 |
| tristan | something broke, then | 10:18 |
| tristan | also fyi all; there is going to be some hard core churn on master today | 10:19 |
| tristan | Nothing which effects user interactions, all related to removal of public API which is not justified to be public | 10:20 |
| *** ssam2 has joined #buildstream | 10:20 | |
| tristan | juergbi, for you I expect this will hurt the most - so far I've made all exceptions (except ElementError and SourceError) private, but I'm thinking of going ahead and making Project private | 10:21 |
| tristan | Any justification for having a public Project object ? | 10:21 |
| * tristan sees that the only use it has currently, is for the translate_url() method, which can easily be migrated directly to the Source API | 10:22 | |
| juergbi | i can't think of anything right now | 10:23 |
| juergbi | we can always go from private to public again later if needed | 10:23 |
| tristan | ssam2, since you walked in... could you take a quick look at https://gitlab.com/BuildStream/buildstream/-/jobs/39149160 ? There seems to be a regression with caching the sources in our integration tests, I *think* you are the last to play with those | 10:23 |
| tristan | ssam2, if you don't know what's going on there, don't bother worrying about it - just raising this in case you might know the quick fix | 10:24 |
| tristan | juergbi, indeed | 10:24 |
| tristan | juergbi, I suspect it will be a bit painful for your rebase, but I think it's best right now to hide anything which is not of use to plugin authors | 10:25 |
| juergbi | agreed, i'll manage | 10:26 |
| ssam2 | tristan, i think it's an internal gitlab glitch | 10:27 |
| tristan | ssam2, I thought it might be too, but as tlater pointed out, look at the end of the job | 10:27 |
| tristan | ssam2, it says "WARNING: cache/buildstream/sources/: no matching files" | 10:28 |
| tristan | So it looks like we're not caching the right directory, or we're not configuring it correctly | 10:28 |
| tristan | ah, indeed | 10:29 |
| tristan | looking at the logs: Source Mirrors: /builds/BuildStream/buildstream/integration-tests/tmp/sources | 10:29 |
| tristan | hrmmm | 10:29 |
| tristan | ssam2, anyway this is starting to look like changes unrelated to your docker stuff and caching fixes | 10:29 |
| ssam2 | "no matching files" will be unrelated to the failure. it's strange though if there are usually files there... | 10:30 |
| tristan | the ./run-tests.sh --sources ${XDG_CACHE_HOME}/buildstream/sources argument seems not working | 10:31 |
| tristan | anyway, I can't deal with this today, but I dont expect to deride anyone's work with this either | 10:32 |
| *** jude has quit IRC | 10:32 | |
| *** givascu has joined #buildstream | 10:34 | |
| ssam2 | looks like --sources only works if the directory already exists | 10:43 |
| ssam2 | needs to either raise an error if it's missing, or create the directory if it's missing | 10:43 |
| * ssam2 votes for creating the directory | 10:43 | |
| tlater | tristan, having spent some more time meditating on the --except changes, I think I misunderstood them a bit | 10:44 |
| ssam2 | oh, or if we do `realpath -m` instead of `realpath` it should work | 10:45 |
| * ssam2 will send a patch | 10:45 | |
| tlater | Do we want *all* dependencies of an excepted element to be excluded? | 10:45 |
| *** jude has joined #buildstream | 10:49 | |
| gitlab-br-bot | push on buildstream@sam/test-source-caching-fix (by Sam Thursfield): 1 commit (last: integration-tests: Fix `run-tests.sh --sources DIR` when DIR doesn't exist) https://gitlab.com/BuildStream/buildstream/commit/2ec4203c2306b566e624499f95ac037f53ecadc8 | 10:50 |
| gitlab-br-bot | buildstream: merge request (sam/test-source-caching-fix->master: integration-tests: Fix `run-tests.sh --sources DIR` when DIR doesn't exist) #137 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/137 | 10:51 |
| *** valentind has left #buildstream | 10:52 | |
| tristan | tlater, ok so maybe my idea of how it should work is confusing... | 10:54 |
| tristan | tlater, what I want is to continue to have the same functionality, which iirc is basically "Exclude everything recursively, except for elements which are indirectly depended upon from outside of the --except scope" | 10:55 |
| tristan | I think that is the right thing, still | 10:55 |
| tlater | tristan: looking at the example here though: https://gitlab.com/BuildStream/buildstream/issues/131 | 10:56 |
| tristan | but, I dont know if it makes the most sense, I feel like it does, but I could be wrong | 10:56 |
| tlater | That seems like it won't be enough | 10:56 |
| tlater | Because in that case the dependencies of target elements will in all cases be indirectly depended on | 10:56 |
| tlater | So you end up not excepting anything | 10:57 |
| tristan | tlater, so you have some toplevel targets, defining your main inclusion / pipeline | 10:58 |
| tristan | tlater, and then you have some except targets... those targets *intersect* at one or more elements | 10:59 |
| tristan | When I say *intersect*, I mean only the topmost elements at which they cross | 10:59 |
| tristan | *Those* intersections become the real exclusion targets | 10:59 |
| tristan | Now you have toplevel / pipeline | 10:59 |
| tristan | And you have some elements in there which are to be excluded recursively | 10:59 |
| tristan | Those should be excluded recursively, excepting for elements which are indirectly depended upon from *above* the intersections | 11:00 |
| tristan | Thats how I envision it | 11:00 |
| tristan | We could be more brutal and except *everything* including the intersection point and below it | 11:00 |
| tlater | tristan: Ah, that makes a lot more sense - I interpreted "intersect" as all shared child nodes of any generation. | 11:01 |
| tlater | Which would be the more brutal approach | 11:01 |
| tristan | But it seems nice to not - for instance if you want to track or fetch, excepting for this part, you dont have to worry about now knowing what the parents depend on | 11:01 |
| tristan | s/about now knowing/about not knowing/ | 11:01 |
| * tlater wishes he could draw graphs on IRC | 11:02 | |
| tristan | Still, I am open to being challenged on this - but the behavior should not change post 1.0, thats the whole point | 11:03 |
| tristan | Except everything ruthlessly ? Or gently except things which are not depended upon by parents via outside of the except intersections (indirect) | 11:04 |
| tlater | tristan: I have a feeling this might be a bit hard to use, because the user will struggle to know in detail what is going to be excluded this way. | 11:05 |
| tristan | Indeed | 11:06 |
| tristan | juergbi, ssam2, care to weigh in also on the above ? | 11:06 |
| ssam2 | it can be tricky figuring out everything that pulled in a dependency | 11:07 |
| tristan | I have this feeling like, excepting something means only remove this branch, if untouched by the outside | 11:07 |
| ssam2 | thing is, --except is quite a special case anyway | 11:07 |
| tristan | But, on the other hand, what are the real use cases | 11:07 |
| ssam2 | it's basically so we can generate source bundles without the stage1 and stage2 toolchain | 11:07 |
| tristan | ssam2, actually not that special, I expect it to be used extensively for, say GNOME | 11:08 |
| ssam2 | ah OK | 11:08 |
| tlater | A brutal approach seems most useful for that specific use case, though. | 11:08 |
| tristan | ssam2, i.e. for instance... we want to keep the base system "stack" pretty much at the same place | 11:08 |
| tristan | so we want to `bst track --except base.bst core/meta-gnome-core.bst` a lot | 11:08 |
| ssam2 | ah yes, track --except | 11:09 |
| tristan | because pulling in a fresh base means rebuilding the world | 11:09 |
| ssam2 | much more use cases than build --except, which will mostly just break your build :-) | 11:09 |
| juergbi | might work better with some kind of project/element configuration | 11:09 |
| tristan | and it means ostree downloading the source and doing that heavy lifting | 11:09 |
| ssam2 | in the case of track, it should probably be the brutal approach | 11:09 |
| tristan | juergbi, that is certainly "on the menu", but not blocking 1.0 | 11:09 |
| juergbi | right | 11:09 |
| tristan | juergbi, i.e. my idea was to have "tracking profiles" for that purpose, making things a bit more easy | 11:09 |
| ssam2 | if you run `track --except foo` and then foo is included anyway, that's annoying, even if the tool is correct | 11:09 |
| tristan | ssam2, that cannot happen, though; because direct targets that are explicitly excepted (or the intersection points) *will* be excepted | 11:10 |
| tristan | ssam2, it's whether the parent of an excepted element depends somehow on a dependency of the excepted element | 11:11 |
| tristan | in which case we un-except that child (yes: visualization would be useful here) | 11:11 |
| tristan | It seems confusing to explain, which is a good reason to hesitate... | 11:12 |
| tristan | Ok actually wait ! | 11:14 |
| tristan | Its easy to explain | 11:14 |
| tristan | So here it is... if you run `bst <command> --except bar.bst foo.bst` | 11:15 |
| tristan | Then you are running a command on the foo.bst target, and excepting elements recursively from bar.bst downward | 11:15 |
| tristan | So far so good | 11:15 |
| tristan | The question however arises... What happens to elements which foo.bst depend on AND bar.bst depend on (foo.bst depends on common dependencies, but not *via* bar.bst) | 11:16 |
| tristan | Now there is choice | 11:16 |
| tristan | Do we include those in the exclusion ? Or to we exclude those commonalities from the exclusion ? | 11:16 |
| * tristan *thinks* he found a way to explain it a bit better | 11:17 | |
| tlater | tristan: And you're proposing that we should exclude only the first row of these commonalities? | 11:17 |
| tristan | If you drew a graph, foo.bst is blue (target) and bar.bst is red (exclude)... the commonalities which are not reached *via* bar.bst, but via other pathways, are purple (both exclude and include IMO) | 11:18 |
| tristan | Question is: What to do with the purple elements ? | 11:18 |
| tristan | tlater, either explicit exclude, or the topmost intersection elements themselves; *must* be excluded, I think that top row is excluded regardless of either approach | 11:19 |
| tristan | tlater, elements become purple when say... I'm excluding a smaller stack from a bigger toplevel stack... and the toplevel stack depends on some of the excluded stacks internals, *not because it depends on that excluded stack* | 11:20 |
| tristan | So, I happen to need zlib to build my toolchain... but something in my middleware depends directly on zlib, without ever assuming that it came from the toolchain | 11:21 |
| tristan | zlib is purple in this case, when the toolchain is excluded from the whole system expression | 11:22 |
| tlater | Alright, I think I understand now | 11:23 |
| tlater | And the choices here are to either exclude all purple elements or to keep them? | 11:23 |
| ssam2 | when put like that, it seems to make more sense to keep them | 11:24 |
| gitlab-br-bot | push on buildstream@private-project-refactor (by Tristan Van Berkom): 12 commits (last: Refactoring: Move ElementError and SourceError to their respective classes, create SandboxError) https://gitlab.com/BuildStream/buildstream/commit/0defb35c0334d78e48bcf21ec6b106b67761e1bc | 11:26 |
| gitlab-br-bot | push on buildstream@sandbox-mounts-refactor (by Tristan Van Berkom): 2 commits (last: sandbox: Refactoring, moving accidentally public MountMap into it's own file) https://gitlab.com/BuildStream/buildstream/commit/69cc9ef00b957a202a80c7690f7ee3e5ad8b8eda | 11:31 |
| gitlab-br-bot | push on buildstream@private-project-refactor (by Tristan Van Berkom): 4 commits (last: sandbox: Refactoring, moving accidentally public MountMap into it's own file) https://gitlab.com/BuildStream/buildstream/commit/69cc9ef00b957a202a80c7690f7ee3e5ad8b8eda | 11:32 |
| tristan | tlater, basically yes, the question is whether we keep those purples or discard them | 11:32 |
| tristan | So originally, we were discarding those from --exclude as I recall | 11:32 |
| tlater | Again, given how hard it was to explain this here, I feel this might be very hard to understand for an actual user. | 11:33 |
| tristan | that was the expected functionality, I think - and now the differences are that there may be more than one exclude, and that an exclude can be an orthogonal target (so we need to collect the toplevel intersections) | 11:33 |
| tristan | tlater, I think that the user wont consider the purple elements until it happens | 11:34 |
| tristan | tlater, and when it "happens" is when it counts that buildstream does something least harmful to the user | 11:34 |
| tlater | tristan: I'm pretty sure they currently are still included, actually | 11:36 |
| tristan | they are forcefully excepted even if depended upon indirectly by parents ? | 11:37 |
| tristan | I'm pretty sure that was unintentional | 11:37 |
| tristan | But that doesnt answer the question: What is less harmful to the user, in the case of ambiguous purple elements | 11:38 |
| tristan | fetch is never harmful, track can be harmful | 11:39 |
| tlater | In that case, *not* tracking deeper dependencies is less harmful | 11:39 |
| tristan | show will only reflect the correct thing either way | 11:39 |
| tlater | So a more brutal --except would cause less mistaken tracks | 11:39 |
| tristan | indeed... | 11:39 |
| tristan | can someone else care about this too for a moment ? I dont want to make a hurried call on this right now | 11:40 |
| tlater | This might actually be worthy of some ML discussion | 11:40 |
| tristan | true... | 11:48 |
| tristan | tlater, assuming it's easier to brutally exclude all purple, want to start with that approach ? | 11:48 |
| tristan | tlater, I think it's close to the last 1.0 blockers, and you are blocking on this | 11:49 |
| tlater | tristan: Yeah, that seems sensible | 11:49 |
| tristan | tlater, ok so... also I would like to see the whole API for `bst build --track` replacements... | 11:56 |
| tristan | tlater, Can you write the whole plan up to the list ? The comments I made on several disconnected bug reports were decent ideas, but I havent considered the whole thing as a whole | 11:57 |
| tlater | Sure :) | 11:57 |
| tlater | I assume only the changes for the bst build --track changes? | 11:58 |
| tristan | tlater, all together - the --except algorithm probably has an effect on that too, I feel that this was all the same issue, even if filed as 4 separate reports | 12:00 |
| tristan | multiple toplevels, ability to --exclude multiple elements, not necessarily exactly in the pipeline but calculating the intersection points... the --track not differentiating from saving or not saving the track results, and the problem that build --track doesnt allow more granular selection of elements | 12:01 |
| tristan | it all plays into how we express pipelines on the command line, and the blocker issues with `bst build --track` which are effected by this | 12:02 |
| tristan | tlater, basically I want to see all the proposed changes grouped together, so that we know that we are not adding something redundant, or introducing CLI options which could be more simple | 12:02 |
| tristan | I want somebody (you) to have thought about that, and how future proof the plan is in general | 12:03 |
| * tlater starts reading back into the tracking changes | 12:03 | |
| tristan | it can be that I suggested things which made sense in one context, but not when you put the whole plan together | 12:04 |
| tristan | ssam2, https://gitlab.com/BuildStream/buildstream/-/jobs/39159818 looks promising, gitlab timeout issues aside | 12:05 |
| tristan | thanks for doing that ! | 12:06 |
| tristan | "Source Mirrors: /builds/BuildStream/buildstream/cache/buildstream/sources" | 12:06 |
| ssam2 | oh yeah, that seems to be working better | 12:08 |
| gitlab-br-bot | buildstream: merge request (private-project-refactor->master: Refactoring: Remove unneeded public API) #138 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/138 | 12:10 |
| * tristan thinks he can remove a lot of additional junk from Context API too | 12:12 | |
| tristan | Oh, maybe the whole thing ! | 12:13 |
| tristan | Actually, not a single plugin calls .get_context() | 12:13 |
| tristan | tlater, in case you didnt notice, I merged your branch sans the weird decision to ignore tty-ness on BST_TEST_SUITE env var | 12:16 |
| tristan | tlater, if there is some reason for that to have been snuck into the branch, you might justify it in a separate merge request | 12:16 |
| * tristan doesnt see a need for that, though | 12:17 | |
| tlater | tristan: Yes, sorry about that, it was a workaround for my test runner somehow behaving as a tty... I didn't actually want to include it. | 12:17 |
| ssam2 | jonathanmaw, tristan: does https://gitlab.com/BuildStream/bst-external/merge_requests/ look OK ? | 12:20 |
| ssam2 | bah, I mean https://gitlab.com/BuildStream/bst-external/merge_requests/2 | 12:20 |
| tlater | tristan: Should I include the merged multiple-targets change in the mail? | 12:24 |
| tristan | ssam2, the gist of it looks correct to me, looks like I merged those removals a little prematurely | 12:25 |
| tristan | ssam2, is there no docs comments perhaps in the accompanying .yaml files which need adjustment for this ? | 12:25 |
| tristan | tlater, sure why not; I mean that part is not a proposal and pretty much a no-brainer solid change; but it adds some context to lead with "recently we merge a bla bla multiple targets" | 12:26 |
| * tlater will resist the urge to quote exactly that | 12:27 | |
| tristan | tlater, as a thought exercise / straw man, it may help to come up with some example invocations based on the proposed changes | 12:28 |
| tristan | ssam2, looks good to me, merging | 12:32 |
| tristan | ssam2, looks like the same cache trick needs to be fixed on bst-external ? | 12:33 |
| *** tpollard has joined #buildstream | 12:33 | |
| tristan | this is also not a big deal... but food for thought: https://gitlab.com/BuildStream/buildstream/issues/146 | 12:38 |
| tristan | We are not catching cases where newly added code needs python > 3.4, because we're using modern python in the runner | 12:38 |
| gitlab-br-bot | buildstream: merge request (private-project-refactor->master: Refactoring: Remove unneeded public API) #138 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/138 | 12:48 |
| gitlab-br-bot | buildstream: Tristan Van Berkom deleted branch private-project-refactor | 12:48 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 12 commits (last: Refactoring: Move ElementError and SourceError to their respective classes, create SandboxError) https://gitlab.com/BuildStream/buildstream/commit/0defb35c0334d78e48bcf21ec6b106b67761e1bc | 12:48 |
| gitlab-br-bot | buildstream: merge request (sam/test-source-caching-fix->master: integration-tests: Fix `run-tests.sh --sources DIR` when DIR doesn't exist) #137 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/137 | 12:49 |
| gitlab-br-bot | push on buildstream@sam/test-source-caching-fix (by Tristan Van Berkom): 20 commits (last: plugins/elements/script.py: Issue #121 - Remove traces of pre-/post- commands) https://gitlab.com/BuildStream/buildstream/commit/656ddd347ed338926a320a04eb5c71b562faf710 | 12:49 |
| ssam2 | i've pushed a fix for the run-tests.sh script in bst-external | 12:51 |
| tristan | and I just set your patch to buildstream to merge :) | 12:52 |
| * tristan was waiting on his huge branch to complete first | 12:52 | |
| tristan | could just as well have been a direct push to master, for the .gitlab-ci.yml change | 12:53 |
| tristan | ok well, removal of Context from public API will wait till tomorrow | 12:54 |
| tristan | closing time | 12:54 |
| * tristan remembers he heeds to take care of Chandon's incremental builds branch | 12:54 | |
| tristan | *needs | 12:55 |
| tristan | We're going to punt that to post 1.0 though - there are starting to be too many moving goal posts | 12:55 |
| tristan | for that patch, anyway | 12:55 |
| persia | Are we close to 1.0? Incremental builds seems like a really nifty feature for the non-automated case. | 12:55 |
| ssam2 | i believe we are very close to 1.0 | 12:57 |
| * persia smiles in anticipation | 12:57 | |
| ssam2 | https://gitlab.com/BuildStream/buildstream/issues?label_name%5B%5D=Blocker | 12:58 |
| tristan | persia, https://gitlab.com/BuildStream/buildstream/merge_requests/126 | 13:05 |
| tristan | persia, see my last comments I just added to the discussion | 13:05 |
| tristan | persia, that said, I am still hopeful to land incremental builds early in 1.1 and start using 1.1.x immediately for GNOME purposes | 13:06 |
| tristan | the cache key problem though, is gonna be tricky to get by | 13:06 |
| *** tristan has quit IRC | 13:17 | |
| *** tristan has joined #buildstream | 13:21 | |
| tristan | weird: https://gitlab.com/BuildStream/buildstream/-/jobs/39177151 | 13:25 |
| tristan | "Failed to commit artifact: No such file or directory" | 13:25 |
| tristan | Sounds like we have race conditions, or maybe the filesystem exposed in gitlab runners dont ensure atomicity | 13:26 |
| ssam2 | ugh | 13:36 |
| gitlab-br-bot | buildstream: merge request (sam/test-source-caching-fix->master: integration-tests: Fix `run-tests.sh --sources DIR` when DIR doesn't exist) #137 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/137 | 13:36 |
| gitlab-br-bot | buildstream: Sam Thursfield deleted branch sam/test-source-caching-fix | 13:37 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: integration-tests: Fix `run-tests.sh --sources DIR` when DIR doesn't exist) https://gitlab.com/BuildStream/buildstream/commit/0f134712d3efb31cd1e3d53d464a8e66ee92a5f1 | 13:37 |
| ssam2 | tristan, by the way do you have a copy of the vm image generation work you did ? | 13:37 |
| ssam2 | it used to be in buildstream-tests but I can't find it in any branch | 13:37 |
| ssam2 | and i'm having issues with the initramfs scripts, probably exactly the same issues you already solved | 13:37 |
| ssam2 | hmm, actually my initramfs.gz looks totally messed up, maybe it's not the script at fault | 13:40 |
| ssam2 | seems the issue is that the 'script' element runs its commands with the cwd set to / now | 13:47 |
| ssam2 | where before it would run commands with cwd set to %{build-root} | 13:47 |
| ssam2 | which is fine, but we should document the expected behaviour at least | 13:47 |
| * ssam2 will send a patch for https://buildstream.gitlab.io/buildstream/elements/script.html#module-elements.script | 13:47 | |
| tristan | lemme check | 14:10 |
| tristan | ssam2, should be build-gnome branch iirc, is this not good: https://gitlab.com/BuildStream/buildstream-tests/tree/build-gnome/elements/initramfs ? | 14:11 |
| tristan | ssam2, note that the scripts from baserock had problems, and I fixed those manually I think | 14:13 |
| tristan | ssam2, also this https://gitlab.com/BuildStream/buildstream-tests/blob/build-gnome/elements/base-system-image.bst ... looks like jonathanmaw updated that after creating x86Image element | 14:13 |
| tristan | it could be things are a wee bit out of date and maybe need updating for churn in buildstream, but I think that is the right thing | 14:14 |
| jonathanmaw | I'm not sure if the x86image tests ever really worked, though. coming back to them there were so many reasons why they shouldn't have worked :/ | 14:15 |
| tristan | the initrd looks correct, pulls in the gnu-toolchain.bst, adds some scripts, and composes just the runtime | 14:15 |
| tristan | then https://gitlab.com/BuildStream/buildstream-tests/blob/build-gnome/elements/initramfs/initramfs-gz.bst takes it and gzips it up into /boot | 14:15 |
| tristan | jonathanmaw, I only ever tested it by booting the result | 14:16 |
| tristan | I dont think we ever got to having automated tests which did that | 14:16 |
| tristan | I do *clearly* recall having to modify https://gitlab.com/BuildStream/buildstream-tests/blob/build-gnome/files/initramfs-scripts/init to get it to work | 14:17 |
| tristan | there is no way it would boot with the existing baserock stuff | 14:17 |
| ssam2 | ah cool, i didn't find that | 14:28 |
| *** semanticdesign has joined #buildstream | 15:06 | |
| gitlab-br-bot | push on buildstream@sam/bst-checkout-metadata (by Sam Thursfield): 1 commit (last: Allow checking out artifact metadata with `bst checkout`) https://gitlab.com/BuildStream/buildstream/commit/e187ec0e25b398619ede835df614dadf69618423 | 17:06 |
| *** Ebardie has quit IRC | 17:14 | |
| gitlab-br-bot | buildstream: merge request (sam/bst-checkout-metadata->master: WIP: Allow checking out artifact metadata with `bst checkout`) #139 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/139 | 17:18 |
| *** cs_shadow has joined #buildstream | 17:30 | |
| *** gitlab-br-bot has quit IRC | 17:41 | |
| *** gitlab-br-bot has joined #buildstream | 17:41 | |
| gitlab-br-bot | push on buildstream@sam/manifests (by Sam Thursfield): 2 commits (last: Allow checking out artifact metadata with `bst checkout`) https://gitlab.com/BuildStream/buildstream/commit/e187ec0e25b398619ede835df614dadf69618423 | 17:50 |
| *** valentind has joined #buildstream | 18:03 | |
| *** ssam2 has quit IRC | 18:05 | |
| *** jonathanmaw has quit IRC | 18:32 | |
| *** tiagogomes has quit IRC | 19:02 | |
| *** givascu has quit IRC | 20:46 | |
| *** tristan has quit IRC | 21:11 | |
| *** jjardon[m] has quit IRC | 21:41 | |
| *** mattiasb has quit IRC | 21:41 | |
| *** mrmcq2u[m] has quit IRC | 21:41 | |
| *** cgmcintyre[m] has quit IRC | 21:41 | |
| *** kailueke[m] has quit IRC | 21:41 | |
| *** waltervargas[m] has quit IRC | 21:41 | |
| *** ptomato[m] has quit IRC | 21:41 | |
| *** ptomato[m] has joined #buildstream | 21:47 | |
| *** julien has joined #buildstream | 22:43 | |
| *** valentind has quit IRC | 22:44 | |
| *** julien has joined #buildstream | 22:44 | |
| *** julien has quit IRC | 22:45 | |
| *** waltervargas[m] has joined #buildstream | 23:46 | |
| *** mrmcq2u[m] has joined #buildstream | 23:46 | |
| *** mattiasb has joined #buildstream | 23:46 | |
| *** kailueke[m] has joined #buildstream | 23:46 | |
| *** cgmcintyre[m] has joined #buildstream | 23:46 | |
| *** jjardon[m] has joined #buildstream | 23:46 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!