| *** narispo has joined #buildstream | 02:33 | |
| *** delli3 has quit IRC | 05:34 | |
| *** traveltissues has joined #buildstream | 08:30 | |
| *** benschubert has joined #buildstream | 09:11 | |
| *** santi has joined #buildstream | 09:44 | |
| *** tme5 has joined #buildstream | 09:48 | |
| *** tpollard has joined #buildstream | 10:07 | |
| *** jonathanmaw has joined #buildstream | 10:10 | |
| *** paulsherwood has quit IRC | 11:34 | |
| *** paulsherwood has joined #buildstream | 11:35 | |
| *** ikerperez has quit IRC | 12:07 | |
| *** traveltissues has quit IRC | 13:15 | |
| *** traveltissues has joined #buildstream | 13:15 | |
| coldtom | hi, i've just realised that using host tools to fetch sources means that buildstream potentially loses reproducibility, is there any thought about how to mitigate/solve this? | 13:46 |
|---|---|---|
| *** traveltissues has quit IRC | 13:55 | |
| *** traveltissues has joined #buildstream | 13:58 | |
| *** traveltissues has quit IRC | 14:00 | |
| benschubert | coldtom: in *theory*, the step of fetching the sources should be repeatable and give you the same data, whatever the version of the tool you are using to retrieve it. Combined with the 'ref' it should be enough to ensure repeatable builds at least. | 14:00 |
| benschubert | For reproducible builds, well... we can't beat the tools that are under us anyways (gcc/etc) | 14:00 |
| benschubert | For more details: | 14:00 |
| benschubert | 1) The Remote Asset API should standardize a part of the source fetching, which might help | 14:00 |
| benschubert | 2) There had been talks of also running the source fetchs in a sandbox, with allowed network access. Nothing concrete until now though | 14:00 |
| coldtom | benschubert: i don't think that that theory holds up in practice, if we just use the host tools then we also get whatever configuration and extra plugins are installed on a host, for example cloning a repo with/without git-lfs could give some pretty huge differences | 14:03 |
| coldtom | but, i like the sound of (2), i think that that seems like a sensible way to do things | 14:03 |
| benschubert | > cloning a repo with/without git-lfs could give some pretty huge differences | 14:31 |
| benschubert | Should not be a problem, the plugin should be able to tell | 14:31 |
| benschubert | > 2:03 PM <coldtom> but, i like the sound of (2), i think that that seems like a sensible way to do things | 14:32 |
| benschubert | Is not ideal either: How do you create this sandbox? By pulling something without a sandbox? -> shifting the problem. Moreover, I'm not sure how it would work with the RemoteAsset API | 14:32 |
| coldtom | i don't think it's reasonable for plugin authors to need to handle every single host tool config/plugin/add-on to ensure that things are fixed, as for sandboxing fetching i think it would need to be optional really for bootstrapping purposes | 14:47 |
| benschubert | > every single host tool config/plugin/add-on | 14:49 |
| benschubert | definitely, but we can have a plugin/setup | 14:49 |
| benschubert | like for lfs, you would have a "git lfs" source transform, and it would bail out if you don't support that | 14:50 |
| tme5 | from what i gather, coldtom's concern is that the user configuration could significantly affect the fetch | 14:52 |
| coldtom | the issue comes when i have lfs installed, and configured to clone with git, then the base git plugin is going to clone that in a different way whether i have a source transform or not, isn't it? | 14:52 |
| coldtom | yup, what tme5 said | 14:53 |
| tme5 | coldtom, idk if that example works, pretty sure it doesn;t automatically pull lfs objects | 14:53 |
| tme5 | but i think it's a reasonable concern in general - if i have a really funky .gitconfig could this break bst? | 14:54 |
| coldtom | tme5, i'm pretty sure you can at least configure it so that it does, and i definitely have had `git clone foo` at least pull lfs objects in the past (in any case, this was just a stab at an example) | 14:55 |
| benschubert | About breaking: you still pin to a ocmmit sha. Unless you rewrite git to do funky things.... but hey :) | 14:56 |
| benschubert | For LFS, I'm surprised that the pull would be automatic | 14:56 |
| coldtom | maybe not for git-lfs in specific, but i don't think it's too hard to consider someone having, say, a plugin for a tool that alters the content of a fetched commit | 15:03 |
| *** phildawson-ct has joined #buildstream | 16:48 | |
| *** phildawson_ has quit IRC | 16:49 | |
| *** hergertme|vaca is now known as hergertme | 17:05 | |
| jjardon | hi, who is the maintainer of the current buildstream CI? | 17:38 |
| *** tme5 has quit IRC | 17:40 | |
| benschubert | jjardon: the CI runners? | 17:51 |
| jjardon | yup | 17:51 |
| benschubert | valentind: If I remember correctly? | 17:55 |
| valentind | jjardon, What is the matter? | 17:55 |
| *** santi has quit IRC | 17:56 | |
| jjardon | I will PM you | 18:01 |
| gitlab-br-bot | juergbi opened MR !1826 (juerg/buildbox-signals->master: _sandboxbuildboxrun.py: Fix signal handling) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1826 | 18:03 |
| *** narispo has quit IRC | 18:07 | |
| *** narispo has joined #buildstream | 18:07 | |
| *** jonathanmaw has quit IRC | 18:21 | |
| *** phildawson-ct has quit IRC | 18:31 | |
| *** narispo has quit IRC | 19:24 | |
| *** benschubert has quit IRC | 21:09 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!