| 6 Jun 2024 |
atemu12 | Because it needs you to be a trusted user | 22:24:10 |
erahhal | Still confused. Looking at the nix.conf options, I don't see something that disables sandboxing for an individual path. Or are you saying to completely disable sandboxing? | 22:28:52 |
jaen | Try this one? https://nix.dev/manual/nix/2.22/command-ref/conf-file.html#conf-sandbox-paths I've been using --extra-sandbox-paths for now so not 100% it's this, but looks like it | 22:34:55 |
erahhal | ah, the sandbox-paths mount them into the sandbox. I was thinking the opposite, i.e. that the daemon would have access outside of the sandbox for those paths | 22:36:06 |
erahhal | let me try that | 22:36:09 |
erahhal | thanks | 22:36:12 |
erahhal | Same thing in effect | 22:36:27 |
jaen | * Try this one? https://nix.dev/manual/nix/2.22/command-ref/conf-file.html#conf-sandbox-paths I've been using --extra-sandbox-paths for now so not 100% sure it's this, but looks like it | 22:36:43 |
erahhal | Redacted or Malformed Event | 22:52:07 |
erahhal | Ok that worked! | 23:01:32 |
erahhal | I'll look at cleaning up that PR. | 23:10:53 |
erahhal | So the one repo it uses when building that is not from github is pantah-kernel. For standard lineage builds, it's using the branch android-14.0.0_r35. Currently greping through the source repos to figure out how the system determines that | 23:40:49 |
erahhal | Also, is it possible to configure the build so that it matches a standard LineageOS build, e.g. I could install over standard lineage and not lose data? Does that involve signing the build? Or anything else? | 23:41:46 |
erahhal | Found an answer to the first question: https://github.com/LineageOS/android/blob/lineage-21.0/default.xml#L14 | 23:47:37 |
| 7 Jun 2024 |
erahhal | One oddity with ccache is that it never goes much above 1.6G. it will go larger temporarily, then go back down to 1.6G. ccache.conf is present and indeed set to 100G | 02:59:12 |
erahhal | * One oddity with ccache is that it never goes much above 1.58G. it will go larger temporarily, then go back down to 1.58G. ccache.conf is present and indeed set to 100G | 03:09:37 |
erahhal | Maybe the conf isn't getting picked up | 03:20:46 |
samueldr | or the cache doesn't need more space because it's not being exercised? | 03:54:40 |
samueldr | if you're rebuilding the same "moral" thing, I would expect the cache won't change size much | 03:55:06 |
samueldr | (it's just a guess) | 04:03:19 |
erahhal | Yeah that's totally possible. | 04:33:44 |
atemu12 | In reply to @erahhal:matrix.org Also, is it possible to configure the build so that it matches a standard LineageOS build, e.g. I could install over standard lineage and not lose data? Does that involve signing the build? Or anything else? That should be the default. If it's not, that's a bug | 08:27:18 |
atemu12 | Though note that your signing keys won't match | 08:28:50 |
atemu12 | You need to migrate the disk state to the new keys though | 08:32:24 |
atemu12 | There's an installable zip somwhere which can do this | 08:34:11 |
jaen | Atemu: is there anything else blocking https://github.com/nix-community/robotnix/pull/236 or could we maybe merge it? I have also rebased https://github.com/nix-community/robotnix/pull/237 on top of it (and used the commit format you seem to prefer). Hopefully it will be easier to merge (unless there's something we'd want to wait for before it?). I have also finally made a PR for the changes to re-enable basic CI (https://github.com/nix-community/robotnix/pull/239), but that might require some more discussion. | 11:30:04 |
atemu12 | No, just me needing to find the time to take a proper look | 14:10:37 |
erahhal | I occasionally get ninja: build stopped: subcommand failed. I assume this is due to lack of resources, as it happens less when I unload all desktop apps, and also it's non-deterministic and doesn't seem to be associated with a particular compilation failure. Tried using the -j and --cores flags with nix build. Any other tips to address this? My machine as 32gb memory and 12 cores. | 15:37:41 |
jaen | If you have /tmp backed by tmpfs you might want to either buy 3x more RAM or back it by a block device. If you don't, then I'm not sure what that could be off-hand | 15:42:44 |
jaen | * If you have /tmp backed by tmpfs you might want to either buy 3x more RAM or back it by a block device instead. If you don't, then I'm not sure what that could be off-hand | 15:43:03 |