| *** qinusty has joined #buildstream | 08:19 | |
| *** ikerperez has joined #buildstream | 08:24 | |
| *** traveltissues has joined #buildstream | 08:25 | |
| benschubert | tristan: oh that seems a good point, but I struggle to understand how the test would actually be testing that :) I'll investigate more, thanks ! | 09:04 |
|---|---|---|
| benschubert | tlater[m]: sorry, was out on friday | 09:05 |
| *** adds68 has joined #buildstream | 09:27 | |
| *** rdale has joined #buildstream | 09:28 | |
| *** tme5 has joined #buildstream | 09:34 | |
| *** santi has joined #buildstream | 09:34 | |
| *** tiagogomes has joined #buildstream | 09:46 | |
| *** tiagogomes has quit IRC | 09:51 | |
| *** tiagogomes has joined #buildstream | 09:53 | |
| coldtom | hi, does anyone know if bst works with python 3.8? | 09:55 |
| tpollard | not quite | 09:57 |
| tpollard | https://gitlab.com/BuildStream/buildstream/merge_requests/1647 | 09:57 |
| coldtom | ack, ta tpollard | 10:00 |
| *** cs-shadow has joined #buildstream | 10:03 | |
| *** jonathanmaw has joined #buildstream | 10:27 | |
| *** lachlan has joined #buildstream | 10:35 | |
| *** lachlan has quit IRC | 10:51 | |
| *** santi has quit IRC | 10:53 | |
| *** santi has joined #buildstream | 10:56 | |
| *** lachlan has joined #buildstream | 11:09 | |
| tlater[m] | juergbi: Think we can land !1645 with the band-aid around the repeated digest thing? | 11:23 |
| gitlab-br-bot | MR !1645: Refactor casserver.py: Stop relying on the buildstream-internal `CASCache` implementation https://gitlab.com/BuildStream/buildstream/merge_requests/1645 | 11:23 |
| tlater[m] | I'm just not sure why my branch suddenly duplicates a digest in the request, when master doesn't and none of that code changed. | 11:24 |
| *** lachlan has quit IRC | 11:25 | |
| juergbi | tlater[m]: it might be a bug in buildbox-casd BatchReadBlobs | 11:27 |
| juergbi | before we had: FetchMissingBlobs from bst to local casd. BatchReadBlobs from local casd to bst-artifact-server. bst-artifact-server handling that internally in the Python implementation | 11:28 |
| juergbi | now the last part is replaced by proxying BatchReadBlobs to the remote casd | 11:29 |
| juergbi | i.e., we didn't hit the casd BatchReadBlobs code path before | 11:29 |
| tlater[m] | The duplication is definitely in the request sent from BuildStream - perhaps bst-artifact-server de-duplicated that? | 11:29 |
| juergbi | no, but it was a simple implementation that didn't fall over with duplicated blobs | 11:30 |
| juergbi | it simply read blobs one by one and added responses | 11:30 |
| tlater[m] | Oh, right | 11:31 |
| tlater[m] | I guess in that case the band-aid is the best option on the BuildStream side for now | 11:31 |
| juergbi | I'm not particularly happy about the workaround. if we can quickly fix it in buildbox-casd, maybe that would be better | 11:32 |
| tlater[m] | I suppose. I guess I'm used to dependency updates taking a bit too long for that | 11:32 |
| juergbi | if it's a simple fix in casd, it shouldn't be an issue per se to update the casd dependency. although such an update still requires a bit more than just a click, unfortunately | 11:35 |
| juergbi | have to update casd anyway for my buildbox-run MR, though | 11:35 |
| juergbi | so maybe we could do this together | 11:35 |
| tlater[m] | Better than a temporary commit, I suppose :) | 11:36 |
| juergbi | it's the only blocker for your MR, so we can still otherwise consider this MR ready. and afaik, nobody is blocking on this MR, except my buildbox-run MR, which also requires a casd update | 11:36 |
| juergbi | (one reason I don't like the workaround is that it's O(N^2), afaict, although that would be easy to fix) | 11:38 |
| tlater[m] | juergbi: Yeah, it's not particularly efficient | 11:39 |
| tlater[m] | And I suppose we make a fair number of requests, so that's rather annoying. | 11:39 |
| *** lachlan has joined #buildstream | 11:39 | |
| *** lachlan has quit IRC | 11:42 | |
| gitlab-br-bot | tpollard opened MR !1741 (tpollard/failedsource->master: element.py: Explicitly ensure failed build sources are not pushed) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1741 | 11:45 |
| benschubert | tpollard: ^ why would we want that? I don't think not being able to push a failed build should be correct :) What if I need to push the sources and the build to show a colleague that it's failing? (Or did we have a discussion somewhere that I missed?) | 11:48 |
| tpollard | I agree, but that's the current behaviour | 11:48 |
| tpollard | the source push will never happen, because the build failed | 11:49 |
| tpollard | and there's no source push command | 11:49 |
| benschubert | if I have a '--on-error=continue' that still isn't pushed? | 11:49 |
| tlater[m] | I also think the problem is that a build failure may still be temporary and can't be repeated | 11:50 |
| tlater[m] | So if a failed build is pushed to a cache, currently anyone using said cache will get that failure, even if, say, the host ran out of memory | 11:50 |
| benschubert | tlater[m]: that's another problem, around artifacts, but for sources, I don't think we should avoid pushing them :) | 11:52 |
| tlater[m] | Ah, that's a different failure case :D | 11:52 |
| juergbi | I agree with benschubert, I'd rather consider the not pushing a bug/limitation | 11:52 |
| juergbi | for artifacts it's actually also considered a bug: #534 | 11:52 |
| gitlab-br-bot | Issue #534: Failed builds not pushing artifacts on quit https://gitlab.com/BuildStream/buildstream/issues/534 | 11:52 |
| gitlab-br-bot | BenjaminSchubert opened MR !1742 (bschubert/update-requirements->master: Update BuildStream requirements) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1742 | 11:52 |
| juergbi | have an xfail for this | 11:52 |
| tlater[m] | We really should have a `source push` command some day. | 11:52 |
| benschubert | ^ +1 | 11:53 |
| tpollard | yep | 11:53 |
| juergbi | yes, I think we agreed on that in the mailing list UX discussion | 11:53 |
| tpollard | I also thinks there's merit for default behaviour to not push the source if it failed, that could be overridden | 11:53 |
| juergbi | not sure whether we actually need that | 11:54 |
| tpollard | do you want to push potentially gigabytes by default if somethings never going to build due to broken source? | 11:54 |
| juergbi | by default, in interactive mode, the user could anyway decide by choosing terminate/quit or continue | 11:54 |
| juergbi | sources are pushed as individual blobs | 11:54 |
| juergbi | if you fix the bug in the source later, only the fixed source files will be updated | 11:55 |
| juergbi | (assuming you don't do strange things like importing a huge tarball as a single source file and then extract as part of the build commands) | 11:55 |
| juergbi | i.e., I'd argue this would normally not waste lots of resources | 11:56 |
| tpollard | yes fair enough | 11:56 |
| tpollard | although that strange usecase is definitely a possibility.... | 11:56 |
| *** lachlan has joined #buildstream | 11:57 | |
| juergbi | maybe but let's focus on the recommended workflows | 11:57 |
| tpollard | yep | 11:57 |
| * tlater[m] creates a BuildStream project with only `manual:` elements and `local:` sources to complain about this | 11:58 | |
| tpollard | I'm happy for the change to get closed, I didn't agree with the current assumptions (I only found the issue when doing the multiprocessing work) | 11:59 |
| benschubert | I think opening an issue saying it should get fixed might be better | 12:00 |
| *** lachlan has quit IRC | 12:00 | |
| benschubert | becasue if we 'cement it' in place, we might not rememeber why and not have the desired behavior in the future | 12:00 |
| tpollard | i.e, the source push queue would execute before the mp queues had time to process the build failure between processes | 12:00 |
| persia | Can the source push block on that processing completing? | 12:01 |
| persia | (yes, this makes it all a bit slower in the success case, but avoids pushing potentially failed things before processing) | 12:01 |
| tme5 | I think if a build fails, the source should be pushed because caching a source is convenient and expected regardless of result. However i'm not sure a failed artifact should be automatically pushed. I think that goes against what the user wants in most cases -- I tried to build an element and it failed: the result is not what i want, so don't push it | 12:02 |
| tme5 | as far as I understand, pushing a failed artifact can still be done manually | 12:03 |
| tlater[m] | persia: Probably, but scheduling that becomes a fun problem because it all happens on different processes. | 12:03 |
| *** phildawson has quit IRC | 12:03 | |
| tlater[m] | It's not a trivial fix | 12:03 |
| benschubert | tme5: I'd love a '--push-only-success' for now that I think about it | 12:03 |
| gitlab-br-bot | tpollard closed MR !1741 (tpollard/failedsource->master: element.py: Explicitly ensure failed build sources are not pushed) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1741 | 12:04 |
| tme5 | sources or artifacts? | 12:04 |
| tlater[m] | Could probably be both, don't really think you'd want to push a failed workspace | 12:05 |
| traveltissues | tpollard, left a comment there just as it was closed | 12:05 |
| tme5 | pushing a failed artifact is, imo, ignorant of the user's intent | 12:05 |
| *** phildawson has joined #buildstream | 12:05 | |
| tme5 | pushing automatically* | 12:05 |
| tme5 | so in some sense i believe this issue is reversed: from failed builds, sources should push automatically, and artifacts shouldn't | 12:06 |
| tpollard | traveltissues: yep I just saw it, will create an issue that links back to the MR so it's not lost | 12:06 |
| benschubert | tme5: in some CIs, you'll want only failing, all, or only succcess, depending on what's the purpose of the CI :) and there is no good way currently | 12:06 |
| traveltissues | agree with benschubert though | 12:06 |
| benschubert | What we do it build everything with no push configuration, then push only the packages we want | 12:07 |
| persia | I also believe it should be configurable. There's lots of cases where you'd want failed CI builds to push (e.g. to speed local debugging of the failure). | 12:07 |
| persia | On the other hand, I suspect this is a knotty problem to solve (and doubt the current behaviour is either well-specified or intentional). Are there other benefits from multiprocess that make it worth landing a change now (still with an issue to resolve the bug later) so that we at least can guess what will happen? | 12:08 |
| tme5 | benschubert, interesting, hadn't encountered this kind of use case in my buildstream usage. I suppose having buildstream manage pushing itself is the only solution for that in CI | 12:10 |
| benschubert | Yep :) | 12:11 |
| gitlab-br-bot | cs-shadow approved MR !1742 (bschubert/update-requirements->master: Update BuildStream requirements) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1742 | 12:11 |
| gitlab-br-bot | tpollard opened issue #1225 (Formalise the pushing of failed sources) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1225 | 12:17 |
| tpollard | juergbi: do you think there's any merit for changing the logic of is_main_process to is_job_process in master, disregarding the wider multiprocessing changes? | 12:24 |
| tpollard | there is in my head, but I release I've been working in different environment for quite a few months :_ | 12:25 |
| tpollard | * :) | 12:25 |
| tpollard | *realise | 12:25 |
| juergbi | I'm not sure | 12:26 |
| juergbi | I would probably leave it as is in master | 12:27 |
| juergbi | as there shouldn't really be any confusion about what the main process is there, afaict | 12:28 |
| *** lachlan has joined #buildstream | 12:31 | |
| *** lachlan has quit IRC | 12:35 | |
| *** lachlan has joined #buildstream | 12:37 | |
| *** lachlan has quit IRC | 12:41 | |
| *** lachlan has joined #buildstream | 12:42 | |
| *** lachlan has quit IRC | 12:48 | |
| gitlab-br-bot | tlater approved MR !1742 (bschubert/update-requirements->master: Update BuildStream requirements) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1742 | 12:59 |
| tpollard | juergbi: ack | 13:03 |
| tlater[m] | juergbi: Looks like the casd bug has somehow become accross all branches. | 13:03 |
| *** akvilebirgelyte__ has joined #buildstream | 13:14 | |
| *** santi has quit IRC | 13:15 | |
| tlater[m] | benschubert: I think marge is refusing to merge things with orange pipelines | 13:16 |
| tlater[m] | We might need to revert to merging manually until the buildbox-casd thing is fixed | 13:16 |
| tlater[m] | (Regarding !1742) | 13:16 |
| *** akvilebirgelyte__ has quit IRC | 13:22 | |
| *** akvilebirgelyte__ has joined #buildstream | 13:22 | |
| benschubert | :( poor Marge, Thanks I'll merge myself :) | 13:24 |
| Kinnison | Is she dead inside again? | 13:24 |
| tlater[m] | Kinnison: Nah, she just gets confused and tells us things take too long to be "marked as merged" | 13:25 |
| tlater[m] | But it happens consistently on anything with an orange pipeline, so I figure that's the problem | 13:25 |
| Kinnison | Aah | 13:26 |
| gitlab-br-bot | BenjaminSchubert merged MR !1742 (bschubert/update-requirements->master: Update BuildStream requirements) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1742 | 13:34 |
| *** akvilebirgelyte__ has quit IRC | 13:35 | |
| *** akvilebirgelyte__ has joined #buildstream | 13:36 | |
| *** akvilebirgelyte__ has quit IRC | 14:02 | |
| *** akvilebirgelyte__ has joined #buildstream | 14:04 | |
| *** santi has joined #buildstream | 14:09 | |
| *** lachlan has joined #buildstream | 14:27 | |
| *** lachlan has quit IRC | 14:33 | |
| *** lachlan has joined #buildstream | 14:49 | |
| *** lachlan has quit IRC | 14:53 | |
| *** lachlan has joined #buildstream | 14:54 | |
| juergbi | tlater[m]: just saw this now. this would indicate that the issue started happening because of a change in either buildgrid or buildbox-* master | 14:56 |
| juergbi | so maybe it's an issue in the BuildGrid CAS server after all, bug in BatchReadBlobs | 14:57 |
| *** lachlan has quit IRC | 14:59 | |
| *** lachlan has joined #buildstream | 15:21 | |
| *** lachlan has quit IRC | 15:26 | |
| tlater[m] | juergbi: Best way to test would be to revert to whatever version of it we were using when the test suite last passed and see :D | 15:29 |
| *** akvilebirgelyte__ has quit IRC | 15:36 | |
| juergbi | tlater[m]: the issue started Wednesday or Thursday, right? | 15:42 |
| tlater[m] | juergbi: I saw it Thursday for the first time | 15:42 |
| juergbi | it seems BuildGrid's nightly docker image build wasn't running in the last few weeks. a new build was produced last Thursday noon and since then it's failing | 15:43 |
| juergbi | see https://gitlab.com/BuildGrid/buildgrid.hub.docker.com/pipelines | 15:43 |
| juergbi | pipeline #87140778 was good | 15:44 |
| juergbi | and I suspect the next pipeline #99215570 started breaking things in BuildStream | 15:44 |
| tlater[m] | Ah, shame that doesn't narrow it down for your debugging purposes | 15:44 |
| juergbi | I've verified that the docker image used in the last successful buildstream CI (on master) was the image from #87140778 | 15:44 |
| juergbi | almost two months of BuildGrid changes that could have triggered this | 15:45 |
| tlater[m] | :| | 15:47 |
| benschubert | juergbi, tlater[m] I'm not sure how come we missed that? Because the docker images were not rebuilt nightly or ? | 15:48 |
| juergbi | yes, we have to ask the BuildGrid devs | 15:49 |
| tlater[m] | benschubert: I seem to recall that someone's account had been demoted due to them leaving whatever organization they were part of | 15:49 |
| juergbi | SotK might know more ^^ | 15:49 |
| tlater[m] | And that GitLab didn't notify us that the job was under their ownership | 15:49 |
| tlater[m] | Hence we didn't have builds for a while | 15:50 |
| benschubert | Oh I see | 15:50 |
| juergbi | my wild guess is https://gitlab.com/BuildGrid/buildgrid/commit/b2af88882ec4762c08ca462f6c5604d7ca621eab | 15:50 |
| juergbi | creates a Python dictionary with the digest hashes as keys | 15:51 |
| * tlater[m] is glad it's probably not his branch introducing this though | 15:54 | |
| tlater[m] | It had me worried that I was introducing some very strange regression :D | 15:54 |
| *** lachlan has joined #buildstream | 15:55 | |
| * SotK reads backscroll | 15:56 | |
| juergbi | SotK: context: buildstream remote execution test started failing. we though it was caused by a change on our side but it seems it's happening since the nightly buildgrid images are building again a few days ago | 15:57 |
| juergbi | even without changes on our side | 15:57 |
| juergbi | I'll open an issue | 15:59 |
| SotK | that wild guess seems like a sensible place to start looking, the timing certainly makes it appear to be an issue in buildgrid itself | 16:01 |
| juergbi | I'll try whether I can quickly reproduce it with a standalone buildgrid test | 16:03 |
| SotK | thanks | 16:07 |
| *** lachlan has quit IRC | 16:19 | |
| *** lachlan has joined #buildstream | 16:26 | |
| *** lachlan has quit IRC | 16:29 | |
| juergbi | SotK, tlater[m]: https://gitlab.com/BuildGrid/buildgrid/issues/230 | 16:35 |
| tlater[m] | ta juergbi | 16:37 |
| gitlab-br-bot | tlater opened MR !1743 (tlater/fix-update-committer-security->master: update_commiters.py: Fix security vulnerabilities) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1743 | 16:42 |
| *** santi has quit IRC | 16:43 | |
| *** lachlan has joined #buildstream | 16:48 | |
| *** traveltissues has quit IRC | 16:51 | |
| *** lachlan has quit IRC | 16:51 | |
| gitlab-br-bot | tlater opened MR !1744 (tlater/fix-jinja-autoescape->master: optionpool.py: Make jinja autoescape rules explicit) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1744 | 16:58 |
| gitlab-br-bot | BenjaminSchubert approved MR !1744 (tlater/fix-jinja-autoescape->master: optionpool.py: Make jinja autoescape rules explicit) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1744 | 17:03 |
| *** santi has joined #buildstream | 17:10 | |
| *** tme5 has quit IRC | 17:20 | |
| gitlab-br-bot | BenjaminSchubert approved MR !1743 (tlater/fix-update-committer-security->master: update_commiters.py: Fix security vulnerabilities) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1743 | 17:21 |
| tlater[m] | Such a shame marge isn't her usual self today | 17:22 |
| tlater[m] | benschubert: yuck, the security vulnerability scanner only allows select_autoescape, not jinja2.select_autoescape | 17:36 |
| tlater[m] | :| | 17:36 |
| * tlater[m] wonders if he can work around that with `select_autoescape = jinja2.select_autoescape` | 17:36 | |
| benschubert | would have been too easy -_-' | 17:36 |
| tlater[m] | Eww, that actually works | 17:39 |
| benschubert | ? | 17:41 |
| tlater[m] | benschubert: It doesn't care whether the function named `select_autoescape` is imported from `jinja2` | 17:42 |
| tlater[m] | It'll take any variable named that, and accept it as "not a security vulnerability at all anymore" | 17:42 |
| tlater[m] | But it will not allow any function not named that. | 17:42 |
| tlater[m] | So if you write your own select function, and name it something else, it will complain, even if it does select a reasonable policy. | 17:43 |
| benschubert | I don't know why, I'm not surprised | 17:47 |
| gitlab-br-bot | tlater merged MR !1743 (tlater/fix-update-committer-security->master: update_commiters.py: Fix security vulnerabilities) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1743 | 17:49 |
| *** mela9inekiddo has joined #buildstream | 17:52 | |
| gitlab-br-bot | tlater opened (was WIP) MR !1744 (tlater/fix-jinja-autoescape->master: optionpool.py: Make jinja autoescape rules explicit) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1744 | 17:54 |
| *** mela9inekiddo has quit IRC | 18:04 | |
| *** mela9inekiddo has joined #buildstream | 18:05 | |
| *** mela9inekiddo has quit IRC | 18:05 | |
| *** santi has quit IRC | 18:11 | |
| *** jonathanmaw has quit IRC | 18:26 | |
| *** lachlan has joined #buildstream | 18:29 | |
| *** tiagogomes has quit IRC | 18:38 | |
| *** lachlan has quit IRC | 18:44 | |
| gitlab-br-bot | cs-shadow opened (was WIP) MR !1706 (chandan/interactive-tests->master: Add tests for interactive BuildStream operations) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1706 | 18:46 |
| *** lachlan has joined #buildstream | 18:47 | |
| *** lachlan has quit IRC | 18:51 | |
| *** rdale has quit IRC | 19:08 | |
| *** lachlan has joined #buildstream | 19:32 | |
| *** lachlan has quit IRC | 19:36 | |
| *** lachlan has joined #buildstream | 20:25 | |
| *** lachlan has quit IRC | 20:35 | |
| *** cs-shadow has quit IRC | 21:11 | |
| *** testy has joined #buildstream | 21:20 | |
| *** coldtom8 has joined #buildstream | 21:21 | |
| *** benschubert_ has joined #buildstream | 21:22 | |
| *** phildawson has quit IRC | 21:22 | |
| *** narispo has quit IRC | 21:22 | |
| *** slaf has quit IRC | 21:22 | |
| *** tristan has quit IRC | 21:22 | |
| *** benschubert has quit IRC | 21:22 | |
| *** aevri has quit IRC | 21:22 | |
| *** jjardon has quit IRC | 21:22 | |
| *** WSalmon has quit IRC | 21:22 | |
| *** jward has quit IRC | 21:22 | |
| *** valentind has quit IRC | 21:22 | |
| *** bethw has quit IRC | 21:22 | |
| *** cgmcintyre[m] has quit IRC | 21:22 | |
| *** gimpnet-irc[m] has quit IRC | 21:22 | |
| *** asingh_[m] has quit IRC | 21:22 | |
| *** Trevinho[m] has quit IRC | 21:22 | |
| *** tchaik[m] has quit IRC | 21:22 | |
| *** ssssam[m] has quit IRC | 21:22 | |
| *** jswagner has quit IRC | 21:22 | |
| *** reuben640[m] has quit IRC | 21:22 | |
| *** tlater[m] has quit IRC | 21:22 | |
| *** rafaelff[m] has quit IRC | 21:22 | |
| *** mrmcq2u[m] has quit IRC | 21:22 | |
| *** nielsdg has quit IRC | 21:22 | |
| *** dbuch has quit IRC | 21:22 | |
| *** kailueke[m] has quit IRC | 21:22 | |
| *** abderrahim[m] has quit IRC | 21:22 | |
| *** m_22[m] has quit IRC | 21:22 | |
| *** doras has quit IRC | 21:22 | |
| *** mattiasb has quit IRC | 21:22 | |
| *** albfan[m] has quit IRC | 21:22 | |
| *** jjardon[m] has quit IRC | 21:22 | |
| *** skullone[m] has quit IRC | 21:22 | |
| *** verdre[m] has quit IRC | 21:22 | |
| *** waltervargas[m] has quit IRC | 21:22 | |
| *** awacheux[m] has quit IRC | 21:22 | |
| *** pro[m] has quit IRC | 21:22 | |
| *** krichter[m] has quit IRC | 21:22 | |
| *** Kinnison has quit IRC | 21:22 | |
| *** coldtom has quit IRC | 21:22 | |
| *** benbrown has quit IRC | 21:22 | |
| *** persia has quit IRC | 21:22 | |
| *** ironfoot has quit IRC | 21:22 | |
| *** benschubert_ is now known as benschubert | 21:22 | |
| *** jjardon has joined #buildstream | 21:22 | |
| *** jswagner has joined #buildstream | 21:22 | |
| *** phildawson has joined #buildstream | 21:22 | |
| *** aevri has joined #buildstream | 21:23 | |
| *** narispo has joined #buildstream | 21:23 | |
| *** benbrown has joined #buildstream | 21:23 | |
| *** Kinnison has joined #buildstream | 21:23 | |
| *** persia has joined #buildstream | 21:23 | |
| *** ironfoot has joined #buildstream | 21:24 | |
| *** bethw has joined #buildstream | 21:24 | |
| *** slaf has joined #buildstream | 21:25 | |
| *** jward has joined #buildstream | 21:25 | |
| *** WSalmon has joined #buildstream | 21:25 | |
| *** valentind has joined #buildstream | 21:25 | |
| *** tristan has joined #buildstream | 21:26 | |
| *** persia has quit IRC | 21:34 | |
| *** persia has joined #buildstream | 21:34 | |
| *** asingh_[m] has joined #buildstream | 21:46 | |
| *** rafaelff[m] has joined #buildstream | 22:03 | |
| *** cgmcintyre[m] has joined #buildstream | 22:11 | |
| *** jjardon[m] has joined #buildstream | 22:30 | |
| *** tlater[m] has joined #buildstream | 22:39 | |
| *** albfan[m] has joined #buildstream | 22:54 | |
| *** mrmcq2u[m] has joined #buildstream | 23:01 | |
| *** awacheux[m] has joined #buildstream | 23:06 | |
| *** krichter[m] has joined #buildstream | 23:09 | |
| *** pro[m] has joined #buildstream | 23:26 | |
| *** gimpnet-irc[m] has joined #buildstream | 23:28 | |
| *** skullone[m] has joined #buildstream | 23:43 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!