Nope - not related.janos666 wrote:I am not sure how these things might be related but I think it was an indirect result of this bug that depclean unmerged nano which should be pulled in by the active system profile. ...
Code: Select all
!!! Digest verification failed:
!!! /usr/portage/sys-apps/busybox/busybox-9999.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 8493
!!! Expected: 8580
dufeu wrote:--sync re-pulls the manifests in the portage tree.StupidBunny wrote:I'm having the same problem with the same package. I'll try --exclude for the time being (I tried remaking the manifest as above, followed by a --sync, and that didn't work.)
What you did was correct the manifest locally - and then overwrite your correction by re-pulling the bad manifest from the portage tree.
The problem is that the manifest in the tree is wrong. The infrastructure team is aware of the problem and making a permanent solution to what ever caused the problem to begin with. The related 'changelog' problem appears to be resolved.
Baiscally, for now when you want to do an @world update - you need to do --sync and then either skip the package:or do your --sync and force correct your manifest locally then perform your @world update:Code: Select all
emerge --exclude="sys-apps/buxybox" @worldYou'll need to do this until the infrastructure team completes their fix.Code: Select all
ebuild /usr/portage/sys-apps/busybox/busybox-9999.ebuild manifest emerge @world
I'd just go ahead with the force local manifest fix the first time so you can get the upgrade to busybox and then use the --exclude option until the portage tree is fixed.
And have patience. I'm certain the infrastructure team is as eager for a permanenet, correct fix so that the problem doesn't recur as everyone else.
Yes.MMMMM wrote:But should this ebuild file not corrected in portage tree anyway?
But since the problem shouldn't have occurred to begin with, the infrastructure team also needs to make sure the original cause can't recur.
I can't speak for the infrastucture team nor am I a gentoo developer or any other kind of developer. The team may have good reason not to correct the bad manifest record yet. I know they'll do it and I'm certain they want to do it right.
In the meantime, either of the work arounds above are pretty painless. It's just a bit annoying to remember to do them after every --sync. For now, I set up my --sync command like so:It's painless and I'm monitoring the situation unltil the issue is fixed. Then I'll drop rebuilding the busybox manifest after each --sync..Code: Select all
date && time emaint --auto sync && time eix-update && date && ebuild /usr/portage/sys-apps/busybox/busybox-9999.ebuild manifest
neogold ... no, why should anyone trust you, a random forum poster, more than, say, themselves, and generate the manifest locally? Its the fact that Manifests fail that provides a measure of the tree integrity, overriding this is a risk taken by the user .... they might as well generate a new manifest themselves, rather than copy the above, they could even get a copy from git if that integrity is in question.neogold wrote:go into manifest file in your repo /usr/portage/sys-apps/busyboxy/ and replace that file with this
I mean fixed in the tree. The update may not have made it to whichever public server you got.yzg wrote:It is marked "FIXED". I just did emerge sync and the problem is still there
Do you mean fixed by the workarounds like ebuild digest or it is real fix in the portage tree?
Code: Select all
--exclude busyboxTHX ^^ this did the job=DvD= wrote:Guys: justwhen updating and wait for the fix to be pulled in with a future sync!Code: Select all
--exclude busybox
Code: Select all
# emerge -uDN --exclude busybox worldThe link to bug #565694 is also in my Orighinal Post as one of the edits. I've been keeping that post up-to-date.Tony0945 wrote:Link?dufeu wrote: You may want to go to the bug where this is being tracked. They're asking for specific information regarding --sync timestamp and what manifest records you ended up.