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
