| *** tristan has quit IRC | 01:16 | |
| *** tristan has joined #buildstream | 07:22 | |
| *** ChanServ sets mode: +o tristan | 07:27 | |
| *** benschubert has joined #buildstream | 07:31 | |
| *** phildawson has joined #buildstream | 07:53 | |
| *** rdale has joined #buildstream | 08:00 | |
| juergbi | tristan: !1845 makes build-uid/gid optional to replace the inconsistent 'tainted artifact' approach to support sandboxes that don't allow custom uid/gid, in case you want to review | 08:15 |
|---|---|---|
| gitlab-br-bot | MR !1845: Improve sandbox configuration handling https://gitlab.com/BuildStream/buildstream/-/merge_requests/1845 | 08:15 |
| *** santi has joined #buildstream | 08:16 | |
| *** tpollard has joined #buildstream | 08:24 | |
| *** phoenix has joined #buildstream | 08:43 | |
| *** lachlan has joined #buildstream | 08:53 | |
| *** phoenix has quit IRC | 08:57 | |
| tristan | juergbi, ok... I am in the middle of a huge proposal email :-S | 09:08 |
| * tristan will try to reduce :( | 09:08 | |
| *** tristan has quit IRC | 09:22 | |
| *** lachlan has quit IRC | 09:28 | |
| *** tristan has joined #buildstream | 09:35 | |
| *** ChanServ sets mode: +o tristan | 09:36 | |
| * tristan curses starbucks wifi... people sneak in some kind of ugly which blocks you from essentials, like IRC | 09:36 | |
| *** lachlan has joined #buildstream | 09:39 | |
| juergbi | I'd suggest using an SSH proxy or VPN | 09:40 |
| *** mohan43u has quit IRC | 09:53 | |
| *** mohan43u has joined #buildstream | 10:04 | |
| tristan | Hmmm yeah maybe I can switch on my VPN | 10:36 |
| *** tristan has quit IRC | 10:36 | |
| *** tristan has joined #buildstream | 10:53 | |
| *** tristan_ has joined #buildstream | 10:54 | |
| *** ChanServ sets mode: +o tristan_ | 10:54 | |
| * tristan_ will try to figure out how to connect to the vpn later... | 10:55 | |
| tristan_ | old creds don't work anymore :-S | 10:55 |
| *** lachlan has quit IRC | 11:03 | |
| douglaswinship | I just found some weird behaviour with the overlap-whitelist. I was trying to put "/etc/issue.net" in to the overlap whitelist for an element, and I was still getting an overlap warning, even though I'd white-listed it. Eventually found out that the leading slash was the problem. | 11:12 |
| douglaswinship | "- etc/issue.net" <-- works | 11:12 |
| douglaswinship | "- /etc/issue.net" <-- doesn't work. | 11:12 |
| douglaswinship | is that expected behaviour? | 11:12 |
| douglaswinship | it's unfortunate, imho, because it means I can't really use the project variables like %{sysconfdir} and %{datadir}. They generally start with slashes. | 11:13 |
| coldtom | douglaswinship this is fixed in 1.4.2 thanks to abderrahim[m] | 11:15 |
| coldtom | https://gitlab.com/BuildStream/buildstream/-/merge_requests/1841 | 11:15 |
| douglaswinship | aha! good to hear. | 11:15 |
| douglaswinship | excellent work abderrahim[m] | 11:16 |
| abderrahim[m] | ;) | 11:17 |
| *** lachlan has joined #buildstream | 11:17 | |
| *** lachlan has quit IRC | 11:23 | |
| juergbi | abderrahim[m]: do you have time to get !1837 over the line? it would be good to get that in as it also blocks !1843 (for regression test) | 11:26 |
| gitlab-br-bot | MR !1837: _artifact.py: don't consider an artifact cached if public data is missing https://gitlab.com/BuildStream/buildstream/-/merge_requests/1837 | 11:26 |
| gitlab-br-bot | MR !1843: Fix handling of missing blobs in `ArtifactCache.pull()` https://gitlab.com/BuildStream/buildstream/-/merge_requests/1843 | 11:26 |
| *** lachlan has joined #buildstream | 11:27 | |
| abderrahim[m] | I'll try to do it today | 11:27 |
| juergbi | great, thanks | 11:31 |
| *** lachlan has quit IRC | 11:41 | |
| *** lachlan has joined #buildstream | 11:56 | |
| *** lachlan has quit IRC | 11:59 | |
| * tristan_ takes a look at https://gitlab.com/BuildStream/buildstream/-/merge_requests/1845 | 12:01 | |
| tristan_ | juergbi, cphang... I'd really like to get an implementation going to actually solve the junctioning issue we discussed sunday (actually I was itching to start banging out code on sunday) | 12:03 |
| tristan_ | But apparently it needs more discussion to get on the same page, maybe you can provide different insights and help me to see the problem differently | 12:04 |
| tristan_ | Anyway I have a proposal on the list, call it a strawman or not a strawman, I think it's a plausible proposal still | 12:04 |
| tristan_ | I'm mostly keen on the scenario where "Projects are maintained by different organizations" and "Products generally junction in various stacks of software from different providers, but need to CI these regularly, and the UX for this should be top notch" | 12:06 |
| tristan_ | Anyway when you get the chance to look at the proposal, I'd recommend glancing over the implementation, and consider reading the PS | 12:07 |
| juergbi | tristan_: regarding junction name-based coalescing, I would not be happy with project name-based coalescing either (even ignoring the loader issue) | 12:08 |
| juergbi | there are some use cases where you may actually want to have the same project twice in the build graph | 12:08 |
| tristan_ | juergbi, project name would be a start, from there one could build out something explicit for same-project-twice | 12:09 |
| juergbi | project name would actually be worse than junction name for these use cases | 12:09 |
| tristan_ | With the coalesce on element name, it just seems to be very confusing | 12:09 |
| juergbi | as with junction name you can actually include the same project twice | 12:10 |
| juergbi | (by using a different junction name) | 12:10 |
| tristan_ | Yes yes, you clearly cannot do something you could do before | 12:10 |
| juergbi | i.e., I don't think we should go there without having at least a clear plan how to handle those cases | 12:10 |
| tristan_ | That I get - but the project name is unique, and telling people to name their elements a certain way is really weird | 12:11 |
| tristan_ | Right | 12:11 |
| juergbi | as I mentioned, it's not like I'm really happy with the implicit junction name-based coalescing either | 12:11 |
| tristan_ | juergbi, The main reason I raised this is because I think it is orthogonal to the issue at hand | 12:11 |
| tristan_ | I mean, if we go there, I think the project name is the *right* thing to use to identify a project | 12:11 |
| tristan_ | And if one wants to explicitly have two of them, that should probably be a feature | 12:12 |
| tristan_ | Well, it could be done different ways, but for the regular case, the project name is safest, you cannot accidentally do the wrong thing | 12:12 |
| tristan_ | FWIW, I was unable to find a git submodules feature which allows you to override the sha1 of a sub-submodule without forking the direct submodule (and I'm quite unattracted to this approach, as outlined in the PS) | 12:15 |
| tristan_ | But, again, maybe there is something I'm not seeing, and maybe I should be seeing things differently, I'm just not convinced now | 12:15 |
| juergbi | coalescing: it could be orthogonal but I think it's not so clear cut. imo, it does make sense to keep both aspects in mind | 12:20 |
| juergbi | tristan_: git submodules: I meant the buildstream git config for submodules | 12:20 |
| *** tristan_ has quit IRC | 12:20 | |
| *** tristan has joined #buildstream | 12:30 | |
| *** cs-shadow has joined #buildstream | 12:34 | |
| *** tristan has quit IRC | 13:12 | |
| *** lachlan has joined #buildstream | 13:23 | |
| *** lachlan has quit IRC | 13:42 | |
| *** lachlan has joined #buildstream | 13:47 | |
| WSalmon | if you have --no-strict on then bst will let you update a dep to a newer version without triggering a rebuild, but if you dont already have a element that can match the weak key will it ever go and get a artifact from a remote server based on a weak key? | 13:51 |
| WSalmon | * a rebuild of all intermediate dependencies | 13:52 |
| abderrahim[m] | WSalmon: yes | 13:52 |
| abderrahim[m] | that's the point of the weak keys | 13:53 |
| WSalmon | benschubert, juergbi ^ | 13:53 |
| juergbi | WSalmon: yes to the first question but I'm not quite sure what you mean with the second message/correction | 13:57 |
| WSalmon | i get this for local work as the you probaly just built something similar so matching agents time is fair, but how dose the server decide which version to match the week key agenst? | 13:58 |
| juergbi | WSalmon: it simply gets the latest artifact that matches the weak key | 14:00 |
| juergbi | but only if a perfect match (strict key) is not available | 14:00 |
| juergbi | i.e., every artifact push will replace any potential previous artifacts on the server with the same weak key | 14:01 |
| WSalmon | so some one could have just pushed a experemintal build with a major version bump but the same weak key and it will go and blindly get that as its the latest thing pushed, wow, i though we didnt have weak pulling for this reason, sorry abderrahim[m] i had got it in my head that we didnt do this, clearly i was wrong | 14:03 |
| *** lachlan has quit IRC | 14:04 | |
| *** tristan has joined #buildstream | 14:04 | |
| abderrahim[m] | the "experimental" build would then cause a build failure later on, and we would have to trigger a strict build to fix it | 14:05 |
| abderrahim[m] | we've been using non-strict build for about a year now in gnome-build-meta, and we know the advantages and pitfalls ;) | 14:05 |
| juergbi | WSalmon: the weak key still only matches the exact same source/version | 14:08 |
| juergbi | it allows major changes / version bumps in build dependencies but yes, that's the clear pitfall | 14:09 |
| valentind | juergbi, I updated the docker image with your branch for the BlobNotFound. But now I get FileNotFoundError. | 14:22 |
| valentind | https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/500299903 | 14:22 |
| valentind | (It is not the branch exactly, but the branch rebased on the last tag in master) | 14:24 |
| juergbi | valentind: haven't seen that before. my initial thought would be casd expiring files that are part of the running bst session, but it shouldn't do that | 14:27 |
| abderrahim[m] | juergbi: !1837 should be ready now | 14:30 |
| gitlab-br-bot | MR !1837: _artifact.py: don't consider an artifact cached if public data is missing https://gitlab.com/BuildStream/buildstream/-/merge_requests/1837 | 14:30 |
| abderrahim[m] | valentind: can you try adding this fix too ^ | 14:30 |
| juergbi | valentind: btw: I don't consider snapshots more stable than master. I would generally not backport. that said, I can't think of a recent change that would make a difference here | 14:31 |
| * abderrahim[m] should rewrite the description | 14:31 | |
| juergbi | abderrahim[m]: thanks, will take a look | 14:31 |
| juergbi | valentind: have you already updated buildbox casd to 0.0.7? | 14:31 |
| valentind | juergbi, No, I was on 0.0.6. | 14:32 |
| valentind | abderrahim[m], I think I already have those patches in the docker image. | 14:34 |
| valentind | Ah no, maybe not one of them., | 14:34 |
| valentind | Right I am missing 1ede315ca55a3b0d7bc2cdaf15d94b2143f15a34. ANd I can update buildbox | 14:35 |
| abderrahim[m] | valentind: I think that's it. Someone (maybe bschubert) mentioned seeing the logs being expired too early and leading to a push error | 14:37 |
| *** BeatriceFer has joined #buildstream | 14:37 | |
| abderrahim[m] | or maybe that's not enough, and we need to also check for logs in `cached()` too? | 14:40 |
| *** BeatriceFer has quit IRC | 14:41 | |
| *** lachlan has joined #buildstream | 14:50 | |
| valentind | abderrahim[m], Maybe you can verify I have all the needed patches: https://gitlab.com/freedesktop-sdk/infrastructure/freedesktop-sdk-docker-images/-/merge_requests/97 | 14:51 |
| valentind | And then approve. | 14:51 |
| *** lachlan has quit IRC | 14:56 | |
| *** lachlan has joined #buildstream | 15:14 | |
| juergbi | abderrahim[m]: passes the test case in my branch. I've commented with a slight tweak | 15:17 |
| juergbi | with that the code changes look fine to me. however, we should run our benchmark, as mentioned earlier | 15:17 |
| juergbi | can you do this or shall I? | 15:18 |
| abderrahim[m] | juergbi: btw, there is one more thing: it seems bst will push logs unconditionally, but doesn't check that logs are cached as part of the artifact (there is a separate `cached_logs` function, but it isn't called outside of `bst artifact log` AFAICT). Could you please take a look? | 15:19 |
| juergbi | good point, at least for now I'd suggest that we simply push logs only if they exist locally | 15:21 |
| juergbi | hm, but also artifact pulling requires logs right now | 15:21 |
| juergbi | we either have to make them optional there as well or always check for logs | 15:22 |
| juergbi | the latter is another potential performance issue, though | 15:22 |
| abderrahim[m] | juergbi: pushed the suggested fix, for the benchmark please do | 15:23 |
| juergbi | ok | 15:23 |
| *** lachlan has quit IRC | 15:25 | |
| *** lachlan has joined #buildstream | 15:53 | |
| *** lachlan has quit IRC | 15:53 | |
| *** lachlan has joined #buildstream | 15:54 | |
| *** lachlan has quit IRC | 15:58 | |
| *** phoenix has joined #buildstream | 16:01 | |
| *** lachlan has joined #buildstream | 16:11 | |
| *** lachlan has quit IRC | 16:23 | |
| *** tristan_ has joined #buildstream | 16:25 | |
| *** lachlan has joined #buildstream | 16:32 | |
| *** lachlan has quit IRC | 16:47 | |
| *** lachlan has joined #buildstream | 16:49 | |
| *** tpollard has quit IRC | 17:01 | |
| *** lachlan has quit IRC | 17:03 | |
| *** santi has quit IRC | 17:19 | |
| *** santi has joined #buildstream | 17:20 | |
| *** lachlan has joined #buildstream | 17:23 | |
| *** santix has joined #buildstream | 17:36 | |
| *** santi has quit IRC | 17:36 | |
| *** santix has quit IRC | 17:37 | |
| *** lachlan has quit IRC | 17:49 | |
| *** lachlan has joined #buildstream | 17:58 | |
| *** lachlan has quit IRC | 18:04 | |
| *** lachlan has joined #buildstream | 18:08 | |
| *** lachlan has quit IRC | 18:14 | |
| *** cs-shadow has quit IRC | 20:33 | |
| *** rdale has quit IRC | 21:17 | |
| *** benschubert has quit IRC | 21:24 | |
| *** phoenix has quit IRC | 23:03 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!