| *** tiagogomes has quit IRC | 01:42 | |
| *** tristan has quit IRC | 04:34 | |
| *** tristan has joined #buildstream | 04:59 | |
| *** tristan has quit IRC | 06:14 | |
| *** jonathanmaw has joined #buildstream | 08:17 | |
| *** tlater has joined #buildstream | 08:23 | |
| *** tiagogomes has joined #buildstream | 08:56 | |
| *** tristan has joined #buildstream | 09:12 | |
| *** ChanServ sets mode: +o tristan | 09:12 | |
| 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 | 09:14 |
|---|---|---|
| jonathanmaw | morning tristan, I found a slightly easier solution to my problem of pulling in default split-rules | 09:16 |
| jonathanmaw | which was to add a use_default_splits member to Element which decides whether to merge default splits and element splits at all | 09:16 |
| tristan | jonathanmaw, I'm skeptical about that approach, because it's a special case for split rules | 09:17 |
| tristan | I see this as a more general problem in our dictionary compositing logic | 09:17 |
| tristan | If for example, you can express an empty dictionary in YAML, then the core could recognize an explicitly empty dict as an indication, when compositing, that the entire dict should be wiped | 09:18 |
| tristan | that might be a better approach, and provide a semantic for any such case which arises | 09:18 |
| jonathanmaw | tristan: I had to deal with the problem that I needed to know which split-rules were part of the defaults to override them with empty dicts in the first place. And if I knew that, I'd be able to exclude them when I was using the split-rules as a list of packages, in the first place. | 09:19 |
| gitlab-br-bot | buildstream: merge request (artifact-share->master: Artifact Cache Sharing) #38 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/38 | 09:20 |
| tristan | jonathanmaw, I think this problem does not really apply to your use case, because you will be using an Element.set_public() API anyway | 09:21 |
| tristan | so you will have the final say, and can programatically decide | 09:21 |
| tristan | jonathanmaw, but in the general sense, for trying to remove existing stuff just via YAML expressions, I think a more appropriate solution might be to handle empty dicts, or explicitly set None values | 09:21 |
| tristan | somewhere around here: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_yaml.py#L448 | 09:22 |
| *** ssam2 has joined #buildstream | 09:26 | |
| jonathanmaw | tristan: ok. for my use case, I'll revert the use_default_splits when the public data changes have landed and rework to use set_public(). | 09:26 |
| *** ssam2 has quit IRC | 09:34 | |
| *** ssam2 has joined #buildstream | 09:34 | |
| 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 | 10:11 |
| gitlab-br-bot | buildstream: merge request (sam/docker->master: Update Dockerfile to add latest OSTreee) #39 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/39 | 10:13 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 19 commits (last: element.py: Allow forceful reinterrogation of cached state) https://gitlab.com/BuildStream/buildstream/commit/36a26fbfcfb0184597aef86436cd1c22b86e15e3 | 10:20 |
| gitlab-br-bot | buildstream: merge request (artifact-share->master: Artifact Cache Sharing) #38 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/38 | 10:20 |
| gitlab-br-bot | buildstream: merge request (sam/docker->master: Update Dockerfile to add latest OSTree) #39 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/39 | 10:43 |
| tlater | What commands are available to a sandbox element? `mkdir -p` returns 1, for example. | 11:17 |
| ssam2 | it depends what is in the sandbox | 11:17 |
| tlater | *script element | 11:17 |
| ssam2 | the script runs in the sandbox, so it depends entirely on what stuff is pulled in by dependencies | 11:18 |
| tlater | Do I need to build basic linux commands before I can test it then? | 11:18 |
| ssam2 | yes | 11:18 |
| ssam2 | or pull host tools from somewhere | 11:18 |
| tlater | Alright, that should work. | 11:18 |
| *** tiagogomes has quit IRC | 11:33 | |
| *** tiagogomes has joined #buildstream | 11:34 | |
| *** jude has joined #buildstream | 12:25 | |
| tlater | "Only build type dependencies supported by script elements" | 12:28 |
| tlater | That seems a bit odd considering we need a base system to run them. | 12:29 |
| ssam2 | build & run semantics are a bit complex | 12:30 |
| ssam2 | but 'script' elements only run at build time | 12:30 |
| ssam2 | runtime dependencies are what an element needs after the build completes, e.g. GIMP runtime-depends on GTK | 12:31 |
| tlater | Can I not run a script element immediately after importing just a base platform? | 12:33 |
| tlater | *"build" | 12:33 |
| ssam2 | yeah | 12:34 |
| ssam2 | but that's still counted as "build time" | 12:35 |
| ssam2 | if it happens inside BuildStream, it's "build time" | 12:35 |
| tlater | Well, that's what gives me the error. "Building" a script element after only having a base system fails. | 12:35 |
| ssam2 | ah, OK | 12:35 |
| ssam2 | i think that should work | 12:35 |
| ssam2 | i certainly have script elements with only 'build' dependencies that go fine | 12:36 |
| tlater | Hm. Do I *need* to specify a layout? Or should a command like "echo 'test' > /test" just run? | 12:36 |
| ssam2 | if you don't specify a layout I think everything gets installed in / | 12:36 |
| ssam2 | do you have PATH set anywhere ? | 12:37 |
| tlater | No, but it fails before the script ever runs | 12:37 |
| tlater | Error loading pipeline: script element at script-test.bst [line 1 column 0]: Only build type dependencies supported by script elements | 12:37 |
| ssam2 | oh, right | 12:37 |
| ssam2 | let me come and have a look | 12:37 |
| *** xjuan has joined #buildstream | 13:20 | |
| gitlab-br-bot | buildstream: merge request (script-documentation->master: script.py: Add detail to script element documentation) #41 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41 | 14:18 |
| gitlab-br-bot | buildstream: merge request (script-documentation->master: script.py: Add detail to script element documentation) #41 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41 | 14:22 |
| *** tlater has quit IRC | 14:52 | |
| *** tlater has joined #buildstream | 14:56 | |
| tlater | Are there any examples of using a tarball source? The one in the documentation doesn't work. | 16:05 |
| tlater | Or has this not been implemented yet? | 16:05 |
| ssam2 | i've successfully used a tarball sourcve | 16:05 |
| ssam2 | *source | 16:05 |
| ssam2 | what problem are you having ? | 16:05 |
| tlater | No Source type registered for kind 'tarball' | 16:06 |
| tlater | When trying to build amhello | 16:06 |
| tlater | for a simple autotools test | 16:06 |
| ssam2 | ah, it's called 'tar' not 'tarball' | 16:07 |
| ssam2 | so I guess whatever example you're following is wrong | 16:07 |
| tlater | Heh, the documentation says tarball | 16:07 |
| ssam2 | another docs issue :-) | 16:07 |
| tlater | There's no way to get a relative url to this dir, is there? | 16:08 |
| tlater | Hmm... | 16:08 |
| ssam2 | no, i think you have to use a full file:/// URL | 16:09 |
| ssam2 | maybe you could do some clever trick with variable substitution if it makes things neater | 16:09 |
| tlater | I think I'll have to just sed | 16:10 |
| tlater | Because I really don't know from where people will be running these tests. | 16:10 |
| tlater | Would it be better to have a main script that can run individual tests or individual tests that can either be run from sub-directories or a main script that runs all of them? | 16:17 |
| ssam2 | we'll want to be able to run all tests (for full testing), or a single test (for debugging test failures) | 16:19 |
| tlater | Both ways allow that. | 16:19 |
| ssam2 | then I have no preference :-) | 16:19 |
| ssam2 | you could perhaps use http://testanything.org/ and something like https://pypi.python.org/pypi/tap.py ... but that might well be overkill for now | 16:20 |
| ssam2 | oh https://pypi.python.org/pypi/tap.py is not the thing at all | 16:21 |
| tlater | I guess I should prioritize getting a lot of tests down. Otherwise we wouldn't be rolling our own test scripts. | 16:21 |
| tlater | Which means I should keep things as they are for now. | 16:21 |
| tlater | x) | 16:22 |
| ssam2 | yeah, for now as long as it works, I think it's fine | 16:22 |
| ssam2 | https://avocado-framework.github.io/ looks pretty nice, for when we want to get cleverer with this | 16:22 |
| tlater | This might eventually be necessary. I'm copying a lot of bash scripts here... After some more refactoring it might be better, but probably still not ideal. | 16:23 |
| tlater | It's also hard to catch errors unrelated to the tests atm, because the scripts use exit codes for certain things. | 16:24 |
| tlater | So `set -e` doesn't work. | 16:24 |
| tlater | Oh, darn, I have to go. Got my exam results today, so a dinner with friends who are graduating :D | 16:29 |
| tlater | o/ | 16:30 |
| ssam2 | fair play. Enjoy the dinner! | 16:30 |
| *** tlater has quit IRC | 16:30 | |
| *** jude has quit IRC | 16:57 | |
| *** jonathanmaw has quit IRC | 17:16 | |
| *** ssam2 has quit IRC | 18:01 | |
| *** jude has joined #buildstream | 18:23 | |
| *** xjuan has quit IRC | 19:20 | |
| *** xjuan has joined #buildstream | 19:29 | |
| *** jude has quit IRC | 19:53 | |
| *** jude has joined #buildstream | 20:08 | |
| *** xjuan has quit IRC | 23:19 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!