| *** tristan has quit IRC | 05:47 | |
| *** tristan has joined #buildstream | 06:16 | |
| *** ChanServ sets mode: +o tristan | 06:58 | |
| *** LaurenceUrhegyi has joined #buildstream | 07:56 | |
| *** jonathanmaw has joined #buildstream | 08:43 | |
| jonathanmaw | hrm, looks like I'm not having problems with an absent host bzr, something else is going wrong. | 09:03 |
|---|---|---|
| tristan | :) | 09:06 |
| tristan | jonathanmaw, I've done something horrible, well... maybe not *that* bad | 09:07 |
| tristan | but anyway, I needed a feature from script element | 09:07 |
| tristan | So... lets talk about script element more later today | 09:07 |
| tristan | it needs some creativity :D | 09:08 |
| tristan | jonathanmaw, anyway, iiuc, it would seem that your test cases are passing on your host but not on gitlab ? | 09:09 |
| jonathanmaw | tristan: yep | 09:10 |
| tristan | I think we are having some similar issues with baserock conversions... first it was that the host didnt support xattrs (wtf ?), and now an issue popped up where executing /bin/sh was permission denied in the sandbox | 09:10 |
| tristan | So... something about these runners :-S | 09:10 |
| tristan | then again, those are different (baserock hosted ?) runners | 09:11 |
| jonathanmaw | tristan: could you try my branch on your machine? I've tried it from a separate checkout of buildstream to isolate the problem from any debris cluttering my working dir | 09:12 |
| tristan | Sure | 09:12 |
| jonathanmaw | ta | 09:12 |
| jonathanmaw | I should probably make a merge request | 09:16 |
| tristan | jonathanmaw, so it passes here | 09:19 |
| tristan | But it would be good to know why it's failing on gitlab really, we want to keep that passing :-S | 09:19 |
| tristan | In the worst case, we can identify why it doesnt pass on that host, and we can start casing out source plugin tests which cannot run on a given host environment | 09:20 |
| *** ssam2 has joined #buildstream | 09:20 | |
| ssam2 | the performance of `bst show` is disappointing on my machine | 09:30 |
| ssam2 | I think the bottleneck is in OStree somewhere | 09:30 |
| tristan | probably | 09:30 |
| ssam2 | it takes 13 seconds to tell me if something is in the cache, with a warm cache | 09:30 |
| ssam2 | and minutes if the cache is cold | 09:31 |
| tristan | There is some profiling... | 09:31 |
| tristan | ssam2, yeah that sounds long | 09:36 |
| tristan | ssam2, it may be that we can parallelize some of that work | 09:36 |
| tristan | So, cache keys are already resolved after the second step | 09:36 |
| tristan | ssam2, am I right to assume that the third step is where things are very painfully slow ? | 09:36 |
| tristan | The third step is where we interrogate the artifact cache and source plugins, to resolve whether things are already cached or need downloads or what | 09:37 |
| tristan | which is i/o intensive of course | 09:37 |
| tristan | but since cache keys are resolved, I think we could run that part in parallel processes, making things snappier | 09:38 |
| tristan | violeta, oh yeah so I was thinking about that the other day, different branches vs one branch and various projects... and it struck me that... we could use one single project for this, but just have different *targets* for each test case | 09:52 |
| tristan | That might be the easiest to manage, as I mentioned the important part to me is to have separate, smallish tests which appear in the gitlab testing pipeline | 09:53 |
| tristan | how they are layed out / managed is less important | 09:53 |
| violeta_ | ok | 09:53 |
| violeta_ | I think it makes sense, but wasn't sure if there was another requirement | 09:54 |
| tristan | we could use buildstream-tests master for this | 09:54 |
| tristan | yeah it's just a question of having small, digestible units | 09:55 |
| tristan | violeta_, since everything buildstream starts with imports, you probably should start with a test for the import element | 09:56 |
| tristan | i.e. https://buildstream.gitlab.io/buildstream/elements/import.html#module-import | 09:56 |
| * violeta_ takes a look | 09:57 | |
| violeta_ | thanks | 09:57 |
| ssam2 | tristan, yes it's the 3rd step | 09:57 |
| ssam2 | it stays on 1/127 and 2/127 for a while, but the rest go faster | 09:58 |
| ssam2 | so maybe some spinup inside Ostree | 09:58 |
| tristan | violeta_, so it has basically 2 options, would be good to have a test which exercises them, also, an option is to use `bst checkout` after `bst build` to inspect that the output of the built element is as expected | 09:58 |
| tristan | violeta_, also... an option would be to have a tests/ subdirectory directly in the buildstream-tests repo (which is also a buildstream project), and write shell scripts in there | 09:59 |
| *** LaurenceUrhegyi has left #buildstream | 09:59 | |
| tristan | instead of having complex stuff in the .gitlab-ci.yml | 09:59 |
| *** LaurenceUrhegyi has joined #buildstream | 09:59 | |
| tristan | ssam2, ah yeah I see, that is strange indeed | 10:00 |
| tristan | ssam2, it should not take that much more time to check if an ostree ref and associated object is present | 10:00 |
| ssam2 | i'll see if i can profile it somehow | 10:00 |
| tristan | however, note that I had to change that check at some point, because it is possible to have a ref present but no backing object in the repo | 10:01 |
| tristan | (i.e. I think it's when there is a summary file, you are allowed to know what refs you can pull before pulling them) | 10:01 |
| tristan | probably the has_object() check to see if it really exists is what is slower | 10:02 |
| ssam2 | right | 10:03 |
| tristan | ssam2, BST_PROFILE=load-pipeline bst show ... | 10:03 |
| ssam2 | oh cool | 10:03 |
| tristan | That will give you a report in the cwd | 10:03 |
| tristan | but, it will probably point to ostree yeah | 10:04 |
| tristan | I added the profiling stuff mostly because, you know sorting the dependencies and checking circular deps of large projects can be exponential if we're not careful | 10:05 |
| ssam2 | http://sprunge.us/LfME | 10:05 |
| ssam2 | seems that configure_origin is slow .. seems odd | 10:05 |
| ssam2 | this profiling feature is ace by the way | 10:05 |
| tristan | :) | 10:06 |
| tristan | its built into the standard library so... thanks python :) | 10:06 |
| jonathanmaw | tristan: looks like it was failing while trying to set up the bzr repo to test with | 10:15 |
| jonathanmaw | It looks like the logs aren't pulling out the error | 10:15 |
| jonathanmaw | so I can't see the specific cause, just that it failed when calling 'bzr commit' | 10:15 |
| tristan | So it looks like you are using Plugin.call() on the plugin directly to do stuff | 10:18 |
| tristan | not exactly a terrible idea, but I'm not sure where the stderr/stdout is going to in that case | 10:19 |
| tristan | You might want to just change that in the test case for subprocess.call() | 10:19 |
| jonathanmaw | ok, I'll give that a go | 10:20 |
| tristan | jonathanmaw, or... I have another idea | 10:21 |
| tristan | jonathanmaw, so how about we modify plugin.py _output_file() to yield stdout in the case that an environment variable is set, and always set that when running test cases ? | 10:22 |
| tristan | for a quick test, you could just force it to yield stdout and push a branch to see whats up on gitlab | 10:23 |
| jonathanmaw | tristan: If it's a quick and dirty solution, using subprocess is probably better | 10:24 |
| tristan | then after we can setup the test environment and use an env var (seems like generally a good idea, since we'll want all the output of everything to appear on a gitlab console directly whenever something fails, and not inside some log file) | 10:24 |
| gitlab-br-bot | buildstream: merge request (jonathan/bzr-source->master: Jonathan/bzr source) #19 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/19 | 10:24 |
| tristan | jonathanmaw, no I think that (as said above), having a different environment for ./setup.py test is actually desirable and not a dirty hack | 10:25 |
| jonathanmaw | tristan: Would there be a way to make the tests use a log handle that's stdout, instead? | 10:25 |
| tristan | note that py.test wont print any of the stdout of a test case to the console unless a test actually failed | 10:25 |
| tristan | jonathanmaw, there would be a way, yeah... but it probably means we need a special fixture and special code littered all around all of the test cases to make it work | 10:26 |
| tristan | the _set_log_handle() is usually called by the scheduler when it creates a log for a given child task | 10:27 |
| jonathanmaw | tristan: ok. Would you prefer an env variable like "BUILDSTREAM_LOG_TO_STDOUT" or "BUILDSTREAM_TEST_MODE"? | 10:29 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 4 commits (last: script element: interim hacks) https://gitlab.com/BuildStream/buildstream/commit/ca9a8837dd00a283fd8a9cca1760588640d23571 | 10:29 |
| *** LaurenceUrhegyi has quit IRC | 10:31 | |
| tristan | jonathanmaw, the latter, maybe BST_TEST_SUITE | 10:36 |
| tristan | or test mode, whichever | 10:36 |
| tristan | log to stdout is not a feature I want anyone using, the output will be mangled and incomprehensible | 10:37 |
| tristan | for running an actual pipeline | 10:37 |
| gitlab-br-bot | buildstream: issue #34 ("Master logs of integration commands are confusing") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/34 | 10:41 |
| gitlab-br-bot | buildstream: merge request (jonathan/bzr-source->master: Jonathan/bzr source) #19 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/19 | 10:47 |
| gitlab-br-bot | buildstream: Tristan Van Berkom deleted branch pages-test | 10:48 |
| gitlab-br-bot | push on buildstream@pages-test (by Tristan Van Berkom): 2 commits (last: Trying fix of docs build) https://gitlab.com/BuildStream/buildstream/commit/41d924c8fbda54c7a2d951696a08c8c46833d346 | 10:48 |
| *** LaurenceUrhegyi has joined #buildstream | 10:48 | |
| gitlab-br-bot | push on buildstream@pages-test (by Tristan Van Berkom): 1 commit (last: Another try) https://gitlab.com/BuildStream/buildstream/commit/6aed581d6018733691a95f25d5dc60b9b7aeeac2 | 10:52 |
| * tristan should soon modify that bot so that it only announces commits to master | 10:53 | |
| ssam2 | seems that my performance issues are actually in gpgme | 11:00 |
| ssam2 | it's the repo.remote_gpg_import() call that is slow | 11:00 |
| tristan | yeah I noticed that from the beginning, but find that strange :-/ | 11:01 |
| tristan | sure it loads a tiny file | 11:01 |
| tristan | and tells the ostree to use that for validating anything incoming | 11:01 |
| tristan | but | 11:01 |
| tristan | so ? | 11:01 |
| tristan | heh | 11:01 |
| ssam2 | yeah | 11:01 |
| ssam2 | i attached gdb and its gpgme_op_import() that is the slow part | 11:01 |
| ssam2 | i'll step through that and see if there's anything obviously dumb going on | 11:02 |
| tristan | ssam2, what distro ? | 11:02 |
| tristan | ssam2, maybe it's something fixed ? | 11:02 |
| ssam2 | Fedora 24 | 11:03 |
| ssam2 | so perhaps indeed | 11:03 |
| *** LaurenceUrhegyi has quit IRC | 11:19 | |
| tristan | hrm... so I think I have a fix here for the documentation builds which have been broken, ever since sphinx started importing from distutils | 11:23 |
| tristan | for which we have a plugin of the same name | 11:23 |
| gitlab-br-bot | buildstream: Tristan Van Berkom deleted branch pages-test | 11:28 |
| gitlab-br-bot | push on buildstream@pages-test (by Tristan Van Berkom): 1 commit (last: Added __init__.py to the plugin subdirectories.) https://gitlab.com/BuildStream/buildstream/commit/25325b0d6f8dc93e2bd40d3f81637c36bf0b3158 | 11:29 |
| gitlab-br-bot | buildstream: Tristan Van Berkom deleted branch pages-test | 11:40 |
| tristan | documentation builds fixed ! | 11:42 |
| tristan | pipelines green again | 11:42 |
| ssam2 | nice! | 11:42 |
| tristan | And the converted jhbuild modulesets for meta-gnome-apps-tested build, all except for gnome-multi-writer | 11:42 |
| tristan | Which... I'm not convinced builds with jhbuild either | 11:43 |
| tristan | (that is, same state as it was before I automated the debootstrapping, but now works with the multistrap thing) | 11:43 |
| tristan | I think we're actually gonna pull this off ! | 11:44 |
| tristan | haha | 11:44 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: Added __init__.py to the plugin subdirectories.) https://gitlab.com/BuildStream/buildstream/commit/25325b0d6f8dc93e2bd40d3f81637c36bf0b3158 | 11:46 |
| ssam2 | I can reproduce this "5 second GPG import" bug with ostree itself. seems to be some stupid gpg2 failure case when filenames are over a certain length | 11:46 |
| *** brlogger has joined #buildstream | 11:51 | |
| ssam2 | should be a fairly easy patch to ostree, anyway | 11:51 |
| *** paulsher1ood has joined #buildstream | 11:52 | |
| *** LaurenceUrhegyi has joined #buildstream | 11:57 | |
| tristan | So, this is the base on which GNOME modulesets get converted: https://gitlab.com/BuildStream/buildstream-tests/tree/gnome-conversion-base | 11:58 |
| tristan | And here is an example of a converted modulesets: https://gitlab.com/BuildStream/buildstream-tests/tree/converted-gnome | 11:58 |
| tristan | Using a jhbuild fork installation from here: https://gitlab.com/BuildStream/jhbuild2bst | 11:59 |
| tristan | and running: jhbuild bst --directory ../buildstream-tests/ meta-gnome-extended-devel-platform meta-gnome-core meta-gnome-core-os-services meta-gnome-apps-tested | 12:00 |
| ssam2 | seems that the issue is fixed in ostree v2017.6 | 12:25 |
| ssam2 | https://github.com/ostreedev/ostree/commit/4f80548454dba1342849caf5b568cb4e34883ba4 | 12:25 |
| ssam2 | seems to be a coincidence though | 12:25 |
| tristan | I see | 12:26 |
| * ssam2 wonders where to write this up for posterity | 12:26 | |
| ssam2 | do you have any "known issues" or "FAQ" ? | 12:26 |
| tristan | ssam2, I'm not sure this is the kind of thing I want in an FAQ, i.e. it will just become obsolete in a short time and add technical debt (that I have to clean it up one day) | 12:29 |
| ssam2 | yeah | 12:29 |
| ssam2 | maybe I could open a bug against ostree and immediately close it as fixed :-) | 12:29 |
| ssam2 | just want something to point people to when they complain that it takes 10 seconds to do anything | 12:29 |
| tristan | Sure, feel free :) | 12:29 |
| tristan | ssam2, note that however there is doc/install.rst which makes a mention of all minimal bound dependencies | 12:30 |
| ssam2 | ah true, we could note it in there | 12:30 |
| tristan | technically we require >= v2016.8 | 12:30 |
| tristan | but we can recommend higher | 12:30 |
| ssam2 | ok, i'll do a patch | 12:31 |
| * tristan jumps out for a bite | 12:31 | |
| *** tristan has quit IRC | 12:34 | |
| *** LaurenceUrhegyi has quit IRC | 12:57 | |
| *** Laurence has joined #buildstream | 13:03 | |
| *** tristan has joined #buildstream | 13:26 | |
| *** ChanServ sets mode: +o tristan | 13:29 | |
| jonathanmaw | hrm, I'm not having much luck making plugin.call use stdout. When I make _output_file() return sys.stdout, I endup with "RuntimeError: generator didn't stop". When I use subprocess.STDOUT (and fix the bits that tried to call write() on it), I end up with OSError: Bad file descriptor. | 13:32 |
| tristan | jonathanmaw, did you really return it ? or did you yield it ? | 13:32 |
| jonathanmaw | yield | 13:33 |
| tristan | Then maybe you are yielding more than one thing | 13:33 |
| tristan | i.e. if (debug) yield stdout ... else do_the_regular | 13:33 |
| tristan | jonathanmaw, it's a context manager so... yield is not return | 13:34 |
| tristan | well, neither is it in a regular generator | 13:34 |
| jonathanmaw | ah, bugger. That was it! | 13:34 |
| tristan | heh | 13:34 |
| *** gitlab-br-bot has joined #buildstream | 13:44 | |
| gitlab-br-bot | buildstream: merge request (jonathan/bzr-source->master: Jonathan/bzr source) #19 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/19 | 13:48 |
| jonathanmaw | ! | 13:59 |
| jonathanmaw | bzr is failing to commit because it requires a name set with bzr whoami | 13:59 |
| tristan | jonathanmaw, :) | 14:00 |
| tristan | Ok... so we can move on ! | 14:00 |
| tristan | Hah | 14:00 |
| jonathanmaw | tristan: any objections to the name Testy McTesterson? | 14:00 |
| jonathanmaw | or should I go with something sensible like "Buildstream Runner"? | 14:01 |
| paulsher1ood | +1 | 14:02 |
| jonathanmaw | hrm, should I make the preflight stage of the plugin set it? | 14:02 |
| tristan | jonathanmaw, ok wait a sec | 14:03 |
| jonathanmaw | aha, there's no need for me to do it in the source plugin, since I shouldn't need it at that point. | 14:03 |
| tristan | ummm | 14:03 |
| jonathanmaw | it's just for the tests | 14:03 |
| tristan | jonathanmaw, ok so in normal operation, we never need to set the whoami, right ? | 14:04 |
| jonathanmaw | tristan: correct. the error occurs when trying to create a commit | 14:04 |
| tristan | The important thing to remember here is that running buildstream should never pollute user configuration | 14:04 |
| tristan | So maybe also more concretely, is it okay for running ./setup.py test to pollute the user-wide configuration ? | 14:05 |
| jonathanmaw | hrm | 14:05 |
| tristan | When we do tests for git, we setup some environment variables | 14:05 |
| tristan | of course running the tests is less bad than running buildstream, if it does that, assuming no buildstream developers ever contribute to bzr projects on the same machine they use to hack on buildstream | 14:06 |
| jonathanmaw | ok, so the best place to put this is in the .gitlab-ci.yml commands | 14:07 |
| tristan | otherwise I presume that the result is inadvertently you submit patches with your commit messages saying that you are Testy McTesterson | 14:07 |
| tristan | in which case, definitely use that name :) | 14:07 |
| ssam2 | setting BZR_HOME in the environment lets you set a custom bzr config dir | 14:08 |
| tristan | I think ssam2's approach is better than doing it in the .gitlab-ci.yml | 14:08 |
| tristan | So in that case, just need to set it in the env, and then set with bzr whoami | 14:09 |
| tristan | directly in the test case | 14:09 |
| tristan | that can be a tempdir or something directly in the tests, doesnt matter really | 14:09 |
| jonathanmaw | aha, there's the environment variable BZR_EMAIL, which overrides things | 14:10 |
| jonathanmaw | so I should set that while in the tests | 14:10 |
| tristan | nod, try that, if that works on the runner we're set :) | 14:10 |
| jonathanmaw | ok. and for the sake of better repeatability, I'll do it inside test scripts (so it is there for all bzr tests), rather than in gitlab-ci | 14:11 |
| tristan | yes | 14:11 |
| tristan | please | 14:11 |
| tristan | jonathanmaw, you may be interested to know that I did some more hacking on the tar plugin too | 14:12 |
| jonathanmaw | tristan: I had a look at some of the history. iirc it was to let you extract a subset of the tar | 14:12 |
| tristan | https://buildstream.gitlab.io/buildstream/sources/tar.html#module-sources.tar | 14:12 |
| tristan | notice it now has a glob, which is * by default, to match the first directory found at the root of the tarball yeah | 14:13 |
| tristan | otherwise, you ended up trying to build things, and in /buildstream/build you had foo-1.23-4/ | 14:13 |
| tristan | instead of a ./configure | 14:13 |
| tristan | turned out it was no easy task to implement globbing on tarballs | 14:14 |
| tristan | but now that we have the secret sauce, I think I'd like to apply that to the split-rules | 14:14 |
| tristan | instead of letting users break their brain cells with crazy regex patterns | 14:14 |
| gitlab-br-bot | buildstream: merge request (jonathan/bzr-source->master: Jonathan/bzr source) #19 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/19 | 14:19 |
| jonathanmaw | \o/ tests pass! | 14:25 |
| tristan | jonathanmaw, yay \o/ | 14:26 |
| jonathanmaw | tristan: merge request at https://gitlab.com/BuildStream/buildstream/merge_requests/19 Do you want me to tidy up the history? It has a bunch of commits to add more and more logging while running bzr tests. | 14:26 |
| tristan | ok now I want you to undo the change to .gitlab-ci.yml | 14:26 |
| tristan | And pass the BST_TEST_SUITE through pytest addopts in buildstream's setup.cfg | 14:27 |
| tristan | we already have a few addopts there, I think it should be: --testdata ="BST_TEST_SUITE:True" | 14:28 |
| tristan | the space before the = is confusing, not sure if it's correct | 14:29 |
| tristan | taken from https://stackoverflow.com/questions/36141024/how-to-pass-environment-variables-to-pytest | 14:29 |
| tristan | couldnt find a regular ini option for env vars in https://docs.pytest.org/en/latest/customize.html | 14:29 |
| tristan | jonathanmaw, and yes please squash some of the things you think should be squashed :) | 14:30 |
| gitlab-br-bot | buildstream: merge request (ostree-version-note->master: Note that OSTree v2017.6 or newer is preferred) #20 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/20 | 14:38 |
| ssam2 | my first buildstream pull request :-) | 14:39 |
| jonathanmaw | hrm, I managed to do something to my buildstream setup, and now `python3 setup.py test` is failing | 14:43 |
| jonathanmaw | "pkg_resources.VersionConflict: (py 1.4.25 (/usr/lib/python3/dist-packages), Requirement.parse('py>=1.4.29'))" | 14:43 |
| jonathanmaw | i.e., whatever "py" is, it is 1.4.25, but needs 1.4.29 | 14:44 |
| ssam2 | something to do with py.test I think | 14:44 |
| ssam2 | maybe reinstall that ? | 14:44 |
| jonathanmaw | I'm not sure what that comes from. I have python-pytest and python3-pytest packages in debian, but I don't think I needed to install one of them, previously. | 14:45 |
| ssam2 | maybe you have stuff installed in ~/.local/lib from pip that conflicts with the debian-packaged stuff? just guessing | 14:46 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: Note that OSTree v2017.6 or newer is preferred) https://gitlab.com/BuildStream/buildstream/commit/f3e1aadfdd781c6aed7920545a654a5e9eaff67f | 14:47 |
| gitlab-br-bot | buildstream: merge request (ostree-version-note->master: Note that OSTree v2017.6 or newer is preferred) #20 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/20 | 14:47 |
| jonathanmaw | ssam2: could be. there's site-packages for "tests" in there | 14:47 |
| jonathanmaw | I'll try pip uninstalling buildstream, then installing again | 14:48 |
| tristan | yeah one recommendation, is never pip install without --user | 14:48 |
| tristan | pip will inevitably mess it up eventually | 14:48 |
| * tristan is running buildstream on aarch64 ! | 14:57 | |
| tristan | heh | 14:57 |
| tristan | first time I actually tried it, unfortunately I cant track the debian base | 14:58 |
| tristan | connection refused to gnome7.codethink.co.uk... when *ON* gnome7.codethink.co.uk :-S | 14:59 |
| * tristan exits building | 14:59 | |
| *** tristan has quit IRC | 15:03 | |
| *** tristan has joined #buildstream | 15:11 | |
| jonathanmaw | aha, I managed to fix it by `pip3 install --upgrade --user py` | 15:11 |
| jonathanmaw | since py with an older version was already provided by debian | 15:11 |
| jonathanmaw | tristan: looks like pytest doesn't recognise --testdata | 15:13 |
| tristan | https://gnome7.codethink.co.uk/test-build.txt | 15:18 |
| tristan | active build log :) | 15:18 |
| tristan | jonathanmaw, ummm | 15:19 |
| jonathanmaw | "setup.py: error: unrecognized arguments: --testdata=BST_TEST_SUITE:True". space before the equals doesn't help, either | 15:20 |
| tristan | I'm asking this question in #python right now | 15:21 |
| tristan | it should be doable | 15:21 |
| tristan | jonathanmaw, seems you are right :-/ | 15:27 |
| tristan | I'm checking and py.test doesnt seem to offer an option | 15:27 |
| tristan | the testdata thing must be outdated, and even then the said SO post mentions you have to catch it in your cases | 15:27 |
| tristan | There is this, though https://github.com/MobileDynasty/pytest-env | 15:28 |
| tristan | we already have a bunch of stuff under tests_require in setup.py | 15:29 |
| tristan | I suppose adding pytest-env there, and then adding the env var to setup.cfg would accomplish that so we have it enabled by default | 15:29 |
| tristan | eh... jonathanmaw I dont know what is best here honestly | 15:30 |
| tristan | I would rather things be nicely wrapped up into setup.py, but python setuptools end up disappointing me time and time again | 15:30 |
| jonathanmaw | I'll give pytest-env a go | 15:31 |
| tristan | looks like ostree is having a hard time on aarch64 | 15:36 |
| tristan | although it's working fine for the debootstrap commits :-/ | 15:37 |
| gitlab-br-bot | buildstream: merge request (jonathan/bzr-source->master: Jonathan/bzr source) #19 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/19 | 15:37 |
| tristan | well, I'll let it run and think I'll go for a midnight gyming | 15:39 |
| tristan | jonathanmaw, looks good btw, have you checked that it actually works ? (by say, causing a test to fail locally and seeing the output ?) | 15:39 |
| jonathanmaw | tristan: I caused a test to fail and used that to check the env. BST_TEST_SUITE was set | 15:40 |
| tristan | jonathanmaw, nice, please push a rebased against master branch so I can click it :) | 15:41 |
| tristan | otherwise I'll merge from my laptop | 15:41 |
| tristan | anyway, I'll take a last look tomorrow | 15:41 |
| tristan | jonathanmaw, https://gitlab.com/BuildStream/buildstream-tests/blob/build-gnome/elements/gnome/gnome-system-image.bst | 15:41 |
| tristan | in the mean time, start looking at that crazy script | 15:41 |
| jonathanmaw | yarp | 15:41 |
| tristan | and think about inventing a base script element class which we can reuse to do all kinds of fancy things | 15:42 |
| gitlab-br-bot | buildstream: merge request (jonathan/bzr-source->master: Jonathan/bzr source) #19 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/19 | 15:42 |
| tristan | jonathanmaw, I'm also using it for this: https://gitlab.com/BuildStream/buildstream-tests/blob/gnome-conversion-base/elements/base-configure.bst | 15:42 |
| tristan | jonathanmaw, we're going to want a base element that we can derive and create reusable elements, so we'll want a sort of x86-image element that derives from script, and does that crazy stuff but can be configured and suchlike | 15:43 |
| tristan | anyway... it's getting late for you too, but something to think about and sleep on it :D | 15:43 |
| *** jonathanmaw has quit IRC | 17:03 | |
| *** tiagogomes has quit IRC | 17:14 | |
| tristan | jjardon[m], I've reproduced the permission denied error you encountered on gitlab | 17:53 |
| tristan | https://gnome7.codethink.co.uk/test-build.txt | 17:53 |
| tristan | on an aarch64 machine | 17:53 |
| tristan | It would seem that under some conditions, there is an ostree bug which fails to checkout with the proper permissions | 17:54 |
| tristan | my /usr/bin is full of -rw-------, except for symlinks which are all lrwxrwxrwx | 17:54 |
| gitlab-br-bot | buildstream: merge request (fix-script-element->master: Fix script element) #21 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/21 | 17:54 |
| tristan | ssam2, looks like a good patch, sadly the script element is in for an overhaul starting right now, and we'll have to change the one we're using in the baserock conversion | 17:57 |
| tristan | but I'll apply anyway | 17:57 |
| gitlab-br-bot | buildstream: merge request (fix-script-element->master: Fix script element) #21 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/21 | 17:57 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 2 commits (last: element: Give a helpful error if the 'collect' dir doesn't exist) https://gitlab.com/BuildStream/buildstream/commit/9de9e5d70bf1e020f9ab729d8fd58c283a5d7f4f | 17:57 |
| ssam2 | no bother | 17:58 |
| ssam2 | just trying to get some initial builds going :-) | 17:58 |
| tristan | yeah anyway why not, I was worried I may have regressed things | 17:58 |
| tristan | which it looks like I did | 17:58 |
| * tristan pushed that collect change only this morning | 17:58 | |
| ssam2 | fast feedback loop! | 17:58 |
| tristan | just my luck that you built it :) | 17:59 |
| ssam2 | i've got a Baserock devel system building which should hopefully be done overnight | 17:59 |
| ssam2 | tomorrow is my last day at work for a while, but i'm going to mail baserock-dev with my partial attempt at a converted definitions repo | 17:59 |
| tristan | I wasnt really gonna ask; hey can somebody spend 2-8 hours of full time cpu usage to try and see if this broke ? | 17:59 |
| tristan | ssam2, ok I hope you are aware also of the automated conversion on gitlab | 18:00 |
| tristan | looks like I hit the same error it was hitting | 18:00 |
| tristan | jjardon[m], set it up | 18:00 |
| ssam2 | hmm, no where's that ? | 18:00 |
| tristan | initially | 18:00 |
| tristan | it's on baserock gitlab... somewhere | 18:00 |
| tristan | it automates the process of running defs2bst and trying to build | 18:01 |
| ssam2 | ah cool | 18:01 |
| ssam2 | if only he'd notified the mailing list about that | 18:02 |
| tristan | at first there was a runner issue, the thing didnt support xattrs (weird) | 18:02 |
| tristan | and now there is this permissions issue I seemed to have hit as well | 18:02 |
| tristan | which I suspect is an ostree bug | 18:02 |
| tristan | but have to investigate | 18:02 |
| ssam2 | aha https://gitlab.com/baserock/definitions/blob/jjardon/bst2/.gitlab-ci.yml | 18:03 |
| tristan | I take it you got much further than the runner did :) | 18:03 |
| tristan | if you're talking about the script element hehe | 18:03 |
| ssam2 | yes :-) | 18:03 |
| ssam2 | got a base system to build already, now trying devel and will try and produce a VM image | 18:04 |
| *** ssam2 has quit IRC | 18:08 | |
| *** violeta_ has quit IRC | 18:21 | |
| *** brejoc has joined #buildstream | 19:14 | |
| *** brejoc has quit IRC | 19:14 | |
| *** tristan has quit IRC | 20:43 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!