| *** mohan43u has quit IRC | 02:58 | |
| *** mohan43u has joined #buildstream | 03:01 | |
| *** tristan has quit IRC | 03:05 | |
| *** mohan43u has quit IRC | 03:12 | |
| *** mohan43u has joined #buildstream | 03:17 | |
| *** mohan43u has quit IRC | 04:26 | |
| *** mohan43u has joined #buildstream | 04:28 | |
| *** mohan43u has joined #buildstream | 04:33 | |
| *** mohan43u has quit IRC | 04:41 | |
| juergbi | robjh: you don't get any output after launching it with maximum verbosity (--log-level=trace) and issuing requests? | 04:50 |
|---|---|---|
| juergbi | you could also check the buildbox-casd logs in the logs subdirectory. however, you should also see bst-artifact-server logs directly in stderr | 04:51 |
| juergbi | there are no logs without requests from clients, though | 04:52 |
| *** mohan43u has joined #buildstream | 05:14 | |
| *** mohan43u has joined #buildstream | 05:14 | |
| *** mohan43u has quit IRC | 05:19 | |
| *** mohan43u has joined #buildstream | 05:19 | |
| *** mohan43u has quit IRC | 05:26 | |
| *** mohan43u has joined #buildstream | 05:26 | |
| *** mohan43u has quit IRC | 05:29 | |
| *** mohan43u has joined #buildstream | 05:29 | |
| *** mohan43u has quit IRC | 05:32 | |
| *** mohan43u has joined #buildstream | 05:32 | |
| *** phildawson has joined #buildstream | 07:10 | |
| *** aminbegood has joined #buildstream | 07:22 | |
| *** aminbegood has quit IRC | 07:24 | |
| *** pointswaves has joined #buildstream | 07:25 | |
| *** benschubert has joined #buildstream | 07:27 | |
| *** pointswaves has quit IRC | 07:30 | |
| *** tristan has joined #buildstream | 07:36 | |
| *** ChanServ sets mode: +o tristan | 07:36 | |
| *** jude has joined #buildstream | 07:38 | |
| *** seanborg__ has joined #buildstream | 07:47 | |
| robjh | juergbi, i go to http://192.168.9.15:11001/ in a browser and i get "unable to connect", and the program produces no output. i'll look for the logs (any hints as to where?) | 07:48 |
| juergbi | robjh: there is no web interface. there might not be logs for completely unknown/invalid requests | 07:49 |
| juergbi | casd logs are in the logs subdirectory of the storage directory you specify on the CLI | 07:49 |
| robjh | ahh, there are files there | 07:49 |
| juergbi | but you're probably not even reaching casd | 07:50 |
| juergbi | have you tried using it from bst instead of web browser? | 07:50 |
| juergbi | "unable to connect" does seem odd, I'd rather expect an HTTP error | 07:50 |
| robjh | i have. but not recently | 07:51 |
| juergbi | the error message you get in bst might be more useful | 07:51 |
| robjh | i thought it was a rest api, because the instructions talk about using a reverse proxy | 07:51 |
| juergbi | it's using gRPC, which is a HTTP-based API | 07:52 |
| juergbi | but there is no web interface | 07:52 |
| robjh | WARNING Failed to initialize remote http://mcr.robjh.com:11001: Remote initialisation failed: failed to connect to all addresses | 07:53 |
| robjh | similar results with both http and https (it is configured for https) | 07:54 |
| robjh | with a cert from letsencrypt | 07:54 |
| *** aminbegood has joined #buildstream | 07:55 | |
| tristan | Hmmm | 07:55 |
| tristan | We removed `bst build --track` but, in the process we lost something important | 07:55 |
| tristan | The tests/frontend/buildtrack.py was the only test I can recall which really thoroughly tested the the `--except` logic | 07:56 |
| tristan | which we still support in `bst source track --deps all foo.bst --except bar.bst --except baz.bst ...` | 07:57 |
| tristan | Am I missing where that test was migrated to in the process of removing build/track support ? I'm not seeing it in tests/frontend/track.py | 07:57 |
| *** lachlan has joined #buildstream | 08:00 | |
| robjh | ive fiddled with it a bit, and it looks like the problems might have been a combination of the server being on my lan and docker-compose run not exposing the port | 08:04 |
| *** lachlan has quit IRC | 08:08 | |
| juergbi | tristan: I think you're right. we have to resurrect it from commit 576be1fc19bb58d25309a911589ceb9f08f7812d | 08:11 |
| tristan | shouldnt be too hard | 08:12 |
| juergbi | we do have some except testing, e.g., test_show_except_simple | 08:12 |
| tristan | Ah | 08:13 |
| juergbi | is for bst show but tracking should no longer have separate except handling, iirc | 08:13 |
| juergbi | might not be as thorough as it was, though, not sure | 08:13 |
| tristan | Well, iirc at least the except code itself is the same | 08:13 |
| tristan | Yes I think the buildtrack.py test was very thorough, we fixed regressions through that path before | 08:13 |
| juergbi | ah, test_show_except actually seems to test fairly complex cases | 08:13 |
| juergbi | build --track was more complex, though, due to the different except combinations for track and build parts | 08:14 |
| tristan | I came across this in the context of https://gitlab.com/BuildStream/buildstream/-/merge_requests/1893/diffs#note_335696186 | 08:15 |
| *** seanborg__ has quit IRC | 08:15 | |
| robjh | also, i was accidentally giving it an expired cert from 2019 | 08:16 |
| tristan | juergbi, I think the show test is not covering for instance, the case of `bst show --deps plan foo.bst --except bar.bst --except baz.bst` | 08:16 |
| tristan | build plan selections can be more tricky | 08:16 |
| tristan | but yeah, it does look like a good test in tests/frontend/show.py | 08:17 |
| * tristan didn't realize it was there | 08:17 | |
| *** seanborg__ has joined #buildstream | 08:19 | |
| tristan | juergbi, can I bribe you for a review of https://gitlab.com/BuildStream/buildstream/-/merge_requests/1892 and https://gitlab.com/BuildStream/buildstream/-/merge_requests/1894 ? | 08:19 |
| tristan | juergbi, any particular MR you want a review on ? | 08:19 |
| * tristan was looking at the MR list trying to buy himself some review points hehe | 08:20 | |
| juergbi | tristan: regarding except, at least it seems like all lines of Pipeline.except_elements() are covered by tests | 08:26 |
| juergbi | review: I actually don't have an MR open right now but I can try to review your MRs in a bit | 08:26 |
| tristan | Thanks :) | 08:27 |
| juergbi | for the pip one I hope benschubert or cs-shadow also find time for a review | 08:27 |
| tristan | yeah | 08:28 |
| * tristan has been hoping to find cs-shadow for a while now | 08:28 | |
| tristan | the thing is that the pip one is based on the other one I wrote just before it, and touches the same areas of code | 08:29 |
| tristan | so landing the other would help me avoid more conflict resolution anyway | 08:29 |
| * tristan thinks this week is time to tackle the junction jungle | 08:30 | |
| benschubert | juergbi: !1894 ? I'll look at it now | 08:31 |
| *** tpollard has joined #buildstream | 08:41 | |
| *** santi has joined #buildstream | 08:41 | |
| tristan | benschubert, note that many of the commits in !1894 are actually from !1892 | 08:42 |
| tristan | benschubert, and: https://buildstream.gitlab.io/-/buildstream/-/jobs/536561483/artifacts/public/format_project.html#loading-plugins | 08:42 |
| tristan | That is the rendered documentation of what !1892 adds, plus a general overhaul of the plugin origin documentation | 08:42 |
| benschubert | tristan: yep, just had a look at 1892 first, it's a really nice change :) | 08:43 |
| * tristan renamed "External plugins" to "Loading plugins" also... as "External" was an outlier in BuildStream 1, but we expect will be the norm in BuildStream 2 | 08:43 | |
| *** lachlan has joined #buildstream | 08:48 | |
| robjh | at what point does a bst client push objects up to a server? | 08:51 |
| robjh | im not seeing as much traffic between the two as i would expect | 08:51 |
| tristan | So you can do `return foo, bar` in python to return a tuple, no need to `return (foo, bar)` ? | 08:52 |
| *** lachlan has quit IRC | 08:54 | |
| tristan | seems tests pass this way too | 08:55 |
| tpollard | tristan: yep | 08:55 |
| tristan | learn something new every day :) | 08:58 |
| tristan | Seems we now have a bit of both in the codebase, and both pylint and black don't seem to care | 08:59 |
| * tristan doesn't personally care all that much, minor inconsistency | 08:59 | |
| *** aminbegood has quit IRC | 09:00 | |
| benschubert | tristan: we can configure pylint to care if wanted :) | 09:02 |
| benschubert | but yeah in python you can have (a, b) = b, a or such weird but gosh you miss them in other languages stuff :) | 09:02 |
| benschubert | juergbi, tristan anything else you need my input on? :) Sorry, have been quite busy lately | 09:03 |
| tristan | No worry | 09:04 |
| juergbi | benschubert: thanks, nothing from my side right now. except feedback on how buildbox-run is working for you :) | 09:05 |
| tristan | benschubert, We should get to the bottom of the cross junction plugin loading story though | 09:05 |
| benschubert | juergbi: haven't been able to run it "in production" but I'd like to have a test deployment this month and will definitely test it thoroughly then. I'm just hodling back our updates until we have the buildbox-casd issue fixed, to reduce number of breaking changes | 09:06 |
| juergbi | the timeout issue, I presume. makes sense | 09:07 |
| benschubert | tristan: right, I'll give you an answer to that today (probably late afternoon London time, so you'll have it tomorrow morning). the TLDR is that I'm worried that the variable overriding with your solution would be unintuitive, but I need to re-read the whole thing to ensure I got everything | 09:07 |
| benschubert | juergbi: correct | 09:07 |
| juergbi | https://gitlab.com/BuildGrid/buildbox/buildbox-casd/-/merge_requests/169 will likely land very soon | 09:07 |
| juergbi | (in addition to the buildstream side mitigation) | 09:07 |
| tristan | benschubert, sure, I thought an IRC chat might help us to align | 09:07 |
| tristan | benschubert, personally I feel like I want "cross junction loading" simplicity, especially to cater to the use case of both depending on elements and using plugins across a junction, with simple syntax (even if the subtle details of how things work need an explanation somewhere) | 09:08 |
| tristan | benschubert, at the same time I can see that using an element to stage plugins somewhere helps if you want to "just get the data" regardless of project.conf | 09:09 |
| tristan | but in that view point, I really wonder why we would need a junction *also* (i.e. if you wanted to use an element to stage plugins and then load them, you could completely drop the need of a junction altogether) | 09:10 |
| *** lachlan has joined #buildstream | 09:11 | |
| benschubert | tristan: one of my concerns with this approach is if you end up with a junction using plugins from `pip` and import them, then you _might_ think you have a guarantee that you are using the exact same version when you might not be. | 09:11 |
| tristan | benschubert, anyway sorry I realize you don't have the bandwidth right now :) | 09:11 |
| benschubert | tristan: no worries, irc might indeed be better :D | 09:11 |
| tristan | I think that if you use a junction, you are indeed subjugating yourself to the whims of the project from whence your plugins come from | 09:12 |
| benschubert | tristan: > why we would need a junction *also* | 09:12 |
| benschubert | Seems my proposal was not 100% clear, You would not _require_ a junction, just allow plugins to be defined as elements and thus track them as such, and you would gain the "accross junction" for free | 09:12 |
| tristan | In multiple ways | 09:12 |
| benschubert | that's also true. Do you think that "just" declaring "I want to use this plugin from this junction" we sufficient for all the needs of gnome and fsdk and such? (I don't have most of those problems since we control the environment more tightly) | 09:13 |
| tristan | ... to elaborate "in multiple ways", I mean: I could envision use cases where a lower level project provides "local" plugins which are intended for consumption by reverse dependency projects | 09:13 |
| tristan | So changes to that static plugin means that updating the junction also brings in changes there, but it seems appropriate | 09:14 |
| benschubert | yeah, if you update your junction you could expect this. agreed | 09:14 |
| tristan | Regarding the gnome/fdsdk cases, I do think it would be sufficient for the custom plugins being used there - however, "I want to use this plugin from this junction" I think is not really enough | 09:16 |
| benschubert | right | 09:16 |
| *** lachlan has quit IRC | 09:16 | |
| tristan | We would need to at least have our upstream plugin packages structured in a way that they have a project.conf and we can consume those | 09:16 |
| tristan | Together I think that would be enough | 09:16 |
| tristan | It would mean that we have a paradigm which allows people to distribute plugins as a "both pip and junction" and allow users to choose (whether it's the upstream ones, or other side projects) | 09:17 |
| benschubert | how do you handle third party pip dependencies? Vendoring? Leave users install them manually (I *think* we should add import-error guards in our plugin and give a nice error in that case) | 09:17 |
| tristan | Back to this territory :) | 09:17 |
| tristan | In this instance, I totally agree | 09:18 |
| benschubert | and so for the "registration" we would say: `{"origin": "junction", "junction": "my-junction.bst", "elements": ["pip"], "sources": ["docker"]}` ? | 09:18 |
| tristan | In the original design, `Plugin.preflight()` is the place for plugins to report specific concise messages about system requirements | 09:19 |
| tristan | But we did not really expect imports from outside the non standard library (those crept in initially with ostree though so it is a reality of course) | 09:19 |
| tristan | And handling import errors in Plugin.preflight() is not ideal | 09:19 |
| benschubert | the problem with that is that it makes importing third party deps harder :) and you might just forget, I think catching a *importError* would solve most of this | 09:19 |
| benschubert | yep | 09:19 |
| benschubert | we _could_ catch ImportError and register a dummy plugin that has the preflight that returns the error about import? :) | 09:20 |
| tristan | The loader could do this and we could have a test for this too | 09:20 |
| tristan | The thing is, once preflight is called, it's too late | 09:20 |
| tristan | Plugins usually import at the toplevel of their module | 09:20 |
| tristan | Right I see what you're suggesting... nah I don't think it's important to delay the error until preflight time | 09:21 |
| traveltissues | can i get a review please https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/104 | 09:21 |
| tristan | traveltissues, This is bazel element isn't it :-S | 09:22 |
| benschubert | depends, if you have many plugins and they all have an error, getting all errors one by one is not ideal, if we keep the error to preflight, we could make optimizations there later and show all errors at time :) | 09:22 |
| benschubert | but as a first pass sure, just catching and showing a nice error would be much better already | 09:22 |
| traveltissues | tristan: yes | 09:22 |
| benschubert | tristan: ok, last point about the proposal: would we allow projects to have different configuration for their junctioned plugins than the junction that contains the plugin? | 09:24 |
| tristan | traveltissues, So I don't really have buffer space for this plugin right now, but I don't think it should prevent you from landing it in bst-plugins-experimental | 09:24 |
| tristan | benschubert, So this is an interesting question, I'm not sure I understand which context you mean | 09:24 |
| tristan | benschubert, Say... I want to depend on elements from project A, and I want to use plugins that project A also uses or provides, but possibly at a different version in the history of project A ? | 09:25 |
| benschubert | let's say you use a cmake plugin through a junction. The cmake plugin is configured to install things in /usr. You want ot install things _from your project_ in /usr/local to have a clear separation between both. | 09:26 |
| benschubert | -> Do we allow that? | 09:26 |
| benschubert | -> How would we express this? | 09:26 |
| benschubert | Not different version (that could be solved with two junctions :) ) | 09:26 |
| tristan | Right I was going to say that regarding two junctions. so indeed... this is the tricky thing. | 09:27 |
| tristan | benschubert, I think we may need to offer the choice here | 09:28 |
| tristan | Either observe the origin project.conf when loading the plugin or don't | 09:28 |
| benschubert | I'm not 100% sure about this solution, you might want to keep _some_ defaults :) (especially if we go with trimming most defaults) | 09:29 |
| tristan | benschubert, orthogonal to this, I think we're treading into territory where plugins have expectations about the projects they are used in | 09:29 |
| benschubert | would special-casing the loader to load from the junction then copy and merge the project's default? | 09:29 |
| tristan | I.e. there is going to be user stories where the user uses a plugin for the first time, and at loading time the plugin explodes and says "Hey, I don't have any variable to expand named %{sysconfigdir} !" | 09:30 |
| tristan | And then the user goes and adds something to their project.conf in order to satisfy the needs of the plugin | 09:30 |
| benschubert | ah yes absolutely, not what I meant sorry :) | 09:30 |
| benschubert | What I meant is "i might be fine with all the configuration given by my junction but 2 of the parameters, please override those to, but only for my project, not the junction" | 09:31 |
| benschubert | and I don't want to keep the others in sync | 09:31 |
| benschubert | (and was saying that this will become even more prevalent with less defaults set) | 09:31 |
| tristan | benschubert, I think that specific case is handled by the local project's overrides always having a chance to set things | 09:32 |
| tristan | i.e. you can set %{sysconfigdir} or whatever variable in the elements: dictionary of the project which used a cross-junction plugin, and it will still have the second-last say about those element configurations | 09:32 |
| benschubert | tristan: if we load the plugin in the junction's context though, wouldn't that affect the junction? | 09:32 |
| tristan | before variables get resolved | 09:32 |
| benschubert | ah right | 09:33 |
| benschubert | the variables and the plugins are handled separately | 09:33 |
| benschubert | ah no wait | 09:33 |
| tristan | There might be a few gritty implementation details in there which indeed mean it's not exactly "just load it from that project", of course | 09:33 |
| benschubert | if that's the case, how do you get the "defaults" from the plugin frm the junction? | 09:34 |
| benschubert | Or do we expect users to have to re-write all of them? | 09:34 |
| benschubert | like "use the plugin as it is configured in my junction" | 09:34 |
| tristan | Actually I expect includes to handle most of this | 09:34 |
| benschubert | or is that somethign that was never requested? | 09:34 |
| benschubert | ok | 09:34 |
| tristan | Right well, that's the other option, I was thinking... maybe we want to give the user the choice to observe the junction's project.conf or not when loading the cross-junction plugin | 09:35 |
| benschubert | yeah, that's actually a better phrasing of one of the things I'm worried about, that this might become an expectation :) | 09:35 |
| tristan | If there is a choice, and you choose to ignore the project.conf configuration from the junction, then you need to provide everything the plugin needs of course | 09:35 |
| tristan | But in practice, I expect the majority of defaults to be provided by include files in low level projects | 09:36 |
| tristan | So it could be that both projects junction the same base runtime which defines %{prefix} and all the general system layout | 09:36 |
| benschubert | Ok, I think that make sense and I don't think we overlooked anything | 09:38 |
| benschubert | I'll have to think a bit longer about it to ensure every thing is fine and I'll reply to the list / ping you more ok? | 09:38 |
| tristan | Awesome :) | 09:38 |
| tristan | Happy we had this talk :) | 09:38 |
| tristan | benschubert, you are happy with the 2 MRs I presume ? I will rework the removal of the tarball which sounds great | 09:39 |
| benschubert | I'm happy with those yep! And the removal of the tarball will indeed be good, it's always such a pain to keep those things in sync :D | 09:39 |
| tristan | Ah more comments, I'll go ahead and address them all :) | 09:40 |
| benschubert | I'll ping cs-shadow also to ask him if he wants to review | 09:40 |
| tristan | Yeah it is, I really wanted a test fixture which builds a package and adds it to PYTHONPATH for the duration of a test | 09:40 |
| tristan | but that turned out to be asking for too much :-S | 09:40 |
| benschubert | yeah, it's a bit of a pain | 09:41 |
| benschubert | unless we start faffing with venvs, but then we'd be having side effects so hey | 09:41 |
| benschubert | but yeah, once the comments are addressed I'm happy with it | 09:41 |
| tristan | Thanks :) | 09:42 |
| juergbi | tristan: create a bst project and build buildstream and the python plugin package inside that. inception ;) | 09:42 |
| WSalmon | do we need to update https://buildstream.build/source_install.html#installing-dependencies for buildbox-run? i have just hit `[00:00:22] FAILURE bootstrap/gnu-config.bst: This platform does not support local builds: buildbox-run not found` is there a MR up already i can test? | 09:44 |
| *** lachlan has joined #buildstream | 09:45 | |
| juergbi | WSalmon: https://buildstream.build/buildbox_install.html is already updated | 09:45 |
| WSalmon | juergbi, would `BuildStream master also requires buildbox-casd: Install BuildBox `-> read better as `BuildStream master also requires buildbox: Install BuildBox` I skim read that like and only registed the `buildbox-casd` bit which i had | 09:50 |
| juergbi | right, should tweak that | 09:51 |
| WSalmon | thanks | 09:53 |
| *** lachlan has quit IRC | 10:07 | |
| tristan | benschubert, When cs-shadow and I discussed this, we said we should link to https://www.python.org/dev/peps/pep-0440/ and mention that version constraints are only guaranteed to work with plugin packages which follow that specification in how they declare their versions | 10:37 |
| tristan | But, this pep does not seem to define the *constraints* themselves :-/ | 10:38 |
| *** lachlan has joined #buildstream | 10:38 | |
| benschubert | tristan: ah, fair enough -_-' | 10:39 |
| tristan | I will add that | 10:40 |
| tristan | I did ask in #python and was given a decent link, but unfortunately not from an official upstream URL :-S | 10:40 |
| * tristan is looking for it in his history now | 10:40 | |
| *** lachlan has quit IRC | 10:41 | |
| tristan | benschubert, here it is: https://python-poetry.org/docs/versions/ | 10:42 |
| tristan | benschubert, Do you think we should link that ? | 10:42 |
| tristan | the material itself looks good and user friendly | 10:42 |
| * tristan doesnt know where 'python-poetry.org' is from or what they are associated to, though | 10:43 | |
| benschubert | https://www.python.org/dev/peps/pep-0508/ :D | 10:43 |
| benschubert | Is that it? | 10:43 |
| benschubert | poetry is an alternative backend to create python packages | 10:43 |
| benschubert | it is quite well known and reputable | 10:43 |
| benschubert | ah shoot, no it doesn't specify the constraints | 10:44 |
| benschubert | oh well, if poetry is the best we can get, let's use that | 10:44 |
| benschubert | bbetter than nothing | 10:44 |
| tristan | Yeah agreed, it is actually a nice page | 10:45 |
| tristan | I'll also link 0440 probably in the same sentence | 10:45 |
| benschubert | seems good, thanks a lot | 10:46 |
| *** seanborg__ has quit IRC | 11:00 | |
| *** seanborg__ has joined #buildstream | 11:00 | |
| *** seanborg__ has quit IRC | 11:12 | |
| *** seanborg__ has joined #buildstream | 11:13 | |
| *** lachlan has joined #buildstream | 11:23 | |
| *** lachlan has quit IRC | 11:29 | |
| *** seanborg__ has quit IRC | 11:34 | |
| *** seanborg__ has joined #buildstream | 11:41 | |
| *** seanborg__ has quit IRC | 11:44 | |
| *** seanborg__ has joined #buildstream | 11:44 | |
| *** seanborg__ has quit IRC | 11:47 | |
| *** seanborg has joined #buildstream | 11:48 | |
| *** tristan has quit IRC | 12:00 | |
| WSalmon | dose anyone else get a crash if they try to tab complete from `bst ar`? | 12:15 |
| WSalmon | on master | 12:15 |
| WSalmon | https://paste.gnome.org/pa2maa2ed | 12:17 |
| *** cs-shadow has joined #buildstream | 12:20 | |
| *** jude has quit IRC | 12:21 | |
| *** jude has joined #buildstream | 12:34 | |
| coldtom | WSalmon i've experienced a crash from attempting to tab complete something or other | 12:39 |
| WSalmon | its especally annoying as it hangs rather than exiting | 12:40 |
| tpollard | WSalmon: does the same thing happen if you try it in a bst project dir | 12:43 |
| WSalmon | yep | 12:44 |
| tpollard | urkj | 12:44 |
| WSalmon | i only made the paste in a diffrent dir as i had finally got bst to go and had lost it off the scroll back | 12:44 |
| tpollard | I just remembered we used to have a tab bug when calling outside of a project dir | 12:45 |
| *** lachlan has joined #buildstream | 13:16 | |
| *** lachlan has quit IRC | 13:20 | |
| *** lachlan has joined #buildstream | 13:23 | |
| *** lachlan has quit IRC | 13:26 | |
| *** scottclarke has joined #buildstream | 13:32 | |
| *** lachlan has joined #buildstream | 13:43 | |
| *** lachlan has quit IRC | 13:47 | |
| *** scottclarke has quit IRC | 13:50 | |
| *** scottclarke has joined #buildstream | 13:51 | |
| *** lachlan has joined #buildstream | 14:16 | |
| *** lachlan has quit IRC | 14:20 | |
| *** lachlan has joined #buildstream | 14:37 | |
| *** lachlan has quit IRC | 14:42 | |
| *** lachlan has joined #buildstream | 14:59 | |
| *** tristan has joined #buildstream | 15:02 | |
| *** lachlan has quit IRC | 15:06 | |
| *** lachlan has joined #buildstream | 15:33 | |
| *** lachlan has quit IRC | 15:38 | |
| *** lachlan has joined #buildstream | 16:21 | |
| *** seanborg has quit IRC | 16:32 | |
| *** lachlan has quit IRC | 17:02 | |
| *** lachlan has joined #buildstream | 17:32 | |
| *** santi has quit IRC | 17:33 | |
| *** lachlan has quit IRC | 18:00 | |
| *** tpollard has quit IRC | 18:01 | |
| *** pointswaves has joined #buildstream | 18:01 | |
| *** phoenix has joined #buildstream | 18:14 | |
| *** aminbegood has joined #buildstream | 18:33 | |
| *** mohan43u has quit IRC | 18:40 | |
| *** cs-shadow has quit IRC | 18:49 | |
| *** aminbegood has quit IRC | 19:08 | |
| *** phoenix has quit IRC | 19:18 | |
| *** phoenix has joined #buildstream | 19:20 | |
| *** benschubert has quit IRC | 19:45 | |
| *** phoenix has quit IRC | 19:56 | |
| *** phildawson has quit IRC | 21:02 | |
| *** jude has quit IRC | 22:05 | |
| WSalmon | what dose [23:48:02][--:--:--][ ][ main:core activity ] WARNING Failed to initialize remote http://XXX.XXX.XXX.XXX:50051: Remote initialisation failed: failed to connect to all addresses mean? | 22:50 |
| *** pointswaves has quit IRC | 22:53 | |
| *** pointswaves has joined #buildstream | 23:05 | |
| *** pointswaves has quit IRC | 23:08 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!