| *** jennis has quit IRC | 03:14 | |
| *** jennis has joined #buildstream | 03:14 | |
| *** mcatanzaro has quit IRC | 04:08 | |
| *** tristan has joined #buildstream | 05:01 | |
| gitlab-br-bot | buildstream: issue #297 ("new tar source etag saved strangely") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/297 | 06:48 |
|---|---|---|
| *** toscalix has joined #buildstream | 08:01 | |
| gitlab-br-bot | buildstream: issue #297 ("new tar source etag saved strangely") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/297 | 08:37 |
| *** jonathanmaw has joined #buildstream | 09:38 | |
| *** valentind has joined #buildstream | 09:41 | |
| gitlab-br-bot | buildstream: merge request (tristan/project-refs->master: WIP: Optionally load and store source references in project.refs) #314 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/314 | 09:46 |
| *** tiago has joined #buildstream | 10:03 | |
| *** dominic has joined #buildstream | 10:16 | |
| juergbi | commenting at the same time, oh well ;) | 10:21 |
| tristan | juergbi, :) | 10:22 |
| tristan | just noticed that yeah | 10:22 |
| tristan | juergbi, looking at the new number I'm much less concerned anyway :) | 10:25 |
| tristan | or s/concerned/optimistic that we could have improved speed alot/ | 10:25 |
| juergbi | yes, makes sense | 10:25 |
| Nexus | milloni: any luck? | 10:26 |
| juergbi | tristan: btw: i'm actually interested in supporting uncached build outputs | 10:26 |
| juergbi | but for things like generating disk images | 10:26 |
| juergbi | as an artifact cache is a bad fit for that, no matter whether on client or server | 10:27 |
| milloni | Nexus, didn't look into it. i'll try later this week (I'm doing this in my free time only) | 10:27 |
| jennis | juergbi, regarding the change of dir_ to directory: I had good Google around and asked on the #pylint IRC and it doesn't seem possible to disable the warning just for one built-in while keeping the others enabled | 10:40 |
| juergbi | jennis: ok. del builtins.__dict__['dir'] might work, if we can execute that early enough even when running pylint. however, that might be considered too hacky | 10:46 |
| * tristan had phone call... | 10:49 | |
| tristan | juergbi, so... *maybe* the approach I outlined already is a good fit for that, on the other hand it's a tricky topic; we originally decided not to make exceptions for "deployments" and suchlike, an element is an element is an element | 10:50 |
| tristan | juergbi, also, regardless of whether caching is a "good fit", we probably want it anyway, if only as a means of transport | 10:51 |
| tristan | The machine you built a firmware on, is not necessarily the machine you deploy it from | 10:51 |
| juergbi | that would be a pretty inefficient means of transport, though | 10:51 |
| juergbi | casync would be useful for disk images but it would be slower for the other cases | 10:52 |
| tristan | Well, be it a tarball or an ostree or whatever abstract thing it is; getting the GPG signed "thing" from a build server to a centralized "store" (i.e. not necessarily a "cache"), needs doing | 10:52 |
| tristan | this is not things we're doing _now_, but it seems to be the direction we're heading in | 10:53 |
| tristan | considering that picture, I wonder if it makes sense special-casing things | 10:54 |
| juergbi | yes, it really depends on how much of that we handle in buildstream in the end | 10:54 |
| juergbi | i don't see it as an urgent issue in any case | 10:54 |
| juergbi | just something that came to mind a while ago | 10:54 |
| tristan | juergbi, do you have thoughts on CLI API and UX for tracking across junctions ? | 10:54 |
| tristan | I'm ready to hammer that in; but I'm not sure what UX to expose | 10:55 |
| juergbi | for specifying elements across junctions, i suggested junction.bst:foo.bst at some point | 10:55 |
| tristan | Currently the *junction* elements themselves dont appear in a pipeline, and need separate tracking | 10:55 |
| tristan | Right, there is also the matter of *addressing* junctioned elements | 10:55 |
| tristan | They are *printed* in that way, but currently non-addressable afaics | 10:56 |
| juergbi | correct | 10:56 |
| tristan | I wonder if we need to support that part in a first step, though | 10:56 |
| juergbi | i think it would be generally useful, yes | 10:57 |
| juergbi | also allow building an element in a subproject | 10:57 |
| tristan | In my branch, I deprecate the `--track-save` option to `bst build` | 10:57 |
| juergbi | how are conditionals handled with external refs? | 10:57 |
| juergbi | (conditional sources) | 10:57 |
| tristan | They are... not. | 10:58 |
| tristan | Hmmm, that is a good point, they *could* be | 10:58 |
| juergbi | probably quite tricky | 10:58 |
| tristan | I have an idea | 10:58 |
| tristan | requires some onus on the project author | 10:59 |
| juergbi | but could be essential for version controlled refs | 10:59 |
| tristan | So... first of all; we agreed that we could rely on optionality and project.refs for the case of "Tracking latest *tag* on branch" | 11:00 |
| tristan | I think optionality in junctions is similar to that | 11:00 |
| *** valentind has quit IRC | 11:00 | |
| tristan | juergbi, so in *any* case, the toplevel project can only see it's own options, and only those can control what options are selected through a junction | 11:00 |
| tristan | juergbi, A project author could author/doctor their project.refs file such that where something is conditional in a junction or a source; it is *also* conditional in the project.refs file | 11:01 |
| * tristan has not supported option resolution in project.refs yet; though; I had not considered this | 11:01 | |
| tristan | However it does do the regular round-tripping and such | 11:02 |
| juergbi | right, that would at least work for ref updates, although not for initial refs, right? | 11:02 |
| tristan | True | 11:03 |
| tristan | Hmm | 11:04 |
| tristan | Well, that's not entirely bad; though | 11:04 |
| tristan | You would have to have a lot of conditional refs for it to start to be painful | 11:04 |
| tristan | Whew; ok not out of the wood yet then | 11:05 |
| tristan | I wonder, what is the lowest barrier to entry for this; such that we could improve things later | 11:06 |
| Nexus | If i put a print in the integration tests, will it print it in the gitlab pipeline or is the outpus sent elsewhere? | 11:06 |
| tristan | without having something utterly crap in the first place | 11:06 |
| tristan | Nexus, I believe it will be captured by py.test and it will be printed if the test fails. | 11:08 |
| Nexus | tristan: i see, because i have a test that's hanging, but don't know what on | 11:09 |
| Nexus | so it isn't failing | 11:09 |
| Nexus | it just isn't passign | 11:09 |
| Nexus | passing* | 11:09 |
| juergbi | tristan: option resolution in project.refs could suffice for now | 11:10 |
| tristan | Nexus, I think if you hit ^C you will find out | 11:10 |
| Nexus | i shall try that :) ty | 11:10 |
| tristan | Nexus, also, --addopts ' -s ' I think will unconditionally print stuff | 11:11 |
| tlater | Nexus: note you'd have to run the test locally for that | 11:11 |
| tristan | which py.test captures | 11:11 |
| juergbi | tristan: there is no documentation yet, right? i'm actually still not sure when we'll recommend which approach. the documentation should provide guidance | 11:11 |
| * tristan implied that, yes :) | 11:11 | |
| Nexus | tlater + tristan it's a unix test that's hanging, i can't run it locally | 11:11 |
| tristan | juergbi, not yet, I wanted to sort out the semantics of cross-junction tracking | 11:11 |
| tlater | Nexus: BST_FORCE_BACKEND=unix is here to help :) | 11:11 |
| tlater | But psst | 11:12 |
| Nexus | how do i use that? | 11:12 |
| tlater | It's only for testing | 11:12 |
| tristan | Nexus, afaik we test the unix backend on linux, I could be wrong | 11:12 |
| juergbi | tristan: another note: the branch adds a mandatory source method. this is essentially an API break, right? | 11:12 |
| Nexus | tristan: it gets skipped locally for me | 11:12 |
| tristan | juergbi, Technically not | 11:12 |
| tristan | juergbi, I handle ImplError and tell the user that the Source implementation in question does not support project.refs | 11:12 |
| skullman | Nexus: could be you need to run the test suite as root | 11:12 |
| juergbi | tristan: old plugins won't work anymore, will they? | 11:13 |
| tlater | Nexus: If you `export BST_FORCE_BACKEND=unix` any test you run afterwards should run using the unix platform | 11:13 |
| tristan | juergbi, they will not work with project.refs driven projects unless they implement that | 11:13 |
| tlater | Alternatively, you can use BST_FORCE_BACKEND=unix <command here> | 11:13 |
| juergbi | tristan: ah, in Source._load_ref(). right. makes sense | 11:13 |
| tlater | But the CI uses the former, so it's probably safer? Not sure exactly how setup.py interacts with env variables. | 11:13 |
| tristan | juergbi, tricky little dance yes... | 11:14 |
| * juergbi thinks we could use a similar approach for remote execution. potentially require plugin update if project enables remote execution | 11:14 | |
| tristan | juergbi, So last time we said; tracking recursively should be disabled across junctions by default | 11:14 |
| Nexus | SKIPPED... how odd | 11:14 |
| tlater | Nexus: If it's an integration test you need to enable it with --integration | 11:15 |
| tlater | Otherwise you might need to install something... | 11:15 |
| tlater | dpkg perhaps? | 11:15 |
| Nexus | AH HA | 11:15 |
| Nexus | tyError loading pipeline: Root privileges are required to run without bubblewrap. | 11:15 |
| tristan | juergbi, however I might not be able to escape "addressing junctioned elements", if say; I wanted to track a junction of a junction | 11:15 |
| skullman | 11:12 < skullman> Nexus: could be you need to run the test suite as root | 11:15 |
| Nexus | yup, trying that now | 11:16 |
| Nexus | passed. | 11:16 |
| Nexus | ... | 11:16 |
| * Nexus is sad | 11:16 | |
| tristan | juergbi, maybe first I need to support addressing junctioned elements | 11:16 |
| tristan | juergbi, maybe... it's not too hard ? | 11:17 |
| skullman | Nexus: sounds like a bug in the CI runner environment then | 11:17 |
| tlater | Yeah, this one will be hard to debug... | 11:17 |
| tlater | You should try running the tests in a docker container set up exactly the same way our CI does, then, Nexus | 11:17 |
| * tlater couldn't spot anything obvious that would cause issues in your test, so this will be necessary :( | 11:18 | |
| tristan | Nexus, tlater; alternatively; you might try pushing a branch to CI which adds the `-s` py.test option | 11:18 |
| juergbi | tristan: i don't think tracking a junction of a junction is more important than tracking a regular element via junction | 11:18 |
| tristan | juergbi, right; I was rather thinking of them as groups to track recursively, or not; but that is totally silly on my behalf | 11:19 |
| juergbi | and either one is mostly orthogonal to supporting optional recursive tracking across junctions | 11:19 |
| juergbi | i think we don't need to support tracking elements via junctions for project.refs to land but we should have a plan on how to handle it | 11:20 |
| tristan | juergbi, not *really* orthogonal, from a UX perspective, I think that if we have support to address elements; we may leverage that in the CLI | 11:20 |
| tristan | i.e. with --except options and such | 11:20 |
| tristan | Otherwise, How do you express what you want to track ? | 11:21 |
| tristan | Hmmm, good point | 11:21 |
| tristan | I like it | 11:21 |
| juergbi | ah, i was mostly thinking about having recursive tracking as a boolean but maybe that's not sufficient | 11:21 |
| juergbi | and tracking directly in subprojects would be via junction.bst:foo.bst | 11:22 |
| juergbi | but the two separate | 11:22 |
| juergbi | i'm not sure. the thing is junctions could be used in various ways, so it's difficult to figure out how users want to use them | 11:22 |
| tlater | tristan: Would a helper to remove a prefix from a string be acceptable in utils.sh? I keep finding myself wanting one. | 11:23 |
| tristan | Ok so (1) Dont support tracking across junctions at all (2) Support addressing of junctioned elements, useful for a lot of things, including workspaces and shells | 11:23 |
| tlater | s/sh/py/ | 11:23 |
| tristan | juergbi, and then (3) we add a boolean switch to enable cross-junction tracking, ... since (2) is already done; we can at that point support the regular --except options ? | 11:25 |
| tristan | tlater, I very dont like it; *where* do you find yourself wanting one ? | 11:25 |
| tlater | tristan: Stripping parts of pathnames :| | 11:25 |
| tristan | tlater, *where* | 11:25 |
| tristan | tlater, i.e. just in tests ? | 11:26 |
| tlater | tristan: Right now when trying to get Gio.File.get_path() to return a path that starts in the 'files' directory | 11:26 |
| Nexus | well it 100% passes locally as root, so, what do i need to do for the ``-s` py.test` idea? | 11:27 |
| tlater | I've had similar situations in the past - I suppose trying to use the path library is a better method, though | 11:27 |
| juergbi | tlater: os.path.relpath()? | 11:27 |
| tlater | Nexus: You'd modify .gitlab-ci.yaml to include -s, which would allow you to `print`, assuming the hang doesn't prevent that | 11:27 |
| tlater | juergbi: Oh, that might work! | 11:28 |
| juergbi | tristan: that could work, yes | 11:28 |
| tristan | juergbi, ok thanks for brainstorming, I have a short list of things I need to do for the initial branch now | 11:31 |
| tristan | What is buildstream-docker-images/image-tools ? | 11:38 |
| tlater | tristan: That's an image we built for using the imagex86 plugin | 11:39 |
| tlater | It contains all the image tools used in it :) | 11:39 |
| tristan | tlater, what is using it ? | 11:40 |
| tlater | One of our example projects that aren't yet committed | 11:40 |
| tristan | tlater, docker source + x86Image ? | 11:40 |
| tlater | I don't think we have an example for docker source yet | 11:41 |
| tlater | But the x86Image one does use it, yes | 11:41 |
| tristan | it must, because that cant be something used to run buildstream inside of | 11:41 |
| tristan | it would be good to have a maintainer of buildstream-docker-images soonish | 11:42 |
| tristan | right now it looks like we're using the fedora thing both for test and for bst-here; which was originally a good idea | 11:42 |
| tristan | right now we dont have a README in each directory explaining what these things are used for | 11:42 |
| tristan | we're running head on into "all purpose dumping grounds repo" territory | 11:43 |
| tristan | which... no thankyou. | 11:43 |
| Nexus | https://m.popkey.co/b907ae/Y0jgQ.gif | 11:43 |
| tlater | \o/ my updated-utime test passes | 11:54 |
| tlater | Pretty sure there are some edge cases that are still missing, but it's a POC :) | 11:54 |
| tristan | w00t https://gitlab.com/gitlab-org/gitlab-ce/issues/34899#note_62688320 \o/ | 11:54 |
| Nexus | hmm, it doesn't seem to output anything before it freezes. tlater, skullman | 11:55 |
| Nexus | the rest do, so it seems to be the first line? | 11:55 |
| tlater | Oh, that's awesome tristan :) | 11:56 |
| skullman | Nexus: it's possible it's buffering, try `sys.stdout.write("text")` then `sys.stdout.flush()`. | 11:56 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 12:02 |
| tristan | juergbi, there is one technical API break; maybe I should instead add Source.clear_ref() | 12:07 |
| tristan | juergbi, in a hurry, I just documented set_ref() to "Must support `None` value" | 12:07 |
| juergbi | hm, right | 12:08 |
| tristan | but then, set_ref(None) does seem reasonable to support | 12:08 |
| tristan | perhaps in this case it's a lesser evil to let it slide; less API | 12:08 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 12:14 |
| *** tristan has quit IRC | 12:14 | |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 12:27 |
| gitlab-br-bot | buildstream: merge request (jmac/remove-sequence-id->master: Remove sequence ID.) #309 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/309 | 12:32 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 12:38 |
| *** mcatanzaro has joined #buildstream | 12:46 | |
| *** ernestask has joined #buildstream | 12:49 | |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 12:49 |
| *** tristan has joined #buildstream | 13:00 | |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 13:02 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 13:03 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 13:17 |
| Nexus | jonathanmaw: Any thoughts as to why the CI for https://gitlab.com/BuildStream/buildstream/merge_requests/305 is still failing to find dpkg? | 13:19 |
| jonathanmaw | Nexus: it looks like none of the files changed in that MR are to .gitlab-ci.yml, so I think you're still using the old image | 13:21 |
| jonathanmaw | I think you need to go into .gitlab-ci.yml, and replace the version (after the colon) with "master-53-10fa1b4" | 13:22 |
| Nexus | ahh | 13:22 |
| Nexus | thanks, being dumb today apparently | 13:22 |
| jonathanmaw | (which I found out by looking at the CI job for the master branch of buildstream-docker-images, they call `docker images` and list the images available) | 13:22 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: WIP: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 13:25 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 13:27 |
| jmac | Just rebased !309, I believe it's ready to merge | 13:33 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 13:36 |
| *** aday has joined #buildstream | 13:44 | |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 13:47 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 13:48 |
| tlater | Are workspaces expected to be in the project directory now? | 14:22 |
| * tlater is a bit confused about this: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/source.py#L322 | 14:22 | |
| Nexus | is this something i did? | 14:24 |
| * tlater suspects this happened when we switched to element-wise workspaces | 14:25 | |
| tlater | Not sure if you were involved Nexus | 14:25 |
| * Nexus defaults to probably | 14:25 | |
| Nexus | i'm always involved when things don't make sense | 14:25 |
| tlater | I think I just missed some chat about this, between the various black weeks I've had | 14:27 |
| jennis | It was implemented on 12th of Dec 2017 | 14:27 |
| jennis | git show ed9b827d | 14:27 |
| Nexus | not me then | 14:28 |
| jennis | (: | 14:28 |
| * Nexus was thoroughly doc-ing at the time | 14:28 | |
| tlater | Yep, it's not Nexus' commit, none of his show up in blame on that file either :) | 14:29 |
| Nexus | \o/ | 14:29 |
| * Nexus is blameless | 14:29 | |
| jennis | My builds in gnome-build-meta aren't working since I pulled to the latest version | 14:31 |
| jennis | Getting an error like this: Error loading project: /home/jamesennis/bst_projects/gnome-build-meta/project.conf [line 117 column 2]: Unexpected key: shell | 14:31 |
| jennis | jjardon[m], are you able to use bst build in this project? | 14:31 |
| jjardon[m] | jennis: yes | 14:33 |
| jjardon[m] | you need to update your installed bst | 14:33 |
| jennis | by update do you mean, be up to date with origin/master...? | 14:34 |
| jennis | Because I am :/ | 14:34 |
| jjardon[m] | jennis: this is the bst version we are using | 14:35 |
| jjardon[m] | https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/.gitlab-ci.yml#L9 | 14:35 |
| jjardon[m] | jennis: somehow you are not :) | 14:35 |
| Nexus | Thought that img is going to be out of date soon | 14:36 |
| jennis | mhmm jjardon[m] even if I checkout that SHA and try to build I get the same error | 14:39 |
| jjardon[m] | jennis: have you tried "pip3 uninstall buildstream" first? | 14:39 |
| jennis | Didn't think I had to | 14:40 |
| jennis | because I used pip3 install --user -e when I installed it | 14:40 |
| jennis | But i'll try that anyway | 14:41 |
| tlater | jennis: A few things can happen. You could have multiple versions of buildstream installed in different locations, for example | 14:41 |
| tlater | This happens a lot with python dev... | 14:42 |
| Nexus | jennis: have you definitely indented `shell` properly? | 14:42 |
| * Nexus has to kep doing it as he has 2 buildstream repos that he messes with | 14:42 | |
| jennis | lol i'll try that | 14:42 |
| tristan | you dont have latest gnome-build-meta, because shell is on line 112, not 117: https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/project.conf#L112 | 14:43 |
| tristan | and if buildstream is too old, you should not get that error, because: https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/project.conf#L5 | 14:44 |
| tristan | it requires format version 5 | 14:44 |
| tristan | or 4 sorry | 14:44 |
| jennis | I've literally just cloned it though | 14:44 |
| jjardon[m] | jennis: in case it helps, docs to updagre bst here: https://buildstream.gitlab.io/buildstream/install.html#upgrading-buildstream-with-pip | 14:44 |
| * tristan interested to know what the underlying reason for this messup is | 14:45 | |
| jennis | yeah jjardon[m] that's what i've been going from | 14:45 |
| jennis | Following the `pip3 uninstall buildstream ... etc` has seemed to have fixed it | 14:46 |
| tristan | 117 *column 2* is `command`, there is no `shell` at column 2 anywhere, very strange | 14:46 |
| Nexus | tlater, skullman: It seems to hang when `capture.start_capturing()` is called | 14:46 |
| jjardon[m] | \o/ | 14:46 |
| tlater | Oh, that's pretty bad | 14:47 |
| Nexus | ? | 14:47 |
| * tlater thinks capture is part of pytest internals, no? | 14:47 | |
| Nexus | yes | 14:47 |
| skullman | sounds like output redirection gone weird | 14:47 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 14:48 |
| tlater | Nexus: This is probably deadlock with one of our helpers | 14:49 |
| tlater | We mess with some of that internal stuff to make sure the tests can do what we want them to do... | 14:49 |
| tlater | Hm, this is a while ago. | 14:49 |
| tlater | Nexus: If you can narrow down when exactly that occurs we can probably try and figure out why it happens | 14:51 |
| tlater | I suspect it will be here: https://gitlab.com/BuildStream/buildstream/blob/master/tests/testutils/runcli.py#L287 | 14:52 |
| Nexus | it happens exactly on ln 299 | 14:54 |
| tlater | Nexus: Right, but it's more knowing about the state around this | 14:55 |
| tlater | E.g. what sys.stdin is at the time etc. | 14:55 |
| tlater | Nexus: Figuring out how capture works might help you: https://github.com/pytest-dev/pytest/blob/master/_pytest/capture.py | 14:55 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 14:58 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 15:08 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 15:13 |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: WIP: Add versioning to workspaces yaml configuration) #313 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/313 | 15:20 |
| Nexus | I'm at a loss :/ | 15:27 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 15:28 |
| Nexus | tlater: I'm not sure what's causing it to fail, but its the only test that does :/ | 15:44 |
| tlater | All other tests just succeed? | 15:44 |
| Nexus | yes | 15:44 |
| Nexus | i removed the test to find out, and everything else is fine | 15:44 |
| tlater | Hrm... | 15:45 |
| tlater | Could you link me to that test case again? | 15:45 |
| Nexus | https://gitlab.com/BuildStream/buildstream/blob/master/tests/integration/script.py#L113 https://gitlab.com/BuildStream/buildstream/merge_requests/310/diffs | 15:46 |
| skullman | Nexus: https://github.com/pytest-dev/pytest/blob/master/_pytest/capture.py#L554 is a potential smoking gun. If the version of pytest is older than that code it might be what's going wrong. | 15:48 |
| skullman | tlater: I updated my merge-request to add an exception should anyone attempt to delete a workspace called "version". You should rebase. | 16:17 |
| skullman | it… appears to pass tests, but I'm having environmental issues with running the whole suite. It's either running out of memory or disk space (probably not disk space since I made sure to extend my drives) since it's also killing my web browsers. | 16:18 |
| skullman | it passes on GitLab CI | 16:18 |
| * skullman reboots in case something is holding onto file desriptors or too much memory | 16:18 | |
| *** aday has quit IRC | 16:56 | |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 16:58 |
| *** toscalix has quit IRC | 17:11 | |
| *** xjuan has joined #buildstream | 17:14 | |
| jjardon[m] | Hi, I think one of the plans for buildstream is to be able to build flatpaks (so replacing flatpack builder); is this correct? I'm asking because I do not see any issue to track this | 17:20 |
| *** mcatanzaro has quit IRC | 17:29 | |
| *** jonathanmaw has quit IRC | 18:16 | |
| *** dominic has quit IRC | 18:19 | |
| *** jennis has quit IRC | 18:20 | |
| *** valentind has joined #buildstream | 18:23 | |
| milloni | is Nexus around? | 18:32 |
| *** ernestask has quit IRC | 19:28 | |
| *** xjuan has quit IRC | 21:58 | |
| *** xjuan has joined #buildstream | 23:28 | |
| *** Prince781 has joined #buildstream | 23:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
