Can't build modify-fasta from lts-6.25 due to missing hackage revision sha

[mgsloan]

This may be an issue with stackage rather than stack, encountered this issue while looking into #3109

mgsloan@computer:~$ stack build --resolver lts-6.25 modify-fasta
Didn't see modify-fasta-0.8.2.1@sha256:e37ce6d83f2431ceb610e14d0d9f359b50280d21c203fc65cacca8ef2009e61c,1772 in your package indices.
Updating and trying again.
Selected mirror https://s3.amazonaws.com/hackage.fpcomplete.com/                                 
Downloading timestamp                                                                            
No updates to your package list were found                                                       
Update complete                                                                                  
The following package identifiers were not found in your indices: modify-fasta-0.8.2.1@sha256:e37ce6d83f2431ceb610e14d0d9f359b50280d21c203fc65cacca8ef2009e61c,1772
The specified revision was not found.
Possible candidates: modify-fasta-0.8.2.1@sha256:6eb0df5a724a634afe4892c65b281d27c6a9dc824d5457df9a00d1f11eb4943c.

Pinging @snoyberg . In general, how would one go about investigating this? The hackage web interface does not have these SHAs so I'm not sure how to diagnose what is going on here, or generally how users would find out these SHAs.

[snoyberg]

I had something similar with 37f0a1c. Here's how I debugged it:

• Looked up the GitSHA1 value in the lts-6.25.yaml file
• Confirmed that I could get that blob out of the all-cabal-files and all-cabal-hashes repos
• Determine the revision number from that blob
• Compare that revision's .cabal file in the 01-index.tar.gz file with the Git repo version (note: stack unpack modify-fasta-0.8.2.1@rev:0 syntax may help here).

[snoyberg]

I've investigated, and it's a bug in the lts-6.25.yaml file; that GitSHA1 refers to version 0.8.2.2, not 0.8.2.1. I think the best approach here is to turn the situation into a warning. Do you have thoughts on this @mgsloan?

[mgsloan]

@snoyberg Seems reasonable, I suppose it is possible to figure out that the other version should be used?

I suppose it's not possible to fix the lts-6.25.yaml file, since it may be cached. Would be good to figure out how the mismatch happened and ensure it doesn't happen in future snapshots.

[snoyberg]

I'm pretty sure I caused that problem myself with a manual edit. Solution: don't do that again. I can't think of a good way to fix the file.

[snoyberg]

Hmm... actually, maybe we can just fix the file, and then tell users in this case to just delete the cached file. Let's give that a shot first, I'm not in favor of breaking the security guarantees of checking cryptographic hashes.

[snoyberg]

@mgsloan Can you test out the 3319-delete-invalid-snapshot-files branch?