| *** tristan has quit IRC | 03:25 | |
| *** tristan has joined #buildstream | 04:15 | |
| *** ChanServ sets mode: +o tristan | 04:15 | |
| tristan | Uhhhh | 04:15 |
|---|---|---|
| tristan | Did someone pull the plug on CI completely ? | 04:16 |
| tristan | https://gitlab.com/BuildStream/buildstream/-/pipelines/166676639 | 04:16 |
| tristan | jjardon, ? | 04:16 |
| *** tristan has quit IRC | 04:30 | |
| *** phildawson has quit IRC | 05:13 | |
| *** benschubert has joined #buildstream | 07:19 | |
| *** tristan has joined #buildstream | 07:24 | |
| *** ChanServ sets mode: +o tristan | 07:24 | |
| tristan | CI seems to have springed back to life | 07:25 |
| nanonyme | tristan, maybe it was just tired and went to sleep | 07:27 |
| tristan | Maybe the config changed somehow | 07:30 |
| tristan | Like, before when it warmed up, you'd have the jobs starting and blocking in the beginning | 07:31 |
| tristan | In this case you just had the whole board stuck on pause | 07:31 |
| *** tristan has quit IRC | 08:17 | |
| *** tristan has joined #buildstream | 08:33 | |
| *** ChanServ sets mode: +o tristan | 08:33 | |
| *** philn has quit IRC | 08:44 | |
| *** santi has joined #buildstream | 08:45 | |
| jjardon | tristan: maybe gitlab update? | 10:24 |
| jjardon | seems they are in 13.2.0-pre now | 10:24 |
| tristan | mm | 10:59 |
| *** adds68 has quit IRC | 15:12 | |
| juergbi | tristan, benschubert: iirc, there was a discussion quite a while ago about dropping the project/element name prefix from artifact cache keys. do either of you or anyone else remember where and when this happened? | 15:19 |
| benschubert | juergbi: I think we discussed it at least in the meeting around blockers for bst 2.0 ? I can't remember where else though | 15:19 |
| juergbi | hm, don't see it in those notes. I thought we had a discussion about this much earlier than that | 15:22 |
| benschubert | juergbi: earliest I remember was the last meeting in London | 15:22 |
| benschubert | can't recall exactly when... october 2019 maybe? | 15:22 |
| juergbi | build meetup london was in October 2019. we might have briefly discussed it there as part of the then Fetch API discussion | 15:25 |
| benschubert | and cleaning up the artifact protos | 15:26 |
| juergbi | related discussions happened in these threads: https://mail.gnome.org/archives/buildstream-list/2018-September/msg00050.html and https://mail.gnome.org/archives/buildstream-list/2019-August/msg00003.html | 15:52 |
| WSalmon | i have definitly discused that moving a element should not invalidate its cache key, or the cache key of things that depend on it. it dose seem rather silly that it dose. but i dont recall were | 16:00 |
| tristan | juergbi, it will be linked in the 2.0 targets email | 16:03 |
| tristan | that took me a while to find | 16:03 |
| juergbi | ah, as part of cache key stability, right | 16:05 |
| juergbi | WSalmon: unfortunately, support for non-strict builds essentially prevents this due to the way weak cache keys work | 16:06 |
| juergbi | but it means it should probably be a whole separate discussion. maybe try to keep Remote Asset API migration as orthogonal as possible | 16:08 |
| WSalmon | juergbi, i do understand it would be quite something to untanble at this point but i think its a shame | 16:11 |
| WSalmon | un-tangle | 16:12 |
| juergbi | it's impossible for weak keys as they use names in their dependencies | 16:12 |
| juergbi | it would be possible for strong keys but only if we completely decoupled strong and weak keys, which would be fairly odd, imo | 16:13 |
| juergbi | (name change resulting in a new weak key but unchanged strong key) | 16:13 |
| juergbi | unless we support completely disabling non-strict builds on a per-project basis (affecting cache keys) | 16:15 |
| tristan | juergbi, I'm not sure that would be odd honestly | 16:23 |
| tristan | I'm not convinced there is an inherent "sense" to building strong keys on top of weak keys | 16:23 |
| juergbi | I would be surprised by non-strict bst build taking longer than strict bst build | 16:24 |
| juergbi | I suppose that wouldn't actually be the case | 16:24 |
| tristan | Only in the rare case something was renamed ? | 16:24 |
| juergbi | yes | 16:25 |
| tristan | Not sure it's something worth caring about | 16:25 |
| juergbi | it's not the only issue | 16:25 |
| tristan | Better that, than completely disabling non-strict on a per-project basis I think | 16:25 |
| juergbi | we currently store the two cache keys in the artifact proto | 16:25 |
| juergbi | we would have to drop this | 16:25 |
| tristan | sounds like plumbing | 16:26 |
| juergbi | which means we could no longer get the weak cache key from a strong one | 16:26 |
| tristan | one is effectively an alias to another conceptually speaking | 16:26 |
| juergbi | yes but we could no longer store the aliases in the artifact prpoto | 16:26 |
| tristan | means an extra (hopefully lightweight) round trip ? | 16:27 |
| juergbi | yes | 16:28 |
| juergbi | or it might | 16:28 |
| tristan | Still sounds better than locking a project into strict/non-strict on a per project basis | 16:28 |
| juergbi | yes | 16:29 |
| juergbi | it still adds an extra wrinkle to non-strict mode, which can already be confusing at times | 16:29 |
| tristan | juergbi, the speed of build on rename should be eliminated with reproducible builds and build cutoff detections in some realistic future | 16:30 |
| juergbi | if we essentially create a local action cache (or use remote execution), it might | 16:31 |
| juergbi | although, the element name is also in the input tree right now, isn't it? | 16:31 |
| juergbi | build-root: /buildstream/autotools/hello.bst | 16:32 |
| tristan | right but if we find a matching content hash of something we do build, we still save ourselves from rebuilding reverse deps.... maybe ? | 16:32 |
| tristan | maybe not | 16:32 |
| tristan | for renamed elements on weak keys | 16:32 |
| tristan | maybe there is a more ideal solution I'm not seeing yet | 16:33 |
| juergbi | it might actually not be that much of an issue as we still check strict keys even in non-strict modes | 16:33 |
| tristan | not sure, but I think I'd still be comfortable with the tradeoffs | 16:33 |
| tristan | right | 16:33 |
| juergbi | have to think about it some more. I thought it might be a quick discussion about dropping the name prefix from the artifact ref on the artifact server as part of switching to the remote asset API | 16:35 |
| juergbi | however, I'm now tending towards keeping the name prefix in the initial switchover and pursuing the potential name prefix drop separately | 16:36 |
| juergbi | don't want to mix matters more than necessary if it's not a trivial topic | 16:36 |
| juergbi | as long as we don't have cache key stability yet in master, an extra step that invalidates previously cached entries may not be a big deal | 16:37 |
| juergbi | (and dropping names would anyway require cache key version increment) | 16:38 |
| *** philn has joined #buildstream | 17:52 | |
| *** santi has quit IRC | 17:53 | |
| *** bwh has joined #buildstream | 19:29 | |
| *** benschubert has quit IRC | 19:46 | |
| bwh | I'm seeing an issue with bst 1.4.3 where the git source is unable to fetch updates | 19:59 |
| bwh | The local git repo has remotes called 'origin' and 'https___gitlab_com_freedesktop_sdk_mirrors_gitlab_', but it tries to fetch from a remote called 'https___gitlab_com_' | 20:00 |
| bwh | I think this might have been fixed on master some time back, but not picked for the 1.4 branch yet | 20:01 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!