IRC logs for #buildstream for Thursday, 2018-11-29

*** cs-shadow has quit IRC00:49
*** nimish has quit IRC01:02
*** mohan43u has quit IRC02:17
*** abderrah1 has joined #buildstream03:17
*** abderrahim has quit IRC03:17
*** mohan43u has joined #buildstream04:54
*** tristan has joined #buildstream05:59
*** nimish has joined #buildstream06:52
*** nimish has quit IRC07:12
*** nimish has joined #buildstream07:15
*** Colleen has joined #buildstream07:26
*** finn has joined #buildstream08:39
gitlab-br-botvalentindavid closed issue #678 (CAS: Avoid double write for received blobs) on buildstream https://gitlab.com/BuildStream/buildstream/issues/67808:47
gitlab-br-botvalentindavid closed issue #678 (CAS: Avoid double write for received blobs) on buildstream https://gitlab.com/BuildStream/buildstream/issues/67808:47
gitlab-br-botvalentindavid merged MR !830 (valentindavid/cache_server_fill_up->master: Fix cleanup of cache in server when disk is full) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/83008:47
*** alatiera has joined #buildstream08:50
*** phildawson_ has joined #buildstream08:52
jjardontristan: ok to add me as an approver for https://gitlab.com/BuildStream/website ?08:58
jjardonjuergbi:  paulsherwood  valentind toscalix ? ^09:02
* juergbi is not an approver for that project either09:08
valentindjjardon, try now?09:10
*** ChanServ sets mode: +o tristan09:10
valentindYou were already on the list of approvers.09:11
tristanvalentind, I just added him seconds ago09:11
tristanmid-air collision09:11
valentindtristan, ah ok09:11
jjardonthanks both!09:12
jjardonvalentind: I've just merged your fixes09:13
*** toscalix has joined #buildstream09:20
*** tristan has quit IRC09:23
*** WSalmon_ has joined #buildstream09:30
*** tiagogomes_whostolemyidentity has joined #buildstream09:40
*** kapil___ has joined #buildstream09:47
*** tiagogomes_whostolemyidentity has quit IRC09:51
*** tiagogomes has joined #buildstream09:52
*** tiagogomes has quit IRC09:52
*** tiagogomes has joined #buildstream09:52
*** jonathanmaw has joined #buildstream09:53
*** tristan has joined #buildstream09:55
*** tpollard has joined #buildstream09:56
*** raoul has joined #buildstream10:05
*** rdale has joined #buildstream10:16
valentindjjardon, thank you10:18
gitlab-br-botjjardon opened issue #794 (Build some CI jobs with buildstream remote execution) on buildstream https://gitlab.com/BuildStream/buildstream/issues/79410:26
*** rdale has quit IRC10:30
*** lachlan has joined #buildstream10:31
gitlab-br-botjmacarthur closed issue #786 (Remove calls to verify_digest_pushed in _sandboxremote.) on buildstream https://gitlab.com/BuildStream/buildstream/issues/78610:42
gitlab-br-botjmacarthur merged MR !976 (jmac/no-verify-digests->master: _sandboxremote.py: Remove unnecessary tests.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/97610:42
juergbitristan: what's your opinion on !972 ?10:49
gitlab-br-botMR !972: plugins/sources/git.py: Do not checkout submodules by default https://gitlab.com/BuildStream/buildstream/merge_requests/97210:49
valentindI all10:54
valentindI am all for it!10:55
valentindOne thing that the issue does not say is that mirroring requires you to declare your submodules anyway.10:55
valentindSo for the user who wants to enable mirroring, it is less surprising that automatic submodule checkout does not work if it is disabled by default.10:56
juergbiit might indeed be a sensible default. my worry is mainly about breaking backward compatibility10:57
valentindStill would be nice to get the blessing from tristan.10:57
juergbiI thought that was the main reason why we set the default to True when introduction the option10:57
juergbiso why change it now that there are more projects that could break10:58
juergbi*introducing10:58
*** lachlan has quit IRC10:59
*** lachlan has joined #buildstream11:04
*** nimish has quit IRC11:14
jennisjuergbi here is a small project that replicates the junction's bug: https://gitlab.com/jennis/bstjunctionsbug11:14
*** nimish has joined #buildstream11:14
jennisFor anyone else interested, if we use the same junction twice in a project, but name it differently, we get an error saying that BuildStream cannot find the 'kind' key in the dictionary of one of the junction's elements.11:16
jennisHowever, if the junctions have consistent naming, then we're fine.11:16
*** WSalmon_ has quit IRC11:17
jennisIMO, we should be able to use different names11:17
*** phildawson_ has quit IRC11:29
juergbijennis: thanks for creating a test case11:32
gitlab-br-botjennis opened issue #795 (BuildStream crashes when we try to use the same junction twice, but named differently) on buildstream https://gitlab.com/BuildStream/buildstream/issues/79511:41
jennisjuergbi no problem, I've also filed an issue ^11:43
gitlab-br-botjmacarthur opened issue #796 (CASCache methods can throw RpcError but don't declare it) on buildstream https://gitlab.com/BuildStream/buildstream/issues/79611:44
jmacjuergbi: #796 ^ is a very minor issue but you might have an opinion on it11:46
*** aiden has quit IRC11:48
*** ChanServ sets mode: +o tristan11:48
tristanjuergbi, oops... sry was booking flights and stuff...11:48
tristanWeird11:49
tristanjuergbi, valentind; what's the rationale behind *not* checking out submodules by default ?11:49
tristan"Always better to be explicit", I mean... isn't it better to assume that if submodules exist, they serve a purpose, and allow being explicit about disabling that ?11:50
jennismhmm, I also had a problem where it *wasn't* checking out submodules by default the other day, I'll see if I can replicate this11:50
tpollardI think it's counter intuitive that the behaviour is opposite to git itself11:51
tpollardbut that might just be me11:51
tristanMy take on it, is that maybe from a project maintainer perspective, it makes sense to "know that your module requires or does not require submodules at a given time"11:52
tpollardI've also used quite a few submodule based repos where there's user defined configuration to decided which submodule are needed11:52
WSalmonjonathanmaw, sorry i didnt see your message, my connection to this channel has been a bit bugy11:52
tristanAnd from the perspective of someone who is integrating a ton of modules together, you want things to "just work" as much as possible all the time, without having to know details about individual modules11:53
tristanSo maybe the more appropriate question is; is the current default more, or less convenient on average ?11:54
tristanWhich default forces less work on the bst project authors ?11:54
* tristan makes a comment on the MR11:55
tristanor on #783 rather, that looks more appropriate place11:55
gitlab-br-botIssue #783: plugins/sources/git.py: Do not checkout submodules by default https://gitlab.com/BuildStream/buildstream/issues/78311:55
tristanjjardon, valentind; comment up here: https://gitlab.com/BuildStream/buildstream/issues/783#note_12105124012:04
* tristan is a bit perplexed at this request honestly12:05
* tristan thinks this cycle has been a bit of a breakage fiasco, and will find more peace of mind when we can return to a strict black and white "No you can't do that; because breaks are not allowed" world.12:09
jjardontristan: well, I'd say current behaviour is broken12:36
jjardonif they are needed I want to explicit set the dependency in my bst files, not download them under the bst courtain12:36
*** nimish has quit IRC12:44
*** nimish has joined #buildstream12:45
tristanjjardon, You want to be forced to know about whether there are submodules in a module you use or not ?12:45
jjardontristan: yes12:45
tristanjjardon, How about this; a warning (configurable as fatal), if you fail to manually specify urls for the submodules that a module uses12:45
tristanThat way you get told if submodules exist that you dont know about, and you can opt-in to enforcing that knowledge in your project12:46
jjardontristan: similar I do not want a random script to wget something when building12:46
tristanBut the default operation is that that things "just work"12:46
tristanjjardon, There is absolutely nothing "random" about it, it's explicitly specified by the upstream as something required by the git repo, by virtue of it being a submodule12:47
jjardonI think that default is broken, for the reason I told you before.12:47
tristanand it's not a random script which calls wget12:47
tristanWhat reason ?12:47
jjardontristan: ok, so why disable network connection at all dureing builds?12:47
tristangit defines in it's data, other specific sources which are needed to constitute the entire repo12:48
tristanjjardon, Absolutely not, git submodules are fetched from their URLs at fetch time exactly like the primary module's URL12:48
jjardontristan: right, and I want to be aware of it12:48
tristanThere is nothing different from the submodules as the main module, and there is no room for non-determinism either12:48
tristanWhich is why I think the best default is to "just work", that is the most user friendly12:49
jjardontristan: what is the difference between that and wget feching a tarball during ./autogen.sh12:49
jjardontristan: not even git defaults to that12:49
jjardonyou have to explicity download the submodules12:50
tristanjjardon, a tarball that you rely on an ./autogen.sh script is not guaranteed to be checksummed by your trusted integration tool like a tar source would be12:50
tristanA git submodule comes with exactly the same guarantees of determinism as the primary git source12:50
*** rdale has joined #buildstream12:51
tristanjjardon, The fact that git is explicitly annoying to work with, does not mean we cannot provide a more convenient experience12:51
jjardonI do not want _anything_ to be downloaded in my system I do not explicit allow12:51
jjardonok imagine after  wget I have a checksum test12:52
jjardonthat is not the problem12:52
tristanjjardon, And the semantic difference here is that you think a git+submodules is not already an explicit thing12:52
tristanI am saying that it is12:52
tristanThe repository clearly states the URL and commit shas, which is the same guarantee we provide for the primary URL of a git repo12:53
jjardonagain, the repo can wget files from internet as well in their scripts12:53
tristanjjardon, the only reason I can fathom is to avoid situations where you want to be sure to alias all of the involved URLs, for which I provided an alternative suggestion above12:53
tristanjjardon, No that is cheating... "git" by itself is the revisioned storage, it by itself clearly states all of the components which setup the directory for a build12:54
tristanThis is much different than trusting the *content* of that revision storage12:54
tristanjjardon, The reason for disallowing network connectivity at build time is to ensure there is no opportunity for non-determinism12:55
tristanWith git submodules, we provide this guarantee, and it's built in to the storage mechanism (git)12:55
jjardontristan: the fact that I do not need some of the submodules to build some of my elements means you are not rigth about determinism there12:55
tristanjjardon, Again read my comments... if you want to optimize because *sometimes* you dont need some of the things defined by the complete layout including submodules, you can do *that* explicitly12:56
tristanjjardon, But having things *just work* is more important than having things optimized12:56
tristan(i.e. comments I made on the issue)12:56
tristanand I'll repeat the above, there is another approach to provide this policy for your project with a single statement, without making things less "works out of the box"12:57
tristan<tristan> jjardon, How about this; a warning (configurable as fatal), if you fail to manually specify urls for the submodules that a module uses12:57
tristan<tristan> That way you get told if submodules exist that you dont know about, and you can opt-in to enforcing that knowledge in your project12:57
jjardonI know I can, I still think the current default is not correct, as makes builds that are not correct (or seem correct but are not) happen by default12:57
tristanI.e. that would solve your case if that's what you wanted, with a single fatal-warnings statement ^^^12:58
tristanHow do they make things incorrect ?12:58
jjardontristan: I have already solved it with the current default in freedesktop-sdk, that issue is to raise the default is incorrect (from my point of view, of course)12:58
tristanIf they *are* incorrect, i.e. the upstream maintainers declared submodules which when checked out, produce an unintended result ?12:59
jjardonnot exactly12:59
tristanThen they are *certainly* still deterministic12:59
jjardonfor example12:59
jjardonno12:59
tristanExplain12:59
jjardonbecause autotools can use the submodule or the system package, only depending on what is present12:59
jjardonfor example12:59
tristanSo in this instance, it's important to consider how often submodules are used this way, I posit that that is the less common case, in which case *those* exceptions are worth an explicit activity of saying "dont download submodules"13:00
tristanDefaults should be optimized towards the common case13:01
jjardonwhen you are managing 200 repos you dont have time to go one by one chaking they are using submodules correctly13:02
jjardonso your default if making my job more difficult, not easier13:02
tristanjjardon, That is exactly the opposite13:04
tristanjjardon, When you are managing 200 repos, you don't want to care about the detail of whether a module uses submodules or not, or when you upgrade one of those repos that it happened to start using a submodule13:05
tristanYou want to just "get the input"13:05
tristanThe very weird case that someone decided to put a conditional check in their autotools setup to call back into git, is the exception, not the rule13:05
tristanWhen you recursively track your modules, you dont want to break just because a module started codesharing some things with a submodule, you want things to keep "just working"13:06
*** phildawson_ has joined #buildstream13:21
*** nimish has quit IRC13:25
*** nimish has joined #buildstream13:25
jjardontristan: I care13:35
*** nimish has quit IRC13:35
jjardonand yes I want things to break if that happen13:35
*** nimish has joined #buildstream13:35
tristanjjardon, What I am seeing here, is that you stumbled on an exceptional case where the default inconvenienced you, and your knee jerk reaction is to argue the default should be changed such as to inconvenience the majority of cases, instead of this one.13:37
jjardonno13:37
tristanI am also offering up a perfectly sane alternative which does not break existing projects, but I don't think you are reading it.13:37
jjardonI want to have control to what is being downloaded and from where, that is all13:37
jjardonas I said, I already have a solution with the current defaults13:38
jjardonthe issue was about changing the default because IMHO is broken13:38
tpollardI think the configurable fatal is reasonable, as with the ref not in track one13:38
tristanjjardon, I mean a solution which would cause you to have an error in the future, if it ever happens again13:38
tristanjjardon, does your solution do this ?13:39
jjardonyep13:39
jjardonsec13:39
tristanIt's with an illegally subclassed git plugin ?13:39
jjardontristan: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/merge_requests/742/diffs13:39
jjardontristan: no13:40
tristanAh right, yeah we even have a way to make a project wide default !13:40
tristanThis is such a non-issue13:40
tristanSo you are anyway opting into this behavior project wide13:40
jjardonyeah, and the argument is that this should be the default, not the other way around13:41
tristanOk, that ship sailed a long time ago, you are arguing to break API for something which can be solved with a single project-wide statement13:41
jjardonI understand is a break change and maybe because for that reason you don't want to apply it, but still I have to raise the issue13:42
tristanAsides from the fact that I disagree with your reasoning, I think we should just close this and stop discussing it13:42
jjardontristan: we are breaking things for much less important things, to be honest13:42
tristanjjardon, I disagree that the default should be the opposite, but in any case we should not do the break especially that we have a project wide way to control it13:43
tristanAND, we are not introducing such changes that almost certainly break every project13:43
tristanWe are introducing breakages to the command line invocations13:43
tristanOnes which are less likely to be used in a CI setting also13:44
tristanjjardon, The breaks we are introducing have mostly the risk to annoy a command line user once or twice when upgrading to 1.413:44
tristanNot changes which break peoples projects, if we are, those are much much worse and deserve a lot more careful consideration13:44
tristanOrthogonally to this discussion, an "unlisted submodule" warning that can be fatal is still something valuable to implement13:45
*** nimish has quit IRC13:45
juergbiNexus: !670 is the other MR I meant13:46
gitlab-br-botMR !670: Continued work on improving BuildStream messaging API https://gitlab.com/BuildStream/buildstream/merge_requests/67013:46
*** nimish has joined #buildstream13:46
jjardonI can argue about not making the change because break things, but I still think the default is broken and can lead to broken projects. Happy to change that MR to an update to the docs, to warning about this13:46
juergbiNexus: with that we'd have context.warn()13:46
*** lachlan has quit IRC14:05
*** WSalmon_ has joined #buildstream14:09
*** finn_ has joined #buildstream14:12
*** finn has quit IRC14:13
Nexusjuergbi: Do you feel we need a second pass on reading the fatal warnings from yaml?14:14
tristanjjardon, The normal case when a git repo has a submodule, is that before you run any build script you need to fetch the submodules. The consequence of the default you are arguing for is that by default: The user adds a git repo to their stack or runs `bst track` on an existing one, and when a submodule presents itself - the build breaks. BuildStream also does not have a way to inform the user *why* the build breaks, and the most likely error14:15
tristanmessage the user will get is something like "No rule to make foo.c"14:15
tristanjjardon, I can't see how this can possibly be a good thing14:15
jjardontristan: no, not always14:16
tristanNormally14:16
jjardonas I said before I do not need the submodules to build some of the components14:16
tristanExactly, and because of that, you are suggesting to make things inconvenient for the *rest* of components14:16
jjardonif be explicit about what I'm putting in my system is inconvenient, then I guess you are right14:18
jjardonyou default is more convenient, but you dont really have a view of the components being put in the system14:18
jjardonor how thay are really being build14:19
tristanThats what I'm saying, as a starting point; things being convenient is better. Once you start drilling down into individual problematic elements, then explicitly add statements to make them work the way you need them to14:20
tristanOptimize defaults for things working out of the box, optimize for less frustration14:20
*** lachlan has joined #buildstream14:22
tiagogomesDidn't read the backlog but submodules are opt-in rather than opt-out, so I'd that buildstream worked in the same way14:23
tristanAlso, back to the warning; to increase awareness: It would be great to have a warning that there is a submodule URL that is not explicitly aliased/mentioned in the .bst file14:23
jjardonwell, I guess we have different views of what is more optimal. For me current default is less potimal as we have to "discover" (only by looking one by one) this submodules at some point, instead make them integrate correctly from the begining14:23
jjardontristan: sure, that warning would improve things14:23
tristanThat is very easy to add, also14:23
tristanLemme think... it would of course be nice if we had *one* warning with a summary of all unlisted submodules, but that would be more tricky to implement as it comes from a plugin14:24
tristanStill, one warning per element which has unlisted submodules would be fine and increase awareness of them existing14:24
*** nimish has quit IRC14:26
jjardonyup14:26
*** nimish has joined #buildstream14:26
valentindjuergbi, Just to be sure, you are done with the review of !908?14:31
gitlab-br-botMR !908: Add support for .netrc in remote/tar/zip plugins https://gitlab.com/BuildStream/buildstream/merge_requests/90814:31
gitlab-br-botjuergbi approved MR !908 (valentindavid/netrc->master: Add support for .netrc in remote/tar/zip plugins) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/90814:53
*** WSalmon_ has quit IRC14:54
*** lachlan has quit IRC14:56
*** WSalmon_ has joined #buildstream14:59
*** lachlan has joined #buildstream14:59
juergbiNexus: I'd prefer removing the second load pass for fatal warnings. potentially having two different configurations for this during the load process could be confusing to the user15:00
juergbiit would be good to actually report an error when a user attempts to set fatal-warning in an include (and thus the second pass would yield a different result)15:01
*** tristan has quit IRC15:02
juergbihowever, that also affects format-version and the other first pass keys, so it's probably out of scope for this MR15:02
* Kinnison would concur with such an error message being out of scope15:08
gitlab-br-botvalentindavid opened MR !979 (valentindavid/cache_server_fill_up-1.2->bst-1.2: [backport 1.2] Fix cleanup of cache in server when disk is full) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/97915:16
*** nimish has quit IRC15:26
*** nimish has joined #buildstream15:27
*** benschubert has joined #buildstream15:29
*** tristan has joined #buildstream15:34
*** adds68 has quit IRC15:58
*** jennis has quit IRC15:58
*** ikerperez has quit IRC15:58
*** coldtom has quit IRC15:58
*** phildawson has quit IRC15:58
*** jennis has joined #buildstream16:00
*** coldtom has joined #buildstream16:02
*** adds68 has joined #buildstream16:03
*** ikerperez has joined #buildstream16:03
jennisFollowing up from a recent ML discussion regarding the creation of a container plugins repo, is someone able to make a BuildStream/bst-plugins-containers repo and add jonathanmaw as maintainer and myself as developer?16:04
jennisjuergbi?16:04
*** lachlan has quit IRC16:06
*** nimish has quit IRC16:12
*** nimish has joined #buildstream16:12
Nexusjuergbi: Please could you review https://gitlab.com/BuildStream/buildstream/merge_requests/967 for me again? :)16:15
gitlab-br-botvalentindavid closed issue #723 (Use .netrc information to fetch archive files) on buildstream https://gitlab.com/BuildStream/buildstream/issues/72316:15
gitlab-br-botvalentindavid merged MR !908 (valentindavid/netrc->master: Add support for .netrc in remote/tar/zip plugins) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/90816:15
juergbiNexus: will do16:19
Nexusta :)16:20
*** lachlan has joined #buildstream16:22
*** WSalmon_ has quit IRC16:29
*** WSalmon_ has joined #buildstream16:30
*** Trevinho has quit IRC16:32
*** lachlan has quit IRC16:35
jmacAnyone familiar with docker import? What registry-url and image parameter should I use for https://hub.docker.com/r/buildstream/image-tools/ ?16:35
gitlab-br-botaevri opened (was WIP) MR !957 (aevri/safe_noninteractive->master: BREAK: make destructive action scripts consistent) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/95716:38
*** cs-shadow has joined #buildstream16:47
jennisjmac, I think you just need: image: buildstream/image-tools16:50
jennisAs the default registry is the docker one, so you shouldn't have to include this16:50
*** lachlan has joined #buildstream16:52
jennisHowever, if you wanna be explicit, you can always set `registry-url: https://registry.hub.docker.com` in the element16:52
juergbibenschubert: regarding the discussion about the docker sandbox backend, the OCI runtime spec was actually released last year17:04
jmacThat didn't work, it just says "   [00:00:02] FAILURE base.bst: 403 Client Error: Forbidden for url: https://production.cloudflare.docker.com/registry-v2/docker/registry/v2/blobs/sha256/50/505a602065b20757cb5ca31eb251c09d6c30afcd78cad25904b6578c3056b320/data?verify=1543514207-rQSmaRwABCktYzjmksrQTtPYjQQ%3D17:07
*** nimish has quit IRC17:07
*** nimish has joined #buildstream17:07
*** Trevinho has joined #buildstream17:11
benschubertjuergbi: oh that seems great, I'll give it a look!17:12
gitlab-br-botjonathanmaw opened MR !980 (jonathan/fix-identical-element->master: _yamlcache.py: Use a project's junction name if present) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/98017:20
gitlab-br-botaevri opened MR !981 (aevri/update_man->master: man/: update with changes since Apr 2018) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/98117:23
*** lachlan has quit IRC17:24
*** nimish has quit IRC17:37
*** nimish has joined #buildstream17:38
*** alyawn has joined #buildstream17:38
*** lachlan has joined #buildstream17:46
*** lachlan has quit IRC17:46
*** finn_ has quit IRC17:47
*** dtf has joined #buildstream17:57
gitlab-br-botjuergbi opened issue #797 (Remote Execution: Don't ignore stdout and stderr) on buildstream https://gitlab.com/BuildStream/buildstream/issues/79717:58
*** jonathanmaw has quit IRC17:59
*** tpollard has quit IRC18:04
*** WSalmon_ has quit IRC18:17
*** alatiera has quit IRC18:30
*** lachlan has joined #buildstream18:35
*** nimish has quit IRC18:40
*** raoul has quit IRC18:42
Kinnisonjuergbi: If you're good with !967 then it's green and able to be merged18:43
gitlab-br-botMR !967: Mandatory .bst suffix https://gitlab.com/BuildStream/buildstream/merge_requests/96718:43
*** nimish has joined #buildstream18:43
Kinnisonjuergbi: At least that's the impression I get from Nexus18:43
*** alatiera has joined #buildstream18:44
*** alatiera has quit IRC18:48
*** xjuan has joined #buildstream19:08
*** toscalix has quit IRC19:09
*** alatiera has joined #buildstream19:10
*** nimish has quit IRC19:23
*** nimish has joined #buildstream19:23
*** rdale has quit IRC19:26
*** nimish has quit IRC19:32
*** nimish has joined #buildstream19:38
*** nimish has quit IRC19:43
*** nimish has joined #buildstream19:44
*** nimish has quit IRC19:54
*** nimish has joined #buildstream19:54
*** finn has joined #buildstream20:01
*** alatiera has quit IRC20:08
*** tristan has quit IRC20:18
*** nimish has quit IRC20:29
*** nimish has joined #buildstream20:35
*** nimish has quit IRC20:45
*** finn has quit IRC21:09
*** finn has joined #buildstream21:11
*** finn has joined #buildstream21:21
*** finn has joined #buildstream21:25
*** finn has quit IRC21:25
*** nimish has joined #buildstream21:26
*** nimish has quit IRC21:46
*** nimish has joined #buildstream21:46
cs-shadowjuergbi: the problem with choosing OCI runtime spec is that it's just that - a spec. We still need to choose some tooling to actually run containers that will across platforms. For example, we can use things like runc (instead of Docker) to run something that conforms to the OCI spec. But the problem is that it is difficult to have runc on Mac/Windows in the same way that "Docker for Windows/Mac" is readily available.21:51
*** nimish has quit IRC21:56
*** nimish has joined #buildstream21:56
*** nimish has quit IRC22:11
*** nimish has joined #buildstream22:12
*** nimish has quit IRC22:17
*** nimish has joined #buildstream22:38
*** nimish has quit IRC22:43
*** xjuan has quit IRC22:43
*** nimish has joined #buildstream22:43
*** nimish has joined #buildstream23:09
*** nimish has quit IRC23:14
*** nimish has joined #buildstream23:14
*** nimish has quit IRC23:29
*** nimish has joined #buildstream23:30
*** nimish has quit IRC23:40

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