| *** juanalday has joined #buildstream | 00:09 | |
| *** xjuan has quit IRC | 00:22 | |
| *** juanalday has quit IRC | 01:35 | |
| *** catonano has joined #buildstream | 04:12 | |
| *** catonano has quit IRC | 06:01 | |
| *** mohan43u has joined #buildstream | 06:41 | |
| *** catonano has joined #buildstream | 07:07 | |
| *** catonano has quit IRC | 08:19 | |
| *** catonano has joined #buildstream | 08:40 | |
| *** phildawson_ has joined #buildstream | 08:41 | |
| *** finn has joined #buildstream | 09:07 | |
| Kinnison | coldtom: in what sense? submodules refs are part of the commit in the parent repository and so are "tracked" by git rather than buildstream directly | 09:08 |
|---|---|---|
| coldtom | ah, i think that was a misunderstanding on my part on how git submodules work | 09:09 |
| Kinnison | That's okay, they're one of the more intricate bits of git :_) | 09:10 |
| *** toscalix has joined #buildstream | 09:10 | |
| *** WSalmon has joined #buildstream | 09:14 | |
| jjardon | valentind: can you increase the limit of the logs so we can see the failure at https://gitlab.com/BuildStream/buildstream/-/jobs/118249521 ? | 09:20 |
| jjardon | adding `output_limit = 262144` to the config.toml of the manager runner should work | 09:23 |
| jjardon | https://www.irccloud.com/pastebin/1AMJCIHX/ | 09:23 |
| jjardon | well, maybe 32768 (32MiB) is enough | 09:25 |
| *** jonathanmaw has joined #buildstream | 09:28 | |
| valentind | jjardon, I realized I do not have access to buildstream-bastion | 09:30 |
| jjardon | valentind: can you try now? | 09:37 |
| valentind | jjardon, Did you do something? | 09:37 |
| jjardon | valentind: I have added you public ssh key | 09:38 |
| valentind | Did not work | 09:38 |
| jjardon | valentind: can you send me it again, please? | 09:38 |
| valentind | jjardon, OK done. | 09:41 |
| jjardon | cheers | 09:41 |
| *** catonano has quit IRC | 09:43 | |
| benschubert | https://gitlab.com/BuildStream/buildstream/-/jobs/118434903 somethign happened with the runners? :/ | 09:43 |
| valentind | benschubert, yes sorry | 09:46 |
| valentind | benschubert, just "retry" | 09:46 |
| benschubert | OK so that's expected? perfect :) thanks! | 09:46 |
| valentind | benschubert, Yes, sorry I had to restart the bastion and it was not smart enough to just resume builds | 09:47 |
| *** raoul has joined #buildstream | 09:47 | |
| benschubert | Got scared that I had changed something bad that killed the runners :) | 09:47 |
| jjardon | valentind: did you restart gitlab-runner? not needed; new runners will pickup the new config automatically | 09:47 |
| valentind | jjardon, Oh, I did not know. | 09:47 |
| valentind | Well oops then | 09:47 |
| jjardon | yeah, It's quite neat, but you are right it will fail and not recover if you restart | 09:48 |
| benschubert | And if you want to restart gitlab-runner anyways, there is a way of telling it to finish the jobs first :) | 09:48 |
| valentind | jjardon, but it is actually strange there is no way to "commit" changes in the configuration. | 09:48 |
| benschubert | commiting changes is saving the file (for better or worse...) | 09:48 |
| valentind | benschubert, how? | 09:48 |
| benschubert | valentind: SIGQUIT tells the runner to stop accepting new jobs and restart as soon as it is done :) | 09:49 |
| benschubert | https://docs.gitlab.com/runner/commands/#signals for reference | 09:49 |
| valentind | Reading the configuration file before each build seems like a hack. How do they make sure the save was complete? Editors do not write atomically all modifications. Does gitlab-runner keep track of processes that have the configuration file opened for writing? | 09:51 |
| benschubert | If I recall well, it watches the file and will reload the configuration on change | 09:53 |
| benschubert | I usually edit the file on the side, then os.rename it | 09:53 |
| *** catonano has joined #buildstream | 09:59 | |
| Kinnison | If anyone has any views or ideas on correctly solving https://gitlab.com/BuildStream/buildstream/issues/760 given tlater's comment, I'd appreciate it | 10:00 |
| Kinnison | Otherwise I'll probably flail at a solution later | 10:00 |
| valentind | Kinnison, what about sys.stderr.write? | 10:05 |
| Kinnison | valentind: I'm not sure if messages always go to stderr | 10:06 |
| Kinnison | valentind: If they do, then I think you're quite right | 10:06 |
| valentind | I think they go. Look at some test failures, it will show for each command first the "output", and then the "stderr". You can see that status messages go to the stderr, if I recall correctly. | 10:07 |
| valentind | For example: | 10:07 |
| valentind | Program stderr was: | 10:07 |
| valentind | [--:--:--][][] START Loading elements | 10:07 |
| valentind | [00:00:00][][] SUCCESS Loading elements | 10:07 |
| valentind | etc. | 10:07 |
| Kinnison | right | 10:08 |
| Kinnison | so the solution is almost certainly just sys.stderr.write() | 10:08 |
| Kinnison | rather than print() | 10:08 |
| valentind | Kinnison, yes. | 10:08 |
| Kinnison | I'll do that in a little bit then, thanks | 10:09 |
| valentind | Kinnison, If you look in _frontend/app.y, in _message_handler | 10:10 |
| valentind | It calls click.echo with err=True | 10:10 |
| Kinnison | Aye | 10:11 |
| *** jonathanmaw_ has joined #buildstream | 10:29 | |
| *** lachlan has joined #buildstream | 10:30 | |
| *** jonathanmaw has quit IRC | 10:30 | |
| jmac | I haven't had any reviews of https://gitlab.com/BuildStream/buildstream/merge_requests/911 yet - I'm on holiday next week, so I will only be able to properly respond to comments today. | 10:43 |
| Kinnison | jmac: Review done, only 3 minor points, should be easy for you | 10:52 |
| jmac | Yep, those all look valid and straightforward | 10:53 |
| jmac | Thanks for taking a look | 10:53 |
| Kinnison | np, I should have done so before, sorry for being so slow | 10:53 |
| * Kinnison goes back to intricate unpleasant refactoring which will likely be rejected | 10:54 | |
| *** lachlan has quit IRC | 11:15 | |
| Kinnison | benschubert: is !895 ready for me to re-review now? | 11:16 |
| gitlab-br-bot | MR !895: Don't cache sandbox failures https://gitlab.com/BuildStream/buildstream/merge_requests/895 | 11:16 |
| benschubert | Kinnison: yes please! thanks a lot! | 11:17 |
| laurence | Kinnison, benschubert - re this auto-closing issues when an MR lands, I've also just found out that if you create and MR from an issue using the button, that will also close the issue once the MR is merged | 11:18 |
| laurence | so the gitlab workflow doesn't really support what we'd ideally like to do with verification | 11:18 |
| Kinnison | :( | 11:18 |
| laurence | (or, at least, what I see as the ideal) | 11:18 |
| benschubert | oh that explains it, thanks a lot :( | 11:18 |
| laurence | But the whole gitlab policy looks set for a makeover right now, so let's see what we can do there. | 11:19 |
| Kinnison | benschubert: Over-all, looks good. See the one remaining discussion comment :_) | 11:21 |
| *** jonathanmaw_ has quit IRC | 11:27 | |
| *** lachlan has joined #buildstream | 11:37 | |
| *** lachlan has quit IRC | 11:42 | |
| *** alatiera_ has joined #buildstream | 11:42 | |
| benschubert | On WSL, the test "test_cache_size_roundtrip" often just "blocks" any idea? :/ | 11:45 |
| Kinnison | "blocks" implies that you're hitting a situation where a job hits an exception outside of the normal chain of catching | 11:45 |
| Kinnison | I'll bet a pound to a penny that if you turn on asyncio debugging in the environment you might spot something useful | 11:46 |
| benschubert | Oh I see, would you have a link on how to do that? :) | 11:46 |
| Kinnison | https://docs.python.org/3/library/asyncio-dev.html mentions some methods | 11:47 |
| benschubert | thanks! | 11:47 |
| benschubert | And thanks for the review, I updated the code and am waiting for it to pass :) | 11:47 |
| Kinnison | Coolio | 11:48 |
| * Kinnison is battling with Python being too darned dynamic for its own good | 11:48 | |
| *** lachlan has joined #buildstream | 11:50 | |
| *** lachlan has quit IRC | 12:00 | |
| *** lachlan has joined #buildstream | 12:16 | |
| benschubert | https://gitlab.com/BuildStream/buildstream/-/jobs/118520421 :/ segfaults | 12:17 |
| tpollard | urk | 12:18 |
| *** catonano has quit IRC | 12:58 | |
| *** catonano has joined #buildstream | 12:58 | |
| *** lachlan has quit IRC | 13:07 | |
| Kinnison | benschubert: good lord, that's not good | 13:13 |
| Kinnison | benschubert: typically you only get that with grpc horror, but I don't see how that could have happened there | 13:14 |
| *** higgins has joined #buildstream | 13:18 | |
| gitlab-br-bot | danielsilverstone-ct opened MR !944 (danielsilverstone-ct/plugin-destroy-debug-to-stderr->master: plugin.py: Redirect DEBUG from `__del__` to `sys.stderr`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/944 | 13:28 |
| benschubert | Yeah :/ I don't even know how and if to debug this | 13:28 |
| Kinnison | First up, just hit retry and see if it happens again | 13:28 |
| Kinnison | it *might* have been a runner hiccough | 13:28 |
| Kinnison | valentind: If you fancy checking https://gitlab.com/BuildStream/buildstream/merge_requests/944 that'd be super-handy (the Plugin.__del__() thing) | 13:29 |
| gitlab-br-bot | valentindavid approved MR !944 (danielsilverstone-ct/plugin-destroy-debug-to-stderr->master: plugin.py: Redirect DEBUG from `__del__` to `sys.stderr`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/944 | 13:29 |
| gitlab-br-bot | valentindavid merged MR !944 (danielsilverstone-ct/plugin-destroy-debug-to-stderr->master: plugin.py: Redirect DEBUG from `__del__` to `sys.stderr`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/944 | 13:30 |
| *** finn_ has joined #buildstream | 13:32 | |
| benschubert | Doesn't happen again | 13:33 |
| Kinnison | benschubert: :( | 13:33 |
| Kinnison | benschubert: also :-D | 13:33 |
| *** finn has quit IRC | 13:33 | |
| benschubert | Also: https://gitlab.com/BuildStream/buildstream/-/jobs/118530442 do some people also see that test failure in their tests? | 13:33 |
| Kinnison | benschubert: yes | 13:34 |
| Kinnison | see !944 ^^^ | 13:34 |
| gitlab-br-bot | MR !944: plugin.py: Redirect DEBUG from `__del__` to `sys.stderr` https://gitlab.com/BuildStream/buildstream/merge_requests/944 | 13:34 |
| benschubert | oh! thanks! :D | 13:34 |
| benschubert | Are we really using __del__ ? To what purpose in the codebase? | 13:35 |
| Kinnison | debug output | 13:35 |
| Kinnison | just rebase, valentind has merged the fix | 13:35 |
| Kinnison | valentind: thanks for that | 13:35 |
| benschubert | Yep, I'll do that | 13:35 |
| benschubert | Ok so only for debug output so it's not "required" ? (Just thinking that __del__ doesn't guarantee it will ever be called) | 13:37 |
| Kinnison | Correct | 13:40 |
| benschubert | thanks! | 13:42 |
| Kinnison | No problem :-) | 13:43 |
| benschubert | https://gitlab.com/BuildStream/buildstream/merge_requests/895 is out of WIP is some people have time to review (Thanks Kinnison for the early reviews!) | 13:49 |
| *** Daedbffe has joined #buildstream | 13:49 | |
| benschubert | @juergbi or @tlater[m] if you have time :) | 13:50 |
| *** catonano has quit IRC | 13:57 | |
| *** catonano has joined #buildstream | 14:07 | |
| *** finn_ has quit IRC | 14:14 | |
| *** finn has joined #buildstream | 14:14 | |
| *** lachlan has joined #buildstream | 14:27 | |
| Kinnison | Nexus: You should rebase !937 to get rid of that DEBUG error | 14:41 |
| gitlab-br-bot | MR !937: Element path not validated before use https://gitlab.com/BuildStream/buildstream/merge_requests/937 | 14:41 |
| *** alatiera_ has quit IRC | 14:50 | |
| gitlab-br-bot | danielsilverstone-ct approved MR !911 (jmac/cas_to_cas_v2->master: Direct CAS-to-CAS import) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/911 | 14:50 |
| *** lachlan has quit IRC | 14:52 | |
| Nexus | Kinnison: ah thanks | 14:56 |
| *** catonano has quit IRC | 15:02 | |
| *** phildawson_ has quit IRC | 15:05 | |
| *** phildawson_ has joined #buildstream | 15:05 | |
| gitlab-br-bot | jmacarthur closed issue #574 (Add direct CAS-to-CAS import for _casbaseddirectory.py) on buildstream https://gitlab.com/BuildStream/buildstream/issues/574 | 15:25 |
| gitlab-br-bot | jmacarthur merged MR !911 (jmac/cas_to_cas_v2->master: Direct CAS-to-CAS import) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/911 | 15:25 |
| *** catonano has joined #buildstream | 15:39 | |
| jmac | martin: On !900 - what happens while waiting for the first operation? Will SIGTERM bypass the new handler, or will it be ignored? | 15:39 |
| gitlab-br-bot | MR !900: _sandboxremote.py: Add sigterm handler that sends CancelOperation https://gitlab.com/BuildStream/buildstream/merge_requests/900 | 15:39 |
| *** alatiera_ has joined #buildstream | 15:39 | |
| raoul | If I understood how signal blocking works correctly, it should be blocked until it leaves that handler, and then caught by the original handler | 15:40 |
| jmac | So if operation_iterator blocks, then I can't cancel it with ^C anymore? | 15:41 |
| raoul | hmm, maybe it should have a timeout. I've done it so if you get the termination signal at the beginning, you wait until you get the operation name so you can actually attempt to cancel it. | 15:45 |
| jmac | Yeah, that makes sense | 15:46 |
| jmac | Setting self.operation_name to something should be an atomic operation though, so maybe you could just check it in cancel_operation and do nothing if it's None? | 15:48 |
| raoul | Yeah could do that, I guess that depends if you'd prefer buildstream to wait in order to attempt to cancel it | 15:50 |
| jmac | Indeed. I don't know which is the best option. | 15:50 |
| jmac | So, I'll mark it as approved | 15:51 |
| gitlab-br-bot | jmacarthur approved MR !900 (725-job-cancellation-on-remote-builds->master: _sandboxremote.py: Add sigterm handler that sends CancelOperation) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/900 | 15:51 |
| *** dabbill15 has joined #buildstream | 15:52 | |
| jmac | benschubert: I just got the same segfault you did | 15:52 |
| *** toscalix has quit IRC | 15:53 | |
| mablanch | jmac, raoul: I don't know either, I guess I should also be fine to do nothing (not waiting on the first stream message and not cancelling). It's sounds like the server's problem to me. | 15:54 |
| benschubert | jmac: same os? (Debian) | 15:55 |
| *** finn_ has joined #buildstream | 15:55 | |
| *** finn has quit IRC | 15:56 | |
| tpollard | benschubert: yep debian on master | 16:07 |
| benschubert | :/ seems like I'll need a debian vm for that x') | 16:07 |
| jmac | benschubert: Yes | 16:08 |
| tpollard | something landed in buildstream-docker-images? | 16:10 |
| *** lachlan has joined #buildstream | 16:36 | |
| *** lachlan has quit IRC | 16:52 | |
| gitlab-br-bot | BenjaminSchubert opened MR !945 (bschubert/fix-silence-stopiteration-pep-0479->master: source.py: don't let StopIteration propagate to silence() contextmanager) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/945 | 16:52 |
| benschubert | ^ fix for running on python 3.7 :) | 16:52 |
| Kinnison | benschubert: 945 looks plausible to me, but I'd prefer someone more familiar with context managers and python's iterator protocol take a double-checky look | 16:57 |
| Kinnison | WSalmon: perhaps you might? | 16:57 |
| benschubert | Kinnison: no worries :) If you want to understand more about it also, the PEP is a good place to start, but I agree, it took me a while to be sure of my fix | 16:58 |
| Kinnison | I kinda grok it all, but I would feel more comfortable if someone else more experienced in python did it. I consider myself an apprentice pythonista at best | 16:59 |
| * Kinnison thinks a master or expert needs to check | 16:59 | |
| Kinnison | perhaps an adept | 16:59 |
| *** tpollard has quit IRC | 17:00 | |
| *** finn_ has quit IRC | 17:10 | |
| *** tiagogomes has quit IRC | 17:11 | |
| *** finn has joined #buildstream | 17:12 | |
| *** finn has quit IRC | 17:19 | |
| *** finn has joined #buildstream | 17:23 | |
| *** Jimlite has joined #buildstream | 17:24 | |
| gitlab-br-bot | jmacarthur opened MR !946 (jmac/remote_execution_split->master: WIP: Split remote execution from artifact cache) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/946 | 17:28 |
| *** abderrahim has joined #buildstream | 17:28 | |
| *** abderrahim4 has quit IRC | 17:29 | |
| *** catonano has quit IRC | 18:08 | |
| *** lachlan has joined #buildstream | 18:14 | |
| *** ajibade has joined #buildstream | 18:16 | |
| *** rdale has quit IRC | 18:17 | |
| *** ajibade_ has joined #buildstream | 18:37 | |
| *** mathieui has joined #buildstream | 18:42 | |
| *** lachlan has quit IRC | 18:44 | |
| *** ajibade has quit IRC | 19:05 | |
| *** ajibade_ has quit IRC | 19:05 | |
| *** xjuan has joined #buildstream | 19:30 | |
| *** lachlan has joined #buildstream | 19:34 | |
| *** lachlan has quit IRC | 19:43 | |
| *** lachlan has joined #buildstream | 19:57 | |
| *** catonano has joined #buildstream | 20:00 | |
| *** revskill has joined #buildstream | 20:32 | |
| *** lachlan has quit IRC | 20:58 | |
| *** juanalday has joined #buildstream | 21:38 | |
| *** catonano has quit IRC | 21:44 | |
| *** Juan_ has joined #buildstream | 21:46 | |
| *** juanalday has quit IRC | 21:48 | |
| *** xjuan has quit IRC | 22:16 | |
| *** toscalix has joined #buildstream | 22:23 | |
| *** xjuan has joined #buildstream | 22:33 | |
| *** catonano has joined #buildstream | 22:44 | |
| *** Juan_ has quit IRC | 23:10 | |
| *** juanalday has joined #buildstream | 23:10 | |
| *** catonano has quit IRC | 23:13 | |
| *** alatiera_ has quit IRC | 23:36 | |
| *** xjuan has quit IRC | 23:42 | |
| *** juanalday has quit IRC | 23:53 | |
| *** juanalday has joined #buildstream | 23:53 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!