| *** Sebastian has quit IRC | 00:29 | |
| *** Sebastian has joined #buildstream | 00:31 | |
| *** Sebastian has quit IRC | 00:34 | |
| *** Sebastian has joined #buildstream | 00:35 | |
| gitlab-br-bot | buildstream: merge request (tristan/running-commands->master: doc: Adding part 2 of the getting started tutorial) #502 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/502 | 01:11 |
|---|---|---|
| *** Sebastian has quit IRC | 01:18 | |
| gitlab-br-bot | buildstream: merge request (tristan/running-commands->master: doc: Adding part 2 of the getting started tutorial) #502 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/502 | 01:37 |
| gitlab-br-bot | buildstream: merge request (tristan/running-commands->master: doc: Adding part 2 of the getting started tutorial) #502 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/502 | 02:13 |
| *** tristan has quit IRC | 04:02 | |
| *** noisecell has joined #buildstream | 06:09 | |
| *** noisecell has quit IRC | 06:16 | |
| *** coldtom has joined #buildstream | 07:30 | |
| *** Phil has joined #buildstream | 07:45 | |
| *** jsgrant has quit IRC | 08:28 | |
| *** jonathanmaw has joined #buildstream | 08:39 | |
| *** bethw has joined #buildstream | 08:45 | |
| *** noisecell has joined #buildstream | 08:58 | |
| *** dominic has joined #buildstream | 09:24 | |
| *** jonathanmaw has quit IRC | 09:41 | |
| *** jonathanmaw has joined #buildstream | 09:57 | |
| *** cs_shadow has joined #buildstream | 10:05 | |
| *** Phil has quit IRC | 11:13 | |
| adds68 | Hi when using the new CAS, when buildstream tries to the CAS, i am seeing an error with permissions | 11:13 |
| adds68 | grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with (StatusCode.UNKNOWN, Exception calling application: [Errno 13] Permission denied: '/home/artifacts/artifacts/cas/tmp/tmp_9_ezrrz')> | 11:13 |
| adds68 | Has anyone seen this before? | 11:14 |
| adds68 | push to the** | 11:14 |
| *** aday has joined #buildstream | 11:15 | |
| *** Sebastian has joined #buildstream | 11:22 | |
| *** Sebastian has quit IRC | 11:44 | |
| *** Sebastian has joined #buildstream | 11:45 | |
| *** Sebastian has quit IRC | 11:48 | |
| *** Sebastian has joined #buildstream | 11:49 | |
| *** Phil has joined #buildstream | 11:57 | |
| *** Sebastian has quit IRC | 11:59 | |
| *** Sebastian has joined #buildstream | 12:00 | |
| jmac | adds68: Hmm, let me have a look | 12:01 |
| jmac | adds68: No, I've not got that error in my logs. I have been getting errors similar to "No such file or directory: /home/jimmacarthur/artifacts/cas/tmp/tmpcpwk8_eh" but that's usually solved by manually creating cas/tmp. | 12:03 |
| *** Sebastian has quit IRC | 12:03 | |
| jmac | It's almost certainly a server-side error, if that helps | 12:04 |
| *** Phil has quit IRC | 12:04 | |
| *** Sebastian has joined #buildstream | 12:04 | |
| *** Phil has joined #buildstream | 12:09 | |
| gitlab-br-bot | buildstream: issue #427 ("pylint version too permissive") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/427 | 12:22 |
| gitlab-br-bot | buildstream: merge request (dp0/pylint_restrict->master: Restrict version of pylint) #503 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/503 | 12:35 |
| adds68 | jmac, sorry just popped out | 12:41 |
| adds68 | jmac, oh nice! Thank you, i will try that now | 12:41 |
| *** Sebastian has quit IRC | 13:03 | |
| *** Sebastian has joined #buildstream | 13:05 | |
| *** Sebastian has quit IRC | 13:08 | |
| *** Sebastian has joined #buildstream | 13:10 | |
| gitlab-br-bot | buildstream: issue #428 ("Unhandled exception when trying to push to the bst CAS") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/428 | 13:13 |
| gitlab-br-bot | buildstream: merge request (issue-191_relative_workspaces->master: WIP: Patch for issue #191 support relative workspaces) #251 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/251 | 13:16 |
| *** xjuan has joined #buildstream | 13:23 | |
| adds68 | jmac, seems that did not solve the issues =/ | 13:25 |
| adds68 | jmac, i'm wondering if it's due to those directories being created as root? | 13:25 |
| jmac | They shouldn't be. Are you running the cache serve as root? | 13:26 |
| adds68 | jmac, no that is running under "artifacts" user | 13:27 |
| adds68 | jmac, should i remove those directories and then recreate them as the artifacts users? | 13:27 |
| adds68 | user* | 13:27 |
| jmac | Yes, they shouldn't be owned by root | 13:28 |
| gitlab-br-bot | buildstream: merge request (dp0/pylint_restrict->master: WIP: Restrict version of pylint) #503 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/503 | 13:40 |
| gitlab-br-bot | buildstream: merge request (issue-191_relative_workspaces->master: WIP: Patch for issue #191 support relative workspaces) #251 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/251 | 13:40 |
| *** Phil has quit IRC | 13:41 | |
| *** Phil has joined #buildstream | 13:41 | |
| gitlab-br-bot | buildstream: merge request (dp0/pylint_restrict->master: WIP: Restrict version of pylint) #503 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/503 | 13:41 |
| *** Sebastian has quit IRC | 13:42 | |
| *** Sebastian has joined #buildstream | 13:47 | |
| *** Sebastian has quit IRC | 13:53 | |
| *** toscalix has joined #buildstream | 13:54 | |
| *** Sebastian has joined #buildstream | 13:55 | |
| toscalix | tlater: are you working on https://gitlab.com/BuildStream/buildstream/issues/135 ? | 13:55 |
| toscalix | Since I am travelling, I am following the project offline and it is very hard | 13:56 |
| tlater | toscalix: I am, though admittedly it's not my number one priority at the moment | 13:56 |
| tlater | The lack of updates stems from my not making any progress over the past week | 13:57 |
| toscalix | if people does not include updates every couple of days or three in the tickets. Sadly following the merge requests at this scale in gitlab is impossible | 13:57 |
| toscalix | when I see the doing column, I wonder if it reflects what is going on | 13:57 |
| toscalix | tlater: I know, it is not on you, it is a general thing | 13:57 |
| toscalix | if you are not actively working on the ticket, send it to ToDo state | 13:58 |
| gitlab-br-bot | buildstream: merge request (relative_workspaces->master: WIP: Patch for issue #191 support relative workspaces) #504 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/504 | 13:58 |
| toscalix | it reflect better what is going on | 13:58 |
| toscalix | will do that now on that ticket | 13:58 |
| tlater | Yes, that's probably better. | 13:58 |
| *** tristan has joined #buildstream | 14:04 | |
| gitlab-br-bot | buildstream: merge request (gokcen/source_transform->master: WIP: Source transform plugin) #505 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/505 | 14:05 |
| *** bethw has quit IRC | 14:08 | |
| *** bethw has joined #buildstream | 14:10 | |
| toscalix | tlater: done | 14:13 |
| *** bethw has quit IRC | 14:13 | |
| toscalix | I will ping people about this same topic | 14:13 |
| toscalix | individually | 14:13 |
| gitlab-br-bot | buildstream: issue #429 ("BuildStream refuses to cache artifacts with files that have very strict permissions") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/429 | 14:24 |
| gitlab-br-bot | buildstream: merge request (gokcen/source_transform->master: WIP: Source transform plugin) #505 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/505 | 14:24 |
| adds68 | jmac, changing to the artifacts user solved the issue, thank you! | 14:38 |
| gitlab-br-bot | buildstream: merge request (relative_workspaces->master: WIP: Patch for issue #191 support relative workspaces) #504 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/504 | 14:39 |
| jmac | adds68: Great! Can you update issue 428 when you get a chance? | 14:40 |
| adds68 | jmac, yes i will do that now :) | 14:41 |
| *** bethw has joined #buildstream | 14:44 | |
| *** Sebastian has quit IRC | 14:49 | |
| *** Sebastian has joined #buildstream | 14:52 | |
| *** Sebastian has joined #buildstream | 14:55 | |
| *** tristan has quit IRC | 14:56 | |
| *** Phil has quit IRC | 15:01 | |
| *** Phil has joined #buildstream | 15:02 | |
| *** Prince781 has joined #buildstream | 15:12 | |
| *** Prince781 has quit IRC | 15:40 | |
| *** Prince781 has joined #buildstream | 15:41 | |
| *** Phil has quit IRC | 15:44 | |
| *** Phil has joined #buildstream | 15:44 | |
| gitlab-br-bot | buildstream: merge request (remove_shebangs->master: Remove shebangs from python files) #506 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/506 | 15:48 |
| *** tristan has joined #buildstream | 15:54 | |
| laurence | I am trying to go through gitlab and tidy up some issues / MRs... | 16:06 |
| laurence | Nexus, please can you update the MR for caching build trees? we spoke f2f earlier about those tests that were failing, please can you add the details to the ticket | 16:06 |
| laurence | https://gitlab.com/BuildStream/buildstream/merge_requests/474 | 16:06 |
| *** bethw has quit IRC | 16:08 | |
| laurence | Nexus, also looks as though the MR for reducing history in cache should be updated - https://gitlab.com/BuildStream/buildstream/merge_requests/482 | 16:09 |
| laurence | there's 2 comments with no response. | 16:09 |
| laurence | tristan, a piece of work that followed on from the work done on caching build trees is 'adding sources to bst shell' - https://gitlab.com/BuildStream/buildstream/issues/413 | 16:10 |
| laurence | could you review Nexus' plan and provide some feedback? | 16:10 |
| laurence | jonathanmaw, pls can you update the MR for source mirroring client side with a status update? - https://gitlab.com/BuildStream/buildstream/merge_requests/404 | 16:13 |
| gitlab-br-bot | buildstream: merge request (188-trigger-external-commands-on-certain-events->master: WIP: Resolve "Trigger external commands on certain events") #226 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/226 | 16:16 |
| jonathanmaw | laurence: okie doke | 16:17 |
| *** j1mc_polari has quit IRC | 16:29 | |
| *** Sebastian has quit IRC | 16:30 | |
| *** coldtom has quit IRC | 16:30 | |
| *** jcampbell has joined #buildstream | 16:31 | |
| *** dominic has quit IRC | 16:32 | |
| cs_shadow | tristan: Hi, when you have some time, I'd like to hear your thoughts on https://gitlab.com/BuildStream/buildstream/issues/422 (https://gitlab.com/BuildStream/buildstream/issues/425 is also related). Let me know if any of the proposed approaches seem okay to you | 16:39 |
| tlater | cs_shadow: For the record, tristan suggested I start on 425 yesterday :) | 16:41 |
| tlater | Admittedly, 422 is so closely related that I think we might be looking at a bigger issue here, but adding `--deps` really just makes checkout more consistent with everything else, so I don't see any downside to it. | 16:42 |
| cs_shadow | tlater: that's good, that might affect 422 as well but I think it still has some merits on its own | 16:42 |
| tristan | 422 looks weird to me | 16:42 |
| tristan | growing tentacles | 16:42 |
| tristan | tlater, cs_shadow: I feel that we get more bang for our buck if we consider that an element can be created to output that | 16:43 |
| tristan | rather than to have `bst shell` grow tentacles | 16:43 |
| tristan | 425 is about `bst checkout`, but it's a good point that tentacles growing on `bst shell` have a likelyhood of reproducing themselves in other places | 16:44 |
| tlater | So you mean have the developer create a little gedit-dev.bst that they use in development? | 16:44 |
| * tlater doesn't like that | 16:44 | |
| tristan | tlater, right, a "something that stages a foo on top of a bar" | 16:45 |
| tristan | not really thinking about the "what it's for", rather, "BuildStream can do this" | 16:46 |
| tristan | already | 16:46 |
| cs_shadow | so you'll checkout foo and shell into bar? | 16:46 |
| *** Phil has quit IRC | 16:46 | |
| tlater | I'm aware, but I wrote that issue being annoyed at how inconvenient this is, and how frequently I have to modify a dependency just to test a small change. | 16:47 |
| tristan | cs_shadow, the way I read "`bst shell` should be able to stage the specified element on top of a base element" - speaks to me that when we stage that specified element, we also have to specify *where* | 16:47 |
| tristan | cs_shadow, which leads me to suspect, we want `bst shell` and potentially `bst checkout` to support things like "Checkout this artifact in /usr/local, checkout this artifact as the base at /, and this also at that location..." | 16:48 |
| tristan | cs_shadow, sounds like a big can of worms doesnt it ? | 16:48 |
| tristan | cs_shadow, reading the full bug | 16:50 |
| tristan | cs_shadow, I dont think I understand the premise to be honest | 16:51 |
| cs_shadow | My point is slightly different - I'm advocating for specifying a runtime base platform at the project level so that I don't have to add it everywhere just for running `bst shell`. So, it's not really changing the existing functionality that much other than introducing a new kind of runtime depdency that's only used by `bst shell` | 16:51 |
| tristan | "I find that I avoid using type: runtime on very low-level elements most of the time, even if they are technically runtime dependencies" | 16:51 |
| tristan | I mean usually you would use stacks to make that more convenient | 16:51 |
| tristan | such that not everything needs to depend explicitly on everything it really depends on | 16:52 |
| tristan | I still dont get it | 16:52 |
| tristan | cs_shadow, you still need that platform when you run it in `bst shell` right ? | 16:52 |
| tristan | I mean, why would you have to add it, why would it not be always there ? | 16:53 |
| cs_shadow | tristan: i need it _only_ for `bst shell`. We generally don't want to include the base platform in the "deployable" that we produce from `bst checkout` | 16:53 |
| cs_shadow | it's useful for debugging purposes though | 16:53 |
| tristan | it wont be a valid bst shell, then, I mean; it's supposed to only run stuff on the stuff it runtime depends | 16:53 |
| tristan | i.e. the target system, not whatever happens to be lying around on a given `site` | 16:54 |
| tristan | cs_shadow, note also that the cache key technically of the element you want to feed a new dependency to, would be necessarily changed by that | 16:54 |
| tristan | so I guess you'd anyway need a way of building that thing which you only use for... something | 16:55 |
| *** toscalix has quit IRC | 16:55 | |
| tlater | tristan: That works as long as you stick to only building the software. As soon as you want to deploy anything but the entire dependency tree you're a little stuck. | 16:56 |
| tristan | tlater, sounds like *that* is more the direction in which problems need solving | 16:56 |
| * tlater agrees, this is a better angle to look from, and probably the issue I should have written | 16:57 | |
| tristan | tlater, compose might allow running the `--except` algo logic for instance | 16:57 |
| tlater | compose? | 16:57 |
| cs_shadow | It would be ideal if we don't end up with two elements for everything | 16:58 |
| tristan | it's basically the thing which squashes / composes an output based on multiple outputs | 16:58 |
| tlater | Oh, you mean the plugin? | 16:58 |
| tristan | tlater, right, I mean... you build your "all your thingies", and then when it comes time to deploy, you use compose on them to produce the data which you want to feed to some sort of packaging plugin | 16:59 |
| tristan | cs_shadow, I think it's much more sound to have the compose logic in one plugin and have that serve a specific purpose, than re-growing compose features on many elements | 16:59 |
| tristan | i.e. let's keep features separated into elements to implement them, that also keeps the pipelines flexible | 17:00 |
| tlater | Hm. That's close, but I think it doesn't work very well if I have many different sets of "all your thingies". | 17:01 |
| tlater | We get dangerously close to creating two elements for each top level element. | 17:01 |
| tristan | tlater, that sounds perfectly normal, I would say maybe 3 elements is more likely | 17:01 |
| tlater | I feel this is a bit ugly... | 17:02 |
| tristan | i.e. you'd have a big shared tree, and then for the things that you *do* distribute (I'm imagining mostly highlevel apps here), have their own: `... | compose | package` phases | 17:02 |
| *** jonathanmaw has quit IRC | 17:02 | |
| tristan | tlater, put the composes and the packaging elements into a directory for that, and make that whole process dependent on the underlying build | 17:03 |
| tlater | Yeah, I can be convinced of that. In this case a packaging plugin could then just be an extension of the compose plugin, and exclude anything unnecessary. | 17:05 |
| tlater | That way we don't duplicate the target again | 17:05 |
| tristan | Even, it might save processing to put the composed output -> package elements into a single batch element (i.e. have one element produce "all the packages", and depend on all of the input compositions) | 17:05 |
| tlater | tristan: Do the compose/stack elements currently allow excluding? | 17:06 |
| tristan | tlater, I was asking that earlier :) | 17:07 |
| tristan | tlater, I think --except could work well on compose | 17:07 |
| tristan | stack has no business knowing how to do any of that | 17:08 |
| tristan | it's just a stack | 17:08 |
| tlater | Compose does have "exclude" on split-rules, but that's a bit different | 17:08 |
| tristan | it's a bit different yeah, it excludes domains | 17:08 |
| tristan | you want a `bst track --exclude ...` kind of semantic, that'd be really sweet | 17:08 |
| tlater | Preferably *not* specified on the command line | 17:09 |
| tristan | something flexible to remove or dictate the list of dependencies to be included in the composition | 17:09 |
| tristan | while taking into account that the compose element author doesnt always know the whole list | 17:09 |
| tristan | (i.e. the --except logic is a nice fit for this I think) | 17:09 |
| tristan | tlater, of course not on the command line, I'm just making a reference to the well known --except logic :) | 17:10 |
| tlater | Hmm... We could do something crazy like allow excluding whole directory trees | 17:10 |
| tlater | That way you can put all the "platform thingies" in a platform directory | 17:10 |
| tlater | And exclude them in one fell swoop | 17:10 |
| tristan | we can already exclude whole directory trees | 17:10 |
| tlater | Without having to worry about what they actually are | 17:10 |
| tristan | I think | 17:10 |
| tristan | well, it might take a second step | 17:10 |
| * tlater doesn't recall implementing that, but someone may have done so | 17:10 | |
| tristan | it can be done, you need 2 composes though | 17:11 |
| tristan | because the first one will make a single artifact, and then dictate it's own split rules | 17:11 |
| tristan | which will highlight/paint a directory | 17:11 |
| tristan | using a split domain | 17:11 |
| tristan | the second compose element just excludes the domain | 17:11 |
| tlater | That seems a bit very involved | 17:11 |
| tlater | In either case, I suppose both #422 and #425 would rather have this compose-exclude thing instead then. | 17:12 |
| tlater | Since they are both just symptoms of the same problem. | 17:12 |
| tristan | Well, having the split rules written the way you intend them to be all the way up the stack is the better thing to do, I wouldnt recommend deleting whole directories from one central location | 17:13 |
| tristan | excepting elements from the composition seems powerful and useful (it lets you remove the "components" you dont want, which is better than "the directories and files" you dont want) | 17:14 |
| *** tristan has quit IRC | 17:42 | |
| *** tristan has joined #buildstream | 17:48 | |
| gitlab-br-bot | buildstream: merge request (tristan/autotools-element->master: doc: Add section 3 to the getting started tutorial) #507 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/507 | 19:20 |
| gitlab-br-bot | buildstream: issue #307 ("Follow-up from "Add getting started section"") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/307 | 19:28 |
| gitlab-br-bot | buildstream: issue #308 ("Follow-up from "Add getting started section"") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/308 | 19:28 |
| *** Sebastian has joined #buildstream | 19:28 | |
| gitlab-br-bot | buildstream: merge request (phil/migrate-alpine-demo->master: WIP: Phil/migrate alpine demo) #499 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/499 | 19:39 |
| *** Sebastian has quit IRC | 19:43 | |
| *** tristan has quit IRC | 19:49 | |
| gitlab-br-bot | buildstream: merge request (tristan/autotools-element->master: doc: Add section 3 to the getting started tutorial) #507 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/507 | 19:55 |
| *** tristan has joined #buildstream | 19:57 | |
| *** xjuan has quit IRC | 20:08 | |
| *** tristan has quit IRC | 20:18 | |
| *** Prince781 has quit IRC | 21:06 | |
| *** jcampbell is now known as jcampbell_polari | 21:48 | |
| *** jcampbell_polari is now known as j1mc_polari | 21:48 | |
| *** Prince781 has joined #buildstream | 22:50 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!