Mathieu Arnold wrote: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --OlhIXV1DiGlq1dCEecu9IveGpJTBcCo6s > Content-Type: multipart/mixed; boundary="95npiUFepM5pQXkT1NqmlD2AdL7GsX8e5"; > protected-headers="v1" > From: Mathieu Arnold <m...@freebsd.org> > To: "Julian H. Stacey" <j...@berklix.com>, po...@freebsd.org > Message-ID: <a0d82435-754d-25ad-ce60-255f125c4...@freebsd.org> > Subject: Re: ports/devel/noweb/Makefile FETCH_* is wrong, comment out works. > References: <201701051334.v05dyjaj003...@fire.js.berklix.net> > In-Reply-To: <201701051334.v05dyjaj003...@fire.js.berklix.net> > > --95npiUFepM5pQXkT1NqmlD2AdL7GsX8e5 > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: quoted-printable > > Le 05/01/2017 =C3=A0 14:34, Julian H. Stacey a =C3=A9crit : > > ports/devel/noweb/Makefile contains > > FETCH_CMD=3D /usr/bin/ftp > > FETCH_ARGS=3D # empty > > that is wrong, because if one already has the distfile on a local site > > (accessed via MASTER_SITE_OVERRIDE or MASTER_SITE_BACKUP ),=20 > > it hangs & fails on make fetch. > > > > This is true. But: > > $ fetch -v ftp://www.eecs.harvard.edu/pub/nr/noweb-2.11b.tgz > looking up www.eecs.harvard.edu > connecting to www.eecs.harvard.edu:21 > setting passive mode > opening data connection > fetch: ftp://www.eecs.harvard.edu/pub/nr/noweb-2.11b.tgz: No route to hos= > t
On 3 boxes direct connected to internet: 6.4-RELEASE SUCCESS fetch -v ftp://www.eecs.harvard.edu/pub/nr/noweb-2.11b.tgz looking up www.eecs.harvard.edu connecting to www.eecs.harvard.edu:21 binding data socket initiating transfer remote size / mtime: 738870 / 1150149960 noweb-2.11b.tgz 100% of 721 kB 288 kBps 10.3-p4 FAIL fetch -v ftp://www.eecs.harvard.edu/pub/nr/noweb-2.11b.tgz looking up www.eecs.harvard.edu connecting to www.eecs.harvard.edu:21 setting passive mode opening data connection fetch: ftp://www.eecs.harvard.edu/pub/nr/noweb-2.11b.tgz: Operation timed out source `which unsetenv.csh`;printenv PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin TERM=xterm fetch -v ftp://www.eecs.harvard.edu/pub/nr/noweb-2.11b.tgz looking up www.eecs.harvard.edu connecting to www.eecs.harvard.edu:21 setting passive mode opening data connection fetch: ftp://www.eecs.harvard.edu/pub/nr/noweb-2.11b.tgz: Operation timed out 10.3-STABLE FAIL fetch -v ftp://www.eecs.harvard.edu/pub/nr/noweb-2.11b.tgz looking up www.eecs.harvard.edu connecting to www.eecs.harvard.edu:21 setting passive mode opening data connection fetch: ftp://www.eecs.harvard.edu/pub/nr/noweb-2.11b.tgz: No route to host source `which unsetenv.csh`;printenv PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin TERM=xterm fetch -v ftp://www.eecs.harvard.edu/pub/nr/noweb-2.11b.tgz looking up www.eecs.harvard.edu connecting to www.eecs.harvard.edu:21 setting passive mode opening data connection fetch: ftp://www.eecs.harvard.edu/pub/nr/noweb-2.11b.tgz: No route to host > > And: > > $ ftp ftp://www.eecs.harvard.edu/pub/nr/noweb-2.11b.tgz > Connected to www-aws.eecs.harvard.edu. > 220- > Anonymous access only (no uploads). > For authenticated access, please use SCP, SFTP, or FTP over SSH. > Thank you, <ftpmas...@eecs.harvard.edu>. > 220 FTP Server ready. > 331 Anonymous login ok, send your complete email address as your password= > > 230 Anonymous login ok, restrictions apply. > Remote system type is UNIX. > Using binary mode to transfer files. > 200 Type set to I > 250 CWD command successful > 250 CWD command successful > local: noweb-2.11b.tgz remote: noweb-2.11b.tgz > 229 Entering Extended Passive Mode (|||65306|) > 150 Opening BINARY mode data connection for noweb-2.11b.tgz (738870 bytes= > ) > 100% > |************************************************************************= > *************************************************************************= > *****************************************************************| =20 > 721 KiB 599.13 KiB/s 00:00 ETA226 Transfer complete > 738870 bytes received in 00:01 (554.01 KiB/s) > 221 Goodbye. > $ > > The port MUST be able to fetch from its MASTER_SITE, and I am talking > about the one in the Makefile, not what gets added/changed by the > framework. Otherwise, the backup master site, or the place where you > have a local cache cannot be filled with something in the first place. Yes, agreed > In the future, when fetch(1) manages to fetch from that ftp site on all > our supported releases, feel free to patch the Makefile. This looks like a regression failure with fetch as 6.4 fetch works fine. Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. http://berklix.eu/brexit/#stolen_votes _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"