| *** mohan43u has quit IRC | 02:16 | |
| *** mohan43u has joined #buildstream | 03:17 | |
| *** narispo has joined #buildstream | 03:34 | |
| *** phoenix has joined #buildstream | 06:06 | |
| *** phoenix has quit IRC | 06:38 | |
| gitlab-br-bot | marge-bot123 merged MR !1642 (juerg/fetch-tree->master: Reimplement contains_directory() with FetchTree()) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1642 | 08:20 |
|---|---|---|
| gitlab-br-bot | juergbi closed issue #1020 (Invalid "Ignoring redundant source references" warnings for git sources) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1020 | 08:30 |
| *** traveltissues has joined #buildstream | 08:54 | |
| tpollard | benschubert: :( indeed | 09:24 |
| benschubert | tpollard: I would believe it's only because that is the time it took to print everything. I didn't get the status bar at all of the run since my display was just trying to catch up | 09:25 |
| benschubert | I'll try with a different project to see if I can see a difference | 09:26 |
| tpollard | hmm, the status bar should show with that branch and the base-files.bst, does for me at least | 09:27 |
| *** rdale has joined #buildstream | 09:29 | |
| tpollard | although it's still very flickery | 09:29 |
| benschubert | yep, my display isn't even able to cope with that :) | 09:30 |
| *** jonathanmaw has joined #buildstream | 09:40 | |
| *** santi has joined #buildstream | 09:43 | |
| tpollard | I'm also surprised that the user/system time hadn't increased more | 09:53 |
| tpollard | does the FetchTree() MR merging require the new version of casd? | 10:02 |
| *** tiagogomes has joined #buildstream | 10:03 | |
| *** bochecha has joined #buildstream | 10:09 | |
| tpollard | that answer to that is yes | 10:17 |
| *** lachlan has joined #buildstream | 10:33 | |
| juergbi | tpollard: yes. but it reports a suitable human-readable error otherwise, right? | 10:37 |
| tpollard | juergbi: yep, it did :) | 10:38 |
| tpollard | I was just running tests, so didn't see straight away | 10:38 |
| juergbi | yes, it's still a bit hidden in the output but should at least not throw an unhandled exception or similar | 10:38 |
| gitlab-br-bot | marge-bot123 merged MR !1673 (aevri/testutils_artifactshare->master: tests/artifactshare: safer cleanup_on_sigterm use) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1673 | 10:42 |
| *** juanalday has joined #buildstream | 10:59 | |
| *** akvilebirgelyte has quit IRC | 11:30 | |
| *** akvilebirgelyte has joined #buildstream | 11:30 | |
| benschubert | tpollard: my 'faster' terminal was even slower... -_-' | 11:38 |
| tpollard | benschubert: yeh... we're going to rerun the times here to see what's seemingly happened since they were last run | 11:46 |
| benschubert | tpollard: ok, let me know if/how I can help | 11:47 |
| *** lachlan has quit IRC | 12:01 | |
| tpollard | benschubert: will do, I think at this point general code review to see if there's anything glaringly obvious with the implementation | 12:03 |
| benschubert | ok! | 12:04 |
| gitlab-br-bot | traveltissues opened (was WIP) MR !1686 (traveltissues/1182->master: Remove `commit`ting sources inside `Source()._generate_key`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1686 | 12:04 |
| *** juanalday has quit IRC | 12:05 | |
| gitlab-br-bot | BenjaminSchubert approved MR !1686 (traveltissues/1182->master: Remove `commit`ting sources inside `Source()._generate_key`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1686 | 12:09 |
| gitlab-br-bot | BenjaminSchubert opened MR !1687 (bschubert/better-reporting-on-userconfig->master: _context.py: Improve reporting of incorrect user config) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1687 | 12:13 |
| gitlab-br-bot | cs-shadow approved MR !1687 (bschubert/better-reporting-on-userconfig->master: _context.py: Improve reporting of incorrect user config) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1687 | 12:16 |
| benschubert | tpollard: are you looking into !1185 ? | 12:16 |
| gitlab-br-bot | MR !1185: utils.py: safe_link(): Unlink only if target already exists https://gitlab.com/BuildStream/buildstream/merge_requests/1185 | 12:16 |
| gitlab-br-bot | aevri closed issue #1154 (Independent testing of Windows Experimental branch) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1154 | 12:16 |
| benschubert | sorry meant #1185 | 12:16 |
| gitlab-br-bot | Issue #1185: bst build does not exit gracefully on a second CTRL-C https://gitlab.com/BuildStream/buildstream/issues/1185 | 12:16 |
| benschubert | juergbi: do you need anything more on my end for #1126? | 12:17 |
| gitlab-br-bot | Issue #1126: Cache resolution is slow https://gitlab.com/BuildStream/buildstream/issues/1126 | 12:17 |
| juergbi | benschubert: no, not right now, thanks. !1642 is merged but we should probably keep the issue open until batching is implemented as well | 12:19 |
| gitlab-br-bot | MR !1642: Reimplement contains_directory() with FetchTree() https://gitlab.com/BuildStream/buildstream/merge_requests/1642 | 12:19 |
| benschubert | awesome thanks! | 12:20 |
| tpollard | benschubert: not actively right now | 12:26 |
| benschubert | ok, were you planning to, or do you want me to have a look ? | 12:26 |
| tpollard | I'm not sure, I didn't want to overlap with the casd process manager work | 12:26 |
| benschubert | I think I have a fix without having to conflict :) | 12:29 |
| tpollard | awesome :) | 12:32 |
| gitlab-br-bot | traveltissues closed issue #1073 (Cache Key Dictionary Changes) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1073 | 12:56 |
| *** lachlan has joined #buildstream | 13:06 | |
| *** juanalday has joined #buildstream | 13:28 | |
| tpollard | gitlab can't handle showing me that Black diff xD | 13:30 |
| traveltissues | tpollard, https://gitlab.com/snippets/1910431 | 13:30 |
| tpollard | traveltissues: tyvm | 13:31 |
| benschubert | traveltissues: interesting timings, so different from mine Oo | 13:31 |
| tpollard | indeed, ~30% difference | 13:31 |
| traveltissues | what were your results benschubert | 13:32 |
| benschubert | no difference between master and this branch | 13:32 |
| benschubert | and 26-28m in total | 13:33 |
| tlater[m] | juergbi: When we check out an element, we stage the artifact in a directory - this seems to be handled by casd | 13:42 |
| tlater[m] | Does the checkout directory also need to be owned by casd? | 13:43 |
| tlater[m] | Or will we need some form of api to send files over the socket? | 13:43 |
| tlater[m] | I suppose the directory should be writeable with umask 002 | 13:43 |
| tlater[m] | Hrmm | 13:43 |
| benschubert | I'm getting a connection refused trying to connect to freedesktop-sdk-cache.codethink.co.uk:11001 for the freedesktop cache. Is that expected? Can anyone else reach it? | 13:59 |
| coldtom | adds68, valentind ^ | 14:00 |
| tlater[m] | GAH THE TEST SUITE CREATES TEMPORARY DIRECTORIES WITH G-RWX | 14:06 |
| valentind | Yes I know. | 14:08 |
| valentind | The cache servers were configured to the wrong path. | 14:08 |
| valentind | So I had to restart them. | 14:08 |
| valentind | It works now. | 14:08 |
| valentind | benschubert, do you still have the issue? | 14:08 |
| *** santi has quit IRC | 14:10 | |
| adds68 | seems there were still errors when i just checked | 14:11 |
| *** santi has joined #buildstream | 14:11 | |
| gitlab-br-bot | marge-bot123 merged MR !1687 (bschubert/better-reporting-on-userconfig->master: _context.py: Improve reporting of incorrect user config) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1687 | 14:12 |
| valentind | adds68, When? | 14:12 |
| adds68 | 2 minutes ago | 14:12 |
| adds68 | on the cache-serve service | 14:12 |
| valentind | Maybe it is your DNS cache then. | 14:13 |
| valentind | AH no you are right. | 14:13 |
| valentind | Let me fix it. | 14:13 |
| adds68 | no the actual server | 14:13 |
| valentind | Strange it sometimes work. | 14:15 |
| valentind | Sometimes it does not | 14:15 |
| adds68 | i will sort this infra stuff out at LAS valentind :D | 14:15 |
| valentind | adds68, The path are still wrong for .service files. | 14:16 |
| valentind | This is what I had to fix. | 14:16 |
| adds68 | I mean like get my fully re-factored branch sorted and merged or maybe even rewrite it all again haha | 14:16 |
| valentind | adds68, I was thinking of making an image of freedesktop sdk with cloud init. | 14:17 |
| valentind | So we could just deploy freedesktop sdk on all the servers. | 14:18 |
| adds68 | valentind, i have that already, it just can't be merged because of the openssl issue | 14:21 |
| adds68 | but yes that would be the idea | 14:22 |
| valentind | Where is that? | 14:22 |
| adds68 | valentind, i had a branch doing all this stuff here: https://gitlab.com/freedesktop-sdk/infrastructure/freedesktop-sdk-docker-images/merge_requests/59 | 14:23 |
| valentind | Ah you mean running the service in docker with freedesktop sdk. | 14:23 |
| valentind | No I mean, just run the whole server on Freedesktop SDK with a kernel and cloud init. | 14:24 |
| valentind | Ditch fedora and ansible. | 14:24 |
| tpollard | that sounds scary | 14:24 |
| valentind | Why? | 14:24 |
| adds68 | valentind, yes that also makes sense | 14:25 |
| adds68 | valentind, we could use Packer | 14:25 |
| adds68 | lets talk at LAS :) | 14:25 |
| valentind | What is packer? | 14:25 |
| adds68 | valentind https://www.packer.io/ | 14:25 |
| coldtom | is it possible for a plugin to stage different sources in different locations? | 14:35 |
| coldtom | s/plugin/element plugin/ | 14:35 |
| juergbi | tlater[m]: the actual checkout step is handled by buildstream code, afaict. in the normal case it should copy files from CAS or create a tarball (both requiring read-only access, which is fine) | 14:38 |
| juergbi | the hardlinking option might not work, though | 14:38 |
| juergbi | at least linux doesn't allow this by default anymore (fs.protected_hardlinks = 0), afaik | 14:40 |
| tlater[m] | juergbi: Are you sure? It looks like the buildbox-casd user is trying to copy files into a directory not owned by it because the test suite sets u+rwx,go-rwx on our staging directories | 14:40 |
| tlater[m] | s/staging/checkout/ | 14:40 |
| tlater[m] | It happens in `_import_files_from_cas` | 14:41 |
| tlater[m] | In `_filebaseddirectory` | 14:41 |
| tpollard | coldtom: erm, I think you could right one that does? | 14:42 |
| tpollard | *write | 14:42 |
| juergbi | tlater[m]: if I'm reading the code correctly, I think this is something that is very suboptimal right now | 14:42 |
| juergbi | we first create a checkout from casd and then copy or hardlink that checkout in bst to the final location | 14:43 |
| coldtom | tpollard: afaict all sources are staged by Element.stage_sources(), which handles them all at once | 14:43 |
| juergbi | tlater[m]: the first step should be replaced by using a virtual directory | 14:43 |
| juergbi | it might actually work correctly with the buildbox-run sandboxing backend as that always uses casbaseddirectory | 14:44 |
| tpollard | coldtom: yeh, afaik it will use buildelements abstract method for it unless overridden | 14:44 |
| tlater[m] | juergbi: I think that already is a virtual directory? | 14:45 |
| coldtom | tpollard: even the internals seem to do all at once though :/ | 14:45 |
| juergbi | tlater[m]: not a casbaseddirectory, though, is it? | 14:45 |
| juergbi | otherwise you wouldn't trigger filebaseddirectory code | 14:46 |
| tlater[m] | Yeah | 14:46 |
| tpollard | coldtom: ah wait, I read that as you wanting to stage them in a custom path, not multiple locations | 14:46 |
| tlater[m] | juergbi: I suppose we shouldn't be using bwrap sandboxing with this configuration... | 14:47 |
| tlater[m] | But that feels like taping over the problem | 14:47 |
| tlater[m] | Can we always use a CAS based directory? | 14:47 |
| juergbi | ah, the integration commands are the issue | 14:48 |
| juergbi | we actually need a sandbox, not just a directory | 14:48 |
| juergbi | tlater[m]: _import_files_from_cas is all bst python code, though. it doesn't call into casd, does it? | 14:50 |
| juergbi | I'd still expect this to fail due to attempting to hardlink files owned by buildbox-casd, but that's not what you saw | 14:51 |
| tlater[m] | juergbi: Ah, no, that may be what I saw | 14:52 |
| tlater[m] | Depends on `actionfunc` | 14:52 |
| juergbi | tlater[m]: yes, so to unblock you, I'd simply always set can_link to False in FileBasedDirectory.import_files for now() | 14:52 |
| juergbi | I can take a look later | 14:52 |
| tlater[m] | Fair enough | 14:53 |
| juergbi | I think it'll be a non-issue for buildbox-run, and long term that's the only thing that matters | 14:53 |
| juergbi | we don't really need to support non-buildbox sandboxing with two uids | 14:53 |
| juergbi | but maybe it makes still sense to fix this up | 14:53 |
| gitlab-br-bot | marge-bot123 closed issue #1182 (Follow-up from "WIP: extend source api and remove private use from workspace plugin") on buildstream https://gitlab.com/BuildStream/buildstream/issues/1182 | 14:53 |
| gitlab-br-bot | marge-bot123 merged MR !1686 (traveltissues/1182->master: Remove `commit`ting sources inside `Source()._generate_key`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1686 | 14:53 |
| *** jonathanmaw has quit IRC | 15:04 | |
| *** jonathanmaw has joined #buildstream | 15:06 | |
| *** lachlan has quit IRC | 15:25 | |
| *** lachlan has joined #buildstream | 15:40 | |
| benschubert | valentind: still same problem :/ | 15:47 |
| *** lachlan has quit IRC | 15:48 | |
| *** lachlan has joined #buildstream | 15:49 | |
| gitlab-br-bot | BenjaminSchubert closed issue #996 (Cache quota shouldn't be computed until we know we need to write to the cache) on buildstream https://gitlab.com/BuildStream/buildstream/issues/996 | 15:50 |
| *** santi has quit IRC | 15:50 | |
| tlater[m] | juergbi: It looks like we're calling os.umask in a couple of places in the codebase | 15:54 |
| tlater[m] | As far as I've heard that's not thread-specific, but set for the entire process | 15:54 |
| tlater[m] | Surely this just means that we have wildly changing umasks as BuildStream changes between the user's and 022? | 15:55 |
| juergbi | yes, it's per process. we don't really have multiple threads, though (except for gRPC) | 15:56 |
| juergbi | is this used around the point where we create the cas directory that needs to be writable by casd? | 15:58 |
| tlater[m] | juergbi: I think it messes with workspaces | 16:01 |
| tlater[m] | Since workspaces will be staged 022 | 16:01 |
| tlater[m] | Which results in us being unable to import them with correct permissions | 16:02 |
| * tlater[m] changed changing that to 002, but the error didn't change, and neither did the permissions, so continues digging to figure out why workspaces end up with 022 | 16:02 | |
| juergbi | tlater[m]: import into CAS only requires read access by casd | 16:02 |
| juergbi | so 022 should not be an issue | 16:03 |
| tlater[m] | It should, right? | 16:03 |
| juergbi | should not | 16:03 |
| juergbi | 022 disallows write access by other users | 16:03 |
| juergbi | but casd won't write into workspace directory | 16:03 |
| tlater[m] | juergbi: https://hastebin.com/uyaruwagon.sql | 16:04 |
| tlater[m] | It should not be an issue, yeah | 16:04 |
| tlater[m] | But then I run into that | 16:04 |
| juergbi | this means it doesn't have read or search access | 16:04 |
| juergbi | unless we're somewhere using very strict umask 077, umask shouldn't be an issue with regards to reads | 16:05 |
| tlater[m] | Hm | 16:05 |
| tlater[m] | It certainly does have both read and search access | 16:05 |
| tlater[m] | The only difference I can see is that the permissions on those files are 755/644 instead of what they are otherwise | 16:06 |
| juergbi | tlater[m]: have you checked the permissions of all parent directories? | 16:10 |
| tlater[m] | juergbi: Yes | 16:11 |
| tlater[m] | juergbi: Hm, going through with -a, there's a file called .bstproject.yaml in there which isn't g+r | 16:14 |
| tlater[m] | Maybe the error message isn't detailed enough? | 16:14 |
| juergbi | ah, that might be it | 16:14 |
| juergbi | yes, we should really pinpoint the problematic directory/file | 16:14 |
| tpollard | I'd forgotten about that file | 16:15 |
| * tlater[m] doesn't even remember what it does | 16:16 | |
| tlater[m] | Seems to tell us what project a workspace belongs to or somesuch? | 16:17 |
| tlater[m] | I wonder why this has such tight permissions... | 16:17 |
| tpollard | tlater[m]: yes, and for supporting multiple projects opening the same workspace, but I'm not sure if that ever landed | 16:20 |
| cs-shadow | tlater[m]: that also allows us to run `bst` commands from the workspace directory | 16:21 |
| tlater[m] | Ah, right! | 16:22 |
| tlater[m] | cs-shadow: Do you have any idea why its permissions are 600 though? | 16:22 |
| * tlater[m] can't find a chmod on it, nor think of a security concern | 16:22 | |
| cs-shadow | i don't think it needs to be 600 | 16:23 |
| cs-shadow | opening a workspace now, I can confirm that it definitely is currently 600 when using BuildStream master | 16:24 |
| tlater[m] | Ta, at least it's nothing strange with my environment | 16:25 |
| tpollard | is it the yaml dumper that's writing it as 600? | 16:26 |
| juergbi | tlater[m]: save_file_atomic uses mkstemp | 16:26 |
| juergbi | and then rename | 16:26 |
| tlater[m] | Hm, I suppose I wouldn't have noticed yet | 16:26 |
| tlater[m] | Oh, that'd do it | 16:26 |
| tlater[m] | Well, I suppose it's easy enough to chmod it after it's written, then, since we don't need to change the permissoin elsewhere | 16:27 |
| tlater[m] | Ta juergbi/tpollard/cs-shadow :) | 16:27 |
| juergbi | benschubert: #1175 is a race condition between buildstream sending SIGTERM and buildbox-casd setting a hanlder for SIGTERM, right? | 16:34 |
| gitlab-br-bot | Issue #1175: buildobx-casd doesn't exit cleanly after some BuildStream errors https://gitlab.com/BuildStream/buildstream/issues/1175 | 16:34 |
| benschubert | juergbi: It would be curious since we wait for capabilities no? But yes that could be | 16:35 |
| juergbi | only if we actually communicate with casd | 16:35 |
| benschubert | oh good point | 16:35 |
| juergbi | we could simply ignore -15, consider this as exit without error | 16:35 |
| benschubert | I'm not 100% confident about that :/ but we could | 16:36 |
| benschubert | otherwie not start casd in that case? | 16:36 |
| benschubert | Because if we're not going to access it, why are we starting it? | 16:36 |
| juergbi | well, it's nice to start casd early so it can already initialize in the background | 16:36 |
| juergbi | e.g., while buildstream loads .bst files | 16:36 |
| benschubert | good point | 16:36 |
| benschubert | but that's becasue we know we might use it | 16:37 |
| benschubert | for 'init' there is literally no way we would use it :) | 16:37 |
| tpollard | hmm | 16:37 |
| juergbi | yes but except for some error cases we actually need it almost always nowadays, afaict | 16:37 |
| benschubert | Otherwise would it be possible to add the handler in casd more often? | 16:37 |
| juergbi | yes, for init, true | 16:37 |
| benschubert | - more often + earlier | 16:37 |
| juergbi | https://gitlab.com/BuildGrid/buildbox/buildbox-casd/blob/master/buildboxcasd/buildboxcasd.m.cpp#L145 | 16:38 |
| juergbi | can't get much earlier | 16:38 |
| juergbi | it might be possible to fix the race condition by blocking the signal in bst | 16:39 |
| benschubert | but then how do we even manage that in python? starting casd would not be that quick | 16:39 |
| juergbi | not sure, system is busy or dynamic loader takes a while? | 16:40 |
| benschubert | I'll investigate and ensure that this is the case. If that is, I'll just ignore -15. Otherwise well, we'll see | 16:40 |
| tpollard | we could definitely start the process sooner in bst I think | 16:41 |
| benschubert | that's not an absolute fix :( | 16:43 |
| tpollard | in the initialised context manager, depending on what bst is going to be doing | 16:43 |
| juergbi | I think we start it fairly early already | 16:44 |
| juergbi | the main delay is loading all .py files / import handling, iirc | 16:44 |
| tlater[m] | Apparently bzr makes its entire version control directory 700 :( | 16:51 |
| * tlater[m] blanket skips bzr tests for now | 16:51 | |
| *** santi has joined #buildstream | 16:57 | |
| *** traveltissues has quit IRC | 17:06 | |
| *** phildawson_ has joined #buildstream | 17:10 | |
| *** phil has quit IRC | 17:11 | |
| *** narispo has quit IRC | 17:18 | |
| valentind | benschubert, connection refused? Could tell me the IP it resolved to for you? | 17:23 |
| *** narispo has joined #buildstream | 17:29 | |
| *** tiagogomes has quit IRC | 17:30 | |
| *** juanalday has quit IRC | 17:35 | |
| *** santi has quit IRC | 17:58 | |
| *** jonathanmaw has quit IRC | 18:03 | |
| benschubert | valentind: sorry, meeting. I get 142.93.136.121:11001 | 18:08 |
| benschubert | (11001 is the port) | 18:09 |
| valentind | benschubert, that should be right. | 18:17 |
| valentind | Nothing weird in the journal. | 18:18 |
| benschubert | valentind: mmh might be a proxy issue I'll look at home :( | 18:19 |
| valentind | Ah right. | 18:19 |
| valentind | That sounds like it. | 18:19 |
| valentind | Because it is a bit special protocol on top of https. | 18:19 |
| valentind | I see actually 3 errors with openssl. | 18:20 |
| valentind | Ah no that was me. | 18:20 |
| *** phildawson_ has quit IRC | 18:21 | |
| *** lachlan has quit IRC | 18:24 | |
| *** bochecha has quit IRC | 21:34 | |
| *** bochecha has joined #buildstream | 21:35 | |
| *** rdale has quit IRC | 23:16 | |
| *** bochecha has quit IRC | 23:36 | |
| *** bochecha has joined #buildstream | 23:36 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!