Closed sharpenedblade closed 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.
and/or its dependencies line kinda fits here.
Hmm but I'll prefer to not take any chances here.
The old code did not install the latest verrsion anyways
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?
It will only install the latest version if makepkg or coreutils are missing, if they are both installed but out of date nothing happens.
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.
Anyways it's a small issue, so we can deal with it later.
I doubt it would actually affect people
Commit 59e0706ca11800b545fca523b23bc4f04f630cb1 doesn't seem to be necessary since the code is not duplicated. And why has loopdevice been removed?
And why has loopdevice been removed?
$loopdev and $loopdevice are exactly the same
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
And why has loopdevice been removed?
$loopdev and $loopdevice are exactly the same
Loopdev is loop50 Loopdevice is loop50p1 or loop50p2
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
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.
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
Please squash the commit when you revert loopdev
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.
Please squash the commit when you revert loopdev
I squashed everything down
I would avoid changes to python code. If you want to get it merged, get a review from Redecorating
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
Has checking for missing dependencies log in method 2 and 3 been removed?
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
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.
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 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 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.
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
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 0
ed on linux in that function too.
I tested the script it looks like its working now.
You have added checking for dependencies from python check. It's not there in deb/rpm/Pacman one
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 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
Something happened to the apfs method its really broken. Il mark this PR as ready once I sort out the bugs.
This is also broken
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.
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.
Everything is working now. I think the logs are fixed too.
Don't squash the commit addressing these changes.
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.
I don’t understand how you moved the extra files to workdir on Linux as well.
Please test whatever you change.
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
No need to squash the commits btw.
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
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
What are you adding python_check in create_firmware_archive? Just put it in macOS specific code.
What are you adding python_check in create_firmware_archive? Just put it in macOS specific code.
I moved it
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.
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.
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.