[gentoo-amd64] Re: portage rmd160 digest errors

[Duncan]

Benny Pedersen posted on Mon, 26 Apr 2010 15:53:21 +0200 as excerpted:

> media-libs/raptor/raptor-1.4.21.ebuild
> media-video/kmplayer/kmplayer-0.11.2b.ebuild
>
> just my server ?

No issues here (just synced and updated everything).

In my experience, digest issues are usually one of three things.

One that can happen if you're actually trying to (re)merge the package is 
an error fetching the sources, such that an incomplete or incorrect source 
or patch tarball is downloaded.  The digest error in this case mentions 
the tarball in question, and the fix is easy enough: simply delete the 
thing so portage can redownload it, hopefully correctly this time.

If the digest error indicates it's the ebuild itself, it can either be a 
similar issue there, in which case a fresh sync should solve the issue, 
or, occasionally, it's an issue with the tools the Gentoo devs use to do 
their updates, such that they actually upload an incorrect value.  These 
problems are generally caught and fixed quite rapidly but not immediately 
-- if you're not too impatient, wait a few hours or a day and resync.  The 
problem will have generally been fixed by then.  If you're impatient or 
just curious, or the problem hasn't been fixed in a day, check bugzilla 
for a related bug (be sure to begin the query with the keyword ALL, so you 
get fixed issues too, this'll often return a quite a lot of old bugs as 
well, but you can look at just the highest numbered ones, the last couple 
of days worth of bugs, since this sort of bug shouldn't be years or even 
weeks old).  Likely, someone has already filed one.  If not, file one 
yourself, and see what happens.

The third type of error is again with the sources tarballs, but in this 
case it's due to upstream pulling a no-no, updating the tarball (so it 
doesn't verify against the old checksums) without changing the version 
number.  These often take a bit longer to resolve, perhaps a few days, as 
the Gentoo dev has to research the issue and find out if the change is 
legit, or not.  Thankfully, it doesn't happen often (at least with 
officially released code, tarballs made available to the distributions for 
testing a few hours or days before a big public release, such as of kde, 
do occasionally get changed before final public release, if a critical 
reason to do so is found, but if you're on a testing team with access to 
that sort of thing, you generally know about it right away, as you're 
following the immediately pre-release testing and discussion), but when it 
does, there's a real security danger in just accepting the new code 
without verifying it, so getting upstream confirmation that they did in 
fact change the sources without changing the version number is vital -- 
and you can be sure that they're getting enough complaints from various 
distribution and compile-your-own users, that most upstreams don't tend to 
to make /that/ mistake again.

Of course, the problem can also be a deliberately tampered with ebuild or 
tarball, as well, one of the reasons it's not recommended to simply 
manually redigest the package yourself, and continue as if nothing was 
wrong.  Redigesting is possible (ebuild /path/to/ebuild digest), and if 
you find a bug confirming it was indeed a simple mistake, you can if you 
wish redigest and continue, instead of doing a full resync, but DO confirm 
that it was a mistake, checking the bug report or the like, before doing 
so, just in case.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman