| *** jjardon[m] has joined #buildstream | 00:11 | |
| *** ernestask[m] has joined #buildstream | 00:11 | |
| *** ernestask[m] is now known as Guest45173 | 00:12 | |
| *** m_22[m] has joined #buildstream | 00:24 | |
| *** bochecha has joined #buildstream | 00:28 | |
| *** cgmcintyre[m] has joined #buildstream | 00:49 | |
| *** mattiasb has joined #buildstream | 00:57 | |
| *** waltervargas[m] has joined #buildstream | 01:03 | |
| *** inigomartinez has joined #buildstream | 01:06 | |
| *** connorshea[m] has joined #buildstream | 01:15 | |
| *** pro[m] has joined #buildstream | 01:20 | |
| *** theawless[m] has joined #buildstream | 01:20 | |
| *** alatiera has joined #buildstream | 01:32 | |
| *** asingh_[m] has joined #buildstream | 02:34 | |
| *** abderrahim[m] has joined #buildstream | 02:41 | |
| *** kailueke[m] has joined #buildstream | 02:43 | |
| *** segfault3[m] has joined #buildstream | 02:43 | |
| *** ptomato[m] has joined #buildstream | 03:06 | |
| *** tristan has quit IRC | 03:17 | |
| *** jsgrant_ has joined #buildstream | 03:38 | |
| *** tristan has joined #buildstream | 03:48 | |
| *** jsgrant has joined #buildstream | 03:48 | |
| *** awacheux[m] has joined #buildstream | 04:08 | |
| *** jsgrant has quit IRC | 04:10 | |
| *** jsgrant_ is now known as jsgrant | 04:10 | |
| *** jsgrant_ has joined #buildstream | 04:14 | |
| *** ssssam[m] has joined #buildstream | 05:00 | |
| *** Guest45173 is now known as ernestask[m] | 06:31 | |
| *** tristan has quit IRC | 07:21 | |
| *** ironfoot has quit IRC | 07:55 | |
| *** ironfoot has joined #buildstream | 07:57 | |
| *** toscalix has joined #buildstream | 07:58 | |
| *** dominic has joined #buildstream | 08:13 | |
| gitlab-br-bot | buildstream: issue #313 ("empty /buildstream/build directory when dropping to a shell after a failed build") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/313 | 08:30 |
|---|---|---|
| *** jonathanmaw has joined #buildstream | 08:44 | |
| *** valentind has quit IRC | 08:52 | |
| *** noisecell has joined #buildstream | 09:05 | |
| *** aday has joined #buildstream | 09:10 | |
| gitlab-br-bot | buildstream: merge request (jmac/rename_size_request->master: WIP: Logging widgets: Rename 'size_request' to 'prepare') #382 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/382 | 10:28 |
| jjardon | Hi! can someone review https://gitlab.com/BuildStream/buildstream-docker-images/merge_requests/15 ? for aarch64 docker images :) | 10:38 |
| tlater | Did jmac ask about these recently? | 10:40 |
| tlater | Someone really wanted to run buildstream on aarch64 | 10:41 |
| jmac | I'm actually on armhf but I'll review them anyway | 10:45 |
| jjardon | tlater: I actually need them | 10:48 |
| * tlater just recalled someone else needing other-arch docker images | 10:49 | |
| jjardon | tlater: bst runs just fine in aarch64, but this will improve times in our CI, as we do not have to install aditional packages as part of the CI (we are using stick Fedora27 at the moment) | 10:50 |
| jmac | That was probably me | 10:50 |
| jjardon | stock* | 10:50 |
| gitlab-br-bot | buildstream: merge request (cmake-ninja->master: WIP: plugins/elements/cmake.yaml: allow using ninja instead of make (#279)) #362 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/362 | 11:01 |
| jjardon | does buildstream have aarch64 runners at all? | 11:01 |
| jmac | jjardon: !15 looks good to me, you might want someone else to have a look as well though | 11:02 |
| jjardon | thanks jmac | 11:02 |
| *** tristan has joined #buildstream | 11:07 | |
| tristan | juergbi, sorry I was on my handphone at the time commenting on terminator() issue in https://gitlab.com/BuildStream/buildstream/merge_requests/375 | 11:11 |
| tristan | was that clear enough ? | 11:11 |
| juergbi | tristan: my question is why do we do the fast exit | 11:12 |
| juergbi | wouldn't an exception based approach via sys.exit() be simpler? | 11:12 |
| tristan | the main process explicitly sends sigterm to child processes, which python is not miraculously smart about (it's not like it's going to raise some kind of SIGTERMException) | 11:12 |
| tristan | juergbi, do you know of a way to have a signal handler cause python to raise an exception in it's regular thread of execution wherever it is ? | 11:12 |
| juergbi | aiui, by default Python indeed doesn't do anything smart, however, if you call sys.exit() in the signal handler, it raises SystemExit exception | 11:13 |
| juergbi | and that's raised in the regular context, not just in the signal context, afaict | 11:13 |
| tristan | also, remember that the child threads do long standing calls, they cannot run an event loop to handle the exception | 11:13 |
| tristan | juergbi, nope, we call sys._exit() to avoid this, remember that a SystemExit exception would be raised *in the signal handler* | 11:14 |
| juergbi | yes, it wouldn't be event loop based, it would be based on exception handling | 11:14 |
| tristan | not in the thread of execution | 11:14 |
| tristan | is it raised in regular context ? | 11:14 |
| tristan | juergbi, it could be plausible to rearchitecture everything that way, if it really works | 11:14 |
| juergbi | tristan: see https://stackoverflow.com/a/24574672 | 11:14 |
| tristan | we'd have to make sure it's not also raised in the signal handler | 11:15 |
| juergbi | I don't have first hand experience, though, so maybe I'm missing something | 11:15 |
| juergbi | and multiprocessing.Process already makes sure to call os._exit() to avoid running parent finalizers in the child | 11:15 |
| tristan | I know that we have issues with doing some things in a signal handler, and we really shouldnt be doing anything like initiating any log messages from there | 11:16 |
| tristan | we explicitly sys._exit() to avoid python trying to be smart and cleanly close stuff | 11:16 |
| tristan | juergbi, I have a *very* low level of trust of python doing anything sensible if you try to do much stuff in a signal handler; unless there is some documented thread synchronization where python will somehow raise the exception in the correct thread of execution, and even then; this is experiment at your own risk territory | 11:18 |
| gitlab-br-bot | buildstream: merge request (unused-workspaces->master: _pipeline.py: correct reporting of unused workspace) #363 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/363 | 11:18 |
| tristan | it would certainly be nice to have the sigterm handler raise an exception in the current thread of execution, though | 11:19 |
| tristan | that would allow more clean shutdown; I dont see how python's going to do it without running sneaky threads behind your back, though | 11:19 |
| juergbi | yes, we would definitely have to verify that Python indeed does the right thing here | 11:19 |
| juergbi | it's an interpreter, it could have some global exception flag or whatever | 11:20 |
| tristan | even then, it's very tricky; the code is blocking in long standing calls | 11:20 |
| tristan | right, that would require the interpretor get woken up | 11:20 |
| tristan | by something | 11:20 |
| tristan | which it wont | 11:20 |
| tristan | because it's blocking most probably in subprocess.call( ... bwrap ...) | 11:20 |
| tristan | for a long time | 11:20 |
| juergbi | EINTR works for this | 11:20 |
| juergbi | if it's waiting in waitpid() or similar | 11:21 |
| tristan | ehhh, sounds delicate; you mean we would have to assume that your code is blocking in a system call ? | 11:21 |
| tristan | and not in some cpu intensive C library call ? | 11:21 |
| juergbi | if it's running in Python code, the interpreter doesn't have to be woken up | 11:21 |
| juergbi | yes, CPU intensive C library call wouldn't be covered | 11:21 |
| tristan | I dont think we can make any assumptions about the nature of what long standing task the python interpretor is blocking on | 11:22 |
| juergbi | http://transactional.blog/blog/CPython-Signal-Handling/ | 11:23 |
| juergbi | interesting: | 11:23 |
| juergbi | "When you request for a piece of python code to be registered as a signal handler, CPython registers a function that will add your handler to a queue of events to be handled, sets the interpreter state to try and run the pending actions soon, and then returns." | 11:23 |
| juergbi | i.e., the whole signal handler is queued | 11:23 |
| juergbi | so the issue already exists as is | 11:23 |
| juergbi | this explains how we can raise exception in the regular context | 11:24 |
| juergbi | my proposal should thus strictly be an improvement but it doesn't fix the C library call case | 11:25 |
| tristan | sorry had to step out... it came to mind though that: | 11:36 |
| tristan | <tristan> I dont think we can make any assumptions about the nature of what long standing task the python interpretor is blocking on | 11:36 |
| tristan | this is me misremembering ^^^^^^^^^^ | 11:36 |
| tristan | We can actually make assumptions, because terminator() is entirely private and not called by plugins afair (although I think I originally intended that plugins would have to use it) | 11:37 |
| tristan | juergbi, that statement cannot be true, though as far as I can see | 11:38 |
| tristan | otherwise termination of builds would just not work, but they do work | 11:38 |
| * tristan looks at the blog | 11:38 | |
| juergbi | why wouldn't they work? | 11:38 |
| juergbi | they don't block in cpu-intensive C library calls | 11:39 |
| juergbi | syscalls should be fine | 11:39 |
| tristan | "sets the interpreter state to try and run the pending actions soon, and then returns." | 11:43 |
| tristan | How can the interpreter run the pending action when it's blocking in a system call ? | 11:43 |
| tristan | That means, there is nefarious stuff happening in threads ? | 11:44 |
| juergbi | the system call will return with EINTR | 11:44 |
| juergbi | if automatic restart is not enabled | 11:44 |
| gitlab-br-bot | buildstream: merge request (cmake-ninja->master: WIP: plugins/elements/cmake.yaml: allow using ninja instead of make (#279)) #362 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/362 | 11:44 |
| juergbi | EINTR which is a pain when you have to handle it (read, write, etc.) but is useful in this case | 11:44 |
| tristan | That again sounds strange | 11:45 |
| tristan | because we also use it for suspend | 11:45 |
| juergbi | this means suspend is potentially delayed as well | 11:45 |
| tristan | So when the child process is handling _signals.suspendable(), it will send SIGTSTP to the process tree | 11:46 |
| tristan | juergbi, yes but it works... and it does so without restarting the bwrap call | 11:46 |
| juergbi | bwrap is not a syscall | 11:46 |
| juergbi | waitpid() or similar is | 11:46 |
| tristan | execve() is not a system call ? | 11:46 |
| juergbi | sure but not blocking | 11:46 |
| juergbi | or rather, that's in the child process | 11:46 |
| tristan | of course it's blocking | 11:46 |
| juergbi | in the parent after fork() you run waitpid() or similar | 11:46 |
| juergbi | by default, child runs completely async | 11:47 |
| tristan | ah right | 11:47 |
| tristan | so you think python is internally calling EINTR on itself ? | 11:47 |
| juergbi | EINTR is returned by the kernel syscall | 11:48 |
| tristan | Ahh, when the program receives *any signal* | 11:48 |
| juergbi | python just needs to handle it in case the signal handler _does not_ raise an exception | 11:48 |
| juergbi | yes, when it returns from the signal handler | 11:48 |
| tristan | I dont know, this sounds like a huge refactor, I would like for it to work that way | 11:48 |
| tristan | people are welcome to spend the 2 or 3 weeks testing all the edge cases and experimenting with that | 11:49 |
| juergbi | the thing is that we have race conditions with the current solution | 11:49 |
| tristan | not a huge code change, but a massive behavior change | 11:49 |
| tristan | juergbi, identifying the race conditions seems to me a much lower bar than redesigning job control | 11:50 |
| juergbi | maybe it would make sense to apply it locally and just use it as base branch for regular bst usage for a while | 11:50 |
| tristan | that seems to imply there is already a patch, if so, I'm happy to try it ! | 11:51 |
| juergbi | there isn't but I can take a look, it might be straight forward | 11:52 |
| tristan | Well, it probably implies changing everything that uses _signals.terminator() | 11:52 |
| juergbi | yes but that's like 10 calls | 11:53 |
| juergbi | and most might already have a corresponding finally, in which case we just have to remove the terminator | 11:53 |
| tristan | And I guess it means we register SIGTERM early on and have it raise SystemExit | 11:53 |
| juergbi | indeed | 11:53 |
| tristan | and change all those calls to do except SystemExit: <do the terminator stuff here instead> | 11:53 |
| juergbi | no, use finally | 11:53 |
| juergbi | well, where it makes sense | 11:53 |
| juergbi | have to look at the individual points in code | 11:54 |
| tristan | Right, most cases it doesnt afaik, the mount things came later, I guess they make sense in finally | 11:54 |
| tristan | the reason it exists is originally for forceful termination of child tasks | 11:54 |
| juergbi | I'll take a look. Maybe it's easy but maybe I'm missing something | 11:54 |
| tristan | which itself could be improved | 11:54 |
| tristan | I spent a long time trying to do the regular send SIGTERM first and wait 5 seconds and then SIGKILL | 11:55 |
| tristan | or 10 seconds or whatever arbitrary amount of time | 11:55 |
| tristan | but it's currently violently killing stuff because that was not working well | 11:55 |
| juergbi | PR_SET_PDEATHSIG_PROC would be useful for the forceful termination path. however, it's linux only (and has some caveats) | 11:56 |
| juergbi | eh, PR_SET_PDEATHSIG. the _PROC variant is not in mainline | 11:56 |
| tristan | reaching for the sky :) | 11:57 |
| gitlab-br-bot | buildstream: merge request (jmac/artifact-receive-profiling->master: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/383 | 12:02 |
| gitlab-br-bot | buildstream: merge request (jmac/artifact-receive-profiling->master: WIP: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/383 | 12:03 |
| gitlab-br-bot | buildstream: merge request (tristan/no-cross-junction-default->master: Disable cross junction tracking by default) #384 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/384 | 12:07 |
| tristan | juergbi, so originally we had agreed that project.refs allowing cross junction tracking should probably be disabled by default... I had waited for that expecting to land the addressing of junctioned elements first, but it blew up now that gnome-build-meta depends on freedesktop-sdk | 12:08 |
| tristan | juergbi, https://gitlab.com/BuildStream/buildstream/merge_requests/384 fixes that... | 12:08 |
| tristan | maybe we should discuss semantics of this, though | 12:08 |
| tristan | juergbi, if you care to take a look and give me your opinion on that, that would be great | 12:09 |
| juergbi | will do | 12:09 |
| tristan | I tried to get a patch out quickly for mcatanzaro et al... | 12:09 |
| tristan | I noticed at the same time that we lack coverage for `bst fetch --track` | 12:09 |
| tristan | but I'll treat that separately | 12:09 |
| tristan | probably need a variant of bst build --track across junctions too in tests/frontend/buildtrack.py, which is still ignoring junctions | 12:10 |
| tristan | juergbi, btw, I'm seeing Element._get_full_name() rendering things like: bootstrap-junction.bst:linux-headers.bst | 12:19 |
| tristan | juergbi, when tracking in gnome-build-meta, which only has the freedesktop-sdk-junction.bst | 12:20 |
| tristan | I think that the full name is probably supposed to be freedesktop-sdk-junction.bst:bootstrap-junction.bst:linux-headers.bst | 12:20 |
| tristan | so early computation is failing in that regard it would seem | 12:20 |
| tristan | I'm starting to very much dislike how long these names are, though | 12:21 |
| juergbi | junctions are currently globally keyed by junction name | 12:21 |
| juergbi | if you have multiple foo.bst junctions, they are all coalesced (and if there is no top-level override, an error is raised) | 12:21 |
| tristan | juergbi, I remember commenting that _get_full_name() was not looking as recursive as it should, and I thought your reply was that that part of the naming was resolved earlier at load time | 12:21 |
| juergbi | effective junction names are unique per session | 12:22 |
| juergbi | so there is no need to qualify it | 12:22 |
| juergbi | and in some cases you'd have multiple possibilities otherwise | 12:22 |
| juergbi | and yes, the length would become painfully long | 12:22 |
| tristan | Err, so if I have base.bst as a junction name in gnome-build-meta, and that junctioned project also has base.bst... it will break the moment the project I depend on starts using a different junction name ? | 12:23 |
| tristan | I have been misinforming jonathanmaw in this case, on how we should be supporting addressing, I would have expected to have to type the full path | 12:23 |
| * tristan supposes that we wont be able to get back completions for junctioned elements very well | 12:24 | |
| tristan | *bash completions | 12:24 |
| tristan | maybe if the checkout is close at hand | 12:24 |
| juergbi | hm, yes, may be tricky for completions | 12:27 |
| juergbi | to be honest, I actually want to add some more flexibility there | 12:27 |
| juergbi | however, that's the current semantics | 12:27 |
| juergbi | the reason is to properly handle the case where two subprojects have a common subsubproject | 12:28 |
| juergbi | you normally don't want two instances of the subsubproject | 12:28 |
| tristan | Hmm | 12:29 |
| tristan | yeah this deserves more exploration | 12:29 |
| juergbi | your MR: it looks fine to me but I haven't touched the plan stuff in a while, so I'm hopefully not missing anything | 12:30 |
| tristan | regarding completions, if the checkout is close we might be able to do it, but seeing how slow things are getting for simple bst shell commands I'm already trying to consider some additional local state | 12:30 |
| tristan | juergbi, regarding the MR; I was more thinking about semantics of this, and if you have some ideas how it might jibe with future additions of junctioned element addressing | 12:31 |
| tristan | like, will it be confusing that there is `--track-cross-junction`... but also the ability to explicitly pass `--track junction.bst:element.bst` ? | 12:31 |
| tristan | Should we ignore disabled cross junction tracking ? | 12:31 |
| tristan | Should we rename the option... to reflect that it only has to do with recursion ? | 12:32 |
| tristan | Maybe the word "cross" is enough to express that ? | 12:32 |
| juergbi | difficult to say for me in an abstract discussion | 12:33 |
| juergbi | unfortunately, I might only know the answer once I've used it... | 12:33 |
| juergbi | I would expect 'cross' to suffice | 12:34 |
| juergbi | directly tracking junctioned element will work without having to specify track-cross-junction, right? | 12:35 |
| gitlab-br-bot | buildstream: merge request (tristan/no-cross-junction-default->master: Disable cross junction tracking by default) #384 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/384 | 12:39 |
| tristan | juergbi, that's what I was not entirely sure about... what the natural approach should be :-S | 12:39 |
| tristan | but I guess that it should work without having to specify it | 12:39 |
| tristan | without implying it | 12:40 |
| tristan | which might be difficult | 12:40 |
| juergbi | yes, this is what I'd expect as a user, I think | 12:40 |
| tristan | juergbi, i.e. it would make sense, if say in `bst build --track foo.bst --track junction.bst:bar.bst` .. then we recursively track foo.bst *until a junction*, and recursively track junction.bst:bar.bst *until it hits a recursive junction* | 12:41 |
| tristan | so the behavior is *still* different if you pass -J / --track-cross-junctions ? | 12:41 |
| tristan | we will need an overhaul of selection of elements in a pipeline with addressing of cross junctions, certainly | 12:42 |
| tristan | ideally we can have all of that code in one place, and we only really need to test these selections with `bst show` | 12:43 |
| tristan | juergbi, ok anyway for the time being I'm convinced that a switch to turn it on and making it disabled by default right now, is most pressing | 12:44 |
| tristan | jmac, I pushed a fix to master for the abbreviations of logfile regressions by the way | 12:44 |
| tristan | MessageOrLogFile was just missing it's size_request() | 12:44 |
| jmac | Oh. That's what !382 was for | 12:46 |
| juergbi | tristan: yes, that's my current line of thoughts. tbh, as a user I would likely use two bst track invocations instead | 12:46 |
| tristan | Hrrrrrmmmm sorry :-( | 12:49 |
| tristan | jmac, I'm under a downpour of emails :-( | 12:49 |
| jmac | No problem. If you think the name change is appropriate I'll make that as a separate request. | 12:50 |
| tristan | I see it's just from a couple of hours ago | 12:50 |
| tristan | jmac, you can do that if you like... to be honest it was a weekend writeup all that logging code | 12:51 |
| tristan | the intention was to do size requests and some terminal width aware rendering, which would require LogLine to have some idea of the size of the widgets | 12:51 |
| tristan | and which ones have natural vs minimum sizes | 12:51 |
| tristan | might still be interesting to render the lines twice (second time only if `bst --log-file` is specified), and allow ellipsize of element names which are getting too long | 12:52 |
| tristan | maybe conditionally wrapping the trailing message part onto a new indented line in the cases where they dont fit | 12:53 |
| tristan | jmac, anyway that was the direction I was headed; I wanted nicely columnized readable lines; and huuuuuuuuge.bst element names are completely breaking that :'( | 12:53 |
| jmac | OK | 12:54 |
| tristan | jmac, but I dont mind changing that to 'prepare', since the current code doesnt do that at all :) | 12:54 |
| tristan | actually the reason we pass the pipeline in there, is because it's what contains the list of elements, which lets us know how long the biggest element is going to be | 12:55 |
| tristan | but we didnt end up using that, because they are just tooooo long :( | 12:55 |
| tristan | jmac, perhaps if we dont need it, we could remove pipeline from there completely, I think there is a stray thing which wants to grab the context or the project pointer off of the pipeline, which makes initialization of the logger weird and gross | 12:56 |
| tristan | anyway, I've noticed you've done some refactoring around there and appreciate it, so I'll okay any cleanup patches you have :) | 12:56 |
| gitlab-br-bot | buildstream: merge request (jmac/rename_size_request->master: WIP: Logging widgets: Rename 'size_request' to 'prepare') #382 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/382 | 12:57 |
| jmac | The pipeline is where we get logdir from, which is what inspired me to change it | 12:57 |
| gitlab-br-bot | buildstream: issue #354 ("Allow configuring an element to not be tracked by --track-all") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/354 | 12:58 |
| gitlab-br-bot | buildstream: merge request (tristan/no-cross-junction-default->master: Disable cross junction tracking by default) #384 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/384 | 12:58 |
| tristan | jmac, but logdir comes from the context | 12:58 |
| tristan | jmac, the context is available in initialization way earlier than the pipeline, which is sometimes never available | 12:59 |
| * tristan gotta change location | 12:59 | |
| tristan | jmac, unable to rebase your 382 with the UI it seems :-/ | 13:00 |
| tristan | I'll okay it once I get to home... | 13:00 |
| jmac | No, leave !382 for now | 13:00 |
| *** tristan has quit IRC | 13:03 | |
| gitlab-br-bot | buildstream: merge request (richardmaw/fix-unit-test-hang-on-crash->master: Fix unit tests hanging when there's an exception in a sandbox run) #375 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/375 | 13:08 |
| *** tristan has joined #buildstream | 13:13 | |
| tristan | jmac, I have a rebase locally of 382, shall I just push it ? | 13:16 |
| tlater | tristan: I think I'm going to need a bit more guidance on the scheduler change - what I've been doing so far a) causes hangs and b) doesn't actually end up being a nice interface. | 13:16 |
| tristan | jmac, oops, I just saw your message in the irc logs, I'll leave it for now :) | 13:17 |
| jmac | Yeah, I was just thinking about the point that context doesn't need to come from pipeline so I was going to have a longer think about it | 13:18 |
| tristan | Yeah, it would be nice to factor out that pipeline for now entirely if we can | 13:20 |
| tristan | I think we only need it for print_heading() and print_summary() | 13:20 |
| tristan | which we could do in a separate class (or file even) | 13:21 |
| skullman | https://gitlab.com/BuildStream/buildstream/merge_requests/375 passes tests and I couldn't reproduce the errors I got earlier after running in a loop for hours | 13:21 |
| gitlab-br-bot | buildstream: merge request (jmac/artifact-receive-profiling->master: WIP: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/383 | 13:24 |
| tristan | skullman, while I think juergbi's experiment is a nice thing to try, I think your patch there is clearly an improvement anyway... | 13:25 |
| gitlab-br-bot | buildstream: merge request (richardmaw/fix-unit-test-hang-on-crash->master: Fix unit tests hanging when there's an exception in a sandbox run) #375 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/375 | 13:25 |
| tristan | so set to merge | 13:26 |
| * skullman waits for the next non-deterministic test failure to prevent it being merged | 13:26 | |
| tristan | :) | 13:26 |
| tristan | oddly, it's very rare we get those in CI | 13:27 |
| skullman | I've had an unlucky year to far, so it figures that they'd happen to me. | 13:28 |
| * tristan still has trouble with test_push_pull, and saw it hang once today | 13:28 | |
| tristan | it hangs almost once a day for me, test_push_pull; yes: it's very bad | 13:28 |
| tristan | eeeek, I introduced a horrible bug it seems :'( | 13:34 |
| *** tristan has quit IRC | 13:38 | |
| gitlab-br-bot | buildstream: issue #298 ("Unix integration tests not unmounting on crash") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/298 | 13:39 |
| gitlab-br-bot | buildstream: merge request (richardmaw/fix-unit-test-hang-on-crash->master: Fix unit tests hanging when there's an exception in a sandbox run) #375 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/375 | 13:39 |
| *** tristan has joined #buildstream | 13:51 | |
| gitlab-br-bot | buildstream: merge request (jmac/artifact-receive-profiling->master: WIP: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/383 | 14:01 |
| *** noisecell has quit IRC | 14:03 | |
| *** tristan has quit IRC | 14:12 | |
| gitlab-br-bot | buildstream: merge request (cmake-ninja->master: plugins/elements/cmake.yaml: allow using ninja instead of make (#279)) #362 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/362 | 14:13 |
| jmac | If I've got a line longer than 119 characters, do I have to mark it with both # nopep8 and # pylint: disable... ? | 14:15 |
| jmac | E.g. this one passes pep8 but not pylint https://gitlab.com/BuildStream/buildstream/-/jobs/62627309 | 14:16 |
| jmac | Er, passes pylint but fails pep8 | 14:16 |
| tlater | jmac: They should both fail | 14:17 |
| gitlab-br-bot | buildstream: merge request (unused-workspaces->master: _pipeline.py: correct reporting of unused workspace) #363 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/363 | 14:18 |
| tlater | I do think you'll have to mark it with both | 14:18 |
| gitlab-br-bot | buildstream: merge request (cmake-ninja->master: plugins/elements/cmake.yaml: allow using ninja instead of make (#279)) #362 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/362 | 14:18 |
| tlater | Never attempted what the actual format for that would be though | 14:18 |
| tlater | Perhaps # nopep8 pylint: disable=* ? | 14:18 |
| jmac | I'll try it | 14:19 |
| gitlab-br-bot | buildstream: merge request (cmake-ninja->master: plugins/elements/cmake.yaml: allow using ninja instead of make (#279)) #362 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/362 | 14:22 |
| jmac | tlater: Yes, that does appear to work, locally at least | 14:23 |
| tlater | Nice, now we know what to do in that case, too :) | 14:23 |
| gitlab-br-bot | buildstream: merge request (jmac/artifact-receive-profiling->master: WIP: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/383 | 14:24 |
| *** tristan has joined #buildstream | 14:30 | |
| tristan | How come I'm spending time "Initializing remote caches", when I've clearly commented out the artifacts from the project and from my buildstream.conf... ? | 14:34 |
| tristan | OH! | 14:34 |
| tristan | because junctions | 14:34 |
| tristan | We need an option to explicitly disable a cache | 14:34 |
| gitlab-br-bot | buildstream: merge request (richardmaw/build-status-extensions->master: Print summary of failed builds) #329 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/329 | 14:34 |
| jmac | !383 is a small change if anyone has a few minutes spare to review | 14:39 |
| *** noisecell has joined #buildstream | 14:45 | |
| skullman | looks sensible to me at a glance, feels like the comment about ForceCommand is missing context about how it's otherwise used so I'm not sure of its value, I'll have to read up on how the profiling stuff works to comment further | 14:45 |
| jmac | skullman: It's a modification to the normal ForceCommand listed in doc/source/artifacts.rst | 14:46 |
| skullman | ta, I'll take a look at that for context | 14:47 |
| jmac | We don't document BST_PROFILE in normal documentation, hence my shoving that example in a comment. | 14:49 |
| tristan | jmac, note that I made a misguided comment in an MR at one point, I am absolutely OK with documenting secret internal env vars when it is done in HACKING.rst | 14:50 |
| tristan | that is what HACKING.rst is sort of about, it's not user facing or API | 14:50 |
| jmac | OK, in which case I'll consider moving that comment | 14:51 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-cross-junction-disaster->master: Fix the cross junction disaster) #385 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/385 | 15:03 |
| tristan | Ok, crisis averted | 15:04 |
| gitlab-br-bot | buildstream: merge request (element-prepare->master: Prevent configure commands from running more than once in incremental workspace builds) #386 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/386 | 15:15 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-cross-junction-disaster->master: Fix the cross junction disaster) #385 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/385 | 15:15 |
| gitlab-br-bot | buildstream: merge request (element-prepare->master: Prevent configure commands from running more than once in incremental workspace builds) #386 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/386 | 15:20 |
| gitlab-br-bot | buildstream: merge request (element-prepare->master: Prevent configure commands from running more than once in incremental workspace builds) #386 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/386 | 15:23 |
| tlater | Would someone mind having a look at that MR? | 15:23 |
| gitlab-br-bot | buildstream: merge request (richardmaw/build-status-extensions->master: Print summary of failed builds) #329 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/329 | 15:24 |
| tristan | tlater, I dont have time tonight, just made a tiny comment | 15:28 |
| tristan | tlater, I'll try to give it a run through tomorrow, looks like it's one of the integral pieces of incremental builds we discussed | 15:29 |
| tlater | tristan: Thanks :) | 15:29 |
| * tlater was hoping to close #209 with it | 15:30 | |
| *** tristan_ has joined #buildstream | 15:32 | |
| *** tristan has quit IRC | 15:32 | |
| gitlab-br-bot | buildstream: merge request (jmac/artifact-receive-profiling->master: WIP: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/383 | 15:35 |
| *** tristan_ has quit IRC | 15:35 | |
| gitlab-br-bot | buildstream: merge request (jmac/artifact-receive-profiling->master: WIP: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/383 | 15:42 |
| *** jsgrant_ has quit IRC | 15:44 | |
| gitlab-br-bot | buildstream: merge request (element-prepare->master: Prevent configure commands from running more than once in incremental workspace builds) #386 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/386 | 15:46 |
| *** tristan_ has joined #buildstream | 15:54 | |
| gitlab-br-bot | buildstream: merge request (element-prepare->master: Prevent configure commands from running more than once in incremental workspace builds) #386 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/386 | 16:04 |
| gitlab-br-bot | buildstream: merge request (richardmaw/build-status-extensions->master: Print summary of failed builds) #329 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/329 | 16:07 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 16:09 |
| gitlab-br-bot | buildstream: merge request (jmac/artifact-receive-profiling->master: WIP: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/383 | 16:11 |
| *** jsgrant__ has joined #buildstream | 16:13 | |
| gitlab-br-bot | buildstream: merge request (jmac/artifact-receive-profiling->master: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/383 | 16:15 |
| *** Prince781 has joined #buildstream | 16:19 | |
| *** toscalix has quit IRC | 16:27 | |
| *** noisecell has quit IRC | 16:40 | |
| *** jonathanmaw has quit IRC | 17:02 | |
| *** tristan_ has quit IRC | 17:06 | |
| jjardon | Hi, can someone check the info at https://gitlab.com/BuildStream/buildstream/issues/353 is correct? | 17:21 |
| jmac | I can't think of anything else | 17:23 |
| *** tristan_ has joined #buildstream | 17:24 | |
| *** dominic has quit IRC | 17:55 | |
| gitlab-br-bot | buildstream: merge request (richardmaw/build-status-extensions->master: Print summary of failed builds) #329 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/329 | 18:03 |
| *** solid_black has joined #buildstream | 18:08 | |
| gitlab-br-bot | buildstream: issue #247 ("Print summary of failed modules when there is a build failure") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/247 | 18:19 |
| gitlab-br-bot | buildstream: merge request (richardmaw/build-status-extensions->master: Print summary of failed builds) #329 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/329 | 18:19 |
| *** Prince781 has quit IRC | 18:33 | |
| *** valentind has joined #buildstream | 18:56 | |
| *** Prince781 has joined #buildstream | 19:03 | |
| gitlab-br-bot | buildstream: merge request (jjardon/getting_started->master: Add getting started section) #323 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/323 | 19:08 |
| *** Prince781 has quit IRC | 19:14 | |
| *** tristan_ has quit IRC | 19:28 | |
| *** solid_black has quit IRC | 19:52 | |
| *** aday has quit IRC | 20:27 | |
| *** cs_shadow has quit IRC | 20:31 | |
| *** Prince781 has joined #buildstream | 20:55 | |
| *** Prince781 has quit IRC | 21:16 | |
| gitlab-br-bot | buildstream: issue #355 ("Add a "cache" command to bst") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/355 | 21:29 |
| gitlab-br-bot | buildstream: merge request (jjardon/ci_fedora_27->master: Run test in Fedora27, apart from Debian 8) #378 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/378 | 22:10 |
| gitlab-br-bot | buildstream: merge request (jjardon/ci_fedora_27->master: Run test in Fedora27, apart from Debian 8) #378 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/378 | 22:16 |
| *** Prince781 has joined #buildstream | 22:57 | |
| *** Prince781 has quit IRC | 22:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!