On Sat, Sep 18, 2010 at 1:13 AM, Albert Hopkins <mar...@letterboxes.org> wrote: > On Fri, 2010-09-17 at 18:23 -0700, Mark Knecht wrote: > [...] >> >>> Verifying ebuild manifests >> >> !!! Digest verification failed: >> !!! /usr/portage/kde-base/ark/files/ark-4.4.5-cli7zip.patch >> !!! Reason: Failed on RMD160 verification >> !!! Got: 285b725e7542b78815f0f909a65b4b6ec20cee89 >> !!! Expected: 57369a955bff3038ad0c105eea0179bbb795a030 >> firefly ~ # >> >> Google isn't turning anything up. Normally these things get cleared >> up within about a day but this time around I'm starting to wonder if I >> have some other problem here and this is only a symptom? >> >> I'm sure there's some way I can get past it WRT emerge but I'd >> rather get it handled at the source if possible. I though about >> deleting things in the path shown above but I haven't ever removed >> anything except distfiles and didn't want to start now. > > Why not? It's in your portage tree. Any deleted/altered files get > replaced on the next --sync anyway. > > Having said that. My copy of the file indeed matches the manifest. So > either you need to re --sync, delete the file and re --sync, or try > syncing from a different mirror.
Thanks Albert. It worked and the problem is gone. In a related way I've never stopped to look at /usr in the process of doing an install. I have an old Mac Mini that I've been trying to get Gentoo running on recently so in the middle of my install this morning I stopped after untarring the stage-3 tarball and before untarring the portage snapshot and found that /usr/portage doesn't exist at that point. Does this suggest that I'm actually free at any time to rm -r /usr/portage and just untar the current snapshot? Other than distfiles and the overhead of downloading all that stuff again is there anything in /usr/portage that once erased would damage the machine? I can always get most of distfile from other machines around here so it's really a question as to whether portage and emerge build anything in /usr/portage that cannot be recreated without much trouble. Thanks again, Mark
