*** tristan has quit IRC | 00:12 | |
*** Prince781 has joined #buildstream | 00:15 | |
*** toscalix has joined #buildstream | 01:37 | |
*** Prince781 has quit IRC | 01:44 | |
gitlab-br-bot | buildstream: issue #301 ("Fix circular imports") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/301 | 02:19 |
---|---|---|
*** Prince781 has joined #buildstream | 02:46 | |
*** mohan43u has joined #buildstream | 02:57 | |
*** toscalix has quit IRC | 03:09 | |
*** tristan has joined #buildstream | 03:10 | |
*** Prince781 has quit IRC | 05:18 | |
*** tristan has quit IRC | 06:26 | |
*** Trevinho has quit IRC | 06:28 | |
*** Trevinho has joined #buildstream | 06:29 | |
*** ernestask has joined #buildstream | 06:36 | |
*** toscalix has joined #buildstream | 07:30 | |
*** toscalix has quit IRC | 07:46 | |
*** coldtom has joined #buildstream | 07:57 | |
*** Phil has joined #buildstream | 08:06 | |
jmac | Grr, GitLab's issue interface is unusable on my laptop screen | 08:06 |
gitlab-br-bot | buildstream: merge request (138-aborting-bst-push-command-causes-stack-trace-3->master: WIP: Resolve "aborting bst push command causes stack trace") #514 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/514 | 08:21 |
gitlab-br-bot | buildstream: merge request (138-aborting-bst-push-command-causes-stack-trace-3->master: WIP: Resolve "aborting bst push command causes stack trace") #514 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/514 | 08:25 |
gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: WIP: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 08:29 |
*** slaf has quit IRC | 08:35 | |
*** slaf has joined #buildstream | 08:37 | |
*** slaf has joined #buildstream | 08:37 | |
*** slaf has joined #buildstream | 08:37 | |
*** slaf has joined #buildstream | 08:37 | |
laurence | coldtom, thanks for the recent MR :) | 08:37 |
laurence | could you add an avatar onto gitlab? | 08:38 |
laurence | helps identifying people | 08:38 |
*** slaf has joined #buildstream | 08:38 | |
*** slaf has joined #buildstream | 08:38 | |
*** slaf has joined #buildstream | 08:38 | |
*** bethw has joined #buildstream | 08:38 | |
*** slaf has joined #buildstream | 08:38 | |
*** slaf has joined #buildstream | 08:39 | |
*** slaf has joined #buildstream | 08:39 | |
*** jonathanmaw has joined #buildstream | 08:39 | |
*** slaf has joined #buildstream | 08:39 | |
*** slaf has joined #buildstream | 08:40 | |
paulsherwood | is buildgrid a real thing yet? | 08:41 |
paulsherwood | if so is there documentation somewhere? | 08:41 |
jmac | Yes, https://gitlab.com/BuildGrid/buildgrid | 08:42 |
jmac | finn is the maintainer | 08:42 |
paulsherwood | super thanks | 08:45 |
laurence | We are due another announcement to the Buildstream and BuildFarm ML actually | 08:46 |
laurence | finn_, do you want to do it ? | 08:46 |
finn_ | I'll announce later today after The Great Restructure | 08:47 |
*** finn_ is now known as finn | 08:48 | |
laurence | finn, I committed straight to master yesterday when fixing the CONTRIBUTING.rst doc | 08:53 |
laurence | so i think we need to re-look at gitlab permissions | 08:54 |
finn | Could be because you have owner permissions | 08:56 |
finn | master is a protected branch for which Maintainers are allowed to push / merge | 08:57 |
gitlab-br-bot | buildstream: merge request (phil/203-BuildStream-crashes-when-dependency-tree-too-deep->master: WIP: Phil/203 build stream crashes when dependency tree too deep) #512 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/512 | 09:04 |
tlater | jmac: To scroll through the right, abuse text selection by selecting something and dragging your mouse to continue the selection | 09:26 |
* tlater also dislikes this | 09:26 | |
jmac | Yeesh | 09:27 |
coldtom | the source for the autotools example/tests is currently giving a 503 | 09:43 |
gitlab-br-bot | buildstream: issue #434 ("Add documentation on workspaces") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/434 | 09:50 |
jmac | coldtom: Which URL is that? | 09:53 |
Phil | jmac, it's gnome7.codethink.co.uk | 09:54 |
jmac | Not familiar with that | 09:55 |
coldtom | yup that's the one | 09:56 |
tlater | jmac: It's where we host some tarballs... | 10:23 |
tlater | Also I believe the gnome-modulesets conversion used to be written into that | 10:23 |
jmac | OK, thanks. Has anyone reported it to Codethink? I can do so if need be | 10:24 |
tlater | jmac: That would be handy | 10:26 |
tlater | I think our test suite will fail for most of the day otherwise | 10:26 |
laurence | jmac, i think jjardon is in talks with Codethink Ops about this already... | 10:26 |
laurence | jjardon, ?? or is that another issue re struggling to access the moonshots? | 10:27 |
jmac | OK then | 10:27 |
gitlab-br-bot | buildstream: merge request (reduce_history_in_cache->master: Reduce history in cache) #482 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/482 | 10:28 |
jjardon | Laurence not about that, no | 10:28 |
*** dominic has joined #buildstream | 10:31 | |
*** dominic has quit IRC | 10:31 | |
laurence | jjardon, ok thanks | 10:40 |
laurence | jennis, i think i have missed some irc conversation here, so will just ask: did we agree that migrating the examples from the examples repo to the main repo makes sense? | 10:46 |
jennis | Yes, it's what we ultimately want to do as they will fit nicely into the new doc structure, and the projects themselves can live under doc/examples in the main repo | 10:47 |
persia | If we do that, we should be sure to create a build process that can easily exclude them (or segment them as docs) to ease installs for folk not running from the git repo | 10:47 |
persia | That works :) | 10:47 |
jennis | :) | 10:48 |
jennis | however, as it currently stands, the projects themselves in the buildstream-examples repo do not actually build... so that needs to be fixed first | 10:48 |
laurence | jennis, cheers | 10:49 |
gitlab-br-bot | buildstream: issue #438 ("Migrate X86 image example from examples repo to main repo") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/438 | 10:56 |
gitlab-br-bot | buildstream: issue #439 ("Migrate Netsurf example from examples repo to main repo") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/439 | 10:57 |
jmac | We have a Netsurf example? Cool. | 10:57 |
paulsherwood | "on BuilStream internals." | 10:58 |
gitlab-br-bot | buildstream: merge request (ps-fix-typo->master: Fix BuilStream typo) #515 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/515 | 11:10 |
tlater | laurence: I updated #438, it now lists the entire task breakdown. Sorry, been carrying this around in my mind. | 11:15 |
tlater | Can't comment much on what's missing for #439, sssam wrote that example. I suspect it's just a case of reformatting it, though. | 11:16 |
*** aday has quit IRC | 11:18 | |
*** aday has joined #buildstream | 11:19 | |
gitlab-br-bot | buildstream: merge request (ps-fix-typo->master: Fix BuilStream typo) #515 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/515 | 11:20 |
*** bethw has quit IRC | 11:22 | |
gitlab-br-bot | buildstream: merge request (ps-fix-typo->master: Fix BuilStream typo) #515 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/515 | 11:28 |
* paulsherwood fixes a one-char typo, then sees the CI pipeline fail on multiple OSes... what kind of shonky project is this? :) | 11:40 | |
laurence | tlater, thanks a lot! | 12:07 |
laurence | tlater, there's also the summary that's required for `bst shell` should be able to stage the specified element on top of a base element - https://gitlab.com/BuildStream/buildstream/issues/422 | 12:08 |
laurence | sorry, i am nagging now, but let's capture it whilst it's fresh | 12:08 |
tlater | paulsherwood: Our server that hosts test data is down | 12:09 |
* tlater is pretty annoyed as well :| | 12:09 | |
tlater | laurence: Planning to write that this afternoon, it takes a bit more thought to express properly | 12:10 |
laurence | cool | 12:18 |
laurence | thanks! | 12:19 |
*** ernestask has quit IRC | 12:35 | |
*** bethw has joined #buildstream | 12:42 | |
*** toscalix has joined #buildstream | 12:58 | |
toscalix | jjardon[m]: around? | 12:59 |
jjardon | toscalix: yes | 12:59 |
toscalix | I wrote again to the organisers of GUADEC | 12:59 |
toscalix | I just saw that the rooms have been taken but I did not received any response | 13:00 |
toscalix | I do not know what to do if they not answer me | 13:00 |
toscalix | do you have any contact I can ping directly? | 13:00 |
toscalix | looking at the wiki, the only available slots for our hackfest is wednesday | 13:00 |
jjardon | #guadec in irc.gnome.org ? who did you email? maube you can CC me? | 13:01 |
toscalix | I just did | 13:02 |
toscalix | CC you | 13:02 |
jjardon | toscalix: did you read https://wiki.gnome.org/GUADEC/2018/Hacking%20days ? Seems you simply have to add you BOF there | 13:02 |
jmac | Thanks for the email finn_ | 13:03 |
jmac | BTW, I'm working with bazel-buildfarm at the moment to see if we can get it to work with Buildgrid, so should be able to do a review | 13:03 |
noisecell | finn, in the README on https://gitlab.com/BuildGrid/buildgrid "BuildGrid is a python remote execution service which implements the Remote Execution API and the Remote Workers API." both links points to the same place "Remote Workers API" file - | 13:08 |
toscalix | jjardon: will try to add it myself then | 13:09 |
finn | ta, shall correct | 13:09 |
toscalix | it will need to be on monday and wednesday | 13:10 |
toscalix | mornings | 13:10 |
toscalix | I would like to avoid wednesday afternoon | 13:10 |
toscalix | jjardon: I am editing directly the wiki | 13:17 |
toscalix | should we use the monday morning for sync up with the release team and gnome devs and wed morning for hacking on BuildStream? | 13:17 |
*** finn has quit IRC | 13:30 | |
tlater | NB ALL: gnome7 is back up, your CI should now happily pass again :) | 13:33 |
Phil | \o/ | 13:33 |
*** Sebastian has joined #buildstream | 13:33 | |
tlater | tristan (whenever you appear): *only* the IP address of gnome7 has been changed, any other pending configuration is left for you to complete. | 13:33 |
*** Sebastian has quit IRC | 13:37 | |
*** finn has joined #buildstream | 13:59 | |
*** aday has quit IRC | 14:05 | |
*** ernestask has joined #buildstream | 14:14 | |
*** sstriker has joined #buildstream | 14:16 | |
*** aday has joined #buildstream | 14:31 | |
*** toscalix has quit IRC | 14:34 | |
*** aday has quit IRC | 14:37 | |
*** aday has joined #buildstream | 14:38 | |
*** aday has quit IRC | 14:42 | |
*** aday has joined #buildstream | 14:42 | |
laurence | finn, have you had a poke around the API since it's been on github? | 14:47 |
laurence | https://github.com/bazelbuild/remote-apis/ | 14:47 |
laurence | wondering if the worker API is in there too | 14:47 |
laurence | or it's just the remote execution | 14:48 |
finn | That's just the remote execution api | 14:49 |
finn | I am now wondering why the worker isn't in there too | 14:49 |
laurence | seems odd that the workers API is still on a google doc | 14:49 |
laurence | aye | 14:49 |
laurence | noisecell, links fixed now, thanks | 14:52 |
gitlab-br-bot | buildstream: issue #430 ("BuildStream.doap is incorrectly included in MANIFEST.in") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/430 | 15:14 |
gitlab-br-bot | buildstream: issue #430 ("BuildStream.doap is incorrectly included in MANIFEST.in") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/430 | 15:14 |
gitlab-br-bot | buildstream: merge request (430-buildstream-doap-is-incorrectly-included-in-manifest-in->master: Resolve "BuildStream.doap is incorrectly included in MANIFEST.in") #508 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/508 | 15:14 |
*** tristan has joined #buildstream | 15:23 | |
*** Prince781 has joined #buildstream | 15:30 | |
tristan | valentind, are you still around ? I think we had to catch up on includes but yesterday around this time I was busy with Nexus ... | 15:33 |
gitlab-br-bot | buildstream: merge request (ps-fix-typo->master: Fix BuilStream typo) #515 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/515 | 15:44 |
valentind | tristan, I was also busy yesterday. | 15:46 |
valentind | So, this is about this separation of the plugin configuration code from Project class. | 15:47 |
valentind | The reason we have to extract it is that because we now have 2 configurations for the plugins. One before includes are processed. One after. | 15:48 |
valentind | And the reason we have two configurations instead of updating configuration is to make sure that junctions are always interpreted the same way. | 15:49 |
valentind | So that a source plugin used in a junction becomes different whether you use the junction or not for finding include files. | 15:50 |
tristan | Ah here we are | 15:56 |
gitlab-br-bot | buildstream: issue #440 ("Should we implement a (remote) CAS-based SourceCache?") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/440 | 15:57 |
*** Sebastian has joined #buildstream | 15:58 | |
tristan | valentind, soooooo from what I understand... you reinstantiate junctions ? | 15:58 |
valentind | tristan, No. | 15:58 |
valentind | I do not. That is the point. | 15:58 |
valentind | I have only one instance of it. | 15:58 |
tristan | hehe | 15:58 |
tristan | you reinstantiate the sources ? | 15:59 |
tristan | of the junctions ? | 15:59 |
valentind | But for that, it means we always need to load it like the project.conf was incomplete. | 15:59 |
valentind | Yes, we have several instance of the plugins. | 15:59 |
tristan | I see what you mean, I think | 15:59 |
valentind | At least the ones used in by junctions. | 15:59 |
tristan | What I have in mind, is that we load everything at once and let the includes "float", and do composition in a later pass | 16:00 |
tristan | s/have/had | 16:00 |
tristan | but | 16:00 |
tristan | I think you are pointing out that is not really possible, at least: It is impossible to use an include to configure a junction source | 16:00 |
*** Phil has quit IRC | 16:01 | |
valentind | I think it is not possible right. | 16:01 |
valentind | Also there would be so many corner cases. | 16:01 |
*** Sebastian has quit IRC | 16:01 | |
tristan | There are a few ugly edge cases, one thing I wanted to test for is that `bst track` correctly updates the included file which was used to configure the associated Source | 16:01 |
tristan | but that has to trigger an error in the case that you include a cross-junction file to configure your source | 16:02 |
valentind | tristan, Can you describe the case, I can write a test for it. | 16:02 |
*** Sebastian has joined #buildstream | 16:02 | |
valentind | Yes. so there are things like a junction needing a configuration from another junction, the problem is that we have no way to know the order of loading. | 16:02 |
valentind | So, the best is to say for now, it is not possible. | 16:03 |
valentind | And because include is a new feature, we have the right to restrict inclusion for junctions. | 16:03 |
tristan | This is true, well; I was thinking about making include illegal in `project.refs` | 16:04 |
tristan | valentind, if we say that include is illegal for a junction element, and illegal for `project.refs`, is it allowed everywhere else ? | 16:07 |
* tristan has to refresh his memory on the patch itself now | 16:08 | |
tristan | right, I didnt like how we are creating new high level Source/Element thingies again, for plugins | 16:08 |
valentind | Yes. I think it should be fine. | 16:08 |
valentind | I have not seen in the code any other case that was tricky. | 16:09 |
tristan | There is some precedent for sharing project loading codepaths | 16:09 |
tristan | project hands off some loading stuff to the artifact cache | 16:09 |
tristan | not necessarily that it's a good thing | 16:09 |
valentind | I am not sure what you mean here. | 16:11 |
valentind | Your objection was about this new class for loading plugin configurations. Which was legitimate. But I want you to see the reason behind. Because what you asked for, I am not sure it would work for what we need. | 16:13 |
valentind | We need to have 2 sets of plugin configuration. | 16:13 |
*** Sebastian has quit IRC | 16:17 | |
tristan | Right | 16:18 |
tristan | valentind, if we added that in PluginContext once, we'd have already two instances of that | 16:18 |
*** Sebastian has joined #buildstream | 16:18 | |
tristan | valentind, well two instances for each project, actually | 16:18 |
tristan | there is on ElementFactory and one SourceFactory for each loaded project | 16:19 |
valentind | tristan, OK, I can try that. I will see if it works. | 16:19 |
valentind | I think there was some downsides. But I do not remember. I think the best is for me to try it and see how it looks. | 16:19 |
valentind | So we would have 2 ElementFactory and 2 SourceFactory in a project. | 16:20 |
tristan | Would we ? ok hold on a second | 16:20 |
valentind | Anyway, I already have a class for duplicated fields. | 16:20 |
* tristan rereads, it's early | 16:20 | |
valentind | Well. We do not need 2 ElementFactory. | 16:21 |
valentind | But we do need 2 SourceFactory. | 16:21 |
*** Sebastian has quit IRC | 16:21 | |
tristan | Aha I see | 16:22 |
valentind | Ah yes. We do need to load the junction plugin with the other ElementFactory. | 16:22 |
tristan | right, 2 configurations | 16:22 |
valentind | One with includes. One without. | 16:22 |
tristan | When do we resolve project includes ? | 16:22 |
*** Sebastian has joined #buildstream | 16:23 | |
valentind | It is in Project._load | 16:24 |
valentind | We have two pass. | 16:24 |
*** finn has quit IRC | 16:26 | |
*** sstriker has quit IRC | 16:26 | |
*** bethw has quit IRC | 16:28 | |
*** finn has joined #buildstream | 16:32 | |
*** ernestask has quit IRC | 16:35 | |
*** aday has quit IRC | 16:36 | |
gitlab-br-bot | buildstream: issue #418 ("Should we use a CAS-based source cache as a mirror?") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/418 | 16:41 |
tristan | valentind, error handling looks clever | 16:45 |
tristan | So, we're squeezing validation through, but is that really required ? | 16:45 |
tristan | it should not be | 16:45 |
tristan | valentind, is it late for you ? | 16:45 |
tristan | I can do more comments on the issue at this point I think | 16:45 |
valentind | It is a bit. But it is fine. But now you got what I meant, I think you can write the comments on the MR. I will look at them later. | 16:46 |
tristan | I think that we don't need that cleverness of validating within the includes | 16:46 |
tristan | The way it's supposed to work: | 16:46 |
valentind | I think you are right, we could delay validation. Though we do interpret options. So it should work. | 16:46 |
tristan | o Blind dictionary composition | 16:47 |
tristan | o Validation and _yaml.node_get() | 16:47 |
tristan | o When an error occurs, use the associated Provenance object | 16:47 |
valentind | What do you mean by blind? | 16:47 |
tristan | The Provenance object should show that the undesired value comes from the file/line/col it was introduced at | 16:48 |
tiago | I am getting a "/home/tiagogomes/buildstream/doc/source/buildstream.sandbox.rst:document isn't included in any toctree" error when trying to build the documentation. Is this a known issue? | 16:48 |
*** tiago is now known as tiagogomes | 16:48 | |
tristan | valentind, I mean, not blind but; without caring about the details of validating them one by one :) | 16:48 |
valentind | Oh OK. I can remove some of the validation. | 16:48 |
tristan | valentind, so we only validate once (and probably change a bit less code, as the validations stay where they approximately were) | 16:49 |
tristan | I think the principal of Provenance object is sound and we've been relying on it; the thing might have bugs but... mostly it's working | 16:49 |
tristan | there is a case where it needs interaction to tell it a specific file, I think that case is when something is expected but not found | 16:50 |
valentind | tristan, OK. Just add that the MR. I will soon go to the store. Will be back in 1h30. I can read the comments and then talk to you if there are any other issue I want to discuss. | 16:50 |
tristan | ok ok | 16:50 |
tristan | valentind, I'm not sure about having to change that project plugin collection thing, lemme look a bit deeper | 16:51 |
*** aday has joined #buildstream | 16:52 | |
*** jonathanmaw has quit IRC | 16:59 | |
*** coldtom has quit IRC | 16:59 | |
gitlab-br-bot | buildstream: merge request (jjardon/host_deps->master: Document BuildStream's plugins host packages dependencies) #495 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/495 | 17:01 |
gitlab-br-bot | buildstream: merge request (tristan/host-deps->master: Rebase and fixup Javier's host dependency docs branch !495) #516 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/516 | 17:10 |
gitlab-br-bot | buildstream: merge request (jjardon/host_deps->master: Document BuildStream's plugins host packages dependencies) #495 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/495 | 17:12 |
*** tiagogomes has quit IRC | 17:19 | |
*** Sebastian has quit IRC | 17:40 | |
gitlab-br-bot | buildstream: merge request (tristan/host-deps->master: Rebase and fixup Javier's host dependency docs branch !495) #516 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/516 | 17:50 |
*** aday has quit IRC | 19:07 | |
*** tristan has quit IRC | 19:44 | |
*** bethw has joined #buildstream | 20:07 | |
*** bethw has quit IRC | 20:09 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!