Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED]Why does adobe-flash always fail verification?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Havin_it
Veteran
Veteran


Joined: 17 Jul 2005
Posts: 1240
Location: Edinburgh, UK

PostPosted: Wed Jan 29, 2014 4:31 pm    Post subject: [SOLVED]Why does adobe-flash always fail verification? Reply with quote

Title says it all. Time and time again, a new version of adobe-flash gets a digest and/or filesize verification failure when you try to emerge it. A bug is raised, and the portage tree gets the manifest tweaked, and all is well (until the next time).

It's just really odd that this keeps happening with this one package. Anyone know what the cause is?


Last edited by Havin_it on Sat Feb 01, 2014 12:32 pm; edited 1 time in total
Back to top
View user's profile Send private message
franzf
Advocate
Advocate


Joined: 29 Mar 2005
Posts: 4565

PostPosted: Wed Jan 29, 2014 4:52 pm    Post subject: Reply with quote

The reason is adobes missing versioning of the .tar.gz "For other linux configurations": It is only called "install_flash_player_11_linux.x86_64.tar.gz". So if they release a new bugfix version they simply replace that single file on their servers. The ebuild dowloads that file, does not recognize that it is a new version (how should portage be able to?) and then verification fails. It's the same issue as with googleearth...
Back to top
View user's profile Send private message
Havin_it
Veteran
Veteran


Joined: 17 Jul 2005
Posts: 1240
Location: Edinburgh, UK

PostPosted: Wed Jan 29, 2014 5:56 pm    Post subject: Reply with quote

Thanks franzf, illuminating!

So do they make updates to the dist archive without announcing it as a new version? (So the bug-report and updating the manifest has to happen every time because nobody's warned of it)

Or is it just the lag in getting fresh ebuilds/manifests into the tree after a new version is announced?

In either case, it's nice to actually know what's going on. Perhaps it'd be worth an einfo in the ebuild (if it fails in this manner) to explain that this is probably the reason...
Back to top
View user's profile Send private message
user
Apprentice
Apprentice


Joined: 08 Feb 2004
Posts: 194

PostPosted: Wed Jan 29, 2014 6:50 pm    Post subject: Reply with quote

hi Havin_it,
adobe deals with versions in directory names.
Code:
# ebuild /usr/portage/www-plugins/adobe-flash/adobe-flash-11.2.202.335.ebuild clean prepare | grep macromedia
>>> Downloading 'http://fpdownload.macromedia.com/get/flashplayer/pdc/11.2.202.335/install_flash_player_11_linux.x86_64.tar.gz'
--2014-01-29 19:44:35--  http://fpdownload.macromedia.com/get/flashplayer/pdc/11.2.202.335/install_flash_player_11_linux.x86_64.tar.gz


But gentoo distfiles logic handle only filenames.

Next adobe-flash update results in a checksum error, because saved source from distfile directory is used.

You need to delete your old saved source from distfile directory.
Back to top
View user's profile Send private message
franzf
Advocate
Advocate


Joined: 29 Mar 2005
Posts: 4565

PostPosted: Wed Jan 29, 2014 8:11 pm    Post subject: Reply with quote

Indead, I missed the ${PV} in the SRC_URI.
But:
The downloaded file get's renamed, so that it has a proper version:
Code:
AF_64_URI="${AF_URI}/${PV}/install_flash_player_${PV_M}_linux.x86_64.tar.gz -> ${P}.x86_64.tar.gz"

Havin_it: Could you post an actual error message? Would be interesting to see where it fails.
When did it happen the last time for you?
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Wed Jan 29, 2014 10:44 pm    Post subject: Reply with quote

Thanks for the explanation. Without knowing what the trouble was, I wrote the following script and run it as /usr/sbin/fixadobe whenever I see there is a new adobe ebuild.

It hurts nothing to run it more than once:

Code:
#!/bin/bash

cd /usr/portage/www-plugins/adobe-flash
ls
rm Manifest
ebuild `equery w adobe-flash` digest
Back to top
View user's profile Send private message
Havin_it
Veteran
Veteran


Joined: 17 Jul 2005
Posts: 1240
Location: Edinburgh, UK

PostPosted: Wed Jan 29, 2014 11:38 pm    Post subject: Reply with quote

franzf wrote:
Indead, I missed the ${PV} in the SRC_URI.
But:
The downloaded file get's renamed, so that it has a proper version:
Code:
AF_64_URI="${AF_URI}/${PV}/install_flash_player_${PV_M}_linux.x86_64.tar.gz -> ${P}.x86_64.tar.gz"

Havin_it: Could you post an actual error message? Would be interesting to see where it fails.
When did it happen the last time for you?


Well, the fix is in now so it actually worked, but here's the emerge log from the last failure.
Code:
>>> Downloading 'http://fpdownload.macromedia.com/get/flashplayer/pdc/11.2.202.335/install_flash_player_11_linux.x86_64.tar.gz'
--2014-01-29 15:54:04--  http://fpdownload.macromedia.com/get/flashplayer/pdc/11.2.202.335/install_flash_player_11_linux.x86_64.tar.gz
Resolving hazel... 192.168.2.7
Connecting to hazel|192.168.2.7|:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 7234961 (6.9M)
Saving to: ‘/usr/portage/distfiles/adobe-flash-11.2.202.335.x86_64.tar.gz’

100%[======================================>] 7,234,961   4.16MB/s   in 1.7s   

2014-01-29 15:54:06 (4.16 MB/s) - ‘/usr/portage/distfiles/adobe-flash-11.2.202.335.x86_64.tar.gz’ saved [7234961/7234961]

!!! Fetched file: adobe-flash-11.2.202.335.x86_64.tar.gz VERIFY FAILED!
!!! Reason: Filesize does not match recorded size
!!! Got:      7234961
!!! Expected: 7234767
Refetching... File renamed to '/usr/portage/distfiles/adobe-flash-11.2.202.335.x86_64.tar.gz._checksum_failure_.ye3ssk'

!!! Couldn't download 'adobe-flash-11.2.202.335.x86_64.tar.gz'. Aborting.
 * Fetch failed for 'www-plugins/adobe-flash-11.2.202.335', Log file:
 *  '/var/log/portage/www-plugins:adobe-flash-11.2.202.335:20140129-155404.log'


I have a horrible feeling there's a facepalm moment bearing down on me here: this is something to do with the proxy (http_replicator), isn't it?

EDIT: Yeah, I totally get it now. My local server does an emerge --sync and an emerge -uDf world every night, and it runs http_replicator (and acts as portage rsync mirror) for local clients such as my laptop.

http_replicator is stateless, so it just serves the file matching the requested filename from its cachedir regardless of the full URL.

Because my server (as an emerge client) doesn't invoke http_replicator (just downloads directly into the same dir as its cache), it always has the renamed-by-portage latest version at $DISTDIR/adobe-flash-*.tar.gz.

On the laptop, going through http_replicator, emerge always downloads the first version of install_flash_player_*_linux.x86_64.tar.gz from http_replicator's cache. So I can't get the current (bugfix) version unless I delete any previous version of that file from the server cache, or don't use the proxy.

Herp and, indeed, derp.

Fascinating though this all is, it doesn't explain what is happening for the other folk who are raising these regular bugs. Wha'gwan?
Back to top
View user's profile Send private message
user
Apprentice
Apprentice


Joined: 08 Feb 2004
Posts: 194

PostPosted: Thu Jan 30, 2014 4:53 pm    Post subject: Reply with quote

franzf pointed it out correctly.

distfiles logic is working.
But net-proxy/http-replicator can't detect content changes when file name is not altered.

You can add this to make.conf for skipping proxy usage.
Code:
# grep no_proxy /etc/portage/make.conf
no_proxy=fpdownload.macromedia.com
Back to top
View user's profile Send private message
Havin_it
Veteran
Veteran


Joined: 17 Jul 2005
Posts: 1240
Location: Edinburgh, UK

PostPosted: Sat Feb 01, 2014 12:31 pm    Post subject: Reply with quote

user wrote:
franzf pointed it out correctly.

distfiles logic is working.
But net-proxy/http-replicator can't detect content changes when file name is not altered.

You can add this to make.conf for skipping proxy usage.
Code:
# grep no_proxy /etc/portage/make.conf
no_proxy=fpdownload.macromedia.com


Very useful tip! I didn't know of this directive, thanks.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum