| *** mcatanzaro has quit IRC | 02:57 | |
| *** tristan has quit IRC | 05:40 | |
| *** tristan has joined #buildstream | 06:09 | |
| gitlab-br-bot | buildstream: merge request (delay-pkg-resources-import->master: Delay import of pkg_resources) #232 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/232 | 06:31 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (sam/improve-cache-warnings->master: Shorten the warnings raised when remote cache initialization fails) #235 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/235 | 07:27 |
| *** ChanServ sets mode: +o tristan | 07:31 | |
| *** tristan changes topic to "BuildStream 1.0.1 is out ! | https://gitlab.com/BuildStream/buildstream | Docs: https://buildstream.gitlab.io/buildstream | IRC logs: https://irclogs.baserock.org/buildstream | Roadmap: https://wiki.gnome.org/Projects/BuildStream/Roadmap" | 07:32 | |
| *** ernestask has joined #buildstream | 07:39 | |
| gitlab-br-bot | buildstream: merge request (juerg/recursive-pipelines->master: WIP: Junctions and subprojects) #160 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/160 | 08:00 |
| gitlab-br-bot | buildstream: issue #192 ("Support for incremental builds for workspaces") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/192 | 08:09 |
| tlater | Hm, looks like the final unix integration test fails with "No space left on device" - wasn't this an issue at some point before? | 08:44 |
| gitlab-br-bot | buildstream: merge request (juerg/recursive-pipelines->master: WIP: Junctions and subprojects) #160 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/160 | 08:56 |
| tristan | tlater, I dont recall it ever arising... still perhaps it's easily fixable with some config... jjardon[m] any thoughts on "No space left on device" issues for gitlab jobs ? | 09:01 |
| tlater | It's possible that we actually *do* run out of space, since the artifact caches aren't shared. | 09:03 |
| tristan | tlater, I'm not refuting that | 09:04 |
| *** noisecell has joined #buildstream | 09:09 | |
| tristan | tlater, ... | 09:10 |
| tristan | tlater, now I recall we did have that issue before | 09:11 |
| tristan | tlater, check the gitlab output before tests begin, iirc there is a `df -h` output to see there | 09:11 |
| tristan | tlater, then; make sure that you are in fact using the huge volume where it is appropriate to put stuff, and not the tiny volume where it would fail. | 09:12 |
| tristan | tlater, if that's not the issue, then we need more space at least until tiny runtimes are delivered. | 09:12 |
| persia | My understanding was that we already fixed that to be the right location, although I may be mistaken. | 09:13 |
| tlater | Right, I knew there was something about the file system | 09:14 |
| * tlater may have reintroduced that bug accidentally, even if it's unlikely | 09:14 | |
| 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 | 09:15 |
| tristan | persia, as tlater is exactly playing around with the .gitlab-ci.yml in likely violent ways, it's a reasonable possibility that he broke that | 09:19 |
| tristan | anyway worth a check. | 09:19 |
| persia | Indeed | 09:19 |
| gitlab-br-bot | buildstream: issue #193 ("RFE: Add timestamp to show the time that have passed since the build started") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/193 | 09:21 |
| tlater | That looks to indeed be the issue, although looking at the old .gitlab-ci.yaml this has been a problem for a while | 09:25 |
| tlater | Did we previously move the project directory to /cache or did something else change? | 09:25 |
| persia | Maybe I misremember it being fixed (e.g. it was fixed in a downstream project), or maybe it was unfixed previously? | 09:26 |
| tlater | I recall ssam2 fixing it, but we have made a lot of changes to the test suite since | 09:27 |
| tlater | It's possible someone removed the fix, but we've been more efficient with caching since | 09:27 |
| * tlater checks commit history | 09:29 | |
| tlater | Hm, no, there never was an explicit fix | 09:30 |
| * tlater waits until ssam2 appears before he mucks too much with this | 09:30 | |
| persia | It may have happened in a downstream project. | 09:33 |
| tristan | The cache downloads have been failing a lot lately, I have written it off as "gitlab unstable as usual", but it's possible we broke it some how on our side too. | 09:35 |
| persia | jjardon[m] has been complaining about load on the cache server, which may be related. | 09:36 |
| * tlater hasn't witnessed successful cache up/downloads for a while, I think it's broken | 09:36 | |
| tristan | No | 09:36 |
| tristan | persia, you are mixing up your caches | 09:37 |
| tristan | have your caches crossed :) | 09:37 |
| jjardon[m] | tristan: gitlab cache or bst cache? Do you have a link to the error? | 09:37 |
| tlater | gitlab cache | 09:37 |
| * tlater digs up a recent test run | 09:38 | |
| tristan | jjardon[m], I *think* tlater has assessed that it is not a problem with gitlab config or lack of GB on disk | 09:38 |
| tlater | jjardon[m]: We seem to be incapable of up/downloading caches though: https://gitlab.com/BuildStream/buildstream/-/jobs/48005346 | 09:39 |
| tristan | <tlater> That looks to indeed be the issue, although looking at the old .gitlab-ci.yaml this has been a problem for a while | 09:39 |
| tristan | My guess from the above comment ^^^ | 09:39 |
| tlater | Yes, that to :) | 09:39 |
| tristan | But, there are 2 separate issues now at play | 09:39 |
| tristan | so dont cross subjects please | 09:39 |
| tristan | :) | 09:39 |
| *** jonathanmaw has joined #buildstream | 09:39 | |
| * tristan walks away in the knowledge that tlater and jjardon[m] will now talk about the same thing | 09:39 | |
| jjardon[m] | mmm, I think the cache server is not running | 09:44 |
| jjardon[m] | tlater: tristan try again and let me know if its still failing | 09:50 |
| tlater | ta jjardon[m] | 09:50 |
| tlater | jjardon[m]: Yes, looks like downloading works fine, so I assume an upload will complete successfully too | 09:51 |
| tristan | Interesting that we have multiple things flying around which can all be called a "cache server" | 09:52 |
| jjardon[m] | \o/ I think maybe someone restarted the server and forgot to restart the S3 server | 09:52 |
| tristan | tlater, yeah last time we broke the gitlab cache downloads, it was because we were not uploading anything (wrong directory) | 09:53 |
| tristan | So assuming we successfully upload at the end, then .gitlab-ci.yml is also correct and subsequent downloads should work | 09:53 |
| * tlater had that on his branch for a little while, but made sure to fix it, so we should be good | 09:53 | |
| tristan | juergbi, if you could proof read my comment on gitlab, that would be appreciated | 10:17 |
| tristan | juergbi, https://gitlab.com/BuildStream/buildstream/merge_requests/126?commit_id=dd13c9396676fb70ce5aec51fb8e84816048635d#note_54674298 | 10:17 |
| juergbi | ok | 10:17 |
| tristan | juergbi, context; incremental workspace builds and cache keys | 10:17 |
| tristan | it's a tricky beast, and I think I came up with the elegant solution, just wanted to have you weigh in | 10:17 |
| tristan | and see if I've overlooked something critical | 10:18 |
| *** ssam2 has joined #buildstream | 10:18 | |
| juergbi | btw: i've pushed !230 yesterday for the source state stuff | 10:18 |
| tristan | I noticed :) | 10:18 |
| juergbi | s/pushed/opened/ | 10:18 |
| tristan | I've been swimming through so many comments/merge requests/issues/emails today it's crazy | 10:18 |
| juergbi | yes, i understand | 10:19 |
| gitlab-br-bot | buildstream: issue #194 ("Pin Jinja2 to use at least 2.10") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/194 | 10:20 |
| juergbi | tristan: that approach makes sense to me. we may need a helper variable to avoid doing the 'calculate cache key and then discard' dance multiple times, but i don't see any fundamental issue with this | 10:25 |
| *** valentind has quit IRC | 10:25 | |
| tristan | juergbi, thanks | 10:26 |
| juergbi | also need to explicitly reset that once the build has actually completed (probably twice, once in subprocess and once in main process) | 10:26 |
| tristan | oh ? | 10:26 |
| juergbi | that said, i still hope that long-term we can avoid using the build output for cache key calculations in typical cases, but that's an improvement for the future | 10:27 |
| tristan | I was thinking, rather even than resetting it, we do the first round as "only assign the key if it's actually cached" | 10:27 |
| juergbi | _update_state() as is doesn't know whether it's the first time | 10:28 |
| tristan | Yes, for my proposed approach it may require state | 10:28 |
| juergbi | that's all i meant, it's not an issue | 10:28 |
| tristan | and adding an enum "why" argument to _update_state() might not be able to solve it without state | 10:29 |
| juergbi | i don't think we need 'why' for this aspect | 10:29 |
| juergbi | so i would rather not add it to keep the API as simple as possible | 10:29 |
| juergbi | we might need it for other things, would have to see | 10:29 |
| tristan | In the preceding comment: https://gitlab.com/BuildStream/buildstream/merge_requests/126?commit_id=dd13c9396676fb70ce5aec51fb8e84816048635d#note_54495313 | 10:30 |
| tristan | I think I found a use for it to allow carrying less state | 10:30 |
| juergbi | will take a look in a bit | 10:31 |
| tristan | if (foo and not (bar or baz) or (bar and (foo and not baz))): ... tends to grow irrationally fast | 10:31 |
| *** tlater has left #buildstream | 10:39 | |
| *** tlater has joined #buildstream | 10:40 | |
| gitlab-br-bot | buildstream: issue #193 ("RFE: Add timestamp to show the time that have passed since the build started") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/193 | 10:43 |
| juergbi | tristan: hm, i think i'd prefer a state variable to conditions such as: stage in ('BUILD INIT', 'BUILD READY') | 10:57 |
| juergbi | depending on how update_state() evolves it may need additional comments or maybe factoring some parts out, but i consider overall complexity lower without the stage parameter | 10:58 |
| tristan | juergbi, my gut disagrees with you completely, rather I feel that using all existing context and resolving on the fly trumps added cached variables which need to be updated and consulted every time | 11:06 |
| tristan | juergbi, but I suppose only history will be the judge :) | 11:06 |
| juergbi | tristan: my worry is that with the large list of stages developers won't have an overview of what's needed when | 11:09 |
| juergbi | as conditions may depend on both stage and state, then | 11:10 |
| juergbi | (you can't get rid of state completely) | 11:11 |
| juergbi | i.e., you'll have quadratic complexity | 11:11 |
| juergbi | update_state is essentially a state machine. maybe we can do it a bit more explicit and in that case such variables would no longer look like 'cached variables' | 11:14 |
| persia | Explicit state machines are much easier to comprehend than implied state machines. | 11:15 |
| juergbi | can't think of a simpler approach for this right now, though | 11:15 |
| tristan | You can't get rid of state, but you can try... Probably also, an Enum declaring every reason for which Element._update_state() can be called, listed in order, and coupled with a few hundred line comment explaining the rationale, would be beneficial; even if it were never used by the code. | 11:15 |
| juergbi | persia: i agree. am i forgetting a really simple way to do this more explicitly without boilerplate or extra tools? | 11:17 |
| juergbi | tristan: the thing is update_state() doesn't really care from what bst stage it's called. it just calculates whatever can be calculated based on what happened since the last call | 11:19 |
| gitlab-br-bot | buildstream: merge request (jjardon/jinja->master: setup.py: Require jinja >= 2.10) #239 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/239 | 11:19 |
| tristan | juergbi, and the fact that it's a central location where a parameter could be added to indicate the event for which it is called, was one of the very attractive things about the patch. | 11:20 |
| juergbi | so if you add the stage aspect, you have to think about a lot more aspects (which bst stage influences elements in such a way that something has to be calculated) | 11:20 |
| tristan | I realize it does not take advantage of this aspect at the moment in master | 11:20 |
| 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: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 | 11:44 |
| ssam2 | juergbi, if i join two pipelines together, can i set options for the foreign project from the commandline ? | 11:48 |
| ssam2 | e.g. `bst -o foreignproject:option foo` or some such thing ? | 11:49 |
| tristan | I believe you should not be able to do that no | 11:51 |
| persia | juergbi: I don't think you're forgetting something simple. When I encounter a problem that becomes messy enough to benefit from a state machine, I usually refactor entirely over boilerplate. | 11:51 |
| ssam2 | ok, so i have to explicitly duplicate any options i want to expose in the project.conf of the 'master' | 11:52 |
| tristan | ssam2, the junction itself specifies options of the foreign project, and can do so leveraging both variable substitutions, and conditional statements on local project options | 11:52 |
| ssam2 | yeah | 11:52 |
| persia | More generally, are "state" and "stage" independent? Can "state" be eliminated by adding more "stage" (and perhaps allowing backtracking through the state machine)? | 11:53 |
| ssam2 | i'm thinking about how this works for the freedesktop SDK | 11:53 |
| ssam2 | which has bootstrap:build_arch, bootstrap:target_arch and sdk:target_arch | 11:53 |
| juergbi | you can explicitly inherit the target_arch option | 11:53 |
| ssam2 | right | 11:54 |
| juergbi | make it a variable and then use %{target_arch} in the junction | 11:54 |
| ssam2 | the existing options in this repo are actually a bit confusing | 11:54 |
| tristan | persia, just to clarify; this discussion with juergbi about state is entirely theoretical and a thought exercise, there is no work blocking on this (just making sure that's clear, it may already be clear :) ) | 11:54 |
| juergbi | persia: python generators might actually be useful for this. however, i don't think it actually would make sense at this point | 11:55 |
| tristan | although evolution of the discussion may very well influence future patches :) | 11:55 |
| persia | tristan: That wasn't clear, but I approached it as "what is the best algorithm to use for this class of issue", rather than "how can I help someone accomplish an immediate goal" :) | 11:55 |
| persia | I really like state machines: it took a while to learn how, but now I can read state machine code fairly comfortably, and find it easier to debug than half-state-machines-done-procedurally | 11:56 |
| persia | juergbi: Something like http://gnosis.cx/publish/programming/charming_python_b5.html ? | 11:58 |
| tristan | Actually, there is a detail in the incremental builds that may depend on this now that I think of it | 11:59 |
| tristan | but, I'd rather punt this discussion to something longer term | 11:59 |
| tristan | persia, I like state charts | 11:59 |
| tristan | And loathe any cached local variables which can be avoided at all; unless they are cached for performance reasons | 12:00 |
| tristan | necessary evils | 12:00 |
| tristan | maybe there are some middle grounds, too | 12:01 |
| tristan | but I've seen too many horrible code fragments which are in my estimation, the result of careless addition of state over years of code evolution | 12:01 |
| juergbi | sure, i'm not proposing to reintroduce the 'recalculate' approach that i just eliminated but some state is necessary | 12:04 |
| gitlab-br-bot | buildstream: merge request (issue-181_bst_build_--track-except->master: Fix for issue #181) #228 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/228 | 12:17 |
| ssam2 | juergbi, could you check if I'm doing anything stupid in https://gitlab.com/freedesktop-sdk/freedesktop-sdk/commit/ba33569c968a36853ed4cce910448e01e0df44c0 ? | 12:25 |
| ssam2 | I get a plugin import error when doing `bst build sdk.bst` inside the sdk project | 12:25 |
| ssam2 | Error loading pipeline: Failed to load Element plugin 'myautotools': No module named 'pluginbase._internalspace._speadd99d8739283c069bdeda7a4d494e3.myautotools' | 12:25 |
| ssam2 | the plugin is enabled in the project.conf of both the 'sdk' project, and the 'bootstrap' project which is embedded as a junction | 12:25 |
| ssam2 | and it works fine in master | 12:26 |
| juergbi | let me take a look. i might have introduced bugs in rebasing with the recent-ish plugin changes in master | 12:26 |
| juergbi | ssam2: can you also push the junction file? | 12:27 |
| juergbi | ssam2? | 12:34 |
| *** jonathanmaw has quit IRC | 12:39 | |
| ssam2 | oops, yes | 12:42 |
| ssam2 | juergbi, pushed now | 12:42 |
| juergbi | ta | 12:42 |
| jmac | pip3 install seems to have problems if you run it after running the integration tests | 12:43 |
| jmac | Tried a run-test.sh clean but it's still got some files left over | 12:43 |
| juergbi | i've noticed dirty git tree after running integration tests as well | 12:44 |
| ssam2 | that will probably be fixed by https://gitlab.com/BuildStream/buildstream/merge_requests/233/diffs | 12:45 |
| jmac | Yes, it updates some URLs when the tests run | 12:45 |
| tristan | jmac, install after integration-tests is untested and yuck, integration-tests however are undergoing a marvelous refactor by tlater | 12:50 |
| jmac | Cool | 12:50 |
| juergbi | ssam2: i suspect plugin issue is a bug on my side, looking into it | 12:51 |
| *** jonathanmaw has joined #buildstream | 12:55 | |
| gitlab-br-bot | buildstream: merge request (juerg/source-state->master: source state updates) #230 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/230 | 12:59 |
| juergbi | ssam2: ah, paths pointing out of a project are problematic (the issue in this case is bootstrap's project.conf pointing to a plugin directory outside the project directory) | 13:01 |
| ssam2 | right | 13:01 |
| juergbi | the project directory is considered as source and used from a temporary directory during the bst session | 13:01 |
| juergbi | in which case the relative path will not make sense anymore | 13:02 |
| ssam2 | right, that makes sense | 13:02 |
| ssam2 | there will be ways to work around this specific case | 13:02 |
| ssam2 | i wonder if it's a general problem though | 13:02 |
| juergbi | yes, wondering the same | 13:02 |
| ssam2 | i guess as long as we don't need to work on oldschool filesystems, a symlink would be enough | 13:03 |
| juergbi | normally separate bst projects are in separate git repositories, as otherwise you wouldn't really need separate projects | 13:03 |
| juergbi | relative symlink would have the same issue | 13:03 |
| juergbi | and absolute symlink doesn't make sense in git repo | 13:03 |
| ssam2 | right, yeahn | 13:03 |
| ssam2 | *yeah | 13:03 |
| ssam2 | well, we could also copy the plugin for this case | 13:03 |
| ssam2 | it's due to be removed anyway | 13:03 |
| gitlab-br-bot | buildstream: merge request (issue-182_Closing_non-existing_workspace->master: Fix for issue 182 Closing non-existing workspace) #227 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/227 | 13:03 |
| ssam2 | i think the rationale for two projects in one repo is so that one can be cross-built | 13:04 |
| ssam2 | although, i guess that could have been achieved without using separate projects | 13:04 |
| ssam2 | just two separate dependency trees in a single project | 13:04 |
| juergbi | i think so, yes | 13:05 |
| juergbi | wondering whether it could make sense to be smart about resolving relative paths to avoid such issues | 13:05 |
| juergbi | but might not work in all cases | 13:05 |
| ssam2 | alternately we could discourage use of local source with this feature | 13:06 |
| ssam2 | i was already a bit uncomfortable about that as the cache key algorithm for local sources isn't very efficient | 13:06 |
| persia | Discouraging use of local source in the case of multiple related projects is likely best practice anyway. | 13:07 |
| persia | In the case where the general workflow involves multiple projects, it liklely involves multiple developers, in which case sources should be published *somewhere* | 13:07 |
| persia | (might be git://127.0.0.1/... of course ...) | 13:07 |
| tristan | what is this ? are we missing an early comprehensive error message when people try crazy stuff like setting a plugin path which points to outside of the project, or a local source which contains symlinks which point outside of the project ? | 13:08 |
| juergbi | yes, that was my thinking when developing | 13:08 |
| juergbi | tristan: yes, this is silently accepted and normally working (without junctions) right now | 13:09 |
| tristan | maybe we are, but I think this discussion is about junctions | 13:09 |
| juergbi | with junctions it breaks in some cases | 13:09 |
| tristan | Ok, but with junctions it breaks, only when you attempt such craziness | 13:09 |
| juergbi | (without properly pointing to the cause) | 13:09 |
| tristan | Lets properly ban it | 13:09 |
| juergbi | probably sensible | 13:09 |
| ssam2 | ok | 13:10 |
| ssam2 | as far as I know only https://gitlab.com/freedesktop-sdk/freedesktop-sdk is doing this | 13:10 |
| ssam2 | jjardon[m], ^^ | 13:10 |
| tristan | leave it jjardon[m] :) | 13:10 |
| tristan | to think up something like that | 13:10 |
| tristan | In fairness I suppose it may be due to complicated setup of external plugins | 13:10 |
| juergbi | junction test cases actually use it but this should be fixable | 13:11 |
| ssam2 | i think it's down to the decision to have separate 'bootstrap' and 'sdk' projects in that repo | 13:11 |
| ssam2 | which then need to share a plugin | 13:11 |
| ssam2 | but as mentioned, there's no real need for the separate projects | 13:11 |
| tristan | I've updated the documentation for external plugins last week so it should be easier: http://buildstream.gitlab.io/buildstream/projectconf.html#project-plugins | 13:11 |
| juergbi | explicitly states subdirectory already, that's good | 13:12 |
| tristan | Just as there is no real need for revisioning the linux kernel outside of the gcc git repo directly | 13:12 |
| tristan | Yet, people tend to like to organize things :) | 13:12 |
| ssam2 | this does mean i need a new testcase for recursive pipelines though ;-) | 13:16 |
| * ssam2 tries building gnome-modulesets against the freedesktop sdk, for science | 13:16 | |
| *** xjuan has joined #buildstream | 13:17 | |
| jjardon[m] | tristan: please open an issue in freedeskltop-sdk so we are aware we are doing it wrongTM :) | 13:19 |
| tristan | jjardon[m], ok ! | 13:21 |
| *** cs_shadow has quit IRC | 13:27 | |
| *** xjuan has quit IRC | 13:27 | |
| *** jonathanmaw has quit IRC | 13:27 | |
| *** ssam2 has quit IRC | 13:27 | |
| *** noisecell has quit IRC | 13:27 | |
| *** tristan has quit IRC | 13:27 | |
| *** tiago has quit IRC | 13:27 | |
| *** jude has quit IRC | 13:27 | |
| *** adds68__ has quit IRC | 13:27 | |
| *** paulsherwood has quit IRC | 13:27 | |
| *** nexus has quit IRC | 13:27 | |
| *** tlater has quit IRC | 13:27 | |
| *** gitlab-br-bot has quit IRC | 13:27 | |
| *** lantw44 has quit IRC | 13:27 | |
| *** ernestask has quit IRC | 13:27 | |
| *** m_22[m] has quit IRC | 13:27 | |
| *** Guest56733 has quit IRC | 13:27 | |
| *** cgmcintyre[m] has quit IRC | 13:27 | |
| *** kailueke[m] has quit IRC | 13:27 | |
| *** jjardon[m] has quit IRC | 13:27 | |
| *** mrmcq2u[m] has quit IRC | 13:27 | |
| *** pro[m] has quit IRC | 13:27 | |
| *** ptomato[m] has quit IRC | 13:27 | |
| *** waltervargas[m] has quit IRC | 13:27 | |
| *** bochecha has quit IRC | 13:27 | |
| *** mattiasb has quit IRC | 13:27 | |
| *** xjuan has joined #buildstream | 13:27 | |
| *** jonathanmaw has joined #buildstream | 13:27 | |
| *** tlater has joined #buildstream | 13:27 | |
| *** ssam2 has joined #buildstream | 13:27 | |
| *** noisecell has joined #buildstream | 13:27 | |
| *** tristan has joined #buildstream | 13:27 | |
| *** tiago has joined #buildstream | 13:27 | |
| *** jude has joined #buildstream | 13:27 | |
| *** adds68__ has joined #buildstream | 13:27 | |
| *** paulsherwood has joined #buildstream | 13:27 | |
| *** nexus has joined #buildstream | 13:27 | |
| *** gitlab-br-bot has joined #buildstream | 13:27 | |
| *** lantw44 has joined #buildstream | 13:27 | |
| *** irc.gimp.ca sets mode: +o tristan | 13:27 | |
| gitlab-br-bot | buildstream: issue #195 ("Errors are needed when referring to local things outside of the project") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/195 | 13:29 |
| *** mattiasb has joined #buildstream | 13:44 | |
| *** bochecha has joined #buildstream | 13:44 | |
| *** waltervargas[m] has joined #buildstream | 13:44 | |
| *** ptomato[m] has joined #buildstream | 13:44 | |
| *** pro[m] has joined #buildstream | 13:44 | |
| *** mrmcq2u[m] has joined #buildstream | 13:44 | |
| *** jjardon[m] has joined #buildstream | 13:44 | |
| *** kailueke[m] has joined #buildstream | 13:44 | |
| *** cgmcintyre[m] has joined #buildstream | 13:44 | |
| *** Guest56733 has joined #buildstream | 13:44 | |
| *** m_22[m] has joined #buildstream | 13:44 | |
| *** ernestask has joined #buildstream | 13:44 | |
| *** cs_shadow has joined #buildstream | 13:44 | |
| tristan | jjardon[m], done https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/40 | 13:44 |
| tristan | also filed #195 here to keep track of the lack of errors | 13:44 |
| *** tristan has quit IRC | 13:51 | |
| juergbi | hm, source_dist job failed: tar: dist/buildstream: Not found in archive | 13:56 |
| juergbi | i'll retry the job | 13:56 |
| *** cs_shadow has quit IRC | 14:04 | |
| *** ernestask has quit IRC | 14:04 | |
| *** m_22[m] has quit IRC | 14:04 | |
| *** Guest56733 has quit IRC | 14:04 | |
| *** cgmcintyre[m] has quit IRC | 14:04 | |
| *** kailueke[m] has quit IRC | 14:04 | |
| *** jjardon[m] has quit IRC | 14:04 | |
| *** mrmcq2u[m] has quit IRC | 14:04 | |
| *** pro[m] has quit IRC | 14:04 | |
| *** ptomato[m] has quit IRC | 14:04 | |
| *** waltervargas[m] has quit IRC | 14:04 | |
| *** bochecha has quit IRC | 14:04 | |
| *** mattiasb has quit IRC | 14:04 | |
| *** mcatanzaro has joined #buildstream | 14:04 | |
| *** cs_shadow has joined #buildstream | 14:05 | |
| *** ernestask has joined #buildstream | 14:05 | |
| *** m_22[m] has joined #buildstream | 14:05 | |
| *** Guest56733 has joined #buildstream | 14:05 | |
| *** cgmcintyre[m] has joined #buildstream | 14:05 | |
| *** kailueke[m] has joined #buildstream | 14:05 | |
| *** jjardon[m] has joined #buildstream | 14:05 | |
| *** mrmcq2u[m] has joined #buildstream | 14:05 | |
| *** pro[m] has joined #buildstream | 14:05 | |
| *** ptomato[m] has joined #buildstream | 14:05 | |
| *** waltervargas[m] has joined #buildstream | 14:05 | |
| *** bochecha has joined #buildstream | 14:05 | |
| *** mattiasb has joined #buildstream | 14:05 | |
| *** csoriano has quit IRC | 14:05 | |
| *** csoriano has joined #buildstream | 14:06 | |
| juergbi | looks like a consistent failure since the HACKING.rst change | 14:07 |
| jjardon[m] | tristan: thanks! | 14:13 |
| juergbi | does anyone have an idea why source_dist jobs are suddenly failing? | 14:13 |
| *** tristan has joined #buildstream | 14:14 | |
| *** ChanServ sets mode: +o tristan | 14:29 | |
| tristan | jjardon[m], I have a feeling that we're doing something wrong in .gitlab-ci.yml, but that it was silently going alright until you restarted that gitlab cache server | 14:40 |
| tristan | jjardon[m], pipelines seem to be failing consistently with this error now: https://gitlab.com/BuildStream/buildstream/-/jobs/48125114 | 14:41 |
| tristan | I wonder, maybe the artifact which it produces already exists or smth ? Or, maybe we should not do work directly in the gitlab artifact output directory, but move the results into it after work is done instead ? | 14:42 |
| tristan | https://gitlab.com/BuildStream/buildstream/blob/master/.gitlab-ci.yml#L36 <-- thats the line that fails | 14:43 |
| tristan | if you dont know off hand what's going on there, I'll fashion a branch with more diagnostics to debug it... maybe not tonight though | 14:43 |
| gitlab-br-bot | buildstream: merge request (164-minimise-overlaps-by-having-overlaps-raise-exceptions-unless-configured-not-to->master: Resolve "Minimise overlaps by having overlaps raise exceptions unless configured not to") #181 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/181 | 14:45 |
| ssam2 | juergbi, the recursive-pipelines branch seems to break if a cache in the list fails to initialize | 14:48 |
| ssam2 | https://pastebin.com/7txbx5U1 | 14:48 |
| ssam2 | we only warn if a cache fails to initialize, we don't abort | 14:49 |
| juergbi | good catch, will fix that | 14:49 |
| gitlab-br-bot | buildstream: merge request (jjardon/jinja->master: setup.py: Require jinja >= 2.10) #239 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/239 | 14:51 |
| gitlab-br-bot | buildstream: issue #196 ("source_dist: job fail with obscure message when a dependency is not satisfied") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/196 | 14:53 |
| jmac | nexus: In your proposed documentation https://gitlab.com/knownexus/buildstream/blob/buildproject/doc/source/buildproject.rst, where do we get elements/core/gedit.rst from? | 14:53 |
| gitlab-br-bot | buildstream: merge request (incremental-build->master: WIP: Add support for doing incremental builds) #126 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/126 | 14:54 |
| gitlab-br-bot | buildstream: merge request (jjardon/jinja->master: WIP: setup.py: Require jinja >= 2.10) #239 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/239 | 14:55 |
| gitlab-br-bot | buildstream: merge request (incremental-build->master: WIP: Add support for doing incremental builds) #126 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/126 | 14:55 |
| gitlab-br-bot | buildstream: merge request (juerg/recursive-pipelines->master: WIP: Junctions and subprojects) #160 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/160 | 14:56 |
| juergbi | ssam2: fix pushed | 14:57 |
| ssam2 | thanks! | 14:58 |
| nexus | jmac: it's in gnome-modulesets | 15:10 |
| jmac | Oh yes, it does say that | 15:11 |
| gitlab-br-bot | buildstream: merge request (incremental-build->master: WIP: Add support for doing incremental builds) #126 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/126 | 15:12 |
| gitlab-br-bot | buildstream: merge request (issue-182_Closing_non-existing_workspace->master: Fix for issue 182 Closing non-existing workspace) #227 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/227 | 15:40 |
| jjardon[m] | ssam2: are you ok with the change at https://gitlab.com/BuildStream/buildstream-docker-images/merge_requests/16/diffs ? | 15:49 |
| ssam2 | i'm not sure of the point | 15:51 |
| ssam2 | either the issue isn't present, or your change will break the docker image build because the dependency can't be satisfied | 15:51 |
| ssam2 | i assume fedora 27 already has a new enough version, and they are not going to somehow replace it with an older version in fedora 28 | 15:52 |
| ssam2 | i should comment in the issue, anyway | 15:52 |
| ssam2 | wait, that's pip not dnf | 15:53 |
| ssam2 | but same thing, if pypi already has jinja 2.10, we're not going to somehow get jinja 2.9 next time we run pip | 15:55 |
| ltu | FOSDEM Schedule updated - https://fosdem.org/2018/schedule/track/distributions/ | 15:57 |
| persia | \o/ | 15:57 |
| jjardon[m] | ssam2: rigth, I guess it makes sense when you want to == , I will close the MR then | 15:59 |
| jjardon[m] | ssam2: can you tell me how to generate a new docker image, I tried the latest available but the build still fails: https://gitlab.com/BuildStream/buildstream/merge_requests/239 | 16:01 |
| jmac | Can I disable the fancy status bar in bst's output? I thought --no-interactive might do it, but it's still there | 16:02 |
| ssam2 | jjardon[m], that's the 'tar: dist/buildstream: Not found in archive' | 16:02 |
| ssam2 | jjardon[m], that appeared today and nobody seems to know why | 16:02 |
| ssam2 | jjardon[m], it's probably unrelated to your changes | 16:03 |
| jjardon[m] | ssam2: ah sorry | 16:03 |
| ssam2 | jmac, it goes away if stdout isn't a tty | 16:03 |
| ssam2 | jmac, i don't remember if there's a cli option | 16:03 |
| ssam2 | --no-colors might do it | 16:03 |
| jmac | Indeed it does | 16:03 |
| jmac | --no-colors does what it says it will, but you still get the status bar | 16:04 |
| ssam2 | probably what it should do | 16:04 |
| ssam2 | :-) | 16:04 |
| persia | Is dump-to-file-with-tail really the best way to avoid status bars? | 16:07 |
| jmac | Doesn't feel very logical to me. Shall I raise an issue to add a '--simple-output' or similar? | 16:08 |
| persia | I remember a discussion about this before: I think the conclusion was something like "Why would someone want to look at that?". If raising an issue, it is probably wise to add a rich use case. | 16:09 |
| jmac | I can do that. | 16:09 |
| persia | Excellent :) | 16:09 |
| *** Guest56733 is now known as ernestask[m] | 16:17 | |
| gitlab-br-bot | buildstream: issue #197 ("Simplified output option") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/197 | 16:22 |
| juergbi | persia: btw: |cat is sufficient, no need for file/tail | 16:25 |
| juergbi | but an option for that probably makes sense | 16:25 |
| persia | heh. I so often avoid using cat when something else works that I entirely forgot about |cat :) | 16:28 |
| gitlab-br-bot | buildstream: merge request (incremental-build->master: WIP: Add support for doing incremental builds) #126 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/126 | 16:31 |
| *** ssam2 has quit IRC | 16:36 | |
| *** ssam2 has joined #buildstream | 16:38 | |
| *** valentind has joined #buildstream | 17:46 | |
| gitlab-br-bot | buildstream: merge request (jmac/handle-child-complete-exceptions->master: WIP: Handle exceptions in job.child_complete() properly) #240 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/240 | 17:50 |
| jmac | That's a small patch I just made to try and fix an issue I found while learning buildstream. It's probably not correct as I'm pretty new to this project, any comments would welcome. | 17:52 |
| jmac | would /be/ welcome | 17:52 |
| *** jonathanmaw has quit IRC | 18:07 | |
| *** ssam2 has quit IRC | 18:29 | |
| gitlab-br-bot | buildstream: merge request (skip-configure-tests->master: WIP: Workspaced builds only run configure commands once) #191 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/191 | 18:29 |
| gitlab-br-bot | buildstream: merge request (skip-configure-tests->master: WIP: Workspaced builds only run configure commands once) #191 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/191 | 18:31 |
| jjardon[m] | Good news for our infra: https://blog.digitalocean.com/new-droplet-plans/ | 19:04 |
| gitlab-br-bot | buildstream: merge request (skip-configure-tests->master: WIP: Workspaced builds only run configure commands once) #191 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/191 | 19:06 |
| *** ernestask has quit IRC | 19:55 | |
| *** tristan has quit IRC | 21:08 | |
| *** xjuan has quit IRC | 21:10 | |
| *** noisecell has quit IRC | 21:58 | |
| *** valentind has quit IRC | 22:29 | |
| *** mcatanzaro has quit IRC | 23:47 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!