| 5 Nov 2025 |
 atemu12 | ccache can cut build time by ~half | 12:01:17 |
| atemu12 | There's also some validation stuff you can disable; I've done it in my config | 12:05:32 |
 magic_rb | isnt ccache deprecated? | 12:07:39 |
| magic_rb | thats what the docs said | 12:07:46 |
| atemu12 | Still worked with 22.2 | 14:54:33 |
| 6 Nov 2025 |
 puffnfresh | https://github.com/nix-community/robotnix/pull/324 | 06:12:16 |
 pentane ⭔ | nice, thanks, gonna test it one of these days! | 21:48:32 |
| pentane ⭔ | which method did you use to get a list of all new APEX packages in android 16? looking into apkcerts.txt in the target files package, or something in these lines? | 21:49:17 |
| pentane ⭔ | bit of context: I'm a bit catious about declaring signing as "officially supported" again, since the AOSP sign_target_files_apks tool doesn't validate whether all APKs that were signed with the test keys during the main build have in fact been re-signed with the release ones. I'm considering writing some sort of validation script that looks at META/apkcerts.txt and META/apexkeys.txt in target_files.zip to validate whether the key mappings and APEX package names defined in the module systems cover everything that needs to be re-signed | 22:29:24 |
| 7 Nov 2025 |
| puffnfresh | the signing process complained when a key was missing, I just tried to sign, it would fail, I'd add that | 01:01:41 |
|  @emma:rory.gay left the room. | 22:44:02 |
| 8 Nov 2025 |
| pentane ⭔ | yeah, that's for keys that you specify with --extra-apks or --key-mapping that turn out to not exist on your filesystem | 21:45:57 |
| pentane ⭔ | but as far as I understand, sign_target_files_apks will happily leave the test keys in place if you don't specify that you wanna re-sign the APKs in question with release keys | 21:46:29 |
| pentane ⭔ | what were the exact error messages you were getting? | 22:18:57 |
| pentane ⭔ | also, I'm a bit confused. shouldn't sign_target_files_apks have complained about the missing gmscompat_lib key (see https://github.com/GrapheneOS/script/blob/16/generate-keys#L16?) | 22:27:02 |
| pentane ⭔ | * also, I'm a bit confused. shouldn't sign_target_files_apks have complained about the missing gmscompat_lib key (see https://github.com/GrapheneOS/script/blob/16/generate-keys#L16)? | 22:27:05 |
| pentane ⭔ | * also, I'm a bit confused. shouldn't sign_target_files_apks have complained about the missing gmscompat_lib key in your case (see https://github.com/GrapheneOS/script/blob/16/generate-keys#L16)? | 22:27:13 |
| 9 Nov 2025 |
| puffnfresh |
Error getting public key: b'Could not open file or uri for loading private key of public key from packages/modules/Virtualization/build/apex/com.android.virt.pem: No such file or directory\n'
| 04:41:44 |
| puffnfresh | at the time, I hadn't specified that as an extra-apk, and specifying it solved the problem - so I think it's opposite to what you're saying | 04:42:20 |
| puffnfresh | I actually generated my keys from the official scripts, so I do have that | 07:22:11 |
| puffnfresh | and that's why the PR includes support for 4096 keys - that's what I'm using | 07:22:28 |
| puffnfresh | I haven't tested Robotnix's key generation since my first attempt at signing, so gmscompat_lib being missing would probably be a problem | 07:23:25 |
| pentane ⭔ | Okay it seems like we're talking about two different things | 09:53:58 |
| pentane ⭔ | this error message refers to the payload private key of the APEX in question | 09:57:12 |
| pentane ⭔ | the test-keys variant of that payload private key is present in the GrapheneOS source tree (see https://github.com/GrapheneOS/platform_packages_modules_Virtualization/tree/16/build/apex), but not in the otaTools derivation which releaseScript cds into | 09:59:45 |
| pentane ⭔ | okay, scratch that. so I investigated this, and it seems like the otatools AOSP build target (i.e. otatools.zip in the config.build.android version) erroneously doesn't include the APEX payload test keys | 10:05:23 |
| pentane ⭔ | so that was the reason for why you were getting these error messages | 10:05:33 |
| pentane ⭔ | I don't see rn though why there should be a guarantee that this happens consistently (for instance, looking into the otaTools derivation, the APEX container test keys are there, and likewise for the normal APK signing keys) | 10:06:47 |
| pentane ⭔ | if you're interested - I'm currently experimenting with patching sign_target_files_apks to throw error messages if one of the test keys hasn't been replaced. Don't think we should do that in production though, I'd probably write a small validation program in Rust that takes META/apkcerts.txt and META/apexkeys.txt, and the signTargetFilesArgs from target_files.zip as an option to check whether the args exhaustively cover all the keys | 10:09:06 |
| pentane ⭔ | FWIW here's my current patch for https://github.com/GrapheneOS/platform_build: | 10:10:03 |
