| *** juergbi has quit IRC | 04:08 | |
| *** brlogger has joined #buildstream | 04:11 | |
| *** hergertme has joined #buildstream | 04:17 | |
| *** Chris has joined #buildstream | 04:19 | |
| *** tiagogomes has joined #buildstream | 04:23 | |
| *** brlogger has joined #buildstream | 04:49 | |
| *** tiagogomes has joined #buildstream | 05:01 | |
| *** Chris has joined #buildstream | 05:02 | |
| *** tristan has joined #buildstream | 06:15 | |
| *** ChanServ sets mode: +o tristan | 07:00 | |
| *** jude has joined #buildstream | 07:02 | |
| *** jonathanmaw has joined #buildstream | 07:11 | |
| jonathanmaw | I think something squiffy might have happened. I've got a gnome-system built, but when I try to `bst checkout`, I get permission denied (https://pastebin.com/hYxFt9a4) | 08:18 |
|---|---|---|
| jonathanmaw | (~/tmp has permissions a+rwx, btw) | 08:19 |
| tristan | oh that is strange | 08:25 |
| tristan | jonathanmaw, and if you try the same symlink in your shell with `ln -s` what does it say ? | 08:26 |
| tristan | also, is ~/tmp on the same filesystem as your artifact cache (~/.cache/buildstream/artifacts) ? | 08:27 |
| tristan | Note that I have to change `bst checkout` to always do copies, the fact it currently does hardlinks is a bug | 08:27 |
| tristan | sort of unfortunate, but must be | 08:27 |
| tristan | maybe we could add a `bst checkout --hardlinks` with an "At your own risk" warning | 08:28 |
| jonathanmaw | tristan: permission denied when creating symlinks | 08:29 |
| jonathanmaw | aha, ~/tmp managed to get owned by root | 08:30 |
| tristan | We didnt do that :) | 08:33 |
| tristan | heh | 08:33 |
| tristan | jonathanmaw, please file a bug though | 08:34 |
| tristan | jonathanmaw, it's not correct that `bst checkout` gives you a stack trace when that happens | 08:34 |
| jonathanmaw | tristan: created https://gitlab.com/BuildStream/buildstream/issues/36 | 08:38 |
| tristan | thanks :) | 08:39 |
| *** gitlab-br-bot has joined #buildstream | 08:40 | |
| tristan | jonathanmaw, here is a script you can use to convert a dd'able system image into a virtualbox bootable thingie: https://bpaste.net/show/4f208bec3df4 | 09:34 |
| tristan | if you run that, like ./setup-vm.sh <imagefile> <vmname> ... then after launching virtualbox you will see 'vmname' is already there | 09:35 |
| jonathanmaw | ta tristan | 09:35 |
| tristan | jonathanmaw, also note that there are some problems with that system, the gnome-initial-setup user handoff seems to be broken | 09:36 |
| tristan | it will boot into a shell, and then doing `service gdm start` will automatically launch gnome-initial-setup, but at the end it wont create the user and flip over to the new session | 09:36 |
| *** zes has joined #buildstream | 09:45 | |
| *** zes has quit IRC | 09:47 | |
| *** jonathanmaw has quit IRC | 10:34 | |
| *** jonathanmaw has joined #buildstream | 10:36 | |
| gitlab-br-bot | buildstream: merge request (jonathan/enhance-script-element->master: Jonathan/enhance script element) #22 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/22 | 11:09 |
| *** Chris has quit IRC | 11:13 | |
| *** Chris has joined #buildstream | 11:13 | |
| jonathanmaw | tristan: I've made merge requests https://gitlab.com/BuildStream/buildstream-tests/merge_requests/3 and https://gitlab.com/BuildStream/buildstream/merge_requests/22 which I'd appreciate your input on | 11:14 |
| tristan | jonathanmaw, Ok ! | 11:18 |
| tristan | jonathanmaw, I just want to go put food in me... | 11:18 |
| tristan | and directly after :) | 11:18 |
| jonathanmaw | :) | 11:25 |
| *** tristan has quit IRC | 11:25 | |
| *** tristan has joined #buildstream | 12:13 | |
| *** ChanServ sets mode: +o tristan | 12:13 | |
| tristan | jonathanmaw, so I've been looking at these MRs... I think it brings us much of the way there | 13:17 |
| tristan | I think we will try to merge soon and probably there will be some post-merge churn here | 13:18 |
| tristan | but I think first we aught to probably nail the x86image element a bit better... | 13:18 |
| tristan | jonathanmaw, I'll put my comments in the MR but my biggest concern here is how derived script elements expose their own API to users | 13:20 |
| tristan | I.e. the base script element is bleeding API to the image element, we should fix that | 13:21 |
| jonathanmaw | tristan: ok | 13:21 |
| tristan | I.e. I can see that gnome-system-image.bst is defining the layout, however the layout for an x86image is probably a detail of the x86image itself | 13:22 |
| tristan | instead it should be exposing it's own API for "what element is the tooling, and what element is the system we're deploying" | 13:23 |
| tristan | root-read-only: true is probably default anyway, but still; a user of the 'x86image' element has no business deciding how the image element is going to do it's work | 13:24 |
| jonathanmaw | tristan: I was assuming the "default" use-case is that you stage everything to "/", perform your commands, and pack up the changed staging area as the output | 13:29 |
| jonathanmaw | in which case root would default to not being read-only | 13:29 |
| tristan | jonathanmaw, right, I think though, that already the x86image element *itself* as a part of it's yaml file can mention that | 13:38 |
| jonathanmaw | tristan: ok | 13:38 |
| tristan | the users of the x86image should not need to know about it | 13:38 |
| jonathanmaw | tristan: I think if the values of the element field in layout accept variables, I can abstract away the need for a "layout" field, assuming there is one element that's in "/", and the other that's being worked on. | 13:41 |
| tristan | jonathanmaw, Ok I gave more comments, I think I have a good idea to change this | 13:43 |
| tristan | After, I think I may want to churn the x86image element itself later on but that is less important | 13:43 |
| tristan | jonathanmaw, take a read of the concerns and the suggested approach, I think it's better | 13:44 |
| jonathanmaw | tristan: I'm not sure what you mean by "Make the base ScriptElement interface purely pythonic" | 13:50 |
| jonathanmaw | Would that mean making root-read-only and layout set in the class, instead of the yaml? | 13:50 |
| tristan | jonathanmaw, yep just stepped out for a sec... ok so... | 13:54 |
| tristan | Basically, ... (I'm going refer to what you called ScriptElementBase as ScriptElement)... The ScriptElement would not itself have a configure() implementation | 13:55 |
| tristan | Instead, it would have some additional python APIs, which it expects the subclass to call in ITS configure() implementation | 13:56 |
| tristan | So, the bulk of the code you presently have in ScriptElement.configure(), would be moved over to the concrete script.py | 13:56 |
| tristan | And the x86image element, would parse it's own things, and call ScriptElement APIs with only the configuration relevant to itself | 13:57 |
| tristan | This way, the all purpose 'script' element gets to basically use all of the features exposed by the base ScriptElement class using yaml, in a very dynamic way | 13:57 |
| tristan | But the x86image only lets you do things relevant to the x86image element | 13:58 |
| tristan | While the bulk of the implementation (get_unique_key(), assemble() etc) is all implemented in the base ScriptElement class | 13:58 |
| tristan | jonathanmaw, how does that sound ? | 13:58 |
| tristan | So far I think it's all around cleaner and safer | 13:59 |
| jonathanmaw | sounds good | 14:00 |
| tristan | mostly some code moves from one place to another, and some APIs need to be defined and documented | 14:00 |
| tristan | jonathanmaw, note that any internal state that needs to be stored on the base ScriptElement instance, should be stored with double underscore prefix | 14:01 |
| jonathanmaw | tristan: I'm guessing that preflight should also be defined only in plugins, since that validates the input | 14:07 |
| tristan | jonathanmaw, Well, in that case we can share | 14:15 |
| tristan | Well, maybe you need some help from the core for that | 14:15 |
| tristan | hold on... | 14:15 |
| tristan | jonathanmaw, right, so for now there are two invariants we have across all script elements | 14:16 |
| tristan | A.) They have no sources | 14:16 |
| tristan | B.) Their direct dependencies are all build only dependencies | 14:17 |
| tristan | jonathanmaw, We can assert that in the base class script element, and document in ScriptElement that subclasses should always chain up in preflight() | 14:18 |
| jonathanmaw | ok | 14:18 |
| tristan | in python3 that is nicely done with: super(MyType, self).preflight() | 14:18 |
| tristan | Nice, ok updated blog post at: https://blogs.gnome.org/tvb/2017/06/01/continuous-bst-conversions-of-gnome-modulesets/ | 14:21 |
| tristan | After sneaking in a patch to jhbuild2bst | 14:21 |
| tristan | Hopefully in the nic of time :) | 14:21 |
| tristan | bst build --track meta-gnome-apps-tested.bst completes to a varying degree, but after this; `bst shell --scope run foo.bst` indeed works to launch and debug any application you have built | 14:22 |
| * tristan just launched gnome-sudoku.bst and glade.bst from a buildstream sandbox without issue | 14:23 | |
| *** jude has quit IRC | 14:33 | |
| jonathanmaw | tristan: I'm currently reading the variables "cwd", "build-root" and "install-root" during configure, too. Should I separate them into a "load_variables" method too? | 15:01 |
| jonathanmaw | I'm not sure if they change the idea that configure should be implemented only in derived classes | 15:02 |
| tristan | Ok so, for the all purpose script element, it is important to be able to specify what the cwd, and other things are, at least the install-root, I'm not sure about whether build-root is relevant | 15:04 |
| tristan | For an x86image element, it makes no sense really to allow the user to specify what the cwd is | 15:04 |
| tristan | Think of it the other way around I think: What API does the base element need to provide in order to allow the subclasses to do meaningful things ? | 15:05 |
| tristan | jonathanmaw, in other words, I would rather see APIs like ScriptElement.set_work_directory() | 15:06 |
| tristan | looking at the current MRs, the x86image element uses %{build-root} as a layout location, that is quite fine, but is quite irrelevant to the ScriptElement base class | 15:10 |
| jonathanmaw | tristan: it's currently just used as part of get_unique_key because it can affect the output | 15:11 |
| jonathanmaw | though I suppose since layout parsing happens after variable substitution, I can get around that | 15:12 |
| tristan | Right | 15:12 |
| tristan | The layout may or may not use the %{build-root} | 15:12 |
| tristan | or may use other variables depending on the subclass | 15:12 |
| tristan | For the collection area (where the artifact is produced from), it can be a set_install_root() which defaults to %{install-root}, or... it can just be hard wired to %{install-root} | 15:13 |
| tristan | without any API | 15:13 |
| tristan | that seems to be a pretty constant variable with always the same meaning | 15:13 |
| tristan | We could always grow an API for it without breaking any projects too, if we wanted to be more strict (and forcefully disallow users from being able to override that) | 15:14 |
| tristan | (i.e. it can be argued that for the x86image element, allowing the user to set install-root at all is just allowing an additional point of failure for no reason) | 15:15 |
| tristan | past midnight here /me leaves coffee shop... | 15:16 |
| *** tristan has quit IRC | 15:20 | |
| *** jude has joined #buildstream | 15:21 | |
| *** tristan has joined #buildstream | 15:27 | |
| *** jonathanmaw has quit IRC | 15:37 | |
| *** jude has quit IRC | 17:06 | |
| *** ChanServ sets mode: +o tristan | 18:05 | |
| *** tristan has quit IRC | 19:17 | |
| *** tristan has joined #buildstream | 19:19 | |
| *** tristan has quit IRC | 21:24 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!