EA Client checksum fails

[insertdead]

Describe the bug

Hi there, I recently tried to install the EA launcher, and it gave me a checksum failure.

(10:34:02) ERROR Downloaded file [EAappInstaller.exe] looks corrupted. 
(10:34:02) ERROR Source cksum: [d88875b6458000d5bd26a08e35ee6b5c] downloaded: [2f2abe1ea86a39e70e3c2c10d58857a3] 
(10:34:02) ERROR Removing corrupted file [EAappInstaller.exe]. 
(10:34:02) ERROR Failed to download EAappInstaller.exe, or checksum failed.

By the way, is there a way for me to locally change the manifests so we wouldn't have to open an issue whenever this happens? Thanks

Screenshot

[mirkobrombin]

You can use local repositories for dependencies, installers and components. E.g. clone the programs repository, give Bottles permission to reach the path and start it with LOCAL_INSTALLERS=/path/to/repo flatpak run com.usebottles.bottles

[insertdead]

alright thanks!

[insertdead]

Hmm, now bottles accepts the installer executable, but it seems to not work past that. Once I get to open the app and install it, it seems to work at first then it errors out. On top of that the app keeps crashing when I install it manually. Here's the stuff wine complains about when this happens during installation

And the stuff I get when I run the manually installed executable.

This might be in relation to #75.

[mirkobrombin]

I think it's a recent EA update because I've also tried other software like Lutris and didn't have any luck

[hamburgerghini1]

I have also same problem.

[mirkobrombin]

Fixed

[FarisZR]

There is already another Hash, I think there shouldn't be File hash checks, or at least be automated, to be checked every hour by for example GH-actions.

[mirkobrombin]

Hash are used to validate downloads, not only for security purposes but also to avoid partial downloads. We can add an option to disable hash per installer when those release updates too fast.

Btw everyone can send a PR to update the hash, so we can just press 1 button to serve the updated one

[FarisZR]

Then i think automating Hash updates would be the best solution to avoid these problems. I will send a PR right now.

[mirkobrombin]

Then i think automating Hash updates would be the best solution to avoid these problems. I will send a PR right now.

We considered using GitHub actions for this purposes but will hit account limits.

[FarisZR]

Shouldn't GH-actions be unlimited for Open Source Projects?

[mirkobrombin]

There are still some limitations. We are considering moving to the GNOME GitLab and/or check for hash using our servers, then using git to open a new PR. Not something we can do in the short time.

[FarisZR]

Interesting, I'm running a project which checks for remote updates every hour and if there is a new commit builds an image. There hasn't been any limitations or issues.

[mirkobrombin]

https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration

Job execution time - Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete.

Sometime the resource is not accessible and the action stuck for hours waiting for it. This is probably something we can improve in our custom tool https://github.com/bottlesdevs/tools/blob/main/DependenciesUpdater/CheckFileChecksum.py but other users reported they get banned from GitHub assuming they where improper using GitHub Actions, so maybe not.

[FarisZR]

Huh, I think this means for each job in a single workflow run. Because there is Upptime which depends on a lot of GitHub action runs, and many uses use it with no problems.

[mirkobrombin]

It's per job