Opened 9 months ago
Closed 9 months ago
#68056 closed defect (fixed)
libhandy-0.0 @0.13: checksum mismatch
| Reported by: | philberthfz (Philip LeBlond) | Owned by: | dbevans (David B. Evans) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.8.1 |
| Keywords: | Cc: | ||
| Port: | libhandy-0.0 |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
When trying to build on arm64, the file that gets downloaded is modified from the version macports is expecting. A checksum bump is required.
Additionally, the port fails during the "Applying patches" step because it expects the work directory to be called "libhandy-0.0.13", however the files are actually extracted to libhandy-v0.0.13-7a193d7692c9c76a1a94f17c4d30b585f77d177c, causing the port to hang. If the files are manually copied to the directory it is expecting, the port builds successfully.
Unfortunately, I don't know how to automate that last step of changing where macports is looking for the work directory.
Change History (4)
comment:1 Changed 9 months ago by jmroot (Joshua Root)
| Cc: | dbevans removed |
|---|---|
| Keywords: | checksum mismatch removed |
| Owner: | set to dbevans |
| Status: | new → assigned |
comment:2 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)
| Description: | modified (diff) |
|---|---|
| Summary: | libhandy-0.0 checksum bump and build script edit required → libhandy-0.0 @0.13: checksum mismatch |
comment:3 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)
Replying to philberthfz:
causing the port to hang.
The hang only occurs on macOS Ventura and later, because Apple changed the implementation of the patch program. On macOS Monterey and earlier, patch and thus port exits with an error.
comment:4 Changed 9 months ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Replying to philberthfz:
Before that can be done, we need to understand what changed and why. The difference between the old file (still on our mirror servers) and the new one on gitlab is:
I'm not sure how it's possible for a new directory to appear despite the git commit hash not having changed. But I suppose the appearance of the debian directory is immaterial to MacPorts. We could continue to use the old distfile (setting
master_sites macports_distfilesto ignore the new file—this is probably the best course of action) or switch to the new distfile (updatingchecksumsand performing the other tasks of a stealth update).I assume you mean that after you changed the checksums to match those of the downloaded file, this problem occurred.
This port was last edited when a MacPorts version between 2.6.0 and 2.8.0 inclusive was current. These versions automatically renamed extracted directories to what MacPorts expected. This feature was found break too many existing ports and so it was changed so that ports must opt in to this behavior if they want it.
Because the project is hosted on a gitlab instance and downloads its distfile from there, the portfile should use the gitlab portgroup. In addition to performing other tasks common to gitlab-hosted software that would simplify the portfile, the gitlab portgroup opts in to the behavior of renaming the extracted directory. Alternately, the portfile could opt in to it manually with
extract.rename yes.