not responding when accessing a certain URL to 'port upgrade'

[Ryan Schmidt]

On May 24, 2009, at 03:32, Kuniaki Mukai wrote:

> There are URLs which start with "http://ftp.nara.wide.ad.jp/pub/X11/ 
> GNOME/sources/"
> such that "port upgrade" never proceed beyond fetching any of the  
> URLs, like
> the following, whenever I try at my home.
>
> % sudo port upgrade  libgsf
> Password:
> --->  Fetching glib2
> --->  Attempting to fetch glib-2.20.2.tar.bz2 from http:// 
> ftp.nara.wide.ad.jp/pub/X11/GNOME/sources/glib/2.20/
> (not responding)
>
> The urls "http://ftp.nara.wide.ad.jp/pub/X11/GNOME/sources/..."  are
> only such exceptions as far as I notice.
>
> However, there is no such troubles whenever I do 'port upgrade' at  
> my office.

I am able to access that URL from here (Austin, TX, USA) without  
problem. MacPorts will try to select a mirror that is close to you,  
so that's why it's choosing to try to download from this server for  
you. Perhaps there is a network routing issue particular to your ISP  
at home. You could contact your ISP. You might try a traceroute  
first, from home.

traceroute ftp.nara.wide.ad.jp

Snipping out the first few lines of local info on my network, I get:

  5  gi0-4-2-6.austtxrdcsc-rtr1.austin.rr.com (24.27.13.106)  176.554  
ms  182.478 ms  111.550 ms
  6  gig5-3-0.hstntxl3-rtr1.texas.rr.com (72.179.205.36)  25.058 ms   
121.933 ms  88.416 ms
  7  ae-2-0.cr0.hou30.tbone.rr.com (66.109.6.108)  95.928 ms  31.542  
ms  27.949 ms
  8  ae-0-0.cr0.dfw10.tbone.rr.com (66.109.6.39)  39.858 ms  45.453  
ms  29.736 ms
  9  ae-1-0.cr0.atl20.tbone.rr.com (66.109.6.37)  42.784 ms  75.379  
ms  40.967 ms
10  ae-0-0.cr1.atl20.tbone.rr.com (66.109.6.35)  53.405 ms  42.441  
ms  72.361 ms
11  ae-4-0.cr0.dca10.tbone.rr.com (66.109.6.33)  75.811 ms  66.592  
ms  58.880 ms
12  ae-2-0.pr0.dca10.tbone.rr.com (66.109.6.169)  56.337 ms  58.831  
ms  63.785 ms
13  * if-11-1.icore1.aeq-ashburn.as6453.net (206.82.139.53)  66.594  
ms  57.775 ms
14  * * *
15  ae-2.r21.asbnva01.us.bb.gin.ntt.net (129.250.2.98)  65.846 ms   
72.865 ms  66.197 ms
16  as-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.2.167)  100.097 ms   
100.978 ms  108.995 ms
17  as-2.r20.tokyjp01.jp.bb.gin.ntt.net (129.250.2.35)  211.099 ms   
227.839 ms  222.378 ms
18  * * *
19  203.105.72.18 (203.105.72.18)  567.084 ms  650.490 ms  798.452 ms
20  ve-3761.cisco2.dojima.wide.ad.jp (203.178.136.110)  870.333 ms   
448.823 ms  363.544 ms
21  ve-7.hitachi2.nara.wide.ad.jp (203.178.136.171)  381.526 ms   
349.230 ms  309.327 ms
22  ftp.nara.wide.ad.jp (203.178.137.175)  259.326 ms  208.178 ms   
218.856 ms

Perhaps for you, you can't get all the way to the destination server?  
If not, note the last server you can get to, and work with your ISP  
on figuring out why you can't get past it.

Another option is to manually download the distfiles and place them  
into the directory where MacPorts expects them. In the case of glib2,  
that's /opt/local/var/macports/distfiles/glib2.

You could also edit the file _resources/port1.0/fetch/ 
mirror_sites.tcl inside your ports tree directory, and remove this  
mirror. But unless you have switched from an rsync directory to a  
Subversion working copy, this change will be overwritten next time  
you "port sync".