| *** tristan has quit IRC | 04:39 | |
| *** benschubert has joined #buildstream | 07:19 | |
| *** santi has joined #buildstream | 08:48 | |
| *** toscalix has joined #buildstream | 08:50 | |
| *** tristan has joined #buildstream | 09:04 | |
| *** ChanServ sets mode: +o tristan | 09:04 | |
| tristan | benschubert, hmmm, have a meeting now, I think you've missed the meaning of that mail in a few ways but appreciate the response | 09:05 |
|---|---|---|
| tristan | I'll read the full mail after my meeting and try to discuss... | 09:06 |
| benschubert | tristan: sure, entirely possible :) | 09:06 |
| benschubert | and sorry about the delay | 09:06 |
| *** mohan43u has quit IRC | 09:23 | |
| benschubert | tristan: also, https://gitlab.com/BuildStream/buildstream/-/merge_requests/1954 would be a breaking change right? | 10:03 |
| tristan | benschubert, Ok so I just got through your mail, the first misconception is that "it cannot be done today" | 10:24 |
| tristan | Today, we can have multiple instances of the same project | 10:25 |
| benschubert | ah true | 10:25 |
| tristan | https://docs.buildstream.build/master/elements/junction.html#nested-junctions | 10:25 |
| tristan | We do this horribly confusing thing where the name of your junction element is meaningful | 10:26 |
| tristan | And note it says "It is recommended that the name of a junction is set to the same as the name of the linked project." | 10:26 |
| tristan | This leads to the main problem which "overrides" is intended to solve | 10:26 |
| benschubert | I am not even sure I understand the docs there :/ | 10:27 |
| tristan | I.e., if I follow that rule, and everyone follows that rule, say one day I add a dependency on another project which has a common dependency on a subproject | 10:27 |
| benschubert | So definitely +1 on confusing | 10:27 |
| tristan | Ok what the docs are saying there is if I have a junciton "freedesktop-sdk.bst" in my project, and a subproject of mine also has a "freedesktop-sdk.bst" junction, then my toplevel "freedesktop-sdk.bst" will *win*. | 10:27 |
| benschubert | based on the name of the element | 10:28 |
| tristan | And it will be used as the common configuration of that junction for all projects which junction freedesktop-sdk | 10:28 |
| benschubert | ah gotcha | 10:28 |
| tristan | Yes | 10:28 |
| benschubert | but then point 2 is not possible (different options) | 10:28 |
| benschubert | ok I'm following | 10:28 |
| tristan | So the *main* problem with that, asides from it being confusing, is that I can *unknowningly* override the subproject of a new project I start junctioning | 10:28 |
| tristan | Effectively getting different artifacts from that project than the artifacts I expect, and the artifacts that project advertizes to provide | 10:29 |
| tristan | Without any warning or anything | 10:29 |
| tristan | I know it's confusing... but, following me so far ? | 10:29 |
| tristan | ;-) | 10:29 |
| benschubert | yep, I had understood that from the message (might not have phrased it best though :D) ) | 10:29 |
| tristan | Ok | 10:29 |
| tristan | So basically the first part of the patch which is already written on !1901, is to add an overrides to replace that junction name coalescing stuff | 10:30 |
| tristan | And to also error out when multiple instances of the same project name occur | 10:30 |
| tristan | Making it impossible to override a junction in a subproject without being explicit about it | 10:30 |
| tristan | Now, you bring up a point in your email which has been simmering in the back of my mind too | 10:31 |
| tristan | Which is overriding of deeply nested junctions | 10:31 |
| tristan | it's unclear to me if we really need that | 10:31 |
| benschubert | I at least could see one case: for bootstrap projects that build themselves | 10:32 |
| tristan | I've also been thinking of that with a nasty wrenching feeling deep in my gut, though | 10:32 |
| tristan | That is the next topic, I thought we were not there yet | 10:32 |
| benschubert | ah gotcha | 10:32 |
| tristan | The other topic is how to explicitly *allow* the duplication of projects, so that there are multiple instances of the same project | 10:32 |
| tristan | Which the first part of the branch (already implemented) prevents | 10:33 |
| tristan | But before moving there, do we think we need the ability to override deeply nested junction configurations ? | 10:33 |
| benschubert | I don't have a use case in hand | 10:33 |
| tristan | I have a feeling that doing that should involve supporting full element pathing | 10:33 |
| benschubert | however, I don't think we should have a disparity between what is possible with "overrides" and "renaming" | 10:33 |
| tristan | So if and when we get there, we should be able to specify an element as "foo.bst:bar.bst:baz.bst:frob.bst" | 10:34 |
| benschubert | correct | 10:34 |
| tristan | rather than being limited to only one colon | 10:34 |
| benschubert | that's part of my email (unless I was unclear :D) | 10:34 |
| tristan | Right, so that part | 10:34 |
| tristan | I understand the discomfort with that | 10:35 |
| valentind | Do we use marge? | 10:35 |
| tristan | valentind, yep | 10:35 |
| tristan | benschubert, So... for overrides, you really need element names, that much is certain I think | 10:35 |
| tristan | you want to address a specific junction via a path | 10:36 |
| benschubert | tristan: my take was: we should either use only 'name' or only 'element' to address those, otherwise it will end up being ocnfusing | 10:36 |
| tristan | benschubert, for the renaming proposal, the logic is that in renames, you will definitely want to be able to rename deeply nested junctions | 10:36 |
| tristan | Yeah I understand that part and I quite agree | 10:37 |
| benschubert | and I think that both should have feature parity otherwise it will also be confusing | 10:37 |
| benschubert | unless there is a technical reason why we don't/can't | 10:37 |
| benschubert | *don't want | 10:38 |
| tristan | Currently we don't, since junction "coalescing" allows overriding of deeply nested junctions | 10:38 |
| tristan | So the renaming approach (one of the many approaches suggested so far to address the second problem)... the value would of course be a project name | 10:38 |
| tristan | The key could be junction names to have a clearer API | 10:39 |
| tristan | But would then require that we also support deep fullpath addressing of elements | 10:39 |
| tristan | If we do that, then we also solve the problem of "overrides" feature parity | 10:39 |
| benschubert | agreed, something like: | 10:40 |
| benschubert | overrides: key: name -> value: element | 10:40 |
| benschubert | project-names: key: name -> value: name | 10:40 |
| benschubert | right? and therefore both would support arbitrary nesting | 10:40 |
| tristan | both would support specifying many `:` in the key | 10:40 |
| benschubert | tristan: if we use name, we don't need any `:` | 10:41 |
| tristan | I don't know if it makes sense to also support it in the value of overrides | 10:41 |
| tristan | benschubert, but I don't believe that is specific enough | 10:41 |
| tristan | at least not in the case of overrides | 10:41 |
| benschubert | for values of overrides, I'd say no, there isn't much to gain from that | 10:41 |
| tristan | We need to specify exactly which *junction* an override overrides | 10:41 |
| tristan | not which project | 10:41 |
| benschubert | but a junction will end up having a unique name in a specific project right? | 10:41 |
| benschubert | since you would not be able to have two projects with the same name anymore | 10:42 |
| tristan | Yeah this is tricky, because thoughts have materialized in different orders | 10:42 |
| tristan | So, if we were to go back and rethink overrides in a scenario where you are allowed to rename things | 10:42 |
| tristan | Is there no possibility at all that there is ambiguity ? | 10:42 |
| benschubert | correct | 10:42 |
| benschubert | because we end up with unique names _all the time_ | 10:42 |
| benschubert | so if you have A -> B ->(c, c2), with C and C2 the same junction with different name, you can uniquely identify them by name | 10:43 |
| tristan | benschubert, this line of thinking is dangerously scope creepy | 10:43 |
| tristan | 2 additional things which I think deserve changing in this approach | 10:43 |
| tristan | * The UI should print "{project-name}:{element-name.bst}" instead of "{full}:{element}:{path}" | 10:44 |
| tristan | * We should logically allow elements to depend on elements in subprojects with "build-depends: ... - {project-name}:{element-name.bst}" | 10:45 |
| benschubert | which will lead to shorter paths and thus a nicer readable UI? :) But true that's a change | 10:45 |
| benschubert | right | 10:45 |
| benschubert | right this could result in bigger changes | 10:45 |
| tristan | * That past part would require that junctions be associated with project names in the toplevel project.conf, otherwise we don't know anymore how to load junctions as a side effect of a dependency | 10:45 |
| tristan | s/past/last | 10:45 |
| tristan | So... I don't know if we have the stomach for all of this | 10:46 |
| benschubert | On the other hand, it's a nicer UX | 10:46 |
| benschubert | I am not sure we want to have to change all of this | 10:46 |
| tristan | The addressing of elements by "paths" via junctions makes the implementation clean | 10:46 |
| tristan | because we have the junction needed to load the project via there | 10:46 |
| tristan | Now if we also had the project.conf maintaining a table of names/junctionelements, that also is annoying for users | 10:47 |
| tristan | Especially given that projects can be renamed | 10:47 |
| benschubert | I think there is also a fundamental problem there: names in projects don't matter but they do | 10:47 |
| tristan | Right | 10:47 |
| tristan | Right now we use them in user config to specify artifact caches | 10:48 |
| tristan | And they are also meaningful in artifact "names" | 10:48 |
| benschubert | which they really should not :) (at least not part of the cache key) | 10:48 |
| tristan | Right, a lot of cans of worms, all of which contribute to reluctance to get involved with this thread on the ML I need resolved :) | 10:49 |
| benschubert | tristan: a middle ground could be to support both types of 'keys' in the config | 10:49 |
| tristan | So, for instance, even if I've decided that I want "two freedesktop-sdk instances" in my pipeline, I think I don't want those to have different artifact "names" just because of that | 10:50 |
| tristan | Remember that the driving reason is the ability to explicitly have two | 10:50 |
| tristan | Not necessarily to rename them | 10:50 |
| benschubert | yep, definitely | 10:51 |
| benschubert | but on the other hand if you _rename_ them explicitely to avoid clashed, the UX should tell you from where it's coming | 10:51 |
| tristan | So maybe the disruption of the rename approach is too much | 10:51 |
| benschubert | otherwise, why am I building 5 times the same element? | 10:51 |
| tristan | benschubert, if you always display full paths in the UI then you don't have that problem | 10:52 |
| benschubert | right | 10:52 |
| tristan | My patch actually *needed* to do this otherwise I get crashes | 10:52 |
| tristan | So currently with !1901, we don't have a limitation of two levels | 10:52 |
| tristan | Without !1901, the problem of name clashes in the UI doesnt arise because of the coalescing | 10:53 |
| tristan | So the other approach that I'm kind of happy with too, is the "internal / duplicates" approach | 10:53 |
| benschubert | Let's rewind a bit | 10:53 |
| tristan | Ok | 10:53 |
| benschubert | > because we end up with unique names _all the time_ | 10:54 |
| benschubert | > 11:43 AM so if you have A -> B ->(c, c2), with C and C2 the same junction with different name, you can uniquely identify them by name | 10:54 |
| benschubert | I meant use this _only_ in the junction: overrides/project-names config | 10:54 |
| benschubert | not use this anywhere else | 10:54 |
| benschubert | for the `key` section | 10:54 |
| tristan | You mean, the rename would not rename project instances, it would rename something internal to the loader | 10:55 |
| tristan | and only there | 10:55 |
| benschubert | correct | 10:55 |
| benschubert | or even if it renames the project instance | 10:56 |
| tristan | So I still worry about ambiguities here | 10:56 |
| benschubert | if should not matter | 10:56 |
| tristan | benschubert, If I have a "would be diamond" pattern of projects that is actually a pyramid | 10:56 |
| benschubert | no wait, I think we are getting confused and going in circles there | 10:56 |
| tristan | For instance: A -> B, A -> C, C -> D(1), B -> D(2) | 10:56 |
| tristan | I'm saying, using project names as keys here, does not explicitly specify *which* junction needs to have a rename, and which one gets overridden | 10:57 |
| benschubert | Are you sure? If we have renames and overrides, we end up in a state where: | 10:58 |
| benschubert | for each project and its junctions, each 'project' in the pipeline has a unique name (either because it has been overriden, or because it was renamed). | 10:59 |
| benschubert | And this is true wherever you are in a tree of projects/junctions | 10:59 |
| benschubert | So, as long as we treat overrides/renames recursively, we are fine | 10:59 |
| tristan | Hmmm, perhaps; because the "A->B" junction is where you rename "C", it is still in the context of "B" where "C" is still unique | 10:59 |
| benschubert | correct | 10:59 |
| benschubert | I think that we should keep the context everywhere, it should make everything easier to reason about | 10:59 |
| benschubert | I know we were discussing there before about having only the top level override win, but if we apply them in order, we get a stricter layout | 11:00 |
| tristan | Yes, I understand, it works this way... and with that, we could use it in the UI, to make more concise names indeed | 11:00 |
| tristan | No no, I'm just having a hard time to follow, sorry | 11:00 |
| benschubert | and we don't (and shouldn't) replace in the build-depends/runtime-depends | 11:01 |
| benschubert | haha I think that's true for both of us :D | 11:01 |
| tristan | But then, there will be other expectations I think which will be broken | 11:01 |
| benschubert | which are? | 11:01 |
| tristan | I.e. changing this in the UI will at least mean people will expect these renames to apply to artifact caches in user configuration | 11:01 |
| tristan | I don't think we'd want to go down the road of allowing dependencies to be expressed via project-name references, though | 11:02 |
| benschubert | I think that we should do that (otherwise renames will get messy) | 11:02 |
| tristan | I don't understand what you think we should do | 11:02 |
| benschubert | Ok, let me rewind: | 11:03 |
| tristan | (also, I'd like to re-re-re-rewind this to the beginning and follow the other branch of thought in a moment) | 11:03 |
| benschubert | - I think we should go for the 'overrides' and the 'project-names' that you propose | 11:05 |
| benschubert | - I think we should apply them recursively, bottom of the stack to the top level project | 11:05 |
| benschubert | - I think we should use project names in the configuration for those | 11:05 |
| benschubert | Other potential improvements: | 11:05 |
| benschubert | - Use the project name in the 'ui' instead of the long name | 11:05 |
| benschubert | - For artifact-caches, I can see some potential use cases to define per-name, though I am not sure we would want that | 11:05 |
| benschubert | -> if we don't want for artifact-caches, let's just use the long name in the UI, it is still simpler and leads to less confusion | 11:05 |
| benschubert | Does that make some sense? :) | 11:06 |
| tristan | ok | 11:06 |
| tristan | It clarifies that you also don't think we should go down the road of allowing project-name addressing of dependencies | 11:06 |
| benschubert | yep | 11:07 |
| benschubert | it's too much of a change | 11:07 |
| benschubert | though with the invariant of per-project cone uniqueness of name, we could do that | 11:08 |
| tristan | before descending into the other branch of thinking: What would we do for artifact names in this world view ? | 11:08 |
| tristan | I think that in this world view, we'd actually want to use the redefined names "as built", not the originals | 11:08 |
| tristan | And in *any case* we still want to be able to address artifacts as "just keys" without the full names, and still get cache hits | 11:09 |
| tristan | that's another long standing discussion | 11:09 |
| tristan | artifact full names are really for user convenience I think, they are largely superficial | 11:09 |
| benschubert | I can see two ways: | 11:10 |
| benschubert | - We allow per-name caching, potentially more work (if you have multiple times the same project for which you define artifacts), but also would allow more complex scenarios (potentially transform the config as a list with a 'projects' key? | 11:10 |
| benschubert | - We move to 'element-based' junction cache (that is we use the junction's element full path in the config) | 11:10 |
| benschubert | - We don't do anything unless someone asks | 11:10 |
| benschubert | correct, an artifact should not change based on those names | 11:10 |
| tristan | currently we may have a situation where we cannot reuse an artifact because a project was renamed, but that is just our failure to also cache it under the "key only" | 11:11 |
| tristan | Anyway | 11:11 |
| tristan | I should point out... | 11:11 |
| tristan | <benschubert> though with the invariant of per-project cone uniqueness of name, we could do that <--- I disagree with this | 11:12 |
| benschubert | right, that's something we already decided to remove the name from the 'key' | 11:12 |
| benschubert | ah? | 11:12 |
| tristan | Because addressing of dependencies by project names implies additional project configuration of elements | 11:12 |
| tristan | The only reason you can depend on freedesktop-sdk.bst:glib.bst, is because that string contains the name of the junction you need to *load* | 11:12 |
| tristan | Without it, you need the name configured somewhere else, which would be horrible when combined with also renaming possibilities in junctions | 11:13 |
| benschubert | right | 11:14 |
| benschubert | what I meant by "we could" is that, since it is unique, it would be a potential way of doing, though it would require a mapping somewhere | 11:15 |
| benschubert | So we agree on that | 11:15 |
| tristan | That leads me to consider the possibility of not making the renames possible in junctions to subprojects, but making it possible in project.conf instead | 11:15 |
| tristan | What if (A) We had this dictionary in project.conf ... and (B) We also supported full pathing of junctions to map to those names ? | 11:16 |
| tristan | I think it would be bad actually | 11:16 |
| tristan | it might obviate the default error you *should* receive when accidentally junctioning a project with a conflicting name | 11:16 |
| tristan | By forcing a project to name all their subprojects ... also bad. | 11:17 |
| benschubert | we could only add the renames + overrides there | 11:17 |
| benschubert | it has one advantage: a single place where you can see all the changes | 11:17 |
| benschubert | but yeah, I have no opinion on that | 11:17 |
| benschubert | and project.conf tends to grow with time, so maybe better to keep it smaller | 11:18 |
| tristan | Ok well, there is a possibility of saying "In project.conf we can list all the junctions we need to access elements from, and rename some of them also" | 11:18 |
| tristan | Listing the junctions there without naming them, would imply preloading them, which is a bad performance experience when you don't need to fetch a junction to `bst show` something unrelated | 11:19 |
| benschubert | definitely | 11:19 |
| tristan | Alright, so can I re-re-re-re-re-rewind this for a moment ? | 11:19 |
| benschubert | go for it :) | 11:19 |
| tristan | We've only explored renaming territory | 11:19 |
| tristan | And now we have a good idea I think of all the kinks and twists it might imply | 11:19 |
| tristan | There is an alternative where say, we add 2 new configurations, but they are basically booleans | 11:20 |
| tristan | (A) A junction itself can have a single "internal: True" boolean | 11:20 |
| tristan | This means: "Do not conflict with any reverse dependency", but does not necessarily come with any complicated guarantee of runtime dependencies bleeding across project boundaries (although that is also an option) | 11:21 |
| tristan | ... | 11:21 |
| benschubert | > Do not conflict with any reverse dependency | 11:21 |
| benschubert | What do you mean by that? | 11:21 |
| tristan | (B) A junction can have a list of "duplicates", e.g.: duplicate: ["foo.bst", "bar.bst:baz.bst", "juice.bst:orange.bst:jazz.bst"] | 11:22 |
| tristan | benschubert, it means basically that any reverse dependency project which junctions the same project without overriding this junction... will not cause any conflict/error, it will be a separate instance of the same project | 11:23 |
| tristan | That is the final goal of all of this in the end: only this | 11:23 |
| tristan | The "duplicate" list, would be for handling this in the reverse dependency project, where I bring in a new version of the same project but I know I'm doing it for a different use case | 11:24 |
| benschubert | not sure I grasp what `B` would do? | 11:24 |
| benschubert | ah | 11:24 |
| tristan | The UX is... I have a project and I add a junction | 11:24 |
| tristan | Then I get an error: sorry dude, this junction conflicts with that deep nested junction | 11:24 |
| benschubert | I like this less, it seems more complex to me, and less clear of what's happening | 11:24 |
| tristan | Now: I decide, Do I want to use a "link" ? Do I want to override the deep one ? Or do I want to "duplicate" it | 11:24 |
| benschubert | Also, the 'duplicates' is tricky, some projects have conflicting elements in the same project, thus having this duplicate.... | 11:25 |
| tristan | This is a junction configuration, not a project configuration | 11:25 |
| benschubert | I understand that | 11:26 |
| tristan | Right ? So at the junction level I say "I'm okay with this duplicate project which this junctioned project brings in" | 11:26 |
| tristan | Essentially, the renaming approach is only to solve these two use cases in the first place | 11:26 |
| benschubert | ah wait, so everything in `duplicates` would be junction elements? | 11:26 |
| tristan | Ye | 11:27 |
| tristan | s | 11:27 |
| benschubert | how do you validate that? Only on access of one of those elements? | 11:27 |
| tristan | So either I can say "Don't let this internal junction cause any conflict with reverse dependencies", or I can say as a reverse dependency "Yes, I'm okay with this duplicated project" | 11:27 |
| tristan | Validation of this is actually the easy part | 11:28 |
| benschubert | how? | 11:28 |
| tristan | That is done while loading, !1901 uses a global table of loaded projects | 11:28 |
| benschubert | which means you might never check it if you are not loading something in the path | 11:28 |
| tristan | I can easily cause those keys to become unique by way of "internal" and "duplicate" declarations, silencing the error and allowing the load | 11:28 |
| benschubert | like if you don't depend on it | 11:28 |
| tristan | I don't think I follow your last two lines exactly | 11:29 |
| benschubert | Back to: | 11:30 |
| benschubert | > Ok well, there is a possibility of saying "In project.conf we can list all the junctions we need to access elements from, and rename some of them also" | 11:30 |
| benschubert | 12:19 PM Listing the junctions there without naming them, would imply preloading them, which is a bad performance experience when you don't need to fetch a junction to `bst show` something unrelated | 11:30 |
| benschubert | It seems to me it's the same problem if we want to validate things correctly | 11:30 |
| tristan | The difference is that you are never *required* to duplicate something | 11:31 |
| benschubert | fair point | 11:31 |
| tristan | benschubert, also remember that... if I duplicate something in my junction, that's my business; the error will reliably happen again in a reverse dependency project which tries to bring in that same project *again* by other means | 11:31 |
| tristan | So every time you junction something, by default you will get an error if you have no explicit knowledge of this coexistence | 11:32 |
| benschubert | so this would not bleed out, I like this idea | 11:32 |
| benschubert | so we would need: coalescing + those two right? | 11:33 |
| tristan | This is the original idea of a "whitelist" combined with the idea of "internal" | 11:33 |
| tristan | coalescing is now what we are calling the thing we currently have | 11:33 |
| benschubert | yeah, but we'd still need it right? | 11:34 |
| tristan | I know it's confusing, but juergbi has been calling it that, I know that technically we are changing coalescing of junction element names for project names, though | 11:34 |
| tristan | Basically !1901 already has coalescing of project names used to trigger an *error* | 11:34 |
| tristan | The other 2 configurations are ways to explicitly avoid that error | 11:34 |
| benschubert | tristan: just to make sure I get it, we would not get rid of the way of telling a junction, "for your junction foo.bst, please you my element "blah.bst" right? | 11:35 |
| benschubert | So we would have this + the two booleans | 11:35 |
| tristan | We would also have overrides yes | 11:36 |
| tristan | overrides explicitly overrides a subproject's junction with a local junction | 11:36 |
| benschubert | (I wonder why we force it to be local?) | 11:36 |
| tristan | Also we now have link, so we can also easily say "Override this subproject junction with my local link to this other subproject junction" | 11:36 |
| benschubert | ok, that's simple enough | 11:37 |
| benschubert | mmh I am still not 100% sure about the 'internal' stuff | 11:37 |
| tristan | Ok so | 11:37 |
| benschubert | it seems hte naming would bring more expectations thant that | 11:37 |
| benschubert | (will need to go to eat, can we continue in 30-45 minutes?) | 11:37 |
| tristan | When you say "duplicate", that means you are a high level project saying "I am okay with this duplication" | 11:37 |
| tristan | benschubert, When you say "internal", that means: I know I am only using this as build dependencies internally, and I want to hide this conflict from any reverse dependency projects | 11:38 |
| benschubert | my problem is "i know that", it's more error pron | 11:38 |
| benschubert | *prone | 11:38 |
| tristan | I.e. we don't *always* want to force reverse dependency projects to have knowledge of low level internals | 11:39 |
| tristan | benschubert, Right, and that's why there is a suggestion of checking for runtime element dependencies bleeding through a project which has an "internal" junction | 11:39 |
| benschubert | that's complex, you _might_ have some internal elements that should not be depended upon that can have runtime deps there | 11:40 |
| tristan | If I declare an internal junction, and my reverse dependency project has elements which end up runtime depending on elements from my internal junction, that could be an error | 11:40 |
| benschubert | and what is your element is a compose and you therefore export everything :P | 11:40 |
| benschubert | correct, so with 'renaming', a low level project could say "project-names: fsdk: my_internal_fsdk_please_dont_touch" and we would have the same behavior | 11:40 |
| tristan | Exactly | 11:40 |
| tristan | It kind of handles both directions | 11:41 |
| benschubert | so by that I still think rename + overrides is a simpler approach | 11:41 |
| benschubert | and allows top level projects to force something if they wish | 11:41 |
| benschubert | at their own risks | 11:41 |
| tristan | But from our conversation, I'm starting to feel the opposite :) | 11:41 |
| tristan | Also, making the distinction between internal/duplicate gives us the power to possibly implement checks | 11:41 |
| tristan | Whereas renames does not separate these semantics | 11:42 |
| tristan | benschubert, go eat and think about it | 11:42 |
| tristan | I'm a bit worried of all the implications of renaming projects more that we talk about it to be honest | 11:42 |
| *** santi has quit IRC | 11:56 | |
| tristan | benschubert, fwiw, I don't see how https://gitlab.com/BuildStream/buildstream/-/merge_requests/1954 would be a breaking change, if it is; then it's certainly fixing a bug (if includes were able to overwrite conditionals by virtue of inclusion, that seems like it would have been a pretty bad bug) | 12:00 |
| *** santi has joined #buildstream | 12:00 | |
| WSalmon | I am getting more `Remote (https://push.public.aws.celduin.co.uk) already has artifact 25176b94 cached` @ https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/578770889, i was expecting a little rebuilding for that job due to a rebase but im pretty sure its rebuiding way too much | 12:00 |
| WSalmon | https://gitlab.com/BuildStream/buildstream/-/issues/1314#note_354422869 are the others involved with this issue happy with my comment? juergbi coldtom cphang et al. ? | 12:10 |
| benschubert | tristan: ok so no need for a ML post I guess? | 12:13 |
| benschubert | and back :) | 12:13 |
| benschubert | The checks would be complex to get right and many things could go awry | 12:13 |
| benschubert | I agree that it's a deeper rabbit hole than expected | 12:14 |
| *** slaf has quit IRC | 12:19 | |
| * tristan got distracted by old friend walking by, back... | 12:20 | |
| benschubert | ok! So... | 12:21 |
| tristan | benschubert, Do you think the checks (for reverse dependencies on "internal" projects bleeding through the junctioning project into reverse dependency projects), would be a hard requirement ? | 12:21 |
| tristan | I think that they could be nice to have, while renaming allows the same construct with no path at all towards such checks | 12:21 |
| tristan | But to be honest, it's mostly all of the possible side effects of renames which are starting to look scary | 12:22 |
| benschubert | I dislike the 'internal' name, because it implies more things than we could check and potentially doesn't have the same understanding for everyone | 12:22 |
| tristan | juergbi, originally suggested 'private' | 12:22 |
| benschubert | iff we have a clear definition of what the "internal" contract means, I could get behind it | 12:23 |
| tristan | But I disliked 'private' because I could see a case for reverse dependency projects 'linking' a private junction and reusing it | 12:23 |
| tristan | For instance, imagine a junction which basically provides a kind of compiler for a given format, we know that it is used internally for that project, but reverse dependencies might want to reuse the same one | 12:24 |
| tristan | I think that the internal contract really means that there is no chance of dependencies bleeding through the junctioning project to reverse dependency projects... OR that having that dependency would be unintended and warranting of an error | 12:25 |
| tristan | For a project which bootstraps itself, it might self junction internally | 12:26 |
| benschubert | I actually kind of like this idea: it would make 'bootstrap' projects easier (ensuring the stage 1 doesn't leak past stage 2) | 12:26 |
| tristan | And again, it would be wrong for reverse dependencies to be granted access to the original project | 12:26 |
| benschubert | but then, why restrict 'internal' to junctions? (playing the devil's advocate there) | 12:27 |
| tristan | I'm not sure that the checks would be that difficult to implement, but I'm not entirely convinced the checks are a hard requirement | 12:27 |
| tristan | benschubert, That is a beautiful idea to be honest | 12:27 |
| benschubert | however, that's a long discussion on the ML ;) | 12:28 |
| benschubert | but I could get behind a `private` | 12:28 |
| tristan | However, I think the semantic might be a bit different for "internal elements" or "private elements" | 12:28 |
| benschubert | I do remember some discussion with Bazel folks where they had a problem around not having a notion of private elements, which lead to quite some problems | 12:28 |
| tristan | Since the beginning, we've left it to project authors to use their own conventions for marking things as private | 12:28 |
| tristan | There is a distinction however to make: Private in my eyes means "Reverse dependency projects should not *directly* depend on this, because it's not stable API of my project" | 12:29 |
| tristan | That is different from an artifact which should never make it into a build sandbox of a build in a reverse dependency project | 12:29 |
| tristan | I would expect people to name their elements with a leading underscore for instance to denote privateness | 12:30 |
| tristan | Things which might change between junction updates to more recent versions | 12:30 |
| benschubert | yeah right | 12:31 |
| tristan | (or place those elements in a private/ directory) | 12:31 |
| tristan | We haven't really taken a stance on how people do that, because we've been busy making the core work and hoping users would come up with that stuff :) | 12:31 |
| benschubert | Ok back to the original problem: is there a particular demand/use-case that was put forward that lead to this ML thread and this proposal? | 12:32 |
| tristan | But anyway, straying a bit here... If we implement the concept of "Elements from this subproject should not be depended on by superprojects in any way", why not do the same for elements ? and what should it really be called ? | 12:33 |
| tristan | Yes | 12:33 |
| tristan | benschubert, there are two competing forces to keep in mind | 12:33 |
| tristan | One: We cant have people overriding the projects they depend on without knowing it | 12:34 |
| tristan | Two: We want to reduce as much as possible any knowledge which projects need to have about the projects they depend on | 12:34 |
| tristan | So basically, If I have a project which depends on things in order to provide data/artifacts to my consumers (reverse dep projects), I don't want them to have to know how I made the sausage | 12:35 |
| tristan | I just want to provide the sausage | 12:35 |
| benschubert | I'd add a third one (that at least I'd like): We? want to allow a top level project ot have the last word on how a junction should behave? | 12:35 |
| tristan | I'm not even entirely convinced of this all around; I think it's clearly undesirable to override a subproject in any way at all | 12:35 |
| tristan | Overriding a subproject's junction is a last resort, because you have multiple dependencies on the same project which need to depend on the same one | 12:36 |
| tristan | It may happen often enough, and indeed, the toplevel project needs to have the last word | 12:36 |
| benschubert | it does happen, there are some "valid" use cases for that, so that's something I'll be keen on keeping | 12:37 |
| tristan | But yes, anyway I think that that is still a detail of "One:", i.e. projects need to be able to explicitly override subproject junctions, but never accidentally | 12:38 |
| benschubert | fair | 12:38 |
| tristan | The "internal" or "private" thing comes from "Two" | 12:38 |
| tristan | I.e. I might use a project to do something internally, have compose or script elements between that and the artifacts my reverse dependencies consume, and I don't want those reverse dependencies to be forced to know about this internal detail | 12:39 |
| tristan | This is all in the interest of creating a clean API surface between projects | 12:39 |
| tristan | I want to `bst track junction.bst` on my dependency projects, get the latest stable, rebuild regularly; and have as little friction in that as possible | 12:40 |
| tristan | If that subproject starts to depend on a common third party subproject for artifacts I consume, I will need to get an error | 12:40 |
| tristan | But if that subproject uses another subproject I don't depend on, or a project only for build dependencies; I should not be bothered by that and my CI should flow | 12:41 |
| benschubert | So to summarize: | 12:41 |
| benschubert | in junction.bst: | 12:41 |
| benschubert | 'overrides': element -> element # to say, "for this (sub)+-junction element, use this element instead | 12:41 |
| benschubert | internal: bool # I guarantee this project does not leek out of my project, please don't notify dependents of me that they have a conflict with this project's junction | 12:41 |
| benschubert | in project.conf: | 12:41 |
| benschubert | junction-duplicates: [a.bst, b.bst, c.bst:d.bst] # I know those junctions are all the same, I don't want to use the same one, let me live with it | 12:41 |
| benschubert | Do I summarize your current thinking correctly? | 12:41 |
| benschubert | does `junction-duplicates` works accross junctions? That is if one junction defines one, it will work for its dep cone? | 12:42 |
| tristan | I would have envisioned duplicates being in a junction | 12:42 |
| tristan | Following the same style as overrides | 12:42 |
| tristan | Part of the declaration of that specific branch of inter-project dependencies | 12:43 |
| benschubert | and how would it work? Let's say I have A->B, A->C, B->C. How do I declare that C can be duplicated? | 12:43 |
| tristan | maybe "duplicate:" is not the perfect verb for this | 12:43 |
| benschubert | with A the top level project | 12:43 |
| tristan | You would only need to declare it on one side | 12:43 |
| tristan | So the "A->C" junction would say to duplicate C | 12:44 |
| tristan | Oh wait, it would be declaring C, I C what you mean :-S | 12:45 |
| tristan | I hadn't thought it out that far into the details of how it's all declared hehe | 12:45 |
| benschubert | Ok, I think I can get behind it, and as long as I can override, that means we can re-define all this stuff on a higher level project so I think it ticks all the boxes for me | 12:46 |
| benschubert | however, we'd need to go through all details again :) | 12:46 |
| tristan | I think that in any case, recursive resolution of junction paths is going to be a requirement | 12:46 |
| tristan | i.e. full paths | 12:46 |
| benschubert | I concur | 12:46 |
| tristan | I can capture all of this in an email and reply to your mail | 12:48 |
| tristan | Good ? | 12:48 |
| benschubert | Seems good to me :) | 12:48 |
| benschubert | thanks for taking the time for this | 12:48 |
| tristan | I think it was a very useful exercise to go down the rename thought experiment | 12:48 |
| tristan | Thank you ! | 12:48 |
| tristan | I've been sitting alone with this problem for a while haha | 12:48 |
| tristan | Have to get it solved | 12:48 |
| benschubert | agreed | 12:48 |
| benschubert | I have a project in mind with a project junctionning itself recursively, with the only thing changing being a config in the junction, and that would probably make it easier :D | 12:49 |
| tristan | It will certainly make it clearer how to achieve this, and stop you from doing things accidentally | 12:50 |
| scottclarke | Hi, I'd like to submit a small patch for this issue, would someone be able to give me developer access? https://gitlab.com/BuildStream/buildstream/-/issues/1336 | 12:50 |
| tristan | Sure ! | 12:51 |
| scottclarke | thanks tristan! | 12:54 |
| *** tristan has quit IRC | 12:56 | |
| WSalmon | I am getting more `Remote (https://push.public.aws.celduin.co.uk) already has artifact 25176b94 cached` @ https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/578770889, i was expecting a little rebuilding for that job due to a rebase but im pretty sure its rebuiding way too much | 13:40 |
| WSalmon | so looking at the code | 13:40 |
| WSalmon | the message from bst is only issues when BlobNotFound is raised (i think) | 13:40 |
| WSalmon | but did coldtom say the last time we looked at this the cache did not report issuing any BlobNotFound ? | 13:41 |
| WSalmon | except BlobNotFound as e: | 13:41 |
| WSalmon | # Not all blobs are available on this remote | 13:41 |
| WSalmon | element.info("Remote cas ({}) does not have blob {} cached".format(remote, e.blob)) | 13:41 |
| WSalmon | ah | 13:41 |
| WSalmon | no | 13:41 |
| WSalmon | sorry miss read | 13:43 |
| WSalmon | the error comes from self._pull_artifact_storage returning false, so that dose line up with what coldtom found :) | 13:44 |
| WSalmon | i though it was getting closer but sadly not | 13:44 |
| coldtom | the real question is why does it think that it's already cached | 13:45 |
| cphang | WSalmon can you think of a minimal example where we can locally reproduce this? | 13:45 |
| WSalmon | coldtom, i think its because it is already cached and its the pull that is incorrectly failing | 13:46 |
| WSalmon | cphang, i am doing so atm | 13:46 |
| WSalmon | i thought i had something but i had not | 13:46 |
| cphang | ack, ta | 13:46 |
| WSalmon | i seems to work fine if it only needs to pull one thing, but when the first thing it tries to pull is not there and so it has to pull loads of things, it seems to thing that it needs to rebuild tooo much. | 13:48 |
| WSalmon | tlater[m], when would https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_artifactcache.py#L313 ever be reached? i would think that ether lines 311 or 316 should be hit? | 14:14 |
| WSalmon | https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_artifactcache.py#L287 this is identiacl to 313 so its really hard to debug why things are falsely being reported as not pull able, so i would like to change one of the lines but i dont under stand the second line so dont know how to make the info more helpful | 14:16 |
| WSalmon | juergbi, | 14:16 |
| juergbi | WSalmon: you can check whether the line before it has `Pulling data for artifact..` or just `Pulling artifact...` | 14:29 |
| WSalmon | thanks juergbi | 14:33 |
| *** tristan has joined #buildstream | 15:00 | |
| *** ChanServ sets mode: +o tristan | 15:00 | |
| WSalmon | tristan, FYI https://gitlab.com/BuildStream/buildstream/-/issues/1337 | 15:01 |
| WSalmon | did you land something todo with this recently? | 15:02 |
| WSalmon | do you know what i need to do to fix it? | 15:02 |
| WSalmon | i presume my project has something that is now not acceptable | 15:02 |
| juergbi | WSalmon: that looks like fallout from !1948 | 15:04 |
| tristan | That is odd (but quiet leet) | 15:05 |
| tristan | Odd given https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_loader/loadelement.pyx#L96 | 15:05 |
| tristan | I mean, it seems quite impossible for a LoadElement to not have a link_target member | 15:05 |
| tristan | maybe a cython glitch here | 15:05 |
| benschubert | WSalmon: that's cython code, did you `pip install` after pulling the newer version? (as in, are you in editable mode and did not reinstall?) | 15:05 |
| tristan | Ah | 15:05 |
| tristan | A lack of rebuild might cause that | 15:06 |
| WSalmon | ah | 15:06 |
| WSalmon | thanks benschubert, that might be it | 15:06 |
| benschubert | yeah, cython is C code in the end, welcome to edit-compile cycle again :'D | 15:06 |
| WSalmon | oh, i didnt think i had moved many commits | 15:07 |
| WSalmon | thanks tristan and benschubert | 15:07 |
| benschubert | even if you move a single commit | 15:07 |
| benschubert | if a .pyx/.pxd file changes, you need to reinstall | 15:07 |
| juergbi | tristan: I assume you don't have any objections dropping BST_FORCE_{SANDBOX,BACKEND} as they become useless with the bwrap drop or do you want to take a closer look at https://gitlab.com/BuildStream/buildstream/-/merge_requests/1952 ? | 15:07 |
| WSalmon | indeed | 15:07 |
| tristan | juergbi, kill it sounds great ! | 15:08 |
| juergbi | :) | 15:08 |
| juergbi | 35 files changed, 186 insertions(+), 2820 deletions(-) | 15:08 |
| tristan | juergbi, I suppose we still might need to have CI testing various modes of BuildBox though ? | 15:08 |
| tristan | Like maybe the unix test or smth ? | 15:08 |
| juergbi | the unix job has been removed a while ago already | 15:09 |
| juergbi | we still test buildbox-run-userchroot, though, which is the variant that also works on non-Linux | 15:09 |
| tristan | Perfect | 15:09 |
| juergbi | and we test missing deps | 15:09 |
| benschubert | that's an awesome MR :D | 15:09 |
| cphang | juergbi including osx? | 15:12 |
| benschubert | cphang: there is currently no sandboxing technologies really usable by BuildStream on OSX | 15:12 |
| benschubert | and if that comes, it will be through buildbox-run, so we should be fine | 15:12 |
| juergbi | is userchroot not (yet) working on MacOS? | 15:12 |
| benschubert | is userchroot working on MacOS? (I didn't know that?) | 15:13 |
| benschubert | I guess you'd still need to make a chroot | 15:13 |
| juergbi | I'm asking, I don't remember | 15:13 |
| benschubert | ah, I actually have no idea whether it works | 15:13 |
| juergbi | yes, it might be tricky to define a suitable chroot, there may also be copyright concerns | 15:13 |
| juergbi | but technically it might work | 15:14 |
| benschubert | true | 15:14 |
| tristan | I (personally) would be happy to land regardless and file that as a buildbox issue | 15:15 |
| tristan | it's not like we had osx support with BuildStream 1 also | 15:15 |
| juergbi | yes, before buildbox-run we never properly supported anything but Linux | 15:19 |
| juergbi | even the 'generic' unix sandboxing backend relied on linux-specific mount options | 15:19 |
| juergbi | and pyfuse | 15:19 |
| juergbi | it's merged now | 15:20 |
| tristan | party \o/ | 15:20 |
| cphang | \o/ | 15:21 |
| benschubert | awesome ! | 15:21 |
| *** tpollard has joined #buildstream | 15:22 | |
| tpollard | Hi, with a script element, I know you can add '' to get an empty r/w directory with a given name | 15:23 |
| tpollard | If I have a path /foo/bar, should I expect only bar to be r/w? | 15:23 |
| tpollard | I'm trying to work out if a package has changed behaviour in a new release, or bst behaviour has changed | 15:25 |
| juergbi | tpollard: if root-read-only is True, only the destinations specified in the layout are read-write | 15:29 |
| juergbi | or am I misunderstanding your question? | 15:29 |
| tpollard | I've got a script element that adds /foo/bar, and writes to it | 15:30 |
| tpollard | however, during the build the packages wants to r/w /foo/baz, but seemingly can't | 15:31 |
| tpollard | if I manually add in another '' for /foo, it works | 15:31 |
| tpollard | so I'm presuming that only the bar subdir is r/w, and the root foo isn't | 15:32 |
| tpollard | however the version of the package & the version of bst changes between both snapshots, so I'm trying to narrow down what is happening | 15:34 |
| tpollard | I can't point you to the actual repo if I'm not explaining it very well | 15:35 |
| tpollard | also referring to https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/scriptelement.py#L143 | 15:36 |
| douglaswinship | I'm trying to build the same thing on two different machines something using buildstream 1.93.1 (and bst-plugins-experimental 1.93.1). It works just fine on one machine, but the other refuses to even build. I'm getting an error message: | 15:41 |
| douglaswinship | Error loading user configuration: {myHomeDirectory}/.local/lib/python3.7/site-packages/buildstream/data/userconfig.yaml: Severely malformed YAML: | 15:41 |
| douglaswinship | 'NoneType' object is not callable | 15:41 |
| douglaswinship | Any ideas? | 15:41 |
| douglaswinship | I've just now pip-uninstalled and pip-reinstalled the appropriate versions of buildstream and buildstream-plugins-experimental | 15:41 |
| douglaswinship | and the file that it mentions (userconfig.yaml) looks identical across both machines. | 15:42 |
| coldtom | douglaswinship: `pip3 install --user ruamel.yaml.clib` is the fix to that iirc, i could be wrong though | 15:42 |
| tpollard | yep, it's a known issue | 15:42 |
| tpollard | one of benschubert's favourites I believe | 15:42 |
| douglaswinship | nope. It's claiming that was already installed, and it hasn't fixed the issue | 15:43 |
| tpollard | juergbi: did my explanation make sense? | 15:43 |
| douglaswinship | i'll try uninstalling/reinstalling | 15:43 |
| benschubert | douglaswinship: you need to force reinstall (-U works) | 15:43 |
| benschubert | it's ... annoying | 15:43 |
| WSalmon | <juergbi> tpollard: if root-read-only is True, only the destinations specified in the layout are read-write <- this seems to agree with what tpollard is experiencing, i wonder why it used to work | 15:43 |
| juergbi | yes, I would ask myself the same thing | 15:43 |
| benschubert | but ruamel.yaml.clib does a test-compile as a pre-build step (WTH) and ends up failing because they haven't setup the env correctly... | 15:44 |
| juergbi | assuming root-read-only is indeed True | 15:44 |
| benschubert | and with their move to sourceforge, contributing is... hard | 15:44 |
| tpollard | the script element is not setting it as true | 15:44 |
| juergbi | hm, then everything should be read-write | 15:44 |
| douglaswinship | juergbi: the file in question doesn't directly set that paramet, if I recall. It could be true by default though? | 15:44 |
| juergbi | it's not | 15:44 |
| juergbi | project.conf could override it, though | 15:44 |
| juergbi | (but would rather be odd) | 15:44 |
| WSalmon | i thought we defaulted to root-read-only is True | 15:45 |
| tpollard | bst doesn't | 15:45 |
| juergbi | root is read-only by default for BuildElements | 15:45 |
| juergbi | but not for scripts | 15:45 |
| WSalmon | oh | 15:45 |
| WSalmon | i wonder if a project conf somewere has changed that would turn it on for scripts.. | 15:46 |
| tpollard | I still think bst is only setting the subdir as r/w | 15:46 |
| tpollard | I don't know if that's change behaviour though | 15:47 |
| WSalmon | i wonder if tpollard tries to explicitly turn it off, then we would have a bug that it is getting turned on when it should not? | 15:47 |
| juergbi | tpollard: it could also be a regression in the switch to buildbox-run | 15:47 |
| douglaswinship | tpollard: i suppose that should be easy enough to test though? | 15:47 |
| juergbi | although we should have this covered by tests | 15:47 |
| douglaswinship | tpollard: s/easy/straight-foward-but-possibly-time-consuming | 15:48 |
| juergbi | (there are known limitations with buildbox-run-userchroot permissions but I assume you're using buildbox-run-bubblewrap) | 15:48 |
| tpollard | https://gitlab.com/celduin/bsps/pi-3b-plus-bsp/-/blob/bst-1.93.1/elements/deploy/image.bst is the script in question | 15:48 |
| douglaswinship | coldtom: benschubert: thanks btw! it worked. | 15:48 |
| benschubert | I should really get to detect that and handle it in BuildStream given how frequent it is :/ | 15:49 |
| tpollard | juergbi: so before adding in https://gitlab.com/celduin/bsps/pi-3b-plus-bsp/-/commit/9ee196fb86b5fe8bc85bfeb05dd42c59ee111f0e | 15:50 |
| douglaswinship | what's the term for things like "root-read-only" btw? they're not 'variables'. Variables are the things that get expanded out with the %{} syntax. So what are they? | 15:50 |
| douglaswinship | (I have a question i want to ask but i'm facing a vocabulary error) | 15:50 |
| tpollard | juergbi: it complained about /genimage/tmp, however, it was seemingly fine with writing to /genimage/sdcard which was defined in the layout | 15:51 |
| benschubert | douglaswinship: options? config? | 15:51 |
| coldtom | i think config is the best word for it | 15:51 |
| coldtom | otherwise you have a name collision with project options imo | 15:52 |
| juergbi | tpollard: you don't have to explicitly list parent directories of layout destinations | 15:52 |
| juergbi | it creates those implicitly | 15:52 |
| juergbi | however, the parents are not writable unless they are specified as layout destinations themselves | 15:53 |
| juergbi | (except for destination '/' where root-read-only takes precedence) | 15:53 |
| WSalmon | juergbi, yep but you said root-read-only should not be on for scripts by default? | 15:55 |
| douglaswinship | WSalmon: juergbi: unless it's on by default, for root. And off by default for everything else? | 15:57 |
| douglaswinship | sorry, ignore that. I misread | 15:57 |
| douglaswinship | coldtom: benschubert: thanks, config sounds good. | 15:58 |
| douglaswinship | So you can use bst show to display all the available variables, and what they resolve to, for a given element: https://docs.buildstream.build/1.4.3/tutorial/autotools.html?#looking-at-variables | 15:58 |
| douglaswinship | is there a way to do the same for config settings? | 15:59 |
| tpollard | juergbi: that makes sense thanks, the the subdir is r/w, but the parent/root of it isn't | 15:59 |
| tpollard | *that the | 15:59 |
| douglaswinship | oh! bst show --format "%{config}" element-name.bst does some of what i was asking for. | 16:03 |
| douglaswinship | (but not enough) | 16:03 |
| tpollard | douglaswinship: I think the easiest way we could test it for peace of mind is to apply a patch to the fdsdk junction in the bsp repo to switch it back to genimage 12 | 16:04 |
| tpollard | remove the explicit /genimage, and see if it doesn't complain | 16:04 |
| tpollard | that would rule out it being a difference in bst versions | 16:04 |
| douglaswinship | tpollard: did you try it out? (/would you like some help?) | 16:31 |
| tpollard | I won't have time to try it out today, if you'd like to feel free :) | 16:32 |
| tpollard | whilst we're in flux between bst versions & 'bsp' repos I wouldn't put too much effort into it though | 16:33 |
| tpollard | once we've got a more stable pipeline then we can give things a good test | 16:33 |
| douglaswinship | Sure | 16:34 |
| tpollard | we'll have to port the license split rule stuff over, so that'll be a good opportunity to see what we hit | 16:36 |
| douglaswinship | port it over? Is the syntax for split rules different between different bst versions? | 16:36 |
| tpollard | between different 'bsp' repos | 16:36 |
| douglaswinship | this is becoming a very #Celduin conversation, in #buildstream... | 16:37 |
| douglaswinship | i'll message you :) | 16:37 |
| tpollard | sure | 16:37 |
| douglaswinship | back on buildstream: Can anyone help me figure out how to resolve this error? I'm trying to "bst shell" into an element: | 16:38 |
| douglaswinship | Error launching shell: Sources for element jupyter/notebook.bst are not cached.Element must be fetched. | 16:39 |
| douglaswinship | This is the first time i've tried to build or shell into anything from this project, locally. The build went fine, but shell is throwing the error. | 16:39 |
| *** toscalix has quit IRC | 16:41 | |
| cphang | do we need to specify a source cache for shell to work? | 16:57 |
| * cphang with a naive grok of https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_stream.py#L211 | 16:57 | |
| cphang | ah, no this is a bug ini 1.93.1 https://gitlab.com/BuildStream/buildstream/-/commit/67ea61f5be51db24c2366167cb372d817e1ab6ff | 16:58 |
| douglaswinship | (and if so: why can't I just download the source from its original origin url?) | 16:58 |
| cphang | or more specifically https://gitlab.com/BuildStream/buildstream/-/commit/1f74bd72280b0e6712355625134af2758ec09717 | 16:58 |
| *** santi has quit IRC | 17:00 | |
| *** tpollard has quit IRC | 17:03 | |
| *** xjuan has joined #buildstream | 19:07 | |
| *** phildawson has quit IRC | 19:53 | |
| *** benschubert has quit IRC | 21:58 | |
| pointswaves | this job https://gitlab.com/pointswaves/embbeded-selfy/-/jobs/580084176 junctions the commit of FD that triggered https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/580051634 but the cache keys of the elements through the junction seem to be diffrent. eg. 0fd8f19015e950dd0808f540d7d5a33b5450405d8324f331b51c5af98194904a freedesktop-sdk.bst:bootstrap/build/base-sdk/image-aarch64.bst vs | 22:33 |
| pointswaves | 99c588db1e8bd9907a3ec89300a22a78aa693638a9b2fe79e2344550eae8ff23 im not sure if its because i have set embbeded selfy wrong or because something else is up | 22:33 |
| pointswaves | Any one got any ideas? | 22:34 |
| *** xjuan has quit IRC | 22:35 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!