cloud.github.com no longer resolves. It is not likely to return. I don't have a fix, but wanted to lodge the PR to the issue known. $ host cloud.github.com cloud.github.com is an alias for d24z2fz21y4fag.cloudfront.net. $ host d24z2fz21y4fag.cloudfront.net $ This results in fetch failures. At least one port has been marked BROKEN because of this and since fixed[1] The lines in question [2]: # We are cheating and using backend URLS for GitHub here. See ports/194898 # comment #15 for explanation as to why and how to deal with it if it breaks. MASTER_SITE_GITHUB+= https://codeload.github.com/%SUBDIR% MASTER_SITE_GITHUB_CLOUD+= https://cloud.github.com/downloads/%SUBDIR% From reading comment #15 [3](as mentioned above), it is not clear to me how to proceed. [1] sysutils/zfs-stats - https://svnweb.freebsd.org/ports?view=revision&revision=518503 [2] https://github.com/freebsd/freebsd-ports/blob/master/Mk/bsd.sites.mk#L392-L395 [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194898#c15
bapt@ tells me there's only about 20 ports affected.
I will email those maintainers.
The list: converters/lua-iconv/Makefile:MAINTAINER= vanilla@FreeBSD.org converters/lua51-iconv/Makefile:MAINTAINER= feld@FreeBSD.org deskutils/devd-notifier/Makefile:MAINTAINER= f.unglaub@googlemail.com devel/libcli/Makefile:MAINTAINER= ports@FreeBSD.org graphics/glosm/Makefile:MAINTAINER= amdmi3@FreeBSD.org java/netty-tcnative/Makefile:MAINTAINER= dvl@FreeBSD.org lang/rhino/Makefile:MAINTAINER= nivit@FreeBSD.org mail/libsieve/Makefile:MAINTAINER= ports@FreeBSD.org math/liblbfgs/Makefile:MAINTAINER= gaod@hychen.org sysutils/bsdinfo/Makefile:MAINTAINER= freebsd-ports@samu.pl sysutils/confctl/Makefile:MAINTAINER= trasz@FreeBSD.org textproc/syck/Makefile:MAINTAINER= ports@FreeBSD.org www/ach/Makefile:MAINTAINER= danilo@FreeBSD.org www/mod_xsendfile/Makefile:MAINTAINER= potatosaladx@gmail.com www/p5-Ark/Makefile:MAINTAINER= kuriyama@FreeBSD.org www/tinytinyhttpd/Makefile:MAINTAINER= smatsui@karashi.org
mail to smatsui@karashi.org bounced.
As I understand it from the mailing list thread; it's a problem with/on GitHub that they are (unwilling?) to resolve. Couldn't someone, maybe even me, simply mirror GHC on say GitLab. Then use the mirror for any, and all affected ports? Maybe even GHC itself? Just a thought. :) --Chris
Just removing the "cloud." subdomain seems to suffice? i.e. change bsd.sites.mk to use https://github.com/downloads/%SUBDIR%
(In reply to andrew from comment #6) Confirmed that everything that still points to GHC passes 'make checksum' if this change is made.
I'd suggest we dump the GHC altogether and convert those few ports to simple MASTER_SITES=https://github.com/downloads/... to be done with it. GHC itself now is misspelling since they dropped the "cloud" prefix. Even when it was meaningful, it was still confusing to have usual GitHub-related knobs meaning something else in presence of MASTER_SITES=GHC. It's hacky and confusing, asking for abuse and mistakes.
devel/breakpad also seems to be affected, but just changing cloud.github.com to github.com in bsd.sites.mk did not solve the problem. The project ( https://github.com/google/breakpad ) exists. Does anyone know how to deal with it?
(In reply to Hiroo Ono from comment #9) devel/breakpad is not using MASTER_SITES=GHC and is therefore not affected by this bug. Whatever is causing it to fail to fetch is unrelated. (FWIW, right now _all_ github downloads appear to be failing for me with "500: Internal Server Error")
(In reply to Hiroo Ono from comment #9) Now that github isn't broken, it's clear that the issue with devel/breakpad is that the file size and/or checksum has changed (which is a common issue with ports that just fetch a github snapshot). Updating the distinfo should be sufficient, but given that the port is nearly 3 years out of date it may require more attention than that.
*** Bug 245055 has been marked as a duplicate of this bug. ***
This domain is still gone. More importantly, we should support their releases framework in some manner so we don't keep duplicating the same MASTER_SITES over again and to satisfy 5.4.3 in the handbook.
Moin moin Please re-open, if this is still an issue. mfg Tobias