| *** mohan43u has quit IRC | 04:04 | |
| *** mohan43u has joined #buildstream | 04:04 | |
| *** tristan has quit IRC | 05:45 | |
| *** tristan has joined #buildstream | 05:50 | |
| juergbi | hi tristan, hm, I think we always said that BuildStream should be able to use more scalable CAS severs than bst-artifact-server. it seems like you're saying the opposite in your latest comment is saying, or am I misreading that? | 06:59 |
|---|---|---|
| juergbi | oops, s/is saying// | 06:59 |
| *** ChanServ sets mode: +o tristan | 07:00 | |
| tristan | juergbi, I've never had that understanding for the artifact cache | 07:00 |
| juergbi | ok, but I think it's needed | 07:01 |
| tristan | juergbi, I've been told that CAS is not going to understand refs, as such we *need* our own custom thing | 07:01 |
| juergbi | yes but not instead of CAS but in addition to CAS | 07:01 |
| tristan | I've never heard of any plans to bake something in between | 07:01 |
| tristan | juergbi, if there are such plans, then feel free to say so :) | 07:01 |
| juergbi | https://gitlab.com/BuildStream/buildstream/issues/1041 | 07:01 |
| tristan | Honestly that design doesnt bother me | 07:01 |
| juergbi | in my mind the plan is to keep bst-artifact-server supporting both, our artifact service protocol and standard CAS | 07:02 |
| tristan | juergbi, What that conversation looks like is a user and a developer and nobody in between - jjardon gets told that "You can use a small service in addition to an abstract CAS implementation", leads to jjardon telling his friends, then we get random folks in the channel complaining that they don't understand how to do it | 07:03 |
| juergbi | I wrote that this will be possible when #1041 is implemented, and that should be correct | 07:03 |
| gitlab-br-bot | Issue #1041: Support seperate end points for artifact caches https://gitlab.com/BuildStream/buildstream/issues/1041 | 07:03 |
| tristan | Yes I know | 07:03 |
| juergbi | nothing else should be needed for that | 07:03 |
| tristan | Oh really ? | 07:04 |
| tristan | Sorry I didn't know that part at all | 07:04 |
| juergbi | it would simply not use the CAS part of bst-artifact-server | 07:04 |
| juergbi | we could also consider supporting bst-artifact-server to proxy CAS requests but that's not strictly needed for that | 07:05 |
| tristan | juergbi, That sounds very sensible, especially in cases where you want to use the same CAS for remote execution as you do for storing artifacts | 07:05 |
| juergbi | exactly | 07:05 |
| tristan | I wonder how expiry is going to work there | 07:05 |
| juergbi | expiry is anyway blob-based already on the server side | 07:05 |
| juergbi | there should probably be some logic in bst-artifact-server to expire refs when external CAS server is used | 07:06 |
| juergbi | I don't think it's a blocker, though | 07:06 |
| juergbi | although we probably need a bst-artifact-server CLI option to disable internal CAS but that should be trivial | 07:07 |
| juergbi | i.e., the ideal solution will require a bit more work than just #1041 but it should already be usable before that | 07:07 |
| tristan | I guess we already handle gracefully the cases where you download an artifact which turns out to be partial half way through the download ? | 07:09 |
| tristan | Because of course I guess... third party CAS implementations expire objects "however they please" | 07:09 |
| tristan | juergbi, I edited my misinformed comment above | 07:12 |
| tristan | above well... in the gitlab issue #1050 | 07:13 |
| gitlab-br-bot | Issue #1050: Not possible to use generic servers implementing the remote-apis as remote cache https://gitlab.com/BuildStream/buildstream/issues/1050 | 07:13 |
| juergbi | partial remote artifacts: yes, I think that's already handled in a reasonable way | 07:13 |
| tristan | I suppose the server just has to change it's expiry technique to also be object based... and then it could do nightly cleanup jobs which eliminate incomplete refs | 07:14 |
| tristan | as a brute force approach | 07:14 |
| juergbi | yes, periodic check with CAS server is a possibility, although it's a bit tricky as if the artifact server called FindMissingBlobs() on the CAS server, the CAS server will likely update the timestamps of all these blobs | 07:16 |
| juergbi | an alternative is simple time-based expiry on the artifact server, independent of what CAS is doing | 07:17 |
| juergbi | as CAS blob-based expiry typically deletes top-level directory objects at the same time or before its descendants, there is no huge overhead when a client has to check CAS whether the objects for an artifact are still there | 07:20 |
| juergbi | (it will typically fail very quickly) | 07:20 |
| juergbi | so artifact cache expiry for refs doesn't have to be very sophisticated. just need to make sure it doesn't collect cruft forever | 07:20 |
| juergbi | disk space should not be a real issue for refs as long as there is some expiry | 07:21 |
| *** toscalix has joined #buildstream | 07:21 | |
| *** tristan has quit IRC | 07:28 | |
| *** bochecha has joined #buildstream | 07:47 | |
| *** tristan has joined #buildstream | 07:49 | |
| *** alexandrufazakas has joined #buildstream | 08:18 | |
| benschubert | juergbi: I just read the cas discussion. Does that mean that even with a BuildGrid RE farm + BuildBox CAS server, we'll still need the bst-artifact-server, or am I mixing some stuff? | 08:20 |
| juergbi | benschubert: to have an actual artifact server, yes, you still need that | 08:21 |
| juergbi | it's not a prerequisite for remote execution, however, relying only on RE action cache would be quite a bit less efficient than having a real artifact server | 08:22 |
| benschubert | 'actual artifact server' -> a server from which I can pull artifacts with BuildStream corrrect? | 08:22 |
| juergbi | yes, i.e., only bst-artifact-server right now, although there could be other implementations | 08:22 |
| benschubert | are there any such plans for alternate implementations already existing? | 08:23 |
| juergbi | no, as the artifact server part (without CAS) should not be too resource intensive, the simple bst-artifact-server will likely be sufficient even for larger deployments | 08:24 |
| juergbi | that said, we'll have to wait and see whether we hit bottlenecks with the simple approach after all | 08:25 |
| juergbi | the artifact service protocol is very simple, though, so other implementations wouldn't require a lot of work (besides the actual scalable storage part if the filesystem approach is considered insufficient) | 08:26 |
| juergbi | (depending on the requirements for expiry but relatively simple approaches should work for that) | 08:26 |
| *** raoul has joined #buildstream | 08:27 | |
| benschubert | juergbi: I see, but the current one doesn't support a multi-node setup right? I could not have 4 nodes behind a proxy and expect them to work correctly? | 08:30 |
| juergbi | benschubert: it's filesystem-based. I think with the CAS part disabled and a suitable network filesystem, it might just work | 08:31 |
| benschubert | I see, thanks for the clarification | 08:31 |
| juergbi | should only require regular POSIX atomic rename | 08:32 |
| juergbi | no in-place modification after rename | 08:32 |
| benschubert | andw hat is stored exactly on the FS? | 08:32 |
| juergbi | the artifact protos for each buildstream cache key | 08:33 |
| benschubert | ok thanks! | 08:33 |
| juergbi | artifact protos contain the CAS digests for the artifact files, logs and some other metadata | 08:33 |
| juergbi | would probably also be fairly simple to write backends for arbitrary key value databases but there are no plans for that at the moment | 08:35 |
| *** tpollard has quit IRC | 08:38 | |
| *** tpollard has joined #buildstream | 08:39 | |
| juergbi | tristan: do you have an opinion on these new config keys? https://gitlab.com/BuildStream/buildstream/merge_requests/1402#note_182418922 | 08:44 |
| juergbi | two new config keys for this doesn't seem ideal. not sure what alternative would be better, though. | 08:45 |
| *** jonathanmaw has joined #buildstream | 09:07 | |
| *** phildawson has joined #buildstream | 09:08 | |
| alexandrufazakas | The `-C` option is not available on the stable version of bst, right? | 09:11 |
| *** ChanServ sets mode: +o tristan | 09:12 | |
| tristan | alexandrufazakas, yes it has always been there | 09:12 |
| tpollard | it should be in 1.2 I think alexandrufazakas | 09:12 |
| tristan | juergbi, I probably do... this looks like it will take quite a context switch... downloading blobs in which context etc... lemme try to decrypt this... | 09:14 |
| tristan | Ok I remember this long ago conversation | 09:15 |
| tristan | juergbi, Essentially I mentioned that the expectation when you build is to have the result, and that it should be the default | 09:15 |
| alexandrufazakas | tristan, tpollard: Err, am I doing something wrong here then? | 09:15 |
| tristan | remote or local execution shouldnt matter, default behaviors are default behaviors | 09:15 |
| tristan | alexandrufazakas, probably ? ;-) | 09:15 |
| alexandrufazakas | https://pastebin.com/CaHQvK0h | 09:16 |
| tpollard | alexandrufazakas: if you do bst --help, you should see it under the main options | 09:16 |
| alexandrufazakas | I forgot to drop that, sorry heh | 09:16 |
| juergbi | tristan: yes, that's the case in master and the MR souldn't change that. targets + runtime deps are in local cache by default | 09:16 |
| alexandrufazakas | ohh | 09:16 |
| tpollard | alexandrufazakas: it's a main option, so goes before the init command | 09:16 |
| alexandrufazakas | it's bst -C dir init | 09:16 |
| tristan | juergbi, right, I'm just recalling the conversation... so this is related to that... | 09:16 |
| alexandrufazakas | not bst init _C dir | 09:16 |
| alexandrufazakas | Yep | 09:16 |
| tristan | alexandrufazakas, :) | 09:16 |
| juergbi | tristan: exactly, the MR is about making this configurable | 09:16 |
| alexandrufazakas | tpollard: Thanks | 09:16 |
| alexandrufazakas | Sorry for pinging you guys with that :/ | 09:16 |
| tristan | alexandrufazakas, no worries ! | 09:17 |
| tpollard | np :) | 09:17 |
| tristan | juergbi, So withing thinking from too deeply in the patch... what are the behaviors we would *like* ? | 09:17 |
| gitlab-br-bot | aevri opened (was WIP) MR !1408 (aevri/smallerjobs2->master: _scheduler: don't pass whole queue to child job) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1408 | 09:18 |
| tristan | juergbi, I think that clearly we are talking about presence of the target and it's Scope.RUN dependencies | 09:18 |
| tristan | juergbi, if one wanted to download *all* dependencies, then this would be a separate object that is certainly not remote-execution specific | 09:18 |
| juergbi | tristan: afaict, the main option we want is to allow builds without guaranteeing any actual artifact files in the local cache | 09:19 |
| tristan | right, I think you suggested in the ticket that we might want configurability for all, but I think that is in the wrong place | 09:19 |
| juergbi | well, for local builds, --deps all would suffice for this | 09:19 |
| juergbi | while it isn't right now for RE | 09:19 |
| tristan | So enter consistency questions | 09:20 |
| tristan | Why have separate "remote execution" specific configurations for this ? | 09:20 |
| juergbi | there is a difference between local builds and remote builds in that for local builds we have to completely download all build dependencies for all builds we have to perform | 09:21 |
| juergbi | while with remote execution there is no such requirement, independent of --deps | 09:21 |
| tristan | juergbi, Perhaps it's better to have a configuration of (A) "Whether we want to ensure that build results are present in the local cache" (default I think)... (B) Whether we only care that build results end up in configured artifact cache servers (implied by A)... (C) Whether we want to ensure that all dependencies including build-of-build-of-build end up in the local cache | 09:22 |
| tristan | And not have it remote-execution related, just have remote-execution honor the setting ? | 09:22 |
| juergbi | maybe we can indeed go in that direction | 09:23 |
| juergbi | existing option --all could be used for (C) even for remote execution | 09:23 |
| tristan | Further, at first sight... I am quite strongly against any configuration with the wording "file blob" or "blob" in it's name | 09:23 |
| tristan | Those are words about low level things that BuildStream developers know about, they are not a part of the knowledge base of a user | 09:23 |
| juergbi | indeed, we need a good word for this. maybe simply artifact files or so | 09:24 |
| tristan | Whether we get the artifacts locally is the right word yeah, these things are artifacts | 09:24 |
| juergbi | to be precise, artifact metadata and directories will always be pulled | 09:24 |
| juergbi | they are required even for remote builds | 09:25 |
| juergbi | however, we might want to hide that detail from the user as well | 09:25 |
| tristan | juergbi, Then we need to decide (A) Does the user have to be burdened with the knowledge that having the metadata is any different from having the artifacts ? ... and (B) If not... then we should ensure that `bst artifact show` commands and the like, when operating on the local cache, don't yield results which will later fail on other artifact commands like `bst artifact checkout` | 09:26 |
| tristan | juergbi, right, essentially what you said with a lot more words :) | 09:26 |
| tristan | I rather tend to favor hiding that metadata from the user | 09:27 |
| juergbi | I'm not sure yet. for someone working in a pure remote execution environment it would be useful to have bst artifact show etc. still work | 09:27 |
| tristan | until a day comes that we have real justification to present that to the user, in which case we have to put thought into making it a coherent experience | 09:27 |
| juergbi | and bst artifact checkout implicitly pulling files | 09:27 |
| tristan | if I `list artifactcts in the local cache`, I certainly expect checking them out to succeed without any internet activity | 09:28 |
| tristan | on any artifact which was listed | 09:28 |
| juergbi | by default, yes | 09:28 |
| juergbi | however, there might be environments where a user wants to fully rely on remote caching | 09:28 |
| tristan | if checking out artifacts implicitly pulls, that is a different topic I think anyway | 09:28 |
| tristan | nice to implicitly pull yes, but expectations of scripts running in possibly intentionally isolated environments should be respected too | 09:29 |
| tristan | I might have some automation which does something to "all artifacts which match a given glob pattern" | 09:29 |
| juergbi | yes, we should definitely keep allowing the current behavior, and that should very likely remain the default | 09:30 |
| tristan | juergbi, Yes exactly | 09:30 |
| tristan | both should be allowed | 09:30 |
| tristan | now back to the more precise topic | 09:30 |
| tristan | If --all in `bst build` is a global non-remote-execution-specific option, I doubt that "ensure I have the artifacts locally" should be remote execution specific | 09:31 |
| tristan | Those appear to be quite the same setting | 09:31 |
| tristan | Also, --all has other implications | 09:31 |
| juergbi | yes, I think we can simplify things quite a bit | 09:31 |
| tristan | juergbi, --all not only ensures that the results are downloaded for build-of-build dependencies, but it ensures they are on the artifact cache server | 09:31 |
| tristan | for instance, what if we want to ensure the artifact cache server has build results fresh and ready to download for the bootstrapping phase, but we don't care about having those locally | 09:32 |
| tristan | it seems like a valid usecase for --all as well | 09:32 |
| juergbi | yes, but if we have one new option for local caching, the combination possibilities with --all might suffice | 09:33 |
| tristan | that does sound sensible | 09:33 |
| alexandrufazakas | Do all the directories created for testing have a `cache` subdirectory? | 09:33 |
| juergbi | tristan: I can't imagine the need for more fine-grained options at the moment, so I think we should do this | 09:34 |
| tristan | juergbi, we probably want to take the `--all` command line option and craft a user config option for it, and put this new option of "ensure-local-artifacts" or whatever it will be named, in the same group in the user config | 09:34 |
| juergbi | tristan: one aspect I'm not sure anymore is what exactly that new config option should be | 09:34 |
| juergbi | --all as user config option could make sense but I think we can consider this separate | 09:35 |
| tristan | juergbi, I am thinking that it is "Whether the user wants to be sure that the build result is present in the local cache after a build", and it is default True | 09:35 |
| tristan | juergbi, It is always true anyway in local build scenarios, but if remote execution is enabled, it will change the behavior | 09:36 |
| juergbi | right, but keeping the previous part of our discussion in mind, should it also mean 'bst artifact show' will show even partial artifacts | 09:36 |
| tristan | juergbi, but what the user is expressing with this option is what they want to happen | 09:36 |
| tristan | juergbi, lets tackle that discussion separately - there are multiple definitions of partial artifacts too | 09:37 |
| tristan | The answer might be yes if the artifact is there but is missing it's build tree | 09:37 |
| juergbi | it increases the risk of having to rename the option later if we don't discuss this yet, though | 09:38 |
| * tristan goes to fetch his clean laundry... | 09:38 | |
| tristan | Hmmm | 09:38 |
| juergbi | but maybe a separate discussion is indeed warranted and we might not want to block this MR on that | 09:38 |
| tristan | juergbi, ok well... think on it a bit if you have any ideas... I'll be back in 15 | 09:39 |
| juergbi | ok :) | 09:39 |
| tristan | I think it's a good start to go the way we discussed though | 09:39 |
| juergbi | yes, I think we're definitely going in the right direction | 09:40 |
| gitlab-br-bot | marge-bot123 merged MR !1427 (juerg/source-checkout->master: Fetch sources as needed for bst source checkout) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1427 | 09:41 |
| tlater[m] | alexandrufazakas: Not 100% on this, but you may find this useful: https://docs.pytest.org/en/latest/parametrize.html | 09:45 |
| *** raoul has quit IRC | 09:48 | |
| alexandrufazakas | tlater: I'll have a look, thanks | 09:49 |
| tlater[m] | Is there any way to run the overnight tests early for a specific branch? | 09:57 |
| * tlater[m] wants to try aarch64 because he changed the base image | 09:58 | |
| tristan | juergbi, I had some thoughts while folding my clothes | 09:58 |
| tristan | juergbi, I think definitely `bst artifact show` should never show artifacts for which it only has metadata, and if the *data* locally is partial, it should be possible to express that | 09:59 |
| tristan | juergbi, Secondly, I think `bst artifact show` shows the local cache by default | 09:59 |
| tristan | and if `bst artifact --remote URL show` or similar is used... then it *only* shows artifacts on *that* remote, not a combination of local + remote | 10:00 |
| tristan | juergbi, most importantly to bear in mind I think... is that when you write `bst artifact show` and check your local cache, you are basically guaranteed that the artifact will *still* be there in your next line in the script | 10:00 |
| tristan | unless you have called bst artifact delete or modified your local cache in some way | 10:01 |
| tristan | juergbi, When you type `bst artifact show` for a *remote* URL, it's really just speculation as to whether it will exist one second later or not | 10:01 |
| tristan | juergbi, essentially this is why we stopped printing "downloadable" state or checking what can be downloaded in advance | 10:02 |
| tristan | juergbi, does this generally make sense ? | 10:02 |
| juergbi | if 'bst artifact show' calls FindMissingBlobs on the remote, the CAS server is expected to retain those blobs for a reasonable amount of time | 10:02 |
| tristan | reasonable is not exactly specified | 10:03 |
| tristan | juergbi, I think that is all fine and good from an internal remote execution standpoint, and I see why | 10:03 |
| tristan | juergbi, Do you think that with this new API then... we should revive the initial query to the artifact server and "downloadable" state in `bst show` and `bst artifact show` ? | 10:04 |
| juergbi | I imagine some people will work in environments where they can rely on artifact/CAS server implementation that provides these guarantees | 10:04 |
| tristan | that is also another valid perspective I guess | 10:05 |
| tristan | the initial query can help guarantee that required dependencies will exist whilst building | 10:05 |
| tristan | juergbi, "reasonable" time frame is not a guarantee though... it implies that "When all is working well, it wont fail", while also implying that "anything built on top of this should expect things to sometimes fail" | 10:06 |
| juergbi | yes but even the local cache has expiry, so there is also no absolute guarantee | 10:07 |
| juergbi | robust scripts will require support for retry | 10:07 |
| tristan | juergbi, As long as there is not parallel instances there is an absolute guarantee yes | 10:07 |
| tristan | as long as you didnt write `bst artifact delete` or launch another build in between | 10:07 |
| juergbi | even bst pull in between can trigger expiry | 10:08 |
| tristan | And even if there are parallel local instances, scripts which setup their own artifact cache directory can have this guarantee | 10:08 |
| juergbi | so you have the guarantee really only if you don't do anything between those lines | 10:08 |
| tristan | exactly | 10:08 |
| juergbi | sure and scripts will always be able to do that | 10:08 |
| juergbi | but I don't think this means that we shouldn't provide the option to work in more opportunistic ways | 10:08 |
| juergbi | as in some environments that will work very well, at least as I imagine | 10:09 |
| juergbi | would probably make sense to confirm this with deployment plans of real users | 10:09 |
| tristan | I don't understand exactly what you mean by opportunistic, or your use of the word :-/ | 10:09 |
| juergbi | I mean without absolute guarantees | 10:09 |
| tristan | juergbi, What I want is certainty and knowing what I am dealing with | 10:10 |
| juergbi | i.e., relying on reasonable time frame being sufficient | 10:10 |
| juergbi | by default that will be the case | 10:10 |
| tristan | if I want to know what might be there for an undetermined by "probably long enough" amount of time, I will query the remote explicitly right ? | 10:10 |
| tristan | If I query the local cache, I get what is right now there | 10:10 |
| juergbi | a user shouldn't have to specify --remote every time | 10:10 |
| tristan | There I certainly disagree | 10:11 |
| juergbi | if they are in an environment where they can rely on the server being available | 10:11 |
| tristan | The artifacts which arent there just arent there | 10:11 |
| juergbi | maybe their environment actually has a never expiring CAS? | 10:11 |
| juergbi | that's not impossible | 10:11 |
| tristan | they might be in a remote, they are unobtainium until pulled | 10:11 |
| tristan | Now, you might want a semantic to query "the project remotes" for `bst artifact show` | 10:12 |
| tristan | but I really don't think that should be default | 10:12 |
| juergbi | I'm talking more generally, not specifically about 'bst artifact show' | 10:12 |
| juergbi | maybe that should be local only | 10:12 |
| juergbi | and not project-specific | 10:13 |
| tristan | But what other commands are there really ? | 10:13 |
| juergbi | but at least for everything project-specific that would make sense | 10:13 |
| tristan | I mean... for everything else, there is a clear definition of what will be done with remotes right ? | 10:13 |
| juergbi | and if a global not-project specific remote is configured, it probably makes sense for 'bst artifact show' as well | 10:14 |
| tristan | in user config | 10:14 |
| juergbi | yes | 10:14 |
| tristan | I still disagree that that should be default | 10:14 |
| juergbi | I'm not saying this should be the default | 10:14 |
| tristan | <tristan> Now, you might want a semantic to query "the project remotes" for `bst artifact show` | 10:14 |
| tristan | Essentially that | 10:14 |
| juergbi | I simply think that we should have an option for this in user config | 10:15 |
| tristan | the ones defined by normal recursive project definitions and user config | 10:15 |
| tristan | Ah, yeah you wont get any argument from me on that of course | 10:15 |
| juergbi | ok, was probably some misunderstanding | 10:15 |
| juergbi | with regards to the pending MR, my question is whether this should be the same user config option | 10:15 |
| tristan | I think mostly, if there is a CLI option, it should be in the user config | 10:16 |
| tristan | while the opposite is not always true | 10:16 |
| tristan | (there are current exceptions to this, but I think it's the right way generally) | 10:16 |
| tristan | anything configurable should be in the conf file (with a few obvious exceptions).... while the CLI is more selective about showing optionalities | 10:17 |
| tristan | juergbi, back to the original discussion ? still a question ? | 10:17 |
| juergbi | <juergbi> with regards to the pending MR, my question is whether this should be the same user config option | 10:18 |
| juergbi | I think this question still stands | 10:18 |
| tristan | Well lets thought experiment... I thought what we had was 2 options: (A) Whether we want to ensure everything is built (currently --all)... (B) Whether we want to ensure that build results exist locally after running a build | 10:18 |
| juergbi | yes, if we count --all, we definitely want at least two options | 10:19 |
| juergbi | my question is whether (B) should also control bst artifact show with regards to metadata-only local artifacts | 10:19 |
| tristan | I don't think those are the same | 10:20 |
| tristan | Unless you can think of something a user could express which really accurately covers both cases, I think they are different things | 10:20 |
| juergbi | i.e., should it essentially be a option to use a workflow designed for a reliable remote server instead of isolated operation | 10:21 |
| tristan | What you expect to materialize locally is different from what you expect to be querying | 10:21 |
| tristan | I see where you are going | 10:21 |
| juergbi | something like transparent-remote-caching (may not be the best name but might help with the meaning) | 10:21 |
| tristan | I feel like it's an attractive idea, but with all the moving pieces I'm reluctant to say with any certainty that that would suffice | 10:22 |
| juergbi | I can definitely understand that | 10:23 |
| juergbi | maybe it's better to just focus on the local caching for build aspect | 10:23 |
| juergbi | and reconsider the generic option in the future | 10:23 |
| juergbi | (possibly deprecating the other option) | 10:23 |
| tristan | was going to say similar | 10:23 |
| tristan | We could analyze workflows after those workflows materialize, learn from that and possibly add more global/easy switches | 10:24 |
| juergbi | yes, adapting based on experience is probably best | 10:24 |
| juergbi | worst case we have to deprecate an option. not the end of the world | 10:25 |
| tristan | juergbi, it's probably also better anyway to start with this separate approach code-wise | 10:26 |
| tristan | juergbi, i.e. already have resolved Context.foo switches which enable very specific modes of operation | 10:26 |
| tristan | instead of having code segments trying to know how to behave because of some global switch that that code segment thinks is smart enough to reason about | 10:27 |
| alexandrufazakas | tlater: Pushed my changes to !1430, I think all looks alright right now | 10:27 |
| gitlab-br-bot | MR !1430: Add bst init argument https://gitlab.com/BuildStream/buildstream/merge_requests/1430 | 10:27 |
| tristan | keep that reasoning in one place | 10:27 |
| alexandrufazakas | Or works, rather | 10:27 |
| juergbi | that can go either way. too fine grained switches can also be an issue when an operation could be influenced by multiple contradicting switches | 10:27 |
| tlater[m] | alexandrufazakas: I'll take a look | 10:27 |
| tristan | juergbi, fair, but I hope we don't get there :) | 10:28 |
| alexandrufazakas | tlater: Sweet, thanks | 10:28 |
| tristan | juergbi, in this case at least we're talking about the behavior of very separate activities | 10:29 |
| tlater[m] | alexandrufazakas: Almost there. I think I spotted another bug that you'll have to write a test case for ;) | 10:41 |
| alexandrufazakas | tlater: yay | 10:42 |
| alexandrufazakas | Btw, to run the linter I should get `detox`, right? | 10:42 |
| * tlater[m] has never heard of detox personally | 10:42 | |
| tlater[m] | Running the linter is possible using `tox -e linting` or somesuch | 10:43 |
| tlater[m] | Running the linter is possible using `tox -e lint` actually somesuch | 10:43 |
| alexandrufazakas | Oh | 10:43 |
| * tlater[m] isn't great at editing stuff in non-emacs apparently | 10:43 | |
| alexandrufazakas | That's for testing and linting in parallel I think? | 10:43 |
| alexandrufazakas | https://gitlab.com/BuildStream/buildstream/blob/master/CONTRIBUTING.rst#L1509 | 10:43 |
| alexandrufazakas | tlater: Yeah, I'll do that, thank you | 10:43 |
| tlater[m] | alexandrufazakas: No, it will only run pylint | 10:43 |
| tlater[m] | And pycodestyle, actually, probably mypy in the future (: | 10:44 |
| tlater[m] | alexandrufazakas: I've seen you use vi... If you're going to be programming for a little longer, I'd suggest installing https://github.com/prabirshrestha/vim-lsp and the python language server | 10:46 |
| tristan | tlater[m], alexandrufazakas, linting and testing in parallel *is* possible when you have detox installed | 10:46 |
| alexandrufazakas | tlater: Alright, i'll do that. Thank you :) | 10:46 |
| tristan | you can lint + test py[35,36,37] all in parallel | 10:47 |
| tristan | alexandrufazakas, however as tlater[m] says, that's not how we use it... we just lint separately from tests in gitlab CI | 10:47 |
| alexandrufazakas | tristan: Yep,I'll just use `tox -e` | 10:47 |
| tristan | but... it worked last time I checked, when I ensured that tmp directories were properly namespaced and fixed it to work | 10:47 |
| alexandrufazakas | `tox -e lint`, rather | 10:47 |
| tristan | alexandrufazakas, yeah, and `tox -e py{your favorit version}` | 10:48 |
| tristan | :) | 10:48 |
| alexandrufazakas | True | 10:48 |
| * tristan has all three and used to run `detox .` | 10:48 | |
| tlater[m] | alexandrufazakas: Also, if you get it installed, vim-lsp will run the linter for you and show errors as you edit :) | 10:48 |
| alexandrufazakas | I only have .5 right now so I'm only using that, I should probably look for all of them | 10:48 |
| tristan | but it's been a while since I did that | 10:48 |
| tristan | alexandrufazakas, yeah you actually don't have to specify, it will just test for each discovered python version on your system (that we support) | 10:49 |
| alexandrufazakas | Ah that makes sense, ye | 10:49 |
| alexandrufazakas | tlater: Thanks for the review, I'll start working on them in a second :) | 10:51 |
| *** lachlan has joined #buildstream | 10:51 | |
| alexandrufazakas | I was considering renaming that argument btw, I just wasn't sure what. Naming things is so cumbersome :/ | 10:51 |
| tlater[m] | Haha, agreed | 10:51 |
| tlater[m] | Tell me if you can figure out how to use that "recommendation" feature | 10:51 |
| tlater[m] | It looked cute, so I wrote actual recommendation code for once | 10:51 |
| tlater[m] | You're supposed to be able to apply it directly somehow | 10:52 |
| alexandrufazakas | tlater: I'll have a look at it | 10:52 |
| alexandrufazakas | tlater: Not sure how to install those vim thingies however, how should I `Plug 'prabirshrestha/async.vim'` | 10:53 |
| tlater[m] | alexandrufazakas: That is for you to find out, I've never used vim? in any capacity, haha. Just recommending a nicer workflow with the tools you have :) | 10:54 |
| alexandrufazakas | Right | 10:55 |
| alexandrufazakas | I'm sure google might help | 10:55 |
| *** lachlan has quit IRC | 10:57 | |
| tlater[m] | Could I get some review for https://gitlab.com/BuildStream/buildstream/merge_requests/1431/diffs? | 11:02 |
| alexandrufazakas | tlater: I'm not so sure about that change btw, the one you proposed on gitlab | 11:06 |
| alexandrufazakas | Before that if, then we need to set the directory t= _main_options['directory'], right? | 11:06 |
| alexandrufazakas | Then, if target_directory: join() | 11:06 |
| alexandrufazakas | Does it make sense? | 11:07 |
| *** lachlan has joined #buildstream | 11:07 | |
| tlater[m] | Ah, yes | 11:07 |
| tlater[m] | Sorry, my bad | 11:07 |
| alexandrufazakas | Alright | 11:08 |
| alexandrufazakas | tlater: regarding this https://gitlab.com/BuildStream/buildstream/merge_requests/1430#note_186017715 | 11:16 |
| alexandrufazakas | I'd need to create a temporary directory, so the test can be ran multiple times? | 11:16 |
| alexandrufazakas | Since we'd initialize a project in the home directory of the user | 11:16 |
| tlater[m] | Remember, pylint does that for you. Don't use the exact arguments I gave you there, those are just an example | 11:16 |
| tlater[m] | The point is that the second argument must be an absolute directory | 11:17 |
| alexandrufazakas | So you wouldn't mind if we did it the other way around | 11:17 |
| alexandrufazakas | e.g. -C into /home/alex/foo | 11:17 |
| alexandrufazakas | and init in tmpdir | 11:17 |
| alexandrufazakas | Alright | 11:17 |
| alexandrufazakas | :D | 11:17 |
| tlater[m] | (Spoiler: You'll find that your code will create a path like `/home/alex/foo/tmp/directory`, though you wanted it to create `/tmp/directory`) | 11:18 |
| tlater[m] | I think anyway, it's possible os.path.join() is smarter about this than I think. | 11:18 |
| gitlab-br-bot | BenjaminSchubert merged MR !1432 (bschubert/node-copy->bschubert/new-node-api: _yaml: Remove 'node_copy' and add 'Node.copy()') on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1432 | 11:27 |
| tristan | is this what this "add new argument to bst init" is all about ? | 11:36 |
| tristan | adding another redundant -C like argument ? | 11:36 |
| tristan | tlater[m], why not just wontfix and close https://gitlab.com/BuildStream/buildstream/issues/702 ? | 11:37 |
| tlater[m] | tristan: Is it redundant? Can you create a new project with bst -C init /home/projects/new_directory? | 11:41 |
| tristan | ofcourse | 11:41 |
| tpollard | well with the dir before init | 11:42 |
| tpollard | subtly different | 11:42 |
| tristan | tpollard, exactly | 11:43 |
| tristan | this would be just adding yet another redundant way to specify the project directory in `bst init`, all commands take `-C` as the project directory already | 11:43 |
| tlater[m] | Doesn't https://gitlab.com/BuildStream/buildstream/blob/master/src/buildstream/_frontend/cli.py#L220 imply the directory must exist already? | 11:43 |
| tristan | we're just adding surface to accomplish nothing... not very much of a fan of "more than one way to achieve the same goal" at all | 11:43 |
| tristan | tlater[m], nope | 11:43 |
| tristan | tlater[m], it will be created | 11:44 |
| tristan | tlater[m], try it, I just did, works fine | 11:44 |
| tlater[m] | Right, in that case I agree with you | 11:44 |
| *** raoul has joined #buildstream | 11:44 | |
| tlater[m] | And I assume that #702 was created before -C or somesuch. | 11:44 |
| gitlab-br-bot | Issue #702: Make `bst init` take an argument https://gitlab.com/BuildStream/buildstream/issues/702 | 11:44 |
| tristan | tlater[m], it was created maybe because you didn't know | 11:45 |
| tristan | tlater[m], -C/--directory existed since the beginning | 11:45 |
| tlater[m] | Possible, too | 11:45 |
| tpollard | I think there's reasons to also have init take a directory | 11:45 |
| tristan | We do have one other redundant thing which Ed wanted | 11:46 |
| tristan | not really a fan but whatever | 11:46 |
| tristan | that is `bst help foo` exists, while `bst foo --help` is perfectly fine and does exactly the same | 11:46 |
| tlater[m] | tpollard: I'll agree that it's a bit more obvious what it does if it's an argument, and we'd be behaving more like git. | 11:46 |
| tlater[m] | But it is redundant | 11:47 |
| tristan | Not sure why we have to mirror git, adding an extra way to do something makes us more complicated in general, not less | 11:47 |
| tristan | -C is basically chosen because it works with very many unixy things | 11:48 |
| tlater[m] | Eh, more complicated code-wise, but an entirely new user will know the pattern from using git | 11:48 |
| tristan | like tar and make | 11:48 |
| tlater[m] | Git also has -C, and I like it (: | 11:48 |
| tristan | tlater[m], I mean more complicated user wise | 11:48 |
| tristan | tlater[m], that came later | 11:48 |
| tristan | I had no idea git accepts that | 11:48 |
| tristan | but it's fine and nice that it does too | 11:48 |
| tristan | it's both more complicated code-wise, AND user wise because now we have TWO user stories of how a thing can work | 11:49 |
| tristan | which means one person can say "do it like this", another can say "do it like that", they can both be right... and now we've just crowded user's knowledge base with extra useless information | 11:50 |
| tristan | that is basically true for every case that there is more than one way to do the same thing | 11:50 |
| tlater[m] | The difference is subtle in that -C sets buildstream's cwd. What would you think about disallowing -C into a nonexistent dir? | 11:50 |
| tristan | That is not true | 11:50 |
| tristan | -C does not by any means set buildstreams CWD | 11:50 |
| tristan | it informs BuildStream of the project directory to operate on | 11:51 |
| tlater[m] | That's what it means in other unixy tools | 11:51 |
| tristan | Then argue that we change it from -C/--directory to something else ? I don't know, it seems like a good fit to me anyway | 11:51 |
| tlater[m] | -Change :) | 11:52 |
| tristan | I don't see any reason why BuildStream should ever modify it's CWD | 11:52 |
| tlater[m] | It doesn't have to explicitly do so, since it already behaves as if | 11:52 |
| tristan | it does not really | 11:52 |
| tristan | actually, it really does not | 11:53 |
| tlater[m] | It's useful in things such as make, and if we're already recycling unixy CI sticking to their stuff makes it a bit easier to get used to. | 11:53 |
| tristan | when I type `make -C directory` I expect to run the build declared by that directory | 11:53 |
| tristan | I dont expect it to internally change it's CWD | 11:53 |
| SotK | I think allowing the git-like syntax is sensible, there is a lot to be said for mirroring patterns from widely used tools for helping users to feel familiar with your tool | 11:54 |
| tlater[m] | tristan: But that's what it does | 11:54 |
| tristan | If I expected that of BuildStream, then I would expect `bst --log-file ./output.log -C /path/to/project build` to create a log file in the project directory | 11:54 |
| tlater[m] | Gnu make anyway does | 11:54 |
| SotK | I wouldn't guess that -C would do that since I've not encountered it much, but the git style is very familiar | 11:54 |
| tlater[m] | make -C changes cwd specifically so recursive make things work | 11:55 |
| tristan | tlater[m], it's rather an important distinction that it has nothing to do with CWD... brings back the painful discussions about how "element names are paths", but they are clearly not | 11:55 |
| tristan | tlater[m], sure it might do so as an implementation detail | 11:55 |
| tlater[m] | In that case -C is a bit of a misnomer in bst | 11:56 |
| tristan | well, it's even documented to do exactly that | 11:56 |
| tlater[m] | tristan: yep | 11:56 |
| tristan | tlater[m], but altogether appropriate and familiar, misnomer only if you want to be that pedantic | 11:56 |
| tlater[m] | You started the pedantry with cwd vs project being important, haha | 11:57 |
| tristan | Well okay, fair point :) | 11:58 |
| tristan | Still there is a difference | 11:58 |
| tlater[m] | My point is; we could behave a bit more like git/make and make people's lives a bit easier if we add that argument | 11:58 |
| tristan | That said, `bst init` is just about the most useless command we could have every added *at all*, and I would also favor removing it altogether | 11:59 |
| coldtom | personally i would expect `bst init [directory]` to work | 11:59 |
| tlater[m] | tristan: Given that only init will work on a nonexistent dir | 11:59 |
| tlater[m] | Should we make -C prohibit those and make init have an argument? | 12:00 |
| tristan | any -C argument will always fail if it refers to an invalid project directory, of course `bst init` must accept it because it's purpose is to *create* the project directory in the first place | 12:00 |
| tristan | but again, my vote would really be to just nuke `bst init` altogether and have people create project.conf | 12:01 |
| SotK | that sounds like it would make starting new projects more painful than necessary to me | 12:02 |
| tristan | SotK, have you started a new project ? project.conf is essentially only a mandatory project name | 12:03 |
| tristan | and a desirable but optional format version | 12:03 |
| tlater[m] | SotK unlike git you don't really create projects that often | 12:03 |
| tlater[m] | There also really aren't that many obvious defaults | 12:03 |
| tristan | Honestly, I cannot imagine any scenario where I would create a project and not want to modify the project.conf by hand *anyway* | 12:03 |
| tlater[m] | tristan: maybe make init more useful by printing some - if not all - the default settings, so users know them without going to the docs? | 12:04 |
| * tristan really only added this because of complaints that "bst commands would fail in a directory without a project.conf" | 12:05 | |
| tristan | tlater[m], that's what it does by default in the interactive experience right ? | 12:05 |
| tristan | holds your hand while you enter some things | 12:05 |
| tlater[m] | Oh, right | 12:05 |
| SotK | only a couple of times and not for a while, but in general I personally prefer an obvious command to do initial config setup than having to find the docs and work out what I need | 12:06 |
| tlater[m] | I forgot it was interactive | 12:06 |
| tristan | yeah the interactive part is probably the most useful part of it | 12:06 |
| tlater[m] | Yeah, I think we could perhaps make the command more useful to get people started | 12:06 |
| SotK | I've not looked at the docs in a while so maybe they make it super trivial to understand anyway, I just remember appreciating the existence of bst init when I was trying out buildstream a while ago | 12:06 |
| tristan | https://docs.buildstream.build/tutorial/first-project.html | 12:07 |
| tristan | if you started there well... yeah it does choose the version | 12:07 |
| tristan | but the version needs to be fixed as per a previous proposal which didnt go through yet as it has to do with the inevitable step of making BuildStream 2 parallel installable | 12:08 |
| tristan | i.e. the version should really be the BuildStream version, and not an internal version | 12:08 |
| tristan | you should be able to just say "2.2" if you want to depend on features added in or before 2.2 | 12:08 |
| tristan | the micro managed format-version is only useful for those relying on development snapshots in between stable releases | 12:09 |
| tristan | (and even then it's not immensely useful as features are allowed to change in advance of being released, even more so in the current long dev cycle) | 12:09 |
| tlater[m] | In any case, looks like init is more useful to newcomers than we thought... | 12:10 |
| tlater[m] | tristan: Oddly, you've managed to convince me that the current behavior is definitely not like other tools and that this MR *should* go through, haha | 12:12 |
| gitlab-br-bot | aevri opened (was WIP) MR !1433 (aevri/cascache_nits->master: cascache.py: pick some nits) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1433 | 12:13 |
| gitlab-br-bot | tlater opened (was WIP) MR !1413 (tlater/freedesktop->master: Use a freedesktop-sdk tar as a base image) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1413 | 12:15 |
| coldtom | even without the interactivity of `bst init` i think that having a simple command to create a boilerplate project is useful | 12:18 |
| coldtom | i definitely have appreciated it when creating projects | 12:18 |
| tristan | tlater[m], sure, I honestly don't care about `bst init` | 12:19 |
| tristan | tlater[m], it just irks me a bit that we adding more surface code to accomplish something we can already accomplish... and having to handle edge cases in addition to that | 12:21 |
| tristan | i.e. actually spending time on it :) | 12:21 |
| tristan | tlater[m], I think that if you want to go ahead with this though, you would bail out if both `-C` AND a project directory is specified in `bst init` | 12:22 |
| tlater[m] | I was surprised the issue was seeing any attention in the first place. | 12:22 |
| tristan | tlater[m], don't mislead people to believe that "we are switching to this directory first and then creating your project inside of it" | 12:22 |
| tlater[m] | tristan: Yep, that's probably better behavior in context. I frankly believed -C did that just by association. I'd also want to disallow using nonexistent directories with -C, since that makes no sense, and that way we avoid having multiple user stories. | 12:24 |
| * tlater[m] comments on the MR | 12:25 | |
| tristan | you would prefer to break existing invocations of `bst init` ? | 12:25 |
| tristan | tlater[m], that means that instead of both -C and the directory being conflicting... -C cannot be used *at all* in `bst init` right ? | 12:25 |
| tlater[m] | tristan: Doesn't 2.0 basically break any idea of backwards compatible scripting anyway? | 12:25 |
| tristan | tlater[m], remember that the condition for `-C` is not only that it is an existing directory | 12:26 |
| tristan | it must be *a valid project directory*, or else we bail out early anyway | 12:26 |
| tristan | tlater[m], I'm just pointing it out | 12:26 |
| tristan | tlater[m], sure you can break it... but be conscious that you are breaking it :) | 12:26 |
| tristan | that means necessary NEWS entry as well | 12:27 |
| tlater[m] | Yep, these are good notes | 12:28 |
| tristan | tlater[m], to clarify on the above... all bst commands will bail out immediately if the project directory is missing a project.conf | 12:28 |
| tristan | (or doesnt exist of course) | 12:28 |
| tlater[m] | And bst init will not even allow you to -C | 12:28 |
| tristan | right, then you would bail out with "Attempted to specify project directory when creating a new project" detail="Use bst pony --foo-bar instead" | 12:29 |
| tristan | something like that | 12:29 |
| tlater[m] | Yup. I think this makes sense, it's more comparable to similar tools than what we had previously and doesn't pretend we're doing something we don't. | 12:30 |
| tristan | well, what we currently have is (A) a global way of setting the project directory ... and (B) a project initializer which assumes you mean to initialize the project in the directory you specified | 12:30 |
| tristan | what we have now is not nonsense | 12:31 |
| tlater[m] | No, it's not, it's just unfamiliar compared to other tools, so I want to change it. | 12:31 |
| tristan | yes I know | 12:31 |
| tristan | ok sorry for whining my head off about this insignificant little detail :) | 12:32 |
| tlater[m] | tristan: Don't worry, good thing you said something, I only realized -C works this way when you did :) | 12:32 |
| tristan | I also think that we should take the user experience of `make` as a more appropriate comparison in general... it's a lot more similar to how you use BuildStream than something like git :) | 12:34 |
| gitlab-br-bot | BenjaminSchubert merged MR !1424 (bschubert/node-api-nodel->bschubert/new-node-api: _yaml: Remove 'node_del' and support `del mapping[key]`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1424 | 12:34 |
| tristan | essentially all the stuff you put in a make project is stuff that you author by hand, it is not a store, it is all input for the tooling | 12:34 |
| tlater[m] | tristan: That's why I sort of agree with you that we shouldn't have an init ;p | 12:35 |
| tristan | yeah, but people like it, especially the hand holding is nice... not sure really how valuable it is | 12:36 |
| tristan | tlater[m], if we fixed "version:" (and perhaps removed "format-version") to work more intuitively, it would be rendered almost pointless | 12:36 |
| tristan | knowing that secret number is kind of what bst init does best | 12:37 |
| * tristan goes out to dinner | 12:37 | |
| tlater[m] | o/ | 12:37 |
| *** phildawson_ has joined #buildstream | 13:13 | |
| *** phildawson has quit IRC | 13:14 | |
| *** phildawson_ has quit IRC | 13:15 | |
| *** phildawson has joined #buildstream | 13:16 | |
| gitlab-br-bot | marge-bot123 merged MR !1433 (aevri/cascache_nits->master: cascache.py: pick some nits) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1433 | 13:17 |
| *** bochecha has quit IRC | 13:20 | |
| benschubert | tristan: I need your input on an API question: should 'node_find_target' be something public or just for us? | 13:33 |
| gitlab-br-bot | BenjaminSchubert opened MR !1434 (bschubert/node-find-target->bschubert/new-node-api: Replace 'node_find_target' by 'MappingNode.find') on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1434 | 13:56 |
| *** lachlan has quit IRC | 14:25 | |
| tpollard | had never seen this feature of gitlab before... https://gitlab.com/BuildStream/buildstream/merge_requests/1429#note_186094789 | 14:44 |
| tpollard | nifty | 14:46 |
| benschubert | tpollard: it's brand new :D | 14:47 |
| gitlab-br-bot | raoul.hidalgocharman opened MR !1435 (raoul/1038-source-cache-proto->master: Proto based source cache service) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1435 | 14:48 |
| *** lachlan has joined #buildstream | 14:49 | |
| tpollard | benschubert: :) | 14:50 |
| *** lachlan has quit IRC | 15:15 | |
| benschubert | I've got a question about provenance of nodes. Currently, when we override an entry, if the new value is not already a node from somewhere else, we set the node's provenance to be the one we just overwrote. I think this is wrong, as we mask real nodes with synthetic ones. I would therefore be in favor of keeping the synthetic provenance. Would someone see a disadvantage to that? tristan, jennis, juergbi ? | 15:21 |
| juergbi | that's not needed for writeback? | 15:22 |
| juergbi | I'm not the YAML expert, others can probably better answer this | 15:23 |
| jennis | I agree with your concern and generally think that we shouldn't overwrite | 15:24 |
| benschubert | juergbi: that's a very good point, I need to check what would happen | 15:24 |
| jennis | However, I'm worried that we'd get an exception which just gives complete garbage provenance | 15:25 |
| benschubert | if that happened, it would be a programming error on our end anyways :/ | 15:28 |
| jennis | True | 15:29 |
| jennis | I don't see any obvious disadvantages | 15:30 |
| *** lachlan has joined #buildstream | 15:54 | |
| raoul | juergbi, tristan, what was the decision for !1402? If I've understood the scrollback correctly: use --all to decide whether to fetch run time or all dependencies (and expose this as a user config option) and then another option as to whether to fetch artifact files at all? | 15:54 |
| gitlab-br-bot | MR !1402: Configuration option for disabling blob fetching with RE https://gitlab.com/BuildStream/buildstream/merge_requests/1402 | 15:54 |
| juergbi | raoul: yes, does this make sense to you as well? | 15:55 |
| raoul | or rather --all would decide what to build, and thus would fetch those dependencies | 15:55 |
| raoul | yeah I think so | 15:55 |
| juergbi | to be clear, the behavior of --all in master is not quite sufficient. also should 'require artifact files' for all elements in that case | 15:57 |
| juergbi | (instead of only for targets and their runtime deps) | 15:57 |
| juergbi | and imo, the user config option for --all could be done in a separate MR. but fine to include in the same MR, of course, if it's simple enough | 15:57 |
| raoul | so --all should override the other option to fetch artifact files? | 15:59 |
| raoul | Might make sense to do it in the same MR, should be small enough a change | 15:59 |
| *** toscalix has quit IRC | 16:24 | |
| *** raoul has quit IRC | 16:33 | |
| *** alexandrufazakas has quit IRC | 16:46 | |
| *** lachlan has quit IRC | 16:55 | |
| *** phildawson has quit IRC | 18:10 | |
| *** jonathanmaw has quit IRC | 18:12 | |
| *** benschubert has quit IRC | 20:02 | |
| *** cs-shadow has quit IRC | 20:40 | |
| *** slaf has quit IRC | 21:50 | |
| *** slaf has joined #buildstream | 22:07 | |
| *** slaf has joined #buildstream | 22:07 | |
| *** slaf has joined #buildstream | 22:07 | |
| *** slaf has joined #buildstream | 22:07 | |
| *** slaf has joined #buildstream | 22:08 | |
| *** slaf has joined #buildstream | 22:08 | |
| *** slaf has joined #buildstream | 22:08 | |
| *** slaf has joined #buildstream | 22:08 | |
| *** slaf has joined #buildstream | 22:09 | |
| *** slaf has joined #buildstream | 22:09 | |
| *** slaf has joined #buildstream | 22:09 | |
| *** slaf has joined #buildstream | 22:09 | |
| *** slaf has joined #buildstream | 22:10 | |
| *** slaf has joined #buildstream | 22:10 | |
| *** slaf has joined #buildstream | 22:10 | |
| *** slaf has joined #buildstream | 22:10 | |
| *** slaf has joined #buildstream | 22:11 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!