ports/devel/noweb/Makefile FETCH_* is wrong, comment out works.

[Julian H. Stacey]

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 <mat at FreeBSD.org>
> To: "Julian H. Stacey" <jhs at berklix.com>, ports at freebsd.org
> Message-ID: <a0d82435-754d-25ad-ce60-255f125c462e at FreeBSD.org>
> Subject: Re: ports/devel/noweb/Makefile FETCH_* is wrong, comment out works.
> References: <201701051334.v05DYjAj003862 at fire.js.berklix.net>
> In-Reply-To: <201701051334.v05DYjAj003862 at 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, <ftpmaster at 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