Version 11.2.202.356.x86_6 of www-plugins/adobe-flash fails digets verification and all previous versions have been removed from portage. # emerge -u adobe-flash [...] Downloading 'http://fpdownload.macromedia.com/get/flashplayer/pdc/11.2.202.356/install_flash_player_11_linux.x86_64.tar.gz' --2014-05-08 16:39:12-- http://fpdownload.macromedia.com/get/flashplayer/pdc/11.2.202.356/install_flash_player_11_linux.x86_64.tar.gz Resolving serv.prhnet... 192.168.0.2 Connecting to serv.prhnet|192.168.0.2|:8080... connected. Proxy request sent, awaiting response... 200 OK Length: 7235769 (6.9M) Saving to: ‘/usr/portage/distfiles/adobe-flash-11.2.202.356.x86_64.tar.gz’ 100%[======================================>] 7,235,769 16.3MB/s in 0.4s 2014-05-08 16:39:12 (16.3 MB/s) - ‘/usr/portage/distfiles/adobe-flash-11.2.202.356.x86_64.tar.gz’ saved [7235769/7235769] !!! Fetched file: adobe-flash-11.2.202.356.x86_64.tar.gz VERIFY FAILED! !!! Reason: Filesize does not match recorded size !!! Got: 7235769 !!! Expected: 7235641 Refetching... File renamed to '/usr/portage/distfiles/adobe-flash-11.2.202.356.x86_64.tar.gz._checksum_failure_.4QnNJt'
I can't reproduce that. Do you use a caching proxy?
Yes, I have a box on the LAN that runs squid and http-replicator. Taking your hint, I ran wget with --no-proxy to get the flash file and had no further problem, so it looks like I shouldn't have raised the bug. Sorry. I had a similar problem with the previous version too, so a pattern seemed to be emerging (no pun intended). But why should my proxy have bad copies of these two versions of adobe-flash and yet never another bad file in the (few) years I've been running this way? Anyway, I'll close the bug report.
(In reply to Peter Humphrey from comment #2) > Yes, I have a box on the LAN that runs squid and http-replicator. Taking > your hint, I ran wget with --no-proxy to get the flash file and had no > further problem, so it looks like I shouldn't have raised the bug. Sorry. > > I had a similar problem with the previous version too, so a pattern seemed > to be emerging (no pun intended). But why should my proxy have bad copies of > these two versions of adobe-flash and yet never another bad file in the > (few) years I've been running this way? Because Adobe doesn't version their files properly, and because your caching proxy fails at distinguishing the URLs. The URLs contain the version as a directory and include only the major version in the file name. A SRC_URI arrow is used to save the downloaded file under a more useful name that includes the package name and version. You would need to teach your proxy to distinguish between those directories. (For the 64-bit installer:) http://fpdownload.macromedia.com/get/flashplayer/pdc/${PV}/install_flash_player_${PV_M}_linux.x86_64.tar.gz -> ${P}.x86_64.tar.gz What emerge ends up seeing is the part after the arrow "->", while the former is being requested from your proxy. It should be easy to tell it not to cache it or to pay better attention. :)
I use http-replicator to buffer emerge's source fetches. It has no built-in options to filter what it gets, at least not as far as I can see. Maybe I should arrange it to fetch through the local squid proxy, though it seems wasteful to cache files twice. Thanks for the explanation anyway - you must weary of telling everyone who stumbles over this problem.
