| *** jude has joined #buildstream | 07:12 | |
| *** jonathanmaw has joined #buildstream | 08:24 | |
| *** tlater has joined #buildstream | 08:41 | |
| *** ssam2 has joined #buildstream | 09:06 | |
| *** tristan has joined #buildstream | 09:22 | |
| *** ChanServ sets mode: +o tristan | 09:22 | |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: Artifacts documentation: Fixed a little typo) https://gitlab.com/BuildStream/buildstream/commit/917a1b9f54a2ec2342b91bdca4fb10f66bbfa6cf | 09:40 |
|---|---|---|
| juergbi | tristan: i currently don't encode the key strength into the ostree ref itself, i.e., both still follow the format project/element/key | 09:41 |
| juergbi | for elements without dependencies, the weak and the strong key and therefore the ref will actually match | 09:41 |
| juergbi | i don't see an issue with this and would keep it this way. unless you can think of an issue | 09:41 |
| tristan | juergbi, that sounds fine to me | 09:42 |
| juergbi | ok, ta | 09:42 |
| tristan | I think it would be nice to know, when building in weak planning mode... whether the strong key is the same as it would have been in strong planning mode | 09:42 |
| tristan | but it's mostly a speculative desire to know that | 09:43 |
| tristan | seems interesting :) | 09:43 |
| tristan | as it can accidentally be the same in many cases, and can be interesting to know | 09:43 |
| tristan | tlater, juergbi... since you guys are not on anything specific project-data wise, I would like for both of you to be testing with https://gnome7.codethink.co.uk/gnome-modulesets.git | 09:46 |
| tristan | instead of some branch of buildstream-tests, if you're not using that already | 09:46 |
| tristan | tlater, also, you could send me your public ssh key and become an authorized pusher to the GNOME artifact cache | 09:47 |
| tlater | Ok | 09:48 |
| tristan | fwiw: The master branch is an untracked conversion of GNOME modulesets which happens every 10 minutes | 09:48 |
| tristan | The "tracked" has commits with all tracked sources, and is updated... every 2 hours I think | 09:49 |
| tristan | with the "tracked" branch one can refer to a commit sha and other people should be able to reproduce exactly the same output | 09:49 |
| juergbi | ok, will switch to that | 09:49 |
| * tristan currently has 1cb9e7b3b0a1dda9414bc7fed694ec7b4433fc0c | 09:49 | |
| tristan | haha, oh crap ;-) | 09:51 |
| tristan | Ok /me fixes the authorized keys | 09:51 |
| tristan | easy to break | 09:51 |
| tlater | tristan: None of the simple gnome-moduleset elements seem to have archs :/ | 09:53 |
| juergbi | regarding key display, yes, i agree. trying to wrap my head around how this should work given that there quite a few key variants in place now and not all may be known at the beginning of the session | 09:53 |
| tristan | tlater, there is only the base system, which chooses the base runtime to build on | 09:54 |
| tristan | tlater, you need arch conditionals ? | 09:55 |
| tlater | Well, I'd like to make sure this branch doesn't break stuff somehow. | 09:55 |
| tristan | tlater, they will probably come, but hopefully they should remain unneeded as much as possible | 09:55 |
| juergbi | tar source at core-deps/mozjs38.bst [line 3 column 2]: Error mirroring https://people.mozilla.org/~sstangl/mozjs-38.2.1.rc0.tar.bz2: <urlopen error [Errno 111] Connection refused> | 09:55 |
| tristan | tlater, oh *that* ? you mean how the arguments are parsed ? | 09:55 |
| tristan | tlater, dont worry about that | 09:55 |
| tristan | eh, that can happen | 09:56 |
| juergbi | also got this, though | 09:56 |
| juergbi | ostree source at base/base-system.bst [line 5 column 6]: Failed to fetch ref '9136b273bebba1316268fe943fbbc39b13fe104bd2a1b2a387117e9e2a83b0da' from origin: https://gnome7.codethink.co.uk/repo | 09:56 |
| juergbi | Failed to fetch ref '9136b273bebba1316268fe943fbbc39b13fe104bd2a1b2a387117e9e2a83b0da' from 'origin': Socket I/O timed out | 09:56 |
| tristan | sigh, so we're not out of the woods ! | 09:57 |
| gitlab-br-bot | push on buildstream@arch_options (by Tristan Maat): 1 commit (last: main.py: Move --arch* options to the main command) https://gitlab.com/BuildStream/buildstream/commit/45d3be971aac9ad138a8c1438a6b7b0e70d59451 | 09:57 |
| tristan | I haven't fetched sources in a while; I regularly nuke my artifact cache but not the sources; cause they take a long time | 09:57 |
| juergbi | makes sense | 09:57 |
| tristan | But downloading from the remote used to work quite stably | 09:57 |
| tristan | I think originally I was downloading alot from sdk.gnome.org | 09:58 |
| tristan | possibly gnome7 is under duress | 09:58 |
| tristan | For artifact cache config: | 09:59 |
| tristan | artifacts: | 09:59 |
| tristan | pull-url: https://gnome7.codethink.co.uk/artifacts | 09:59 |
| tristan | push-url: artifacts@gnome7.codethink.co.uk:artifacts | 09:59 |
| tristan | tlater, and in your ~/.ssh/config... you need: | 09:59 |
| juergbi | not compatible with the artifacts (metadata) required by my branch | 09:59 |
| tristan | Host gnome7.codethink.co.uk | 09:59 |
| tristan | Port 10007 | 09:59 |
| tristan | Hmmm | 10:00 |
| tlater | Thanks :) | 10:00 |
| juergbi | that reminds me, we really need the cache key versioning | 10:00 |
| tristan | juergbi, ok so... we need artifact revisioning for this kind of thing | 10:00 |
| juergbi | :) | 10:00 |
| tristan | juergbi, yeah, I wrote an email to the list with thoughts on all kinds of revisions, not long ago | 10:00 |
| juergbi | yes, i saw that but haven't really looked into the details yet | 10:01 |
| tristan | yeah it's a bit complicated because plugins | 10:01 |
| gitlab-br-bot | buildstream: merge request (arch_options->master: main.py: Move --arch* options to the main command) #52 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/52 | 10:01 |
| gitlab-br-bot | push on buildstream@arch_options (by Tristan Maat): 3 commits (last: utils.py: Fix _tempdir for python3.4) https://gitlab.com/BuildStream/buildstream/commit/eecec59a93fba04fd9b84e474cf4237aea35ff16 | 10:02 |
| gitlab-br-bot | buildstream: merge request (arch_options->master: main.py: Move --arch* options to the main command) #52 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/52 | 10:02 |
| gitlab-br-bot | push on buildstream@arch_options (by Tristan Maat): 1 commit (last: main.py: Move --arch* options to the main command) https://gitlab.com/BuildStream/buildstream/commit/580b2f331aa1db716f72b7aa57ef463fdc1db588 | 10:04 |
| gitlab-br-bot | buildstream: merge request (arch_options->master: main.py: Move --arch* options to the main command) #52 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/52 | 10:04 |
| tlater | Can I add a test that ensures permissions are 644? x) | 10:05 |
| tlater | Actually, pre-commit hooks can probably do that | 10:05 |
| tristan | tlater, there are some things we want executable | 10:06 |
| tristan | tlater, but I think they are quite limited, one of them is setup.py | 10:06 |
| tristan | also doc/sphinx-build3 needs exec | 10:06 |
| tristan | but looks like thats part of the weird docs building hack that would be nice to remove, we shouldnt be touching python 2 interpretors at all | 10:07 |
| tlater | I'll just hack a script locally for now ;) | 10:07 |
| tlater | Looks like this passes fine: https://gitlab.com/BuildStream/buildstream/merge_requests/52/pipelines | 10:28 |
| tristan | tlater, did you get my comment ? | 10:29 |
| tristan | To be honest, I also overlooked some of the wording of the arches stuff, but that was there since ssam2 put it anyway | 10:29 |
| tlater | Ah, alright | 10:30 |
| tristan | "Architecture of the machine running the build" for --arch is just misleading | 10:30 |
| tristan | Maybe we should take this opportunity to correct these strings | 10:31 |
| ssam2 | oops, yes I meant to change that | 10:31 |
| tlater | Hm, how woudl you word that? | 10:31 |
| tristan | Ok so... for --target-arch "Produce elements that execute on this architecture" | 10:31 |
| tristan | I think it can be more readable with "Machine architecture for build output" | 10:32 |
| tristan | That way we can take --host-arch and say "Machine architecture for the sandbox", or "Machine architecture for build input" | 10:33 |
| tristan | because "Run as a native build for the given architecture" isnt really meaningful... to me at least | 10:33 |
| tlater | I like the sandbox one, it explains what "build input" is | 10:33 |
| ssam2 | yes that sounds better | 10:34 |
| tristan | Then --arch "Architecture of the machine running the build" can just be "Machine architecture", leave it ambiguous, it's anyway clarified by the other two which say "(defaults to --arch)" | 10:34 |
| tristan | Ok agreed for the sandbox thing | 10:35 |
| tristan | Ok I'm comfortable with those strings, unless there are objections in the next few seconds... tlater just roll with those | 10:36 |
| tristan | I'm still not _entirely_ clear about what this is going to mean for running full pipelines with virtualization capable sandboxes | 10:37 |
| tristan | but it makes sense for what we do with it now anyway | 10:38 |
| tristan | and we'll just have to learn from experimentation when we get there | 10:38 |
| * tristan is tempted to add a push-port to the artifacts configuration | 10:39 | |
| * tristan doesnt like sneaking into users' .ssh/config files | 10:39 | |
| tlater | My linter shows an error on line 844 of main.py - There's a format string with too many arguments there. Not sure what the string is supposed to be, but that should probably be fixed? | 10:41 |
| tristan | tlater, good call | 10:46 |
| tristan | it's on a different line here though | 10:46 |
| tlater | Probably additions by me | 10:47 |
| tristan | tlater, anyway just keep self.file_count | 10:48 |
| tristan | on that line | 10:48 |
| gitlab-br-bot | push on buildstream@arch_options (by Tristan Maat): 3 commits (last: main.py: Move --arch* options to the main command) https://gitlab.com/BuildStream/buildstream/commit/9e45372c687afd0dc378c36742dfe782912eb48a | 10:55 |
| gitlab-br-bot | buildstream: merge request (arch_options->master: main.py: Move --arch* options to the main command) #52 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/52 | 10:55 |
| gitlab-br-bot | push on buildstream@arch_options (by Tristan Maat): 3 commits (last: main.py: Move --arch* options to the main command) https://gitlab.com/BuildStream/buildstream/commit/86578b928f29697b26ab025278f7104d590974ff | 10:59 |
| gitlab-br-bot | buildstream: merge request (arch_options->master: main.py: Move --arch* options to the main command) #52 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/52 | 10:59 |
| tristan | oh weird, did I mess something up with artifacts ? | 11:02 |
| tristan | suddenly I cant push ? | 11:02 |
| * tristan fixes | 11:03 | |
| gitlab-br-bot | push on buildstream@workspaces (by Tristan Maat): 9 commits (last: utils.py: Fix _tempdir for python3.4) https://gitlab.com/BuildStream/buildstream/commit/eecec59a93fba04fd9b84e474cf4237aea35ff16 | 11:08 |
| gitlab-br-bot | buildstream: merge request (workspaces->master: Workspaces) #50 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/50 | 11:08 |
| tlater | tristan: For the `workspace list` command, should there be a target? It would make sense just to display all workspaces in the project. | 11:16 |
| tristan | tlater, agreed, no target | 11:19 |
| gitlab-br-bot | buildstream: merge request (arch_options->master: main.py: Move --arch* options to the main command) #52 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/52 | 11:23 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 3 commits (last: main.py: Move --arch* options to the main command) https://gitlab.com/BuildStream/buildstream/commit/86578b928f29697b26ab025278f7104d590974ff | 11:23 |
| tristan | freaky | 11:27 |
| tristan | So now that I had 'ForceCommand bst-artifacts-receive' in the /etc/sshd_config... it wont take any arguments I give it | 11:28 |
| tristan | like... ForceCommand has to specify more than just the program I'm gonna run, but also the arguments ? | 11:28 |
| tristan | That strict ? | 11:28 |
| tristan | Also... | 11:28 |
| tristan | Now that I am commenting it out... it's *still* not working | 11:29 |
| tristan | After systemctl restart sshd... it retains the same behavior | 11:29 |
| tristan | So that means... yesterday when I added "ForceCommand bst-artifacts-receive" and restarted sshd... | 11:29 |
| tristan | I actually broke it | 11:29 |
| tristan | but it kept working for a while, because it looks like... some unknown cosmic dust needs to be sprinkled on the sshd server | 11:30 |
| tristan | which happens, at some unknown time | 11:30 |
| tristan | juergbi, you seem to be the one who has any clue about sshd, any idea what's going on ? | 11:31 |
| juergbi | tristan: do you use a control master on the client and might this still be running with the old sshd? | 11:32 |
| tristan | Also, is there a way to do "ForceCommand bst-artifact-receive *" or something ? | 11:32 |
| tristan | Ahhh | 11:32 |
| tristan | That can be the problem yes | 11:32 |
| tristan | its on my side | 11:32 |
| juergbi | tristan: ForceCommand, maybe try this: http://at.magma-soft.at/sw/blog/posts/The_Only_Way_For_SSH_Forced_Commands/ | 11:33 |
| juergbi | (wrapper script that feeds back the arguments) | 11:34 |
| tristan | Oh weird | 11:34 |
| tristan | ForceCommand actually takes whatever command I send to ssh | 11:34 |
| tristan | and runs that command *instead* | 11:34 |
| tristan | it doesnt say "Only allowed to run this command you idiot" | 11:35 |
| juergbi | yep | 11:35 |
| tristan | :-/ | 11:35 |
| juergbi | you get the SSH_ORIGINAL_COMMAND env variable instead | 11:35 |
| tristan | So it would be nice to have some flexibility, but I guess that's not a feature of ssh | 11:35 |
| juergbi | so a wrapper script can do whatever you want | 11:35 |
| juergbi | but it doesn't appear to be built-in | 11:35 |
| tristan | okay | 11:35 |
| tristan | So I'll amend the docs for this | 11:36 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 3 commits (last: _artifactcache/pushreceive.py: Changing up the bst-artifact-receive options) https://gitlab.com/BuildStream/buildstream/commit/cd781089d2be66c79837f59355b0710f7bb09b53 | 12:00 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: Update man pages for new placement of arch parameters) https://gitlab.com/BuildStream/buildstream/commit/fc7eb1d5cbaa448a6c6df9da78fe582a665235fd | 12:02 |
| tristan | juergbi, ok so... I think you are changing the UI a bit for the weak keys and suchlike... I just wanted to say; that I'm concerned for the regular log lines; I think the log lines should continue to only display either the strong or weak abbreviated key (depending on build mode) | 12:05 |
| tristan | because those lines... I dont want them to be too long | 12:06 |
| tristan | juergbi, I hope that we can restrict this to LogLine.show_pipeline() | 12:06 |
| juergbi | yes, for build logs i'm planning to use the abbreviated strong key of the actual build (i.e., the same that gets stored in metadata, may be different from the strong key in strong build planning mode) | 12:07 |
| tristan | Ah well that's alright too | 12:07 |
| juergbi | unfortunately, we may not know that key yet in earlier stages | 12:07 |
| juergbi | so we'd either first have to display/use the weak key or no key at all | 12:08 |
| tristan | Yes, currently with tracking queues enabled they default to ???????? | 12:08 |
| tristan | true | 12:08 |
| juergbi | yes, one option is to do the same before we're sure about the key we actually use | 12:08 |
| juergbi | alternative would be to first display the weak key but this may also be confusing | 12:09 |
| juergbi | (i.e., displayed key changing in the session) | 12:09 |
| tristan | Right, well I think that if you are going to show strong key all the time it probably wont change the code that much ? | 12:09 |
| tristan | I.e. in weak planning mode; strong keys get resolved based on the dependencies which will be built against, correct ? | 12:09 |
| tristan | Right I'd rather stay with, if keys change, they change from ???????? -> real key | 12:10 |
| juergbi | one source of possible confusion that we essentially have two strong keys. one is the ideal strong key, i.e., as per strong build planning mode. the other is what you just described | 12:10 |
| tristan | true | 12:10 |
| tristan | heh | 12:10 |
| juergbi | as buildstream will still attempt to pull the artifact using the ideal strong key even in weak build planning mode | 12:11 |
| juergbi | at first, that is. it will fall back to weak key | 12:11 |
| tristan | That makes sense | 12:11 |
| juergbi | we actually have a third strong key | 12:11 |
| juergbi | the one embedded in the artifact that was downloaded using the weak key | 12:11 |
| tristan | Right | 12:12 |
| tristan | Whoa, mind boggling | 12:12 |
| tristan | So I guess the ultimate strong key is whatever it was built against, in weak mode | 12:12 |
| juergbi | yes | 12:12 |
| tristan | And I guess that we want to make an attempt to download strong ideal artifacts even when we have weak artifacts present | 12:12 |
| juergbi | yes, that's how i implemented it | 12:13 |
| tristan | So I guess we want to resolve as late as possible, just like with tracking enabled | 12:13 |
| juergbi | that ultimate key, yes | 12:13 |
| tristan | juergbi, ok well; I am going to add something of a session summary when a pipeline completes | 12:14 |
| tristan | So it *could* be augmented to repeat the LogLine.show_pipeline() again at the end | 12:14 |
| tristan | My plan was just to clean things up and show what was processed/skipped/failed for each queue | 12:14 |
| juergbi | to show what has the ideal strong key in the end? | 12:14 |
| tristan | and have only one path for that, instead of those custom messages in the Pipeline() apis | 12:15 |
| tristan | Right, it *could* be useful; show what was the ultimate strong key produced for each element all in one place | 12:15 |
| juergbi | yes, could be interesting. we can also look into this after merging the actual weak build/key functionality | 12:16 |
| juergbi | let's first get it into mergeable shape | 12:16 |
| tristan | I'm thinking that... first of all; the formatting options (see Context.log_element_format), will need weak keys | 12:16 |
| tristan | that is the same formatting options to `bst show` | 12:16 |
| tristan | and we can start by adding weak abbreviated keys beside strong ones by default | 12:17 |
| juergbi | could make sense, yes | 12:17 |
| tristan | so that there is always the two keys | 12:17 |
| juergbi | the two keys will never match, though, not even in strong build planning mode (except for elements without dependencies) | 12:17 |
| tristan | Right | 12:17 |
| juergbi | maybe it would make more sense to display two strong keys | 12:17 |
| juergbi | the ieal one and the one actually built/downloaded | 12:18 |
| tristan | Hmmm | 12:18 |
| tristan | Yeah all three seem to be interesting | 12:18 |
| tristan | To be honest though, I feel like I'm more interested in this information: | 12:18 |
| juergbi | or just some flag whether the two strong keys are identical | 12:18 |
| tristan | o Strong key of created/used artifacts | 12:18 |
| tristan | o Weak key of created/used artifacts | 12:18 |
| tristan | o Whether the strong key was the ideal one or not | 12:19 |
| tristan | I.e. I'm not so interested in what the ideal key would have been right ? | 12:19 |
| juergbi | right | 12:19 |
| tristan | Or might I be ? | 12:19 |
| tristan | yeah, I feel initially I'm more interested in just whether they were identical or not | 12:19 |
| juergbi | not really sure about the use cases for the displayed keys | 12:20 |
| juergbi | the last point is definitely something interesting | 12:20 |
| juergbi | if you have the artifact cached, you can theoretically easily gof rom strong key to weak key | 12:20 |
| juergbi | i.e., we could also just display strong key and make it easy to get to the weak key via bst show | 12:20 |
| tristan | In log lines, we could portray that information with a color, like we could dim the keys which are non-ideal or such | 12:20 |
| juergbi | yes, could make sense | 12:21 |
| juergbi | maybe also some non-color indication when logging (non-colored) to file | 12:21 |
| juergbi | like a check mark next to the key | 12:22 |
| tristan | I'm thinking for the summaries at least we should do that | 12:22 |
| tristan | Like, if you have a whole log file, you can easily derive that from looking at the summary | 12:22 |
| juergbi | agreed | 12:22 |
| juergbi | ✓ | 12:23 |
| tristan | hmmm, if utf8 is not an issue, maybe using an extra char for a checkmark is good | 12:24 |
| * tristan thinks there is still no exotic characters in the output so far | 12:25 | |
| juergbi | i don't expect any issues these days for UTF-8 output on linux | 12:27 |
| tristan | nah it should be fine to have utf8 logs, in any case I think they technically already are | 12:38 |
| tristan | i.e. we cannot predict what is in the commands shown | 12:38 |
| tristan | Or in the case of an error, what is captured and displayed from the stdout of the process | 12:38 |
| jonathanmaw | tristan: After some fiddling with safe_copy, it seems the standard way to handle errors in utils.py (raising an exception) always leads to stack traces. | 12:48 |
| jonathanmaw | I can give a more informative error message (which would have helped when I was having the problem initially) | 12:49 |
| jonathanmaw | but I'm not sure what to do if I want to get rid of the stack traces | 12:49 |
| jonathanmaw | Is it a matter of going to all the things that call them and raising those exceptions as an appropriate type (ElementError, SourceError, etc)? | 12:50 |
| tristan | jonathanmaw, yes. | 13:13 |
| jonathanmaw | tristan: ok, I'll have a look where it's being called. | 13:14 |
| tristan | jonathanmaw, in this case it's a special case though, cause it's the frontend that does it | 13:16 |
| tristan | jonathanmaw, so you will want to except OSError as e, and raise PipelineError(...) from e | 13:16 |
| tristan | in _pipeline.py | 13:16 |
| *** xjuan has joined #buildstream | 13:48 | |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 6 commits (last: _artifactcache: Few changes) https://gitlab.com/BuildStream/buildstream/commit/aad3ff24cfecf3745abf5f69f53a9ee757024bf4 | 13:52 |
| gitlab-br-bot | buildstream: merge request (jonathan/36-fix-ugly-stack-trace->master: Fix ugly stack trace) #53 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/53 | 13:57 |
| tlater | tristan: Is there a way to get access to *all* elements in the project yet? | 13:57 |
| gitlab-br-bot | buildstream: merge request (jonathan/36-fix-ugly-stack-trace->master: Fix ugly stack trace) #53 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/53 | 14:06 |
| tlater | tristan: For checking workspaces for elements that don't exist I'll have to load the entire set of elements - otherwise there's no way to tell if something has been removed | 14:14 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: artifacts documentation: Now there is 'push-port', amend artifact docs for this) https://gitlab.com/BuildStream/buildstream/commit/5106173c3dbfed75831baaaab658b0ed9500937f | 14:27 |
| tristan | tlater, no there is no way to do that | 14:28 |
| tristan | tlater, but I thought it would make sense at least to issue a warning if there are open workspaces that are irrelevant to the current pipeline | 14:29 |
| tristan | maybe I have to rethink that | 14:29 |
| tristan | tlater, I guess you have a point that the user may use many different pipelines or be running subsets of their project | 14:30 |
| tristan | still it would be nice to have a warning in place I think, perhaps without user prompting though | 14:30 |
| tlater | This is probably going to issue a warning most of the time - perhaps it's better to point out workspaces with missing elements in `workspace list` | 14:31 |
| tristan | tlater, also I think we should be mentioning the active workspaces relevant to the pipeline when printing the heading ahead of running the pipeline | 14:31 |
| tristan | probably that should just be wired in by default into `bst show` | 14:32 |
| tristan | so it's automatically a part of the default formatting (Context.log_element_format) | 14:33 |
| * tristan has to leave closing coffee shop for now | 14:33 | |
| tlater | o/ | 14:34 |
| tristan | tlater, if it's going to warn most of the time that may not be too much of a problem though, if its a brief warning listing the unused workspaces, and shows up as a WARNING message, after showing the summary and at the beginning of the scheduling | 14:34 |
| tristan | Although I honestly doubt that it would show up most of the time | 14:35 |
| tristan | if people opened a workspace, it stands to reason that it's going to be active for the majority of pipelines they run for that project | 14:35 |
| tlater | Yeah, that's fair | 14:35 |
| tristan | could be just a MessageType.WARN with "Unused workspaces" as the message, and a \n separated list of workspaces in the message detail | 14:36 |
| tristan | nice and clean | 14:36 |
| * tristan out | 14:37 | |
| *** tristan has quit IRC | 14:40 | |
| *** jonathanmaw has left #buildstream | 15:43 | |
| tlater | The element-format value in the default userconfig doesn't seem to have an effect in `bst show` - though this may just be me not using it correctly. I think the --format option of `bst show` accidentally overrides it with a new default. | 17:02 |
| tlater | ^ I'll just leave that here because I'm not confident enough to leave an issue, and don't know enough about output to simply fix it. | 17:05 |
| *** tlater has quit IRC | 17:09 | |
| *** jude has quit IRC | 17:26 | |
| *** tristan has joined #buildstream | 17:54 | |
| *** ChanServ sets mode: +o tristan | 18:07 | |
| *** jude has joined #buildstream | 18:09 | |
| *** ssam2 has quit IRC | 18:52 | |
| *** jude has quit IRC | 19:25 | |
| *** jude has joined #buildstream | 19:36 | |
| *** jude has quit IRC | 21:30 | |
| *** xjuan has quit IRC | 21:43 | |
| jjardon[m] | hi, I get a 404 error from https://buildstream.gitlab.io/ ; is this intended? | 23:39 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!