I'm not sure whether to consider this a bug in portage (emerge/ebuild) itself, or a bug in the SRC_URI used by sys-firmware/intel-microcode . When attempting to emerge an update to sys-firmware/intel-microcode from a system which requires connection through a proxy, I get errors during the download (see below). The proxy settings in make.conf seems to work fine for all other emerges in my @world. If I download the tarball manually and place it in /usr/portage/distfiles/ then sys-firmware/intel-microcode installs fine. I suspect the problem is that the SRC_URI in the ebuild file gets 302-redirected, and portage gets confused about handling that through the proxy. # grep proxy /etc/portage/make.conf http_proxy="http://ip6-localhost:8880" https_proxy="http://ip6-localhost:8880" # emerge -1 sys-firmware/intel-microcode Calculating dependencies... done! >>> Verifying ebuild manifests >>> Running pre-merge checks for sys-firmware/intel-microcode-20191115_p20191110 >>> Emerging (1 of 1) sys-firmware/intel-microcode-20191115_p20191110::gentoo >>> Downloading 'https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20191115.tar.gz' --2020-02-02 21:56:29-- https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20191115.tar.gz Resolving ip6-localhost... ::1 Connecting to ip6-localhost|::1|:8880... connected. Failed reading proxy response: Success Retrying. --2020-02-02 21:56:30-- (try: 2) https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20191115.tar.gz Connecting to ip6-localhost|::1|:8880... connected. Failed reading proxy response: Success Retrying. --2020-02-02 21:56:32-- (try: 3) https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20191115.tar.gz Connecting to ip6-localhost|::1|:8880... connected. Failed reading proxy response: Success Giving up. !!! Couldn't download 'microcode-20191115.tar.gz'. Aborting. * Fetch failed for 'sys-firmware/intel-microcode-20191115_p20191110', Log file: * '/var/tmp/portage/sys-firmware/intel-microcode-20191115_p20191110/temp/build.log' # ssh $proxyhost wget -v https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20191115.tar.gz 2>&1 | egrep 'response|Location' HTTP request sent, awaiting response... 302 Found Location: https://codeload.github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/tar.gz/microcode-20191115 [following] HTTP request sent, awaiting response... 200 OK
Can you reproduce the problem by downloading the same file with wget outside of portage? How about with some other client, such as curl?
Um, right... should have done that instead of the ssh... and trying that suggests that the problem is actually with my proxy, which is net-proxy/http-replicator . $ https_proxy=http://ip6-localhost:8880 wget -v https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20191115.tar.gz --2020-02-03 21:09:58-- https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20191115.tar.gz Resolving ip6-localhost... ::1 Connecting to ip6-localhost|::1|:8880... connected. Failed reading proxy response: Success Retrying. [and a few more retries] Using a net-proxy/tinyproxy instance works fine: $ https_proxy=http://ip6-localhost:9388 wget https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20191115.tar.gz 2>&1 | tail -n2 2020-02-03 21:18:20 (2.87 MB/s) - 'microcode-20191115.tar.gz.3' saved [2998063/2998063] So changing the title in this bug to belong to net-proxy/http-replicator; re-assign as needed.
