#65303 closed defect (fixed)
magic-wormhole 0.12.0: revision needs to be bumped for new python version
| Reported by: | jrabinow | Owned by: | herbygillot (Herby Gillot) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | Cc: | ||
| Port: | magic-wormhole |
Description
The last PR here https://github.com/macports/macports-ports/pull/14037 dates from February 17th. However https://packages.macports.org/magic-wormhole/ shows that the last build was on 2021-12-06 and only included the x86-64 version.
Further, looking at files downloaded from https://pypi.org/project/magic-wormhole/#files shows no hardcoded references to python3.8 However, downloading files from the macports package server shows that there is a hardcoded reference to python3.8 in what I'm assuming is an autogenerated script:
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
This makes me wonder if the build system isn't failing somehow. It may not be the build system, but I'm pretty sure it's not coming from the port itself.
Change History (4)
comment:1 Changed 2 years ago by jmroot (Joshua Root)
| Cc: | herbygillot removed |
|---|---|
| Component: | server/hosting → ports |
| Owner: | changed from admin@… to herbygillot |
| Status: | new → assigned |
| Summary: | magic-wormhole 0.12.0: easy-install autogenerated script refers to hardcoded python version → magic-wormhole 0.12.0: revision needs to be bumped for new python version |
comment:2 Changed 2 years ago by jrabinow
Thanks, just created a PR to bump the revision number https://github.com/macports/macports-ports/pull/15078
comment:3 Changed 2 years ago by jmroot (Joshua Root)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
For future reference, you can put a line like Fixes: https://trac.macports.org/ticket/65303 in the body of the commit message to have it automatically close the ticket.
comment:4 Changed 2 years ago by jmroot (Joshua Root)
Replying to jrabinow:
the last build was on 2021-12-06 and only included the x86-64 version.
BTW, it looks like this port is pure python, so it could set supported_archs noarch.
The problem is simply that the PR that changed which python version is used didn't also increase the revision.