>>>>> Martin Maechler <maech...@stat.math.ethz.ch> >>>>> on Thu, 7 Dec 2017 17:37:23 +0100 writes:
>>>>> Neil Shephard <nsheph...@gmail.com> >>>>> on Tue, 5 Dec 2017 08:18:08 +0000 writes: >> Hi, I've only just caught up on the update to ess-17.11 >> and went to install it using the Gentoo Linux package >> management system portage. >> It complained that the ess-17.11.tgz was not a compressed >> archive and this appears to be true, its just a plain >> tar-ball. > well, I'm managing the ess.r-project.org server and I have > actually mounted the file system where ess-17.11.tgz lives > and 'ls -l' and 'file' say > ls -l ess-17.11.tgz -rw-r--r--. 1 maechler sfsstaff > 3275703 Nov 13 15:13 ess-17.11.tgz > file ess-17.11.tgz ess-17.11.tgz: gzip compressed data, > last modified: Mon Nov 13 14:13:29 2017, from Unix > (and read on) >> This means that when portage trys to unpack it based on >> the file extension '.tgz' it tries to uncompress it, >> which fails. >> For now I've change the ebuild (the scripts which install >> programmes under Gentoo/Linux) to use the ess-17.11.zip >> but thought this worth reporting. I include below >> downloading the ess-17.11.tgz and attempting to >> unzip/uncompress manually, what finally worked was >> renaming to ess-17.11.tar and untar the archive. >> Details of this are also on Gentoo Buzilla at >> https://bugs.gentoo.org/639752 >> Regards, >> Neil > Now look closely at the output of wget -- which I can > reproduce in my (Fedora 26) Linux : >> ~/tmp/ess $ wget >> http://ess.r-project.org/downloads/ess/ess-17.11.tgz >> --2017-12-05 08:12:09-- >> http://ess.r-project.org/downloads/ess/ess-17.11.tgz >> Resolving ess.r-project.org... 129.132.119.195 Connecting >> to ess.r-project.org|129.132.119.195|:80... connected. >> HTTP request sent, awaiting response... 200 OK Length: >> 3275703 (3.1M) [application/x-tar] > ^^^^^^^^^^^^^^ >> Saving to: ‘ess-17.11.tgz’ >> >> ess-17.11.tgz >> 100%[===========================================================================================>] >> 3.12M 6.30MB/s in 0.5s >> >> 2017-12-05 08:12:09 (6.30 MB/s) - ‘ess-17.11.tgz’ saved >> [8898560] > ^^^^^^^^ > so indeed wget seems to do __silly!__ behave a bit > magically nowadays ... -- at least being honest about it: > It gets a *.tgz of size 3275703 bytes (~ 3.1 M) and > internally uses gunzip absolutely with*OUT* saying so, but > then honestly reports that the result is of size 8898560 > bytes > I'm appalled. > Note one thing though: For 2 year or so, 'tar' has become > smart enough to "see" if it needs to uncompress or not; so > for practical purposes, you nowadays can use > tar xf <file> > and it will do the right thing if the file is compressed > or not. Well, not quite: If the file ends in *.tgz it tries automatically to use gunzip on it and fails... so it seems the manual 'mv ...tgz ...tar' seems needed. Ok, now having skimmed the result of 'wget --help', I see (among HTTP options) : --compression=TYPE choose compression, one of auto, gzip and none and indeed some silly people made 'auto' the default *and* forgot to implement a renaming of *.tgz --> *.tar in the case of auto compression. The solution for (tested): Use wget --compression=none : $ wget --compression=none http://ess.r-project.org/downloads/ess/ess-17.11.tgz --2017-12-07 17:40:02-- http://ess.r-project.org/downloads/ess/ess-17.11.tgz Resolving ess.r-project.org (ess.r-project.org)... 129.132.119.195 Connecting to ess.r-project.org (ess.r-project.org)|129.132.119.195|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3275703 (3.1M) [application/x-tar] Saving to: 'ess-17.11.tgz.1' ess-17.11.tgz.1 100%[==========================>] 3.12M --.-KB/s in 0.04s 2017-12-07 17:40:02 (81.1 MB/s) - 'ess-17.11.tgz.1' saved [3275703/3275703] -- Martin Maechler ETH Zurich ______________________________________________ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help