rooted-lineage

[xabolcs]

Hi!

I'm bad at naming things, sorry for that!

As you can see there are a few fix: commits on my branch. They have the worst commit title and description in the world (so don't pick them as-is), but at least you get a hint from them! 😅

About porting to LineageOS: well it was straightforward! 🙏
I put all the new things into findLatestVersion().

But sadly all this porting stuff should be put on hold because of erofs: chenxiaolong/afsr#14

[xabolcs]

Added sugar. Should I drop this?

[xabolcs]

Hi @schnatterer ,
as you can see I refreshed the PR, also introduced the suggested OTA_TYPE and the self founded OTA_VENDOR. 😅

How should I continue?

• should I fix the PR action not to fail? I'm OK with this.
  • should I take this into production in my fork as a fully-fledged real world test? I'm OK with this too.
• should I start updating README? I don't really want to do it now - I want to do it as the last step! After "code freeze". 😀
• should I thinking and implementing the modularization? I'm OK with this.
  • modularization commit should come before or after the lineage addition? I'm OK with both! I'm just wanna keep the commits clean: one for adding LOS, one for doing the modularization. 👌

I'm not working on this PR until your further notice! 🙂

[xabolcs]

Those nice print, printRed and printGreen functions are not available yet. And I didn't want to move them before this just now.

Maybe they could be moved into a separate file within the upcoming modularization work! 🙂

[xabolcs]

As a nice to have change would be an unconditional:

Suggested change

	args+=("--patch-arg=--rootless")
	args+=("--patch-arg=--${flavor}")

[schnatterer]

Hey @xabolcs, Thanks for your patience!

Here are my thoughts - open for discussion.

Lets try to implement a modularized version getting rid of the case $OTA_VENDOR and if [ "$OTA_VENDOR" blocks.

At the beginning of rooted-ota.sh we could just try to source $OTA_VENDOR.sh. Fail if it is not there.
Then we can implement grapheneos.sh and lineage.sh.
For these we offer three functions that hook into the main logic

• init
• findLatestOtaVersion
• addVendorPatchArgs

The last one might be challenging. While we can pass the flavor in as a parameter, return values are a pain in bash. Maybe we can use args a global var? 😬

This way we should be able to keep the code base much cleaner.

I also like your idea of a utils.sh that is sourced in the beginning, so you can e.g. printGreen in init. Which functions will we put there? My feeling would be all mere technical functions that don't have anything to do with our "domain" (OTA patching), e.g. checkMandatoryVariable, base642key, key2base64, extractGithubRepo, gitPushWithRetries, print*

Yes, at the end we should have a green build for both graphene and lineage. And at some point a real world test that proves that all of this works would be good 😅

I think the problem with the build is that secrets (like the signature key) are not loaded into untrusted PRs. I already though about that. We could just create temporary keys during build (which will waste my precious GH action minutes) or I'll try to provide dev keys as non-secrets.

Writing the docs at the very end is fine with me!

[xabolcs]

Hi @schnatterer,
Thank you for your time!

I'm mostly OK with your food for thoughts!
I would start implementing once we decide for the commit order, see below!

Lets try to implement a modularized version ...

How would you like it to do? Modularizing first and adding LineageOS support as a first example, or in the reverse: use the current state of this PR and modularize now as a second commit?

• addVendorPatchArgs

The last one might be challenging. While we can pass the flavor in as a parameter, return values are a pain in bash. Maybe we can use args a global var? 😬

I like using envsubst with dynamically predefined variables:

# some other code
# ...

# "parsing" some environment file: stuff=value
set -o allexport
source "$file"
ENVSUBST_VARIABLES=`cut -d= -f1 ${file} | sed -e 's/^/$/'|xargs`
set +o allexport

# and later then
envsubst "${ENVSUBST_VARIABLES}" < $file_for_environment_substitution

# do something else
# ...

What do you think?
I think something like this would work, but I'll figure it surely out once I got there!

... (which will waste my precious GH action minutes) ...

I already found a few spots where your precious GH action minutes could be saved. Are you interested in such contribution?
I planned to propose it in a different PR as it is totally irrelevant for this one.

[xabolcs]

Yes, at the end we should have a green build for both graphene and lineage. And at some point a real world test that proves that all of this works would be good 😅

Hi @schnatterer,
I am going to exercise this for shiba.
For that, I will need the script accepting already downloaded input zips (e.g. with --input).

[schnatterer]

How would you like it to do? Modularizing first and adding LineageOS support as a first example, or in the reverse: use the current state of this PR and modularize now as a second commit?

I don't care about the order too much.
Refactoring the current state would be most efficient, wouldn't it?

I like using envsubst with dynamically predefined variables

I'd rather source the module files as is.
Creating temp files with envsubst feels error prone.
I also don't understand how envsubst will help us with return values. But I might miss something. Please try it without, and if you get stuck commit the state and let's discuss solutions then.

I already found a few spots where your precious GH action minutes could be saved. Are you interested in such contribution?

Yeah, if you have any ideas regarding more efficient builds I'd be happy to hear them. Different PR? I haven't done a lot of optimization, yet, other than make them run concurrently for multiple devices.

I am going to exercise this for shiba.
For that, I will need the script accepting already downloaded input zips (e.g. with --input).

You mean as an alternative to OTA_VERSION? I'd like to keep downward compatibility. Other than that feel free to add it here, or if it makes sense to a different smaller PR.

[xabolcs]

You mean as an alternative to OTA_VERSION?

I'd like to use an already downloaded zip!
Currently your script want to download latest or specific version of an ota.
I would like to use an already downloaded zip (because of GApps prepatching, erofs -> ext4 conversion, etc, etc).
Sure, for a GH release all the necessary parameters should be provided!