This problem seems to have plagued us for a very long time and I've finally gotten around to studying it. The root of the problem is that when an ebuild is re-added to cvs after being removed (it still exists in the Attic), cvs updates the header on the client side with an erroneous "Attic/" element in the ebuild path. Subsequent checkouts of the ebuild will not have the erroneous "Attic/" element in the header. Since repoman then generates the Manifest using the client side ebuild (with corrupt header), the Manifest is broken. The telltale signature for this problem is an ebuild having a size that is exactly 6 bytes smaller than that recorded in the Manifest (6 bytes is the number of characters in "Attic/"). It seems like the ideal solution would be to patch cvs so that it correctly updates the client side header after the commit. If necessary, a workaround can be added to repoman itself, but that would be suboptimal.
Another issue which might be similar to this is that initial cvs imports frequently seem to result in broken Manifests. I've observed this today with the initial import of x11-themes/qtcurve: !!! Digest verification failed: !!! /home/gmirror/gentoo-x86/x11-themes/qtcurve/qtcurve-0.46.4.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 701 !!! Expected: 598 In this case the size if off by 103 bytes which is approximately the size that the path in the header should be (perhaps cvs doesn't insert the path into the header for an initial import like this).
(In reply to comment #1) > Another issue which might be similar to this is that initial cvs imports > frequently seem to result in broken Manifests. I've observed this today with > the initial import of x11-themes/qtcurve: Nevermind the above. The x11-themes/qtcurve Manifest was not committed by repoman.
Created attachment 125543 [details, diff] automatically detect "/Attic/" in the $Header path and correct it This is fixed in svn r7341.
This has been released in 2.1.3_rc9.
