| *** nimish has quit IRC | 00:11 | |
| *** nimish has joined #buildstream | 00:13 | |
| *** bochecha has quit IRC | 00:22 | |
| *** alatiera has quit IRC | 00:22 | |
| *** nimish has quit IRC | 00:24 | |
| *** xjuan has quit IRC | 01:39 | |
| *** Ulrike has joined #buildstream | 03:33 | |
| *** nimish has joined #buildstream | 03:40 | |
| *** nimish has quit IRC | 03:43 | |
| *** nimish has joined #buildstream | 03:43 | |
| *** nimish has quit IRC | 05:47 | |
| *** nimish has joined #buildstream | 05:50 | |
| *** tristan has joined #buildstream | 05:57 | |
| *** mohan43u has quit IRC | 06:08 | |
| *** mohan43u has joined #buildstream | 06:13 | |
| gitlab-br-bot | tristanvb opened MR !988 (tristan/refactor-queues-update-state->master: _scheduler/queues/queue.py: Don't call update state outside of error handling harness) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/988 | 06:15 |
|---|---|---|
| *** nimish_ has joined #buildstream | 06:38 | |
| *** nimish has quit IRC | 06:38 | |
| *** nimish_ is now known as nimish | 06:39 | |
| *** abderrahim has quit IRC | 06:55 | |
| *** abderrahim has joined #buildstream | 06:55 | |
| *** mohan43u has quit IRC | 07:04 | |
| *** mohan43u has joined #buildstream | 07:06 | |
| *** nimish has quit IRC | 07:07 | |
| *** tristan has quit IRC | 07:18 | |
| *** tristan has joined #buildstream | 07:36 | |
| gitlab-br-bot | tristanvb merged MR !988 (tristan/refactor-queues-update-state->master: _scheduler/queues/queue.py: Don't call update state outside of error handling harness) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/988 | 07:37 |
| *** nimish has joined #buildstream | 07:51 | |
| *** Nexus has joined #buildstream | 07:54 | |
| *** tristan has quit IRC | 07:55 | |
| *** Nexus has joined #buildstream | 07:55 | |
| *** tristan has joined #buildstream | 08:26 | |
| *** ChanServ sets mode: +o tristan | 08:27 | |
| tristan | <juergbi> tristan: this should actually already be possible using a local junction to . | 08:27 |
| tristan | juergbi, picking that up from the logs I think you didn't understand what I meant | 08:27 |
| tristan | juergbi, I meant if a "bst build" with no arguments "build everything" kind of thing would be practically useful... I should be able to use it to build everything... like if I run `bst build` in gnome-build-meta, I would like to have a bootable system image; AND a flatpak GNOME SDK | 08:27 |
| tristan | where those two products probably imply specifying different `-o` project options | 08:27 |
| juergbi | the default target could theoretically point to a stack that points to two self-junctions (local `.` source) each with different project options | 08:28 |
| *** pro[m] has quit IRC | 08:34 | |
| tristan | juergbi, Ah I see what you mean now | 08:36 |
| tristan | The power of self-junctions | 08:36 |
| juergbi | yes, don't know whether we actually want to recommend this, but it should be possible | 08:36 |
| tristan | I keep forgetting :) | 08:36 |
| juergbi | there is a potential issue with nested junctions getting merged/coalesced where we don't want it in that case | 08:37 |
| tristan | Thankfully I forget about self-junctioning powers enough that I don't accidentally recommend this | 08:37 |
| juergbi | I'd like to make this more flexible | 08:37 |
| tristan | maybe I will start remembering if we have a lot of use cases to recommend it for | 08:37 |
| tristan | juergbi, I think valentind has been asking for something like "using the same element twice in the same project", maybe self-junctioning is the way to do that | 08:43 |
| juergbi | yes, I have been using that for my buildstream test version of my distro for bootstrapping purposes | 08:45 |
| juergbi | only one gcc element with build instructions | 08:46 |
| juergbi | (although I needed helper gcc elements without build instructions due to not sufficiently flexible path/sysroot handling) | 08:46 |
| *** paulsherwood has joined #buildstream | 08:50 | |
| *** slaf has quit IRC | 08:51 | |
| *** toscalix has joined #buildstream | 08:53 | |
| *** slaf has joined #buildstream | 08:53 | |
| tristan | juergbi, sounds like that might be the very use case indeed | 08:55 |
| * tristan has git:unlisted-submodule ready... and tying up a test for git:invalid-submodule now | 08:56 | |
| *** pro[m] has joined #buildstream | 09:03 | |
| *** alatiera has joined #buildstream | 09:04 | |
| *** nimish has quit IRC | 09:06 | |
| *** nimish has joined #buildstream | 09:06 | |
| *** finn has joined #buildstream | 09:23 | |
| *** alatiera has quit IRC | 09:23 | |
| tristan | valentind, Ok I'm just going to force push some rewording to your documentation *directly* to your !906 branch | 09:25 |
| gitlab-br-bot | MR !906: Track of git tags and save them to reproduce minimum shallow repository https://gitlab.com/BuildStream/buildstream/merge_requests/906 | 09:25 |
| tristan | And then merge | 09:25 |
| valentind | tristan, ok | 09:26 |
| Nexus | ohh, found an uncaught exception in master | 09:26 |
| Nexus | If you have an element with "depends:" but nothing in the depends, it gives a nonetype error | 09:27 |
| tristan | Nexus, nice catch, I would have expected that to be invalid YAML | 09:30 |
| Nexus | tristan: Do you want an issue for it, or do you just want to fix it? | 09:30 |
| tristan | Nexus, I'm ambivalent about the issue; if you have time to fix it as the next thing, then fix is better, use an issue if there is any chance at all of forgetting | 09:31 |
| tristan | Nexus, *however*, a fix for this should come with a regression test in tests/format somewhere | 09:32 |
| *** kapil___ has quit IRC | 09:43 | |
| gitlab-br-bot | knownexus opened issue #803 (Unhandled NoneType exception) on buildstream https://gitlab.com/BuildStream/buildstream/issues/803 | 09:45 |
| *** finn has quit IRC | 09:48 | |
| *** finn has joined #buildstream | 09:49 | |
| tristan | valentind, done, I've rewritten the docs and set the last iteration to merge | 09:54 |
| *** jonathanmaw has joined #buildstream | 09:57 | |
| *** alatiera has joined #buildstream | 10:01 | |
| *** tristan has quit IRC | 10:02 | |
| *** tpollard has joined #buildstream | 10:03 | |
| *** nimish has quit IRC | 10:06 | |
| *** nimish has joined #buildstream | 10:06 | |
| gitlab-br-bot | gokcennurlu opened (was WIP) MR !985 (gokcennurlu/remote_url_override_push_error->master: Set ArtifactCache for push/pull correctly when `--remote` is used) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/985 | 10:07 |
| *** solid_black has joined #buildstream | 10:11 | |
| *** nimish has quit IRC | 10:11 | |
| *** nimish has joined #buildstream | 10:12 | |
| *** paulsher1ood has joined #buildstream | 10:19 | |
| gitlab-br-bot | tristanvb closed issue #487 (Implement a mechanism to allow builds to leverage git describe) on buildstream https://gitlab.com/BuildStream/buildstream/issues/487 | 10:23 |
| gitlab-br-bot | tristanvb merged MR !906 (valentindavid/git_describe_tracking->master: Track of git tags and save them to reproduce minimum shallow repository) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/906 | 10:23 |
| *** tristan has joined #buildstream | 10:33 | |
| *** lachlan has joined #buildstream | 10:34 | |
| *** alatiera has quit IRC | 10:36 | |
| *** nimish has quit IRC | 10:37 | |
| *** nimish has joined #buildstream | 10:37 | |
| *** paulsherwood has quit IRC | 10:46 | |
| *** bochecha has joined #buildstream | 10:48 | |
| gitlab-br-bot | valentindavid opened MR !989 (valentindavid/git_shallow_fetch->master: Fetch git shallow clone when possible) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/989 | 10:51 |
| *** jmac has joined #buildstream | 10:51 | |
| valentind | jjardon, tristan, I have made !989 for shallow clones on fetch/build. | 10:52 |
| jjardon | cool! | 10:52 |
| jjardon | valentind: can we make shallow clones configurable? | 10:53 |
| valentind | jjardon, what would be the use case? | 10:54 |
| valentind | If you want git describe to work, then just set "track-tags", and track the element. The tags gets stored. And when there are tags, it is never shallow. | 10:55 |
| valentind | If you have no tag, then the .git repository does not exist during the build. | 10:56 |
| valentind | So that would not make a difference. | 10:56 |
| valentind | Well actually, when using tags, the build .git is shallow but with what it needs, but the fetch cache is full. | 10:56 |
| *** nimish has quit IRC | 10:57 | |
| *** nimish has joined #buildstream | 10:58 | |
| valentind | Anyway, there should be no reason to have it configurable. | 11:00 |
| jjardon | valentind: what if I'm developing a element so Im tracking master and I need the full git history? would that work fine by default? | 11:07 |
| valentind | jjardon, It switches to full clone when needed. | 11:08 |
| valentind | jjardon, so if you "bst track" or "bst build --track", then it should clone the full repository. | 11:09 |
| valentind | Even if you did a "bst fetch" before. | 11:10 |
| jjardon | nice, I guess no need to be configurable then | 11:10 |
| valentind | jjardon, we should prepare for 1.4 in freedesktop SDK by merging all the 1.4 changes of git into git_tag. | 11:11 |
| jjardon | true | 11:11 |
| valentind | Now we have git describe working in master, so the new git plugin should work again for fd.o SDK. That was the missing thing. | 11:12 |
| valentind | jjardon, but we will have to track all elements that require git describe. | 11:13 |
| jjardon | valentind: you mean they have to have a "track:" in the bst? Would the module fail to build if It's not there? | 11:19 |
| *** kapil___ has joined #buildstream | 11:25 | |
| valentind | jjardon, you can set "track:" to the desired ref. | 11:29 |
| valentind | And track it. | 11:29 |
| tpollard | juergbi: in terms of https://gitlab.com/BuildStream/buildstream/issues/566#note_121157069 would you envision if the user specified it to not push-buildtrees, this would override if they've set normal push to true? | 11:29 |
| tpollard | with the default being to push buildtrees | 11:30 |
| valentind | tristan, something we forgot about, maybe we want to have git describe to work on submodules as well. Should not be much to do, though. | 11:40 |
| *** bochecha has quit IRC | 11:41 | |
| *** nimish has quit IRC | 11:43 | |
| *** nimish has joined #buildstream | 11:43 | |
| jjardon | valentind: should we assume then all the git elements would need to be tracked (as we do not know if they use git describe unless we actually inspect the elemtent), and maybe fire a warning if "track:" is not specify? | 11:46 |
| valentind | jjardon, no it is fine to not have track: | 11:47 |
| *** alatiera has joined #buildstream | 11:47 | |
| *** lachlan has quit IRC | 11:47 | |
| valentind | It is just that you cannot track tags to make git describe work. | 11:47 |
| jjardon | right | 11:48 |
| juergbi | tpollard: push-buildtrees is irrelevant if push is False, so yes, the combination 'push True and push-buildtrees False' should not push buildtrees | 11:49 |
| *** abderrahim has quit IRC | 11:49 | |
| juergbi | not sure about the default | 11:49 |
| *** abderrahim has joined #buildstream | 11:50 | |
| jjardon | Is there plans to release a new snapshot of master? the last one is quite behind now (more than 1000 commits I think) | 11:50 |
| juergbi | there hasn't been any real development snapshot yet. 1.3.0 was just to get the proper version number | 11:51 |
| juergbi | may make sense to release a snapshot before Christmas but I'm not sure whether tristan has other plans | 11:52 |
| *** nimish has quit IRC | 11:53 | |
| *** nimish has joined #buildstream | 11:53 | |
| jjardon | cool, thanks | 11:54 |
| *** bochecha has joined #buildstream | 11:57 | |
| *** lachlan has joined #buildstream | 12:01 | |
| jmac | Hanging test on tests/artifactcache/pull.py again | 12:04 |
| jmac | Is it just me and tristan who are seeing this, or are other people? | 12:04 |
| phildawson | For what it's worth, I've not noticed it. | 12:04 |
| tpollard | juergbi: I'll go with push-buildtrees to default to true for now | 12:07 |
| juergbi | jmac: you see this also on master? and always/frequently or sporadically? | 12:09 |
| juergbi | I'm not aware of such an issue blocking CI. and haven't seen it for a long time myself locally (but I'm not running tests locally as frequently anymore) | 12:10 |
| juergbi | tpollard: ok, I'll leave possible discussion on this to tristan and sstriker ;) | 12:11 |
| jonathanmaw | WSalmon: I've simplified the way we use the WorkspaceProjectCache in line with your comments in !924, if you want to have another look | 12:12 |
| gitlab-br-bot | MR !924: Support invoking buildstream from a workspace outside a project https://gitlab.com/BuildStream/buildstream/merge_requests/924 | 12:12 |
| valentind | jmac, I recommend you add a faulthandler on a signal like SIGUSR1 and then kill -USR1 the process to print the current stacks in all thread if this happens again | 12:13 |
| valentind | See https://docs.python.org/3/library/faulthandler.html | 12:13 |
| jmac | Does seem to be just my branch | 12:18 |
| *** lachlan has quit IRC | 12:19 | |
| juergbi | valentind: could it make sense to add this in master? | 12:19 |
| valentind | juergbi, not by default. | 12:19 |
| *** lachlan has joined #buildstream | 12:19 | |
| valentind | But we could make it configurable. | 12:19 |
| valentind | Like with an environment variable. | 12:19 |
| juergbi | yes | 12:20 |
| valentind | Well, that is my opinion. | 12:20 |
| valentind | Let me make a branch for that. | 12:20 |
| juergbi | ta | 12:22 |
| *** alatiera has quit IRC | 12:27 | |
| *** alatiera has joined #buildstream | 12:46 | |
| *** nimish has quit IRC | 13:18 | |
| *** nimish has joined #buildstream | 13:19 | |
| *** nimish has quit IRC | 13:24 | |
| *** nimish has joined #buildstream | 13:24 | |
| *** hjudt has joined #buildstream | 13:31 | |
| *** nimish has quit IRC | 14:04 | |
| *** nimish has joined #buildstream | 14:04 | |
| juergbi | phildawson: btw: there are also seems to be some cruft in the commit history. create_source_tarball still exists in old commit and create_tarball is introduced in a later commit than the one that actually needs it | 14:10 |
| juergbi | s/there are/there/ | 14:10 |
| juergbi | maybe you can clean this up at the same time as fixing the other points I mentioned | 14:10 |
| phildawson | juergbi, will do. | 14:15 |
| phildawson | thanks for taking another look | 14:15 |
| skullman | :/ shell completion tests assume they won't need to configure a cachedir, but to provide completions for artifact refs requires interacting with a cache, which means it's got to initialise it, which involves a mkdir outside of the testing directory | 14:39 |
| juergbi | skullman: what's the reason this is more problematic for shell completion tests than for all the other tests that need a cache dir? | 14:49 |
| skullman | juergbi: other tests that need a cache dir are full integration tests, and expect to have a whole project to build | 14:53 |
| skullman | I've worked out how tests get a different kind of cli object, might have to either add a dummy project and use the integration tests CLI object, or add a new kind of CLI object half-way in-between which handles having custom config but doesn't expect a project.conf | 14:55 |
| juergbi | skullman: don't you anyway have to put something in the cache (using full cli object) for the completion test? | 15:01 |
| skullman | hmm, I'd just been thinking as far as making sure all the old uses of `bst checkout` could be replaced with `bst artifact checkout`. I will later, yeah. I could probably just catch the failure to get completions for artifact refs and only provide completions for element target names | 15:07 |
| skullman | though it's not great that command-completion can have side-effects… | 15:07 |
| *** alatiera has quit IRC | 15:08 | |
| *** alatiera has joined #buildstream | 15:08 | |
| valentind | juergbi, Interesting error: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/129794635 | 15:16 |
| valentind | CPU use was 33%. Bandwith maybe high though. | 15:17 |
| valentind | I wonder if grpc has a very short timeout for connect() | 15:17 |
| juergbi | maybe, would be worth checking | 15:20 |
| gitlab-br-bot | knownexus opened MR !990 (issue-640-contrib-build-all->master: contrib files for build all and show all) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/990 | 15:21 |
| valentind | Maybe we show handle UNAVAILABLE for GetCapabalitiesRequest to make it retry. | 15:21 |
| valentind | But having long timeout would be also something nice. | 15:21 |
| laurence | Nexus, when raising an MR, if there is no gitlab issue, pls can you link to the relevant ML discussion ? | 15:23 |
| Nexus | laurence: there is an issue | 15:23 |
| * Nexus wonders who will get MR 1000 | 15:25 | |
| laurence | Nexus, ah, ok | 15:26 |
| gitlab-br-bot | juergbi closed issue #775 (Execution Environment Requirements) on buildstream https://gitlab.com/BuildStream/buildstream/issues/775 | 15:28 |
| gitlab-br-bot | juergbi merged MR !969 (raoul/775-execution-environment-reqs->master: Execution environment reqs) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/969 | 15:28 |
| valentind | Reading the code in grpc, it should be 20 seconds of timeout. | 15:46 |
| valentind | At least. | 15:46 |
| *** nimish has quit IRC | 15:54 | |
| *** nimish has joined #buildstream | 15:55 | |
| *** lachlan has quit IRC | 15:57 | |
| *** nimish has quit IRC | 16:25 | |
| *** nimish has joined #buildstream | 16:25 | |
| *** nimish has joined #buildstream | 16:26 | |
| gitlab-br-bot | raoul.hidalgocharman closed issue #628 (Remote-execution client flow optimisation (technical debt)) on buildstream https://gitlab.com/BuildStream/buildstream/issues/628 | 16:36 |
| gitlab-br-bot | raoul.hidalgocharman merged MR !982 (raoul/628-RE-flow-optimisation->master: Remote-execution client flow optimisation) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/982 | 16:36 |
| *** nimish has quit IRC | 16:41 | |
| *** nimish has joined #buildstream | 16:41 | |
| *** lachlan has joined #buildstream | 16:42 | |
| *** lachlan has quit IRC | 16:44 | |
| *** nimish has quit IRC | 16:46 | |
| *** nimish has joined #buildstream | 16:46 | |
| *** lachlan has joined #buildstream | 16:51 | |
| *** nimish has quit IRC | 16:56 | |
| *** nimish has joined #buildstream | 16:57 | |
| *** lachlan has quit IRC | 17:04 | |
| *** solid_black has quit IRC | 17:06 | |
| *** lachlan has joined #buildstream | 17:08 | |
| *** alatiera has quit IRC | 17:16 | |
| *** toscalix has quit IRC | 17:28 | |
| *** alatiera has joined #buildstream | 17:50 | |
| *** tpollard has quit IRC | 18:01 | |
| *** finn has quit IRC | 18:10 | |
| *** nimish has quit IRC | 18:12 | |
| *** nimish has joined #buildstream | 18:12 | |
| *** nimish has quit IRC | 18:17 | |
| *** nimish has joined #buildstream | 18:17 | |
| *** jonathanmaw has quit IRC | 18:29 | |
| gitlab-br-bot | nanonyme opened issue #804 (Not possible to disable git ls-tree for submodules) on buildstream https://gitlab.com/BuildStream/buildstream/issues/804 | 18:35 |
| *** raoul has quit IRC | 18:36 | |
| gitlab-br-bot | gokcennurlu opened issue #805 (fetch() is called on the source even though it is cached) on buildstream https://gitlab.com/BuildStream/buildstream/issues/805 | 18:37 |
| *** xjuan has joined #buildstream | 18:40 | |
| *** nimish has quit IRC | 18:52 | |
| *** nimish has joined #buildstream | 18:54 | |
| cs-shadow | Is buildstream expected to preserve the order of dependencies as they are listed in the bst file, when the time comes to stage them in the sandbox? | 18:59 |
| cs-shadow | or, checkout them, for that matter | 19:00 |
| *** nimish has quit IRC | 19:03 | |
| *** nimish has joined #buildstream | 19:04 | |
| juergbi | cs-shadow: no, at least for staging it actually guarantees to use a deterministic order that is independent of the declaration order | 19:05 |
| juergbi | Element.dependencies() will produce that order | 19:05 |
| juergbi | https://buildstream.gitlab.io/buildstream/buildstream.element.html#buildstream.element.Element.dependencies | 19:05 |
| cs-shadow | juergbi: thanks! that clarifies a few things. So, the reason I started looking at this order was because overlaps currently produce a warning like "there's an overlap ... order foo.bst above bar.bst" | 19:08 |
| gitlab-br-bot | juergbi opened MR !992 (juerg/fetch->master: Do not call fetch() for cached sources) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/992 | 19:08 |
| cs-shadow | if the declaration order doesn't matter, then is this warning misleading? Or have i misinterpreted it? | 19:08 |
| *** nimish has quit IRC | 19:09 | |
| *** nimish has joined #buildstream | 19:10 | |
| juergbi | cs-shadow: the warning message is based on the staging order. bst show may help to get you the staging order of an element's dependencies | 19:10 |
| *** nimish has quit IRC | 19:10 | |
| *** ChanServ sets mode: +o tristan | 19:11 | |
| tristan | cs-shadow, if there is no explicit dependency between two elements which a given element depends on, and those two elements overlap eachother, then they are guaranteed to overlap eachother in the same order, but the project has just not determined it with an explicit dependency | 19:11 |
| tristan | (in the same order, i.e. it will be deterministic and not random, just the order hasn't been declared with a dependency) | 19:11 |
| cs-shadow | tristan: right, that's exactly the example I was looking at, i.e. no explicit dependency. So, I am just wondering how is ordering one element over the other going to change anything? (if buildstream will come up with a deterministic ordering anyway) | 19:12 |
| tristan | ordering of elements in a depends: doesnt mean anything | 19:13 |
| tristan | saying that one element runtime depends on another element however is a way to explicitly decide the order | 19:13 |
| cs-shadow | tristan: So, the bit from the warning that says "order A above B" can be removed right? | 19:13 |
| cs-shadow | or changed to say something like "declare explicit dependency on B from A" or such | 19:14 |
| tristan | I think that warning could be phrased better (and less verbosely), but one is certainly above the other | 19:14 |
| tristan | maybe it could be enhanced in some way to *also* communicate whether the order was explicitly declared with a dependency or not | 19:15 |
| tristan | but there is always a linear staging order, whether explicitly declared or not | 19:15 |
| cs-shadow | tristan: cool, thanks! I do think it's a bit confusing at the moment. As I initially thought it was telling me to order the dependencies in the bst file | 19:15 |
| *** nimish has joined #buildstream | 19:16 | |
| tristan | agree that it is a source of confusion :) | 19:16 |
| cs-shadow | i'll try to submit a MR to try and improve the wording (or at least create an issue for it) | 19:16 |
| cs-shadow | thanks! | 19:16 |
| *** nimish has quit IRC | 19:26 | |
| *** nimish has joined #buildstream | 19:26 | |
| *** nimish_ has joined #buildstream | 19:32 | |
| *** nimish has quit IRC | 19:33 | |
| *** nimish_ is now known as nimish | 19:33 | |
| *** tristan has quit IRC | 19:35 | |
| *** nimish has quit IRC | 19:36 | |
| *** nimish has joined #buildstream | 19:41 | |
| *** bochecha_ has joined #buildstream | 19:42 | |
| *** bochecha has quit IRC | 19:42 | |
| *** bochecha_ is now known as bochecha | 19:43 | |
| *** nimish has quit IRC | 20:41 | |
| *** nimish has joined #buildstream | 20:41 | |
| *** xjuan has quit IRC | 20:42 | |
| *** lachlan has quit IRC | 20:52 | |
| *** xjuan has joined #buildstream | 21:01 | |
| *** nikc has joined #buildstream | 21:05 | |
| *** xjuan has quit IRC | 21:48 | |
| *** xjuan has joined #buildstream | 22:06 | |
| *** bochecha has quit IRC | 22:51 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!