| *** ChanServ sets mode: +o tristan | 01:14 | |
| *** tristan has quit IRC | 01:28 | |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: plugin.py: Add note on plugin extension support) https://gitlab.com/BuildStream/buildstream/commit/4813c828b77233b83442662353c7ad0498f408b2 | 02:10 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (64-clarify-about-plugins-importing-other-plugins->master: plugin.py: Add note on plugin extension support) #92 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/92 | 02:11 |
| gitlab-br-bot | buildstream: issue #64 ("Clarify about plugins importing other plugins") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/64 | 02:12 |
| *** tristan has joined #buildstream | 02:13 | |
| *** ChanServ sets mode: +o tristan | 02:13 | |
| *** tristan has quit IRC | 05:42 | |
| *** tristan has joined #buildstream | 06:12 | |
| *** bochecha has joined #buildstream | 06:18 | |
| *** bochecha_ has joined #buildstream | 06:52 | |
| *** bochecha has quit IRC | 06:54 | |
| gitlab-br-bot | buildstream: merge request (artifacts-config->master: Artifacts config) #88 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/88 | 07:34 |
| *** jonathanmaw has joined #buildstream | 08:17 | |
| *** tlater has joined #buildstream | 08:31 | |
| gitlab-br-bot | push on buildstream@cross_platform (by Tristan Maat): 9 commits (last: _sandboxchroot.py: Implement sandboxchroot) https://gitlab.com/BuildStream/buildstream/commit/fe5a84fbeeccd693080d3c412d9d77fcc1e751a5 | 08:48 |
| gitlab-br-bot | buildstream: merge request (cross_platform->master: WIP: Cross platform) #81 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/81 | 08:49 |
| *** ssam2 has joined #buildstream | 09:15 | |
| gitlab-br-bot | push on buildstream@cross_platform (by Tristan Maat): 8 commits (last: Add platform factories) https://gitlab.com/BuildStream/buildstream/commit/585f0582dec12bb7fee366fad2d51def9cbe59f7 | 09:27 |
| gitlab-br-bot | buildstream: merge request (cross_platform->master: WIP: Cross platform) #81 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/81 | 09:28 |
| gitlab-br-bot | buildstream: merge request (artifacts-config->master: Artifacts config) #88 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/88 | 09:36 |
| gitlab-br-bot | buildstream: merge request (artifacts-config->master: Artifacts config) #88 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/88 | 09:45 |
| *** laurenceurhegyi has quit IRC | 09:53 | |
| gitlab-br-bot | push on buildstream@cross_platform (by Tristan Maat): 8 commits (last: Add platform factories) https://gitlab.com/BuildStream/buildstream/commit/7e19d6a33443348596594195ad44b59f9d073be7 | 09:53 |
| gitlab-br-bot | buildstream: merge request (cross_platform->master: WIP: Cross platform) #81 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/81 | 09:53 |
| *** adds68 has quit IRC | 09:54 | |
| *** adds68 has joined #buildstream | 10:00 | |
| gitlab-br-bot | buildstream: merge request (artifacts-config->master: Artifacts config) #88 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/88 | 10:01 |
| gitlab-br-bot | push on buildstream@cross_platform (by Tristan Maat): 1 commit (last: .gitlab-ci.yml: Add fallback tests to CI) https://gitlab.com/BuildStream/buildstream/commit/26aeaa24940298432fcf9a0192965b1542949f72 | 10:01 |
| gitlab-br-bot | buildstream: merge request (cross_platform->master: WIP: Cross platform) #81 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/81 | 10:02 |
| bochecha_ | ssam2: any reason the base docker image for tests (which you seem to provide) doesn't already have the deps in it? (the ones installed with dnf for each test run) | 10:04 |
| tlater | bochecha_: Mainly that it's not exclusively intended for tests - though this is a discussion tristan has wanted to bring up. | 10:05 |
| ssam2 | bochecha_, which tests are you referring to? | 10:05 |
| bochecha_ | ssam2: in https://gitlab.com/BuildStream/buildstream/blob/master/.gitlab-ci.yml, the `dnf install` lines | 10:06 |
| bochecha_ | tlater: oh, the images are used for something else? I see | 10:06 |
| ssam2 | ah yes | 10:06 |
| *** laurenceurhegyi has joined #buildstream | 10:06 | |
| ssam2 | yeah the idea of those Docker image is that you can do "docker pull buildstream/buildstream" and have an environment to *use* buildstream | 10:07 |
| ssam2 | installing extra stuff to speed up tests would be fine provided it doesn't make the docker container huge though | 10:07 |
| ssam2 | certainly `which` and `patch` could be added | 10:08 |
| gitlab-br-bot | push on buildstream@cross_platform (by Tristan Maat): 1 commit (last: .gitlab-ci.yml: Add fallback tests to CI) https://gitlab.com/BuildStream/buildstream/commit/839b5b4a52ce0970526682ae75acf922c8f39d49 | 10:10 |
| gitlab-br-bot | buildstream: merge request (cross_platform->master: WIP: Cross platform) #81 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/81 | 10:10 |
| gitlab-br-bot | push on buildstream@cross_platform (by Tristan Maat): 1 commit (last: _sandboxchroot.py: Fix missing mknod directory) https://gitlab.com/BuildStream/buildstream/commit/58ff9921770fab7a6795c69ddcfda472d5c8d0f2 | 10:29 |
| gitlab-br-bot | buildstream: merge request (cross_platform->master: WIP: Cross platform) #81 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/81 | 10:30 |
| gitlab-br-bot | push on buildstream@cross_platform (by Tristan Maat): 9 commits (last: _sandboxchroot.py: Implement sandboxchroot) https://gitlab.com/BuildStream/buildstream/commit/9af9b129db526afa8059ef886c1ea45c2a18c969 | 10:30 |
| gitlab-br-bot | buildstream: merge request (cross_platform->master: WIP: Cross platform) #81 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/81 | 10:31 |
| gitlab-br-bot | push on buildstream@cross_platform (by Tristan Maat): 9 commits (last: _sandboxchroot.py: Implement sandboxchroot) https://gitlab.com/BuildStream/buildstream/commit/0b7fb0c3172f55d10b6e7eebe995b1491d3a1d83 | 10:45 |
| gitlab-br-bot | buildstream: merge request (cross_platform->master: WIP: Cross platform) #81 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/81 | 10:46 |
| *** tristan has quit IRC | 11:15 | |
| *** tristan has joined #buildstream | 11:24 | |
| tristan | ssam2, I'm confused by this docker on gitlab thing to be honest | 11:29 |
| tristan | ssam2, are we using the same image that we have in our docs for "using buildstream with docker", on gitlab, and thats why we have that on gitlab ? | 11:29 |
| tristan | I thought we were referring to a specific, prebuilt "samthursfield" docker image that only needed to be downloaded | 11:30 |
| tristan | maybe that is generated from the same thing | 11:30 |
| ssam2 | there's only one Docker image | 11:42 |
| ssam2 | the one hosted on my "samthursfield" personal account on dockerhub was temporary, I moved it to https://hub.docker.com/r/buildstream/buildstream-fedora/ | 11:43 |
| ssam2 | we could do one docker image for users and for gitlab, it might make sense actually | 11:43 |
| ssam2 | *and one for gitlab | 11:43 |
| tlater | tristan: The documentation only talks about building that image - perhaps those instructions should be updated, given there's an "official" pre-built image now. | 11:44 |
| ssam2 | true. although i would like to make it so the prebuild image was built automatically | 11:45 |
| ssam2 | to do that I think it's best to move it out of buildstream.git into its own repo | 11:45 |
| ssam2 | we can't add a "build docker image" step to buildstream.git because the gitlab-ci pipeline already uses docker, and docker-in-docker is... a mess | 11:46 |
| ssam2 | but with a separate repo we could have a pipeline that doesn't use docker, and thus could run "docker build" on each new commit | 11:46 |
| ssam2 | and push straight to dockerhub if we gave it the right keys | 11:46 |
| tlater | ssam2: What about using gitlab's docker repo? | 11:46 |
| ssam2 | for hosting? we could, but I don't think that solves anything | 11:46 |
| ssam2 | as I understand it a docker repo can only hold *already build* docker images, and it's the building that is the tricky part | 11:47 |
| ssam2 | *already built | 11:47 |
| tlater | Hmm... Could the pipeline be: build image -> run tests/integration -> publish? | 11:47 |
| tlater | No, you're right | 11:48 |
| tlater | Unless there is a way to share images as an artifact, but that would probably be messy. | 11:49 |
| ssam2 | actually, removing `docker build` from the process altogether and adding a "docker" 'build' plugin to BuildStream would be great | 11:50 |
| ssam2 | pushing it from inside a docker container might still be tricky though | 11:50 |
| ssam2 | if there's a tool that can speak to Docker hub that doesn't require talking to a root-priviliged daemon then it would be fine | 11:51 |
| ssam2 | hmm, such as https://github.com/shaded-enmity/docker-tar-push | 11:52 |
| ssam2 | so all possible, but probably a week's worth of work if we're honest | 11:52 |
| * tristan reappears | 11:56 | |
| tristan | Mkay | 11:57 |
| tristan | So | 11:57 |
| tristan | The idea of putting the docker support in another repo is fine... | 11:57 |
| tristan | But I wonder; is there a way that we can revision the built images in this docker repo ? | 11:58 |
| tristan | I feel like it would be a good idea to gate changes to the latest image build in .gitlab-ci.yml, on running the tests themselves | 11:58 |
| tristan | Then we can tell when a new docker build is what caused tests to break right away | 11:59 |
| ssam2 | that should be possible | 11:59 |
| ssam2 | we could build the image, run the tests in it, and push after they succeed | 11:59 |
| tristan | Also, upgrading things is also error prone, note that I've been removing the --upgrade lines from `pip install` | 11:59 |
| tristan | Cause that always breaks when A.) psutils is updated and B.) the docker image has no gcc to build the C code that comes with that python upgrade | 12:00 |
| tristan | ssam2, thats not the same though, while it ensures that we never push a new docker image that breaks with that day's buildstream master, it doesnt ensure that buildstream master's test cases always run against exactly the same image; until we explicitly commit a new .gitlab-ci.yml to build against a fresher one | 12:01 |
| tristan | Although it's still a bit better than now :) | 12:02 |
| ssam2 | a docker repo can hold multiple versions of an image | 12:02 |
| ssam2 | notice in https://hub.docker.com/r/buildstream/buildstream-fedora/ i tagged the image with the date i built it | 12:02 |
| ssam2 | so you'll be able to `docker pull buildstream/buildstream-fedora:0.1-20170825` forever and get the same thing | 12:03 |
| ssam2 | i also tagged with 'latest', so that `docker pull buildstream/buildstream-fedora:latest` works and (assuming we always correctly tag new images with 'latest') it'll always pull whatever is newest | 12:03 |
| tristan | Ah that's nice, so we do have the option | 12:04 |
| tristan | Your other approach is not without it's merits though, I guess it would mean that need not add commits to upgrade the image, and the times that something fails; we might be confused but manually provoking a failed pipeline might "work this time" | 12:06 |
| tristan | The downside with the manual approach is we have to remember to do it | 12:06 |
| * tristan supposes that could be automated with a weekly cron job which submits a merge requests for the latest docker image update, automatically triggering a build and letting us click "yes" or "no" | 12:08 | |
| tristan | ah right, it was 'all-gcc' and 'configure-target-gcc', here https://github.com/flatpak/freedesktop-sdk-base/blob/1.6/meta-freedesktop/recipes-devtools/gcc/gcc-cross-initial_%25.bbappend | 12:19 |
| tristan | whoops wrong window :) | 12:19 |
| tristan | anyway | 12:20 |
| tlater | tristan: GitLab has scheduled builds - even ones where you are asked to click 'deploy' to confirm | 12:34 |
| * tristan forgot his adaptor at home and anyway timing is good to go home... | 14:03 | |
| tristan | If I dont find another solution for these option conditionals... | 14:03 |
| tristan | I'll explore a bit what we can do with pure YAML | 14:03 |
| ssam2 | to be clear, i don't dislike the s-expression approach enough to want to block it | 14:04 |
| ssam2 | i just think it may turn out to be a bad choice in 2 years time | 14:04 |
| *** tristan has quit IRC | 14:06 | |
| *** tristan has joined #buildstream | 14:09 | |
| * tristan reappears from home | 14:10 | |
| tristan | ssam2, honestly the reason why I lean towards something more data-ish than cute-code-ish, is the same (long term I cant predict what will happen, I only know that my options are reduced by using a stronger, more defined format) | 14:11 |
| ssam2 | fair. i predict that what will happen is it'll eventually grow to encompass most of the functionality that jinja2 can already provide | 14:13 |
| ssam2 | but that is just a prediction, and you're in a better place to know what things you will and won't allow into the language in future | 14:14 |
| tristan | So to cover the bases, in that case at least we control what is added and why, and if we really end up implementing many keywords to rival functionality of jinja2, it's not really a dangerous or regrettable thing | 14:17 |
| ssam2 | well true, it's not the end of the world and I guess it could be spun out to provide the library that we wish existed now :-) | 14:18 |
| ssam2 | i agree it would be nicer if jinja2 had a formal spec we could reference; although i'm pretty confident it won't change though as there are millions of website templates and ansible scripts already depending on that syntax | 14:19 |
| tristan | I dont know, I mean; S expressions already exist; and using them to perform comparisons is a piece of cake; does it merit it's own library ? or is it safe to say that different applications will have different needs ? | 14:20 |
| ssam2 | if we're just doing comparisons then no | 14:20 |
| tristan | I think what we really wish existed, is something that lets us be free with defining what we support, like S Expressions, but that looks more like what a programmer wants | 14:20 |
| tristan | the more I turn this around in my head I think it's mostly a matter of taste, and it seems to me absurd to make a practical decision based on taste | 14:21 |
| tristan | but then, maybe we need a marketing department to convince me otherwise :-/ | 14:22 |
| ssam2 | there's two questions I think | 14:22 |
| ssam2 | one is the syntax, and that is down to taste really | 14:22 |
| ssam2 | i'm sure some people will go "Oh cool! S-Expressions!" | 14:23 |
| ssam2 | the other question is whether we need to formally specify and implement everything ourselves | 14:23 |
| ssam2 | i mean, as a strawman argument, how about allowing a limited subset of GNU Guile for conditionals ? | 14:23 |
| tristan | So for the latter, you are presenting it as a question of whether we *need* to do that, and I am perceiving it as; whether it's going to be safe to *not* do that | 14:24 |
| ssam2 | right | 14:24 |
| ssam2 | what things can go wrong? | 14:25 |
| tristan | right so guile is more like the jinja2 thing | 14:25 |
| tristan | So, what can go wrong is an expensive question; a cheaper angle is: Assuming the that murphy's law is as true as usual, something will go wrong; and if we are the ones who define it; we can address that; if we dent even control the format; we're kind of stuck | 14:28 |
| tristan | My crappy example on the list was about case sensitivity (which is another point we should decide on, whether option names are case sensitive, probably not I guess) | 14:29 |
| ssam2 | i can't really argue with Murphy's law :-) | 14:29 |
| tristan | Assuming case insensitivity as the winner, I assume that jinja2 will have its own; personal opinion about "FOO" == "foo" | 14:29 |
| tristan | An opinion we might not share | 14:29 |
| tristan | Or we might | 14:29 |
| tristan | I dont know | 14:29 |
| ssam2 | it tries to imitate python, so == is case sensitive | 14:30 |
| tristan | So that is something we should be deciding | 14:30 |
| tristan | Working around that by asking the user to use our special little: tolower(foo) == "foo" helper, is not very nice | 14:31 |
| tristan | in the case where we disagree with the chosen already written parser (whatever it is) | 14:31 |
| ssam2 | my only real datapoint is that Ansible has been using Jinja2 for conditionals for 5 years already, and clearly haven't hit too many issues with it | 14:34 |
| ssam2 | but, I think i've made all the points I have to make | 14:35 |
| ssam2 | i trust you'll make something workable, even if it's not quite what i would have made ;-) | 14:35 |
| ssam2 | and we can always do buildstream 2.0 with a fancier syntax; i think that question can be punted more easily than "do we wholesale reuse someone else's DSL" | 14:36 |
| tristan | Right, the hard calls | 14:39 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 5 commits (last: Simplify a bit of code) https://gitlab.com/BuildStream/buildstream/commit/f40ae33b52197241880d7e6399bfd0e28c4ee468 | 14:57 |
| gitlab-br-bot | buildstream: issue #87 ("Projects should have a say in their artifact caches") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/87 | 14:57 |
| gitlab-br-bot | buildstream: issue #87 ("Projects should have a say in their artifact caches") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/87 | 14:57 |
| gitlab-br-bot | buildstream: merge request (artifacts-config->master: Artifacts config) #88 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/88 | 14:57 |
| *** jonathanmaw has quit IRC | 14:58 | |
| *** jonathanmaw has joined #buildstream | 14:58 | |
| tristan | bochecha_, alright merged ! I wonder when pytest.param() was added to pytest though, my installed pytest blew up without that (could be nice to depend on the version of pytest that provides it ;-)) | 14:59 |
| tristan | bochecha_, I added you as developer to gitlab group by the way, it means you can push to non-protected branches you create (which can save you time in annoying rebases from a separate repo) | 15:00 |
| *** bochecha_ has quit IRC | 15:03 | |
| *** bochecha_ has joined #buildstream | 15:04 | |
| *** bochecha_ has quit IRC | 15:08 | |
| *** bochecha_ has joined #buildstream | 15:08 | |
| bochecha_ | tristan: yay, thanks for the review, and for being patient as I discover the code :) | 15:18 |
| bochecha_ | tristan: I'll see if I can find what version of pytest added pytest.param, and send a MR for that, sorry I missed it | 15:19 |
| tristan | bochecha_, meh you couldnt have known | 15:21 |
| tristan | I chased it down a bit but fell flat on my face | 15:22 |
| tristan | bochecha_, note: https://github.com/pytest-dev/pytest/issues/2658 ... pytest.param() is undocumented so... I suspect one might have to crawl through a git repo to find out :-/ | 15:22 |
| tristan | dont be burdened by it, obviously finding the right version is something we'll want, though | 15:23 |
| bochecha_ | weird, I found it in the documentation :-/ | 15:23 |
| tristan | you found an example I think | 15:23 |
| tristan | maybe this: https://docs.pytest.org/en/latest/example/parametrize.html | 15:23 |
| bochecha_ | I didn't know about pytest.param until this morning, in fact, when I was searching for something else in the pytest docs (which I never found, in fact) :) | 15:23 |
| bochecha_ | yes, that's the page | 15:24 |
| tristan | but no hyperlink or reference to the API reference where I would think a "Since version" might appear :) | 15:24 |
| bochecha_ | ah right, yeah, the api doc reference doesn't have pytest.param | 15:24 |
| bochecha_ | they aren't great at documenting things, especially the "Since version X" stuff :( | 15:24 |
| bochecha_ | anyway, I have to go now | 15:24 |
| bochecha_ | have a good evening | 15:24 |
| tristan | nah I'm untrusting of python libs yeah | 15:24 |
| tristan | Ok have fun ! | 15:25 |
| *** bochecha_ has quit IRC | 15:25 | |
| *** bochecha_ has joined #buildstream | 15:44 | |
| gitlab-br-bot | push on buildstream@cross_platform (by Tristan Maat): 12 commits (last: sandbox.py: Add sandbox RO state) https://gitlab.com/BuildStream/buildstream/commit/d4e451fd587430566ff3d8801de64170497db6c5 | 16:16 |
| gitlab-br-bot | buildstream: merge request (cross_platform->master: WIP: Cross platform) #81 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/81 | 16:17 |
| bochecha_ | tristan: which pytest did you have, which didn't work with pytest.param ? | 16:35 |
| bochecha_ | tristan: seems it was introduced in 3.1.0 https://github.com/pytest-dev/pytest/blob/master/CHANGELOG.rst#310-2017-05-22 | 16:35 |
| bochecha_ | did you have something older? | 16:35 |
| *** bochecha_ has quit IRC | 16:41 | |
| tristan | yeah, I certainly had something older than May 2017, thats brand spanking new | 16:54 |
| *** bochecha_ has joined #buildstream | 17:03 | |
| *** jonathanmaw has quit IRC | 17:04 | |
| *** tlater has quit IRC | 17:08 | |
| *** ssam2 has quit IRC | 17:09 | |
| *** bochecha_ has quit IRC | 18:23 | |
| *** tristan has quit IRC | 22:19 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!