| *** xjuan has quit IRC | 00:28 | |
| *** tristan has joined #buildstream | 02:25 | |
| *** ChanServ sets mode: +o tristan | 02:25 | |
| *** tristan has quit IRC | 04:53 | |
| *** bochecha has joined #buildstream | 05:59 | |
| *** finn has joined #buildstream | 07:18 | |
| *** iker has joined #buildstream | 07:19 | |
| *** tristan has joined #buildstream | 07:39 | |
| *** ChanServ sets mode: +o tristan | 07:40 | |
| qinusty | https://gitlab.com/BuildStream/website/merge_requests/85/ is looking for contributions, feel free to add any terms which you wish to define in the glossary as commits or comments in the MR. | 08:01 |
|---|---|---|
| *** toscalix has joined #buildstream | 08:11 | |
| *** iker has quit IRC | 08:13 | |
| *** phildawson has joined #buildstream | 08:14 | |
| *** iker has joined #buildstream | 08:14 | |
| qinusty | Is there a potential for a tag relating to MR's which are ready to be reviewed within buildstream? I realise the WIP system is in place, however I feel that a `Ready For Review` tag would make searching for MR's which need reviewing easier to filter and process. When reviewed and going back to further work, the reviewer can remove the tag which is | 08:15 |
| qinusty | much easier than editing the title of the MR. Perhaps toscalix can weigh in on this? | 08:15 |
| coldtom | isn't that what the 'Review' tag is for? | 08:16 |
| *** rdale has joined #buildstream | 08:22 | |
| finn | I've configured the autotools example to use remote execution. I can build it. I can pull it. Though I can't checkout | 08:40 |
| finn | Error while staging dependencies into a sandbox: 'Artifact hello.bst is configured to use remote execution but has no push remotes. The remote artifact server(s) may not be correctly configured or contactable.' | 08:40 |
| finn | I do have push remotes and surely for a checkout, this shouldn't be an issue? | 08:41 |
| *** jonathanmaw has joined #buildstream | 08:43 | |
| finn | If I remove my remote configuration, I can checkout | 08:44 |
| qinusty | Is there a review tag coldtom? | 08:51 |
| gitlab-br-bot | buildstream: merge request (richardmaw/builddir-sockets->master: Fix: While caching build artifact: "Cannot extract [path to socket file] into staging-area. Unsupported type.") #783 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/783 | 08:53 |
| coldtom | i was thinking of "verify" | 08:53 |
| jmac | Checkout needs to stage dependencies, so it does require remote execution | 08:54 |
| finn | Even after I've run the build and pulled everything into my local cache? | 08:55 |
| jmac | Yes. Staging runs integration commands which are no different to build commands. | 08:56 |
| jmac | I realise it isn't ideal | 08:56 |
| finn | I have my remote still setup though | 08:57 |
| finn | So even so, it shouldn't be an issue | 08:57 |
| jmac | And there was nothing in the initialization messages from buildstream indicating a problem with the artifact cache? | 08:59 |
| jmac | Did you see [00:00:00][][] SUCCESS Initializing remote caches | 09:00 |
| finn | ls | 09:04 |
| finn | nope | 09:05 |
| finn | I get | 09:05 |
| finn | https://pastebin.com/wDpDerfx | 09:05 |
| jmac | Oh, interesting, I don't think it's even tried to setup the remote | 09:05 |
| jmac | Perhaps bst doesn't bother if it's just doing a checkout | 09:06 |
| gitlab-br-bot | buildstream: merge request (richardmaw/builddir-sockets->master: Fix: While caching build artifact: "Cannot extract [path to socket file] into staging-area. Unsupported type.") #783 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/783 | 09:06 |
| jmac | I'll have to log it as an issue, I'm in the middle of something else at the moment | 09:07 |
| finn | I'll send you the details for the cluster we have set up here too | 09:11 |
| tiagogomes | tristan I need some design help here. Recently, a pull_tree method was added to the artifact cache. This method is run from SandboxRemote and adds content the artifact cache. I need to communicate the size of the content added to the main process for dynamically update the artifact cache. But having the sandbox class return that data seems odd to me | 09:11 |
| tiagogomes | Any idea for a nice and clean solution? | 09:12 |
| *** abderrahim has quit IRC | 09:14 | |
| *** abderrahim has joined #buildstream | 09:15 | |
| tristan | Hrrrrrm | 09:15 |
| tristan | This is a bit curious, I think it's better to take a step back and consider the design of SandboxRemote first | 09:16 |
| tristan | Is it, per chance... doing more than what a Sandbox should do ? | 09:16 |
| tristan | tiagogomes, let me safely task switch, I'm trying to add a regression test for `bst build --track` which accidentally deletes required artifacts | 09:17 |
| tiagogomes | sure, no rush | 09:17 |
| tristan | https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/sandbox/_sandboxremote.py#L59 | 09:20 |
| tristan | First question to ask here is... Is this a different artifact cache ? | 09:20 |
| tristan | If so... Why ? | 09:20 |
| tristan | A lot of thinking to do around here, I have it on the menu to examine the design with juergbi and jmac, and have a lot of catching up to do | 09:21 |
| tristan | input from juergbi would be good | 09:21 |
| tristan | on what is currently intended | 09:21 |
| jmac | Nope, same cache as the rest of buildstream | 09:22 |
| *** ikerperez has joined #buildstream | 09:22 | |
| tristan | But honestly, we need to look at the big picture; I have a feeling that our artifact cache is only a part of the local CAS; and we probably intend that the quota applies to anything stored in the CAS, not only the artifacts | 09:23 |
| *** iker has quit IRC | 09:23 | |
| tristan | jmac, interesting, how come we are not using the regular Platform.get_platform() + platform.artifactcache to access it ? | 09:23 |
| qinusty | This includes the build/ folder tristan? I was seeing this as an issue when looking into the issues with filling up on disk space | 09:24 |
| tristan | Seems dangerous to have multiple instances of the CasCache with different state, accessing the same store no ? | 09:24 |
| tristan | qinusty, It does not include the build/ directory | 09:24 |
| qinusty | Not currently. Which is the problem | 09:24 |
| tristan | qinusty, I believe that the build/ directory is coined for automatic cleanup *all the time* in the technical debt follow up issue related to caching of failed builds | 09:24 |
| qinusty | build/ is part of the cache directory, and is a large contributor towards storage during a build. | 09:25 |
| tristan | qinusty, I have outlined everything that has to happen to that build/ directory in the related issue | 09:25 |
| tristan | qinusty, search for Blocker issues for milestone 1.4 to find it quickly | 09:25 |
| gitlab-br-bot | buildstream: merge request (issue-642-Invalid_project.conf_seen_as_missing->master: Incorrect error when malformed project.conf) #792 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/792 | 09:25 |
| qinusty | Okay | 09:25 |
| tlater[m] | qinusty: Also, only *failed* builds remain in build/, so it should generally not explode like the old artifact cache. | 09:27 |
| tristan | Don't mix artifact caches with the build/ directory | 09:27 |
| tristan | While it would have been a good idea from the start to offer only one directory as configuration where we would have stored build/ and artifacts/ underneath from the beginning, we did not | 09:28 |
| tristan | Also, unrelated to this, those are separate, unrelated things; builds dont happen in the artifact cache | 09:29 |
| jmac | If Platform is available inside a sandbox, I agree platform.artifactcache() would be a better way of obtaining it | 09:29 |
| tristan | jmac, Platform.get_platform() is a class method of Platform | 09:29 |
| tristan | i.e. you don't need an instance, it's a singleton | 09:29 |
| qinusty | My concerns were regarding filling a disk. When you're approaching a full disk. You have 2G headroom, you build in build/ then copy to artifacts/ meaning you need double the size of that current artifact available at the time of copy? | 09:30 |
| gitlab-br-bot | buildstream: merge request (issue-642-Invalid_project.conf_seen_as_missing->master: Incorrect error when malformed project.conf) #792 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/792 | 09:30 |
| *** lachlan has joined #buildstream | 09:31 | |
| tristan | qinusty, Ignore the fact that they exist on the same partition, and read the issue | 09:31 |
| tristan | qinusty, My point to tlater[m] is not to mix up terminology and concepts and make everyone confused as a result | 09:32 |
| tristan | The build directory is one thing, the source cache is another thing (and another can of worms), the artifact cache is another thing | 09:32 |
| tristan | Those are all things, not one thing | 09:32 |
| * tlater[m] apologizes for being ambiguous here | 09:33 | |
| toscalix | qinusty: you are trying to solve with labels what should be solved by assigning the MR to a person or several people at the same time. | 09:37 |
| toscalix | In any case, if you think the label is the best way, I will not stopped. I am not a gate keeper in this project | 09:38 |
| toscalix | .. stop it... | 09:38 |
| toscalix | adding labels makes the usage of the tool more expensive. And the real benefits comes when everybody use them. The principle is... less features used by everybody instead of more used by just a few | 09:40 |
| qinusty | I agree this would work in some cases toscalix, but I feel it is easier for everyone if there are a collection of MRs awaiting reviews and people took some time to review MRs throughout the week. Assigning to a specific person means you need to pick people (who aren't clearly defined currently) and the same people will end up being assigned MR afte | 09:40 |
| qinusty | r MR. | 09:40 |
| adds68 | Is there a document anywhere that explains what each label is used for and where they should be applied? | 09:41 |
| toscalix | checking the overall usage of the high amount of labels we have.... I would claim we are making a mistake, making the usage of the tool more and more expensive and, at some point, we will not be able to pay the price | 09:41 |
| qinusty | Well perhaps we need a clean up of the ones we do not use? | 09:41 |
| qinusty | Rather than considering the negative impact of adding new labels | 09:41 |
| toscalix | adds68: I did with the ones originally. Thos who have created the new ones have not followed that process, I am afraid | 09:42 |
| toscalix | adds68: https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/BuildStream_policies.md | 09:42 |
| toscalix | qinusty: erasing labels is tempting... but is a bad practice | 09:43 |
| toscalix | it might have little impact on our project at this time | 09:43 |
| toscalix | because we are not doing reports or analising any past data | 09:44 |
| toscalix | at some point we will | 09:44 |
| toscalix | in any case, erasing the labels does not solve the real problem.... we are creating new labels while we are not using as we should the ones we already have | 09:44 |
| adds68 | toscalix, why is this in a separate project? If the labels are so important, they should be presented to the user via the readme or contributing page | 09:45 |
| gitlab-br-bot | buildstream: merge request (richardmaw/builddir-sockets->master: Fix: While caching build artifact: "Cannot extract [path to socket file] into staging-area. Unsupported type.") #783 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/783 | 09:46 |
| toscalix | that is questionable | 09:46 |
| toscalix | you are assuming that gitlab will be use only by code contributors | 09:46 |
| toscalix | the structure does not only affect to the buildstream repo | 09:47 |
| toscalix | as I mentioned yesterday, I think policies are part of the governance model. There used to be a time where only devs care about them. Today covernance is part of the decision process to adopt a tool or not | 09:49 |
| adds68 | toscalix, the service primarily exists for code contributors, there are other things such as a wiki for people who are not well versed in git | 09:49 |
| toscalix | the audience for these policies is wider than developers | 09:49 |
| adds68 | toscalix, or your website :) | 09:49 |
| toscalix | the policie was created beforethe website | 09:49 |
| toscalix | and yes, if you check the content structure document and the sitemap, the plan is to include the policies on the website | 09:50 |
| toscalix | sadly there is now a discussion that intends to put part of the policies in the buildstream repo | 09:50 |
| adds68 | The policies are buildstreams policies, would that not make sense? | 09:51 |
| tlater[m] | toscalix: Personally, I wasn't aware we had these definitions. I think I agree with adds68 that label definitions should at least *also* be in our readme. | 09:51 |
| toscalix | the policies are part of the governance model, that transcend the contributors | 09:51 |
| adds68 | nobody is going to go to a separate git project to find policies, they will just assume you don't have any | 09:52 |
| phildawson | perhaps referencing the policies document on the contributing page would help | 09:52 |
| toscalix | adds68: the policies affecting the website, the graphic design, the roadmapping..... | 09:52 |
| adds68 | toscalix, nobody cares about those, they come for BuildStream | 09:53 |
| toscalix | all those are part of the governance model of a project. | 09:53 |
| adds68 | If they care about the website, they will go there | 09:53 |
| tristan | There is not IMO much reason to fragment all of the things into separate repos; The HACKING.rst document for instance is accessible via the "Contributing" link in the documentation: http://buildstream.gitlab.io/buildstream/ | 09:53 |
| toscalix | adds68: nobody that you know care about those. Look at a wider scope. In order to be successful, wqe need to attract people that are not like ours | 09:54 |
| tristan | The trick is not to make everything more complex with fragmentation, but to have the website point to the things which concern those who are looking for them only | 09:54 |
| toscalix | like us | 09:54 |
| tristan | So that everyone finds their way, and that everything is still accessible in one repo | 09:54 |
| toscalix | the trick is to have a clear idea about who are we doing this for | 09:54 |
| toscalix | if you do it for ourselves....then you take some decisions | 09:54 |
| toscalix | if we do it for a wider audience who is not aware of bst, then you might take different decisions | 09:55 |
| tristan | We can make decisions which satisfy all of the use cases, fragmentation makes things more complicated and harder to maintain - the right audience needs a way to find the right materials | 09:56 |
| tristan | That is unrelated to which git repo those materials are created and stored in | 09:56 |
| toscalix | I think that today, the governance model has a wider audience than those pariticipating in the project, that is a fundamental maturity variable and that we should assume that it will be a matter of inspection by those who need to decide if they will use the tool ... in corporate environments | 09:56 |
| toscalix | tristan: agree, this is wht adds68 proposal makes no sense | 09:56 |
| toscalix | it is not a matter of the repo, it is a matter of how you present it and for who | 09:57 |
| tristan | I think there is confusion in the conversation | 09:57 |
| tristan | I agree with you toscalix on that front certainly | 09:57 |
| toscalix | back to the labels.... | 09:57 |
| toscalix | you want to use a new one, fine. Just make sure that everybody use it | 09:58 |
| coldtom | i have been using buildstream for 3 months and had no idea there was a written policy, having this document hidden away in a separate repo makes things far more confusing. A link in the README would be sufficient to make people aware it exists | 09:58 |
| toscalix | make the extra cost worth it. This would mean a change compared to the current behaviour | 09:58 |
| qinusty | I agree with coldtom on the separate repo thing. Information like this should atleast be referenced from within buildstream HACKING or README | 09:59 |
| tristan | tlater[m], If I change the required artifacts for required elements, as we previously discussed, would you agree that this statement no longer makes sense ? https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_artifactcache/artifactcache.py#L203 | 10:00 |
| *** robertheywood_ has joined #buildstream | 10:00 | |
| jmac | The current behaviour is that we assign reviewers in a private IRC channel, which is definitely not what we want | 10:00 |
| *** robjh has quit IRC | 10:01 | |
| toscalix | coldtom: https://mail.gnome.org/archives/buildstream-list/2018-May/msg00033.html | 10:02 |
| tlater[m] | tristan: So, you're changing this such that we only know what the locked keys are when we are actually removing things. | 10:03 |
| tlater[m] | I assume you do this by walking through all elements and collecting their keys just before we start cleaning | 10:03 |
| adds68 | toscalix, there is no direct link from IRC to the mailing list FYI :) | 10:03 |
| tlater[m] | Surely we still want to delete both weak and strong keys, for the reasons stated? | 10:03 |
| tlater[m] | We just don't "lock" them anymore. | 10:04 |
| toscalix | adds68: are you suggesting you will work on it? | 10:04 |
| tristan | tlater[m], wrote the failing test, fails correctly; now about to write the code | 10:04 |
| tlater[m] | tristan: I think the point of that comment is to say "if we're only deleting one of the keys we're probably doing something wrong" | 10:04 |
| tlater[m] | I think that still holds. | 10:05 |
| adds68 | toscalix, yea sure, how do i go about doing that? | 10:05 |
| tristan | tlater[m], my intention is to store a list of elements that are required, and while walking the LRU artifacts, delete only the ones which are not required | 10:05 |
| toscalix | qinusty: tlater[m] if you think this policy should be referenced somewhere else.... please take action and include it | 10:05 |
| tristan | tlater[m], actually yes you are right, let's leave that in | 10:05 |
| toscalix | adds68: you are asking the wrong person | 10:05 |
| qinusty | adds68 ask an OP, tristan, jjardon, ironfoot | 10:06 |
| tlater[m] | adds68: While you're at it, mind adding this to HACKING.rst? :) | 10:06 |
| qinusty | If you mean the message at the top in irc. | 10:06 |
| adds68 | tlater[m], sure :) | 10:06 |
| adds68 | qinusty, yea i guess ironfoot jjardon or tristan can fix that | 10:07 |
| adds68 | If we are pointing people to the mailing list for context, then we should make that obvious | 10:07 |
| *** tristan changes topic to "BuildStream 1.2.0 is out ! | https://gitlab.com/BuildStream/buildstream | Docs: https://buildstream.gitlab.io/buildstream | IRC logs: https://irclogs.baserock.org/buildstream | Mailing List: https://mail.gnome.org/mailman/listinfo/buildstream-list | Roadmap: https://wiki.gnome.org/Projects/BuildStream/Road" | 10:08 | |
| tristan | adds68, :) | 10:08 |
| adds68 | ta tristan :) | 10:08 |
| jmac | finn: In your pastebin, is 'hello.bst' publically available? I'd like to include it in the issue report | 10:08 |
| finn | it's the autotools example | 10:08 |
| tristan | Whenever we deem the website is in the right shape, we'll make that the first link in the topic :) | 10:09 |
| adds68 | tristan, yea that is a good idea also | 10:09 |
| jmac | finn: Where can I find that? | 10:09 |
| finn | buildstream/doc/examples/autotools | 10:10 |
| *** lachlan has quit IRC | 10:10 | |
| jmac | Thanks finn | 10:10 |
| jonathanmaw | tiagogomes: how is https://gitlab.com/BuildStream/buildstream/merge_requests/671? Are you currently awaiting review? | 10:11 |
| *** cs-shadow has joined #buildstream | 10:11 | |
| tlater[m] | juergbi: Am I right in assuming that the new CAS server isn't insecure by default anymore? I.e., it implements its own SSL, and doesn't need to be proxied through nginx? | 10:12 |
| gitlab-br-bot | buildstream: issue #653 ("bst checkout fails due to artifact cache error when remote execution is enabled") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/653 | 10:13 |
| tiagogomes | jonathanmaw Qinusty reviewed it. Now there's a new pull_tree in master that will cause the cache size to not be accurate for remote execution if the MR is merged as it is | 10:13 |
| juergbi | tlater[m]: it supports both. if --server-key is specified, TLS is enabled, otherwise it's insecure | 10:14 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 10:14 |
| juergbi | i.e., correct, no proxying is required | 10:14 |
| jonathanmaw | tiagogomes: okay, I'll refrain from further review for now | 10:14 |
| tlater[m] | Thanks juergbi - I didn't realize you could omit --server-key | 10:15 |
| juergbi | handy for local testing | 10:15 |
| juergbi | (or if you still want a proxy) | 10:15 |
| gitlab-br-bot | buildstream: merge request (issue-642-Invalid_project.conf_seen_as_missing->master: Incorrect error when malformed project.conf) #792 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/792 | 10:17 |
| tiagogomes | jonathanmaw, hopefully tristan will have bright ideas about how to have pull_tree to tell the bytes added to the main process | 10:17 |
| tlater[m] | Yep, that makes me wonder if my docker implementation is flawed | 10:17 |
| * tlater[m] will leave it as-is for now, if someone needs to go ssl-less they can always implement that. | 10:17 | |
| * tristan is annoyed that there is no location, other than Element.__calculate_cache_key(), where we know that "A cache key has been discovered", due to the multi-return nature of Element._update_state() | 10:21 | |
| *** lachlan has joined #buildstream | 10:24 | |
| gitlab-br-bot | buildstream: merge request (issue-642-Invalid_project.conf_seen_as_missing->master: Incorrect error when malformed project.conf) #792 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/792 | 10:26 |
| *** finn has quit IRC | 10:27 | |
| gitlab-br-bot | buildstream: merge request (richardmaw/test-config-fixes->master: Fix tests that attempt to access the home directory) #780 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/780 | 10:27 |
| WSalmon | python3 setup.py test --addopts --integration tests/integration/workspace.py::test_workspace_commanddir | 10:27 |
| WSalmon | invalid command name 'tests/integration/workspace.py::test_workspace_commanddir' | 10:27 |
| WSalmon | skullman et al. ^ should this work or am i being think | 10:28 |
| gitlab-br-bot | buildstream: merge request (richardmaw/test-config-fixes->master: Fix tests that attempt to access the home directory) #780 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/780 | 10:28 |
| tiagogomes | python3 setup.py test --addopts '--integration tests/integration/workspace.py::test_workspace_commanddir' | 10:28 |
| WSalmon | brill | 10:28 |
| WSalmon | thanks | 10:28 |
| *** lachlan has quit IRC | 10:29 | |
| tristan | tlater[m], So that fixes it \o/ with a nice new regression test... will push a branch soon | 10:29 |
| tristan | tlater[m], However there is one problem... I guess we can keep the LOC where we mark the required element at the end of Element._assemble_done(), for the sake of updating the atime; but that is not "correct" | 10:31 |
| tristan | tlater[m], That line assumes that that is the only place where we might discover a cache key in mid-build | 10:31 |
| tristan | tlater[m], On the other hand, placing the line of code deep in Element.__calculate_cache_key() is also flawed and out of place | 10:32 |
| tlater[m] | Sounds like we need some sort of streamlined way to say "oh, cache keys updated" | 10:32 |
| tristan | How about we keep that in Element._assemble_done(), but add a FIXME comment explaining how this is problematic ? | 10:32 |
| skullman | tristan: could do with a follow up review on https://gitlab.com/BuildStream/buildstream/merge_requests/788 when you're free | 10:33 |
| tristan | tlater[m], that is why I expressed my annoyance above indeed | 10:33 |
| tlater[m] | tristan: I think that's fine for now, since we do actually only update cache keys there to my knowledge | 10:34 |
| tlater[m] | Just important to know if we change that in the future. | 10:34 |
| tristan | skullman, ah good spot about the update.py, I always operated that by having BuildStream installed with "pip install --user -e...", I think it only breaks when not installed ? | 10:36 |
| gitlab-br-bot | buildstream: issue #654 ("Use Platform.artifact_cache() instead of reconstructing CASCache from context") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/654 | 10:36 |
| tristan | skullman, Looks good, please merge :) | 10:37 |
| * skullman queues it | 10:37 | |
| gitlab-br-bot | buildstream: merge request (richardmaw/subprocess-PWD->master: Address post-merge review of Ensure PWD is set in process environment) #788 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/788 | 10:37 |
| *** jonathanmaw_ has joined #buildstream | 10:37 | |
| *** jonathanmaw has quit IRC | 10:38 | |
| tristan | tlater[m], I do not believe we only update cache keys there, the strong keys I think can change dynamically when --no-strict and pulling artifacts along the way... they can also change dymaically as a result of `bst build --track-all`, etc | 10:38 |
| tristan | tlater[m], Of course, the likelihood of already having a cached artifact in those cases are slim (although with tracking not always, if you've rewinded and then fast forwarded with build + track to test some regression) | 10:39 |
| tlater[m] | tristan: In that case, maybe an issue is more appropriate, so we don't forget about this? | 10:40 |
| tlater[m] | I don't think it's likely enough to block the fix, but having something actually broken in a FIXME isn't nice. | 10:41 |
| *** lachlan has joined #buildstream | 10:41 | |
| tristan | tlater[m], Will do | 10:46 |
| * tristan prepares MR | 10:47 | |
| toscalix | coldtom: tlater[m] adds68 if you guys are interested in following the improvements in the policy or are willing to contribute to it, please track your effort on this ticket: https://gitlab.com/BuildStream/nosoftware/alignment/issues/9 | 10:47 |
| toscalix | and qinusty: | 10:47 |
| adds68 | toscalix, i am adding some changes now | 10:48 |
| adds68 | toscalix, tristan do you think we should link to the labels document in the issue template? | 10:48 |
| tristan | tlater[m], that is at least, the *last* opportunity where we can discover a cache key | 10:48 |
| toscalix | ok, then please track them in the ticket | 10:48 |
| gitlab-br-bot | buildstream: merge request (Qinusty/message-helpers->master: WIP: Continued work on improving BuildStream messaging API) #670 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/670 | 10:49 |
| toscalix | sorry, wrong ticket, the right one is https://gitlab.com/BuildStream/nosoftware/alignment/issues/11 | 10:49 |
| tristan | toscalix, Ummm, it's a good question - on the one hand I think it's useful to have a description of the available labels, on the other hand I don't like the idea of introducing someone to an entirely different repository if the information is going to be fragmented | 10:49 |
| toscalix | coldtom: tlater[m] adds68 qinusty | 10:50 |
| toscalix | tristan: the information is not going to be fragmented | 10:50 |
| tristan | toscalix, Ideally, the page where labels are configured, is read-only for someone who doesnt have privileges, and we just point them there ? | 10:50 |
| toscalix | the idea has always been to have all the policies listed in the website under the community page | 10:50 |
| toscalix | as proposed in the content design document and applied in the diagrams | 10:51 |
| toscalix | it is just not implemented for this release because we would not have time | 10:51 |
| tristan | Right, which will probably be a link to the HACKING.rst (http://buildstream.gitlab.io/buildstream/HACKING.html) | 10:51 |
| toscalix | so this fragmentation problem did not exist...until the hacking.rts proposal came up | 10:52 |
| tristan | There is another downside though which I worry about | 10:52 |
| tristan | Which is pointing people away from the issue page while they are filing an issue | 10:52 |
| toscalix | it seems clear to me that the content design was not considered carefully | 10:52 |
| tristan | toscalix, I think rather no; not based on fragmentation (I was rather worried we might point to something in "alighment"), but more because I want the issue tracker to be optimized towards non-contributors | 10:53 |
| toscalix | check the management box: https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/content_design/BuildStream_Content_Structure_all.pdf | 10:53 |
| tristan | The onus is on us to do the triage, not the issue reporter who may have encountered a problem, and is courtious enough to file an issue | 10:53 |
| toscalix | the policies are considered there, structured in for areas | 10:54 |
| tristan | toscalix, I am aware that we all did not take real time to pay attention to the content design proposals | 10:54 |
| *** alatiera_ has joined #buildstream | 10:54 | |
| tristan | toscalix, but on the subject of linking someone away from the issue template, I disagree | 10:54 |
| adds68 | How about moving the "no-software" project to a wiki inside the Buildstream project? | 10:55 |
| gitlab-br-bot | buildstream: merge request (richardmaw/test-config-fixes->master: Fix tests that attempt to access the home directory) #780 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/780 | 10:55 |
| tristan | Contributors should read the policies about contributing, issue reporters should have as hassle free of a time as possible | 10:55 |
| toscalix | they were not considered for the website, which means we will need to do it. If there is pressure not to do them.... well, I would advice to first finish the website content we have and then discuss which content we want to do next | 10:55 |
| toscalix | so we can have a serious discussion about the design before we just.... solve the gap. Nothing different from what you are requesting to do with the code | 10:56 |
| tlater[m] | Could I ask someone to review my README update to this patch? It's usage instructions... https://gitlab.com/BuildStream/buildstream-docker-images/merge_requests/53 | 10:56 |
| tristan | When issue reporters happen to also be contributors, they will have read the policies anyway | 10:56 |
| toscalix | I would really prefer in finishing what we have now half way through | 10:56 |
| toscalix | havinbg people fixing the labels policy when we have not finished the web is.... not ideal | 10:57 |
| tristan | Related to labels, I was thinking that if we have "domains" clearly defined (as we already use a great deal of labels for in interesting ways), they should be brought inline with the proposed committer policy, if that goes through (https://mail.gnome.org/archives/buildstream-list/2018-September/msg00044.html) | 11:00 |
| tristan | I.e. "Frontend", "Logging", etc, would be nice if they correspond to the subsystems for which certain groups are approved for review/direct commit | 11:00 |
| toscalix | adds68: nosoftware subgroup was to host everything that is not code | 11:00 |
| tristan | But let's not have that conversation unless we have it first on the mailing list | 11:00 |
| toscalix | that requires a specific structure on gitlab, different from buildstream repo | 11:01 |
| adds68 | toscalix, that is usually what people use the Gitlab wiki for see: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/wikis/home for EG | 11:01 |
| toscalix | adds68: no, the milestones are diferent, the label structure is different.... | 11:02 |
| toscalix | that is not what the gitlab wiki is for | 11:02 |
| toscalix | the wiki is for contents | 11:02 |
| toscalix | check the labels, the milestones... they are different in nosoftware | 11:02 |
| * adds68 is unsure what you are looking for, but for example Buildstream_polocies seems like a wiki page to me | 11:02 | |
| toscalix | we decided to avoid using the wiki on gitlab because we have the gnome wiki | 11:03 |
| toscalix | at the same time, we want to to keep the policies on git | 11:03 |
| toscalix | so we can control who changes it | 11:04 |
| toscalix | since they affect the governance of the project | 11:04 |
| adds68 | toscalix, where is the link to gnome-wiki? | 11:05 |
| toscalix | sadly we had to move the website to the root tree because of a limitation of gitlab with managing pages from repos inside subgroups | 11:05 |
| toscalix | on the website | 11:06 |
| toscalix | community page | 11:06 |
| toscalix | https://wiki.gnome.org/Projects/BuildStream/Monthly-Meeting | 11:06 |
| toscalix | by the way, there is a broken link on the community page | 11:06 |
| toscalix | that is the only page that we are promoting for now | 11:07 |
| toscalix | the rest of the contents are being deprecated or listed in the fron wiki page for now | 11:07 |
| toscalix | the work in that front is being tracked here: https://gitlab.com/BuildStream/website/issues/20 | 11:08 |
| adds68 | toscalix, so the website has it's own wiki page? | 11:11 |
| toscalix | no, it is the gnome wiki page. That is the only wiki we have | 11:11 |
| adds68 | toscalix, ah ok, so you can update the wiki page via Gitlab? Nice! | 11:13 |
| toscalix | gnome wiki ? No we cannot, which is why we are moving socntent that requires some level of control away from the wiki and into the website | 11:20 |
| toscalix | s/socntent/some content | 11:21 |
| toscalix | the gnome wiki is open to those with an account | 11:21 |
| toscalix | for some time, it was the only thing we had, so we added there everything | 11:22 |
| toscalix | now that we have the website, there is content we can move there, keeping the website for stuff where people without git knowledge might/can contribute to, or content that does not require certain level of control | 11:23 |
| toscalix | obviosuly which contents belongs where is questionable | 11:23 |
| toscalix | so far, I think info about meetings belongs there | 11:24 |
| toscalix | the front wiki page will remain as a directory for now | 11:24 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-required-artifacts->master: Don't delete required artifacts when tracking is enabled) #793 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/793 | 11:24 |
| toscalix | since it is still the number one output on searchs | 11:24 |
| flatmush | I'm trying to get binutils to build from git source, the easiest step seems to be to use a script in the repository to build a tarball, and then build binutils from the tarball. | 11:25 |
| flatmush | Is there an easy way to get buildstream to source a tar file from inside another artifact? | 11:25 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-required-artifacts-1.2->bst-1.2: Don't delete required artifacts when tracking is enabled) #794 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/794 | 11:26 |
| tristan | damn, those MRs are not ready :-S | 11:29 |
| *** robertheywood__ has joined #buildstream | 11:29 | |
| *** lachlan has quit IRC | 11:29 | |
| tristan | aha | 11:29 |
| *** robertheywood_ has quit IRC | 11:30 | |
| tlater[m] | flatmush: You'll probably want to have an element named `binutils-tar.bst`. It's just easiest to split that build into two steps. | 11:31 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-required-artifacts->master: Don't delete required artifacts when tracking is enabled) #793 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/793 | 11:31 |
| tlater[m] | Alternatively, of course, you can set your own build commands for this | 11:31 |
| * tlater[m] doesn't think there's an easy way to say "use this element as a source" | 11:31 | |
| coldtom | i think you could use a script element and stage the tarball element in a writable directory | 11:32 |
| coldtom | then recreate the install | 11:32 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-required-artifacts-1.2->bst-1.2: Don't delete required artifacts when tracking is enabled) #794 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/794 | 11:32 |
| gitlab-br-bot | buildstream: merge request (chandan/update-project-homepage->master: setup.py: Make website the primary homepage) #795 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/795 | 11:32 |
| tlater[m] | coldtom: I think in this case pre-pending the "build tarball" commands is a better option, since you can then just use the default plugin commands afterwards. | 11:33 |
| *** iker has joined #buildstream | 11:34 | |
| coldtom | tlater: agreed | 11:34 |
| tristan | tlater[m], Can you give https://gitlab.com/BuildStream/buildstream/merge_requests/793 a lookover ? | 11:37 |
| tlater[m] | tristan: Sure! | 11:37 |
| tristan | thanks :) | 11:37 |
| * tristan should really get a 1.2.1 out asap after this | 11:38 | |
| gitlab-br-bot | buildstream: merge request (adamjones/contribution-guide->master: Adamjones/contribution guide) #796 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/796 | 11:38 |
| tristan | Or people will get corrupted local artifact caches with 1.2.0 | 11:38 |
| tristan | when they reach quota | 11:38 |
| gitlab-br-bot | buildstream: merge request (adamjones/contribution-guide->master: Update contribution guide) #796 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/796 | 11:38 |
| tristan | adds68, You wanna break tradition for the sake of GitLab, cause they use a hard coded name and decided that people should call it CONTRIBUTING ? | 11:39 |
| tristan | adds68, I was very annoyed that GitLab wanted to make this decision for everyone else - but meh; I don't mind | 11:40 |
| tristan | that's what people want, let's give it to them :) | 11:40 |
| adds68 | tristan, it's annoying that you can't change it i agree, but i feel the UI link the Contributing is very valuable for new comers | 11:40 |
| * tristan thinks that we are on a higher level of cool than the younger projects to keep the traditional HACKING filename, but I digress | 11:41 | |
| adds68 | tristan, haha | 11:42 |
| *** lachlan has joined #buildstream | 11:44 | |
| tristan | adds68, I brought it up in #gitlab a while ago, when this obnoxious "Contributing" empty box appeared in the project page, being empty when we *clearly* had a HACKING file in place, with the correct name :) | 11:45 |
| adds68 | tristan, no way, what was their response? | 11:45 |
| tristan | but meh, no setting | 11:45 |
| adds68 | "it sounds too technical" ? | 11:45 |
| tristan | I suppose they had some debate about the filename, and CONTRIBUTING was more modern and perhaps politically correct | 11:46 |
| tristan | people don't want to refer to development by it's proper name "hacking", anymore, those days are sadly gone | 11:46 |
| tristan | adds68, I'm a bit more generally peeved that they decided on a name at all, as with everything they want to hard code us into their garden of how things work | 11:47 |
| tristan | instead of remaining extensible | 11:47 |
| adds68 | tristan, yea i imagine some web developer somewhere didn't want to have to read another variable from your gitlab conf :P | 11:48 |
| tristan | For instance, I want a way to generate my *own* analytics on their pages, by feeding my data from pipelines and interpreting that data for their chart representations | 11:48 |
| tristan | But no... they keep coming up with "Codequality" plugin... "It shall work this way and no way else !" | 11:49 |
| tristan | adds68, https://gitlab.com/BuildStream/buildstream/merge_requests/796 points the user to a file in the "alignment" repo, more fragmentation; I think that everything that materializes into what we want people to see, either goes onto the website, or in the docs | 11:53 |
| adds68 | tristan, so should i change that link to point to the wesbite? | 11:53 |
| adds68 | website* | 11:54 |
| tristan | I guess we have to actually create the content first ? | 11:54 |
| adds68 | toscalix, ^ ? | 11:55 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-required-artifacts->master: Don't delete required artifacts when tracking is enabled) #793 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/793 | 12:08 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-required-artifacts-1.2->bst-1.2: Don't delete required artifacts when tracking is enabled) #794 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/794 | 12:11 |
| toscalix | adds68: if we think that the incorporating a section related with policies in the community page is a priority at this point, then find with me. We can, as second step, move the policies to the website | 12:16 |
| toscalix | once we finish the current contents | 12:16 |
| toscalix | did I answered the question? | 12:17 |
| tristan | Frankly, this part will probably land up in CONTRIBUTING.rst anyway, as the plan is to structure it better and make it much more elaborate | 12:19 |
| tristan | filing issues, committer policy, coding guidelines, are all part of a contributors guide afaics | 12:19 |
| *** lachlan has quit IRC | 12:20 | |
| tristan | tlater[m], unfortunately, there is no straight forward way to "only turn an iterable into a list if the iterable is a generator" | 12:20 |
| tristan | tlater[m], so I'm living with "elements = list(elements)" | 12:20 |
| tlater[m] | tristan: That's what I expected you to do :) | 12:20 |
| tristan | I don't like it, but options to work around that are limited :-S | 12:21 |
| tlater[m] | It's a bit of a shortcoming of python, with the whole quacking ducks thing. | 12:21 |
| tristan | isinstance(iterable, collections.Sequence) is an option | 12:21 |
| tristan | yeah | 12:21 |
| tlater[m] | tristan: My idea here is just to clearly document what kind of iterables are expected. In this case we expect a generator - if someone gives us a list, it won't be optimized. | 12:22 |
| tlater[m] | But I don't think this is going to be the end of the world for a few hundred elements anyway. | 12:23 |
| tristan | tlater[m], it's a one off, but indeed I think that long term we should have clear guidelines on how to handle iterable inputs | 12:24 |
| tlater[m] | Type hints may help - jmac has been pushing for us to use those. | 12:24 |
| tristan | tlater[m], it's certainly better to handle on the receiving end, and say "You can call this with any iterable", than the other way around, where you tell the caller to "be careful" | 12:25 |
| tristan | tlater[m], done with comments I suppose ? | 12:26 |
| tlater[m] | tristan: They're actually incorporated into the function header | 12:26 |
| tristan | tlater[m], as a point of interest; it's interesting how the regression test fails without the fix applied | 12:26 |
| tristan | tlater[m], since they are all import elements, the cleanup job just happily cleans everything up as needed, and the build reports SUCCESS ! | 12:27 |
| tristan | tlater[m], but only the last built artifacts are cached (but show up as "waiting", because they depend on deleted deps) | 12:27 |
| tlater[m] | Hmm | 12:28 |
| tlater[m] | We might want to check if all built elements actually end up "cached" before we report success, then | 12:28 |
| tristan | In real life, this usually aborts with an "artifact not found" error/bug when staging dependencies for a build | 12:28 |
| tristan | tlater[m], Nah, adding more checks is usually not the right answer | 12:29 |
| tristan | tlater[m], We now have a regression test for this - but adding runtime checks to the code, because we don't trust it to do what it's supposed to do, adds more complexity and takes away from clarity over time | 12:30 |
| tristan | Such that we trust less and less that it does what it's supposed to | 12:30 |
| adds68 | tristan, so we merge this for now, open a new issue for me to update once the website is updated? | 12:30 |
| tlater[m] | I suppose the only way we can ever run into this outside of the test suite is if a user decides to deliberately remove an artifact during cleanup. | 12:30 |
| tristan | adds68, I'm fine with that | 12:30 |
| tristan | adds68, It will be the CONTRIBUTING.rst I think which gets updated, and the link which goes away | 12:30 |
| adds68 | :) | 12:32 |
| tristan | tlater[m], I don't think it will be allowed ultimately | 12:32 |
| tristan | tlater[m], We already know that we have issues with concurrent instances | 12:32 |
| tristan | tlater[m], It's low priority but it's on the radar, we should avoid stop gap fixes and slowly work towards perfection | 12:33 |
| tristan | tlater[m], stop gaps are good if we really have serious issues that effect users and we need a fix right away | 12:33 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-required-artifacts->master: Don't delete required artifacts when tracking is enabled) #793 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/793 | 12:34 |
| tristan | tlater[m], in case that was ambiguous somehow, the expected behavior should be that `bst artifact delete <artifact name>` returns non-zero and says "This artifact is required by an ongoing build" or such | 12:35 |
| tlater[m] | Y | 12:35 |
| tlater[m] | *Yeah that was pretty clear :) | 12:35 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 12:39 |
| gitlab-br-bot | buildstream: merge request (adamjones/contribution-guide->master: Update contribution guide) #796 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/796 | 12:43 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-required-artifacts->master: Don't delete required artifacts when tracking is enabled) #793 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/793 | 12:44 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-required-artifacts-1.2->bst-1.2: Don't delete required artifacts when tracking is enabled) #794 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/794 | 12:44 |
| tristan | tiagogomes, Your question is a very hard one for me to answer at the moment | 12:48 |
| tristan | tiagogomes, and approaching 10pm, I don't think it will be answered this week | 12:48 |
| tristan | bochecha, They have gone a long way towards debugging the confidential issue, and are pointing out they have another issue https://gitlab.com/gitlab-org/gitlab-ce/issues/41973, which is about the inability to invite participants to discuss confidential issues ! | 12:50 |
| bochecha | tristan: shaving the yak all the way down :) | 12:50 |
| tristan | bochecha, they are asking me to gather information from you because of this... they are unable to reproduce :-S | 12:51 |
| tristan | sec | 12:51 |
| tristan | bochecha, they ask if the edit was made through this UI: https://gitlab.com/BuildStream/bst-external/edit/master/bst_external/elements/collect-integration.py ? | 12:51 |
| tristan | bochecha, and if the process involved creating a merge request and such and such | 12:51 |
| bochecha | tristan: I browsed to the file: https://gitlab.com/BuildStream/bst-external/blob/master/bst_external/elements/collect-integration.py | 12:52 |
| tristan | bochecha, clearly they take the issue seriously, but eh... what canna do | 12:52 |
| bochecha | clicked "Edit" | 12:52 |
| bochecha | which indeed lead me to the edit UI you linked to | 12:52 |
| bochecha | the "target branch" was prefilled as "master" | 12:53 |
| bochecha | I clicked "commit changes" | 12:53 |
| bochecha | trying it again, the "target branch" is prefilled as "patch-1", so at least this doesn't seem like it would happen inadvertently like it did | 12:53 |
| bochecha | it did not create a merge request, it just committed to master | 12:53 |
| tristan | bochecha, I'll paste your comments back to the issue | 12:54 |
| tristan | bochecha, thanks :) | 12:59 |
| bochecha | np | 12:59 |
| tristan | Anyway, it's not a huge deal to me, just trying to be helpful to them :) | 12:59 |
| tristan | WSalmon, I didnt get a chance to reply your email, but I think that what you are saying is that we should somehow make it clear who is committer in which area (I think the COMMITTERS file does this ?) in policy, so that reviewers are easier to find ? | 13:06 |
| tristan | Which I think is a large part of the intent ? | 13:06 |
| tristan | But... anyway I'll write back to the list when I get a chance | 13:06 |
| *** lachlan has joined #buildstream | 13:08 | |
| *** iker has quit IRC | 13:08 | |
| *** ikerperez has quit IRC | 13:08 | |
| *** iker has joined #buildstream | 13:08 | |
| *** ikerperez has joined #buildstream | 13:09 | |
| *** tristan has quit IRC | 13:09 | |
| *** lachlan has quit IRC | 13:11 | |
| *** alatiera_ has quit IRC | 13:46 | |
| *** alatiera_ has joined #buildstream | 13:47 | |
| *** lachlan has joined #buildstream | 13:47 | |
| *** lachlan has quit IRC | 13:51 | |
| tiagogomes | https://twitter.com/gnomealex/status/1040558646122430464 :o | 13:52 |
| bochecha | tiagogomes: yeah, he announed it in #flatpak earlier and some of us were going bonkers :) | 13:55 |
| tiagogomes | xD | 13:56 |
| *** lachlan has joined #buildstream | 13:59 | |
| *** lachlan has quit IRC | 14:02 | |
| *** ikerperez has quit IRC | 14:12 | |
| gitlab-br-bot | buildstream: merge request (jonathan/pickle-yaml->master: WIP: Add a cache of parsed and provenanced yaml) #787 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/787 | 14:17 |
| *** ikerperez has joined #buildstream | 14:20 | |
| *** iker has quit IRC | 14:21 | |
| *** lachlan has joined #buildstream | 14:38 | |
| *** lachlan has quit IRC | 14:45 | |
| *** lachlan has joined #buildstream | 14:48 | |
| gitlab-br-bot | buildstream: merge request (danielsilverstone-ct/fix-654->master: sandbox/_sandboxremote.py: Acquire CASCache via Platform) #797 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/797 | 14:56 |
| Kinnison | jmac: Thanks for the chat I had with you earlier. I've submitted !797 to resolve #654 - it passed tests on my machine but I'm still waiting for the pipelines on gitlab. | 14:58 |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 14:59 |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 15:02 |
| * qinusty wanted to use pytest-quickcheck for a test... Ended up raising a ticket https://bitbucket.org/pytest-dev/pytest-quickcheck/issues/12/configuring-different-ranges-per-parameter | 15:02 | |
| Kinnison | qinusty: can you not use the decorator twice, once for each parameter? | 15:03 |
| qinusty | heh | 15:06 |
| * qinusty just tried this | 15:06 | |
| qinusty | Yes. Yes you can, HOWEVER it uses the min_num, max_num specified by the first fixture. | 15:06 |
| qinusty | for BOTH values | 15:06 |
| Kinnison | oh jeepers | 15:06 |
| Kinnison | Someone didn't test that very well | 15:07 |
| *** lachlan has quit IRC | 15:11 | |
| *** robertheywood__ has quit IRC | 15:12 | |
| gitlab-br-bot | buildstream: merge request (adamjones/contribution-guide->master: Update contribution guide) #796 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/796 | 15:16 |
| gitlab-br-bot | buildstream: merge request (adamjones/contribution-guide->master: Update contribution guide) #796 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/796 | 15:20 |
| *** lachlan has joined #buildstream | 15:23 | |
| *** lachlan has quit IRC | 15:30 | |
| qinusty | Can someone dockery take a look at this https://gitlab.com/BuildStream/buildstream-docker-images/merge_requests/66, Adding a development dependency for some tests I'm working on. I can merge but would appreciate a glance from someone :D | 15:35 |
| qinusty | Anyone got any ideas what's going on here https://hastebin.com/kazafelaje.cpp? I assume the [x-y] is the parameters separated by a hyphen (I'm printing the space separated numbers on the right...) | 15:41 |
| qinusty | SOMETIMES, the parameter numbers aren't identical.... | 15:41 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/some-cleanups->master: Bunch of cleanups) #798 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/798 | 15:42 |
| Kinnison | This is pointing at pytest-quickcheck not being very safe to use | 15:42 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-287-backport->bst-1.2: Backport of !678 (Add validation of configuration variables) to 1.2 branch.) #789 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/789 | 15:43 |
| qinusty | :D | 15:44 |
| qinusty | :( | 15:44 |
| * qinusty will just add 4-5 test cases manually and leave it at that. | 15:46 | |
| *** lachlan has joined #buildstream | 15:52 | |
| gitlab-br-bot | buildstream: merge request (Qinusty/unit-test-utils->master: Add unit tests for some utils.py functions) #799 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/799 | 16:01 |
| gitlab-br-bot | buildstream: merge request (Qinusty/unit-test-utils->master: Add unit tests for some utils.py functions) #799 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/799 | 16:01 |
| *** lachlan has quit IRC | 16:02 | |
| gitlab-br-bot | buildstream: merge request (chandan/automate-pypi-release->master: WIP: .gitlab-ci.yml: Publish to PyPI when new tags are pushed) #731 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/731 | 16:06 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/some-cleanups->master: Bunch of cleanups) #798 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/798 | 16:08 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-287-backport->bst-1.2: Backport of !678 (Add validation of configuration variables) to 1.2 branch.) #789 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/789 | 16:10 |
| gitlab-br-bot | buildstream: merge request (coldtom/strip-rules->master: WIP: Upstream freedesktop-sdk strip rules) #750 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/750 | 16:10 |
| gitlab-br-bot | buildstream: merge request (chandan/automate-pypi-release->master: .gitlab-ci.yml: Publish to PyPI when new tags are pushed) #731 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/731 | 16:25 |
| gitlab-br-bot | buildstream: merge request (jmac/remote_exec_checkout_fix->master: Remote exec: Remove early warning and check directory is not None) #800 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/800 | 16:33 |
| *** CTtpollard has quit IRC | 16:34 | |
| *** ikerperez has quit IRC | 16:37 | |
| *** lachlan has joined #buildstream | 16:38 | |
| jmac | https://gitlab.com/BuildStream/buildstream/merge_requests/800 is a potential fix for `bst checkout` under remote execution (but see the caveat in the descripton) | 16:39 |
| *** lachlan has quit IRC | 16:45 | |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-573->master: Reduce IO overhead caused by artifact cache size calculation) #671 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/671 | 16:47 |
| gitlab-br-bot | buildstream: merge request (adamjones/contribution-guide->master: Update contribution guide) #796 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/796 | 16:47 |
| gitlab-br-bot | buildstream: issue #287 ("Special / Magic variables are unprotected") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/287 | 16:49 |
| Kinnison | Thanks jmac, if noone else gets to it, I'll give it a look over on Monday | 16:53 |
| *** lachlan has joined #buildstream | 17:01 | |
| *** lachlan has quit IRC | 17:06 | |
| gitlab-br-bot | buildstream: merge request (adamjones/contribution-guide->master: Update contribution guide) #796 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/796 | 17:08 |
| gitlab-br-bot | buildstream: issue #655 ("Update CONTRIBUTING.rst to point to website") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/655 | 17:11 |
| gitlab-br-bot | buildstream: merge request (adamjones/contribution-guide->master: Update contribution guide) #796 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/796 | 17:14 |
| gitlab-br-bot | buildstream: merge request (jonathan/pickle-yaml->master: WIP: Add a cache of parsed and provenanced yaml) #787 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/787 | 17:18 |
| *** toscalix has quit IRC | 17:21 | |
| *** lachlan has joined #buildstream | 17:32 | |
| *** jonathanmaw_ has quit IRC | 17:38 | |
| *** lachlan has quit IRC | 17:40 | |
| *** lachlan has joined #buildstream | 17:51 | |
| *** lachlan has quit IRC | 17:58 | |
| *** rdale has quit IRC | 18:05 | |
| *** lachlan has joined #buildstream | 18:16 | |
| *** lachlan has quit IRC | 18:34 | |
| *** lachlan has joined #buildstream | 19:21 | |
| *** cs-shadow has quit IRC | 19:29 | |
| *** lachlan has quit IRC | 19:39 | |
| *** tristan has joined #buildstream | 20:16 | |
| *** ChanServ sets mode: +o tristan | 20:16 | |
| *** xjuan has joined #buildstream | 20:33 | |
| *** alatiera_ has quit IRC | 20:47 | |
| *** alatiera_ has joined #buildstream | 20:47 | |
| *** bochecha has quit IRC | 21:00 | |
| *** bochecha has joined #buildstream | 21:02 | |
| *** bochecha has quit IRC | 21:36 | |
| *** tristan has quit IRC | 21:37 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!