IRC logs for #buildstream for Monday, 2018-01-15

*** tristan has quit IRC00:17
*** tristan has joined #buildstream03:06
*** ernestask has joined #buildstream05:50
gitlab-br-botbuildstream: merge request (show_sources->master: Added a flag to bst show) #222 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/22206:40
gitlab-br-botbuildstream: merge request (fixup_internal->master: _variables: refactor, private 'subst_internal') #150 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/15006:51
gitlab-br-botbuildstream: issue #191 ("Allow project relative workspace paths") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/19107:04
gitlab-br-botbuildstream: issue #139 ("Inconsistent error printing at load time") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/13908:02
*** valentind has joined #buildstream08:26
*** jude has joined #buildstream09:03
*** noisecell has joined #buildstream09:25
*** ernestask has quit IRC09:31
*** ssam2 has joined #buildstream09:32
tlaterAre variables supposed to expand in script element scripts?09:37
tlaterI.e., the commands in the config section09:37
tristantlater, Yes.09:38
*** jonathanmaw has joined #buildstream09:38
tristantlater, That is not to say that `bst show` would ever be able to tell you about how it would expand, though.09:38
*** ernestask has joined #buildstream09:39
tlaterDarn... Well, they aren't expanding for me atm, not sure if this could somehow be triggered by how the tests run buildstream.09:39
tristanit could be a bug09:39
tristanbut looks like `script` element calls self.node_subst_list()09:40
tristanwhich should do the subst thing09:40
tlaterHm, I'll try and confirm it outside of the test suite09:40
* tlater has a feeling it won't be a bug though09:41
tlaterAh, nevermind, I changed something about how the test suite runs that changed the way I have to specify variables...09:57
tlaterAlright, so the (hopefully) last isue before the new integration tests can go up for review is that the unix tests cannot run the base-platform, because that's an ostree source10:04
* tlater thinks this used to work because we had a lingering artifact cache10:04
tristanErr, that is strange10:04
tristantlater, I think this is working for another reason10:05
tristantlater, we currently always test on linux, and force the backend, without uninstalling ostree or such10:05
tristanso we run the unix backend but still use the ostree plugin on linux10:05
tristantlater, yes that is certainly what happens now; I often see the ostree plugin output on gitlab in the unix tests10:06
tlaterThat can't be - if that was the case, we would still be running into that10:06
tlaterI am running the tests in the same environment, just with better cache management10:06
* tlater also remembers having a discussion on how we could avoid this with same10:07
tlaterssam2:10:07
tlaters/same/ssam2/10:07
*** valentind has quit IRC10:08
tristantlater, https://gitlab.com/BuildStream/buildstream/-/jobs/4782925510:09
tristantlater, see the lines like: [--:--:--][b9c0de0c][fetch:dependencies/base-sdk.bst     ] STATUS  Receiving objects: 72% (23055/31817) 224.2 MB10:09
tristantlater, remember; the local artifact cache != the ostree source plugin10:09
tlaterRight, yeah10:10
tlaterHrm10:10
tlaterEither way, that seems like a bug - how would we run the tests without the ostree plugin?10:10
tristantlater, using a tarball hosted somewhere instead10:10
tlaterI've been thinking about including the base tarball in the main repo, but that would be 3GB just for integraiton tests10:11
tlaterWhere else could we host that?10:11
ssam2do the tests actually need to use the 3GB Freedesktop SDK ?10:11
*** tiago has joined #buildstream10:11
tristantlater, so hopefully that would be a tarball of the "tiny base runtime" which is being created in the freedesktop-sdk project10:11
tristanNo they dont, and even if it's a nice and small 300MB runtime, I dont want it in BuildStream repo10:12
ssam2of course10:12
ssam2using Docker Hub is one option10:12
ssam2or, just any web server that can serve tarballs10:12
tristanNeeds a docker source though10:12
ssam2any buildstream artifact cache server could do that, we just stick the tarballs in a tarballs/ dir and have the existing web server serve it10:13
tristan(or maybe docker does tarballs I dont know)10:13
tristanYes10:13
tlaterDo we have a public cache server that we could use for this?10:13
tristantlater, So short term: we put a tarball up on gnome710:13
ssam2oh, by the way -- i wrote up https://wiki.gnome.org/Projects/BuildStream/Infrastructure10:14
tristantlater, Long term; we later switch that to point to an officially hosted (smaller) tarball generated by freedesktop-sdk project10:14
tlaterYeah, that seems like a solution10:15
tristanssam2, nice10:15
tlaterI just need access to gnome7 then to push this tarball10:15
tristantlater, perhaps also; we use conditional statements to use ostree in the linux tests and tarballs in the unix tests10:16
tristantlater, ssam2 has access, I'd help but it wouldnt be very efficient at 350ms ping10:16
tlaterssam2: Could I ask you to create the tarball? I have a very poor connection atm as well, unfortunately10:17
tristanlooks like I fell short of the mark of restructuring the toplevel documentation into sections... wanted to do that today and get the existing docs patches out of the way...10:17
tristantomorrow then10:18
* tlater will happily make a little mini-script to do it, but would preferably run it somewhere ostree doesn't take 60 minutes10:18
tristanAhh that part10:18
ssam2tlater, what should i create a tarball of ?10:19
* tristan was under the impression tlater had a tarball in his possession10:19
* tristan suspects it will be an ostree clone, checkout, and tar10:19
ssam2ok, I can do that if you give me the repo and ref10:19
tlaterssam2: Hang on a second, I'll give you my buildstream element10:20
tlaterssam2: https://gitlab.com/BuildStream/buildstream/blob/759cd4c5a4bdb4a80b0056378f43d32cd16620a9/tests/integration/project/elements/base/base-sdk.bst10:22
* tlater wonders if we should create tarballs for multiple architectures10:22
tlaterI neglected that for now, but wanted to add it back now that the tests are running10:22
tristantlater, maybe we can punt that yeah, until freedesktop-sdk provides a nice smaller one10:22
tristantlater, that said, the smallest runtimes wont necessarily work for our tests; we may consider reducing our tests to avoid depending on such high level things like python10:24
tristansince all the build element code is the same and just different YAML defaults, seems like it would be an okay tradeoff10:25
tlaterHm, we'd miss issues with those defaults, though10:26
nexusIs there a know cause for my pipelines getting an AssertionError in runcli.py:107 ?10:26
tristanMyeah; we're not really testing much relevant stuff with them, we're more concerned that split rules and modifications made in integration commands and such work10:27
tristanthat the fuse layer is working well10:27
tristanthat the sandboxing works10:27
tristantlater, consider 'integration tests' as 'anything which requires external stuff', like running against a specific host, or needing an external runtime in order to test the core10:27
tristantlater, you're correct; that we would not be covering those defaults, but ... eh10:28
tristananyway; that is out of scope for now10:28
tristannexus, perhaps with a paste of the output10:28
tristannexus, and probably you ran it on your machine with `./setup.py test`10:28
tristanso you should be able to debug it10:29
* tristan has to head out early today10:29
nexushttps://pastebin.com/chrjz70110:30
tristannexus, so assert_main_error() failed10:32
tristannexus, to find out what that means, you would normally run something like this:10:33
tristangrep -r "assert_main_error" tests/10:33
tristannexus, that would end up leading you to where it's declared: https://gitlab.com/BuildStream/buildstream/blob/master/tests/testutils/runcli.py#L8710:34
*** tristan has quit IRC10:37
*** tristan has joined #buildstream10:42
*** mcatanzaro has joined #buildstream11:44
gitlab-br-botbuildstream: merge request (issue-181_bst_build_--track-except->master: Fix for issue #181) #228 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/22811:57
jjardon[m]Hi, looking at https://gitlab.com/freedesktop-sdk/freedesktop-sdk/merge_requests/74 : is it expected that no rebuild is needed when upgrading the bst version we use to build?12:49
gitlab-br-botbuildstream: merge request (juerg/source-state->master: source state updates) #230 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23012:50
juergbijjardon[m]: yes, as long as the project wasn't affected by the instability of cache keys for local sources12:51
jjardon[m]juergbi: rigth, thanks12:54
*** xjuan has joined #buildstream12:59
* tlater needs to build muscle memory to use tar -vcaf over tar -caf on large directories...13:15
gitlab-br-botbuildstream: merge request (monkey-patch-setuptools->master: Modify the generated CLI script by monkey patching) #231 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23113:51
gitlab-br-botbuildstream: merge request (monkey-patch-setuptools->master: Modify the generated CLI script by monkey patching) #231 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23114:00
inigomartinezi don't know if it makes any sense, but is there any way to "mount" somehow the sandbox environment?14:01
tlaterinigomartinez: Do `bst shell <element>` or `bst shell -b <element>` do what you want?14:02
inigomartinezi'm porting an application to meson and I would like to compare the tree installed by autotools with meson's installed tree14:02
bochechainigomartinez: then yes, `bst shell <element>`14:03
bochechathat starts a shell in the sandbox after the element was installed14:03
inigomartinezyes... i still haven't tried it (i'm opening a shell right now), but i think that i would have some issues that way14:05
bochechawhat you'll see is the merged filesystem, containing both what was installed for your element, as well as all the dependencies14:06
bochechawhen I want to just list the files installed by my element, I add a command at the end of the `install-commands:` list like `find %{install-root}` :P14:07
inigomartinezyes, but i suspect that i'll have a limited set of utilities to compare both trees14:07
bochechaanother possibility is `bst checkout <element> <checkout_directory>`14:08
tlaterinigomartinez: Could you use `bst checkout` to just checkout the resulting files?14:08
tlaterAh, that^14:08
bochechathat gives you the whole filesystem tree of your element and its dependencies, checked out in `<checkout_directory>`14:08
gitlab-br-botbuildstream: merge request (monkey-patch-setuptools->master: Modify the generated CLI script by monkey patching) #231 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23114:09
inigomartinezok, that is what i needed, thank you :)14:16
inigomartinezi suppose that this doesn't change on the fly with new builds, isn't it?14:16
tlaterinigomartinez: No, you'll have to check out again14:17
inigomartinezok14:18
inigomartinezwhat about accessing the host system through the sanboxed environment? is it possible?14:19
tlaterNo, that is not possible. Buildstream aims to keep builds reproducible, and therefore needs them to be completely independent from the host system.14:21
tlaterWhy would you want to do that, inigomartinez?14:23
* inigomartinez sent a long message: inigomartinez_2018-01-15_14:24:03.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/FwKOLKPpoVDvlDxnTbKHpoFf>14:24
inigomartinez(though i'm able to do the reverse procedure on the host system)14:25
tlaterWhy are you avoiding `bst checkout`? There *is* a way to do the above on just the host system, yes, but it involves poking internals.14:25
bochechatlater: `bst shell` allows getting a shell either before the build (`--build`) or after composing the built element and its dependencies... could it allow getting a shell right after the installation of the element, but while it's all still in %{install-root}?14:26
inigomartinezit's a bit slow here checking out the whole build system and I was trying to think on a faster :/14:27
inigomartinez*faster alternative14:27
tlaterAh, yeah, I understand that... You can find the artifacts in ~/.cache/buildstream/artifacts before you check them out, but iirc they are still in an ostree repo, which means you have to check them out anyway.14:29
tlaterTo do the mounty thing without mounting, you can access the sysroot that the shell is launched in in ~/.cache/buildstream/build/14:29
tlaterBut this is obviously all reliant on buildstream internals, so may change any time, or be quite unstable.14:30
tlaterbochecha: I don't think so, unfortunately - the fastest way to do this probably is poking around in ~/.cache/buildstream/build14:31
inigomartinezthe `~/.cache/` alternative looks like a nice alternative at the moment14:31
inigomartinezthx again :)14:31
gitlab-br-botbuildstream: merge request (delay-pkg-resources-import->master: Delay import of pkg_resources) #232 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23214:34
jonathanmawtristan: I don't quite understand the new test scenario in https://gitlab.com/BuildStream/buildstream/merge_requests/181. I'm not sure what ordering you're expecting, but I think it's A above B above C, and you want to be sure that, even when overlaps aren't triggered by an element building that depends on something it overlaps with (i.e. A and B)15:07
jonathanmawDoes it matter whether the dependency is build or runtime?15:09
gitlab-br-botbuildstream: merge request (incremental-build->master: WIP: Add support for doing incremental builds) #126 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/12615:09
gitlab-br-botbuildstream: merge request (incremental-build->master: WIP: Add support for doing incremental builds) #126 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/12615:10
gitlab-br-botbuildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23315:13
gitlab-br-botbuildstream: merge request (version-read-no-pkg_res->master: Get version number w/o pkg_resources) #234 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23415:27
gitlab-br-botbuildstream: merge request (version-read-no-pkg_res->master: Get version number w/o pkg_resources) #234 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23415:27
gitlab-br-botbuildstream: merge request (sam/improve-cache-warnings->master: Shorten the warnings raised when remote cache initialization fails) #235 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23515:28
ssam2jmac, https://gitlab.com/BuildStream/buildstream-tests/commit/d275b2d57c481316a24fa4cf30df38536b7211b615:31
jmacGreat, thanks ssam2!15:31
gitlab-br-botbuildstream: merge request (version-read-no-pkg_res->master: Get version number w/o pkg_resources) #234 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23415:47
gitlab-br-botbuildstream: merge request (modAndTest->master: Making changes to various documents:) #206 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/20616:00
gitlab-br-botbuildstream: merge request (master->master: WIP: Documentation improvements) #183 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/18316:02
gitlab-br-botbuildstream: merge request (postbuild->master: Added Postbuild documentation) #236 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23616:14
gitlab-br-botbuildstream: merge request (createProject->master: Adding create project document) #237 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23716:16
gitlab-br-botbuildstream: merge request (buildproject->master: Added buildproject doc) #238 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23816:19
gitlab-br-botbuildstream: merge request (version-read-no-pkg_res->master: Get version number w/o pkg_resources) #234 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23417:55
*** ssam2 has quit IRC17:55
gitlab-br-botbuildstream: merge request (juerg/recursive-pipelines->master: WIP: Junctions and subprojects) #160 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/16017:57
*** ernestask has quit IRC18:13
*** jonathanmaw has quit IRC18:24
*** valentind has joined #buildstream18:27
*** ironfoot_ has joined #buildstream18:29
*** noisecell has quit IRC18:29
*** cs_shadow has quit IRC18:29
*** csoriano has quit IRC18:29
*** saxa has quit IRC18:29
*** ptomato[m] has quit IRC18:29
*** waltervargas[m] has quit IRC18:29
*** ernestask[m] has quit IRC18:29
*** m_22[m] has quit IRC18:29
*** pro[m] has quit IRC18:29
*** mrmcq2u[m] has quit IRC18:29
*** cgmcintyre[m] has quit IRC18:29
*** mattiasb has quit IRC18:29
*** kailueke[m] has quit IRC18:29
*** ironfoot has quit IRC18:29
*** jjardon[m] has quit IRC18:29
*** bochecha has quit IRC18:29
*** xjuan has quit IRC18:29
*** mcatanzaro has quit IRC18:29
*** tristan has quit IRC18:29
*** tiago has quit IRC18:29
*** jude has quit IRC18:29
*** adds68__ has quit IRC18:29
*** paulsherwood has quit IRC18:29
*** nexus has quit IRC18:29
*** tlater has quit IRC18:29
*** gitlab-br-bot has quit IRC18:29
*** lantw44 has quit IRC18:29
*** saxa has joined #buildstream18:29
*** noisecell has joined #buildstream18:30
*** csoriano has joined #buildstream18:30
*** xjuan has joined #buildstream18:30
*** mcatanzaro has joined #buildstream18:30
*** tristan has joined #buildstream18:30
*** tiago has joined #buildstream18:30
*** jude has joined #buildstream18:30
*** adds68__ has joined #buildstream18:30
*** paulsherwood has joined #buildstream18:30
*** nexus has joined #buildstream18:30
*** tlater has joined #buildstream18:30
*** gitlab-br-bot has joined #buildstream18:30
*** lantw44 has joined #buildstream18:30
*** cs_shadow has joined #buildstream18:30
*** saxa has quit IRC18:32
gitlab-br-botbuildstream: merge request (juerg/recursive-pipelines->master: WIP: Junctions and subprojects) #160 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/16018:35
*** mattiasb has joined #buildstream18:46
*** bochecha has joined #buildstream19:13
*** xjuan has quit IRC20:14
*** waltervargas[m] has joined #buildstream20:33
*** ptomato[m] has joined #buildstream21:14
*** noisecell has quit IRC21:44
*** pro[m] has joined #buildstream21:59
*** mrmcq2u[m] has joined #buildstream22:00
*** jjardon[m] has joined #buildstream22:15
*** kailueke[m] has joined #buildstream22:43
*** cgmcintyre[m] has joined #buildstream22:54
*** ernestask[m] has joined #buildstream23:09
*** ernestask[m] is now known as Guest5673323:09
*** m_22[m] has joined #buildstream23:45

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!