| *** kapip has joined #buildstream | 03:35 | |
| *** toscalix has joined #buildstream | 07:17 | |
| *** bochecha has joined #buildstream | 07:28 | |
| laurence | Gitlab 12.1 released | 07:50 |
|---|---|---|
| laurence | https://about.gitlab.com/2019/07/22/gitlab-12-1-released/ | 07:50 |
| laurence | Parallel MERGE TRAINS | 07:50 |
| laurence | Just trying to figure out if Gitlab now automatically comes with merge trains or we need to set something up in the same way we did with marge | 07:53 |
| *** kapip has quit IRC | 07:54 | |
| *** alexandrufazakas has joined #buildstream | 07:57 | |
| *** alexandrufazakas has quit IRC | 08:00 | |
| laurence | alexandrufazakas, morning :) | 08:01 |
| laurence | are you familiar with the marge bot that we have in place on the project? | 08:01 |
| laurence | that was basically a 'work-around' that someone implemented to solve the issue of having a large and active development team, where many merge requests would be submitted at once | 08:02 |
| laurence | and the problem was that by the time your branch passed CI and was about to merge, another branch finished earlier and merged before you, meaning you'd have to go back and start again | 08:02 |
| laurence | marge bot solved it with a queuing system | 08:03 |
| laurence | But it was unofficial, we had to set up a bot as a new Gitlab user (Marge) on a VM etc etc | 08:03 |
| laurence | So now Gitlab have introduced Merge Trains, it would be nice to utilise that instead, and then we can pull marge bot down | 08:04 |
| *** alexandrufazakas has joined #buildstream | 08:17 | |
| *** traveltissues has joined #buildstream | 08:20 | |
| gitlab-br-bot | traveltissues opened issue #1088 (Do not force reset workspace cache data) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1088 | 08:31 |
| benschubert | laurence: I saw that, the feature seems really nice :D | 08:36 |
| benschubert | and parallel testing with the result of all branches | 08:37 |
| benschubert | traveltissues: I believe you benchmarked #1088, correct? do you have the numbers by any chance? :) | 08:38 |
| laurence | benschubert, yeah, definitely worth upgrading to :) | 08:38 |
| laurence | thanks to jjardon who pointed it out to me | 08:38 |
| traveltissues | i did not, i'll update that | 08:48 |
| benschubert | traveltissues: oh I thought you had, sorry about that | 08:50 |
| traveltissues | i haven't managed to run benchmarking yet | 08:51 |
| benschubert | problems with the script? | 08:51 |
| alexandrufazakas | laurence: I read everything about the merge trains and I get the idea. Is there you wanted me to do regarding these or just know the new workflow? | 08:51 |
| alexandrufazakas | s/there you/there something you/ rather | 08:52 |
| laurence | alexandrufazakas, I think we definitely want to start using the merge trains | 08:53 |
| laurence | not sure exactly what that migration would look like | 08:53 |
| traveltissues | benschubert, i didn't have time to run that last night but yes, i had one so far | 08:53 |
| laurence | I think it just means amending some settings and testing it...then if all goes well we can email the list and announce how cool they are, then we deprecate marge-bot | 08:53 |
| traveltissues | sent an mr | 08:53 |
| laurence | (which is an email to Codethink Operations team and they have donated computing power for it) | 08:54 |
| benschubert | oh thanks traveltissues ! | 08:55 |
| tpollard | ooo Merge Trains | 09:07 |
| *** jonathanmaw has joined #buildstream | 09:25 | |
| *** lachlan has joined #buildstream | 09:28 | |
| tpollard | has anyone had issues with the cache expiry tests recently? | 09:55 |
| benschubert | tpollard: I have one that fails intermitently, what's the one that's failing for you? | 09:56 |
| tpollard | currently have 4, but I have made some changes. Just wondered if there was a underlying issue somewhere | 09:57 |
| benschubert | 4 seems a lot, I usually get always the same one failing | 09:58 |
| *** lachlan has quit IRC | 09:59 | |
| tpollard | yep I'll keep digging for now | 10:00 |
| tpollard | :) | 10:00 |
| *** lachlan has joined #buildstream | 10:07 | |
| alexandrufazakas | Why do we lint only on master changes? | 10:11 |
| alexandrufazakas | in .gitlab-ci.yml, that is | 10:12 |
| Kinnison | we lint on MRs too | 10:22 |
| *** phoenix has joined #buildstream | 10:23 | |
| alexandrufazakas | Kinnison: you're right. I must've read it wrong | 10:23 |
| * alexandrufazakas sighs | 10:24 | |
| alexandrufazakas | So I've implemented merge trains on a smaller project I used to fetch and publish bst documentation and everything works fine as far as I've tested it. I'm trying to make it work on my bst fork to make sure nothing blows up when implementing it on the actual repo | 10:26 |
| alexandrufazakas | And the changes seem to be fairly minimal | 10:26 |
| *** phoenix has quit IRC | 10:33 | |
| *** phoenix has joined #buildstream | 10:42 | |
| *** phoenix has quit IRC | 10:44 | |
| alexandrufazakas | Okay, I'm not sure I can test my implementation regarding merge trains as I don't have the same runners as the bst repo and I'm not sure if I can set them up easily. I believe it should just be setting these jobs run on merge_requests https://pastebin.com/2sgTDLnQ and changing that setting mentioned in the Gitlab documentatoin. Am I missing anything? | 11:00 |
| alexandrufazakas | A second opinion from anyone good with gitlab CI would be great as I'm not well versed in it or anything :D | 11:01 |
| traveltissues | not related but btw gitlab has gists | 11:01 |
| alexandrufazakas | traveltissues: good point, I'll use that instead of pastebin next time :P | 11:02 |
| alexandrufazakas | thank you | 11:02 |
| laurence | alexandrufazakas - jjardon knows gitlab CI very well | 11:03 |
| laurence | jjardon, are you able to have a wuick look? | 11:03 |
| laurence | q | 11:03 |
| laurence | quick * | 11:03 |
| alexandrufazakas | Awesome. thanks laurence | 11:03 |
| jjardon | alexandrufazakas: I think that's everything you need; if you have developer access, you can create a branch directly from the buildstream repo | 11:10 |
| alexandrufazakas | jjardon: Thanks for having a look. Do you mean creating a branch in order to open an MR on it and push the changes? | 11:12 |
| jjardon | yes | 11:12 |
| alexandrufazakas | Oh, yeah, I do have that | 11:12 |
| alexandrufazakas | I was wondering if you'd have any idea how I could test these, however | 11:12 |
| alexandrufazakas | Or, if it looks alright with you, I can try to set it up and see how everything goes | 11:13 |
| alexandrufazakas | jjardon ^ | 11:13 |
| jjardon | check you can see the "Start/Add to merge train" on that MR | 11:13 |
| jjardon | See https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/ | 11:13 |
| alexandrufazakas | jjardon: Oh, I assumed that would become effective *after* merging that particular MR | 11:14 |
| jjardon | mmm, you might be right. you migth create a fork of the project on your namespaces and use the gitlab runners instead ours? | 11:15 |
| alexandrufazakas | jjardon: That's what I wanted to do at first, but I need specific runners | 11:15 |
| alexandrufazakas | Such as the windows ones | 11:15 |
| jjardon | alexandrufazakas: remove that job for the test | 11:15 |
| alexandrufazakas | ...or I could skip those jobs | 11:15 |
| alexandrufazakas | Alright | 11:15 |
| alexandrufazakas | I'll try doing that | 11:15 |
| alexandrufazakas | jjardon: thanks for the help | 11:15 |
| jjardon | the linux runners are notthing special, as fas as I know. Only faster than using the gitlab.com free ones | 11:16 |
| juergbi | valentind, jjardon: bst-artifact-server uses 'headroom' to determine how much to expire while bst uses a quota. do you remember the reason for this difference? | 11:44 |
| juergbi | was it only because we didn't have efficient disk usage tracking and due to this we went for the efficient 'free space' approach? | 11:44 |
| valentind | To avoid every push to be slow. | 11:44 |
| juergbi | buildbox-casd precisely tracks used disk space without significant overhead | 11:45 |
| juergbi | so I'm wondering whether we'd all be ok in switching the server to be quota based as well | 11:45 |
| valentind | Because we look for objects and sort them, making sure we clean-up a bit more than required makes sure that we do not do that again. | 11:46 |
| valentind | The listing and sorting of object I think is the slow part. | 11:47 |
| juergbi | yes, that approach will pretty much remain the same | 11:47 |
| juergbi | the only difference would be whether the two levels are based on free disk space (headroom) or based on disk usage (quota) | 11:47 |
| juergbi | I think quota is nicer from a configuration perspective as the concept also works if you run multiple servers on the same partition (could be different kinds of servers, not necessarily multiple artifact servers) | 11:49 |
| valentind | Ah right. | 11:49 |
| valentind | I mixed up. | 11:49 |
| valentind | Yes headroom is the quota. | 11:49 |
| valentind | Note that some servers share disk space with other things. For example for us we have a local cache server on each builder. And we have a bigger free space there. And if some other things start using more space then at some point we will clean more. | 11:50 |
| juergbi | ok but wouldn't it make more sense that each thing has its own quota? | 11:51 |
| juergbi | otherwise the distribution of used disk space among these different things would be kind of random | 11:51 |
| juergbi | (if each of those used the same 'free space' based approach) | 11:52 |
| juergbi | (it kinda works if only one uses that approach, I suppose, but it's still somewhat odd) | 11:52 |
| valentind | I think it is fine if you remove this in the new version. We can adapt. But there are some cases where it is fine. | 11:53 |
| valentind | And for us it was nice because we do not know how many docker machines will run and how much space is taken. | 11:54 |
| valentind | So taking more space for cache when there are less builds was nice. | 11:54 |
| valentind | Of course if you have several services that do the same, take as much as space as they can, then you can run into troubles. | 11:54 |
| valentind | But it is rare unless it is a cache. | 11:54 |
| juergbi | ok. it would probably not really be difficult to re-add support for it but it would also require an addition on the buildbox-casd side, and if we can do without, I'd rather leave it | 11:56 |
| juergbi | if it turns out to be needed after all, we can revisit | 11:56 |
| *** lachlan has quit IRC | 12:02 | |
| *** brlogger has joined #buildstream | 12:27 | |
| *** phoenix has joined #buildstream | 12:41 | |
| gitlab-br-bot | AlexFazakas opened MR !1494 (alexfazakas/test-merge-trains_2->master: Alexfazakas/test merge trains 2) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1494 | 12:50 |
| gitlab-br-bot | AlexFazakas closed MR !1494 (alexfazakas/test-merge-trains_2->master: Alexfazakas/test merge trains 2) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1494 | 12:50 |
| gitlab-br-bot | AlexFazakas opened MR !1495 (alexfazakas/test-merge-trains_2->master: Alexfazakas/test merge trains 2) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1495 | 12:51 |
| gitlab-br-bot | AlexFazakas closed MR !1495 (alexfazakas/test-merge-trains_2->master: Alexfazakas/test merge trains 2) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1495 | 12:52 |
| alexandrufazakas | Ugh, sorry about the spam everyone, I meant to open an MR on my fork :/ | 12:52 |
| gitlab-br-bot | AlexFazakas opened MR !1496 (alexfazakas/use-merge-trains->master: Use Gitlab merge trains) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1496 | 13:04 |
| alexandrufazakas | So I've just checked `Merge pipelines will try to validate the post-merge result prior to merging` on the buildstream repository. once !1496 lands, we should be able to use Gitlab's merge train, I believe | 13:05 |
| alexandrufazakas | Actually | 13:10 |
| alexandrufazakas | I should probably uncheck that, merge that request | 13:10 |
| alexandrufazakas | And then turn it back on | 13:10 |
| alexandrufazakas | Since it looks like I *have to* start a merge train in order to merge !1496, which contains the .yml changes the merge train *needs* in order to work. Awesome. | 13:11 |
| alexandrufazakas | Not sure if owners or maintainers get emails/notifications regarding these changes. Sorry if that's the case. | 13:12 |
| alexandrufazakas | jjardon: If you could have a look at https://gitlab.com/BuildStream/buildstream/merge_requests/1496 just to make sure I'm messing anything up, I'd appreciate it. Also 2 jobs failed due to `docker daemon not running`. Should I just rerun them? | 13:15 |
| alexandrufazakas | not messing anything up, even | 13:15 |
| benschubert | alexandrufazakas: restarting jobs is fine in that case, some of our runners tend to have such problems | 13:16 |
| alexandrufazakas | benschubert: Oh, okay. Thank you :) | 13:17 |
| traveltissues | i'm not sure linting needs to happen except on merge_requests if we're using the train though | 13:18 |
| gitlab-br-bot | traveltissues approved MR !1496 (alexfazakas/use-merge-trains->master: Use Gitlab merge trains) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1496 | 13:18 |
| benschubert | but why would we not want tests on branches that are not part of MRs? | 13:18 |
| benschubert | like, how do we test code _before_ adding a MR? | 13:18 |
| traveltissues | i thought the philosophy people wanted for this was that everything would be mr | 13:19 |
| benschubert | We already have dozens of them rotting away, I'm not sure forcing people to open one to test a change is a wise thing to do | 13:20 |
| traveltissues | it's a fair point | 13:20 |
| *** phoenix has quit IRC | 13:20 | |
| traveltissues | and i agree | 13:20 |
| alexandrufazakas | traveltissues, benschubert: Yes, that's what I thought we'd have as well. If you wanted to test something, open an MR on it | 13:21 |
| traveltissues | although there is still some amount of local testing | 13:21 |
| laurence | we never had a strong policy on MRs in this regard....people started using WIP MRs because they offer a nice way to review work | 13:21 |
| alexandrufazakas | traveltissues: thanks for approving that | 13:21 |
| laurence | but yeah we have a lot of stale ones | 13:22 |
| laurence | which i try to police every now and then | 13:22 |
| benschubert | traveltissues: running integration tests on my system is extremely taxing, with proxies problems + having to run them in docker through windows and roughly takes 2.5 hours to complete | 13:22 |
| laurence | but i think we certainly want local testing of your branch, prior to an MR | 13:22 |
| traveltissues | yes, proxywoes | 13:22 |
| traveltissues | i forgot | 13:22 |
| laurence | or, maybe not local, but pre-MR for sure | 13:23 |
| benschubert | laurence: exactly my point, we should have tests on branches :) | 13:25 |
| laurence | benschubert, yes, i will comment on the ticket now | 13:25 |
| gitlab-br-bot | traveltissues unapproved MR !1496 (alexfazakas/use-merge-trains->master: Use Gitlab merge trains) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1496 | 13:26 |
| traveltissues | how about only: branches except: master | 13:27 |
| alexandrufazakas | benschubert, laurence: Yeah, makes sense. So we *always* want to run tests, right? | 13:27 |
| benschubert | traveltissues: why except master? (I don't particularily mind, even though I'd like to have master always green :) ) | 13:28 |
| traveltissues | if the mrs are in the train then is there any purpose to rerunning the same tests on master as they land? | 13:30 |
| traveltissues | (except overnight/master specific things ofc) | 13:31 |
| benschubert | fair point, then except master seems fine | 13:32 |
| laurence | MRs should always run the pipeline, but I think if we say 'hey developer, you can't run any tests until you create an MR' then that breaks people's current workflows | 13:32 |
| SotK | can people still push straight to master? | 13:33 |
| alexandrufazakas | I updated the MR as per traveltissues' suggestion for now, running tests for anything other than master | 13:34 |
| alexandrufazakas | Oh, I messed up the syntax | 13:35 |
| alexandrufazakas | thank you traveltissues | 13:35 |
| benschubert | SotK: I don't think that was ever possible here? At least not now | 13:37 |
| SotK | ah I'm probably misremembering then, I thought here was the place where some people had enough permission to do so for quickly applying small fixes | 13:40 |
| traveltissues | np | 13:41 |
| traveltissues | i'd hope only marge could | 13:41 |
| *** lachlan has joined #buildstream | 13:42 | |
| alexandrufazakas | traveltissues: um, not sure I understand these last discussions and the `apply suggestion` option doesn't help. Do you want me to replace `merge_requetsts` with `branches` everywhere? | 13:45 |
| *** traveltissues has quit IRC | 13:57 | |
| alexandrufazakas | Okay, so we just run everything for *any* branch now. Excepts for tests, which do not run on master. Does that make sense? | 13:58 |
| *** traveltissues has joined #buildstream | 13:58 | |
| benschubert | what's the "only: branch" ? Why? | 13:59 |
| alexandrufazakas | benschubert: Isn't that what traveltissues suggested on the MR? | 14:01 |
| benschubert | I'm just not sure what this brings? | 14:01 |
| alexandrufazakas | And isn't that what you described earlier when you wanted to run tests without opening a MR? | 14:01 |
| benschubert | Yes, but we already have this behavior | 14:01 |
| benschubert | so I would have expected 'expect:master' only for the tests | 14:01 |
| alexandrufazakas | Being the only change? | 14:02 |
| traveltissues | it's not technically equivalent aiui | 14:02 |
| benschubert | traveltissues: ah? | 14:02 |
| traveltissues | only: \ - branches is not the default i think | 14:03 |
| traveltissues | which is why i thought only: \ - branches \ except: \ - master was more explicitly what was wanted | 14:03 |
| traveltissues | for everything except the overnight and the master specific wsl | 14:04 |
| alexandrufazakas | https://gitlab.com/gitlab-org/gitlab-ce/commit/d85e04e45247a64c704a44a2c8abecba94972061 | 14:04 |
| benschubert | I'm just not sure why we want to clutter the gitlab.yml for something that would not change anything? I mean, it would stop doing for 'tag', but apart from that | 14:04 |
| alexandrufazakas | Apparently default is only : \ - branches \ - tags? | 14:04 |
| traveltissues | i don't agree that it's clutter but i don't think it matters too much. in that case sure, just the except | 14:05 |
| alexandrufazakas | If that's the only change needed, I think we can already start using merge trains, right? it's just that some tests will be run twice until this MR is accepted | 14:36 |
| *** lachlan has quit IRC | 14:38 | |
| alexandrufazakas | Would it be okay with everyone if I enabled them? | 14:44 |
| alexandrufazakas | benschubert, traveltissues? | 14:44 |
| laurence | I think now could be a good time for a mailing list post, alexandrufazakas | 14:45 |
| laurence | Please outline the changes made, and any changes to the developer workflow | 14:45 |
| gitlab-br-bot | traveltissues approved MR !1496 (alexfazakas/use-merge-trains->master: Use Gitlab merge trains) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1496 | 14:46 |
| laurence | We can say that we have enabled this already since there was a broad consensus on irc, if any issues arise we can address them quickly, etc etc | 14:46 |
| laurence | assuming we do know how to revert things with no adverse impact ? | 14:47 |
| traveltissues | ah, i forgot, coverage will fail | 14:47 |
| alexandrufazakas | laurence: Sure, I'll do that in a second | 14:47 |
| alexandrufazakas | Okay, well, I'll enable `Merge pipelines will try to validate the post-merge result prior to merging` for now if it's alright | 14:48 |
| alexandrufazakas | And let everyone on the mailing list know | 14:48 |
| alexandrufazakas | marge bot isn't assigned to any MR right now | 14:49 |
| alexandrufazakas | So that's good | 14:49 |
| alexandrufazakas | I'll start a merge train with my MR | 14:49 |
| alexandrufazakas | laurence: Btw, you should probably downgrade my access back to developer now | 14:49 |
| *** lachlan has joined #buildstream | 14:51 | |
| laurence | alexandrufazakas, ok, done | 14:52 |
| alexandrufazakas | Thanks | 14:52 |
| benschubert | traveltissues: coverage will fail? | 15:08 |
| laurence | alexandrufazakas, nice work! all aboard the merge train! | 15:11 |
| laurence | sorry, someone had to say it | 15:11 |
| alexandrufazakas | haha thanks laurence | 15:11 |
| alexandrufazakas | Ergh, code_quality and remote-execution keep failing as there's no docker daemon :( | 15:12 |
| alexandrufazakas | benschubert: I think coverage is going to fail as it depends on remote-execution | 15:12 |
| *** lachlan has quit IRC | 15:13 | |
| alexandrufazakas | benschubert: traveltissues was saying it would fail as the other tests did not run earlier, so there was nobody to create ./coverage-reports which the coverage job is looking for | 15:14 |
| *** lachlan has joined #buildstream | 15:15 | |
| benschubert | then, we still need the tests on master, or add the other one on merges, or what is the plan? | 15:15 |
| alexandrufazakas | benschubert: Hmm, I think you are right. If these don't run on master as well coverage will always fail there | 15:17 |
| traveltissues | i suggested just except: master for coverage | 15:23 |
| traveltissues | benschubert, i have the benchmark for #1088 in the description | 15:24 |
| gitlab-br-bot | Issue #1088: Do not force reset workspace cache data https://gitlab.com/BuildStream/buildstream/issues/1088 | 15:24 |
| alexandrufazakas | benschubert: I was just telling traveltissues as well, is there a reason why we'd want anything other than the overnight tests on master? | 15:26 |
| alexandrufazakas | s/telling/asking | 15:26 |
| alexandrufazakas | I guess an argument could be made for people pushing changes straight to master, but then again, you wouldn't push something that needs testing I'd assume? | 15:27 |
| benschubert | alexandrufazakas: I don't think _anyone_ has the rights to push to master, and this is not an acceptable workflow as per our contributing guide. | 15:28 |
| benschubert | I think having coverage reporting on master is still important (the badges on the README), so we do need some tests there | 15:28 |
| benschubert | traveltissues: cheers! master being the bad branch, correct? | 15:28 |
| benschubert | and the other one, the one before the modifications | 15:29 |
| traveltissues | yes, after i reverted one of the changes | 15:29 |
| traveltissues | the benchmark branch is prior to that | 15:29 |
| benschubert | ok! | 15:29 |
| benschubert | Gah, that's a pretty bad regression | 15:29 |
| alexandrufazakas | benschubert: you're right about the badges. thanks for pointing that out | 15:29 |
| traveltissues | normal config was taking too long on my machine | 15:29 |
| alexandrufazakas | Given the current state of things, I'll try to implement merge trains on my fork *without* changing the CI at all and see if everything works out fine | 15:46 |
| traveltissues | btw, this might be relevant | 15:50 |
| traveltissues | https://gitlab.com/gitlab-org/gitlab-ce/issues/58226 | 15:50 |
| alexandrufazakas | I'll have a look at that | 15:52 |
| benschubert | seems like we will need to wait for this :/ | 15:52 |
| traveltissues | it looks that way | 15:52 |
| gitlab-br-bot | traveltissues unapproved MR !1496 (alexfazakas/use-merge-trains->master: Use Gitlab merge trains) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1496 | 15:53 |
| *** phoenix has joined #buildstream | 15:58 | |
| *** tristan has quit IRC | 16:05 | |
| *** bochecha has quit IRC | 16:09 | |
| alexandrufazakas | Seeing as we'll postpone !1496 for now, can one of the maintainers/owners disable the pipeling for merged results settings in the bst repo so nobody tries to use merge trains for now? | 16:11 |
| alexandrufazakas | Do we need to send out another email as we're not implementing it rn, laurence? | 16:12 |
| alexandrufazakas | s/pipeling/pipelining | 16:14 |
| * laurence reads backscroll | 16:18 | |
| laurence | so we can't use merge trains? | 16:18 |
| alexandrufazakas | laurence: I believe we can but it's still not perfect and there's more to discuss as to how we'd to it, from my understanding | 16:19 |
| laurence | damn, and we figured this out just after sending a mail | 16:20 |
| *** traveltissues has quit IRC | 16:20 | |
| *** lachlan has quit IRC | 16:20 | |
| *** alexandrufazakas has quit IRC | 16:20 | |
| *** tpollard has quit IRC | 16:20 | |
| *** rdale has quit IRC | 16:20 | |
| *** tiagogomes has quit IRC | 16:20 | |
| laurence | annoying | 16:20 |
| *** traveltissues has joined #buildstream | 16:21 | |
| *** rdale has joined #buildstream | 16:21 | |
| *** tiagogomes has joined #buildstream | 16:21 | |
| *** tpollard has joined #buildstream | 16:21 | |
| *** alexandrufazakas has joined #buildstream | 16:21 | |
| *** lachlan has joined #buildstream | 16:21 | |
| laurence | alexandrufazakas_, I think we better had, yes - I will do it | 16:21 |
| alexandrufazakas | laurence: Alright. Thanks for that | 16:22 |
| *** alexandrufazakas has quit IRC | 16:22 | |
| *** tristan has joined #buildstream | 16:30 | |
| *** traveltissues has quit IRC | 16:55 | |
| *** rdale has quit IRC | 16:58 | |
| *** rdale has joined #buildstream | 17:00 | |
| *** jonathanmaw has quit IRC | 17:01 | |
| *** bochecha has joined #buildstream | 17:20 | |
| *** lachlan has quit IRC | 17:29 | |
| *** lachlan has joined #buildstream | 17:35 | |
| *** lachlan has quit IRC | 17:36 | |
| *** traveltissues has joined #buildstream | 17:50 | |
| *** traveltissues has quit IRC | 18:10 | |
| *** phoenix has quit IRC | 18:16 | |
| *** toscalix has quit IRC | 19:01 | |
| *** traveltissues has joined #buildstream | 19:28 | |
| *** traveltissues has quit IRC | 19:42 | |
| *** bochecha has quit IRC | 22:52 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!