The SRC_URI for ARM packages is currently broken in all ebuilds since 375.39: $ wget http://http.download.nvidia.com/XFree86/Linux-x86-ARM/381.22/NVIDIA-Linux-armv7l-gnueabihf-381.22.run --2017-05-13 22:13:42-- http://http.download.nvidia.com/XFree86/Linux-x86-ARM/381.22/NVIDIA-Linux-armv7l-gnueabihf-381.22.run Resolving http.download.nvidia.com... 192.229.221.58, 2606:2800:233:ef6:15dd:1ece:1d50:1e1 Connecting to http.download.nvidia.com|192.229.221.58|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2017-05-13 22:13:43 ERROR 404: Not Found. The directory name for the ARM packages in SRC_URI should be "Linux-32bit-ARM" instead of "Linux-x86-ARM": $ wget http://http.download.nvidia.com/XFree86/Linux-32bit-ARM/381.22/NVIDIA-Linux-armv7l-gnueabihf-381.22.run --2017-05-13 22:25:00-- http://http.download.nvidia.com/XFree86/Linux-32bit-ARM/381.22/NVIDIA-Linux-armv7l-gnueabihf-381.22.run Resolving http.download.nvidia.com... 192.229.221.58, 2606:2800:233:ef6:15dd:1ece:1d50:1e1 Connecting to http.download.nvidia.com|192.229.221.58|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 26815484 (26M) [application/octet-stream] Saving to: ‘NVIDIA-Linux-armv7l-gnueabihf-381.22.run’
It worked for me, oddly. I can see how the x86 -> 32bit change would make sense, but why then was I able to download the differently named files as well?
Hmm, interestingly, this appears to be an inconsistency in the directory naming between the us.download[...] and http.download[...] domains, respectively: $ wget http://http.download.nvidia.com/XFree86/Linux-x86-ARM/381.22/NVIDIA-Linux-armv7l-gnueabihf-381.22.run --2017-05-15 12:45:23-- http://http.download.nvidia.com/XFree86/Linux-x86-ARM/381.22/NVIDIA-Linux-armv7l-gnueabihf-381.22.run Resolving http.download.nvidia.com... 192.229.221.58, 2606:2800:233:ef6:15dd:1ece:1d50:1e1 Connecting to http.download.nvidia.com|192.229.221.58|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2017-05-15 12:45:24 ERROR 404: Not Found. $ wget http://us.download.nvidia.com/XFree86/Linux-x86-ARM/381.22/NVIDIA-Linux-armv7l-gnueabihf-381.22.run --2017-05-15 12:47:53-- http://us.download.nvidia.com/XFree86/Linux-x86-ARM/381.22/NVIDIA-Linux-armv7l-gnueabihf-381.22.run Resolving us.download.nvidia.com... 192.229.221.58, 2606:2800:233:ef6:15dd:1ece:1d50:1e1 Connecting to us.download.nvidia.com|192.229.221.58|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 26815484 (26M) [application/octet-stream] Saving to: ‘NVIDIA-Linux-armv7l-gnueabihf-381.22.run’ I'd assume you've fetched the files before the recent SRC_URI change to http.download[...].
(In reply to niniel from comment #2) > Hmm, interestingly, this appears to be an inconsistency in the directory > naming between the us.download[...] and http.download[...] domains, > respectively: Yes, some outside committer messed up some of the ebuilds for about a day when I wasn't looking. I reverted that in bug #618224 and specified a different URL for nvidia-settings tarballs from then on.
I'm afraid this happened even earlier in bug #617096 via [1] when you altered the SRC_URI from us.download[...] to http.download[...] in the first place while fixing bug #617096. The mess-up you are referring to (mentioned in bug #618224 via [2]) reverted that to us.download[...], breaking the settings package, which you, in turn, reverted again to http.download[...] (via [3]), fixing the settings package but breaking the ARM package. We're mixing up two different problems here. While the nvidia-settings issue is currently fixed, the ARM package (NVIDIA-Linux-armv7l-gnueabihf-381.22.run) is not accessible. [1] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f41d9628eae446301363c2ec84fc9c495d6ff4b6 [2] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6d13e04dfc44a35bf8da24975a76d17bb7f5c18 [3] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e6adfce1c34aaca5dec9fc0ab8ab18bab4f30458
Fixed again. Hopefully.
