| *** tristan has quit IRC | 07:20 | |
| *** tristan has joined #buildstream | 07:49 | |
| *** tlater has joined #buildstream | 08:02 | |
| *** jonathanmaw has joined #buildstream | 08:09 | |
| *** tristanmaat has joined #buildstream | 08:20 | |
| *** tristanmaat has quit IRC | 08:21 | |
| jonathanmaw | tristan: Would I be correct in thinking that the dpkg conversion script task should generate all the necessary .bst metadata, but creating a repository of the source is the user's responsibility? | 08:40 |
|---|---|---|
| *** ChanServ sets mode: +o ironfoot | 08:43 | |
| jonathanmaw | tristan: I can forsee us having problems with assuming that a debian package's dependencies can be translated into a .bst | 08:48 |
| jonathanmaw | chiefly, that one source can generate multiple packages, and the dpkg build element is performed on a source and creates packages as splits within it | 08:49 |
| jonathanmaw | and packages aren't always prefixed with the source package (i.e. python3-defaults-debian produces idle3, python3-* and libpython3-*) | 08:52 |
| *** tiagogomes has joined #buildstream | 09:09 | |
| *** ssam2 has joined #buildstream | 09:09 | |
| *** tiagogomes has quit IRC | 09:13 | |
| *** tiagogomes has joined #buildstream | 09:14 | |
| ssam2 | just to check, the script element's 'layout' config option can't deal with artifact splits right ? | 10:01 |
| ssam2 | I need a separate 'compose' element first to remove junk that I don't need from my image ? | 10:01 |
| jonathanmaw | ssam2: yep | 10:02 |
| gitlab-br-bot | buildstream: merge request (artifact-share->master: Artifact Cache Sharing) #38 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/38 | 10:03 |
| ssam2 | \o/ | 10:03 |
| tristan | jonathanmaw, ok so taking dpkg-deploy discussion here... | 10:07 |
| tristan | jonathanmaw, agreed that scriptlets pre/post inst/rm scriptlets are generic enough that they may apply to multiple packaging systems | 10:07 |
| tristan | jonathanmaw, *however* there is a catch | 10:07 |
| tristan | if we're going to make something generic for this kind of scriptlet, we have to recognize the different semantics of these with different packaging systems | 10:08 |
| tristan | and document the specifics and limitations around this | 10:08 |
| tristan | for instance, as I recall the rpm scriptlets are invoked with an argument | 10:08 |
| tristan | I forget exactly the detail, but it's a number | 10:09 |
| tristan | probably something convenient can be done so that pre/post inst/rm scriptlets can be embedded into a generated package scriptlet and fit the bill for multiple package based deployment systems | 10:09 |
| tristan | regarding debian/control | 10:10 |
| tristan | I'm still unclear about what you mean by this, i.e.: I dont know what is in that control file, you do | 10:10 |
| tristan | heh | 10:10 |
| tristan | I know it's a file with some metadata, I dont know what exactly the metadata is | 10:10 |
| tristan | tlater, your patch is getting warmer... lemme add some comments... | 10:11 |
| tlater | Okay :) | 10:12 |
| jonathanmaw | tristan: debian/control contains all of the package's metadata. Information that would be potentially useful is that it lists pre-depends (not sure what that is), depends, suggests, replaces and provides | 10:13 |
| jonathanmaw | (potentially useful to non-debian deployment) | 10:19 |
| jonathanmaw | tristan: as for rpm scriptlets, they usually go | 10:23 |
| jonathanmaw | <command-name> [-n <package>][-p <interpreter>] | 10:23 |
| jonathanmaw | <script body> | 10:23 |
| jonathanmaw | which should be parsable from the metadata available currently if we parse the shebang for the appropriate interpreter | 10:25 |
| tristan | tlater, ok comments up ! | 10:25 |
| tlater | Ok | 10:26 |
| tristan | jonathanmaw, right that is what is in a spec file, and that's not exactly what I mean :) | 10:26 |
| tlater | The comment on the subshell (set -e thing), some build scripts seem to assume that each command is executed in its own shell. In particular, glibc fails without that. | 10:27 |
| tristan | jonathanmaw, I mean, you will find that some %postinst scriptlets start with `if [ "$1" -eq "0" ]; then ...` | 10:27 |
| jonathanmaw | ah | 10:27 |
| jonathanmaw | hrm | 10:27 |
| tristan | tlater, good point | 10:28 |
| tristan | tlater, in which case, it makes more sense then to have the function return an array of script strings, instead of returning one fat script string | 10:28 |
| tristan | Maybe or maybe not | 10:29 |
| tristan | lets think of that a bit | 10:29 |
| tlater | I think it makes more sense to the user not to need to know that subshells may be necessary. | 10:29 |
| tristan | tlater, one argument for keeping it that way, is that the buildelement.py itself is the one responsible for calling the sandbox with `sh -e` | 10:29 |
| tristan | so in theory, if an element wants to create a script without that criteria, they no longer can if we make an api that doesnt allow it | 10:30 |
| *** jonathanmaw has quit IRC | 10:33 | |
| tristan | tlater, I think I redact that comment, and that you are right, it should generate a single script fragment | 10:35 |
| tristan | although we should take also a moment to consider what criteria and guarantees buildstream makes about the execution environment of that fragment, and document that on the public API | 10:36 |
| *** jonathanmaw has joined #buildstream | 10:49 | |
| *** jonathanmaw has quit IRC | 11:28 | |
| *** jonathanmaw has joined #buildstream | 11:44 | |
| tristan | juergbi, so... I sort of feel gross about passing a plugin object down into the guts of _ostree.py directly; on the one hand, I dont want to delay this merge further; on the other hand, I feel like I'm really going to have this itching desire to just create a utils._call() utility method similar to the current Plugin.__call() but without the self references (probably by just having output_file as an optional parameter defaulting to sys.stdout) | 12:12 |
| juergbi | yes, it's not ideal | 12:13 |
| juergbi | tristan: would you prefer passing a function reference to plugin.call down to ostree.py instead of the plugin itself? | 12:14 |
| juergbi | going via plugin is convenient with regards to logging etc. | 12:15 |
| tristan | juergbi, I would prefer that utils.py offer a utility for doing the call(), and that plugin.py use that function | 12:15 |
| tristan | a private utility | 12:15 |
| jonathanmaw | hrm, writing split-rules in public data doesn't override the defaults, so I can't cut out the "packages" variable from dpkg-deployment elements | 12:16 |
| tristan | I feel like, from the high levels, I really dont mind that say, _pipeline.py is doing self.toplevel.call() | 12:16 |
| tristan | juergbi, but I just feel gross about crossing the stack that way, while _ostree.py is a rather low level utility layer | 12:17 |
| gitlab-br-bot | buildstream: merge request (tristan/source-bundle->master: Add source-bundle command) #35 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/35 | 12:17 |
| juergbi | tristan: yes, i understand the concern | 12:17 |
| juergbi | tristan: hence my question about passing a function reference. strictly speaking, _ostree.py wouldn't know anything about Plugin class in that case | 12:17 |
| juergbi | it just knows the function signature | 12:17 |
| juergbi | if we can move it to util with clean logging etc. with ease, that would definitely be fine, of course | 12:18 |
| tristan | I would still want to shuffle things around | 12:18 |
| juergbi | ok. after merge or shall i give it a try before? | 12:19 |
| tristan | juergbi, it would mean that in plugin.py, self.__call() would itself have to do the __note_command() | 12:19 |
| tristan | and it would have to pass the self._output_file() | 12:19 |
| tristan | to the utility | 12:19 |
| tristan | juergbi, well, I already made one more comment that I think we should change | 12:19 |
| tristan | did you see, regarding the bin/ scripts ? | 12:20 |
| juergbi | yes, i agree, it makes sense | 12:20 |
| juergbi | it's not for users | 12:20 |
| juergbi | just have to figure out how to handlethis with setuptools | 12:20 |
| juergbi | (don't really know that at all) | 12:20 |
| tristan | ah, there are a couple more things too | 12:21 |
| tristan | juergbi, so put it in the same place data/ directory | 12:21 |
| tristan | and with setup.py add those to the same place as the default configs | 12:21 |
| tristan | juergbi, then add a line to _site.py, which will tell you the absolute path of where to find it in the installation | 12:22 |
| juergbi | ok, thanks for the info | 12:23 |
| tlater | I've finished making the changes for my PR, would you mind checking tristan? In particular, I'm not sure if the API doc is detailed enough. | 12:23 |
| tristan | juergbi, added one more comment there regarding `bst fetch` expected behavior | 12:25 |
| tristan | jonathanmaw, I again dont understand | 12:25 |
| tristan | jonathanmaw, I dont know what the "packages" variable is | 12:26 |
| juergbi | ok, makes sense | 12:26 |
| jonathanmaw | tristan: I'm using the "packages" variable as a way to identify which packages should be generated | 12:26 |
| tristan | jonathanmaw, still not following, ok so; first of all; is it not correct to just make one for every defined split domain ? | 12:27 |
| jonathanmaw | both for which packages to be staged into subdirs, and which subdirs to have `dpkg-deb --build` called in | 12:27 |
| jonathanmaw | "every defined split domain" includes the defaults | 12:27 |
| tristan | And in that case, do we have a problem inasmuchas, we are unable to remove the defaults ? | 12:28 |
| tristan | juergbi, one last thing; I heard wind of your working on documentation for this, I would like it to be an added rst file to docs/sources | 12:31 |
| tristan | probably a stand alone section in the beginning about hosting an artifact share would be good (not a moving part / wiki page / have to maintain separately kind of thing) | 12:31 |
| tristan | tlater, I'm mostly happy with your new MR | 12:32 |
| tristan | tlater, please stop making python files 0755 | 12:32 |
| tristan | and rebase | 12:32 |
| tlater | I wasn't even aware of that. I'll have to check why that happens. | 12:34 |
| tristan | :) | 12:34 |
| tristan | actually, _frontend/main.py is executable, but even that is unnecessary, not sure why I did that | 12:35 |
| tristan | or if it was me | 12:35 |
| tlater | Should I add a "Fix all permissions" commit? | 12:36 |
| tristan | tlater, sure I'm fine with that | 12:36 |
| tristan | as it'll save you time in rebasing | 12:36 |
| jonathanmaw | tristan: I'm not sure how I would go about removing the defaults in that specific case. | 12:39 |
| * jonathanmaw has a look at how the split rules are generated | 12:40 | |
| *** tlater has left #buildstream | 12:41 | |
| *** tlater has joined #buildstream | 12:41 | |
| tristan | jonathanmaw, right so... sorry I've been looking at other patches | 12:43 |
| tristan | but you have a legitimate issue | 12:43 |
| tristan | jonathanmaw, there are a couple of things to consider here, one is that with an Element.set_public() API, we should be able to explicitly manipulate the public data how we want | 12:44 |
| tristan | jonathanmaw, another thing though, is that it may be desirable to eliminate things explicitly | 12:44 |
| tlater | Just to make sure I'm doing the right thing here, should I rebase to make things neat and then --force push onto my branch? | 12:45 |
| tristan | jonathanmaw, Now one way, is to say something explicit like public-data: bst: split-rules: devel: [] | 12:45 |
| tristan | jonathanmaw, I think that should entirely wipe out the content of 'devel' for instance, which might be meaningful | 12:46 |
| jonathanmaw | ok, so override the split-rules by making them an empty dict | 12:46 |
| jonathanmaw | right, that should work | 12:46 |
| jonathanmaw | ta tristan | 12:46 |
| tristan | but it doesnt provide a YAML semantic for nuking a dict member either | 12:46 |
| tristan | jonathanmaw, I still think this is a sub-par solution to this kind of problem, so I'll see if I can come up with better maybe after sleeping on that | 12:47 |
| tristan | let me know if you have any ideas, I think ideally it would be nice to have the option of wiping out an entire dict, but the way we do dictionary compositing doesnt currently allow for something like that | 12:48 |
| tristan | jonathanmaw, maaaybe if an empty dict is specified in yaml format (I dont know, is that expressed as {} ?) then we could handle that as a case in the compositing code to allow wiping out a dict completely ? | 12:49 |
| tristan | tlater, you should rebase your local branch against fresh upstream/master, and overwrite your gitlab branch with that yes | 12:49 |
| tristan | tlater, I normally do this as `git push origin :my-branch && git push origin my-branch:my-branch` (I delete and recreate) | 12:50 |
| tristan | but I think I heard rumors about a --force option to git push | 12:50 |
| tristan | I just dont know what that does :) | 12:50 |
| tlater | Pretty sure it does just that ;) | 12:51 |
| tristan | :) | 12:53 |
| * tristan disappears for the night | 12:59 | |
| tlater | o/ | 13:00 |
| tristan | \o | 13:00 |
| jonathanmaw | o/ | 13:01 |
| *** tristan has quit IRC | 13:04 | |
| gitlab-br-bot | buildstream: merge request (tristan/source-bundle->master: Add source-bundle command) #35 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/35 | 13:12 |
| gitlab-br-bot | buildstream: merge request (tristan/source-bundle->master: Add source-bundle command) #35 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/35 | 13:15 |
| *** tristan has joined #buildstream | 13:28 | |
| *** tlater` has joined #buildstream | 14:00 | |
| *** tlater has quit IRC | 14:01 | |
| *** jude has joined #buildstream | 14:27 | |
| gitlab-br-bot | buildstream: merge request (sam/docker->master: contrib: Add Docker image for running BuildStream) #39 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/39 | 15:48 |
| gitlab-br-bot | buildstream: merge request (jonathan/dpkg-build->master: WIP: Jonathan/dpkg build) #37 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/37 | 15:49 |
| *** jonathanmaw has quit IRC | 16:20 | |
| gitlab-br-bot | buildstream: merge request (tristan/test_tests->master: WIP: Add integration tests) #40 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40 | 16:37 |
| *** tlater` has quit IRC | 16:41 | |
| *** ssam2 has quit IRC | 16:59 | |
| *** ssam2 has joined #buildstream | 17:00 | |
| *** ssam2 has quit IRC | 18:30 | |
| *** jude has quit IRC | 18:42 | |
| *** jude has joined #buildstream | 19:23 | |
| *** jude has quit IRC | 20:15 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!