| gitlab-br-bot | push on buildstream@zip (by Mathieu Bridon): 5 commits (last: plugins/sources/tar.py: Ignore possible leading '.' directory.) https://gitlab.com/BuildStream/buildstream/commit/9870257fd81299c282f909d04b88d821f90b3743 | 06:49 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (zip->master: WIP: Add a new zip source) #131 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/131 | 06:49 |
| gitlab-br-bot | push on buildstream@zip (by Mathieu Bridon): 1 commit (last: Add a new zip source) https://gitlab.com/BuildStream/buildstream/commit/958d118a380a4785e26f4542532216c33bad408d | 06:57 |
| gitlab-br-bot | buildstream: merge request (zip->master: WIP: Add a new zip source) #131 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/131 | 06:57 |
| *** tristan has joined #buildstream | 07:26 | |
| gitlab-br-bot | buildstream: merge request (zip->master: Add a new zip source) #131 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/131 | 07:53 |
| *** valentind has joined #buildstream | 09:24 | |
| *** jude has joined #buildstream | 09:39 | |
| *** jude has quit IRC | 09:49 | |
| *** ssam2 has joined #buildstream | 09:50 | |
| *** jude has joined #buildstream | 09:50 | |
| tristan | ssam2, sorry sometimes I dont notice the MRs which appear on not-buildstream adjacent projects... just merged your defs2bst patch which it looks like baserock is blocking on | 09:57 |
| ssam2 | nice, thanks | 09:59 |
| ssam2 | i feel like the baserock loose ends are finally getting wrapped up | 10:00 |
| ssam2 | how would you feel about moving defs2bst into the baserock/ project ? | 10:00 |
| ssam2 | my thinking was, then we could set up a full CI pipeline for it that ran on the Baserock CI runners | 10:00 |
| tristan | I'm not entirely keen on that honestly | 10:06 |
| ssam2 | fair enough | 10:07 |
| tristan | ssam2, My thinking is that baserock is only one of the projects which are using definitions/YBD - and that we want to maintain a migration path for at least one other project which will need one | 10:07 |
| ssam2 | sure, well my thinking is that baserock has no real reason to keep the .morph files around any more | 10:08 |
| ssam2 | other than testing defs2bst, but testing defs2bst should really be done as part of defs2bst | 10:08 |
| tristan | well, I dont disagree with that | 10:08 |
| tristan | Also there are some special cases in there that are probably baserock specific | 10:08 |
| ssam2 | moving it to baserock was just an easy way to get access to the faster CI runners... but, there is probably another way to do that | 10:09 |
| tristan | But if we're going to drop the .morph files, why is it important for baserock to have ownership of the conversion project after ? | 10:09 |
| tristan | right | 10:09 |
| tristan | I see | 10:09 |
| tristan | still, it is important that we care about migration of other YBD using projects | 10:10 |
| ssam2 | agreed | 10:10 |
| ssam2 | looks like it's pretty easy to make the baserock-manager-runner2 runner available for defs2bst without moving it | 10:11 |
| tristan | ssam2, I personally dont care a great deal about the perfect-ness of the CI of the conversion script, but if we wanted a great CI for it; we would want a reduced data set which exercises and tests only the conversion features | 10:11 |
| ssam2 | hmm, ok | 10:11 |
| tristan | i.e. there is nothing great about redundantly building a whole heavy system, one which might not exercise all of YBD's features, even | 10:12 |
| ssam2 | true; but computer time is much cheaper than engineer time | 10:12 |
| tlater | tristan: So, apart from your comment about the tests, the only thing left for the multiple targets branch is dealing with --except | 10:12 |
| tristan | better would be a small as possible project which exercises each YBD feature | 10:12 |
| tristan | ssam2, yes - which is why I lead with "I dont really care that much" :D | 10:13 |
| ssam2 | right :-) | 10:13 |
| tristan | I mean, it would be great to have, but I'm sure there are more important things to work on | 10:13 |
| tristan | tlater, no | 10:13 |
| ssam2 | yeah. but if we do merge .bst files to baserock definitions, defs2bst will have *no* CI -- i'm trying to figure out the quickest way to ensure it still has some CI | 10:14 |
| tristan | tlater, I want to merge that branch as an isolated thing, and the --except stuff is separate | 10:14 |
| ssam2 | and if someone wants to polish it later, all the better | 10:14 |
| tlater | tristan: That's fair - then, do the tests have to be part of the frontend stuff? It's going to be quite hard to assert that elements are built in the correct order using just buildstream output. | 10:15 |
| tristan | ssam2, If we can run it for a "minimal system" sample first... A.) There is no need to chase a moving target of that sample... B.) The tests only need to run when the defs2bst repo is modified | 10:15 |
| tristan | tlater, `bst show` by default shows build plan order, surely there is something to do with that ? | 10:15 |
| ssam2 | tristan, agreed | 10:16 |
| tlater | tristan: I'm pretty sure it shows deps(Scope.ALL) | 10:16 |
| tristan | tlater, that can be controlled with the --deps option | 10:16 |
| tristan | tlater, it's really quite flexible | 10:16 |
| tlater | Ah, alright, I overlooked that | 10:16 |
| tristan | tlater, I think you can already understand from this experience, why it's important to stop contributing to the mess of tests which poke the innards of BuildStream | 10:17 |
| tristan | tlater, i.e. when you made this change, thankfully you only had to modify a hand full of tests, because a ton of them are already migrated | 10:18 |
| tristan | besides having to maintain a bunch of hard-to-follow code, of course | 10:18 |
| tristan | I'm thinking of doing a migration of the remaining old-school crappy tests in tests/sources, looks like it wont take me too long and I need to address https://gitlab.com/BuildStream/buildstream/issues/145 anyway, which means I need proper source tests for tar at least | 10:19 |
| tlater | Yeah, it makes sense. I'm just never sure whether to stick with the current test suite or not, but I guess from now on the policy is to always test using the frontend. | 10:22 |
| tristan | tlater, yes, always - in fact I'm thinking its going to be worthwhile soon to move LoadErrorReason to be generalized ErrorReason which we can use for all BstErrors, so we can easily pass that back from child processes and assert that in tests | 10:23 |
| tristan | tlater, I want to migrate almost everything else, so far I think the only thing which is certainly worth keeping around is the _yaml tests | 10:23 |
| tlater | tristan: Could the 'integration' tests also be migrated over at some point? | 10:24 |
| tristan | to pytest ? | 10:24 |
| tlater | There seems to be little reason to keep a shell script around for those anymore. | 10:24 |
| tristan | I have been thinking that yeah | 10:24 |
| tristan | But, it's important to mark and distinguish them | 10:25 |
| tristan | tlater, i.e. they should not run by default with `./setup.py test` | 10:25 |
| tlater | tristan: pytest has options to specify the test dir, which we really should use anyway. | 10:25 |
| tlater | From there it's simple to just have two separate test commands. | 10:26 |
| tristan | that's an option - and possibly we want to move some of `testutils` into buildstream core | 10:26 |
| tristan | so that third party plugin repositories can leverage those fixtures | 10:26 |
| tristan | I think this is quite not the today priority, though :D | 10:27 |
| tristan | certainly we agree on general direction, though | 10:27 |
| *** jude has quit IRC | 10:27 | |
| tristan | So in other news, bochecha created a new `zip` source, which shares most of it's code with `tar`, and makes it easy to implement other "download a file" kinds of source | 10:28 |
| tristan | Its has good test coverage, I want to merge it | 10:28 |
| tristan | pushing it back to after the 1.0 release (cause technically, it's a feature addition), would seem to cause more friction than add risk in this case | 10:29 |
| tristan | Thoughts ? | 10:29 |
| paulsherwood | +1 | 10:29 |
| paulsherwood | (not that my vote counts for much :-)) | 10:30 |
| ssam2 | it doesn't seem like a particularly risky feature addition, i say merge it | 10:30 |
| tristan | paulsherwood, we appreciate you :D | 10:30 |
| paulsherwood | heh :) | 10:30 |
| tristan | yeah, he also made an effort to do good tests and make it well shareable, I'm very happy with the patch | 10:30 |
| tristan | alright | 10:31 |
| tristan | will do | 10:31 |
| valentind | Great! Was waiting for it. | 10:39 |
| *** valentind has quit IRC | 10:41 | |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 3 commits (last: tests: Reuse utils.sha256sum) https://gitlab.com/BuildStream/buildstream/commit/f330024d640f340e92ea221ff26a343bf26a0115 | 10:45 |
| gitlab-br-bot | buildstream: merge request (zip->master: Add a new zip source) #131 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/131 | 10:45 |
| gitlab-br-bot | buildstream: Mathieu Bridon deleted branch zip | 10:45 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: doc/source/pluginindex.rst: Added zip source to the plugins index) https://gitlab.com/BuildStream/buildstream/commit/45501e618079245e22f5f337cd0d77a939bbfeef | 10:51 |
| *** givascu has joined #buildstream | 11:00 | |
| tlater | tristan: I assume no targets should result in an error? It looks like running with an empty list makes sense in some applications, but not buildstream. | 11:11 |
| tristan | tlater, Yeah that makes sense | 11:24 |
| tristan | tlater, I think for `bst show` it's a bit ambiguous, but lets roll with an error for now | 11:25 |
| tlater | tristan: `bst show` should default to showing the whole project IMO, but yes, easier for now :) | 11:26 |
| tristan | Maybe one day someone will say "with my script which introspects bla bla and generates a list of elements to ask `bst show` about, I dont want an error when there is no arguments" | 11:26 |
| tristan | We can deal with that, on that day I think | 11:26 |
| tristan | In any case I think it's a sane default for now, error out with nothing to do | 11:26 |
| *** adds68__ has quit IRC | 12:20 | |
| *** adds68__ has joined #buildstream | 12:22 | |
| cs_shadow | Hi @tristan. Thanks for your feedback on the mount workspaces MR. I wanted to discuss a couple of things with you about it. For elements like `import` that don't actually "run" anything in the sandbox, I wasn't sure how the mounting should work as it happens when the sandbox is run. Did you had any thoughts on that? | 12:32 |
| cs_shadow | I was thinking perhaps I could run some dummy commands like `true` but there's no guarantee that it would be present in the sandbox | 12:32 |
| tristan | cs_shadow, its a source like any source | 12:34 |
| tristan | cs_shadow, basically, when you workspace it initially, it is "staged" via the normal staging codepaths into a user controlled workspace directory | 12:35 |
| tristan | cs_shadow, when you build anything with an active workspace, the core ensures that, instead of copying over stuff from a workspace directory (current stuff), it is mounted instead | 12:35 |
| tristan | ahhhh | 12:36 |
| tristan | I see what you mean, this is a little annoying isnt it | 12:36 |
| cs_shadow | yeah :) | 12:36 |
| tristan | grrr | 12:36 |
| tristan | So what do we do about this :-/ | 12:36 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 2 commits (last: tests/sources/tar.py: Converted tar test to use the CLI and enhanced) https://gitlab.com/BuildStream/buildstream/commit/069dcb4f43e64197224fd9d9bc56c6d6d54ac847 | 12:37 |
| gitlab-br-bot | buildstream: issue #145 ("Tar Source should normalize leading `.`") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/145 | 12:37 |
| cs_shadow | so far, `import` is the only one that I've seen causing problems. I'm not sure how common this would be | 12:37 |
| tristan | so elements are going to call "stage_sources" | 12:37 |
| tristan | And while some elements only expect it to be present in the sandbox (mount will work) | 12:38 |
| tristan | Other elements expect the data to appear at that location, and dont run a sandbox | 12:38 |
| cs_shadow | yes, i added that option for the plugins that are not running a sandbox | 12:38 |
| cs_shadow | but admittedly it's a cop-out solution | 12:38 |
| tristan | Doing some processing on data with some python code and buildstream utilities, without running a sandbox, certainly happens | 12:39 |
| tristan | When it happens in compose elements, it happens on artifacts instead of sources | 12:39 |
| tristan | Hmmm | 12:39 |
| tristan | Well, maybe we can churn some things here | 12:40 |
| tristan | maybe it makes sense to say that "If the element does not need a sandbox, then we can assume it's unsafe to mount" | 12:41 |
| tristan | Not sure if that entirely makes sense, but certainly, not supporting the incremental build thing transparently for elements which dont use sandboxes sounds acceptable at face value | 12:42 |
| tristan | cs_shadow, there is another interesting side effect, which maybe does not matter a great deal initially | 12:43 |
| tristan | cs_shadow, from what I can tell, if we support incremental builds from workspaces, it means that the first time you build... it will need a new cache key (because calculated from workspace)... | 12:44 |
| tristan | and *then*... the next time you build, *even* if you didn't modify anything in the workspace | 12:44 |
| tristan | it will require a rebuild again, because local directory is effected and so is cache key | 12:44 |
| tristan | there is another interesting stumper | 12:45 |
| cs_shadow | hmm, during my testing, it didn't appear to be doing that. But I'll double check | 12:46 |
| tristan | One way around that might be to create a manifest at workspace creation time, and only consider files which were originally in the workspace in the cache key; but that has other drawbacks too | 12:46 |
| tristan | cs_shadow, if it's not, there is probably a bug somewhere; the rule for calculating a cache key from a workspaced source, is to do a recursive checksum of the directory content | 12:46 |
| tristan | in fact, this will not happen only on initial workspace, but potentially on every build | 12:47 |
| cs_shadow | okay, I'll check what's going on there. Reg. the MR, do you think we can move forward with it? (perhaps after better explaining how `mount_workspace` option should be used) | 12:48 |
| tristan | modify foo.c, causes it to require rebuild, building changes foo.o, meaning another build is required | 12:48 |
| tristan | No, | 12:48 |
| tristan | cs_shadow, we need to think about this, I really dont think mount_workspace belongs in the API, rather a better path is to understand why it needs to be treated differently (initial thoughts "need of a sandbox", maybe ?) and treat it differently for that reason | 12:49 |
| cs_shadow | Instead of "need of a sandbox", it's probably more like "need to run commands in a sandbox" - as it probably still wants the directory structure | 12:51 |
| cs_shadow | although the elements would need some way of expressing that | 12:52 |
| tristan | for the double rebuilds, it seems like a course of action could be to refuse to know about cache keys at startup time, and resolve them as a result of a build, in the case of workspaced elements (and elements which depend on such) | 12:52 |
| tristan | But that problem, I'm happy to deal with after | 12:52 |
| tristan | cs_shadow, yes it's certainly possible that *some* api is needed, I feel strongly that that API should not be an element knowing about what a workspace is | 12:53 |
| tristan | it may be something which defines the nature of the element which might be useful to deduce other things as well, I just dont want to take that lightly at all | 12:54 |
| tristan | so regarding the double-builds, I would go so far as to merge it with an open issue about improving that, possibly with the dynamic cache key resolution approach, which is tricky to implement (similar to bst build --track, but a bit more hare brained) | 12:55 |
| tristan | Because really, workspaces are *often* used with --no-strict, and are for developers to test stuff, the artifacts are never pushed | 12:56 |
| tristan | And also, the second build (assuming --no-strict) is going to be mostly a noop, if incremental builds work at all | 12:56 |
| tristan | so it's an annoyance, but not horrible | 12:56 |
| cs_shadow | okay, thanks. I'm going to think about the sandbox run issue a bit more and get back to you once I have some nicer alternatives | 12:57 |
| tristan | cs_shadow, yeah I think it's very tricky, I'll also sleep on it and will be thinking on it since you raised that unforeseen obstacle :-S | 12:58 |
| cs_shadow | thanks! :) | 12:59 |
| tristan | these apis are at the very heart of what BuildStream does so, it's critical to get it right | 12:59 |
| cs_shadow | definitely, makes sense. | 13:00 |
| *** adds68__ has quit IRC | 13:05 | |
| gitlab-br-bot | push on buildstream@remove-arches (by Tristan Van Berkom): 20 commits (last: _platform/linux.py: Add preflight check to detect user namespaces) https://gitlab.com/BuildStream/buildstream/commit/a9a2bcece3b90092d9260f5c46675a0e17df381d | 13:28 |
| gitlab-br-bot | buildstream: merge request (remove-arches->master: WIP: Remove arches) #117 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/117 | 13:28 |
| tristan | cs_shadow, there is a whole other approach I just thought of | 13:30 |
| tristan | cs_shadow, instead of deciding on whether we act differently at stage time for elements which want to use sources outside of a sandboxed environment... | 13:31 |
| tristan | cs_shadow, we could instead just decide on whether a given element supports workspacing _at all_ | 13:31 |
| tristan | Not sure how valuable that idea is, just throwing it out there as a thought exercise | 13:32 |
| cs_shadow | that's not outrageous. Although in case of `import`, having a sandbox might make sense... not sure | 13:33 |
| gitlab-br-bot | push on buildstream@remove-pre-post-commands (by Tristan Van Berkom): 20 commits (last: Catch attempts to compose a list) https://gitlab.com/BuildStream/buildstream/commit/8c4d8ca2b7c886690fb933428c6768c745667db7 | 13:34 |
| gitlab-br-bot | buildstream: merge request (remove-pre-post-commands->master: WIP: Remove pre post commands) #118 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/118 | 13:34 |
| tristan | cs_shadow, I think you mean, having a workspace might make sense | 13:35 |
| tristan | in which case, yeah | 13:35 |
| tristan | it's true it might | 13:35 |
| cs_shadow | oh right, that was a trpo | 13:35 |
| cs_shadow | typo* | 13:35 |
| tristan | :) | 13:35 |
| cs_shadow | grr | 13:35 |
| * cs_shadow is stepping out to get some lunch | 13:36 | |
| * tristan is leaving... right about now :) | 13:37 | |
| gitlab-br-bot | push on buildstream@multiple_targets (by Tristan Maat): 2 commits (last: Move tests) https://gitlab.com/BuildStream/buildstream/commit/d3eb64a0baf326a3b6242a49d37659c4423f9c65 | 13:40 |
| gitlab-br-bot | buildstream: merge request (multiple_targets->master: Multiple targets) #135 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/135 | 13:40 |
| gitlab-br-bot | push on buildstream@multiple_targets (by Tristan Maat): 2 commits (last: Add tests for multiple targets) https://gitlab.com/BuildStream/buildstream/commit/c98a2743948c5359d39d744dad4f03871d25a635 | 13:41 |
| gitlab-br-bot | buildstream: merge request (multiple_targets->master: Multiple targets) #135 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/135 | 13:41 |
| gitlab-br-bot | push on buildstream@multiple_targets (by Tristan Maat): 2 commits (last: Add tests for multiple targets) https://gitlab.com/BuildStream/buildstream/commit/3f2dc772fd3381db4594ed1cea9604c365546de1 | 13:44 |
| gitlab-br-bot | buildstream: merge request (multiple_targets->master: Multiple targets) #135 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/135 | 13:44 |
| tristan | tlater, just made a little comment right now about an assertion I think we should remove... aside from that your branch rebased against master looks ready to go to me | 13:47 |
| tlater | tristan: Right, yeah, want to merge it right away? | 13:48 |
| tlater | (It *is* a Friday) | 13:48 |
| tristan | tlater, I'm about to step out honestly... I'll have my phone though :) | 13:48 |
| tlater | tristan: Nah, I get it :) | 13:49 |
| tlater | Though I'd like to just get your thoughts on the --except work so I can start with that, if you don't mind | 13:49 |
| *** adds68__ has joined #buildstream | 13:49 | |
| tristan | grrr | 13:49 |
| tlater | Heh, it's alright if you don't, I can probably find something else to do for the next few hours | 13:50 |
| tristan | tlater, ok well, remove that assertion and rebase, and I will merge that from my phone assuming all passes | 13:50 |
| * tlater should really start discussing things with you early. | 13:50 | |
| tristan | tlater, let me know what it is with except ? | 13:50 |
| tristan | Like right now, and I'll tell you if I have a straight answer | 13:50 |
| tlater | tristan: You said you wanted an 'intersection' element for this work, I'm not sure how that would relate to a solution for it at all | 13:51 |
| tristan | Nah, I dont want a new element | 13:51 |
| tlater | Gah, sorry, element API | 13:51 |
| tristan | Ah, nah it's not important | 13:51 |
| tristan | tlater, I thought the algo of calculating an intersection might be api-worthy, that's all | 13:52 |
| tristan | but that's not important | 13:52 |
| tlater | tristan: My sketch for this would be essentially to do a breadth first search through the graph, and simply removing excepted elements - O(V+E), so pretty efficient. | 13:52 |
| tristan | tlater, I guess what an intersection is... is where graph A overlaps with graph B, giving you the elements you would logically want to exclude from targets A using exceptions B | 13:52 |
| tlater | Hmm... I can just draft these things and show you Monday, that's probably better than keeping you from leaving now | 13:53 |
| tristan | tlater, right, I think its a *little* more complicated, as you want to avoid removing from graph A, elements which graph B intersect with, but are orthogonally still depended on from other elements in A | 13:54 |
| tristan | I think that's what we do now | 13:54 |
| tlater | tristan: Yeah, but the algorithm I worked on throughout this week actually knows that an element still has parents | 13:54 |
| tristan | I.e. excepting is recursive, except it wont except things which are commonly depended on from outside the exception | 13:54 |
| tristan | tlater, sounds reasonable anyway | 13:55 |
| tlater | Alright, cool | 13:55 |
| tristan | "still has parents" sounds pretty algo specific :) | 13:55 |
| tristan | but I think I get it | 13:55 |
| tristan | counting the references of dependencies | 13:55 |
| tristan | sounds sane | 13:55 |
| gitlab-br-bot | push on buildstream@multiple_targets (by Tristan Maat): 10 commits (last: _loader.py: Adjust the loader to support multiple targets) https://gitlab.com/BuildStream/buildstream/commit/cd591d7ac9061c17283bf536cea0b58b14d783b3 | 13:56 |
| gitlab-br-bot | buildstream: merge request (multiple_targets->master: Multiple targets) #135 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/135 | 13:57 |
| *** tristan has quit IRC | 13:59 | |
| *** adds68__ has quit IRC | 14:12 | |
| *** adds68 has joined #buildstream | 14:12 | |
| *** Ebardie has joined #buildstream | 14:34 | |
| ssam2 | the buildstream docs appear to have vanished | 14:51 |
| ssam2 | the last 'pages' CI job seems to have succeeded ... https://gitlab.com/BuildStream/buildstream/-/jobs/38888317 | 14:53 |
| ssam2 | slightly weird that the 'pages' job has an 'artifacts' entry, but the GitLab CI UI doesn't list any artifacts from that job | 14:55 |
| * ssam2 tries triggering the pipeline for 'master' again | 15:02 | |
| ssam2 | that seems to have fixed things | 16:02 |
| *** bochecha has joined #buildstream | 16:06 | |
| *** bochecha has quit IRC | 17:01 | |
| *** bochecha has joined #buildstream | 17:02 | |
| *** tristan has joined #buildstream | 17:25 | |
| tristan | ssam2, I've been watching this fwiw: https://gitlab.com/gitlab-org/gitlab-ce/issues/34899 | 17:38 |
| tristan | known bug with gitlab pages | 17:38 |
| tristan | usually doesnt effect us, but has in the past | 17:38 |
| *** bochecha has quit IRC | 17:46 | |
| ssam2 | right! this case is weirder as the pages job didn't fail at all | 18:11 |
| ssam2 | but it deleted all the pages, so something must have gone wrong. | 18:11 |
| ssam2 | there was one pages job that got cancelled, so could have been that | 18:11 |
| tristan | there is apparently some race condition | 18:29 |
| tristan | ssam2, I think something about another job being started while last one was deploying, cancelling the last or something really stupid | 18:30 |
| tristan | anyway | 18:30 |
| ssam2 | ouch | 18:30 |
| tristan | yeah seems like it's really duct taped together | 18:31 |
| ssam2 | i guess we'll notice quick enough when it happens, anyway | 18:31 |
| tristan | the whole thing also seems to be designed around the use case of a git repository who's goal is to deploy static web pages | 18:31 |
| tristan | anyway, they'll surely figure it out | 18:32 |
| *** ssam2 has quit IRC | 19:01 | |
| *** valentind has joined #buildstream | 19:45 | |
| valentind | I updated buildstream, now I get the message: "WARNING Unable to create user namespaces with bubblewrap, resorting to fallback" | 19:51 |
| valentind | What is the requirement for bubblewrap? | 19:51 |
| valentind | Ah I got it. It was because put a wrapper script that would print the command line. And that did not work with buildstream. | 19:54 |
| *** tristan has quit IRC | 22:07 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!