*** mohan43u has joined #buildstream | 05:23 | |
*** jesopo has joined #buildstream | 05:24 | |
*** jit10 has joined #buildstream | 06:19 | |
gitlab-br-bot | juergbi opened (was WIP) MR !915 (juerg/command-batching->master: Command batching) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/915 | 07:26 |
---|---|---|
*** tristan has joined #buildstream | 08:00 | |
juergbi | hi tristan, in case you're up for some (API) reviewing, I've updated my command batching MR: https://gitlab.com/BuildStream/buildstream/merge_requests/915 | 08:25 |
*** toscalix has joined #buildstream | 08:39 | |
*** benschubert has joined #buildstream | 09:13 | |
*** scadoosh has joined #buildstream | 09:28 | |
*** rdale has joined #buildstream | 09:38 | |
benschubert | skullman: would you have time to look at https://gitlab.com/BuildStream/buildstream/merge_requests/895#note_116963234 ? Thanks! | 09:46 |
gitlab-br-bot | toscalix opened issue #769 (Improve the documentation related with the disk space quota used by default by BuildStream.) on buildstream https://gitlab.com/BuildStream/buildstream/issues/769 | 09:47 |
skullman | benschubert: looking at it now | 09:47 |
*** tiagogomes has quit IRC | 09:49 | |
toscalix | that #769 ticket was in my todo as consequence of a discussion a couple of weeks ago of the #733 ticket, openned by jjardon | 09:50 |
gitlab-br-bot | Issue #733: quota config parameter should be the maximum amount of cache allowed, not the minimum https://gitlab.com/BuildStream/buildstream/issues/733 | 09:50 |
*** tiagogomes has joined #buildstream | 09:50 | |
skullman | benschubert: replied | 09:54 |
benschubert | thanks | 09:54 |
*** jonathanmaw has joined #buildstream | 09:59 | |
*** phildawson_ has quit IRC | 10:07 | |
*** phildawson has joined #buildstream | 10:07 | |
phildawson | can anyone explain this CI failure to me? https://gitlab.com/BuildStream/buildstream/commit/f067397bd2560ae62be99254cdde8315c3e636ac/pipelines?ref=phil%2Fsource-checkout-options | 10:07 |
Kinnison | wow, that looks broken | 10:08 |
Kinnison | Have you hit retry? | 10:09 |
Kinnison | does it repeat? | 10:09 |
phildawson | Yup | 10:09 |
Kinnison | hrm | 10:09 |
phildawson | My thought exactly | 10:09 |
Kinnison | Did you re-push between the pipeline running? | 10:09 |
phildawson | I did not | 10:09 |
Kinnison | is the listed SHA a treeish in your repo? | 10:09 |
Nexus | oh i've had that before | 10:09 |
* Nexus thinks | 10:09 | |
Nexus | i think that's when i accidentally rebased to a pre-master commit | 10:10 |
benschubert | juergbi: I'm not sure i understand everything about your comment in https://gitlab.com/BuildStream/buildstream/merge_requests/895#note_118194846 would you mind explaining it a bit more to me? | 10:11 |
juergbi | benschubert: !915 introduces (optional) command batching where the sandbox.run() calls will be added to a sandbox-internal batch object and the commands execution is deferred until the batch context ends | 10:12 |
gitlab-br-bot | MR !915: Command batching https://gitlab.com/BuildStream/buildstream/merge_requests/915 | 10:12 |
juergbi | an effect of this is that the sandbox will be responsible for raising errors for command failures if they were executed as part of a command batch | 10:13 |
*** raoul has joined #buildstream | 10:13 | |
juergbi | in the MR I raise SandboxError as that's no longer directly in the Element class hierarchy | 10:13 |
phildawson | Kinnison, it looks like the SHA gitlab is using for the pipeline is different to the head I thought I pushed. I'll try again and let you know how it goes. | 10:13 |
Kinnison | good luck :-) | 10:14 |
juergbi | benschubert: however, with regards to caching build failures it shouldn't be treated differently from non-batch command failures even though it's a SandboxError | 10:14 |
phildawson | nope, git thinks everything is up to date. | 10:14 |
benschubert | Oh and then since I don't cache them anymore in my MR this would break I see. Would it be cleaner to propagate a "BatchCommandError" Instead, like a new exception instead of the sandbox? | 10:14 |
phildawson | Kinnison, This branch is based on something which may have gone a while without a rebase. Has there been any changes that might be causing this by their absence | 10:15 |
toscalix | I have been doing cleaning up in tickets this morning | 10:15 |
Kinnison | phildawson: It's possible that docker containers have changed, rebasing so that gitlab-ci.yml is up to date may be sensible | 10:16 |
juergbi | benschubert: could be an option, or maybe rather a generic CommandError that could also be raised by plugins. not sure about best practice with regards to exception class hierarchies | 10:18 |
phildawson | Thanks Kinnison | 10:18 |
gitlab-br-bot | BenjaminSchubert closed issue #758 (the pip source plugin incorrectly search for a valid version) on buildstream https://gitlab.com/BuildStream/buildstream/issues/758 | 10:19 |
gitlab-br-bot | BenjaminSchubert merged MR !942 (bschubert/fix-pip-python->master: plugins/sources/pip.py: also look for python version named "python") on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/942 | 10:19 |
*** lachlan has joined #buildstream | 10:19 | |
*** ctolentino has joined #buildstream | 10:20 | |
benschubert | Mmh true | 10:20 |
benschubert | juergbi: It seems to me that not reusing exceptions too much would be good and keeping sandbox related errors in the sandbox, and commands related ones separately would be better since we would be more sure about what we are catching. However adding the "artifactErrors" too makes it also a bit much in term of complexity (however it could be as simple as "except (SandboxError, ArtifactError): raise; except BstError: setup caching | 10:23 |
benschubert | elements" which is still acceptable for my PR (don't know how much work it would be on your?) What would you prefer? | 10:23 |
juergbi | benschubert: shouldn't we rather inverse it? explicitly save artifacts for ElementError and SandboxCommandError? | 10:24 |
juergbi | because e.g. for buildstream core or plugin bugs (non-BstError exceptions) we don't want to save it, right? | 10:25 |
juergbi | due to this I would default to not saving as per my comment | 10:25 |
benschubert | Oh right that makes lots of sense! | 10:28 |
benschubert | The SandboxCommandError doesn't exist yet right? Is it okl if I let you add it and depending on which changes lands first we update this part? | 10:28 |
juergbi | yes, I think that makes sense | 10:29 |
benschubert | Ok I'll update this! | 10:30 |
juergbi | ta | 10:30 |
benschubert | And what about the shelling in the sandbox, do we still want that for every BstError? | 10:32 |
benschubert | or should we just do it for ElementError? | 10:32 |
juergbi | I'd tend towards using the same check as for artifact saving. skullman: does this make sense to you as well? | 10:37 |
skullman | aye, makes sense to me | 10:38 |
benschubert | juergbi: skullman does the new approach for !895 seems good to you? | 10:43 |
gitlab-br-bot | MR !895: Don't cache sandbox failures https://gitlab.com/BuildStream/buildstream/merge_requests/895 | 10:43 |
skullman | looking at the changes now | 10:43 |
*** alatiera_ has joined #buildstream | 10:44 | |
tiagogomes | So the new buildstream website looks already dead. There's no reference whatsoever to the gathering there | 10:47 |
juergbi | benschubert: hm, aren't we now missing caching on success? or am I misreading the code? | 10:47 |
benschubert | the last line in the "try" should do right? | 10:47 |
benschubert | Would you rather have a boolean check and the caching in the finally? | 10:48 |
benschubert | I found it more readable like that but can revert :) | 10:48 |
juergbi | ah, missed that line in the diff | 10:48 |
skullman | benschubert: makes sense to me, looks neater. Haven't tried the changes out so I may have missed something. | 10:51 |
mablanch | lachlan: I can't approve from BuildStream/benchmarks, but !10 looks good, I think you can merge that fix. | 10:51 |
gitlab-br-bot | MR !10: Sphinx to not assume python3 is the default python version https://gitlab.com/BuildStream/buildstream/merge_requests/10 | 10:51 |
juergbi | benschubert: I agree, structure looks good to me | 10:52 |
benschubert | Ok, so if the tests pass I can merge? | 10:52 |
benschubert | or is there something else on this one that would require more work? | 10:52 |
*** alatiera_ has joined #buildstream | 10:54 | |
gitlab-br-bot | jjardon closed issue #769 (Improve the documentation related with the disk space quota used by default by BuildStream.) on buildstream https://gitlab.com/BuildStream/buildstream/issues/769 | 10:56 |
juergbi | benschubert: I commented with a couple of nits but looks good to merge to me otherwise | 10:57 |
benschubert | Thanks a lot! I will address them and merge if I don't get any more questions :) | 10:57 |
juergbi | ta | 10:58 |
benschubert | and maybe if you had time for !938, it's currently preventing me from running buildstream tests on a more powerfull machine | 10:59 |
gitlab-br-bot | MR !938: Fix os.rename in git source element to correctly handle error codes https://gitlab.com/BuildStream/buildstream/merge_requests/938 | 10:59 |
juergbi | skullman: I don't know whether you saw this already but I've included a commit (unmodified) from !920 in !953. I assume that's fine with you (in case my MR gets merged earlier), otherwise let me know | 11:02 |
gitlab-br-bot | MR !920: Add artifact log command https://gitlab.com/BuildStream/buildstream/merge_requests/920 | 11:02 |
gitlab-br-bot | MR !953: _context.py: Drop duplicated default values for user configuration https://gitlab.com/BuildStream/buildstream/merge_requests/953 | 11:02 |
skullman | juergbi: I saw and yes it's fine. | 11:02 |
juergbi | ta | 11:04 |
lachlan | Thanks: mablanch | 11:23 |
gitlab-br-bot | richardmaw-codethink approved MR !938 (bschubert/fix-atomic-move-git-repo->master: Fix os.rename in git source element to correctly handle error codes) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/938 | 11:39 |
gitlab-br-bot | juergbi approved MR !895 (bschubert/dont-cache-errors-from-host-tools->master: Don't cache sandbox failures) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/895 | 11:41 |
*** alatiera_ has quit IRC | 11:52 | |
gitlab-br-bot | tlater approved MR !938 (bschubert/fix-atomic-move-git-repo->master: Fix os.rename in git source element to correctly handle error codes) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/938 | 12:05 |
*** lachlan has quit IRC | 12:07 | |
*** smkelly has joined #buildstream | 12:08 | |
jennis | I'm importing a tarball (which I can't change) that contains a broken symlink: /bin/foo -> /something/else/bar, now /something/else/bar doesn't actually exist, and I want to relink /bin/foo to /another/thing/baz | 12:11 |
jennis | What would be the best way to do this? I'm thinking some kind of script element that sits on top of the import element and then bundling both together with a stack element | 12:12 |
jennis | But I wonder if there is a nicer way to do this? | 12:13 |
jennis | Or if there are any potential flaws in my proposed method | 12:13 |
jmac | Can you just import another element on top which just contains /another/thing/baz and the symlink to it? | 12:15 |
juergbi | jennis: I think this would work but you could potentially also combine the two. i.e., just use the import source as source in a script element and create combined output | 12:15 |
juergbi | or maybe even import with a second source which is a local symlink. not sure whether that would work | 12:17 |
jennis | I will try these options | 12:22 |
gitlab-br-bot | BenjaminSchubert merged MR !938 (bschubert/fix-atomic-move-git-repo->master: Fix os.rename in git source element to correctly handle error codes) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/938 | 12:22 |
jennis | Bit worried that I'm not actually going to have the permission to relink this | 12:22 |
jennis | thanks | 12:22 |
*** lachlan has joined #buildstream | 12:23 | |
jennis | juergbi, sources are forbidden in a script element btw | 12:31 |
juergbi | hm, didn't realize that | 12:31 |
juergbi | I guess it would kind of conflict with the layouting | 12:32 |
cs-shadow | juergbi: hi. Before I land source-checkout command, I wanted to ensure that we are on the same page regarding https://gitlab.com/BuildStream/buildstream/merge_requests/820#note_113915907 so please have a look at it when you get a chance. | 12:33 |
juergbi | lgtm | 12:34 |
cs-shadow | ace, thanks! | 12:34 |
*** adds68 has joined #buildstream | 12:35 | |
adds68 | Hi, in reference to: https://gitlab.com/BuildStream/buildstream/issues/764 | 12:38 |
adds68 | Could anyone give me any idea on what "provenance" data is? | 12:38 |
jonathanmaw | adds68: provenance data is an object attached to a dict which says which line in which source file the data came from | 12:39 |
* jonathanmaw checks the MR | 12:39 | |
jonathanmaw | yeah, that's the kind of provenance data there | 12:41 |
adds68 | jonathanmaw, so from that error, a function is somehow ending up in the provenance data? | 12:43 |
jonathanmaw | adds68: that'd be my guess | 12:44 |
adds68 | hmmm, is not sure where to even look to debug :( | 12:45 |
jonathanmaw | adds68: I'd suggest looking at collect_manifest.py, line 145, and check whether the manifest being put in the public data contains only objects that ought to be in a yaml dict | 12:46 |
jonathanmaw | judicious use of print statements is usually my first port of call | 12:48 |
adds68 | yea good point, it seems to work on out bootstrap project, but not in the platform project | 12:51 |
juergbi | benschubert: a bit late, but I've added a few post-merge comments to !938. will you keep track of those or shall I move them to an issue? | 12:53 |
gitlab-br-bot | MR !938: Fix os.rename in git source element to correctly handle error codes https://gitlab.com/BuildStream/buildstream/merge_requests/938 | 12:53 |
jennis | jmac, your suggestion has worked well for me, thanks! | 12:54 |
benschubert | juergbi: oups sorry about merging it too soon. I will create a following mr after lunch | 12:56 |
juergbi | ta | 12:56 |
gitlab-br-bot | cs-shadow merged MR !820 (chandan/source-checkout->master: Add `bst source-checkout` command) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/820 | 13:03 |
*** Jackneill has joined #buildstream | 13:36 | |
*** lachlan has quit IRC | 13:57 | |
*** lachlan has joined #buildstream | 14:13 | |
*** phildawson has quit IRC | 14:22 | |
jennis | Do we have optional configuration to *not* remotely cache stuff? | 14:42 |
jennis | For example, if I have a cache with push access and build an element from gnome-build-meta, this will depend on elements from freedesktop, which means I can pull freedesktop elements from their cache, but these will also get pushed to my cache, as well as the gnome stuff. So effectively, the freedesktop artifacts are cached in two remotes | 14:44 |
jennis | Basically, I don't want to have the junctioned dependencies in my cache | 14:44 |
jmac | We have no per-element configuration for artifact caches | 14:52 |
*** phildawson has joined #buildstream | 14:53 | |
juergbi | jennis: jmac is right with regards to pushing, however, with pulling buildtrees disabled by default now, a side effect is that we will actually no longer push pulled elements | 14:54 |
juergbi | (unless you enable pullin buildtrees) | 14:54 |
juergbi | might change again, though | 14:55 |
gitlab-br-bot | valentindavid approved MR !947 (abderrahim/cmake-variable-types->master: plugins/elements/cmake.yaml: always specify variable types) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/947 | 14:55 |
jennis | Oh, that's a great side affect | 14:57 |
jennis | effect | 14:57 |
jennis | Mhmm, because we have the functionality to just push one element/artifact without it's dependencies | 14:57 |
jennis | It's just, by default, when we bst build, dependencies are pushed | 14:58 |
jennis | So I'm asking for something like `bst build --push-deps none` foo.bst | 14:59 |
jennis | where the default of --push-deps is all | 14:59 |
jennis | which is what we essentially have now | 15:00 |
tiagogomes | jennis why don't you use bst push for that | 15:02 |
valentind | adds68, I am closing #235, because we have an alternative approach now. | 15:06 |
gitlab-br-bot | Issue #235: Add the ability to generate manifest files https://gitlab.com/BuildStream/buildstream/issues/235 | 15:06 |
gitlab-br-bot | valentindavid closed issue #235 (Add the ability to generate manifest files) on buildstream https://gitlab.com/BuildStream/buildstream/issues/235 | 15:07 |
jennis | tiagogomes, because I don't want my build to push dependencies from the junction | 15:12 |
jennis | so the only way I can do it now is build locally without declaring a remote cache, declare a remote cache and then `bst push` those elements | 15:13 |
juergbi | cs-shadow: can you please add a NEWS entry for source-checkout? | 15:14 |
benschubert | jennis: would "--pushers 0" be a solution when doing bst build? | 15:17 |
benschubert | that would avoids the need of editing the file every time | 15:18 |
Nexus | Can someone link me to a good description of what junctions are and how they work? :) | 15:19 |
jennis | benschubert, I've not tried that, that's a nice idea though, but I still need to do a separate build and then push job, but I like it | 15:19 |
jennis | Nexus, they are elements that represent another buildstream project | 15:19 |
jennis | elements in that project can be addressed with junction-name.bst:element-in-junction.bst | 15:20 |
jennis | I would recommend the tutorial in our documentation | 15:20 |
jennis | https://docs.buildstream.build/advanced-features/junction-elements.html | 15:20 |
Nexus | ty | 15:21 |
benschubert | Nexus: would you have time to reply to https://gitlab.com/BuildStream/buildstream/merge_requests/949#note_118191077 ? :) | 15:21 |
Nexus | benschubert: sure gimme a sec | 15:22 |
tiagogomes | benschubert unless there was some recent change, that means infinite number of fetchers | 15:22 |
benschubert | tiagogomes: ooups, got mistaken with another project then, sorry jennis | 15:23 |
Nexus | benschubert: done | 15:24 |
benschubert | ta! | 15:24 |
Nexus | jennis: Any idea where in the codebase junctions are interpreted? | 15:25 |
gitlab-br-bot | valentindavid closed issue #761 (cmake: CMAKE_INSTALL_LIBDIR isn't properly set) on buildstream https://gitlab.com/BuildStream/buildstream/issues/761 | 15:31 |
gitlab-br-bot | valentindavid merged MR !947 (abderrahim/cmake-variable-types->master: plugins/elements/cmake.yaml: always specify variable types) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/947 | 15:31 |
jennis | benschubert , tiagogomes `--pushers 0` still pushes | 15:32 |
jennis | Nexus, not off the top of my head, I'd just be grep'ing | 15:33 |
Nexus | kk :) | 15:34 |
tiagogomes | jennis yeah, what you need is perhaps https://gitlab.com/BuildStream/buildstream/merge_requests/950 | 15:34 |
jennis | tiagogomes, this is partially what I need yes | 15:35 |
jennis | thanks | 15:35 |
cs-shadow | juergbi: sure, was just about to do that | 15:46 |
abderrahim[m] | Hi, how do I backport a MR to 1.2? Is the cherry-pick button on the MR the right thing? | 15:48 |
gitlab-br-bot | BenjaminSchubert opened MR !958 (bschubert/mr938-comments->master: Followup on MR 938, addr4essing additional comments) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/958 | 15:51 |
benschubert | juergbi: could you validate that !958 adresses your points correctly? thanks! | 15:51 |
*** [TwistedJail] has joined #buildstream | 15:57 | |
gitlab-br-bot | cs-shadow opened issue #771 (Support multiple elements in checkout and source-checkout) on buildstream https://gitlab.com/BuildStream/buildstream/issues/771 | 16:05 |
toscalix | jonathanmaw: , you and Chandan have a point in "repo per plugin" idea. I will evaluate if we can specify the policy in the line of what I propose it removing the hard link between repo and plugin. I cannot today but I will try tomorrow | 16:21 |
jonathanmaw | ta toscalix | 16:22 |
gitlab-br-bot | BenjaminSchubert closed issue #727 (Don't cache host tools failures) on buildstream https://gitlab.com/BuildStream/buildstream/issues/727 | 16:29 |
gitlab-br-bot | BenjaminSchubert merged MR !895 (bschubert/dont-cache-errors-from-host-tools->master: Don't cache sandbox failures) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/895 | 16:29 |
benschubert | Nexus: I would rather not add the marker per file to keep it consistent with before, would that seem fair to you? | 16:29 |
Nexus | benschubert: yeah thats fine | 16:30 |
benschubert | thanks! | 16:31 |
benschubert | I'll rebase and merge then | 16:31 |
jonathanmaw | hrm, I'm trying to make it optional to specify the element when running buildstream commands, and I'm not sure if it's possible to do it in a non-confusing way. I've marked the 'element' argument with required=False, but there doesn't seem to be a way to actually separate optional args | 16:37 |
jonathanmaw | I gather that's why skullman ended up adding "-e" to add extra elements in !909 | 16:38 |
gitlab-br-bot | MR !909: Allow staging multiple elements in `bst shell` https://gitlab.com/BuildStream/buildstream/merge_requests/909 | 16:38 |
skullman | jonathanmaw: yep | 16:38 |
jonathanmaw | hrm | 16:39 |
jonathanmaw | If people expect normal things (like '--' separating out the variable-length args) then I can't really make it optional | 16:40 |
gitlab-br-bot | phildawson opened MR !959 (phil/source-checkout-options->master: Phil/source checkout options) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/959 | 16:43 |
jonathanmaw | on the other hand, there is *some* functionality, if you don't plan to specify a command to be run, it works. | 16:44 |
gitlab-br-bot | cs-shadow opened MR !960 (chandan/source-checkout-news->master: NEWS: Add entry for the new source-checkout command) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/960 | 16:44 |
adds68 | jonathanmaw, i've managed to get the manifest json data to print a few times from the plugin, however now it seems to have stopped? I've deleted my local artifacts cache, but it still will not rebuild, any idea what could cause this? | 16:46 |
cs-shadow | can someone please do a quick sanity check of https://gitlab.com/BuildStream/buildstream/merge_requests/960 | 16:48 |
gitlab-br-bot | jmacarthur approved MR !920 (richardmaw/artifact-log->master: Add artifact log command) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/920 | 16:50 |
jonathanmaw | cs-shadow: looks fine to me | 16:51 |
gitlab-br-bot | phildawson approved MR !960 (chandan/source-checkout-news->master: NEWS: Add entry for the new source-checkout command) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/960 | 16:51 |
cs-shadow | jonathanmaw: thanks! | 16:51 |
cs-shadow | phildawson: thanks :) | 16:52 |
jonathanmaw | adds68: hmm, I occasionally see print statements getting overwritten/swallowed by other output. How about if you replace the print(text) with sys.stderr.write(text+'\n')? | 16:53 |
adds68 | jonathanmaw, still nothing, even with --debug engabled | 16:55 |
*** lachlan has quit IRC | 16:56 | |
jonathanmaw | adds68: I suppose in assemble you should be able to use self.info() to print messages | 17:05 |
gitlab-br-bot | adds68 opened issue #772 (Buildstream plugin output being suppressed) on buildstream https://gitlab.com/BuildStream/buildstream/issues/772 | 17:12 |
*** lachlan has joined #buildstream | 17:12 | |
gitlab-br-bot | cs-shadow merged MR !960 (chandan/source-checkout-news->master: NEWS: Add entry for the new source-checkout command) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/960 | 17:15 |
gitlab-br-bot | richardmaw-codethink opened issue #773 (The command-line should provide access to artifacts) on buildstream https://gitlab.com/BuildStream/buildstream/issues/773 | 17:21 |
toscalix | fosdem lightning talks CfP deadline is this coming Saturday https://fosdem.org/2019/news/2018-08-10-call-for-participation/ | 17:30 |
*** phildawson82 has joined #buildstream | 17:33 | |
*** abderrah1 has joined #buildstream | 17:34 | |
*** abderrahim has quit IRC | 17:36 | |
adds68 | jonathanmaw, seems anything inside the configure method will print, it's quite strange though why other parts of the code are suppressed | 17:47 |
jonathanmaw | adds68: I think the specific reason is that configure is called in the main process, and during assemble, it's being called in various subprocesses | 17:48 |
jonathanmaw | and the only reliable way to get the messages out in a sensible order is to pass them back to the parent process to print | 17:48 |
jonathanmaw | tbh I think this confusion would end if we could call the likes of self.info in configure | 17:48 |
adds68 | jonathanmaw, o opened https://gitlab.com/BuildStream/buildstream/issues/772 to see if this could be documented anywhere to make it bit clearer | 17:50 |
jonathanmaw | adds68: ok, I'll add my response there so it doesn't get lost to history. | 17:56 |
adds68 | jonathanmaw, awesome thanks :) | 17:56 |
adds68 | jonathanmaw, when you say pass them back to the parent process, could you elaborate on that a little bit also? | 17:56 |
jonathanmaw | adds68: ok, I'll do some code diving for context. | 17:59 |
*** lachlan has quit IRC | 18:00 | |
adds68 | jonathanmaw, thanks! | 18:01 |
jonathanmaw | adds68: interestingly, self.info() should work in the main process, so if it's not working in configure(), then there's a bug there. | 18:11 |
*** jonathanmaw has quit IRC | 18:12 | |
adds68 | jennis, yes self.info does seem to log as expected! :) | 18:19 |
adds68 | oops jonathanwaw*** | 18:19 |
*** lachlan has joined #buildstream | 18:25 | |
*** lachlan has quit IRC | 18:29 | |
*** toscalix has quit IRC | 18:29 | |
*** raoul has quit IRC | 18:56 | |
*** lachlan has joined #buildstream | 19:03 | |
*** lachlan has quit IRC | 19:42 | |
*** rdale has quit IRC | 19:51 | |
*** phildawson has quit IRC | 20:01 | |
gitlab-br-bot | juergbi merged MR !953 (juerg/context-default-values->master: _context.py: Drop duplicated default values for user configuration) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/953 | 20:36 |
*** jonathanmaw has joined #buildstream | 20:54 | |
*** jonathanmaw has quit IRC | 20:56 | |
*** tristan has quit IRC | 22:33 | |
*** dabukalam has quit IRC | 22:57 | |
*** dabukalam has joined #buildstream | 22:58 | |
*** dabukalam has left #buildstream | 22:58 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!