| 1 |
On Montag 26 April 2010, Duncan wrote: |
| 2 |
> Benny Pedersen posted on Mon, 26 Apr 2010 15:53:21 +0200 as excerpted: |
| 3 |
> > media-libs/raptor/raptor-1.4.21.ebuild |
| 4 |
> > media-video/kmplayer/kmplayer-0.11.2b.ebuild |
| 5 |
> > |
| 6 |
> > just my server ? |
| 7 |
> |
| 8 |
> No issues here (just synced and updated everything). |
| 9 |
> |
| 10 |
> In my experience, digest issues are usually one of three things. |
| 11 |
> |
| 12 |
> One that can happen if you're actually trying to (re)merge the package is |
| 13 |
> an error fetching the sources, such that an incomplete or incorrect source |
| 14 |
> or patch tarball is downloaded. The digest error in this case mentions |
| 15 |
> the tarball in question, and the fix is easy enough: simply delete the |
| 16 |
> thing so portage can redownload it, hopefully correctly this time. |
| 17 |
|
| 18 |
you don't need to remove it. Portage will rename the failed tarball and retry |
| 19 |
the next time. You have to clean DISTFILES from failed packages once in a |
| 20 |
while. But it is not necessary from a 'portage will redownload it' POV. |
| 21 |
Example: |
| 22 |
/var/portage/distfiles/necflash_linux.tgz._checksum_failure_.We1z4V |
| 23 |
|
| 24 |
|
| 25 |
> |
| 26 |
> The third type of error is again with the sources tarballs, but in this |
| 27 |
> case it's due to upstream pulling a no-no, updating the tarball (so it |
| 28 |
> doesn't verify against the old checksums) without changing the version |
| 29 |
> number. These often take a bit longer to resolve, perhaps a few days, |
| 30 |
|
| 31 |
usually only a few hours after the initial bugreport. But sometimes weeks (see |
| 32 |
binflash). |
Archives