Hello Denis, thank you for your answer. I understand that all the app signing steps are ** not** needed if I want to build by myself a replicant-6 0004 version from the sources to install a new device, am I correct? The goal would then to be to install just this last 0004 image. Do you confirm it is possible this way? Until now, I followed the steps in dedicated page https://redmine.replicant.us/projects/replicant/wiki#Replicant-build
I confess I do not really understand why I would need to use the signing key for releasing a new replicant 6 0005 version but not for a 0004 since I begin from the source code for both. So I prefer to wait for being sure before following those steps since I do not want breaking a new device. Regards - Fil Lupin. PS: sorry I answered only to Denis so I send it back to the list in case someone else would have some insights to share. ------- Original Message ------- On Thursday, April 20th, 2023 at 12:01 AM, Denis 'GNUtoo' Carikli <gnu...@cyberdimension.org> wrote: > On Thu, 13 Apr 2023 21:17:34 +0000 > Fil Lupin via Replicant replicant@osuosl.org wrote: > > > Hi, > > Hi, > > sorry for the delay, I again have a big mail backlog. > > > trying to build replicant-6 image, > > I read > > > [...] > The issue is that the migration script is only used in the -transition > releases, so it doesn't show up in the regular git history. This should > be documented better indeed. > > The difference between these two release: > https://git.replicant.us/replicant/vendor_replicant/log/?h=replicant-6.0-0004-transition > https://git.replicant.us/replicant/vendor_replicant/log/?h=replicant-6.0-0004 > > is basically that commit: > https://git.replicant.us/replicant/vendor_replicant/commit/?h=replicant-6.0-0004-transition&id=98d74730a5a7db5662dde5cceb4609f7d299d6a9 > > > However, following last instructions, it seems > > `./vendor/replicant/build.sh i9300` signs apk with the generated key, > > That is correct > > > but since this file has been modified 9/9/2020, I understand the > > files generated bu this script are not usable and need to install > > replicant6-0004 and need to run > > https://git.replicant.us/replicant/vendor_replicant-scripts/tree/images/gen_key_migration_script/README > > instructions. However, I probably missed some information in this > > file: it seemed to me `./gen_key_migration_script.py gen-script \ > > > So if you were to release a Replicant 6.0 0005 version yourself or a > fork of Replicant, you would: > (1) Generate the migration script with the command above. This python > script ends up generating a shell script (more on that later). > (2) Add the generated shell script in vendor/replicant like the commit > 98d74730a5a7db5662dde5cceb4609f7d299d6a9 mentioned above does > (3) Add a commit to set the new Replicant version in vendor/replicant > for instance to set it to replicant-6.0-0005-transition > (4) Push that to the replicant-6.0-0005-transition during the release > with the release scripts. > > And then you would again do a new release: > (1) You would not add the generated script in vendor/replicant. > (3) You would Add a commit to set the new Replicant version in > vendor/replicant for instance to set it to > replicant-6.0-0005 > (4) You would push that to the replicant-6.0-0005 during the release > with the release scripts. > > Users then will install the replicant-6.0-0005-transition images and > boot them. The shell script will run at each boot of the > replicant-6.0-0005-transition release. This is why it has > #!/system/bin/sh. > > Users are then expected to install the replicant-6.0-0005 images to > avoid running the script at each boot as if the power goes off at the > wrong moment the applications won't be able to access their data > anymore. > > An alternative to all that is to: > (1) Generate the migration shell script with the command above > (2) Go in the recovery and mount the data partition > (3) run the script manually in the recovery. Here you don't necessarily > have /system/bin/sh so you either need to run the script with sh or > modify it to use #!/bin/sh. > > > In addition, it seemed some additionnal fixes were needed : > > > > - chmod u+x > > ../../../../vendor/replicant/prebuilt/common/bin/key-migration.sh > > > > - the sashbang `!/system/bin/sh` in > > ../../../../vendor/replicant/prebuilt/common/bin/key-migration.sh > > does not work (/bin/sh should work) > > If you run the script in the recovery, a better way would probably to > keep #!/system/bin/sh and fix the instructions to run the script with sh > manually, like with sh key-migration.sh. > > > But I then got following output (si I probably made missed something): > > --- > > ./gen_key_migration_script.py gen-script > > ./gen_key_migration_script.py gen-script \ > > > > Traceback (most recent call last): > > File "./gen_key_migration_script.py", line 20, in <module> > > import sh > > ImportError: No module named 'sh' > > Here you need to install a debian package that is probably named > python3-sh. > > Denis. _______________________________________________ Replicant mailing list Replicant@osuosl.org https://lists.osuosl.org/mailman/listinfo/replicant
