| gitlab-br-bot | buildstream: merge request (chandan/bst-and-docker->master: Add documentation and NEWS entry about bst-docker-import) #864 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/864 | 00:21 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (chandan/bst-and-docker->master: Add documentation and NEWS entry about bst-docker-import) #864 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/864 | 00:59 |
| *** xjuan has quit IRC | 01:22 | |
| *** catonano has joined #buildstream | 04:30 | |
| *** catonano has quit IRC | 05:01 | |
| *** catonano has joined #buildstream | 05:15 | |
| *** catonano has quit IRC | 06:43 | |
| *** tristan has joined #buildstream | 07:00 | |
| Kinnison | tristan: Hi! I've been investigating quite an unpleasant performance issue related to large projects and wondered what the best way to open up discussion on it would be | 07:47 |
| Kinnison | tristan: I could post to the ML, or else open an issue on GL. Which would you prefer? | 07:48 |
| *** ChanServ sets mode: +o tristan | 08:10 | |
| tristan | Kinnison, If there is an unpleasant performance issue, should file an issue anyway. If the approach you have in mind to solve it is invasive; propose on mailing list and link to issue. If you want to discuss the issue and get more eyes on it, also mailing list and link to issue | 08:10 |
| tristan | Anyway, issues are issues - we like to avoid filing issues for "tasks" or feature additions in advance of a proposal passing | 08:11 |
| Kinnison | tristan: understood, I'll start by filing the issue then | 08:11 |
| gitlab-br-bot | buildstream: issue #703 ("Queues do too much work during scheduling") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/703 | 08:17 |
| Kinnison | tristan: the brief writeup is at https://gitlab.com/BuildStream/buildstream/issues/703 | 08:18 |
| Kinnison | tristan: I will need to think hard about an amelioration pathway before I can recommend anything on the list | 08:19 |
| Kinnison | tristan: it may make sense to have a short session about it at the gathering first instead | 08:19 |
| Kinnison | tristan: Cooler heads than mine may come up with an elegant solution which is evading me | 08:19 |
| *** rdale has joined #buildstream | 08:28 | |
| tristan | Kinnison, looking at 703, it seems quite fixable; the biggest obstacle being the crazyness of Element._update_state() | 08:30 |
| *** toscalix has joined #buildstream | 08:31 | |
| tristan | Kinnison, I.e. from the first sentences, it seems clear that we are not correctly caching state, and we are redundantly interrogating the disk | 08:31 |
| tristan | Ultimately, this state should not need reinterrogation as it should already be cached on the element in memory | 08:31 |
| Kinnison | tristan: I assumed reinterrogation was performed because other processes might have injected it into the cache in the meantime | 08:32 |
| Kinnison | tristan: regardless, the CPU consumption of calling _update_state() over the entire waiting queue repeatedly seems unnecessary if the actual state changes can be edge-propagated instead | 08:32 |
| Kinnison | tristan: I hope that there's a small fix which can improve matters, but I worry it might end up being quite intricate to cover all the state change cases | 08:33 |
| tristan | Currently, as long as an artifact doesnt exist we will re-interrogate it; that part could be cached and propagated indeed, but sometimes we don't yet know what a cache key will be | 08:34 |
| tristan | But as the build moves forward, once an artifact exists, it should no longer need any re-interrogation | 08:34 |
| tristan | And the order in which elements are processed should minimize these interrogations | 08:34 |
| tristan | If we can serialize all this state from subprocesses and compute it entirely in memory in the main process, of course that will be much nicer | 08:35 |
| Kinnison | I think once an artifact exists, it'll pop off the end of the build queue and so not be reinterrogated | 08:35 |
| tristan | But before going that far, I do suspect we are over-interrogating | 08:35 |
| tristan | Kinnison, Whether or not it is on the queue, it will exist in the form of a dependency of another element | 08:36 |
| Kinnison | True | 08:36 |
| Kinnison | If we can cause _update_state() to pop back out early if there's nothing to do, then we wouldn't need to change much else to improve matters | 08:36 |
| Kinnison | it'd probably seriously improve the startup speed too because both Pipeline and Stream end up calling _update_state() in various ways across the loading and prparing stages | 08:37 |
| tristan | The initial _update_state() is necessary, if it's over-working that is a problem surely | 08:37 |
| tristan | I'm skeptical of just how much we can save at startup for that, but at least artifact cache interrogations should be one off and not recursively redundantly doing syscalls | 08:38 |
| tristan | The source cache interrogations are pretty good in this regard afaics | 08:38 |
| tristan | i.e. Source.get_consistency() reports should be no more than needed | 08:39 |
| Kinnison | Mmm, I accept that startup might not be too bad, just running some analyses | 08:40 |
| Kinnison | I think total calls to `.contains()` before the scheduler starts up might be minimal. It seems only 243 of the 13853 calls to it occur outside of `Scheduler.run()` in my test set | 08:42 |
| Kinnison | Though there's an obvious way to halve those if the weak and strong keys are identical | 08:43 |
| Kinnison | If you think it'd be valuable, I could tar up this trace pile and put it somewhere, though frankly there's not many classes of traceback over all :-) | 08:44 |
| tristan | Kinnison, In fact, there is indeed a way to optimize startup in that regard (but it's not our biggest bottleneck) | 08:57 |
| Kinnison | Fair :-) | 08:57 |
| tristan | We should be able to parallelize at least source interrogations | 08:58 |
| tristan | And ultimately the _update_state() stuff too, if we can serialize those results in memory in the main process | 08:58 |
| tristan | just, a bit tricky to do | 08:58 |
| Kinnison | Sounds like a future-optimisation goal. Short-term I'd be grateful if we can find a way to shortcircuit unnecessary `Element._update_state()` calls :-) | 09:01 |
| tristan | We really should be able to at least do it in the task processes :-S | 09:02 |
| Kinnison | The ultimate goal would be that `*Job.status()` don't have to call `Element._update_state()` | 09:03 |
| Kinnison | erm `*Queue.status()` even | 09:04 |
| tristan | Well, something needs to happen around there | 09:05 |
| tristan | But it might be transparent for Queue subclasses | 09:05 |
| tristan | And it would mean mostly, just transmitting the result of update_state() in the sub process to the main process | 09:06 |
| tristan | But, that all needs a real refactor | 09:06 |
| tristan | Different queues add to element state in different ways, and different configurations of elements handle those events differently | 09:06 |
| tristan | I wanted an event based approach to updating state, juergbi made good arguments at the time that handling it all in a central function was simpler in some ways | 09:07 |
| Kinnison | If the element whose job has just completed has _update_state() called in the parent, and then *it* is responsible for propagating that to elements which depend on it, stopping that propagation once an element's external state is unchanged, that'd likely be enough | 09:07 |
| tristan | (i.e. when I say event based: I wanted to tell the element something like: Element._event(ElementEvent.BUILT), etc | 09:08 |
| tristan | ) | 09:08 |
| Kinnison | Yeah that's what I was thinking would be the better solution | 09:08 |
| Kinnison | it's marginally more intricate to implement than the current approach, but would have better potential for doing minimum work on change | 09:09 |
| tristan | Also, splitting up these state transitions into separate code blocks allows us to assert invariants more clearly, I think | 09:11 |
| tristan | I would like to see this organized into classed state transitions; i.e. a "workspaced element" implements a "ready -> built" state transition differently | 09:12 |
| tristan | And strict/non-strict mode also implies different handling | 09:13 |
| Kinnison | I think that would be valuable. Perhaps we could whiteboard it next week? | 09:13 |
| tristan | Looks like we have a lot of things on the menu, but certainly a tentative yes :) | 09:13 |
| Kinnison | :-) | 09:13 |
| Kinnison | At least it's now recorded and in your head as a performance issue rather than a "just" an "It'd be nicer if..." | 09:14 |
| *** jonathanmaw has joined #buildstream | 09:14 | |
| tristan | Kinnison, heh, not me you have to convince about that | 09:14 |
| tristan | If I could allocate people's time, I would concentrate on the "it'd be nicer if" architectural issues; and presume that performance benefits will be a natural result of good refactoring :) | 09:15 |
| Kinnison | heh | 09:15 |
| gitlab-br-bot | buildstream: merge request (richardmaw/distinguish-sandboxing-build-fail->master: WIP: Distinguish between bubblewrap sandboxing failure and command failure) #868 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/868 | 09:17 |
| *** bochecha has joined #buildstream | 09:19 | |
| *** mohan43u has quit IRC | 09:20 | |
| Kinnison | If I wrote up a neater traceback capturing system as an MR, so that it could easily be inserted into things to do debugging, would that be welcomed, or rejected? (I can see good reasons for the latter, so don't worry that I'd be offended if you say 'rejected') | 09:21 |
| *** mohan43u has joined #buildstream | 09:23 | |
| tristan | Kinnison, There are a few things I want to do to improve debugging, I'm not sure exactly what you mean by traceback capturing system and how it would be enabled and what it would do | 09:31 |
| tristan | Kinnison, One thing I found myself doing recently, is inserting traceback call trace prints where messages are issued | 09:32 |
| Kinnison | tristan: basically a tidied up form of what I did for that issue | 09:32 |
| tristan | One thing I want, is to add debugging "domains" for MessageType.DEBUG, and add a way for the --debug CLI option to specify which domains to trace | 09:33 |
| tristan | And automate selection of plugins in general for debugging | 09:33 |
| tristan | For instance... bst --debug "artifacts:element(compose):sandbox" | 09:34 |
| tristan | or bst --debug "all" | 09:34 |
| tiagogomes | Same style as gstreamer would be powerful :) | 09:34 |
| tristan | Something like that yeah | 09:34 |
| toscalix | I have sent material for two of the discussion topics we will have during the Gathering so we can advance the feedback offline | 09:47 |
| toscalix | jjardon: I know you are a busy man but I really need your points on the Proposal Topics table for the Gathering today | 09:49 |
| toscalix | adds68: ^^ maybe you can do it if jjardon can't? I would like to to finish the agenda draft today | 09:53 |
| jjardon | toscalix: I will | 09:53 |
| toscalix | jjardon: thanks | 09:53 |
| jjardon | toscalix: points fdsk wants to talk about are already there | 10:03 |
| jjardon | wait I will add another | 10:03 |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 10:11 |
| coldtom | jonathanmaw, what release number will bst-external be at with the addition of the git-tag plugin? | 10:15 |
| jonathanmaw | coldtom: I'd bump the version of bst-external to 0.6 | 10:16 |
| *** abderrahim[m] has quit IRC | 10:16 | |
| *** pro[m] has quit IRC | 10:16 | |
| *** oknf[m] has quit IRC | 10:16 | |
| *** ssssam[m] has quit IRC | 10:16 | |
| *** theawless[m] has quit IRC | 10:16 | |
| *** inigomartinez has quit IRC | 10:16 | |
| *** awacheux[m] has quit IRC | 10:16 | |
| *** mattiasb has quit IRC | 10:17 | |
| *** asingh_[m] has quit IRC | 10:17 | |
| *** segfault3[m] has quit IRC | 10:17 | |
| *** tlater[m] has quit IRC | 10:17 | |
| *** mohan43u has quit IRC | 10:17 | |
| coldtom | as i thought, thanks! | 10:18 |
| *** mohan43u has joined #buildstream | 10:21 | |
| *** abderrahim[m] has joined #buildstream | 10:24 | |
| jonathanmaw | coldtom: ah, I think there's been a misunderstanding. I meant to add the note under the "next version" heading, and I'd add the "bst-external 0.6" heading when I release the next version | 10:25 |
| *** pro[m] has joined #buildstream | 10:25 | |
| jonathanmaw | it's harmless, though, so I'll merge it when CI finishes | 10:25 |
| *** oknf[m] has joined #buildstream | 10:34 | |
| *** ssssam[m] has joined #buildstream | 10:40 | |
| jjardon | jonathanmaw: apart frrom the governance matter in bst-external, there is another technical conversation but that is already happening at https://gitlab.com/BuildStream/buildstream/issues/697 | 10:42 |
| jjardon | we can touch that with tristan and thomas at any point in the gathering | 10:43 |
| *** theawless[m] has joined #buildstream | 10:44 | |
| *** inigomartinez has joined #buildstream | 10:45 | |
| *** abderrahim has quit IRC | 10:52 | |
| *** abderrahim has joined #buildstream | 10:52 | |
| toscalix | jjardon: mention it during the topic and make sure you schedule a slot during the hacking sessions so we keep track of it during the retrospective. Some people is going to be very busy that week. You will need to schedule in advance | 10:54 |
| *** slaf_ has joined #buildstream | 10:58 | |
| *** slaf has quit IRC | 11:00 | |
| *** slaf_ is now known as slaf | 11:00 | |
| *** awacheux[m] has joined #buildstream | 11:09 | |
| jjardon | toscalix: done; I have called "Extending plugins" | 11:13 |
| toscalix | jjardon: is this a different topic discussion that the one already scheduled or can we merge them? | 11:19 |
| toscalix | jjardon: this is the scheduled session https://calendar.google.com/event?action=TEMPLATE&tmeid=NTA1ODRrdm1hZDRyaDRsbGtrdWV2dDUyYWkgY29kZXRoaW5rLmNvLnVrX21wZ2FoMHVqNTM4aG5ic2Y0bDdiNHJjaHRzQGc&tmsrc=codethink.co.uk_mpgah0uj538hnbsf4l7b4rchts%40group.calendar.google.com | 11:19 |
| toscalix | ah, forgot to add you to the participants so you receive a mail | 11:21 |
| *** mattiasb has joined #buildstream | 11:21 | |
| *** asingh_[m] has joined #buildstream | 11:30 | |
| jjardon | toscalix: different, but they can go together | 11:42 |
| toscalix | ok | 11:43 |
| *** segfault3[m] has joined #buildstream | 12:01 | |
| *** tlater[m] has joined #buildstream | 12:08 | |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 12:16 |
| toscalix | sent by mail the instruction to register to the training sessions | 12:22 |
| * tristan thinks we should move all of _ostree.py into plugins/sources/ostree.py, now that we don't use it anywhere else | 12:22 | |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 12:41 |
| *** cs-shadow has joined #buildstream | 13:00 | |
| cs-shadow | tristan: hey! Quick question - did https://gitlab.com/BuildStream/buildstream/merge_requests/819#note_105468622 make sense to you or do you still think we should revert it? | 13:01 |
| tristan | cs-shadow, The function is called Element.dependencies(), and Scope defines what is captured, some scopes do include the self element in this "list of dependencies" | 13:07 |
| tristan | Sure the nomanclature is perhaps imperfect, but I don't think changing it is worth all the diffs clouding history there | 13:08 |
| tristan | the nomanclature is not *that* bad anyway | 13:08 |
| cs-shadow | tristan: okay, I can revert that change. Does the rest look good to you? | 13:09 |
| tristan | cs-shadow, I think so, honestly I would love to see the diff without those changes - as I mentioned in the comment: "It is unclear to me what has actually changed in this diff to element.py." | 13:10 |
| cs-shadow | sure, let me do it now | 13:11 |
| tristan | cs-shadow, I would just say yes, but that is a sensitive function | 13:11 |
| cs-shadow | makes sense | 13:11 |
| tristan | Overall it does make sense to me though | 13:11 |
| *** lantw44 has quit IRC | 13:17 | |
| *** lantw44 has joined #buildstream | 13:17 | |
| *** lantw44 has joined #buildstream | 13:17 | |
| gitlab-br-bot | buildstream: merge request (chandan/bst-checkout-build->master: Add `--deps build` option to `bst checkout`) #819 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/819 | 13:20 |
| cs-shadow | tristan: updated ^. Does it look good to you now? I'll update the corresponding 1.2 branch as well if this makes sense to you | 13:26 |
| tristan | I'm looking now :-S | 13:28 |
| cs-shadow | thanks! | 13:29 |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 13:38 |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 13:43 |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 13:47 |
| gitlab-br-bot | buildstream: merge request (chandan/bst-checkout-build->master: Add `--deps build` option to `bst checkout`) #819 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/819 | 13:47 |
| cs-shadow | tristan: and now with better commit messages ^ | 13:47 |
| tristan | sec | 13:47 |
| tristan | still looking | 13:47 |
| cs-shadow | take your time :) | 13:48 |
| tpollard | sorry for the bot spam, trying to debug something that's seemingly only happening in CI :) | 13:52 |
| *** catonano has joined #buildstream | 13:56 | |
| tristan | cs-shadow, I think that's it for the comments | 13:57 |
| tristan | you have 3 | 13:57 |
| toscalix | you can always mirror the repo/branch and copy the CI config in your own gitlab account | 13:57 |
| toscalix | so tpollard you can do all the tests you want | 13:57 |
| toscalix | and config the notifications to your own account | 13:58 |
| cs-shadow | tristan: thanks! I'll finish it up later today. | 13:58 |
| tristan | tpollard, we don't mind the spam from the gitlab bot, don't bend over backwards :) | 13:58 |
| tristan | Even, if you want to avoid spam, you can always create a branch that is *not* associated with a merge request | 13:59 |
| tristan | Actually, people love to create merge requests prematurely, and I don't really understand why | 13:59 |
| tpollard | Are the runners for the buildstream.git beefier ones though? | 14:00 |
| tpollard | i.e if I fork will I get the free ones, as the integration tests can take a while | 14:00 |
| tpollard | tristan: that's just the process I've been told to follow :) | 14:01 |
| tristan | tpollard, It's alright, I don't really mind the spam, I will just occasionally criticize the early creation of merge requests :) | 14:04 |
| tristan | yeah, if you use a separate repo, (A) you will have all the headache of setting up CI yourself... (B) You will have all the hassle of keeping your master branch in sync with upstream master and rebasing will be really annoying (C) We will not be able to press a "Rebase" button on merge requests you submit from that repo | 14:05 |
| tristan | tpollard, So we recommend people just ask for developer access to avoid all of that hassle | 14:05 |
| tristan | And yeah, I don't think you have permission to use our runners, either | 14:06 |
| tristan | Which means CI will not have cached sources, and will take > 1hrs to complete every run | 14:06 |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 14:16 |
| gitlab-br-bot | buildstream: merge request (willsalmon/outOfSourecBuild->master: Out of source builds) #776 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/776 | 14:21 |
| laurence | skullman, wrt to the patch in upstream bwrap - https://github.com/projectatomic/bubblewrap/pull/293 | 14:28 |
| laurence | ooi, what do they mean by 'bot, add author to whitelist'? | 14:29 |
| Kinnison | It's an instruction to their CI/Review bot | 14:29 |
| skullman | laurence: I'm guessing they only want to run good faith patches through CI | 14:29 |
| laurence | skullman, right, i see | 14:30 |
| laurence | Kinnison, I knew that bit :) | 14:30 |
| laurence | will v soon time to be pushing those bwrap folks for some attention | 14:35 |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 14:36 |
| *** tristan has quit IRC | 14:40 | |
| gitlab-br-bot | buildstream: merge request (jonathan/debug-remote-failed-builds->master: Jonathan/debug remote failed builds) #869 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/869 | 14:44 |
| *** tristan has joined #buildstream | 15:02 | |
| *** ChanServ sets mode: +o tristan | 15:03 | |
| jonathanmaw | skullman: iirc you did some research into creating anonymous directories. Would they work in python? | 15:06 |
| skullman | jonathanmaw: what exactly do you mean by an anonymous directory? | 15:07 |
| jonathanmaw | skullman: I've hit the thorny issue of needing a "scratch" directory that's on the same filesystem as the directory I want to use as a sysroot for `bst shell`. Since it needs to be the same filesystem, I can't just use a tmpfs | 15:08 |
| jonathanmaw | and I can't think of a good place to put it on the filesystem (can't put it in the sysroot directory, putting it in the directory above the sysroot will make it vulnerable to being messed with) | 15:09 |
| skullman | if you're after something O_TMPFILE like but a directory you'll be disappointed no matter what language you use, the closest you get is that a process can have its root and current directory be a directory that is unlinked, but you can't create new files in it | 15:09 |
| jonathanmaw | :-/ | 15:09 |
| skullman | if you had the right privileges there's theoretically something you could do with a loopback mount or fuse, but that wouldn't count as being on the same filesystem | 15:09 |
| skullman | on btrfs or a new enough XFS you could theoretically do zero-copy from your fuse filesystem to the destination, but that only helps with the data, not the metadata, and would be a huge amount of work | 15:11 |
| tristan | jonathanmaw, one way to look at this, is that the "scratch" directory is basically used by our fuse layer, and as such is important for copy-on-write hardlinks when running builds | 15:13 |
| tristan | jonathanmaw, so, if we have "given" the user a sysroot in some way, like via a checkout, it's questionable whether we need to do the fuse stuff at all in that case | 15:14 |
| tristan | because the user has "received" the directory, they should not have received a directory full of files hardlinked into the artifact cache, compromising the artifact cache | 15:14 |
| tristan | If they use `bst checkout --hardlinks`, which has a big fat warning in the help, they are shelling into it at their own risk | 15:15 |
| *** catonano has quit IRC | 15:49 | |
| flatmush | Is it possible to build multiple elements from the same git repository? | 16:16 |
| Kinnison | I don't think there's any issue with multiple elements having the same source | 16:17 |
| Kinnison | If, on the other hand, you mean that you have one source building multiple things and then you want to use them independently, you should look at filter elements IIRC | 16:17 |
| Kinnison | i.e. have an element build everything, and then have filter elements which split up the result | 16:17 |
| *** jonathanmaw has quit IRC | 16:38 | |
| *** toscalix has quit IRC | 17:19 | |
| gitlab-br-bot | buildstream: merge request (patch-2->master: README: Update to add link to website) #859 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/859 | 17:48 |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 17:48 |
| gitlab-br-bot | buildstream: merge request (patch-2->master: README: Update to add link to website) #859 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/859 | 17:50 |
| *** asingh_[m] has quit IRC | 18:08 | |
| *** ssssam[m] has quit IRC | 18:08 | |
| *** asingh_[m] has joined #buildstream | 18:08 | |
| *** ssssam[m] has joined #buildstream | 18:08 | |
| *** xjuan has joined #buildstream | 18:30 | |
| *** catonano has joined #buildstream | 18:33 | |
| *** rdale has quit IRC | 19:03 | |
| gitlab-br-bot | buildstream: merge request (patch-2->master: README: Update to add link to website) #859 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/859 | 19:24 |
| *** finn has joined #buildstream | 19:28 | |
| *** finn has quit IRC | 20:23 | |
| *** tristan has quit IRC | 21:19 | |
| *** cs-shadow has quit IRC | 21:20 | |
| *** catonano has quit IRC | 21:44 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!