Apr 26, 2010, 11:52 AM
Post #2 of 3
(1409 views)
Permalink
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