| *** nimish has joined #buildstream | 00:55 | |
| *** nimish has quit IRC | 03:24 | |
| *** rdale has quit IRC | 04:40 | |
| gitlab-br-bot | juergbi merged MR !1142 (juerg/buffer-size->master: Increase read buffer size to improve performance) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1142 | 07:08 |
|---|---|---|
| nielsdg | juergbi: The main use case is to connect to the user session (which is provided on the dbus interface "org.freedesktop.login1" | 07:36 |
| nielsdg | juergbi: The practical use case is being able to run gnome-shell in a bst shell basically | 07:37 |
| juergbi | nielsdg: you could try to add /run/dbus/system_bus_socket to `host-files` in the project.conf's `shell` configuration | 07:41 |
| juergbi | not sure whether that will suffice | 07:41 |
| nielsdg | doesn't seem so :( | 07:58 |
| nielsdg | I also found out about the SYSTEMD_OFFLINE variable, so experimenting with that as well | 07:59 |
| juergbi | you could also try strace on systemctl/loginctl in bst shell to figure out what's missing | 08:01 |
| juergbi | valentind: do you expect to have time today to think about !1140 (and possibly also its dependency !1139)? | 08:01 |
| gitlab-br-bot | MR !1140: WIP: Do not resolve or mangle symlinks during staging https://gitlab.com/BuildStream/buildstream/merge_requests/1140 | 08:01 |
| gitlab-br-bot | MR !1139: Return all directories in list_relative_paths() https://gitlab.com/BuildStream/buildstream/merge_requests/1139 | 08:01 |
| juergbi | it's not really about full code review at this point, but rather whether you anticipate issues with the change in behavior | 08:02 |
| juergbi | you mentioned a potential issue with compose at the gathering, but that might actually be avoided by !1139 | 08:03 |
| juergbi | if you have a branch that you suspect may break, I can also do a test build here, let me know | 08:04 |
| *** erle- has left #buildstream | 08:12 | |
| *** tristan has joined #buildstream | 08:12 | |
| valentind | juergbi, I am fine !1140. It think it is the right thing to do. That solves quite a lot of problems. But I do not remember what was the conclusion of the discussion with had with tristan. | 08:53 |
| juergbi | valentind: ok, good. tristan was not in favor of it at the gathering but I'll discuss this again with him with the latest findings - given that I got fdo-sdk and gnome-build-meta working with very little changes, and the split-rule issue I didn't think of before | 08:57 |
| juergbi | speaking of which, hi tristan :) arrived safely back home? | 08:57 |
| Kinnison | Hmm, WSL runner trying to run the autotools examples | 08:57 |
| Kinnison | is that right? | 08:57 |
| Kinnison | I'd have expected that to not run on WSL | 08:57 |
| juergbi | Kinnison: no, one of the WSL runners didn't skip them for some reason | 08:58 |
| Kinnison | Urgh | 08:58 |
| Kinnison | so spurious failure? | 08:58 |
| juergbi | we anyway switched WSL CI to manual until the runner situation is sorted out | 08:58 |
| Kinnison | OK | 08:58 |
| * Kinnison will rebase so that comes into his branch then | 08:58 | |
| juergbi | maybe the platform check is not robust enough | 08:58 |
| Kinnison | perhaps | 08:58 |
| juergbi | I think it worked correctly with the newly setup runner but broke with the old (manually installed?) runner | 08:59 |
| valentind | juergbi, we could always have a top integration command to recreate symlinks after staging if we needed. I think it would be better. Maybe we could actually make a plugin that does that. | 08:59 |
| juergbi | valentind: replacing directory with a symlink in integration command should still work (fdo-sdk does that, iirc, and I could successfully build that) | 09:00 |
| juergbi | I don't currently see a need for a plugin for this but maybe I'm missing something | 09:01 |
| juergbi | it's not like we stop supporting symlinks anymore, we just don't follow them during staging | 09:01 |
| Kinnison | WSalmon: print(data) worked, thanks for taking the time to speak with me | 09:18 |
| *** rdale has joined #buildstream | 09:23 | |
| juergbi | jennis: I think the code changes in !1101 look good now but please fix up the branch history as per our contributing guidelines. I've mentioned a few things in the MR but it applies to all the fixups | 09:57 |
| gitlab-br-bot | MR !1101: Refactor artifact log command https://gitlab.com/BuildStream/buildstream/merge_requests/1101 | 09:57 |
| *** solid_black has quit IRC | 09:57 | |
| *** solid_black has joined #buildstream | 09:58 | |
| jennis | thanks juergbi | 09:58 |
| *** jonathanmaw has joined #buildstream | 10:00 | |
| *** raoul_ has joined #buildstream | 10:06 | |
| *** raoul_ is now known as raoul | 10:20 | |
| *** alatiera has joined #buildstream | 10:22 | |
| raoul | Looks like I've had a pipeline pass everything bar wsl, is this something I should worry about? Or has it been removed for now and I just need to rerun the whole pipeline for it to pass? | 10:23 |
| laurence | raoul, think it's been temporarily removed for now until we sort out the hardware for WSL runners | 10:23 |
| Kinnison | raoul: if you rebase you'll find WSL temporarily set to manual | 10:23 |
| raoul | Ah cool, I'll do that | 10:24 |
| raoul | cheers | 10:24 |
| tpollard | raoul: have you got a link to the specific failure? | 10:25 |
| laurence | jonathanmaw, any news on that? /me goes to chase Codethink Ops | 10:25 |
| raoul | tpollard, seems to be a few things https://gitlab.com/BuildStream/buildstream/-/jobs/159690597 | 10:26 |
| raoul | just examples and integration tests that are failing it seems | 10:26 |
| juergbi | raoul, jonathanmaw: one WSL runner doesn't skip sandbox-requiring integration tests for some reason | 10:27 |
| juergbi | the other runner does/did | 10:27 |
| raoul | ah well that'll be where it's going wrong | 10:27 |
| jonathanmaw | how odd. I'll have a peek | 10:28 |
| valentind | juergbi, found an interesting thing. If we have 2 files in cache that are the same content, one should have execution access right, the other not, then at the end they will both have execution rights. And it will be written in cache at checkout. | 10:28 |
| juergbi | valentind: yes, that's a limitation of the hardlinking approach :/ | 10:29 |
| juergbi | not an issue with FUSE | 10:29 |
| juergbi | buildbox-fuse, that is | 10:29 |
| juergbi | not sure how to best handle this long term for the non-FUSE case | 10:29 |
| juergbi | we could copy all executable files instead of hardlinking them, but... | 10:29 |
| juergbi | valentind: do you see this issue in practice or just in a test case? | 10:30 |
| valentind | juergbi, I do not think of anything that would be problematic. Because at the end execution rights win. | 10:32 |
| juergbi | yes, we never remove them | 10:33 |
| valentind | Though yes. Maybe for reproducibility. | 10:33 |
| valentind | Because depending on the order of the build, you might have different right. | 10:33 |
| valentind | And, let's say, you have a script element that set +x on all files and make an artifact of all the files. | 10:35 |
| valentind | You can seriously mess up a local cache like that. | 10:35 |
| juergbi | indeed, it's definitely not a good situation | 10:35 |
| valentind | What if we duplicate in the local cache. By default we start with the just the object in 0644. If we want it in 0744, we rename it in the cache with an extension .exec. If ever want it again in 0644 and it is only the .exec file, then we copy it. | 10:38 |
| *** lachlan has joined #buildstream | 10:38 | |
| valentind | And we rename it only if there is no other links. | 10:38 |
| juergbi | a simple object existence check would get more expensive | 10:38 |
| juergbi | another option could be to always verify the permissions when creating hardlinks. if they do not match, update them only if the link count is 1 | 10:39 |
| valentind | Right. | 10:39 |
| juergbi | otherwise, create a full copy of the file | 10:39 |
| juergbi | in most cases (same file not changing executable bit) this should not require copies | 10:39 |
| valentind | We need to do it atomically however. | 10:40 |
| juergbi | right, that's probably not possible | 10:40 |
| *** WSalmon__ has joined #buildstream | 10:44 | |
| *** WSalmon_ has quit IRC | 10:45 | |
| valentind | I think the hash of objects should have included its inode metadata. | 10:55 |
| *** ChanServ sets mode: +o tristan | 11:02 | |
| tristan | juergbi, Yes thanks :) | 11:02 |
| tristan | juergbi, I'm in that limbo between a nap and sleep where you try to aim your wakeup time for a sensible hour haha | 11:03 |
| juergbi | :) | 11:07 |
| juergbi | probably best to discuss symlinks tomorrow ;) | 11:08 |
| tristan | yeah indeed, I couldnt wrap my head around it now | 11:09 |
| tristan | I do suspect losing that symlink argument, mostly I regret that alternative solutions might force the user to carefully place output files in paths which dont have symlinked directory components | 11:11 |
| tristan | but anyway, if I tried to reason about the edge cases now I won't be able to | 11:13 |
| juergbi | I don't expect it to be painful in practice, but I can't be sure I'm not missing a use case, of course | 11:15 |
| juergbi | also, actually placing output files in symlinked directories breaks strip-rules, afaict | 11:16 |
| juergbi | but let's discuss this tomorrow :) | 11:17 |
| tristan | At staging time we share some aspects of a package based system, but we are not... at the same time, we aren't an lfs style "build and install in this environment" thing either | 11:18 |
| tristan | seems there is a missing link | 11:18 |
| tristan | (like, rpm packages can say "this is a directory I provide", but we just have files) | 11:19 |
| juergbi | for package based systems, I think this would be an issue as well, at least if you allow the directory symlinks to ever change | 11:19 |
| juergbi | as then the manifest of the other package no longer matches the reality, so you can't uninstall it properly | 11:19 |
| tristan | Well, if a dependency provided the symlink causing an install path to a file to be valid but redirected, that symlink is reliably existing as you cannot delete the dependency without deleting the package which needs it | 11:21 |
| juergbi | but what if that package is upgraded? | 11:21 |
| tristan | of course we have an algo which explicitly ignores the subdirectories in directory walks | 11:21 |
| juergbi | and in the new version the symlink doesn't exist or points somewhere else? | 11:21 |
| juergbi | this is not an issue for buildstream itself, as we don't have the concept of uninstalling package in the core | 11:22 |
| tristan | That seems to be a breaking change indeed | 11:22 |
| juergbi | the skipping of non-empty directories is actually an issue and also something we need to discuss tomorrow | 11:25 |
| laurence | lachlan, jennis, I've added a load of issues to the benchmarks repo | 11:53 |
| laurence | mainly focused on what we need to do wrt the Debian-like project | 11:54 |
| laurence | I also and a new milestone to capture those - | 11:54 |
| laurence | https://gitlab.com/BuildStream/benchmarks/milestones/1 | 11:54 |
| laurence | pls review / amend tickets as desired | 11:54 |
| * lachlan is reviewing | 12:00 | |
| *** solid_black has quit IRC | 12:10 | |
| gitlab-br-bot | jjardon opened (was WIP) MR !1137 (jjardon/fedora_29->master: .gitlab-ci.yml: Test with current fedora release: 29) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1137 | 12:10 |
| gitlab-br-bot | cs-shadow closed issue #890 (RFE: Allow `bst show` to print list of dependencies) on buildstream https://gitlab.com/BuildStream/buildstream/issues/890 | 12:19 |
| gitlab-br-bot | cs-shadow merged MR !1121 (chandan/deps->master: _frontend: Allow printing dependencies using `bst show`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1121 | 12:20 |
| gitlab-br-bot | juergbi approved MR !1137 (jjardon/fedora_29->master: .gitlab-ci.yml: Test with current fedora release: 29) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1137 | 12:22 |
| gitlab-br-bot | juergbi approved MR !1144 (valentindavid/pull-chmod-bug->master: buildstream/_cas/cascache.py: Set 0644 rights to pulled files) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1144 | 12:22 |
| jonathanmaw | raoul, juergbi: hmm, I can't reproduce the WSL runner not skipping that test when running tests manually | 12:26 |
| juergbi | jonathanmaw: on the DESKTOP-7154KN6 runner? | 12:27 |
| jonathanmaw | yep | 12:27 |
| juergbi | interesting, no idea why this could happen sporadically | 12:28 |
| juergbi | I saw it here https://gitlab.com/BuildStream/buildstream/-/jobs/159550820 | 12:28 |
| *** raoul has quit IRC | 12:28 | |
| juergbi | jonathanmaw: oh, examples still use IS_LINUX/HAVE_BWRAP, not HAVE_SANDBOX | 12:29 |
| juergbi | maybe bwrap is installed on a WSL runner | 12:29 |
| jonathanmaw | ah, yes apparently | 12:30 |
| juergbi | not sure why your manual retest didn't trigger this issue, though | 12:30 |
| * jonathanmaw uninstalls that | 12:30 | |
| juergbi | build-uid.py also has a couple of missing HAVE_SANDBOX checks | 12:30 |
| juergbi | and cachedfail.py and sandbox-bwrap.py | 12:31 |
| juergbi | (they might need HAVE_SANDBOX as additional constraint instead of as the only constraint, as they may be bwrap-specific) | 12:31 |
| gitlab-br-bot | jjardon opened issue #906 (The logic to calculate the disk quota seems to be wrong) on buildstream https://gitlab.com/BuildStream/buildstream/issues/906 | 12:37 |
| jjardon | pipelines are taking ~140 minutes to finish; is this the expected time? | 12:39 |
| gitlab-br-bot | juergbi approved MR !1101 (jennis/refactor_artifact_log->master: Refactor artifact log command) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1101 | 12:40 |
| juergbi | 140 minutes sounds very long, especially without WSL | 12:42 |
| tpollard | I've had a single pipeline take over 2 hours too | 12:43 |
| juergbi | without WSL? | 12:43 |
| tpollard | yep, one of the fedora ones | 12:43 |
| juergbi | the fedora update-deps one sometimes takes quite some time | 12:44 |
| tpollard | yep, for instance https://gitlab.com/BuildStream/buildstream/-/jobs/158429643 | 12:45 |
| Kinnison | I have noticed it starts counting from when it tries to allocate a runner | 12:46 |
| juergbi | yes, timestamps in the log would be useful | 12:46 |
| Kinnison | so sometimes it sits there counting when it isn't actually doing anything yet | 12:46 |
| gitlab-br-bot | jjardon opened issue #907 (Pipelines are taking a lot of time to finish (~140 min)) on buildstream https://gitlab.com/BuildStream/buildstream/issues/907 | 12:47 |
| jjardon | yeah, It's a feature requested a lot: https://gitlab.com/gitlab-org/gitlab-runner/issues/2412 | 12:48 |
| juergbi | in tpollard's example, actual tox tests took 96 min, out of 136 min total runtime | 12:50 |
| juergbi | still longer than normal | 12:50 |
| jjardon | what would be the normal? It used to be much less but I think more tests were added since then | 12:51 |
| jjardon | the slowest test took ~5min, not sure that was faster before? | 12:51 |
| *** raoul has joined #buildstream | 12:54 | |
| juergbi | jjardon: we used to share the local artifact cache directory across integration tests and we no longer do this for better isolation and to allow parallelism | 13:02 |
| juergbi | not sure how big the impact of that was | 13:02 |
| raoul | Is there a sensible way to instantiate sources for tests? I've been trying to do this in order test source cache methods I'm working on but seem to end up in a mess of instantiating various required objects | 13:06 |
| juergbi | raoul: can't you cover this indirectly via CLI-based tests? | 13:06 |
| juergbi | that's currently the preferred style | 13:07 |
| raoul | Yeah, was just hoping to test the API before integrating it fully into the rest of buildstream | 13:07 |
| juergbi | ah ok, don't know out of the top of my head how much would be involved for this | 13:08 |
| raoul | Yeah seems to be a lot of faff, I've ended up trying to track down bits that aren't set up. Guess I'll just go for the full cli tests. | 13:10 |
| *** lachlan has quit IRC | 13:12 | |
| *** lachlan has joined #buildstream | 13:21 | |
| gitlab-br-bot | jjardon merged MR !1137 (jjardon/fedora_29->master: .gitlab-ci.yml: Test with current fedora release: 29) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1137 | 13:31 |
| *** nimish has joined #buildstream | 13:37 | |
| gitlab-br-bot | danielsilverstone-ct opened (was WIP) MR !1131 (danielsilverstone-ct/further-optimisations->master: Further optimisations) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1131 | 13:41 |
| *** aevri has joined #buildstream | 14:11 | |
| *** lachlan has quit IRC | 14:41 | |
| *** lachlan has joined #buildstream | 14:53 | |
| gitlab-br-bot | cs-shadow opened (was WIP) MR !998 (chandan/junction-dependency-format->master: loader: Allow dependencies to use ":" to refer to junctioned elements) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/998 | 15:01 |
| gitlab-br-bot | tpollard opened issue #908 (Create Artifact abstraction class) on buildstream https://gitlab.com/BuildStream/buildstream/issues/908 | 15:07 |
| *** lachlan has quit IRC | 15:19 | |
| *** WSalmon__ has quit IRC | 15:20 | |
| *** lachlan has joined #buildstream | 15:23 | |
| *** mohan43u has quit IRC | 15:28 | |
| *** mohan43u has joined #buildstream | 15:33 | |
| *** lachlan has quit IRC | 15:34 | |
| gitlab-br-bot | LaurenceUrhegyi opened issue #909 (Artifact As A Proto) on buildstream https://gitlab.com/BuildStream/buildstream/issues/909 | 15:46 |
| laurence | raoul, tpollard, Kinnison, juergbi, anyone else who's interested in AaaP - please review the above ticket, trying to capture all the tasks | 15:46 |
| laurence | feel free to amend as required | 15:46 |
| Kinnison | "the above ticket" ? | 15:48 |
| laurence | yeah, the gitlab bot posted it above my comment | 15:48 |
| laurence | <gitlab-br-bot> LaurenceUrhegyi opened issue #909 (Artifact As A Proto) on buildstream https://gitlab.com/BuildStream/buildstream/issues/909 | 15:48 |
| Kinnison | aah I have the bot on ignore so that I don't ragequit the channel | 15:50 |
| laurence | ragequit, hahah | 15:54 |
| *** lachlan has joined #buildstream | 15:55 | |
| *** lachlan has quit IRC | 16:03 | |
| *** lachlan has joined #buildstream | 16:11 | |
| laurence | hhhhhmm, wonder if anyone can respond to Emerson on this ticket? https://gitlab.com/BuildStream/buildstream/issues/900 | 16:13 |
| laurence | cryptographic authentication... | 16:14 |
| gitlab-br-bot | BenjaminSchubert merged MR !1131 (danielsilverstone-ct/further-optimisations->master: Further optimisations) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1131 | 16:14 |
| *** lachlan has quit IRC | 16:20 | |
| *** lachlan has joined #buildstream | 16:31 | |
| *** lantw44 has quit IRC | 16:50 | |
| *** lantw44 has joined #buildstream | 17:03 | |
| *** tristan has quit IRC | 17:20 | |
| tlater[m] | <_gimpnet_lau "hhhhhmm, wonder if anyone can re"> laurence: That looks like a tough one | 17:33 |
| * tlater[m] is curious where it will go | 17:33 | |
| laurence | indeed, tlater[m] | 17:34 |
| gitlab-br-bot | valentindavid opened MR !1146 (valentindavid/local-cache-exec-leak->master: Deduplicate files in local cache with or without exec rights) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1146 | 17:47 |
| valentind | juergbi, I have made !1146 to solve the issue with exec rights. Was there a ticket for that? | 17:48 |
| juergbi | I'm not aware of one | 17:48 |
| valentind | OK, I will create one then. | 17:48 |
| juergbi | hm, it doesn't make me very happy | 17:52 |
| valentind | juergbi, the issue or the fix? | 17:52 |
| gitlab-br-bot | valentindavid opened issue #910 (Execution rights on an object can corrupt local cache) on buildstream https://gitlab.com/BuildStream/buildstream/issues/910 | 17:55 |
| juergbi | the fix. it makes the code less simple/elegant, but maybe there is no better way | 17:55 |
| valentind | juergbi, yes. For sure. I think the idea of having executable rights stored on the directory was not really the right way to go. | 17:57 |
| valentind | Also I wonder, what if we want to simulate links between files when using fuse? I think we would have needed inodes in the cache. Maybe there should be some refactoring to do in the protocol. | 17:59 |
| gitlab-br-bot | jonathanmaw closed issue #895 (Buildstream needlessly stages junctions into tmpdir) on buildstream https://gitlab.com/BuildStream/buildstream/issues/895 | 17:59 |
| gitlab-br-bot | jonathanmaw merged MR !1134 (jonathan/junction-no-tmpdir->master: Stage junctions into .bst instead of a tmpdir) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1134 | 17:59 |
| juergbi | you mean hardlinks? yes, we have a ticket open about this. this would require protocol extension | 18:00 |
| valentind | yes. | 18:00 |
| valentind | And will we store the access rights along with the file in this extension? | 18:01 |
| juergbi | one aspect that bugs me is that it's not necessary on modern systems (when we use buildbox-fuse) | 18:01 |
| juergbi | (the exec thing, not hardlinks) | 18:01 |
| juergbi | and I generally prefer not to work around system limitations all over the code base | 18:02 |
| juergbi | hardlinks: there is no design/proposal yet for this extension | 18:02 |
| valentind | juergbi, I would be fine removing the local cache completely and always go through buildbox-fuse. But if we keep it, we should fix it. | 18:03 |
| juergbi | we have to support systems that don't support FUSE, unfortunately | 18:03 |
| *** jonathanmaw has quit IRC | 18:04 | |
| valentind | juergbi, I think we can simplify the code if we go for a different protocol for storing cache. If every file can have some metadata, then we can make simpler code. | 18:05 |
| juergbi | possibly, but I don't see such a fundamental protocol change happening upstream anytime soon | 18:06 |
| juergbi | and we want to be compatible, as far as possible | 18:06 |
| valentind | juergbi, I think it is only for storing locally that we would need the extension. We could still support an older remote cache. | 18:08 |
| juergbi | you want to rewrite things for every transfer? sounds potentially expensive | 18:09 |
| valentind | Maybe. | 18:09 |
| juergbi | valentind: regarding the MR, couldn't we reduce the impact by having our own Digest class that includes the proto Digest + the executable bit? | 18:10 |
| juergbi | so we don't need separate executable lists and sets etc. | 18:10 |
| valentind | juergbi, sure. | 18:10 |
| valentind | But we still need to populate that bit when pulling. | 18:11 |
| juergbi | yes, sure, but I would expect this to be much cleaner | 18:12 |
| juergbi | but maybe I'm missing something | 18:12 |
| valentind | I think we send the digest object to the server. | 18:12 |
| valentind | So that would be a change in protocol. | 18:12 |
| valentind | Can we add a field in the message without breaking backward compatibility? | 18:12 |
| juergbi | we would only send the Digest proto part, of course | 18:12 |
| valentind | And would the server answer back with the right bit? | 18:13 |
| juergbi | I wasn't proposing changing the protocol | 18:13 |
| valentind | OK, I have to look at that again. Because I thought that was not possible. | 18:13 |
| valentind | So wrap the _CASBatchRead. | 18:14 |
| valentind | I see. I will try that. | 18:15 |
| juergbi | ah, right, that's maybe not straight forward | 18:15 |
| juergbi | as we don't currently track the requested digests | 18:16 |
| juergbi | so maybe this just shifts things around but doesn't simplify it | 18:17 |
| juergbi | have to think about it some more | 18:17 |
| valentind | juergbi, I still simplifies the code to hide it in CASBatchRead. | 18:19 |
| valentind | CASBatchRead is relatively simple. | 18:19 |
| valentind | juergbi, like that: https://gitlab.com/BuildStream/buildstream/commit/da80724e93acf662fb1b58b9f34918b91911437a | 18:27 |
| valentind | It saves 13 lines of patch. | 18:30 |
| valentind | Not that big difference. | 18:30 |
| *** raoul has quit IRC | 18:35 | |
| juergbi | ok, but we could still have this digest helper class to avoid requiring is_exec parameters everywhere | 18:38 |
| valentind | oh, I might have not understood all. | 18:40 |
| valentind | Yes maybe I can do better. | 18:40 |
| *** lachlan has quit IRC | 18:41 | |
| valentind | This is interesting. If we have multiple times the same file in a directory, we will make a batch request with multiple times the digest, and get multiple times the content. | 18:45 |
| juergbi | deduplication in CASBatchRead.add() could make sense | 18:54 |
| gitlab-br-bot | valentindavid merged MR !1144 (valentindavid/pull-chmod-bug->master: buildstream/_cas/cascache.py: Set 0644 rights to pulled files) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1144 | 19:13 |
| *** adds68 has quit IRC | 20:13 | |
| *** ikerperez has quit IRC | 20:13 | |
| *** jennis has quit IRC | 20:13 | |
| *** mablanch has quit IRC | 20:17 | |
| *** mablanch has joined #buildstream | 20:18 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!