Fetching tar.gz archives from at least ftp://ftp.uni-kl.de/pub/linux/gentoo/distfiles are getting uncompressed after download by wget. the http-protocol (i.e. http://ftp.uni-kl.de/pub/linux/gentoo/distfiles) does not show this behaviour. This results in checksum mismatches and therefore in a package refetch. I got this problem solved by adding --compression=none in make.conf in the variables FETCHCOMMAND and RESUMECOMMAND Reproducible: Always Steps to Reproduce: emerge --nodeps --fetchonly dev-java/protobuf-java
This sounds like a bug in wget. Decompressing files from FTP automatically is not a "feature". The --compression options doesn't mention doing anything for ftp servers; it only mentions the Content-Encoding HTTP header.
I am unable to reproduce this with net-misc/wget-1.19.2. % GENTOO_MIRRORS="ftp://ftp.uni-kl.de/pub/linux/gentoo" ebuild xz-utils-5.2.3.ebuild fetch >>> Downloading 'ftp://ftp.uni-kl.de/pub/linux/gentoo/distfiles/xz-5.2.3.tar.gz' --2017-11-02 10:44:11-- ftp://ftp.uni-kl.de/pub/linux/gentoo/distfiles/xz-5.2.3.tar.gz => ‘/var/portage/distfiles/xz-5.2.3.tar.gz’ Resolving ftp.uni-kl.de (ftp.uni-kl.de)... 131.246.123.4, 2001:638:208:ef1b:0:ff:fe00:4 Connecting to ftp.uni-kl.de (ftp.uni-kl.de)|131.246.123.4|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD (1) /pub/linux/gentoo/distfiles ... done. ==> SIZE xz-5.2.3.tar.gz ... 1490665 ==> PASV ... done. ==> RETR xz-5.2.3.tar.gz ... done. Length: 1490665 (1.4M) (unauthoritative) xz-5.2.3.tar.gz 100%[===================>] 1.42M 1.93MB/s in 0.7s 2017-11-02 10:44:13 (1.93 MB/s) - ‘/var/portage/distfiles/xz-5.2.3.tar.gz’ saved [1490665] * xz-5.2.3.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] % file /var/portage/distfiles/xz-5.2.3.tar.gz /var/portage/distfiles/xz-5.2.3.tar.gz: gzip compressed data, max compression, from Unix
(In reply to Mike Gilbert from comment #2) > I am unable to reproduce this with net-misc/wget-1.19.2. I found the error: my squid proxy uncompressed the archive. So you can close this bug as invalid. It is strange to me, this happened so unexpected. I haven't touched my proxy config for months, but the error just appeared first in the last days.
Just FYI, this is not a bug in wget, though the description might be confusing. The option is to enable transparent compression of files that are not compressed. The server must not use this for download of compressed files, since it does not compress them transparently (well, unless it does second layer of compression). The question then is: did you actually set anything non-standard in Squid that caused this? If not, then it's a bug in Squid and it should be reported as such.
*** Bug 640930 has been marked as a duplicate of this bug. ***
