t2linux / wiki

Repository for the t2linux.org wiki
https://wiki.t2linux.org
Creative Commons Attribution Share Alike 4.0 International
181 stars 65 forks source link

Cleanup and refactor firmware.sh #549

Closed sharpenedblade closed 5 months ago

sharpenedblade commented 5 months ago

There are minor visual changes and some of the "warnings" about installing packages got removed but most of the logic is exactly the same. 9c427e2 has a gnarly diff but the code changes are actually really small.

AdityaGarg8 commented 5 months ago

Also for the Fix Message commit, I dunno if "$package is missing" would be right for makepkg, cause the logic checks for makepkg as well as coreutils.

I split that if up to only install the right packages.

It was intentionally not split so that latest version of both is installed. Brew for some reason hasn't included coreutils as a dependency but without it makepkg doesn't work.

GNU coreutils are stable so it shouldnt really matter what version they are as long as it is somewhat modern.

Hmm but I'll prefer to not take any chances here.

AdityaGarg8 commented 5 months ago

and/or its dependencies line kinda fits here.

sharpenedblade commented 5 months ago

Hmm but I'll prefer to not take any chances here.

The old code did not install the latest verrsion anyways

AdityaGarg8 commented 5 months ago

Hmm but I'll prefer to not take any chances here.

The old code did not install the latest verrsion anyways

How can you say that?

sharpenedblade commented 5 months ago

It will only install the latest version if makepkg or coreutils are missing, if they are both installed but out of date nothing happens.

AdityaGarg8 commented 5 months ago

It will only install the latest version if makepkg or coreutils are missing, if they are both installed but out of date nothing happens.

If someone has both of them installed, I believe homebrew will update both together when it upgrades its packages.

AdityaGarg8 commented 5 months ago

Anyways it's a small issue, so we can deal with it later.

AdityaGarg8 commented 5 months ago

I doubt it would actually affect people

AdityaGarg8 commented 5 months ago

Commit 59e0706ca11800b545fca523b23bc4f04f630cb1 doesn't seem to be necessary since the code is not duplicated. And why has loopdevice been removed?

sharpenedblade commented 5 months ago

And why has loopdevice been removed?

$loopdev and $loopdevice are exactly the same

sharpenedblade commented 5 months ago

Commit 59e0706 doesn't seem to be necessary since the code is not duplicated.

Its for logging to a file later Sorry wrong commit

It makes the code cleaner since less stuff is in "main". Im going to convert everything to local variables so there's less shared global state

AdityaGarg8 commented 5 months ago

And why has loopdevice been removed?

$loopdev and $loopdevice are exactly the same

Loopdev is loop50 Loopdevice is loop50p1 or loop50p2

sharpenedblade commented 5 months ago

And why has loopdevice been removed?

$loopdev and $loopdevice are exactly the same

Loopdev is loop50 Loopdevice is loop50p1 or loop50p2

I didnt see that when testing, il revert the change. I think its because I used a partitionless file to check the code

AdityaGarg8 commented 5 months ago

And why has loopdevice been removed?

$loopdev and $loopdevice are exactly the same

Loopdev is loop50 Loopdevice is loop50p1 or loop50p2

I didnt see that when testing, il revert the change. I think its because I used a partitionless file to check the code

Be assured there is no variable unnecessarily declared in the script.

sharpenedblade commented 5 months ago

And why has loopdevice been removed?

$loopdev and $loopdevice are exactly the same

Loopdev is loop50 Loopdevice is loop50p1 or loop50p2

I didnt see that when testing, il revert the change. I think its because I used a partitionless file to check the code

Be assured there is no variable unnecessarily declared in the script.

I thought it was just old code since they were similarily names

AdityaGarg8 commented 5 months ago

Please squash the commit when you revert loopdev

AdityaGarg8 commented 5 months ago

And why has loopdevice been removed?

$loopdev and $loopdevice are exactly the same

Loopdev is loop50 Loopdevice is loop50p1 or loop50p2

I didnt see that when testing, il revert the change. I think its because I used a partitionless file to check the code

Be assured there is no variable unnecessarily declared in the script.

I thought it was just old code since they were similarily names

You can change the names to avoid confusion. I couldn't get a good name while writing it.

sharpenedblade commented 5 months ago

Please squash the commit when you revert loopdev

I squashed everything down

AdityaGarg8 commented 5 months ago

I would avoid changes to python code. If you want to get it merged, get a review from Redecorating

sharpenedblade commented 5 months ago

I would avoid changes to python code. If you want to get it merged, get a review from Redecorating

It looks like this change breaks file comparison and sticks new file in the tar archive. I dont think this will break anything but I dont want to take chances. It significantly improves performance for the python part (~0.3 seconds), so im going to try to replace sha256 with something faster since we dont care about security

AdityaGarg8 commented 5 months ago

Has checking for missing dependencies log in method 2 and 3 been removed?

AdityaGarg8 commented 5 months ago

I would avoid changes to python code. If you want to get it merged, get a review from Redecorating

It looks like this change breaks file comparison and sticks new file in the tar archive. I dont think this will break anything but I dont want to take chances. It significantly improves performance for the python part (~0.3 seconds), so im going to try to replace sha256 with something faster since we dont care about security

Sorry I won't merge any change to the python code

sharpenedblade commented 5 months ago

I would avoid changes to python code. If you want to get it merged, get a review from Redecorating

It looks like this change breaks file comparison and sticks new file in the tar archive. I dont think this will break anything but I dont want to take chances. It significantly improves performance for the python part (~0.3 seconds), so im going to try to replace sha256 with something faster since we dont care about security

Sorry I won't merge any change to the python code

Il open a different PR with it then, but with some work it can be significantly sped up.

sharpenedblade commented 5 months ago

Has checking for missing dependencies log in method 2 and 3 been removed?

No, it got moved to the function that needs the dependency though

AdityaGarg8 commented 5 months ago

I would avoid changes to python code. If you want to get it merged, get a review from Redecorating

It looks like this change breaks file comparison and sticks new file in the tar archive. I dont think this will break anything but I dont want to take chances. It significantly improves performance for the python part (~0.3 seconds), so im going to try to replace sha256 with something faster since we dont care about security

Sorry I won't merge any change to the python code

Il open a different PR with it then, but with some work it can be significantly sped up.

As said before, if you want to make changes to python code, unless it's very necessary, first open it upstream.

sharpenedblade commented 5 months ago

I would avoid changes to python code. If you want to get it merged, get a review from Redecorating

It looks like this change breaks file comparison and sticks new file in the tar archive. I dont think this will break anything but I dont want to take chances. It significantly improves performance for the python part (~0.3 seconds), so im going to try to replace sha256 with something faster since we dont care about security

Sorry I won't merge any change to the python code

Il open a different PR with it then, but with some work it can be significantly sped up.

As said before, if you want to make changes to python code, unless it's very necessary, first open it upstream.

I dont think upstream will accept a non-cryptographic hash, but since we arent verifying hashes anyways it doesnt matter to us. Asahi has a lot more requirements than us, which is why their code is complicated.

AdityaGarg8 commented 5 months ago

Has checking for missing dependencies log in method 2 and 3 been removed?

No, it got moved to the function that needs the dependency though

I can't find in the macOS bit

sharpenedblade commented 5 months ago

Has checking for missing dependencies log in method 2 and 3 been removed?

No, it got moved to the function that needs the dependency though

I can't find in the macOS bit

I messed something up when I moved stuff around, I will fixed it now. It return 0ed on linux in that function too.

sharpenedblade commented 5 months ago

I tested the script it looks like its working now.

AdityaGarg8 commented 5 months ago

You have added checking for dependencies from python check. It's not there in deb/rpm/Pacman one

sharpenedblade commented 5 months ago

You have added checking for dependencies from python check. It's not there in deb/rpm/Pacman one

Then it says Checking for dependencies twice, which looks kinda wierd. Should I still add it?

AdityaGarg8 commented 5 months ago

You have added checking for dependencies from python check. It's not there in deb/rpm/Pacman one

Then it says Checking for dependencies twice, which looks kinda wierd. Should I still add it.

You should add it before the code that is executed first

sharpenedblade commented 5 months ago

Something happened to the apfs method its really broken. Il mark this PR as ready once I sort out the bugs.

AdityaGarg8 commented 5 months ago

image This is also broken

AdityaGarg8 commented 5 months ago

Tbh I am not really convinced in moving the non repetitive code like method 4 and 5 in functions. The code is much easier to read without them. So I would prefer reverting those changes.

sharpenedblade commented 5 months ago

Tbh I am not really convinced in moving the non repetitive code like method 4 and 5 in functions. The code is much easier to read without them. So I would prefer reverting those changes.

I reverted those.

sharpenedblade commented 5 months ago

Everything is working now. I think the logs are fixed too.

AdityaGarg8 commented 5 months ago

Don't squash the commit addressing these changes.

AdityaGarg8 commented 5 months ago

nvram_txcap_quirk is broken in Method 1 (I haven't tested other methods yet). Cause is quite evident by the code itself. You are making a firmware-raw.tar.gz for the main firmware and firmware-raw.tar for extra firmware. After that you are only extracting firmware-raw.tar.gz on Linux and firmware-raw.tar is untouched.

Screenshot 2024-06-18 at 10 43 25 PM

I don’t understand how you moved the extra files to workdir on Linux as well.

Please test whatever you change.

AdityaGarg8 commented 5 months ago

Also, separate out python_check for macOS in a separate function like it was in the older version. There is not need to unnecessarily complicate the create_firmware_archive

AdityaGarg8 commented 5 months ago

No need to squash the commits btw.

sharpenedblade commented 5 months ago

I don’t understand how you moved the extra files to workdir on Linux as well.

Once I add those files to the right archive it will work. When the tarfile is extracted those files will be in $PWD, which is $workdir

Please test whatever you change.

I dont have a mac where that code is used.

Also, separate out python_check for macOS in a separate function like it was in the older version. There is not need to unnecessarily complicate the create_firmware_archive

Ok

AdityaGarg8 commented 5 months ago

I don’t understand how you moved the extra files to workdir on Linux as well.

Once I add those files to the right archive it will work. When the tarfile is extracted those files will be in $PWD, which is $workdir

Please test whatever you change.

I dont have a mac where that code is used.

You can change the model identifier to your Mac and path to the firmware folder to your chip. That's how I test on my Mac.

Also, separate out python_check for macOS in a separate function like it was in the older version. There is not need to unnecessarily complicate the create_firmware_archive

Ok

AdityaGarg8 commented 5 months ago

What are you adding python_check in create_firmware_archive? Just put it in macOS specific code.

sharpenedblade commented 5 months ago

What are you adding python_check in create_firmware_archive? Just put it in macOS specific code.

I moved it

AdityaGarg8 commented 5 months ago

Script looks good to me now, I've tested it on Ubuntu as well as Arch. I wonder if there could be a way to use /tmp if storage in RAM is sufficient. I would prefer not to write much on the SSD for such tasks.

sharpenedblade commented 5 months ago

I wonder if there could be a way to use /tmp if storage in RAM is sufficient.

I think its better to use the disk since a lot of macs only have 8Gb of RAM and if you have swap enabled its going to write to disk anyways.

I would prefer not to write much on the SSD for such tasks.

It shouldn't be a problem, a lot of things write more than this to disk. SSD wear only matters if you write large amounts of data regularly, a user will probably only run this script once.