Frotz 2.54 SHA256 hash is wrong

[DavidGriffith]

brew gist-logs <formula> link OR brew config AND brew doctor output

I'm the upstream for Frotz.

I've been alerted that the SHA256 hash for Frotz 2.54 is wrong.  See https://gitlab.com/DavidGriffith/frotz/-/issues/272 for the report.  Would someone please tell me where that hash came from and when?  I'm investigating what could have gone wrong.

Verification

• My "brew doctor output" says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem.

What were you trying to do (and why)?

Trying to figure out why you have a bad SHA256 hash for the Frotz tarball.

What happened (include all command output)?

SHA256 mismatch. See above.

What did you expect to happen?

Frotz to install. See above.

Step-by-step reproduction instructions (by running brew commands)

`brew install frotz`

[DavidGriffith]

After going over things, I cannot explain why the hash here differs from what is observed at Gitlab. I have confirmed that the hash there (756d7e11370c9c8e61573e350e2a5071e77fd2781be74c107bd432f817f3abc7) matches what I have on my local machines for the 2.54 tag.

@Porkepix, would you please tell me where you got the hash for Frotz 2.54 in #99273?

[Porkepix]

I didn't get the hash, brew bump or brew bump-formula-pr got it, and fetched it directly from GitLab.
If the hash changed, you can open a PR to fix it to the new one.

[carlocab]

That was the hash for the tarball when it was downloaded and built from source in #99273.

[cho-m]

May be a GitLab issue given a similar issue in #127055.

However, other formula (svt-av1) is fine now and may have been related to https://gitlab.com/gitlab-org/gitlab/-/issues/402616 which was fixed a few days ago.

---

EDIT: as we have Ventura bottles (e.g. e9ed39f), this means the SHA of tarball was still the same on Nov 30, 2022.

[qianbinbin]

Anyone has the copies of tarballs?

Tarballs of svt-av1 have different directory names, SVT-AV1-018276d714ce65d9b586f6205ee016cbd8d5425d and SVT-AV1-v1.4.1, that's why they got different checksums, but the contents are exactly the same.

[cho-m]

Could also be a side-effect of git update in GitLab servers. Hard to pin down exact cause without debugging further.

I think both GitHub and GitLab have potentially unstable checksums for archive tarballs due to their design and currently require attaching download asset to remain unchanged. Usually not a problem, but they crop up every once in a while. Only alternative for Homebrew & others is the git commit, but that has its own set of problems.

Anyway, if new SHA remains, we can merge #127298.

[jcgraybill]

It looks like @DavidGriffith has confirmed the new hash is okay to use in GitLab issue 272:

After I set core.abbrev 8, I was able to get a file from my local repository with the same hash as from Gitlab using this command:
git archive --format=tar.bz2 --prefix frotz-2.54/ HEAD -o frotz-2.54.tar.bz2

I also checked (and confirmed) this new hash is consistent across all of GitLab's CloudFlare endpoints:

% while true; do \
  echo $(date -Isec) $(curl -v https://gitlab.com/DavidGriffith/frotz/-/archive/2.54/frotz-2.54.tar.bz2 | shasum -a 256 ) ; \
  sleep 1; done 2>&1 | grep -e 'sv:' -e 'lb:' -e '\-$'

< gitlab-lb: fe-19-lb-gprd
< gitlab-sv: web-gke-us-east1-c
756d7e11370c9c8e61573e350e2a5071e77fd2781be74c107bd432f817f3abc7 -
< gitlab-lb: fe-34-lb-gprd
< gitlab-sv: web-gke-us-east1-c
756d7e11370c9c8e61573e350e2a5071e77fd2781be74c107bd432f817f3abc7 -
< gitlab-lb: fe-24-lb-gprd
< gitlab-sv: web-gke-us-east1-b
756d7e11370c9c8e61573e350e2a5071e77fd2781be74c107bd432f817f3abc7 -
...

[chenrui333]

I just merged #127298, I think we can close this issue now.

[cho-m]

Closing for now as nothing left to do on Homebrew side.

Let us know if there are still issues.

---

On side note, we could consider switching to tarball from website (https://ifarchive.org/if-archive/infocom/interpreters/frotz/frotz-2.54.tar.gz), which may avoid issues from GitLab updates.

In this cause, we would probably want to mirror https://ifarchive.org/indexes/if-archive/infocom/interpreters/frotz/old/ to avoid breaking downloads when a new release is out that we didn't update to yet.

Can consider this change on a future release.