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".
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
