I suspect this is the same problem that happened in bug #133136 (libkdepim, same issue, quickly fixed), since in both cases it appears there was an updated ebuild, pulled and then recreated, with the size then off by six bytes. Something's obviously not working quite as it should be. Either that, or there simply needs to be a rule saying if an ebuild is pulled, the -rX number must still be bumped, to avoid this issue. Duncan
Seems to me the problem is with new repoman. Basically the sync between cvs and the master rsync was done after repoman committed the ebuild and before it committed the new Manifest. The checkout is perfectly fine wrt Manifest and size.
Argh! I must be tired! That was supposed to include this: !!! Digest verification failed: !!! /str/portage/dev-util/confcache/confcache-0.4.2-r1.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 1001 !!! Expected: 1007 ViewCVS says 1007 also, as expected based on the other bug. Again as expected, the only diff is the Header line, which naturally would be different thru ViewCVS since it supplies a ViewCVS header. That should give you a bit more to go on! =8^) You work fast, even with that little info! =8^) Mid-air collision detected! Posting this anyway as for all I know it's still useful.
(In reply to comment #1) > Seems to me the problem is with new repoman. > > Basically the sync between cvs and the master rsync was done after repoman > committed the ebuild and before it committed the new Manifest. > > The checkout is perfectly fine wrt Manifest and size. This is nothing new. Due to our use of cvs tags, there is always a window of time where the file containing the cvs tag will not have a correct Manifest entry. If the cvs tags were dropped, we could commit the ebuild and Manifest atomically.
Oh damn, now I get what Duncan meant with "pulled", there was an old -r1. The problem seems to be that when I committed it the $Header: $ line left the Attic/ part (and now we see the 6 bytes discrepancy, too). Infra, is that a problem with CVS server?
I'm not sure exactly what caused this but it seems to be an isolated incident.
*** Bug 145480 has been marked as a duplicate of this bug. ***