| *** bochecha has quit IRC | 00:00 | |
| *** gitlab-br-bot has quit IRC | 00:07 | |
| *** phildawson has quit IRC | 00:07 | |
| *** aiden has quit IRC | 00:07 | |
| *** WSalmon has quit IRC | 00:07 | |
| *** tiagogomes has quit IRC | 00:07 | |
| *** flatmush has quit IRC | 00:07 | |
| *** qinusty has quit IRC | 00:07 | |
| *** juergbi has quit IRC | 00:07 | |
| *** adds68 has quit IRC | 00:07 | |
| *** lantw44 has quit IRC | 00:07 | |
| *** skullman has quit IRC | 00:07 | |
| *** Trevinho has quit IRC | 00:07 | |
| *** ironfoot has quit IRC | 00:07 | |
| *** hergertme has quit IRC | 00:07 | |
| *** gitlab-br-bot has joined #buildstream | 00:08 | |
| *** phildawson has joined #buildstream | 00:08 | |
| *** aiden has joined #buildstream | 00:08 | |
| *** WSalmon has joined #buildstream | 00:08 | |
| *** tiagogomes has joined #buildstream | 00:08 | |
| *** flatmush has joined #buildstream | 00:08 | |
| *** qinusty has joined #buildstream | 00:08 | |
| *** juergbi has joined #buildstream | 00:08 | |
| *** adds68 has joined #buildstream | 00:08 | |
| *** lantw44 has joined #buildstream | 00:08 | |
| *** skullman has joined #buildstream | 00:08 | |
| *** Trevinho has joined #buildstream | 00:08 | |
| *** ironfoot has joined #buildstream | 00:08 | |
| *** hergertme has joined #buildstream | 00:08 | |
| *** mohan43u has quit IRC | 02:43 | |
| *** mohan43u has joined #buildstream | 02:43 | |
| *** mohan43u has quit IRC | 05:13 | |
| *** mohan43u has joined #buildstream | 05:16 | |
| *** leopi has joined #buildstream | 05:47 | |
| *** issyl0 has joined #buildstream | 06:34 | |
| *** ernestask has joined #buildstream | 06:52 | |
| *** ernestask has quit IRC | 07:28 | |
| *** leopi has quit IRC | 07:37 | |
| *** ernestask has joined #buildstream | 07:37 | |
| *** toscalix has joined #buildstream | 07:43 | |
| *** tristan has joined #buildstream | 08:08 | |
| *** leopi has joined #buildstream | 08:12 | |
| gitlab-br-bot | buildstream: merge request (Qinusty/235-manifest->master: Implement generated build manifests) #596 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/596 | 08:15 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (willsalmon/trackWarning->master: git.py: Add warning to git track if track and ref are not present) #580 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/580 | 08:29 |
| gitlab-br-bot | buildstream: issue #539 ("Allow debugging of remotely failed builds") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/539 | 08:33 |
| gitlab-br-bot | buildstream: issue #481 ("Misleading SUCCESS status when artifact push is skipped") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/481 | 08:35 |
| toscalix | tristan: paulsherwood I suggested on the list to give a little more thought to the naming. I think the current proposal brings controversy, maybe as much as the one we solve | 08:41 |
| toscalix | if we have no better proposal, then we go for the current one | 08:42 |
| toscalix | naming is one of those things that benefit from having a wide audience thinking about it | 08:42 |
| toscalix | out loud | 08:42 |
| *** coldtom has quit IRC | 08:44 | |
| *** bochecha has joined #buildstream | 08:45 | |
| *** coldtom has joined #buildstream | 08:49 | |
| laurence | tristan, in meetings this morning, but I shall fix up my mess of tickets after that :) | 08:49 |
| laurence | tristan, those tickets are like my personal technical debt, ha | 08:49 |
| gitlab-br-bot | buildstream: merge request (jmac/cas_virtual_directory->master: WIP: CAS-backed virtual directory implementation) #481 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/481 | 08:51 |
| *** noisecell has joined #buildstream | 08:56 | |
| gitlab-br-bot | buildstream: merge request (Qinusty/docs_changes->master: HACKING.rst: Add running a single test example) #597 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/597 | 09:13 |
| gitlab-br-bot | buildstream: merge request (Qinusty/docs_changes->master: HACKING.rst: Add running a single test example) #597 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/597 | 09:14 |
| gitlab-br-bot | buildstream: issue #511 ("Fixing VCS reduction") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/511 | 09:15 |
| qinusty | tristan, jjardon had a question about !596 being backported to 1.2 once merged. What is the state of the feature freeze? | 09:15 |
| tristan | laurence, I think I've covered all of the technical debt issues at this point, I suggest closing 536 | 09:16 |
| tristan | laurence, Next on my todo is (A) open issues for the bst artifact command subgroup discussed on the ML... and (B) open issues for the non-determinism of many of our Source implementations | 09:17 |
| tristan | qinusty, I dont know where !596 is coming from, and I don't recall seeing a proposal to the list for this either | 09:18 |
| tristan | qinusty, my preference would be to handle that with `bst artifact list-contents`, from the already proposed command subgroup | 09:18 |
| tristan | qinusty, jjardon: it is absolutely not okay to use the new commit policy to sneak new features into core without prior discussion | 09:20 |
| tristan | Just to make that clear. | 09:20 |
| tristan | (I know your intentions are in the right place, though :)) | 09:20 |
| qinusty | Manifest generation was discussed with freedesktopsdk. There was no intention of merging without discussion, it was a feature branch created to investigate the issue further and see what could be done. | 09:20 |
| tristan | qinusty, sorry for the reaction; this is caused by how the MR is dressed. First of all this is a merge request, not just a side branch, second of all it is not WIP | 09:22 |
| tristan | This spells out to me: Fair game for review and merge | 09:22 |
| tristan | qinusty, in any case, the next logical step would be to take it to the mailing list, as I stated above, my preference will be to have similar functionality solve the use case from the `bst artifact` command subgroup | 09:23 |
| qinusty | ^ I see where you're coming from. That is my bad on the lack of WIP. The MR was mainly to get the ideas out there regarding what sort of things could be done to approach the issue at hand. The ML is more likely the place to this (I half drafted a proposal before investigating some possibilities) | 09:25 |
| gitlab-br-bot | buildstream: merge request (Qinusty/235-manifest->master: WIP: Implement generated build manifests) #596 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/596 | 09:25 |
| qinusty | Also tristan, I looked into the issue of --track modifying indentation. It appears to be a regression from the project.refs work. The issue can be found here https://gitlab.com/BuildStream/buildstream/issues/470. | 09:38 |
| * tristan *palmface* | 09:45 | |
| tristan | qinusty, thanks for adding your findings to that issue :) | 09:45 |
| qinusty | No worries, I wasn't sure where to go from there since the changes were fixes from another issue and didn't want to cause a regression by 'fixing' #470 :D | 09:47 |
| gitlab-br-bot | buildstream: merge request (Qinusty/docs_changes->master: HACKING.rst: Add running a single test example) #597 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/597 | 10:02 |
| qinusty | Anyone against https://gitlab.com/BuildStream/buildstream/merge_requests/597 being merged? Small section added to HACKING.rst regarding running individual tests | 10:03 |
| gitlab-br-bot | buildstream: issue #491 ("Users can specify an artifact cache quota larger than their disk size") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/491 | 10:03 |
| tpollard | qinusty: I've merged it | 10:03 |
| tristan | valentind, around ? | 10:24 |
| valentind | yes | 10:25 |
| valentind | tristan, | 10:25 |
| tristan | valentind, lets get this includes feature in... I'm looking at the discussion page and see that there are still comments which are not "resolved", but say that the code was changed | 10:25 |
| tristan | I need to know that I'm only looking at relevant open comments, not addressed ones. | 10:25 |
| valentind | tristan, Everything was addressed except one that you did not answer. But I kept some opened for you to remember the different dicussions. | 10:26 |
| tristan | ok.. | 10:27 |
| valentind | The straight forwards are closed. | 10:27 |
| tristan | valentind, "I will however try to remove side effect in artifactcache.py." did we move that side effect from the artifact cache ? | 10:27 |
| valentind | tristan, Actually, I see everything was fixed. Just one I wondered if we really wanted to not forbid name and element-path to be overriden. | 10:28 |
| valentind | tristan, Yes I did. | 10:28 |
| valentind | I made _stream.py call all the ensure_fully_loaded before calling the artifactcahe method. | 10:28 |
| tristan | valentind, thanks; about the other one... lemme see, that's the old comment from a month ago ? | 10:29 |
| * tristan looks at code | 10:29 | |
| tristan | valentind, are we talking about the Includes() constructor here ? | 10:32 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-195->master: Add validation for project paths) #593 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/593 | 10:33 |
| valentind | tristan, the class I think. | 10:33 |
| valentind | tristan, You see there was a "valid_keys" parameter. That does not exist anymore. | 10:34 |
| valentind | This was a parameter to say what keys are valid at top level. | 10:34 |
| valentind | This was removed. | 10:34 |
| tristan | valentind, I think we made the right move to remove that, yes | 10:34 |
| valentind | But we do not verify anymore that "name" or "element-path" is overwritten. | 10:34 |
| tristan | I understand the problem, but the code is better this way | 10:35 |
| valentind | OK | 10:35 |
| valentind | The we can resolve it. | 10:35 |
| tristan | In the worst case, we can perform validation around it (compare before/after), but I think we can live with the functionality as is for a start | 10:36 |
| tristan | valentind, did we squash the commit which places the cleanup() method in the right place ? | 10:37 |
| valentind | tristan, yes. | 10:37 |
| valentind | tristan, Also in my last comment, I found two bugs: #538 and #537. You should look at them. | 10:39 |
| tristan | valentind, ok I'll try to give it another light lookover but I think it's ready, last review was quite thorough I think... | 10:39 |
| tristan | and exactly what I was going to say | 10:39 |
| valentind | I added tests to make sure that mirror configuration was picked up correctly. And found those. | 10:40 |
| tristan | I have open tabs on them and need to check those | 10:40 |
| tristan | toscalix, oh wait; so you are *still* using "Critical" in your priority scale ? | 10:43 |
| tristan | I thought we went over this | 10:43 |
| tristan | toscalix, context: I am adding "Critical" to https://gitlab.com/BuildStream/buildstream/issues/538 because it's a crasher, as the "Critical" tag has always been, indicating impact; regardless of whether or not we have resources to prioritize for it | 10:44 |
| tristan | toscalix, I am *also* marking it as "Urgent", so that it gets on to the priority scale and gets discussed | 10:45 |
| tristan | Please advise what I should do instead, and where my Critical label has gone | 10:45 |
| tristan | If that has been renamed or changed, have all of the previously Critical issues been labelled with something new that I should know about ? | 10:46 |
| tristan | (and I can use instead) | 10:46 |
| tristan | valentind, I can say that #538 is certainly a problem with mirroring which probably needs attention from jonathan maw; that assertion should never fail | 10:47 |
| tristan | valentind, for the other issue about git, #537... can you clarify that the test case you added still breaks without the includes work ? | 10:48 |
| valentind | tristan, Yes it fails. | 10:49 |
| * tristan checks the history of the branch, thinking maybe the added test case is placed *before* any of the include related commits | 10:49 | |
| tristan | ah | 10:49 |
| valentind | tristan, I tried to move the list of mirrors in the project.conf and remove the include. Still fails. | 10:49 |
| valentind | It is because we list all submodules when returning fetchers. | 10:50 |
| valentind | And when we do that we clone from upstream. | 10:50 |
| tristan | valentind, have you tried the test on a separate branch, without any of the include feature at all ? | 10:50 |
| valentind | tristan, no I have not tried that. I can do that if you want. But the bug is so obvious that I think it is not a problem with includes. | 10:51 |
| tristan | valentind, Ok I see what you mean | 10:51 |
| tristan | valentind, My concern was because the way that we parse mirror configuration might be complicated (we still suffer from that horrible artifact cache delegation of configuration parsing) | 10:52 |
| valentind | tristan, get_source_fetchers which is called out of the loop through mirrors, calls itself refresh_submodules, which calls self.mirror.ensure() | 10:52 |
| valentind | And this runs git clone. | 10:53 |
| tristan | valentind, to clarify; your branch adds new tests that are commented out ? | 10:53 |
| valentind | tristan, only track was tested for fallback in the tests. The fetch was not tested. | 10:53 |
| valentind | There are two FIXME in one of the two tests I added in tests/frontend/mirror.py | 10:54 |
| tristan | are there commented out tests ? | 10:55 |
| valentind | @pytest.mark.parametrize("kind", [(kind) for kind in ALL_REPO_KINDS if kind not in ['git', 'ostree']]) | 10:55 |
| valentind | tristan, I disabled git and ostree. | 10:55 |
| tristan | Gah, okay that is one way | 10:55 |
| valentind | I still wanted to run it on others. At least it shows the include part works. Just that git and ostree plugins have bugs. Also the mirror feature is fine, I think it is just bugs in the plugins. | 10:56 |
| tristan | valentind, I was hoping for a SKIP notification from pytest, instead of anything commented out, but I see how this poses an issue | 10:56 |
| valentind | Is it possible with pytest to raise a skip? | 10:57 |
| tristan | Oh yeah that's a good idea ! | 10:57 |
| tristan | valentind, yeah I have an example one sec... | 10:58 |
| tristan | valentind, see tests/testutils/repo/git.py for an example of calling pytest.skip() when git is not available on the host | 10:58 |
| tristan | valentind, it will be better to change that `if kind not in [...]` to do that in the beginning of the test body :) | 10:59 |
| valentind | OK | 10:59 |
| valentind | I do that. | 10:59 |
| tristan | making sure it keeps slapping us in the face with a SKIP message when we run the tests, is preferable :D | 10:59 |
| tristan | valentind, a separate line for each will also be nice, so the fixing merges simply remove lines from the test | 11:00 |
| toscalix | tristan, the old critical is now high_impact | 11:01 |
| toscalix | critical is severity, kind of, let's leave everything and focus on this | 11:01 |
| toscalix | for times like tomorrow, last day before feature freeze, or something going wrong on release day.... | 11:02 |
| tristan | toscalix, Ok I will change that... I find High_Impact to be a bit too blue, and wonder if it carries the same very high weight when sorting the issues page by label priority weight | 11:02 |
| valentind | tristan, that worked. pushing now. | 11:02 |
| toscalix | tristan: the color can be changed. I would ike to avoid red though since it is used in Urgent and critical (light and dark red) | 11:02 |
| tristan | toscalix, i.e. when I view the whole issues page; I want to see blockers and high impact stuff at the top, severity of the issue | 11:02 |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 11:03 |
| toscalix | I can create a board for those | 11:03 |
| tristan | toscalix, I am not at all interested from that point of view, in what we have judged we have resources to focus on at a given point in time | 11:03 |
| tristan | I think that we can live without the boards for that; it's just the default view | 11:03 |
| toscalix | you mean on the issues list? | 11:04 |
| tristan | exactly | 11:04 |
| toscalix | I am afraid you only have available some filters by default. Let me check if I can add one | 11:04 |
| *** jjardon has quit IRC | 11:04 | |
| tristan | toscalix, in my drop box, I can sort by last updated, created date, priority etc | 11:05 |
| tristan | these days I've been looking at last updated, but I also like to view the whole list sorted by priority | 11:05 |
| tristan | this is controlled by the order of the "prioritized labels" in the labels page | 11:05 |
| toscalix | yes, but it is done globally, so everybody would have the same view | 11:06 |
| tristan | Exactly | 11:06 |
| tristan | toscalix, I expect that the issues page shows everything, and I can sort it by how high impact it is basically | 11:06 |
| *** jjardon has joined #buildstream | 11:06 | |
| toscalix | but that is imposing such view to everybody else. Other people is interested in other priorities | 11:06 |
| tristan | toscalix, and the boards provide the finer detail about what we're prioritizing work on | 11:07 |
| tristan | i.e. I am assuming it should not effect the boards; which have specific labels I think to categorize issues in boxes | 11:07 |
| toscalix | prioritising labels have impact in other places | 11:07 |
| toscalix | it does not affect the boards, I believe | 11:07 |
| tristan | Right, so that should be fine ? | 11:08 |
| tristan | I.e. the global view can be sorted by "how bad the problem is" | 11:08 |
| toscalix | but it will impose high_impact issues to everybody using that filter | 11:08 |
| tristan | and the boards are not going to be negatively impacted by this | 11:08 |
| toscalix | let me check one thing | 11:08 |
| tristan | Yes, but everyone using the issues filter I believe have been using that since before all the boards, I want to preserve the original meaning there without harming the boards :D | 11:09 |
| toscalix | forget for a second about the boards | 11:10 |
| tristan | :) | 11:10 |
| toscalix | prioritising labels and boards are unrelated | 11:10 |
| toscalix | right now, the label priority are: blockers -> critical -> urgent -> important | 11:10 |
| toscalix | so when you use the filter priority label, you find the issues listed in that order | 11:11 |
| toscalix | that is, per severity | 11:11 |
| toscalix | what is your proposal exactly? | 11:11 |
| tristan | toscalix, blockers -> high impact -> bug -> enhancement | 11:12 |
| toscalix | add high_impact between critical and urgent? | 11:12 |
| tristan | I think you have commandeered critical / urgent / important, to deal with workflow and what we are able to focus on | 11:12 |
| tristan | I see this as unrelated to "how bad the problem is" | 11:13 |
| gitlab-br-bot | buildstream: merge request (dp0/513/cas-cache-client-certs->master: WIP: Support dynamic client certificates for CAS cache) #594 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/594 | 11:13 |
| toscalix | by doing a board with that order, you will have a better overview and you will see more issues than in the issues list plus... that priority is yours. I mean, other do not have it | 11:13 |
| tristan | I dont really want to view issues in a board at all; I dont want any filtering, and I want to see the full page | 11:14 |
| tristan | Whether the order I suggested makes sense or not; we should be able to sort the list by "how bad things are" | 11:15 |
| tristan | Normally, I will view the list from the last page first (reverse order), to ensure that new issues without tags are attended to, also | 11:15 |
| toscalix | ah, ok, this is about what you want so everybody will inherit. Then there is obviously no discussion. Let me do it in the buildstream repo. I will keep the group level as it is. This way you will have what you want but we all keep a different criteria tto, although in a different place | 11:16 |
| toscalix | done | 11:19 |
| tristan | toscalix, Thanks, I don't want to mess up any boards; I just want the global/default picture to reflect severity, rather than what we've prioritized | 11:21 |
| tristan | toscalix, and yes, I recognize the value in taking issues which we can realistically prioritize :D | 11:23 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-195->master: Add validation for project paths) #593 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/593 | 11:24 |
| tristan | valentind, ok so... one last thing | 11:33 |
| tristan | valentind, When correcting the documentation the other day, I pointed out that we should mention that the directive supports string, or list of strings | 11:33 |
| tristan | valentind, Does it actually support that ? | 11:33 |
| tristan | valentind, other than that, I have make one more comment about the version needing another bump since your last rebase | 11:34 |
| tristan | s/make/made | 11:34 |
| tiagogomes | I am keep hitting https://gitlab.com/BuildStream/buildstream/issues/520. This should be resolved asap | 11:34 |
| tristan | tiagogomes, marked this as Urgent instead of Important, that is the policy from toscalix; for ensuring this comes up in our sync up meetings and such... | 11:35 |
| toscalix | it is already | 11:36 |
| toscalix | ah, you did, great | 11:36 |
| tristan | yeah I just swapped the label right now :) | 11:36 |
| toscalix | tiagogomes: will you be able to finish the blocker tomorrow with this unfixed? | 11:37 |
| toscalix | otherwise, this is a blocker | 11:37 |
| toscalix | sorry critical | 11:37 |
| tristan | Yeah critical probably better :) | 11:38 |
| valentind | valentind, I think it does and there is a test. Let me check. | 11:39 |
| toscalix | if critical, we might need to change assignments and reconsider what we can deliver by tomorrow | 11:39 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-195-1.2->bst-1.2: Add validation for project paths) #598 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/598 | 11:39 |
| tristan | Afaics, my comments on tiagogomes's blocker are easy to resolve, but if CI is suffering due to this race (damn I fixed a similar one just last weekend !), that is a real drag :-S | 11:39 |
| tristan | valentind, gotcha; I think we're about ready - I sort of feel that we should adjust the example to show the string form rather than list form (because I think that string form will be much more commonly used) | 11:40 |
| valentind | tristan, I verified. There is test for include as string. | 11:40 |
| valentind | tristan, sure. | 11:41 |
| tristan | valentind, great | 11:41 |
| tristan | valentind, in that case... lets take the plunge ! | 11:41 |
| tristan | valentind, I leave it in your hands to (A) fix/adjust the version bump and related doc... (B) adjust that little example... (C) merge to master... (D)... merge to bst-1.2 | 11:42 |
| tristan | valentind, nice huge patch btw ! | 11:42 |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 11:42 |
| tiagogomes | Why are me merging that includes feature into 1.2? IMO the priority should be fixing the regressions like #500 and #520 | 11:44 |
| valentind | tristan, What did you mean about version bump? | 11:44 |
| tristan | tiagogomes, Because we need it for 1.2, it's on the blocker list | 11:44 |
| valentind | tristan, Did you just mean rebase? | 11:44 |
| tristan | tiagogomes, it doesnt make the other things less of a priority, but remember we have a fix window in feature freeze | 11:44 |
| tristan | valentind, you already rebased, causing your change to _versions.py to disappear from the patch | 11:45 |
| tristan | valentind, master has added features since, now the new format version would be 12 | 11:45 |
| tiagogomes | I think that fixing the regressions should have higher priority | 11:45 |
| tristan | tiagogomes, I don't disagree | 11:45 |
| tristan | tiagogomes, however we absolutely need a hand full of features on 1.2 | 11:45 |
| tiagogomes | It is hardly debatable. | 11:46 |
| tristan | tiagogomes, we branched bst-1.2 *early* this cycle to accommodate other things | 11:46 |
| tristan | tiagogomes, the reason for the selected features is related to activities we have to be able to do with the 1.2.x line over the next 6 months | 11:46 |
| tristan | tiagogomes, for instance, the includes feature is what allows us to provide a sensible build story for building Flatpak apps | 11:47 |
| tristan | We cannot do any of those activities if we dont have the feature, and we cannot recommend the development line in this cycle | 11:47 |
| valentind | tristan, OK, I understand now. | 11:47 |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 11:48 |
| valentind | tristan, ready to merge. (I do not have rights to merge). | 11:49 |
| tristan | wat !? | 11:49 |
| valentind | Ready to be merged automatically. Ask someone with write access to this repository to merge this request | 11:49 |
| * tristan fixes that | 11:49 | |
| tristan | valentind, fixed | 11:50 |
| valentind | tristan, thank you. | 11:50 |
| tiagogomes | tristan I am just afraid that landing a big feature just one day before the release will introduce more bugs which were hard to find with some extensive testing | 11:56 |
| Kinnison | Is there a way to get the output produced during a test, even if the test passes? | 11:59 |
| Kinnison | i.e. some addopts? | 11:59 |
| tpollard | -s I think | 12:02 |
| tristan | tiagogomes, I understand, however, we are a few days before feature freeze, after which point we have another few weeks, almost a month before release | 12:05 |
| tristan | tiagogomes, it's in the planning :) | 12:05 |
| tristan | tpollard, +1 | 12:05 |
| tristan | Kinnison, -s is the one :) | 12:05 |
| * Kinnison nods | 12:05 | |
| tristan | tiagogomes, september 5 is release day iirc | 12:06 |
| tiagogomes | tristan oh, I confused the feature freeze with release dates. That sounds much better :) | 12:06 |
| * Kinnison grumps that despite deliberately failing the job, a build succeeded | 12:06 | |
| * Kinnison tries to trace why | 12:06 | |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-195-1.2->bst-1.2: Add validation for project paths) #598 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/598 | 12:06 |
| *** jennis has joined #buildstream | 12:07 | |
| *** jennis2 has quit IRC | 12:08 | |
| tristan | tiagogomes, we did push back feature freeze a bit... I think toscalix intends to make a clearer announcement about the dates on the ML :) | 12:09 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-195->master: Add validation for project paths) #593 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/593 | 12:10 |
| tristan | jmac, did I see an issue/merge request fly by about staging tar source directly into the virtual CAS thingamajigie ? | 12:32 |
| jmac | There was an issue, IIRC. No work done on it yet. Hang on... | 12:33 |
| jmac | tristan: Yes, it was https://gitlab.com/BuildStream/buildstream/issues/521 | 12:34 |
| gitlab-br-bot | buildstream: issue #540 ("tar source introduces non-determinism") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/540 | 12:37 |
| gitlab-br-bot | buildstream: issue #541 ("zip source can introduce non-determinism") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/541 | 12:39 |
| tristan | jmac, ah thanks, I'm just triaging things and wanted a handle on the number :) | 12:41 |
| gitlab-br-bot | buildstream: issue #542 ("deb source plugin can introduce non determinism") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/542 | 12:47 |
| tiagogomes | Why the tests leave artifacts on buildstream/tmp? | 12:47 |
| *** ChanServ sets mode: +o jjardon | 12:48 | |
| toscalix | tristan: I am on it | 12:48 |
| toscalix | in any case, the original question remains, sorry but I haven't read an answer. tiagogomes will you be able to finish the blocker you are working on by friday with the current issue you reported? | 12:49 |
| tiagogomes | toscalix the issue has already been resolved on both master and 1.2 | 12:50 |
| gitlab-br-bot | buildstream: issue #543 ("git source plugin can introduce non-determinism") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/543 | 12:51 |
| toscalix | tiagogomes: ah, so closing the ticket would be the next thing to do | 12:52 |
| tiagogomes | isn't automatically closed when the associated merge request is merged? | 12:52 |
| jmac | No | 12:53 |
| gitlab-br-bot | buildstream: issue #544 ("bzr source plugin can introduce non-determinism") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/544 | 12:53 |
| jmac | A ticket may have multiple MRs | 12:53 |
| tiagogomes | Ah ok | 12:53 |
| toscalix | tiago, it is when the facto the MR is associated | 12:55 |
| toscalix | and all MR are merged | 12:55 |
| toscalix | I cannot find in this case that the MR has been associated | 12:55 |
| gitlab-br-bot | buildstream: issue #545 ("remote source plugin can introduce non-determinism") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/545 | 12:57 |
| tiagogomes | Are we talking about the same ticket? https://gitlab.com/BuildStream/buildstream/issues/195 | 12:57 |
| toscalix | ouch no | 12:58 |
| tristan | Eek, tiagogomes I missed that in the MR as well | 12:58 |
| toscalix | tiagogomes: https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html | 12:59 |
| tristan | In any case, it's a minor slip; lets try to ensure we always mention the issue number that an MR resolves | 12:59 |
| toscalix | I thought you were talking about the race condition, anyway | 12:59 |
| tristan | Ok, issues #527, #540, #541, #542, #543, #544, #545... all a class of issues related to non-determinism arising from Sources | 13:00 |
| tiagogomes | iirc that issue was not part of the list of blockers | 13:00 |
| tristan | I marked these as urgent and milestone 1.4, but maybe we can get a fix for most of this in 1.2 | 13:00 |
| toscalix | tiago, check the section "What will this merge request resolve? Close issues automatically." of this tutorial https://about.gitlab.com/2016/03/08/gitlab-tutorial-its-all-connected/ | 13:01 |
| toscalix | tiagogomes: ^ | 13:01 |
| tiagogomes | ok, thanks | 13:01 |
| gitlab-br-bot | buildstream: issue #195 ("Errors are needed when referring to local things outside of the project") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/195 | 13:28 |
| toscalix | tristan: we should probably have a sync meeting to track blockers tomorrow morning in Europe | 13:33 |
| toscalix | do you agree? | 13:34 |
| tristan | valentind, it looks like another MR landed in advance of you, are you going to be able to babysit the MR and ensure it lands ? | 13:39 |
| tristan | toscalix, I... would rather not make commitments too late on a friday evening; can we ensure it's really going to be morning ? like... 5pm here ? | 13:41 |
| toscalix | tiagogomes: can you make 9 am tomorrow? | 13:43 |
| adds68 | Freedesktop-sdk has officially migrated to the new CAS server \o/ :) | 13:43 |
| toscalix | valentind: is on vacation | 13:43 |
| tristan | toscalix, also, (just incase you didnt notice), I have marked a hand full of issues to be Blockers... to the 1.4 milestone - as we discussed this was the right way to denote the technical debt incurred in the master branch | 13:43 |
| toscalix | adds68: good news | 13:43 |
| tristan | (so... not all blockers at this point are blockers to 1.2) | 13:44 |
| tristan | "Fast-forward merge is not possible. To merge this request, first rebase locally" ehhh, includes branch conflicts with whatever 11 commits have landed on master in the last hour | 13:46 |
| tiagogomes | toscalix I can do it, but is it worth it considering we have a meeting monday morning as well? | 13:47 |
| tristan | I think the issue here is that I have spoken for the last remaining blocker feature, and have not had time do to it | 13:48 |
| toscalix | given that tristan is 9 hours ahead of UK, if something pops up on Monday he basically have no time to act on it in normal conditions | 13:48 |
| toscalix | I would prefer to know in advance if there is an extra effort that needs to be made | 13:49 |
| tristan | Which... I should have time to do over the weekend - but yeah; annoying | 13:49 |
| toscalix | the rest of the relevant dates are tue to thu to avoid these risks | 13:49 |
| toscalix | relevant days of the release, I mean | 13:50 |
| toscalix | I am working on the mail with the timeline | 13:50 |
| toscalix | tiagogomes: thanks for making the effort on friday. Feel free to join from home if you cannot make it to the office at that time. I will arrange the meeting. valentind is on vacation tomorrow | 13:51 |
| tristan | In general, I have designed this process to work based on the clock, to avoid arguably meaningless pressure around release dates, but in this case we do have these features which must land, unfortunately | 13:51 |
| tristan | In the future, we should try to be careful and just release what is ready; cutting out features which dont make it | 13:52 |
| gitlab-br-bot | buildstream: merge request (relative_workspaces->master: WIP: Patch for issue #191 support relative workspaces) #504 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/504 | 13:55 |
| *** jennis2 has joined #buildstream | 13:58 | |
| *** jennis has quit IRC | 13:58 | |
| gitlab-br-bot | buildstream: merge request (willsalmon/trackWarning->master: Add warning to git track if track and ref are not present) #580 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/580 | 13:59 |
| tristan | toscalix, I'm heading out, tomorrow meeting: confirmed :) | 13:59 |
| laurence | tristan, just before you do - any chance I can ask about gitlab permissions | 14:00 |
| laurence | you recently mailed out: | 14:01 |
| laurence | Today I have done the following: | 14:01 |
| laurence | o Added explicit merge permission to everyone I had previously set | 14:01 |
| laurence | to have the "Maintainer" role | 14:01 |
| laurence | o Set this same group of contributors back as "Developer" | 14:01 |
| laurence | I'm trying to do similar on BuildGrid, but can't figure it out (may be missing something very obvious) | 14:01 |
| tristan | laurence, yep... basically; you want to go to settings -> protected branches | 14:02 |
| tristan | laurence, you want 2 protected branches, one is master, and one is a wildcarded expression which matches your stable branches (i.e. I used `bst-*` to match bst-1.0, bst-1.2, and make sure I dont need to do anything when there is bst-1.4 etc) | 14:03 |
| tristan | laurence, then you want to set the merge capability and push capabilities, push capabilities is Maintainer only... merge capabilities is also Maintainer | 14:03 |
| tristan | laurence, but for the merge capabilities; you also hand select all of your committers in a drop down menu | 14:03 |
| laurence | tristan, aha, ok, cheers ! | 14:04 |
| tristan | :) | 14:04 |
| tristan | Can someone make sure valentind's branch lands tonight ? | 14:04 |
| tristan | I think he might be finished in his timezone ? | 14:05 |
| tristan | It wont rebase automatically, because of other stuff which landed in the last hour; haven't had time to check what it is | 14:05 |
| tristan | tiagogomes, if you have some time for that maybe ? | 14:05 |
| tristan | if it's too complicated, I'll take care of it tomorrow I guess | 14:05 |
| gitlab-br-bot | buildstream: merge request (relative_workspaces->master: WIP: Patch for issue #191 support relative workspaces) #504 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/504 | 14:08 |
| toscalix | tristan: is it possible for you to review the release timeline communication before I send it? | 14:11 |
| qinusty | Nexus RE #534: What artifacts are produced on a failed build? Artifacts for other elements etc? | 14:12 |
| toscalix | https://gitlab.com/BuildStream/nosoftware/alignment/issues/27#note_92127960 | 14:12 |
| toscalix | if not, since you confirmed the dates, I will send it in 30 min aprox | 14:12 |
| valentind | tristan, I am not totally finished. But I started to travel. I will make sure it merges. | 14:12 |
| *** tristan has quit IRC | 14:13 | |
| Nexus | qinusty: https://gitlab.com/BuildStream/buildstream/merge_requests/475 | 14:16 |
| tiagogomes | valentind let me know if you haven't enough time, and I'll take over :) | 14:17 |
| valentind | tiagogomes, rebase seemed straight forward. Pushing now. | 14:19 |
| toscalix | tiagogomes: thanks | 14:19 |
| tiagogomes | Nice :) | 14:19 |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 14:20 |
| qinusty | With my failed project it seems to push on `q` Nexus | 14:26 |
| qinusty | Could this be an issue besides the fail? | 14:27 |
| tiagogomes | `q` doesn't terminate other jobs which are running in parallel. So that seems normal | 14:28 |
| gitlab-br-bot | buildstream: merge request (chandan/sourcetransform->master: WIP: Allow source plugins to access previous sources) #568 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/568 | 14:29 |
| qinusty | re https://gitlab.com/BuildStream/buildstream/issues/534 tiagogomes | 14:29 |
| gitlab-br-bot | buildstream: merge request (chandan/sourcetransform->master: WIP: Allow source plugins to access previous sources) #568 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/568 | 14:30 |
| gitlab-br-bot | buildstream: merge request (chandan/sourcetransform->master: Allow source plugins to access previous sources) #568 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/568 | 14:30 |
| tiagogomes | toscalix, so the meeting is at 8am BST?? | 14:30 |
| tiagogomes | qinusty ahh | 14:31 |
| qinusty | q pushing is intended behaviour, but I'm unable to reproduce it not working | 14:31 |
| toscalix | tiagogomes: fixed | 14:41 |
| Nexus | qinusty: i'm not sure, i raised the issue because it was something skullman commented on, you'd have to speak to him about it when he gets back | 14:42 |
| *** tpollard has quit IRC | 14:53 | |
| *** tpollard has joined #buildstream | 14:54 | |
| *** j1mc-polari has joined #buildstream | 15:01 | |
| jjardon | hi | 15:02 |
| jjardon | does buildstream check the cache every time it starts to build a element, or only in the beginning whe you start the build command? | 15:03 |
| *** tristan has joined #buildstream | 15:04 | |
| *** xjuan has joined #buildstream | 15:11 | |
| gitlab-br-bot | buildstream: issue #331 ("Project configuration required is too much") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/331 | 15:17 |
| gitlab-br-bot | buildstream: issue #331 ("Project configuration required is too much") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/331 | 15:17 |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: Add support for include in project.conf) #471 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 15:17 |
| Nexus | tristan: would you have time to review the relative workspaces MR for me? https://gitlab.com/BuildStream/buildstream/merge_requests/504 | 15:18 |
| Nexus | juergbi: ^ | 15:18 |
| valentind | tiagogomes, it is merged. So no worries. Thanks anyway. | 15:21 |
| toscalix | valentind: great | 15:25 |
| toscalix | please close the ticket when the work is done | 15:25 |
| toscalix | if there are features or things left behind, please create another ticket with milestone 1.4 and related to this one | 15:26 |
| jjardon | tristan: not sure you missed this question before: does buildstream check the cache every time it starts to build a element, or only in the beginning whe you start the build command? | 15:29 |
| valentind | toscalix, ticket is closed. | 15:30 |
| qinusty | 00:30 in korea jjardon, maybe tomorrow :D | 15:31 |
| jjardon | ooops, true, sorry tristan ! | 15:31 |
| qinusty | By check the cache do you mean for space or contents? | 15:31 |
| qinusty | s/contents/artifacts | 15:32 |
| jjardon | qinusty: artifacts | 15:32 |
| qinusty | Hmmmm, I'll take a quick look around and see if I can give you an answer | 15:33 |
| jjardon | basically I'd like to know if bst keeps trying if there is a hiccup with the cache server or gives up and never tries again | 15:33 |
| jjardon | qinusty: thanks | 15:33 |
| qinusty | remote cache specifically then? | 15:34 |
| qinusty | jjardon, it looks like the pulling from a cache is done at the start of the build command | 15:37 |
| qinusty | So I don't think it does it every time it goes to build an element | 15:37 |
| jjardon | :( | 15:38 |
| jjardon | qinusty: ok, ,thanks for checking | 15:38 |
| qinusty | Track -> Pull (From Cache) -> Fetch (Sources) -> Build (Elements) -> Push (To Cache) | 15:38 |
| qinusty | np | 15:39 |
| gitlab-br-bot | buildstream: issue #546 ("Trying to pull from the cache should be done every time before try to build an element, not only in the beginning of the bst build command") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/546 | 15:45 |
| jjardon | benbrown: only to confirm: this is how ybd/kbas works, right? https://gitlab.com/BuildStream/buildstream/issues/546 | 15:51 |
| benbrown | essentially, yeah | 15:52 |
| *** ernestask has left #buildstream | 15:59 | |
| gitlab-br-bot | buildstream: issue #536 ("UI for inspecting build logs and failed builds from the artifact cache") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/536 | 16:09 |
| gitlab-br-bot | buildstream: merge request (chandan/sourcetransform->master: WIP: Allow source plugins to access previous sources) #568 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/568 | 16:18 |
| gitlab-br-bot | buildstream: merge request (chandan/sourcetransform->master: Allow source plugins to access previous sources) #568 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/568 | 16:23 |
| *** noisecell has quit IRC | 16:26 | |
| *** tpollard has quit IRC | 16:31 | |
| *** nukedclx has joined #buildstream | 16:35 | |
| *** leopi has quit IRC | 16:38 | |
| *** toscalix has quit IRC | 16:53 | |
| tiagogomes | Are workspaces and entering a shell on failed builds supposed to work? | 16:56 |
| qinusty | Nexus knows about workspaces I believe | 16:57 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-500->master: Handle additional types on `_process_list`) #570 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/570 | 16:58 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-500->master: Handle gracefully files of type socket) #570 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/570 | 16:58 |
| gitlab-br-bot | buildstream: issue #547 ("Ugly unhandled exception when cache server restarted") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/547 | 16:59 |
| Nexus | wut wut? | 17:00 |
| * Nexus got pinged | 17:00 | |
| Nexus | tiagogomes: yes | 17:00 |
| *** coldtom has quit IRC | 17:00 | |
| Nexus | tiagogomes: do they? | 17:00 |
| bochecha | before I waste time replicating somebody else's work… has anybody made BuildStream packages for Fedora? | 17:28 |
| Nexus | bochecha: what do you mean by "BuildStream packages"? | 17:34 |
| bochecha | Nexus: a package in the official fedora repo, to install buildstream with dnf | 17:34 |
| bochecha | I used plural because I was thinking about bst-external as well, but I'm not sure that's as interesting… | 17:34 |
| Nexus | afaik, only arch has packages, the rest use source | 17:35 |
| Nexus | but i could be wrong | 17:35 |
| jjardon | bochecha: dependencies are documented here: https://buildstream.gitlab.io/buildstream/install_linux_distro.html, but the list here migth help with the pip ones: https://aur.archlinux.org/packages/buildstream | 17:37 |
| paulsherwood | win 8 | 17:38 |
| paulsherwood | bah | 17:38 |
| bochecha | jjardon: I know that doc page, but thanks for the link to the arch package, it will certainly help :) | 17:38 |
| gitlab-br-bot | buildstream: issue #338 ("buildstream fails with "EOFError: Compressed file ended before the end-of-stream marker was reached"") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/338 | 17:41 |
| *** VoidWhisperer has joined #buildstream | 17:50 | |
| gitlab-br-bot | buildstream: issue #548 ("Idea: distribute buildstream as a flatpak") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/548 | 17:57 |
| gitlab-br-bot | buildstream: issue #549 ("Generate .deb packages of buildstream") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/549 | 18:02 |
| *** leopi has joined #buildstream | 18:59 | |
| *** xjuan has quit IRC | 19:25 | |
| *** MartesZibellina has joined #buildstream | 19:40 | |
| *** leopi has quit IRC | 19:42 | |
| bochecha | hmm, why does `python setup.py build` try to install pytest-runner? | 20:15 |
| bochecha | ah, it's a setup-requires :( | 20:15 |
| bochecha | isn't it only needed for the tests? | 20:15 |
| *** tristan has quit IRC | 20:39 | |
| *** xjuan has joined #buildstream | 20:46 | |
| *** mohan43u has quit IRC | 21:36 | |
| *** xjuan has quit IRC | 23:31 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!