| *** tristan has quit IRC | 05:48 | |
| *** tristan has joined #buildstream | 05:53 | |
| *** toscalix has joined #buildstream | 07:03 | |
| *** bethw has joined #buildstream | 07:54 | |
| *** mohan43u has quit IRC | 08:12 | |
| *** mohan43u_ has joined #buildstream | 08:12 | |
| *** slaf has quit IRC | 08:17 | |
| *** bethw has quit IRC | 08:18 | |
| *** slaf has joined #buildstream | 08:19 | |
| *** aday has joined #buildstream | 08:28 | |
| *** toscalix has quit IRC | 08:35 | |
| *** toscalix has joined #buildstream | 08:41 | |
| *** noisecell has joined #buildstream | 08:45 | |
| gitlab-br-bot | buildstream: merge request (tristan/symbol-name-hardening->master: hardening of symbol names in the format) #365 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/365 | 08:50 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (tristan/symbol-name-hardening->master: hardening of symbol names in the format) #365 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/365 | 08:51 |
| *** jonathanmaw has joined #buildstream | 08:52 | |
| *** bethw has joined #buildstream | 08:54 | |
| *** dominic has joined #buildstream | 09:01 | |
| *** sstriker has joined #buildstream | 09:09 | |
| gitlab-br-bot | buildstream: issue #339 ("Can't use project names with spaces in") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/339 | 09:11 |
| gitlab-br-bot | buildstream: merge request (tristan/symbol-name-hardening->master: hardening of symbol names in the format) #365 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/365 | 09:11 |
| gitlab-br-bot | buildstream: issue #340 ("If no project name found (eg because no project.conf) set it to a default, with a warning") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/340 | 09:14 |
| *** striker has joined #buildstream | 09:17 | |
| *** valentind has quit IRC | 09:21 | |
| tlater | Are artifacts supposed to be in the cache after pulling? | 09:27 |
| * tlater has a failing junctions test :( | 09:27 | |
| tlater | Ah, it simply has both a weak and a strong key but not both are in the cache | 09:29 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 09:42 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 09:49 |
| *** mohan43u_ has quit IRC | 09:59 | |
| *** mohan43u has joined #buildstream | 09:59 | |
| *** cs_shadow has joined #buildstream | 10:20 | |
| tlater | tristan: We never finished our conversation on this dependency: https://gitlab.com/BuildStream/buildstream/merge_requests/347/diffs?commit_id=13839bddf39cb450b8f8ff6f3f59d0406da54acb | 10:29 |
| tlater | Would you be happy to add that? I suspect jennis' branch will need something similar, and if we do eventually add prompts for cache quota we'll probably want to do the reverse. | 10:30 |
| tlater | It also happens to support is_a_tty(), which means it could replace blessings | 10:30 |
| cs_shadow | Hi! while developing a system to manage our BuildStream projects, we realized that one thing that we need to often is to update the tracking branch or ref in a bst file. So, to set the ref to a given value, is it recommended to edit the bst file directly (using normal yaml tooling) or to use some BuildStream API? Or, do we need to add some plumbing commands like `bst set-ref`? | 10:33 |
| tristan | cs_shadow, it would be good to have a deeper understanding of the workflow for this | 10:35 |
| tristan | cs_shadow, I would caution against manual setting refs with ruamel.yaml, because this makes an assumption about `ref-storage` (http://buildstream.gitlab.io/buildstream/projectconf.html#ref-storage) | 10:36 |
| tristan | cs_shadow, note also, that already some tricks can be played with project options | 10:38 |
| cs_shadow | okay, one use-case for setting refs is that for some projects, we might not know a tracking branch but only the commit sha. So, we can't use `bst track` but we will know the new commit sha. And would like to somehow update the ref in the bst file. | 10:39 |
| cs_shadow | so i'm trying to understand what would be the best way of achieving this | 10:39 |
| tristan | like, one can encode tracking branches at authoring time manually, but then have `bst --option main_branch foo track element.bst`, and if the ref is also already conditionalized, tracking will properly occur within a specific option | 10:39 |
| tristan | hmmm, "tracking outside of buildstream" | 10:40 |
| tristan | cs_shadow, would it not make sense to use custom Source implementations for this ? | 10:40 |
| tristan | or consider restructure of code to allow some separation of tracking responsibilities (TrackProviders ?) | 10:41 |
| sstriker | tristan: sounds like we need a set-ref command... I can think of use cases for this as well, where refs are provided as inputs rather than being resolved by track. | 10:41 |
| tristan | I mean, if they are provided as inputs, they are resolved from *somewhere* | 10:42 |
| tristan | even if that is a file | 10:42 |
| sstriker | True. Maybe be able to track and feed in the same file format that we conceived for split refs? | 10:43 |
| tristan | Then again, from a user perspective, if you have policy to ensure ref-storage = project.refs, you can simplify workflow with a simple tool which updates project.refs with ruamel.yaml | 10:43 |
| sstriker | That feels a bit circular though | 10:44 |
| sstriker | True | 10:44 |
| cs_shadow | well, yes, they are definitely coming for somewhere but it may be hard to encode that in a way that bst track can work | 10:44 |
| tristan | right, i.e. we already have split refs into project.refs and a strongly defined format for it (project.refs is not some internal detail) | 10:44 |
| cs_shadow | So, updating project.refs directly with ruamel.yaml is fair game then? | 10:44 |
| tristan | cs_shadow, right, I dont have the whole picture, but it's certainly fair game, the only constraint is that you are in control of the projects you use :) | 10:45 |
| tristan | which, I think this whole "knowing your explicit refs" statement already implies | 10:45 |
| tristan | cs_shadow, "fair game" inasmuch as, it's part of the API stability guarantees, and users are anyway allowed to manually write them | 10:46 |
| cs_shadow | tristan: thanks! yes, we should have control of these projects. I was just trying to ensure that updating project.refs isn't considered a part of the private API | 10:47 |
| tristan | cs_shadow, for forward compatibility (i.e. if ever additional features are added to project.refs, and you want to *use* those), I would recommend ruamel.yaml and round-trip editing (load/edit/save) | 10:48 |
| tristan | that would allow you to manually put stuff in there (I dont see why we need to extend that, but it's a possibility), without overwriting things with your updater | 10:48 |
| cs_shadow | tristan: yep, that makes sense. thanks! | 10:50 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 11:21 |
| tristan | cs_shadow, sstriker note also, when initially doing project.refs, juergbi and I were discussing that it might be interesting to allow specifying a path for it on the command line | 11:23 |
| tristan | such that a different project.refs is in use for a given session; that might be of interest to you, and is quite easy to implement | 11:24 |
| *** aday has quit IRC | 11:40 | |
| *** sstriker has quit IRC | 11:41 | |
| gitlab-br-bot | buildstream: issue #343 ("initial cache-key resolution should display whole key, not just a short SHA") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/343 | 11:48 |
| jmac | Are the BuildStream docker images specific to x8664? | 11:57 |
| tristan | I expect they are | 11:58 |
| tlater | Yeah, docker doesn't do architectures | 11:59 |
| tlater | Although I think a recent Dockerfile format added some support for that | 11:59 |
| jmac | grr | 11:59 |
| tristan | A quick look at https://gitlab.com/BuildStream/buildstream-docker-images/ shows me that the .gitlab-ci.yml and the fedora/ subdir has a complete neglect for specifying the arch | 12:00 |
| tristan | so yeah, tlater who might know the first thing or two about docker (unlike myself), would seem to be right | 12:00 |
| * tristan has to say that docker has a clear advantage over kubernetes: As a person who doesnt want to understand the buzzwords, docker is only 50% of the syllables, reducing a lot of the noise... | 12:02 | |
| tristan | </snark> | 12:02 |
| tlater | ;p | 12:02 |
| jmac | +1 | 12:02 |
| *** tristan has quit IRC | 12:17 | |
| *** tristan has joined #buildstream | 12:22 | |
| *** aday has joined #buildstream | 12:35 | |
| gitlab-br-bot | buildstream: merge request (node-get-default->master: Allow 'None' as a default_value for _yaml.node_get) #366 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/366 | 12:36 |
| gitlab-br-bot | buildstream: merge request (node-get-default->master: Allow 'None' as a default_value for _yaml.node_get) #366 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/366 | 12:37 |
| *** xjuan has joined #buildstream | 12:38 | |
| gitlab-br-bot | buildstream: merge request (node-get-default->master: Allow 'None' as a default_value for _yaml.node_get) #366 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/366 | 12:40 |
| gitlab-br-bot | buildstream: merge request (node-get-default->master: Allow 'None' as a default_value for _yaml.node_get) #366 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/366 | 12:43 |
| *** dominic has quit IRC | 12:43 | |
| *** dominic has joined #buildstream | 12:43 | |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 12:44 |
| tristan | tlater, just made a couple comments there, no time for a full review but so far looking good... | 12:45 |
| tlater | tristan: ta :) | 12:45 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 13:16 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 13:19 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 13:19 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 13:19 |
| * tlater wonders if we should always lead local private symbols with an underscore | 13:29 | |
| gitlab-br-bot | buildstream: merge request (node-get-default->master: Allow 'None' as a default_value for _yaml.node_get) #366 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/366 | 13:29 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 13:31 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 13:32 |
| jmac | Setting up BuildStream on debian stretch is a real pain | 13:41 |
| tlater | jmac: Agreed - we have a docker image that goes through the whole thing :) | 13:47 |
| tlater | jmac: The main pain is ostree, there's a script in the repo that does that: https://gitlab.com/BuildStream/buildstream-docker-images/tree/master/testsuite/debian-8 | 13:48 |
| jmac | Ah, but your docker image doesn't work on my hardware :) | 13:49 |
| jmac | However, the list of debian packages in ostree.sh is useful | 13:49 |
| tlater | Yeah, the docker image doesn't, but the install instructions that build it should still do. | 13:50 |
| jmac | The list of prerequisites in ostree.sh is not complete | 13:52 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 13:53 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 13:53 |
| tlater | jmac: Erk, that's annoying, I'd hoped it would be. That script runs after prepare.sh, perhaps there's a dependency or two that buildstream and ostree share? | 13:54 |
| jmac | Ah, no, it's actually fine. It just requires that specific version of ostree; upstream ostree has more dependencies. | 13:56 |
| gitlab-br-bot | buildstream: merge request (node-get-default->master: Allow 'None' as a default_value for _yaml.node_get) #366 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/366 | 14:01 |
| *** toscalix has joined #buildstream | 14:09 | |
| *** toscalix_ has joined #buildstream | 14:11 | |
| *** toscalix has quit IRC | 14:13 | |
| gitlab-br-bot | buildstream: merge request (jennis/136-expire-remote-cache-artifacts->master: WIP:136 expire remote cache artifacts) #364 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/364 | 15:09 |
| *** toscalix_ has quit IRC | 15:16 | |
| *** toscalix has joined #buildstream | 15:29 | |
| *** valentind has joined #buildstream | 15:53 | |
| *** bethw has quit IRC | 16:00 | |
| gitlab-br-bot | buildstream: issue #344 ("junctions don't work with project.refs references") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/344 | 16:10 |
| *** jonathanmaw has quit IRC | 16:14 | |
| *** sstriker has joined #buildstream | 16:16 | |
| *** noisecell has quit IRC | 16:25 | |
| *** sstriker has quit IRC | 16:41 | |
| *** dominic has quit IRC | 16:49 | |
| *** tiago has quit IRC | 17:05 | |
| *** toscalix has quit IRC | 17:09 | |
| *** sstriker has joined #buildstream | 17:15 | |
| tristan | tlater, if the documentation in HACKING.rst is ambiguous let me know, the question is mostly about *scope*, and whether the symbol will be accessed outside of *scope* | 17:16 |
| tristan | tlater, if an object in a module is "local private", the object itself needs an underscore, the member accessed in the same module are not local private to that object | 17:17 |
| *** striker has quit IRC | 17:17 | |
| tristan | similarly, if an object is local private, it's members are not local private if they are to be accessed outside of that module's scope | 17:19 |
| tristan | err, s/if an object/if a module/ | 17:19 |
| tristan | in other news, I lost a tooth today, which had a root canal last week and was planned for some work | 17:20 |
| tristan | luckily I have a dentist appointment tomorrow :) | 17:20 |
| * tristan hopes he doesnt have to lose the whole tooth now that it broke :-S | 17:20 | |
| *** sstriker2 has joined #buildstream | 17:23 | |
| *** sstriker2 has quit IRC | 17:23 | |
| *** tiago has joined #buildstream | 17:26 | |
| *** tiago has quit IRC | 17:26 | |
| *** jsgrant has joined #buildstream | 17:48 | |
| gitlab-br-bot | buildstream: issue #344 ("junctions don't work with project.refs references") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/344 | 18:09 |
| jjardon[m] | 1.1.3 IS OUT! | 18:17 |
| jjardon[m] | ah no, https://buildstream.gitlab.io/buildstream/ tricked me | 18:18 |
| tristan | I dont know why it's doing that, seems that setuptools_scm assumes a version bump when version ? release tag | 18:19 |
| tristan | s/?/> | 18:20 |
| *** sstriker has quit IRC | 18:22 | |
| jjardon[m] | no, idea; I will try to take a look over the weekend | 18:22 |
| *** jsgrant has quit IRC | 18:36 | |
| *** jsgrant has joined #buildstream | 18:37 | |
| *** tristan has left #buildstream | 18:44 | |
| *** tristan has joined #buildstream | 18:44 | |
| *** aday has quit IRC | 18:45 | |
| *** tristan has quit IRC | 19:56 | |
| *** jsgrant has quit IRC | 20:06 | |
| *** jsgrant has joined #buildstream | 20:07 | |
| *** jsgrant has quit IRC | 20:29 | |
| *** jsgrant has joined #buildstream | 20:29 | |
| *** jsgrant has quit IRC | 20:44 | |
| *** cs_shadow has quit IRC | 21:10 | |
| *** valentind has quit IRC | 21:15 | |
| *** valentind has joined #buildstream | 21:15 | |
| *** valentind has quit IRC | 21:18 | |
| *** valentind has joined #buildstream | 21:22 | |
| *** valentind has quit IRC | 21:26 | |
| *** valentind has joined #buildstream | 21:26 | |
| *** jsgrant has joined #buildstream | 21:59 | |
| *** xjuan has quit IRC | 22:59 | |
| *** jsgrant has quit IRC | 23:31 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!