| *** slaf has quit IRC | 00:02 | |
| *** Prince781 has quit IRC | 00:06 | |
| *** slaf has joined #buildstream | 00:25 | |
| *** Prince781 has joined #buildstream | 00:43 | |
| *** mcatanzaro has quit IRC | 02:27 | |
| *** Prince781 has quit IRC | 04:02 | |
| *** tm has joined #buildstream | 07:32 | |
| *** tristan has joined #buildstream | 08:09 | |
| *** Prince781 has joined #buildstream | 08:19 | |
| *** toscalix has joined #buildstream | 08:52 | |
| *** dominic has joined #buildstream | 09:33 | |
| *** jonathanmaw has joined #buildstream | 09:48 | |
| *** ssam2 has joined #buildstream | 10:00 | |
| *** Prince781 has quit IRC | 10:10 | |
| gitlab-br-bot | buildstream: issue #266 ("`get_unique_key()` only works with an incorrectly initialised dictionary") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/266 | 10:12 |
|---|---|---|
| *** ernestask has joined #buildstream | 10:12 | |
| *** aday has joined #buildstream | 10:37 | |
| ssam2 | should integration-commands propagate across junction boundries ? | 10:42 |
| tristan | Yes, is there a reason to think they should not ? | 10:44 |
| ssam2 | no, i'm seeing some not being run | 10:45 |
| * tristan thinks we should really finally split up integration-commands in two | 10:45 | |
| ssam2 | so wondering what is going wrong | 10:45 |
| tristan | It could be a bug, or, it could be lost in build-only deps | 10:46 |
| tristan | build-only dep separation will of course lose anything prior | 10:46 |
| ssam2 | ah, that's possible. right, so they won't propagate across compose elements | 10:46 |
| tristan | right | 10:46 |
| ssam2 | which actually makes sense too.. the results of the integration should be in the compose | 10:46 |
| tristan | they wouldnt | 10:46 |
| tristan | if compose opted to include the result, yeah | 10:46 |
| tristan | (I think that's default, though) | 10:47 |
| ssam2 | I'm currenlty digging into (separate) issue with files seemingly being lost during compose | 10:47 |
| ssam2 | I wonder if this is actually the same thing | 10:47 |
| ssam2 | actually, I think this isn't a bug, it's a directory overwriting a symlink | 10:56 |
| tristan | That area can get really confusing | 10:56 |
| tristan | indeed | 10:56 |
| tristan | juergbi, Would you say that context.projects[0] is the canonical right place to get the "main project", when that is desired ? | 11:01 |
| tristan | I guess | 11:02 |
| tristan | or rather, projects = context._get_projects(), projects[0] | 11:03 |
| *** aday has quit IRC | 11:03 | |
| *** aday has joined #buildstream | 11:04 | |
| *** aday has quit IRC | 11:08 | |
| *** aday has joined #buildstream | 11:09 | |
| juergbi | juergbi: i'd say so, yes. we could add a helper, of course. _get_toplevel_project() | 11:13 |
| tristan | Hmm, maybe I'll do that, will look cleaner | 11:17 |
| tristan | fwiw, I'm getting rid of that hard coded list of env vars in `bst shell` | 11:23 |
| tristan | and opening the door for more configurability | 11:24 |
| juergbi | \o/ | 11:25 |
| tristan | juergbi, so you think host bind mounts is a good idea ? | 11:25 |
| tristan | if we're gonna go configurable, then buildstream doesnt have to know that there is a resolv.conf or passwd file | 11:25 |
| juergbi | as long as it's part of the bst shell config, i don't have an issue with it | 11:25 |
| juergbi | right | 11:25 |
| juergbi | i wouldn't like them hard-coded | 11:25 |
| tristan | of course | 11:25 |
| tristan | I wonder what the bind mount behavior will be for a file already exists | 11:26 |
| tristan | *which already exists | 11:26 |
| juergbi | it actually has to exists, iirc | 11:26 |
| juergbi | you can't bind mount to nothing | 11:26 |
| juergbi | *exist | 11:26 |
| tristan | in the target ? | 11:26 |
| juergbi | yes, can just be an empty file | 11:27 |
| tristan | hmmm, so it would require create-if-not-exists first | 11:27 |
| juergbi | or rely on project to ensure it's in their files | 11:27 |
| juergbi | but create-if-not-exists would be convenient | 11:27 |
| tristan | Now, graphics acceleration is hard; probably not gonna work ? | 11:33 |
| tristan | Maybe we need to use a runtime with llvmpipe for graphics if we want a decent, but not performant `bst shell` ? | 11:34 |
| tristan | now I realize what the epiphany font problem is; runtime has no korean fonts | 11:35 |
| tristan | and by default of course, google.com will forward to your local google which will inevitably display korean characters | 11:35 |
| juergbi | tristan: mount bind of /dev/drm is not acceptable? | 11:53 |
| juergbi | eh, /dev/dri | 11:53 |
| juergbi | only helps if the sandbox includes a suitable mesa but in many cases that would be possible | 11:54 |
| tristan | juergbi, lets try it :) | 11:55 |
| tristan | I have a pretty good first shot here, though... | 11:55 |
| tristan | without bind-mounts yet | 11:55 |
| tristan | and sexy customized PS1 | 11:55 |
| juergbi | :) | 11:55 |
| tristan | I did so far make the assumption though, that PS1 will be considered; this is not customized | 11:56 |
| tristan | But then, we do assume there is at least a /bin/sh | 11:56 |
| tristan | and did not use custom PS1 features (afaik) | 11:56 |
| tristan | tlater, any tips on running integration tests on my host ? | 12:12 |
| tristan | tlater, shall I just run it ./setup.py test --addopts '-k integration/mytest.py' ? | 12:13 |
| tristan | hrmmm | 12:15 |
| tristan | everything fails with: ./setup.py test --addopts '--integration tests/integration/shell.py' | 12:15 |
| tristan | well, every test in shell.py | 12:15 |
| tristan | any help ? | 12:15 |
| nexus | Does it say why it fails? | 12:16 |
| tristan | myeah | 12:17 |
| tristan | And looks like we have another bug | 12:17 |
| tristan | https://bpaste.net/show/c54778023e8a | 12:18 |
| tristan | ostree is trying to set extended attributes here, and instead of a decent error, we get stack trace | 12:18 |
| juergbi | tristan: set INTEGRATION_CACHE to some path | 12:18 |
| juergbi | default is /tmp which doesn't work, iirc | 12:19 |
| juergbi | should fix that | 12:19 |
| tristan | it wouldnt if it's tmpfs | 12:19 |
| tristan | default should be in tree along with other stuff no ? | 12:19 |
| juergbi | would be fine with me | 12:19 |
| juergbi | we even already have integration-cache in .gitignore | 12:20 |
| tristan | I was just thinking tmp/ because that's our pytest configured tmpdir (so we already populate it with every run, due to the datafiles test plugin which copies stuff there) | 12:21 |
| tristan | when I run it with INTEGRATION_CACHE=`pwd`/tmp ./setup.py ... it creates tmp/integration-cache... also | 12:22 |
| juergbi | it's useful to keep integration cache around to avoid redownloading sources | 12:22 |
| tristan | looks like it failed again... waiting to discover why | 12:22 |
| juergbi | not sure whether tmp is a good place for that or not | 12:22 |
| tristan | me neither, I just want it to "just work" by default | 12:25 |
| juergbi | agreed | 12:26 |
| tristan | Also, in-tree must be sensible for that default; otherwise it means `./setup.py test` is leaving debris on your system | 12:29 |
| tristan | which I think is generally undesirable | 12:29 |
| tristan | recommendation in HACKING.rst to put it somewhere where you want to persist things, could be good; if that is a better place | 12:30 |
| tristan | or a place which takes less time for repeated tests | 12:30 |
| * tristan double checks against master, but looks like INTEGRATION_CACHE=`pwd`/tmp ./setup.py test --addopts '--integration tests/integration/shell.py' ... is totally broken too | 12:31 | |
| ssam2 | works for me locally | 12:35 |
| ssam2 | on commit b696d36386b3ec0a57d1eda72449d4bcee2bd227 | 12:35 |
| tristan | yup | 12:37 |
| tristan | I just tried with master, and works with INTEGRATION_CACHE | 12:38 |
| tristan | also fails on gitlab in similar way; so that is a problem on my side | 12:38 |
| *** xjuan has joined #buildstream | 12:40 | |
| gitlab-br-bot | buildstream: issue #267 ("Integration tests dont work by default, and write outside of repo") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/267 | 12:43 |
| gitlab-br-bot | buildstream: issue #268 ("Stack trace when ostree operates in filesystem not supporting extended attributes") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/268 | 12:46 |
| gitlab-br-bot | buildstream: merge request (project-shell-customize->master: Allow customization of shell environment, and set custom prompt in PS1) #287 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/287 | 12:56 |
| gitlab-br-bot | buildstream: merge request (project-shell-customize->master: Allow customization of shell environment, and set custom prompt in PS1) #287 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/287 | 12:56 |
| tristan | Debugging this is also becoming difficult | 13:00 |
| tristan | We print the command as ran from tests thanks to the cli fixture, so that things are reproducible in the state left behind by tests | 13:00 |
| tristan | But if I run: bst --no-colors --config /codethink/GNOME/buildstream/tmp/test_no_shell0/cache/buildstream.conf --directory /codethink/GNOME/buildstream/tmp/test_no_shell0 shell shell/no-shell.bst -- /bin/echo Pegasissies! | 13:00 |
| tristan | Now I get "Missing elements for staging an environment for a shell:" | 13:01 |
| tristan | For "shell/no-shell.bst" | 13:01 |
| tristan | The problem seems to be that a `None` is getting printed after running `bst shell` with any command | 13:02 |
| tristan | Cannot reproduce outside of integration tests | 13:05 |
| tristan | Maybe the fixture is printing None for some reason | 13:05 |
| tristan | aha, I think I nailed it | 13:12 |
| gitlab-br-bot | buildstream: merge request (project-shell-customize->master: Allow customization of shell environment, and set custom prompt in PS1) #287 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/287 | 13:15 |
| gitlab-br-bot | buildstream: merge request (project-shell-customize->master: Allow customization of shell environment, and set custom prompt in PS1) #287 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/287 | 13:28 |
| tristan | got it | 13:29 |
| tristan | Have to run go get dinner | 13:29 |
| tristan | that pipeline will pass :) | 13:30 |
| tristan | freaky shlex in shell.py test screws it up | 13:30 |
| *** tristan has quit IRC | 13:33 | |
| tlater | tristan: sorry, was being cut open. Still waiting for the narcotics to wear off, will see if I can help out after. | 13:35 |
| tlater | Ack, of course he dcs while I type that out x) | 13:36 |
| nexus | lol | 13:39 |
| ssam2 | i don't even know how to respond to someone irc'ing from an operating theatre ;-) | 13:42 |
| ssam2 | i hope the repairs went well! | 13:42 |
| *** tristan has joined #buildstream | 13:54 | |
| * tristan going out | 13:54 | |
| tristan | MR !287 above unfortunately cannot be merged | 13:55 |
| tristan | I should update the base format version for the new project.conf options, and make the gnome-build-meta require that before pushing | 13:55 |
| tristan | that's what the version assertions are for, after all | 13:55 |
| tlater | tristan: Can't tell if you've figured it out by now, but the invocation would be: `./setup.py test --addopts '--integration -m integration'` | 15:45 |
| * tlater is planning to add a "How to run the test suite" section to Hacking.rst for this kind of stuff. | 15:46 | |
| *** xjuan has quit IRC | 15:46 | |
| tlater | ssam2: I wanted to tell family members I was awake. My phone showed me the ping, figured I should reply while I'm at it ;) | 15:50 |
| * tlater tunes out of IRC to avoid being tempted again :p | 15:52 | |
| jennis | tlater, I would like to help you write that / will write some material for it next week while you're away | 16:05 |
| *** tiago has quit IRC | 16:20 | |
| *** xjuan has joined #buildstream | 16:36 | |
| *** toscalix has quit IRC | 16:39 | |
| gitlab-br-bot | buildstream: issue #269 ("buildstream hangs forever if fuse device is not present") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/269 | 16:54 |
| *** dominic has quit IRC | 16:59 | |
| jmac | So we're running a FUSE filing system for all builds at the moment to do copy-on-write, is that correct? | 17:12 |
| skullman | yes | 17:15 |
| jmac | I assumed in the previous discussions that the delay due to adding a fuse was a problem because we were going from no fuse to fuse | 17:15 |
| jmac | Is it just us adding the chown calls etc to that fuse that's slow, then? | 17:16 |
| skullman | not sure of all the details, some of it is that it's already noticeably slow, and that chown implies being able to run as another user, and FUSE has interesting behaviour if you're not the user who mounted it | 17:17 |
| *** mcatanzaro has joined #buildstream | 17:19 | |
| ssam2 | jmac, it's not for all builds | 17:22 |
| ssam2 | it's only for things which needs a read/write rootfs | 17:22 |
| ssam2 | which in practice is only the integration commands | 17:22 |
| jmac | Right, got it | 17:25 |
| *** jonathanmaw has quit IRC | 17:27 | |
| gitlab-br-bot | buildstream: issue #270 ("Compose element throws away files inside directory symlinks at integration time") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/270 | 17:30 |
| *** ssam2 has quit IRC | 17:37 | |
| gitlab-br-bot | buildstream: merge request (sam/compose-log-splits->master: WIP: Log details of artifact splitting when building 'compose' elements) #140 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/140 | 17:38 |
| *** cs_shadow has joined #buildstream | 18:09 | |
| *** ernestask has quit IRC | 18:19 | |
| *** ernestask has joined #buildstream | 18:21 | |
| *** aday has quit IRC | 19:04 | |
| *** valentind has joined #buildstream | 19:13 | |
| *** ernestask has quit IRC | 21:38 | |
| *** xjuan has quit IRC | 21:52 | |
| *** cs_shadow has quit IRC | 22:08 | |
| *** valentind has quit IRC | 22:46 | |
| *** tm has quit IRC | 22:46 | |
| *** mcatanzaro has quit IRC | 23:44 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!