Bug 239079 - math/metis: Use SSL MASTER_SITES
Summary: math/metis: Use SSL MASTER_SITES
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
Keywords: needs-qa
Depends on:
Reported: 2019-07-09 19:46 UTC by Miyashita Touka
Modified: 2019-08-23 11:10 UTC (History)
2 users (show)

See Also:

patch (481 bytes, patch)
2019-07-09 19:46 UTC, Miyashita Touka
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Miyashita Touka 2019-07-09 19:46:59 UTC
Created attachment 205616 [details]

Comment 1 Miyashita Touka 2019-08-01 18:29:53 UTC
Maintainer timeout.
Comment 2 Koichiro Iwao freebsd_committer 2019-08-23 03:37:26 UTC
I'm not sure the GitHub repo is reliable official mirror.
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2019-08-23 07:09:42 UTC
Even if its 'reliable' in the connectivity/availability sense it may not be appropriate as it may not provide processed files in the same form as the distribution.

Further, using a direct URL per attachment 205616 [details] to github, and to the master branch directly, is not framework compliant. USE_GITHUB/GH_* variables must be used to obtain a named (either by tag or commit hash) tarball, not a moving target.

If it is determined and confirmed that using GitHub as the source for these files is appropriate, the changeset it should also be fully QA'd to ensure that additional or further port changes are not necessary.

For example, but not limited to: often repository tarballs for projects that use GNU autoconf as a build system  require auto[re]conf/auto* tools to be run first to produce ./configure & Makefiles which exist in the distribution tarballs, but not in the repository sources.

Alternatively, this may be closed -> Not Accepted in favour of requesting upstream support SSL on their existing distribution file host

Given this port currently has no maintainer, I'd tend to lean towards the latter as the best present/first port of call to resolve this issue.