| *** phoenix has joined #buildstream | 00:10 | |
| *** phoenix has quit IRC | 00:25 | |
| *** phoenix_ has joined #buildstream | 00:25 | |
| *** phoenix_ has quit IRC | 00:28 | |
| *** phoenix has joined #buildstream | 00:34 | |
| *** phoenix has quit IRC | 00:38 | |
| *** Amelia8605 has joined #buildstream | 01:55 | |
| *** Amelia8605 has quit IRC | 01:58 | |
| *** Harper4216 has joined #buildstream | 04:55 | |
| *** tristan has quit IRC | 04:56 | |
| *** Harper4216 has quit IRC | 04:57 | |
| *** tristan has joined #buildstream | 05:25 | |
| *** Serenity2190 has joined #buildstream | 05:57 | |
| *** Serenity2190 has quit IRC | 05:59 | |
| *** phildawson has quit IRC | 07:03 | |
| *** tristan has quit IRC | 07:11 | |
| *** benschubert has joined #buildstream | 07:22 | |
| *** jude has joined #buildstream | 07:30 | |
| coldtom | thanks so much juergbi! | 08:06 |
|---|---|---|
| juergbi | yw | 08:10 |
| *** tpollard has joined #buildstream | 08:23 | |
| traveltissues | can someone have a look please https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/115 | 08:42 |
| traveltissues | ty | 08:44 |
| *** santi has joined #buildstream | 08:51 | |
| *** slaf_ is now known as slaf | 09:16 | |
| *** tristan has joined #buildstream | 09:22 | |
| *** tpollard has quit IRC | 09:28 | |
| *** tpollard has joined #buildstream | 09:30 | |
| *** ChanServ sets mode: +o tristan | 09:44 | |
| traveltissues | the cache for bst-plugins-experimental seems to be full: https://gitlab.com/BuildStream/bst-plugins-experimental/-/jobs/572806134#L446 does anyone have access to clear it? | 10:04 |
| tristan | traveltissues, the "clear runner caches" button ? ... sure sec | 10:05 |
| tristan | cache is reset now | 10:06 |
| traveltissues | thanks | 10:06 |
| traveltissues | i don't have permissions for that button | 10:06 |
| tristan | Yup, just was wondering for a sec if it might be a different cache, like an artifact server or smth | 10:06 |
| tristan | but yeah logically it must be a gitlab cache you mean :) | 10:06 |
| tristan | So, still no decision about what semantics to use to allow multiple junctions in the same project, and no opinions at all about the artifact cache configuration spaghetti yet either... | 10:09 |
| tristan | benschubert, juergbi ... cs-shadow seems to have expressed ambivalence about the name of `target` (by my reading of https://gitlab.com/BuildStream/buildstream/-/merge_requests/1937#note_348934212)... shall we go with `inherit` rather than `link` ? | 10:10 |
| * tristan otherwise rummages through the milestone for something to "do" over the weekend... | 10:11 | |
| benschubert | tristan: I'm fine with that | 10:11 |
| benschubert | if you're looking for things to do, I'll appreciate reviews on https://gitlab.com/BuildStream/buildstream/-/merge_requests/1943 :) | 10:12 |
| tristan | oh sure ! | 10:12 |
| traveltissues | tristan: both 'inherit' and 'link' are overloaded terms imo but 'link' especially so | 10:12 |
| benschubert | for the multiple junctions and artifact cache, I need to take a moment to sit down and go through it, not sure I'll manage before monday though :/ | 10:12 |
| juergbi | tristan: inherit to me sounds a bit more like include semantics, which is not the case | 10:12 |
| juergbi | it's not a separate junction/subproject instance | 10:12 |
| juergbi | it is the same | 10:13 |
| tristan | juergbi, honestly, that has never been clear to me from the word `target` either; I'm not sure it's that important that the user sees it as "the same junction" or "using that remote junction configuration to define this one" | 10:14 |
| tristan | It would be better if that was clear, agreed | 10:15 |
| juergbi | the behavior would be different for these two scenarios | 10:15 |
| juergbi | so using the wrong term here is misleading, imo | 10:15 |
| juergbi | it would then be a conflicting subproject | 10:15 |
| tristan | Mmmyeah, the docs are not really clear about that differing behavior either | 10:16 |
| tristan | I.e. does it make any difference to the end user that internally, element instances are not duplicated ? | 10:16 |
| tristan | Or is it mostly just important that "both junctions are configured exactly the same" (which is what the docs have been saying) | 10:16 |
| juergbi | well, yes, as long as the config must be identical, it should indeed not be relevant | 10:17 |
| juergbi | however, inherit without ability to change anything also sounds like the wrong term to me | 10:17 |
| tristan | That's the caveat I pointed out in my last email | 10:17 |
| juergbi | yep | 10:17 |
| benschubert | fair point | 10:18 |
| benschubert | maybe dumb but... "use" ? | 10:18 |
| juergbi | on its own that word also doesn't seem that clear, imo | 10:18 |
| traveltissues | 'intersection'? | 10:18 |
| tristan | But, the reason I still like it better than other options, especially link; is that the inability to "merge" is mostly important at project authoring time (you'll get errors if you try anyway) | 10:19 |
| tristan | traveltissues, I like intersection for other things honestly, and I don't think it works here | 10:19 |
| tristan | traveltissues, for instance, the intersection of elements to include / exclude with using `--except` parameters on the command line | 10:19 |
| traveltissues | true | 10:19 |
| traveltissues | i forgot that's already a thing | 10:20 |
| tristan | it's not a keyword anywhere but still I think it is a useful term | 10:20 |
| jjardon | tristan: can you be an apache project but still hosted in gitlab? | 10:21 |
| traveltissues | ultimately a single word config key is going to have a certain ambiguity that needs to be clarified by the docs, i think you're just trying to decide which is least ambiguous, not which is unambiguous | 10:21 |
| jjardon | tristan: can you be an apache project but still be LGPL? | 10:21 |
| tristan | So "use" is a bit empty, less clear... "link" is bit ambiguous, however, at least expresses "this thing is a link: junction.bst" | 10:22 |
| tristan | I would prefer a verb honestly | 10:22 |
| tristan | jjardon, (A) I think it's not problematic, (B) No I believe not. | 10:22 |
| traveltissues | well does it express a 'union' of elements? | 10:22 |
| * jjardon noticed announcements were made about joining apache but not about implications license-wise | 10:23 | |
| tristan | jjardon, regarding (A) it's still not clear what will happen, we hope we can keep using gitlab wherever we're physically hosted, though | 10:23 |
| benschubert | jjardon: AFAIK we'll need to move to their infrastrucutre, but that's not something that needs to be done right away and we can have a trnasition period, and they do use GitHub + Jenkins | 10:23 |
| benschubert | but I don't have the whole context either, others would be able to answer better | 10:24 |
| tristan | would be smoother to stay with gitlab rather, but we'll see what happens then | 10:24 |
| tristan | I'd really like to figure out the name here... :-S | 10:24 |
| tristan | traveltissues, I think it's a configuration of a junction, which might have an impact on elements, but only indirectly (and not even necessarily related to elements) | 10:25 |
| tristan | You can use junctions just for includes or just for plugins | 10:25 |
| juergbi | tristan, benschubert: in a way I'd like `kind: link` with `target: ...` | 10:25 |
| tristan | juergbi, Yeah I see what you mean | 10:26 |
| juergbi | but I think we said we don't want to support it for non-junction elements | 10:26 |
| tristan | Well | 10:26 |
| tristan | What is a junction anyway | 10:26 |
| tristan | Hmmm | 10:26 |
| juergbi | I wouldn't mind generalizing this | 10:26 |
| tristan | Right, actually a link is imperfect because... what if a link can link other things, not just a junction | 10:26 |
| tristan | Hmmm | 10:27 |
| juergbi | yes, if we have a 'kind: link' it should really work with any element | 10:27 |
| tristan | Like a junction-link | 10:27 |
| juergbi | that's another option | 10:27 |
| juergbi | kind: junction-link | 10:27 |
| juergbi | target: foo.bst | 10:27 |
| jjardon | benschubert: github is ok but not gitlab? Do you know who can know more about this? | 10:27 |
| tristan | Right, would you see a 'kind: link' being useful for anything other than a junction, though ? | 10:27 |
| benschubert | jjardon: sander most definitely would know or point to the right persons | 10:28 |
| jjardon | benschubert: what about the licensing? | 10:28 |
| juergbi | tristan: conceptually, yes. although it can trivially be handled by a stack with a single element right now | 10:28 |
| juergbi | e.g., you could have c-compiler.bst | 10:28 |
| juergbi | that links to gcc or clang depending on project option | 10:29 |
| tristan | Myeah, that seems covered by stacks | 10:29 |
| tristan | I'm weary of adding multiple angles to the same problem | 10:29 |
| benschubert | jjardon: don't know for sure, but I don't know any Apache project that doesn't have the apache license | 10:29 |
| tristan | juergbi, although interestingly it seems like a good approach seeing as; the alternative is to have an option which makes all other options invalid | 10:30 |
| tristan | Hmmm | 10:30 |
| jjardon | mmm, I think those are important things to clearly state, if this is actually happen | 10:30 |
| juergbi | yes, I really like the clarity of kind: link | 10:30 |
| benschubert | juergbi: agreed | 10:31 |
| jjardon | benschubert: I guess the only one that knows for sure is Sanders? | 10:31 |
| tristan | I was just thinking, maybe "link-to: target-junction.bst" would be good, but "kind: link" is really warming up | 10:31 |
| tristan | Or I'm warming up to it rather ;-) | 10:31 |
| tristan | juergbi, benschubert; does a "link" element allow linking to local elements too ? | 10:31 |
| tristan | (or junctions) | 10:32 |
| juergbi | yes | 10:32 |
| benschubert | jjardon: I don't know. Probably Neil too | 10:32 |
| tristan | Yeah I'd think | 10:32 |
| tristan | the junction target does not currently | 10:32 |
| juergbi | oh, right, I thought it did already | 10:32 |
| benschubert | yeah, a link seems nice to me too, that way you can alias elements, without having a 'stack' in a middle | 10:32 |
| jjardon | benschubert: Neil? from GNOME? | 10:33 |
| traveltissues | i see your point about the use of 'union' and i'd like to say that junctions are sets which are larger than one item but that's not helpful | 10:33 |
| traveltissues | tristan: ^ | 10:33 |
| benschubert | jjardon: as from the email about it: CC: Neil McGovern, Executive Director, GNOME Foundation | 10:33 |
| tristan | traveltissues, I think this `kind: link` so far is really the nicest semantic, what do you think ? | 10:34 |
| traveltissues | it makes sense to do that yes but i doesn't clarify that you're disallowing non-junctions (if i read that correctly) | 10:34 |
| jjardon | ah, he probably would know about the gNOME rules, not sure about the Apache ones :) I will ask in the thread | 10:34 |
| tristan | traveltissues, this way the junction documentation can recommend using a link to a subproject junction | 10:35 |
| tristan | traveltissues, to accomplish the same as what `target` currently does | 10:35 |
| tristan | traveltissues, and no, it has to work with any element too | 10:35 |
| tristan | it's a general all purpose "link" | 10:36 |
| traveltissues | ah, ok then i think that's fine | 10:36 |
| traveltissues | can someone take a look please https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/114 | 10:38 |
| *** cphang has joined #buildstream | 10:41 | |
| *** cs-shadow has joined #buildstream | 10:53 | |
| benschubert | thanks tristan ! | 10:54 |
| *** tristan has quit IRC | 11:01 | |
| *** Julia7011 has joined #buildstream | 11:10 | |
| *** Julia7011 has quit IRC | 11:12 | |
| *** Nevaeh1974 has joined #buildstream | 11:23 | |
| cphang | Tyvm benschubert juergbi and tristan for the help and assistance around https://gitlab.com/BuildStream/buildstream/-/issues/1310 and https://gitlab.com/BuildStream/buildstream/-/issues/1318, once both issues close would it be possible to consider a new 1.93.4 dev tag? | 11:24 |
| *** Nevaeh1974 has quit IRC | 11:24 | |
| juergbi | please note that the main fix for the latter is in buildbox-common | 11:24 |
| juergbi | and not merged yet | 11:24 |
| cphang | right ofc juergbi, would you consider a 0.0.9 tag for buildbox-common? | 11:25 |
| juergbi | should be possible, yes, but let's first finish/merge it | 11:27 |
| cphang | juergbi, is there an issue to track against in buildbox-common? The MRs in buildbox you linked to in #1318 all appear to have been merged? | 11:28 |
| WSalmon | juergbi, i thought it was https://gitlab.com/BuildGrid/buildbox/buildbox-common/-/merge_requests/278 | 11:29 |
| juergbi | No, I don't think there is an issue. I've linked to the buildbox-common branch from #1318 but I haven't opened an MR yet | 11:30 |
| juergbi | https://gitlab.com/BuildGrid/buildbox/buildbox-common/-/commits/juerg/grpc-retry | 11:30 |
| juergbi | Want to make sure the changes really make sense first | 11:31 |
| juergbi | and it causes an issue with casd tests that needs to be resolved | 11:31 |
| juergbi | I can open a WIP MR if that helps with tracking | 11:31 |
| cphang | juergbi, no rush, if the MRs going to be up eventually then we can wait, as you pointed out you've already linked to the branch in #1318 | 11:33 |
| cphang | I was curious why we would only retry on UNAVAILABLE, in principle we would want to retry for FAILED_PRECONDITION and ABORTED as well? | 11:36 |
| juergbi | that's one aspect that requires a closer look | 11:37 |
| juergbi | according to https://grpc.github.io/grpc/cpp/md_doc_statuscodes.html FAILED_PRECONDITION should not trigger a blind retry | 11:38 |
| juergbi | UNAVAILABLE should always be retried (with backoff) | 11:38 |
| juergbi | at least for idempotent operations | 11:38 |
| juergbi | for ABORTED it may make more sense to retry at a higher level, i.e., in buildstream | 11:39 |
| WSalmon | https://gitlab.com/freedesktop-sdk/infrastructure/freedesktop-sdk-docker-images/-/commits/willsalmon/bst2-buildbox-fix juergbi do we think this should fix that cache issue? | 11:52 |
| juergbi | yes, I think so | 11:53 |
| juergbi | at least assuming it won't ever need more than 10 retries | 11:54 |
| WSalmon | Brill, i apprecate its to the best of our knowlage | 11:54 |
| WSalmon | right, i am hoping that that should push the "mean time before failure" from the ~1hr to ~10hr which combined wiht the build order fix should resolve this for FD | 11:55 |
| cphang | juergbi, in principle I agree, although what gets returned can be a bit subjective, at least with my experience with buildbarn. FAILED_PRECONDITION is in particular very context specific | 11:56 |
| juergbi | which is why we should not blindly retry in that case | 11:56 |
| juergbi | maybe there are selected operations where retry still makes sense | 11:56 |
| juergbi | but e.g. for remote execution failed precondition may happen if a blob was already expired | 11:57 |
| juergbi | in that case it doesn't make sense to retry Execute, we have to first reupload missing blbos | 11:57 |
| juergbi | i.e., retry the whole job in BuildStream, not the individual gRPC call in buildbox | 11:57 |
| juergbi | well, Execute doesn't go via buildbox (yet), so maybe not the best example | 11:58 |
| cphang | Yeh I'm thinking within the context of FindMissingBlobs, is there a client side context upon which if the server returns FAILED_PRECONDITION, the client shouldn't repeat the FindMissingBlobs call? | 12:00 |
| *** tpollard has quit IRC | 12:16 | |
| *** tpollard has joined #buildstream | 12:16 | |
| *** Emilia7128 has joined #buildstream | 12:23 | |
| juergbi | cphang: when would FindMissingBlobs fail with FAILED_PRECONDITION? | 12:25 |
| *** Emilia7128 has quit IRC | 12:25 | |
| cphang | So I'm thinking of a scenario where the REAPI connects to a storage backend (say an S3 bucket) that is transiently unavailable. In principle that would be a bad but recoverable system state, and would justify a FAILED_PRECONDITION. | 12:32 |
| *** phildawson has joined #buildstream | 12:33 | |
| cphang | I would note that Buildbarn doesn't return FAILED_PRECONDITION in this scenario. I'm just thinking of the potential behvaiour of other REAPI server implementations, though I could be wrong on this. | 12:33 |
| cphang | and then there's DEADLINE_EXCEEDED calls as well? | 12:35 |
| juergbi | according to the documentation the server should return UNAVAILABLE, not FAILED_PRECONDITION if the client should simply retry the call | 12:58 |
| juergbi | I think we should aim to following the spec before adding workarounds for hypothetical non-compliant servers | 12:59 |
| juergbi | I'm not sure about DEADLINE_EXCEEDED, have to take a look | 12:59 |
| traveltissues | are there any objections to https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/114 | 13:49 |
| traveltissues | ty coldtom | 14:05 |
| traveltissues | i'd appreciate a review on https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/113 too | 14:14 |
| traveltissues | can someone with access please clear the bst-plugins-experimental cache again, https://gitlab.com/BuildStream/bst-plugins-experimental/-/jobs/573279754#L1621 | 14:26 |
| juergbi | traveltissues: I've triggered a docker clean for the permanent runners | 14:35 |
| traveltissues | thanks | 14:36 |
| *** cs-shadow has quit IRC | 14:43 | |
| *** CTtpollard has joined #buildstream | 15:03 | |
| *** tpollard has quit IRC | 15:03 | |
| *** Julia7275 has joined #buildstream | 15:21 | |
| *** Julia7275 has quit IRC | 15:22 | |
| *** tristan has joined #buildstream | 15:26 | |
| *** jude has quit IRC | 16:19 | |
| *** cs-shadow has joined #buildstream | 16:48 | |
| *** Piper5383 has joined #buildstream | 17:11 | |
| *** Piper5383 has quit IRC | 17:12 | |
| *** CTtpollard has quit IRC | 17:22 | |
| *** cphang has quit IRC | 17:28 | |
| *** santi has quit IRC | 17:32 | |
| WSalmon | benschubert, juergbi cphang https://gitlab.com/BuildStream/buildstream/-/issues/1310#note_352089023 | 17:54 |
| *** philn has quit IRC | 19:30 | |
| *** philn has joined #buildstream | 19:33 | |
| *** cs-shadow has quit IRC | 20:28 | |
| *** benschubert has quit IRC | 20:30 | |
| *** Isabella7743 has joined #buildstream | 21:16 | |
| *** Isabella7743 has quit IRC | 21:18 | |
| *** jude has joined #buildstream | 21:34 | |
| *** jude has quit IRC | 21:59 | |
| *** tpollard has joined #buildstream | 22:08 | |
| *** tpollard has quit IRC | 22:09 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!