| *** aminbegood has quit IRC | 01:23 | |
| *** aminbegood has joined #buildstream | 01:25 | |
| *** aminbegood has quit IRC | 01:44 | |
| *** aminbegood has joined #buildstream | 01:54 | |
| *** aminbegood has quit IRC | 02:07 | |
| *** aminbegood has joined #buildstream | 02:43 | |
| *** aminbegood has quit IRC | 02:55 | |
| *** tristan has quit IRC | 03:07 | |
| *** aminbegood has joined #buildstream | 03:11 | |
| *** aminbegood has quit IRC | 03:25 | |
| *** aminbegood has joined #buildstream | 04:24 | |
| *** aminbegood has quit IRC | 04:35 | |
| *** aminbegood has joined #buildstream | 04:52 | |
| *** aminbegood has quit IRC | 05:09 | |
| *** aminbegood has joined #buildstream | 05:12 | |
| *** aminbegood has quit IRC | 05:31 | |
| *** aminbegood has joined #buildstream | 05:33 | |
| *** aminbegood has quit IRC | 05:48 | |
| *** tristan has joined #buildstream | 06:10 | |
| *** aminbegood has joined #buildstream | 07:17 | |
| *** aminbegood has quit IRC | 07:33 | |
| *** ChanServ sets mode: +o tristan | 07:58 | |
| tristan | Looking more at junction configuration, I find the documentation and naming around `cache-junction-elements` and `ignore-juction-remotes` confusing | 07:58 |
|---|---|---|
| tristan | Moreover, I think there is some confusion or lack of clarity around how those options interact with the `target` option | 08:01 |
| tristan | We say only "Note that this option cannot be used in conjunction with sources.", and in preflight errors, we only bail out with an error if sources, options or path is specified, but not when the artifact pull/push options are specified (but will be ignored in the current implementation) | 08:03 |
| tristan | Are we allowed to specify `None` as a default value for `MappingNode.get_bool()` ? | 08:29 |
| tristan | Ah I think this doesnt matter, we can still use `in` to check if a parameter was specified explicitly or not. | 08:31 |
| tristan | juergbi, I've noticed that some people are oh holiday today (including gitlab-br-bot apparently)... | 09:21 |
| tristan | if you are around and have some spare cycles, you could look at https://gitlab.com/BuildStream/buildstream/-/merge_requests/1937 | 09:21 |
| * tristan doing some house cleaning while two significant junction branches are still hanging in the balance | 09:22 | |
| * juergbi is around | 09:22 | |
| juergbi | will take a look | 09:23 |
| juergbi | should probably give others a chance to comment as well before a merge, though | 09:23 |
| tristan | Sure, should I raise this on the list you think ? | 09:24 |
| tristan | If so, I will combine with a proposal to also rename `cache-junction-elements` and `ignore-juction-remotes` | 09:24 |
| tristan | that could make sense | 09:24 |
| tristan | Looking at those, it looks like both options are "whether to push" and "whether to pull" from remotes defined by that junction, when dealing with elements from that junction | 09:25 |
| tristan | It looks like an opportunity to much simplify the expression, maybe have a dictionary with a "pull" and "push" boolean, and better structured docs around that - but I will look deeper into this to verify that I've understood these new options correctly first | 09:26 |
| tristan | I'd like to understand what the impacts of these options are in the context of deeply nested pipelines and hopefully clarify this story | 09:27 |
| * tristan starts by pinging cs-shadow on the MR as this was his feature after all | 09:29 | |
| juergbi | tristan: it's not about push vs. pull. it's about whether this project's remotes should cache elements from the subproject and whether remotes configured in subproject's project.conf should be used or ignored | 09:32 |
| juergbi | I'd expect it to be push/pull in both cases (although remote defined in project.conf is most likely pull-only as push typically requires authentication) | 09:33 |
| juergbi | clarifying the name/purpose sounds like a good idea to me, though | 09:34 |
| tristan | Ahhh | 09:39 |
| tristan | juergbi, I feel like, we should be able to observe these configurations for a linked junction (or a "targetted" junction) | 09:42 |
| tristan | Seems like | 09:42 |
| tristan | but I think we're not, looking at loader code, we just parse the junction and discard it right away if it's a link to another one | 09:42 |
| juergbi | hm, shouldn't that be handled by the target junction? | 09:46 |
| juergbi | the question is how to handle it for nested junctions, I suppose | 09:46 |
| juergbi | naively I would expect these flags to apply recursively | 09:47 |
| juergbi | don't know whether that might not be enough configurability | 09:47 |
| valentind | tristan, Because junctions elements have a partial configuration, I need to make variables defined using missing variables allowed. We can either make this case only for junction. Or we could transform the resolution of variables on demand for all elements (which remove the preprocess and replace it by a cache). | 09:49 |
| tristan | juergbi, I'm thinking honestly; maybe this should be removed from junctions and setup in the project globally, perhaps in a new "session" group defining behaviors which only apply to the toplevel session | 09:52 |
| tristan | juergbi, because I think the junction level configuration doesnt achieve the (probable) intent and pain point driving this feature | 09:52 |
| juergbi | tristan: hm, so you wouldn't be able to specify it per subproject anymore? | 09:52 |
| tristan | I'll try to find a trace of this on the ML | 09:53 |
| tristan | juergbi, Basically I suspect that the driving principal here is "I'm building something with my project, and I want to be sure that I am in control of all my artifacts" | 09:53 |
| tristan | I want to ensure that I have my own copy in my own artifact server, etc | 09:53 |
| tristan | With junction level configuration, we don't achieve this | 09:54 |
| tristan | I wonder what were the motivations/arguments for having fine grained control | 09:54 |
| juergbi | some subprojects might be trusted | 09:54 |
| juergbi | I don't remember the details OTOH | 09:54 |
| * tristan finds https://mail.gnome.org/archives/buildstream-list/2019-June/msg00049.html | 09:57 | |
| tristan | via https://gitlab.com/BuildStream/buildstream/-/merge_requests/1403 | 09:58 |
| tristan | looks like there was a lot of confusion around this and this was a revert of something else | 09:58 |
| tristan | valentind, I think your comment is about solving include behavior across junction boundaries | 10:00 |
| valentind | No. | 10:01 |
| valentind | A project includes some variables through a junction in project.conf. | 10:01 |
| tristan | Ok | 10:02 |
| valentind | project.conf defines variables depending on those variables. | 10:02 |
| tristan | Yup | 10:02 |
| valentind | Then just loading a junction element, we do not have all the definitions. The variables on top level cannot be fully resolved. | 10:02 |
| tristan | Yes, there is a possibility of circular dependencies | 10:03 |
| tristan | of variables | 10:03 |
| valentind | It is not even circular. | 10:03 |
| valentind | Well kind of. | 10:03 |
| valentind | You could need the junction to load the variables. | 10:03 |
| tristan | If I need variables from the junction to define the variables I use to configure that same junction, it's a circular dependency | 10:04 |
| tristan | It would be good to have an error for that I think ? | 10:04 |
| valentind | But we already said that junctions never have full configuration even if there is no circular dependencies. | 10:04 |
| tristan | Usually the way we use junctions, these cases don't occur | 10:05 |
| valentind | Yes, but we could force evaluating all variables later for non junction element.s | 10:05 |
| tristan | valentind, I'm having trouble parsing "junctions never have full configuration" | 10:05 |
| valentind | junction use the project first pass configuration. | 10:05 |
| valentind | junctions | 10:06 |
| valentind | So it is the project.conf with only local includes. | 10:06 |
| tristan | Right okay | 10:06 |
| valentind | So it is partial. | 10:06 |
| tristan | But the project across that junction is fully loaded | 10:06 |
| tristan | when it comes to including from that junction right ? | 10:07 |
| valentind | Even in a case where it could have loaded another through junction fine. But that would make behavior quite complex. | 10:07 |
| valentind | Yes. | 10:07 |
| valentind | Later. | 10:07 |
| valentind | Junction elements have partial configuration. But all projects have full configuration loaded when we load other elements. | 10:07 |
| tristan | I see the circular dependency issue, and now I think I understand your original comment better | 10:08 |
| valentind | So if you say "variables: foo: "foo_%{bar}" | 10:08 |
| valentind | And then you have "(@): junction.bst:variables.yml" | 10:09 |
| valentind | Where variables.yml defines bar. | 10:09 |
| tristan | We still have error cases to report regardless of which way it's implemented, those need to report something useful | 10:09 |
| valentind | tristan, Yes but we could delay checking for all variables for other elements after loading has been done. | 10:09 |
| tristan | Every element resolves their variables in their own time | 10:10 |
| tristan | Variables are not a project wide thing | 10:10 |
| valentind | OK, I should check in master. But in 1.5, the variables are resolved when element is loaded. | 10:10 |
| valentind | So that means quite early. | 10:10 |
| tristan | For each element yes, well | 10:11 |
| valentind | Seems the same in master. | 10:11 |
| tristan | valentind, They are resolved when the Element is instantiated | 10:11 |
| tristan | now when the MetaElement is loaded as I understand | 10:11 |
| tristan | s/now/not | 10:11 |
| valentind | Sure. | 10:12 |
| tristan | That is also quite late, depending on how you look at it :D | 10:12 |
| tristan | heh | 10:12 |
| tristan | valentind, to be honest, I do like the latter of your two suggested approaches better than the former (at first sight) | 10:13 |
| tristan | Keeping a cache and resolving on demand seems like it will perform well and be more maintainable than special casing junction load behavior | 10:14 |
| valentind | I have to try, but yes, I think it might possible to make code that is very simple and still fast. | 10:14 |
| valentind | I will give a try. | 10:15 |
| tristan | valentind, I think it would be good to consult benschubert on this if possible, as he's also been playing very recently around variables (completely removing the Element.get_variable() APIs) | 10:15 |
| valentind | Noted. | 10:15 |
| tristan | But essentially I think that it's a good approach, and I think that with the nice nodes and provenance we have in master, we should be able to produce good errors | 10:16 |
| tristan | The root of all of this is #401 | 10:32 |
| tristan | With which I pretty much agree with jjardon's points | 10:32 |
| tristan | I can see from https://mail.gnome.org/archives/buildstream-list/2019-June/msg00049.html, james tried to bake in the best of all worlds | 10:33 |
| tristan | But I think that in the end, it was overlooked that the final solution fails to give the toplevel project full control | 10:34 |
| tristan | I'm still having a hard time tracking down why so much configurability was required, though | 10:34 |
| tristan | juergbi, maybe the junction configurations work if for instance, we consider that they apply to subprojects recursively ? | 10:36 |
| tristan | I guess "trusted caches" is important | 10:36 |
| juergbi | yes, recursive is what I'd expect intuitively | 10:36 |
| tristan | Ah, it's not what I'd expect intuitively :D | 10:37 |
| tristan | Looking at the docs and config, I expect that each junction expresses what it wants from it's subproject | 10:37 |
| tristan | And then when you throw it all together... "Something happens" | 10:37 |
| tristan | Also, it looks like while the "default is False" for these options, I feel like setting it explicitly to False is different from leaving it default (i.e. "no matter what, behave like False") | 10:39 |
| tristan | Lets see, recursive seems to fix things except for linked/targetted junctions | 10:39 |
| juergbi | tristan: well, better than recursive might be transitive, although they are fairly close here | 10:43 |
| juergbi | although it can depend on the perspective | 10:44 |
| juergbi | if you disconnect the project's remotes from the subproject's remotes, all subsubproject remotes should also be disconnected, imo | 10:44 |
| juergbi | that's for the ignore-... option | 10:44 |
| tristan | juergbi, I feel like setting either to True should do so recursively | 10:45 |
| juergbi | it might be the simplest approach | 10:45 |
| tristan | I.e. I want to be sure that I always have a separate copy of the artifact in my server | 10:46 |
| tristan | Of course, if a parent project said ignore-junction-remotes and I (the subproject) says cache-junction-elements for my subprojects, the parent project wins | 10:47 |
| tristan | I mean I say "of course", but it's by no means outlined or described anywhere | 10:47 |
| tristan | specified being the word I'm looking for :) | 10:48 |
| tristan | juergbi, Basically... any setting of True for either of those settings is recursive and overrides the whole subtree... but then, what about False ? | 10:49 |
| tristan | Also, when I say true at the toplevel, I mean cache everything built recursively in *my* project, it's not the same as setting True to each junction recursively | 10:50 |
| tristan | that would mean "try to cache everything in every project" | 10:50 |
| juergbi | yes | 10:50 |
| juergbi | for False I don't think it should be recursive | 10:50 |
| juergbi | True is currently the override | 10:51 |
| juergbi | and that makes sense to be recursive to let the top-level project be in control | 10:51 |
| tristan | Right, so in cases that I build a project which does not override, but builds a project which does say that... that subproject's True override is still in effect ? | 10:51 |
| juergbi | for ignore, I would definitely think so | 10:52 |
| juergbi | for cache, it would be cached as part of that middle project, right? | 10:52 |
| tristan | And for cache, it ends up meaning you will just get failed push attempts ? | 10:52 |
| juergbi | failed push? | 10:52 |
| tristan | Assuming the middle project said "cache-junction-elements: True" when declaring the sub-sub-project | 10:53 |
| tristan | Then when the toplevel (which did not set cache-... to True), builds... it probably doesnt have credentials for that middle project cache server | 10:54 |
| tristan | But it will try to push everything for that subproject and subsubproject to the middle project's cache server | 10:54 |
| tristan | Or maybe that is not a failed push | 10:54 |
| tristan | it will just do it if it was able to push at initialization time | 10:54 |
| tristan | That doesn't seem to sound perfectly sensible :-S | 10:55 |
| tristan | For ignore, I would definitely think so also | 10:55 |
| tristan | For cache, it's unclear | 10:55 |
| juergbi | I wouldn't expect project.conf to actually specify push remotes due to the authorization issue | 10:56 |
| juergbi | in which case nothing would happen | 10:56 |
| tristan | Good point | 10:56 |
| juergbi | imo, cache-junction elements in a junction in the middle project should definitely not suddenly result in elements being pushed to the top-level remote | 10:57 |
| tristan | no | 10:59 |
| tristan | I don't think so either | 10:59 |
| tristan | However this makes me curious | 11:00 |
| tristan | Where to the artifacts go if not to the toplevel project ? | 11:00 |
| tristan | I mean, in the normal scenario, the toplevel project uses other subprojects but controls their own cache, you'd think we'd want to push to the toplevel always by default, especially if mid-level elements needed rebuilding and couldn't be obtained from a mid-project-level cache ? | 11:01 |
| *** aminbegood has joined #buildstream | 11:01 | |
| tristan | juergbi, I guess I feel like the decision should be "cache-junction-elements: never | when-built | always" | 11:02 |
| tristan | where "when-built" is the natural default | 11:03 |
| juergbi | that requires some extra state, which I'd rather avoid | 11:03 |
| tristan | The current default is to always rebuild elements from a subproject if that subproject's cache didn't have the exact artifact you want | 11:04 |
| juergbi | elements from all (sub)projects will always be cached locally, of course | 11:04 |
| juergbi | it's only about artifact servers | 11:04 |
| tristan | Which, is a bit bad especially given that (A) The subproject might not define a public artifact cache for downloads, and (B) You can override subproject junction configurations to bring them inline | 11:04 |
| tristan | Yeah, but artifact servers are important heh | 11:05 |
| juergbi | and we shouldn't forget, we always said the preferred setup is to have artifact server configured in the user config | 11:05 |
| juergbi | which also makes sense regarding credentials | 11:05 |
| tristan | Yes | 11:05 |
| juergbi | and with user config it should still work well for all subprojects | 11:05 |
| juergbi | (depending on whether the servers in user config are project-specific or not) | 11:05 |
| tristan | Ok, are we allowed to wildcard all subprojects in user config and do what we want ? | 11:05 |
| juergbi | no, I don't think we have anything like that right now | 11:06 |
| juergbi | just global user and per-project user config | 11:06 |
| juergbi | in practice I'd expect many users to just use a global one | 11:06 |
| tristan | That's problematic for me, as I do want to push the concept that "You don't need to know about subprojects" | 11:06 |
| tristan | untill you really do need to of course | 11:06 |
| tristan | juergbi, Oh, global is good enough | 11:07 |
| *** mohan43u has quit IRC | 11:07 | |
| tristan | I sort of meant that by wildcarding, not glob patterns or anything weirdly fancy like that | 11:07 |
| juergbi | yes, the only issue I see is if people work with two (or more) completely different project hierarchies where they want to use different servers | 11:08 |
| tristan | https://docs.buildstream.build/master/using_config.html#artifact-server | 11:08 |
| tristan | indeed, that's practical and allows the working group to say "Ok lets use our cache" | 11:09 |
| juergbi | btw: I'd expect CI to be the main (or even only) artifact pusher in many projects | 11:09 |
| tristan | juergbi, I think that we can (with backwards compatibility) add a 'recursive: True' option to the per-project user configuration | 11:10 |
| tristan | However | 11:10 |
| tristan | I do sort of wonder, if I've specified a cache for a given project name in my user config, don't I mean "All subprojects of these when I build that project as a toplevel" ? | 11:11 |
| tristan | juergbi, I do agree with that yes | 11:11 |
| tristan | I think CI being the pusher is a bit orthogonal though, the setup/config needs to be done somewhere; I'm just trying to make sure we have the right configuration surface to properly capture subprojects of dependencies which we don't want to constantly know about as a project | 11:12 |
| juergbi | would it make sense for those server lists to be combined (and I think we already have duplicate detection) | 11:13 |
| tristan | I.e. the "I want to use all my own infra for caching, and I want to be able upgrade my junctions regularly and still capture everything in my infra" | 11:13 |
| juergbi | e.g, if I have a push server that I use for fd-sdk, I probably want to use that when building fd-sdk on its own but also when building gnome-build-meta or similar | 11:14 |
| juergbi | (for the fd-sdk part) | 11:14 |
| juergbi | combinatorial explosion *sigh* | 11:15 |
| juergbi | tristan: CI: right, but CI could handle this with a global user config and would probably want to ignore all project.conf remote definitions | 11:15 |
| tristan | Honestly, I really mostly agree with jjardon's comment on #401 in this regard - when you are owner of a project: you decide if you want to trust third party upstream artifact servers for pulling from, and you probably don't have credentials to push to those | 11:16 |
| tristan | So what you do is you first try to pull from your project, and fallback to pulling from the upstream junctioned project, in the worst case: you build | 11:16 |
| tristan | But you always end up pushing to your *own* artifact cache server | 11:17 |
| juergbi | who is the owner of a project? | 11:17 |
| tristan | A group/organization | 11:17 |
| juergbi | user of a project might not match maintainer of the corresponding project.conf | 11:17 |
| juergbi | so maybe the project maintainer trusts some server but the user doesn't | 11:17 |
| tristan | The ones who collaborate to create that project, and who decide to advertize a public cache server to pull from in project.conf if they want to | 11:17 |
| juergbi | a user should be able to completely avoid project.conf remotes | 11:18 |
| juergbi | (without editing the project) | 11:18 |
| tristan | I think that makes sense too yes | 11:18 |
| juergbi | I think there was a proposal somewhere about a CLI / user config option for this | 11:18 |
| juergbi | i.e., to specify whether to use project.conf remotes at all or not | 11:18 |
| tristan | I feel like there is a minimal amount of flexibility we need to provide, and we've got a lot, really a lot of confusing configuration API surface to reflect it | 11:19 |
| juergbi | yes, feels too complex to me as well | 11:19 |
| tristan | user config, project.conf, and now junction | 11:20 |
| tristan | there must be a way to cut this all in half and still support the use cases that are important :-S | 11:20 |
| juergbi | would things be a bit simpler if we completely disallowed push remotes in project.conf? | 11:21 |
| juergbi | because I don't think that makes really sense anyway | 11:21 |
| *** aminbegood has quit IRC | 11:21 | |
| juergbi | (given the required authentication) | 11:22 |
| juergbi | theoretically some company-internal (not publicly accessible) server could allow unauthorized push but even that seems odd | 11:22 |
| tristan | It does seem odd, but I'm not entirely sure | 11:24 |
| tristan | I mean I'm not entirely sure that it saves us from the complexity | 11:24 |
| *** aminbegood has joined #buildstream | 11:26 | |
| tristan | juergbi, it would, but I think it's also questionable that projects and junctions get to decide these things | 11:27 |
| tristan | juergbi, what might save us the complexity is to say "Projects can publish their download urls if they like" and user config decides the rest | 11:27 |
| juergbi | i.e., let user config decide for which projects the project.conf remotes are used? | 11:30 |
| *** tristan has quit IRC | 11:31 | |
| juergbi | and maybe also have a global user config option to decide the default? | 11:31 |
| *** tristan has joined #buildstream | 11:35 | |
| *** ChanServ sets mode: +o tristan | 11:35 | |
| tristan | juergbi, errrrm, gotta run soon what's my last line before getting cut off ? | 11:36 |
| tristan | eh, even the IRC logs are having trouble today | 11:37 |
| tristan | all the bots on vacation | 11:37 |
| tristan | https://irclogs.baserock.org/%23baserock.2020-05-25.log.html | 11:37 |
| tristan | I'll just repaste for now | 11:37 |
| tristan | <tristan> juergbi, it would, but I think it's also questionable that projects and junctions get to decide these things | 11:37 |
| tristan | <tristan> juergbi, what might save us the complexity is to say "Projects can publish their download urls if they like" and user config decides the rest | 11:37 |
| tristan | <tristan> juergbi, I have to run soon, have an appointment, I'll chew on this more | 11:37 |
| tristan | <tristan> Maybe for the junction decisions, it would make more sense to (A) Have the per-project user config things be recursive, and (B) Allow user config to also make these decisions | 11:37 |
| tristan | <tristan> This would at least centralize all this configuration to one place, plus hints from project.conf (pull urls) | 11:37 |
| tristan | <tristan> And it would eliminate the whole complexity of analyzing and negotiating project preferences | 11:37 |
| tristan | <tristan> Having one place where a decision is made, and a good default behavior | 11:37 |
| tristan | <tristan> To bring something randomly into context... the reason we originally added push url lists to project configuration was the output of a workgroup session at GUADEC in Manchester | 11:37 |
| tristan | <tristan> It was in consideration of "long standing branches of buildstream projects" | 11:37 |
| tristan | <tristan> We had the idea that, when creating the branch, we might have an alternative push url and use 2 pull urls | 11:37 |
| tristan | <tristan> so that development artifacts from the work branch would go to a separate cache | 11:37 |
| tristan | <tristan> and avoid polluting the mainline cache with those artifacts | 11:37 |
| juergbi | <juergbi> i.e., let user config decide for which projects the project.conf remotes are used? | 11:39 |
| juergbi | <juergbi> and maybe also have a global user config option to decide the default? | 11:39 |
| *** aminbegood has quit IRC | 11:44 | |
| tristan | juergbi, myeah gotta chew on this a bit | 11:45 |
| tristan | have to think about allowing users to have good control without requiring constant knowledge of all subprojects in play | 11:46 |
| * tristan is off to dinner | 11:46 | |
| *** tristan has quit IRC | 11:49 | |
| *** aminbegood has joined #buildstream | 12:10 | |
| *** aminbegood has quit IRC | 12:28 | |
| douglaswinship | I have a merge request for pi-3b-plus-bsp https://gitlab.com/celduin/bsps/pi-3b-plus-bsp/-/merge_requests/4 | 15:12 |
| douglaswinship | ... to resolve issue https://gitlab.com/celduin/bsps/pi-3b-plus-bsp/-/issues/1 | 15:13 |
| douglaswinship | But I'm not sure how we would test that? | 15:13 |
| douglaswinship | I'm guessing we use the example app, for testing that sort of thing? | 15:15 |
| douglaswinship | I'm not familiar with the CI on that project though. The lines at the end of .gilab-ci.yml seem to indicate that it pushes the built artifact(s) to a cache server, at celduin-cache.codethink.co.uk | 15:17 |
| douglaswinship | (https://gitlab.com/celduin/bsps/example-app/-/blob/master/.gitlab-ci.yml#L97) | 15:17 |
| douglaswinship | Is that something I ought to have access to, and is that where I'd look to see if my test gives the results I was hoping for? | 15:18 |
| *** jude has joined #buildstream | 15:18 | |
| douglaswinship | Also... I'm in the wrong chat window | 15:19 |
| douglaswinship | Sorry! | 15:19 |
| douglaswinship | Ignore everything I just said. | 15:19 |
| *** jude has quit IRC | 15:23 | |
| *** benschubert has joined #buildstream | 17:05 | |
| *** tristan has joined #buildstream | 17:07 | |
| *** cphang has joined #buildstream | 17:50 | |
| cphang | Hi! Is there any appetite for having development versions of BuildStream packaged as flatpaks? | 18:17 |
| juergbi | cphang: does BuildStream even work as a flatpak right now (requiring FUSE and [nested] bubblewrap)? | 19:09 |
| juergbi | (for local execution) | 19:09 |
| cphang | I think valentind has done some work with 1.4, would 1.9x have additional requirements/ | 19:10 |
| juergbi | shouldn't require anything fundamentally different. more recent version of libfuse and buildbox binaries but those shouldn't be an issue | 20:21 |
| *** tristan has quit IRC | 20:38 | |
| *** tristan has joined #buildstream | 20:38 | |
| jjardon | cphang: yes! https://gitlab.com/BuildStream/buildstream/-/issues/548 | 21:51 |
| *** cphang has quit IRC | 22:22 | |
| *** benschubert has quit IRC | 22:54 | |
| *** lantw44 has quit IRC | 23:23 | |
| *** Trevinho has quit IRC | 23:23 | |
| *** lantw44 has joined #buildstream | 23:23 | |
| *** Trevinho has joined #buildstream | 23:23 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!