| *** bochecha has quit IRC | 02:44 | |
| *** bochecha has joined #buildstream | 02:44 | |
| *** bochecha has quit IRC | 03:42 | |
| *** bochecha has joined #buildstream | 03:42 | |
| *** narispo has quit IRC | 07:51 | |
| *** narispo has joined #buildstream | 07:51 | |
| *** traveltissues has joined #buildstream | 08:04 | |
| *** phoenix has joined #buildstream | 08:19 | |
| *** juanalday has joined #buildstream | 08:31 | |
| *** narispo has quit IRC | 08:59 | |
| *** narispo has joined #buildstream | 09:03 | |
| *** rdale has joined #buildstream | 09:12 | |
| *** bochecha has quit IRC | 09:22 | |
| *** santi has joined #buildstream | 09:35 | |
| *** tiagogomes has joined #buildstream | 09:41 | |
| *** bochecha has joined #buildstream | 09:42 | |
| gitlab-br-bot | traveltissues opened issue #1190 (ignore_workspaces is unnecessary after !1640) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1190 | 09:44 |
|---|---|---|
| *** phildawson_ has joined #buildstream | 09:52 | |
| gitlab-br-bot | traveltissues opened issue #1191 (non-deterministic test failure from casd timeout) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1191 | 09:54 |
| benschubert | tpollard: do you know if the double ctrl+c ever worked? | 10:03 |
| tpollard | benschubert: it works on master for me, but gives those child process errors | 10:04 |
| tpollard | * on bst build | 10:04 |
| traveltissues | on linux only? | 10:04 |
| benschubert | ah right | 10:04 |
| tpollard | my testing for that issue was linux yes | 10:04 |
| benschubert | interesting I get a different behavior on Windows | 10:04 |
| traveltissues | it never worked for the versions i tried on wsl/mac, i'm not sure about windows | 10:05 |
| benschubert | traveltissues: never worked == ? | 10:05 |
| benschubert | what's your output? :) | 10:05 |
| traveltissues | i don't remember the specifics atm but afair it either ignored the interrupt or got stuck in a loop | 10:06 |
| traveltissues | looping into the menu for continue/quit/etc | 10:07 |
| benschubert | ok, I yet have another behavior | 10:07 |
| traveltissues | what did you see? | 10:08 |
| benschubert | a fun error: https://gitlab.com/snippets/1910707 :D | 10:10 |
| traveltissues | that's not healthy looking | 10:10 |
| tpollard | I get that on source fetch | 10:10 |
| benschubert | that's one way to put it :'D | 10:11 |
| benschubert | tpollard: when you double ctrl + c ? | 10:11 |
| tpollard | yep | 10:11 |
| tpollard | but not on build | 10:11 |
| traveltissues | do we know if that's an issue with bst or with the asyncio lib | 10:11 |
| benschubert | awesome, that means I can at least fix one thing x') | 10:11 |
| benschubert | that's a problem with our signal handling as far as I can tell | 10:11 |
| tpollard | yep, and I suspect it's come from adding a watch child process for casd | 10:12 |
| benschubert | that would seems weird | 10:12 |
| benschubert | but I can check easily | 10:12 |
| tpollard | which we don't have as robust control over our custom signal handling compared to the scheduler jobs | 10:12 |
| tpollard | it's even more fun when the scheduler is in a separate process :D | 10:13 |
| benschubert | tpollard: commenting https://gitlab.com/BuildStream/buildstream/blob/master/src/buildstream/_scheduler/scheduler.py#L188 out still yields the same error | 10:14 |
| benschubert | so I would think it's not because of child watcher of buildbox-casd? | 10:14 |
| *** jonathanmaw has joined #buildstream | 10:19 | |
| *** lachlan has joined #buildstream | 10:31 | |
| benschubert | does someone has bst 1.4 installed and could try a double ctrl+c on a build/fetch for me? | 10:34 |
| juergbi | benschubert: can do that | 10:38 |
| juergbi | a particular project or it doesn't matter? | 10:38 |
| benschubert | doesn't matter | 10:41 |
| benschubert | just need to ctrl+c twice during build/fetch :) | 10:41 |
| gitlab-br-bot | traveltissues opened (was WIP) MR !1688 (traveltissues/closeworkspaces->master: Remove ignore_workspaces kwarg) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1688 | 10:42 |
| juergbi | benschubert: https://hastebin.com/biqozeqoru.rb | 10:42 |
| benschubert | mind posting it on gitlab snippet? corporate proxies :( | 10:43 |
| juergbi | sure, if gitlab responds at some point ;) | 10:43 |
| benschubert | haha sure ! | 10:45 |
| juergbi | 502 Whoops, GitLab is taking too much time to respond. | 10:46 |
| juergbi | benschubert: https://gitlab.com/BuildStream/buildstream/snippets/1910723 | 10:46 |
| * tpollard wonders why he doesn't get that on build | 10:46 | |
| bochecha | hi, I just got this: https://paste.gnome.org/pvm25jclm/1zsc0u/raw | 10:47 |
| bochecha | with bst 1.4.1 | 10:47 |
| bochecha | I'm not sure what's going on, but that looks like a bug in bst? | 10:47 |
| tlater[m] | bochecha: Probably, looks like some sort of utf-8 bug. Do you have a copy of the element causing this? | 10:50 |
| bochecha | tlater[m]: how can I figure out what element is causing this? | 10:51 |
| benschubert | juergbi: tpollard ok exactly what I get 4 times over 5, with the last time being the same error as tpollard. Which means we have a signal handling problem :'D | 10:52 |
| benschubert | juergbi: mind adding that to https://gitlab.com/BuildStream/buildstream/issues/1185 ? | 10:52 |
| tlater[m] | bochecha: I'd expect it to be the last element that printed a message in your logs. If you've cleared your terminal, they're usually in $HOME/.cache/buildstream/logs/ | 10:52 |
| bochecha | tlater[m]: in any case the repo is https://github.com/endlessm/endless-sdk-flatpak, in the dylanmccall/T28284-gnome-3-34 branch | 10:52 |
| benschubert | tpollard: to have that on build, you can try with --builders 16 :) | 10:52 |
| bochecha | tlater[m]: no element printed anything in the logs | 10:53 |
| tlater[m] | Oh, even more interesting, that means this happens when loading the pipeline | 10:53 |
| bochecha | tlater[m]: this is the full output: https://paste.gnome.org/puwdelv79/wxx5hi/raw | 10:53 |
| bochecha | (first paste was only missing a few lines at the start) | 10:53 |
| benschubert | tlater[m]: that would be while creating the element's cache key | 10:54 |
| tlater[m] | benschubert: Yeah, it makes sense | 10:54 |
| tpollard | benschubert: I still don't get the keyboard interrupt exception coming through | 10:54 |
| bochecha | so how can I debug this? I'm happy to send a MR fixing the issue, but I need a bit of help to understand what's happening first :) | 10:54 |
| tpollard | but like I say I do on source fetch, so I agree there's a sig handling problem | 10:55 |
| * tlater[m] wants to pop a `raise Exception(self._get_name())` in bochecha's buildstream | 10:55 | |
| tlater[m] | bochecha: I'd really like to look at this, it's definitely a bug, but I don't think I have the time right now :( | 10:55 |
| juergbi | bochecha, tlater[m]: I don't think that's a UTF-8 issue. it's ujson complaining that the cache key dict is not (JSON) serializable | 10:55 |
| juergbi | sounds like a possible plugin bug to me | 10:55 |
| juergbi | but we should really detect this and provide a proper error message | 10:56 |
| tlater[m] | juergbi: Looking at the first line it's struggling to serialize some sort of garbled characters | 10:56 |
| bochecha | the plugins are from bst-external | 10:56 |
| juergbi | tlater[m]: yes, that's presumably the not serializable object. not sure what exactly ujson prints | 10:57 |
| juergbi | something like this happens when you put a protobuf into a cache key dict, iirc | 10:57 |
| tlater[m] | Oh, that's a fun result | 10:58 |
| bochecha | I'm printing the value in `generate_key, seems to be a fine-looking SanitizedDict | 10:58 |
| juergbi | can you paste? | 10:59 |
| bochecha | sure | 11:01 |
| bochecha | this is the dict tripping up ujson: https://paste.gnome.org/pfyefwi8k/zhb8gr/raw | 11:01 |
| bochecha | err, that's not very easy to read, sorry | 11:01 |
| * bochecha tries pprint | 11:02 | |
| bochecha | juergbi, tlater[m]: better: https://paste.gnome.org/pj0gg05e0 | 11:02 |
| bochecha | this is bst 1.4.1 and bst-external 0.19.1 | 11:03 |
| tlater[m] | Huh, nothing odd in there, indeed | 11:03 |
| juergbi | collect-integration plugin, afaict | 11:04 |
| coldtom | that's the collect_integration plugin i think | 11:04 |
| coldtom | snap | 11:04 |
| juergbi | are sets allowed by ujson? | 11:04 |
| juergbi | if not, I don't see how that plugin could have ever worked, though | 11:04 |
| *** lachlan has quit IRC | 11:05 | |
| juergbi | ujson.dumps(set()) doesn't complain | 11:05 |
| bochecha | it does here | 11:06 |
| juergbi | oh, ujson version difference? | 11:06 |
| bochecha | https://paste.gnome.org/phdscnqfb/mhnzct/raw | 11:06 |
| bochecha | python3-ujson-2.0-0.1.20170206git2f1d487.fc31.8.x86_64 | 11:06 |
| bochecha | juergbi: what version do you have? | 11:07 |
| * bochecha expects 1.35, as that's the last one on pypi :-/ | 11:07 | |
| juergbi | yes, ujson 1.35 here | 11:07 |
| juergbi | regression in ujson or intentional change? | 11:08 |
| bochecha | I found this: https://github.com/esnme/ultrajson/issues/232 | 11:09 |
| bochecha | which says sets can't work at all, issue closed | 11:09 |
| bochecha | except it works for you | 11:09 |
| bochecha | so that might have been an unintended change leading to the intended behaviour :P | 11:09 |
| bochecha | ujson seems to have been abandoned, though, last commit was in March 2017 | 11:10 |
| juergbi | bochecha: it was removed in this horrible commit: https://github.com/esnme/ultrajson/commit/7b5dc3172ddb19f781a668e2e9899566294ba8b3 | 11:11 |
| bochecha | juergbi: https://src.fedoraproject.org/rpms/python-ujson/c/82eb59a2f5b8102b7ac812d4e9c1bf940924e03b?branch=f31 | 11:11 |
| juergbi | so ujson 2 is apparently not compatible with ujson 1 | 11:11 |
| juergbi | and ujson 2 is not on pypi | 11:11 |
| bochecha | it hasn't been released | 11:12 |
| bochecha | the commit above is Fedora deciding to go with a git snapshot of version 2 specifically to make it stricter | 11:12 |
| bochecha | thanks Fedora! | 11:13 |
| juergbi | doesn't make too much sense if it's abandoned, imo | 11:14 |
| juergbi | being incompatible with the rest | 11:14 |
| *** phoenix has quit IRC | 11:46 | |
| *** lachlan has joined #buildstream | 11:46 | |
| *** phoenix has joined #buildstream | 11:46 | |
| bochecha | juergbi: to be fair, Fedora updated before it was abandoned | 11:53 |
| *** lachlan has quit IRC | 11:53 | |
| bochecha | it still doesn't make much sense to update to a git snapshot which breaks compatibility with everything, before the release; if it hadn't been abandoned, 2.0 could have broken compat again for example | 11:53 |
| bochecha | juergbi: it seems ujson also doesn't serialize datetimes any more, could that cause problems in bst? | 11:58 |
| bochecha | anyway, the fix for my specific issue is trivial: https://gitlab.com/BuildStream/bst-external/merge_requests/109 | 12:02 |
| bochecha | thanks for the help figuring this out :) | 12:02 |
| gitlab-br-bot | traveltissues opened (was WIP) MR !1689 (traveltissues/1186-3->master: skip tracking elements without trackable sources) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1689 | 12:08 |
| tlater[m] | bochecha: I wonder why one would want to ignore duplicates in a key... The effect would just be that if you add a duplicate entry the element won't rebuild. | 12:09 |
| bochecha | tlater[m]: I don't know | 12:09 |
| bochecha | like I said, I just didn't want to inadvertently change the semantics | 12:10 |
| tlater[m] | Yeah, it makes sense | 12:10 |
| bochecha | imho, removing the set (if desired) should really be done in its own commit, explicitly | 12:10 |
| bochecha | not as part of a "work with ujson 2.0" commit | 12:10 |
| tlater[m] | It probably doesn't affect performance in any significant way anyway | 12:10 |
| tlater[m] | Not going to be that much to ignore | 12:11 |
| tlater[m] | Yeah, you've convinced me, let's keep the MR as-is. | 12:11 |
| *** traveltissues has quit IRC | 12:13 | |
| *** traveltissues has joined #buildstream | 12:13 | |
| benschubert | bochecha: would you mind also adding your patch to the bst-2 compatible version: https://gitlab.com/buildstream/bst-plugins-experimental :) | 12:14 |
| bochecha | ah, sure | 12:14 |
| bochecha | I didn't know of that repo :) | 12:14 |
| *** lachlan has joined #buildstream | 12:15 | |
| *** bochecha has quit IRC | 12:17 | |
| benschubert | awesome, ping me once you have made it, I'll review | 12:17 |
| *** bochecha has joined #buildstream | 12:17 | |
| *** lachlan has quit IRC | 12:18 | |
| bochecha | benschubert: should we wait for valentind's answer first though? https://gitlab.com/BuildStream/bst-external/merge_requests/109#note_240790410 | 12:20 |
| bochecha | benschubert: or should I do the same as I did in bst-external and we'll deal with the set later, depending on what valentind says? | 12:20 |
| valentind | I did not know about it. | 12:21 |
| benschubert | did you mean tlater[m] ? :) | 12:21 |
| valentind | Is not list sorted somehow? | 12:21 |
| bochecha | benschubert: no, tlater[m] asked a question for valentind | 12:21 |
| valentind | How do you make a key not care about the order of elements in a list? | 12:21 |
| benschubert | ah right, haven't seen that | 12:22 |
| bochecha | valentind: the question is whether making a set to remove dupes is important or not | 12:22 |
| bochecha | oooh | 12:22 |
| benschubert | valentind: you are correct, we should do sorted(set(...)) | 12:22 |
| bochecha | that's why you used a set? to avoid ordering? | 12:22 |
| *** lachlan has joined #buildstream | 12:22 | |
| tlater[m] | bochecha: sets aren't ordered | 12:22 |
| bochecha | that's what I'm saying | 12:22 |
| benschubert | valentind: the key will care about the order in any case | 12:22 |
| benschubert | because we translate it to json which doesn't know sets | 12:23 |
| bochecha | so the goal is to consider all collections equal even if they aren't ordered the same | 12:23 |
| valentind | benschubert, even with a set? | 12:23 |
| bochecha | valentind: no sets in json | 12:23 |
| benschubert | valentind: yup, set doesn't exist in json | 12:23 |
| bochecha | that's the problem my MR fixes | 12:23 |
| valentind | So it needs sorting then. | 12:23 |
| tlater[m] | We'd need a `sorted(list(x))` | 12:23 |
| bochecha | that will break existing keys though (only once) | 12:23 |
| bochecha | I'll update the MR then | 12:24 |
| benschubert | yep, but currently you don't have any idea on what the cache key will be if you are on python 3.5 :'D | 12:24 |
| tlater[m] | Hehe, the order in which you get things from a set is non-deterministic, bochecha | 12:24 |
| bochecha | tlater[m]: I know that | 12:24 |
| tlater[m] | So currently the keys are continuously broken | 12:24 |
| benschubert | so sorted(set(...)) should be fine | 12:25 |
| bochecha | benschubert: seems like we don't need the set though? | 12:25 |
| tlater[m] | benschubert: That'll actually be an iterator | 12:25 |
| benschubert | fair | 12:25 |
| tlater[m] | So you'll need list(sorted(set(...))) | 12:25 |
| benschubert | then tlater[m] ujson supports sorted iterators normally | 12:25 |
| tlater[m] | And then you don't need the set :) | 12:25 |
| valentind | I am fine with breaking keys on that. Collect integration is on the surface it does not involve much rebuilds. | 12:25 |
| bochecha | benschubert: since the goal of using it wasn't to remove dupes, but instead to try and avoid ordering issues (which didn't work as we are discussing) | 12:26 |
| tlater[m] | Oh, interesting | 12:26 |
| benschubert | tlater[m]: for python3.7 sorted returns a list? | 12:26 |
| bochecha | benschubert: and no, ujson doesn't support iterators | 12:26 |
| tlater[m] | Does it still after the patch that caused all these problems? | 12:26 |
| tlater[m] | Because then it can just be `sorted(...)` | 12:26 |
| bochecha | benschubert: not in 2.0 (not yet released, but fedora has it already :'( ) | 12:26 |
| tlater[m] | benschubert: Oh, you're right, apparently it does | 12:27 |
| * tlater[m] feels cheated | 12:27 | |
| benschubert | so sorted(...) should be enough :D | 12:27 |
| bochecha | didn't `sorted` always return a list? | 12:27 |
| tlater[m] | Looks like it, yeah | 12:27 |
| valentind | "Return a new sorted list from the items in iterable." | 12:27 |
| * tlater[m] imagined it wouldn't because it's common in iterator chains | 12:27 | |
| bochecha | tlater[m]: then it's wrong to use it in iterator chains if you don't want intermediate lists ^_^ | 12:28 |
| benschubert | tlater[m]: you can't sort an iterator, what sorted does there is consume it entirely then sort it and return the list | 12:28 |
| valentind | It is a pity it is not possible to remove duplicates during sorting. | 12:28 |
| tlater[m] | benschubert: Yup, I always wondered why | 12:29 |
| * tlater[m] never bothered to check the doc though | 12:29 | |
| tlater[m] | I wonder how much code I've written that goes `list(sorted()0` | 12:30 |
| benschubert | valentind: [x for x, _ in itertools.groupby(sorted(my_data)) | 12:31 |
| bochecha | valentind: wait, there might be duplicates after all? | 12:32 |
| valentind | In theory. | 12:32 |
| valentind | It would be nice to have a way to construct keys in a descriptive way. Where you can say, here I have a container, I care or not about order, duplicates, etc. | 12:34 |
| tlater[m] | benschubert: `sorted(x for x, _ in itertools.groupby(my_data))`, but given what you've told me about iterators that's probably slower ;p | 12:35 |
| valentind | tlater[m], groupby requires consecutive similar elements | 12:35 |
| valentind | So you need to sort first. | 12:36 |
| tlater[m] | Oh, right, it does | 12:36 |
| tlater[m] | :| | 12:36 |
| valentind | I am fine with benschubert's proposal. | 12:37 |
| gitlab-br-bot | traveltissues opened (was WIP) MR !1689 (traveltissues/1186-3->master: skip tracking elements without trackable sources) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1689 | 12:37 |
| bochecha | alright, let me update the MR then | 12:38 |
| bochecha | that solution fixes a real issue in bst (ordering breaking the keys) and incidentally fixes my problem in Fedora ^_^ | 12:39 |
| tlater[m] | \o/ | 12:40 |
| bochecha | although to be honest, `[x for x, _ in itertools.groupby(sorted(my_data))]` is more complex than simply `sorted(set(my_data))` | 12:41 |
| bochecha | and I don't see what it gains us | 12:41 |
| bochecha | both seem to iterate twice over `my_data`? | 12:42 |
| gitlab-br-bot | tpollard approved MR !1688 (traveltissues/closeworkspaces->master: Remove ignore_workspaces kwarg) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1688 | 12:44 |
| bochecha | and in fact, sorting after removing duplicates might make things slightly faster? | 12:44 |
| tlater[m] | bochecha: yes, I suspect groupby will be slightly faster though, since it assumes the set is sorted. | 12:44 |
| tlater[m] | So it's O(n), whereas set() will need to sort first to remove duplicates - it really depends on implementation though. | 12:44 |
| bochecha | I think set is close to the dict implementation, which doesn't sort keys | 12:45 |
| tlater[m] | I suppose set() might be implemented as some sort of bucketed map? | 12:45 |
| tlater[m] | Yeah, that might be faster. | 12:45 |
| tlater[m] | Especially because groupby is an iterator and those tend to be slow when fully executed. | 12:46 |
| bochecha | and if set sorted things first, then Python would be able to guarantee ordering of sets, which it doesn't do :) | 12:46 |
| * tlater[m] is almost curious enough to benchmark/dive into cpython | 12:46 | |
| bochecha | I'm not :P | 12:46 |
| bochecha | I doubt that will make much difference for bst | 12:47 |
| tlater[m] | 'specially on a list of like 4 elements | 12:47 |
| tlater[m] | But it'd be nice to know in general. | 12:47 |
| bochecha | yeah | 12:52 |
| bochecha | I'm just not curious enough right now :P | 12:52 |
| bochecha | I updated the MR | 12:54 |
| bochecha | although gitlab still shows the old version :-/ | 12:57 |
| *** santi has quit IRC | 13:24 | |
| tlater[m] | juergbi: It looks like buildbox-casd ignores umask as well | 13:29 |
| tlater[m] | It'll create non-group writeable files | 13:29 |
| tlater[m] | Which in turn means that we can't update mtimes there without FetchTree() | 13:29 |
| tlater[m] | I suppose luckily I have a patch coming in for that already | 13:29 |
| juergbi | do we still update mtimes in master? | 13:29 |
| juergbi | as master now uses FetchTree | 13:30 |
| juergbi | ah, server side? | 13:30 |
| tlater[m] | juergbi: On the casserver side we do it seems | 13:30 |
| tlater[m] | Yeah | 13:30 |
| juergbi | right, the permissions on the casd side are intentional, though | 13:30 |
| juergbi | clients should not be allowed to write to the CAS | 13:30 |
| juergbi | otherwise commands could corrupt hardlinked cached files | 13:31 |
| tlater[m] | The only problem is that practically no casserver tests can pass now :( | 13:31 |
| * tlater[m] wonders if he should land that MR before continuing with this | 13:31 | |
| juergbi | if this blocks you, a quick workaround could be to simply drop those utimes in the server | 13:32 |
| juergbi | this shouldn't break anything but expiry tests | 13:32 |
| juergbi | and proper fix will be your branch | 13:32 |
| benschubert | bochecha: I agree, you should not use my solution :) It will be slower and less readable | 13:33 |
| bochecha | benschubert: I didn't, I used `sorted(set(self.ignore))` in the MR | 13:34 |
| tlater[m] | juergbi: That's what I've done so far, but `pull` is falling over too | 13:34 |
| benschubert | perfect :) | 13:34 |
| tlater[m] | Although I'm not 100% sure why that fails yet. | 13:34 |
| * tlater[m] supposes he'll dig further before switching MRs | 13:34 | |
| tlater[m] | I still have 400 failing tests, there'll be something I can do before that x) | 13:35 |
| *** akvilebirgelyte has quit IRC | 13:56 | |
| *** phildawson_ has quit IRC | 14:00 | |
| *** tiagogomes has quit IRC | 14:00 | |
| *** lachlan has quit IRC | 14:00 | |
| *** traveltissues has quit IRC | 14:00 | |
| *** jonathanmaw has quit IRC | 14:00 | |
| *** tpollard has quit IRC | 14:00 | |
| *** tiagogomes has joined #buildstream | 14:00 | |
| *** phildawson_ has joined #buildstream | 14:00 | |
| *** tpollard has joined #buildstream | 14:00 | |
| *** traveltissues has joined #buildstream | 14:00 | |
| *** jonathanmaw has joined #buildstream | 14:00 | |
| *** lachlan has joined #buildstream | 14:00 | |
| *** traveltissues has quit IRC | 14:02 | |
| *** lachlan has quit IRC | 14:02 | |
| *** phildawson_ has quit IRC | 14:02 | |
| *** tpollard has quit IRC | 14:02 | |
| *** jonathanmaw has quit IRC | 14:03 | |
| *** tiagogomes has quit IRC | 14:03 | |
| *** tiagogomes has joined #buildstream | 14:03 | |
| *** tpollard has joined #buildstream | 14:03 | |
| *** phildawson_ has joined #buildstream | 14:03 | |
| *** traveltissues has joined #buildstream | 14:03 | |
| *** jonathanmaw has joined #buildstream | 14:03 | |
| *** lachlan has joined #buildstream | 14:03 | |
| *** santi has joined #buildstream | 14:08 | |
| tpollard | benschubert: are you running WSL1 on the machine you ran the times for my branch on? | 14:08 |
| benschubert | tpollard: yes I was | 14:38 |
| Kinnison | Are you using the built-in WSL terminal? | 14:44 |
| benschubert | the second try (not on the issue) yes, the other time was Windows Terminal | 14:54 |
| benschubert | Kinnison: ^ | 14:55 |
| Kinnison | Hmm | 14:56 |
| *** narispo has quit IRC | 15:25 | |
| *** narispo has joined #buildstream | 15:26 | |
| benschubert | juergbi: would you mind testing something more for me on bst 1.4? https://gitlab.com/BuildStream/buildstream/blob/bst-1/buildstream/_frontend/app.py#L507 change the line to 'except (click.Abort, SystemError)': and retry? Do you get also 'unknown child process' errors? | 15:47 |
| juergbi | benschubert: yes, overall much better but I get | 15:49 |
| juergbi | Unknown child process pid 1064121, will report returncode 255 | 15:49 |
| benschubert | ok! good so it seems we had that from way longer :( | 15:50 |
| benschubert | that's more investigation x') | 15:50 |
| benschubert | I'm surprised nobody complained before | 15:50 |
| *** bochecha_ has joined #buildstream | 15:51 | |
| gitlab-br-bot | BenjaminSchubert approved MR !1688 (traveltissues/closeworkspaces->master: Remove ignore_workspaces kwarg) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1688 | 15:51 |
| tpollard | That's why I get on master | 15:51 |
| tpollard | *what | 15:51 |
| benschubert | tpollard: yep, there are two bugs in total :) one is intermittent with SystemError, the other one is the returncode 255 | 15:52 |
| benschubert | I know how to hide the first one, but don't like the solution. The other one I'm looking into it | 15:52 |
| *** bochecha has quit IRC | 15:53 | |
| *** bochecha_ is now known as bochecha | 15:53 | |
| tpollard | yeh, click Abort should be handling it whilst the int signal handler is disconnected right? | 15:53 |
| benschubert | yep | 15:54 |
| benschubert | seems many things are going weird there | 15:54 |
| gitlab-br-bot | marge-bot123 closed issue #1190 (ignore_workspaces is unnecessary after !1640) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1190 | 15:58 |
| gitlab-br-bot | marge-bot123 merged MR !1688 (traveltissues/closeworkspaces->master: Remove ignore_workspaces kwarg) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1688 | 15:58 |
| *** bochecha_ has joined #buildstream | 16:20 | |
| *** bochecha_ has quit IRC | 16:21 | |
| *** bochecha has quit IRC | 16:23 | |
| *** phil has joined #buildstream | 16:29 | |
| *** phildawson_ has quit IRC | 16:30 | |
| *** santi has quit IRC | 16:44 | |
| traveltissues | i think the wsl runner might need a restart | 16:58 |
| *** santi has joined #buildstream | 17:02 | |
| *** lachlan has quit IRC | 17:04 | |
| *** lachlan has joined #buildstream | 17:05 | |
| benschubert | are the child jobs not handling sigkill? | 17:07 |
| tpollard | afaik, we only explicitly block the child jobs having int/stp/term | 17:15 |
| benschubert | *sigterm sorry | 17:16 |
| tpollard | things might be going weird during the suspend though during the interrupt handler | 17:16 |
| *** phoenix has quit IRC | 17:16 | |
| benschubert | we seem to be unblocking it, but not handling it explicitely | 17:17 |
| *** juanalday has quit IRC | 17:38 | |
| *** narispo has quit IRC | 17:59 | |
| *** narispo has joined #buildstream | 18:00 | |
| *** santi has quit IRC | 18:03 | |
| *** lachlan has quit IRC | 18:03 | |
| *** jonathanmaw has quit IRC | 18:03 | |
| *** tiagogomes has quit IRC | 18:03 | |
| *** tpollard has quit IRC | 18:03 | |
| *** phil has quit IRC | 18:03 | |
| *** traveltissues has quit IRC | 18:03 | |
| *** tiagogomes has joined #buildstream | 18:04 | |
| *** tpollard has joined #buildstream | 18:04 | |
| *** traveltissues has joined #buildstream | 18:04 | |
| *** jonathanmaw has joined #buildstream | 18:04 | |
| *** phil has joined #buildstream | 18:04 | |
| *** tiagogomes has quit IRC | 18:04 | |
| *** traveltissues has quit IRC | 18:04 | |
| *** tiagogomes has joined #buildstream | 18:05 | |
| *** traveltissues has joined #buildstream | 18:05 | |
| *** lachlan has joined #buildstream | 18:05 | |
| *** traveltissues has quit IRC | 18:05 | |
| *** phildawson_ has joined #buildstream | 18:06 | |
| *** phil has quit IRC | 18:06 | |
| *** lachlan has quit IRC | 18:06 | |
| *** phildawson_ has quit IRC | 18:06 | |
| *** tpollard has quit IRC | 18:06 | |
| *** tiagogomes has quit IRC | 18:06 | |
| *** jonathanmaw has quit IRC | 18:06 | |
| *** tiagogomes has joined #buildstream | 18:07 | |
| *** jonathanmaw has joined #buildstream | 18:07 | |
| *** tpollard has joined #buildstream | 18:07 | |
| *** lachlan has joined #buildstream | 18:07 | |
| *** phildawson_ has joined #buildstream | 18:08 | |
| *** phil has joined #buildstream | 18:08 | |
| *** tiagogomes has quit IRC | 18:10 | |
| *** jonathanmaw has quit IRC | 18:20 | |
| *** narispo has quit IRC | 18:31 | |
| *** narispo has joined #buildstream | 18:32 | |
| *** narispo has joined #buildstream | 18:32 | |
| *** narispo has quit IRC | 18:39 | |
| *** narispo has joined #buildstream | 18:40 | |
| *** lachlan has quit IRC | 19:06 | |
| *** lachlan has joined #buildstream | 19:07 | |
| *** phildawson_ has quit IRC | 19:26 | |
| *** phil has quit IRC | 19:26 | |
| gitlab-br-bot | cs-shadow opened issue #1192 (Plugin documentation is lacking) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1192 | 19:30 |
| *** dylan-m_ has joined #buildstream | 19:45 | |
| *** narispo has quit IRC | 19:46 | |
| *** narispo has joined #buildstream | 19:46 | |
| *** narispo has quit IRC | 19:47 | |
| *** narispo has joined #buildstream | 19:48 | |
| *** narispo has quit IRC | 20:11 | |
| *** narispo has joined #buildstream | 20:12 | |
| *** narispo has quit IRC | 20:15 | |
| *** narispo has joined #buildstream | 20:15 | |
| *** narispo has quit IRC | 20:26 | |
| *** narispo has joined #buildstream | 20:26 | |
| *** narispo has quit IRC | 20:27 | |
| *** narispo has joined #buildstream | 20:27 | |
| *** lachlan has quit IRC | 21:09 | |
| *** narispo has quit IRC | 21:40 | |
| *** narispo has joined #buildstream | 21:43 | |
| *** narispo has quit IRC | 22:03 | |
| *** narispo has joined #buildstream | 22:03 | |
| *** narispo has quit IRC | 22:43 | |
| *** narispo has joined #buildstream | 22:44 | |
| *** narispo has quit IRC | 22:51 | |
| *** narispo has joined #buildstream | 22:51 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!