| *** tristan <tristan!tristan@223.62.219.133> has joined #buildstream | 01:39 | |
| *** ChanServ sets mode: +o tristan | 01:39 | |
| *** tristan <tristan!tristan@223.62.219.133> has quit IRC | 01:54 | |
| *** tristan <tristan!tristan@223.62.219.133> has joined #buildstream | 01:54 | |
| *** ChanServ sets mode: +o tristan | 01:54 | |
| *** tristan <tristan!tristan@223.62.219.133> has quit IRC | 02:47 | |
| *** tristan <tristan!tristan@223.62.219.216> has joined #buildstream | 03:10 | |
| *** ChanServ sets mode: +o tristan | 03:10 | |
| *** tristan <tristan!tristan@223.62.219.216> has quit IRC | 03:19 | |
| *** tristan <tristan!tristan@223.62.219.216> has joined #buildstream | 03:24 | |
| *** ChanServ sets mode: +o tristan | 03:24 | |
| *** tristan <tristan!tristan@223.62.219.216> has quit IRC | 03:30 | |
| *** tristan <tristan!tristan@223.62.219.216> has joined #buildstream | 05:36 | |
| *** ChanServ sets mode: +o tristan | 05:36 | |
| juergbi | nanonyme: FUSE capture optimization requires FUSE xattr to work but that's supported in the kernel for many years, as far as I know. I'm not aware of it being possible to be disabled. except via a seccomp filter but that would be very odd | 07:11 |
|---|---|---|
| *** tristan <tristan!tristan@223.62.219.216> has quit IRC | 08:08 | |
| nanonyme | Not really my area of expertise | 08:25 |
| *** tristan <tristan!tristan@223.62.203.218> has joined #buildstream | 09:41 | |
| *** ChanServ sets mode: +o tristan | 09:41 | |
| *** tristan <tristan!tristan@223.62.203.218> has quit IRC | 10:07 | |
| *** tpollard <tpollard!tompollard@167.98.27.226> has joined #buildstream | 10:14 | |
| *** CTtpollard <CTtpollard!tompollard@167.98.27.226> has joined #buildstream | 10:29 | |
| *** tpollard <tpollard!tompollard@167.98.27.226> has quit IRC | 10:30 | |
| *** CTtpollard <CTtpollard!tompollard@167.98.27.226> has quit IRC | 10:37 | |
| *** CTtpollard <CTtpollard!tompollard@167.98.27.226> has joined #buildstream | 10:37 | |
| *** CTtpollard <CTtpollard!tompollard@167.98.27.226> has quit IRC | 10:57 | |
| *** tristan <tristan!tristan@223.62.172.42> has joined #buildstream | 12:55 | |
| *** ChanServ sets mode: +o tristan | 12:55 | |
| *** tristan <tristan!tristan@223.62.172.42> has quit IRC | 13:37 | |
| *** tristan <tristan!tristan@223.62.172.42> has joined #buildstream | 13:37 | |
| *** ChanServ sets mode: +o tristan | 13:38 | |
| *** tristan <tristan!tristan@223.62.172.42> has quit IRC | 16:33 | |
| *** tristan <tristan!tristan@223.62.172.42> has joined #buildstream | 16:34 | |
| *** ChanServ sets mode: +o tristan | 16:34 | |
| *** tristan <tristan!tristan@223.62.172.42> has quit IRC | 17:06 | |
| nanonyme | juergbi: could I somehow with a simple command validate if FUSE xattr doesn't work? Would implication of it be that files would be missing sha256 xattr in sandbox? | 19:11 |
| nanonyme | Would it silently fallback to hardlinks if fuse was not available at all? | 19:16 |
| juergbi | nanonyme: checking the sha256 xattr in the sandbox (for a staged, unmodified file) would be sensible for validation, yes | 19:20 |
| juergbi | if FUSE isn't available, it would fallback to full file copies (hardlinks are only used if casd runs as a different user) | 19:21 |
| nanonyme | juergbi: was there some simple command line I can run or do I need to write some Python command? | 19:45 |
| juergbi | nanonyme: getfattr --name=user.checksum.sha256 FILE | 19:46 |
| juergbi | if getfattr is available | 19:46 |
| juergbi | it's part of the attr package | 19:46 |
| nanonyme | Looks like attr.bst should be in bootstrap-import.bst | 19:46 |
| nanonyme | So it should be enough to bst shell bootstrap-import.bst -- getfattr --name=user.checksum.sha256 /usr/bin/bash | 19:48 |
| nanonyme | juergbi: right, I get user.checksum.sha256="961064b5726d4bc1692f1c61ad1a3ebb44f3d8e4151f3443175b6714fc543156" so that's sufficient proof that the problem is not missing xattr | 19:50 |
| nanonyme | I am next trying to disable storage service to see if it does anything | 20:01 |
| nanonyme | It should not since all the artifacts are already local at this point | 20:01 |
| nanonyme | But who knows | 20:03 |
| nanonyme | juergbi: to be honest, we don't actually need storage service. It would be more useful to have something like `bst build --cached` that would not pull cached things unless they are build dependencies | 20:06 |
| nanonyme | Or rather, that would fulfill the requirements we are currently fulfilling with a storage service | 20:08 |
| nanonyme | doras: FYI looks like your hunch may have been correct | 20:27 |
| nanonyme | Or is this a red herring. aarch64 flatpak repo was now 3 min 34 seconds. But I don't yet have number on x86_64 although it seems considerable slower than aarch64 (which is probably expected) | 20:32 |
| nanonyme | Or maybe aarch64 was faster all along? | 20:52 |
| nanonyme | We need to test! :D | 20:52 |
| nanonyme | Yeah, okay, I'm pretty sure it does absolutely nothing for x86_64 flatpak_repo performance | 21:30 |
| nanonyme | Mmm, looks like there's nested batching happening with flatpak_repo | 21:57 |
| nanonyme | This is entirely not what script itself dodes | 22:03 |
| nanonyme | Does even | 22:03 |
| nanonyme | Even more curious is why aarch64 was fast once but it no longer reproduces! | 22:34 |
| nanonyme | juergbi: when we set root read-only, does it affect only root or also the laid out flatpak images? | 22:46 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!