Bug 239079 - math/metis: Use SSL MASTER_SITES
Summary: math/metis: Use SSL MASTER_SITES
Status: Closed Not Accepted
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Lorenzo Salvadore
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2019-07-09 19:46 UTC by Miyashita Touka
Modified: 2020-02-25 16:51 UTC (History)
3 users (show)

See Also:

Attachments
patch (481 bytes, patch)
2019-07-09 19:46 UTC, Miyashita Touka 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

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]
patch

Switch MASTER_SITES to HTTPS.
Comment 1 Miyashita Touka 2019-08-01 18:29:53 UTC 
Maintainer timeout.
Comment 2 Koichiro Iwao freebsd_committer freebsd_triage 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.
Comment 4 Lorenzo Salvadore freebsd_committer freebsd_triage 2019-10-15 15:40:22 UTC 
Comment on attachment 205616 [details]
patch

Hello, I am the new maintainer of metis.

I am sorry but I have to reject the patch: I am unable to find any relation between the official metis site and the GitHub repository you suggest. Thus, I do not find reasons to prefer

https://github.com/scivision/METIS (your suggestion)

rather than one of those, for example:

https://github.com/EmanueleCannizzaro/metis
https://github.com/scibuilder/metis

On the other hand, Karypis Lab, which wrote the software, is slowly moving its codes to GitHub, so we will soon probably have a patch to use GitHub as you suggested.
In the meantime I think this PR can be closed: we can open a new one when the GitHub repository from the authors will be ready.

Thanks for your time.
Comment 5 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-02-25 16:50:48 UTC 
Close this myself because of comment #4 (I was not a committer before and could not do it earlier).