| *** mohan43u has quit IRC | 00:00 | |
| *** mohan43u has joined #buildstream | 02:06 | |
| *** mohan43u has quit IRC | 02:23 | |
| *** mohan43u has joined #buildstream | 02:24 | |
| tristan | dftxbs3e, yes | 03:11 |
|---|---|---|
| tristan | using `and` | 03:11 |
| tristan | dftxbs3e, syntax for conditionals is like python (internally we use jinja to parse these) | 03:12 |
| dftxbs3e | tristan, oh awesome! thanks! So: - arch == "i686" and arch == "ppc64le": | 03:12 |
| dftxbs3e | That's very cool! | 03:12 |
| dftxbs3e | what about or? | 03:12 |
| tristan | well, obviously not *that*, but yeah similar :) | 03:12 |
| dftxbs3e | - arch == "i686" or arch == "ppc64le": | 03:13 |
| dftxbs3e | Is that OK? | 03:13 |
| tristan | it's more plausible for `arch` to be either of those values than both simultaneously :D | 03:13 |
| tristan | dftxbs3e, yes :) | 03:13 |
| dftxbs3e | It's impossible yes. or is what I want! | 03:13 |
| tristan | dftxbs3e, you may need parenthesis | 03:14 |
| dftxbs3e | tristan, hmm I see: - (arch == "i686") or (arch == "ppc64le"): | 03:15 |
| tristan | at least the `and` using examples at https://docs.buildstream.build/master/format_intro.html#conditionals use parenthesis | 03:15 |
| dftxbs3e | or operator should have less priority though | 03:15 |
| tristan | I'm not sure it's required though | 03:15 |
| dftxbs3e | so it should be fine already, without parens | 03:15 |
| dftxbs3e | It's definitely not required as per the standard C priority rules which most things inherit | 03:15 |
| tristan | they do `- (foo == "x" and bar == "y")` | 03:16 |
| tristan | not sure why | 03:16 |
| dftxbs3e | ohhh, parens at each right and left end | 03:16 |
| dftxbs3e | So it's not a priority concern.. | 03:16 |
| tristan | anyway parens are supported, and looking at the docs they *might* be needed, I don't recall off hand why we have them in the docs | 03:16 |
| dftxbs3e | I'll give it a try when I can! | 03:17 |
| dftxbs3e | Since we don't have a buildstream web playground! :D | 03:17 |
| *** tristan has quit IRC | 03:23 | |
| *** tristan has joined #buildstream | 03:32 | |
| *** ChanServ sets mode: +o tristan | 03:32 | |
| *** tristan has quit IRC | 04:44 | |
| *** tristan has joined #buildstream | 05:38 | |
| *** ChanServ sets mode: +o tristan | 05:38 | |
| *** tristan has quit IRC | 07:47 | |
| *** tristan has joined #buildstream | 08:14 | |
| *** ChanServ sets mode: +o tristan | 08:14 | |
| nanonyme | tristan, are there any blockers for next bst 1.93.x release? | 10:27 |
| *** hasebastian has joined #buildstream | 14:26 | |
| tristan | nanonyme, yeah | 15:16 |
| tristan | nanonyme, a bug was discovered with link elements replacing the junction `target` config in some edge cases which I missed in my initial tests | 15:17 |
| tristan | So I need to fix that, wouldnt make sense to have that breakage included in this big api-changing snapshot | 15:17 |
| tristan | it's my immediate task at hand though, I should be able to take care of it early this week | 15:18 |
| tristan | ideally I should also get the non-recursive variables fix in too, which is a tangent of an important fix from valentind which I need to also backport to 1.5.x asap | 15:25 |
| nanonyme | tristan, sounds good. Why I'm asking is https://gitlab.com/freedesktop-sdk/infrastructure/freedesktop-sdk-docker-images/-/issues/11#note_377358821 | 15:38 |
| nanonyme | tristan, are you expecting significant API breakages still with future snapshots? | 15:40 |
| *** hasebastian has quit IRC | 15:48 | |
| tristan | nanonyme, a few yes, some more breaking than others | 16:34 |
| tristan | some of it is unpredictable but those I don't expect to incur major breakages; i.e. there are some agreed upon goals which need to be analyzed and hard proposals brought to the list, which makes for a significan portion of the blockers for 2.0 | 16:36 |
| nanonyme | Ok | 16:36 |
| tristan | implementing these goals are not necessarily blockers, but ensuring we can do them without API breaks is | 16:36 |
| tristan | Which means we may have to make some minor breaks for those | 16:36 |
| nanonyme | Right, just wondering how probable it is that we need to keep fixing plugins for API changes | 16:37 |
| tristan | The main upcoming breakage is sealing off some things which should never have worked in the first place (host side manipulation of content in the sandbox) | 16:37 |
| tristan | nanonyme, https://gitlab.com/BuildStream/buildstream/-/milestones/3 should point out a couple of the plugin facing breakages that we need to consider | 16:38 |
| nanonyme | tristan, that is actually interesting point. In some cases it would be nice to be able to run host commands that mangle sandbox | 16:38 |
| tristan | We may for instance try to rethink how we invoke the sandbox so as to ensure batching commands is default, not the exception | 16:38 |
| tristan | right, that should never be happening, it kind of breaks rule number 1 | 16:39 |
| tristan | if something can be done on the host, it can also be done in a sandbox deterministically (i.e. using only content that is controlled inside a sandbox) | 16:39 |
| nanonyme | Like, say, we have in our pipeline some flatpak tests and usage of flatpak-builder. These use bwrap so they cannot run inside BuildStream sandbox. Currently as a result these have to be heavily decoupled from BuildStream which makes it hard to be able to say in CI "just build this stuff with as high parallelity as possible" | 16:40 |
| tristan | As Chandan recently summarized on the list, there are some gaps, we need to expose the right data to the sandbox in the right way for the sandbox to be able to do what it needs in some edge cases | 16:40 |
| nanonyme | It would be nice to have less decoupling and do more things within scope of one BuildStream invocation since that would make CI faster | 16:41 |
| tristan | Right, BuildStream's primary focus is deterministic permutations of data within a controlled environment, and flexible tooling allowing modelling of such | 16:41 |
| tristan | running VMs and suchlike can often be better suited to post `bst checkout` activities | 16:42 |
| tristan | of course, with time, we may have in-sandbox solutions for these, who knows what the future will bring :) | 16:42 |
| nanonyme | Yes, that's how we do it now and it means there are unnecessary synchronization points in the CI pipeline | 16:43 |
| nanonyme | Since we need to wait for everything to build before calling checkout and progressing further. | 16:43 |
| tristan | Sure, it sounds like a nice to have to extend usage of buildstream to full CI scenarios; I quite firmly believe that that cannot come at the cost of guaranteed encapsulation | 16:44 |
| nanonyme | But not all of the built elements are relevant for all of the post-build steps | 16:44 |
| nanonyme | Yeah, it's problematic when testing involves another build system that also uses guaranteed encapsulation | 16:45 |
| nanonyme | That said, the alternative to mangling sandbox data from host seems to be just not use sandbox at all for some activities | 16:47 |
| nanonyme | bubblewrap inside bubblewrap just will not work when it's used for securing things :) | 16:48 |
| *** mohan43u has quit IRC | 18:36 | |
| *** mohan43u has joined #buildstream | 18:38 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!