[MacPorts] #68056: libhandy-0.0 @0.13: checksum mismatch (was: libhandy-0.0 checksum bump and build script edit required)

[MacPorts]

#68056: libhandy-0.0 @0.13: checksum mismatch
---------------------------+----------------------
  Reporter:  philberthfz   |      Owner:  dbevans
      Type:  defect        |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.8.1
Resolution:                |   Keywords:
      Port:  libhandy-0.0  |
---------------------------+----------------------

Old description:

> 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.

New description:

 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.

--

Comment (by ryandesign):

 Replying to [ticket:68056 philberthfz]:
 > When trying to build on arm64, the file that gets downloaded is modified
 from the version macports is expecting. A checksum bump is required.

 Before that can be done, we need to [wiki:FAQ#checksums understand what
 changed and why]. The difference between the old file (still on our mirror
 servers) and the new one on gitlab is:

 {{{#!diff
 % diff -ru
 macports/libhandy-v0.0.13-7a193d7692c9c76a1a94f17c4d30b585f77d177c
 upstream/libhandy-v0.0.13-7a193d7692c9c76a1a94f17c4d30b585f77d177c
 Only in
 upstream/libhandy-v0.0.13-7a193d7692c9c76a1a94f17c4d30b585f77d177c: debian
 }}}

 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_distfiles` to ignore the new
 file—this is probably the best course of action) or switch to the new
 distfile (updating `checksums` and performing the other tasks of a
 [wiki:PortfileRecipes#stealth-updates stealth update]).

 > 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.

 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`.

-- 
Ticket URL: <https://trac.macports.org/ticket/68056#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS