 | CalyxOS Development | 879 Members |
| CalyxOS development channel | Main channel #CalyxOS:matrix.org | 57 Servers |
| CalyxOS Development | 879 Members |
| CalyxOS development channel | Main channel #CalyxOS:matrix.org | 57 Servers |
| Sender | Message | Time |
|---|---|---|
| 4 Oct 2024 | ||
 chrisrg (Telegram) | Thanks for the reply! I might forget some of the things I tried, although I've got some notes. I did add LineageOS/android_packages_apps_Trebuchet in place of the calyx Launcher3 and got a build after adding a line to external/roboelectric/Android.bp. The phone booted but no launcher installed, so device endlessley starting on the home screen. Apps could be accesed from pull down shade and settings. | 17:42:46 |
| chrisrg (Telegram) | I know it's a finicky thing I'm trying to do and it's possible to hide some apps with the calyx launcher.😉 | 17:44:54 |
 mkbestas | You need to add TrebuchetQuickStep to PRODUCT_PACKAGES if you do it that way | 18:03:42 |
| chrisrg (Telegram) | My lack of knowledge is quite extensive, so that seems a bit cryptic at the moment. Much appreciate your pointers and I'll have another go in the morning. Thanks.👍 | 18:11:43 |
| chrisrg (Telegram) | Couldn't wait...and now I've got it! Just as you said. Thank you so much guys, I'm really grateful. These little tips really help one to move forward and just learn a little more. 😀 I'll just add the specific file here in case anyone like me is searching the chat later; that's how I found to include Datura in LOS (from a few years ago comment!) Add TrebuchetQuickStep to PRODUCT_PACKAGES in device-lynx.mk. | 20:00:01 |
| 5 Oct 2024 | ||
 jr_az joined the room. | 19:43:00 | |
| 6 Oct 2024 | ||
 one1two2 joined the room. | 13:48:30 | |
| one1two2 | Hi, I am currently having a few issues with build calyxos for FP4. As far as I can tell from the commits on gitlab and patches on gerrit, the device.sh script is currently not working due to the changed folder structure in the factory image? Meaning the extraction process is currently also not tested? I am using my own scripts for extracting the vendor files (which internally of course uses the extract-files.sh script). I adapted it to the new folder structure with the "FP4-TP2I-factory" and I just had to add an additional intermediate folder, iirc. Though, on a first glance, I could not find the calls to simg2img and lpunpack in your scripts, otherwise I could look into fixing it. Additionally it seems that with the FP4-TP2L-factory some vendor file hashes have changed and must be updated in the proprietary-files.txt. I could provide an update for those, however, I am unsure about the EuiccGoogle.apk. I think it was updated to fix an issue with eSIM activation, however I could not find documentation that says from where the updated file was pulled, the hash in the FP4-TP2L-factory deviates. | 14:13:53 |
| one1two2 | * Hi, I am currently having a few issues with building calyxos for FP4. As far as I can tell from the commits on gitlab and patches on gerrit, the device.sh script is currently not working due to the changed folder structure in the factory image? Meaning the extraction process is currently also not tested? I am using my own scripts for extracting the vendor files (which internally of course uses the extract-files.sh script). I adapted it to the new folder structure with the "FP4-TP2I-factory" and I just had to add an additional intermediate folder, iirc. Though, on a first glance, I could not find the calls to simg2img and lpunpack in your scripts, otherwise I could look into fixing it. Additionally it seems that with the FP4-TP2L-factory some vendor file hashes have changed and must be updated in the proprietary-files.txt. I could provide an update for those, however, I am unsure about the EuiccGoogle.apk. I think it was updated to fix an issue with eSIM activation, however I could not find documentation that says from where the updated file was pulled, the hash in the FP4-TP2L-factory deviates. | 14:15:05 |
| one1two2 | * Hi, I am currently having a few issues with building calyxos for FP4. As far as I can tell from the commits on gitlab and patches on gerrit, the device.sh script is currently not working due to the changed folder structure in the factory image? Meaning the extraction process is currently also not tested? I am using my own scripts for extracting the vendor files (which internally of course uses the extract-files.sh script). I adapted it to the new folder structure with the "FP4-TP2I-factory" and I just had to add an additional intermediate folder, iirc. Though, on a first glance, I could not find the calls to simg2img and lpunpack in your scripts, otherwise I could look into fixing it. Additionally it seems that with the FP4-TP2L-factory some vendor file hashes have changed and must be updated in the proprietary-files.txt. I could provide an update for those, however, I am unsure about the EuiccGoogle.apk. I think it was updated to fix an issue with eSIM activation, however I could not find documentation that says from where the updated file was pulled. The hash in the FP4-TP2L-factory deviates. | 14:16:10 |
| mkbestas | The build instructions need some work and as you mentioned, fairphone device.sh is currently not working due to the extra folder. There are also other issues that prevent you from extracting from stock factory image and having a fully functional build, since we have manually updated some things like the EuiccGoogle apk and the WiFI display stack in order for them to work on Android 14. The guides will be updated at some point so that you have to extract from calyx factory images instead of stock, since that is the only way to achieve 1:1 vendor image with official calyx builds. | 15:51:20 |
| mkbestas | In reply to @one1two2:matrix.orgthe updated EuiccGoogle.apk comes from play store/aurora store after manually updating it on a device | 15:52:49 |
| one1two2 | Hi, thank you for the quick answer and explaining the reasons behind this! It's completely plausible to me that some of the apks have to be replaced in order to work with Android 14 (coming from the Android 13 FP4 factory image). Wouldn't it also be an option to add the replaced binaries to a git (or git-lfs) repo and pull them (e.g. in the extract-files script) after extracting the original binaries from the factory image? I think it would be a pity to abandon the possibility to extract the binaries from original factory image, especially given that Fairphone is providing them so readily. Moreover, having the replaced / updated apks in a separate git repo would implicitly document which of the binaries had to be replaced. Maybe one could even find a way to document the source of the new binary (e.g. pixel7codename-factory-version). In my opinion this would improve reproducibility and transparency (or traceability). | 20:43:02 |
| one1two2 | * Hi, thank you for the quick answer and explaining the reasons behind this! It's completely plausible to me that some of the apks have to be replaced in order to work with Android 14 (coming from the Android 13 FP4 factory image). Wouldn't it also be an option to add the replaced binaries to a git (or git-lfs) repo and pull them (e.g. in the extract-files script) after extracting the original binaries from the factory image? I think it would be a pity to abandon the possibility to extract the binaries from the original factory image, especially given that Fairphone is providing them so readily. Moreover, having the replaced / updated apks in a separate git repo would implicitly document which of the binaries had to be replaced. Maybe one could even find a way to document the source of the new binary (e.g. pixel7codename-factory-version). In my opinion this would improve reproducibility and transparency (or traceability). | 20:43:33 |
| 9 Oct 2024 | ||
 cdesai | It wouldn't be possible to put the binaries in a separate git repo since it isn't always possible to make such repos publicly available. It'd also be a lot of additional work for us. | 14:07:17 |
| cdesai | Transparency and traceability aren't issues because all such files already have their checksums listed, and the commit message adding them always describes the source. | 14:07:44 |
| cdesai | You're only building for a device or two, but we have to do these kinds of things for every device we support, and keep maintaining that. | 14:08:20 |
| cdesai | So right now the best way for us is to just ask people to extract from CalyxOS factory images instead, and if someone wants they can always extract most of the files from the stock image instead, and look at the git history to see where the other files were obtained from for verification. | 14:09:00 |
| 10 Oct 2024 | ||
| cdesai | lucas! ∞: also, were you able to compile microG after all? | 15:16:53 |
 lucas! ∞ | not really | 15:17:25 |
| cdesai | my suggestion: If you're trying to compile anything that has CI setup and it doesn't go well - just fork, push your changes and have CI build it. microG has github actions setup calyxos.org has gitlab ci setup | 15:17:33 |
| cdesai | it's not as fast as building locally ofc but definitely much simpler. | 15:17:44 |
| lucas! ∞ | In reply to @lucasmz:tchncs.deIt did end up working actually locally (before any changes) but the user builds which are supposed to use another package name I think were using the regular Google package names so | 15:19:02 |
| lucas! ∞ | I need to mostly just figure out I believe how to edit the package name for regular microG | 15:19:41 |
| lucas! ∞ | (Also god damn I did not know microG was as expensive to build as it is) | 15:20:04 |
| cdesai | In reply to @lucasmz:tchncs.deI don't think that's going to be trivial. | 15:20:42 |
| cdesai | In reply to @lucasmz:tchncs.defrom what I saw they use some org.microg package name. | 15:20:56 |
| lucas! ∞ | It could've been some other issue too, I didn't look too much into it Just got package Conflict when trying to install on Calyx | 15:21:49 |
| lucas! ∞ | Their wiki page was definitely helpful ;D | 15:22:10 |
| cdesai | yeah I don't know if I'd expect them to work side by side like that. | 15:23:47 |