| *** jswagner has quit IRC | 00:56 | |
| *** nimish2711 has joined #buildstream | 01:21 | |
| *** rdale has quit IRC | 01:22 | |
| *** nimish2711 has quit IRC | 02:06 | |
| *** nimish2711 has joined #buildstream | 02:07 | |
| *** paulsherwood has quit IRC | 02:07 | |
| *** benbrown has quit IRC | 02:07 | |
| *** paulsherwood has joined #buildstream | 02:07 | |
| *** laurence has quit IRC | 02:07 | |
| *** laurence has joined #buildstream | 02:07 | |
| *** nimish2711 has quit IRC | 02:22 | |
| *** nimish2711 has joined #buildstream | 02:48 | |
| *** nimish2711 has quit IRC | 02:53 | |
| *** nimish2711 has joined #buildstream | 02:53 | |
| *** nimish2711 has quit IRC | 03:03 | |
| *** nimish2711 has joined #buildstream | 03:03 | |
| *** nimish2711 has quit IRC | 03:08 | |
| *** nimish2711 has joined #buildstream | 03:09 | |
| *** nimish2711 has quit IRC | 03:29 | |
| *** nimish2711 has joined #buildstream | 03:29 | |
| *** nimish2711 has quit IRC | 03:34 | |
| *** nimish2711 has joined #buildstream | 03:34 | |
| *** nimish2711 has quit IRC | 03:39 | |
| *** nimish2711 has joined #buildstream | 03:40 | |
| *** nimish2711 has quit IRC | 03:55 | |
| *** nimish2711 has joined #buildstream | 03:55 | |
| *** nimish2711 has quit IRC | 04:05 | |
| *** nimish2711 has joined #buildstream | 04:05 | |
| *** nimish2711 has quit IRC | 04:10 | |
| *** nimish2711 has joined #buildstream | 04:11 | |
| *** nimish2711 has quit IRC | 04:21 | |
| *** nimish2711 has joined #buildstream | 04:21 | |
| *** nimish2711 has quit IRC | 04:26 | |
| *** nimish2711 has joined #buildstream | 04:32 | |
| *** nimish2711 has joined #buildstream | 04:32 | |
| *** nimish2711 has quit IRC | 04:36 | |
| *** alatiera has joined #buildstream | 05:26 | |
| *** alatiera has quit IRC | 06:08 | |
| *** alatiera has joined #buildstream | 06:12 | |
| *** bochecha has joined #buildstream | 06:49 | |
| *** toscalix has joined #buildstream | 07:27 | |
| *** toscalix has quit IRC | 07:29 | |
| *** toscalix has joined #buildstream | 07:29 | |
| gitlab-br-bot | jjardon approved MR !1308 (tristan/fdsdk-ci-refresh->master: .gitlab-ci.yml: Updating overnight tests to test ported freedesktop-sdk) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1308 | 07:30 |
|---|---|---|
| *** benbrown has joined #buildstream | 07:34 | |
| bochecha | hi, has anybody ever seen something like this? https://paste.gnome.org/pqoziwlri | 07:58 |
| *** nimish2711 has joined #buildstream | 08:06 | |
| benschubert | bochecha: ouch that seems bad. Do you have something with which we could reproduce it? | 08:08 |
| bochecha | benschubert: not sure, I just installed buildstream and bst-external so I'm wondering whether it's my installation that is missing something | 08:09 |
| bochecha | benschubert: in any case, this is after cloning https://gitlab.com/freedesktop-sdk/freedesktop-sdk/ and checking out the 18.08 branch | 08:09 |
| benschubert | bochecha: I can't have a look in depths right now, but I might be able to have a look tonight if nobody else had a chance. This error shouldn't break anything though, it's in the UI reporting. Seems quite bad though | 08:15 |
| *** nimish2711 has quit IRC | 08:15 | |
| bochecha | yeah, bst track actually did its job fine | 08:16 |
| *** tpollard has joined #buildstream | 08:19 | |
| *** rdale has joined #buildstream | 08:30 | |
| *** nimish2711 has joined #buildstream | 08:31 | |
| *** nimish2711 has quit IRC | 08:51 | |
| *** nimish2711 has joined #buildstream | 08:52 | |
| *** nimish2711 has joined #buildstream | 09:02 | |
| *** nimish2711 has joined #buildstream | 09:03 | |
| *** nimish2711 has joined #buildstream | 09:03 | |
| *** nimish2711 has quit IRC | 09:08 | |
| *** phildawson has joined #buildstream | 09:15 | |
| phildawson | Please could I get a quick review on updating the docker image for bst-experimental: https://gitlab.com/BuildStream/bst-plugins-experimental/merge_requests/6 | 09:17 |
| *** nimish2711 has joined #buildstream | 09:19 | |
| *** nimish2711 has quit IRC | 09:29 | |
| *** nimish2711 has joined #buildstream | 09:29 | |
| *** nimish2711 has quit IRC | 09:34 | |
| *** lachlan has joined #buildstream | 09:35 | |
| *** dtf has joined #buildstream | 09:38 | |
| *** tristan has joined #buildstream | 09:41 | |
| gitlab-br-bot | tristanvb merged MR !1308 (tristan/fdsdk-ci-refresh->master: .gitlab-ci.yml: Updating overnight tests to test ported freedesktop-sdk) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1308 | 09:45 |
| phildawson | Could anyone with merge rights to bst-experimental push the button on https://gitlab.com/BuildStream/bst-plugins-experimental/merge_requests | 09:46 |
| phildawson | Also, who should I ask about getting merge rights myself? | 09:47 |
| *** ChanServ sets mode: +o tristan | 09:48 | |
| tristan | phildawson, Sec, lemme check how that is setup | 09:48 |
| phildawson | :) | 09:49 |
| tristan | merged !6 | 09:50 |
| gitlab-br-bot | MR !6: Expand ~ in paths https://gitlab.com/BuildStream/buildstream/merge_requests/6 | 09:50 |
| phildawson | cheers | 09:50 |
| tristan | phildawson, I guess that will make the mr !5 work, cause of missing gcc in the image | 09:51 |
| gitlab-br-bot | MR !5: Dependency types https://gitlab.com/BuildStream/buildstream/merge_requests/5 | 09:51 |
| tristan | yeah | 09:51 |
| tristan | gitlab-br-bot, wrong repo man... keep up ! ;-) | 09:51 |
| tristan | looks like it was allowing merge without rebase... fixed that | 09:52 |
| phildawson | actually, I think !5 still needs !1307 | 09:52 |
| gitlab-br-bot | MR !1307: Make Integration cache fixture available in testing package https://gitlab.com/BuildStream/buildstream/merge_requests/1307 | 09:52 |
| tristan | Hmmm that is gonna be a bit tricky | 09:53 |
| tristan | It's a fork of bst-external, lets see how that is setup | 09:53 |
| tristan | I think it's like BuildStream | 09:53 |
| *** nimish2711 has joined #buildstream | 09:55 | |
| tristan | phildawson, you should already have rights | 09:55 |
| tristan | the repo settings say for the protected branch "Maintainers" are allowed both to push and merge | 09:55 |
| tristan | and in the little drop down thing, you are listed as a maintainer :-/ | 09:56 |
| tristan | oh no I'm reading it wrong | 09:56 |
| phildawson | hmm, I wonder why I can't merge then :/ | 09:56 |
| tristan | ui changed it seems | 09:56 |
| *** bochecha has quit IRC | 09:56 | |
| phildawson | Ah :) | 09:57 |
| tristan | Ok now should work, what I did is just add you as a maintainer | 09:57 |
| phildawson | Thanks! | 09:57 |
| tristan | not sure it's the end-all strategy, bit different to what we had in BuildStream, but what we have in BuildStream is a bit broken because of marge | 09:57 |
| *** nimish2711 has quit IRC | 10:00 | |
| *** nimish2711 has joined #buildstream | 10:00 | |
| *** nimish2711 has quit IRC | 10:13 | |
| *** lachlan has quit IRC | 10:37 | |
| jennis | tristan, for our cache expiry tests we say that '0' is a valid value | 10:37 |
| tristan | jennis, For headroom | 10:38 |
| jennis | Now, in the test suite, this test passes because our headroom is also zero, however, in reality, we'll get a LoadError | 10:38 |
| jennis | No, for the quota | 10:38 |
| tristan | oh ? | 10:38 |
| jennis | Are we saying that quota: 0, in userconf is essnetially 'infinity'? | 10:38 |
| tristan | That is a bit strange, but I guess 0 is *anyway* a valid value, regardless of how nonsensical it is ? | 10:38 |
| tristan | I mean the env var we use for tests is to circumvent the hard coded headroom iirc | 10:39 |
| jennis | Well, in our tests, we test to ensure that if the cache quota is set to 0, the test passes (i.e. there isn't a load error) | 10:39 |
| *** lachlan has joined #buildstream | 10:39 | |
| jennis | which to me sounds like we're saying, "zero quota" == "infinity" | 10:39 |
| tristan | jennis, as I recall, 'infinity' means 'the rest of your hard drive' | 10:39 |
| jennis | Yep | 10:39 |
| tristan | jennis, and that is very efficient to calculate (it's a single stat(), unlike calculating usage) | 10:40 |
| tristan | Now, I don't recall a change, it's possible that the way the setting is expressed may have changed | 10:40 |
| phildawson | I think that the references to ostree in cache expiry tests (https://gitlab.com/BuildStream/buildstream/blob/master/tests/artifactcache/expiry.py#41) are hangovers from the old cache and are no longer correct. Am I right? If so I'll fix them. | 10:40 |
| jennis | Yes I'm aware of that, but I'm asking what *should* the real world behaviour be if we explicitly set the quota to zero | 10:40 |
| tristan | But as I recall we allowed setting the string 'infinity' to ask for this, not '0' | 10:41 |
| tristan | It's a decent question | 10:41 |
| tristan | jennis, I would be happy with interpreting it as "not allowed to add any data to the cache" | 10:41 |
| tristan | And fire a warning when trying to cache anything | 10:41 |
| tristan | honestly, it's not that dissimilar from 1 | 10:41 |
| tristan | I can't imagine anything that could be stored in an artifact cache of 1 byte | 10:42 |
| jennis | ahh, so the other extreme | 10:42 |
| tristan | I mean, if we're deciding something that is still not clearly defined, that would be my vote | 10:42 |
| jennis | Yeah, I think it makes sense | 10:43 |
| jennis | because if we want the opposite behaviour, i.e. "add as much data to the cache as possible" we have the default behaviour, or we could explicitly set quota: 100% | 10:44 |
| jennis | So i guess we should also provide this (hopefully intuitive) method of, "don't add to my cache" | 10:44 |
| *** tristan has quit IRC | 10:46 | |
| *** tristan has joined #buildstream | 10:46 | |
| *** ChanServ sets mode: +o tristan | 10:46 | |
| * tristan changes his config to only allow 2 or 3 builders | 10:47 | |
| tristan | it's a sad day when I cannot build the whole stack with 4 parallel builds without overheating :-S | 10:48 |
| jennis | :( | 10:52 |
| jennis | tristan, I'm unsure how we should raise this when the quota is explicitly set to zero | 10:53 |
| jennis | I wouldn't exactly say it's a LoadError | 10:53 |
| jennis | CASError? | 10:54 |
| tristan | jennis, Wouldnt it be okay to not raise an error ? | 10:54 |
| jennis | So to just info? | 10:54 |
| tristan | jennis, and live with a cache that is full ? | 10:54 |
| jennis | This is what I was wondering | 10:54 |
| tristan | I mean it's a zero size cache, which is used 100% | 10:54 |
| tristan | Then as soon as anything tries to cache something, we bail out in the normal way as we would when we hit the end of the cache | 10:54 |
| tristan | It's a nonsensical situation to be sure, but I don't think it's any more nonsensical as a value of 1 | 10:55 |
| jennis | I mean, when we call CASCache.full(), if this returns true we raise a CASCacheError | 10:55 |
| tristan | So might as well just treat it the same way | 10:55 |
| *** nimish2711 has joined #buildstream | 10:56 | |
| tristan | jennis, Do we ? I mean when do we do that ? | 10:56 |
| tristan | I think when CASCache.full() returns true, we stop any ongoing jobs and do a cleanup | 10:57 |
| benschubert | tristan: we don't stop jobs, we just don't enqueue new ones | 10:57 |
| tristan | benschubert, Yes that is more accurate | 10:57 |
| tristan | Indeed | 10:57 |
| benschubert | meaning on a relatively powerfull machine, you will get out of disk space completely and multiple builds/pulls will fail | 10:57 |
| tristan | Well, if you have any idea of how to handle that better :) | 10:58 |
| tristan | We *could* start killing off jobs for the sake of a cleanup | 10:58 |
| jennis | ahh apologies, this raising of the CASCacheError is in the cleanup job | 10:58 |
| tristan | But headroom should be able to handle it in normal operation | 10:58 |
| tristan | Or, we could make headroom configurable | 10:59 |
| tristan | For powerful machines which build many many things in parallel to have a bigger safety margin | 10:59 |
| tristan | jennis, Right, that's when it's still full and there are artifacts we cannot delete | 10:59 |
| jennis | So if I have set my cache cache to zero, and then `bst build foo.bst`, what should I expect to see? An info message saying that we're not going to add data to the cache? | 10:59 |
| tristan | jennis, Just normal startup, and a failure once you try to cache an artifact (or source) ? | 11:00 |
| tristan | jennis, Also, you will see 100% in red in the statusbar | 11:00 |
| *** shash has joined #buildstream | 11:00 | |
| tristan | jennis, i.e. if you set your cache size to zero, it's pretty much equal to setting it to 1 | 11:01 |
| benschubert | tristan: yep configurable/a function of the number of builders would be better :D | 11:01 |
| tristan | jennis, which is what I keep saying... if we have to draw the line somewhere, lets just not draw it | 11:01 |
| jennis | Ok, bare in mind that I've made changes so that we're only calulating the quota when we actually need to write to the cache | 11:01 |
| tristan | :) | 11:01 |
| tristan | jennis, no that is not true ! | 11:02 |
| tristan | jennis, your lazy changes defer calculating it until it needs to be *known* | 11:02 |
| tristan | that is different | 11:02 |
| tristan | It needs to be known for instance, when a real build session starts and we try to print it in the log | 11:02 |
| jennis | the ones you saw yesterday? I've followed your suggestion and changed these | 11:02 |
| jennis | Ahh, but CASCacheUsage just needs to know about it | 11:03 |
| tristan | jennis, that said, if you have some abstract "get_cache_size()" which is used by all calling code paths, including the CASCacheUsage() etc, then you know that it will only be resolved when asked for | 11:03 |
| tristan | So, you might not have noticed that you will discover it earlier than that :) | 11:03 |
| *** nimish2711 has quit IRC | 11:06 | |
| jennis | tristan, and *don't* trigger a cleanup job for this? | 11:09 |
| tristan | jennis, "I don't think it needs to be handled in any different way than any other condition when the cache becomes full" | 11:11 |
| tristan | Does that answer the question ? | 11:11 |
| tristan | I.e., no conditional statement that handles it at all, and trust the code does the right thing, even it if seems ridiculous | 11:11 |
| tristan | because it is just as ridiculous as any other severely small number | 11:12 |
| jennis | Ok, well without conditional statements, we see that this is less than the headroom and get a LoadError right away... | 11:12 |
| tristan | Ahhh | 11:12 |
| jennis | So anything defined between 0 and 2G | 11:13 |
| tristan | So we already had that in place | 11:13 |
| tristan | Right | 11:13 |
| tristan | Not enough side for the headroom | 11:13 |
| jennis | Yes, but the test suite passed because the headroom is 0 for the test suite | 11:13 |
| tristan | I am confused, I think that load error is intentional | 11:13 |
| jennis | and in the test suite, we have "Valid configurations":, where an explicitly set cache quota of zero, should be a success | 11:14 |
| tristan | Right | 11:14 |
| jennis | which to me indicates that we were treating this edge case as, 0 is infinity | 11:14 |
| tristan | Because the test suite needs to run in conditions where we don't require 2G of actual cache, and we want to hit the limit in under that size | 11:14 |
| tristan | jennis, Ok that part I dont think so... the 0 is clearly less than headroom | 11:15 |
| jennis | Yep, so if we want to keep this behaviour, we could set the test suite headspace to be 1 Byte | 11:15 |
| * tristan is not clear why any of this has to change just because we resolve things lazily | 11:15 | |
| jennis | because of the failing tests | 11:16 |
| jennis | which assume that a cache quota of 0 should be a success | 11:16 |
| tristan | you could have lead with that ;-) | 11:16 |
| tristan | What is the failing test ? | 11:16 |
| tristan | And why would that now fail when before it didnt ? | 11:16 |
| jennis | tests/artifactcache/expiry.py::test_invalid_cache_quota[0-success-None] | 11:17 |
| tristan | jennis, perhaps the test is using a bst command which need not resolve the headroom ? | 11:17 |
| tristan | like, is it triggering `bst workspace list` and imagining that is enough ? | 11:17 |
| shash | Hey guys, I've recently joined Bloomberg and will be working with the BuildStream team for the next 6 months. I've been mainly tasked with working on the container plugins. As such, would it be possible to have developer access to the org. My Gitlab account is: shashwatdalal. Looking forward to working with all of you for the coming months :) | 11:17 |
| benschubert | laurence: ^ can you help? :) | 11:17 |
| tristan | shash, I think there is a button in the UI to request access, but certainly :) | 11:18 |
| tpollard | welcome shash :) | 11:18 |
| jennis | Hi shash, welcome | 11:19 |
| shash | tristan: I've just requested access through the UI, thanks :) | 11:19 |
| tristan | jennis, I just looked at the test, and indeed it is | 11:19 |
| tristan | jennis, that means you are using a codepath which does *not* have any reason to try to calculate the cache size at all | 11:20 |
| jennis | Ok tristan, so I've changed it so that we're only calculating the cache quota when we need it, so I've changed the workspace list command in that test to a build | 11:20 |
| tristan | jennis, that would explain it I think | 11:20 |
| tristan | Right, and it still doesnt pass ? | 11:20 |
| jennis | now that problem is that we're now trying to divide by zero to show the cache usage stats | 11:20 |
| jennis | Which then lead me to ask, what *should* the behaviour of a cache quota explicitly set to zero be | 11:21 |
| tristan | jennis, So that means you have not marshalled the codepaths to the right places | 11:21 |
| tristan | I think it's what that means anyway | 11:21 |
| tristan | I.e. you want all of that to happen in response to trying to get the cache size, so all that load time cache quota validation cannot be known until you actually check | 11:22 |
| tristan | jennis, so you have some case where a 0 is appearing as a value before having been calculated | 11:22 |
| tristan | something is accessing the value directly, without going through the right codepath | 11:22 |
| *** tristan has quit IRC | 11:26 | |
| *** nimish2711 has joined #buildstream | 11:28 | |
| *** tristan has joined #buildstream | 11:30 | |
| *** ChanServ sets mode: +o tristan | 11:30 | |
| tristan | jennis, I gotta run... actually I think the machine needs a bit of a break, overheated 3 times today :-/ | 11:32 |
| jennis | No worries, there is confusion added from the head space being 2G in reality and 0 in the test suite | 11:34 |
| *** nimish2711 has quit IRC | 11:52 | |
| *** nimish2711 has joined #buildstream | 11:53 | |
| *** nimish2711 has quit IRC | 12:03 | |
| *** nimish2711 has joined #buildstream | 12:03 | |
| *** jonathanmaw has joined #buildstream | 12:04 | |
| *** nimish2711 has quit IRC | 12:08 | |
| *** nimish2711 has joined #buildstream | 12:08 | |
| *** nimish2711 has quit IRC | 12:16 | |
| *** bochecha has joined #buildstream | 12:23 | |
| *** nimish2711 has joined #buildstream | 12:40 | |
| *** nimish2711 has quit IRC | 12:45 | |
| *** nimish2711 has joined #buildstream | 12:45 | |
| *** bochecha has quit IRC | 13:26 | |
| *** nimish2711 has quit IRC | 13:30 | |
| *** nimish2711 has joined #buildstream | 13:30 | |
| jennis | tristan, I've now uncovered that we weren't really fully supporting a cache quota of '0' in master anyway... I've left a summary comment here: https://gitlab.com/BuildStream/buildstream/merge_requests/1311/diffs#note_164227696 | 13:32 |
| jennis | So to me, it looks like we definitely need to specialcase this behaviour | 13:32 |
| jennis | I'm not sure what we agreed from our conversation this morning, I'm still a bit confused. So I will wait for your thoughts on this comment | 13:33 |
| *** nimish2711 has quit IRC | 13:35 | |
| *** nimish2711 has joined #buildstream | 13:36 | |
| *** nimish2711 has quit IRC | 13:51 | |
| *** nimish2711 has joined #buildstream | 13:51 | |
| *** nimish2711 has quit IRC | 13:56 | |
| *** nimish2711 has joined #buildstream | 13:56 | |
| *** nimish2711 has quit IRC | 14:01 | |
| *** nimish2711 has joined #buildstream | 14:02 | |
| *** tristan has quit IRC | 14:07 | |
| *** nimish2711 has quit IRC | 14:12 | |
| *** nimish2711 has joined #buildstream | 14:12 | |
| *** bochecha has joined #buildstream | 14:16 | |
| *** nimish2711 has quit IRC | 14:27 | |
| *** nimish2711 has joined #buildstream | 14:27 | |
| *** nimish2711 has quit IRC | 14:32 | |
| tpollard | anybody else been suffering from https://gitlab.com/BuildStream/buildstream/-/jobs/202329002 today? | 14:35 |
| tpollard | 'runner system failure' is really hitting this pipeline hard it seems | 14:37 |
| jennis | Yeah, not just that one too | 14:41 |
| phildawson | I've been seeing a lot of that | 14:48 |
| *** nimish2711 has joined #buildstream | 14:54 | |
| *** nimish2711 has quit IRC | 15:24 | |
| *** nimish2711 has joined #buildstream | 15:30 | |
| *** toscalix has quit IRC | 15:33 | |
| jjardon | shash: done | 15:39 |
| *** nimish2711 has quit IRC | 15:55 | |
| *** nimish2711 has joined #buildstream | 16:16 | |
| *** lachlan has quit IRC | 16:18 | |
| *** nimish2711 has quit IRC | 16:26 | |
| *** nimish2711 has joined #buildstream | 16:26 | |
| *** lachlan has joined #buildstream | 16:28 | |
| *** bochecha has quit IRC | 16:28 | |
| *** nimish2711 has quit IRC | 16:31 | |
| *** nimish2711 has joined #buildstream | 16:37 | |
| *** nimish2711 has quit IRC | 16:42 | |
| *** nimish2711 has joined #buildstream | 16:42 | |
| *** lachlan has quit IRC | 16:49 | |
| *** nimish2711 has quit IRC | 16:52 | |
| *** nimish2711 has joined #buildstream | 16:53 | |
| *** lachlan has joined #buildstream | 16:57 | |
| *** nimish2711 has quit IRC | 16:58 | |
| *** nimish2711 has joined #buildstream | 16:58 | |
| *** jonathanmaw has quit IRC | 17:04 | |
| shash | jjardon thank you :) | 17:07 |
| gitlab-br-bot | shashwatdalal opened MR !1313 (fixed-bug-for-pip-test->master: tests/testutil/python_repo.py: fixed executable path when running pip) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1313 | 17:20 |
| *** nimish2711 has quit IRC | 17:22 | |
| *** lachlan has quit IRC | 17:43 | |
| *** nimish2711 has joined #buildstream | 17:46 | |
| *** nimish2711 has quit IRC | 17:51 | |
| *** nimish2711 has joined #buildstream | 17:52 | |
| *** nimish2711 has quit IRC | 18:02 | |
| *** nimish2711 has joined #buildstream | 18:02 | |
| *** nimish2711 has quit IRC | 18:22 | |
| *** nimish2711 has joined #buildstream | 18:28 | |
| *** nimish2711 has quit IRC | 18:33 | |
| *** nimish2711 has joined #buildstream | 18:33 | |
| *** nimish2711 has quit IRC | 18:53 | |
| *** nimish2711 has joined #buildstream | 18:53 | |
| *** nimish2711 has quit IRC | 19:08 | |
| *** nimish2711 has joined #buildstream | 19:09 | |
| *** nimish2711 has joined #buildstream | 19:09 | |
| *** nimish2711 has quit IRC | 19:14 | |
| *** toscalix has joined #buildstream | 19:17 | |
| *** toscalix has quit IRC | 19:19 | |
| *** nimish2711 has joined #buildstream | 19:25 | |
| *** nimish2711 has quit IRC | 19:35 | |
| *** nimish2711 has joined #buildstream | 19:35 | |
| *** nimish2711 has quit IRC | 19:40 | |
| *** nimish2711 has joined #buildstream | 19:40 | |
| *** nimish2711 has quit IRC | 19:50 | |
| *** nimish2711 has joined #buildstream | 19:51 | |
| *** nimish2711 has quit IRC | 20:11 | |
| *** nimish2711 has joined #buildstream | 20:11 | |
| *** nimish2711 has quit IRC | 20:26 | |
| *** nimish2711 has joined #buildstream | 20:37 | |
| *** nimish2711 has quit IRC | 20:39 | |
| gitlab-br-bot | cs-shadow approved MR !1313 (fixed-bug-for-pip-test->master: tests/testutil/python_repo.py: fixed executable path when running pip) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1313 | 23:32 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!