*** cs-shadow has quit IRC | 00:49 | |
*** nimish has quit IRC | 01:02 | |
*** mohan43u has quit IRC | 02:17 | |
*** abderrah1 has joined #buildstream | 03:17 | |
*** abderrahim has quit IRC | 03:17 | |
*** mohan43u has joined #buildstream | 04:54 | |
*** tristan has joined #buildstream | 05:59 | |
*** nimish has joined #buildstream | 06:52 | |
*** nimish has quit IRC | 07:12 | |
*** nimish has joined #buildstream | 07:15 | |
*** Colleen has joined #buildstream | 07:26 | |
*** finn has joined #buildstream | 08:39 | |
gitlab-br-bot | valentindavid closed issue #678 (CAS: Avoid double write for received blobs) on buildstream https://gitlab.com/BuildStream/buildstream/issues/678 | 08:47 |
---|---|---|
gitlab-br-bot | valentindavid closed issue #678 (CAS: Avoid double write for received blobs) on buildstream https://gitlab.com/BuildStream/buildstream/issues/678 | 08:47 |
gitlab-br-bot | valentindavid 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/830 | 08:47 |
*** alatiera has joined #buildstream | 08:50 | |
*** phildawson_ has joined #buildstream | 08:52 | |
jjardon | tristan: ok to add me as an approver for https://gitlab.com/BuildStream/website ? | 08:58 |
jjardon | juergbi: paulsherwood valentind toscalix ? ^ | 09:02 |
* juergbi is not an approver for that project either | 09:08 | |
valentind | jjardon, try now? | 09:10 |
*** ChanServ sets mode: +o tristan | 09:10 | |
valentind | You were already on the list of approvers. | 09:11 |
tristan | valentind, I just added him seconds ago | 09:11 |
tristan | mid-air collision | 09:11 |
valentind | tristan, ah ok | 09:11 |
jjardon | thanks both! | 09:12 |
jjardon | valentind: I've just merged your fixes | 09:13 |
*** toscalix has joined #buildstream | 09:20 | |
*** tristan has quit IRC | 09:23 | |
*** WSalmon_ has joined #buildstream | 09:30 | |
*** tiagogomes_whostolemyidentity has joined #buildstream | 09:40 | |
*** kapil___ has joined #buildstream | 09:47 | |
*** tiagogomes_whostolemyidentity has quit IRC | 09:51 | |
*** tiagogomes has joined #buildstream | 09:52 | |
*** tiagogomes has quit IRC | 09:52 | |
*** tiagogomes has joined #buildstream | 09:52 | |
*** jonathanmaw has joined #buildstream | 09:53 | |
*** tristan has joined #buildstream | 09:55 | |
*** tpollard has joined #buildstream | 09:56 | |
*** raoul has joined #buildstream | 10:05 | |
*** rdale has joined #buildstream | 10:16 | |
valentind | jjardon, thank you | 10:18 |
gitlab-br-bot | jjardon opened issue #794 (Build some CI jobs with buildstream remote execution) on buildstream https://gitlab.com/BuildStream/buildstream/issues/794 | 10:26 |
*** rdale has quit IRC | 10:30 | |
*** lachlan has joined #buildstream | 10:31 | |
gitlab-br-bot | jmacarthur closed issue #786 (Remove calls to verify_digest_pushed in _sandboxremote.) on buildstream https://gitlab.com/BuildStream/buildstream/issues/786 | 10:42 |
gitlab-br-bot | jmacarthur merged MR !976 (jmac/no-verify-digests->master: _sandboxremote.py: Remove unnecessary tests.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/976 | 10:42 |
juergbi | tristan: what's your opinion on !972 ? | 10:49 |
gitlab-br-bot | MR !972: plugins/sources/git.py: Do not checkout submodules by default https://gitlab.com/BuildStream/buildstream/merge_requests/972 | 10:49 |
valentind | I all | 10:54 |
valentind | I am all for it! | 10:55 |
valentind | One thing that the issue does not say is that mirroring requires you to declare your submodules anyway. | 10:55 |
valentind | So 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 |
juergbi | it might indeed be a sensible default. my worry is mainly about breaking backward compatibility | 10:57 |
valentind | Still would be nice to get the blessing from tristan. | 10:57 |
juergbi | I thought that was the main reason why we set the default to True when introduction the option | 10:57 |
juergbi | so why change it now that there are more projects that could break | 10:58 |
juergbi | *introducing | 10:58 |
*** lachlan has quit IRC | 10:59 | |
*** lachlan has joined #buildstream | 11:04 | |
*** nimish has quit IRC | 11:14 | |
jennis | juergbi here is a small project that replicates the junction's bug: https://gitlab.com/jennis/bstjunctionsbug | 11:14 |
*** nimish has joined #buildstream | 11:14 | |
jennis | For 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 |
jennis | However, if the junctions have consistent naming, then we're fine. | 11:16 |
*** WSalmon_ has quit IRC | 11:17 | |
jennis | IMO, we should be able to use different names | 11:17 |
*** phildawson_ has quit IRC | 11:29 | |
juergbi | jennis: thanks for creating a test case | 11:32 |
gitlab-br-bot | jennis 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/795 | 11:41 |
jennis | juergbi no problem, I've also filed an issue ^ | 11:43 |
gitlab-br-bot | jmacarthur opened issue #796 (CASCache methods can throw RpcError but don't declare it) on buildstream https://gitlab.com/BuildStream/buildstream/issues/796 | 11:44 |
jmac | juergbi: #796 ^ is a very minor issue but you might have an opinion on it | 11:46 |
*** aiden has quit IRC | 11:48 | |
*** ChanServ sets mode: +o tristan | 11:48 | |
tristan | juergbi, oops... sry was booking flights and stuff... | 11:48 |
tristan | Weird | 11:49 |
tristan | juergbi, 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 |
jennis | mhmm, I also had a problem where it *wasn't* checking out submodules by default the other day, I'll see if I can replicate this | 11:50 |
tpollard | I think it's counter intuitive that the behaviour is opposite to git itself | 11:51 |
tpollard | but that might just be me | 11:51 |
tristan | My 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 |
tpollard | I've also used quite a few submodule based repos where there's user defined configuration to decided which submodule are needed | 11:52 |
WSalmon | jonathanmaw, sorry i didnt see your message, my connection to this channel has been a bit bugy | 11:52 |
tristan | And 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 modules | 11:53 |
tristan | So maybe the more appropriate question is; is the current default more, or less convenient on average ? | 11:54 |
tristan | Which default forces less work on the bst project authors ? | 11:54 |
* tristan makes a comment on the MR | 11:55 | |
tristan | or on #783 rather, that looks more appropriate place | 11:55 |
gitlab-br-bot | Issue #783: plugins/sources/git.py: Do not checkout submodules by default https://gitlab.com/BuildStream/buildstream/issues/783 | 11:55 |
tristan | jjardon, valentind; comment up here: https://gitlab.com/BuildStream/buildstream/issues/783#note_121051240 | 12:04 |
* tristan is a bit perplexed at this request honestly | 12: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 | |
jjardon | tristan: well, I'd say current behaviour is broken | 12:36 |
jjardon | if they are needed I want to explicit set the dependency in my bst files, not download them under the bst courtain | 12:36 |
*** nimish has quit IRC | 12:44 | |
*** nimish has joined #buildstream | 12:45 | |
tristan | jjardon, You want to be forced to know about whether there are submodules in a module you use or not ? | 12:45 |
jjardon | tristan: yes | 12:45 |
tristan | jjardon, How about this; a warning (configurable as fatal), if you fail to manually specify urls for the submodules that a module uses | 12:45 |
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 project | 12:46 |
jjardon | tristan: similar I do not want a random script to wget something when building | 12:46 |
tristan | But the default operation is that that things "just work" | 12:46 |
tristan | jjardon, 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 submodule | 12:47 |
jjardon | I think that default is broken, for the reason I told you before. | 12:47 |
tristan | and it's not a random script which calls wget | 12:47 |
tristan | What reason ? | 12:47 |
jjardon | tristan: ok, so why disable network connection at all dureing builds? | 12:47 |
tristan | git defines in it's data, other specific sources which are needed to constitute the entire repo | 12:48 |
tristan | jjardon, Absolutely not, git submodules are fetched from their URLs at fetch time exactly like the primary module's URL | 12:48 |
jjardon | tristan: right, and I want to be aware of it | 12:48 |
tristan | There is nothing different from the submodules as the main module, and there is no room for non-determinism either | 12:48 |
tristan | Which is why I think the best default is to "just work", that is the most user friendly | 12:49 |
jjardon | tristan: what is the difference between that and wget feching a tarball during ./autogen.sh | 12:49 |
jjardon | tristan: not even git defaults to that | 12:49 |
jjardon | you have to explicity download the submodules | 12:50 |
tristan | jjardon, 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 be | 12:50 |
tristan | A git submodule comes with exactly the same guarantees of determinism as the primary git source | 12:50 |
*** rdale has joined #buildstream | 12:51 | |
tristan | jjardon, The fact that git is explicitly annoying to work with, does not mean we cannot provide a more convenient experience | 12:51 |
jjardon | I do not want _anything_ to be downloaded in my system I do not explicit allow | 12:51 |
jjardon | ok imagine after wget I have a checksum test | 12:52 |
jjardon | that is not the problem | 12:52 |
tristan | jjardon, And the semantic difference here is that you think a git+submodules is not already an explicit thing | 12:52 |
tristan | I am saying that it is | 12:52 |
tristan | The repository clearly states the URL and commit shas, which is the same guarantee we provide for the primary URL of a git repo | 12:53 |
jjardon | again, the repo can wget files from internet as well in their scripts | 12:53 |
tristan | jjardon, 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 above | 12:53 |
tristan | jjardon, 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 build | 12:54 |
tristan | This is much different than trusting the *content* of that revision storage | 12:54 |
tristan | jjardon, The reason for disallowing network connectivity at build time is to ensure there is no opportunity for non-determinism | 12:55 |
tristan | With git submodules, we provide this guarantee, and it's built in to the storage mechanism (git) | 12:55 |
jjardon | tristan: the fact that I do not need some of the submodules to build some of my elements means you are not rigth about determinism there | 12:55 |
tristan | jjardon, 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* explicitly | 12:56 |
tristan | jjardon, But having things *just work* is more important than having things optimized | 12:56 |
tristan | (i.e. comments I made on the issue) | 12:56 |
tristan | and 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 uses | 12: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 project | 12:57 |
jjardon | I 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 default | 12:57 |
tristan | I.e. that would solve your case if that's what you wanted, with a single fatal-warnings statement ^^^ | 12:58 |
tristan | How do they make things incorrect ? | 12:58 |
jjardon | tristan: 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 |
tristan | If they *are* incorrect, i.e. the upstream maintainers declared submodules which when checked out, produce an unintended result ? | 12:59 |
jjardon | not exactly | 12:59 |
tristan | Then they are *certainly* still deterministic | 12:59 |
jjardon | for example | 12:59 |
jjardon | no | 12:59 |
tristan | Explain | 12:59 |
jjardon | because autotools can use the submodule or the system package, only depending on what is present | 12:59 |
jjardon | for example | 12:59 |
tristan | So 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 |
tristan | Defaults should be optimized towards the common case | 13:01 |
jjardon | when you are managing 200 repos you dont have time to go one by one chaking they are using submodules correctly | 13:02 |
jjardon | so your default if making my job more difficult, not easier | 13:02 |
tristan | jjardon, That is exactly the opposite | 13:04 |
tristan | jjardon, 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 submodule | 13:05 |
tristan | You want to just "get the input" | 13:05 |
tristan | The 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 rule | 13:05 |
tristan | When 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 #buildstream | 13:21 | |
*** nimish has quit IRC | 13:25 | |
*** nimish has joined #buildstream | 13:25 | |
jjardon | tristan: I care | 13:35 |
*** nimish has quit IRC | 13:35 | |
jjardon | and yes I want things to break if that happen | 13:35 |
*** nimish has joined #buildstream | 13:35 | |
tristan | jjardon, 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 |
jjardon | no | 13:37 |
tristan | I 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 |
jjardon | I want to have control to what is being downloaded and from where, that is all | 13:37 |
jjardon | as I said, I already have a solution with the current defaults | 13:38 |
jjardon | the issue was about changing the default because IMHO is broken | 13:38 |
tpollard | I think the configurable fatal is reasonable, as with the ref not in track one | 13:38 |
tristan | jjardon, I mean a solution which would cause you to have an error in the future, if it ever happens again | 13:38 |
tristan | jjardon, does your solution do this ? | 13:39 |
jjardon | yep | 13:39 |
jjardon | sec | 13:39 |
tristan | It's with an illegally subclassed git plugin ? | 13:39 |
jjardon | tristan: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/merge_requests/742/diffs | 13:39 |
jjardon | tristan: no | 13:40 |
tristan | Ah right, yeah we even have a way to make a project wide default ! | 13:40 |
tristan | This is such a non-issue | 13:40 |
tristan | So you are anyway opting into this behavior project wide | 13:40 |
jjardon | yeah, and the argument is that this should be the default, not the other way around | 13:41 |
tristan | Ok, that ship sailed a long time ago, you are arguing to break API for something which can be solved with a single project-wide statement | 13:41 |
jjardon | I 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 issue | 13:42 |
tristan | Asides from the fact that I disagree with your reasoning, I think we should just close this and stop discussing it | 13:42 |
jjardon | tristan: we are breaking things for much less important things, to be honest | 13:42 |
tristan | jjardon, 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 it | 13:43 |
tristan | AND, we are not introducing such changes that almost certainly break every project | 13:43 |
tristan | We are introducing breakages to the command line invocations | 13:43 |
tristan | Ones which are less likely to be used in a CI setting also | 13:44 |
tristan | jjardon, The breaks we are introducing have mostly the risk to annoy a command line user once or twice when upgrading to 1.4 | 13:44 |
tristan | Not changes which break peoples projects, if we are, those are much much worse and deserve a lot more careful consideration | 13:44 |
tristan | Orthogonally to this discussion, an "unlisted submodule" warning that can be fatal is still something valuable to implement | 13:45 |
*** nimish has quit IRC | 13:45 | |
juergbi | Nexus: !670 is the other MR I meant | 13:46 |
gitlab-br-bot | MR !670: Continued work on improving BuildStream messaging API https://gitlab.com/BuildStream/buildstream/merge_requests/670 | 13:46 |
*** nimish has joined #buildstream | 13:46 | |
jjardon | I 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 this | 13:46 |
juergbi | Nexus: with that we'd have context.warn() | 13:46 |
*** lachlan has quit IRC | 14:05 | |
*** WSalmon_ has joined #buildstream | 14:09 | |
*** finn_ has joined #buildstream | 14:12 | |
*** finn has quit IRC | 14:13 | |
Nexus | juergbi: Do you feel we need a second pass on reading the fatal warnings from yaml? | 14:14 |
tristan | jjardon, 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 error | 14:15 |
tristan | message the user will get is something like "No rule to make foo.c" | 14:15 |
tristan | jjardon, I can't see how this can possibly be a good thing | 14:15 |
jjardon | tristan: no, not always | 14:16 |
tristan | Normally | 14:16 |
jjardon | as I said before I do not need the submodules to build some of the components | 14:16 |
tristan | Exactly, and because of that, you are suggesting to make things inconvenient for the *rest* of components | 14:16 |
jjardon | if be explicit about what I'm putting in my system is inconvenient, then I guess you are right | 14:18 |
jjardon | you default is more convenient, but you dont really have a view of the components being put in the system | 14:18 |
jjardon | or how thay are really being build | 14:19 |
tristan | Thats 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 to | 14:20 |
tristan | Optimize defaults for things working out of the box, optimize for less frustration | 14:20 |
*** lachlan has joined #buildstream | 14:22 | |
tiagogomes | Didn't read the backlog but submodules are opt-in rather than opt-out, so I'd that buildstream worked in the same way | 14:23 |
tristan | Also, 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 file | 14:23 |
jjardon | well, 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 begining | 14:23 |
jjardon | tristan: sure, that warning would improve things | 14:23 |
tristan | That is very easy to add, also | 14:23 |
tristan | Lemme 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 plugin | 14:24 |
tristan | Still, one warning per element which has unlisted submodules would be fine and increase awareness of them existing | 14:24 |
*** nimish has quit IRC | 14:26 | |
jjardon | yup | 14:26 |
*** nimish has joined #buildstream | 14:26 | |
valentind | juergbi, Just to be sure, you are done with the review of !908? | 14:31 |
gitlab-br-bot | MR !908: Add support for .netrc in remote/tar/zip plugins https://gitlab.com/BuildStream/buildstream/merge_requests/908 | 14:31 |
gitlab-br-bot | juergbi approved MR !908 (valentindavid/netrc->master: Add support for .netrc in remote/tar/zip plugins) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/908 | 14:53 |
*** WSalmon_ has quit IRC | 14:54 | |
*** lachlan has quit IRC | 14:56 | |
*** WSalmon_ has joined #buildstream | 14:59 | |
*** lachlan has joined #buildstream | 14:59 | |
juergbi | Nexus: 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 user | 15:00 |
juergbi | it 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 IRC | 15:02 | |
juergbi | however, that also affects format-version and the other first pass keys, so it's probably out of scope for this MR | 15:02 |
* Kinnison would concur with such an error message being out of scope | 15:08 | |
gitlab-br-bot | valentindavid 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/979 | 15:16 |
*** nimish has quit IRC | 15:26 | |
*** nimish has joined #buildstream | 15:27 | |
*** benschubert has joined #buildstream | 15:29 | |
*** tristan has joined #buildstream | 15:34 | |
*** adds68 has quit IRC | 15:58 | |
*** jennis has quit IRC | 15:58 | |
*** ikerperez has quit IRC | 15:58 | |
*** coldtom has quit IRC | 15:58 | |
*** phildawson has quit IRC | 15:58 | |
*** jennis has joined #buildstream | 16:00 | |
*** coldtom has joined #buildstream | 16:02 | |
*** adds68 has joined #buildstream | 16:03 | |
*** ikerperez has joined #buildstream | 16:03 | |
jennis | Following 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 |
jennis | juergbi? | 16:04 |
*** lachlan has quit IRC | 16:06 | |
*** nimish has quit IRC | 16:12 | |
*** nimish has joined #buildstream | 16:12 | |
Nexus | juergbi: Please could you review https://gitlab.com/BuildStream/buildstream/merge_requests/967 for me again? :) | 16:15 |
gitlab-br-bot | valentindavid closed issue #723 (Use .netrc information to fetch archive files) on buildstream https://gitlab.com/BuildStream/buildstream/issues/723 | 16:15 |
gitlab-br-bot | valentindavid merged MR !908 (valentindavid/netrc->master: Add support for .netrc in remote/tar/zip plugins) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/908 | 16:15 |
juergbi | Nexus: will do | 16:19 |
Nexus | ta :) | 16:20 |
*** lachlan has joined #buildstream | 16:22 | |
*** WSalmon_ has quit IRC | 16:29 | |
*** WSalmon_ has joined #buildstream | 16:30 | |
*** Trevinho has quit IRC | 16:32 | |
*** lachlan has quit IRC | 16:35 | |
jmac | Anyone 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-bot | aevri opened (was WIP) MR !957 (aevri/safe_noninteractive->master: BREAK: make destructive action scripts consistent) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/957 | 16:38 |
*** cs-shadow has joined #buildstream | 16:47 | |
jennis | jmac, I think you just need: image: buildstream/image-tools | 16:50 |
jennis | As the default registry is the docker one, so you shouldn't have to include this | 16:50 |
*** lachlan has joined #buildstream | 16:52 | |
jennis | However, if you wanna be explicit, you can always set `registry-url: https://registry.hub.docker.com` in the element | 16:52 |
juergbi | benschubert: regarding the discussion about the docker sandbox backend, the OCI runtime spec was actually released last year | 17:04 |
jmac | That 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%3D | 17:07 |
*** nimish has quit IRC | 17:07 | |
*** nimish has joined #buildstream | 17:07 | |
*** Trevinho has joined #buildstream | 17:11 | |
benschubert | juergbi: oh that seems great, I'll give it a look! | 17:12 |
gitlab-br-bot | jonathanmaw 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/980 | 17:20 |
gitlab-br-bot | aevri opened MR !981 (aevri/update_man->master: man/: update with changes since Apr 2018) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/981 | 17:23 |
*** lachlan has quit IRC | 17:24 | |
*** nimish has quit IRC | 17:37 | |
*** nimish has joined #buildstream | 17:38 | |
*** alyawn has joined #buildstream | 17:38 | |
*** lachlan has joined #buildstream | 17:46 | |
*** lachlan has quit IRC | 17:46 | |
*** finn_ has quit IRC | 17:47 | |
*** dtf has joined #buildstream | 17:57 | |
gitlab-br-bot | juergbi opened issue #797 (Remote Execution: Don't ignore stdout and stderr) on buildstream https://gitlab.com/BuildStream/buildstream/issues/797 | 17:58 |
*** jonathanmaw has quit IRC | 17:59 | |
*** tpollard has quit IRC | 18:04 | |
*** WSalmon_ has quit IRC | 18:17 | |
*** alatiera has quit IRC | 18:30 | |
*** lachlan has joined #buildstream | 18:35 | |
*** nimish has quit IRC | 18:40 | |
*** raoul has quit IRC | 18:42 | |
Kinnison | juergbi: If you're good with !967 then it's green and able to be merged | 18:43 |
gitlab-br-bot | MR !967: Mandatory .bst suffix https://gitlab.com/BuildStream/buildstream/merge_requests/967 | 18:43 |
*** nimish has joined #buildstream | 18:43 | |
Kinnison | juergbi: At least that's the impression I get from Nexus | 18:43 |
*** alatiera has joined #buildstream | 18:44 | |
*** alatiera has quit IRC | 18:48 | |
*** xjuan has joined #buildstream | 19:08 | |
*** toscalix has quit IRC | 19:09 | |
*** alatiera has joined #buildstream | 19:10 | |
*** nimish has quit IRC | 19:23 | |
*** nimish has joined #buildstream | 19:23 | |
*** rdale has quit IRC | 19:26 | |
*** nimish has quit IRC | 19:32 | |
*** nimish has joined #buildstream | 19:38 | |
*** nimish has quit IRC | 19:43 | |
*** nimish has joined #buildstream | 19:44 | |
*** nimish has quit IRC | 19:54 | |
*** nimish has joined #buildstream | 19:54 | |
*** finn has joined #buildstream | 20:01 | |
*** alatiera has quit IRC | 20:08 | |
*** tristan has quit IRC | 20:18 | |
*** nimish has quit IRC | 20:29 | |
*** nimish has joined #buildstream | 20:35 | |
*** nimish has quit IRC | 20:45 | |
*** finn has quit IRC | 21:09 | |
*** finn has joined #buildstream | 21:11 | |
*** finn has joined #buildstream | 21:21 | |
*** finn has joined #buildstream | 21:25 | |
*** finn has quit IRC | 21:25 | |
*** nimish has joined #buildstream | 21:26 | |
*** nimish has quit IRC | 21:46 | |
*** nimish has joined #buildstream | 21:46 | |
cs-shadow | juergbi: 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 IRC | 21:56 | |
*** nimish has joined #buildstream | 21:56 | |
*** nimish has quit IRC | 22:11 | |
*** nimish has joined #buildstream | 22:12 | |
*** nimish has quit IRC | 22:17 | |
*** nimish has joined #buildstream | 22:38 | |
*** nimish has quit IRC | 22:43 | |
*** xjuan has quit IRC | 22:43 | |
*** nimish has joined #buildstream | 22:43 | |
*** nimish has joined #buildstream | 23:09 | |
*** nimish has quit IRC | 23:14 | |
*** nimish has joined #buildstream | 23:14 | |
*** nimish has quit IRC | 23:29 | |
*** nimish has joined #buildstream | 23:30 | |
*** nimish has quit IRC | 23:40 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!