| *** tristan has quit IRC | 05:37 | |
| *** tristan has joined #buildstream | 06:09 | |
| tristan | oops | 06:21 |
|---|---|---|
| * tristan just replied jjardon[m] but see it's not in the logs | 06:21 | |
| * tristan repeats | 06:21 | |
| tristan | <tristan> jjardon[m], there is no page generated for the group there | 06:22 |
| tristan | <tristan> So I was thinking a general project page could be put at https://buildstream.gitlab.io/, if someone has time to create one; you know would be nice if it was awesome and designed too | 06:22 |
| tristan | <tristan> The page at https://buildstream.gitlab.io/buildstream is the documentation automatically generated from the source code; so I dont think it's the right thing ultimately to put as the main buildstream group page | 06:22 |
| tristan | <tristan> jjardon[m], maybe we could add a placeholder page at https://buildstream.gitlab.io/ that does a temporary redirect to the generated documentation, until we do have a website | 06:22 |
| *** ChanServ sets mode: +o tristan | 06:22 | |
| *** jude has joined #buildstream | 07:08 | |
| *** tlater has joined #buildstream | 08:36 | |
| *** jonathanmaw has joined #buildstream | 08:42 | |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 7 commits (last: _scheduler/scheduler.py: Done unset scheduler queues when exiting) https://gitlab.com/BuildStream/buildstream/commit/47e6b24b589ac617934261f811a35c975e61c961 | 08:57 |
| *** ssam2 has joined #buildstream | 09:08 | |
| gitlab-br-bot | buildstream: issue #35 ("End of session reports") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/35 | 09:30 |
| tlater | tristan: What output do you expect for the workspaces in the pipeline status header thing? | 09:37 |
| tristan | tlater, it should be part of the formatting understood by LogLine.show_pipeline() | 09:40 |
| tristan | tlater, there are two approaches I can think of; and maybe both is an option | 09:40 |
| tristan | A.) %{workspaced} expands to '(workspaced)' if the thing is workspaced, otherwise it expands to nothing | 09:40 |
| tristan | B.) %{workspace-dirs} expands to a list of the local directories which it's linked to (substituting ${HOME} with ~/) on one line, if any, otherwise expands to nothing | 09:42 |
| tristan | The default depends mostly on whether we think it will cause ugly wrapping in the terminal | 09:42 |
| tlater | B definitely seems like it will | 09:42 |
| tlater | But implementing both and leaving one as an option is probably fine. | 09:43 |
| tlater | Do I just ignore which source is being workspaced then? | 09:43 |
| tristan | tlater, we should probably make `bst show` default to using Context.thingamagiggie also | 09:43 |
| tlater | Do you mean 'print_heading'? | 09:44 |
| tristan | Well that's why %{workspace-dirs} would expand to a comma separated list | 09:44 |
| tristan | tlater, no I mean LogLine.show_pipeline() | 09:44 |
| tlater | It already uses that :) | 09:44 |
| tristan | Which coincidentally, is called as a side effect of print_heading() yeah | 09:44 |
| tristan | But `bst show` calls show_pipeline() directly | 09:44 |
| tlater | Oh, I understand, yeah | 09:45 |
| tristan | so then we get it for free in all places right | 09:45 |
| tlater | I suppose a separate `bst list` command would then still be useful to display individual sources? | 09:46 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: _yaml.py: Fixed node_copy()) https://gitlab.com/BuildStream/buildstream/commit/dd15b1ba494c4725fd452b6723ff799d1708830c | 09:48 |
| tristan | tlater, not sure what you mean display individual sources | 09:49 |
| tristan | you mean `bst workspace list` ? | 09:49 |
| tlater | Yeah | 09:49 |
| tristan | So can `bst workspace list` be done without any <target> ? | 09:49 |
| tristan | I think that was the intention | 09:49 |
| tlater | Oh, right, `bst show` has a target | 09:50 |
| tlater | My problem with the current concept is that it ignores individual sources - you only see which elements are workspaced. | 09:50 |
| tlater | But elements may have a mix of workspaced and non-workspaced sources | 09:50 |
| tristan | Specifically which concept ? | 09:50 |
| tlater | %{workspaced} | 09:51 |
| tristan | Right | 09:51 |
| tristan | Ok so that is to give the user some feedback when running some build | 09:51 |
| tristan | But indeed, it is missing the concept of source indices | 09:51 |
| tlater | It might be enough for the pipeline display, but it will probably have to change for `bst workspace show` | 09:52 |
| tristan | One way to do approach that; is in the case an element has more than one source, _and_ is workspaced... we can display a list | 09:52 |
| tristan | Differently | 09:52 |
| tristan | Ohhh, oh you mean %{workspaced} not %{workspace-dirs} | 09:53 |
| tristan | Yeah I see what you mean, but I'm not really concerned; one approach is less verbose than the other | 09:53 |
| tristan | Maybe %{workspace-dirs} is unnecessary, even | 09:53 |
| tristan | tlater, consider it this way: We want to shove it in the users face that a workspace is being used | 09:54 |
| tristan | We never want the user to not know | 09:54 |
| tristan | So in fact, %{workspace-dirs} is better for that, because seeing (workspaced) in the output is not as attention demanding | 09:54 |
| tristan | tlater, however; consider that workspaces is pretty much exclusively for interactive users | 09:55 |
| tristan | I mean, I really dont see any use cases where production autobuilders and CI systems will be using active workspaces | 09:55 |
| tristan | tlater, in which case I think it's safe to deduce that this particular output need not be incredibly precise | 09:56 |
| tristan | I.e. if the user wants to know more about which is which, then can invoke `bst workspace list` | 09:56 |
| tlater | Yeah, that makes sense. | 09:56 |
| tlater | I'll implement it this way then, thanks :) | 09:57 |
| tristan | One question to consider is what to do when running `bst fetch`, `bst track` or `bst build --track`, with active workspaces in play | 09:58 |
| tristan | I think the answer to that though, is to have the respective queues explicitly skip over elements that are workspaced | 09:58 |
| tlater | So have a condition in source._track that only shows a warning and doesn't actually track if it is workspaced? | 09:59 |
| tristan | Nah | 10:00 |
| tristan | tlater, I mean have an added clause here: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_scheduler/trackqueue.py#L48 | 10:00 |
| tristan | But maybe the warning is better ? | 10:01 |
| tlater | Couldn't a user intend to only track/fetch sources that are not workspaced? | 10:01 |
| tristan | Or, we could track and fetch as usual, but issue a warning that any newly tracked sources will be ignored due to the active workspace ? | 10:02 |
| tristan | That way the project gets updated as expected but the user is notified for that element that it wont take effect in a build ? | 10:03 |
| tlater | Yeah, I think that's better. | 10:03 |
| tristan | maybe that is less special cases to catch | 10:03 |
| tristan | yeah | 10:03 |
| tristan | So... on a different topic... `bst build --track`, when pull and push queues are both enabled... is a lot of queues :) | 10:04 |
| tristan | Lots of output going on here | 10:04 |
| jjardon[m] | tristan: yup, that would make sense for now | 10:12 |
| tristan | jjardon[m], I just havent got around to doing that... anyone wanna... figure out how to do it and do it ? | 10:13 |
| tristan | :) | 10:13 |
| jjardon[m] | tristan: I will try when I manage finish this: https://gitlab.com/baserock/definitions/merge_requests/43 :) | 10:14 |
| tristan | I think it will need just small static html with some embedded javascript to actually do the temporary redirect (as I recall it's not doable in html, and apache has some things for that but, I dont think this is apache) | 10:14 |
| *** jonathanmaw has quit IRC | 10:27 | |
| *** jonathanmaw has joined #buildstream | 10:29 | |
| ssam2 | tristan, any chance of a review for https://gitlab.com/BuildStream/buildstream-tests/merge_requests/9 ? | 10:38 |
| ssam2 | it will be useful to have the buildstream-tests gnu-toolchain branch up to date so I can pull it when converting Baserock definitions to BuildStream | 10:39 |
| ssam2 | i can squash all the .gitlab-ci commits into 1 if you don't want all that noise in the commit log | 10:40 |
| tristan | oh sorry I dont watch the buildstream-tests repo as closely | 10:42 |
| tristan | ssam2, nice, so this is basically one project for multi host/target arch, merge request to gnu-toolchain ? | 10:43 |
| ssam2 | i don't quite understand that sentence | 10:43 |
| tristan | ssam2, I'm glossing over it but I think I'm just going to pretty much blind accept | 10:44 |
| ssam2 | but yeah, it's all my work so far on the toolchain | 10:44 |
| tristan | ssam2, I mean... the work you have done to make a cross buildable toolchain, not hardwired to a specific arch | 10:44 |
| ssam2 | ah, right yeah | 10:44 |
| tristan | I wasnt aware it was to land in gnu-toolchain in buildstream-tests, but I am certainly fine with that :) | 10:44 |
| tristan | I guess it's one step on the road to migrating baserock | 10:45 |
| ssam2 | it's kind of a temporary thing... Baserock definitions is probably not going to convert fully for a while | 10:45 |
| ssam2 | yeah | 10:45 |
| ssam2 | so it's nice to be able to say 'merge this branch of buildstream-tests.git to get the latest toolchain' for now | 10:45 |
| ssam2 | obviously when Baserock does make the switch we'll merge that into the definitions.git repo | 10:45 |
| tristan | right | 10:46 |
| tristan | ssam2, for the timeout, I think jjardon[m] knows how to fix that | 10:46 |
| ssam2 | i'll go ask :-) | 10:47 |
| tristan | ssam2, remember if you're going to setup CI pipelines to run builds... run `bst --colors` :) | 10:47 |
| ssam2 | i did :-) | 10:47 |
| tristan | jonathanmaw, regarding https://gitlab.com/BuildStream/buildstream/merge_requests/53/diffs#note_34787967 ... I dont want to raise system errors, and even more so; I dont want to use access() in advance of a failing system call | 10:53 |
| tristan | that is just technically wrong; we should not check file permissions with access() and expect they are the same on the next line of code | 10:53 |
| tristan | I think that, if we try: utils.copy_files() and except OSError as e: from _pipeline.py | 10:55 |
| tristan | we can raise PipelineError("Failed to checkout files to {}: {}".format(checkout_directory, e) | 10:55 |
| tristan | And it will have a nice error saying: "Failed to checkout files to /home/jonathanmaw/tmp2: Permission denied: '/home/jonathanmaw/tmp2/sda.img'" | 10:56 |
| jjardon[m] | Hi , any idea what Im doing wrong here? https://gitlab.com/baserock/definitions/-/jobs/22163988 , this other pipeline worked fine: https://gitlab.com/baserock/definitions/-/jobs/22101629 (failed for another problem) the only change between the 2 is this commit: https://gitlab.com/baserock/definitions/commit/81806370995d7f176e1f9805f698895ec04632f9 | 10:56 |
| tristan | That seems pretty comprehensive enough | 10:56 |
| ssam2 | jjardon[m], is bst being run from the directory containing project.conf ? | 10:57 |
| tristan | is there a project.conf at buildstream-metadata/build-system/ ? | 10:58 |
| tristan | Also if bst is not being run from there, run it with bst -C buildstream-metadata/build-system/ | 10:58 |
| jjardon[m] | if you see the last link, It seems thats what im doing? | 11:00 |
| jjardon[m] | "bst -C buildstream-metadata/build-system build build-system-x86_64-content.bst" | 11:03 |
| jjardon[m] | tristan: ssam2 for the timeout; go to https://gitlab.com/BuildStream/buildstream-tests/settings/ci_cd and change the "Timeout" in the "Pipelines" section | 11:06 |
| ssam2 | ah ok, thanks | 11:07 |
| tristan | ah | 11:08 |
| *** jonathanmaw has quit IRC | 11:08 | |
| *** jonathanmaw has joined #buildstream | 11:08 | |
| ssam2 | it'll get tested as part of the Baserock->BuildStream conversions in any case so I will probably leave it for now | 11:08 |
| tristan | jjardon[m], so it was a while ago I wrote that conversion initially, but as I recall it expects gnu-toolchain to exist | 11:09 |
| tristan | hence the rebase thing | 11:09 |
| jjardon[m] | yeah, as I said it works, but it fails after I apply that commit | 11:09 |
| tristan | So what I expect, is that buildstream-metadata/build-system/ does not contain the gnu-toolchain branch of buildstream-tests | 11:10 |
| tristan | I.e. it looks like you expect it to copy files over | 11:10 |
| tristan | but the tool expects to output directly into a checkout of a gnu-toolchain branch of buildstream-tests | 11:10 |
| tristan | before that commit, it would A.) Checkout buildstream-tests and then B.) output into buildstream-tests/elements | 11:11 |
| tristan | what you want is for buildstream-metadata/build-system/ to be a fork of the gnu-toolchain branch of buildstream-tests | 11:12 |
| tristan | and just stop checking out buildstream-tests I guess | 11:12 |
| ssam2 | yeah I have been doing it this way: | 11:12 |
| ssam2 | git remote add buildstream-tests https://gitlab.com/buildstream/buildstream-tests | 11:12 |
| ssam2 | git remote update buildstream-tests | 11:12 |
| ssam2 | git merge --no-ff --allow-unrelated-histories buildstream-tests/gnu-toolchain | 11:12 |
| ssam2 | in my definitions.git clone | 11:12 |
| tristan | Or, you could do a manual copy of the files in the buildstream-tests checkout (excluding .git/) into buildstream-metadata/build-system/ | 11:13 |
| ssam2 | jjardon[m], I have updating my buildstream conversion branch on my todo list today | 11:14 |
| ssam2 | looks like you are on the case with automating it already | 11:14 |
| ironfoot | So, the problem here is that "git clone https://gitlab.com/BuildStream/buildstream-tests.git -b gnu-toolchain" command should be clonned in buildstream-metadata folder? | 11:14 |
| ssam2 | jjardon[m], i found a bunch of issues in the conversion when I did it before that I had to fix up manually, so I guess i'll get to work on documenting those and (if possible) fixing defs2bst | 11:15 |
| tristan | ironfoot, it really depends what your intention is here, I'm not sure I follow | 11:15 |
| tristan | ironfoot, but it would have to be like, "git clone https://gitlab.com/BuildStream/buildstream-tests.git -b gnu-toolchain buildstream-metadata/build-system | 11:16 |
| tristan | So you want it to appear as buildstream-metadata/build-system, not as buildstream-metadata/buildstream-tests | 11:16 |
| ironfoot | just looking at jjardon[m] commits, he changed buildstream-tests with buildstream-metadata in that commit, but without modifying that git-clone line | 11:16 |
| tristan | right | 11:17 |
| tristan | actually he changed buildstream-tests with buildstream-metadata/build-system | 11:17 |
| jjardon[m] | Yeah, I want to do 2 system conversions; one for the gnome system and another for the build syatem | 11:18 |
| tristan | jjardon[m], but they would both have to contain the build system | 11:19 |
| ssam2 | do them into the same directory | 11:19 |
| ssam2 | check out https://gitlab.com/baserock/definitions/tree/sam/buildstream/elements .. I converted about 10 systems into the same dir | 11:20 |
| jjardon[m] | Mmm, ok | 11:20 |
| tristan | right we dont have recursive pipelines (ability to make projects depend on other projects), yet | 11:20 |
| ssam2 | otherwise, you'll duplicate things like core.morph | 11:20 |
| tristan | So for baserock, definitions will remain largely with the same structure until we can solve that bit | 11:20 |
| jjardon[m] | That should be fine? They are in different folder s anyway | 11:21 |
| ssam2 | but why would you want 2 copies of the same thing ?? | 11:21 |
| tristan | yeah the underlying intent is what is missing here :) | 11:21 |
| jjardon[m] | Id like to migrate the systems independently | 11:22 |
| ssam2 | why ? | 11:23 |
| jjardon[m] | Metadata of the conversion of bla in black, metadata of the conversion of bla2 in bla2, them use bla1 or bla2 depending what I want to build | 11:23 |
| jjardon[m] | I though maybe some thing can be overwritten if I run the conversion script several times to the same output, but if not I can put everything in the same foldet | 11:25 |
| jjardon[m] | Folder* | 11:25 |
| ssam2 | the conversion should be the same every time | 11:25 |
| ssam2 | e.g. core.morph becomes the exact same core.bst | 11:26 |
| ssam2 | so it does get overwritten, but it's not a problem | 11:26 |
| tristan | ssam2, not entirely true | 11:26 |
| ssam2 | oh | 11:26 |
| tristan | ssam2, as I understand it; I think that defs2bst will invoke ybd each time to get the output, and also invoke git to get the latest definitions, no ? | 11:27 |
| tristan | So, basically if you have a definitions commit land in between 2 conversions, the output would differ | 11:27 |
| ssam2 | ah, well that's true | 11:27 |
| tristan | but that shouldnt really be an issue, the output of one run of 5 conversions will give you the latest | 11:28 |
| ssam2 | but from the point of view of a single job in .gitlab-ci.yaml that converts 10 systems, it's not an issue | 11:28 |
| ssam2 | and if a later conversion updates core.bst to a newer version, that's also good | 11:28 |
| ssam2 | the last thing we want is 10 different versions of core.bst all out of sync with each other | 11:28 |
| tristan | right, better convert them all once in the same directory, and then run builds after | 11:28 |
| tristan | just dont start running builds before you've converted everything you're going to convert | 11:28 |
| ssam2 | yeah | 11:29 |
| tristan | jjardon[m], also, add --colors to your `bst` invocations | 11:29 |
| tristan | :) | 11:29 |
| jjardon[m] | Why it can be in different folders though; is this a limitation of the conversion script or I'm doing sth wrong trying to do that? | 11:29 |
| tristan | You mean why can't it ? | 11:29 |
| jjardon[m] | Yup, sorry | 11:30 |
| tristan | jjardon[m], it can, it's just you havent understood that one thing: defs2bst expects the --output directory to be an elements/ subdirectory of an EXISTING gnu-toolchain project | 11:30 |
| tristan | I tried to say that before but lots of details are covering it up :) | 11:30 |
| tristan | jjardon[m], so yeah you can, either checkout buildstream-tests gnu-toolchain branch multiple times into multiple subdirectories where you convert into | 11:31 |
| tristan | jjardon[m], the rest of this conversation is just basically ssam2 and I not really understanding why one would want to do that into separate dirs | 11:31 |
| tristan | it's not a natural conversion for baserock, which has everything in one tree anyway | 11:32 |
| tristan | you'll end up with duplicated stuff, and you wont want to consume that as a conversion candidate for baserock anyway | 11:32 |
| gitlab-br-bot | buildstream: issue #27 ("Summary output at startup makes no sence at `bst track` time") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/27 | 11:44 |
| jjardon[m] | ok, thanks for the help guys! | 12:16 |
| 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 | 12:20 |
| gitlab-br-bot | push on buildstream@workspaces (by Tristan Maat): 20 commits (last: status.py: Minor touchups in the queue formatting) https://gitlab.com/BuildStream/buildstream/commit/bdae56627224d920bf02adeba0570792064a83f6 | 12:35 |
| gitlab-br-bot | buildstream: merge request (workspaces->master: WIP: Workspaces) #50 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/50 | 12:35 |
| gitlab-br-bot | push on buildstream@workspaces (by Tristan Maat): 9 commits (last: main.py: Add workspace commands) https://gitlab.com/BuildStream/buildstream/commit/99ac048b0adbe1c5bba7b77036a266f25844cae2 | 12:44 |
| gitlab-br-bot | buildstream: merge request (workspaces->master: WIP: Workspaces) #50 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/50 | 12:44 |
| gitlab-br-bot | push on buildstream@workspaces (by Tristan Maat): 2 commits (last: Add `workspace reset` command) https://gitlab.com/BuildStream/buildstream/commit/22ed0aa942b455234e1a0939de18e12a9fb79e1f | 13:42 |
| gitlab-br-bot | buildstream: merge request (workspaces->master: WIP: Workspaces) #50 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/50 | 13:42 |
| *** xjuan has joined #buildstream | 13:49 | |
| *** xjuan has quit IRC | 14:03 | |
| tlater | I have a pretty strange problem. _yaml.node_sanitize fails when trying to sort a map the second time I store it.It looks like loading is turning a dict into a list, and then when sorting the elements of that list have conflicting types. | 14:30 |
| tristan | "trying to sort a map the second time I store it" | 14:31 |
| tristan | I'm not sure I really get that | 14:31 |
| tlater | Load yaml with workspaces -> Add workspace -> store workspace | 14:32 |
| tristan | tlater, you are doing _yaml.node_santize() multiple times on the same dict ? | 14:32 |
| tristan | Or, you are doing _yaml.node_sanitize() on the returned dict ? | 14:32 |
| tlater | Well, twice, but the second time after I load it from the file system. | 14:32 |
| tristan | What does "fail" mean ? | 14:33 |
| tlater | `TypeError: unorderable types: str() < int()` | 14:33 |
| tlater | On a dict with an int as a key, and a str as a value | 14:34 |
| tristan | tlater, I suggest you debug it and find out what is going wrong | 14:35 |
| tlater | Specifically, this: | 14:35 |
| tristan | I dont really understand that error | 14:35 |
| tristan | the node_sanitize() could have a bug | 14:35 |
| tristan | Not sure, it looks pretty clean and simple, though | 14:35 |
| tristan | all it does is sorts dicts and yanks out provenance | 14:36 |
| tlater | The sorting part seems to mess up | 14:36 |
| tlater | I think the problem is in loading | 14:36 |
| *** jude has quit IRC | 14:36 | |
| tlater | It tries to sort this: | 14:36 |
| tristan | integer keys seems to be the thing | 14:36 |
| tlater | CommentedMap([(0, '/home/tristanmaat/Documents/Projects/buildstream/gnome-modulesets/test3')) | 14:36 |
| tristan | tlater, I think you have an issue comparing 0 with '__bst_provenance_info' | 14:37 |
| tristan | when doing sorted | 14:37 |
| tlater | Oh. I'll try removing that. | 14:37 |
| tristan | I guess that exception is raising on the line sorted() | 14:37 |
| tlater | Yeah | 14:38 |
| tristan | sorting is an important part of node_sanitize(), cant just throw it out the window | 14:38 |
| gitlab-br-bot | buildstream: merge request (jonathan/dpkg-build->master: WIP: Jonathan/dpkg build) #37 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/37 | 14:40 |
| tlater | Yeah, you're right, it's the __bst_provenance_info, I was looking at the wrong thing :/ | 14:41 |
| ssam2 | tristan, how about https://gnome7.codethink.co.uk/cgit/ ? | 14:41 |
| tristan | https://gnome7.codethink.co.uk/cgit/gnome-modulesets/tree/ Awesome \o/ | 14:42 |
| tristan | jjardon[m], https://gnome7.codethink.co.uk/cgit/gnome-modulesets/tree/elements/apps/glade.bst :) | 14:42 |
| tristan | https://gnome7.codethink.co.uk/cgit/gnome-modulesets/tree/elements/apps/meta-gnome-apps-tested.bst | 14:43 |
| tristan | ssam2, thanks ! | 14:43 |
| tristan | you sorted that out much quicker than I could have | 14:43 |
| ssam2 | no problem. main issue was cgi not enabled in apache config | 14:43 |
| ssam2 | probably required fresh eyes | 14:43 |
| tristan | I wasted a whole hour or two not getting anywhere | 14:43 |
| tristan | googling about apache and cgit and suchlike | 14:43 |
| tristan | ssam2, probably also helps that you have any experience whatsoever with cgit, or apache | 14:44 |
| tristan | of which, I have neither :) | 14:44 |
| *** tristan has quit IRC | 14:50 | |
| gitlab-br-bot | buildstream: merge request (workspaces->master: WIP: Workspaces) #50 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/50 | 14:51 |
| gitlab-br-bot | push on buildstream@workspaces (by Tristan Maat): 1 commit (last: _yaml.py: Fix _yaml.sanitize_node attempting to sort provenance) https://gitlab.com/BuildStream/buildstream/commit/81c448e1d03243028d446557043d3a0f4ebc8c1b | 14:51 |
| gitlab-br-bot | buildstream: merge request (workspaces->master: WIP: Workspaces) #50 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/50 | 14:51 |
| gitlab-br-bot | push on buildstream@workspaces (by Tristan Maat): 1 commit (last: _pipeline.py: Add warning for unused workspaces) https://gitlab.com/BuildStream/buildstream/commit/76026166e9885ba8ca9f4451971a7e35219d145e | 14:53 |
| gitlab-br-bot | buildstream: merge request (workspaces->master: WIP: Workspaces) #50 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/50 | 14:53 |
| gitlab-br-bot | buildstream: merge request (jonathan/dpkg-build->master: WIP: Jonathan/dpkg build) #37 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/37 | 14:54 |
| *** tristan has joined #buildstream | 15:03 | |
| *** ChanServ sets mode: +o tristan | 15:03 | |
| jonathanmaw | hrm, generating manpages fails, and I have a warning that my setuptools is too old. | 15:08 |
| jonathanmaw | though the debian package python3-setuptools is the same version number as the one provided by pip3 | 15:10 |
| jonathanmaw | 5.5.1 | 15:10 |
| jonathanmaw | (running `python3 setup.py --command-packages=click_man.commands man_pages` fyi) | 15:10 |
| tristan | not sure about why, but quality of the click man package is not so great :-/ | 15:14 |
| tristan | for now, dont worry I can regenerate them (although they should be up to date as of the latest cli changes in master right now) | 15:15 |
| gitlab-br-bot | push on buildstream@workspaces (by Tristan Maat): 1 commit (last: Fix workspaces with symlinks causing issues) https://gitlab.com/BuildStream/buildstream/commit/40a368731196bb7e1ed7b82dd235add0e2c698de | 15:16 |
| gitlab-br-bot | buildstream: merge request (workspaces->master: WIP: Workspaces) #50 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/50 | 15:16 |
| *** jude has joined #buildstream | 15:16 | |
| gitlab-br-bot | push on buildstream@workspaces (by Tristan Maat): 1 commit (last: Fix workspaces with symlinks causing issues) https://gitlab.com/BuildStream/buildstream/commit/26a9fb9ac0ef51b15462548ac8f6e470c384f1f0 | 15:17 |
| gitlab-br-bot | buildstream: merge request (workspaces->master: WIP: Workspaces) #50 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/50 | 15:17 |
| *** jude has quit IRC | 15:21 | |
| *** jude has joined #buildstream | 15:21 | |
| tlater | Is it just me or does `bst build ` on an inconsistent pipeline show a stacktrace? | 15:35 |
| tlater | ^ app.print_summary doesn't currently deal with the fact that the scheduler may not have any queues yet, causing a stacktrace during error handling. | 15:42 |
| gitlab-br-bot | push on buildstream@inconsistent_trace (by Tristan Maat): 1 commit (last: widget.py: Fix stacktrace on early pipeline failure) https://gitlab.com/BuildStream/buildstream/commit/3efce1bf775558d406d245409253f22e0e130459 | 15:45 |
| jonathanmaw | hrm, dpkg-build and dpkg-deploy don't seem to be building the documentation. I have a sinking feeling that it might be because the names are hyphenated. | 15:51 |
| gitlab-br-bot | push on buildstream@inconsistent_trace (by Tristan Maat): 1 commit (last: widget.py: Fix stacktrace on early pipeline failure) https://gitlab.com/BuildStream/buildstream/commit/998a599f7ce36557181aae8f6e6b93b18c43f38c | 15:51 |
| jonathanmaw | (full log at https://pastebin.com/HZNp6Ukf) | 15:56 |
| gitlab-br-bot | buildstream: merge request (inconsistent_trace->master: widget.py: Fix stacktrace on early pipeline failure) #54 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/54 | 15:57 |
| gitlab-br-bot | buildstream: merge request (inconsistent_trace->master: widget.py: Fix stacktrace on early pipeline failure) #54 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/54 | 15:58 |
| jonathanmaw | yep, the warning disappears if the filename uses underscores instead of hyphens :/ | 16:08 |
| gitlab-br-bot | push on buildstream@workspaces (by Tristan Maat): 7 commits (last: Change workspace --track to --refresh-source) https://gitlab.com/BuildStream/buildstream/commit/41c23d3a03d2618654c9f5a61abfb39c1c923fb9 | 16:10 |
| gitlab-br-bot | buildstream: merge request (workspaces->master: WIP: Workspaces) #50 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/50 | 16:10 |
| gitlab-br-bot | buildstream: merge request (workspaces->master: Workspaces) #50 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/50 | 16:11 |
| tlater | Alright, I think I've solved all current problems on !50. Need to be home early today, I'll see the new problems tomorrow :) | 16:14 |
| *** tlater has quit IRC | 16:17 | |
| *** jonathanmaw has quit IRC | 17:24 | |
| *** jude has quit IRC | 17:26 | |
| jjardon[m] | hi! any idea what could go wrong here? https://gitlab.com/baserock/definitions/-/jobs/22212965 | 19:05 |
| jjardon[m] | for the logs seems everything is fine | 19:05 |
| ssam2 | scroll up; libffi failed to build | 19:18 |
| ssam2 | I hit this issue before when I did a bst conversion, hold on | 19:18 |
| ssam2 | https://gitlab.com/baserock/definitions/commit/78694667008ce1a508c5a4143765b06af486a0ea | 19:19 |
| ssam2 | there's a bunch of other fixes you will want to cherry-pick | 19:20 |
| ssam2 | https://gitlab.com/baserock/definitions/commit/f83bcfbd639452a4593e0cf8552dcf24b285b2c8 | 19:20 |
| ssam2 | https://gitlab.com/baserock/definitions/commit/fd2d3961336af97b4dc20609cec33faa2360c764 | 19:20 |
| ssam2 | https://gitlab.com/baserock/definitions/commit/69b7f620c1253db5c43bc9635bee733e3c0db79d | 19:20 |
| ssam2 | https://gitlab.com/baserock/definitions/commit/646a18b3f362dc8f92aac31021f4a96fb41c87ed | 19:20 |
| ssam2 | https://gitlab.com/baserock/definitions/commit/f83bcfbd639452a4593e0cf8552dcf24b285b2c8 | 19:20 |
| ssam2 | some of these could be fixed upstream in defs2bst, i didn't get around to it yet though | 19:20 |
| ssam2 | the libffi one could be fixed in definitions.git master in fact | 19:21 |
| jjardon[m] | ah! I see it now: " Command 'cp "$(gcc -dumpmachine)"/include/ffi.h "/buildstream/install"/usr/include/' failed with exitcode 1" | 19:29 |
| * jjardon[m] takes a look | 19:29 | |
| ssam2 | https://gitlab.com/baserock/definitions/commit/78694667008ce1a508c5a4143765b06af486a0ea is the fix | 19:30 |
| tristan | jjardon[m], `bst --colors` on gitlab man :) | 19:51 |
| *** ssam2 has quit IRC | 20:03 | |
| jjardon[m] | tristan: :) why you dont put it on by default? | 21:27 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!