If a mirror gives an error for an emerge download, portage does not continue to the next one(s), but aborts. Reproducible: Always Steps to Reproduce: emerge --fetchonly sys-apps/file Actual Results: [...] >>> Downloading 'ftp://ftp.gw.com/mirrors/pub/unix/file/patch-4.20-REG_STARTEND' --21:10:14-- ftp://ftp.gw.com/mirrors/pub/unix/file/patch-4.20-REG_STARTEND => `/usr/portage/distfiles/patch-4.20-REG_STARTEND' Resolving localhost... 127.0.0.1 Connecting to localhost|127.0.0.1|:3128... connected. Proxy request sent, awaiting response... 502 Bad Gateway 21:10:47 ERROR 502: Bad Gateway. !!! Couldn't download 'patch-4.20-REG_STARTEND'. Aborting. Expected Results: emerge should have tried the next server listed in GENTOO_MIRRORS. The "502 Bad Gateway" was sent by the remote site, not the proxy, which just passes it on. (In this particular case, it is due to a deliberately misconfigured ftp server that rejects requests where the PASV request and the subsequent connect are from two different IPs. Probably because some coder didn't envision that people can have multiple IPs, and thought this would be indicative of hacking. It could have been any 5xx error, and these do occur from time to time -- this is just an example, so please don't jump on the fact that this was triggered by a load balanced connection, nor that the remote ftp server is misconfigured. It's the fact that emerge didn't continue I'm reporting here, not that there was a 502 error. :-) )
It's no fault of sys-apps/portage. The ebuild specifies RESTRICT=mirror and there's only one URI for patch-4.20-REG_STARTEND listed in SRC_URI.
If patch-4.20-REG_STARTEND can legally be mirrored then we can add mirror://gentoo/patch-4.20-REG_STARTEND to SRC_URI in order to have that file exempted from fetch restriction.
has nothing to do with legality ... look at the bug # listed in the ebuild
