| juergbi | jjardon: our cache key tests don't include cmake elements, i.e., these tests only cover core code | 04:39 |
|---|---|---|
| *** Amabella has joined #buildstream | 05:11 | |
| *** Amabella has quit IRC | 05:15 | |
| *** tristan has quit IRC | 05:27 | |
| *** tristan has joined #buildstream | 05:53 | |
| *** ChanServ sets mode: +o tristan | 05:57 | |
| tristan | jjardon, https://gitlab.com/BuildStream/buildstream/-/issues/318 | 05:57 |
| abderrahim[m] | jjardon: besides, the cache key should change if the artifact changes (because of the bug fix) | 05:57 |
| * tristan is certainly missing a large gap in this conversation ;-) | 05:58 | |
| tristan | irc logs to the rescue, almost forgot about those | 05:59 |
| tristan | Yeah !1549 will definitely cause cache keys to change | 05:59 |
| *** BadHotLady has joined #buildstream | 06:09 | |
| *** BadHotLady has quit IRC | 06:12 | |
| *** benschubert has joined #buildstream | 06:59 | |
| *** benschubert has quit IRC | 07:08 | |
| *** tristan has quit IRC | 07:08 | |
| *** narispo has quit IRC | 07:08 | |
| *** pro[m] has quit IRC | 07:08 | |
| *** cgm[m] has quit IRC | 07:08 | |
| *** skullone[m] has quit IRC | 07:08 | |
| *** awacheux[m] has quit IRC | 07:08 | |
| *** DineshBhattarai[m] has quit IRC | 07:08 | |
| *** asingh_[m] has quit IRC | 07:08 | |
| *** jjardon[m] has quit IRC | 07:08 | |
| *** SamThursfield[m] has quit IRC | 07:08 | |
| *** kailueke[m] has quit IRC | 07:08 | |
| *** mattiasb has quit IRC | 07:08 | |
| *** dylan-m has quit IRC | 07:08 | |
| *** doras[m] has quit IRC | 07:08 | |
| *** reuben640[m] has quit IRC | 07:08 | |
| *** rafaelff1[m] has quit IRC | 07:08 | |
| *** theawless[m] has quit IRC | 07:08 | |
| *** connorshea[m] has quit IRC | 07:08 | |
| *** abderrahim[m] has quit IRC | 07:08 | |
| *** m_22[m] has quit IRC | 07:08 | |
| *** tlater[m] has quit IRC | 07:08 | |
| *** albfan[m] has quit IRC | 07:08 | |
| *** persia has quit IRC | 07:08 | |
| *** jjardon has quit IRC | 07:08 | |
| *** ironfoot has quit IRC | 07:08 | |
| *** jward has quit IRC | 07:08 | |
| *** paulsherwood has quit IRC | 07:08 | |
| *** flatmush has quit IRC | 07:08 | |
| *** benbrown has quit IRC | 07:08 | |
| *** jswagner has quit IRC | 07:08 | |
| *** gitlab-br-bot has quit IRC | 07:08 | |
| *** krichter[m] has quit IRC | 07:08 | |
| *** segfault1[m] has quit IRC | 07:08 | |
| *** Demos[m] has quit IRC | 07:08 | |
| *** walterve[m][m] has quit IRC | 07:08 | |
| *** dbuch[m] has quit IRC | 07:08 | |
| *** tchaik[m] has quit IRC | 07:08 | |
| *** Trevio[m] has quit IRC | 07:08 | |
| *** milloni has quit IRC | 07:08 | |
| *** hergertme has quit IRC | 07:08 | |
| *** benschubert has joined #buildstream | 07:10 | |
| *** tristan has joined #buildstream | 07:10 | |
| *** narispo has joined #buildstream | 07:10 | |
| *** pro[m] has joined #buildstream | 07:10 | |
| *** cgm[m] has joined #buildstream | 07:10 | |
| *** skullone[m] has joined #buildstream | 07:10 | |
| *** awacheux[m] has joined #buildstream | 07:10 | |
| *** albfan[m] has joined #buildstream | 07:10 | |
| *** kailueke[m] has joined #buildstream | 07:10 | |
| *** Trevio[m] has joined #buildstream | 07:10 | |
| *** DineshBhattarai[m] has joined #buildstream | 07:10 | |
| *** dbuch[m] has joined #buildstream | 07:10 | |
| *** asingh_[m] has joined #buildstream | 07:10 | |
| *** connorshea[m] has joined #buildstream | 07:10 | |
| *** segfault1[m] has joined #buildstream | 07:10 | |
| *** jjardon[m] has joined #buildstream | 07:10 | |
| *** theawless[m] has joined #buildstream | 07:10 | |
| *** krichter[m] has joined #buildstream | 07:10 | |
| *** m_22[m] has joined #buildstream | 07:10 | |
| *** tchaik[m] has joined #buildstream | 07:10 | |
| *** mattiasb has joined #buildstream | 07:10 | |
| *** Demos[m] has joined #buildstream | 07:10 | |
| *** rafaelff1[m] has joined #buildstream | 07:10 | |
| *** SamThursfield[m] has joined #buildstream | 07:10 | |
| *** dylan-m has joined #buildstream | 07:10 | |
| *** tlater[m] has joined #buildstream | 07:10 | |
| *** walterve[m][m] has joined #buildstream | 07:10 | |
| *** reuben640[m] has joined #buildstream | 07:10 | |
| *** doras[m] has joined #buildstream | 07:10 | |
| *** abderrahim[m] has joined #buildstream | 07:10 | |
| *** persia has joined #buildstream | 07:10 | |
| *** jjardon has joined #buildstream | 07:10 | |
| *** milloni has joined #buildstream | 07:10 | |
| *** ironfoot has joined #buildstream | 07:10 | |
| *** jward has joined #buildstream | 07:10 | |
| *** hergertme has joined #buildstream | 07:10 | |
| *** paulsherwood has joined #buildstream | 07:10 | |
| *** flatmush has joined #buildstream | 07:10 | |
| *** benbrown has joined #buildstream | 07:10 | |
| *** jswagner has joined #buildstream | 07:10 | |
| *** gitlab-br-bot has joined #buildstream | 07:10 | |
| *** irc.poop.nl sets mode: +ooo tristan jjardon ironfoot | 07:10 | |
| *** BritManuela has joined #buildstream | 07:42 | |
| jjardon | So, I guess the questions are; is the cache key change expected/acceptable? Do we have a gap in the cache key test cases? (I'd say this should have failed, then we can decide is ok and merge it) | 07:45 |
| *** BritManuela has quit IRC | 07:45 | |
| persia | More generally, how do we handle cache key changes imposed by plugins? | 07:45 |
| persia | Do we have sufficient oversight to ensure that when a change to a plugin would (or should) cause a cache key change, the plugin developer can be aware of that at merge-time, or that this information can be communicated to any users? | 07:46 |
| tristan | jjardon, the second question is clearly yes, and that is #318 above | 08:12 |
| gitlab-br-bot | Issue #318: Cache key test is incomplete https://gitlab.com/BuildStream/buildstream/-/issues/318 | 08:12 |
| tristan | The first question is multifaceted, I believe that we should overlook this while we are still in master leading up to 2.0 | 08:13 |
| jjardon | Yes, agree, but this is for bst-1 | 08:13 |
| tristan | Is it ? (!) | 08:14 |
| tristan | I don't think that should go into bst-1 | 08:14 |
| jjardon | Yes, it is | 08:14 |
| jjardon | persia: I would say the CI is the place to notice this (this plugin is in the buildstream repo) | 08:15 |
| tristan | The policy in bst-1 is that cache keys will not change across micro point releases, but *can* (not always do) in minor point releases | 08:15 |
| persia | jjardon: Yes, maybe, but bst-1 is tricky to deal with. | 08:15 |
| tristan | e.g. this change would cause a bump to bst 1.6 | 08:15 |
| persia | For bst-2, my understanding was that nearly all the plugins would move to external repos. | 08:16 |
| tristan | Why would such a semantic change be such an emergency as to get it into bst-1 ? | 08:16 |
| jjardon | persia: correct | 08:16 |
| persia | But, either way, independent of the repo that hosts something, the question is: do we know when a change in a plugin causes a cache key change, and do we have means in place to ensure that this only happens intentionally? | 08:16 |
| *** tpollard has joined #buildstream | 08:16 | |
| jjardon | tristan: let's release 1.6 and we are done then? | 08:16 |
| tristan | For bst-2, there is still going to be stable plugins under BuildStream governance | 08:17 |
| tristan | For those I would say the changes would be unacceptable and cache key tests will need strengthening | 08:17 |
| tristan | For plugins which are *not* under BuildStream governance, we should really be using an alternative mechanism to load them, e.g. unstable plugin sets should currently be loaded as git submodules | 08:18 |
| tristan | In that case each project buys into their cache key changes | 08:18 |
| persia | tristan: Sure, but we should close #318 for all plugins. There might be an external plugin that doesn't run the test (or doesn't care), but there's no reason to intentionally not to the right thing just because some folk maintain some plugins and other folk maintain other plugins | 08:18 |
| gitlab-br-bot | Issue #318: Cache key test is incomplete https://gitlab.com/BuildStream/buildstream/-/issues/318 | 08:18 |
| persia | Pushing the responsibility down the projects just makes a mess. Project developers are likely to be the most affected by this sort of thing, and the least able to detect it until everything goes wrong. | 08:19 |
| * tristan was briefly interrupted by SIGSANDWICH | 08:19 | |
| tristan | persia, I think we're agreeing but maybe not on semantics | 08:20 |
| tristan | There is always going to be "unstable plugins", that is by design, in that case we expect cache keys to change frequently but only when a project declares that it is going to use a new version of an unstable third party plugin | 08:21 |
| tristan | i.e. we should be loading those unstable things by precisely their commit sha or such | 08:21 |
| tristan | Only when a project buys into a new revision, does the plugin change in any way, and probably the accompanying cache key | 08:21 |
| *** santi has joined #buildstream | 08:22 | |
| tristan | persia, For stable plugins which are being moved out of BuildStream core, these are expected to be maintained under the same governing body, and I would expect BuildStream core cache key tests (and those repository tests) to keep testing for cache key changes | 08:22 |
| tristan | jjardon, Do we really want to release 1.6 just for that cmake change ? or would we prefer to just back it out ? | 08:23 |
| persia | Yes, to all of that, except we really need the -good, -bad, -ugly model or something if doing it that way. | 08:23 |
| tristan | persia, I don't really see why we need anything more than -good | 08:23 |
| * persia thinks backing out the cmake change would be better: 1.6 will be disruptive. | 08:23 | |
| persia | tristan: So -good + 3rdparty? | 08:24 |
| tristan | yeah that's what I'd rather expect | 08:24 |
| persia | -ugly was usually weird licensing issues (like: this is excellent, but you need to get a patent license, or can't use commercially) in other places. Maybe we can discourage those sorts of things being created in other ways. | 08:25 |
| tristan | Right, suffice to say that we should have alternative means to obtain third party/unstable plugin sets than either git submodules, or distro packages, come bst-2 | 08:29 |
| tristan | Which is why I would only advocate caring about the "good" plugin set(s), and possibly getting only those into distros | 08:29 |
| *** narispo has quit IRC | 08:30 | |
| *** narispo has joined #buildstream | 08:31 | |
| *** rdale has joined #buildstream | 08:36 | |
| *** NatashaOakl47 has joined #buildstream | 08:43 | |
| *** NatashaOakl47 has quit IRC | 08:46 | |
| *** lachlan has joined #buildstream | 09:01 | |
| *** lachlan has quit IRC | 09:08 | |
| *** lachlan has joined #buildstream | 09:09 | |
| *** tristan has quit IRC | 09:11 | |
| *** lachlan has quit IRC | 09:12 | |
| *** lachlan has joined #buildstream | 09:18 | |
| *** lachlan has quit IRC | 09:21 | |
| *** ikerperez has joined #buildstream | 09:27 | |
| *** MicheleMatu has joined #buildstream | 09:29 | |
| *** tristan has joined #buildstream | 09:30 | |
| *** ChanServ sets mode: +o tristan | 09:30 | |
| *** lachlan has joined #buildstream | 09:31 | |
| *** MicheleMatu has quit IRC | 09:33 | |
| *** phoenix has joined #buildstream | 09:39 | |
| *** lachlan has quit IRC | 09:39 | |
| *** lachlan has joined #buildstream | 09:39 | |
| traveltissues | are there any objections to https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/90 ? | 10:03 |
| tristan | traveltissues, it does make me wonder why the linter needs to be specifically informed for a marker that is implemented by a dependency | 10:08 |
| tristan | for 'integration', it makes sense since we implement that ourselves, and not as a module which should be able to advertise that it implements this marker | 10:09 |
| traveltissues | probably because the marks are registered in the setup config which is not being picked up | 10:09 |
| tristan | traveltissues, it's probably best to just fix it for now with that explicit statement | 10:14 |
| *** narispo has quit IRC | 10:14 | |
| *** narispo has joined #buildstream | 10:15 | |
| tristan | we (or I) can whine about why these components are not designed to fit together automatically without explicit sprinklings of tweaks separately | 10:15 |
| tristan | if it is designed to 'just work' though, it would be good to investigate using datafiles properly, if we're just doing it wrong | 10:16 |
| * tristan would also note that the datafiles thing appears to be such a trivial thing, it seems weird that we go to lengths to use it as an external dependency rather than just reimplementing it ourselves | 10:17 | |
| traveltissues | tristan: aiui this is not an implementation issue, the newer versions of pytest have changed unregistered markers to warning to prevent typos | 10:18 |
| traveltissues | if you mean that this should be automatically registered since it's in the config for buildstream then i'm not sure if that would be a good thing since one config would be overriding another | 10:20 |
| traveltissues | anyway, someone will have to hit the merge since i don't have merge access | 10:20 |
| benschubert | tristan: > it does make me wonder why the linter needs to be specifically informed for a marker that is implemented by a dependency | 10:24 |
| benschubert | That is because they did not register it, it is a bug in their project :( | 10:24 |
| tristan | benschubert, Ah I see, I think the datafiles project itself is rather unmaintained, I think I recall seeing one revision of it over the years | 10:25 |
| benschubert | yep, it's "stable so we won't touch" but pytest moves under it | 10:26 |
| benschubert | we _could_ reimplement the subset of it we use. Though having something 'familiar' though dated might be easier (since datafiles is quite used) | 10:26 |
| tristan | Meh, lets just merge traveltissues's patch then :) | 10:28 |
| benschubert | done | 10:29 |
| benschubert | done and added the link to the issue on pytest-datafiles' repo | 10:29 |
| benschubert | the PR on their repo is up and passing since june :'D | 10:31 |
| traveltissues | i'd appreciate a review of this: https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/91 this is primarily a poc plugin at the moment but has usecases similar to https://gitlab.com/celduin/remote-execution/bazel-gtk-hello (although in the opposite direction) | 11:00 |
| benschubert | traveltissues: I'm not sure I get everything: It only works with C/C++ right? And if I'm correct, Bazel will not need to rebuild it, but will just includ it as is? | 11:05 |
| traveltissues | it currently only supports c/c++ yes, via cc_library and cc_binary calls, there are a number of improvements/features that would be useful for this plugin but as a basic usecase those aren't needed. in terms of 'rebuilding', this plugin is intended to produce the BUILD for a bazel project to use directly, whether that means any actual compilation will need to occur will vary from project to project aiui, but in the case where the output is | 11:10 |
| traveltissues | just a collection of cc_library calls on so/a library blobs then it should just be configuring linking | 11:10 |
| traveltissues | if i understand those rules correctly | 11:10 |
| benschubert | would it be planned to add other support than cc_library/cc_binary to this one directly? (Like Python/fortran/java?) | 11:14 |
| benschubert | because if not, I believe we should rename | 11:14 |
| traveltissues | rename the plugin? | 11:15 |
| benschubert | yep | 11:15 |
| traveltissues | technically the rule can be overriden via the config | 11:15 |
| tristan | I'm not familiar enough with bazel to have an in depth opinion here but... I would put on the table another option to having different plugins for different languages... | 11:15 |
| tristan | One might reason about a plugin which generates this bazel BUILD input metadata by way of collecting public data from it's dependencies | 11:16 |
| tristan | I'm not saying that it's necessarily better, but something to consider, and might offer interesting flexibility | 11:16 |
| traveltissues | that probably makes sense tristan just to avoid the inevitability of a monolithic plugin | 11:16 |
| tristan | I'm also thinking if you're going to build a stack with bazel, you probably want more than one language supported, and you probably want to collect edge cases from your runtime/input | 11:17 |
| benschubert | Yep, I think that we should have this discussion before merging the plugin in if that's possible, so we have a consistent stance on Bazel, since it will inevitably have questions around :D | 11:17 |
| tristan | in that case, you'd want to annotate special cases on specific elements which introduce them, rather than having them all in one place | 11:17 |
| traveltissues | i agree, it's one of the reasons i wanted to send the mr | 11:17 |
| traveltissues | motivating the discussion i mean | 11:18 |
| persia | While I find the use of public data to do that very rich, I wonder if many bazel projects support that. The ones I've seen mostly seem to assume either a total repository of everything or a well-defined "platform" and a total respository of everything atop that platform. | 11:18 |
| persia | For use of Bazel within BuildStream, I would assume the BuildStream dependency set would inform the platform, such that the Bazel project could use "host" tooling and libraries for the most part (as these are tracked and sandboxed already). | 11:18 |
| tristan | persia, I'm personally envisioning this plugin as something one uses in late stages of a pipeline intended to create such a runtime blob for bazel consumption | 11:19 |
| tristan | but I might be off base :) | 11:19 |
| traveltissues | i also thought it worthwhile sending the mr earlier rather than later since my exposure to bazel is pretty limited and the usecase i prototyped it on top of is specific | 11:19 |
| persia | tristan: Maybe. My thought was that BuildStream might want to consume something that uses Bazel as a project build system, to be treated as just another component. I could be equally off-base :) | 11:20 |
| traveltissues | tristan: that is how i intended it to be used when i was writing it at least, whether that is how people would want to use it i'm not sure | 11:20 |
| tristan | There are probably various ways to fry the cat | 11:20 |
| tristan | Personally I'm still very much interested in the bazel plugin approach discussed at Build Meetup, where we might intersperse multiple bazel projects at various levels of the pipeline, feeding it dependencies and sharing the CAS | 11:21 |
| tristan | But this appears to have not materialized yet and I think is a completely separate topic (one need not block the other) | 11:21 |
| traveltissues | persia: from my perspective this is intended to be independent of any bazel client, the idea is that the owners of a bst project may want to use this sort of plugin to provide build calls to people maintaining bazel projects. Those bazel projects should be able to directly consume it | 11:22 |
| persia | Indeed. I think that discussion led to many ideas, which were intended to be rediscussed before implementation in New York last week. We should probably have that discussion on the mailing list instead. | 11:22 |
| persia | traveltissues: Ah, so this is about producing an output artifact for consumption *by bazel*. Yes, that's different to what I was thinking. (might be reentrant, but that should be immaterial). Naming is probably very important here. | 11:23 |
| coldtom | aiui this is so that bazel projects can manage their system dependencies in buildstream | 11:24 |
| traveltissues | persia: coldtom yes that's also my understanding. exactly what other features/conveniences buildstream might provide need more thought but at the least this will allow bazel project owners to get necessary dependency metadata from a buildstream project which i think has use on its own | 11:26 |
| persia | Yes, probably. | 11:28 |
| *** cs-shadow has joined #buildstream | 11:34 | |
| abderrahim[m] | Regarding the cache key change in !1549. 1. the change makes sense (i.e. new version generates a potentially different artifact, so the cache key should be different), 2. the change fixes a bug, 3. the change is already released as part of 1.4.2, and 4. this isn't unprecedented, !1127 changes the cache key for filter elements and was released with 1.2.4 | 11:51 |
| gitlab-br-bot | MR !1549: plugins/elements/cmake.yaml: always specify variable types https://gitlab.com/BuildStream/buildstream/-/merge_requests/1549 | 11:51 |
| gitlab-br-bot | MR !1127: filter.py: don't recurse when staging dependencies https://gitlab.com/BuildStream/buildstream/-/merge_requests/1127 | 11:51 |
| abderrahim[m] | granted the issue fixed by !1127 is arguably more severe (it can't be easily worked around in projects), but still... | 11:52 |
| tristan | abderrahim[m], changing cache keys in previous releases is certainly something we were not supposed to do, though :-/ | 11:56 |
| tristan | if it snuck into previous micro point releases, that was a mistake on our part | 11:56 |
| tristan | We're going to have to figure out what strategy we need for bst-2, as we'll want to tighten that up even further, and never implicitly break cache keys with feature-addition minor point releases | 11:57 |
| tristan | It may be we need a feature for this, or a recommendation that people override so-and-so for certain elements in their project.conf | 11:58 |
| *** lachlan has quit IRC | 12:01 | |
| *** phoenix has quit IRC | 12:01 | |
| tristan | Any thoughts on https://buildstream.gitlab.io/-/buildstream/-/jobs/510145769/artifacts/public/main_using.html ? | 13:04 |
| tristan | This is the docs rendered by !1864 | 13:05 |
| gitlab-br-bot | MR !1864: WIP: User guide enhancements https://gitlab.com/BuildStream/buildstream/-/merge_requests/1864 | 13:05 |
| *** tpollard has quit IRC | 13:05 | |
| *** tpollard has joined #buildstream | 13:06 | |
| *** ElenaRosse has joined #buildstream | 13:20 | |
| *** ElenaRosse has quit IRC | 13:23 | |
| *** lachlan has joined #buildstream | 13:30 | |
| persia | tristan: Looks much nicer to me. I especially like to see "Advanced Features" gone, making the content formerly hidden there more accessible. | 13:42 |
| *** phoenix has joined #buildstream | 14:25 | |
| *** LisaMarie has joined #buildstream | 14:39 | |
| *** lachlan has quit IRC | 14:41 | |
| *** LisaMarie has quit IRC | 14:43 | |
| *** lantw44 has quit IRC | 14:48 | |
| *** lantw44 has joined #buildstream | 14:48 | |
| *** lantw44 has quit IRC | 14:49 | |
| *** lantw44 has joined #buildstream | 14:49 | |
| *** lachlan has joined #buildstream | 14:50 | |
| jjardon | tristan: maybe examples at the end or as a subcategory makes more sense? | 15:22 |
| *** lachlan has quit IRC | 15:29 | |
| *** lachlan has joined #buildstream | 15:30 | |
| *** tristan has quit IRC | 15:54 | |
| *** BritManuela has joined #buildstream | 16:11 | |
| *** BritManuela has quit IRC | 16:14 | |
| gitlab-br-bot | juergbi opened MR !1865 (juerg/cache-key->master: element.py: Fix strong cache key calculation in non-strict mode) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1865 | 16:24 |
| *** lachlan has quit IRC | 16:30 | |
| gitlab-br-bot | marge-bot123 merged MR !1845 (juerg/platform->master: Improve sandbox configuration handling) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1845 | 16:34 |
| *** mohan43u has quit IRC | 16:35 | |
| *** lachlan has joined #buildstream | 16:40 | |
| *** Anabella has joined #buildstream | 16:41 | |
| *** tristan has joined #buildstream | 16:43 | |
| *** Anabella has quit IRC | 16:44 | |
| *** ChanServ sets mode: +o tristan | 16:44 | |
| *** lachlan has quit IRC | 16:52 | |
| *** phoenix has quit IRC | 16:54 | |
| *** lachlan has joined #buildstream | 16:58 | |
| *** phoenix has joined #buildstream | 16:59 | |
| *** mohan43u has joined #buildstream | 17:22 | |
| douglaswinship | This might be a dumb question, but do buildstream plugins generally depend on outside software? ie do you need to have git installed on your pc to use the git source plugins? Or bazaar installed to use the bazaar plugin? | 17:30 |
| douglaswinship | It never really occured to me before, but I just got a build failure on a remote machine. It's complaining that bazaar wasn't installed. | 17:31 |
| tpollard | douglaswinship: yes | 17:32 |
| tpollard | the source plugins in general depend on the underlying host tool | 17:32 |
| douglaswinship | thanks | 17:32 |
| douglaswinship | I mean it makes sense, as soon as you think about it. | 17:32 |
| douglaswinship | Just never thought about it before. | 17:33 |
| douglaswinship | thanks | 17:33 |
| tpollard | hmm, I can understand why you might not assume so | 17:34 |
| tpollard | similar projects build their own source tools | 17:34 |
| juergbi | sandboxing source plugins could be interesting but it gets somewhat tricky with bootstrapping | 17:38 |
| tpollard | :) indeed | 17:38 |
| juergbi | sandboxing for commands executed by element plugins is definitely more important, in my opinion, and we already have that | 17:39 |
| juergbi | however, it would be nice to support sandboxing for source fetching as well | 17:39 |
| *** RosieRoff has joined #buildstream | 17:47 | |
| *** RosieRoff has quit IRC | 17:50 | |
| *** santi has quit IRC | 17:58 | |
| *** tpollard has quit IRC | 17:58 | |
| *** phoenix has quit IRC | 18:16 | |
| *** lachlan has quit IRC | 18:16 | |
| *** phoenix has joined #buildstream | 18:27 | |
| *** phoenix has quit IRC | 18:35 | |
| *** rdale has quit IRC | 18:48 | |
| *** ReginaRus has joined #buildstream | 19:03 | |
| *** ReginaRus has quit IRC | 19:06 | |
| *** benschubert has quit IRC | 19:28 | |
| *** toscalix has joined #buildstream | 19:39 | |
| *** Honey2bee has joined #buildstream | 20:25 | |
| *** phoenix has joined #buildstream | 20:27 | |
| *** Honey2bee has quit IRC | 20:28 | |
| *** toscalix has quit IRC | 20:34 | |
| *** phoenix has quit IRC | 21:20 | |
| *** cs-shadow has quit IRC | 21:24 | |
| *** phoenix has joined #buildstream | 21:29 | |
| *** phoenix has quit IRC | 21:34 | |
| *** CaraDeLevi has joined #buildstream | 21:40 | |
| *** phoenix has joined #buildstream | 21:43 | |
| *** CaraDeLevi has quit IRC | 21:44 | |
| *** phoenix has quit IRC | 23:28 | |
| *** narispo has quit IRC | 23:30 | |
| *** narispo has joined #buildstream | 23:30 | |
| *** phoenix has joined #buildstream | 23:38 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!