| *** toscalix has quit IRC | 00:13 | |
| *** xjuan has quit IRC | 01:33 | |
| *** Prince781 has joined #buildstream | 01:47 | |
| *** Prince781 has quit IRC | 01:54 | |
| *** tristan has joined #buildstream | 06:02 | |
| *** ChanServ sets mode: +o tristan | 06:02 | |
| *** tristan has quit IRC | 06:31 | |
| *** tristan has joined #buildstream | 06:32 | |
| *** mohan43u has quit IRC | 06:32 | |
| *** mohan43u has joined #buildstream | 06:38 | |
| *** bochecha has joined #buildstream | 07:00 | |
| *** iker has joined #buildstream | 07:06 | |
| *** finn has joined #buildstream | 07:40 | |
| *** toscalix has joined #buildstream | 07:43 | |
| gitlab-br-bot | buildstream: merge request (tristan/fix-override-options->master: Fix override options) #802 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/802 | 07:49 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (tristan/fix-override-options-1.2->bst-1.2: Fix override options 1.2) #803 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/803 | 07:52 |
| Kinnison | Does anyone know if work has been done to silence the more modern pylint warnings? | 08:03 |
| Kinnison | such as: R: 28, 0: Class 'Mounter' inherits from object, can be safely removed from bases in python3 (useless-object-inheritance) | 08:04 |
| *** ChanServ sets mode: +o tristan | 08:09 | |
| tristan | Kinnison, not as far as I know, no | 08:09 |
| Kinnison | Okay, I'll ignore them for now | 08:09 |
| * Kinnison hrms, after adding an assert, test_pull gets stuck, presumably something died in a child of a scheduled job | 08:10 | |
| tristan | Kinnison, I feel rather worried about fixing them without making the tests work the same way on every host first (as it could be hiding that issue "for a time") | 08:10 |
| Kinnison | Is there a convenient envvar or somesuch for debugging that kind of thing? | 08:10 |
| tristan | That is a regression :-S | 08:10 |
| tristan | We have hangs now, we shouldnt have hangs :'( | 08:10 |
| Kinnison | Since I started looking at buildstream, which was pretty much just before the policy changed on committing, it has hung in the test suite if the child job in the scheduler dies unexpectedly | 08:11 |
| tristan | Yeah, I don't know why that is happening, it's horrible | 08:11 |
| Kinnison | Last time I was tracking it down, it was when the exception occurred outside of the protected blocks | 08:12 |
| Kinnison | e.g. if it happened during job_complete() | 08:12 |
| Kinnison | But I wasn't very experienced in the codebase so ended up stopping after I'd found my bug | 08:12 |
| Kinnison | rather than finding a generic solution | 08:12 |
| gitlab-br-bot | buildstream: issue #658 ("Conditionals not supported in element overrides") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/658 | 08:14 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-override-options->master: Fix override options) #802 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/802 | 08:14 |
| tristan | Kinnison, looks like that might be stemming from tlater[m]'s scheduler refactor; maybe we need to move the handling and reporting of unhandled exceptions higher up in the stack | 08:14 |
| Kinnison | I figure you shouldn't have *any* chance of an exception leaking into the asyncio code | 08:15 |
| Kinnison | because within there, it just dumps the job on the floor | 08:15 |
| Kinnison | So signal handlers, child exit handlers, everything, should have a wide ranging try: around it | 08:15 |
| tristan | Kinnison, essentially, there should be very little code outside of a try: block in the scheduler in response to a job completed event | 08:15 |
| * Kinnison nods | 08:15 | |
| gitlab-br-bot | buildstream: merge request (tristan/fix-override-options-1.2->bst-1.2: Fix override options 1.2) #803 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/803 | 08:15 |
| Kinnison | What's the test-suite argument to get the output displayed? I'm changing from an assert to logging the traceback so I can chase this down | 08:16 |
| tristan | We certainly run the higher level stuff which Queue's implement in response of job completion in try blocks for that reason | 08:16 |
| Kinnison | (this being my bug) | 08:16 |
| tristan | it's '-s' (./setup.py test --addopts '-s ...') | 08:16 |
| Kinnison | thanks | 08:17 |
| Kinnison | Hrf, I'm not getting stuff sent to logging.warning() nor if I just print() it here :( | 08:19 |
| Kinnison | Oooh I do see the assert though, if I put that back in, nice | 08:19 |
| *** rdale has joined #buildstream | 08:20 | |
| Kinnison | Interesting, so the assert was in the test setup, and that was what blocked the suite | 08:20 |
| tristan | juergbi, after implementing CAS, it looks like you forgot to update http://buildstream.gitlab.io/buildstream/format_project.html#artifact-server ? | 08:20 |
| tristan | juergbi, I.e. there are a bunch of new fields for push urls ? | 08:20 |
| tristan | Or I guess, ssssam[m] and others also forgot to update this and note the specific project format versions in which the new configs were available | 08:21 |
| tristan | Looking at https://gitlab.com/BuildStream/buildstream/issues/625, we have fell behind in documentation on that front | 08:21 |
| tristan | We should fix that post haste and document the relevant format versions, as it's easy to do and causes frustration | 08:22 |
| tristan | Or, am I missing another place in the docs where this is documented ? | 08:22 |
| juergbi | there is http://buildstream.gitlab.io/buildstream/install_artifacts.html#user-configuration | 08:22 |
| * tristan thinks it should not be documented in the instructions for installing an artifact server | 08:22 | |
| juergbi | however, we should improve on that | 08:22 |
| juergbi | yes | 08:22 |
| 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 | 08:24 |
| Kinnison | tristan: as per our discussion yesterday, I'm attempting to ensure that artifacts.setup_remotes() is called only once ever | 08:25 |
| Kinnison | sadly my computer isn't super-fast so tests take a while :_) | 08:25 |
| * Kinnison goes to get a cuppa while the suite runs | 08:26 | |
| tristan | juergbi, What is the 'client-key' ? I need to generate one for my test case | 08:26 |
| tristan | juergbi, not reproducing that issue without setting one | 08:26 |
| juergbi | http://buildstream.gitlab.io/buildstream/install_artifacts.html#authenticating-users | 08:26 |
| tristan | juergbi, ok interesting, I have to scroll that line to see 'client.key' at the end, and have no other hints that that is what should be set as the 'client-key:' configuration | 08:27 |
| juergbi | maybe we should mention the relevant filenames in the sentences above each command | 08:28 |
| tristan | juergbi, I think it would be good to (A) Document the concepts in the artifact server related document, where we name each "thing" in a linkable section | 08:30 |
| tristan | juergbi, And we document the configuration in the user conf and project conf docs respectively, linking to those things ? | 08:30 |
| tristan | So this way we centralize the "how to generate the things" and the "what the things are", with the artifact server docs; and have the config docs separately ? | 08:31 |
| juergbi | makes sense | 08:34 |
| *** toscalix has quit IRC | 08:35 | |
| *** toscalix has joined #buildstream | 08:35 | |
| tristan | juergbi, Do you have any idea where this "TypeError: expected bytes, NoneType found" is coming from, in https://gitlab.com/BuildStream/buildstream/issues/625 ? | 08:35 |
| tristan | juergbi, I have to figure out why that unhandled exception is not coming with it's stack trace, and raise the appropriate LoadError instead | 08:36 |
| tristan | I have a feeling it might be by the magick namedtuple behavior of ArtifactCacheSpec | 08:36 |
| juergbi | tristan: I suspect _CASRemote.init() in cascache.py | 08:37 |
| juergbi | use of client-key without client-cert | 08:37 |
| tristan | Hmm okay | 08:39 |
| tristan | Maybe not the right place to raise a load error | 08:39 |
| tristan | Can raise the LoadError in the ArtifactCacheSpec parsing if only I know what the API contract for it is (what is allowed and what is not) | 08:39 |
| juergbi | well, the gRPC API is supposed to accept None for those | 08:40 |
| juergbi | in the common case, client-cert has to be speicifed if client-key is specified as these are typically self-signed keys | 08:40 |
| juergbi | however, theoretically, they could be signed by a system trusted CA, in which case I didn't expect client-cert to be required | 08:40 |
| juergbi | eh, scrap that. gRPC always requires the private/public key pair, private alone is never sufficient | 08:41 |
| juergbi | so we should really not accept users specifying only one of client-key or client-cert | 08:41 |
| 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 | 08:41 |
| tristan | juergbi, OK. | 08:41 |
| juergbi | casserver has a corresponding check for the server key, but it seems that's missing on the client side | 08:42 |
| Kinnison | tristan: In your comment on 797 you suggested we should want _platform.get_artifacts() or somesuch, but there's no similar pattern for me to follow. Should I skip that part of your suggestions for now? | 08:42 |
| tristan | So this happens in the main thread, while loading, through Stream._load() -> setup_remotes() | 08:42 |
| tristan | The global_exception_handler is set at this point, no traceback | 08:43 |
| tristan | Kinnison, Yes, skip that | 08:43 |
| Kinnison | tristan: ack, thanks | 08:43 |
| tristan | Kinnison, I was noting that, we could afford to lose the various `__artifacts` handles on all the objects and just call _platform.get_artifacts() everywhere, could be a good cleanup | 08:43 |
| tristan | Also avoids passing it through everything | 08:44 |
| tristan | but yeah, that is a wider scope | 08:44 |
| * Kinnison nods | 08:46 | |
| * Kinnison has done the platform = Platform.get_platform() \n cache = platform.artifactcache \n transform though | 08:46 | |
| * Kinnison is just testing and will then re-push | 08:47 | |
| *** jonathanmaw has joined #buildstream | 08:47 | |
| gitlab-br-bot | buildstream: merge request (willsalmon/outOfSourecBuild->master: WIP: out of source builds) #776 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/776 | 08:50 |
| 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 | 09:02 |
| tristan | juergbi, So the the `client-cert` is the client.crt generated in the same line ? | 09:05 |
| juergbi | yes | 09:05 |
| juergbi | matching the example config at the bottom | 09:06 |
| tristan | juergbi, That line generates two things, both of which must be specified if either is specified | 09:06 |
| tristan | Basically ? | 09:06 |
| juergbi | correct | 09:06 |
| Kinnison | tristan: 797 updated, pipeline running now. It's several commits now, so I need to retitle and update the description | 09:06 |
| tristan | juergbi, Thanks | 09:06 |
| gitlab-br-bot | buildstream: merge request (danielsilverstone-ct/fix-654->master: sandbox/_sandboxremote.py: Acquire cache via Platform) #797 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/797 | 09:07 |
| gitlab-br-bot | buildstream: merge request (richardmaw/fix-chroot-sandbox-devices->master: fix chroot sandbox devices) #781 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/781 | 09:13 |
| *** alatiera_ has joined #buildstream | 09:13 | |
| tristan | juergbi, Is it possible at all to configure a push remote without specifying *either* ? | 09:15 |
| *** lachlan has joined #buildstream | 09:17 | |
| juergbi | tristan: yes, if the server accepts uploads without authentication. e.g., for servers running locally or in restricted environments | 09:18 |
| juergbi | for internet-facing servers that would definitely not be recommended, though | 09:18 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-artifact-config-crash->master: Fix artifact config crash) #804 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/804 | 09:19 |
| tristan | juergbi, Please take a glance at https://gitlab.com/BuildStream/buildstream/merge_requests/804 | 09:19 |
| tristan | juergbi, it is however, pretty straight forward, just adds the luxurious errors with provenance | 09:20 |
| tristan | (and regression tests them) | 09:20 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-artifact-config-crash-1.2->bst-1.2: Fix artifact config crash (1.2)) #805 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/805 | 09:22 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-artifact-config-crash->master: Fix artifact config crash) #804 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/804 | 09:25 |
| juergbi | tristan: looks good to me. on the server side I used a single check and error message for both cases but either way works | 09:25 |
| Kinnison | tristan: If you have a chance to glance over 797 soon, that'd be awesome. If you are too busy, that's obviously fine too :-) | 09:27 |
| * Kinnison has hopes that he's done enough this time :-D | 09:27 | |
| tristan | tiagogomes, fair comments, in fact in this case; we could commit empty files | 09:33 |
| tristan | I'll update the MRs | 09:33 |
| tristan | tiagogomes, I don't like generating them on the fly because it insinuates additional dependencies for tests; and also takes quite some time (took like a few seconds here) | 09:34 |
| tiagogomes | fair | 09:35 |
| tristan | The error will happen way before the certs need to be valid, but emptying them saves some repo space | 09:36 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-artifact-config-crash->master: Fix artifact config crash) #804 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/804 | 09:38 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-artifact-config-crash-1.2->bst-1.2: Fix artifact config crash (1.2)) #805 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/805 | 09:38 |
| gitlab-br-bot | buildstream: merge request (willsalmon/outOfSourecBuild->master: WIP: out of source builds) #776 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/776 | 09:44 |
| valentind | tristan, do we have a work-around for #623? | 09:49 |
| valentind | Like setting a low quota. | 09:49 |
| gitlab-br-bot | buildstream: issue #659 ("Split up artifact cache and cas cache") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/659 | 09:51 |
| gitlab-br-bot | buildstream: merge request (danielsilverstone-ct/fix-654->master: sandbox/_sandboxremote.py: Acquire cache via Platform) #797 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/797 | 09:53 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-artifact-config-crash->master: Fix artifact config crash) #804 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/804 | 09:56 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-artifact-config-crash-1.2->bst-1.2: Fix artifact config crash (1.2)) #805 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/805 | 09:56 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-artifact-config-crash->master: Fix artifact config crash) #804 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/804 | 09:57 |
| tristan | valentind, #623 is mostly fixed | 09:58 |
| valentind | Oh ok. | 09:59 |
| valentind | So it will not be on the known issues? | 09:59 |
| tristan | valentind, I haven't closed it, in case we actually hit out of space exceptions because of committing exceedingly large artifacts | 09:59 |
| tristan | valentind, nah, the server side issue is a known issue | 09:59 |
| tristan | valentind, The client side will have a fix in 1.2.1 which I intend to release this week | 09:59 |
| valentind | But it is the same ticket, right? | 10:00 |
| tristan | nope | 10:00 |
| valentind | OK, wrong one then. | 10:00 |
| tristan | where is the server side ticket... | 10:00 |
| tristan | I don't know, please find it... jjardon knows :) | 10:00 |
| valentind | tristan, is there a work around for that one better than removing the cache directory? | 10:02 |
| valentind | #609 | 10:02 |
| gitlab-br-bot | buildstream: merge request (willsalmon/outOfSourecBuild->master: WIP: out of source builds) #776 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/776 | 10:03 |
| *** tristan has quit IRC | 10:04 | |
| valentind | I have added a issue parser in the markdown for the website. | 10:05 |
| *** tristan has joined #buildstream | 10:05 | |
| valentind | So now we can use BuildStream/buildstream#123 and it will make a link. | 10:05 |
| *** tristan has quit IRC | 10:06 | |
| *** tristan has joined #buildstream | 10:06 | |
| *** tristan has joined #buildstream | 10:08 | |
| toscalix | valentind: great for the known issues page | 10:11 |
| toscalix | but it will also be of great help for the roadmap page and for blog posts | 10:12 |
| toscalix | so the known issues page will be a web page.... much better solution than starting using the gitlab wiki | 10:12 |
| *** ChanServ sets mode: +o tristan | 10:12 | |
| tristan | valentind, https://gitlab.com/BuildStream/buildstream/issues/609 | 10:13 |
| * tristan lost connection temporarily, that was in my browser tabs | 10:13 | |
| gitlab-br-bot | buildstream: merge request (tristan/fix-artifact-config-crash-1.2->bst-1.2: Fix artifact config crash (1.2)) #805 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/805 | 10:13 |
| valentind | tristan, yes. I found it. | 10:14 |
| gitlab-br-bot | buildstream: issue #625 ("BUG without stack trace when public keys are not specified for an artifact cache using a self-signed certificate") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/625 | 10:16 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-artifact-config-crash->master: Fix artifact config crash) #804 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/804 | 10:16 |
| *** ikerperez has joined #buildstream | 10:20 | |
| *** iker has quit IRC | 10:21 | |
| *** lachlan has quit IRC | 10:21 | |
| toscalix | valentind: the ticket description is fin with me. About the code.... I cannot tell. https://gitlab.com/BuildStream/website/merge_requests/88 I assigned the MR to tiagogomes | 10:25 |
| gitlab-br-bot | buildstream: issue #660 ("Stack traces when running out of disk space") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/660 | 10:28 |
| gitlab-br-bot | buildstream: issue #623 ("Stack trace when running out of disk space") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/623 | 10:29 |
| tiagogomes | BuildStream does no longer builds freedesktop sdk https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/98460309 | 10:30 |
| 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:30 |
| *** lachlan has joined #buildstream | 10:32 | |
| *** lachlan has quit IRC | 10:35 | |
| *** finn has quit IRC | 10:41 | |
| Kinnison | tristan: Thanks for merging 797 | 10:42 |
| *** finn has joined #buildstream | 10:42 | |
| tristan | Kinnison, Opened up that separate followup issue for you too :) | 10:43 |
| Kinnison | tristan: Excellent | 10:44 |
| Kinnison | Don't suppose you have the issue nr off the top of your head? If not, I'll go grab it | 10:44 |
| Kinnison | aha, #659 | 10:44 |
| * Kinnison makes note | 10:44 | |
| * tristan goes for lunch | 10:48 | |
| tristan | Team meeting tonight ! | 10:48 |
| *** tristan has quit IRC | 10:51 | |
| *** alatiera_ has quit IRC | 10:54 | |
| toscalix | will send a mail in a few min | 11:01 |
| toscalix | reminder | 11:01 |
| jennis | What's our procedure for bumping issues that have fallen through the cracks? | 11:03 |
| *** tristan has joined #buildstream | 11:32 | |
| 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 | 11:36 |
| *** ChanServ sets mode: +o tristan | 11:37 | |
| toscalix | jennis: can you give me an example? | 11:58 |
| Nexus | toscalix: this seems to have: https://gitlab.com/BuildStream/buildstream/issues/22 | 12:01 |
| toscalix | Nexus: no, there is an answer to that bug | 12:01 |
| toscalix | requesting for further information | 12:02 |
| toscalix | with the release we need to move many tickets to milestone 1.2 | 12:02 |
| Nexus | https://gitlab.com/BuildStream/buildstream/issues/39 | 12:02 |
| Nexus | that one is laurence asking for an update | 12:03 |
| toscalix | but I do not consider this bug...fallen through the crtacks | 12:03 |
| Nexus | why not? | 12:03 |
| toscalix | this 39, yes | 12:03 |
| Kinnison | There's a lot to be said for closing ancient issues which have seen no activity from the submitter in a year | 12:03 |
| Nexus | this one seems to have a branch made, but noting updated on it in 11 months https://gitlab.com/BuildStream/buildstream/issues/48 | 12:04 |
| toscalix | Nexus: we, in general have a problem with the roadmap. Many new features requests are left behind. It is my plan to work on it before ELCE: roadmapping | 12:05 |
| toscalix | so there are more "enhancements" in such case | 12:05 |
| Kinnison | I guess for things like #48 what matters is that there's a process whereby the project examines old issues, determines if they are still an issue, and closes those which aren't | 12:06 |
| toscalix | I would say that #48 should be discussed again, yes | 12:07 |
| laurence | jennis, comment on the issue, explaining why it is affecting you as a downstream user of the tool - then mark it as urgent and the upstream devs will look at it in their weekly planning meeting | 12:07 |
| laurence | late to the chat here | 12:07 |
| toscalix | Kinnison: agree. It should take place, at least, after each major release | 12:07 |
| toscalix | laurence: I just advices somebody in a different channel to use the emoticons features if you have nothing new to say about the bug but you are affected | 12:08 |
| toscalix | adviced | 12:08 |
| toscalix | as another simple option | 12:08 |
| Kinnison | That requires that the emoticons have a fixed understood meaning. Do they? | 12:08 |
| *** iker has joined #buildstream | 12:11 | |
| *** ikerperez has quit IRC | 12:11 | |
| toscalix | The thumbs up, for instance, is mostly used in bugs to say.... I want this to be fixed. Kind of popular contest. It is useful if you do not want to add acomment since we can identify who put it | 12:11 |
| toscalix | but I am open to write down a policy if there is demand | 12:11 |
| persia | I feel fairly strongly that old bugs should be retained until they do not apply. | 12:11 |
| persia | If they can't be reproduced with the current version, but can be reproduced with an old version, marking them accidentally fixed is an excellent treatment. | 12:12 |
| toscalix | I would agree with a good ticketing system | 12:12 |
| Nexus | persia: what if they can't be reproduced in general and the person who raises the ticket doesn't reply/follow up? | 12:12 |
| persia | If they can be trivially reproduced with a current version, they should be kept, regardless of age or inactivitiy (although maybe it is worth mentioning reproduction with a newer version) | 12:12 |
| toscalix | I think that by filtering after every major release we can have a fairly clean state. We move to the new milestones those that make sense | 12:13 |
| toscalix | those old bugs are there way before we implemented the current structure | 12:14 |
| persia | Nexus: If they can't be reproduced at all, and the submitter does not engage, it's hard to say. I've seen bugs that were closed after being ignored for months result in published articles about callous developers. | 12:14 |
| toscalix | and this is the first time we will move tickets to a new milestone. I would wait for the end of such process to evaluate if we need to do more | 12:14 |
| persia | I've also seen lots of bugs eagerly closed as "impossible to reproduce" by zelous folk where reproduction was possible, but the text of the bug didn't mention something obvious to developers. | 12:14 |
| * Kinnison firmly believes that if the developers cannot reproduce, and the submitter is not engaging, then the bug is worthless | 12:15 | |
| Kinnison | If the submitter engages, then even if the developers cannot reproduce, it's worth retaining | 12:15 |
| persia | If it is truly the case that it cannot be reproduced even when approached properly, and the there is demonstrable effort to reach out to a submitter for further information over time, it may be safe to close unfixed. | 12:16 |
| persia | Kinnison: Absolutely. | 12:16 |
| persia | Err, absolutely on keeping issues with engaged submitters, rather. | 12:16 |
| Nexus | Wouldn't a better option to reply to the issue saying "I was unable to reproduce this error and have not been able to get any additional information. If this issue persists, please raise another issue with steps to reproduce your issue. Many thanks, [dev]" *close ticket* | 12:16 |
| Kinnison | Nexus: yes, but first you have to try and reach out | 12:17 |
| persia | When developers cannot reproduce is more nuanced: I think it worth having a few folk try, unless we want to set a very high bar for troubleshooting to be a "developer": personally, I've not found these skills to correlate particularly much. | 12:17 |
| Nexus | Kinnison: how many times/over what timespan? I tihnk a hard set metric would be useful for these cases | 12:18 |
| Kinnison | Nexus: The project has to pick some settings for that, and try them, I fear. | 12:18 |
| Nexus | e.g. 3 seperate attempts, one each month for 3 months | 12:18 |
| persia | I'&ve found that hard-set metrics are horrid for these cases. | 12:18 |
| persia | Well-timed procedures (like multiple attempts over multiple months) work well. | 12:19 |
| Kinnison | I tend to say that if a submitter is demonstrably active on a platform (and gitlab and the like let you see that to some extent) and they don't react to a request for information at all for a month, then they're not interested any longer | 12:19 |
| Kinnison | But I'm "over-zealous" by some measures :-D | 12:19 |
| persia | But nothing is more frustrating for a submitter than to be told "please start over because you missed an arbitrary deadline by four hours" or similar. | 12:19 |
| Kinnison | Mmm, though I think issues can be reopened by the submitter on gitlab, no? | 12:20 |
| persia | Kinnison: I've been in too many situations where folk are required to use a platform for $work, but are chasing a personal issue for which they have trouble finding time because $work or because it takes time to set up the specific environment (maybe days). | 12:20 |
| Nexus | Kinnison: i believe do yes | 12:21 |
| Kinnison | persia: If they can't find the time to log in and say "Hi, this is still an issue but I won't have chance to update it for a few weeks" then they're not interested enough IMO | 12:21 |
| persia | Kinnison: Yes: hence my desire not to have a policy that bugs that meet these firmly defined rules should be closed: if reopened without input, taht ends up being closed. If we're flexible, and someone wants to reopen (but doesn't have data yet), it is easier to excuse the special case. | 12:21 |
| *** alatiera_ has joined #buildstream | 12:22 | |
| persia | Kinnison: To my mind, that way of thinking leads to hard forks for many people. In some environments, the normal workflow is to fork and be done with it. In the better of those, bugs are filed with affected projects, but it may be months before the heads-down deathmarch completes, during which time someone is very likely not going to spend any time trying to keep track of which bugs might still matter upstream. maybe after the deathmarch | 12:23 |
| persia | concludes, if they are permitted to do so. | 12:23 |
| Kinnison | persia: If you think this project is likely to fall into that category, then we set the timeout at a larger number, but reopens are still possible | 12:24 |
| persia | If we accept reopens, then I'm fine. As I said, I think the policy should be flexible, but I've no issues with a default practice of 3 attempts/3 months or similar. | 12:25 |
| persia | On the other hand, as a submitter, I've become somewhat sensitized to "autoclose", having had many bugs in many projects closed without reproduction when a test case is included in the report., simply because $time passed. | 12:26 |
| Kinnison | If the close happened with no attempt to reach out first, then that'd be rude | 12:26 |
| Kinnison | It should definitely involve an attempt to contact the submitter | 12:26 |
| persia | Past experience is that complaining doesn't mean anyone looks at it, so I guess I jsut don't want to be another one of those projects. | 12:26 |
| Kinnison | fair | 12:27 |
| persia | *and* a real attempt to reproduce, with real questions asked to the submitter if reproduction is difficult in some way. | 12:27 |
| * Kinnison nods | 12:27 | |
| persia | Just saying "Nobody commented on this in four weeks, please update if you care" doesn't help much, especially if one has a calculator where 1+1=2, 1+2=4, and 2+2=4. | 12:28 |
| Kinnison | heh | 12:28 |
| Nexus | Then the issue isn't really with the time limitation, more with rude developers. Which for the most part, is an issue we can address on a case by case basis | 12:29 |
| persia | It is on the submitter to write "1+2 shouldn't be 4" but many submitters will write things like "incorrect addition result", "failure with certain obscure values", "unshift failure", or similar. | 12:29 |
| Nexus | i.e. implement something like the 3 attempts/3 months system, and if it gets abused by people just ignoring the policy we put in place, that gets addressed and re-opened | 12:30 |
| persia | Nexus: My issue with time falls into two categories: a) I think it is good to have time guidelines, but folk should not be penalised by missing by a couple days, and b) no timeout should ever happen for a reproducible bug | 12:30 |
| persia | Other than that, 3/3 sounds good to me | 12:31 |
| Nexus | persia: if a bug is reproducable, then no contact should be needed with the person who raised the ticket, at that point if the ticket gets stagnent, we find someone else to resolve it, not close it | 12:31 |
| Nexus | and i think yes, we should definitely support re-opening tickets, if someone misses the deadline by a couple of days, they can re-open with a reply | 12:32 |
| Kinnison | s/by a couple of days// | 12:32 |
| Nexus | yes, i was just using the example given in that case | 12:33 |
| persia | Given those caveats, I have no objections to such a model. | 12:33 |
| persia | I've just seen counterexamples produced by people who didn't beleive they were being rude, so like to be explicit about these sorts of things :) | 12:33 |
| persia | Looking at 48, I think that's a good example of something that was reproducible some time ago (but should be retested). | 12:47 |
| gitlab-br-bot | buildstream: merge request (willsalmon/outOfSourecBuild->master: WIP: out of source builds) #776 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/776 | 13:04 |
| *** lachlan has joined #buildstream | 13:12 | |
| 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 | 13:17 |
| gitlab-br-bot | buildstream: merge request (richardmaw/fix-chroot-sandbox-devices->master: fix chroot sandbox devices) #781 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/781 | 13:22 |
| laurence | BuildStream monthly irc team meeting starting in 10 minutes over on #buildstream-meetings | 13:49 |
| laurence | See you there, folks | 13:50 |
| gitlab-br-bot | buildstream: merge request (richardmaw/fix-chroot-sandbox-devices->master: fix chroot sandbox devices) #781 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/781 | 13:50 |
| gitlab-br-bot | buildstream: merge request (mablanch/630-remote-execution-reconn->master: Handle connection losses during remote build execution) #806 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/806 | 13:54 |
| *** ikerperez has joined #buildstream | 14:06 | |
| *** iker has quit IRC | 14:08 | |
| *** johanneshilling has joined #buildstream | 14:24 | |
| jennis | /join #buildstream-meetings | 14:24 |
| jennis | haha | 14:24 |
| gitlab-br-bot | buildstream: issue #620 ("Adjust Source / SourceFetcher API contract") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/620 | 14:35 |
| *** abderrahim has quit IRC | 14:46 | |
| *** abderrahim has joined #buildstream | 14:46 | |
| tlater[m] | Hmm, I'm writing a report and trying to cite the BuildStream contributors list - who would the author for that be? | 15:11 |
| tristan | tlater[m], I use git shortlog -s <range> to obtain that for each release | 15:12 |
| tristan | you could do that globally (and filter out dups, like qinusty) | 15:12 |
| tlater[m] | tristan: That's a good point, I can just do that and manually reproduce the list, making it original research... Thanks! | 15:13 |
| *** tristan has quit IRC | 15:15 | |
| *** tristan has joined #buildstream | 15:24 | |
| *** ChanServ sets mode: +o tristan | 15:24 | |
| *** lachlan has quit IRC | 15:30 | |
| *** ikerperez has quit IRC | 15:31 | |
| *** iker has joined #buildstream | 15:31 | |
| valentind | Noticed we do not have the man page for bst-artifact-server. It seems it gets generated when calling "python3 setup.py --command-packages=click_man.commands man_pages". Have we forgotten it? | 15:36 |
| valentind | We cannot put badge in the documentation of buildstream that is packaged for debian. That is privacy breach. | 15:41 |
| Kinnison | Indeed | 15:45 |
| *** lachlan has joined #buildstream | 15:46 | |
| 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 | 15:49 |
| *** iker has quit IRC | 16:02 | |
| 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 | 16:06 |
| *** lachlan has quit IRC | 16:07 | |
| Nexus | please could either of the tristans look at my test for https://gitlab.com/BuildStream/buildstream/merge_requests/792 ? :) tristan tlater[m] | 16:09 |
| Nexus | is that the kind of test oyu had in mind? | 16:09 |
| *** dabukalam has joined #buildstream | 16:10 | |
| 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 | 16:15 |
| Nexus | juergbi: if you have time can you have a look at https://gitlab.com/BuildStream/buildstream/merge_requests/726 for me please? :) | 16:16 |
| 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 | 16:17 |
| juergbi | Nexus: will take a look tomorrow morning | 16:18 |
| Nexus | juergbi: thanks :) | 16:18 |
| juergbi | Nexus: btw: related to the discussion in the meeting, how do you handle the bwrap requirement in setup.py on WSL? | 16:19 |
| juergbi | i.e., https://gitlab.com/BuildStream/buildstream/issues/644 is related | 16:20 |
| Nexus | i run it as root i think | 16:20 |
| juergbi | I don't think that skips the bwrap check. also, I don't think root should be necessary on either WSL or macOS | 16:21 |
| juergbi | or did you simply install bwrap on WSL as well? | 16:22 |
| juergbi | (even though it's not working) | 16:22 |
| Nexus | yeah i just instlaled it | 16:22 |
| Nexus | as if it were linux | 16:22 |
| gitlab-br-bot | buildstream: issue #661 ("descend in _filebaseddirectory.py fails if "." etc is in the "subdirectory_spec" argument") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/661 | 16:23 |
| juergbi | ok, iirc, it's not in the default Ubuntu version of WSL yet, so that's somewhat inconvenient. but maybe we should address this separately with #644 | 16:23 |
| Nexus | i use debian for WSL | 16:23 |
| juergbi | ok | 16:24 |
| *** lachlan has joined #buildstream | 16:29 | |
| *** lachlan has quit IRC | 16:36 | |
| tlater[m] | Nexus: as commented, that test looks fine :) | 16:41 |
| Nexus | tlater[m]: happy to approve a merge? | 16:44 |
| 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 | 16:45 |
| tlater[m] | Pretty sure I'd already approved it, also my comment says I approve so just go ahead. | 16:46 |
| Nexus | tlater[m]: cool :D | 16:46 |
| *** finn has quit IRC | 16:55 | |
| 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 | 16: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 | 16:59 |
| *** tiagogomes has quit IRC | 17:04 | |
| *** xjuan has joined #buildstream | 17:07 | |
| *** jonathanmaw has quit IRC | 17:10 | |
| *** xjuan has quit IRC | 17:16 | |
| bochecha | one thing I find annoying with buildstream, is when I try to `bst shell --build foo.bst` and it tells me "nope, don't have the deps to open a shell" | 17:16 |
| bochecha | so I `bst build foo.bst`, but that just pulls that element from the cache | 17:16 |
| bochecha | and I have to copy-paste the list of required elements into a `bst build …` command | 17:16 |
| *** xjuan has joined #buildstream | 17:17 | |
| bochecha | is there no way to `bst build --stuff-needed-for-a-build-shell foo.bst` ? | 17:17 |
| gitlab-br-bot | buildstream: merge request (chandan/fix-source-bundle->master: Fix source-bundle command) #807 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/807 | 17:17 |
| bochecha | (this happens to me very regularly) | 17:17 |
| *** lachlan has joined #buildstream | 17:22 | |
| *** lachlan has quit IRC | 17:27 | |
| tristan | bochecha, Interesting, so you have a lot of "build only" dependencies ? | 17:43 |
| tristan | bochecha, you should be able to `bst build --all`, but that will really make the target "every build dep of every build dep" | 17:44 |
| tristan | bochecha, We could do something like this... (A) Deprecate the `--all` option of `bst build`, (B) Introduce a `--deps` option, symmetrical with other bst commands, which could be defaulting to 'plan', but support 'all' and 'build' | 17:45 |
| tristan | Then we could do `bst build --deps build foo.bst` | 17:45 |
| bochecha | tristan: oh yes | 17:47 |
| tristan | bochecha, It would be nice if you could propose the change on the ML honestly, I don't think it's huge or controversial change; but it's always nice to have more people going through the proposal process, also others might have ideas/gotchas I didn't think of | 17:54 |
| gitlab-br-bot | buildstream: merge request (chandan/fix-source-bundle->master: Fix source-bundle command) #807 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/807 | 17:58 |
| tristan | bochecha, I've started on ripping out blessings as a dependency today, which I will backport to 1.2 for the sake of easing packaging | 18:02 |
| tristan | however I noticed that for some time (or since always ?) blessings depends on curses | 18:02 |
| tristan | which is ironic, because when I chose blessing originally, I thought I was avoiding that dep | 18:02 |
| *** toscalix has quit IRC | 18:02 | |
| tristan | maybe we inadvertantly started depending on it since we started depending on >= 1.6 | 18:03 |
| tristan | not sure | 18:03 |
| tristan | bochecha, do you think python curses will be problematic ? | 18:03 |
| tristan | (for fedora I mean) | 18:03 |
| bochecha | tristan: isn't it part of Python itself? | 18:03 |
| tristan | I could go either way, but with curses it's more reliable | 18:03 |
| tristan | standard lib ? | 18:03 |
| bochecha | I think so | 18:04 |
| bochecha | yup | 18:04 |
| bochecha | $ rpm -ql python3-libs | rg curses | 18:04 |
| bochecha | /usr/lib64/python3.6/curses | 18:04 |
| tristan | oh maybe | 18:04 |
| tristan | https://docs.python.org/3/howto/curses.html | 18:04 |
| tristan | by the location of that doc, it would seem | 18:04 |
| tristan | okay then, completely uncontroversial then | 18:04 |
| tristan | and it will be more reliable than blessings was | 18:05 |
| tristan | As I can just disable the status bar completely in a setting where curses (with it's deep knowledge of terminal databases) tells me that not all the escape codes I want are available | 18:05 |
| tristan | whereas blessings just gives us empty strings | 18:06 |
| *** rdale has quit IRC | 18:31 | |
| *** toscalix has joined #buildstream | 18:32 | |
| *** tristan has quit IRC | 21:17 | |
| *** bochecha has quit IRC | 22:37 | |
| *** toscalix has quit IRC | 22:42 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!