| *** narispo has quit IRC | 01:39 | |
| *** narispo has joined #buildstream | 01:39 | |
| *** tristan has quit IRC | 04:44 | |
| *** tristan has joined #buildstream | 04:54 | |
| *** narispo has quit IRC | 06:03 | |
| *** narispo has joined #buildstream | 06:04 | |
| *** pointswaves has joined #buildstream | 06:55 | |
| *** ChanServ sets mode: +o tristan | 07:55 | |
| tristan | juergbi, I've posted an elaborate email on the problems of the junction jungle (aka 'the juncle') | 07:55 |
|---|---|---|
| tristan | I think some people are having a day off today for some holiday reason | 07:55 |
| juergbi | yes, UK people are on bank holiday | 07:56 |
| juergbi | will take a look | 07:56 |
| benschubert | Hey, could someone have a look at https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/107 ? | 08:01 |
| * tristan takes a look | 08:08 | |
| benschubert | thanks :) | 08:10 |
| * tristan notices that bst-plugins-experimental is doing `from buildstream.testing.something_else import foo` rather than `from buildstream.testing`, and wonders if we want to cleanup around there | 08:11 | |
| tristan | but I guess we want to cleanup more than just those nitpicks | 08:11 |
| benschubert | yeah, guess there is quite a bit of things to do there | 08:12 |
| tristan | At first I was confused that formatting changes seemingly intended for one commit ended up in the other, but I see the second commit adds setup.py and also fixes it's format | 08:16 |
| tristan | looks clean to me | 08:16 |
| benschubert | thanks :) let's get that in before more bleeding happens | 08:16 |
| *** tristan has quit IRC | 08:24 | |
| pointswaves | tristan they move the early may bankholiday to today because its 75 years since the end of the second world war in Europe. | 08:45 |
| *** phoenix has joined #buildstream | 09:06 | |
| benschubert | pointswaves: concerning what oyu asked yesterday. are both versions of buildstream you are using on the same commit? | 09:58 |
| coldtom | pointswaves, your issue is you're using the 1.4 bst-artifact-server image, and a master client | 10:01 |
| coldtom | there is no corresponding image for master, in celduin-infra we use buildstream/buildstream:dev for this, as it still provides the `bst-artifact-server` command | 10:02 |
| pointswaves | coldtom, i presumed it must be soemthing like that, master-140892353 tag seems rather missleading | 10:15 |
| pointswaves | thanks | 10:15 |
| *** phildawson has quit IRC | 10:38 | |
| *** rdale has joined #buildstream | 11:25 | |
| jjardon | Hi would it be possible to have a new bst-1.x release? IT has some issues that is affecting some projects | 12:44 |
| jjardon | 1.4.3 I think it would be | 12:45 |
| *** toscalix has joined #buildstream | 13:46 | |
| *** slaf_ has joined #buildstream | 14:04 | |
| *** slaf has quit IRC | 14:06 | |
| pointswaves | When i build https://gitlab.com/pointswaves/keytest on x86 i get a cache key of 67b38a5cf9461b1c896412a789af9b26a338546cf900f969ceaa1dca8eb1090d but on aarch64 51a1df4f9e3a2184deda7f621368562e2a2081a96ed3ccd841acf14d17ffd07f why do includ elements like this not have the same key on all architectures? i am running both at 1.93.3 and i updated both today | 14:37 |
| pointswaves | i wish to pull and checkout remotely build artifacts, how todo ask bst to make the artifacts mach so i can pull the other arches artifact? | 14:39 |
| juergbi | pointswaves: there is no special casing for `import` | 14:41 |
| juergbi | maybe we could skip the sandbox parts of the cache key for all elements with BST_RUN_COMMANDS = False | 14:41 |
| abderrahim[m] | +1 | 14:42 |
| abderrahim[m] | I've stumbled upon this too and didn't know there was already something in plugins that tells they don't run any command | 14:42 |
| abderrahim[m] | pointswaves: for your second question, define an option for the arch (and assign it to a variable), and define sandbox:build-arch to the value of the option | 14:44 |
| abderrahim[m] | then you can do things like `bst -o arch aarch64 artifact pull some/element.bst` | 14:44 |
| pointswaves | that sounds like what i want | 14:45 |
| pointswaves | is sandbox:build-arch a config option or a var? | 14:45 |
| abderrahim[m] | it's actually | 14:45 |
| abderrahim[m] | sandbox. | 14:45 |
| abderrahim[m] | sandbox: | 14:45 |
| abderrahim[m] | build-arch: '%{arch}' | 14:45 |
| pointswaves | :) | 14:46 |
| abderrahim[m] | in project.conf | 14:46 |
| pointswaves | like https://gitlab.com/pointswaves/keytest/-/blob/willsalmon/sandboxarch/project.conf ? | 14:52 |
| pointswaves | because bst dose not seem to expand the target_arch.. | 14:52 |
| abderrahim[m] | pointswaves: you named your variable arch https://gitlab.com/pointswaves/keytest/-/blob/willsalmon/sandboxarch/project.conf#L13 and are trying to expand the name of the option rather than that of the variable | 14:54 |
| abderrahim[m] | (you can have the same name if you want) | 14:55 |
| abderrahim[m] | and it's probably a good idea | 14:55 |
| pointswaves | are you recomending setting the var to target_arch ? | 14:56 |
| pointswaves | that dose not seem to work.. | 14:57 |
| abderrahim[m] | I think it's less confusing if the option and the variable containing it are the same name, yes | 14:58 |
| abderrahim[m] | let me try | 14:59 |
| pointswaves | i have bumped https://gitlab.com/pointswaves/keytest/-/blob/willsalmon/sandboxarch/project.conf | 14:59 |
| pointswaves | https://pastebin.com/GYwLwsX2 | 15:00 |
| abderrahim[m] | I believe it did work at some point, may be a regression | 15:02 |
| juergbi | sounds like we're missing variable substitution. if so, we definitely need to fix that, and add a test | 15:04 |
| *** tristan has joined #buildstream | 15:08 | |
| pointswaves | juergbi, were should i look? i never knew much about the loader even when i worked on the code regually | 15:13 |
| juergbi | pointswaves: it's outside/after the loader. we need something like Elelment.__expand_environment() also for the sandbox | 15:19 |
| pointswaves | juergbi, like https://gitlab.com/BuildStream/buildstream/-/commit/a4f504dce4cf3dba74837f4d64b58a9003463157 ? these new nodes confuse me, can i turn a dict back in to one? im gessin this means im doing it wrong? | 15:57 |
| pointswaves | oh i got it the worng way round.. | 15:59 |
| pointswaves | i have something that runs... | 16:07 |
| pointswaves | SAME CACHE KEY :O | 16:09 |
| pointswaves | juergbi, how do i test for this? | 16:10 |
| *** slaf_ has quit IRC | 16:21 | |
| *** slaf has joined #buildstream | 16:21 | |
| pointswaves | I gues we could just have a project conf were its a var and make sure that it atleast expands.. | 16:22 |
| juergbi | yep | 16:25 |
| juergbi | as BuildStream validates arch names, unexpanded variable will immediately bail out, as you've noticed | 16:26 |
| benschubert | juergbi: I know it's been a long while but should we still get https://gitlab.com/BuildStream/website/-/merge_requests/121 in ? If so, mind merging it I don't have permissions there | 16:51 |
| pointswaves | i need to verify but something like https://gitlab.com/BuildStream/buildstream/-/commit/e0890f7bb3fde705038c0e40c9efd43a1d42dcfb | 16:51 |
| juergbi | benschubert: yes, I think so. pip3 install --user -e . doesn't even work anymore, afaik | 16:53 |
| juergbi | I think we simply forgot to merge this back then, right? | 16:53 |
| juergbi | and cs-shadow has added venv instructions in the meantime | 16:54 |
| benschubert | ah, should I just remove it entirely then? | 16:54 |
| benschubert | yeaah we did indeed forget that | 16:54 |
| *** pointswaves has quit IRC | 16:55 | |
| juergbi | benschubert: as long as we have instructions to install from tarball without venv, instructions to install from git without venv are not less useful, imo | 16:58 |
| benschubert | Ok I'll clsoe this one then :) | 16:58 |
| juergbi | I wrote _not_ less useful | 16:58 |
| juergbi | maybe focusing on fewer installation variants would make sense | 16:59 |
| benschubert | ah woops missed that one | 16:59 |
| juergbi | that MR is definitely better than the status quo, though. I don't have a strong opinion on it right now | 16:59 |
| benschubert | Ok, then let's get it in and we can make it better later? | 17:00 |
| juergbi | ok | 17:00 |
| benschubert | thanks | 17:03 |
| *** pointswaves has joined #buildstream | 17:27 | |
| pointswaves | juergbi, i have added https://gitlab.com/BuildStream/buildstream/-/merge_requests/1909 | 18:12 |
| juergbi | pointswaves: thanks. I think this might not be working for element-specific sandbox config | 18:15 |
| juergbi | i.e., it only expands project sandbox config | 18:15 |
| juergbi | should probably expand after composite | 18:15 |
| *** phoenix has quit IRC | 18:42 | |
| *** toscalix has quit IRC | 18:42 | |
| *** toscalix has joined #buildstream | 18:43 | |
| *** toscalix has quit IRC | 18:52 | |
| *** toscalix has joined #buildstream | 18:54 | |
| benschubert | Could someone have a look at https://gitlab.com/BuildStream/buildstream/-/merge_requests/1910 ? We'll need to rebase all our PRs on this afterwards because of https://docs.gitlab.com/ee/user/compliance/license_compliance/#migration-from-license_management-to-license_scanning | 19:22 |
| pointswaves | benschubert, could you add a description? | 19:23 |
| benschubert | pointswaves: done, I've copied the commit message there | 19:24 |
| benschubert | thanks! | 19:32 |
| pointswaves | juergbi, do we really want element wise arch? seems a bit mental but i dont see why not | 19:35 |
| * pointswaves tries to grok what `<juergbi> should probably expand after composite` means in code | 19:36 | |
| juergbi | pointswaves: it can be interesting for cross compilation with bootstrapping | 19:44 |
| juergbi | also, variable expansion needs to be handled correctly independent of whether anyone will use per-element build arch | 19:44 |
| juergbi | other parts of the `sandbox` config may be more commonly set in elements (e.g., future #38 knobs) and they may use variables as well | 19:45 |
| pointswaves | fair | 19:48 |
| pointswaves | Im just trying to understand, it needs to happen in the same place tho? as that info is not inside the cls so cant happen in the function but needs to happen before the funtion as thats were the bang happens | 19:49 |
| pointswaves | do i just need a alternative function to __expand_environment? | 19:49 |
| juergbi | pointswaves: yes, expand_environment is only meant for env. variables | 19:56 |
| juergbi | sandbox config is a bit different. maybe the split between extract and expand helper functions doesn't make sense | 19:58 |
| juergbi | i.e., we could also consider making extract an instance method and adding expansion after _composite() in there | 19:58 |
| juergbi | because I don't think we want to build SandboxConfig first with unexpanded values and then expand them | 19:59 |
| juergbi | I think benschubert suggested we actually expand all variables early on instead of the current explicit node_subst_vars() steps, which can be missed | 20:00 |
| juergbi | so it might change a bit again in the future | 20:01 |
| pointswaves | I dont really understand the element to follow all of that.. | 20:04 |
| benschubert | juergbi: correct, haven't been able to build a nice design yet though :/ | 20:04 |
| benschubert | and currently focused on plugins and related tests | 20:04 |
| benschubert | but might get to it in the month (at least I hope so) though if someone else want to give it a go, I'm happy to help | 20:04 |
| pointswaves | I dont think i am going to have time to attack anything that big in my own time.. do you feel the current MR is going to make further work harder? if not can we have it as a incremental imporement? | 20:11 |
| juergbi | no, this shouldn't be a blocker for this MR at all. was just fyi | 20:19 |
| benschubert | yeah, I'm not entirely convinced with the MR though | 20:19 |
| benschubert | wonder if we could get something nicer (and an explicit test) | 20:19 |
| *** rdale has quit IRC | 20:19 | |
| *** Paisley4198 has joined #buildstream | 20:44 | |
| *** Paisley4198 has quit IRC | 20:46 | |
| *** pointswaves has quit IRC | 22:07 | |
| *** slaf has quit IRC | 22:24 | |
| *** slaf has joined #buildstream | 22:24 | |
| *** toscalix has quit IRC | 22:58 | |
| *** benschubert has quit IRC | 23:11 | |
| *** mohan43u_ has joined #buildstream | 23:37 | |
| *** mohan43u has quit IRC | 23:39 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!