| *** noisecell has joined #buildstream | 08:37 | |
| *** valentind has joined #buildstream | 08:55 | |
| *** bethw has joined #buildstream | 09:19 | |
| *** tiago has quit IRC | 09:36 | |
| *** tiago has joined #buildstream | 09:45 | |
| *** valentind has quit IRC | 09:46 | |
| *** jonathanmaw has joined #buildstream | 09:48 | |
| *** bethw has quit IRC | 09:52 | |
| *** ssam2 has joined #buildstream | 10:16 | |
| gitlab-br-bot | buildstream: merge request (jonathan/bzr-source-method->master: Jonathan/bzr source method) #242 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/242 | 10:59 |
|---|---|---|
| *** cs_shadow has joined #buildstream | 11:00 | |
| ssam2 | juergbi, is there a way to have a 'junction' element work when the project.conf is not at the top level of the repo ? | 11:06 |
| ssam2 | i wanted to try building gnome-build-meta against the sdk project from https://gitlab.com/freedesktop-sdk/freedesktop-sdk | 11:06 |
| ssam2 | using the sam/use-recursive-pipelines branch did for that project | 11:06 |
| ssam2 | but seems impossible to use it because the project that I need is in the sdk/ subdirectory | 11:07 |
| juergbi | hm, no, i don't think this is currently possible | 11:07 |
| juergbi | we can't specify a subdirectory in the git source | 11:07 |
| juergbi | and there is no junction-specific way to specify a patch | 11:07 |
| juergbi | adding a junction config for this would likely be fairly simple, though | 11:08 |
| ssam2 | ah right, so like a 'project-subpath' option that would go in the `config` section ? | 11:08 |
| juergbi | might be useful as alternative to the ../ paths we're about to disallow | 11:08 |
| ssam2 | seems logical | 11:08 |
| juergbi | yes, unlike build elements where you can handle such thing via commands, we need explicit config option in the case of junctions | 11:09 |
| ssam2 | i can have a go at a patch | 11:11 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 11:11 |
| juergbi | thanks | 11:20 |
| gitlab-br-bot | buildstream: merge request (issue-166_yaml_removing_underscores->master: WIP: Issue 166 yaml removing underscores) #245 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/245 | 11:34 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 11:47 |
| tlater | ssssam: Why were your tests not possible using the old-style integration tests? | 12:09 |
| tlater | Was it down to symlinks not being tracked correctly? | 12:10 |
| tlater | Sorry, ssam2 ^ | 12:13 |
| ssam2 | it's because i wanted to detect the error raised by symlinks pointing outside the sandbox | 12:22 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 12:22 |
| ssam2 | the old test framework didn't support 'expected fail' tests | 12:22 |
| tlater | Ah, right, yeah, that would have been difficult | 12:22 |
| *** tlaxkit has joined #buildstream | 12:23 | |
| jmac | ssam2: https://gitlab.com/BuildStream/buildstream/merge_requests/248 is the MR I mentioned to you earlier. It appears to have a pipeline failure which I'm unsure how to interpret. | 12:30 |
| tlater | jmac: the 'source_dist' job may be failing due to the changes to the cache that are about to happen | 12:31 |
| jmac | Right. | 12:32 |
| tlater | Sorry if that's disrupting, clearing the runner cache should solve these issues - maybe I should look into using a separate cache | 12:32 |
| jmac | I noticed when I fork a repo on gitlab, it still tried to run automated tests on my local copy - is that normal? | 12:32 |
| ssam2 | what do you mean by 'local copy' ? | 12:32 |
| tlater | Yup, when you clone it you copy the .gitlab-ci.yaml | 12:32 |
| ssam2 | ah, the copy in your personal gitlab account ? | 12:33 |
| jmac | Yes | 12:33 |
| jmac | But presumably the existing runners won't pick that up | 12:33 |
| ssam2 | right. what tlater said :-) | 12:33 |
| ssam2 | but yes, runners are enabled per-project | 12:33 |
| ssam2 | so you will get the tests running on the GitLab CI free-to-use runners | 12:33 |
| ssam2 | which are slower and have 1 hour timeouts, so things might fail due to that | 12:33 |
| ssam2 | although you can configure the timeout | 12:34 |
| * tlater remembers he can do that and avoids testing with the main cache from here on | 12:34 | |
| jmac | GitLab gives out free test running VMs? That's generous | 12:34 |
| ssam2 | indeed | 12:34 |
| jmac | My DogeCoin mining code needs lots of testing | 12:36 |
| ssam2 | yes, i don't know how they deal with that | 12:36 |
| ssam2 | presumably just manual review of projects using high CPU | 12:36 |
| *** xjuan has joined #buildstream | 12:47 | |
| tlater | Hm. I'm not sure why my cache files aren't being uploaded | 12:54 |
| ssam2 | juergbi, should i do a merge request for the junction element 'path' option or do you want to review and cherry pick it directly into your branch ? | 12:54 |
| ssam2 | it's pushed as sam/recursive-pipelines-in-subdir either way | 12:54 |
| tlater | I've checked a few times now, there should be something in the directory I'm trying to cache | 12:55 |
| juergbi | ssam2: i think the latter makes more sense, ta | 12:55 |
| tlater | Is it possible that the gitlab runner clears /tmp if it gets too full or something? | 12:57 |
| ssam2 | are you trying to cache stuff from /tmp ? | 12:58 |
| tlater | ssam2: Yup, trying to change that now | 13:00 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 13:09 |
| tlater | ssam2: About the docker images... Do you want to keep with the '-' names? I.e., something like buildstream/testsuite-debian-8? | 13:11 |
| ssam2 | yeah | 13:12 |
| ssam2 | although, testsuite-debian | 13:12 |
| ssam2 | with tag :8 | 13:12 |
| tlater | Right, yeah, that makes sense | 13:13 |
| ssam2 | i guess we could do testsuite:debian8; but it would be inconsistent with the existing buildstream-fedora image | 13:14 |
| ssam2 | and also the UI for managing tags isn't that great, so if we have one image with loads of different tags it'll probably be confusing | 13:14 |
| * tlater wonders how to do this without exploding the .gitlab-ci.yaml file | 13:14 | |
| ssam2 | you should only have to add a couple of lines | 13:14 |
| ssam2 | one to call `docker build`, and two to call `docker push` | 13:15 |
| ssam2 | although i wonder if the 'fixed tag, moving tag' concept is even relevant here | 13:15 |
| tlater | Yeah, but if we're going to have more platforms this will get a bit messy | 13:15 |
| ssam2 | the idea of having a 'moving tag' for the buildstream-fedora image was so that people could pull 'latest' | 13:15 |
| tlater | This seems entirely pointless for a testuite image | 13:15 |
| ssam2 | but the testsuite image will only be used by gitlab-ci, where we'll never want to do that | 13:15 |
| ssam2 | yeah | 13:15 |
| ssam2 | i don't think gitlab-ci.yml will get too messy if we have a few more distro bases | 13:16 |
| tlater | I suppose we can cross that bridge when we get there anyway | 13:16 |
| ssam2 | i'd be as worried the effort of maintaining all those different bases every time we have a change in our dependency set | 13:16 |
| ssam2 | *about the effort | 13:16 |
| ssam2 | long term distros should just package buildstream ! | 13:17 |
| tlater | Well, even then we'd have to install the dependencies rather than buildstream itself | 13:17 |
| tlater | I guess most package managers will have neat ways to express that though | 13:17 |
| ssam2 | at that point one would assume the distros would run our testsuite for us. although i guess it'd still be good for us to also do taht | 13:18 |
| ssam2 | *that | 13:18 |
| persia | Packaged buildstream will just have the dependencies, automated by distro packaging. | 13:18 |
| tlater | persia: I was considering our testing environments, in case we're doing stuff like solaris testing | 13:19 |
| persia | But upstream, we'll still want to test things raw, possibly on a few platforms, so that if we have a change that breaks on platform X, we'll know that before the distro folk get around to checking upstream (or maybe decide not to update because it would be hard). | 13:19 |
| persia | tlater: For testing environments, I think we never want to use packaged buildstream and I think we need to verify dependencies: even if they are installed, the versions might be off. | 13:19 |
| gitlab-br-bot | buildstream: merge request (issue-166_yaml_removing_underscores->master: WIP: Issue 166 yaml removing underscores) #245 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/245 | 13:20 |
| tlater | That in turn would be a bit of a maintenance overhead, as ssam2 says, if we start testing on many platforms - but I suppose we'll see where that goes | 13:20 |
| tlater | I don't think we'll change our dependencies that often from here on out | 13:21 |
| ssam2 | does the new testsuite image install buildstream? i think it shouldn't do | 13:21 |
| paulsherwood | famous last words | 13:21 |
| * tlater was thinking that typing it out | 13:21 | |
| tlater | ssam2: It doesn't, having an installed buildstream has bitten us before | 13:21 |
| ssam2 | great | 13:21 |
| gitlab-br-bot | buildstream: merge request (issue-166_yaml_removing_underscores->master: WIP: Issue 166 yaml removing underscores) #245 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/245 | 13:24 |
| tlater | Hm, thinking about it, what if we change our testsuite images? | 13:28 |
| tlater | Should we move the tag ahead, or do we want to keep a log of testsuite images? | 13:28 |
| ssam2 | right | 13:28 |
| ssam2 | it's probably better to reuse the 'fixed tag' logic used for the other images | 13:29 |
| ssam2 | but maybe prepend the distro version too | 13:29 |
| tlater | And then have multiple moving tags that specify the "current" version? | 13:29 |
| ssam2 | so we have e.g 8-${number of commits in repo}-${sha1 of HEAD} | 13:29 |
| ssam2 | where we're going, we don't need moving tags | 13:29 |
| tlater | Well, the CI will only want to specify 'this tests debian-8' | 13:30 |
| ssam2 | no, the CI will want to specify "use this exact version of our debian-8 base image" | 13:30 |
| tlater | In fact, I think that will be necessary unless we want to update buildstream's ci config every time we make a new commit | 13:30 |
| ssam2 | that's exactly what tristan wants | 13:30 |
| ssam2 | so that the only thing that can possibly break the CI is commits to buildstream itself | 13:30 |
| tlater | That will make using the CI very cumbersome :| | 13:31 |
| ssam2 | this is how it already works | 13:31 |
| ssam2 | and i agree that it would be nice to avoid having to update a bunch of tag names each time we need to change something in the base images | 13:32 |
| ssam2 | but i have already discussed this with tristan in the past; and i do see his point | 13:32 |
| * tlater forgot that the images don't have buildstream baked-in | 13:32 | |
| tlater | Yeah, that seems alright then | 13:32 |
| gitlab-br-bot | buildstream: merge request (issue-166_yaml_removing_underscores->master: WIP: Issue 166 yaml removing underscores) #245 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/245 | 13:38 |
| * tlater wonders if we should enable per-branch caching | 13:46 | |
| tlater | On the one hand that would slow down CI in some cases | 13:46 |
| tlater | Specifically, the first commit to a branch | 13:47 |
| tlater | But on the other hand, it would keep these branch problems in check | 13:47 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 13:55 |
| tlater | ssam2: I put an MR for my debian-8 image up: https://gitlab.com/BuildStream/buildstream-docker-images/merge_requests/17 | 13:57 |
| gitlab-br-bot | buildstream: merge request (issue-166_yaml_removing_underscores->master: WIP: Issue 166 yaml removing underscores) #245 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/245 | 14:03 |
| *** saxa has joined #buildstream | 14:06 | |
| ssam2 | tlater, per-branch caching might be an idea | 14:18 |
| ssam2 | my main worry would be that as long as we're using a needlessly enourmous sysroot for the integration-tests, that will add up to many GBs of caches | 14:18 |
| ssam2 | and the cache server is only of limited size | 14:18 |
| ssam2 | but you'd expect that it would have some way of expiring artifacts when the disk is full | 14:19 |
| ssam2 | that said, you'd also expect that from buildstream caches but actually they don't do that yet :-) | 14:19 |
| ssam2 | i'll look at your MR | 14:19 |
| tlater | ta :) | 14:19 |
| * tlater is still struggling to get gitlab to accept his cache :| | 14:20 | |
| * jmac wonders when he'll stop typing "BuildSteam" | 14:21 | |
| tlater | jmac: That's a nice name for the optimization branch | 14:21 |
| *** mcatanzaro has joined #buildstream | 14:36 | |
| * tlater assumes gitlab is broken since it complains about files not existing that never should exist. | 14:47 | |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 14:48 |
| ssam2 | tlater, you need to create the buildstream/testsuite-debian image on Docker Hub | 14:48 |
| * tlater created that file | 14:48 | |
| ssam2 | the CI is failing because it can't push there because it doesn't exist | 14:48 |
| tlater | Ah | 14:48 |
| ssam2 | it's not a file, you have to go on the web interface on hub.docker.com | 14:48 |
| tlater | Let me check why that's failing | 14:48 |
| tlater | s/file/image/ | 14:49 |
| ssam2 | hmm, yes you did | 14:49 |
| ssam2 | maybe that's an old build ? this is weird | 14:49 |
| ssam2 | ah, i know the issue | 14:50 |
| ssam2 | initially the image has nobody allowed to push to it | 14:50 |
| ssam2 | if you go on the image and then the "collaborators" tag | 14:50 |
| ssam2 | you can give write access to certain "Teams" | 14:50 |
| ssam2 | the CI is a member of the "Automation" team so give that write access | 14:50 |
| ssam2 | s/tag/tab/ | 14:50 |
| tlater | Ah | 14:50 |
| tlater | Should be set now | 14:51 |
| tlater | I assume read/write is enough? | 14:51 |
| ssam2 | yeah | 14:51 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 14:56 |
| ssam2 | this is annoying; my machine spent 90 minutes building LLVM, failed during install-commands because my disk got full | 14:57 |
| ssam2 | now i have to spend another 90 minutes building it again from scratch | 14:57 |
| tlater | Perhaps we could work around that issue by pausing a build if we run out of disk space, allowing the user to deal with whatever | 15:09 |
| tlater | Then again, it's run in the sandbox, so not actually trivial :| | 15:09 |
| ssam2 | yeah, the out-of-disk-space error was from 'make install', so buildstream just saw a non-zero exit code | 15:09 |
| ssam2 | what would have helped would be a 'retry but starting from install-commands' option | 15:10 |
| ssam2 | there's a possible reproducibility issue there though ... it's fine if we assume that all buildsystems are free from bugs, but if we accept that they are not then we have to accept that the results of rerunning 'make install' after an initially failed 'make install' may not be the same as running a clean 'make install' | 15:10 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 15:11 |
| tlater | Hm, yeah, that's annoying... | 15:11 |
| tlater | I suppose this wouldn't be fixed by artifact cache management either, since we can't predict how much space a build will need | 15:12 |
| ssam2 | yeah, LLVM is humoungous | 15:12 |
| ssam2 | hence why i ran out of space | 15:12 |
| tlater | I guess this is "not buildstream's problem" - it's that no build systems manage to work around this issue nicely | 15:13 |
| ssam2 | what might have been useful is a 'warning: your failed builds directory is taking up 35GB of space, do you want to sort that out" | 15:13 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 15:15 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 15:28 |
| gitlab-br-bot | buildstream: issue #202 ("Build of gnome-build-meta.git is broken") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/202 | 15:30 |
| ssam2 | juergbi, any ideas about https://gitlab.com/BuildStream/buildstream/issues/202 ? | 15:32 |
| juergbi | ssam2: your patch looks good to me, will add it to the MR | 15:32 |
| ssam2 | thanks (after i finally fixed the style errors :-) | 15:33 |
| juergbi | let me take a look | 15:33 |
| ssam2 | it seems something element-state related, I haven't dug into it yet | 15:33 |
| nexus | For issue 191 https://gitlab.com/BuildStream/buildstream/issues/191 Would it be an option to always return a relative path? whether it is a subdirectory or not? | 15:33 |
| ssam2 | I might need a bit more context to be able to answer that | 15:34 |
| ssam2 | but if this is about recording workspace path relative to project dir ... what happens if the project dir moves but the workspace does not ? | 15:34 |
| juergbi | ssam2: commit 43bc41b from the log is missing my two fixes that i pushed to master last week | 15:35 |
| juergbi | can you retry with that? | 15:35 |
| juergbi | although, it also doesn't have my source state patch, so it shouldn't actually need those fixes | 15:36 |
| ssam2 | oops, yeah i had the wrong branch checked out | 15:37 |
| ssam2 | it happened on master too though | 15:37 |
| ssam2 | just reproduced with f490343d98e40f9c9b651aa02f351d0bbee9afd9 | 15:37 |
| juergbi | ssam2: does it only happen with --no-strict? | 15:39 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 15:39 |
| juergbi | i can take a look if it's reproducible. i'll be boarding in a few minutes, though | 15:40 |
| ssam2 | juergbi, yes | 15:40 |
| ssam2 | no worries, i can dig into it | 15:40 |
| juergbi | ta | 15:40 |
| ssam2 | it's only with --no-scrict | 15:40 |
| ssam2 | just wondered if you had any pointers | 15:40 |
| juergbi | either _update_state() is not called between the point where the cache key became calculatable and when bst attempts to use the cache key for pulling | 15:41 |
| juergbi | or it's called and for some reason fails to calculate the cache key. i.e., one of the prereqs for that calculation are not available | 15:41 |
| ssam2 | ok | 15:42 |
| juergbi | might need some debug prints in that function | 15:42 |
| ssam2 | it seems like it shouldn't pull base.bst at all until it can calculate the cache key | 15:42 |
| ssam2 | but, the refs for the base/ elements are actually all there | 15:42 |
| ssam2 | it's weird that it shows them all as ????? | 15:42 |
| ssam2 | it doesn't do that in strict mode | 15:42 |
| juergbi | well, with --no-strict, it's sufficient to have the weak cache key | 15:43 |
| ssam2 | right; but it actually has both for those elements | 15:43 |
| juergbi | it won't know the strong cache key until it has actually pulled the artifact | 15:43 |
| ssam2 | ah I guess it doesn't bother to calculate strong keys in --no-strict mode, even if it can ? | 15:43 |
| juergbi | the strange thing is that it should only be pulling if it knows that the remote server actually has the artifact | 15:43 |
| juergbi | and that can only be the case if the (weak) cache key is known already | 15:44 |
| ssam2 | right ... it can be known though, because the refs for the base/* elements are committed in the repo | 15:44 |
| ssam2 | so maybe something is going wrong when it tries to calculate the cache key | 15:44 |
| ssam2 | for base.bst | 15:44 |
| ssam2 | i'll start by tracing that | 15:44 |
| juergbi | or maybe it tries to use the strong cache key too early even when it should only just use the weak one | 15:45 |
| juergbi | maybe our test coverage of non-strict mode is insufficient | 15:45 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 15:45 |
| ssam2 | looks that way | 15:45 |
| * tlater did notice that looking at coverage reports | 15:46 | |
| juergbi | boarding has started... | 15:47 |
| ssam2 | safe trip | 15:47 |
| nexus | o/ | 15:48 |
| nexus | ssam2: did you see my question? :) | 15:48 |
| ssam2 | yes, did you see my answer ? | 15:48 |
| nexus | no | 15:50 |
| nexus | hmm | 15:50 |
| ssam2 | the 2 lines after you spoke were directed at you | 15:50 |
| nexus | ah | 15:50 |
| nexus | hmm | 15:52 |
| * nexus goes back to the drawing board | 15:52 | |
| nexus | i was hoping to find a way of dealing with all workspaces in the same way, but that probably isn't possible | 15:54 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 15:55 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 15:56 |
| nexus | To me then, that would make a combination of os.path.abspath and os.path.relpath the best option. Something like https://paste.codethink.co.uk/?3866 | 16:00 |
| *** noisecell has quit IRC | 16:07 | |
| gitlab-br-bot | buildstream: merge request (skip-configure-tests->master: Workspaced builds only run configure commands once) #191 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/191 | 16:17 |
| gitlab-br-bot | buildstream: merge request (issue-166_yaml_removing_underscores->master: WIP: Issue 166 yaml removing underscores) #245 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/245 | 16:37 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 16:49 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 16:55 |
| * tlater apologizes for the noise, gitlab CI is a fickle beast | 16:55 | |
| * nexus knows the feels | 16:55 | |
| ssam2 | this logic for loading strict cache key from the artifact is pretty broken | 17:06 |
| ssam2 | the first thing it does is call OSTreeCache.extract() | 17:06 |
| ssam2 | and the first thing that does is call Element._get_strict_cache_key() | 17:07 |
| ssam2 | which is exactly the thing we don't know until we extract the artifact | 17:07 |
| ssam2 | oh, seems i can just make the call to Element._get_strict_cache_key() conditional | 17:07 |
| ssam2 | we are definitely missing test coverage here ... | 17:07 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 17:08 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 17:15 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 17:27 |
| gitlab-br-bot | buildstream: merge request (issue-166_yaml_removing_underscores->master: Issue 166 yaml removing underscores) #245 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/245 | 17:37 |
| tlater | Gah, I screwed up and forgot to test if an sdist works with the debian image | 17:53 |
| gitlab-br-bot | buildstream: merge request (sam/fix-202->master: Fix breakage when running in no-strict mode with --track-all and an existing remote cache) #250 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/250 | 17:57 |
| ssam2 | tiago, https://gitlab.com/BuildStream/buildstream/merge_requests/250 hopefully fixes that issue | 17:58 |
| ssam2 | juergbi, i will be interested in your thoughts on that fix as well | 17:58 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 18:01 |
| gitlab-br-bot | buildstream: merge request (issue-191_relative_workspaces->master: Patch for issue #191 support relative workspaces) #251 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/251 | 18:04 |
| gitlab-br-bot | buildstream: merge request (issue-191_relative_workspaces->master: WIP: Patch for issue #191 support relative workspaces) #251 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/251 | 18:04 |
| nexus | oops | 18:04 |
| *** ssam2 has quit IRC | 18:13 | |
| *** tlaxkit has quit IRC | 18:29 | |
| *** jonathanmaw has quit IRC | 18:41 | |
| *** valentind has joined #buildstream | 18:46 | |
| *** valentind has quit IRC | 21:57 | |
| *** cs_shadow has quit IRC | 22:27 | |
| *** noah has joined #buildstream | 23:03 | |
| *** mcatanzaro has quit IRC | 23:05 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!