not responding when accessing a certain URL to 'port upgrade'
Kuniaki Mukai
mukai at sfc.keio.ac.jp
Sun May 24 07:27:00 PDT 2009
Ryan,
Thank you for analysing the trouble and giving suggestions
to solve it. I will take time to digest your suggestions.
To type the command 'traceroute' the ip address is only what I can do
for now.
(The ip address not responding is at the last line of the traceroute
output.)
% traceroute ftp.nara.wide.ad.jp
traceroute to ftp.nara.wide.ad.jp (203.178.137.175), 64 hops max, 40
byte packets
1 10.0.1.1 (10.0.1.1) 3.085 ms 3.492 ms 6.613 ms
2 wapiti.kanagawa-ip.dti.ne.jp (203.181.66.8) 11.770 ms 30.983
ms 10.475 ms
3 ip-gate.kanagawa-ip1.dti.ad.jp (203.181.66.1) 11.876 ms 16.644
ms 14.623 ms
4 kanagawa-ip1-gate-1.otemachi4.dti.ad.jp (202.216.252.26) 18.657
ms 15.522 ms 13.319 ms
5 gate1-gate-ix1.otemachi4.dti.ad.jp (202.216.225.133) 16.685 ms
13.643 ms 11.767 ms
6 xe-3-4.a16.tokyjp01.jp.ra.gin.ntt.net (61.213.169.85) 13.872 ms
10.932 ms 9.912 ms
7 xe-6-2-0.a20.tokyjp01.jp.ra.gin.ntt.net (61.120.147.201) 10.783
ms 13.298 ms 13.311 ms
8 xe-1-1.a15.tokyjp01.jp.ra.gin.ntt.net (203.105.72.58) 14.464 ms
16.182 ms 16.595 ms
9 203.105.72.18 (203.105.72.18) 31.465 ms 11.881 ms 10.916 ms
10 ve-3761.cisco2.dojima.wide.ad.jp (203.178.136.110) 20.548 ms
20.217 ms 21.743 ms
11 ve-7.hitachi2.nara.wide.ad.jp (203.178.136.171) 24.418 ms 30.465
ms 26.487 ms
12 ftp.nara.wide.ad.jp (203.178.137.175) 25.544 ms 22.010 ms
27.251 ms
Kuniaki
On May 24, 2009, at 9:00 PM, Ryan Schmidt wrote:
> 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".
>
>
More information about the macports-users
mailing list