| *** swick has joined #buildstream | 00:00 | |
| *** nimish2711 has quit IRC | 00:09 | |
| *** nimish2711 has joined #buildstream | 00:56 | |
| *** nimish2711 has quit IRC | 02:39 | |
| *** tristan has quit IRC | 06:50 | |
| *** tristan has joined #buildstream | 07:09 | |
| *** bochecha has joined #buildstream | 07:48 | |
| gitlab-br-bot | BenjaminSchubert approved MR !1347 (chandan/coverage-doesnt-need-deps->master: tox.ini: Coverage does not need module installed) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1347 | 08:21 |
|---|---|---|
| gitlab-br-bot | jennis approved MR !1347 (chandan/coverage-doesnt-need-deps->master: tox.ini: Coverage does not need module installed) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1347 | 08:24 |
| *** jonathanmaw has joined #buildstream | 08:59 | |
| *** phildawson_ has joined #buildstream | 09:07 | |
| *** tristan has quit IRC | 09:08 | |
| *** lachlan has joined #buildstream | 09:36 | |
| gitlab-br-bot | juergbi approved MR !1325 (jonathan/cached-to-artifact->master: Move Element.__*cached variable to Artifact class) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1325 | 09:37 |
| *** lachlan has quit IRC | 09:40 | |
| *** lachlan has joined #buildstream | 09:58 | |
| *** lachlan has quit IRC | 10:02 | |
| * juergbi is confused | 10:14 | |
| juergbi | I stopped a hung job and now gitlab doesn't allow me to retry (there is not even a button anymore) | 10:15 |
| juergbi | ah, have to retry on the pipeline level instead of on the job level if it was the last job | 10:15 |
| juergbi | not exactly intuitive to remove retry button from the job in that case | 10:16 |
| jennis | juergbi, yes I had this earlier too | 10:23 |
| tpollard | jonathanmaw: marge is dead again, you will need to manually merge | 10:25 |
| jonathanmaw | ok | 10:26 |
| gitlab-br-bot | jonathanmaw closed issue #1015 (Move Element.__*cached variable to Artifact class) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1015 | 10:45 |
| gitlab-br-bot | jonathanmaw merged MR !1325 (jonathan/cached-to-artifact->master: Move Element.__*cached variable to Artifact class) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1325 | 10:45 |
| *** tristan has joined #buildstream | 10:46 | |
| tpollard | \o/ | 10:47 |
| *** lachlan has joined #buildstream | 11:01 | |
| *** lachlan has quit IRC | 11:04 | |
| *** lachlan has joined #buildstream | 11:06 | |
| *** pointswaves has joined #buildstream | 11:24 | |
| tpollard | tristan: would you still be ok with seeing a user config option for disabling the status 'bar' (I'd take that as the complete status header)? | 11:34 |
| tpollard | probably have value in being a bst main option too | 11:35 |
| *** ChanServ sets mode: +o tristan | 11:38 | |
| tristan | tpollard, I think it could be alright... it should be handled in the same way as all options of course... probably should have --log-smth on the CLI and be an option in the logging: section of the config file for consistency with other logging options | 11:40 |
| tristan | tpollard, however | 11:40 |
| tristan | I *think* that it's technically unneeded, I think you can provoke that exact behavior without any option | 11:40 |
| gitlab-br-bot | cs-shadow merged MR !1347 (chandan/coverage-doesnt-need-deps->master: tox.ini: Coverage does not need module installed) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1347 | 11:40 |
| tristan | oh well, not precisely, you would also lose interactive prompts | 11:41 |
| tristan | tpollard, i.e. its a very similar mode as `bst --colors ... | cat` | 11:41 |
| tristan | hmmm, due to clicks handling of boolean options it might not be prefixable with --log- | 11:42 |
| tristan | lemme check current options, actually technically we have --color / --no-color already which is not --log-color / --log-no-color | 11:43 |
| tristan | tpollard, probably we can have --status/--no-status on the CLI, defaulting to whatever value is in the config; and have `status: True` in data/userconfig.yaml (the defaults) | 11:44 |
| tristan | right, I was wrong about --log prefix... we don't have anything like that (--verbose/--no-verbose, --debug/--no-debug, --message-lines, --error-lines, --colors, --no-interactive... all examples of logging related options) | 11:46 |
| tpollard | tristan: yep I think --status/--no-status makes sense with the default as true in userdata | 11:48 |
| tpollard | under the logging options | 11:48 |
| tpollard | which I'd have set Status._header to None, queried in render() | 11:51 |
| tristan | tpollard, I think there is already conditions under which we either create the status bar or not | 11:53 |
| cs-shadow | hi, it seems like several CI jobs get "stuck" these days. Any clues as to what's causing that? | 11:53 |
| tpollard | cs-shadow: raoul is looking at https://gitlab.com/BuildStream/buildstream/issues/1023 | 11:54 |
| tristan | tpollard, it's not created if were not connected to the terminal and/or the terminal we're created on does not support the ANSI escape codes that it requires | 11:54 |
| cs-shadow | tpollard: Thanks! I think I am referring to a different issue. For example, https://gitlab.com/BuildStream/buildstream/-/jobs/216320678. It has been started 15 mins ago but nothing seems to be happening there. Is that perhaps because we have too many jobs running in parallel and it's unable to find resources? | 11:56 |
| tristan | tpollard, so you want to first create the user config and parse it in _context.py, then add a main option in _frontend/cli.py, and finally you want to add that option to the mapping here: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_frontend/app.py#L174 | 11:56 |
| tristan | tpollard, those come together to get the right order of precedence of defaults and such... that happens early enough that you can decide whether or not a Status() object is needed or not | 11:57 |
| tristan | looking at the mapping https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_frontend/app.py#L174, one cannot help to notice the eyesore | 11:58 |
| tristan | that we are accessing private _strict_build_plan | 11:58 |
| tristan | one has to wonder if that is really private, I think it is actually | 11:59 |
| tpollard | tristan: Yep, I did pull/cache buildtrees so it's part of the codebase I'm comfortable with to some extent :). Thanks for pointing out that it probably makes sense to capture the need for Status() earlier | 12:01 |
| tristan | Heh :) | 12:01 |
| tpollard | cs-shadow: that one would suggest a resource bottleneck to me. One thing I would like to handle in a more automated fashion would be to stop a pipeline executed if another push was sent within a certain threshold | 12:03 |
| tpollard | if a push is sent early enough the git checkout fails obviously, but it's still wasted resources | 12:03 |
| tpollard | especially with no enforced policy to manually cancel again non MR branches | 12:03 |
| tpollard | *against | 12:05 |
| *** lachlan has quit IRC | 12:11 | |
| tpollard | tpollard: ah yes, render & clear are noop depedant on the terminal init return. That could be the most suitable places for the option capture too | 12:28 |
| *** lachlan has joined #buildstream | 13:41 | |
| *** lachlan has quit IRC | 13:57 | |
| *** lachlan has joined #buildstream | 14:01 | |
| Kinnison | I have a question about project second stage loading | 14:06 |
| Kinnison | Under what circumstances can a project not be in a position to undergo second stage load (i.e. become fully realised)? | 14:06 |
| *** lachlan has quit IRC | 14:08 | |
| gitlab-br-bot | aevri opened (was WIP) MR !1348 (aevri/fix_logging_regex_test->master: tests/frontend/logging.py: fix error message regex) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1348 | 14:09 |
| Kinnison | Basically I'm trying to work out how early I can call someproject.ensure_fully_loaded() | 14:11 |
| tristan | Kinnison, good luck ;-) | 14:13 |
| tristan | heh | 14:13 |
| tristan | Kinnison, valentind implemented the dual stage load... and I can tell you the reason for it | 14:13 |
| *** lachlan has joined #buildstream | 14:14 | |
| tristan | Basically, (@) includes has to work cross-junctions | 14:14 |
| tristan | Kinnison, so the first pass load, is for resolving junctions, once junctions are all resolved - cross junction includes can be processed, meaning the rest of the project can be resolved | 14:14 |
| * tristan created https://github.com/ostreedev/ostree/pull/1862 today | 14:16 | |
| *** lachlan has quit IRC | 14:17 | |
| Kinnison | tristan: So basically if I could come up with a clean way to force-resolve the junctions as early as possible, I could fully resolve the projects and the junctions first, and then load the rest of the elements? | 14:17 |
| tristan | wasn't all that hard actually ... in case anyone is interested, that will let us do `bst checkout --tar - | ostree commit --tree=tar=-`, and should be the first step towards supporting similar in flatpak tooling | 14:17 |
| tristan | Kinnison, Well... that exercise might end up mostly being finding a more sensible name for "first pass" and "second pass" | 14:18 |
| tristan | Which... I would definitely support :) | 14:18 |
| tristan | If it is even cleaner as a result of refactoring, always a bonus | 14:18 |
| Kinnison | tristan: current, afaict, we defer "second pass" to Element._new_from_meta essentially | 14:18 |
| * Kinnison wants to do more work in the loader, which means working out how to second-pass as *early* as possible | 14:19 | |
| tristan | Mmmmyeah | 14:19 |
| tristan | Kinnison, I didnt delve too deeply into that proposal honestly | 14:19 |
| Kinnison | which probably means processing the includes on the project in such a way that if there's a cross-junction include, that gets noted, then we load that junction element, and repeat, until we're able to resolve fully | 14:19 |
| Kinnison | at that point we have the parent project, its junction elements, the subprojects, their junctions, blahblah, all fully resolved | 14:20 |
| Kinnison | then we can begin to load the targets | 14:20 |
| Kinnison | (note, only the junctions mentioned by the project.conf and any includes there-from) | 14:20 |
| Kinnison | so that *ought* to be okay | 14:20 |
| tristan | Kinnison, and you're not worried about cementing the load process into the loader and out of the elements at all ? | 14:21 |
| Kinnison | tristan: I think the load process *ought* to be in the loader | 14:22 |
| tristan | That is splitting hairs a bit, or arguing over terminology | 14:22 |
| tristan | Kinnison, part of the load process will always be in Plugin.configure() | 14:22 |
| Kinnison | at the end of the loader, we ought to have the fully realised set of data necessary to construct the elements, ideally without having to re-read yaml or re-composite things | 14:22 |
| tristan | i.e. it cannot be owned by the core | 14:22 |
| Kinnison | Plugin.configure() is about retrieving information that has already been loaded | 14:23 |
| Kinnison | no? | 14:23 |
| tristan | Right, that is a question of terminology indeed | 14:23 |
| tristan | But now, instead of the the base Element class knowing what it needs from the loaded yaml and handling that, you've moving that into the loader I guess | 14:23 |
| Kinnison | Basically I want to move out of Element anything which is actually part of the *format* | 14:24 |
| tristan | as I said, I havent delved too deeply into that - my only twitch was that "Is the element/source going to have less freedom to evolve now that things get cemented into this loader thing ?" | 14:24 |
| Kinnison | and which bits of what yaml get composited together in what order and when is the *format* IMO | 14:24 |
| Kinnison | Once you're beyond the *format*, it's up to plugins and I don't mind | 14:24 |
| Kinnison | But if we've defined it in the format specification in the docs, then IMO the loader should deal with it | 14:25 |
| tristan | Right, but there is all the composition, for that you get out of the loader domain and into the element domain IMO | 14:25 |
| Kinnison | I'd say no, the element is responsible for consuming the composed format | 14:25 |
| tristan | Well, you are aiming to change is so that it would be that, yes | 14:26 |
| Kinnison | Right, currently your statement is currently, I'm aiming to make it so that the loader is king for all of that | 14:26 |
| Kinnison | Eventually then the loader may be able to do cross-element optimisation by not repeating composition work which could be shared | 14:27 |
| tristan | Right, which does make me twitch a bit - I understand this is in the interest of better caching | 14:27 |
| Kinnison | Not necessarily caching so much as not-repeating-work | 14:27 |
| tristan | but I don't feel it is more sensible | 14:27 |
| gitlab-br-bot | cs-shadow opened (was WIP) MR !1322 (chandan/src-directory->master: Move source from 'buildstream' to 'src/buildstream') on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1322 | 14:27 |
| Kinnison | You don't feel that right now Element and Loader are too tightly coupled via the 'format' specification ? | 14:27 |
| tristan | Kinnison, We shouldnt be repeating work as it is | 14:27 |
| tristan | Kinnison, I.e. element class level YAML overrides project YAML, and gets cached once | 14:28 |
| tristan | (cached in memory) | 14:28 |
| Kinnison | Yes, that's Plugin.__defaults | 14:28 |
| *** lachlan has joined #buildstream | 14:28 | |
| tristan | Kinnison, I don't feel that the definition of what the format is belongs to the loader, to answer your question, no | 14:29 |
| Kinnison | Okay, that's helpful | 14:29 |
| Kinnison | so i need to try and rationalise my thought process and put it out there for debate | 14:29 |
| Kinnison | so we can find a middle ground | 14:29 |
| tristan | Kinnison, I feel that the definition of what an Element's format is belongs to Element, and what a Source is, belongs to Source, and whatever is common, belongs to Plugin | 14:29 |
| tristan | Kinnison, But - I should really say this is a only a twitch, I cant allow myself to feel super strongly about that, it's my gut intuition of what is sensible | 14:30 |
| Kinnison | So code-logic-wise I don't necessarily disagree, but invocation time and management I think might belong to Loader but I'm not sure - it may belong to Project | 14:30 |
| Kinnison | I need to think harder about where the behaviour is, esp. now you've clarified what the first-pass vs. second-pass on project is | 14:30 |
| Kinnison | thank you | 14:30 |
| tristan | I sort of recognized it was a twitch when I originally read the email, and refrained from any reaction, and though - maybe I will understand more when I see the code, and probably the result will be equally sensible :) | 14:31 |
| tristan | s/though/thought | 14:31 |
| Kinnison | I don't want to make things worse, for sure :D | 14:32 |
| *** lachlan has quit IRC | 14:32 | |
| Kinnison | I was thinking that if I moved the logic, it'd be Element's logic => MetaElement and Source's logic => MetaSource | 14:32 |
| Kinnison | so there'd still be *some* separation of Loader vs. Meta{Element,Source} | 14:33 |
| *** tristan has quit IRC | 14:57 | |
| *** tristan has joined #buildstream | 15:20 | |
| WSalmon | I think benschubert, and aevri have stages running on pipelines that are not latest, given that we dont have infinite runner and that gitlab dose not kill off your old pipeline if you push another, could i make a gentle reminder for us to all be careful to cancel unneeded pipelines (I know im not always great at this, and i know not every one realises that they dont get auto killed and i know some times people have a good reason to keep them | 15:24 |
| WSalmon | running) | 15:24 |
| *** ChanServ sets mode: +o tristan | 15:26 | |
| * tristan sometimes gardens them and ruthlessly kills other peoples pipelines that are not 'latest' of their branch | 15:26 | |
| tristan | havent had a complain yet ;-) | 15:26 |
| tristan | *complaint | 15:26 |
| aevri | Aha, I wasn't aware of that before, sorry to take up resources :) | 15:26 |
| aevri | I've cleaned mine up from here https://gitlab.com/BuildStream/buildstream/pipelines?scope=running&page=1 | 15:26 |
| WSalmon | lots of people aren't :) so i thought a reminder might be a good idea | 15:27 |
| aevri | I do notice a certain wsalmon also seems to have a 'non-latest' job running :P :) | 15:28 |
| tristan | we could probably script a bot that kills them, but then in some edge cases I actually *want* to see the results of different pipelines on the same branch intentionally | 15:28 |
| WSalmon | hahaha, i thought i had checked | 15:28 |
| WSalmon | its so easily done | 15:28 |
| aevri | yeah, unfortunately that it's the default | 15:28 |
| juergbi | I also occasionally cancel non-latest jobs, especially if there are lots pending or running | 15:29 |
| juergbi | would be good to solve the stuck job issue soon | 15:29 |
| WSalmon | yes that one was one of our randomly hanging ones from much earlier in the day i wonder if our 22h hour time out is a good idea given most of our jobs are sub 1hr | 15:31 |
| juergbi | I'm wondering whether it might be related to parallel testing. the stuck job issue started happening a lot after enabling parallel testing but it's still possible that it wouldn't happen without parallel testing | 15:31 |
| juergbi | WSalmon: I think we have the long timeout because of the overnight tests. is there a way to have different timeouts for overnight and regular? | 15:31 |
| WSalmon | I would hope so, i will go have a look | 15:31 |
| tpollard | the issue raised on raoul's ticket definitely only happens to me if I run locally in parallel | 15:32 |
| tpollard | hopefully the bug chasing pays off | 15:33 |
| tristan | WSalmon, I think the 22h timer is excessive, but we need a longer timeout for the nightly tests which build freedesktop-sdk without hitting any artifact cache | 15:33 |
| raoul | Yeah I've never reproduced it not in parallel | 15:33 |
| tristan | not sure if we can configure the timeout on a per-jobtype basis | 15:33 |
| raoul | tristen you can set timeouts per test with pytest-timeout | 15:34 |
| tristan | raoul, I mean the gitlab timeout | 15:34 |
| juergbi | raoul: in that case maybe we should disable parallel testing in CI until we find a solution | 15:34 |
| tristan | but that is also possible I guess | 15:34 |
| juergbi | that said, I haven't seen tests hang locally yet despite always running them in parallel | 15:35 |
| raoul | me and tpollard have | 15:36 |
| WSalmon | so, according to the docks you could set it at a runner level, so we could have two bastions on the bastion server and get the nightly to build on them and give them the longer time out, it would be a bit more effort. (I assuem that they both take runners from the same pool and that other things would play ball) | 15:36 |
| WSalmon | jjardon, did you set up all the runners, would this be a pain to do? | 15:36 |
| benschubert | locally I also have often tests hanging | 15:37 |
| benschubert | especially the umask tests | 15:38 |
| juergbi | oh, interesting. wondering why I don't see that issue | 15:49 |
| juergbi | number of workers (and timing) might make a big difference, in case a specific sequence of tests in a particular worker triggers the issue | 15:50 |
| tpollard | maybe 16 runners is the magic number juergbi | 15:50 |
| tpollard | threadripper is just too good | 15:50 |
| WSalmon | i presume juergbi also has a very nice disk, and that the runners and benschubert's wsl have very slow disk | 15:51 |
| WSalmon | *I know benschubert's is fast disk but it has to go via wsl | 15:51 |
| tpollard | WSalmon: don't make me even more envious | 15:52 |
| benschubert | WSalmon: that's even when running on my Fedora home system | 15:52 |
| WSalmon | oh fair | 15:53 |
| WSalmon | benschubert, have you had them fail and hang? or just one? | 15:56 |
| benschubert | hang only | 15:58 |
| juergbi | benschubert: what tox options do you commonly use on your Fedora system? i.e., how many workers and with or without --integration? | 16:12 |
| gitlab-br-bot | BenjaminSchubert approved MR !1322 (chandan/src-directory->master: Move source from 'buildstream' to 'src/buildstream') on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1322 | 16:15 |
| gitlab-br-bot | BenjaminSchubert unapproved MR !1322 (chandan/src-directory->master: Move source from 'buildstream' to 'src/buildstream') on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1322 | 16:15 |
| *** lachlan has joined #buildstream | 16:16 | |
| *** bochecha has quit IRC | 16:17 | |
| benschubert | juergbi: tox -e py37 -- -x --no-cov is usually what I run | 16:17 |
| *** phil has joined #buildstream | 16:18 | |
| juergbi | benschubert: that'd be without parallel testing, though | 16:18 |
| juergbi | i.e., do you see hangs without parallel testing or do you enable them some other way? | 16:19 |
| benschubert | juergbi: yup, I get hangs even without parallel testing | 16:19 |
| *** phildawson_ has quit IRC | 16:19 | |
| juergbi | oh, good to know. so much for that theory | 16:19 |
| juergbi | raoul: ^^ | 16:19 |
| raoul | oh, at a similar sort of rate? | 16:19 |
| *** lachlan has quit IRC | 16:19 | |
| raoul | cause I've never had it | 16:19 |
| benschubert | raoul: I have to cancel roughly 20% of my test runs | 16:20 |
| raoul | wow that's pretty bad | 16:20 |
| raoul | this bug just doesn't make any sense :( | 16:20 |
| benschubert | I can have a better look, but might need to wait, I can only reproduce on my home laptop x0 | 16:20 |
| raoul | is it always hanging after the zip.py::test_use_netrc[HTTP] test? | 16:21 |
| benschubert | raoul: I'm more seeing hangs locally on umask tests, and on the CI on the netrc onces | 16:22 |
| benschubert | *onces | 16:23 |
| benschubert | I however have no idea what can be going wrong :/ | 16:23 |
| raoul | ah, yeah I've been trying to track down the netrc one | 16:23 |
| benschubert | good luck :/ | 16:24 |
| *** tpollard has quit IRC | 16:42 | |
| gitlab-br-bot | BenjaminSchubert approved MR !1322 (chandan/src-directory->master: Move source from 'buildstream' to 'src/buildstream') on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1322 | 16:43 |
| gitlab-br-bot | aevri approved MR !1322 (chandan/src-directory->master: Move source from 'buildstream' to 'src/buildstream') on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1322 | 16:49 |
| aevri | It's possible we have an intermittent bug in cache deletion: https://gitlab.com/BuildStream/buildstream/-/jobs/216486082 | 16:49 |
| aevri | It failed "test_never_delete_required_track" | 16:49 |
| aevri | With this: [00:00:00] FAILURE dep2.bst: Directory not found in local cache: [Errno 2] No such file or directory: '/builds/BuildStream/buildstream/.tox/py37/tmp/popen-gw0/test_never_delete_required_tra0/cache/cas/objects/33/ee7006f0398c9ceb86b4a5deb2753bb9dd5f13f33d4418589c0f92d173400e' | 16:50 |
| gitlab-br-bot | aevri opened (was WIP) MR !1337 (aevri/set_message_unique_id->master: jobs: refactor, use new set_message_unique_id) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1337 | 16:53 |
| *** jonathanmaw has quit IRC | 17:03 | |
| *** lachlan has joined #buildstream | 17:08 | |
| gitlab-br-bot | cs-shadow closed issue #1009 (CI doesn't test sdist packaging includes necessary data files) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1009 | 17:08 |
| gitlab-br-bot | cs-shadow merged MR !1322 (chandan/src-directory->master: Move source from 'buildstream' to 'src/buildstream') on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1322 | 17:08 |
| cs-shadow | Public service announcement: Now that ^ is merged, all buildstream source is now inside a `src` directory. There might be some manual rebasing needed if your branch was adding/removing files. Other than that, if you notice any incorrect links etc, please let me know | 17:13 |
| *** phil has quit IRC | 17:40 | |
| *** lachlan has quit IRC | 17:45 | |
| *** xjuan has joined #buildstream | 17:57 | |
| *** slaf_ has joined #buildstream | 18:24 | |
| *** slaf_ has joined #buildstream | 18:25 | |
| *** slaf_ has joined #buildstream | 18:25 | |
| *** slaf_ has joined #buildstream | 18:25 | |
| *** slaf has quit IRC | 18:26 | |
| *** slaf_ is now known as slaf | 18:27 | |
| *** bochecha has joined #buildstream | 18:34 | |
| *** pointswaves has quit IRC | 18:54 | |
| *** bochecha has quit IRC | 19:18 | |
| *** pointswaves has joined #buildstream | 19:22 | |
| *** bochecha has joined #buildstream | 19:47 | |
| *** slaf has quit IRC | 19:58 | |
| *** toscalix has joined #buildstream | 20:25 | |
| *** toscalix has quit IRC | 20:36 | |
| *** pointswaves has quit IRC | 20:36 | |
| *** bochecha has quit IRC | 20:39 | |
| *** slaf has joined #buildstream | 20:39 | |
| *** slaf has joined #buildstream | 20:40 | |
| *** slaf has joined #buildstream | 20:40 | |
| *** slaf has joined #buildstream | 20:40 | |
| *** slaf has joined #buildstream | 20:41 | |
| *** slaf has joined #buildstream | 20:41 | |
| *** slaf has joined #buildstream | 20:41 | |
| *** slaf has joined #buildstream | 20:41 | |
| *** slaf has joined #buildstream | 20:42 | |
| *** slaf has joined #buildstream | 20:42 | |
| *** bochecha has joined #buildstream | 20:55 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!